いつも見て頂きありがとうございます！「エンプレス」の編集部：エンプレス編集部です。スムーズなシステム開発のためにとても大切な要件定義書。書き方のコツを知って、快適に開発を進めましょう！
要件定義書をどう書けばいいのかわかんないという悩みをお持ちではないでしょうか。
要件定義書はシステム開発を行う際に重要な文書のことです。
これがないと依頼者と開発者の間で誤解が生まれてしまって、上手くシステム開発ができなくなってしまいます。
今回は要件定義書の書き方をご紹介します。
＼お役立ち資料／
要件定義書とは
要件定義書とはシステム開発を行うときに、依頼者が要求しているITシステムやWebサイトをわかりやすく説明する書類です。
要件定義書は基本的には開発担当者が作成するもので、プロジェクトを進めていくうえでとても重要。
要件定義書に不備があると、依頼者の要望に上手く答えられなかったり、最悪の場合はプロジェクトが失敗に終わってしまう可能性が高くなってしまいます。
開発者と依頼者の認識のすり合わせをするためにあるものなので、システムの知識がない人が読んでもわかりやすいと思えるように作成する必要があります。
なぜ要件定義書を書くのか？その目的
要件定義書を書く目的はシステム開発の依頼者、開発者の間で意見の食い違いをなくし、正しい情報が共有されていることを確認するために作られます。
依頼を受けた企業のシステム製作担当者が作成を行うことが一般的。
その際、要件定義書は依頼者、開発に携わる関係者が見るものなので、誰が見てもわかりやすく認識の相違がないように作るべきです。
一般的にはRFP（提案依頼書）と依頼者へのヒアリングに基づいて作成され、必要に応じて現地調査を行うこともあります。
要件定義書の書き方・コツ
こちらでは、要件定義書の書き方とコツをご紹介します。
書き方の流れをしっかりつかむことで無駄な遠回りをせずに要件定義書を作成することができ、スムーズに作業を進めることができます。
コツをつかむことで情報の抜け漏れを防ぎ、認識のズレを防ぐ効果もあります。
依頼者がわかりやすい要件定義書を作成するために、ぜひ参考にしてください。
誰が書くのか
要件定義書は、ITシステム開発の依頼を受けた開発担当者が作成します。
依頼者からの要望や目的を遂行するためにやるべき内容をまとめます。
この内容をもとにシステムの設計・開発をします。要件定義書の内容が曖昧な状態になってしまうと、依頼者との認識の違いがおき、プロジェクトに大きな影響を与えることも。
そのため、開発者は依頼者が理解できるようになるべく言葉を噛み砕いて作成を行うべきです。
今のシステム・業務の流れを棚卸しする
既存システムに新しいシステムを更新する場合は、事前に仕様の確認を必ず行いましょう。
確認に抜け漏れがあると、新しく導入したシステムに不具合が生じてしまい、既存システムの運用ができなくなってしまう可能性があります。
その他、必要のないプログラムやソフトウェア開発が必要になってしまうなど無駄な費用が発生する可能性もあるため注意も必要。
新しいシステムを更新する際は、既存システムの仕様を必ず確認しましょう。
新システムで実現できること・解決したい課題を整理する
ヒアリングで明確化した依頼者の要求を細かく分析して、どうすればシステムを実現できるかを整理します。
課題解決や目標実現に必要な手順や機能を洗い出していく工程が重要となり、依頼者からの要求によっては時間とコストなどの関係で実現不可能な課題が出てくる可能性があります。
課題が解決できるのかどうかも明確化して、代替案や次のフェーズでの開発を提案する準備を始めます。
導入予定のシステムで課題を解決できるのか内容をすり合わせる
依頼者と開発者の間での認識のすり合わせを何回も行うことは、要件定義書を作成するうえでとても重要です。
すり合わせを疎かにして依頼者と認識のズレが生じてしまうと、プロジェクトがスムーズに進まなくなる可能性があります。
ミーティングや進捗状況の報告を定期的にして、依頼者からのフィードバックを元に要件定義書を修正していくことで、課題の解決につながります。
顧客の要求を的確にヒアリングする
ヒアリングをする際は、以下6つのポイントを意識しましょう。
- 専門用語は使いすぎず、依頼者にしっかり伝わるようにわかりやすさを意識する
- 曖昧な表現は避けて、具体的な数値や条件を示す
- 複雑な内容はイラストや図表を使ってわかりやすくする
- 情報をしっかり整理する
- 要件の優先度・重要度をはっきりさせる
- 一般ユーザーを想像して、気遣うようにする
依頼者からの要望をしっかりと把握するために、認識のすり合わせや疑問点の確認をしながらヒアリングを行います。
新規システムの導入目的を聞いてみたり、既存システムの更新の場合は問題点を詳しく聞き出すと良いです。
大体の場合がシステムなどの専門知識に詳しくない依頼者なので、全く知識がない方にもわかりやすく説明ができることを心がけましょう。
難しい言葉は翻訳する
難しい言葉は翻訳するように心がけましょう。
ただし、要件定義書の翻訳は簡単ではありません。
翻訳するときは対応できる翻訳者や翻訳会社に依頼することをおすすめします。
機械翻訳の精度が上がっているため、自分でできるだろうと考える方も多いですが、専門用語や表現までしっかりとカバーしきれていないのが現状です。
基本的に、ビジネスシーンで機械翻訳のみに頼ることは避けるべきです。
プロジェクトを進めるうえで依頼者と開発者の間で誤解を生まないためにも、正確な翻訳をしてくれる専門家に頼みましょう。
最初から作り込まない
システムは実際に動かしてみてから改善点や依頼者からの追加要求が出てくるので、最初で作り込みすぎないようにしましょう。
最初から入れ込むことで時間短縮につながりますが、抜け漏れがあった場合に修正が必要となり、内容を大きく変更しなければならない可能性も出てきます。
まずは全体像を4〜6割くらいにまとめて、そこからどんどん広げていくイメージで作成すると良いです。
依頼者の要求を汲み取りつつ、改良を繰り返しながら使いやすい良いシステムを作り上げるのがベストです。
予算に合わない要件にしない
予算に合わない要件にしてしまうと、スケジュールの遅延や開発者への負担が大きくなってしまい、最悪の場合はプロジェクト失敗につながることも。
プロジェクトが上手く進まないのは、要件の明確化ができていないことが主な原因です。
予算をしっかりと把握し、要件に合ったプロジェクトを組むことで、予算オーバーを防げます。
プロジェクト進行において、コスト管理はとても重要なため徹底して依頼者の予算を管理・把握するようにしましょう。
要件定義書で書くべき項目・テンプレート
こちらでは、要件定義書で書くべき項目・テンプレートについて解説します。
これから要件定義書を作成する方や作成に慣れていない方は、書くべき項目を把握したうえでテンプレートを活用しましょう。
効率よく、わかりやすい要件定義書を作成するためにも、ぜひ参考にしてください。
システム開発の目的
システム開発の目的をわかりやすく明確に書くことで、プロジェクトの方向性が把握しやすくなります。
プロジェクトを行う背景や概要、最終的なゴールを誰がみてもわかりやすいように記載することで、認識のズレを防げます。
要件定義書の文面に出てくる専門用語の定義についてもしっかり記載しておくと、ITシステムに知識がない方や後から参加するメンバーにもわかりやすく伝わる資料になります。
現状のシステム状況から最終的にどのようなゴールを目指しているのか明確に記載して、依頼者や開発メンバーと共通認識をもちましょう。
解決したい課題等
多くの場合は、要件定義が始まった時点で要件は明確になっていないため、プロジェクト内容を明確化する必要があります。
依頼者からのヒヤリングで判明した課題や要求をまとめ、重要度や優先度も明確に記載することで、要件定義が検討しやすくなります。
要件定義が始まる前や要件定義中に出てきた課題で、解決が難しくシステム対象外になったものがあれば、明確な時期と理由とともに掲載しておくべきです。
システム開発の概要
システム開発の概要には「なぜシステム開発に至ったのか」や「システム開発の目的」などを記載する必要があります。
目的はシステム開発をすることによって、どのような結果を求めているかという内容を明確に書きましょう。
ゴールを定めることでプロジェクトに関わる関係者全員の認識のズレを防ぐことができます。
システム方式・構成
テキストやネットワーク図などを使い、アーキテクチャや全体のシステム構造図を書きます。
設計のときに変更となる場合が多いため、作り込みすぎず概要レベルにとどめておきましょう。
以下はシステム構成を作る手順になります。
| 概要を描く | システム全体の構造や機能、ユーザーとの接点も含め、概要を描きます。 |
|---|---|
| モジュールを定義する | モジュールを定義することでシステム内の関係性や機能の役割がわかりやすくなります。 |
| モジュールの関係を描く | モジュールの役割や情報の流れをわかりやすくするために描きます。 |
| ハードウェアを描く | システムの物理的な構造をわかりやすくするために、システム内で使用するサーバーやネットワーク機などのハードウェアを描きます。 |
| インタフェースを描く | システム同士のやりとりやデータの流れをわかりやすくするために、APIやデータベースなどのインターフェースを描きます。 |
| テキストで説明する | システム全体の機能や構造、モジュールの関係性や役割、ハードウェアやインターフェースの詳細をテキストで説明するようにします。 |
用語定義
開発者と依頼者の間で用語定義が違うことはよくあることです。
双方の解釈がズレたままプロジェクトを進めてしまうと失敗に陥ってしまう可能性も出てきてしまいます。
専門用語をわかりやすくかみ砕きながら、認識のすり合わせを何回も行い認識のズレをなくすことが大切です。
自分がこう思ってるから相手もこう思ってるだろうと思わずに、常に相手と認識が合っているかを意識しましょう。
環境や制約等
インフラ環境についても明記します。
ドメインは新しいものを取得すると、ドメインパワーが0になってしまうので、既存ドメインを使う場合が多い傾向です。
サーバーはリニューアルに合わせて、前よりも容量の大きいサーバーに切り替える必要があるケースも。
ドメインやサーバーなどの知識が依頼者にない場合は、わかりやすく説明することが大切です。
現在の業務要件
業務要件とは、ある業務を遂行するために必要不可欠な業務に関する要件のことを言い、業務プロセスやシステム開発の指針になります。
業務プロセスを最適化したり、システム開発や導入、運用をする際の問題回避にも繋がります。
現在のフロー
簡易的なものはフローチャートで、複雑なものはビジネスモデリング表記法、産能大式フローチャートを使って、業務プロセスの流れを記述します。
これを開発関係者に共有して、現状の問題・課題の洗い出しや業務プロセスの改善をします。
システム構築後のフロー
現在のフローと同じく、簡易的なものはフローチャート、複雑なものはビジネスプロセスモデリング表記法、産能大式フローチャートを使って、業務フローが既存のものとどう変わるのかを記述します。
システム導入後に仕事が変わる可能性があるため、依頼者の体制を整えて作成をするとイメージしやすくなります。
システムの利用者（予定者含む）一覧
構築後における利用者を一覧化します。
利用者はシステムに関わる方たちなので、変更内容を認識してもらう必要があります。
システム構築後、スムーズに利用してもらうための教育なども必要。
利用するはずの方が一覧から漏れてしまうと、システム運用後にトラブルへつながる可能性があります。
システム運用後スムーズに利用してもらうためにも、利用予定者も含む一覧を作成して事前に使い方などの説明が必要です。
システム規模・人数
サーバーやネットワーク周りにおける変更が見込まれる可能性がある場合を考慮し、システム規模や人数を明記しましょう。
最初から最後の工程までを同じメンバーで進める場合もありますが、基本的には各工程でのメンバー変更が多い傾向です。
プロジェクトマネージャーやプロジェクトリーダーは決まった人数がアサインされますが、システムエンジニアやプログラマーは工程によって変動します。
システムの機能要件
機能要件とは、システムに実装すべき機能や業務要件を満たすために求められる機能。
機能要件が明確になると、どのようなシステムなのかがわかり、プロジェクトのゴールが想像できるようになります。
機能要件に情報漏れや曖昧な箇所があると、設計書が不十分なものになり、開発やテストなどの下流工程が手戻りになる可能性もあり注意が必要です。
依頼者からヒアリングした内容を整理した上で、適切かつ明確に記載しましょう。
システムの画面
新たに作成、変更される画面をまとめます。
見積もりがしっかりできるのであれば、ざっくりとした項目・機能・レイアウトでも問題ありません。
細かいところは設計工程の際にすり合わせながら決めましょう。
依頼者が利用しやすいように要求を汲み取りながらの進行が理想です。
システムの権限
機能に必要な権限設定をまとめます。
利用者区分に沿って、利用可能な業務、データ閲覧範囲を制限しましょう。
システム帳票
システムから修正が必要な帳票や新たに出力される帳票をまとめます。
見積もりができれば大まかな内容で作成して、依頼者が利用しやすいようにすり合わせながら進行しましょう。
システムが作成する情報・データ
新たに作成するデータや変更する既存のデータをまとめます。
移行データがある場合、完成系のシステムが必要なデータに基づいて、既存のデータベースとどうマッピングするかなど、別途で考える必要が出てきます。
要件定義中にさまざまな要望や課題が出てきたときに本質の課題なのか、そうではないのかを混合してしまうことを防ぐためにも必要な情報です。
システムが接続する外部インタフェース
システムが外部サービスへ接続する場合に明記が必要です。
システムを作っていく上で必要な外部システムとの提携を整理するために書きます。
これを書くことで改善箇所やテスト範囲が拡大して、見積もりミスの防止につながります。
データフロー
データフローは、大きなシステムを設計する時にデータの流れをわかりやすく図にしたもの。
テーブルデータやフローチャートを用いて、明記します。
システム開発を始める前にデータがどのように動くのかが詳しくわからないと設計を開始することができないため、必要な機能をデータフロー図にして、整理しましょう。
システム以外の非機能要件
非機能要件とはシステム開発以外の要件をさします。
システムの性能・安定性・セキュリティレベル・運用保守が該当し、機能要件にさらに明確化された非機能要件が加わることで、プロジェクトのゴールがさらにイメージがしやすくなります。
しかし、依頼者にとってはイメージしづらいもののため、すり合わせをする際は開発者が主導となって、内容を決定させることが必要です。
旧システムとの互換性
旧システムとの互換性を明記する必要があります。
ただし、プロジェクトが既存システムの更新である場合に限ります。
互換性がない場合は、データ移行や多重運用することを明記するようにしましょう。
プロジェクトの進行スケジュール（WBS）
プロジェクトがスムーズに完了するのに必要な項目（テスト・納品・運用教育・データ移行など）を全て洗い出した上で、プロジェクト全体におけるスケジュールを決め記述します。
プロジェクトの予算
プロジェクトでかかるコストや売り上げを想定して、計画と実績の相違をなくすためにする業務を予算管理と言います。
予算管理をすると作業範囲の明確化ができ、各作業に適切なリソースを決めることが可能です。
リソースを正確に決めることができれば、予算超過や作業時間が不足することがなくなり、自社の不利益が防げます。
サポート
プロジェクトを進めていく上で必要なサポートを紹介します。
| 依頼者と開発者の価値観を理解する | プロジェクトを進めていく上で依頼者と開発者の価値観に大きな相違が生じ、会話が成立しないということが多いです。人それぞれ価値観が違うのは当たり前のことですが、お互い押し付けずに理解をしていくことが大切です。 |
|---|---|
| システムへの影響は最小限にする | サポートエンジニアは問題を分断する手段を多く持っておいたり、その手段がどのような時に使えるのかを常に把握しておく必要があります。 |
| 依頼は具体的にする | 曖昧な依頼をしてしまうと、開発者への依頼回数が増えてしまい相手を不快にしてしまいます。 |
| 記録を元に調査を行う | 開発者へ問い合わせを行うときはできるだけソフトウェアの出力ベースで話をするようにしましょう。人は無意識に嘘をついてしまうことがあるので記憶を頼りにするのは危険です。システムの状態が変化するときにどのような記録が残るかは常に抑えておくと良いです。 |
要件定義に含まれない事項について
システム開発をする際に失敗してしまう原因と対策について説明します。
| 要件定義が不十分 | 要件定義が不十分なものはプロジェクトの途中で大幅な変更が生じやすく、結果プロジェクトが失敗で終わってしまう可能性が高くなります。「なぜその機能が必要なのか」をしっかり確認していく必要があります。依頼者側も開発者に任せっきりにせず、細かいチェックを行うことが大切です。 |
|---|---|
| 開発チーム間のコミュニケーション不足 | プロジェクトを遂行する上で大事なことはコミュニケーションです。正しい情報を明確に伝えることができなければ、間違った認識のままプロジェクトが進んでいってしまう可能性があります。定期的な進捗管理でお互い確認し合いながら、開発を進めていくようにしましょう。 |
| 業務を理解せずになんとなくの想像で工数を考えている | 正確なイメージが描けていない納品物を勘や経験で見積もってしまうのはリスクが高いです。特にまだ経験が浅いエンジニアは業務にかかる工数を上手く考えられずに失敗してしまうケースがあるので、実績があるスペシャリストがヒアリングを行って、見積もりの精度を上げていくようにしましょう。 |
| 迅速に対応できる体制が整っていない | 要求が頻繁に変わるなと感じたときは、仕様が変更される前提で最初から対応しやすい体制に整えておきましょう。全てにおいて自立的に行動ができるように連携を取ることを意識してみてくださいね。 |
| テストを軽視している | 日本人は何か問題が起きたときに「作った側に問題がある」という固定概念が強い傾向にあるため、システムで何か不具合が起きてしまったときもそう考えてしまいます。その結果、テスト工程を省略してしまったり、確認事項を放置したままテストが終わってしまい、問題点を見逃してしまうことがあります。テストは曖昧にせずにしっかり行いましょう。 |
まとめ
要件定義書とはシステム開発を行うときに依頼者が実現したいことをまとめた文書です。
基本的に作成は開発者が行います。
依頼者との認識のすり合わせをするときに使うため、相手がシステム知識に乏しい場合でも伝わるような文書を書く必要があります。
その他にもプロジェクトに携わる関係者との進捗状況などを確認するときにも使うため、内容を明確化することが重要。
要件定義書の内容を曖昧にしてしまうと、関係者間で認識のずれが生じてしまい、修正を行うことになってしまったり、プロジェクトが失敗に終わってしまうこともあります。
しっかり目的を達成させたシステム開発ができるように丁寧に書くことを意識しましょう。
