マルチタスキング

前回述べましたように、同時に実行するプロジェクトが増えて皆忙しくなると、互いに行き違いになる状況があちこちで生じます。そうして、仕事が多い上に納期のプレッシャーが高まると、現場では、行き違いによる時間のロスを小さくしようとして、心理的にマルチタスキングせざるを得なくなります。つまり、今の仕事を終えないうちに別の仕事に手をつけるのです。ところが、マルチタスキングは、タスクの期間を著しく長くすることが経験的に知られています。つまり、タスクの期間が長くなって行き違いの影響がますます大きくなるという悪循環が生じます。そうなると、どこもここも仕掛が増える上に、どれもこれも赤状態になって、優先順位が混沌として制御が効かなくなります。

異なるプロジェクトの間に技術的または内容的な依存関係が無くても、それらのプロジェクトに関わる人や部署あるいはパートナーを介して依存関係が生じます。そうすると、ある一つのプロジェクトの遅れが他の複数のプロジェクトに伝播する、その結果さらに別の複数のプロジェクトに遅れが伝播する、そういう具合に連鎖反応的かつ広範囲に遅れが伝播するのです。その状態で投入計画を変えないままにいると、事態はどんどん悪化するばかりです。部署間のリソース調整が難しいことを考えると、そういうカオス的な状態に落ち入るのは避けたいところです。そのためには、先ず、マルチタスキングしなくて済む環境を作らないといけません。

リソースの希薄化

期間を見積もるときには、前提として各タスクあるいはタスクの集合に必要なスキルと数を想定すると思いますが、実行時にそれに見合うリソースが割り当てられないと、普通はそのタスクの期間が想定より長くなることを意味します。当然ですが、同時に実行するプロジェクトが多ければ多い程リソースは希薄になります。相手は人間ですから必ずしも数で測れるものではないのですが、流石に想定の半分とかそれ以下だと遅れを最初から覚悟するしかないでしょう。見積もりが正しければ尚更です。その上、他のプロジェクトと掛け持ちのマルチタスキングだとしたら、どうなるかは想像にお任せします。

こうして見積もりと実際が乖離した状態が恒常化すれば、顧客に提示する納期が長くなり競争力を失っていきます。その仕事自体を失うことになりかねません。そして、失った分を別のもので埋めているなら、いつか本当に何も無くなります。

解決の方向性 ― 投入のコントロール

人が中心のプロジェクト業務は、生産業務のように負荷の高いリソース(機械やワークセンター)からドラムにするリソースを選んでスケジューリングするやり方は通常困難です。“ドラム”とは全体のペースを決めるところですが、どれがドラムのリソースか簡単に選べないからです。

しかし目的は“少し余裕を作ること”だから手段はそう重要ではありせん。そこで、どこか全体の流れをコントロールできる工程なりイベントをペースメーカーにすることが考えられます。例えば、ソフトやハードの開発なら総合試験や品質検査をドラムにするということです。営業なら商談フェーズをドラムにすればよいでしょう。ドラムは複数の連続する工程でもかまいません。例えば総合試験+品質検査です。こういうドラムをマルチプロジェクトのCCPMでは“仮想ドラム”と呼びます。そして、この仮想ドラムを同時に通るプロジェクトの最大数を決めておいて、プロジェクトが一つ仮想ドラムを通過する度に、投入待ちのプロジェクトを一つ投入します。そうすればプロジェクトの同時実行数を常に一定に保つことができます。

ここでは詳しく述べませんが、投入スケジュールを決めるには、先ず、プロジェクトの投入順に従って、仮想ドラムのカレンダー上にプロジェクトのドラムタスク(仮想ドラムに該当するタスク群)を積み重ねながら並べていきます。プロジェクトの制限数を超えたら次は後ろにずらして同じことを繰り返します。このとき、直前のプロジェクトとの間に適度なバッファ(“キャパシティバッファ”)を入れて、前の遅れがそのまま後ろに伝播しないようにします。こうして仮想ドラムのスケジュールが決まると、今度はそれを起点にプロジェクト各々の投入予定日とバッファ込みの納期が定まります。

以上の方法で全体の負荷を均すやり方を“プロジェクト・スタガリング”と呼びます。細かなことを無視すれば、これはドラム・バッファ・ロープ(DBR)と全く同じです。

このようにして能力に対し一定の余裕を確保すれば、プロジェクト各々が独立しているかのように扱えるようになります。つまり、プロジェクトを跨ったリソースの取り合いは、スケジューリング段階では均す必要はなく、実行の段階でこの後述べる“バッファ管理”を使ってコントロールできます。詰まった状態よりはシンプルになるのです。

どうしても無くせない変動と不確実性がある限り、プロジェクト間の取り合いを事前にスケジューリングしても、実際はその通りにならないので、詳細は実行時に対処しようという考え方です。もちろん、重要なリソースについては、クリティカルチェーンの方法を用いて、プロジェクトそれぞれの中ではタスク間のリソースの取り合いを解消しておきます。なぜなら、そうしないと正当な期間が見積もれないからです。当然、プロジェクトごとにプロジェクトバッファと合流バッファを含んだ通常のクリティカルチェーンの工程にしておきます。プロジェクトの実際のスケジュールは、このクリティカルチェーン工程表をスタガリングが決めたドラムタスクの位置に合うように前後にずらしたものです。

さて、投入が確定したプロジェクトについて仮想ドラムのスケジュールが決まると、今新しいプロジェクトを入れたら最短で大体どこが納期になるか想定できるようになります。これは簡易ドラム・バッファ・ロープ(S-DBR)の計画負荷を用いた納期見積もりと基本は同じ考え方です。見積もりは見積もりであって正確ではありませんが、詰めすぎずちょうどよい加減の投入ペースを維持する上で、営業と開発の間の強力なコミュニケーションツールになります。営業がいくら頑張っても開発がついていけないと顧客への約束は守れず信頼を失います。良い顧客と長く付き合うには信頼が最も重要です。

こうしてプロジェクトのスケジュールができ上がったら、次はその計画をどうやって実行していくかです。次回はそれについて考えてみたいと思います。

黒木 市五郎 プロフィール

大学を卒業後、日立系情報処理企業で18年ほど技術系ソフトの受託開発に従事。正に阪神大震災のとき1995年1月ビーイングに入社、土木積算ソフトGaiaのWindows対応版初版、カリテス原価、Avoid避難・Avoid防災など、土木・建築系パッケージソフトの設計と開発を行う。
2004年春、TOC-CCPMの情報収集に着手。そのときからTOCコンサルティンファームの米国Afinitus社および日本のゴール・システム・コンサルティング社との交流が始まり現在に至る。
2005年より社内と顧客での実証実験と並行でCCPM対応プロジェクトマネジメントソフトBeingProject-CCPM初版を開発。現在に至る

LINEで送る
Pocket