V字モデルで品質を高める開発の羅針盤

とある大規模なシステム開発プロジェクトが納期直前で大炎上したと。理由はたった1つだったそうなんです。 プロジェクトの最初に交わした、何を作るかっていう一番大事な約束をいつの間にか誰も正確に覚えていなかったから。 今日はですね、そんな悲劇を防ぐための開発現場の羅針盤とも言える考え方、V字モデルについてあなたと一緒に深く掘り下げていきたいと思います。 いやー、本当に笑えない話ですよね、それ。 最後の最後になって、あれ？こんなもの作るはずじゃなかったんだけどなって気づく恐怖。時間もお金も、そして何よりチームの士気も失われるっていう最悪の事態ですよ。 今回取り上げる資料は、まさにその最初の約束を最後まで見失わないための知恵が詰まっていると言えるんじゃないでしょうか。まさに羅針盤ですね。 そこで今回のミッションです。一見すると複雑でなんか専門的に見えるシステム開発のプロセスが、実は鏡合わせっていう驚くほどシンプルで強力な構造で成り立っている。 これを理解することです。 OK。では早速この賢い羅針盤の中身を紐解いていきましょう。まずシステム開発の古典的な手法にウォーターホールというのがありますよね。 ありますね。滝が上から下に流れるように、企画、設計、プログラミングと工程を順番に進めていく。これはイメージしやすいんですけど、 最後のテストの段階で、それまでの全工程の問題が一気に噴き出すなんて話もよく聞きます。 その通りです。もう滝つぼに全部溜まってしまうようなイメージですよね。 そこで登場するのが今回取り上げるV字モデルなんです。これはそのウォーターホール開発における設計とテストの関係性をもっと効果的に管理するために生み出された考え方でして、 開発工程とテスト工程の関係をアルファベットのVの字で可視化、視覚的に表現したものなんですよ。 Vの字ですか。なるほど。一度下に降りて、谷底を通過して、また同じ高さまで上がっていくという、そういうイメージでしょうか。 まさにその通りです。Vの左側の斜面、つまり下り坂が要件をどんどん具体的に落とし込んでいく設計のフェーズです。 そしてVの谷底が実際にコードを書くプログラミング。で、重要なのが右側の斜面、上り坂です。 これが作られたものが正しく動くかを確認していくテストのフェーズになれます。設計で細かくしていき、プログラミングで形にして、 テストでそれを確かめながら統合していく。この降りて上がるという対の構造がV字モデルの基本ですね。 面白いですね。滝のように一方通行で下るだけじゃなくて、ちゃんと下った分だけ上がっていくと。 でも、なぜわざわざV字で表現する必要があるんでしょう。ただ順番に並べるだけではダメなんですかね。 素晴らしい質問です。そこがまさにV字モデルの核心でして。このモデルが本当に面白いのは、 Vの左側と右側がまるで鏡合わせのようになっている点なんです。 鏡合わせ、それはどういうことでしょう。つまりですね、左側の下り坂で行ったある段階の設計作業が、 右側の上り坂のちょうど同じ高さに位置するテスト工程で検証されるという明確な対応関係があるんです。 あー、なるほど。計画段階で決めたことが、テスト段階でちゃんと実現できているかを同じレベル感でチェックする。この対応関係こそがV字モデルの力なんですよね。 なるほど。それって言ってみれば答え合わせみたいなものですね。 左側の設計フェーズでこういうものを作りますという仕様書、つまり問題用紙を作っておいて、 右側のテストフェーズで、はいできました、問題の通りでしょうと回答用紙を提出して答え合わせをする。そういうイメージですか。 まさにその通り。その答え合わせという考え方、すごく的確です。 そしてこの答え合わせがあるからこそ、テストの段階で、あれ？何を基準に確認すればいいんだっけと迷うことがなくなるんです。 だって確認すべき基準、つまり問題はすでに対応する設計書にすべて書かれているわけですから。 その答え合わせっていう考え方面白いですね。ということはテストで失敗する、つまりバグが見つかるっていうのは、いわば答えが間違っていたってことだから、 決して悪いことじゃない。むしろ歓迎すべきことと捉えることもできますか。 おっしゃる通りです。V字モデルの本質はまさにそこにあります。テストは開発者を罰するためのものじゃなくて、 品質を高めるためのフィードバックの仕組みなんです。 そしてこのフィードバックは早ければ早いほどいい。なぜなら、開発の後の工程でバグが見つかるほど修正コストが爆発的に増大するからです。 そんなに違うものなんですか。 資料には直接書かれていませんが、一般的に一番最後のユーザーによるテストで要件定義のミスが発覚した場合の手戻りコストは、 一番最初のプログラマーのテストでバグを見つける場合の、まあ100倍以上になるとも言われています。 100倍！ええ、V字モデルはその莫大なリスクを各段階で潰していくための、いわば早期発見システムなんです。 それはもう会社の存続に関わるレベルですね。なるほど。だから各階層でこまめに答え合わせをしていく必要があるわけですね。 そういうことです。では、具体的にどの計画がどのテストに対応するのか、その鏡合わせの関係を詳しく見ていきましょうか。 はい。ではV字の1番底、最もミクロなレベルから見ていきましょう。左側の谷底に一番近い部分には、詳細設計という工程があります。 これはプログラムの部品一つ一つが具体的にどういう動きをするのか、その内部のロジックを細かく決める作業です。 あの、この詳細設計とすぐ上にある基本設計って言葉は似てますけど、具体的にどう違うのかもう一度教えてもらえますか。 どこで線引きするんでしょう。 よいポイントですね。ざっくり言うと基本設計はユーザーから見える部分、つまり外側の振る舞いを決めます。 画面のデザインとか、ボタンを押したらどうなるかとかですね。 一方詳細設計はユーザーからは見えない部分、つまり内側の仕組みを決めます。 そのボタンが押されたときに裏側でデータベースにどういう命令を送るかみたいな、まあ技術的な話です。 なるほど。外から見えるのが基本。見えない内部が詳細。分かりやすいです。 ええ、そしてこの詳細設計書という内側の設計図と鏡合わせになっているのが、右側の1番最初のテスト、単体テストです。 これはプログラマーが作ったプログラムの部品、つまり単体が詳細設計書に書かれた通りに正しく動くかどうかを個別にチェックするテストです。 1番細かい設計が一番細かいテストでチェックされる。非常に直感的ですね。 そうなんです。私も若いころ、この単体テストを疎かにして次のテストで地獄を見た経験がありますよ。 個々の部品が信用できないと、問題が起きたときに原因がどこにあるのか全くわからなくなるんです。 だからこの最初の関門が極めて重要なんです。 経験者は語るですね。さて、こうして部品単体の品質が保証されて、初めて我々は次のステップに進めるわけですね。 その通りです。じゃあこれらの部品を組み立ててみようというステップ。それがV字を少し上がった中間のレベルです。 左側の基本設計に対応するのが右側の結合テストです。 単体テストをクリアした個々の部品を今度は組み合わせて、つまり結合して動かしてみるテストですね。 具体的にはどういうことを確認するんでしょう。例えばログイン画面でIDとパスワードを入れてボタンを押したら、 ちゃんと次のマイページ画面に移動するかとか、そういう部品同士の連携を見るということですか。 まさに。その例は非常に分かりやすいですね。 もう少し技術的な話をすると、例えばユーザー情報を登録する部品と、その情報を使ってメールを送信する部品があるとします。 単体テストではそれぞれ完璧に動く。でも結合してみたら、登録したはずのメールアドレスがなぜかメール送信部品に正しく渡せていなかったとか、 こういう部品間の連携ミスを発見するのが結合テストの重要な役割なんです。 へー、なるほど。それぞれの部品は優秀でもチームになると上手く連携できないみたいな、なんか人間社会にもありそうな話ですね。 そうかもしれませんね。その連携のルールが鏡の向こうにある基本設計書に書かれている。 お見事。そういうことです。基本設計で定めた画面Aのこのボタンを押せば画面Bに遷移するとか、 登録部品はメール部品にこの形式でデータを渡すという約束事が結合テストによって正しく守られているかを確認するわけです。 よくわかりました。ではいよいよV字の一番上、最も大きな枠組みの話ですね。 ここはプロジェクトの成否を分ける一番重要な部分だと感じます。 ええ、その通りです。V字の出発点であり、最も外側の枠組みとなるのが要件定義。 これはそもそもこのシステムで何を解決したいのか、ユーザーが何を求めているのか、どんな機能が必要なのかといった、 開発全体の目的やゴールを定義する、まさにプロジェクトの憲法とも言える工程です。 全てはここから始まる。冒頭の炎上したプロジェクトはこの憲法が曖昧だったり、忘れ去られたりしたわけですね。 そういうことになります。そしてこの開発の出発点である要件定義と鏡合わせになっているのが、 右側の最後にして最大の関門、運用テストです。受入テストとも呼ばれますね。 運用テスト、これは誰がやるテストなんですか。 ここが非常に重要なポイントなんですが、この運用テストは開発者ではなく、実際にシステムを依頼したユーザー自身が参加して行います。 あ、そうなんですか。発注者側が自分たちの実際の業務でシステムを使いながら、 本当に私たちが頼んだ通りのシステムになっていますかとか、これで私たちの仕事は楽になりますかという最終確認をする場なんです。 なるほど。だから受入テスト。まさに開発の最初に交わした約束、つまり要件定義という問題用紙の答え合わせを問題を出した本人、 つまり発注者が行うわけですね。 その通りです。これは緊張する瞬間でしょうね。 ええ、でもそれって何というか理想論じゃないですかと突っ込みたくなる気持ちもわかります。 実際の現場では設計とテストがそんなに綺麗に対応するものなのか、何か落とし穴はあったりしないんですか。 はい。もちろん落とし穴はあります。例えば最初の要件定義が曖昧な言葉で書かれていると、 最後の運用テストで、いや私たちが言ったいい感じにというのはこういう意味じゃなかったというような解釈の違いが生まれるんです。 うわー、ありそう。 ですよね。だからV字モデルをうまく機能させる大前提として、左側の各設計書がテスト可能なレベルまで具体的かつ明確に書かれている必要があるんです。 誰が読んでも同じ解釈しかできない状態が理想ですね。 なるほどな。設計書がテストの判断の拠り所になるわけだから、その拠り所自体がグラグラだと意味がないと。 そういうことです。逆に言えばそこさえしっかりしていれば、V字モデルは絶大な効果を発揮します。 テスト中に意見が割れても対応する設計書を確認しましょう。そこに書かれていることが正解ですと客観的な基準で判断できる。 これによりテストの品質が安定し、無駄な手戻りも劇的に減るわけです。いやこれシステム開発に限った話ではないですね。 資料にも少しヒントがありましたが、僕たち自身の仕事のタスク管理にもこのV字の考え方は応用できそうですね。 面白い視点ですね。どういうことでしょう。例えば何かプレゼン資料を作るタスクがあったとします。 まず最初にこの資料で誰に何を伝えどう行動してほしいのかという要件定義を自分なりに明確にする。 そして資料が完成した最後の最後に、最初の目的に立ち返ってこの資料で本当にその目的は達成できるだろうかと自分自身で運用テストをしてみる。 なるほど。セルフ運用テストですね。面白い。 ええ、次にこういう章立てでこういうグラフを使おうという大まかな構成、つまり基本設計を考えますよね。 そして各章を書き終えた段階で全体の構成として話の流れはスムーズか、章と章のつながりは自然かと結合テストのようにチェックする。 そして最後に一つ一つの文章やデータの正確性といった詳細設計レベルの作業をして、誤字脱字がないか単体テスト的に校正する。 素晴らしい。まさにタスク管理におけるV字モデルの応用ですね。計画したことと確認することを常にセットで、同じ粒度で考える。 この思考法はどんな仕事にも役立つ非常に強力なフレームワークと言えるでしょう。よかったです。私自身も何か文章を書くときは無意識にそれに近いことをやっていますね。 この章の目的はAだと決めて書き、書き終えたら本当にAが伝わるか読み返す。まさに詳細設計と単体テストの繰り返しです。 はい、というわけで今回の内容をまとめてみましょう。V字モデルとはシステム開発における設計とテストを鏡合わせのように対応させることで、 開発プロセス全体を視覚化し品質を高めるための強力な考え方であるということでした。 そうですね。Vの左側が設計の下り坂、右側がテストの上り坂。そしてその左右の同じ高さが対応しているんでしたね。 ええ、早い段階で答え合わせを繰り返すことで、後工程での手戻りという致命的なリスクを減らす賢いリスク管理の手法とも言えます。 その通りです。具体的には3つの対応関係がありました。1番大きな枠組みである要件定義は最終確認の運用テストと。 ユーザーから見る部分の基本設計は部品の連携を見る結合テストと。 そして1番細かい内部の詳細設計は部品単体を見る単体テストと。この3つのセットがV字モデルの核心でした。 このモデルは冒頭で話に出た計画通りに正しく作られたかを検証するための非常に洗練された優れた枠組みです。 計画と検証が常に対応しているため、迷いがなく品質も担保しやすい。まさに物事を着実に正しく作るための知恵と言えるでしょう。 本当にそうですね。この考え方を知っているだけでプロジェクトを見る目が変わりそうです。 ええ、その上で最後にあなたに一つ思考を深めるための問いを投げかけてみたいと思います。お、何でしょう。 V字モデルは見てきたように、物を正しく作るための非常に強力な方法論です。では、その大前提である正しいものを作るには、そもそもどうやって決めたらいいのでしょうか。 あー、つまりV字モデルが始まる前の要件定義のさらに外側にある、顧客が本当に解決したい課題は何かなのかとか、 このプロダクトは市場に受け入れられるのかというさらに大きな問いに、私たちはどう向き合えばいいのでしょうか。