［変更管理編］変更指示だけを伝えてはいけない

　仕様変更の指示は、“ウォーターフォール”で流れる。ここでいう“ウォーターフォール”とは、ユーザー、開発側で要件定義を担当するITエンジニア、基本設計・詳細設計を担当するITエンジニア、プログラマ、という変更指示の流れを指す。その流れでの力関係は、ユーザーが最も強く、プログラマは弱い、というものだ。つまり、仕様変更の指示は、力関係の強い方から弱い方に一方的に流れることになる。

　このとき、力関係が強い立場にある者は弱い立場にある者に対して、変更指示だけを伝えてはいけない。それでは、指示を受ける力関係の弱い者が、心の中で納得しないからだ。

　相手が機械ならば、変更の指示だけで問題はない。しかし、現場で仕様変更の指示を受ける開発者は、感情を持つ生身の人間だ。仕様変更だけの指示を受けると、「いったん指示されて作ったものを変更しろと言われるのは理不尽だ。勘弁してほしい」と感じがちになる。その感情は作業効率に大きく影響し、生産性が確実に下がる。

　人は力の強い立場にあるとき、力の弱い者への配慮が及ばなくなることが多い。忙しいときはなおさらである。変更だけを伝えると、生産性が低下するばかりではなく手戻りも発生しがちだ。変更の指示に加えて何を伝えればよいのかを、二つの事例を基に考えてみよう。

目的なしの指示で手戻りが発生

　優秀なプログラマのMさんは、経験と技術力が買われ、あるプロジェクトでプログラマの取りまとめ役を任されることになった。ユーザーと上級SEが協議した結果、実現することになった仕様変更の内容を、他のプログラマに伝える役割である。

　Mさんは責任を持って、仕様変更の内容から、どの画面のどの項目をどう直すかを十分に検討した上で、他のプログラマに的確に指示していった。

　仕様変更を始めた当初、作業は効率良く進んだ。ところが仕様変更作業の後半になって雲行きが怪しくなってきた。指示した変更による影響で、別の不具合が表面化してきたのだ。変更を指示する際、本来ならば影響が及ぶ別の箇所も変更しなければならなかったのだが、その対応が漏れていたのである。この場合、別の箇所の変更を指示しなかったMさんのミスになってしまった。

　このように、Mさんがたとえ優秀であっても、変更に伴って影響が及ぶ箇所を洗い出すのは難しい。1人でなんでもこなそうとすると、こういったミスを招いてしまうものだ。

　そこでプログラマに、変更箇所だけではなく、変更する背景や目的も併せて伝えるとよい。背景を説明する分、時間は多くかかるが、この変更が何を目的としているかを説明し、プログラマが変更の意図を理解して作業できるように気を配ることが大切だ。

　例えば、受注入力画面に「客先希望納期」という項目を追加する仕様変更を伝えたとしよう。画面のここに項目を追加し、受注日より後の日付しか入らないようにし、受注伝票や出荷指図書にも印字を追加する、というように具体的に変更内容を指示すればプログラマはその通りにやってくれる。しかしそのとき、希望納期の早い受注を優先するためという目的まで伝えておくと、「じゃあ、商品入荷時に入荷待ちだった受注伝票への引当処理は、受注日順でなく希望納期順に変更しなければならないのでは？」と、指示漏れを指摘してくれることが多い。

理由を伝えないと険悪ムードに

　Jさんはあるプロジェクトで、ユーザーと仕様の打ち合わせを行い、その内容を基にメンバーのITエンジニアに指示を出し、設計書を作成する流れで作業を進めている。

　仕様の打ち合わせを続けていると、当然のごとく、固めた仕様の変更依頼が出てきた。こういう場合に備えて、Jさんはあらかじめプロジェクトで1割程度の作業バッファーを確保。Jさんはバッファーの余裕を見ながら、優先度の高い依頼だけを変更対象にするように、ユーザーと交渉を続けた。その交渉で実施が決まるとすぐに、メンバーへ変更指示を伝えた。

　しかしプロジェクト内のムードが険悪になっていった。メンバーたちは、「Jさんが簡単にユーザーから変更を受け付けるから、残業が増え、スケジュールが遅れた」と、感じるようになっていたのだ。

　Jさんも疑心暗鬼になってきた。「優先度の高い変更依頼に絞って、メンバーに変更を指示しているのに、自分の努力が伝わらないのは、彼らのやる気がないからだ」と思うようになったのだ。

　なぜこんな状況になったのか。それは、Jさんが変更指示を伝えるとき、「なぜこのような変更をしなければいけないか」「変更しないとユーザーがどう困るか」といった変更理由をきちんとメンバーに伝えなかったからだ。

　指示を受けたメンバーは、「ただでさえ忙しいのに、せっかく作ったものを変更しなければならないのは嫌だ。できれば変更したくない」と思っていた。ときには、変更指示を出すJさんが憎々しく見えてしまっていたのだ。

　変更理由を併せて伝えておけば、メンバーは仕方がないと思って受け入れてくれるかもしれない。メンバーが「自分が変更に応じなければユーザーが困るんだ」と納得した上で変更作業を行えば、納得しない場合に比べてはるかに効率が良いし、モチベーションも低下しにくい。リーダーが自分ばかり納得するのではなく、メンバーたちにも同じ納得を共有するように変更理由をきちんと伝える必要がある。