【失敗の記録】株を始めてみました

今まであまり投資ということを考えて生きてませんでしたが、「インベスターZ」という漫画を読み始めた影響で株を始めてみました。

インベスターZは、

ある北海道の中高一貫校に通う普通の中学生の少年（成績は新入生の中でトップ）が学校に存在する「投資部」に誘われ、そこから株やFXといった投資を覚え始め隠れた才能を発揮していく...

という内容です。そもそもインベスターZを読もうと思ったきっかけとして「そろそろ株でも始めてみるか」という思いがあり、色々と初心者向けの本はあると思ったんですが漫画の方がわかりやすいだろうということで手に取りました。まぁ漫画なので展開とかはドラマチックすぎる部分もあるのですが、「株をやってみようかな？」と迷ってる自分からすると「やってみたら楽しいよ」と背中を押してくれるような内容でした。

インベスターZ(1)

 面白いので、興味のある方は、是非どうぞ

どの株を買うか

株を買う、というのを決めたものの「どこで」買うか、「どんな」株を買うかが何も決まってませんでした。

どこでについては色々とあると思うのですが、自分が普段使ってる銀行が三菱UFJ銀行だったのでカブドットコムを使うことにしました。普通口座からカブドットコムへの資金の移行も簡単だったためです。手数料とか本当は色々比較すべき部分もあったと思うのですが、その辺りはあまり考慮せず・・・という感じです。

次にどんな株を買うか、についてですが自分自身の職業がITエンジニア（SE）ということもあり少なくとも知ってる業界の方がいいだろうということでIT系の株をチョイスしました。

銘柄は「2303：ドーン」「3915：テラスカイ」「4442：バルテス 」の3銘柄です。

ドーンは「地理情報システム（ＧＩＳ）構築ソフト「ジオベース」をリソースとしたソフト受託開発が主力」という企業なのですが、今後のドローンの運用がどんどん普及していくと考えた時に地理情報システムというのはシステム会社としてアドバンテージだと思ったためです。

テラスカイは「米セールスフォースとＡＷＳのクラウドシステム導入支援・開発事業を展開。大企業向け強い」という企業です。いつかのニュースで政府？がAWSを積極的に運用していく方針というのを見た気がしたので、AWSの導入支援を大企業向けに強いのであれば今後の成長が見込めるかな？と考えたためです。

バルテスは「ソフトウェアテスト事業が主力。関連の品質コンサル、人材派遣やセキュリティ・脆弱性診断も」という企業で、最近多いソフトウェアテストを事業の柱としている中で2019年5月末に上場したばかりの会社です。ソフトウェアテストという事業は今後ニーズの拡大が感じられる上にきっと業績も良いだろう、と思ったためです。

いきなり失敗

株を買うときの鉄則？として「安く買って高く売る」というのがあります。商売ごとならそうですが、安く仕入れて高く売って利益を出すのは当たり前ですね。

わかっていましたが、まず上記3銘柄ですが現在のところ「安く買う」ことはできていません。

まずバルテスについては上場直後の高値ほどではないですが、かなり高い株価で買ってしまい、しばらく含み損（300株買ったので10万ほど）がありました。しかし、8/9の決算発表？で黒字への上方修正があったことで含み損は減りました。まだ株価としては安いような気もしてるんですけどね...

ドーンについては「この会社いいな〜」と思ったタイミングで株価が上昇していたため、「このビッグウェーブに乗らないと損だ！」と焦って購入してしまい（200株）、その後じわじわ上昇したものの株価の上下を繰り返した挙句、現在で3万円程度の含み損です。事業自体は今後も期待できるので、今は底値っぽいのでもうちょっと粘ってみたいです。

テラスカイは100株試しに買った後、決算発表により利益が40パーセントも上回ったことで一気にストップ高となりいきなり含み益が5万円くらい出ることになりました。その時点で売っても良かったのですが、欲をかき保持し続けている状況です。その後は緩やかに株価は下がり、現在の含み益は3万円程度です。量子コンピュータ事業にも進出らしいので今後期待できる感じはあります。

株を始めてわかったこと

