［変更管理編］コストの話を後回しにしてはいけない

　ITエンジニアとしては、スケジュールが圧迫されてコストもかさむ仕様変更はなんとか避けたい。ところが利用部門の立場で見ると、変更は正義である。仕様を変更しないよりも変更した方が、システムは良くなるからだ。それゆえ、「変更しなければ業務が大変なことになってしまう」といった、変更を求めるユーザーの説明には説得力がある。

　このとき、ほとんどのITエンジニアが用いる交渉の切り札は納期だろう。コストも切り札として有効なのに、「コストの話をするのは卑怯で汚いような気がする」と感じて、コストの話を後回しにしがちである。

　しかし、変更する/しないという交渉の場で、コストの話を後回しにしてはいけない。ITエンジニアにとって劣勢を挽回する最大の切り札はコストだからだ。「変更依頼をシステムに反映させるとしたら、これだけコストがかさむ」という反撃をすると、ユーザーはひるまざるを得ない。

　そもそも納期は、交渉をする切り札としてはもろい。ITエンジニアの「それを受けると納期に間に合わなくなります」という言葉は、時としては有効だが、ユーザーから「そこをなんとかお願いします」と切り返されやすいからだ。

　筆者が見たところ、コストという切り札を交渉に使っているITエンジニアがいても、有効に使えていないケースは多い。ITエンジニアであるIさんとKさんの二つの事例を基に、どうすれば有効に使いこなせるかを考えてみよう。

変更してからコストの話をして泥沼化

　Iさんはユーザーの立場でものを考えることができることから、ユーザーからの信頼が厚い。Iさんがあるプロジェクトを進めてゆく中で、これまでに決めた仕様に対して変更依頼が次々と出てきた。Iさんは、個々の変更に対して必要性を確認しながら変更依頼を一覧にまとめた。その一覧に基づいて、変更作業によるスケジュール遅延を抑えるためにメンバーの増員という対策を講じ、納期に間に合うようにシステム稼働にこぎつけた。

　本番稼働を無事に済ませたIさんは、変更依頼を実施する際にかかる追加請求額の見積もりを作成してユーザーに提出した。その追加請求額を見たユーザーはびっくり。「こんなにコストがアップするなんて思ってもみなかった。なんで早く言わないんだ。こんな膨大な金額、払えないよ」と怒り出した。その後、両社の交渉は泥沼化。ユーザーとIさんの関係も悪化してしまった。

　仕様変更には、「必要性」と「変更コスト」という二つのパラメーターが伴う。ユーザーは仕様変更の必要性は十分認識していても、変更にかかるコストがどれくらいかは分からない。システム開発の経験が浅いので、ITエンジニアからコストが示されなければ変更すべきかどうかは判断できないのだ。コストがかかる割に必要性が低いと分かったとき、ユーザーは「そんなにかかるなら、このままでいいや」と判断できる。しかし、コストを伝える前にITエンジニアが良かれと思って変更作業を先行させると、こんなトラブルに見舞われてしまう。

コストの話を後回しにする

　Iさんの失敗を耳にしたKさんは、「自分はそんなへまはしない」と心して別のプロジェクトを進めている。ユーザー企業の各利用部門から次々と出てくる変更依頼をリストにまとめるのはIさんと一緒だ。しかしKさんは、「再見積もりの結果を基に変更作業に着手するかどうかを決めましょう」と、ユーザーとあらかじめ取り決めている。

　Kさんは変更依頼が一段落した2カ月後、これまで出てきた変更依頼それぞれにかかるコストを算出し、ユーザーに提示した。出された変更依頼のどれをやるか、ユーザーに判断を仰ぐためだ。

　Kさんから示された金額を見たユーザーは「えっ、こんなにかかるの？」と驚いた。「今さら優先順位をつけろって言われても削れない。下手に削ったらちゃんとシステムが回るのか心配だし、削ってしまったらそもそものシステムの導入効果が出るのか疑問だ」と言われて揉めてしまった。

　冒頭で述べたように、ユーザーにとって仕様変更は正義である。ユーザーが正義を語るとき、ITエンジニアは「はい、はい」と耳を傾けるものだ。実はこの段階で、ユーザーの頭の中では「伝えた仕様変更は、必ず実現される」というイメージが構築されてしまう。それなのに2カ月後にリストを見せられて、「あれもこれもやるとコストがかかりすぎるから、どれかを諦めてください」と言われたら、夢が一気にしぼんでしまう。そして、「実現するはずだった仕様変更がふいになった」と逆上するのだ。

　こうした事態に陥らないためには、二つの取り組みが必要である。一つは、変更リストにコストと優先度（必要性）の項目を設けて、変更依頼ごとに記入すること。もう一つは、週1回くらいのペースでITエンジニアからコストを提示して、ユーザーに実施するかどうかの判断を仰ぎながら進めることだ。

　ユーザーにとって、コストの話をするのは嫌だろう。ITエンジニアは忙しいので、コストの確認と提示を後回しにしがちだ。しかし、後でドカンとまとめてコストを出して揉めると、もっと大ごとになる。できるだけこまめにコンセンサスを取りながら進めていこう。