TRACERYプロダクトマネージャーのharuです。
システム開発チームのメンバーとして、ユーザーから「この機能が欲しい」と依頼されたとき、どのように対応しますか。
このような場合に役立つのが、依頼された内容を要望、要求、要件に明確に分類する考え方です。
本記事では、依頼された内容を要望、要求、要件に分類し、要件を導き出す方法について説明します。
要件定義の目的とゴールについては、以下の記事を参照してください。
要望、要求、要件の3段階で考える
開発の依頼内容は、以下のように要望、要求、要件の3つに分けて考えると整理しやすくなります。
要望
要望は、クライアントやステークホルダーからの初期の希望やアイデアです。ニーズともいいます。この段階では、技術的な制約を考えずに、望むことを自由に出してもらいます。例えば、「アプリの使い勝手を改善してほしい」という抽象的な内容の場合もありますし、「月次売上データをグラフで出力したい」という具体的な内容の場合もあります。
要求
要望を取捨選択し、整理、構造化したものが要求です。例えば、「ユーザーが少ないクリックで購入できるようにしたい」という具体的な内容です。
要件
最終的に、要求を取捨選択し、実現対象として合意したものが要件となります。クライアントやステークホルダー全員が同じ理解を持つことが重要です。要件は明確で実現可能でなければなりません。例えば、「ナビゲーションメニューを再設計し、3回以内のクリックでユーザーが購入できるようにする」といった具体的な内容が望ましいです。
要望、要求、要件の3つの段階を経ることで、ユーザーのニーズへの解像度を高め、費用対効果の高いシステム開発が可能になります。
要望、要求、要件の例
要望、要求、要件の具体的な内容について例をもとに説明します。
システム開発全体との関係を示すために、後述の図内では、Why、What、How、Makeとのマッピングも記載しています。
- Why 『なぜそのシステムを作るのか』という目的
- What 『何を作るのか』
- How 『どのように作るのか』
- Make『実際に作る』
詳細は以下の記事を参照してください。
要望の発生
現場担当者から「月次売上データをグラフで出力したい」という話を聞いたとします。この時点では開発するかどうかは決まっていません。開発者は「要望」としてリストアップしておきます。
要望をうけてすぐに開発するリスク
要望に対してすぐに設計や実装に取り掛かるのは、適切ではありません。
まず、グラフを画面上に出力することが本当に費用対効果が高いかを検討する必要があります。実際、グラフの実装には多くの開発工数がかかり、後になって「工数が掛かりすぎた」となることがよくあります。
また、現場担当者の要望をそのまま実現しても、担当者の誤解により、開発した機能が事業やユーザーの価値につながらず「結局使われなかった」となってしまうこともあります。要望の本質を理解し、必要性を慎重に検討することが重要です。
背景、目的の確認
要望を聞いたら、まず、要望の背景や目的を確認します。
月次売上のグラフを「いつ」「誰が」「何のために」「どれくらい」使うのかなど*1を、現場担当者に詳細にヒアリングします。これらのことを「ユースケース(システムの使用事例)」といいます。
具体的な機能の要望を受け取ったら「ユースケースはなにか」と考える習慣を持つとよいでしょう。
確認したところ、月に一度、経営者に売上を報告する際に月次売上のグラフが必要であることがわかりました。
さらに、売上報告の目的を尋ねると、会社では経営層と現場の認識の乖離が問題となっており、「経営と現場の一体化」を進めるための取り組みの一環であり、実現できればスピーディーな意思決定ができるという価値が生まれることがわかりました。
ユースケースを確認した後は、さらに深堀りして「その機能によって解決される問題や生まれる価値はなにか」を考えるとよいでしょう。
目的を実現するための手段の再検討（要求の完成）
目的が明らかになったら、その目的を実現するための手段をあらためて検討します。
グラフを画面に出力することでも目的は果たせますが、月に一度の出力頻度であれば、より低コストで実現できるCSVを画面から出力する機能を開発し、Excelでグラフを作成するという案が浮上しました。
要求とは要望を取捨選択し、整理、構造化したものと説明しましたが、この段階で、下図のとおり、要求は構造化された状態（階層構造）になります。
要件の検討（要求から要件へ）
開発者は、月次売上をCSVで出力することが最も費用対効果が高いと結論づけ、この方法を提案することにしました。
この提案に基づき、月次売上のCSV出力に必要な要件を現場担当者と相談しながら以下のように検討しました。
機能要件
- CSVに出力する項目は何か？（例：売上日、商品名、数量、売上金額）
- どのような抽出条件が必要か？（例：期間指定、商品カテゴリ別、店舗別）
非機能要件
- 出力までの時間
- 数秒以内での出力完了が必要かどうか
- 現場担当者に確認したところ、数秒以内での出力は必須ではないことがわかった。データ抽出処理の時間を試算した結果、数分かかる見込みのため、画面を非同期化し、出力完了時に通知を受け取ってダウンロードできることとした。
- 数秒以内での出力完了が必要かどうか
- 出力データのセキュリティ
- アクセス権限の制御
- 機能を使えるのは「管理者」のみ
- データの暗号化
- HTTPSによる暗号化
- アクセス権限の制御
要件の合意
開発者、現場担当者、現場責任者などのステークホルダーと協議し、今回は月次売上をCSVで出力することで合意しました。将来的には画面上でグラフを表示する計画もあり、この要求は今後の検討課題として残すことにしました。
要件は、要求をさらに取捨選択し、実現対象として合意したものと上述しましたが、合意した時点で、要求は要件になったといえます。
要件から、設計、実装へ
明確になった要件をもとに工数見積もりをし、スケジュールやコストをステークホルダーと合意したら設計を始めます。設計では、具体的な画面設計やデータ設計などを行います。設計が完了したらプログラムの実装に入ります。
これらの検討結果を経て、ユーザーの要望に基づき、費用対効果の高い開発を行うことが可能になります。
工数見積りやコスト、スケジュールなどの話は、別記事で説明します。
最後に
開発の依頼内容を要望、要求、要件の3段階に分けて整理する考え方について説明しました。
アジャイル開発宣言*2の4つの価値のひとつに、「契約交渉よりも顧客との協調を（Customer collaboration over contract negotiation）」があります。
開発者は依頼された内容をそのまま開発するのではなく、依頼者と開発者が協調して実現したい価値や目的を確認し、要件を明確にすることが重要です。
こうすることで、不要な機能の開発を避け、優先度の高い要件に集中し、結果として必要な価値をユーザーにスピーディーに提供することが可能になります。
*1:5W2Hなどという「When（いつ）」「Where（どこで）」「Who（だれが）」「What（なにを）」「Why（なぜ）」「How（どのように）」「How Much（いくらで）」の頭文字をとったもの
