システム開発における開発工程の一部である要件定義について具体的にどのようなことをしているのか。よく比較されがちな基本設計や詳細設計と何が違うのか。
その辺りも含めて本記事では解説していきたいと思います。
目次 [非表示]
1.要件定義とは？
システム開発の一連の流れの中で一番上に位置する（最初にやること）要件定義。ここで手を抜くとシステム開発はだいたいは失敗します。そんな要件定義について1章では概要を説明します。
1-1.要件定義は、クライアントの要望をまとめること
要件定義は、クライアントが作りたいシステムがどんなものかヒアリングして、要件定義書という形でドキュメント化する工程になります。
※要件定義書については、2章以降で詳しく解説いたします。
要件定義で、クライアントが欲しいシステム要件をまとめることになるので、ここで曖昧な状態で進めると、最後出来上がった時に「思っていたモノと違う」というトラブルになりかねません。そのような時は再度システム開発をすることになり、多額の不要な費用が発生しかねません。このようなトラブルを回避するためにも要件定義はかなり重要なフェーズです。
1-2.要件定義は、上流工程に位置する
要件定義は上流工程の中でも上流に位置するフェーズになります。上流の中の上流、システム開発における王様的な存在です。
※水の流れのように開発が進んでいくので、「上流」と呼んでいます。逆にテスト工程は「下流」と呼びます。
要件定義ではこんなことを決めてまとめていきます…
- 全体のスケジュール（何をいつまでに終わらせるか）
- 全体で掛けることができる予算
- 開発手法
- リリースする方法
- リリース後の運用方法 など…
システム開発は要件定義で決めた内容に沿って大枠は進んでいくので決裁権のある人たちも含めて話し合いを重ねていきます。クライアント側×開発側でプロジェクトマネージャー, プロジェクトリーダーを交えて決めていきます。
各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。
| 工程 | 略称 | 英語 |
|---|---|---|
| 要件定義 | RD | Requirement Definition |
| 基本設計 | BD | Basic Design |
| 詳細設計 | DD | Detail Design |
| 単体テスト | UT | Unit Test |
| 結合テスト | IT | Integration Test |
| システムテスト | ST | System Test |
| 運用テスト | OT | Operation Test |
1-3.基本設計や詳細設計との違い
良く比較されるのが、基本設計と詳細設計の違いです。簡単に表にまとめると以下の通りです。
| 名称 | 工程 | 対象 | 内容 | |
|---|---|---|---|---|
| 要件定義 | 最上流 | WHY （なぜ作るのか） | クライアント向け | システム導入する背景・課題、システム全般の概要 |
| 基本設計 | 要件定義の次 | WHAT （何を作るのか） | クライアント向け | システムの各機能、画面イメージ等具体化したもの |
| 詳細設計 | 基本設計の次 | HOW （どうやって作るのか） | 開発者向け | 基本設計を開発者向けにアレンジしたもの |
要件定義は最上流に位置するもので、クライアントから課題やどんなシステムを開発したいのか隅々まで確認することになります。その情報をもとに基本設計以降の工程に入るので、要件定義の時点で齟齬があれば完成品が思ったものと違うものができてしまいます。
2.要件定義書の進め方
2章からは実際に要件定義書を作成するために必要な情報を紹介していきます。まずは要件定義書をどうやって作り進めていけば良いか紹介します。
2-1.現状の課題分析
クライアントからどんな課題を持って、今回システム開発をすることになったのか確認します。ここでは、クライアントから良くいただく課題を紹介します。
＜よくある課題＞
- 手作業が多く、非効率である
- ヒューマンエラーが多いので防ぎたい
- 情報を一元化したい
- 既存システムが古いので刷新したい
- 既存システムでは不足している機能が多すぎる
2-2.システムの開発目的
課題が見えてきたら次にその課題を解決するためにどんなシステムがあったら解決できるか精査していきます。クライアントが気づいていない課題が潜んでいる可能性もあるので、隠れた課題を見つけ出すことも重要です。いわゆるコンサルティング的なことをしていきます。
2-3.システムで実現可能性を精査
続いて、そのシステム開発がどこまで実現可能性があるか精査します。機能が多ければ多いほど費用も増え、時間も掛かるので必須機能、希望機能を洗い出す必要があります。優先順位を決めて、リリース後に希望機能は付け足していく等…進め方は様々あります。クライアントに今回の予算と納期を確認して良い塩梅を探っていきます。
2-4.機能要件を整理
必須機能、希望機能までまとまったら、クライアントの要求を「業務要件」「機能要件」「非機能要件」の3つに分けて整理していきます。
業務要件：目的を達成するために必要な機能や条件をまとめたもの
機能要件：業務要件の中でシステム化することで何が実現できるのかまとめたもの
非機能要件：業務要件の中でシステム化以外で必要な要件をまとめたもの
2-5.予算・体制・スケジュールを設定
最後にここまで整理してきた内容に対して、「いくら掛けて」、「どのような体制」で、「いつまで」に、を決めます。無理な予算、無理な体制、無理なスケジュールでは失敗に繋がりかねません。現実的な計画を立てるようにしましょう。
決まった内容をドキュメントとして残す必要があります。それが要件定義書と呼ばれる代物です。要件定義書の書き方については、3章でまとめています。何か決められたフォーマットがあるわけではないので、自分がまとめやすいにまとめていきましょう。
3.要件定義書に記載すべき項目
3章では要件定義書の中身について踏み込んで紹介していきます。要件定義書は書く人によって内容等が変わりますが、3章で記載している内容は最低限入れるように心がけましょう。
3-1.プロジェクトの概要
まずは与件の整理から入ります。今回のプロジェクトでシステム化することにより、何を実現することができるのか、開発の目的と背景を記載します。関係者の共通認識がずれないようにシステム全体の概略図や、今回のプロジェクトで使われる用語・略語等の定義をまとめたりもします。
＜入れる内容（例）＞
- システム化の目的／背景
- システム化しないといけない課題
- システム全体の概略図
- プロジェクトのオリジナル用語／略語の定義
3-2.システム導入後の姿
続いて、現在の業務が今回のシステムが導入されることでどのような姿になるか理想郷を入れます。システムがある場合／ない場合で、何がどう便利になるのかまとめます。まとめるにあたり、今課題になっているものを一覧化すると分かりやすいです。
＜入れる内容（例）＞
- 業務要件一覧／フロー図
- 業務の規模
- 業務の時間や時期
- 業務の場所
- 業務の範囲（どの範囲をシステム化するか）
- システム化する前と後の変化
3-3.機能要件を整理
ここでは、システムで具体的にどのような機能が必要になるか画面のイメージを含めて整理していくことになります。ここで、抜け漏れがあると本当はこの機能必要だったのに、、という事態が起きるので時間を掛けて練っていく必要があります。
＜入れる内容（例）＞
- システムに必要な機能一覧
- 各機能の役割や画面イメージ
- システムに蓄積されたデータの取り扱い／処理方法
- API連携（外部システムとの連携）
3-4.見えない部分の機能を整理
3-3では表側を整理しましたが、続いて裏側（ユーザーから見えない部分）を整理することになります。裏側だからといって手を抜いてはいけません。ユーザーがストレスなくシステムを使うためには裏側が重要になってきます。
＜入れる内容（例）＞
- 想定されるユーザー規模数（同時接続数）
- 処理速度や閾値等の必要最低限の性能
- バックアップの性能
- 将来的な拡張性
- セキュリティレベル
- リリース前のテストの種類と方法
- リリース後の保守・運用体制／内容（いつまで継続していくか）
4.要件定義で失敗するとどうなる？
システム開発において、要件定義はプロジェクト全体の方向性を決める重要な工程です。この段階で認識のズレや要件の整理不足があると、その後の設計・開発・テスト工程にも大きな影響を及ぼします。
4-1.想定していたシステムにならない
要件定義が不十分な場合、
- 現場が求めている機能が不足している
- 使いづらい画面になっている
- 想定していた業務フローを実現できない
といった問題が発生することがあります。開発完了後に問題が発覚すると、大幅な改修が必要になるケースも少なくありません。
4-2.開発コストが増加する
開発途中やリリース直前に仕様変更が発生すると、追加開発費用が必要になります。
特に要件定義後の仕様変更は、設計やプログラム修正だけでなくテストのやり直しも伴うため、想定以上にコストが膨らむ原因となります。
4-3.スケジュールが遅延する
要件が曖昧なまま開発を進めると、途中で認識のズレが発覚し、手戻りが発生します。その結果、
- 開発期間の長期化
- リリース延期
- 社内調整の増加
など、プロジェクト全体への影響が広がる可能性があります。
4-4.現場に定着しないシステムになる
システム開発の目標は、システムを作ることではなく業務課題を解決することです。
しかし、要件定義で業務課題を十分に整理できていないと、完成したシステムが現場で活用されず、期待した効果を得られない場合があります。要件定義では、「どのような機能が必要か」だけでなく、「なぜシステム化するのか」「どのような課題を解決したいのか」を明確にすることが重要です。
5.要件定義で失敗を避けるためのポイント
ここまで要件定義の流れと記載すべき内容をまとめてきました。4章では要件定義において、失敗を避けるために何を注意したら良いか紹介していきます。
5-1.クライアントの要望を隅々まで確認する
クライアントが作りたいシステムを納品しないと意味がありません。クライアントが気づいていないところ（決めないといけないところ）もあるかもしれません、ヒアリング側が積極的に引き出しを開けに行くようにしましょう。
5-2.専門用語少なめで、コミュニケーションを取る
クライアントが非IT系の会社の場合もあります。その際は、IT業界用語を連発してしまうと齟齬が生じる可能性が高いです。IT知識がない人でも伝わるような一般的な言葉でコミュニケーションを取るようにしましょう。
5-3.WBSを活用してスケジュール管理
WBSを活用してスケジュールとタスク管理、そのタスクは誰がやるのかを管理するようにしましょう。曖昧なママ進めると、なあなあになりがちなので、ある程度のマイルストーンは置いてそこに向けて進めるようにしましょう。
6.要件定義を外部委託するメリット
「システム化したい業務はあるが、何を要件として整理すればよいのかわからない」という企業は少なくありません。そのため、要件定義は発注企業だけで進めるのではなく、開発会社と協力しながら進めることが重要です。
外部委託することでどんなメリットがあるか解説していきます。
6-1.業務課題を整理できる
システム開発を検討する際、自社では課題が明確だと思っていても、実際には原因が別の場所にあることがあります。開発会社がヒアリングを行うことで、
- 現状の業務フロー
- 課題の発生原因
- システム化の必要性
を整理し、本当に解決すべき課題を明確にできます。
6-2.要件の優先順位を決めやすい
「あれも欲しい」「これも必要」という状態で要件を増やしていくと、開発費用や期間が大きく膨らみます。そこで開発会社の視点を取り入れることで、
- 必須機能
- 優先度の高い機能
- 将来的に追加する機能
を整理し、現実的な開発計画を立てやすくなります。
6-3.概算費用や開発期間を把握できる
要件定義が進むことで、
- どのくらいの予算が必要なのか
- どの程度の期間で開発できるのか
- どのような体制が必要なのか
を具体的に検討できるようになります。プロジェクト開始前に現実的な見通しを立てられることは、大きなメリットです。
6-4.開発後の手戻りを減らせる
要件定義段階で認識合わせを十分に行うことで、開発途中の仕様変更や手戻りを減らしやすくなります。結果として、
- コスト超過の防止
- スケジュール遅延の抑制
- 品質向上
につながり、プロジェクト成功率の向上が期待できます。
要件定義や進め方に迷ったらICDへ
システム開発における要件定義に解説してきました。要件定義はプロジェクトの立ち上げ時期であり、システム開発のシステム開発の成功は、要件定義の質によって大きく左右されます。
このようなお悩みはありませんか？
- システム化したい業務はあるが、何から整理すればよいかわからない
- 要件定義をどのように進めればよいかわからない
- パッケージ開発とスクラッチ開発で迷っている
- 開発費用やスケジュールの目安を知りたい
- 要件定義から開発・運用までまとめて相談したい
ICDでは、要件定義・基本設計からシステム開発、運用保守まで一貫して支援しています。お客様の業務課題やご要望を丁寧に整理し、最適なシステム開発をご提案いたします。
また、弊社はお客様に合わせて様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。
