開発会社の提案書にVの字の図が載っていて、左に要件定義や設計、右にテストが並んでいた。なんとなく分かった気になって流したけれど、自社が何を見ればいいのかは結局よく分からなかった。そんな方に向けた記事です。
この図は、工程の順番を説明するためだけのものではありません。発注側にとっては「いつ決めたことが、いつ確かめられるのか」を示す対応表です。ここが読めると、要件定義の時点で受入テストの準備ができるようになります。この記事では、V字モデルの読み方と、発注側がどの工程で何を確認しておけばよいのかを説明します。
この記事のポイント
- 左が「決める」工程、右が「決めたとおりか確かめる」工程
- 同じ高さの工程どうしが対応している
- 発注側が主役になるのは、左の一番上と右の一番上だけ
- 確かめようのない書き方の要件は、右側で必ず揉める
目次
システム開発のV字モデルとは何を表した図か
まず、図が何を表しているのかを整理します。
左が決める工程、右が確かめる工程
V字モデルは、工程を左下がり・右上がりのVの形に並べた図です。左側は上から順に、要件定義・基本設計・詳細設計と降りていきます。谷の底が実装で、そこから右側を上っていくと、単体テスト・結合テスト・総合テスト・受入テストと並びます。
左は「決める」工程です。何を作るか、どういう構造にするかを、だんだん細かくしていきます。右は「決めたとおりになっているか確かめる」工程です。細かい部品から順に、だんだん大きな単位で確認していきます。
順番にも意味があります。右側を下から上へ進むのは、小さい単位で問題を潰してから大きい単位に進むためです。部品が動かない状態で全体をつないでも、どこが原因なのか分からなくなります。逆に言うと、下の工程を飛ばして上だけやると、原因の切り分けに時間がかかります。
ウォーターフォールを縦に折り曲げただけとも言えますが、折り曲げることで初めて見えるものがあります。それが、同じ高さの工程どうしの対応です。
なぜわざわざ折り曲げて描くのかというと、まっすぐ並べた図では「どの確認がどの決定に対応しているか」が見えないからです。工程を横一列に並べると、テストは最後にまとめて置かれた作業に見えます。実際には、テストのそれぞれが前半のどこかと結びついています。
同じ高さの工程が対応している
この図の要点は、左右で同じ高さにある工程が対になっていることです。
| 左（決める） | 右（確かめる） | 確かめる内容 |
|---|---|---|
| 要件定義 | 受入テスト | 頼んだ業務が回るか（発注側が実施） |
| 基本設計 | 総合テスト | システム全体として仕様どおりか |
| 詳細設計 | 結合テスト | 機能どうしをつないで動くか |
| 実装 | 単体テスト | 部品ひとつずつが動くか |
いちばん上の対応を見てください。要件定義と受入テストが対になっています。つまり、受入テストで確かめるのは「要件定義で決めたこと」だけです。要件定義書に書かれていないことは、受入テストで指摘しても仕様変更の扱いになります。
この対応関係が分かると、要件定義のときに考えるべきことが変わります。「これをどうやって確かめるか」を同時に考えられるようになるからです。
下のほうの対応も同じ考え方です。詳細設計で決めた機能どうしのつなぎ方は、結合テストで確かめます。実装した部品ひとつずつは、単体テストで確かめます。決めた粒度と、確かめる粒度がそろっているわけです。
発注側が主役になるのは両端だけ
4つの対のうち、発注側が主体で関わるのは一番上の1組だけです。下の3組は開発会社の担当で、発注側は結果を報告として受け取る立場になります。
ここを取り違えると、疲れるだけで成果が出ません。結合テストの中身を細かく確認しようとしても、判断に必要な知識が発注側にはありません。逆に、受入テストを開発会社に任せてしまうと、業務が回るかどうかを誰も確かめないまま納品されます。
実際、開発会社が「受入テストもこちらでやります」と提案してくることがあります。親切に見えますが、業務のルールを知らない人がテストしても、確かめられるのは画面が動くかどうかまでです。締め日をまたいだときの扱いや、例外的な承認の流れは、日々その業務をやっている人にしか判断できません。
力の入れどころは、左上の要件定義と右上の受入テストです。ここに社内の人と時間を集中させてください。下の3工程は、報告書を受け取って残っている不具合を見るだけで足ります。工程ごとの略語や全体の順番はシステム開発の工程と流れの記事で扱っています。
もうひとつ、左側の基本設計にも発注側の出番があります。画面の並びや帳票の様式は基本設計で決まるので、ここを承認せずに進めると、総合テストの段階で「思っていた画面と違う」となります。ただし関わり方は要件定義とは違い、出てきたものを見て意見を返す立場です。
W字モデルとの違い
関連してW字モデルという言葉も出てきます。V字を2つ重ねた形で、左側の各工程と同時にテストの設計も進めるという考え方です。
発注側にとっての違いは1点だけです。V字では受入テストの準備を右側に入ってから始めますが、W字では要件定義と並行してテストの内容を考えます。後者のほうが早い段階で「この要件は確かめようがない」と気づけます。
提案でW字モデルを掲げている会社があれば、その分の工数が見積もりに入っているかを確認してください。名前だけで実態が伴っていないこともあります。
とはいえ、発注側からW字モデルを指定する必要はありません。開発会社のやり方を変えさせるより、要件を決めるときに自分たちで確かめ方を書き留めておくほうが早く、費用もかかりません。
システム開発のV字モデルで発注側が確認する場面
ここからは、この対応関係を実務でどう使うかです。
要件定義の時点で合格の基準を決める
V字モデルがいちばん役に立つのは、要件定義の場面です。ひとつ要件を決めるたびに、「これは受入テストでどう確かめるか」を同時に書き留めてください。
たとえば「承認された伝票だけが出荷指示に回る」と決めたなら、確かめ方は「未承認の伝票を作って、出荷指示の一覧に出てこないことを見る」になります。この1行を要件の横に書いておくだけで、受入テストのシナリオが要件定義の段階で半分できあがります。
実際には、確かめ方を書こうとして初めて要件の曖昧さに気づくことのほうが多いです。「使いやすくする」と書いた要件は、どう確かめればよいのか誰にも書けません。その場で「3クリック以内で登録できる」のように言い直せば、右側で揉めずに済みます。
この作業は開発会社にも歓迎されます。確かめ方が決まっていれば、何をもって完成とするかが双方で同じになるからです。着手前に片付くので、あとから仕様の解釈で止まる時間も減ります。
受入テストの体制を要件定義と同時に決める
V字の対応関係からもうひとつ言えるのは、受入テストに出る人は要件定義に出た人と同じであるべきだという点です。決めた人と確かめる人が違うと、なぜその仕様にしたのかが分からないまま合否を判断することになります。
要件定義の打ち合わせに出てもらった現場の担当者に、その場で「数か月後の受入テストにも出てもらいます」と伝えておいてください。人事異動や繁忙期と重なると出られなくなるので、早い段階で上長にも共有しておくと安全です。
人数の目安は、業務ごとに1〜2名です。全部門から集める必要はありません。実際にその業務を毎日やっている人が1人いれば、机上のレビューでは出てこない例外が出てきます。
確かめようのない要件は書き直す
要件定義書を読み返すときの基準は、ひとつで足ります。「これは、どうやったら合格と言えるか」が書けるかどうかです。
- 「速くする」→ 何が何秒以内になれば合格か
- 「使いやすくする」→ どの操作が何手順で終われば合格か
- 「柔軟に対応できる」→ 何を変えられれば合格か
- 「安定して動く」→ 月に何時間までの停止なら合格か
左側の言葉が曖昧なまま進むと、右側で必ず食い違います。しかも稼働直前という、いちばん直しにくいタイミングで表に出ます。要件の抜けや曖昧さを点検したい場合は、要件定義書レビューシートに確かめ方まで書けているかを見る観点が入っています。
右側が極端に短い計画は疑う
提案されたスケジュールを見るときにも、この図が使えます。左側の4工程と右側の4工程で、期間の配分がどうなっているかを見てください。
実装までに8割の期間を使い、残り2割で右側を全部やる計画になっていることがあります。この形だと、実装が少し遅れただけでテストの時間が消えます。そして削られるのは、たいてい一番上の受入テストです。発注側の作業なので、開発会社からは削りやすく見えるためです。
提案の段階で「受入テストは何日間を想定していますか」と1つ聞いておくだけで、この危険はかなり下がります。日数が明記された計画は、あとから削るときに理由の説明が必要になるからです。
私の感覚では、受入テストの日数が2週間を切っている計画は、あとで無理が出ます。現場の担当者は通常業務を抱えながら参加するので、実働は日数の半分程度になるからです。受入テストの進め方はシステム開発のUATの記事で詳しく扱っています。
アジャイルの場合はどう考えるか
V字モデルはウォーターフォールを前提にした図なので、アジャイルには当てはまらないと言われることがあります。ただ、発注側にとっての意味は変わりません。
アジャイルでは、この小さなVが2週間ごとに何度も回ります。決めて、作って、確かめる。1回あたりの範囲が小さくなるだけで、決めたことを確かめるという関係そのものは同じです。
むしろ回数が増えるぶん、発注側が確認に出る回数も増えます。毎回の確認に誰が出るのかを決めておかないと、確かめないまま次へ進んでいきます。テストの段階ごとに何を受け取るかはシステム開発テストの種類の記事で整理しています。
アジャイルで進める場合は、確認に出る人を固定しておくのが実務的です。毎回違う人が見ると、前回どこまで確かめたのかが分からなくなり、同じ指摘が繰り返されます。業務ごとに1名ずつ、通常業務の何割かをこの確認に充てる前提で体制を組んでおいてください。
システム開発のV字モデルについてよくある質問
- Q. V字モデルは古い考え方ですか。
- 図としてはウォーターフォール前提のものですが、決めたことを対応する工程で確かめるという関係は開発の進め方によらず成り立ちます。発注側にとっては、今も自社が出る場面を把握するための地図として使えます。
- Q. 発注側もV字モデルを覚える必要がありますか。
- 工程名を暗記する必要はありません。要件定義と受入テストが対になっていること、この1点だけ押さえていれば実務では足ります。
- Q. 図に自社の作業が書かれていない場合はどうしますか。
- 受入テストの担当が空欄になっている、あるいは開発会社の名前が入っている場合は、その場で確認してください。誰が実施するかで、必要な日数も社内の準備も変わります。
- Q. W字モデルのほうが良いのですか。
- 早い段階で要件の曖昧さに気づける利点はありますが、そのぶん初期の工数が増えます。名前で選ぶより、受入テストの準備をいつから始めるのかを確認するほうが実務的です。
