仕事は準備が７割！プロジェクトの成否は要件定義で見えている

改めて、要件定義書とは

要件定義書作成における全体のプロセスは次の通りです。

1. 要求書をクライアントから受領する
   1. 大まかなシステム要件
   2. 予算
   3. 納期 など
2. 要件と作業内容を文書化する（SE）
3. 実現方法を検討し、クライアントの合意を得る（PM）

多くの現場で要件定義書はSEが記載するという風潮があると思います。それ自体は間違っていませんが、SEで完結する作業ではない事を念頭に置くべきです。 SEが対応できるのは2の「要件と作業内容を文書化する」プロセスまでです。「要件定義書の書き方」が2を指すのであれば、「IPAや、過去プロジェクトのサンプルを参考にすべし」で話は終わります。しかし、要件定義書は書いたから終わりではありません。

SEが2で作成した文書を基に、金銭面や責任範囲などビジネスとしての都合を加味し、現実的な実現方法を検討し、その結果でクライアントの合意を得るまでが要件定義書の作成です。ここまで行わないと要件定義書が実質的な効力を持たず、「ここが想定していた挙動と違う」「仕様の追加・変更ができないなど聞いていない」などの論議が発生します。冒頭で述べたように、こういった事態は誰もが一度は経験したことがあるのではないでしょうか。

要件定義書の目的

「説明」だけが目的ではない

要件定義書の目的は、次の2つに分解することができます。

1. 顧客に対する要件説明資料であること
2. 実現方法を理解・合意してもらう

1は言うまでもなく、機能要件・作業範囲を明確にしないと費用と納期が守れる保証がありません。実装者の実作業にも関わってきますので、これがおろそかにされることはあまりないでしょう。

プロセスとして飛ばされがちなのが2です。開発途中にクライアントから「そんなことは聞いていない」「そんなつもりではなかった」と言われる事態に陥るのは、実現方法に関してきちんと合意が得られていないからです。

各フェーズにおける要件定義書の完成度は、大まかに次のように表すことができます。

1. 要求書をクライアントから受領する：20%（ざっくりとしていて、不明瞭な状態）
2. 要件と作業内容を文書化する：60%（実作業にあたり、ひとまずは整理された状態）
3. 実現方法を検討、合意した文書：100%（要件に関して、双方の認識に疎通が取れている状態）

つまり要件定義書とは、「要件説明を行うためだけの資料」ではありません。合意形成を行い、双方の認識に疎通が取れて初めて要件定義書が100%完成したと言えます。

ただしクライアント側にシステム部門がない限り、実現方法について先方がきちんと理解することは難しいでしょう。そういった場合は、制作会社から理解が得られるよう働きかける必要があります。

要件定義書は、プロジェクトの責任者間で仕上げて初めて形を成す。

【合意形成のためのプロセス①】課題を整理し、実現方法を具体化する

実現方法の合意を得るには、課題が整理されており、かつプロジェクトの目的と効果が明らかになっている必要があります。

プロジェクトの開始時点では双方次のように考えているでしょう。

• クライアント「頓挫されては困る、精度もしっかりと保って欲しい」
• 制作会社「赤字にしたくないし、不夜城も避けたい」

どちらも満たすために必要な条件や課題を洗い出すと、概ね次のような項目が出てきます。

• 打ち合わせ頻度・方法・回答期限
• 開発体制・他社の参画有無
• 情報漏洩の防止
• インシデント発生時の対応
• コーディング規約
• セキュリティの保証
• 認識齟齬の防止方法
• チェック体制・方法
• システム実利用者の声
• 期限が守られるかどうかの定期チェック
• 仕様追加・変更の受付期限
• 支払い時期
• 制作中止時の支払い …

このように列挙することで、「我々制作会社がクライアントにどのような協力を求めているのか」だけでなく、制作会社自体が抱えている懸念も表面化させることができます。「わざわざ言わなくても普通はこうだよね」と思われるようなことでも、曖昧にしておくと後々起こりうるリスクとなります（誰しもが一度は経験があるのではないでしょうか）。当たり前と思われることでも、必ず一度表面化させましょう。

一つ一つの解消方法が実現方法の具体化につながっているため、条件や課題の洗い出しは合意形成だけでなく、実作業においても役立ちます。開発中にこれらのうち1つでも曖昧な項目が発見された場合、技術者1人では検討できない事項であるため確認時間の分だけロスが発生します。

