支援対象地域:札幌、仙台、関東、愛知、関西、広島、福岡

  • TOP
  •   
  • コラム
  •   
  • プロジェクトの成功を左右する、要件定

はじめに

ウォーターフォールモデルの進め方は以下のとおりです。

[要件定義]→[設計]→[ソフトウェア構築]→[テスト]→[導入]

上記の進め方のように、特にウォーターフォールモデルにおいて要件定義は最初の工程であり、ここが完了しない限り、次の工程に進むことはできません。仮に要求の変更により、前の工程の戻る場合は開発効率が著しく低下します。

家で例えると、設計どおりに大工さんなどが建設を進めている途中で、「庭をもう少し広くしてほしい」や「和室を狭くしてリビングを広くしてほしい」といった変更を要求することと同じです。その変更を実現するには、家の構造の変更も必要となる場合があります。

このようにシステム開発において、要件定義は重要な工程です。そこで本記事では、その進め方を紹介します。

要件定義工程の進め方とその注意点

要件定義工程における成果物は、業務要件や機能要件、非機能要件の定義をまとめた要件定義書です。これを作成するまでには、次のような進め方で各ステップを踏んでいきます。

要件定義工程の進め方

1. プロジェクト全体の方針決定

ここは、要件定義をはじめるための事前準備です。要件定義より上位の企画工程で、システム化構想の立案および、それを具現化したシステム化計画が策定されている場合は、それを引き継ぐだけで問題ありません。しかし、そうでない場合は、ヒアリング調査などの前に次のような事などについて確認しておく必要があります。

  • 開発スケジュール
  • 開発における組織・体制
  • 概算コスト
  • 解決すべき課題
  • 目的や目標とその費用対効果
  • 目的や目標を達成するための手段や方針

2. 業務要件の定義

業務要件定義の進め方は以下のとおりです。

現状の整理

クライアントが求める理想像を実現するには、その理想像に至るまでの課題を明確にする必要があります。そのためには、現状と理想像との差(ギャップ)を理解する必要があるため、現状の整理が大切です。この整理では現状の業務だけでなく、既存のシステムがある場合は、そのシステムの調査も必要です。

現状を把握してクライアントとの共通認識を形成するにあたっては、業務フローなどを用いた対象業務のモデル化(可視化)といった手法があります。

ヒアリング調査

ヒアリング調査では、その次のステップである問題の分析のために、クライアントが抱える現状の対象業務の問題点やその原因を探ります。そのためには、例えば次の内容を把握できるような質問をします。

  • 現状の業務における問題
  • 問題が生じる原因
  • 問題によって引き起こされる悪影響
  • 問題に対する現状の対応方法
  • 既存のシステムで満足している部分
問題分析と解決策の検討

ヒアリング調査の結果を基に対象業務の問題を分析します。例えば、問題が起きる原因について、「その問題が起きてしまう具体的な事象」を基に深堀りして、実際に解決が必要な問題点を洗い出します。

その後、問題分析で判明した問題点について、システムだけでなく、設備などのハードウェアや組織、制度といった、多角的なアプローチで改善・解決策を検討していきます。

新たに構築する業務の明確化およびシステム化範囲の確認

改善・解決策を反映した、新たなシステム導入後の業務フローを、クライアントとの間で共通認識が持てるように明確化します。一方で、クライアントの当初の予算と比較しつつ、ここで決定したシステム化の範囲を確認します。

3. システム要件の定義

これまでの業務要件はエンドユーザーの視点で定義してきましたが、システム要件はエンジニア視点で定義していきます。ここでは、まず業務要件の定義で確認した、システム化を行う範囲を基にプラットフォームの再検討を行います。その後、機能要件と非機能要件について定義します。

機能要件の定義

機能要件とは、クライアントが求めている機能のことです。例えば、業務で扱うデータの種類や構造、処理内容、ユーザーインターフェース、帳票などの定義を行います。

非機能要件の定義

非機能要件とは、パフォーマンスや信頼性、セキュリティなど、機能面以外の要件全般を指します。そのため、その内容は多岐にわたりますが、情報処理機構(IPA)の「非機能要求グレード」では、これを大きく6つに分類しています。それらの項目を実現することで、クライアントの満足度を高めることができます。

以上の3つのステップが完了した後、要件定義書の作成や見積もりの算出などを行います。

要件定義工程の進め方における注意点

見切り発車はしない

特にウォーターフォールモデルの開発手法では、上流工程の遅れによって、下流工程にしわ寄せがいく場合もあります。こういった焦りなどから、要件定義を中途半端にしておくと、全体の方向性が揃わず、プロジェクトが失敗してしまう可能性があります。

しかし、要件定義工程がスムーズに進まない場合もあります。この対策としては、ステークホルダー間で合意の下、要件定義の完了基準を決定する方法があります。

分かりやすい要件定義書の作成

クライアントによっては、IT分野の専門知識に乏しい場合もあります。これを踏まえ、専門用語などの使用は極力避け、クライアントやエンジニアを問わず、要件定義書から同様の完成形のイメージが抱けるように、分かりやすく要件定義書を作成する必要があります。

もちろん専門用語に限らず、「短時間」や「多数」をはじめとする、人によって解釈に差が生じる表現も具体的な数値に置き換える必要があります。

まとめ

本記事では、要件定義工程の進め方とその注意点について紹介しました。要件定義工程は、クライアントの要望を把握して、新たに構築する業務やシステム化の範囲などを明確にする工程である一方で、その後の工程の進め方にも影響を与える重要な工程です。IT分野を目指している方は、こういった内容も理解していく必要があります。