自社の求めるシステム開発を行うに当たって最も重要な工程となるのが、自社の求めているものを明確に定義し、開発者と顧客の間で認識を共有する要件定義工程です。
明確な要件定義ができていなければ、どれだけ手を尽くしても最後には「無用の長物」が出来上がります。
時間をかけて要件定義を行うことは、最初は無駄に手間と時間がかかるように感じられるかもしれませんが、その後の効率的でスムーズなプロジェクト進行と開発成功につながります。
この記事ではRD（要件定義）の基本や、システム構築におけるRD工程の重要性について解説します。
RD（要件定義）とは？
要件定義は、システムやソフトウェアの開発プロジェクトにおいて、
- 顧客や利用者の期待や要望を明確かつ具体的に把握し
- それを基にシステムの機能や性能、制約条件などを整理・分析し
- 簡潔な要件定義を文書としてまとめる
というプロジェクトのはじめに行う最重要プロセスです。
この要件定義書はプロジェクトの出発点となり、開発チームや顧客とのコミュニケーションの基盤となります。
RD（要件定義）の意味
要件定義（Requirements Definition）とは、システム開発において最も最初に行われる「顧客の要望や求める潜在ニーズを明確化する」プロセスです。
頭文字をとり、RDとも呼ばれます。
RD工程では、システムに必要な機能や制約条件、必要な性能などを「要件」として明確に定義し、要件定義書にまとめます。
要件定義書についてより詳しく知りたい方は、下記のページを参照ください。
RDはシステム開発工程で重要
RD工程で作成した要件定義書はプロジェクトの出発点であり、様々なトラブルが起こる「システム開発」という大海を渡るための道標と言えます。
開発チームと顧客との間のコミュニケーション基盤となり、様々な認識確認や提案の前提が要件定義書を土台にして行われます。
すべての土台として扱われるRDが適切に行われたかが、システム開発の成功に直結します。
適切に作られた要件定義書には、以下のような重要なメリットが存在します。
- 顧客の要望を文書として明確化する
- 開発チームは超能力者ではないため、顧客の要望を「空気を読んで読み取る」なんてことはできません。
- 逆に顧客も「ITシステムで何ができるのか」を知らないため、最初から適切な要望を伝えることは難しいです。
- RD工程を通して、顧客の悩みや要望について理解を深め、必要とされている機能を把握することができます。
- RDは双方の誤解や認識のすれ違いをなくし、開発が円滑に進む基盤を築きます。
- 開発チームの共通理解を促進する
- 開発自体も様々な人が関わるため、お互いの誤解やケアレスミスによるトラブルが絶えません。
- そこで、プロジェクトの目標や要件を共有し、理解することが非常に重要となります。
- 要件定義文書はそのための道標となり、開発者やテスター、デザイナーや営業担当など異なる役割を持つメンバーが共通の理解を持つための手段となります。
- 変更や規模、適用範囲の管理
- 要件定義が明確であれば、開発段階で起こるトラブルや課題、顧客からの要望の変化に対して問題の切り分けが迅速に行なえます。
- 影響するスコープが明確になるため、プロジェクトが脱線するリスクを防ぎ、方針転換などによる影響範囲を正確に把握できます。
- 開発効率化と品質の向上
- RDの段階で問題や実装範囲、顧客の頭の中にある「本当に必要としているもの」を明確にできれば、開発工程で起きるトラブルを予防することができます。
- 開発に入る前段階でトラブルを回避できることで、プロジェクト全体が効率的に進行し、追加作業や寄り道を減らすことができます。
- つまり、そこにかかる無駄なコストや超過スケジュールを防ぎ、品質を向上させることができます。
RD（要件定義）のフェーズとプロセス
RDの一般的な手法では
- 現状分析
- 要件収集
- 要件分析
- 要件定義書の作成
の4つのフェーズを経て要件を定義します。
各フェーズについて注意点を含めて詳しく紹介します。
現状分析
このフェーズでは、現在の業務プロセスや既存システムを詳細に調査し、課題を明確に洗い出します。
現状分析における「詳細な調査」は、
- 現行のシステムや業務プロセスについての理解を深める
- 利用者や関係者がどのように影響し合うのかを確認する
- ステークホルダーへのミーティングやヒアリングを行います。
- また、実際にシステムに関わる従業員や外部協力者、場合によっては市場の一般ユーザーからのフィードバックを得ることも重要です。
- 問題点や課題を特定し、さらなる要望を引き出し、要望の全体像を把握する
といった作業になります。
その際には注意事項として、特に以下のことについては気を配るべきです。
- 情報収集は慎重に行い、現状の詳細に把握すること
- 現状の理解や深掘りが不足していると、その後どれだけ精細に開発しようと、新規システムが適切に機能しないリスクが高まります。
- 利用者や関係者との密なコミュニケーション方法を模索し、確保すること
- 言葉にならないノウハウや、漠然とした苦情、システムに対する期待値や要望を正確に理解するために、コミュニケーションは密に取る必要があります。
要件収集
現状分析の結果を踏まえ、必要な機能や要求、制約条件を収集し、優先順位をつけて整理します。
このフェーズでは、顧客とのコミュニケーションが欠かせません。
そのため現状分析で培った「密なコミュニケーション」を実際に活かすフェーズとも言えます。
具体的には
- 要件を利用者や関係者からのヒアリングやワークショップを通じて収集する
- 実際に業務が行われている現場に赴く場合もあります。
- アンケートやインタビューといった方法で、様々な角度からの意見を収集する場合もあります。
- 業務に関わるドキュメントを整理し、既存資料のレビューを行う
- 要件に優先順位や重要度といった定量的評価基準をつけ、整理する
といった作業になります。
その際には注意事項として、特に以下のことについては気を配るべきです。
- 確実性を高めるために複数の情報源を活用し、多角的に要件を検証すること
- 積極的な対話で隠れたニーズや要件を更に引き出すこと
- スケジュールに間に合うように、要件は常に優先順位を確認し、重要な要件は重点的に調べること
要件分析
このフェーズでは、収集した要件を更に整理し、実現可能性や情報の不足について検討します。
要件変更が行える最終フェーズでもあるため、十分に時間を取って情報の過不足や要件同士の矛盾を洗い出しましょう。
具体的には、
- 収集した要件について分析し、重複や矛盾、制約条件に反した要望がないか整理し、場合によっては要件を変更する
- 要件ごとに関連性を評価し、更に細かい優先順位をつけ、実装機能や資料と紐付ける
- ビジネスルールや業務プロセスと要件自体を関連づけ、すべての要件がどの業務プロセスに関わるのか全体像を把握する
- 開発チームで課題を共有するためにフローチャートなどを使い全体像を図示することも多いです。
といった作業を行います。
その際には注意事項として、特に以下のことについては気を配るべきです。
- 要件の実現可能性を注意深く検討すること
- この時点で更に関係者と対話し、要件を変更することもよくあります。
- また複雑な要件に関しては入念な技術検証を行い、開発中のトラブルをなるべく避けるように努力しましょう。
- 要求同士の関連性を整理し、矛盾点や情報の過不足は可能な限り洗い出すこと
- 必要な情報を補完し、関連するプロセスを明確に区分けすることで開発中の混乱を防げます。
- 要件変更の際には、プロジェクト全体や他の要件について影響範囲を考慮すること
要件定義書の作成
全ての要件について分析が終わり、関係性や実現性などが整理できたあとは、それを誰にでも理解できる明確な文書や図形に起こし共有します。
具体的には、
- 整理した要件を明確に文章と図に表し、要件定義書を作成する
- 要件の種類を明確に区別し、文章化しましょう。
- 機能要件
- 非機能要件
- 制約条件
- など
- 要件の種類を明確に区別し、文章化しましょう。
- 作成した要件文書を関係者に共有し、レビューやフィードバックを取り入れる
- お互いに誤解や認識違いがないか最終確認を行う
といった作業を行います。
その際には注意事項として、特に以下のことについては気を配るべきです。
- 要件文書は明確で一貫性がある文書にすること
- 要件文書は誤解を生じないように、わかりやすく端的に記述します。
- 誰が見ても同じ認識になるように、一貫性を意識しましょう。
- 文書の作成・変更履歴を記録しておき、好きなタイミングでどのバージョンかを追跡・確認できるように管理すること
RD（要件定義）の成功事例と失敗事例
システム開発の成功事例や過去の失敗から、多くの教訓を得ることができます。
そして、システム開発においてRDはプロジェクトの成功に直結する鍵となる重要な要素です。
RDについて、いくつかの成功事例や、代表的な教訓を紹介します。
RD（要件定義）が成功した事例
RDの特異な事例として、トヨタとサントリーの事例を紹介します。
トヨタシステムズのデータ駆動型カイゼンアプローチ
トヨタ自動車は従来のムダを排除したカイゼン計画の一環として従来の
- 不要な機能を廃止する
- 重複している機能は統合する
といったアプローチに限界を感じていました。
そこで、トヨタシステムズによるRDの結果、顧客のシステム作業証跡のデータを活用した「データ駆動型」のアプローチを発見
「システム作業証跡のカイゼン」という新たな要件を発見したことで、従来手法では見つからなかった598個の検討課題を発見し、約45%のシステムスリム化に成功しました。
サントリーシステムテクノロジーのリザルトチェーン
サントリーシステムテクノロジーは企業のDX化やAI活用に向けて、RD工程へ「リザルトチェーン」という考え方を導入しました。
現代ビジネスにおけるITシステム導入やDX化は、前提となる知識に複雑なものが多く、顧客との合意形成が難しい事が増えました。
そこで、要件定義の段階でより深く認識共有するために、
「まずは前提条件や施策、効果の因果関係を可視化・抽象化しながら合意形成し、そのうえで具体的な手段を検討し合意する」という、よりRDを重視した開発プロセス「リザルトチェーン」を発明しました。
これにより多くのプロジェクトで、顧客の理解を得ながら複雑な業務プロセスのDX化が達成できるようになりました。
徹底した「事業部門との対話」と「予測精度と期待値の定量化」─サントリーのAI推進リーダーが語る秘訣 | IT Leaders (impress.co.jp)
失敗した要件定義の教訓
いくつかの要件定義にまつわる教訓を紹介します。
- 要件の収集や整理の時間に時間をかけないと、かえってプロジェクトの遅れを招く
- RDにかける時間を短縮するために顧客の要望が不明瞭なまま進めると、開発チームと顧客の間で誤解が生じたまま開発が進み、品質と信頼性の低下を招きます。
- 要件定義に失敗すると、プロジェクトが遅れ、原因の分からないリテイクが何度も発生し、予算超過や品質低下などの問題が発生します。
- 要件定義のプロセスを改善し、ユーザーとのコミュニケーションと分析に時間を割くことで、かえってプロジェクトの品質向上や開発期間の短縮につながります。
- コミュニケーション不足はプロジェクト自体の失敗に直結する
- RD工程において重要なのは
- 顧客との密なコミュニケーション
- 定義された要件の明確さ
- の2つです。
- お互いの認識を共有し、顧客にも要件や機能の重要性を理解して貰う必要があります。
- コミュニケーションを怠ると、ユーザーが言語化できないニーズを見落とし、信頼を大きく損ねます。
- また明確なコミュニケーションを行うためにも、要件を記述する際には明確な定義を心がけましょう。
- 要件を明確にしづらい場合は、より顧客との対話や開発修正タイミングが頻繁に行えるアジャイル開発手法なども検討すべきです。
- RD工程において重要なのは
- わかりやすく正確な要件定義書を作成する
- 要求定義書がわかりやすく正確でなければ、顧客は「なぜその機能が必要で、スケジュールや予算が必要なのか」を理解できません
- 不正確な要件定義は不正確な見積もりによる予算超過や、仕様を固められず見切り発車するような杜撰なスケジュールにつながります。
- 顧客の理解できない要件定義書を作ってしまうと、契約の合意さえ覚束なくなります。
- 明確な優先順位付けが不足すると、無駄なコストが膨れ上がる
- 要件収集の際にユーザーは実現性や優先度を度外視して、思いついたままに要望を並べることが多いです。
- また基本的に「本当に必要なもの」を理解できている顧客はいません。
- そのため、全ての要望に対応しているとコストやスケジュールが圧迫されいつまでも製品が完成しません。
- 集めた要件に明確な優先順位をつけ、重要なものから取り組むことでコストの圧迫やスケジュール超過のリスクを回避することができます。
中小企業におけるRD（要件定義）の成功ポイント
RDを重視し、顧客とのコミュニケーション時間を手厚く取ることがRD成功の鍵と紹介しましたが、現実の開発で使えるリソースは限られています。
スケジュールや予算が限られている中で、うまくRDを完遂するためのポイントを紹介します。
限定的なリソース環境での要件定義のやり方
リソースが限定されている環境でのRDでは、厳密なリソース配分を行うために、より迅速で効率的な情報整理が求められます。
- 要件の優先順位付けと優先順位の明確化
- リソースが限られている場合は、最も重要な関係者からの要件取得を優先します。
- 要件の優先付けや整理を初期から行い、核となる機能だけでも先に確定させましょう。
- 揺るぎない要件を定めることで、効率的に全体像を定めることができます。
- また、要件の優先順位と取捨選択を行う際には、バックログを作成しておくと、追加リソースが確保できた際に素早く取り組むことができます。
- 頻繁なコミュニケーションと簡潔なドキュメントを重視する
- リソースが限られているからこそ、手戻りを防ぐために顧客との手厚いコミュニケーションを重視しましょう。
- またドキュメントから冗長な表現を省き、可能な限り簡潔に記述することで、無駄な議論を防ぎ、要点を抑えた開発を行えます。
- MVPやプロトタイピングの導入
- 開発の初期にMVPやプロトタイプを作成し、要件収集がより早期から実施できます。
- 迅速な要件収集によって、誤解や情報漏れを早期に発見しやすくなります。
- 最小限の機能開発にリソースを集中し、段階的に拡張していくことで、効率的にリソースを配分できます。
- 共通言語の確立
- リソースが限られているが、関係者が多いプロジェクトでは、いち早い共通言語の確立が求められます。
- 持っている知識も求める要望も違う関係者間で、可能な限り共通の用語や言葉を使うことで、双方の認識のズレを防ぎ、コミュニケーションを円滑にできます。
小規模プロジェクトでの要件定義のコツ
小規模プロジェクトのRDでは、小規模だからこそ気をつけるべき事柄があります。
特に一見全体を把握しやすく見えるため、「作り始めたほうが分かりやすい」と見切り発車しやすく、影響範囲や要件の定義を疎かにしがちです。
ですが要件定義工程は、規模の大小に関わらずプロジェクトの成功を左右します。
小規模プロジェクトでは、例えば以下のような注意点があります。
- ステークホルダーの特定と整理
- プロジェクトに関わる主要な関係者を洗い出し、その要望や抱えている課題を最初期に整理するべきです。
- 可能な限り要望を簡潔に纏まめることで、より開発が効率的に行えます。
- 明確な責任者を決めること
- 小規模開発では、リーダーのもとで一丸となれる緊密なチームワークが求められます。
- 明確に責任者や旗振り役を定めておくことで、一貫性のある開発プロセスが行なえます。
- 適切なツールの活用
- 小規模プロジェクトに合った適切なツールを使用しましょう。
- プロジェクトの規模に合わない高性能ツールはかえって開発を妨げる原因になります。
定期的に要件定義を見直す
国際情勢や顧客の要件の変更、技術検証の結果によって、しばしばプロジェクトの変更を余儀なくされることがあります。
そのため、RD自体も「要件定義書が現在のプロジェクト目標と一致しているのか」を見直す必要があるということです。
また、RDの見直しを行うことで
- 現在のプロジェクトの目的と要件定義書が一致しているかの確認
- システム開発の過程で、プロジェクトの目的から脱線している要件はないかという洗い出し
- プロジェクトの目的や優先順位の再確認
- 定期的な要望収集により、顧客やユーザーとのコミュニケーションの向上
- プロジェクトの進行状況の再確認と、スケジュールや予算の再調整
が行なえます。
最初期に決めたRDを遵守するのではなく、柔軟に再修正を行える体制は現代のビジネスに不可欠です。
別のページで要件定義書についても解説していますので、参考にしてみてください。
まとめ – RDをしっかりしてシステム開発を効果的に進めましょう
RD（要件定義）工程は、システム開発の最初に行われる最も重要なプロセスです。
顧客が求めている要望を適切に整理し、本当に必要な機能や実現可能性を検討し、プロジェクトの目標を明確にします。
RDが明確に定まっていれば、プロジェクトはスムーズに進み、開発トラブルや予算超過を防止できます。
また、多くのコミュニケーションを必要とするため、顧客からの信頼度が向上し、次回のリピート営業にも繋げられます。
とはいえ、システムの「要件」を明確にするというのは豊富な実績に裏打ちされた知識や技術が必要となります。
その要件をどのような形で実現するのかといったノウハウや要望の洗い出しには、やはり経験豊富なエンジニアに頼る方がより効率よく行えます。
株式会社Jiteraでは、豊富な国内実績を背景とした手厚いIT技術支援を行っています。
業務システム導入やアプリ開発の選定にお悩みの際は、ぜひ株式会社Jiteraに一度ご相談ください。
メールマガジン登録
