はじめに
この記事はテスコンに挑戦したど素人が、いざ提出まで終わってみてどこが悪かったかを振り返る記事です。
最終的にどこまでできたか
何も形にできなかったです。
「何も」というのは、テスト設計において
要求分析、そこからのテストアーキテクチャ構成、テスト観点だし、テスト条件だし、テスト設計、テスト実装
を含みますが、全てができませんでした。
「整頓して他人に見せられる形まで完成できなかった」です。
かろうじて最初に考えていたことを元にプレゼンテーションを作りました。
何が悪かったか
全部が悪かったと思います。
ですが、悪かった点の解像度をあげないと改善点が見えてこないので悪かった点を考えます。
図で考えてみる
理想：アウトプットに必要なものを順々に考えていく。広がりすぎない制約を決める
現実：とりあえず手を付けてみることを最優先にした結果、全ての成果物作成が時間内に収まらない事になった
思いつく点を羅列する
・プロダクト理解に時間をかけすぎた
1ヵ月しか期間が無い中、1週間はかけすぎてしまったかと思います。
プロダクトリリースの期間が2週間だとしたらそこまでかけていられないような。
言い換えると時間を念頭に置かなかったことが悪かったです。
・全部を挙げきることを考えすぎた
抜け漏れ無く、を考えるときに全体を見てから…と考えが行きましたが
どの範囲に対して全部か？どの粒度で全部か？がぼやけている状態で全部を挙げきろうとすると
果てしない上に何に対して全部なのかよく分からなくなるという悲しい状態になりました。
「全部」という言葉の解像度が荒すぎました。
・スコープが曖昧だった
前項の「全部」と同じです。
どの範囲に対して？だけはかなり解像度を詳細にしないと、キリがなくなってしまう。
ここでいう範囲とは、細かさも含みます。
・時間に見合ったスコープにしなかった
全てのプロセスを終わらせるのに絶対関係あるのが時間です。
「時間足りないとか考えてたら始まらないか」と思い始めましたが
終わってみると、これは考えておかないと後で全部中途半端になり（今のことです）
まず与えられた時間でできる範囲、しかもギリギリではなくマージンをもって決めるべきでした。
・要求・要件・仕様を理解できていなかった
「要求」の粒度を荒く考えすぎていました。
また「要件」と「要求」の理解が曖昧でした。
・最後までつなげられるかを考えた時に矛盾があるときに修正しなかった
この方針をもってテスト実装まで考えられるか、の段階で考えられないときに
スコープがおかしいのにきづいたら、そこから修正した方が良かったと思います。
・あまりにも分析の技法を使わな過ぎた
分析を使う理由が腹落ちできないからという理由であまりにも何も使わなかったのですが
今考えると考えるのに情報の整頓は必然なので、使えばよかったです。
自分は情報を整頓する手段を使う工数を、気軽に始めることより重く捉えていた節があります。
つまり、机上のみで、技法が手になじんでいない。
情報の整頓にも色々な手法があるわけで（それがモデル化か）それをしないままずっとブレインストーミングを
続けてしまった結果、まとまらずに終わりました。
・情報の整頓・構造化ができなかった
前項と同じです。
整頓、構造化は重いプロセスではなく、理解の手段であり
それを重いとしているところに問題があると思います。
悪かった点を踏まえた修正点
最初に手を付けるスコープを決める
この範囲でやる、この範囲は手をつけない！を早めに決めたいです。
（スコープに収まらなかった経験を踏まえ）
内容が期間内に収まるか検討する
これから作ろうとしている内容が期間内に収まるのかを検討してから始めたいです。
矛盾があるなら修正する
途中で矛盾に気づいたときに「時間無いからこのまま」という選択をしてしまいました。
ですが矛盾はどこまでいっても矛盾してしまうので、気づいたときに修正します。
構造化の手段を手になじませる
使うと有効な手段が自分にとって重くなってしまっているのが問題です。
整頓できない状態でずっと進めているとモヤモヤし続けたままだったので
まず、情報を整頓する手段を自分にとって「便利」「理解しやすい」に落とし込もうと思います。
総評（まだ早いけど）
始めてみないと分からないことがいっぱいある
今回、申しこんだのが締め切りまで1か月未満のときで
「時間足りないかな…」「途中になるだろうなあ…」「でも始めることと提出することを最優先にしよう」と思いながらずっと取り組んでいました。
実際取り組んでみると、問題になるのは時間より情報の整頓の仕方で、混沌としたまま進めると混沌と進むなというのを実感しました。
こういうと「ちゃんとできてないと始められないのか」と始めるのに敷居が高くなってしまうのですが
結果的にはたとえめちゃくちゃでも取り組んだ方がよかったです。
具体例に取り組むからか、やってみると自分のわかってない所が可視化されます。
それが可視化されることだけでも得られるものとしては大きいです。
おまけメモ
・テスコンの予選でみる「プレゼンテーション」は成果物のほんの一部。テスト設計仕様書を作るのが本番
・プレゼンテーションは早く作った方が自分の作業の道しるべになる気がした。おまけに少し気が楽になる
・テスト実装（具体的なテストケース）まで書くのが本来はゴール
・未完成で出す勇気も必要そう（これを恐れてると始められなくなるから）
