どうも！カワヤスです。
前回記事では複数プロジェクトで発生するよくある問題について述べました。では、複数プロジェクトはどのように進めることが良いのでしょうか？この記事ではプロジェクトの全体最適を目指し、複数プロジェクト進め方のポイントについて具体的に言及して参ります。今までプロジェクト管理で悩みを抱えていた方は、改善の本質について気づくきっかけになればと思います。この記事が皆様のプロジェクト管理のヒントとなれば幸いです。
結論
と声が聞こえてきそうですが、しっかり解説していきたいと思います。では解説に行きましょう！
複数プロジェクトで発生する問題点
これは、リソースの競合が問題でした。この問題によって、下のような２次的問題が出てきます。
２、リソース競合を調整した結果生じる計画のズレを利害関係者と都度すり合わせなければならないという負荷が高いという問題です。しかし、調整しなければドミノ倒しのように各プロジェクトが総崩れしてしまいます。
あるステップで遅れた場合のリソース調整
多少ステップで遅れた程度では、スケジュールやリソースを再調整する必要はないです。例えば、あるステップで10日かかるとします。しかし、場合によっては７日で終わることも、15日で終わることもあります。ところが、合流バッファやプロジェクトバッファを考慮しないまま調整を進めると、ただ調整の負荷が高いだけになってしまいます。これは、パス全体の見積日数が３０日ある時でも、３日間のリソース競合を重大な問題だとみなしてしまったことに因ります。8*8=64という考え方に捉われてしまったということです。しかしながら、実際には多少の遅れであれば、調整せずにそのままにしておけば、楽にバッファで吸収できるはずです。常にスケジュール変更を余儀なくされる状態ではないはずです。
リソースの競合を考慮に入れた調整
リソースの競合は無視してはいけませんね。複数のプロジェクトがある時はなおさらです。リソースが競合したときはどうすればよいでしょうか？
製造の場合
機械の前に作業がいくつか溜まっていて、どれから作業したらいいのか優先順位がはっきりしていない場合は、いつもリソースの競合の問題が発生します。複数の作業が同じリソースをめぐって争うのです。
その場合の対応は？
ずべての機械の仕事一つ一つにスケジュールを組もうとすることが馬鹿げていることは学びました。まず、最初はボトルネックを見つけるのです。そして次にボトルネックを徹底活用します。ボトルネックでの作業の順序を決めるんです。そうすれば制約条件上での競合はなくなります。ボトルネックは同時に複数の作業をしなくて済むようになります。それから制約条件に従わせます。制約条件以外のすべてのリソースを制約条件に従わせます。そうすると、他のリソースからは余計な負荷をほとんど取り除くことができます。散発的に残るものもあるかもしれませんが、それはバッファで吸収することができます。
プロジェクトの場合
プロジェクトのボトルネックは何でしょうか？ボトルネックをしっかり認識しなければどうなるでしょうか？
・バッファを用意してボトルネックをマーフィから守ることもしない。
・プロジェクトの同期化が難しくなるだけでなく、製造の場合と同じで悲惨な結果を招くことになる。
・必然的にボトルネックの貴重な時間が無駄にされる結果になる。
→その結果、会社全体のスループットが減る。完成するプロジェクトの数も減る。
では、ボトルネックは？
プロジェクトではそれぞれの会社において異なることかと思います。が、例えば何かのアプリケーションの開発であればIT部門、工場のプラント建設であれば生産技術部門などがボトルネックに当たるということで良いかと思います。そしてそのボトルネックの部門のスケジュールをまず決めます。
どうやって？
製造の時と同じように決めるのです。製造の場合、優先順位はオーダーの納期に従って決めますが、プロジェクトの場合は目標完成期日によって決めればよいわけです。一つ一つのプロジェクトを個別に扱えばいいのです。他のプロジェクトからの影響はボトルネック部門のスケジュールが決まれば自然と考慮されます。多くのプロジェクトにおいてそのボトルネック部門で行うステップがあります。ボトルネック部門のスケジュールが固まれば、これらのステップの作業開始と作業終了日がわかります。各プロジェクトでは、他のプロジェクトのことはまったく気にせずに普通に作業を行います。リソースの競合を無くしてやるんです。あとは、各プロジェクトをボトルネック部門のスケジュールに合わせて調整すればいいのです。
クリティカルチェーンは変わったりしないか？
プロジェクトによっては変わるものもあります。バッファはもちろん挿入します。これまで述べてきたバッファ、つまりプロジェクトバッファ、合流バッファ、リソースバッファはどれも、個々のプロジェクトを保護するために使われます。ここで忘れてはいけないのはボトルネックも保護しないといけないところです。つまり、会社全体のパフォーマンスも守らなければいけないということです。そのためにもう一つ別のバッファを組み込みましょう。それはボトルネックバッファというものです。本書のケースでは２週間もあれば十分すぎると判断し、ボトルネック部門を通過する全てのパスについては２週間早めに作業を開始するようスケジュールを組んでいました。
ボトルネック部門のスケジュールを決めるだけで本当に十分なのだろうか。
製造の場合、ボトルネックだけでなく他のリソースも考慮しないといけないときもあります。キャパシティに制約がある場合などです。プロジェクトの場合は、合流バッファを監視していれば、十分でです。リソースが競合しているせいで合流バッファが食いつぶされ始めたら、それでわかります。しかし、その時まではじっと我慢です。実際にそういう状況になるまではすぐにリソースが競合しているといって動いてはいけません。負荷が過剰になったとクレームが来てもすぐに騒いではいけません。
まとめ
結論、「複数プロジェクトの進め方のポイントはTOCのファイブステップを活用して調整すること」でした。製造の場合もプロジェクトの場合も、まずはTOCの考えに基づけば、合理的に改善や調整を行うことができます。
最後になりましたが、本記事が皆様に少しでもお役に立てれば光栄です。今後ともカワヤスブログをお願いいたします。
コメント