上手くいっていないプロジェクトは主導権を取れていない


顧客から見たら全員プロフェッショナルなのよ
主導権と言ってもプロジェクトで傍若無人な振る舞いをするようなことではありません。ワタシたちプロジェクトマネージャしかり、アーキテクトしかり、担当のシステムエンジニアしかり、どのロールのエンジニアであっても“ワタシたちエンジニアが技術のプロフェッショナル”なのであって、“ITプロジェクトをキャリーするプロフェッショナル”の集団なのです。


プロフェッショナルだからこそ、顧客から控えめにも安いとは言えない費用を対価として受け取るわけです。この場合、ITエンジニアリングの多重な契約構造は顧客から見たらプライムベンダへの費用支払いになるわけで、その点で除きます。


つまり、顧客から見たらプロジェクトに入るシステムエンジニア全員がプロフェッショナルであることを期待されている、と言っても過言ではありません。実際は、その期待とおりのスキルを持ったシステムエンジニアで構成すると採算割れは確実なので、経験の若いエンジニアやパートナーとのビジネススキームでやっていけるようなメンバ構想になるのは企業として当然のことです。


トラブルじゃないよデスマだよ、デスマじゃないよ自爆だよ
ところで、上手くいっていないプロジェクトは、トラブルプロジェクトの一言で片づけられてしまっているような気がするのですが、最近は、トラブルプロジェクトというよりもデスマと言われる方が多いかもしれません。そのデスマであるトラブルプロジェクトはプロジェクトは一つひとつ違うようにデスマになる原因もそれぞれ違うのは当然であり、それも、「システムエンジニア側に起因する問題の方が多いんじゃないの。」なんて思ったりもするのです。


この際、顧客側のことは一旦棚にあげます。


やりたいことを実現することと御用聞きなお伺いは違う
やっぱり一番拙いのは、“デスマになっているプロジェクトは、IT側にプロジェクトの進め方がすべてにおいて受け身になっている”、でしょう。「顧客のやりたいことを実現してあげるんだ。」ということを時々耳にする人もいるかもしれません。「とても顧客思いですね。」、なんて思いますか。これは全くの間違いとしか言いようがないと思うのです。

顧客が高いコストを払うのはITが自分たちのコアコンピタンスでないこともありますが、それを主体的にキャリーするのが“面倒”だからでしかないのであって、その面倒な部分もIT側がお伺いモードで擦り寄ってきたら、「(折角高いコストの予算執行の稟議を取ってきたのに!ムギー!)」って思っても仕方がないです。


IT側はプロジェクトのすべてにおいてシナリオを書いて、その上に顧客に乗ってもらわなければならないのです。勿論、無理やり乗せるのではなく、顧客に促しながら、ですが。


最後までキャリーする覚悟がないならやめておきなさい
それは言い換えれば、プロジェクトの主導権を、手綱を引っ張て行く覚悟がないならデスマになる、という示唆でもあるのではないか、と思うのです。ですからプロジェクトに入るならそうした気持ちをIT側のプロジェクトメンバ全員がそう思いながら臨もうね、ということです。それがプロジェクトを思うようにキャリーするためのたった一つの大切なことであって、デスマにしない処方箋だと思います。


がんばろう、ワタシ。