冒頭から煽るようなタイトルとなってしまいすみません。
タイトルの通り、テスト設計コンテスト2023 OPENクラス(以降、テスコン)に、ソロで出場し、優勝という結果をいただきました。
過去12回の開催のうち、初出場にして一人で優勝したのは初めてのようです。
これは誤りで、既に一人チームで優勝されているチームがあるとのことです。
このエントリーでは、審査裏イベントでも少し話した、何故テスコンに一人で出場しようと思ったのか？実際出てどうだったのか？について書いていきたいと思います。
一人でも多くの方にテスコンに興味を持っていただき、(独りでも)出場をする人が増えたら、今後のソフトウェアテスト業界の発展に繋がると考えているからです。
審査について
審査員の方が述べられていたように、今回は、決勝のプレゼンテーションで順位が入れ替わる可能性が充分にあり得るくらい接戦だったようです。
会場で成果物を拝見させていただいても、ドキュメントの出来栄えはどのチームも素晴らしく、どのチームが優勝してもおかしくないと感じていました。
それと同時に、私は優勝なんて無理だろうとタカを括っていたので、結果を聞いた時は、何もコメント準備してなくて、あたふたしました。
出場されたチームの皆さん、本当長い期間取り組まれた成果物の作成や準備、大変お疲れ様でした。
また、実行委員の皆様におかれましては、テストベースのご提供と、ハイブリッド開催の運営の両面で大変お世話になりました。ありがとうございました。
何故一人で出場しようと思ったのか
WACATEなどに出たことはなく、コミュニティにお友達がいない、つまりボッチだからです。
また、転職直後で会社の人を誘う勇気がなかったのもあります。
って別にボッチ自慢をしたいわけじゃないんです。
出場のモチベーションは、3つありました。
1つ目は、前回のテスコンの審査委員の湯本さんの講評です。
誤解を招く可能性もあるため引用はしませんが、 ソフトウェアテストに対して強い想いを持っているからこその、厳しいコメントだと受け止めました。
ソフトウェア開発においては、昨今のOSSの普及などにより、他人の書いたコードを見ることのできる機会は確実に増えました。
一方で、ソフトウェアテストにおいて、現場以外で、他人の作ったテスト設計を見ることのできる機会は少ないように感じます。
テスコンは、その機会を提供してくださる貴重な場でもあると考えています。
テスコンを聴講される方はさまざまな目的を持って参加されていると思いますが、
一つの目的例として、現場や自分自身のテスト設計をより良くするためのヒントを得るために参加されているものと考えています。
私自身も聴講者として参加していた時は、そのような目的意識を持って参加していました。
だからこそ、エンドユーザも含むステークホルダの要求や、システムのアーキテクチャをしっかり捉えるテスト設計を示したかった、それが1つ目のモチベーションでした。
2つ目、OPENクラスの新しいテストベースが興味深い内容だったからです。
感染症対策のため入場者の制限を行う動物園の入場管理システムが対象でしたが、
開発の体制、スコープ、マイルストン、制約事項などが定められており、
実際のプロジェクトに近い状況でテスト設計ができるということにとてもワクワクしました。
3つ目、エントリー前に、やまずんさん(@55_ymzn)、ぐんちゃさん(@gun_chari)とお話する機会をいただけたことです。
テスコンに関しては先輩のお二人とお話できたことが最後の一押しになりました。
自分よりも若い方が、色々なことに果敢にチャレンジしている一方で、自分はこれまで勝手に壁を作ってチャレンジを恐れていた、
そんな壁を少しでも壊したいと思い、エントリーを決めました。
ソロでよかったこと・大変だったこと
複数人で参加する難しさ、ソロで参加する難しさ、それぞれあると思います。
ブレスト・議論・意思決定
複数人で参加する場合、複数人でのブレスト・議論ができるというメリットがあります。
それはソロではできません。そして、自分が選択した方針が本当に良いのだろうかと悩んだ時に助言してくれる人はいません。
ただし、複数人で参加されたチームのメンバーの方とのアフタートークで、自分が納得できない方針で進んでしまったというお話も伺い、そこが複数人参加の大変なことだと改めて感じました。
プライベートがある中で、同期的なコミュニケーションを取るための調整も相当な労力ですよね。
全て一人で完結・意思決定できることはソロの最大のメリットだと感じました。
成果物の作成
複数人で分担して作業を進める場合、予め方針やテンプレート、どこまで情報を書くかなど事前に決めておかないと、成果物間の一貫性が崩れてしまいます。
進め方一つとっても、テスト要求分析、テストアーキテクチャ設計、詳細設計、実装のように工程毎に分担をするのか、
工程内で分担して作業を進めるのかも悩ましい問題です。
また、本業を抱える中で、プライベートの時間とどう折り合いをつけていくのかも、切実な課題です。
チームで参加してると、途中で離脱してしまうメンバー、期限までに成果物が出てこない状況が発生してしまうという話もよく聞きます。
ソロでは、そういった悩みを抱えることなく、一貫性を取りやすい、短時間でも作業に取り組めるのはメリットだと思います。
一方で、今回のテストベースのような大規模なテスト開発を一人で行なっていくのは、結構大変でした。
仕事の忙しさにかまけて、サボっていた時間もありつつも、去年のプライベートの時間はほとんどテスコンに費やしたように感じます。
私は片方の見方しかできないので、どちらが大変かはお伝えできないですが、 チームでコミュニケーションをとりながら、一つの成果物を作り上げた他チームの方はすごいと思いますし、リスペクトしています。
おわりに
この記事によってテスコンに興味を持ってくれる人が増えたら嬉しいです。
私が成果物を作るときに考慮したことや、技術選定の理由、作成した成果物の詳細な説明はさすがにプレゼンの15分では語りきれなかったので、またどこかで書いたり、発信できるとよいなと思っています。
最後まで読んでいただきありがとうございました。
