TOP > ブログ > [5分で分かる」要件定義とは?要件定義書サンプルあり|オフショア開発を失敗しないように必見|

[5分で分かる」要件定義とは?要件定義書サンプルあり|オフショア開発を失敗しないように必見|

20/12/2021

システム開発において最も重要な「要件定義」。開発におけるトラブルは多くのケースにおいてこの「要件定義」に原因があると言われています。このテキストでは、開発を成功させるために必要なポイントを解説します。要件定義の概要、要件定義の流れ、要件定義のスムーズに進め方とポイントを次々に紹介します。オフショア開発の失敗を防ぎたい方へぜひ最後までお読みになってください。

 

要件定義の概要


  • 要件定義とは?

システム開発を行う上で、「何をどうシステム化するのか」を決めるのが要件定義です。要件定義書は一般的にドキュメント形式で制作されます。

要件定義は、お客様の要求定義をいかにシステム化していくかを定義するものです。お客様の要求にある動作やそれに伴って、発生する可能性があるエラー動作まで想定して、一つ一つをプログラムの動作でイメージする必要があります。

 

  • オフショア開発プロジェクトで要件定義の役割

何をどうシステム化するのか」を決める要件定義はプロジェクトで非常な役割があるものです。要件定義は、プロジェクトの残り部分の基本となり、ユーザーの期待に応えられるかどうかを決定する重要な役割を果たします。そのため、何よりもまず自分の意図や開発の取引先と共有するのが求められます。

 

 

上流工程と下流工程とは?


  • 上流工程はシステム開発・設計において最初に行う初期の段階のことです。

システム開発では、要件定義から詳細設計までを上流工程と言います。上流工程は「要件定義」、「機能定義」、「構成管理」、「計画立案」など工程が含まれます。システムの作り始めを上流、システム構築完成までを下流と言います。滝をイメージから作られた用語です。

上流工程には、設計物の品質や方向性を決める重要な役割を果たすと言えます。

 

  • 下流工程はプログラミングからテストまで

下流工程は上流工程で決定された機能、仕様、プログラミング言語を活用して、システム開発や実際の製造を行う階段です。

下流工程では、「実装(コーディン))」「テスト」「導入」様々な要件があります。実装(コーディング)では、決められた機能・プログラミング言語通り開発し、テストでは、完成した機能が想定通りに実際に動いて、レスポンスを返すかどうか何回もチェックし、導入は、本番環境へリリーズし、クライアントの環境で実際に動作するのかを確認する工程です。

上流工程と下流工程は深い関係があります。上流工程で、定義された内容を作り、下流工程で、その通り、開発してテストします。プロジェクトを成功に導くには、上流工程からきちんと行う必要があります。特に要件定義からきちんと行わなければならない。

 

 

要件定義の基本的な流れはなんですか


  • ユーザー(クライアント)の要求のヒアリング

要件定義の最初の大切なのはユーザー(クライアント)の要求をヒアリングです。なぜかというと、この段階でオフショア開発の取引先はシステムの全体像を把握するからです。どのような目的があるか、どのようなシステムを求めているのかをお互いに積極的に意見交換しなければ、認識ずれでプロジェクトでミスが発生する可能性があります。もし下流工程でミスが発生すれば、フィックスするのが非常に難しく、時間がかかり、締め切りに間に合わない恐れがあります。そのため、積極的に意見交換を行うの必要があります。

 

  • 要求の細分化

システムの全体像が把握できたら、実際のプログラミングにおける、機能の一つ一つを、細分化して要件としてまとめていきます。ユーザーの業務フローの詳細を把握し、全てが一つのシステムとして動くように、実装すべき機能を洗い出すことが必要です。機能範囲が明確でなければ、システム開発の途中で、「仕様バグ」が発生し、手戻りが時間がかかります。最悪の場合はプロジェクトの失敗を招く原因となってしましますので、要求についてきちんと相談するのが非常に重要です。

 

  • 要件定義制作

要件の機能を細分化できたら、いよいよ要件定義書の制作です。要件定義で書き出すドキュメントの内容は、要件定義後の工程でえある「システム設計」に落とし込む前段階です。要件定義のおかげでオフショア開発のプログラマーチームはシステムの全体像を把握できますので、システム運用開始後の保守まで影響を与えますため、システム的な矛盾が出ることは許されませんし、ユーザーとの意識合わせが必須となります。

 

  • 要件定義において重要な用語と進め方のコツ

要件定義には、業務要件、システム要件、機能要件、非機能要件という理解すべき用語があります。

それぞれのフェーズをスムーズに進行させるためのコツを紹介いたします。ご参考になれば幸いです。

 

 

業務要件とは?


業務要件とは要件定義の初期に実施する工程です。業務要件のフェーズでは、システム化に先立って現状の業務がどのように流れているかを分析し、質問を抽出した上で、新たに何を実現すべきかを決めていきます。業務要件では、業務に詳しい担当者に参加してもらい、密度の高いコミュニケーションを図るのが非常に大事です。もし発注者と開発者の目的が合わないまま開発を開始してしまうと、手戻りが発生して、時間とコストの無駄につながります。

 

 

システム要件とは?


この段階で、どのようにシステムに落とし込んでいくかを決めます。

この段階で決められる、システム開発の方向性をシステム要件を言います。業務要件とシステム要件はややこしいと思う方がいらっしゃるかもしれません。業務要件では、「業務上の要望」を、システム要件では、「システム化を通じてできること」を決められます。たとえば、業務要件が「取引先の地名を調べられるようにしたいです」。これに対するシステム要件は、「ノートPCからブラウザ経由で検索できること」や「スマホのアプリで使う」などのことになります。、また、業務要件の中にはシステム要件の対象から外れるものもあります。そのため、発注者と開発者の間にギャップがあることが少なくないです。

 

 

機能要件とは?


システム化の方向性が決定されると、システムに必要な機能を決めます。

機能要件はシステム開発を通じて最低限実現すべき機能です。機能要件はヒアリングの階段でお互いにきちんと相談するのが必要です。

 

 

非機能要件とは?


機能要件はシステムを通じて最低限実現すべき機能であり、非機能要件は発注者が「あればいい」と考える要件です。たとえば システム画面の切り替え速度などの性能要件がよくあげられます。もちろん。非機能要件を実現すれば実現するほど満足ですが、予算や納期を意識しつつ、開発者の会社と合意形成を図るべきです。

 

 

まとめ


本記事では、システムオフショア開発では非常に大切な「要件定義」について解説いたしました。

要件定義をきちんと行われば、オフショアシステム開発を失敗させないようになります。オフショア開発を検討している方はぜひご参考になってください。オフショア開発の会社は要件定義がないこともありますのでオフショア開発を検討している方へ要件定義サンプルをご用意いたします。ぜひダウンロードししてご参考になってください。

 

 

要件定義ダウンロード

Tags: