ひと昔前のシステム開発では「どのように開発を行うか（How）」に重点を置き進められていましたが、その進め方では不備や失敗が多く、ひととおり経験したのちに、現代のシステム開発の関心事は「どんなシステムが必要か（What）」に変わりました。
このように、よいシステムを開発するには、考え方や進め方、成果物の書き方に至るまで、目的や環境に合わせて常に変化していく必要があります。しかし、ただ一つ変わらないことがあります。品質は顧客が決めるということ、つまり「品質＝顧客満足度」という図式です。
今回は、システム開発の超上流工程の要求定義と品質をテーマに、要求定義の進め方や書き方、要件定義書やRFPとの違いに至るまで網羅的に解説していきます。どうぞ最後までお付き合いください。
要求とは何か
①強く請い求めること。当然のこととして強い態度で相手に求めること。
②必要とすること。ほしく思うこと。
③人間の行動の基礎にある動因。願望として自覚されたものだけではなく、意識されない深層の動因もこれに含まれる。欲求。
④法律で、相手方にある行為を求めること。「請求」よりもやや広い意味で使われる。
「要求」について辞書を引くとこのように説明されていますが、システム開発における要求には②と③の内容が混在し、特に③の意味合いの要求が要求定義の難易度を格段に押し上げます。
このような要求の特徴に対して、要求定義では「何がしたいのか？」という“What”に着目することこそが正しく、開発側は顧客（発注側）から“What”をヒアリングしたうえで、技術的にシステムで実現可能なこととして、その実現方法（How）を要件として定義します。
しかし、顧客が必要とする要求の中には、いまの技術では実現不可能なことや矛盾が含まれていることが多いため、開発側は、顧客の要求に対して最適な実現手段を選択したり、顧客の要求を最適な実現方法に導くといったことが求められます。
但し、“What”をヒアリングする前に必要なことがあります。それは顧客の“Why”の確認で、システム化に至った背景やシステム化する目的が顧客の“Why”に該当します。この“Why”の確認は最も重要な部分で、ここを間違えてしまうとプロジェクトは必然的に失敗に向けてまっしぐらに突き進んでいくことになります。
要望、要求、要件の違い
さて、要望、要求、要件の違いについてですが、メタファを使って「カレーが食べたい」という要望を例に取り上げてみます。
| 要望 | 要求 | 要件 |
|---|---|---|
| ・カレーが食べたい | ・ボリューム感のあるカレー ・エビアレルギーがある | ・ポークカレーにフライ盛り合わせをトッピング ・エビフライは抜き |
上記は全て「カレーが食べたい」ことを言っているのですが、抽象度が下がるにつれ臨場感のある具体的な内容になっていきます。
要求定義とは
システム開発の一番はじめに行い、顧客がそのシステムに何を求めているのかを明確にしていく作業のことを「要求定義」と言います。
顧客が自分たちの作りたいシステムのイメージを開発側に伝え、開発側はそのイメージを形作るために顧客からの要求を整理し、必要な機能や性能などの非機能を具体的に定義していくフェーズです。
要求定義では、開発側が一方的に顧客の要求を聞くのではなく、双方が協力して行う共同作業という理解が重要で、品質の良いシステムを構築するためには、事前にこの理解を共有しておくことが望まれます。
要求定義書と要件定義書の違い
「要求定義書」とよく似た言葉に「要件定義書」があり、何れも英語では「Requirements definition document」と表記されます。
では、要求定義書と要件定義書は何が異なるのでしょうか？その違いについては、主に2つの側面があります。
要件定義書と要求定義書の違いは「夢」と「理想」の違い
要求定義書には顧客の「夢」が語られており、要件定義書にはその顧客の「夢」をシステム化した場合の「理想」が語られています。
要件定義書と要求定義書の違いは主体となる書き手の違い
要求定義書はシステム化に向けての顧客の要求を書き留めたものであるため、発注する側の顧客が書き手の主体である一方、要件定義書はシステム化するためシステムに必要な機能や非機能を整理して書き留めたものであり、書き手の主体は開発側となります。
要求と要件の対比
「要求」と「要件」について、より理解を深めて頂くために対比で確認します。
| 意味 | システム開発における定義 | |
|---|---|---|
| 要求 | 発注側が開発側に出す依頼事項（リクエスト） | 発注側が開発側に対して誰が何のためにシステム化したいかを表したもの |
| 要件 | 発注側と開発側の間の合意事項 | 開発側が発注側の依頼に対してシステムが備えるべき機能を表したもの |
要求定義書とRFPの違い
「RFP（Request for Proposalの略で日本語訳は「提案依頼書」）」と「要求定義書」は、作成意図は同じですが、作成目的が異なります。
要求定義書は、「顧客自身がシステムに求めることを整理すること」を目的としているのに対し、RFPは、「顧客の求めるシステムを実現するのに相応しいベンダー会社を選定すること」を目的としています。
品質を高めるための開発側の心得
要求定義が失敗する要因には、要求定義の作業を行う開発側SE（システムエンジニア）の力量不足ということもありますが、大半は顧客の認識不足によって起こっています。
目的が明確でない場合やシステムへの知識不足により、要求があまりにもざっくりとし過ぎており、思いつきによる要求の抜け漏れは勿論のこと、要求同士の衝突といった内容が多分に含まれているためです。
とは言え、顧客の要求を整理してまとめるのが開発側の仕事でもありますので、まずは本当に必要な機能とそうでない機能の整理から始めます。
整理した結果、思いつきの機能と重要な機能の間に矛盾が生じることがありますが、もちろん重要な機能を優先する必要がありますので、開発側はそのことについて顧客の理解を得られるよう調整役に徹します。
その他、システム開発には開発側の常識というものが存在しますので（例えば、機密情報を取り扱うシステムを開発する場合は、厳重なセキュリティ対策を講じるなど）、仮に顧客の要求の中にそのようなものがなかったとしても、開発側にはその必要性を顧客に提案することが求められます。
このように要求定義では、顧客の要求を最大限実現する努力をしつつ、必要に応じて顧客の思いつきの要求を他の機能との矛盾という観点から要求を排除したり、顧客の要求にはないが必要とする機能や非機能があれば提案するといったことが望まれます。
顧客視点が要求定義の品質を高める
詰まるところ、要求定義で品質を高めるには「顧客視点」で考えよ、ということです。
「顧客視点」で考えるためには、新システムの導入前と導入後を想像し「顧客視点」で要求分析を行うことが重要です。
実際の進め方ですが、新システムの導入前は「マーケティングミックスの4C」、導入後は「非機能要求グレード」をフレームワークとして活用します。
| 要求分析の対象とするスコープ | 顧客視点のフレームワーク |
|---|---|
| 新システム導入前 | 4C（マーケティングミックス） |
| 新システム導入後 | 非機能要求グレード |
新システム導入前は「4C」を活用する
ステークホルダから出てくる要求の中には、自社都合に寄りがちなものも含まれています。そこで、それぞれの要求に顧客視点を当てるために4Cのフレームワークを活用して各要求を分析します。
| 4C | Customer Value | 顧客価値 |
| Cost | コスト | |
| Convenience | 利便性 | |
| Communication | コミュニケーション |
新システム導入後は「非機能要求グレード」を活用する
新システムに対する要求は、システムの仕様に対する要求に集中し、開発後の運用や保守、あるいは先々のシステムの在り方などについては盲点となっている場合が多いです。
非機能要求グレードのフレームワークとして活用することで、その盲点をケアすることが可能となりますので、システム導入後についてもしっかりとイメージし、要求として獲得、整理しておきましょう。
要求定義で定義すること
要求定義では、「業務要求」「機能要求」「非機能要求」の3つの要求を定義します。
各々で定義することと具体例を纏めると、以下のようになります。
要求定義の進め方
要求定義の進め方について、要求工学REBOKのプロセスと対比しながら説明します。
要求獲得フェーズの進め方
REBOKでいう要求獲得フェーズでは、現行業務調査を行います。調査内容は「ステークホルダの洗い出し」と「現行業務のヒアリング」ですが、ここでは現行業務のヒアリングを掘り下げていきます。
事前に確認しておくべきこと
ヒアリングという行為は、顧客とのコミュニケーションそのものです。よって事前に前提知識として顧客の情報をきちんと押さえておかないとよいヒアリング（コミュニケーション）はできません。
（誰だって自分（顧客）に興味や関心のない人とは色々と話したくないですよね）
そんなの当たり前でしょ？と思うかもしれませんが、意外と適当になっている場合が多いのが実情です。
現行業務のヒアリングでは「文書化して確認」を繰り返す
現行業務のヒアリングでは、顧客の要求をある程度明確にしていくために以下の作業を意識的に行うとよいでしょう。ポイントは「文書化→確認のサイクル」です。
- 要求は一旦文書にまとめ、矛盾や曖昧さに着目しながら明確化を試みる
- まとめた要求の中で何が本当に実現したいことなのかを確認する（MustとWantの整理）
- 外部要因や制約などは、顧客にとっては言うまでもないものと判断されて語られない可能性があるので、必ず確認するようにする
要求分析フェーズの進め方
REBOKでいう要求分析フェーズでは、「As-IsとTo-Beの業務フロー作成」と「業務分析」を行いますが、ここではポイントとなる点をピックアップして説明します。
細部にこだわり過ぎないようにする
時間をかければ全ての要求が出揃うというのは思い過ごしで、どうしても明らかにならない暗黙の要求が存在します。また工程が進み、設計段階で詳細化された仕様を顧客が見た時に気づくレベルの要求の変更が出てくる場合もあります。
よって要求分析の段階では、明らかにならない要求があることはある程度仕方がないことと割り切り、細部にこだわり過ぎないようにすることが注意点となります。
但し、できる限りの要求を見つける努力は必要で、要はそのバランスを取ることです。
役割分担を明確にしておく
要求分析は開発側だけで進めようとせず、顧客の担当者も巻き込みながら役割分担を明確にしておくと、比較的スムーズに進めることが可能となります。
顧客には業務担当者や運用担当者、またそれらを管理する部門の担当者などのステークホルダが存在し、それぞれに異なる要求を持っています。また既存の他システムと連携させる場合は、その既存システムの担当者が一番詳しいはずです。
開発側はステークホルダの特徴を捉えて、うまく役割を分担できるようにしたいものです。
把握していないアプリがないかを確認する
顧客の業務部門にはExcelやAccessのプログラミングに精通している人がいて、特定の人しか把握していないアプリを作って業務をサポートしている場合があります。
As-Is業務フローの作成段階においては、このような把握していないアプリについても確認し、もしアプリがサポートしている業務があればそれも含めて業務全体を俯瞰できるようにする必要があります。なぜならシステム化の範囲を見誤ってしまうかもしれないからです。
課題管理を実施する
要求について整理を進めていくと、次のような調査や確認が必要となる場合があります。
・ヒアリングに参加していない担当者へのヒアリング実施
・法的な要求があれば法務や顧問弁護士への確認
・既存の他システムとの連携に関する外部インターフェイス仕様調査
この対処法としては課題一覧表を用意し、課題を一覧にまとめてステークホルダ間でも共有できるようにするとよいでしょう。
業務上の時間（頻度）と量を確認する
業務や作業の実行頻度は、ソフトウェア要求のトランザクション量と関連します。また伝票数は、ソフトウェア要求のデータ量と関連し、業務における作業人数は、同時アクセス数やアカウント数と関連します。
このような頻度や量、時期やタイミングなどについては、要求として顧客から出てこないことが多いため、必ず確認するようにします。
時間・量ともに多い業務を見逃さない
業務上の時間（頻度）と量を確認することで、システム化すべき領域が見えてきます。
「確認したら時間も量も多い業務がありました」となれば、その業務は何が何でもシステム化すべき箇所ということになります。
要求定義書の書き方・まとめ方
要求定義書は、要求分析の結果から二つの側面に注意してまとめていきます。一つは開発工程間の成果物同士の関係性、もう一つは具体的にどのような内容を記載するかです。
| 要求定義書作成のポイント | 開発工程間の成果物同士の関係性 |
| 具体的にどのような内容を記載するか |
開発工程間の成果物同士の関係性
まず、開発工程間の成果物同士の関係性について説明します。
①上流工程では前工程の成果物をインプットとして段階的に詳細化すること
「作成する要求定義書は次工程の設計を実施するために必要な情報が記載されている必要がある」ということ。
②各工程での成果物間は整合性が取れていること
要求定義の本質的な難しさは②にあります。なぜなら、要求定義は開発の最初の工程で前工程の成果物がないため、要求定義の成果物としての正しさを検証する比較対象がないからです。
| 成果物同士の関係性 | ①上流工程では前工程の成果物をインプットとして段階的に詳細化すること |
| ②各工程での成果物間は整合性が取れていること |
要求定義書への記載項目
作成目的により多少異なりますが、要求定義書への記載項目については、以下にRFP（提案依頼書）の記載内容を例として挙げましたので、ご参照ください。
| 大項目 | 中項目 | 小項目 |
|---|---|---|
| 目的 | 現行業務・システムが抱える課題 | 現行業務、システムの課題を記載する |
| システム化の目的 | システム化する目的や背景を記載する | |
| 事業目標 | 事業目標に関する事項 | 事業内容について概要を記載する |
| 現状 | ビジネス概要 | 基本情報、事業内容を記載する |
| 組織概要 | 組織概要、組織図を記載する | |
| 現行業務 | 現行業務の概要 | 現行業務概要を記載する |
| 現行システム構成図 | 現行システムのシステム構成図を記載する | |
| 現行業務一覧 | 現行業務一覧を記載する | |
| 現業業務フロー | 現行業務フローを記載する | |
| 業務要求 | 業務要求に関する事項 | 事業を構成する業務内容を記載する |
| To-Be（あるべき姿）業務要求 | To-Be（あるべき姿）業務一覧業務フローを記載する | |
| 機能要求 | 機能要求に関する事項 | システム化の対象範囲において、システムに求める機能を記載する |
| 新システム構成図 | 新システム構成図を記載する | |
| 非機能要求 | 非機能要求に関する事項 | システム化の対象範囲において、システムに求める性能、冗長性、セキュリティ対策などについて記載する |
| スケジュール | 事業計画に関する事項 | 想定する事業計画についてのスケジュールを記載する |
| 提案依頼 | 提出要領 | 提出期限、提出書類、提出方法、提出場所の要領を記載する |
| 提案書類作成要領 | 提案書類の構成を記載する | |
| 委託予定事項 | 委託作業範囲・成果物 | 開発工程の作業範囲と成果物、成果物内容を記載する |
| 本番稼働時期 | 本番稼働時期を記載する | |
| 契約事項 | 開発業務に関する契約形態 | 開発ベンダーとの契約形態を記載する |
| 保守契約に関する契約形態 | 開発ベンダーとの契約形態を記載する | |
| 開発環境、作業環境、連絡手段 | 開発環境、作業環境、連絡手段を記載する |
要求定義書を成果物としてまとめる
要求定義書は、要求を分析し、その後に検証・妥当性確認・評価した結果を上図（上図はRFP）に示した項目ごとに整理し成果物としてまとめていきます。その際にポイントとなる部分を以下に列挙いたします。
| 成果物として整理する際のポイント | 定義した要求には新業務実現に向けた優先度を明確にする |
| 新業務を実現するために必要となる「機能要求」を抜け漏れなく定義する | |
| システムの運用面や保守面も考慮した「非機能要求」を定義する |
要求定義書は作成後も管理を怠らない
要求定義書の作成をなんとか無事に終えシステム開発が本格化したのちに、後からその組織の暗黙知が顕在化して要求が追加となったり、「要求した内容を少し変えてほしい」といった変更の要求が出てくる場合がままあります。
このような要求定義後の要求の追加・変更は常に起こりがちなことなのですが、実際に追加や変更内容を要求定義書に反映できているプロジェクトは一握りです。
（変更管理の必要性は全ての成果物に対して言えることで、要求定義書も例外ではありません）
要求定義書は、顧客が検収時に行う受入テストのインプット資料にもなるため、もし要求定義書が追加や変更に対応していなければ、その受入テストの根拠が不明瞭となり評価ができなくなります。また状況によってはトラブルに発展することもあるでしょう。
このようなことから、要求定義書は作成後も要求に追加や変更があれば、その都度必ず変更管理を行うことが重要です。
ご質問・ご要望
弊社、株式会社QualityCubeでは、「要求定義代行サービス」を提供しています。
コンサルタント利用は効率面でのメリットだけでなく、教授したナレッジは成功法則として継承していけることより、企業の資産となります。
依頼には費用が発生しますが、中長期的には費用対効果が実感できるはずです。
DX推進等の一助としてできるだけ早い段階で導入を検討されることをおすすめいたします。
より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。
- 要求定義をした経験がなく、問題なく作成できるか不安
- 要求定義項目の抜け漏れをチェックする方法を探している
- 要求定義ができる有識者が少ないため、作業が難航している
- 外注を検討しているが、どこに外注したらよいかの決め手がない
