ITシステムやWebサイトを開発するプロジェクトにおいて、最初の工程が要件定義であり、その内容を記載したドキュメントが要件定義書です。以降のプロジェクトはこの要件定義書をよりどころとして進めるため、非常に重要で影響度の大きなドキュメントとなります。
また、要件定義を行うためには、システム開発工程の大筋を押さえていることが前提となります。ITエンジニアとしての経験と知識が問われる、腕の見せ所でもあるわけです。
本記事では、要件定義で行うこと、要件定義書の書き方、要件定義工程の進め方などを丁寧に紹介します。
要件定義書とは、非常に大まかに言えばITシステムやWebサイトによって実現したいこと（すること）を定めたドキュメントです。
結果として、システム開発プロジェクトにおけるゴールを定めるドキュメントにもなっています。
要件定義書は、システム（※）の構築や改修プロジェクトにおいて、システムを利用してどんなこと（業務）を実現するかを定めた資料です。
システム開発プロジェクトにおいて、最終的に出来上がってくるのはITシステムですが、このITシステムは特定の課題の解決や業務効率の改善などを目的とします。この課題の解決や業務効率の改善などの、実現したいことを要件定義書に定めて、以降の開発プロジェクトを進める前提とします。
※システムとしていますが、Webシステムや業務システム、スマホアプリなどの開発プロジェクトでも概ね同様です。アジャイル開発を適用するサービスの開発では若干違いますが、後述しています。
要件定義書というドキュメントは、主にウォーターフォール型の開発プロジェクトの場合に要件定義工程において作成します。要件定義工程は、ウォーターフォール型システム開発プロジェクトの一番最初の工程です。
ウォーターフォール型の開発はV字モデルとも呼ばれるもので、定められた順序通り工程を一つずつ進めていくシステム開発方式です。前工程のアウトプット（成果物。設計書などのドキュメント）が後工程のインプットとなります。また、各工程の検証がV字に対応する工程にて行われることも特徴の一つです。
要件定義はシステム開発の依頼元が行う最終的なテスト（※）にて、検証が行われます。言い換えれば、要件定義はウォーターフォール型のシステム開発プロジェクトで一番最後に行われるテストで満たすべき内容を定めているため、要件定義書はプロジェクトのゴール地点を示す意味を持っています。
※テスト名称は受入テストや運用テストなどケースバイケースです。
要件定義を実施するにあたって注意すべきポイントの一つに、技術的な制約に縛られ過ぎないことが挙げられます。最初から技術的に実現が可能/不可能という縛りを設けてしまうと、課題の解決や業務の効率化という本題の実現を妨げてしまう可能性があるためです。
IT技術を用いて課題の解決を図ることが、多くのシステム開発プロジェクトに求められる成果です。技術的な制約はもちろん存在しており、有限のリソースでは実現不可能な要件も確かにあります。しかし、技術的な制約を理由に要件を絞り過ぎてしまうと、本当に実現したかった事が置き去りにされてしまう場合があるため、注意しておきましょう。
また、システム開発プロジェクトの目的と手段が入れ替わってしまうような場合も要注意です。例えば、「AIを導入すること」がシステム開発プロジェクトの要件となっている場合は、プロジェクトの成功は難しくなります。「実現したいこと（要件）があって、その要件の実現にAI（という技術）が適しているので、AIを採用したシステム開発を行う」といった具合に、技術はあくまで要件を実現するための手段であり目的とすべきではないのです。
要件定義書は、システム化の最終的な姿を決める部門（の担当者）が主担当となって責任を持って作成すべきドキュメントです。外部発注をするのであれば発注元の企業、社内のプロジェクトならばシステムを利用する業務部門が条件に該当します。
要件定義書ではシステム開発プロジェクトで最終的に実現したいことを決めるため、IT部門や制作チーム、ベンダーなどのシステムの製作者が主担当とはなりません。しかし、業務部門とその担当者は、システム開発を専門としないことが多いため、要件定義書の作成のための支援は必要です。
社外にシステム開発を外部発注する場合は、SIerなどのベンダーは業務部門を支援する立場として要件定義書の作成に関わります。また、社内のプロジェクトであれば社内SEや情報システム部門は支援する立場となります。
要件定義書は、システム開発プロジェクトにおける他の設計書と比較しても、作成の難易度が高いドキュメントです。その理由として、下記の3点が挙げられます。
システム開発プロジェクトにおいて、設計作業は基本的にブレイクダウンによる詳細化を行っていく作業です。ウォーターフォールの全体像から見ると、前の工程のアウトプットをインプットとしており、前の工程で決まったことを、より細かく定めていきます。設計の元となる情報が常に存在しているのです。1決まっている事を詳細化して10にしていくイメージです。
一方、要件定義は他の工程とは異なり、ウォータフォールの先頭の工程です。この段階では、システムの完成系は関係者の誰にも見えてはいません。各関係者の頭の中に実現したい事や要望、課題などが整理されていない状態で存在しており、これを引き出し、共通認識としながら、新たなシステムをゼロから作成していくのが要件定義なのです。0から1を作る作業といえるでしょう。
要件定義では、これから作るもの（システム）を決めていきます。この時点では、誰も正解を知りません。システムの概要が見えていない状態であり、関係者が手探りで最も良いと考えられる形に作っていきます。
要件定義書として必要なドキュメントの種類、記述、項目だけを埋め、「要件定義が完了した」とすることは可能かもしれません。しかし、要件定義の先のプロジェクトで何を作り上げるかを最優先事項とし、形だけではなく本当に必要なものを定めたドキュメントを作らなくてはいけないところも非常に難しいポイントです。
「要件とはクライアントの実現したいこと」とここまで繰り返し記載してきました。実際にその通りなのですが、「それならばクライアントにヒアリングを行えば全ての要件がでてくる。要件定義書を書ける。」と直接的には繋がっていないのが難しいところです。
要件は、クライアントやその業務の付近に存在しています。しかし、クライアントも内容を明確に言語化はできてはいないのが実情です。あるいは、要件が明確に言語化できていれば、既にクライアントはITエンジニアの登場を待たずに手を打っているでしょう。
クライアントが抱えているのは、要件の形になる前の要求・課題レベルのケースがほとんどです。課題は潜在的な場合も多く、表面化されていないことも多々あります。要件定義は、これらの要求・課題を掘り起こし、かみ砕いて整理し、ITを活用した解決方法を提案するという作業が含まれているのです。
さらにはクライアントとITエンジニアは持っているバックグラウンドが異なります。同じ物事を表す言葉さえも違う場合もありますが、それでも要件定義を行うことによって共通認識を持つ必要があります。要件を言語化して、お互いに齟齬の無い状態で共有するのが目指すべき姿です。認識が一致していない場合には、出来上がったシステムがクライアントが求めていたものとは違うという状況を招いてしまいます。
要件定義書はこれから行うシステム開発プロジェクトのゴールを定めたドキュメントでもあると先に記載しました。
ウォータフォール方式での開発の場合には、要件定義を行うことによりプロジェクトの初頭に最初にどこまでシステムを実現するかを定めます。これで、プロジェクトのゴールが決まるわけです。
ゴールが定まることにより、システム開発プロジェクトの対象範囲を定め、予定納期やシステム開発プロジェクト全体の見積が可能となります。納期や予算に関する制約の強い大規模開発プロジェクトでは、今日でもウォータフォールでの開発が好まれる由縁の一つです。
一方、Webサービスを自社提供する場合などでは、一定の機能ができあがったら、リリースを行い、継続的に開発サイクルを回し、改善を続けていくシステム開発形態がとられます。この場合には、アジャイルが開発手法として適用されます。
継続的な開発を前提とする場合には、ゴールが最初に見えてはおらず、サービスをリリースしながらより良い方向に導いていく形態を取ります。ウォーターフォール型で作成するような要件定義書は作れません。
ただし、アジャイルを用いたシステム開発の場合「要件定義を行わない」、という事ではありません。プロジェクトの開始時にもドキュメントを作成しますし、開発サイクルの中にも要件定義にあたる作業が存在します。作成するドキュメントがウォーターフォール型とは異なるというのが正確なところでしょう。
アジャイルによるシステム開発では、要件定義として下記のようなドキュメントを作成します。ウォーターフォールの場合と違い、一度作成したドキュメントでも最終的なゴールとして定めるわけではありません。より良くするため繰り返し修正を行ったり、概要を書き残しておいて後からリファインするなどの方法で作られる事も一般的です。
・ビジネス要求、ビジョン、スコープを定めたドキュメント
・リーンキャンバス（ビジネスモデルを整理する）
・ユーザーストリー（顧客視点でユーザ要求を記載する）
要件定義書には決まったフォーマットがあるわけではありません。企業や組織によっては、定型のフォーマットを用意して利用している場合もあるでしょう。
本項では、要件を段階的に記載していくためのドキュメントおよび記載項目の例を下記に記載します。
要件定義書を作成する一番の大本となるのが、クライアントの持つ要望や課題の一覧です。多くの場合、要件定義が始まった段階では要件は明確になっていません。要件を固める元となる要望、課題、要求事項などをまとめたものが最初に作られる要件定義書となります。
要件定義を行うにあたり、関係者の持つ要望などを集めて一覧として書き出します。関係者を集めて、意見のすり合わせをする段階で重要となるドキュメントです。要望などの内容に加えて重要度や優先度をつけておくと、要件定義での検討がしやすくなります。
要望や課題の一覧を作成することで要件定義のとりかかりとなります。このプロジェクトでは何を目的としてシステム開発を行い、どこまでを実現範囲とするかを定めるためには、まずはそのもととなる情報の書き出しから始まるのです。
要件定義開始前や要件定義内であがった内容で、システムの対象外となったものがあれば、そちらも記載しておくのが望ましいです。明確にいつ、なぜ実現対象から外れたかが分かると以降の工程で振り返りやすくなります。
要望や課題をもとに要件を煮詰めていき、システム化により実現することを決定した内容を要件の一覧として書き起こします。プロジェクト内で、何を実現するのかをリストアップしたドキュメントです。要望や課題の一覧から、話を深めていき、対応することが確定した内容を記載するイメージです。
要件定義の段階で要件が増えすぎてプロジェクトの期間内に全てが開発不可能なことが予測される場合には、優先順位をつけて、二次開発の対象を分けておくような場合もあります。このような場合、システムの実装範囲を定める上で優先順位が重要となるため、要件定義完了までに明確な線引きが必要です。
業務フローは現状の業務の流れ、システムを導入した後の業務の流れを、フロー（流れ図）として表現したドキュメントです。一つの業務に関わる担当者を洗い出し、登場するドキュメント、データ、モノの流れや、各担当者が実施する作業を記述します。フローチャートなどの図を用いて表すことが一般的です。
業務の改善点を探す用途でも利用されるため、要件定義の早い段階でヒアリングにより現状業務のフローチャートを作成します。その後、要件がある程度固まってきたら、システム化要件を導入した場合の業務フローを作成し、システム導入を行った場合の業務を確認します。
要件をシステムとしてどの様に実現するか概要を定め、機能（画面や帳票、バッチなど）のリストとしたドキュメントです。必要に応じて、要件定義の中で個別の詳細な資料を作成する場合もあります。
システム機能と実現する要件とを紐づけて管理しましょう。あくまで要件定義でのシステム化の想定を記載するため、技術的な検証が必要な場合もあります。この場合には、プロジェクトへの影響度を検討しながら設計工程などで技術的な裏付けを取る作業が必要となります。
業務フローの整理などを進める中で、システムで取り扱う情報（データ）が浮かび上がってきます。情報の名称や保有する項目、形、桁、ルールなどを記載可能な範囲で記述しておきます。
データベース上の実際のレイアウトレベルには、以降の設計工程で落とし込みます。
要件定義工程を行っていくと、その場では解決ができず継続的に対処が必要となる課題が発生します。例えば、予算面で大きな影響がでる要件がでてきた場合には、要件定義を行っているメンバーでは可否判断がつかず上司の判断や経営層の稟議を通さなくてはならない場合もあるでしょう。また、将来的にプロジェクト推進上のリスクとなる懸念点とでもいうべきものも出てきます。
プロジェクトマネージャーなどのプロジェクトの推進を行う責任者は、これらの課題、リスクなどを一覧化し、対応者や対応状況をフォローしていく必要があります。これらの管理表は要件定義工程の成果物としては扱われないことが多いものの、事実上重要度が高い要件定義ドキュメントの一つといえます。
要件定義工程で、「ボタンのクリックにより○○を実行する」などの具体的なイメージがでてきた機能については、画面レイアウトなどの資料を作成します。
Webシステムでの開発など前提がある場合は、HTMLモックを作成し、イメージ資料とする場合も多々あります。後で変更する前提でも、できるだけ形にしておくことで認識の共有、イメージの具体化につながり、要件定義の精度を高める役割りを果たします。
他システムとの連携が前提となるシステムの場合、連携先、IF（インタフェース）の種類、データ種別などの情報も一覧として記述しておきましょう。場合によっては、連携先のシステムにも影響がでるため、漏れのないよう記載し、フォローを行います。
要件定義はシステム開発プロジェクトの一番最初の工程となりますが、そのインプットとなるドキュメントとして下記が挙げられます。これらのドキュメントの有無や名称、記載粒度などはケースバイケースです。
・RFP（提案依頼書）
・業務課題をまとめた資料
・業務改善案をまとめた資料
要件定義では、要求事項や最初のヒアリングを行った段階で完成版のドキュメントを作成できることはほとんどありません。この段階では、集められた情報には各方面の意見が反映されていないためです。
ドラフト（草稿）のドキュメントをまずはたたき台として作成します。その後、関係者間で繰り返しすり合わせを行いながら、修正を行い、品質を高めて最終的な要件定義書を作成する手順となります。
要件定義工程が始まった段階では、まずはRFPや課題の一覧表などの資料の読み込み、および業務の担当者などへのヒアリングを行い、要件を検討する元となる情報を収集・整理します。
要件の検討上で必要となる既存業務の調査や既存のシステムに関する調査も行い、関係者間でのすり合わせの打ち合わせに向けたドラフト資料の作成に繋げます。
インプットにより得た情報をまとめ、要件定義のたたき台となる資料の作成を行います。初回は関係者が全員集まり、必ず読み合わせが行われることが前提です。
読み合わせ後には、ドキュメントに内容を反映し、ビルドアップしていきます。
ドラフトとなる資料をもとに読み合わせを行います。システムの利用者部門の決定権者、情報システム部門、システム開発者などステークホルダーが集まって実施します。忌憚なく意見を集め、システムによって実現したい事を明確化していく打ち合わせです。
メンバーを集めるのが難しいため、ドラフト版の資料作成者は決定が必要な内容、検討事項、仕様を決める担当者の管理など、出来る限り準備をしておく必要があります。
場合によって回数や期間は変わってきますが、このドキュメントの作成と読み合わせを繰り返して要件定義の精度を高めます。
読み合わせとドキュメント作成を繰り返して、要件定義書を作成します。最終版を作成し、全員の確認が取れたら要件定義書は完成します。
どの方面からも疑義がでない状態まで作りこむことが理想ですが、期限や予算といった制約があるため、ある程度検討事項が残る場合もあります。この場合、いつ、誰が、どの様に解決するのかまでを定めておき、リスト化したものを補足資料としましょう。
要件定義書は、システム開発プロジェクトの一番最初の工程である要件定義にて定めた内容を記したドキュメントです。システム開発プロジェクトでどの様なことを実現するのかを定め、以降の工程では要件定義書から設計をブレイクダウンしていきます。また、最終的なテスト工程で確認する内容は、要件定義書の内容をシステムが満たしていることですので、システム開発プロジェクトのゴールを定めたドキュメントにもあたります。
本記事ではウォーターフォール型のシステム開発における要件定義書について、ドキュメント種類や記載する内容を紹介しました。要件定義はシステム開発の中でも扱う内容が固まっておらず、難易度の高い工程です。要求や課題を解決する事を最重要視して、システムを成り立たせる基礎部分をドキュメントに記すことを心がけましょう。
この記事を見ているあなたに
オススメの記事
前の記事へ
