必要なときに全力を出せるためには

期待値の最大化
マネージャをやっていると、見積もりやらプロジェクト計画やらのレビューアの役割も持っているので様々なプロジェクトに触れる機会を与えてもらっている。担当外のレビューにも声が掛かることがあり、経験を積めるということは嬉しい限りだ。
レビュー対象のレビュー結果の傾向は、その組織の家風が出色することが多く、特色もハッキリしている。設立が新しい組織は体系だったドキュメントになっておらず、そのプロジェクトのチームのパフォーマンスの前提がどこのスーパーマンか？と驚くときもある。古くからある組織であれば、過去の類似プロジェクトからの類推で計画することが多く、実績も踏まえていることが多いから信頼性は高いが計画するエンジニア自身の経験でその信頼性は左右されるので誰が計画したかを確認するまではリスクは排除できない。
経験が少ないエンジニアが計画する場合、計画時にどれだけ計画のシナリオが見切れているか、具体的なプロジェクト管理手法や開発方法論がイメージできているかでWBSのワークパッケージのボリュームが過大にも過小にもなってしまう。そのような経験の少ないエンジニアの傾向として、計画のシナリオが見切れておらず、作業の抜け漏れとともにWBSのワークパッケージの作業量の過小での計画になっていることが多い。これは、裏返すと根拠のないチームパフォーマンスを最大化していることになる。

プロジェクトがはじまったら
不幸にして、過小な計画のもとに始まってしまうプロジェクトがないわけではない。はじまるということは、何らかの契約の元に顧客にサービスをデリバリーすることが約束されたということであり、エンジニアとしてアサインされたのであればそれを達成すべく知恵を出すほかない。
幸いにして、妥当な計画の下で始まるプロジェクトだとしてもリスクがZEROであることはありえなく、プロジェクトのコンディションに応じてリスクは発現の可能性を秘めており、それに掛け合わせるインパクトのエクスボージャを秘めていることを忘れてはならない。エンジニアはそのリスクが既知であれば、発現を防止するか、仮に発現しても最小限に留める責をチームとして負う。でも、それが起きるのはプロジェクトである。

必要なときに全力を出せるようにするために
リスクが発現した場合、計画したWBSのほかに、何らか対処する必要のあるタスクが優先順位が高い状態で割り込みしてくる。これは、だれでも予見できることであり、急な割り込みがあってもどれだけ柔軟にパニックにならず対応できるかが、エンジニアの経験の価値である。このような必要なときに、いつでも全力を出せる状態にするためには、自分の技術の素養や応用力を把握し、自分の限界値を知ってかなければならない。もちろん、精神的にもどちらかというと飄々として受け流し、急な割り込みの流れを受け流して手を打つようにすることが必要だ。すべては、自己のコントロールに基づく。そのように考えを置くと、いつも全力を求めるマネージャがいるのであれば、それは間違いなのだ。