仕様の変更が発生した場面でのITエンジニアの腕の見せ所は、いかにユーザーのニーズを引き出して変更依頼の内容を的確につかむかである。思い込みで進めてはいけない。これは要件定義の勘所と共通している。優秀なITエンジニアほど自分なりのヒアリングのスタイルを持っていて、仕様変更でユーザーにものを言わせることに、非常に長けている。

 だからといって、ユーザーの言い分を真に受けてはいけない。ひっくり返されることが少なくないからだ。

 ひっくり返されるのは、システム開発におけるユーザーは1人ではないことが背景にある。例えば販売管理システムを構築する場合、ユーザーは営業部門、物流部門、システム部門、経営者と多岐にわたる。そしてそれぞれの立場でニーズを言うため収拾しづらい。一つの部門に限っても、事務担当者、課長などの立場によって、見ている世界が微妙にずれているため、聞く人によって意見やニーズは異なる。

 ここでは、筆者が知る、ITベンダーに勤めるSさんがリーダーとして携わったあるプロジェクトのケースを通じて、ITエンジニアがいちいち真に受けてしまう原因と、その対策を考えてみよう。

体制図なく詰めた仕様をひっくり返される

 Sさんたちは、キックオフミーティングでITベンダー側の体制図を出したものの、ユーザー企業側から体制図は出てこなかった。このことを気にかけつつも、翌日からユーザー企業の担当者とともに要件定義をスタートさせた。3カ月後、固まった仕様について承認をもらおうとしたところでどんでん返しを食らった。

 それまでほとんど打ち合わせに出てこなかったユーザー企業の役員から大幅な修正を命じられたのだ。結局、仕様決定が2カ月ずれ込む事態に陥った。

 キックオフミーティングは、ユーザーと懇意にするためだけのセレモニーや飲み会ではない。プロジェクトスタート時に意思決定者や意思決定プロセスを明確にする場でもある。それをしないで進めてしまうと、こんな悲劇に見舞われてしまう。

ユーザーの内部で合意されていない変更に対応する

 ずれ込んだ2カ月を経てSさんたちはようやく仕様を確定させることができた。しかし続く基本設計に着手したところ、ユーザー側から「こう変えたい」「こうしないと困る」といった変更依頼が次々と出てきた。迅速な対応をモットーとするSさんは、そうした依頼にもきちんと応えていた。

 ところがここでもどんでん返しが待っていた。あるユーザーからの変更依頼をシステムに反映させたところ、別のユーザーから「そんなのダメだ。元に戻せ。誰がそうしろと言ったんだ」と怒られてしまったのだ。部門と立場が異なっていて認められない、というのでSさんは調整をする羽目になった。

 このように、同じユーザー企業の担当者とはいえ利害が異なることは少なくない。利害関係をユーザー側で調整して合意が得たものを初めて変更依頼とする、といったルールをあらかじめ取り決めておく必要がある。

 どんでん返しのトラブルは、変更依頼を口頭で受けたときにも起こってしまうので注意したい。ユーザーから口頭で受け付けた変更依頼をITエンジニアのほうで記載すると、手間がかかるだけではなく、認識が食い違って手戻りが発生してしまう。手間がかかるので文書化されなくなってしまう危険性も高まる。

 それを回避するには、キックオフ時に変更のルールを定めて「変更依頼書」を、ユーザーに記入してもらうようにする必要がある。「すみませんが、変更依頼書に記載してください」のひとことを言う勇気がないと、後で泣くことになる。

 また、納期通りにシステムを稼働させるには、変更依頼をシステムに反映させないという判断を下す必要も出てくる。変更プロセスを決めてユーザーに守ってもらうだけではなく、ITエンジニア側も「やる/やらない」を判断してから対応するルールを、変更プロセスに含めておくようにしなければならない。

梅田 弘之(うめだ ひろゆき)
システムインテグレータ 代表取締役社長
東芝、住商情報システムを経て、1995年にシステムインテグレータを創業。前職でProActive、現職でGRANDITという2つのERPパッケージの開発に関わるほか、ECサイト構築ソフトSI Web Shopping、開発支援ツールSI Object Browserシリーズなどのパッケージ開発を手掛けている。最近は統合型プロジェクト管理システムOBPMをリリースし、IT業界の合理化をライフテーマとして活動している。