LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守を受託

上流工程の全体像：企画から要件定義、基本設計までの流れ

システム開発は、企画・要求定義・要件定義・基本設計・詳細設計・開発・テスト・運用という工程を経て進みます。このうち「要求定義」と「要件定義」は名称が似ているため、発注側の担当者でも役割の違いを曖昧にしたまま打ち合わせに臨んでしまうケースが少なくありません。

本記事は、要求定義と要件定義の違いと、それぞれが上流工程のどこに位置づけられるかという点に主題を絞って整理します。基本設計・詳細設計で検討する具体的な設計内容や、工数見積りの算出方法は扱う工程が異なるため、本記事では取り上げません。

なお、この二つの工程をどこで区切るかは、組織や案件によって幅があります。企画と要求定義をまとめて一つの工程として扱う企業もあれば、要件定義をさらに「業務要件定義」と「システム要件定義」に細分化して進める企業もあります。呼び方や粒度に差があること自体は珍しくないため、まずは自社やプロジェクトの体制がどちらの整理を採用しているかを確認しておくことが実務上のつまずきを避ける第一歩になるでしょう。

IPAが公表する共通フレーム2013は、ソフトウェア・システムの構想から開発、運用、保守、廃棄に至るライフサイクル全体の工程と役割を包括的に規定した枠組みです。同フレームの要件定義プロセスには、要求定義の国際規格であるISO/IEC/IEEE 29148の考え方が取り入れられており、要件定義を独立した工程として位置づける重要性が示されています^*1。組織や案件によって工程の呼び方や区切り方には幅がありますが、一般に「要求定義が先、要件定義が後」という順序で捉えられることが多いといえるでしょう。

要求定義とは何か：発注者側が「何をしたいか」を整理する工程

一般に要求定義とは、システムを利用する事業部門や情報システム部門といった発注者側が、自社の経営課題や業務上のニーズを踏まえて「何を実現したいか」を言語化する工程を指します。この段階ではまだシステムの技術的な仕様には踏み込まず、業務の目的やあるべき姿を整理することが中心になります。

要求定義で行う代表的な作業には、次のようなものが挙げられます。

• 現状業務の棚卸しとヒアリング（担当部門ごとの業務フローや課題の整理）
• 解決したい経営課題・業務課題の言語化（なぜ実現したいのかという背景の整理）
• 実現したいことの優先順位づけ（必須事項と将来検討事項の切り分け）
• 費用対効果や実現可能性の大まかな検討

成果物としては、要求仕様書や業務フロー図、提案依頼書（RFP）などが挙げられます。担当は発注者側が主体となりますが、社内に上流工程の経験者が少ない場合は、外部の専門家がヒアリングを支援する形で関与することもあります。ここで整理された要求が曖昧なままだと、次の要件定義工程に持ち込まれる情報も曖昧になってしまう点に注意が必要です。

特に注意したいのは、要求定義の段階ではまだ「システムでどう実現するか」という技術的な手段を決め切らないという点です。この段階で早々に画面イメージや機能一覧まで固めてしまうと、要件定義の工程で技術的な制約と突き合わせた際に、要求そのものを見直す手戻りが発生しやすくなります。要求定義では、あくまで目的・課題・優先順位を整理することに軸足を置くとよいでしょう。

要件定義とは何か：システムが満たすべき条件を定義する工程

要件定義とは、要求定義で整理された要求を実現するために、「システムが満たすべき条件」を具体的に定義する工程です。一般に要件定義は、システムが持つべき機能を定める「機能要件」と、性能・可用性・セキュリティといった品質面の条件を定める「非機能要件」の二つに分けて整理されます。

非機能要件は発注者と開発側で認識がずれやすい領域として知られています。IPAが公表する非機能要求グレードの紹介資料では、性能・信頼性・セキュリティなどのシステム特性について、利用者側と開発側の間で認識のずれや解釈の相違が生じやすいという課題が示されており、これを解消するための項目一覧とレベル分けの仕組みが整理されています^*2。非機能要求グレードでは、非機能要件を大きく次の六つの区分で捉えています^*2。

• 可用性（稼働率やサービス停止時の復旧方針など）
• 性能・拡張性（処理量やレスポンス時間、将来の利用増加への対応など）
• 運用・保守性（監視体制やメンテナンス方法など）
• 移行性（現行システムからの切り替え方法など）
• セキュリティ（アクセス制御やデータ保護の水準など）
• 環境・エコロジー（設置環境や省電力性など）

要件定義書のレビューでは、機能要件だけでなく、これらの非機能要件の区分についても具体的な項目として確認しておくことが望ましいでしょう。すべての区分を高い水準で満たそうとすると開発コストが膨らむため、自社の業務にとって重要度の高い区分から優先的に水準をすり合わせる形が現実的です。

要求定義と要件定義の違い：担当・目的・成果物を比較する

要求定義と要件定義は、上流工程における担当・目的・成果物のいずれの観点でも役割が異なります。次の表に主な違いを整理しました。

