【生産性のモノサシ】 普段使いのPLANとDO （４）
「全体最適のプロジェクトマネジメント」 岸良裕司、2011
PDCAのPLANとDOはプロジェクトマネジメント（以下PM）そのものだと思うのですが、一般的なPMの教科書は大げさすぎて、日常のPDCAでは使いこなせません。岸良さんの本を参考にして「普段使いできるPLANとDOのマイ・マニュアル」をつくってみました。いわばPMのアレンジレシピです。
ツール３： 問題点一覧
これは岸良さんの本には書いてなかったと思いますが、便利なのでマイ・マニュアルとして入れてみました。
Excel などを使って、問題の内容、問題解決の主担当、問題が認識された日(Open)、問題が解決した日(Close)をリストにします。問題が多すぎると眩暈（めまい）がしてきますが、坦々とリストにしてメンテナンスします。
問題点一覧をレビューするときの質問
工程表レビューで使う質問がそのまま使えます。
気がかりなことは何ですか？
なぜそう思いますか？
この（気がかりの）原因を解消するうまい方法はありませんか？
その解消策をやるメリットは何ですか？
これら（解消策）はやろうと思えばやれますか？
これら（メリット）が全部できるなら、先程の解消策をやる価値があると思いますか？
着手後に問題点が出て来るということは、その解決というタスクが新たに湧き出したことになります。新タスクの規模によっては、工程表を書き換える必要が出てきます。この場合も、フローチャート式の工程表はメンテナンスが容易です。
プロジェクト初期に問題点がどんどん増えていき、途中から減り始めます。問題点の増え具合、減り具合を見れば、おおよよ全体の進捗がわかります。問題点が全部解決しなくてもPJが完了することがあります。理由は三つくらい考えられます。
もともと心配しすぎたり、リスク予防のために提言された問題点だった。プロジェクトを始めてみると、それが懸念するほどの問題ではなかったと実感できた。
不便だけど実用に支障がないので利害関係者が了解してくれた。
かなり不便だけれど、後で改善すると約束したり、運用の工夫で我慢できるようになった。
顧客向けの製品やサービスの場合は、解決率も高いレベルが要求されます。しかし、社内の生産性改革や風土改革などの場合は、3割程度未解決でもまあまあの出来になる場合があります。我慢できる問題、後回しにできる問題を嗅ぎ分けて、避けて通れない問題の解決に全力をあげます。
付録．私のカレーライス・プロジェクト
料理は慣れた人にとっては不確定要素がないのでプロジェクトとは言えませんが、ODSCや工程表作りの例題として判りやすいので「私のカレーライス・プロジェクト」を作ってみました。
ODSC
Objectives（目的）
バランスの良い食事が取れる
美味しい
コスパが良い
簡単にできる
冷蔵庫に残っている野菜が使える
後片付けが簡単
ビールにあう
Deliverables（手段）
カレーライスを楽しむ
Success Criteria（モノサシ）
またカレーライスを作ろうと思う
まず、これを見て思うに、Objectives を満たす Deliverables には、いろいろな選択肢があります。他の料理でも良いですし、冷凍食品を買ってきたり、出前を頼むことでも達成できます。厳密にいうと、Objectives の項目同士にも優先順位があって、その日の優先順位に応じて「今日はカレーライスにしよう」という決断を日々していることになります。
またDeliverables は「カレーライスを作る」ではなく「カレーライスを楽しむ」にしてみました。ITプロジェクトも「ITシステムを完成すること」ではなく「ITが活用されている状況を作り維持すること」が Deliverables になると思うからです。
工程表
工程図を描いてみると、担当者がマルチタスクできないことや、設備の数と能力に限りがあること、など制約のせいで手順が決まる、ということが理解できます。
以下のサンプルでは、制約のせいで順序が決まる場所を点線矢印で示しています。ここでは調理者が一人しか居ないこと、電子レンジが1台しかないことが制約になっています。実際のプロジェクトでは、余力のある担当者や設備を制約があるタスクに配置換えしたり、順序を入れ替えたりして、制約を緩和することで、納期が短縮できます。
