はじめに
しまぶさんが以下のようなポストをしていました。
自分たちで決めたリリース日が決まっているのに、リリース前のテストで問題が出たからといって、すぐにリスケも視野に入れようみたいな話が出てくるのがどうしても違和感がある。いや、気持ちは分かるよ。分かるんだけど、そんなムーブがまかり通ると全てがそうなってしまわないかい。ギャップある。
— しまぶ (@shimabox) 2025年8月16日
このポストは、多くの開発現場が抱えるジレンマを的確に表現しているように感じました。
彼の問題意識に深く共感すると共に、その背景にあるオーナーシップを尊敬します。
その上で、テストの専門家として「この状況に対し、テストの側面から何ができるか？」を考察してみたいと思います。
もちろん、これはしまぶさんの現場のコンテキストを離れ、一般論として課題を考察するものです。
この記事が、同様の「違和感」を抱える方々にとって、次の一手を考えるきっかけとなれば幸いです。
語る前の前提
しまぶさんの問題意識に思いを馳せる
このツイートを表面的に捉えると、「テスト担当者が悪い」あるいは「リスケという意思決定が悪い」と解釈してしまうかもしれません。
しかし、このポストの問題意識の本質はそこにはないと考えています。
むしろ自分たちのプロダクトのリリース、コミットメントにオーナーシップを持っているが故の葛藤であると捉えました。
その上で、「我々には、他に何かできたことはなかったのか」と深く自問されているのだと拝察します。
だからこそ、私はテストの専門家として、「テストの側面でなにかできなかったか」と考察するのです。
やまずんのスタンス
まず、結論として、「問題が顕在化しているからリスケする」という判断自体は多くの場合で合理的です。
「バグがないこと」「品質に問題がないこと」が品質保証であるならば、リリースしないことが一番簡単な防衛策です。（これがメンテナンスリリースならば問題をややこしくします）
そもそもテストだけの問題ではないとは思う
これからテストの話をしますが、おそらく本質はテストの問題だけではない可能性については言及しておきたいです。
品質保証とリリースの意思決定プロセス・ソフトウェアエンジニアリングの成熟性・チームのマインドセットのズレなどの課題が複雑に絡まっている上で問題意識となっている可能性もあります。
また、問題としても緊急度の高いものではなく、現場では「個人の小さな違和感」程度のものかもしれません。
あくまでこの記事は、この話題をきっかけとした私個人の考察であることをご了承ください。
テストにおける問題点
短期的な対策：テストのモニタリングとコントロール
基本的に短期的に根本解決は難しいと思っています。ただ、この場で打てる手は何かを考えます。
「リリース前のテストで問題が見つかる」場合、この問題がどの程度なのかが明確な基準で判断できていない可能性があります。
まずできることは、現状を正確に把握し、事実に基づいた意思決定をすることです。
例えば、バグ管理の分野ですね。この辺の情報がクリアになった上で意思決定すべきですし、その情報を取得するためにリスケの意思決定を先送りして、そのバグの情報集めに全力を出すことはできるかもしれません。
中期的な対策：テスト計画の問題
もしテスト計画に問題があるのであれば、対策は比較的立てやすいと考えます。
まず、ソフトウェアテストのセオリーは「重大なプロダクトリスクを早いタイミングで潰す」ことであり、これはシステムテスト工程全般でも言えることです。
また、開発工程でのリスク低減策もあります。シフトレフトと言ったりします。
よくあるケースとして、プロダクトリスクを考慮せず、仕様書の項目順にテストを実行してしまうことが挙げられます。
これはテスト計画のみならず、テスト実装の技術が不十分で、ここも見直す価値があります。
「リリース前に問題が出る」であれば、ここから見直すのが建設的です。
※テストの実行手順はプロダクトリスクの早期発見のみではできないので、その点はその現場のコンテキストを知っているテストの専門家に相談するのがよさそうです。
ほかにも、テストの開始基準、終了基準が不明瞭だったり、それに対するリソースの確保が不十分である場合などはこういったリリース直前でストップがでたりします。
よくあるのが、「テストの開始予定にプロダクトのリリースが間に合わない」です。
これは仕方がないですが、この場合はテスト計画と開発計画を分離するより、プロジェクトマネジメント全体の問題として扱うのがいいでしょう。
プロジェクトリスク管理を事前にしておくのが効果的かもしれません。（ただ、これはチームの成熟度によります）
典型的なシフトレフト、テスト計画のプラクティスを書いておきます。
- プロダクトリスク分析をしておく
- テスト実行計画もやっておく
- 要件定義や設計の段階からテストの批判的な考えを入れて、レビューに加える
長期的な対策：テストの文化の品質とビジネスへのオーナーシップ
テストの技術が十分に機能していない可能性がありますが、これは組織的な問題の可能性があります。
例えば、テストという専門性への理解や、専門知識を持つ人材の確保が不十分であるケースです。
必ずしもテストエンジニアが開発チームや会社に必要だとは私は思いませんが、テストという課題についてきちんと考えられる人材は必要だと考えます。
また、「問題が出た」の背景には品質に対する理解、例えば顧客やステークホルダへの理解があると思います。
そういった下地にプラスして、「リリースしなかった場合に顧客やビジネス側のステークホルダの不満足は起こさないか」という観点もプラスできる余地があります。
こういった広い視野で物事を考え、トレードオフの上で意思決定していくこと、それを透明性の観点からサポートしていくのもテストへの期待と捉えてよいと思います。
おわりに
しまぶさんが感じた「違和感」は、コミットメントと品質の間で揺れる、プロのエンジニアとしての葛藤だと感じました。私はその姿勢を非常に尊いものだと感じました。
ソフトウェア開発チームでは、「プログラミングや設計のプロセスは成熟しているがテストや意思決定は未熟」ということも少なくありません。
そういった課題を抱えているチームのヒントの一助になれば幸いです。
上記の内容は、特定のコンテキストを想定しない一般論としての考察です。
もし個別の状況に合わせたコンサルティングが必要でしたら、MENTAなどのサービスを利用して、適切な技術者を探してみてください。
