関連するソリューション
システム開発
株式会社IDデータセンターマネジメント
ICTサービス第6部
テクニカルスペシャリスト 千葉 由紀祐
早いもので今年もあとわずかになりました。
東京では11月上旬まで20度を超えていましたが、中旬から急激に気温が下がり、秋を感じる間もなく冬が到来した感じですね。
写真にあるIDカフェは例年晩秋に開催され、近くのイチョウ並木で紅葉を楽しめますが、今年は色づきが少なく、いつもと違う景色でした。
１年を振り返ってみると、ITサービスマネジメント、事業継続管理に加えて、顧客先の新規プロジェクトの要件定義に携わり、新たな分野にも従事した年でした。
2023年最後のコラムは、要件定義におけるユーザとの協働をテーマに述べていきたいと思います。
要件定義の実状
従来のシステム開発プロジェクトは、ウォーターフォール型の開発がベースにあり、要件定義から始めることが多くありました。しかし、近年の技術の高度化、クラウドをはじめとする多様なサービス創出、開発手法の変化、不確実性が高い外部環境などを受けて、要件定義の前工程として、構想・企画や概念実証(PoC：Proof of Concept)を行うことが多くなりました。特にDX推進プロジェクトにおいては、新しいサービス開発のため、導入実績のない技術を採用するケースも多く、まずは構想・企画、概念実証からとなり易いと言えます。
そして、要件定義においては、構造・企画、概念実証の結果を踏まえた上で、要求を満たすための新技術・サービスの活用をした要件を整理することから、以前よりも難易度は上がってきていると思います。
プロジェクトの開発遅延、予算オーバー、品質不良などの原因の過半を要点定義が占めると言われていることから、より堅実かつ体系的に要件定義に取り組み、手戻りがない様に進める必要があります。
そして、取り組むにあたって一番大事なのが、ステークホルダーのそれぞれの立場で要件定義の目的・手段・対応内容を理解した上で協働できる様にすることです。
要件定義におけるユーザとの協働
要件定義を端的に言えば、要求から要件を整理し文書化することですが、ビジネス要求、システム化要求それぞれの要件整理、要件定義工程を円滑に進めるマネジメント、後工程で正しく利用できる文書化など、対応すべき事項は多々あります。情報処理推進機構（IPA）が「ユーザのための要件定義ガイド」（現在は第２版）を公開しており、システム開発のステークホルダーが、要件定義が何故必要なのか、活動内容はどういったものなのか、目的や効果を理解した上での活動を推進しています。
例えば、ビジネス要求定義における現状把握を行う際、業務の可視化、資料収集、ヒアリング、業務作業のシャドーイングなど、様々な対応を検討・実施しますが、ユーザが目的・効果を理解しているのと理解していないのでは、進捗や品質に差が出てしまいます。（ユーザへのヒアリング時間を十分確保できなかったり、収集資料に不足が出てしまうなど）
ベンダーにおいては、このような目的・効果の共通認識を得られるガイドなどを活用し、ユーザなどのステークホルダーに要件定義の理解推進を図り、協働するための取組みは非常に大事な活動になります。
要件定義における主な問題
要件定義を協働していく上で、起こり得る問題に対する共通認識も持っておく事も大事なポイントです。前述のガイドでは “要件定義における主な問題”を取り上げ、それを要件定義の4つのプロセス（ビジネス要求定義、システム化要求定義、要件定義マネジメント、文書記述）で「要件定義問題カテゴリマップ」として分類・整理しています。
■要件定義における主な問題
| 問題 |
分類 |
|---|---|
| 現行業務やシステムが分からない |
現状把握の問題 |
| 真の問題・課題が抽出できていない |
問題課題抽出の問題 |
|
ゴール明確化の問題 |
| 要求間の整合性がとれていない |
要求の体系化の問題 |
| 要求に基づき、新たな業務としてうまく具体化できない |
要求の具体化の問題 |
| 要求が膨らみ、捨てる判断が難しい |
優先順位付けの問題 |
| 各ステークホルダに対し要求の合意形成が難しい |
要求の交渉の問題 |
| 成果物に抜け・漏れ・あいまいが存在する |
要求の仕様化の問題 |
| 要件定義の不具合を抽出しきれない |
要求の検証の問題 |
| システム化仕様が経営や業務にどう貢献するか分からない |
妥当性確認の問題 |
|
立ち上げ時の問題 |
| 要件定義で何をどこまで実施すれば良いのか分からない |
要件定義プロセス計画の問題 |
| そもそも開発スコープがあいまいである |
スコープ定義の問題 |
| 要求件数では開発規模の膨らみが分からない |
見積りの問題 |
| 要件定義ドキュメントの品質の確保方法が分からない |
品質計画の問題 |
| 要件定義の体制が不十分である |
体制・チームビルディングの問題 |
| 要件定義の契約形態がバラバラである |
契約の問題 |
| コミュニケーションが不十分である |
コミュニケーション計画の問題 |
| リスクを把握できていない |
リスク認識の問題 |
| 要求調整・規模調整のコントロールができない |
要求・スコープコントロールの問題 |
| 要件定義の品質を監視できない |
品質の監視の問題 |
| コミュニケーションがうまくいっているか分からない |
コミュニケーション監視の問題 |
| 課題やリスクが放置される |
リスクの監視の問題 |
| ドキュメント間の整合性がいつの間にか失われる |
トレーサビリティ管理の問題 |
| 要件定義完了時期に未決定要求が残る |
要求評価の問題 |
| 要件定義の完了を判断できない |
完了判断の問題 |
| 要件定義ドキュメントのサンプルや書き方のコツが欲しい |
要件定義ドキュメント記載上の問題 |
■要件定義問題カテゴリマップ
引用：IPA「ユーザのための要件定義ガイド 第2版」P58
そして、各プロセスのサブプロセス（例えば、ビジネス要求定義であれば、獲得、分析、文書化）のタスク・項目毎に、問題とその問題を解決のための勘所がペアで記載されています。
例えば、ビジネス要求定義(BR)のビジネス要求の獲得(BR.1)における現状把握(BR1.1)では、問題２点に対して、勘どころが複数（1つ目が5点、2つ目が2点）挙げられています。
引用：IPA「ユーザのための要件定義ガイド 第2版」P60 一部加筆
ガイド文中には、それぞれの勘どころ毎に、取り組み方や成果物、テクニカルな手法などの説明などがあり、ユーザにとっても目的を理解し易い形になっています。
ユーザと共にカテゴリマップで全体を俯瞰した上で、現在のプロジェクトの状況にあった項目をピックアップして取り入れていくなどの行動は、共通認識を持つ取り組みとして有効です。
最後に
私が要件定義に取り組む際は、要件漏れ、曖昧さなどの不備による手戻りを回避するために、以下の項目を常に意識しています。
| 項目 |
行動 |
|---|---|
| 要求と要件の整理 |
要求（～したい）と要件（～する）は明確に分けて整理する |
| 要件の明確化 |
相手に伝わる資料作りで要件の曖昧さを残さない |
| 要件の優先度 |
スケジュールを踏まえて、詰めるべき(後で変更が困難)要件と後で詰める要件を分ける |
| 要件変更・追加要件の対応 |
適宜発生する要件変更・追加要件は期限を切って対応する |
| 関係者の把握 |
関係者はできる限り早めに参画要請する |
| リスク対応 |
リスクや課題に対しては早期の対応検討・調整する |
要件定義はプロジェクトそれぞれで対応が異なり、また正解のないものです。
手戻りのない効果的な要件定義を実現するためには、ベンダー含めた開発サイド中心で推進するのではなく、プロジェクトに係わるステークホルダーが要件定義の目的・手段・対応内容を共通認識を持ち、より多く関わり合いを持ちながら協働できる様にする取り組みが重要です。
本コラムがその取り組みの参考になったら幸いです。
では、また次回コラムでお会いしましょう。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。
