今回は顧客折衝に関する課題を取り上げる。プロジェクトを大きな混乱なく推進するためには、顧客に色々な場面でお願いしなければならないことが多い。当然、すべての請願が認められるほど簡単なことではない。折衝相手とお願いするタイミングを見極めると同時に、しっかりした論拠を持ち誠意を持って折衝することが、少しでもいい成果を引き出す道である。
顧客へのプロジェクト状況報告や各種請願、新システムの提案などにおいて、そのために用意する資料は、顧客担当者の上司にもそのままで通じるよう記述することが肝要である。
一般に顧客の担当者は、ベンダーから聞いた説明を幹部用に書き換えたり追記したりするものだが、もしベンダーが用意した資料に何の手も加えずに上司に提出できるなら、担当者の手間は省けるし、報告される情報に間違いも生じないはずだ。あるべき資料は、「顧客担当者がその上司にそのままで説明できる資料」である。
ロボット工学の権威である金出武雄氏は、その著書『素人のように考え、玄人として実行する』（PHP研究所刊）において、「上手なプロポーザルというのは、そのプロポーザルを読んだ人が分かるだけのプロポーザルではない。それを読んだ人が、その上司やボスや選定委員会に説明しやすく書かれていなければならない」としている。プロジェクト途中での交渉資料についても、それは変わらない。
顧客から仕様追加や仕様変更要求が出てきたとき、A社では「見積らせて下さい」「見積ってきます」と回答するよう訓練しているという。つい「検討してみます」などと、あいまいに表現することは、「何とか無償でやることを検討します」と言っているに等しい。技術、納期、コストの面で実現性が低いのに、あいまいな回答を放置すると、顧客は当然実現してくれると思っているのに、いつまでも実現されないため信頼を大きく失墜してしまう。
ある大手顧客の幹部も、「ベンダーの担当者は、『できません』と言う代わりに『検討します』『持ち帰ります』と表現する傾向がある」と指摘している。「検討します」という言葉そのものに不信感を抱いているのである。
プログラムは後工程になるほど修正を抑制しなければならないが、ベンダーの担当者は、顧客の担当者から修正相談を持ちかけられることが多い。プロジェクトの進行とともに、開発者と顧客担当者との親密度が高まってくることもあり、開発者は顧客からの変更要求を安易に受け入れてしまう傾向があるが、これがプロジェクト全体を混乱させる元凶になる。
システム修正・変更に伴うプロジェクトの混乱を避けるには、顧客とベンダーの双方が、変更管理窓口責任者を任命し、その責任者同士が、変更案件の採否や優先順位、修正時期などを判断することが望ましい。プロジェクト開始時点から窓口責任者を互いに任命しておけば混乱は少なくなるだろう。
仕様変更に対しては、予算の追加を頼まなければならないが、ある要件が仕様変更であると主張するためには、元々の仕様がきちんとしていなければならない。あいまいな仕様のまま開発を進めていると、元の仕様が何だったかが分からなくなり、ベンダー側が仕様変更だと主張しても、顧客からは「元々そのつもりだった」と言われてしまうことになる。
仕様変更に関する予算追加の依頼も、仕様変更の度にやるのは現実的ではないと考え、ある程度まとまってから頼もうとするのなら、変更の来歴をしっかり管理しておく必要がある。特にプロジェクト全体でどうなっているかをリーダーがすぐ見られるように管理されていることが大事だ。元の仕様の明確化と、追加変更の来歴管理はプロジェクト管理に不可欠である。
