目次
クライアントからシステムやスマホアプリ開発などの発注依頼を受けた後、その開発プロジェクトを成功に導く鍵となるものが要件定義の成果物です。こちらの記事では、成果物の詳細を解説するとともに、その作成に必要な工程を解説していきます。
要件定義工程の成果物は要件定義書
まずはじめに要件定義工程の成果物について見ていきましょう。成果物とは「要件定義書」と呼ばれる書類を指します。これを基に開発プロジェクトのフェーズを次工程の設計工程へと進めることができます。
要件定義書は、システム開発会社がクライアントとの認識を合わせるために、平易な言葉で文書化したものとなっています。中身は、クライアントから提出された要求仕様書やRFP（提案依頼書）、企画書・仕様書、ヒアリングの中で聞き出した内容を基にして作成します。これらはシステムを実際に設計・開発する前に提出する書類になりますので、実装予定の機能についてできる限り詳細に記入します。
また、作成の目的はクライアントへのプロジェクト内容の説明が主となります。そのため、システム開発の内容について専門的な知識がない人に対しても理解しやすい内容で記述する必要があります。内容はクライアントからの要望を明確にしたうえで、クライアントと意識合わせを行い、先方から合意を得ます。
クライアント側とシステム開発会社側でしっかりと認識を合わせ、目的を具体的にすることで後々の認識の齟齬を防止することができます。
要件定義書の作成に必要な要件定義とは
続いて、要件定義書の基となる「要件定義」について解説します。要件定義とは、システム開発の初期段階で行うもので、システムに実装する範囲や内容を決定する重要な工程です。システム開発を進めるうえで、プロジェクトを整理してわかりやすく文書（ドキュメント）化することは、開発全体の道標となるため、要件定義工程がシステム開発プロジェクト成功を決定づけると言っても過言ではありません。
次章では要件定義とは何かをさらに深掘りし、また要件定義を進める前段階の要求仕様書と、RFPについても詳しく解説します。
要求仕様書とは
まずはじめに「要求仕様書」について説明していきます。要件定義書と言葉は似ていますが、要求仕様書とはクライアントがシステム開発会社側に対して、開発を依頼するシステム要件を記載したものを指します。要求と予算、開発体制、リリース時期などの記載がメインで、技術的な要件を含みません。
要求仕様書は、要件定義よりも前の段階でクライアントがまとめるのが通常です。
また、システムによっては要求仕様書の作成は行わずに、要件定義の段階で要求仕様も含めて要件定義書として一つにすることもあります。
RFP（提案依頼書）とは
クライアントから新しい機能の実装を依頼される場合は、既存システムの改良であることが多いため、プロジェクト開始の準備段階として、はじめにクライアントの現状や既存のシステムについて調査する必要があります。既存のシステムを確認したい場合は、RFP（提案依頼書）などの書面で確認する必要があります。
RFPとはRequest For Proposalの略で、クライアントがシステム開発を依頼する際に作成する、開発側に求める要件を明確に記載した書類です。RFPを開発側に提出することで、具体的な提案をもらい、比較・検討をさらに進めることができます。
依頼された開発側は、RFPに記載されている機能や範囲、環境、条件、稼動までの期間などを参考にします。そしてクライアントの要望に沿った提案や見積もりを提示し、実現可能で最適な提案をしていきます。
要件定義とは
「要件定義」とは、システム開発における「目的」を明確にする作業を意味しており、クライアントの要望をまとめた要求仕様書を基にさらに具体化し、各種要望に対し、それらをどのように実現するのかを文章としてまとめる作業です。この要件定義がないままプロジェクトを進めた場合、後々の工程でクライアントの要望と齟齬が生じる可能性があります。そのため、はじめに要件定義書を作成することは、開発プロジェクトを成功に導くためにも非常に重要と言えます。要件定義書の作成にあたっては、クライアントの要望（実装して欲しい機能など）をしっかりとヒアリングする必要があり、お互いの認識に食い違いが生じないように確認しながら丁寧に進めていきます。
要件定義の作成のフェーズでは、クライアントの要求が実現可能かを判断したり、実際に搭載する具体的な機能を決定します。注意点として、この工程に時間を掛けすぎてしまうと、プロジェクト全体のスケジュール（設計や、開発、テストなど）が圧迫されてしまうため、タイムマネジメントには注意が必要です。
要件定義書の内容について
では、ここからは要件定義書に記載が必要な３つの項目について解説します。機能要件や非機能要件の違いもあわせて説明をしていきます。
システムに関する要件
要件定義書の要とも言うべきは、システムに関する要件です。どのようなシステムを構築、導入する予定なのか、また開発形態を詳細にクライアントに説明するために記載します。
具体的には以下の４つの項目が挙げられます。
・システムの基本概要
・システムを開発する目的
・開発したシステムから得られるメリット
・システム導入後の業務の変化
それでは具体的に１つずつ見ていきましょう。
システムの基本概要
システムの概要や範囲、どのような機能を備えたシステムなのかを記載し、システム全体の方向性をわかりやすくまとめます。業務要件はクライアント側の視点で作成し、システム要件は開発側の視点で作成します。
システムを開発する目的
新たに開発した機能を導入することで、具体的にどのような要望を実現できるか、また導入する理由やシステム開発に至った背景について説明します。
開発したシステムから得られるメリット
現状のシステムから新たなシステムを導入することでプラスになるメリットや、目標などを具体的に記載します。
システム導入後の業務の変化
システムを実際に導入すると、現状の業務フローから具体的にどのように変わるのかなど変更点を表記します。クライアントの体制にあわせてフローチャートを作成すると、文章だけのものよりイメージが伝わりやすくなります。
機能要件とは
「機能要件」とは、クライアントがシステムに実装する機能について求める要件のことです。システムを実装することで何ができるようになるのかを記述します。具体的には、データやシステムの種類・構造や、システムが処理可能である内容について記述していきます。
機能要件は、システム開発における最初の工程である「要件定義」の段階で文章化します。クライアントが完成形のイメージを持っていないこともあるため、クライアントからの要求にある背景や目的の確認をヒアリング調査で何度も行いながら、機能要件を見つけ出していきます。単に必要な機能をヒアリングするだけではなく、背景や目的を共有することも重要です。
クライアントから聞き出した内容は一覧で纏め、業務改善のシステム開発は業務フローから確認して必要な機能を抽出します。さらに必要な機能要件を選定したうえで、実装を実現できない場合は与えられた予算やスケジュールの中で、実現可能な機能要件をクライアントと開発側で絞り込みます。
非機能要件とは
非機能要件とは、クライアントがシステム要件・機能要件など、機能面以外で検討すべき、すべての要件のことを指します。具体的にはシステムの性能や効率性、セキュリティや保守・運用サービスなどについて記述します。非機能要件は軽視されがちですが事業に大きな影響を与える可能性もあります。そのため、こちらも機能要件と同じくシステム構築において必要不可欠なものになります。
また、非機能要件は要件定義の初期段階でヒアリングしておく必要があります。非機能要件は発注側の直接的な要求ではないため、発注側からの提示が困難です。非機能要件を洗い出すのは、機能要件が明確に定まった後になります。機能要件が決まり次第、非機能要件のヒアリング調査に入り、実際の運用を想定してクライアントとの細かい打合せが必要となります。
実行計画の定義
実行計画では、この後のプロジェクトの開発を進行するための計画を立てていきます。リリースまでに必要な作業とかかる工数を抽出し、開発体制（人員・作業場所・使用する機器）・期間・予算等を定義します。
また、プロジェクトの担当者は明確に決めておく必要性があります。クライアント側がやらなくてはいけない業務までSEなどの開発側が引きとって作業してしまうケースもよくあります。すべてのタスクについて、担当者が適切に決められていれば、不要な業務で工数を圧迫する可能性もなくなります。
５W２Hを用いて作成する
５W２Hは・When（いつ）・Where（どこで）・Who（だれが）・What（なにを）・Why（なぜ）・How（どのように）・How much（いくらで）の英単語の頭文字をとった言葉です。情報の整理や、報告などにおいて活用できるフレームワークです。
実際のプロジェクトでは以下のような観点で整理していきます。
・要求
Why：なぜシステム開発を行いたいのか
What：新しいシステムで何を（どんな目的を）実現したいのか
・システム要件
Where：要求を満たすためには、どの部分をシステム化するのか
Who：そのシステムの利用者は誰なのか、運用者は誰なのか
How：開発したシステムを使ってどのように実現するのか
・プロジェクト要件：制約、前提事項
When：そのシステムによるサービスをいつから運用開始したいのか
How much：システム開発するための予算はいくらか
要件定義においては、これらの５W２Hの観点から要望・課題を掘り下げることで、様々な要件・確認事項の漏れを防止できます。要件定義書にも５W２Hを用いて記載することでプロジェクトを整理し、設計工程でのトラブルを未然に防ぎましょう。
要件定義書を「最良な成果物」にするには
前段落までは、要件定義から成果物に仕上げるまでに必要な要件項目や、工程を解説いたしました。ここからは、さらに成果物をより良い物へ仕上げるための内容や、しかるべき注意点を解説していきたいと思います。
誰が読んでも分かりやすい内容に
要件定義書を最良な成果物にするために、作成時における注意点を解説します。
大事なポイントは「分かりやすさ」です。具体的には専門知識がなくても内容が分かるように記載します。良い要件定義書には、実際にシステムを利用するクライアントが理解しやすい文章が記載されています。クライアントの大半はIT分野の専門知識に詳しいわけではないため配慮が必要です。
そのため、書面ではIT分野に関する専門用語や専門知識を極力使わないようにします。書面の内容を理解してもらわなければ、具体的な仕上がりがイメージできないためクライアントの不信感が高まる恐れがあります。
また、要件定義書の作成には図解を多用することも重要です。業務フローや技術的な内容は文章だけでは分かりにくい点も多いからです。作成時には図解を効果的に用いてクライアントが理解しやすいように校正をまとめます。
問題の解決策が記載されている
要件定義の最終目的は、クライアントからの要求をまとめるだけではありません。クライアントの要求を明確にしたうえで、開発側は積極的なコミュニケーションをはかり、お互いの疑問点・懸念点を徹底的に無くしていくことが重要です。そして、その要求をどのようにして叶えるのかという「答え」にあたる文章を記載する必要があります。
クライアントも開発側がどのような対処をとってくれるのかが明確になります。答えを記述して、要件定義書は初めて完成と見なされます。
まとめ
いかがでしたでしょうか？今回は、要件定義の成果物について解説してきました。要件定義の成果物である「要件定義書」はシステム開発における道標であり、プロジェクトの進行において重要な書類となります。また、要件定義書はプロジェクトのスタート地点であり、その先の作業の基礎となるものです。クライアントへのヒアリング調査をしっかりとおこない、課題や要求を正確に捉えることと同時に、クライアントの立場や目線で考え、抽出が出来ていない課題を見出すことも重要です。
品質の高い要件定義書を作成することが出来れば、最終的なシステムも良いものになり、プロジェクト全体が成功に近づくと言えるでしょう。
—————————————————————————————————————
システム開発、スマホアプリ開発、MVP開発、新規事業立ち上げ、DX化の推進でお困りではありませんか？
日本全国には開発会社が無数にありますが、Webサービスやアプリサービスのスケール（規模拡大）を実現するビジネス推進力やシステムの堅牢性、可用性を意識した設計力・技術力を合わせ持つ会社は、全国で見ても多くはなく、弊社は数少ないその一つ。お客様のご要望通りに開発することを良しとせず、お客様のビジネス全体にとって最適な解を模索し、ご提案ができるビジネス×テック（技術力）×デザインの三位一体型のシステム開発/アプリ開発会社です。ITやDX全般に関して、何かお困りのことがございましたら下記の「GeNEEへのお問合せ」フォームからお気軽にご連絡いただけたらと思います。
—————————————————————————————————————