この比較からわかるとおり、要求定義は目的や課題を扱う工程、要件定義はその目的を満たすための具体的な条件を扱う工程という違いがあります。どちらか一方だけを丁寧に行っても、もう一方が曖昧なままでは上流工程全体としては機能しません。両工程をセットで捉えることが大切です。

曖昧なまま進めた場合に起きやすい失敗：手戻りとスコープ膨張

要求定義と要件定義の境界が曖昧なまま上流工程を進めると、いくつかの典型的な失敗につながりやすくなります。第一に挙げられるのが手戻りです。要求定義の段階で「なぜそれを実現したいのか」という目的まで整理しきれていないと、要件定義や基本設計が進んだ後になって「イメージと違う」という指摘が発注者側から出て、工程を巻き戻さざるを得なくなる場合があります。

第二に、スコープ膨張という問題も起きやすくなります。要求が明文化されないまま要件定義に入ると、関係者ごとに解釈が異なる状態で作業が進み、後から機能追加の要望が積み重なっていくことも少なくありません。当初の予算・納期を前提に契約している場合、こうしたスコープの拡大は追加費用や納期遅延の原因になりかねない点に注意が必要です。非機能要件の合意が不十分なケースでも、同様の問題が起こり得ます。性能やセキュリティの水準を具体的な項目として確認していないと、リリース直前や運用開始後になって想定と異なる仕様が発覚することもあるでしょう^*2。

実務で起きやすい失敗の具体例を整理すると、次のようなパターンが挙げられます。

• 要求定義で目的を言語化しないまま要件定義に進み、開発途中で「本来やりたかったこと」に気づいて仕様が変わる
• 要件定義書に機能要件しか記載されておらず、性能やセキュリティの水準が未確認のまま契約する
• 発注者側の複数部門が別々に要望を出し、優先順位が整理されないまま要件が積み上がる
• 要件定義書のレビューを開発側だけで完結させてしまい、発注者側の最終確認が形式的になる

これらはいずれも、要求定義と要件定義のどちらか一方、あるいは両方の整理が不十分なまま次工程に進んでしまうことが原因になりやすい失敗です。工程を分けて考えること自体が、こうした失敗を未然に防ぐ手がかりになります。

発注側が押さえておきたい勘所と体制の選択肢

発注側が上流工程で押さえておきたい勘所は、大きく二つに整理できます。一つ目は、要求定義の段階で「何をしたいか」だけでなく「なぜそれをしたいか」まで言語化しておくことです。目的が共有されていれば、要件定義以降で判断に迷う場面でも、当初の目的に立ち返って優先順位を判断しやすくなります。二つ目は、要件定義書のレビュー時に機能要件だけでなく非機能要件も具体的な項目として確認する姿勢です。

要件定義書のレビュー時に発注側が確認しておきたい項目は、たとえば次のとおりです。

• 要求定義で整理した目的・課題が、要件定義書のどの機能要件に対応しているか
• 可用性・性能・セキュリティなど、非機能要件の区分ごとに水準が具体的に記載されているか
• 優先度の高い要件と、将来対応でよい要件が区別されているか
• 要件定義書の内容について、関係部門の合意が取れているか

体制の面では、社内に上流工程の経験者が十分にいない企業も少なくありません。その場合の選択肢としては、社内の情報システム部門が主導して事業部門を巻き込みながら整理する体制、プロジェクトごとに専任の担当者を置く体制、そして要求定義・要件定義の整理そのものを専門パートナーに依頼する体制などが考えられます。どの体制を選ぶ場合でも、要求（何を実現したいか）を整理する主体はあくまで発注者側であるべきで、外部パートナーはヒアリングや資料化を支援する立場として関わる形が望ましいでしょう。

要件定義以降を委託する場合も、要求定義で整理した目的や優先順位を発注者側が説明できる状態にしておくことが、後工程の手戻りを防ぐ土台になります。逆に言えば、要求定義さえ丁寧に整理できていれば、要件定義以降を外部の体制に任せる場合でも、認識のずれは大きく減らせるはずです。

まとめ：要求定義と要件定義は「役割」が違う

本記事では、要求定義と要件定義の違いを、上流工程における位置づけとあわせて整理しました。要点は次の三つに集約できるでしょう。第一に、要求定義は発注者側が「何をしたいか」を整理する工程であり、要件定義はその要求を実現するために「システムが満たすべき条件」を定義する工程です。両者は担当・目的・成果物のいずれの観点でも役割が異なります。

第二に、この境界が曖昧なまま進めると、開発着手後の手戻りやスコープ膨張につながりやすくなります。第三に、発注側は要求定義の段階で目的まで言語化し、要件定義書では機能要件・非機能要件の双方を確認することが、トラブルを防ぐ勘所になります。社内に経験者が少ない場合は、専門パートナーへの相談も一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA「SEC BOOKS：共通フレーム2013」（https://www.ipa.go.jp/publish/secbooks20130304.html）
2. *2　出典：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）

Tweet