要件定義の進め方は?効率的に進める方法や要件定義書に必要な項目なども紹介

コラムCOLUMN

要件定義の進め方は?効率的に進める方法や要件定義書に必要な項目なども紹介

2021/06/24

システム開発を行うなかで、クライアントの要望をヒアリングし、実現方法の検討や開発プロセスなどをまとめる要件定義は必須の工程です。

要件定義という言葉は聞いたことがある人でも、対応方法や進め方はどのようにすればよいのかと疑問に感じている人もいるでしょう。

この記事では、要件定義を効率的に進める方法やヒアリングに必要な項目について解説をしていきます

これから上流工程も対応ができるエンジニアとして働きたいと考えている人は、ぜひ参考にしてみてください。

要件定義とは?

要件定義とは、クライアントが「このようなシステムを構築して欲しい」「この課題を解決したい」という要望を実現するための方法を検討し、開発プロセスをまとめるなどの作業を行う工程のことです。

要件定義は、システム開発を行う上で、仕様書や設計書の基になるもののため、抜け漏れや認識に齟齬が無いようにするために、クライアントと入念に打ち合わせを行う必要があります。

抜け漏れや要件に関する齟齬が発覚すると、システム開発が始まってから手戻りの発生や納期の遅延、クレームなどといったトラブルの原因にもなります。

システム稼働時にこのようなことが発覚すると、修正作業のための人材や費用など余計なコストがかかってしまいます。

また、要件定義は入念に行わなければなりませんが、時間をかけ過ぎてしまうとシステム開発に充てる時間がなくなってしまうため、効率的に進める必要があります。

要件定義の効率的な進め方については後述します。

要件定義の進め方

要件定義は、抜け漏れがないように入念な打ち合わせを行う必要があると解説しましたが、具体的にどのように進めれば良いのでしょうか。

ここでは、一般的な要件定義の進め方について紹介していきます。

1.クライアントからの要求をヒアリング

上記で解説をしたように、まずはクライアントから構築したいシステム(機能)や解決したい課題などの要求をヒアリングするところから始まります。

ヒアリングをする際は、クライアントの要求を尊重することは重要ですが、システムの機能や予算などの関係から、要望をすべて実現することができない場合があります。

そのため、ヒアリングをしながら実現可能か否かを判断しなければなりません。

実現可能性を判断するためには、提案するシステムについて把握しておく必要があります。

要件定義をする人は、プログラミングができなくても良いというイメージを持つ人もいるかもしれませんが、最適なシステムを開発するためには、システムの全体像や特性を把握していなければならないため、開発に関する多くの知識が必要です。

2.クライアントの要件を整理

ヒアリング実施後は、クライアントの要件を整理し、課題の洗い出しや実現可能性を検討する作業に移ります。

特に、クライアントの要望を整理する作業は、要件の抜け漏れ防止にもなる非常に重要な作業です。

単にヒアリング内容を整理するだけではなく、次回の打ち合わせ時に確認すべきポイントのあぶり出しを行い、整理した内容をクライアントに提示することで、過不足の無いなく要件定義の作成に繋がります。

クライアント側も質問に対して即答できない事項もあるため、次回確認したいポイントは事前に提示しておくとスムーズに進めることができます。

3.要件定義書の作成

すべてのヒアリングが完了したら、要件定義書を作成し、クライアントに提示します。

要件定義書には、クライアントの要求やシステム開発を行うことで解決したい課題、それらを実現するための方法、各種機能についての詳細を記載します。

要件定義書をクライアントが確認し、内容に問題が無いという合意を得ることができれば、システム開発に着手することができます。

要件について齟齬が無いかクライアントと認識を合わせるフェーズになるため、必ずクライアントに確認をしてもらうようにしましょう。

効率的に要件定義を進める方法

効率的に要件定義を進める方法

要件定義は、システム開発をする上で必須かつ非常に重要なため、つい時間をかけてしまいがちです

しかし、前述したように要件定義に時間をかけ過ぎてしまうと、肝心のシステム開発をする時間が圧迫されてしまいます。

そのため、要件定義には精度だけではなく、効率性も必要です。

ここでは、要件定義を効率的に進める方法について紹介していきます。

既存のシステムと業務フローについて把握する

システムの導入方法はさまざまで「現行システムから新システムへ移管したい」「業務フローにおいて一部をシステム化したい」など、抱えている課題によって要求は異なります。

また、クライアントによっては抱えている問題点の原因を把握しきれていない場合もあるでしょう。

効率良く要件定義を行うためには、単にクライアントから挙げられた課題をヒアリングするだけではなく、既存システムや業務フローについて改善点がどこにあるのか把握する必要があります。

これにより、ヒアリング時の精度が上がることはもちろん、別の解決方法を提案することも可能になります。

既存システムを把握するためには、業務担当者だけではなくシステム担当者にも確認を行う必要があります。

打ち合わせ当日では即時回答を得られない場合もあるため、クライアントへ確認したい内容を事前に提示し回答を準備しておいてもらうようにしましょう。

