まいどフォーラム

ITコーディネータによる中小企業の企業内IT支援は、まいどフォーラムにご相談ください。


投稿

HOME > 投稿 > 失敗を少なくする為の要求定義の進め方について私なりの工夫。

失敗を少なくする為の要求定義の進め方について私なりの工夫。

1.はじめに
世の中のプロジェクトに関する本を読むと、上流工程に関して多くのことが書かれています。ITコーディネータのプロセスガイドラインも上流工程に関する比重は高く、PMBOKもまた同じように感じます。これらの傾向を考えると、IT開発や一般的なプロジェクト管理においても、上流工程の失敗が多くそれを改善するがために、この様なガイドラインが出てきたのではないかと想像してしまいます。

2.序論
システム開発を行う上で最も重要なフェーズのひとつに要求定義があげられるのではないでしょうか?少なくとも私はその様に感じます。私は製造業会社の、情報システム子会社に所属していました。ユーザは親会社の製品開発部門だったので、毎日の様に顔を合わせていたのでなあなあの関係になっていたところもあると思いますが、突然の仕様変更などは普通に発生し、プロジェクトを管理している身には痛い経験が多々ありました。
過去いくつかのシステム開発で要求定義や使用作成を行ってきましたが、プロジェクトの終盤に差しかかった時期に仕様変更が何度も発生します。要求定義書に承認印があっても変更するものは出来る範囲で変更します。情報システム子会社は、親会社の業務を向上させる為に存在するのですから。そこで、仕様変更を極力なくす方法をいくつも試してきました。その中で効果があったと思うことを紹介いたします。

3.本論
コンピュータシステムの開発で必ず発生すると言ってよいのが仕様変更です。(私だけの経験かもしれませんが)小規模な開発でも、必ずと言って良いほど仕様変更は発生します。しかもその発生時期はプロジェクトの終盤に集中している様に思います。
それはなぜかを考えたところ、ユーザは要求定義の時にすべてを話して依頼したつもりになっており、開発側はユーザが言ったことが全てだととらえます。ユーザはその後システムに対してあまり関心を持ちませんが、それが形になってデモなどで確認したときに初めて強い関心を持ち出すのです。
そして、「この機能が必要だ。」「あの機能が無いと業務が出来ない。」「今のシステムではこんなことが出来るのに、新しいシステムでは出来ないのはおかしい。」と訴えてきます。こうなると、ユーザと、下流工程を行っているプログラマーの板ばさみになるのです。この状態は非常に辛い状態です。要求定義書に承認印があれば追加要求を退けることも可能ですが、多少のことなら受け入れる事が多いのではないかと思います。
そこで、要件定義を行なう時に漏れが出ない様にする方法を考え実践していきました。

要件定義がしっかり出来ていないと、開発は何度も後戻りを繰り返します。それほどシステム開発にとって上流工程は重要なフェーズです。これを成功させる方法は、業務にかかわるユーザ達に漏れなく話させる事だと思います。これが出来れば、追加要求の数がグッと減るはずです。そこで私は以下の3つの方法を試みました。
①聞くこと、頷くことや相槌を打つこと
以前、コンサルタントの本を読んだことがありますが、同じようなことを書いていました。ユーザの言うことを否定せずに聞き、現状のシステムに対する不満や要望などを全て聞きだすのです。コンサルタントにはいろんなテクニックがありますが、私にはそんなテクニックは無いので、聞いて頷いて相槌を打つようにしたのですが、これだけでも大量の情報を引き出すことが出来ると感じました。

②相手の業務に興味を持つこと
相手の話を聞くにしても、相手の業務に興味が無ければ情報を十分引き出す事は出来ないと思います。そこで、対象ユーザの業務に関することを調べました。例えば用語、その業界に関する一般的なニュースなどです。用語を知らなければ、相手が話していることが十分理解できませんし、業界のニュースを触りだけでも知っていれば話の枠がグッと広がります。ユーザとの信頼関係を築くには有効な方法だと思います。

③相手にシステムのイメージを持たせること
私の場合、開発規模の大小にかかわらず、要件定義は複数回行う様にしました。最初のヒアリング時に聞いた内容を資料にし、図示(例えば、業務の関連図、画面のイメージなど)できるようにして、イメージを持たせる様にしました。これにより通常デモなどの終盤に発生する追加要求がこの時に出る様になり、①との組み合わせで、私のプロジェクトでは大きな成果が出ました。

これらを行う前と後では、仕様変更の数は大きく変わりました。定量的に出したいところですが、その様なデータは取っていなかったので、体感的な数字を出させて頂くとすれば、1/3~1/4くらいになったと思います。

4.結論
要求定義をする時に大事な事は、①聞くこと、頷くことや相槌を打つこと②相手の業務に興味を持つこと③相手にシステムのイメージを持たせることの3つだと私は思っています。他にも大事な事は多いと思いますが、相手にいっぱい話させる事は、要求定義をする上で一番大事な事だと考えています。

ITコーディネータ 中谷正明

このページの上へ



『経営に活かせるIT』と『ITを活かした経営』の橋渡しは‥‥まいどフォーラム