読者です 読者をやめる 読者になる 読者になる

そらとぶへび

仕事・プライベートを通しての気づき、JavaやPHP、データベースやサーバの話などこつこつと書いていきます

要件定義で心がけるポイント

仕事 開発


「要件定義」と 呼ばれる作業フェーズには、構築するシステムやサービスによって、様々なアプローチがあり、一般的な書式や決まったルールが存在しないため、どこから手を付けていいか悩みところです。

そうはいっても、ただ手をこまねいていては、時間・コストを消費し、品質も低下するだけです。プロジェクトを成功に導くためには、最上流である要件定義が重要であり、要件定義を成功させるためのポイントを考えてみます。

 

 

システムが作り出す、ビジネスの成果を明確にすること

システムとは何らかのビジネス成果を得るために開発・運用されます。要件定義書ではまず最初に「獲得すべきビジネス成果」を記述します。

ヒアリングを行うにあたって、ある程度の業界・業務のルールやの知識、専門用語、競合他社の状況やトレンドなどが必要になってきます。

要件定義のときにベンチマークとなるようなシステムやサービスを準備しておくと、より定義が明確になってくると思います。

またそれらを参考にすることによって良い機能はより改善できたり、同じ失敗をせずに済んだりもします。


要件を評価し、優先順位の決める

すべてのプロジェクトには期限があり、すべての要求をシステム化するのは、難しい場合があります。
その機能がないと、サービスとして成立しない、あるいは運用ではカバーできないもの、などは必ず入れるとして、多少期限の調整が効くものを、洗い出しておく必要があります。

以下のようなものが該当すると思います。
・月次、年次作業など、リリースと同時でなくてもよい機能
・運用や別のツール類でカバーが可能なもの

また、すべてをシステム化するのがふさわしくないケースもあります。
それがある場合とない場合でどれくらいコストが違うのかといった費用対効果の評価軸で判定するのが、シンプルかつ確実なものです。


機能的に難しいと感じる要件

技術的課題は、知識量の不足、もしくは、考え方が誤っているかのどちらかであることがほとんどです。
知識量が不足する場合は、ネットで調べてるなり、その分野に長けたベンダー に協力を仰いだりして、ある程度は解決できるはずです。
また、考え方を転換すれば、既存のパターンを応用する程度で解決することがあります。

それでも確証が持てない場合は、調査課題として要件定義書の中に明記して、後で解決することにします。

 

まとめ

要件定義は、どんなビジネスを実現するためのシステムなのかを軸に考え、クライアントにいくつかの指標や判断軸を提示してあげることによって、より早く確実なものとなっていきます。

なお、具体的なRFP/SLAのサンプルが、ITコーディネータ協会のサイトからダウンロードすることができます。

www.itc.or.jp