最終的な成果物のイメージを共有する

クライアントと開発側がイメージする最終的な成果物が異なることは多々あり、それが後々大きな手戻りとなる可能性もあります

打ち合わせごとに要件定義書を更新し「打ち合わせで課題となった内容を解決する方法はこれ」「この機能を追加した際の動作画面はこのようになる」という情報を逐一共有することで、認識に齟齬がないようにすることが可能です。

これにより、都度確認と合意を得られるため、認識にズレがなく、精度の高い要件定義書を作成することができます。

手間はかかりますが、その後大きな手戻りが発生することを未然に防ぐことができるでしょう。

打合せの回数を予測しておく

「キックオフが始まり、そのまま要件確認を行った」「要件を確認しきるまで打ち合わせを繰り返す」ということはよくありますが、これではプロジェクト全体のスケジュール管理をすることができません。

機能や業務フローごとに打ち合わせ内容を区切ると、大まかながらも打ち合わせに必要な回数が見えてきます

そのため、スケジュール管理もしやすくなります。

こちらも打ち合わせ前に確認内容を伝えておくことで、「この日の打ち合わせにはシステム担当者も同席してもらう必要がある」という調整をクライアント側も図れ、「担当者が出席できず確認したい内容の回答が得られなかった」「次回に持ち越しとなった」といった事態を回避することができます。

要求定義と要件定義のすり合わせをする

要求定義書とは解決したい課題や導入したいシステムの要求をまとめた書類であり、こちらを基に要件定義書は作成されます。

要求定義書を読み込むことはもちろんですが、要件定義書がクライアントの要求に対し満たしているのか、派生する懸念点はないか、すり合わせすることで抜け漏れのない要件定義書を作成することができます。

要件定義書に必要な項目を把握し整理する

システムの概要・構想

システムの概要について詳細説明を行うための項目です。

これによりクライアント側も、どのようなシステムを導入しようとしているのかを具体的にイメージすることができ、認識のすり合わせになります。

システム要件

業務要件はクライアント側で作成を行いますが、システム要件は開発側で行います。

内容としては、システムで何ができるのか、どのような機能があるのか、それによってどのような課題が解決できるのかを確認できるような項目を設けるようにしましょう

そうすることでクライアントへのヒアリングが進めやすくなるでしょう。

性能要件

機能はクライアントの要求を満たしていても、その品質や性能が伴っていなければ不備やクレームへ発展してしまいます

例えば、動作するブラウザのバージョン、検索速度、データの種類、処理が可能なものなどが挙げられます。

また、昨今においてはセキュリティーに関する性能についても重要視されているため、こちらも説明できるよう準備をしておくと安心です。

システム導入後の業務フロー

システムを導入することによって従来の業務フローに変化が起きます。

導入後はどのように変化するのか、運用手順はどのようになるのか、メンテナンスはどのようにするのかなど項目ごとに説明の準備をしましょう

その際、資料での説明だけではなく、デモ画面を使用し、動作をクライアントに見てもらいながら説明すると要件確認時に齟齬が生まれにくくなるため、おすすめです。

システム導入の目的・目標

システム導入における目的とは「システムを導入することで顧客満足度を向上させる」「煩雑だった業務を整理して生産性を上げる」というような、クライアントがシステム導入によって実現したい理念的な要求のことを指します。

一方、システム導入における目標とは「Webページの離脱率を30%減少させる」「従来の業務時間より3時間短縮させる」などのように、どれだけ向上させることができるのかを具体的に提示するものです。

これらを提示することにより、システム導入におけるゴールの設定が共有できるようになるため、要件定義の際に何を確認しなければならないのかが明確になります。

まとめ

要件定義はシステムを導入する上で必須の工程です。

ウォーターフォール型の開発であれば「要件定義→設計書作成→開発→テスト→納品」というように、要件定義を行わなければ開発が始まりません。

効率良く要件定義書を作成するためには、事前準備が非常に重要で、導入するシステムへの理解、クライアントの業務フローの把握、解決したい課題などのポイントを押さえておくことが大切です。

また、このように要件定義(上流工程)をできるエンジニア対応できる業務の広いため市場価値が高くなりやすく、案件の選択が広がる、比較的報酬が高いというメリットがあります。

市場価値が高いエンジニアとして働くことに繋がるため、フリーランスとして働く場合においても案件を獲得しやすい傾向があります。

要件定義フェーズから担当できる案件はフリーランス専門のエージェントサービスを利用すると見つけやすく、営業活動にかかる手間を省けます。

i-common tech」もフリーランスITエンジニア専門のエージェントサービスであり、要件定義などの上流工程を担当する案件も豊富に扱っています。

一からシステム開発を行う案件や既存システムのリプレイス案件、既存システムのAPI連携を行う案件など、担当する業務内容も多岐に渡ります。

また、案件の紹介だけでなく、面談前後のフォローや契約内容・契約延長の代理交渉なども行っており、効率的に希望する案件を獲得する可能性を高めることができます

サービスは無料で利用できるため、情報獲得のためにも登録をしてみてください。