まずはこのように条件や課題を一度全て整理し、ここからNDAや契約書など別資料に記載されるもの、口頭確認でよいと判断される内容は要件定義書から省いていきます。

潜在的な懸念を洗い出し尽くし、リスクを最小限にする。

【合意形成のためのプロセス②】開発手法を導き出す

まずシステム開発における開発手法をおさらいしましょう。細かく分けるとさらに列挙することができますが、一般的なのは次の通りです。

• ウォーターフォール…逐次型。要件定義・外部設計・内部設計といった工程を、上流工程から下流工程へ順におこなっていく
• プロトタイプ…試作型。動作するシステムを作りつつ改善を繰り返していく
• アジャイル…反復型。機能毎の小さな単位に分割して追加開発を繰り返していく
• スパイラル…複合型。上記手法を組み合わせてバージョンアップを繰り返して理想へ近づけていく

一般的にはウォーターフォールが中～大規模開発向きと言われています。要件定義書が必要になった時点で、ウォーターフォールが採用される（※）可能性が高いわけですが、順序を守らずに開発手法から決めていくと目的を見失った半端な中間成果物が生まれる危険性が高まります。

※部分的な併用を含む（特定機能のみプロトタイプを作成。デザインはアジャイルにして最低提示パターン数や修正期限を設定するなど）

開発手法は、本来次のプロセスを経て導き出します。

1. 課題の解決方法を検討する
2. 課題解決に必要な作業・資料を検討する
3. 課題解決に必要な「プロセス」「成果物」が決まる
4. 開発手法が決まる

本来の順序に従えば、5W1H（誰が、いつ、どこで、何を、なぜ、どのように）が明確なフォーマットで、成果物が選定されているはずです。この際に基本設計書、詳細設計書など成果物のサンプルを作成して、記載粒度まで工程担当者間で確認できれば、次工程への進み方がスムーズになります。

例えば、プログラマーは「この場合はどうするんですか？」「画面Aと同様ってどこまでの意味ですか？」などの疑問が発生しない設計を望んでいます。サンプルを用意しておくことで「画面遷移でエラー時の挙動を検討して記載しておく気があるのか」「画面毎に項目の全量が確認する気があるのか」など、どのような設計をするつもりかをあらかじめ共有できます。事前に検討不足の懸念があれば指摘を貰えることになるので、サンプルの事前作成は後々の作業遅延を防ぐ意味で非常に有効です。

ここまで行うことで多くの課題に対しての実現方法が示された状態になりますが、多様な経験と知識も求められます。内容によっては複数人であたるといいでしょう。

開発手法、工程、成果物（中間成果物）から決めない。課題をベースにボトムアップで開発手法を導き出す。

【合意形成のためのプロセス③】各工程でのレビュー

ここまでの内容で、課題の整理と開発手法の導出は行いました。しかし繰り返しになりますが、要件定義書は「作って終わり」ではありません。これでは完成度は60%のままです。作成した内容を基にクライアントと実現方法を検討し、合意を得て初めて要件定義書の役割を100%果たせていると言えます。

例えば、工程を順に進むウォーターフォールにおいて工程の逆戻りはNGです。では開発手法がウォーターフォールと書かれていれば、開発の進行途中で仕様変更の必要性を感じたクライアントは諦めるでしょうか。ほとんどのケースで否でしょう。やむを得ない場合は上流工程に戻りスケジュールと費用を見直してやり直す必要があります。

しかし仕様変更も、いつまでも際限なく受けてしまうと開発工数が増大し続けるだけでなく、影響範囲を見誤ることによる品質低下を招きます。成果物の品質が下がることは、クライアントも制作会社も、誰も望んではいません。

そういった事態を防ぐために、要件定義書に予め仕様追加・変更の受付期限や、それによる金額・スケジュールの変更についても明記し、かつクライアントと認識を合わせます。

また各工程においても

• 要件定義書に記載外の機能は本工程では追加できない
• 要件定義書に記載外の帳票出力は別費用

など、次工程に入ると対応できない事を都度伝え、理解を深めてもらうとともに、合意に沿ったシステム開発の進行を定着させなければ意味がありません。要件定義書に記載されている内容、本契約を履行する上で必要な条件・理由をしっかりと説明して、理解と合意が得られるまでが要件定義工程です。妥協が変更が必要ならば予め代案や対策を講じます。

