連載
» 2009年04月16日 00時00分 UPDATE

TOC流の開発型プロジェクト管理術「CCPM」(6):対策の実施されないマネジメントは今すぐ中止! (1/3)

量産型工場の生産管理手法として生まれたTOCは、そのエッセンスを拡張させて設計開発型業務のマネジメントにも応用されている。TOCの最新ツール「クリティカルチェーン・プロジェクトマネジメント」を紹介しよう。

[村上悟, 西原隆/ゴール・システム・コンサルティング,@IT MONOist]

 前回までの連載で、開発プロジェクトをコントロールするポイントは、バッファ・マネジメントであり、そのためにバッファを中心としたマネジメント(PDCAサイクル)のDo(実行段階)、Check(確認段階)について説明してきました。最終回になる今回は、Action(対策場面)について考えていきます。

Actionにつながらなければ意味がない

 すべての管理はCheck(確認段階)からAction(対策)につながっていなければ意味がありません。もし、確認だけで、その後何ら対策が行われないならば、そのような作業は即刻やめるべきです。すべての管理には膨大な工数が掛かります。貴重な時間を無意味に使う管理は行うべきではありません。

 CCPMも問題が確認されたらAction(対策)が取られないならば、実施する意味がありません。CCPMのActionは、バッファがレッドゾーンに入った時の「応急対策」、遅れの原因そのものを改善していく「プロセスの改善」、遅れ原因解決を邪魔している組織的な問題を解決する「システムの改善」の3つのタイプに分けられます。今回は、この3つについて順に考えていきます。

(1)応急対策:直近の状況を改善する

 バッファがレッドゾーンの場合、そのまま放置しておけばほとんどのプロジェクトは納期遅れになります。ですから、バッファがレッドゾーンにある場合はバッファ消費率を回復させるための対策を実施する必要があります。この対策は一般的には下のような対策が取られます。

応急対策検討の視点

スコープ

スコープ削減ができないか検討する

プロジェクトの目的を再確認し、削減できるスコープがないか確認する(分割納品の検討など)

品質

品質に関連する項目について検討する

品質が過剰になっていないか検討し、あれば削除する

以降の品質トラブルを減らすため品質管理を増加させる

資源

資源(人・設備など)に関する項目について検討する

開発者の交替(ベテランの投入など)

開発者の増員(増員による混乱防止を十分検討しておくこと)

リソースを追加して並行作業を増やす

外注を活用できないかを検討

時間

時間(納期)に関する項目について検討する

社内的に決められた納期の場合再設定可能か検討する

スコープ

マネジメント業務(リーダー業務・計画・組織全体への影響)に関する項目について検討する

マネジメント業務のフォロー

優先順位変更

計画の見直し実施

情報ロット分割によるスピードUP

他プロジェクトの停止によるリソースの確保


 権限を持つスタッフの協力を得る

 前回までの連載記事でも説明したように、製品開発のプロジェクトリーダーには大きな権限が与えられないことが多く、対策実施の選択肢は限られています。納期を守るための対策は権限を持ったそれぞれの関与者の協力が不可欠です。

 組織的対応のためのマネジメント体制

 このためにも、プロジェクトの進ちょく状況を、それぞれの責任者がバッファ傾向グラフで共有し、レッドゾーンに入れば迅速に組織的に対策しなくてはなりません。変えるべきポイントは、これまでプロジェクトリーダーに丸投げされていたプロジェクトマネジメント体制なのです。

 コミュニケーションルートの把握

 レッドゾーン対策ではさまざまな人がかかわりながら意思決定が行われます。この意思決定スピードを速めるためには、どのようなレッドゾーン対策が可能なのか、その対策は誰が意思決定して実行されるのか、というコミュニケーションルートを整理しておき、いざというとき迅速に対策が実施できる体制を構築することも重要になります。

(2)プロセスの改善:中長期的に対策する

 プロセスの改善では、タスクが遅れる原因を追究して再発しないような対策を打ちます。

図1 バッファ傾向グラフ 急激な遅れ 図1 バッファ傾向グラフ 急激な遅れ バッファ傾向グラフを作成すると開発プロセスを統計的に管理できるようになります。

 いままでの計画立案方法では各作業の見積もりは、ほぼ守れる安全な日数が見積られていました。そうなると多くのタスクは遅れることなく進ちょくし、改善すべき問題が見えない状況になっていました。しかし、説明したようにCCPMでは50%の確率でタスクの見積もりが行われるため、多くの問題が見えるようになります。バッファ傾向グラフから特に急激にバッファを消費しているところを見つけ、その原因を分析すれば改善すべき重要な問題を明確にすることが可能です。

 バッファ傾向を基にしたパレート図から問題を特定・改善する

 複数のプロジェクトのバッファ傾向グラフを確認し、急激に遅れるタスクとその発生原因についてのパレート図を作れば、組織的に取り組むべき問題を効率よく特定できます。

 問題を特定し、改善担当チームを結成、徹底して改善していく。こういった取り組みの繰り返しにより継続的に改善する企業体質を構築できるのです。

 QC、シックスシグマ、CMMへの取り組みなど開発でもさまざまな改善活動が行われていますが、活動のテーマをどうすべきかは難しい問題です。中には発表会に報告しやすくするために、解決しやすい改善テーマを選ぶといったことが横行し、活動が形骸(けいがい)化しているケースも見受けられます。しかし、ここで説明したように、バッファ傾向を中心に、開発プロセスを統計的管理状態にしたうえで改善活動を行えば、有効な改善活動ができるようになることはいうまでもありません。

       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.