プロジェクトの問題はメンバが積むバッファなのか

on

「ほとんどのプロジェクトの問題は、上手く行かないー叱るーバッファ積む、から来てる気がしてきた。」

早朝に起きてスマホでSNSのTLで、ほとんどのプロジェクトの問題は、上手く行かない−叱る−バッファを摘む、が起因じゃないかというのを見たのですが、そうかなぁ、というのが一番最初に感じたことです。


わたしはプロジェクトの問題が起きる起因は、要件と実現する人のギャップにあると考えています。


そのギャップとはプロジェクトの要件を実現する人にあると思うのです。まぁ、要件を持ち出すとその要件自体が現実的なのかという方に話がいってしまうと身も蓋もないし、前提として要件はニュートラルであると仮定してこの話を進めても問題がないからです。


なぜなら、要件が厳しくてもドリームチームが編成できて必要なリソースが確保できればその要件は実現できますし、逆に、要件が緩くても、集めたチームがダメチームなら要件は実現できないのです。なので、要件は考慮してもしなくても良いことにします。


メンバはなぜバッファを積むんだろう
プロジェクトマネージャや数人のメンバのリーダの役割をしたことがある人なら、メンバにWBSを展開して日付を入れてスケジュールにしてもらうと「えぇ、こんなに日数がかかるの」と思ったことが１度や２度、もう、毎回、なんて経験したことがあると思うのです。（確信


なぜメンバはタスクの作業の正味時間にバッファを積むのでしょうか。タスクの正味で必要となる作業時間にバッファを摘む。タスクの正味時間の精度が高ければバッファは必要ありません。これは誰も同意できることだと思います。


ではどうしてバッッファを積む必要があると「メンバは」考え、実際に、作業の正味時間にバッファとなる時間を加えようとするのでしょうか。メンバの立場で何があったらバッファを追加してスケジュールを水増ししておくかを書き出してみます。

  1. 仕様が曖昧
  2. コミュニケーションロスが多い
  3. スキルエリア・レベルのギャップ
  4. 計画どうりに仕上げたことがない


それではひとつ一つみていきます。


仕様が曖昧
タスクで作るアウトプットの仕様に不確かなところがある、と言う意味です。アウトプット自体の諸元に曖昧さがあると見切ったのかもしれません。もしくは、過去の経験から想定した工数を単純に割り増ししているのかもしれません。


何れにしても、このくらいでできる妥当と想定する工数に対して、アウトプットを作る手間に確認を持てない部分があるという状態です。この不確かな仕様がある限り正味の作業時間ではできるとコミットできないということです。逆に言えば、作業の不確かな仕様を作業見積もりの時点で解消することができればバッファは必要ではないということになります。ただ、これまでスケジュールを作るときに正味の作業時間にバッファを入れていたメンバにとっては不安な要素になるでしょう。


コミュニケーションロスが多い
作業を進めていく上で、実際に動くプログラムを作る工程に入るには、プログラムのコードが書けるレベルまでに仕様が決まっていないところがあるとプログラムは完成しません。当たり前なことですが、現実にはコードを書くまので仕様を判断していく途上に掛かる時間はあまり問題視されないことが多いです。


ただ、そうしたなかなかプログラムの諸元の判断に時間がかかることを経験したことがあるメンバは、作業の正味時間にコミュニケーションロスの係数を加えようとします。意思決定に至るまでに時間的な不安があるからバッファを追加するということです。


こういった経験をしているメンバはWBS自体あまり分割をしようとはせずに、一本の長い期間を描く傾向があります。こうしたことは、ガントチャートを作成してみると、５個とか１０個とかのまとまったWBSが１週間以上の長い期間の図となって可視化することができるので見つけやすい特徴があります。


スキルエリア・レベルのギャップ
作業で要求されるスキルエリアが未経験だったり経験が少なかったりすると要求される技術領域や技術の難易度のレベルとメンバ自身が持ち合わせている技術エリアやレベルと較差が生じます。その較差を自分で認識できるメンバなら正味の作業時間に対してギャップを時間に変換したバッファを追加します。


これは事実の認識としては正しい判断ですし、バッファを追加すること自体に誰も疑問視はしないでしょう。ただ、人はスキルのエリアやレベルの自己評価については甘くする性質を持っているため、どうせとるバッファなのだから少し余分に取っておこうとしがちです。


計画どうりに仕上げたことがない
このケースは、先の３つの要素を特定できていないけれども、これまでの自分の経験則からなんとなくこの位あれば出来るかなと当てずっぽうの工数にバッファをさら当てずっぽうで加えたものです。経験の浅いメンバはこれに陥りやすいですがスキルが上がればここか脱出できます。


ところが、ここに滞留するメンバはスケジュールを実行した結果から何が遅延の要因で何をすれば解決するかを識別することができませんからこのエリアで滞留することになります。遅延する理由がわかりませんから、対処も出来ず、自覚できませんから周りから示唆されても効果的な対処もできません。いつになっても、根拠なく自分が担当する作業のスケジュールには根拠がないバッファを積むことを繰り返します。


現実には、ずっとこの要素を抱えたままの中堅のメンバも１０人のメンバがいるとしたら１人は存在する確率があるので思った以上に見かける機会は多いです。プロジェクトマネージャはこういったメンバは身に沁みて覚えているもので、可能な限りメンバに入れないように行動します。


叱る→メンバがバッファを積むなら
もし、メンバがバッファを積むことの前に叱るがあるとするなら、これまで述べてきたことをプロジェクトマネージャやマネージャが要因として識別できていないからではないかということが考えられます。叱る→バッファは少しだけ表面を見過ぎているのではないか…。


怒るプロジェクトマネージャやマネージャを捕まえて、起きている事象の原因はどこにあるかを観察や検証をする必要があるのではないでしょうか。


でもですね…、メンバが作業をスケジュール化するときにバッファを積まなくてよいように様々な不安を解消したとしても、次はプロジェクトマネージャがプロジェクトとしてバッファを積むんですよ。これはスケジュールのリスクに対するコンテンジェンシとして、です。これはリスクマネジメントの観点では無くせないのですよね。


ただ、こうしたプロエジェクトとしてのバッファはプロジェクト全体としての余裕であって必ずしも使われるとは限らないですが、メンバのバッファはスケジュールの納期期限と一致するので既得権と麺が自身が看做してしまうので使わないなんてことは滅多に起こりません。というか１００％使われるんですよ。TOCの世界の話になってしまいます。


そこがこの最初の問いに対する疑問というか引っかかりなんですよねぇ。TOCじゃないでしょう、って。実現することに対して不安を感じているかどうか。それを何に置き換えているのかがプロエジェクトの問題となってあわられるのではないか、と。