要件定義とは、システム開発の最初に行う工程です。システム開発の成功を左右するといわれる重要なフェーズですが、誰が何を行うのかよく知らないという声も聞かれます。この記事では、要件定義で行われる内容や進め方、要件定義の重要性、起こりがちな失敗例などを紹介します。
目次
システム開発の要件定義では誰が何をする？
システム開発には、ウォーターフォールモデル、アジャイルモデルなど何通りかの手法がありますが、どのモデルでシステム開発を行う場合であっても要件定義は必要になります。まずは要件定義の概要を説明します。
システム開発者のヒアリング
初めに行われるのは、システム開発者による発注者へのヒアリングです。対象システムの課題を整理し、開発の目的や範囲を明確にするために実施されます。
ヒアリング内では実装したい機能の聞き取りや実現の可否検討も行われ、それらを踏まえてシステム開発で行うべき内容（新規開発、改修、拡張など）が話し合われます。
システムの仕様や工数、費用の見積
システム開発の方向性をある程度固めた後、各種見積もりが行われます。
システム開発者は、行うべき開発内容から必要な工数・費用を算出し、発注者へ見積もりを提出します。工数はシステム開発にかかわるメンバー（プロジェクト管理者、コンサルタント、システムエンジニア、プログラマーなど）全員分を考慮する必要があり、費用はシステム開発の全工程に発生する各費用（要件定義費用、人件費、プロジェクトルームの賃料、端末・開発環境・サーバー関連の費用など）を割り出す必要があります。
成果物である「要件定義書」の作成
見積もりに対する発注者の同意を得ることができたら、システム開発者は要件定義書の作成を行います。要件定義書とは、主に業務要件・システム要件の2点について記載するドキュメントで、成果物として発注者へ納品されることが一般的です（業務要件、システム要件については後ほど解説します）。
システム開発における要件定義の進め方とは？
続いて、要件定義の進め方を紹介します。
既存システムの情報を集める
要件定義を行うには、開発対象となるシステムや連携システム・周辺システムの仕様や動作環境、取り扱いデータの種類や型などに関する詳細な情報が必要です。そのため、システム開発者は、発注者から連携されるドキュメント類（各システムの基本設計書・詳細設計書・改修記録など）からさまざまな情報を収集します。
ドキュメントが整備されていない場合や最新の情報が反映されていない場合は、開発対象システムを使って業務を行っている人（発注者側の社員）や保守担当者（発注者側の社員もしくは保守委託会社、前回のシステム開発担当者など）からも話を聞き、その時点での動作状況・利用状況などの確認を行います。
業務要件を明確にする
必要な情報がそろったら、業務要件の明確化を行います。業務要件とは「開発を経た後、対象システムがどのように使用されることになるのか」という点についてまとめるもので、システムを使って行われる業務のフローやプロセス、入出力データ、システムによって行われる処理の種類やタイミングなどといった内容が含まれます。
業務要件を明確化する際に重要なのは、「いつ・誰が・なぜ・どのようにシステムを使用して業務を行うのか」「どの業務やシステムと連携しているのか」という点を明示することです。そのため、業務要件はフロー図などを用いて視覚化されることが多く、必要に応じて組織図や事業区分のマトリクスなどが併記されるケースもあります。
そして、明確化された業務要件をもとにシステム要件（業務要件の実現方法、開発前後のシステムにおける機能・ユーザビリティ・アクセシビリティ・保守体制など）の定義が行われ、業務要件とともに要件定義書へ記載されます。
予算・スケジュールを組む
業務要件・システム要件の定義を受け、予算やスケジュールの検討が行われます。システム開発者は先ほど紹介したような工数・費用について見積もりを行い、システム開発終了までのスケジュールを組みます。発注者とシステム開発者との間で予算・工数・スケジュールに関する合意が得られたら、要件定義書の再確認を行い、次の工程へと進みます。
要件定義の後は、基本設計（外部設計）、詳細設計（内部設計）、開発、テストなどの工程が順に行われ、実際の運用が開始されます。要件定義・その後の工程ともに、予算やスケジュールなどにある程度余裕をもたせて見積もりを行っておけば、不測の事態などにも対応しやすくなります。
システム開発で要件定義が重要な理由とは？
システム開発で要件定義が重要と言われる大きな理由は、「プロジェクトに必要な要素を決める工程であるから」です。システム開発者側の担当者には、発注者から出された要望の実現可否や具体的な実装方法、プロジェクト全体のスケジュールやコストなどを正確に判断・提案する知識とスキルが求められます。そして、発注者側の担当者には、提案されたコスト・スケジュール・工数などにOK/NGを出せる知識や経験が必要です。
また、「後の工程への影響度が高いから」というのも要件定義が重要視される理由のひとつです。要件定義の際にシステム開発者・発注者間で認識のすりあわせをしっかり行っておくと双方に信頼関係が生まれ、その後の工程がスムーズに進みやすくなります。要件定義で課題を残してしまうと、その後のコミュニケーションや報連相などもうまく行きにくいということを覚えておきましょう。
システム開発で要件定義が失敗するケースとは？
では、要件定義が失敗に終わるのはどのようなケースなのでしょうか。多く見られる例を紹介します。
十分な知見を持ったメンバーがいない
まず、システム開発に関して十分な知見を持ったメンバーがいないケースが挙げられます。システムの仕様やプログラミングに対する知識がない、システム開発の経験が浅い、工数や予算を適切に見積もれないなどといった人が担当者になると、要件定義がうまくいかない場合があります。逆に、発注者側・システム開発者側のどちらにも知見あるメンバーがアサインされていると、要件定義が成功する可能性も高まります。
信頼関係が構築できない
要件定義中にメンバー間の信頼関係が構築できないケースも見られます。発注者とシステム開発者の間だけでなく、開発チームの構成員同士で信頼関係を築けない場合も同様です。要件定義に限ったことではありませんが、信頼関係の欠落によって正確な判断や相手への配慮が難しくなり、不当な要求・無茶な納期設定・超過労働などが発生してプロジェクトがうまく回らなくなることがあります。
工数やスケジュールの正確な見積もりが重要となる要件定義において、メンバー間で信頼関係を築いておくと「無理なものは無理」と端的に伝えやすくなるため、その後の工程が円滑に進む場合もあります。
スムーズな要件定義をサポートする「クラウドワークス」
上述のように、要件定義をスムーズに行うにはシステム開発の十分な知見を持ったメンバーが必要です。自社に適した人材がいない場合、要件定義をサポートしてくれる人材をクラウドソーシングサービスで探すという方法があります。
たとえば、日本最大級のクラウドソーシングサービス「クラウドワークス」には、システム開発の知識と経験が豊富な人材が数多く登録しています。依頼前にはスキル・職歴などを確認できるため、要件定義の経験者に絞って人材を探すことも可能です。
また、相談しながら仕事を進める「プロジェクト形式」で依頼を行えば適切なコミュニケーションを取ることができ、信頼関係が築きやすい点もメリットです。要件定義書の作成・システム開発によって発生するドキュメント修正などの業務に限定して依頼することもでき、要件定義終了後は「タスク形式」に切り替えてその後の工程を引き続き依頼することなども可能です。
▶クラウドワークスの使い方や事例、発注相場がわかる資料をダウンロードする
まとめ
要件定義は発注者とシステム開発者が合意・協力のもとに行う工程です。その後の工程を左右する重要なフェーズであり、要件定義の成功には知見や信頼関係が欠かせません。要件定義に適したリソースが不足している場合、クラウドソーシングサービスなどを活用して良い人材を探すのもひとつの選択肢といえるでしょう。
クラウドワークスのサービス資料
サービス特徴、活用事例、発注相場などを紹介しています。
【こんな方におすすめ】
・サービスを詳しく知りたい
・外部人材の活用を検討したい
・発注相場や事例を知りたい