まず、鉄則を忘れないようにすること...「安く買って高く売る」。慌てて買っても株価は上がればその後下がるようなタイミングがあり、上がる材料がなければ下がり続けるだけというのがなんとなくわかったので（これもどうかわかってませんが）。よく「買いたい時が買うタイミング」的な言葉が買うのを悩む人に対して背中を押すものとしてありますが、株の場合買ったその場から価値が上下するのである程度はよく考えた上で買ってもいいんじゃないか、と思いました。

また、IT業界以外の業界株については全くわからないままです。ヤフーファイナンスでその日その日で「値上がり率トップ」の銘柄が一覧に並びますが、「なんでこの株が上がったの？」という銘柄ばかりで（おそらく決算発表の結果が良かったから、ということでしょうが）、それまでノータッチなのでちょっとビックリします。

ただ、銀行に普通口座にそのまま預けているだけより全然良い、というのは実感しました。

今後

時間が取れないため、デイトレード的な運用は難しいのである程度保持して運用する方が自分にとってはいいのかもしれません。本当に利益を出すならデイトレードなのかもしれませんが...

含み損が多くてちょっとナーバスになりますが、株を始めて「面白い」と感じたのは事実で、これまで興味のなかった経済ニュースが妙に耳に入るようになってきました。株なんてやらなきゃ良かったなとは思ってません。今後も有望な企業を探して、安いタイミング（それって結局日経が暴落してるタイミングじゃないの、という気もしてますが）で買えるように頑張ります！

株とPython─自作プログラムでお金儲けを目指す本 (技術の泉シリーズ（NextPublishing）)

世界一やさしい 株の教科書 1年生

マンガでわかる最強の株入門

図解・最新　難しいことはわかりませんが、お金の増やし方を教えてください！

投資と金融がわかりたい人のための ファイナンス理論入門　プライシング・ポートフォリオ・リスク管理

環境は仕事の出来不出来に影響するか？

プロ野球の世界では、頻繁ではないが年に何度かトレードが実施される。トレードとはチームに所属する選手を他球団の選手と交換すること（場合によっては金銭との交換もある）。それまであまり活躍していなかった選手が他球団に移籍したところ、今まで活躍してなかったのが嘘のように活躍するなんていうこともある。最近のトレードで印象的なのが、元巨人の大田泰示選手。巨人ではレギュラーでもなくあまり活躍してなかった印象だが、移籍先の日本ハムファイターズではレギュラーとして活躍している。巨人は「常勝」が宿命づけられた球界でも特に異質な雰囲気を持つチームというのもあり、かかるプレッシャーも甚大ではなかっただろうというのは想像に難くない。もしかしたらプレッシャー以外に、ファイターズでは指導者に恵まれたのかもしれない（特に監督が「三振を恐るな！」とアドバイスを与えたことが大田本人にとってよかったというインタビューをどこかで見た）。

プロ野球の世界でなくても一般的なサラリーマン、例えばエンジニアでも似たようなことはあると思っている。極端なことを言えば、常に無茶な要求ばかりしてくるクライアントやパワハラ上等の上司や先輩社員に囲まれ、システム開発において不明点があっても気軽に質問や雑談をする雰囲気にならない同僚ばかりだとしてまともに仕事が出来るだろうか。そんな環境で仕事が上手くいかなくて、「仕事ができないやつ」という烙印を押されたとしてそれは本当だろうか。

元々のポテンシャルがどれだけあろうが、そんな環境ではまともに仕事ができない人がほとんどだろうと思う。たまたまストレス耐性が人より高くて環境に関係なく仕事をスムーズに出来る人もいるかもしれないが、そんな人が「当たり前」なはずはなく仕事ができない方が当たり前だろう。

でもそんな環境にいると仕事ができない自分というのが当たり前に感じられなくて、自己嫌悪に陥ることもある。その場にいるとその場だけが世界の全てで比較対象がその中にしかないから、自分が仕事が出来ないのは自分が悪いせいとしか考えられなくなる。

