解決の方向性 ― バッファ管理による集中と交通整理
実行するプロジェクトの計画が決まったら、次はそのとおり実行することですが、CCPMにおいては、実行中のプロジェクトを管理することは、バッファの色（※）とその変化をモニタすること（バッファ管理）です。そしてその基本は、危険なプロジェクトに管理の労力を集中することです。現場への介入は赤と黒のプロジェクトだけに限り、それ以外は無用な介入を避け自然に流します。もちろん、バッファ消費のトレンドから判断して赤に向かって急速に悪化しそうなら、原因の報告や対策の検討を指示することもあります。しかし、毎日バッファをモニタしている限り、突然赤になることはなく、手を打つ時間的余裕が十分あるはずです。受託プロジェクトはもちろん、基本的には納期遅延した黒バッファのプロジェクトはあってはならないのです。したがって、少なくともPMOとプロジェクトマネージャは毎日バッファを見ることが重要です。
一旦実行を開始したプロジェクトはどれが重要ということはなく、バッファの色だけがその優先度を決めます。なぜなら、実行中のプロジェクトは、どれも実行すると決めた重要なものだからです。したがって、プロジェクトの進捗会議は、バッファ一覧から赤と黒のプロジェクトをピックアップして、回復策の実施状況とその結果を確認する場になります。必要なら工程レベルまでドリルダウンして詳細な状況を確認し、リソースの追加や顧客との交渉など追加の策を検討して実行に移します。従来のように全てのプロジェクトについて工程表のタスク個々を細かく確認するスタイルとは大分違ったものになります。その分問題のある赤と黒のプロジェクトに時間をかけるのです。
バッファ管理がちゃんと機能すれば、複数のプロジェクトの複数のタスクを抱えているときは、バッファの優先度がより高いものを先に着手するようになるから、先ほど述べたタイミングの行き違いは小さく抑えられるはずです。そうすると、待ち時間のロスが大幅に小さくなり、リソースの調整や手配のやり直し、遅延対策の検討と実行、いろんなところで無駄な労力を費やさなくて済むようになるはずです。そのようにして、少し負荷を抑えることによって、いろんなところに埋もれていた能力が解放されるのです。その解放された能力を使って、プロジェクトに必要なリソースを適正数割り当て予定通り確実に終えるようにします。
しかし、バッファ管理に従って優先度が高いタスクに人を割り当てて着手するといっても、企画や設計といった上流の工程になると、そう簡単にできないのが実情だと思います。必要なスキルを持つ人が大勢居ればよいのでしょうが、そんな贅沢な環境はそうありません。人を確保するには人を育てなければなりません。一人で良いところでも、一人は見習いとして二人割り当てる必要があります。その意味でも、同時に実行するプロジェクトの数を抑える必要があるのです。そうしないと、そのうちバッファ管理が巧く機能しなくなるでしょう。
全体の負荷を考えるについては、大雑把に言って、赤バッファのプロジェクトが全体の5～10%を下回っているなら、全体として負荷を制御できていると言ってよいと思います。それより多くなった上に赤と黒の割合が上昇しているなら危険です。赤や黒が多くなれば全体が柔軟性を失い不安定になるからです。その時は、赤と黒のプロジェクトの割合が5%を下回るまで新しいプロジェクトの投入を一時待つとか、思い切った策が必要だろうと思います。
バッファ管理の良いところは、プロジェクト個々の状態の善し悪しが判断できるとか、タスクに優先順位を付けて交通整理できるとかだけでなく、バッファの一覧を見れば全体の状況が一望できることです。意図的にデータを改竄しない限り、システム全体の健康状態がちゃんと見えているはずです。遅れたり遅れそうなプロジェクトが多くなったことが目で分かるようになれば、今の状態について皆の理解が得られ易くなるのではないでしょか。
ここで紹介している方法は、弊社の『BeingManagement3』のようにマルチプロジェクト環境のCCPMに対応したプロジェクトマネジメントソフトウェアを使うことによって容易に行うことができます。
継続するということ
TOC的には「将来に渡って“持続（継続）”する」ことが絶対命題です。それ抜きでは意味がありません。「詰まらずにスムースに流れる」状態をずっと持続できねばならないのです。しかし、この継続的に続けるというところで、大体は躓くのではないかと思います。
これまで説明したのはアルゴリズムに過ぎず、これで全て巧くいくものではありません。経営のサポートはもちろん、皆の同意と協力が必要です。そうでないと一回きりの花火に終わります。そうならないためには、大きな偏りができないよう複数のカテゴリのプロジェクトを適度に混ぜて投入する必要があります。そしてサイクルタイム（最後に入れてから次に再び回ってくるまでの期間）を短くしなければなりません。そうでないと投入頻度の低いカテゴリに携わるグループにはマイナスに働くようになります。今売上が小さくても将来に向けた戦略としてやらねばならないカテゴリが必ずあります。ですから、皆にとって良くならないとシナリオ全体が崩れます。トヨタシステムでも平準化というのがキーになっていると聞きますが、ここでも同じことが言えるでしょう。これを妨げるとすれば、おそらく物理的な制約より方針制約の方が大きいのではないでしょうか。もちろん、何でもかんでもやるということではありません。
そういう意味でプロジェクトの投入単位を小さくするのは検討に値するでしょう。これほど変化が大きくかつ速くなると、事前の十分な調査と分析に基づいてしっかり設計してから一気に作るバッチスタイルの開発では、出来上がった頃にはもう受け入れられないものになっている可能性があります。また、開発が長くかかることは長い間無防備になることです。最初は小さく始めて、速いサイクルで仮説を検証して再ビルドすることを繰り返す、アジャイルな開発と展開が求められるようになったのだと思います。
私は最近“リーンスタートアップ”という言葉を知って、そういう変わり目に来ているという感覚が予感から確信に変わり始めています。スタートアップではなく既存のビジネスでも、こうも環境の変化が激しく速いと、どんなものに変えたら良いか初めから分かる人はいないかもしれません。顧客も何が本当の望みか初めから分からないだろうし、使って初めてそれを知るのだろうと思います。先を読んだビジョンあってのことですが、やって分かったことを短いサイクルでフィードバックしながら正しい方向に修正していかないと、おそらく期待外れになるだろうと思います。そうして、あれこれやって体力を失ってしまいます。だから、詰め込みすぎないようにして、常に機敏さを失わないようにしたいのです。
（※）バッファの色は５色です。
・白（ライトブルー）：まだ着手しないでください
・緑色：納期まで十分余裕があります
・黄色：何か問題がないか確認してください
・赤色：何も手を打たないと納期に遅れる可能性が高い危険な状態です
・黒色：既に納期遅れになっています
黒木 市五郎 プロフィール
大学を卒業後、日立系情報処理企業で18年ほど技術系ソフトの受託開発に従事。正に阪神大震災のとき1995年1月ビーイングに入社、土木積算ソフトGaiaのWindows対応版初版、カリテス原価、Avoid避難・Avoid防災など、土木・建築系パッケージソフトの設計と開発を行う。
2004年春、TOC-CCPMの情報収集に着手。そのときからTOCコンサルティンファームの米国Afinitus社および日本のゴール・システム・コンサルティング社との交流が始まり現在に至る。
2005年より社内と顧客での実証実験と並行でCCPM対応プロジェクトマネジメントソフトBeingProject-CCPM初版を開発。現在に至る
