ツナグマデザイン流PM術

ツナグマデザイン流PM術とは

ツナグマデザインの実務経験をもとに、プロジェクトマネジメントの手法を体系化したものです。

適用範囲

小規模から中規模のプロジェクトを対象とします。システム開発に限定した手法ではなく、プロジェクト一般を扱います。

PM術では、プロジェクトを依頼する側を「クライアント」と呼びます。事業会社の社内のプロジェクトでは、依頼する部署に置き換えて読んでください。

実用ベースの体系である

クライアントに見せるための整理ではなく、実際にプロジェクトを動かす現場の人間が使うことを想定しています。

PMBOK7との関係

プロジェクトおよびプロジェクトマネジメントの基本的な捉え方は、PMBOK第7版で示される定義と大きく違いません。PM術は、共通の捉え方の上に、ツナグマデザイン固有の運用思想を重ねるものです。

プロジェクトは思い通りにならない

ツナグマデザインがPM術を組み立てるにあたり、現場での経験から得た三つの認識があります。

プロジェクトの本質は不確実性である

プロジェクトは本質的に不確実性を内包しており、計画通りに進むことはほとんどありません。したがって、プロジェクトマネジメントとは、この不確実性にいかに対応するかという技術であると考えます。

メンバーもPMも、その能力以上のアウトプットは出せない

人間の能力には上限があり、プロジェクトのアウトプットはその総和を超えません。これはメンバーだけでなくPM自身にも当てはまります。したがってプロジェクトの成否は、開始前の人選と設計の段階でかなりの部分が決まっています。

プロジェクトの全ては、PMですらも把握できない

中規模以上のプロジェクトでは、進行中のすべてのアクティビティをPMが把握することは現実的に不可能です。これを認めずに全把握しようとすると、PM自身が先にボトルネックになります。

最悪ケースから設計する

三つの認識への設計の答えは、どれも最悪ケースを基準にしています。

不確実性のうち、制御しやすい方がある

不確実性は大きく上振れと下振れに分かれます。想定を上回るケースと、想定を下回るケースです。重要なのは、この二つは同じようには扱えないということです。

上振れは、発生確率や規模を事前に見積もることがほぼ不可能です。どの要因がどう作用して成功に寄与するかは、あらかじめ分解して計算できるものではありません。一方で下振れは、ある程度の予測が可能です。予算超過、納期遅延、メンバー離脱、要求の肥大化といった典型的な失敗パターンは経験的に列挙でき、それぞれに対して事前の対策も検討できます。

したがってPM術では、予測不可能な上振れを期待値として追うのではなく、予測可能な下振れを積極的に制御することを主軸に据えます。これをミニマックス思想と呼んでいます。

加えて、損失の非対称性という現実があります。プロジェクトにおける損失は、同程度の利益よりも影響が大きくなりやすい構造を持ちます。大きな失敗を一度するダメージは、小さな成功を複数積むことでは回収しきれない場合が多い、ということです。この観点からも、最悪ケースの管理を優先する戦略が合理的になります。

ミニマックスとは何か

ミニマックスとは、ゲーム理論における意思決定原理の一つであり、最大損失を最小化する戦略を指します。

ある意思決定において複数の結果が想定される場合、それぞれの選択肢について最悪の結果を評価し、その中で最も損失が小さい選択を採用します。

数式的にはminimize（max loss）と表現され、各選択肢における最大損失を算出し、その最小値を選ぶという意味です。

この原理は、将来の確率分布が不明である、あるいは信頼できない状況において特に有効です。期待値最大化の戦略とは異なり、最悪ケースを基準に意思決定を行うため、リスクの制御に強い特性を持ちます。

最悪ケースは、始める前に潰しておく

ミニマックスを採るということは、最悪ケースを許容範囲に収めるための事前準備に重心を置くということです。ここで効いてくるのが、メンバーとPMの能力の上限です。能力以上のアウトプットが出ない以上、走り出してから挽回することはできません。だからこそ、開始前にどれだけ最悪ケースを潰しておけるかが決定的になります。

最悪ケースで見積もれれば、プロジェクトは設計できる

最後は、PMでもプロジェクトのすべては把握できないという制約への答えです。

各作業や各メンバーについて、ミニマックスの考えで、最悪でもどこまでのアウトプットが出るかを見積もれていれば、その中身まで把握する必要はありません。インプットを与えれば想定の範囲内でアウトプットが返ってくる単位として扱えます。これはブラックボックスを許容する設計です。

