仕事の流量を意識しなさいって話


仕事の流量って言われても何のことだかわからないかもしれません。まぁ、ワタシがプロジェクトをみたときにアンコントローラブルだなぁと思うプロジェクトの運営はほとんどプロジェクトマネージャはプロジェクトチームのメンバがプロジェクトチームはプロジェクトマネージャがどうして担当する仕事、つまり作業が予定とおり行かないのかさっぱりその原因の一つに気付いていないのです。


そのほとんどの上手くいっていないプロジェクトは大体はWBSもあったりするんですけれど、いや、WBSがあるのに作業が日に日に遅滞していく理由がわからないまま日付だけ進行してしまっていて、でもやっぱりなぜ計画どおりに進まないかはわからないみたい。


ワタシの経験から言えばプロジェクトマネージャがコントロールしたい作業単位のWBSWBSで得るつもりのdeliverableと担当者と予定工数と予定開始日と完了日と実績開始日と完了日と、日別のガントチャートをプロジェクトメンバと毎日更新した同じ資料を見ながら実績と課題を聞くだけでメンバとはプロジェクトマネージャであるワタシと“認識の共有”は出来るものです。


仕事の流量とは
仕事の流量とは、エンジニア一人がある期間に処理できる作業量であってエンジニアのスループットと言い換えてもいいです。プロジェクトマネージャもエンジニアも同じ人なので与えられている1日の時間は24時間だし、仕事に充てられる時間も限りがあります。費やせる時間の中でどれだけの仕事が処理できるかは、そのエンジニアのスキルのレベルと性格などのタレント性によってプラスにもマイナスにも補正されるのですが、それらの係数を全部含めたものが作業の流量というものです。


流量を意識しないと何が起きるの
仕事の流量は、エンジニア一人がある期間で処理できる作業であることは先に述べたとおりで、その流量を意識しないと何が起きるでしょうか。プロジェクトマネージャがプロジェクトメンバ一人ひとりの流量をプロジェクトマネージャが勝手な思い込みで実際のエンジニアの流量を越えたものを積み続けたらどうなるかは考えるまでもありません。プロジェクトマネージャが欲しい納期までに終わらない、ただそれだけです。


プロジェクトマネージャは、プロジェクトメンバとチーミングをしてプロジェクトを立ち上げるとき、はじめにしなければならないことの一つにプロジェクトメンバの作業の流量を把握することがあります。それをしなければ後々にプロジェクトマネージャが勝手に期待して、プロジェクトマネージャが勝手にエンジニアの作業の流量を決めつけて、期待する結果を得られなくて勝手に失望することになるのです。


プロジェクトが終わるまでは同じチームであるのにプロジェクトマネージャが勝手に期待して勝手に失望することは進んですることではありません。ならば、どのくらいの作業の流量を持っているかエンジニアのポテンシャルをザックリでも知っておくことが以後の作業の割り当てでも目安になるので有意義です。


仕事の流量を視覚化することの意味
人は文字より表の方が理解し易いし、表より図の方がより理解し易いです。プロジェクトの作業はWBSの一覧に必要な項目、作業名、deliverable、工数、予定開始日と完了日、実績開始日と完了日があれば情報としてはそれで十分ですが、その一覧でプロジェクトメンバと作業に対する“時間”という価値の軸で本当に共通の理解を得られるかと言うと実は怪しかったりします。


それは、一覧では日付の羅列になるので所謂カレンダのように時間や曜日を意識することが出来ないので記載されている納期である予定完了日へのプレッシャが実はそれほど伝わらないのです。不思議なことにそれでも予定完了日はそれなりには伝わるのですがとても曖昧にルーズになるのが予定開始日です。終わらせるとうことは夏休みの宿題と一緒で気にするのですが、いつからやるかは「納期までに終わればいいのでしょう。」と言う開き直りのような態度で現れることが多いです。


ワタシは予定した開始日に始められないことを非常に危険さを感じられずにいられません。予定した開始日に始められないなら予定した完了日に終わるわけがないのですから。そして予定とおりはじめられないなら、その前の作業が終わっていないということです。


仕事の流量は今、今日、このときに誰にどれだけの作業が割り当てられているかを誰もがメンバそれぞれの過負荷や閑散を知るためにとても役に立つのです。数字だけでは自分の作業しか目に入らなくても、ガントチャートを付けて図で視覚化することでいやがおうにも視界の中に投げ込むことで、一人のエンジニアに負荷が掛かっているから後続の作業を別のエンジニアに割り当て直そうとか、それを手伝うだとか、そうした過負荷に応じた作業の平準化を進めるツールとして効果があるし、図で視覚化することでプロジェクトマネージャ自身がそれに自ら気づくことが出来るのです。