要件定義を担当することになったけど、何から始めればいいの？どうやって進めるの？
要求定義と要件定義は違うの？要求定義ってなに？
何のために要求定義をするの？
システム開発において、スケジュールが遅れる主な原因のうち、50％以上が要件定義の不備に起因すると言われています。プロジェクトの成否は要件定義で決まると言っても過言ではありません。
要件定義は、「企画構想」「要求定義」「要件定義」の3つのステップで進めていきます。いきなり要件定義に着手するわけではありません。
要求定義は、要件定義のインプットになる重要なプロセスです。ここで誤った情報を掴むと使われないシステムを構築することになるかもしれません。
ここでは、システム開発における要求定義について、要件定義とは何か、要件定義との違い、要求定義の進め方とポイントをわかりやすく解説します。少しでも要件定義の参考になれば幸いです。
要求定義とは（要件定義との違い）
要求定義とは、企画構想で立案されたプロジェクト計画書をもとに、それに向けた業務プロセスの改善や標準化の検討を行う作業です。
文章にすると分かり難いため、まずは下図をご覧ください。
これは要件定義の3つのステップを表しており、今回のテーマである「要求定義」は2つ目のステップになります。
Step1. 企画構想
通常、要件定義を行う前には、企画構想のステップがあります。ここではプロジェクトの立ち上げ、体制の構築、プロジェクト計画書の立案を行います。経営方針やシステム化方針により、そのプロジェクトの目的、システム化の構想、実現後の効果が決定し、プロジェクト計画書にまとめ上げます。
Step2. 要求定義
企画構想で立案されたプロジェクト計画書をもとに、それに向けた業務プロセスの改善や標準化の検討を行います。現状把握から問題・課題を抽出し、実施すべき業務要件を決めます。
Step3. 要件定義
要求定義をもとに、システム化に必要な機能要件を抽出し、実現可能な要件仕様の検討、システム化する機能要件と非機能要件の決定、成果物（ドキュメント）作成を行います。
つまり、「要求定義」は「要件定義」のインプットになる重要なプロセスで、「企画構想」の目的を実現させるために必要な業務要求を取りまとめて文書化することがゴールになります。
まずは「要件定義全般について知りたい」と言う方はこちらで解説しています。
要求定義の進め方
要求定義は、次の4つの手順で進めます。
1. 現状を把握する
システム化の対象となる業務すべてを洗い出します。
業務の洗い出しは、大きな括りで業務を列挙してから業務ごとに詳細化していくと漏れなくまとめることができます。
| 業務名 | 詳細業務名 |
|---|---|
| 受注業務 | 注文受付、商品確認、台帳登録、仕入先発注、納品登録、・・・ |
| 出荷業務 | 出荷登録、出荷伝票作成、納品伝票作成、・・・ |
| 在庫管理業務 | 在庫棚卸、入庫管理、出庫管理、月末在庫登録、・・・ |
お客様でも現行業務と既存システムの全体像を描ける方は少ないと思います。まずは現行業務の全体像を可視化することから始めましょう。
2. 現在の業務フロー図をまとめる
システム化対象の業務について、業務担当者にヒアリングして業務の流れを図式化しましょう。業務フロー図は縦軸に登場人物や関連システムを列挙し、横軸は時系列でまとめると分かりやすくなります。
また、業務は日々の業務（日次作業）の他に、月末や月初に行う業務（月次作業）、半期毎や年末のみの業務（年次作業）、突発的な業務（臨時作業）がないかも確認しましょう。
なお、業務フローの書き方は次の「要求定義のポイント」に記載しています。
業務を漏れなく洗い出す業務フローの書き方をまとめています。よろしけれ参照ください。
ヒアリング時に現在使っている帳票や画面キャプチャ、既存システムの仕様書やマニュアルなど、参考資料として受領しておきましょう。
もし、既存システムの仕様書やマニュアルが無い場合は、既存システムのテスト環境（本番以外の環境）が利用できないか確認しましょう。
3. 問題や課題を抽出する
業務フローをまとめると業務全体の理解が深まります。これにより、お客様と現在の問題箇所の確認、課題の認識合わせができます。確認した問題や課題は要求事項一覧に追記していきます。
4. 実現可能な問題解決の手段を決める
確認した問題・課題について、お客様の要求に合わせて実現可能な解決手段を検討します。解決方法が決まったら、ビフォーアフター図などにまとめます。
ビフォーアフター図とは、現在の問題点と解決後の姿と効果を業務視点で描いたもので、経営層にも理解できる内容でまとめます。できれば、お客様に依頼してビフォーアフター図に作成してもらってもよいでしょう。
要求定義のポイント
要求定義を実施する上で、気を付けておきたいポイントを記述します。
ステークホルダーが誰かを把握する
このプロジェクトに関わるステークホルダーが誰なのか、ステークホルダー全員を把握することがとても重要です。
ステークホルダーが漏れていると、システム化対象の業務と要求も漏れてしまいます。最悪、お客様の受入テスト段階で機能漏れが発覚すると手戻りによるスケジュール遅れ、開発工数の増加により失敗プロジェクトへまっしぐらです。
ステークホルダーがプロジェクトに与える影響、ステークホルダーの特定や理解など、ステークホルダーの管理方法をこちらで解説しています。合わせてお読みください。
お客様から情報提供いただいて現状を把握する
現行業務の全体像や流れを把握するために、まずはお客様から情報提供いただくものが無いか相談しましょう。
会社の業務規程やマニュアル、担当者が持っている個人メモ等、何でも有益な情報であれば情報提供いただけないか確認して受領しましょう。
業務規程に関する資料、新人研修資料、運用マニュアル、担当者間の引継ぎマニュアル、担当者が持っている個人メモなど
既存システムから現状を把握する
システム化対象の業務において、担当者の入れ替わりが続くと次第に何のための作業か目的が分からない（担当者が説明できない）ことがあります。
業務がきちんと引き継がれていないことが原因ですが、このような場合は既存システムから業務の目的や機能、手順を把握できないか確認します。
システム操作マニュアル、システム設計書、ソースコード、ジョブスケジュール、システム運用マニュアルなど
また、既存システムのテスト環境（本番以外の思考環境など）があれば、それをお借りして操作することで画面の動きや手順の理解を深めることができます。
ぜひともお客様にテスト環境が無いか確認して、利用できるようならセットアップを依頼しましょう。
現場・現実・現物で現状を把握する
「現場」「現実」「現物」の3つの「現」から三現主義と言われ、モノづくりの製造現場では当たり前の言葉ですが、「現場」で「現物」をみて「現実」を認識することが重要という意味です。
これはシステム開発の場面、特にお客様の業務内容を理解するために重要な考え方だと思っています。
現状把握に行き詰まった時は、業務担当者の現場まで足を運んで、実際に使っている帳票の現物を見て、どのように処理しているか現実の動きを確認しましょう。
３階層のフロー図で現状を把握する
対象業務の実態が見えてきたら、次の3つのフロー図をまとめて全体を把握しましょう。
モデル化した図を用いることで検討メンバー全員の認識合わせができるため、理解の食い違いを防ぐためにも非常に有効です。
1. 業務プロセス関連図
対象となる業務全体の流れを鳥瞰して1枚にまとめたフロー図です。1枚にまとめるわけですから「○○業務」とか「○○処理」など、大括りな表現で記入します。経営層が主体となる業務プロセスの改革には、このレベルの図を使って検討を進めます。
2. 業務フロー
対象業務の現状の流れをまとめたフロー図です。業務プロセス関連図に記載されている業務の1つ（もしくはひと塊り）を切り出して業務の流れを詳細化します。このフロー図を業務担当者と共有し、現状の問題・課題の抽出、業務プロセスの改善を検討します。
3. システム化業務フロー
システムを利用した場面を書き込んだフロー図です。業務フローに記載されている作業の1つ（もしくはひと塊り）を切り出し、システムの利用場面を追加して詳細化します。このフロー図を業務担当者と共有し、システムの現状の問題・課題の抽出、システム化の改善を検討します。
これら3つの業務フローの書き方について詳しく解説しています。こちらもあわせてお読みください。
問題と課題を正しく抽出する
問題や課題とは何でしょうか？
問題とは「解決すべき事柄」で、課題とは「解決しなければならない問題」と辞書には記されていますが、これだと分かり難いので次のように言葉を置き換えて説明します。
プロジェクトで「解決すべき事柄」とは「あるべき姿(To-Be)＝プロジェクトの目的」と「現状(As-Is)＝現行業務や現行システム」とのギャップです。それが「問題」と言うことになります。
プロジェクトで「解決しなければならない問題」は「あるべき姿と現状のギャップ」で、「ギャップを埋めるための方策＝解決すべきテーマ」が「課題」であると考えれば理解し易いかと思います。
このように、ステークホルダーから「プロジェクトの目的と現行業務や現行システムのギャップ」を確認し、そのギャップを埋めるための方策を「解決すべきテーマ」として抽出しましょう。
解決手段は業務とシステムの両面で検討する
解決すべきテーマの解決手段は、アイデア次第でいくつも出てくるでしょう。
解決手段を検討する時に常に意識しておきたいことは、業務面の解決手段とシステム面の解決手段の両方で検討すると言うことです。
システム構築することが決まっているプロジェクトの場合、解決手段をシステム面だけで捉えてしまいがちですが、業務面で解決できるならその方が最善です。
目的に合った業務プロセスに見直すことが重要ですので、まずは業務面で手段を考え、次に見直された業務プロセスをベースにシステム面の手段を検討しましょう。
目的に合った解決手段かを見極める
時間をかけて検討した解決手段が目的から逸れていては意味がありません。企画構想で立案されたプロジェクト計画書の目的、経営方針、システム化方針を理解し、目的に合致した解決手段かどうかを見極める必要があります。
そのためには、目的・問題（目的と現状のギャップ）・課題（解決すべきテーマ）を明記し、検討メンバー全員で共有してから解決手段の検討を始めましょう。
また、経営層の目的を業務部門の目的に落とし込む必要がありますが、検討した解決手段が業務部門のどの目的に該当して、それが経営層の目的に繋がるかも確認しましょう。
経営層と業務部門の担当者とは目的意識が違うため、業務担当者にヒアリングすると目先の現行システムの操作性に関する改善要求が多くなります。また、業務担当者は自分達が行なっている業務範囲での改善を希望するため、俯瞰して検討しないと後工程の業務で非効率な改善となってしまう可能性もあります。
それらが目的から逸れていなければまだ良いですが、目的からかけ離れた要求事項であれば全く意味がありません。そうならないためにも、プロジェクトに関わる全員が何のためにシステム構築を行うのか、その目的をしっかり理解してもらうことが重要です。
優先度の高い要求に絞り込む
プロジェクトに関わるステークホルダーには、実際にシステムを利用する業務部門もあれば、開発費用に厳しい経理部門、事業拡大を成功させたい経営層など、様々な立場の方がいます。それぞれの要求を持っているため、ステークホルダー全員の要求すべてを実現するのは難しい場合があると思います。
その時は、プロジェクトの目的や背景、前提条件、制約条件に照らし合わせて要求事項に優先度を設け、優先度の高いものは採用し、優先度の低いものは捨てる選択ができないか調整します。
また、優先度の低いものでも方策として効果が見込めるのであれば、システム運用後に追加機能として開発する等、ステップを分けて段階的に機能拡張する方法も提案しましょう。
お客様である業務部門の方と長期間検討を重ねて決めた要件だけに、優先順位の検討には迷うことが多いでしょうし、声の大きい方に負けることも。優先順位を決めるためには、客観的に判断できる基準を定義して予め共有しておくことが重要です。
正しい要求定義でプロジェクトの第一歩を踏み出そう
要求定義は、要件定義のインプットになる重要なプロセスです。ここで誤った情報を掴むと使われないシステムを構築することになるかもしれません。それだけに抜け漏れなく慎重に進める必要があります。
ここに記述した要求定義の進め方とポイントを参考に、正しい要求定義を実施して後戻りの無いの第一歩を踏み出しましょう。
もし要件定義の進め方に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
