IMARI20160806220208_TP_V-2

システム開発において、最初に行うのが「要件定義」の工程です。要件定義は、ユーザー業務のどの部分をシステム化するか(システム要件)について決めるものです。どのようにするのかというと、システムを使う側である「ユーザー」とシステムを開発構築する側である「ベンダー」が打合せを行い議論を重ねることによって行います。

ここでは、システム開発プロジェクトにおける要件定義の重要性についてお話ししていきます。ここで述べる内容を理解し実践することで、システム開発における要件定義フェーズを十分な品質で完了させることができます。それによって、後工程での手戻りをなくすという効果が期待できます。そして、プロジェクトの成功確率を大幅に引き上げることができます。

要件定義では、システム化の範囲を決定する

要件定義は、たいていのシステム開発で最初に行う作業です。そして、以後の開発作業量を大きく左右する決定事項がもっとも多く含まれるのが特徴です。

例えば要件定義の後工程において、それまであまり発言していなかったユーザーの一人が「そう言えば、今まで出て来なかったけど追加でこういった機能がほしいな」と言ったとしましょう。システム開発では多くのユーザーとベンダーが集まり長期間に渡って打合せを行うため、実際にこのようなことはよくあります。

その要望の機能を開発するかどうかを決める判断基準が、「要件定義で決定したシステム要件に含まれているかどうか」なのです。要件定義で決定したシステム要件に含まれない機能は、「システム化の範囲外となる要望のため、本プロジェクトでは却下、または変更要求による追加費用請求」となるのです。

それでは、要件定義での話に出なかった要望がすべてシステム化の範囲外になるかというとそうではありません。

ユーザーは、システム開発経験が少ないのが当たり前です。そのため、「この機能を作りこんだ場合、別の機能にデメリットが生じる」とか「ある機能と別の機能の2つを組み合わせて使うと、画面の切り替わりに時間がかかるようになり業務に影響を及ぼすかもしれない」といったようなことはユーザー自身ではまずわかりません。

したがって、システムを開発するベンダーは上記のような懸念事項や疑問点についてユーザーに開示説明する義務があります。そして、ユーザーを適切にリードしていくようにします。こうして、すべての懸念事項や不確定事項についてユーザーとベンダーが話し合いを行い最終的にシステム要件を具体化していきます。

このように、要件定義ではユーザーとベンダーが向き合いユーザーの業務洗い出しとシステム化の範囲を決めていきます。ここで検討漏れがあると、あとで機能設計を行うときに手戻りが発生してプロジェクトの遅れにつながってしまうこともあります。

失敗プロジェクトの9割は、要件定義での品質の問題が原因であるとも言われます。そのため、要件定義はシステム開発プロジェクトにおけるもっとも重要な工程であると言えます。

ユーザーとベンダーで徹底的に議論する

それでは、要件定義の工程をあとで手戻りが発生しないように十分な品質で完了させるにはどのようなことに心がけたら良いでしょうか。

それは、「ユーザーとベンダーで徹底的に議論する」ことです。言い換えれば、ベンダーはユーザーの言いなりになって良い顔をしているだけではいけませんし、ユーザーはベンダーに任せきりでもいけません。

ユーザー業務についてはユーザーの方が圧倒的に詳しいのが普通です。そのため、要件定義においてベンダーはユーザーの言いなりになってシステムを作ってしまいがちです。

しかし、ユーザーの言いなりになって作られたシステムはまずまともなものになりません。なぜなら、ユーザーはシステム開発やプロジェクト管理のプロフェッショナルではないので、ユーザーの頭に「実際のシステム」のイメージを正しく持っていない状態で話をしなければならないからです。

その結果、実際のシステムが出来上がったあとになって「この機能は、思っていたものと違う」とか「このシステムは使えない」との評価になってしまうのです。

そのようなことにならないために、要件定義の工程ではユーザーとベンダーで徹底的に議論して検討漏れをなくすことが必要です。

ときには、ベンダーがユーザーに代わって「業務のこの部分は、このように変えた方が効率的ではありませんか」と提案したり、ユーザーが「この期間で、本当に開発が間に合うの?」とベンダーに対して見解を求めたりといった姿勢が求められます。

ユーザー・ベンダーのお互いの役割を超えた発言のようになってしまいますが、要件定義の議論では、時には役割を超えた発言も重要になります

ベンダー内も結束すること

さらに、ベンダー内でも営業担当やプロジェクト担当で意見を統一し結束することが大切です。営業やプロジェクト担当が各自でわがままなことを言っていると、プロジェクトは必ず失敗します。

なぜなら、要件定義はユーザーの仕様変更要求が多く発生するフェーズです。仕様変更に対応する場合、追加費用や期間が必要になりますがユーザー企業との関係悪化を懸念してそのような追加費用の請求を嫌がる営業担当もいるのです。

プロジェクトの開始段階において、ユーザーの仕様変更に対する方針を定めておき営業とプロジェクト担当が上手に結束できるような体制を作るようにしましょう。ベンダーの営業とプロジェクト担当の間でわだかまりがあれば、その他の関係者に対しても迷惑をかけてしまいます。

このように、システム開発プロジェクトでは要件定義がもっとも重要になります。要件定義の作業品質を上げることが、プロジェクトの成功率を高めることにつながります。要件定義で大切なことは、ユーザーとベンダーがそれぞれ意見を出し合い相手に任せきりにしないことです。

特にベンダーは、要件定義でシステム化の懸念事項や疑問点をそのままにせず、あとでシステム要件の検討漏れが発覚することのないような姿勢で臨むようにしましょう。