要件定義とは
要件定義とは、開発工程の前段階で開発者側の視点から要求をまとめ、具体的な作業内容を決めることです。要件定義では、大きく分けて2つの工程を行います。1つ目はクライアントの要望を明確化・統一化することです。クライアントの要望を明確にして、不透明な部分や意見の齟齬を解決させます。2つ目は明確になった要望を開発担当者の視点で、システムの機能に落とし込み、スケジュールを明確にすることです。
これら2つの作業を行うことで、後続のフェーズで速やかに作業を進めることができます。
要件定義を行うために必要なスキル
要件定義で必要なスキルを紹介します。大きく分けて以下の4つがあります。費用の見積などはメンバーレベルでは必須ではありませんが、考え方はぜひ知っておくといいでしょう。
要件をヒアリングするスキル
ヒアリングスキルが要件定義ではもっとも重要になります。要件はただクライアントの要望を聞けば良いというわけではありません。クライアントの要望がふんわりしていたり、他の部署のクライアントと意見が異なるというケースも存在します。
要件定義を行う人は、クライアントの状況を把握したうえでクライアントの要望を叶えるために要望や状況を深堀して、素案や折衷案の提案も行わなければなりません。要件をヒアリングする際にはクライアントの要望を深堀して聞く力や、提案力も必要となります。
オペレーションを踏まえたシステム化を検討するスキル
要件をヒアリングするだけではシステムは作ることができません。要件がまとまったら、それらをどのようにシステムに落とし込むかというシステム化を検討するスキルが必要となります。
しかし、システム化ができるだけでは不十分です。例えば、部署Aが入力する欄と部署Bが入力する欄が同じ入力画面にある場合、クライアントは部署Aと部署Bで入力フローの調整をする業務が発生してしまいます。これでは使い勝手の良いシステムとは言えません。よりクライアントの業務プロセスや業務背景を理解して、適切なオペレーションができるシステムを検討するスキルが求められます。
工程・費用を検討するスキル
要件定義の目標は今後の工程でかかる時間や費用を算出し、適切なスケジュールや予算を立てることです。したがって、工程や費用を把握するスキルも必要になります。
工程ではどのような優先順位で後続の設計を行うか、並行して追加の検討等が実施できるのかを確認していきます。費用のところでは要件定義で上がってきた機能単位で工数を概算し、費用を算出します。
工数の導出はステップ数で見積もる方法や、FP（ファンクションポイント）で見積もる方法などが存在しますが、実際の現場では過去の経験をもとに、構築する機能の難易度と開発規模で見積もっていくケースが多いでしょう。これらの工程や費用を検討する担当者は要件定義チームのリーダー的なポジションの人が実施することが多いですが、メンバーレベルでも持っていた方が良いスキルになります。
要件をドキュメント化するスキル
要件定義時にはクライアントとの話し合いを綿密に行います。話し合いの場では資料を持ち込んで自社の素案の検討やクライアントへの確認を実施します。したがって、クライアントへのヒアリングのための適切な資料を作成するスキルが求められます。後の工程ではこれらの資料を参考にして設計・開発を行うため、誰が読んでも認識齟齬がないドキュメントを作成する必要があります。
また、最終的には検討した結果をすべて要件定義書という形でクライアントへ提出することになります。クライアントと相談した結果のアップデートや追加の検討が発生するため、バージョン管理などにも気を付けるようにしましょう。
要件定義の具体的な進め方
要件定義の進め方では、以下の6ステップに分かれています。場合によっては1から6まで順番に作業を行うわけではなく、納期や状況によっては並行して進めたり、順番が前後することもあるので注意しましょう。
- 業務要件を明確にする
- システム構成を明確にする
- 機能要件を定義する
- 非機能要件を定義する
- 予算、スケジュール、体制、コミュニケーションプランを定義する
- 要件定義書を作成する
手順(1)業務要件を明確にする
最初の手順としてクライアントの業務要件を明確にするところから始まります。クライアントの多くは、「なんとなくこんなことをしたい」といったイメージレベルから始まります。
要件定義ではシステム側の視点を踏まえて、具体的な要望に落とし込みます。具体的な要望に落とし込んでいく際には、既存の運用プロセスではうまく行かないケースや他部署との意見の食い違いが発生することもあるので、クライアントに運用プロセスの変更や意思の統一化を図ってもらうこともあります。
■主な成果物
業務機能構成表、ビジネスプロセスフロー、システム化業務フロー
手順(2)システム構成を明確にする
次にシステムの構成を決めます。システム構成ではどのようにシステムが繫がるかというアプリケーション機能構成図であったり、インフラ基盤の構成やネットワーク基盤の構成などを考えます。
このタイミングでセキュリティ要件を確認しておかないと、後に機能構成やネットワーク構成に課題が発生してしまう可能性があるため、確認は忘れずに行いましょう。
■主な成果物
ハードウェア構成図、ソフトウェア構成図、ネットワーク構成図
手順(3)機能要件を定義する
ある程度システム構成が明確化されて、各システムの利用目的が決まったら、機能要件を作成します。機能要件とは「クライアント業務に必要とする機能の要件」を指します。この段階では業務要件をまとめるフェーズで作成した業務機能構成表をもとに、開発者の視点で開発する機能単位に分解していきます。
その中で、システムの仕様上対応できない要件が発生した場合には、業務要件に遡って業務機能構成表の修正を行います。
■主な成果物
システム機能に関する資料→機能や帳票一覧、画面一覧、バッチ処理一覧、テーブル・ファイル一覧
関連性を明確にする資料→機能構成図、帳票レイアウト、画面遷移図、テーブル関連図
手順(4)非機能要件を定義する
機能要件と合わせて非機能要件も決めていく必要があります。非機能要件は機能要件以外のすべての要件を指します。
機能要件でクライアントの要望を満たすことができたとしても、運用に耐えられるかの保障がないため、運用の面でも問題がないか要件を決めていきます。例えば、可用性や処理性能（Webサイトであれば2秒以内にレスポンスが返ってくることなど）、システムの稼働時間やセキュリティ要件などを確認します。
特にセキュリティはシステム構成や業務要件にも影響が出るところなので、綿密に確認をしましょう。また、非機能要件も運用の面では機能要件と同じくらい重要ですので、過去の実績も比較して的確に要件を決めていきましょう。
手順(5)予算、スケジュール、体制、コミュニケーションプランを定義する
大枠の要件（業務、システム、機能、非機能など）が確定したら、今後の設計・開発から運用に入るまでに必要なことを決めていきます。具体的には予算やスケジュール、体制、コミュニケーションプランなどです。
システム構成から大まかな機能ごとにチームを作り、チームごとにコミュニケーションを取るタイミング（会議体、クライアントのメイン担当者など）を決め、機能要件などから予算やスケジュールを決めていきます。スケジュールやコミュニケーションプランなどは状況によって変えなければならない場合も発生するので継続的に見直す必要があります。
手順(6)要件定義書を作成する
手順1〜5までの検討が完了したら、最後に要件定義書を作成します。要件定義書は手順1〜5までの成果物をまとめたものと考えればよいでしょう。要件定義書をどのような形式（それぞれの成果物はリンクのみを記載すればよいのか、何か埋め込みなどで資料を直接確認できるようにする必要があるのかなど）で提出するかはクライアントによって異なるので、要件定義書の提出フォーマットは確認するようにしましょう。
作成が完了したら、クライアントと合意をして、要件定義のフェーズは完了となります。この後は設計・開発のフェーズに移行していくことになります。
要件定義スキルの需要
これまで紹介してきた要件定義スキルですが、実際の現場ではどのような需要があるのでしょうか。けつろん要件定義スキルは身に着けるのが難しい分、市場価値も高くなります。ここでは要件定義スキルの需要を紹介いたします。
ITの普及に伴い市場価値が高まる
近年、企業のIT化が進んでおり、ITスキルを持っている人の市場価値というのは高くなっています。その中でも、要件定義スキルを身に着けるためには、これまでの開発フェーズの経験や開発するシステムへの深い理解が必要となります。
また、要件定義フェーズではクライアントとの会議がメインとなるため、ヒアリング力だけでなく、コミュニケーション力も必要になります。経験も知識もコミュニケーション力も必要とされるので、条件を満たす人材も少なく、要件定義スキルを持っている人はエンジニアの中でも特に市場価値があると言ってよいでしょう。
下流工程のエンジニアと比較して年収が高くなる
下流工程とは異なり、要件定義フェーズでは多くの経験や知識が求められます。また、要件定義後の開発フェーズではPMOを担当したり、要件定義を担当した業務関連の開発チームのリードの担当を求められたりすることになります。
マネジメント能力を求められるとともに、システムの全体感を把握しなければならず、難易度や責任範囲も大きくなりますが、その分下流工程のエンジニアと比較して年収が高くなる傾向にあります。
要件定義以降の工程で心掛けるべきこと
最後に要件定義以降の工程で心掛けることを紹介します。
要件定義書の引き継ぎは正確に行う
設計過程で参入してきた担当者は要件定義の状況を把握していません。資料を読むだけですべてを把握できるわけではないので、設計・開発も同じ会社で行う場合には必ず引継ぎの時間を確保するようにしましょう。
スケジュールの遅延が発生した場合には迅速に連携する
要件定義からスケジュールがずれる場合には、今後の工程にも影響が出るため、すぐにPM・PMOに連絡し、リカバリ策を立てるようにしましょう。
要件が変更になった場合にはPM・PMOと連携する
要件が変更になった場合にも後続の工程に影響が出る懸念や周辺機能との調整も必要になります。すぐにPM・PMOに連携して実施可否、追加費用の要否、スケジュール調整の要否を検討するようにしましょう。
まとめ
この記事では要件定義に必要なスキルについて解説しました。コンサルティング案件などを探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。