ブラックボックスを許容できれば、プロジェクトはフラクタルなINとOUTの集合として設計できます。これをツナグマデザインではオブジェクト指向プロジェクト設計と呼んでいます。

オブジェクト指向プロジェクト設計

PMは中身に踏み込まない

設計思想が決まれば、PMの動き方も決まります。

PMはINとOUTの設計者であり、その制御者です。ブラックボックスの中身まで踏み込んで管理することは、積極的には担いません。中身まで制御しようとした瞬間に、PMはボトルネックになります。

進行中のPMが見るのはINとOUTの境界だけ

PMはINとOUTの定義を握っている張本人なので、出てきたOUTが定義どおりかを判断するのに、担当者への問い合わせは必要ありません。OUTが出てくるタイミングについても、工程設計の段階でPMが決めたものなので、自分で検知できます。進行中のPMの仕事は、この自己評価の繰り返しに集約されます。

異常を検知した時点で初めて動く

自己評価のなかで何かおかしいと判断した瞬間が、PMが動き出すタイミングです。異常の中身は、OUTが定義と違う、OUTが出てこない、外部からの制約変更、設計そのものの間違いの判明、という四つの型に整理されます。対処は、バッファで吸収する、フェーズの骨格を維持する部分的再設計、フェーズから組み直す全体的再設計、の順に考え、どこまで進むかは変更の大きさでPMが決めます。

進行中のPMの動き方の詳細は、次のサブページで扱います。

進行中のPMの動き

プロジェクトの進め”型”

ここまでの設計思想を、実際の進行に落とし込んだものが「進め型」です。各フェーズはオブジェクト指向プロジェクト設計の単位として扱い、フェーズ自体もINとOUTを持つオブジェクトとして組み立てます。事前準備フェーズが他より厚く設計されているのは、能力に上限があり、走り出してからの挽回が効かないためです。

以下に標準的な進め方を示します。ただし、進め方は現場に応じてテーラーするための型であり、無思考で当てはめることを想定していません。各ページで示す手順も、同じくテーラーするための標準の並びです。プロジェクトの規模、性質、クライアントとの関係、チームの構成によって、フェーズの粒度や順序は調整してください。

事前準備フェーズ

事前準備フェーズでPMが達成すべきタスクは、利益が出る形でプロジェクトを組み立て、実行可能な工程として成立することを確認することです。受注すること自体はPMの達成目標ではありません。受注後に自分が責任を持つプロジェクトが、利益が出る形で成立するかどうかを、受注前の段階で見極めるのがPMの仕事です。

事前準備フェーズでは、要求定義、予算設計、工程設計、チーム設計のすべてを通します。受注前だからといって仮の設計で済ませず、実際に進める計画として組みます。計画の中に仮に置いた所は、進行中に組み直します。すべてを通したうえで利益が出る形で成立すると判断できれば受注し、成立しないと判断すれば断る、というのが基本ロジックです。

なお、コンペと依頼で扱いを分けません。どちらの場合も、予算の中で利益が出る形にプロジェクトを組み立て、工程として実行可能か確認するという構造は同じだからです。

クライアントが企画を重視していないと、企画のないままプロジェクトが進むことがあります。PM術では、クライアントに求められていなくても、PMが能動的に企画を行います。

企画の考えは、要求の読み方、予算への収め方、工程やチームの組み方など、プロジェクトのどの段階にも出てきます。そのうえで、企画を一つの作業として切り出して行う所が、二つあります。「受注前企画」と「工程内企画」です。受注前企画は、提案のための方針レベルの企画で、予算設計の後に行います。受注前企画が成立したら、工程設計とチーム設計に進みます。工程内企画は、制作に入れるレベルの企画で、実作業フェーズの中で行います。

受注前企画と工程内企画は、両方を切り出すプロジェクトもあれば、片方だけのプロジェクトもあります。受注前企画を切り出さないときは、工程内企画を厚くして、方針から決めます。大きな視点での企画の余地が小さいプロジェクトもありますが、その場合でも、どの段階にも工夫の余地があります（ケース3）。どこに、どれだけ力を入れるかは、案件に応じてテーラーします。いずれの場合も、企画を重視するというPM術の骨子は変わりません。

企画の組み立て方そのものは、PM術では扱いません。