どこまで厳密にやれるかはともかく、要件定義書を反故にするのであれば、こちらも成果物の品質を担保できないことは理解してもらわねばなりません。各工程のレビューが如何に重要な意味を持っているか、早い段階で気づいてもらいましょう。

ここまでを経て「実現方法を検討、合意した文書」になります。せっかく時間をかけて作成した要件定義書をただの納品物としてとらえ、思い出の栞にしてしまうのは勿体ないです。

要件定義書は納品して終わりではない。要件定義書は理解が得られて初めて意味を持つ。

合意形成が軽視されると何が起きるか？

少し脇道にそれて、 「開発手法：ウォーターフォール」の1行を軽視するとどうなるかで見てみます。というのもトップダウンの業務であればウォーターフォールの要素を少なからず含んでおり、これを正しく理解しておくことはとても大切だからです。

ウォーターフォールのおさらい

出版元にもよりますが、ウォーターフォールの解説は概ねこのような内容かと思います。

メリット

1. 工程が並行して行われないので手戻りが起きにくい
2. 各工程で成果物ができるので進捗状況が明確
3. 制作段階で作るモノが明確になる
4. 各工程で精査されることで品質が担保しやすい

デメリット

1. 各工程のドキュメントを、発注側が理解できる必要がある
2. 各工程を順次終わらせるフローなため、手戻りのコストが大きくなる
3. 実際に動くものを触るまでに時間がかかる

各工程の性質

下記のような工程があった場合、A～DはそれぞれEの成果物を示しており、「最終的に成果物が出来上がる」という意味では、あくまで全てイコールの関係です。

ウォーターフォールにおける各工程の粒度（説明が煩雑に煩雑になるため、結合テスト以降は省略しています）

しかし下流へ進むほど粒度が細かくなって記述量が増え、AとDで比較すると1行が表す範囲は大きく変わります。Aで1行で語られていたことを、Dで数行〜何十何百行も使って詳細に詰めます。従って上流工程ほどファイル単位の密度が高く、わかりやすく言い換えれば上流工程ほど重要になります。

各成果物が示す総量はイコールでも、それぞれで表現の仕方は全く異なります。「要件定義書の記述量が1割増えたから、プログラムも1割増える」というような性質ではありません。

仕様変更がもたらすもの

ウォーターフォールという名のとおり、水の流れに逆らって工程を遡る、遡上行為はNGです。好まれないのではなく、NGです。各フェーズのレビューと承認は不備・不足がないことを証明する非常に重要な行為です。この世で遡上するのを許されている生物は鮭のみです。

それでも、仮に開発途中で仕様変更があったり、重大な欠陥が見つかるなど、遡上行為をやむをえず許可する場合もあると思います。そういった場合における、起こりうる自体はきちんと理解しておきましょう。

前工程に対する修正作業が追加される

ウォーターフォールで変更や追加があった場合、同じ内容の仕様でも、発生するタイミングが遅ければ遅いほど、下流の開発に進んでいればいるほど必要な工数は増えます（デメリット2）。例えば工程Aで変更が発生した場合、必要な追加工数は15人月です。しかし同じ内容の変更でも工程Dで発生した場合は、25人月の工数が必要となってしまいます。

なぜここまで工数が膨れ上がるかというと、これは下流工程で発生した変更は、原則として上流工程の修正とレビューを必要とすることに起因します。簡単に表すと、次の通りです。

• 工程Aで発生：15人月の作業量
• 工程Bで発生：18人月（15人月 + Aの修正とレビュー）
• 工程Cで発生：22人月（15人月 + A／Bの修正とレビュー）
• 工程Dで発生：25人月（15人月 + A／B／Cの修正とレビュー）

また本来はここまでですが、対応を誤るとこれだけでは終わりません。上述の通りクライアント視点では工数が過小に想像されがちなため、15人月自体の理解も得られにくいでしょう。下流工程では作業が膨れてしまうため、25人月が正確な工数であったとしても大概揉めます。加えて予算の都合もあります。「なんでそんなにかかるんですか？」と言われたことはありませんか？

ここできちんと説明できず、工程Dで発生した変更でも15人月の追加で妥協してしまった場合、マイナス10人月の乖離が生まれ制作会社内では「巻き」が発生します。これがこの後の問題点の全ての原因で、不夜城建築の基礎工事となります。

工程の平行作業がおこなわれる

作業を巻くために設計書修正を待たずに、口頭指示で下流作業がおこなわれます。これはウォーターフォールのメリットの1つ目である「工程が並行して行われないので手戻りが起きにくい」に明らかに反します。また指示が口頭ベースとなるため情報の属人化が発生するだけでなく、ヘルプなどで後から入った人が「どの情報が正しいかわからない」という混乱を招きます。

仕様不備と仕様齟齬が発生する

作業を巻くために充分な検討が不足し、設計者との認識齟齬が発生します。これはメリットの3つ目である「制作段階で作るモノが明確になる」に反します。

品質が落ちる

作業を巻くために前工程のレビューが割愛され、仕様不備を誘発します。さらに足りない工数を補うためにテスト期間も削られます。4つ目のメリットである「各工程で精査されることで、品質が担保しやすい」に違反します。

裏進捗表が生まれる

マイナス10人月の乖離のつじつまをどうにか合わせようとすることによって、制作会社内部でのみ使用する「裏進捗表」が生まれ、実際の進捗が把握しにくくなります。これは2つ目のメリットである「各工程で成果物ができるので進捗状況が明確」に反します。

このように、下流工程における仕様変更は、ウォーターフォールの全てのメリットを奪いかねません。力技で捌けなかった場合、品質低下や進捗遅延で制作会社側の立場が弱まり、追加要求を受けざるを得ない悪循環のサイクルが始まります（経験がありませんか？）。乖離率が広がり、やがて50%を超えると、いわゆる「デスマーチ」と呼ばれ手の施しようがなくなります。要件定義書に書かれた「開発手法：ウォーターフォール」の1行にも、これだけの重要な意味があるのです。

クライアントは開発のプロではないため、下流の視点がなく、どうしても作業量を軽く考えてしまいがちです。それ自体は仕方がないでしょう。重要なのはPMやディレクターが各工程の性質を理解して、両方の視点でクライアントとエンジニアを繋ぐ役割を担うことが求められます。

ただしそれにも高度な専門知識と管理能力が求められるため、これがウォーターフォールのデメリットの1つとして数えられています。

要件定義書の用途

ウォーターフォールの話が長くなってしまいましたが、きちんと作成され、双方の合意を得ている要件定義書はこういった事態を防ぐことに役立ちます。

制作会社は手戻り（都合のいい解釈、機能追加）が行われないようクライアントをディレクションするための根拠として、要件定義書を使用することができます。またそれだけでなく、設計不備やバグなどが起きないよう、制作会社社内の各工程の作業を管理するのも要件定義書の役目です。

一方クライアントも、制作会社に対して認識齟齬や要件漏れ、機能レベルの引き下げ、ごまかしを監視するために要件定義書を活用できます。それだけでなく、クライアントも社内において成果物やQAの承認を行うための体制作りに要件定義書が役立てられます。

このように、きちんと作成され合意形成がされている要件定義書は、双方が双方をコントロールするだけでなく、それぞれの社内においても重要な役割を果たします。

まとめ

つまり要件定義書とは、「アウトプットを定め、実現可能条件を示した合意書」であるべきだと私は考えています。

クライアントと制作会社はパートナー関係です。作業が進行するにつれて関係が悪化する多くの原因は、制作会社側にあります。

• 自社全体の能力を把握しきれていない
• 全工程を描き切れていない
• 説明責任を果たせていない
• 指針が明確に定められていない
• 遵守されるべき進行を怠っている
• バグが多すぎる

要件を定めたうえで、守られそうにないリスクがあるならば、相応の対策を講じておくべきであり、それをおこなうのは要件定義工程です。 往々にして理想通りには進みませんが、重要性を理解して活用すれば必ず助けになるはずです。

プロジェクトの安定進行は、結果としてクライアントだけでなく、制作会社のメリットに繋がります。双方が幸せになるためにも、ぜひ要件定義書を積極的に活用してみてください。

株式会社12Gridについて

WEBシステム／CMS開発、HTMLコーディング、WEB広告などの課題を解決する札幌の制作集団です。
受託と自社サービス開発を並行しています。新しいアイディア、チャレンジは大歓迎です！