Ｖモデル

受託開発プロジェクトの終盤、ユーザーテスト（受け入れテスト）などと呼ばれる検証が始まると、当初の要件を覆すような「仕様変更」が発生するものだ。

システムの要件定義（要求分析）は依頼者（顧客）と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。

開発会社もある程度は折り込み済で、「手戻り」の時間を確保しているものだ。しかし、なにしろリリースまでの時間が残り少ない時のことである。「手戻り」の規模によっては間に合わないケースも多く、顧客との関係が悪化することもある。

開発者が「しかし、当初のお話では・・・」などと反論しようものなら、「こっちは客だぞてめえ」ぐらいのことは平気で言う人も。ビジネスの世界では金を払う人が偉いのである。

★

いわゆる「Ｖモデル」に従って進めているとされるプロジェクトでは、こうしたトラブルがよくある。Ｖモデルの図をよく見ていると分かるのだが、開発の終盤に「当初のお話」が間違っていることに気がつくというのは、自然なことである。

Ｖ字の後半の右上がりの部分は、テスト工程を表している。この部分は、意地の悪い言い方をすれば、「先にプログラムの細かい枝葉を確認し、システムの拠り所である要件が正しいかどうかは最後に確認しましょう」ということになっているのである。最後に要件上の問題が見つかるのは当然である。しかも、顧客が要件を出したのは遙か昔のことなので、今更「当初のお話」をしたところで、「そんなこと言いましたっけ？」となるのも当然である。

★

もちろん、ここでのテストとは、あくまでも動作確認（動的テスト）の話である。要件定義自体のチェック（静的テスト）は、Ｖ字の「書き出し」に定義した時点で行われているはずであり 100% 問題ない、という前提（というか建前）で進んできているわけである。基本設計（外部設計）以降も同様だ。

しかし、この静的テストは、主に要件定義書や設計書などを作って「机上」で行われる。開発の当初、まだ影も形もない新しいシステムを 100% イメージできる人がいるだろうか？　もちろん、システムだけでなく、それを使った業務全体の運用イメージも必要なのだ。しかも、誰か１人が分かっていればよいというわけではない。そのイメージは、システムの素人である顧客と、業務の素人である開発者の間で、完全に共有しなければならない（出会って間がないにもかかわらず）。

実際のところ、そんなことはできないのである。結局、システム要件というものは、結局は開発期間の最初から最後までかけて、ああでもない、こうでもないと言いながら決めていくことになる。

いや、開発が終わってもそれは続く。完成した後で「ここはこうした方が良かった」と思わないようなシステムは、まずないだろう。ソフトウェアに限らず、実際に使ってみて初めて気がつくことがあるというのは、当然のことだ。

このように、仕様変更があるというのは自然なことであり、開発プロジェクトでは、変更があったときにどうするか、ということをあらかじめ決めておくということも重要である。

★

とはいえ、Ｖモデル（ウォーターフォール）での開発では、後半に発生する変更を少なくすることが最重要課題である。開発が終盤に近づくほど、残り期間が少なくなるし、同じ変更であっても手戻りの作業量も難易度も大きいからだ（既に作っている部分を直すため）。

このため、一番最初の要件定義の段階でいかにして精度の高い「完成図」をイメージするか、ということが非常に重要なのである。これは、開発側の視点でいえば、顧客に「どこまで本気で考えてもらえるか」ということにかかっている。

プロジェクトも始まったばかりのこの頃、顧客はのんきに構えているのが普通である。そして困ったことに、開発者にもそんな人は多い。会議を開いても、結論も出さずにあいまいな状態で終わったり、雑談ばかりしていたりする。「時間があるのだから、今考えなくてもいいでしょう？」などと思っているようだが、実はこの時が最も重要なのだ。Ｖモデルでは、最初はバリバリ、最後は淡々と仕事すべきなのである。

応援のクリックお願いします →