トラックナンバーとハネムーンナンバーと新しいナンバーに耐えられるチーム運営をするためにマネージャがしておくこと

ある週明けの朝一に、プロジェクトチームのプロジェクトマネージャ役のエンジニアが今にも泣きそうな声で電話をかけて来たんですよ。大のオトナが早朝から、それも泣きそうなくらいに声を震わせて、です。尋常じゃないことはすぐにわかります。

「すみません…。体調がおかしくて病院に行ったら数日入院することになりました。プロジェクトがあるのに…体調管理もろくにできなくて…うっ」
「今病院なんだ、そう。大丈夫。なんのために毎週顧客との週次ミーティングに出ていると思っているの。大丈夫。病院って、あ、そこね。了解。ワタシが代役しておくから大丈夫。信頼して」

トラックナンバー

プロジェクトのチームであるメンバがいなくなるとプロジェクトが継続できなくなる人の数を表す用語（かなりざっくり）です。

上記の例でワタシがいないとしたら、プロジェクトマネージャが入院したのでプロジェクトチームは止まってしまいます。

現実的には、仕掛り中のタスクがあるのでそれがあるうちは止まるかといえば止まりませんがプロジェクトとしての意思決定が必要になったら仕掛り中のタスクがあろがなかろうがストップします。

これまでのエントリでは、人的冗長化をロールとしてすることを推して来たのはこう言った経験が何度かあって、その都度カバーしてプロジェクトを止めないようにして来たからです。

予め想定されるトラブルをこのブログを読んているエンジニアが同じ鉄を踏む必要はないので。

協力要請とWBSとリポジトリ

心配させないように電話を切った後、まー、大見得を切った割にはどうしようかなと思うんですよ。現実としては。マネージャなのでプログラムマネジメントはしても、個々のプロジェクトのWBSやタスクの状態や次回のagendaまでは首を突っ込んでいないので。

今必要なことは計画どおりに進捗させることです。

計画どおりにの裏には、チームを動揺させない＝進捗を停滞させない＝パフォーマンスを落とさせないというのが1つ。

顧客に不安を持たせない＝プロジェクトが止まらないが2つ。

この2点が頭を過ぎったんですね。さては初めに何をするか。

チームに事情を話して協力を取り付けること、プロジェクトの目の前のToDoを押さえること、少し先のタスクの段取りをしておくことをしようかと思ったんです。

それには、情報が必要で、情報の源泉は、WBSとドキュメントや検討資料などのリポジトリですね。これがほぼ現状を表す状態になっているから大見得を切って安心しろといえたわけですが。

これはプロジェクト開始時や週次に行く前に資料の事前説明をそうした情報から受けていたので情報がほぼリニアであることが把握できていたというのはあります。

ハネムーンナンバーと新しいナンバー

トラックナンバーはブラックジョークらしいのであまり好ましくないという意見もあるようですが、組織の上でのトラックナンバーは悪い意味で自分自身があるなと思っている（当時は同じレベルまで育っていなかったので）のですけれど、バスに轢かれたとき自分たちが困らないようにね、と仕事は振って経験させていましたねぇ。

プロジェクトが止まる理由はネガティブな事由ばかりじゃなくていいことでも度が過ぎれば止まります。ハネムーンとかね。組織の中でというか年代であるタイミングである年齢層が集中的に結婚する時期があったりするんですよねえ。数年に一度とか。

どっちかといえば行ってこい長期で休んでいいよ派なので、予め教えておいてね、なんですけれど、これは出産も同じですね。わかったら教えてもらえれば7ヶ月後やそのあとの育児休暇も想定してアサイメントを考えるわけです。

これはベビーナンバー、と呼ぶのはどうでしょう。

新しい。このベビーナンバーは新米ママさんばかりではなく、新米パパさんも当てはまるというところがミソ。

ハネムーンナンバーもベビーナンバーもそれでチームから一時的に離脱したら何人まで耐えらるかという指標です。

対策はロールの冗長化でプロジェクトが止まらないようにしておこうぜ、という考え方になるのはいつものことですけれど。