もしかしたら勉強が足りないことが影響してる部分もあるかもしれないし、経験が足りてないことで判断できないことがあるのかもしれない。でもそれが理由で仕事が出来ないとしたら上司や先輩はなんのためにいるの？会社はなんのためにあるの？となる。出来ない部下や後輩がいるならそれを上手く指導したりするのが上司や先輩の役目なはず。会社も全員とは言わないまでも大体の人が上手く仕事が出来るようにするような仕組みを作るべきでしょう。

パワハラ上司や無理解な先輩社員、不愉快な同僚という組み合わせの場合だけでなく、このいずれか、または自分にとって負担でしかないような環境の職場であれば、転職することも視野に入れるべきだと思う。野球選手の場合、トレードを志願することで移籍することが出来る場合もごく稀にあるが、基本はトレードやフリーエージェントという仕組みを利用しないと環境を変えることはできないが、サラリーマンであればそのあたりの制約はない。

長々書いてきたが、実は今のプロジェクト先で「仕事が出来ておらずとても自己嫌悪に陥っている」のです。もともと開発のセンスがなく、実装から逃げてばかりいたので、上記で書いたような状況とはまた違うのですが、仕事を指示してくれるプロパーの社員さんの当たりが厳しく心身がしなびてきてしまったのです。

もうベテランとよばれてもおかしくない年齢とキャリアを重ねてきているので、「プログラムの組み方」を改めて手取り足取り教えてもらうという状況も異常だと思うし...学校じゃないんだから。役立たずで申し訳なくて恥ずかしくて死んでしまいそうでした。なので、現場を変えてもらう要望を出したのですが、案外プロジェクト先の評価はそこまで悪いものではなく、「役に立ってないということはなく、今後も頑張ってほしい」という意外なもの。

ただプログラミングの考え方はみっちり身についたので、別の現場で改めてリスタートした方が精神的にはいいかなぁと思っている次第です。

もしブラック・ジャックが仕事の悩みに答えたら

まんがで変わる 仕事は楽しいかね?

神メンタル 「心が強い人」の人生は思い通り

スキルがないまま中堅になってしまった人のための　仕事は簡単と思えるようになる本 (Panda Publishing)

仕事が辛い辞めたい時に見る本: お金の問題を解決しよう 仕事の悩み解決 (gomao books)

【ゲーム感想】FinalFantasyⅫ The Zodiac Ageをプレイしました

