　そこで、バッファ傾向グラフを使って過去のプロジェクトから、よく問題が発生しているタスクだけをペアプログラミングで実施します。またペアプログラミングで実施しないタスクも、ペアを組ませておき、毎日作業状況を少しでも確認するようにします（ペアレビュー）。このようにペアプログラミングはバッファ傾向グラフと組み合わせて使うことで効果を最大限に引き出すことが可能になります。

　ペアプログラミングは、ソフトウェア開発で行われる方法ですが、メカ設計・電気設計などの業務でも応用が可能です。大きな効果がありますので検討してみるといいでしょう。

DBRとバッチサイズ縮小

　TOCで生産リードタイム短縮を狙う場合、DBRと呼ばれる手法を展開しますが、これを実施するときは、必ずバッチサイズ縮小に取り組んで、リードタイム短縮を実現します。

　バッチサイズとは、1回で実施する作業ひとまとまりの大きさを意味しており、ロットサイズとも呼ばれます。バッチサイズが大きいと、まとめ待ちの時間が発生し、リードタイムが長くなります。よってバッチサイズを小さくし、待ち時間を減らす改善を行います。

　あまり意識されていませんが、開発でも同じようなことが起こっています。

　例えばデザインレビューでは、100個の機能が完成して同時にレビューするという決まりになっていれば、99個が完成しても、残り1個のためにデザインレビューが開催されず、99個の作業が待ちになります。これによりリードタイムが長期化します。100個の要求仕様があり、100個設計して、100個コーディングして、100個テストするこういったソフトウェア開発のやり方が一般的ですが、これはまとめ生産しているのと同じ問題が発生させます。開発業務ではあまり意識されていませんが、バッチサイズを小さくするための改善を行うことは、重要なテーマになります。

システムの改善と組織全体の方針

　バッファ・マネジメントを展開すると、プロジェクトが遅れる原因が明確になっていきます。このときプロセスを改善するだけでなく、なぜいままで遅れの原因が解決されず放置されてきたのか、根本的な問題までさかのぼって検討し改善していく必要があります。

　問題が解決されず長期間放置されているような場合、問題相互が複雑に絡み合い根深いジレンマが存在していることがあります。さらにジレンマの背後には、組織の方針や評価制度などマネジメント体制そのものが問題である場合も少なくありません。

　これらの組織的な問題を解決できれば、開発業務そのものを大幅に改善できます。このためには組織方針の「何を」「何に」「どのように」変えるべきかを明らかにしていくTOC思考プロセスを活用し、組織の在り方そのものから考えていくことが必要になってきます。

　以上、説明してきたような取り組みによってCCPMを展開することから始まり、評価制度・方針など組織の問題まで改善していく継続的改善の仕組みを構築し定着させていくことができるのです。

図2　TOC思考プロセス5つの図

改善のヒントはバッファ管理から見えてくる

　本連載ではTOCのプロジェクトマネジメントであるCCPMについて解説してきました。

　いままで学んできたプロジェクトマネジメント方法と全く異なると感じた方、自分がやってきたことが整理され体系化されたと感じた方など、さまざまな感想があると思います。

　マネジメントとは、F. W. テイラーの科学的管理法を出発点として20世紀になり発展してきたといわれています。連載第1回で説明したとおり、不確実性の高い新製品開発・ソフトウェア開発では、テーラーのマネジメントサイクルをうまく回せません。

　時代の変化に伴い、生産マネジメント手法も、トヨタ生産方式、TOC、セル生産など新しいスタイルに変化してきました。プロジェクトマネジメント手法もアジャイル開発、リーン開発、TOC／CCPMなど、従来と基本的な考え方（パラダイム）を異にした手法が紹介されるようになってきています。

　バッファ管理を中心としたTOCのプロジェクトマネジメント方法であるCCPMは、PMBOK第3版に掲載されてから急速に普及しています。CCPMの歴史そのものは浅く、まだまだ発展途上の手法ですが、バッファを中心としてプロジェクトをマネジメントすることで、いままで見えなかったものが見え、確実に改善に向かうことができる大変パワフルな手法であることはご理解いただけたのではないでしょうか。

　いま混乱している開発現場を変えていくことができるCCPMをぜひ皆さまの組織に活用してみてください。

前のページへ 1|2|3 　　　　　　