顧客側の担当者が代わったとき、プロジェクトはどうなるか｜続いた案件と終わった案件の違い

システムの保守や開発は年単位で続きます。その間に、発注側の担当者が異動したり退職したりすることは珍しくありません。担当者退職時の引き継ぎは発注側の備えとして整理していますが、この記事では開発会社の側から見て、担当者が代わったときに実際に何が起きたかを書きます。

引き継ぎは、打ち合わせの積み重ねの中でできた

担当者が代わったとき、特別な引き継ぎの場を設けたわけではありません。FUNBREWでは2週間に一度の打ち合わせを続けており、その中で前回から今回までの差分を説明していきます。それを何度か重ねるうちに、新しい担当者もプロジェクトの状況を把握できるようになりました。

差分の説明が引き継ぎとして機能するのは、経緯が細かく積み上がっていくためです。一度にすべての背景を説明されても頭には入りませんが、進んだ分だけを毎回聞いていけば、順番に文脈がつながっていきます。

定例の間隔が空きすぎていると、この形は取りにくい

逆に言えば、打ち合わせの間隔が空いている案件では同じことが起きにくくなります。前回から差分が大きくなりすぎると、説明が一度に長くなり、聞く側も追いきれません。打ち合わせの頻度は進行の管理のためだけでなく、担当者が代わったときの保険にもなっています。打ち合わせの進め方については別の記事にまとめました。

担当者が代わっても続いた案件に共通していたこと

担当者の交代を挟んでも続いた案件を振り返ると、顧客側が複数人で対応していたケースが多くなっています。

窓口が1人だけの場合、その人が抜けた時点でプロジェクトの経緯を知っている人が社内にいなくなります。複数人が関わっていれば、担当が交代しても、誰かが前の話を覚えている状態が残ります。開発会社から説明できるのは、あくまで作ったものと決めたことであり、社内でなぜそれを進めていたのかという背景までは代わりに語れません。

複数人といっても、全員が実務に入る必要はない

ここでいう複数人とは、全員が打ち合わせに出て手を動かすという意味ではありません。決裁する立場の人が経緯を把握している、あるいは実務の担当者が2人いる、といった程度でも状況は変わります。1人に集中していないことが重要です。

開発会社の側から、交代のときにできること

担当者が代わることを事前に知らされていれば、開発会社の側からも打てる手はあります。差分の説明を丁寧に続けるほかに、次のような整理が有効です。

• これまでに決まったことと、その理由を一覧にして渡す
• 検討して見送った案があれば、見送った理由も添えておく
• 現在動いている作業と、止まっている作業を分けて示す

二つ目は見落とされがちですが、後任の方から同じ提案が再び出てくることは珍しくありません。前任者との間で一度検討した内容であれば、その経緯ごと共有しておくほうが、同じ議論を繰り返さずに済みます。

ただし、これらはあくまで開発会社が把握している範囲の記録です。社内でその案件をどう位置づけていたか、予算をどこから出していたかといった背景は、発注側でしか引き継げません。保守契約がどう終わるかを見ても、契約が切れる場面の多くは技術的な理由ではなく、社内の事情の側で決まっています。

そこで終わった案件について

一方で、担当者の交代をきっかけに続かなくなった案件もあります。理由をこちらから確かめたわけではないので断定はできませんが、社内でその案件の優先度がもともと高くなかったのではないかと考えています。あくまで想像の範囲です。

重要視されているプロジェクトであれば、担当者が代わるときに引き継ぎが行われます。引き継がれずに止まるということは、社内でそれほど重い位置づけではなかった可能性があります。開発会社の側からは、これを事前に見分ける手段はほとんどありません。

発注側が担当者の交代に備えてできること

交代そのものは避けられないので、備えられるのは次の三点です。

• 窓口を1人に集中させず、経緯を知っている人を社内に2人以上つくる
• 交代が決まったら、後任を交代前の打ち合わせに同席させる
• そのプロジェクトを何のためにやっているのかを、担当者個人ではなく社内の共有事項にしておく

三つ目は、担当者が代わった瞬間に効いてきます。目的が個人の頭の中にしかないと、後任は「前任者が進めていた案件」としてしか受け取れません。この状態は現場と経営で判断が食い違う場面とも重なります。ご相談はお問い合わせからお受けしています。