少しでも被災された皆様のお役に立ちたい、それにはどうしたらよいかキットＰＭなりに考えましたが、やはり本職のノウハウのご提供が一番だと思い立ちました。被災された中小企業の皆様のために、緊急のプロジェクトの立上げやプロジェクトのリカバリを行う場合の計画立案のために、キットＰＭの方ハウを無償でご提供いたします。
ご提供可能なサービスの内容についてはこちらをご覧ください。
◆－－－－－－－－－－－－－－－－－－－－－◆
■福島の問題はまだ解決したわけではないのに、最近の報道量の低下はどうなっているんでしょうね。なれちゃってニュースバリューがなくなったとでも言うのでしょうか？ などど愚痴りながら、５月最初のブログをお届けします。
連休真っ最中（今日おやすみの方は．．．）ですがいかがお過ごしでしょうか。関西は昨日まで不順な天候が続いていましたが、今日は朝から晴れ渡って（ちょと待ってください。まどからの景色を見ると霞がかかっているようです）いて、暖かく気持ちのいい日となっています。
■さて、前回「現状問題構造ツリー（CRT）」の結果から抽出した”根本原因”を解決するアイデアを得るためのツールとして「対立解消図」をご紹介しました。「対立解消図」は英語では「evaporating cloud（蒸発する雲）」といいます。雲の形の対立（コンフリクト）が蒸発するように消えるからです。
せっかくですからもう一つの”根本問題”についても、「対立解消図」をあげてみましょう。まずは対立図です。 解説はなしです。
続いて、”分析”です。
そして”注入”です。
■プロジェクトの進行を阻害する”根本原因”をつきとめ、”対策”を考えたらその対策の妥当性を検証します。
妥当性の検証とは、対策が本当に有効なものであるかということと、対策を実施した場合プロジェクト内やプロジェクト外に別の悪い影響が発生しないかを確認するということです。
そのための手段として「未来問題構造ツリー（FRT）」を作成します。といってもそんなにややこしい話ではなく、考えついた「注入（injection）」を「現状問題構造ツリー」に当てはめて、ＵＤＥや追加した要素がどう変わるかをシミュレーションすればいいわけです。
■とすると、【アプリの品質が悪い】のであれば【アドオン開発をストップする】かつ【アプリの品質を上げるためのテスト作業に協力する】と仮定します。そうすると、ツリーの上部にあるもろもろのＵＤＥがどう解消されるかを検証します。ネガティブからポジティブへ変化しますね。
また、この注入によるネガティブポイントである【アドオン開発をストップする】から何が起きるかを想像します。当然、アドオンの納期が当初予定より遅れることになります。というかすでに当初予定より遅れることは確実な状況なのですが。
ここで重要なのは、対策をとったときの遅れと、とらなかった時の遅れにどのくらいの差があるかということです。取らなかったときの遅れは、解決策を実施していないわけですから予想もつかないということになるかもしれませんが。
もう一つ大切なのは、遅れが現状考えられる押さえられたとしてプロジェクトの”目的”達成にどの程度の影響があるかを考えることです。
プロジェクトによっては、納期が守れなかったときプロジェクト自体に何の意味もなくなるというものもあります。例え意味があったとしても、そのための遺失利益（失われた利益）がどの程度になるのかをちゃんと説明できることは重要です。
■ここで言う”遺失利益”は考え方がちょっと難しいです。例えば、新製品開発プロジェクトがあってプロジェクトに1ヶ月の遅れがでました。このとき失った利益はどうなるでしょう。
まず、プロジェクトメンバが１ヶ月余分に働く費用つまり人件費や経費ですね。でも会社から見ればそれだけではなく、新製品のプロモーションやり直しの費用や、製造手配のやり直し、発売タイミングのずれによる売上の減少（競合他社が先に新製品を発売する等）、そのためにやっと発売した新製品の製品寿命の短期化、次製品開発期間の短期化による影響など、様々でしかも会社全体に影響を及ぼし利益が消失するのです。
プロジェクトとしては、計画段階でリスクとしてこれらの要素をきっちり考慮しておくおことが望ましいです。
■何れにしても、「こういう理由でこういう対策をとると、結果はこうなると予測しています」という一連の流れを、プロジェクトオーナー（スポンサー）に説明することがＰＭの責務ですが、思考プロセスの作業は結果として全ての状況を論理的に説明できるようになります。これは便利でしょう？ＰＭにとって有益なツールであるのはご理解いただけるかと思います。
■さてこれで「未来問題構造ツリー」で対策をとった場合の状況が判りました。次は、その対策をどうやって実現するかという手順に進みます。
その手順を列挙すると「前提条件ツリー（PRT）」で実行の中間目標と障害を上げ、「移行ツリー（TrT）で目標に向けた行動計画を作成し、行動に移ります。
あれっ？気が付きましたか？思考プロセスという手法単独で見ると、実現までの手順を示す必要があるわけですが、ＰＭから見ると単に変更計画を立てるという作業になりますね。
ＰＭは対策をとった場合を想定して、タスクを抽出し体制を考え、リスクを検討し、プロジェクト計画書を変更管理規定に従って変更するという作業を行います。後は実施あるのみですね。
■さて、これで思考プロセスの一連の流れのご紹介は終りにしますが。えっまだ不十分ですか？ それほどややこしいことはないと思いますが、実践してみないとピンと来ないかもしれないです。また別の機会に再度挑戦するかもしれません。お楽しみに。
ところで、ケーススタディで上げたプロジェクトの結果ですが順調にリカバリしていたのですが、納期遅延による予算オーバーが大きくて、アドオン機能を大幅に削減して終了しました。その結果製品としての成功は、んーそうですね。ご想像にお任せしますと言っておきます。
■TOCの思考プロセスはいかがでしたでしょうか？ 世の中には他にも沢山問題解決のためのツールや考え方があります。ＰＭはそのなかから自分のスタイルに合ったものを探し出して、使えばいいので特別に「思考プロセス」にこだわっているわけではありません。ただ、思考プロセスはＴＯＣという統合的な体系の中で発生したもので、利用者や文献も多く使い勝手がいいとキットＰＭは考えていますので、皆さんにオススメしているわけです。
■次回からのテーマがまだ決まっていません。おっ、次回の更新日は子供の日ですね。では