プロジェクトでカイゼン [Project de Kaizen] 第12回

進ちょく会議を不要にするスケジュールマネジメント(その2)

前回、従来のスケジュール作成の問題点として「逆線表の誤り」など三つほどを説明しました。そして、それらの問題点をすべて解消する「2点見積もり法」によるスケジュール作成をご紹介しました。また、このスケジュール立案によって、スケジュールのバッファー(余裕しろ)を使って従来の進ちょく管理を不要にすることができるようになると述べました。今回はその続きです
 
【従来の進ちょく管理の問題点】
これについて、責任追及会議になりやすいことを既に述べました。また、前回述べたように、スケジュール遅れの判断については属人性があり、人によって判断基準が変れば困ることになります。場合によっては、リスケジューリング(再作成)という後戻りが起こるので、属人性を排除するために、経験ある人が欠かせないということも起きてきます。
そもそも、進ちょくの問題とは計画に対する遅れがどの程度なら「問題である」かの判断基準(判定基準)をどう設定するかということに落ち着きます。これは、遅れの程度の問題の他に、その作業の重要性の程度も合わせて考える必要があります。判断にはそれなりの経験が必要とされてきた理由はここにもあります。
 
【従来の進ちょく管理で改善したいこと】
上記に述べたことに対応して、次のようになります。
・遅れが出てもどの程度の問題なのかを、経験者でなくても判断できること
・リスケジューリング(再作成)を無くすこと
これらが可能になれば、まさにマネジメントの大きな改革になります。
 
【バッファー残量による進ちょく管理】
まず、前回の説明、ギリギリ値プラスバッファーの付いたスケジュールを掲載しておきます。
 
図1 お薦めのスケジュール

 
スケジュールにはバッファーが付いています。これを3分割し進ちょくの状況を三段階で管理します。三段階とは交通信号と同様な感覚です。バッファーがたっぷり残っていれば緑信号(安全)、逆に残りわずかなら赤信号(危険)、中間は黄信号(要注意)ということになります。
 
図2 バッファー残量で進ちょくを管理する

 
●バッファー残量の算出
・各作業の着手後まもなくの時点でギリギリ値を見直して予測値を提示する
 各担当者自ら見直しをおこなう。作業を開始して2日目などの時点
・予測値に基づき、その時点でのバッファー量(残量)を算出する
 予測値がギリギリ値に対して増加すれば、バッファー残量は減少する
 
●進ちょく状態の判断と三段階のアクション
 ・バッファー残量に対応して、進ちょく状態を「緑・黄・赤」の三段階で判断する
  残量2/3以上・・緑、残量1/3~2/3・・黄、残量1/3以下・・赤
 ・三段階に対応したアクションを実行する
  緑・・何もしなくてよい
  黄・・バッファーを初期状態に回復させる対策を決めておく
  赤・・その対策を実行する
 
バッファー残量で進ちょくを管理するこのやり方は「バッファー・マネジメント」と呼ばれています。
 
【このやり方の優れた点】
・作業の着手時点でギリギリ値を見直した予測値を集約するだけで、誰でも進ちょくの状況がわかり、必要なアクションが何かを判断できます。進ちょく管理に専門性が不要になります。
・プロジェクトの途中段階で、終了時の予測が可能になり、必要な対策が早めに実行できます。終了間際で想定外の対応をしなくてすむことになります。
 
【このやり方の前提として必要なこと】
・予測値の提示が正直ベースで安心して申告できる職場の雰囲気があること
・各作業の期間は大きな差が無いようにします。許容範囲は最大5倍程度とする(今回の例、図1で作業Aは2日、作業Dは10日ですから許容範囲内です)。長すぎる作業は計画時に分割しておきます。
・作業数は10個以上が望ましい。多いほど、バッファーマネジメントが有効に働きます。
・作業に想定外のリスクが無いようにします。あらかじめリスクが想定されるときは、事前に対処しておきます。リスクの事前対処はすべてのプロジェクトに共通する原則となります。
 
【スケジュールマネジメント】
筆者の所属する企業では、これまで述べてきた「2点見積もり法によるスケジュール」と「バッファー残量による進ちょく管理」を統合したものをスケジュールマネジメントと称しています。
・2点見積もりにより見積もり精度にこだわることなく見積もりのバラツキを解消できること、
・進ちょく管理において遅れの判断に専門性を要しないこと、
・基本的にリスケジューリングを発生させない仕組みであること、
これらを考え合わせると、スケジュールマネジメントは進ちょく管理において画期的なやり方であることがわかります。
 
なお、「バッファー残量による進ちょく管理」はTOC(制約理論)によるプロジェクトマネジメント(通称:クリティカルチェーン)で提唱されているものです。また、本稿の説明ではチームの実力値ベースで説明しています。チーム実力値を超える要求があった場合については、本連載で次回以降に述べることにします。