要件定義の進め方とは？見極めるべき3つのリスクと対策

システム開発プロジェクトにおいて、要件定義はプロジェクトの成否を分ける重要なフェーズです。
本コラムでは、私がこれまで経験してきたプロジェクトの中から、「事前のルールや仕組み作りによって未然に防げるもの」に焦点を当て、要件定義で特につまずきやすいリスクを選定しました。
「理想的な環境」と「自社の現実」のギャップに気づき、プロジェクトを成功させるための実践的な対策をご紹介します。

記事の執筆

システムコンサルタント久保田一樹

メーカー系SIerに入社後、メガバンク案件でプロジェクトマネジメントを経験する。多くのステークホルダーと厳格なスケジュールのもと、プロジェクトの成功に貢献する。その後、信用調査会社で社内システムの要件定義から移行までを担当し、利用者視点の設計で高く評価される。これらの経験を活かし、現在は開発者と利用者双方の視点を持つコンサルタントとして、PMO支援を中心に活動している。

要件定義の基本的な進め方

要件定義の進め方について、IPA（情報処理推進機構）が策定した共通フレームを参照すると、主に以下のアクティビティ（タスクの集合）で定義されています。

プロセス開始の準備（計画の策定）
利害関係者の識別（体制の構築）
要件の識別（業務フローや要望の洗い出し）
要件の評価（実現可能性や妥当性の検討）
要件の合意（ステークホルダー間での合意形成）
要件の記録（要件定義書としての文書化）

端的に言えば、「あらかじめ策定されたプロジェクト計画に従い、関係者を巻き込みながら要件を洗い出し、評価・合意する」ことが要件定義の基本的な進め方です。
しかし、実際の現場では、この手順をなぞるだけでは理想通りに進まないことが多々あります。

計画なきプロジェクトが失敗しやすい理由

要件定義の手順に入る前に、重要な前提があります。
それは「プロジェクト計画（目的、スケジュール、役割、コミュニケーションルールなど）」が策定されているか、という点です。
「今回は小規模な改修だから」と計画書の作成を省略し、要件定義を始めるケースがあります。
しかし、こうした進め方はスケジュール遅延やコスト超過を引き起こす原因となり得ます。
なぜなら、計画がない状態とは「いつ・誰が集まって要件を決定するのか」「いつまでに要件を固めるのか」というルールや期限が存在しない状態だからです。
実際に私がPM支援として参画したプロジェクトの中にも、計画を省略した結果、月単価130万円のエンジニアが2ヶ月で完了させる予定が6ヶ月経っても終わらず、520万円（4ヶ月分）もの追加コストが発生してしまったケースがありました。
このプロジェクトの状況を分析したところ、以下の事実が分かりました。

コミュニケーションエラー：チャットツールでの文字ベースのみでやり取りされており、微妙なニュアンスの取り違えが多発していた。
決定事項の埋没：決定事項が正式なドキュメントに整理されずチャット上に流れてしまい、要求出し元自身が過去の要求を失念していた。
手戻りの常態化：「要件定義で合意した」と認識して構築しても、UAT（受入テスト）になって要求出し元が不具合として認識し、修正を繰り返していた。
業務とITの橋渡し役の不在：現場の要求を、システム要件や設計に正しく落とし込める（業務と開発の両面に精通した）人材が不足していた。

これに対し、改めてテスト計画書や議事録といった「成果物の定義」を行い、定例会議を設けて「コミュニケーションルール」を再構築しました。
さらに、要求出し元と開発側の橋渡しを担う人材をアサインすることで、ようやくプロジェクトは正常化に向かいました。
このような状況にならないためにも、要件定義を始める前に、まずは「計画」という土台があるかを確認することが不可欠です。

「理想」と「現実」のギャップを知る3つの問い

プロジェクト計画が存在していても要件定義が難航する要因として、「理想的なプロジェクト環境」を暗黙の前提として進めてしまうことが挙げられます。
自社の環境が「理想」からどれだけ離れているかを見極めるため、要件定義の開始時に以下の「3つの問い」を立ててみてください。

問い①：現場の業務担当者は、プロジェクトの専任（または十分な時間が確保されている状態）か？
問い②：現行業務の判断基準は、担当者の「感覚」や「経験則」に依存せず、ルールとして整理できる状態か？
問い③：システムを利用するのは単一部署のみで、業務パターンの複雑さは低いか？

これらがすべて「Yes」となるような理想的な要件定義など現実には存在しないと思った方が良いでしょう。実際の要件定義は、一筋縄ではいかない複雑な調整の連続です。
この「現実」に対する対策を講じずに進めると、各フェーズで思わぬリスクが顕在化します。

「現実のプロジェクト」を成功に導く3つの対策

