プロジェクトの失敗要因として要件定義工程の問題が指摘されてからしばらく経ちますが、いまだに同じ要因の失敗プロジェクトが後を絶ちません。
このようなプロジェクトを少しでも減らすために、約20年間ITベンダーに勤め上流工程に携わってきた私が失敗しない要件定義の進め方を解説します。
ITベンダー目線になってるところはご勘弁ください。
まず結論から言うと、要件定義で最も重要なポイントは以下の３つです。
上記の理由を以下で説明します。
まず、要件定義工程の作業の関係者と内容を簡単に説明します。
要件定義工程での関係者は主に以下の３者になります。
そして要件定義でやるべきことは以下の３つです。
基本的には上から順番に実施しますが、見積りについては、システム要件定義と並行して実施することもあります。
それではこれらの作業について説明します。
前工程のアウトプットであるシステム化計画書をもとに業務要件を定義します。
ここでは、システムを意識せずに、業務としてやりたいことを定義します。
具体的には要求を一覧化します。この時、各要求事項には、優先度、対応工数（難易度）、代替手段を記載します。
一通り、記載した後に、優先度や対応工数などから、システム化する要求を決めます。これが業務要件となります。
要求の中には、システム化しないでも運用を見直すことで満たされるものもあります。
また、費用対効果で落とされるものもあります。
最終的にシステム化が必要と判断されたものが要件となります。これが「要求」と「要件」の違いです。
業務要件として決まったものは、業務フローを作成して、要件を詳細化します。
この時、異例系／特殊系のフローも漏れなく洗い出します。
よくある問題としては、通常のフローだけ定義していて、異例系／特殊系の業務のフローを定義できてなくて、後工程で、「この場合は、どうなるのか？」といった話になって、要件漏れとなって手戻りや追加工数などが発生します。
ここまでの作業は業務を知っている業務部門の担当となります。
ただ実態としては、一般的な業務フローだけを作成して、「あとは宜しく！！」っといったケースも未だに多いです。
これらは問題となっていることから、独立行政法人のIPAのソフトウェア・エンジニアリング・センター発行の「経営者が参画する要求品質の確保 ～超上流から攻める IT 化の勘どころ～」では、「要件定義は発注者の責任である」と明記しています。
システム要件定義は、業務要件を満たすために、ITシステムが持つべき機能要件や非機能要件を定めたものです。
ここからは、ユーザ企業のシステム部門の仕事になります。システム部門の体制が弱い場合は、ITベンダーが肩代わりで実施する場合も多いです。
機能要件の定義では、業務要件をもとに、システム化する内容を定義します。
具体的には、業務フローをシステム化フローにしたり、実装方式の検討を行います。
業務の内容をシステムに変換する作業で、SEとしての腕の見せ所です。
個人的には一番好きな作業になります。
非機能要件は業務要件とは別の観点での要件となります。
この特性より、業務部門はあまり関心がないことが多いですが、重要な内容なので、こちらも漏れなく定義する必要があります。
具体的には以下のような内容を定義します。
これら定義すべき内容はどのプロジェクトでも決まっているので、定型のフォーマットを作成して、全てのプロジェクトで共通に使用することをおすすめします。
システム要件定義の内容をもとに、基本設計以降の開発にかかる見積りを行います。
システム要件の各要件毎に見積りを行うことをおすすめします。
これは、要件定義工程で要件が膨らんだ時に、最終的に予算内に収まらなかったり、工期が足りないと想定された場合に、優先度の低い要件から取り下げてもらうためです。
この作業はシステム部門が主導して行います。
ITベンダーは担当するシステムについて、見積りを行います。
プロジェクト工期遅延の理由は、全体の約５５％が要件定義の問題という調査結果があります。
（(出典) 日本情報システム・ユーザー協会「ソフトウェアメトリックス調査 2016」）
要件定義に抜け／漏れがあったり、曖昧だったりすると、基本設計工程以降で問題が発覚し手戻りを起こしている。手戻り負荷は、発覚が遅ければ遅いほど指数的に大きくなると言われています。
今までで述べましたが、業務部門が要件定義に積極的でないことも未だに多いです。
これについては、最終的にできたシステムが効果のないものになるリスクがあることを伝えて、主導的に動いてもらうようにする必要があります。
それでも動いてくれないようなら、業界全体としてそのような動きであることをIPA発行の「ユーザのための要件定義ガイド」を読んでもらって理解してもらいましょう。
また、ユーザ企業自体が積極的でなく、ITベンダーに丸投げといったケースもあります。このようなケースではユーザ企業とベンダ企業の責任や役割分担が不明確のままプロジェクトが進んでいき、紛争・訴訟へと発展するケースも増えています。
SE がユーザ企業、ベンダ企業のどちらに所属しているかの比率を見ると、日本はユーザ企業 25 対ベンダ企業 75 であるのに対して、米国はユーザ企業 75 対ベンダ企業 25 と逆の比率になっている。
＜パラダイムシフト＞
システム部門は、今まで以上にビジネス視点を持ち、情報化やシステム活用を考え推進していく必要があり、変わっていかなければならない。開発技術だけではなく、ビジネス指向で経営層や業務部門と対話し推進する組織へと変化する必要がある。ベンダ企業は、お客様のビジネス課題をお客様と一緒に考え、ソリューション、ビジネス価値を提供する企業へと変化する必要がある。
システム再構築の場合、現行踏襲ということで、要件定義を軽視しがちになります。
要件定義で現行業務仕様を文章化しなと、要件を確認する運用テストで、テスト項目として何を設定すべきか分からない状態に陥ります。
今まで述べてきたように、要件定義ではやることがたくさんあります。また、その内容はとても重要な内容です。そのため、他の工程以上に十分な工期、工数を割り当てる必要があります。
ここでの工期、工数を惜しんで未決事項を残した場合、以降の工程では、それ以上の工期延長、工数増加が待っています。
いままで述べてきましたが、要件定義工程は以降のどの工程よりも重要で、ステークホルダーが協力しあって進めていく必要があります。
考慮すべき内容は多岐、多様にわたりますが、細かい内容はIPA発行の「ユーザのための要件定義ガイド 第2版 ～要件定義を成功に導く128の勘どころ～」を参照ください。こちらはPDF版が無料で公開されています。全498ページもありますが、ポイントを読むだけでも非常に有益です。あなたが、プロジェクトマネージャーであれば、ステークホルダーに配って共通意識を持ってもらうことをおすすめします。
要件定義はシステム開発において、もっとも重要な工程といっても過言ではありません。
最低でも以下の３つは守って、プロジェクトを成功に導いてください。