登場人物
名前： スーさん。(SUさん)
仕事： 神戸のソフトウェア会社W社でSEをやっている
最近の楽しみ：実写版の映画「東京喰種トーキョーグール」を見る予定があること。早くトーカちゃんを見たい！
名前： ター坊
仕事： 無職。仕事を探している。
最近の楽しみ：「幸せのパンケーキ」でパンケーキを食べる予定があること。早くプレーンの「幸せのパンケーキ」を食べたい！
ある日のこと。。。。
あ～、エスイーね。
SEの仕事内容って、これのことだね。
エスイーの仕事。
意外とター坊って向学心があるんだね。
いつまでも親からお金もらって、「幸せのパンケーキ」食べるわけにもいかないし。。
早く、「セ」になって仕事を覚えないと。
前回、SEの仕事、仕事内容とシステム開発ライフサイクルをわかりやすく解説しました。
ただ、ター坊には、内容がちょっと難しかったでしょうか。
それでは、今回は、要件定義に絞って解説してみましょう。
まず、要件定義と同じ場面でよく使われる 要求仕様 について解説します。
要求仕様 (Requirement、リクワイアメント ) 、要求仕様書とは
要求仕様書とは、エンドユーザーが開発担当側に対して開発を依頼するシステム要件を文章化したものです。
こういったことがしたい、という要求と予算、開発体制、リリース時期などの記載が主で、多くの場合、実現方法が具現化していません。
要求仕様、要求仕様書は、実現性が低いものでは困りますが、あくまでユーザー側の要求なので、基本的にユーザー側は好きに書いても構いません。
要求仕様書は、システムを使う側からの要望を書き留めたドキュメントであり、エンドユーザーが、開発の結果、得る機能をまとめたものとも言えます。
要求仕様書は、要件定義よりも前の段階でエンドユーザーがまとめるのが普通ですが、
一方で、要件定義の段階で、エンドユーザーではなくて、SEがまとめることもあります。
また、システムによっては、要求仕様書の作成は行わずに、要件定義の段階で、要求仕様も含めて要件定義書として一つにすることもあります。
次に、要求定義と同様に要件定義の場面でよく使われる RFP について解説します。
RFP ( Request For Proposal、提案依頼書 ) とは
RFPとは、Request For Proposal (提案依頼書) の略で、発注企業がシステム開発を行う際に必要な要件をまとめ、発注先の開発会社に具体的な提案を依頼するための資料のことを言います。
RFP は要求仕様を元に、エンドユーザー側で作成し、ベンダー側に提示します。
RFPでは、システム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出します。
RFPには、エンドユーザーが必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証用件、契約事項などを記述します。
業者側はRFPをもとに提案書を作成します。
そして、発注元は業者の提案書を評価し、契約する業者を選定し、ハードウェアやソフトウェア、サービスなどを調達します。
一般的に、市役所や学校、消防署、警察署などの公的なシステム開発では、RFP に基づき、複数のベンダーがシステムを提案します。
それではいよいよ、要件定義について解説します。
要件定義、要件定義書とは
要求仕様、RFPの作成までは、エンドユーザー側の作業でしたが、要件定義ではいよいよ、SEの出番です。
要件定義とは、エンドユーザー (お客様) が実現したい機能を、システム的にまとめることを言います。
ここで大事なことは、先ほどのエンドユーザー側が要望を書いた要求仕様書と事なり、要件定義書は、システムを理解しているＳＥがシステム的に要件をまとめるます。
また、要件定義で作成した成果物、ドキュメントのことを要件定義書と言います。
要件定義は、システム開発のライフサイクル (System Development Life Cycle、SDLC) の最初の工程です。
要件定義の工程を上流工程と呼ぶこともあります。
この工程では、開発担当のSEは、ユーザー部門から要求を引き出し、システムに実装するべき機能を整理します。
要件定義は、設計、実装工程の前工程として行われ、
ユーザーがそのシステムで何をしたいのか、
なぜそのシステムが必要なのか、
システムの目的（要求定義）に基づき分析、検討を行い、
その実現のために実装しなければならない機能や性能などを明確にしていきます。
この工程では、プログラム開発などは行わず、複数回の打ち合わせによって成果物、要件定義書を作成します。
エンドユーザーは、システムに求める要求をより具体的に示す必要があります。
システム開発サイドは、それを正しく理解して、機能や性能といった技術的な要件にまとめていく必要があります。
ユーザーサイドと開発サイドの最初にして、最も重要なコミュニケーションということができるでしょう。
SEは、整理した内容を基に業務フローや業務シナリオ、データモデルなどを作成し、ユーザー部門と認識に食い違いがないかを確認します。
ところで、要件定義の成果物、要件定義書には何が含まれるべきなのでしょうか？
要件定義書の中身を見てみましょう。
要件定義書の中身
要件定義書は、システム設計者側から見た、ユーザーからの要望に応えるための機能を書き止めたドキュメントです。
要件定義書は、システム開発プロジェクトにおける要件定義フェーズのアウトプットとなるドキュメントであり、機能要件、非機能要件など、後工程の設計に必要な情報を記述します。
よって、「要件定義書の内容」＝「クライアントに確認する成果物」であるとも言えます。
よくある要件定義書の中身は以下の要素で構成されます。
・システムの概要／システムの構想
・機能要求
・入力要求と出力要求
・システム導入後の業務フロー
・品質・性能要求
・セキュリティ要求
・システム導入の目的と目標
要件定義で特に重要なポイントを見てみましょう。
要件定義のポイント
要件定義では、エンドユーザーがシステムに求めるものを明確にし、システム開発側がそのユーザーの求めるものを理解するため、エンドユーザーとシステム開発側の認識合わせをする重要な工程です。
従って、この工程でのコミュニケーション不足や目的を曖昧にすることは、開発の失敗につながりかねません。
なぜなら、後工程は、すべてこの工程で作成したドキュメントに依存して作られるからです。
そこで、要件定義において、特に重要な点をまとめると、次の3点になります。
・エンドユーザーがシステムに求めるものを明確にするために、そのシステムで何がしたいのか、なぜそのシステムが必要なのか、具体的に想像し、定義させること。
・エンドユーザーとシステム開発側の間で十分に話し合い、上記のようなシステムに期待すること、役割、目的の情報を共有化し、しっかりとした認識の統一、相互理解を深めること。
・システム開発側は、上記のような要求の理解に基づき、システムの目的に沿った機能や性能を要件として定義すること。
失敗するプロジェクトを分析してみると、要件定義において目的が明確になっていないことや、エンドユーザーとシステム開発側の意識合わせが不十分であることが、原因であることがよくあります。
したがって、要件定義では、エンドユーザーとシステム開発側が、求める要求と必要となる要件について、徹底的に議論し話し合うことが必要となります。
これまで書いたように要件定義において、
プロジェクトの目的を明確にし、ユーザー、開発両者の意識を統一することが、
「目的のぶれ」「仕様の変更」「仕様の追加」といったシステム開発失敗の原因をなくし、
プロジェクトを成功へと導くことが可能となります。
まとめ
いかがですか？
要件定義フェーズ、要件定義書について理解してもらえたでしょうか。
要件定義局面は、そのあとに続く工程の第一歩であるために、このフェーズでの取りこぼし、齟齬は、後の工程で取り返しの付かないことになります。
従って、要件定義は、システム開発ライフサイクルの工程の中で最も重要な工程と呼んでよいでしょう。
要件定義は難しいです。
以下に書かれているオレゴン大学の実験の風刺画が物語っていますね。
要件定義は難しい。システム開発が失敗する理由、顧客が本当に必要だったもの。
これってやりたいことを書けばいいだけでしょ？
これをRFPにしてベンダーに発注すればいいんだね。
さて、ター坊は無事に要件定義フェーズを理解してくれたのでしょうか。。。？
この続きは、コチラです。