前述の「要件定義の基本的な進め方」の中で、特にリスクが潜みやすい3つのアクティビティと、その対策を解説します。

利害関係者の識別でのリスク（「体制図の承認＝現場が動く」という認識に潜むリスク）

【想定されるリスク】
プロジェクト体制図が承認され、現場の業務担当者がメンバーにアサインされたとしても、安心はできません。
兼務である現場担当者にとっては日々の「通常業務」が優先されやすく、要件定義のタスク（業務フローの作成やヒアリングへの回答など）が後回しにされてしまうリスクがあるためです。

【対策】
担当者個人の善意や「お願い」ベースで進めるのではなく、指示を出せる現場の上長を巻き込むことが重要です。
「日々の業務を調整し、プロジェクトに参画すること」を正式なミッションとして現場担当者に与えてもらうよう、上長と事前に合意形成をしておきましょう。
しかし、業務部門に協力を依頼しても「本来の業務で忙しいから」とプロジェクトを業務と捉えていないケースも見られます。
たとえ業務部門の上長が形だけ承認しても、実態として現場の負荷調整は行われないことが多々あります。
このような状況を打破するためには、外部のコンサルタントを「外圧」として活用することが有効です。
経営的視点（プロジェクト失敗による損失など）からトップダウンで現場の上長に動いてもらうよう働きかけるなど、社内の関係性上、強く要求しづらい部分を、外部リソースに担わせることも、プロジェクト管理の手法です。
ユーザー企業のプロジェクトリーダーが果たすべき役割と上長を巻き込むべき理由については、下記コラムもぜひ参考にしてください。

要件の識別でのリスク（「現場の要望＝要件」と捉えることのリスク）

【想定されるリスク】
感覚や経験則に依存した業務をヒアリングしようとしても、現場から出てくる要望には「今まで通り」や「特定の条件以外」といった曖昧な表現が含まれることが少なくありません。
これらをそのまま要件として捉えてしまうと、解釈の余地を残したまま文書化され、システム化に向けた判断基準や条件の定義漏れを招くリスクがあります。

【対策】
要件の曖昧さを排除するため、ヒアリング時に出てきた「定性的な表現」や「否定語」はそのまま要件とせず、明確な基準へと「翻訳・変換するプロセス」を設定しましょう。
例えば、「今まで通りのレスポンス」という定性的な要望は、「3秒以内」といった明確な基準（定量化）に変換します。
また、「無料会員以外」といった否定語で終わらせず、「それは『有料会員』のことか、あるいは『休眠会員』や『退会済み会員』も含むのか」を検討し、「有料会員なら処理X、休眠会員なら処理Y」のように、『肯定的な条件パターン』で洗い出すようにしましょう。

要件の合意・評価でのリスク（「ドキュメントの読み合わせ」による承認の形骸化リスク）

【想定されるリスク】
業務パターンの複雑性が高い要件において、分厚いドキュメントを読み合わせるだけのレビューは、「形骸化した承認」になるリスクがあります。
なぜなら、システム用語や機能単位で書かれた文字の羅列を追うだけでは、システムの要求出し元（現場担当者）が「自分たちの実際の業務がどう変わるのか」を正しく理解し、レビューすることが難しいためです。
結果として、テスト段階になってから仕様漏れが発覚する可能性を高めてしまいます。

【対策】
システムの画面や機能ごとの確認ではなく、UAT（受入テスト）のように「誰が・いつ・どう操作し、結果としてどうなるべきか（期待値）」という「業務シナリオ」の粒度で要件をレビューする計画を、あらかじめ要件定義のタスクとして組み込んでおきましょう。

【業務シナリオの例】

キャンペーンの案内メールを配信する際、「無料会員」と「休眠会員」には正常に送信され、「退会済み会員」には誤って送信されないこと

「これで実業務が回るか」という観点でレビューを実施することで、仕様漏れを防ぐ可能性を向上させられます。
形骸化を防ぐレビューのあり方については、下記コラムもぜひ参考にしてください。

まとめ：要件定義の成功率は「現実の直視」で高まる

要件定義を成功させるためには、「プロジェクト計画」という土台があることが大前提です。
その上で、自分たちのプロジェクトが抱える「現実（現場の状況や業務の複雑さなど）」を正しく認識し、体制づくりやルールの厳格化、レビュー手法の工夫といった対策を講じておくことが、プロジェクトを成功に導くノウハウと言えます。
社内メンバーだけではしがらみにとらわれて打破できない壁がある場合は、第三者である外部専門家の「客観的な視点」や「外圧」を上手く活用することも一つの有効な選択肢です。
自社のプロジェクト体制や進め方に不安を感じた際は、一度フラットな視点で現状の計画を見直してみてはいかがでしょうか。