いくら出来るエンジニアでチーミングしても諦めてしまうならプロジェクトマネージャを改造してしまえ

on


プロジェクトは有限期間で遂行されるもので、そのプロジェクトの顧客要求を実現するために必要なスキルを持つエンジニアを集めてチーミングします。チームメンバとプロジェクトマネージャ、チームのレポートラインのマネージャ、そしてステークホルダの一部である顧客。これらのメンツが同じ方向に顔を向いて歩き出すことができるかどうかがプロジェクトにこれから起きる数多の課題や発現する問題に気づき、意思を持ってコントロールできるか、又は、いつものパターンでデスマに足を踏み込むかが決まるのです。


スタート時点で見積もり時と同じ条件を等価に確保しなければスタートラインに立ってはいけない
プロジェクトで顧客が実現したい要件を手に入れたい期日までに届けるために必要なスキルは見積もり時点で識別されていなければならないし、そのスキルレベルも特定されていなければそれに見合ったエンジニアを調達することは現実的ではありません。


見積もる人が見積もり、レビューする人がレビューし、プロジェクトのチーム編成をする人が編成するためのスキルを押さえて調達する。それが初めてそろって、見積もり時点と等価のスタートラインにつくことができるのです。それが正常に機能してエンジニアを超他することができたとしても、それ以降のプロジェクトのキャリーがうまくいく保証がされるわけではないのですが、それでもそれは最低限しなければならないことです。


エンジニアはエンジニアであるが故にモノづくりは諦めない
それでも、必要なスキルセット、スキルレベルを持ったエンジニアを集められることができたとしても、プロジェクトが計画したようにいく保証はないことは先に書いたとおりです。それはチームやプロジェクトを取り巻く外部環境の作用である場合もあるし、チーム内部のことが原因で自滅することもアルアルなのです。


特に、チームが自滅する場合はどうしてチームが自滅したのか真因、つまり、本当の原因まで到達することは難しい。なぜなら、そうした嫌な経験は自衛本能が働いてベールに隠されてしまうから。普段は歯に衣を着せぬ物言いをするエンジニアがそうしたときには大人の対応をとったりするのでその原因を知りたくてもそれに到達することは手間がかかるのです。


ただ、そういった自滅をするようなプロジェクトであってもエンジニアはエンジニアであるが故に、顧客が望む要件は自分自身が折れない限り実現しようと頑張るのです。だから、プロジェクト全体としては例えスケジュールオーバーランが多少あったり、徹夜を繰り返してまでもアウトプットの実現に尽くすので一見外部からは内部の問題が視覚化されないのです。


それでも出来るエンジニアが諦めてしまうこと
チーム内部の問題はその問題があると外部が気づくためにはその兆しや予兆が識別できなければ検知は難しいものです。やはり、内部から何等か信号が発信されないと監視をしようにも関心を持っているイシューでなければ引っかけようがない。


デリバリーするアウトプットはエンジニアがムキになっても諦めずやり遂げるにもかかわらず、諦めてしまうことがある。あるプロジェクトの終わりにメンバを集めてプロジェクトをふりかえる場を持つ機会があったのですが、その場で出てきたことは、一人ひとりのエンジニアスキルは立派だし、品質もしいし、それぞれのエンジニアと会話するときちんとコミュニケーションが取れる。そうしたメンバで構成されたチームなら、なんらも内部の問題はなさそうだし、あっても自己解決しそうと期待できる……と印象を持ったのですがインタビューしていたらどうやらオカシイ雰囲気に。

「他のプロジェクトなら、普通にできた横横の連携ができなかった。」
「しようとしたが、縦割りがひどくて。」
「そうそう、連携したかったのでやろうとしたけどそんな雰囲気じゃなかった。」


横横で連携して仕事をすることがプロジェクトでの自分の作業を円滑にするために必要なことは重々わかっているし、“他の”プロジェクトならやってきたし、やろうと思ったけれど、実際、やろうとしたし、コミュニケーションも試みたけれど。

「試みたけれど、叶わなかった。」


エンジニアの人はそれぞれのエンジニア自身の耐えられるまでの閾値を超えてしまったので、もうそれは諦めてしまったのです。なんと悲しいことか。


エンジニアが諦める前に
一人ひとりのエンジニアは横横のつながりが結果、巡り巡って自分の仕事を円滑にすることは身をもって知っているのにそれがかなわないなんて。それは、そのプロジェクトで場を作ろうとしても作れないということだ。


もし、それがプロジェクトマネージャなのだとしたら。そうなのだとしたら、エンジニアが仕様をデザインするときに課題が出てきたらデザインを変更したり課題を解決して対応するように、自分の仕事をやり易いように変化させる作用をしよう。それはしていいことだし、一人でやっていいかどうかを悩むなら横のエンジニアと雑談して反応を見てみよう。大丈夫、同じように感じているものだ。


組織で動いているのだから、間接的にその対象であるプロジェクトマネージャに作用する人を探せばいい。どこにでも一人や二人いるはずだ。そうした人に横で世間話をするように、たとえ話をするように、あたかも脳内のツイートが声に出てしまったように相談すればいい。

「横横の連携が悪いんです。自主的にやっているけれどこれから構築工程なので危ないと思うんだけれどどうしたらいいかなー。」
「設計でインタフェースが自分のところは大丈夫だけれど、危なそうな機能があって全体で場を持たないとまずいと思うんだけれどどうしたらいいかなー。」


そうした人を触媒にして変化しないならそれはそれで深刻な問題なのだ、と認識しよう。それはエンジニアの領分ではないけれど、それをしないと確実に不幸になるのだから。不幸のまま突入していくより、不幸を排除する方に働く方が何倍もいいのだから。