久々にゲームしました。前にPS2で途中までプレイしてたファイナルファンタジー12(FF12）のHD化されたリメイクを買ったのでプレイ感想を書きたいと思います。

まだクリアしてないので、途中までのプレイ感想になりますが、よかったらお付き合いください。 基本的にストーリーの根幹に関わるようなネタバレはない方向で

どんなストーリーか

すごくざっくり言うと、

強大な軍事国家であるアルケイディア帝国とその帝国に侵略されたダルマスカ王国の王家の生き残りであるアーシェが 帝国への復讐を狙う

というのが今のところの本筋になっているけど、そこまで単純な話ではないかもしれない。 関わるキャラクターがたくさん出てくるので、誰が誰だっけ？となるので混乱するが、完全な群像劇ではないので話自体は上記の通り すごくシンプル。

キャラクターは割とリアルな作りだと思う

造形が、という話じゃなく。 主要な登場人物は7人。

• ダルマスカ王国の王家の生き残りである、アーシェ
• ダルマスカ王国の将軍だった男、バッシュ
• 空賊という自由な生き方をしてる、バルフレア
• バルフレアの相棒であり、魅力的なヒップのフラン
• ダルマスカ王国の国民（つまり一般人）のヴァン
• 同じくダルマスカ王国の国民でヴァンの幼馴染のパンネロ
• アルケイディア帝国皇帝グラミスの三男（長男・次男は死んだ）で、軍事的に天才的な才能を持つヴェイン

どの辺がリアルか、というと
最初はヴァンが主人公というか物語を引っ張っていくのかな？と想像していたのに プレイしているとヴァンは無邪気な少年で、世間知らずな面もあるけれどパーティのムードを盛り上げる 楽しいキャラクターではあるものの、物語の中心人物ではない感じ。

王家復興を行動の主体としているアーシェやバッシュに比べて動機が薄いし、 空賊としてすでにキャリアを積んでるバルフレアやフランとは物事の見通しのレベルが違う。

そもそもアーシェがヴァンに頼るようなポイントがないので、パーティのリーダー的立場として振る舞うようになる というのは自然じゃない。安易にヴァンを主人公としてパーティに据えないのはよかったと思う。
（まだクリアしてないので、どういう展開になるのかは実はちょっとまだわかってないんだけども）

FF12のメインキャラクターと、登場種族たち

広大なフィールド、ダンジョン

FF12のフィールドはオープンワールドではないけれど、とても広い。 ケチってチョコボを利用しないで徒歩で移動すると特に広い。 広いけど、ダルマスカの東西に広がる砂漠に、南のギーザ草原、森林地帯や山岳地帯、海岸線などロケーションは豊富で飽きない。 冒険中にふと立ち止まってキャプチャを撮ってしまう。

頑張って撮ったパンチラ

FF12のイヴァリース世界で最も文明の進んだ都市である帝国領内

ガラスの不透明感とかすごくいい感じ

ダンジョンも、古代の遺跡や坑道にありふれた洞窟などパターンもたくさんあり、そのどれもが細部に至るまできちんとデザインがされていて 製作スタッフの徹底したこだわりに頭がさがる思いだ。 FF15でも一つの街、一つのロケーションで「誰も見てないんじゃないの？」という部分までデザインがされていてため息が出たけど。 何よりこれだけの内容をPS2時代に実現していた、ということを考えると本当にFFの製作スタッフはすごい。 いまだにPS4をプラットフォームとしながらそのスペックのほとんど使わず紙芝居みたいな会話シーンでお茶を濁している 他メーカーとの力量の差を強く感じる。

ただのショーケースだけど、とてもリアルに作られてる

空賊のお姉さん。ファッションがとてもセクシーですね。

ガンビットシステムは癖があるが、慣れれば楽しい

PS2版でプレイした時は、いわゆるモンスターと接触からの戦闘エリアに移動してコマンド戦闘するという従来のRPGに慣れていた自分は フィールドでモンスターと接触してそのまま戦闘に移るFF12のシステムに違和感があり、なおかつパーティメンバーに対してつどつど指示を出す のではなく「指示書」としてガンビットを使うというのに全く慣れなかった。

エンジニアとして働く今なら「IF文の羅列」という仕組みに非常に馴染みができているのだけど、 それでももうちょっとパターンというか「IF〜ELSE」くらい欲しかったような気もする。 でもELSEまで含めてしまうと、ネストが深くなってもっと分かり難かったかもしれない。

しかし、慣れてはいるものの、いまだにガンビットを上手に使えていない。

「これで固定してOK」という運用じゃなくて、 ガンビットは固定ではなくて、戦う場所やモンスターによってその場で書き換えて運用するのが正しいのかもしれない。

美人姉妹

不満点は？

実はこれといった不満点はあまりない。 今回のリメイクで実装された高速モード（通常のプレイを2倍または4倍でプレイすることが出来る）があることで 広いイヴァリースの世界もそんなに苦ではないし。

一つ挙げるとしたら、MAPと自分の進行方向がよくわからなくなることが多くて、 行きたい方向と真逆に行ってしまうことが多々ある。L3ボタンで現在地のMAP表示が出来るようになっているのですごく 便利なのだけど、MAPと自分自身との連動がうまくいかないのでイライラすることが結構ある。

世界観の細部を突けば、飛空艇が非常に発達した世界であればその前に一般市民がもっと利用できるような自動車、バイクと行った交通手段が 発達してないとおかしいような気もする。帝国領内では空中を移動するタクシーが運行しているのに、それを外の世界で 使わないのはなんか変な感じ。人の行き来が飛空艇、またはクリスタルを介したものがメインになっているのと モンスターが跋扈している世界なので、自動車なんて危なくて乗ってられなかったりするのかもしれないけど。

とは言ってもやっぱり自動車（そもそも整備された道路がない）のは変だな。都市から都市へ荷物を運ぶのは飛空艇を利用するとして 飛空艇のステーションから離れた場所に荷物を運ぶ時どうしてるんだろ。人力？

クリア前の感想

とてもよくできたRPGで、他にPS4で一般的なRPGで遊べるものがない人は遊んでみたほうがいいと思う。 最初のジョブ選択ではよく考えたほうがいいとは思うけども。

ファイナルファンタジーXII ザ ゾディアック エイジ - PS4

ファイナルファンタジーXII ザ ゾディアック エイジ - Switch

ファイナルファンタジーXII ザ ゾディアック エイジ アルティマニア (SE-MOOK)

ファイナルファンタジー XV 初回生産特典 武器「正宗/FINAL FANTASY XVオリジナルモデル」アイテムコード同梱 - PS4

ソースコード読めないプログラマがソースコードを読むために教えてもらったこと

懺悔めいた前置き(長くなってしまった）

今のプロジェクトに入るまでしばらくコーディングから離れていた。
プログラミングが苦手だったので、意図的に実装フェーズに関わらないようにプロジェクトを選んでいたので当たり前なんだけども。

なんで苦手かといえば、

• ソースが読めない
• 意図した通りにプログラムを組むことが出来ない

そんなのプログラマとして致命的だし向いてないからエンジニア辞めろ！という感じだが、 辞めず（追い出されずに、と言ってもいいかも）にこの業界に残れているのはひとえに周りに助けられてきたから。

ゴミエンジニアである自分が存在している時点で関わったプロジェクトの迷惑になっていて、それ自体は本当に申し訳ないんだけども、周りのおかげでなんとかエンジニアとして生きながらえさせてもらっていた。

前述の通り実装に不安を抱えていたので、ここ数年はテスト設計フェーズからのプロジェクトに参画していた。

いくつかWEB系プロジェクトのテストフェーズに関わり、そのままテストエンジニア（名前だけで中身は伴ってない）としてエンジニアを続けていければよかったのだけども、WEB系プロジェクトでテスト設計から関わってみて気づいたのが、自分が持つ「標準的なWEBアプリケーションに関する知識」が足りてないという実感。
今まで業務系システム（C言語でオンプレミス）ばかり関わってきていたので、WEB系は本当に門外漢もいいところ。

WEBアプリケーションの基本部分を知らないと、業務的にWEBアプリケーションとしてテストすべき観点等が 曖昧になり、テスト設計がきちんと出来てこない。 という認識が漠然とある。

知識がないので、確認すべきこと・確認しなくてもよいことの判断も出来ない。
テストとして不足していることにも気づけない。 内部の動きがわからないので、きちんと動いているかどうかをWEB画面上で表面的にしか確認できない。

もちろんWEBの知識が不完全でも、テスト設計するのは自分だけではないのでテストケースが出来上がらないということもないし、
レビューで指摘を受ければ足りないことを加筆修正することは出来るので、テスト設計自体が「まったく出来ない」訳ではない。

やはりずっと心理的に 「プログラムから離れていると不安である」ということを抱えているのかもしれない。 なので、テスト設計と併せてWEBアプリケーションの実装もさせてもらえるような条件を探してもらって今のSES先に入りこんだわけです。

今のSES先ではプロジェクト自体はいくつも並行で走っていて、
そのうちの一つに関わっている。周りにいるプログラマはそれぞれ別のプロジェクトに関わっているので、関わりは全くない（全く無関係ではないが、今のところ直接関係してない感じ）。

自分の担当プロジェクトでは、「リーダー」の下に自分だけがいるという構成になっている。久々に実装をしていて、

毎日めちゃくちゃ怒られている。

怒られているし、呆れられている。

（自分の仕事の出来なさに改めて泣きそうになっているが泣いたら終わりだと思うので踏ん張っている。）

目的と処理（手段）を分けて考える

前置きが長くなってしまったが、毎日何に怒られているかというと、

• 変数の目的・役割をきちんと理解・把握出来ておらず、曖昧な状態でわかったふりをしているから。

今更「変数」か、という感じだが、本当にそのレベルなんです。すみません。 ただこれは基本だけどすごく大事なことで、変数だろうがメソッドだろうが、クラスだろうが同じことになる。

例えば、「成績優秀な生徒の名前を表示する処理」というような以下のソースがあった場合に、 （showという名前のメソッドのくせに表示する処理がなかったり、配列一つしかないのにforループしていたり、goodというフラグを作ってフラグを立てたり無駄なコードが入ってますがお気になさらず）

var students = {"name": hime,"testResult":100};

function showStudents(students){
  var good = false;
  var goodStudents = [ ];
  for(var key in students){
    if(students[key].testResult > 80){
      good = true;
      goodStudents[key].name.push({
        "name":students[key].name
      })
    }
  }
}

goodStudentsは成績が80点以上の生徒名が入る変数ではあるけれども、成績が80点以上の生徒名を入れるためではなく

• 成績優秀な生徒として表示したいから作られた変数であること

という理解が大事だと教えられている。

今まで、

• studentsは生徒情報を入れる変数
• goodStudentsは成績が80点以上の生徒名を入れる変数

というように、「なんのため（目的）の変数なのか」ではなく「何をしている（処理）変数なのか」という読み方でコードを読んでいたし、プログラムしていた。 目的が曖昧だと「何をしているか」はわかっても「どうしたいか」の理解があやふやになる（自分の場合）。 このあたりの理解があやふやだった自分は、showStudents()を生徒名を表示する処理と中途半端に理解した気になって、 studentsとgoodStudentの役割の違いをきちんと言語化出来なかった。

ソースを修正したり、修正案を提示するたびに

• 「これはなんのためにあるの」
• 「どんな条件で変数に値を入れるの」
• 「〜したいときはどうするの」
• 「なぜここで初期化されているの」

と一つ一つ詰められている。答えられないということは理解がまだ出来てないということ。

これは変数に限った話ではなくて、関数だってクラスだってそれぞれ目的がまずあって、そのための手段をどうするかを考えるわけで、 ソースコードを読むときに目的をきちんと理解した上で読めば最終的に何をしたいのかわかる（と思う）。

小さな処理の単位で「何を目的に作られたのか」「なぜここで作られたのか」を理解出来れば どう処理を作ればいいのかも同時にわかる（実現の難易度とは別）。

ずっと詰められて頭が真っ白になってストレスでおかしくなる寸前で、 まだ消化できてなくて自分の言葉でわかりやすいようにアウトプット出来てない部分もあるけれど （わかりにくい文章だったらごめんなさい） まずは「目的」をきちんと把握するようにソースコードを読めば、理解できないこともないかなと思い始めている。

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

ソースコードリーディングから学ぶ Javaの設計と実装

プログラマーのためのソースコードを読む技術

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

【基礎】テストエビデンスの取得について

長くて苦しい結合テストがやっと終わった。
テスト設計ではなく、久々に「テスター」として結合テストの最初から終わりまで一人でやり切った。
※わからないことは聞きまくりだったけども

しかし、長くて苦しかった訳はほとんど自分にあった。

とにかくテスト実施時の基本的なことをおろそかにしていたのだ...
何が大事だったか、戒めのために残しておこうと思う

テストを実施することよりも重要なことは、エビデンスをどう残すかということ

テストケースの消化、ということに集中しがちだが、結局納品物として「テストをしましたよ」という証明になるのはエビデンスになる。 「やりました」と口で言ってもエビデンスが残ってなければ話にならないからだ。 単体テストレベルであれば、打鍵のみでエビデンスを残さないケースもあるだろうが、結合テストではカッチリエビデンスに残すことに なるので、そのためにどうやってエビデンスを残すのか？というのは大事。

そして、エビデンスをどう残すかは決まったルールがあればそれに従うだけだが、 もし決まったルールがないのであれば、基本的には以下の４点を基本エビデンスとして残すこと。

1. WEB系であれば、実行後の画面キャプチャ
2. 実行前のデータ状態
3. 実行後のデータ状態
4. 実行後のログ 　　

エビデンスとテストケースの紐付け

エビデンスを格納した後でテストケースとエビデンスと一致させるために、紐付けが必要になる。
基本的にはエビデンス自体にテストケースナンバーをつけた上で保存しておけば基本は大丈夫。 わかりやすいのは、テストケースの大項目単位でフォルダを作成して、階層的にフォルダ管理をすることで エビデンスの紐付けはしやすくなる。
　　 　　

テストケースが「絶対」に正しいということはない

これはテストを実施中には実は判別が難しい。
テストケースが正しいか、誤っているかは仕様を理解していないと判別がつかないからだ。 単純にテストを消化するだけだと、テストケースの「期待値欄」とテスト結果が一致しないので、 「テスト結果＝NG」としてしまいがち。
なので、テスト結果がNGとなった項目については、テスト実施直後くらいに先に報告をすべき。

※現場によってはRedmine等のテスト結果を管理するためのツールを利用しているかもしれない。　　

テスト実施前にどんなテスト結果が必要か準備と確認をしておくこと

テスト実施前に手順の確認、という意味合いもあるが、

• DBダンプを取る必要がある
• 画像のキャプチャを取る必要がある
• 実行ログを取得する必要がある
• クライアントツール等のキャプチャを取る必要がある　等々

これらのエビデンスを取るために「何が必要なのか」を実施前に把握しておくこと。

テスト実施のための環境

テストを実施する環境は様々あると思うが、

• WEBブラウザ（IEやChromeのブラウザ種別の他に、versionも考慮されるはず）
• ローカル環境（どこで実行するか、ログの出力はどこか）
• サーバ環境
• Dockerなどの仮想環境
• AndroidやiPhone等の各種スマホ

それぞれ「テストをするためにどんな環境構築が必要か？」と確認しておくこと。 最初から用意されている場合もあるが、大概何かしらの準備が必要になる。　　

遅れていても余裕を持って（余裕がなくなることがミスを生む）

テストってどうしてもスムーズに進まず、どこかで遅れが発生することがある。 そもそもどんなテストをするのか、漠然と理解していてもきちんと理解できていない状態で、 テストを実施していると順調に進んでいるのか遅れているのかもよくわからなくなる気がする。 順調に進んでいるように見えて、実は確認すべきテスト項目の半分くらいしか確認できていない、 なんてこともあったりする。終わったと思ってエビデンスを格納する段階で「エビデンスが足りてない...」なんてことも。

場合によってはバグが多くてテスト実施はしたものの不完全だったりするなんてこともある。 現状の理解をきちんとをすることで進捗状態を把握できる。 パニックにならないためにも、状況を理解できる余裕を持つようにしよう。

もし大事はエビデンスを誤って消去してしまったら...

1. MVコマンドでファイル名を置換しようとしたつもりが、RMコマンドを打っていた...
2. 誤ってファイルの上書きをしてしまい、元のファイルが消えてしまった

など何かしらの操作により大事なエビデンスが消えてしまった場合の対処方法

RMコマンドで消してしまった場合は、ファイルシステムがext3またはext4であること限定ですが、 以下の手段により復旧が可能なようですので試してみる価値はあります。

Linuxの恐怖体験「rmで間違ってファイル消してしまった！」そんな時はextundeleteでリカバリ | Unskilled?

大事なファイルを消してしまったけどextundeleteを使って危ないところで助かった話 - Qiita

Windowsの場合は、ゴミ箱に入っている可能性があるので、探してみよう。 そして、もし復旧ができなかった場合は素直に「すみません消してしまいました」と報告しよう。 何かしら対処を考えてくれるかもしれないし、単純にテストの取り直しを指示されるかもしれない。 おっかないのでRMコマンド打つ前はバックアップを取るのを忘れないようにしよう。

実施コマンド、投入したデータ、JSON、は念の為残しておこう

テスト実施時に叩いた、コマンドやデータ類、JSONなどの投入データは念の為手元に置いておこう。 だいたいテスト実施前に実行コマンド、データ、JSONなんかは実施前手順書的なドキュメントにあるだろうけど、 手順書に書いてある通りのコマンドなどで実施できない場合に書き換えもありうる。

日付やIDなどがユニークなキー値になっていて、すでに同じようなテストデータが投入されている場合に、 入力が弾かれてしまう場合があるからだ。

そもそも手順書の記載が誤っているかもしれない。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

現場の仕事がバリバリ進む ソフトウェアテスト手法

JUnit実践入門 ── 体系的に学ぶユニットテストの技法 WEB+DB PRESS plus

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

テスターちゃん 1巻