目次
要求定義は、プロジェクトの成功を左右する重要なプロセスです。具体的には、開発すべきシステムやスマホアプリが満たすべき条件や機能を明確にする作業のことで、開発の効率化や品質向上を高める上で必要不可欠な作業と言えます。
本記事では、要求定義とは何か、その重要性、具体的な書き方や作り方について、作成者目線を取り入れながらわかりやすく解説します。
要求定義とは？
要求定義の目的と役割、基礎知識について以下で解説します。
要求定義の目的と役割
要求定義とは、システム開発やスマホアプリ開発のプロジェクトにおいて、必要な機能や性能、条件などをクライアント側が明確に定めるプロセスを意味します。この段階で各種要求詳細を具体的に定めることで、開発の方向性がはっきりし、将来的な無駄な開発工数の削減、クライアントと開発会社間で起きやすい認識齟齬を防ぐことができます。
要求定義の基礎知識
要求定義を行う際には、まず該当プロジェクトの目的を明確にし、対象となるシステムやスマホアプリの範囲を明確に定義します。次に、ステークホルダーから受領した個別要件を収集・分析し、ドキュメント化します。このプロセスには、様々な手法やツールが用いられ、しばしば反復的に行われます。
要求定義書で定義すべきもの
要求定義書で定義すべきものは以下の通りです。
- プロジェクトの目的
- As-Is/To-Be分析
- QCD：Quality（品質）Cost（費用）Delivery（納期）
プロジェクトの目的
プロジェクトの目的を明確にすることは、要求定義書の基礎と言えます。目的をはっきりすることで、プロジェクトの方向性が定まり、関係者が共通のゴールを理解し、ミッションを遂行できるようになります。例えば、とあるオンラインストアの開発プロジェクトでは、「ユーザーがスムーズに商品を検索し、安全に購入できるショッピング環境を提供する」という目的が設定されるかもしれません。プロジェクトの目的を定めた後、新しく参画するメンバーが増えるたびにプロジェクトの目的をしっかりと共有するようにしましょう。共通認識が持てない状況になると、プロジェクトメンバー内で不穏な空気が漂うことになり兼ねません。
As-Is/To-Be分析
As-Is（現在の姿）/To-Be（将来あるべき理想的な姿）分析は、現在の状態と目指すべき未来の状態を描き、必要とされる具体的な変化を明確にする作業です。例えば、ある企業の在庫管理システムがレガシー化してしまい、古い状態が続き、効率性が悪い（As-Is）場合、新しいシステムを導入して処理速度を向上させ、在庫の正確性を高める（To-Be）ことが目標となるでしょう。実際の開発実務では、業務フローとシステムフローをしっかりと描写し、将来どのような業務フロー/システムフローになれば、先述したプロジェクトの目的達成に近づくのかを細かく検討することになります。
QCDマネジメント：Quality（品質）Cost（費用）Delivery（納期）
QCDマネジメントは、クオリティとしての品質、コストとしての費用、デリバリーとしての納期、これら三つの要素をバランス良く管理することを意味します。例えば、新しいWebアプリの開発では、「ユーザーに高速で快適な操作性を提供し（Quality）、開発費用は5,000万円以内に抑える（Cost）、そしてリリースまでの期間は12ヶ月以内にする（Delivery）」といった具体的な基準を設定します。QCDを要求定義書に纏めることで、後々ステークホルダーとの意思疎通にも役立ちます。
要求定義の進め方とポイント
要求定義の進め方とポイントは以下の通りです。
- プロジェクトの範囲と目標の設定
- ステークホルダーとのコミュニケーション
- 要求の収集と分析
- 要求の優先順位付けと整理
- 要求定義書の作成とレビュー
- 変更管理の実施
プロジェクトの範囲と目標の設定
要求定義のポイントの一つとして、プロジェクトの範囲と目標を明確にすることが挙げられます。例えば、新しいスマホアプリの開発では、「ユーザーフレンドリーなインターフェースを持ち、高速な検索機能を提供するオンライン書店の構築」といった目標が設定されるかもしれません。その目標を実現するために必要な作業や業務を洗い出し、プロジェクト範囲をドキュメントに落とし込むことが重要です。プロジェクト範囲を大まかにお伝えすると、クライアント側が行う要求定義が始点となり、その後は開発会社が中心的に行う要件定義、基本設計、詳細設計、開発・製造、単体試験、結合試験、システム試験、受入試験、上市、そこから運用保守という流れが一般的です。自工程の要件定義について関心のある方は以下のページも合わせてご覧いただけたらと思います。
クライアント側が行う要求定義と開発会社側が行う要件定義の違いについて学びたい方はこちらの記事をご参照ください。
関連記事：要件定義の成果物とはなにか？具体的な作業内容や進め方についてシステムエンジニアが要件定よ
ステークホルダーとのコミュニケーション
プロジェクトに関わる全てのステークホルダーとのコミュニケーションは、要求定義の成功に欠かせないものと言えるでしょう。例えば、定期的に開催されるミーティングの中で、ステークホルダーから直接フィードバックを収集し、そのフィードバックを要求定義に反映させることが重要です。
開発プロジェクトは基本、中長期期間に渡りますので、定期開催される打ち合わせや会議の議事録をしっかりと作成し、誰がどのような考えを持っているか、管理するようにしましょう。また議事録をステークホルダーにも回覧することで、後々の認識齟齬の発生を未然に防止します。
要求の収集と分析
要求の収集の仕方には、様々な方法があります。例えば、ユーザーインタビューやアンケート調査を通じて、エンドユーザの潜在ニーズを掘り起こすことも有益でしょう。また新しいシステムやスマホアプリに求められるものや期待も明確になるはずです。収集した要求は、その後、重要度や緊急度、実現可能性といった指標に基づいて分析されることになります。
要求の分析も非常に重要です。可能な限り定量的に分析することが大切です。「数値」や「データ」として結論を導くことで説得力が変わるからです。ただ、開発実務においては全てを定量分析にかけることは非常に難しいです。要所要所で定性分析を活用しながら最大公約数のステークホルダー理解が取れるように心掛けましょう。
要求の優先順位付けと整理
すべての要求を同時に対応することは不可能です。そのため、要求のプライオリティ、つまりは優先順位を付けることが大切です。例えば、スマホアプリサービスのプロジェクト初期段階では、コアバリューとなり得る機能を優先し、後継フェーズの中で、追加機能や改修箇所を順次対応していく、アジャイルの要素を取り入れると良いでしょう。
要求定義書作成とレビュー
収集した要求を基に要求定義書を作成します。日経の大手企業ではWord形式（PDF形式）かPPT形式（パワーポイント）で作ることが多いです。一部細かな数値等を扱う場合にはExcelを使用します。スタートアップ企業では、KeynoteやGoogleスプレッドシートで纏めることが多いようにお見受けしています。様式・フォーマットに指定はありませんので、普段使い慣れたツールで作ることをお勧めします。
要求定義書の構成は、プロジェクト概要、プロジェクト体制図、As-Is/To-Be分析結果として現状の課題、課題一覧、機能要求、非機能要求、設計・開発要求、テスト要求、移行要求、教育研修要求、各種要求に対する自社の考えと方針、その他付随資料で作られることが多いです。
収集・分析した要求を要求定義書としてドキュメント化した後はステークホルダーのレビュー工程に入ることが一般的です。ステークホルダーがITや開発に関して詳しくない場合、要約版の資料を用意するとより良いでしょう。サマリー版があると後々メンバー間の認識合わせにも役立ちます。
変更管理の実施
プロジェクトの進行に伴い、要求の変更が発生する可能性があります。変更管理プロセスを確立することで、要求の変更を適切に追跡し、プロジェクトチームとステークホルダー間で情報を共有することができます。
まとめ
この記事では、要求定義の意味、進め方、および要求定義書の作成について解説しました。プロジェクトの目的を明確にし、ステークホルダーとの効果的なコミュニケーションを行い、要求を収集・分析・整理することが重要です。また、要求定義書は、プロジェクトの指針となる文書であり、機能要求と非機能要求を詳細に記述することで、開発チームとステークホルダー間の認識の齟齬を防ぎます。
変更管理の実施も、プロジェクトの透明性と柔軟性を保つために欠かせません。要求定義は、成功に向けたプロジェクトの基盤を築くために不可欠なステップであり、その重要性を理解することが、効果的なシステム開発への第一歩となります。
Webアプリ開発やスマホアプリ開発ではユーザのニーズや市場環境によって適切なライブラリやフレームワークを採用することが成功の鍵となります。Webアプリ開発やスマホアプリ開発のご要望がございましたら、ぜひ弊社GeNEEまでお気軽にご相談ください。お客様のニーズや将来的な事業方針をヒアリング情報を踏まえながら最適な開発手法をご提案いたします。こちらの問い合わせフォームからお問い合わせ可能です。
【注目コンテンツ】
・DX・ESGの具体的な取り組みを紹介！専門家インタビュー
・DX人材は社内にあり！リコーに学ぶ技術者リスキリングの重要性
・サービタイゼーションによる付加価値の創造と競争力の強化