工程設計

工程設計は、プロジェクトの骨格を組み立てる作業です。PM術では、工程設計そのものはオブジェクトではなく、フェーズを組み立てるためのスキルとして位置づけます。

工程設計は、事前準備フェーズの中で、予算設計のあとに行います。受注前企画を切り出すときは、受注前企画のあとです。材料は、最終的なOUTと制約条件です。

最終的なOUTがどこまで決まっているかは、受注前企画を切り出したかどうかで変わります。受注前企画を切り出したときは、何を作るかの方針まで決まっています。受注前企画を切り出さないときは、何を作るかの方針も、実作業フェーズの工程内企画で決めます。工程設計では、工程内企画のフェーズを最初に置き、あとのフェーズは、要求定義で決めた手段の取り扱いをもとに仮に置きます。工程内企画のOUTが出たところで、あとのフェーズを組み直します。

制約条件は、予算設計で出した総工数と、要求定義で確かめたクライアントの納期です。工程設計で作る工程表は内部の管理用で、クライアントに見せるマイルストンとは別に作ります。

予算設計で総工数と要求を見比べるとき、PMは粗い工程を思い描いていることが多いです。粗い工程を土台にするか、改めて組み直すかは、PMが決めます。

フェーズは、クライアントにマイルストンとして説明できる単位で切る

PM術では、フェーズを、いちばん上の階層のオブジェクトとして扱います。フェーズは不可逆で、シングルスレッドで進み、クライアントにはマイルストンとして説明できる単位です。

工程設計の手順

工程設計はフェーズ階層から始め、フェーズ階層が固まってからオブジェクト階層に降りていく流れで進めます。

手順1から3までは、PMが独断で行う仮設計です。経験にもとづいて、フェーズの分割、後ろからの逆算、工数の見当までを一通り置きます。手順4で担当オブジェクトに問い合わせ、その結果を受けて手順5で本設計に確定させる、という二段の流れを取ります。

1 分割の細かさを決める

最終的なOUTと最初のINを見て、フェーズをどの程度細かく分割するかを決めます。PM術の進め型にある、セットアップ、実作業、フィニッシング、事後処理のフェーズをそのまま使ってもよいですし、プロジェクトの性質に合わせてテーラーしても構いません。

分割の細かさも、クライアントにマイルストンとして説明できる単位かどうかで決めます。

進め型の実作業フェーズは、工程内企画を切り出すときは、工程内企画のフェーズと、企画以外のフェーズに分けます。PM術は企画を重視する立場を取っているため、工程内企画を独立したフェーズとして切り出すことが、実作業フェーズを分ける出発点になります。

あわせて、クライアントから見たマイルストンの観点も働きます。実作業の中身を分割せずに一つのフェーズとして扱うと、最終OUTまで中間のマイルストンが存在せず、クライアントへ何も提出されないまま走り続けることになります。工程内企画をフェーズとして切り出さないときも、実作業の内部はPMの判断で分けて、中間のマイルストンを置きます。

実際には、企画以外の部分もさらに細かく分けることが多いです。実作業の内部をどう分けるかは、案件の中身に応じてPMが設計する部分で、PM術の中でも特に重要な作業です。

なお、フェーズはオブジェクトと違い入れ子にはできません。直列に並ぶ複数のフェーズに分割するのであって、一つのフェーズの内部にさらにフェーズを抱えるのではありません。フェーズの内部にオブジェクトを抱えることはできます。

2 後ろからフェーズを決める

分割の細かさが決まったら、フェーズを後ろから順に組み立てます。最終的なOUTから逆算して、手前のフェーズのOUTを決め、さらに手前のフェーズのOUTを決める、という形で前に向かっていきます。

後ろから決める理由は二つあります。一つ目は、INとOUTが本質的に同じものを指しており、目的が成果物であるため、成果物から逆算するのが自然だからです。二つ目は、最終OUTに要らない作業を入れないためです。前から組み立てると、最終OUTに直結しない作業が混入しやすくなります。後ろから組み立てれば、最終OUTに必要なものだけが残ります。

3 各フェーズに工数を割り当てる

フェーズの並びが定まったら、総工数を各フェーズに人日単位で割り当てます。

ここで実務上の前提を一つ置きます。セットアップフェーズ、フィニッシングフェーズ、事後処理フェーズは、原則としてPM一人で完結する小工数のフェーズです。それぞれ1人日から2人日程度に収まることが多く、しかも案件規模によらずほぼ一定です。3つのフェーズは、商談やプリセールスと同じく会社として案件管理にかかる固定的なオーバーヘッドとして扱い、プロジェクト工数の外側で見るのが標準的な運用です。

したがって、ここで割り当てる総工数は、実質的に実作業フェーズが受け取る形になります。たとえば総工数100人日の案件であれば、実作業フェーズに100人日を充てます。総工数30人日の案件であれば、実作業フェーズに30人日を充てます。

ただし例外もあります。規模が大きく、セットアップで広範な権限設定や環境構築を伴う場合、フィニッシングで複数人による検収プロセスを伴う場合、事後処理が単なる片付けを超えて成果物の運用引き継ぎなどを含む場合は、それらのフェーズもプロジェクト工数として扱います。

4 担当オブジェクトに可能性を問い合わせる

工数の割り当てが終わった段階で、各フェーズを担当するオブジェクト、つまり人やチームに対して、割り当てた工数で実行できるかを問い合わせます。事前にある程度は調べているはずですが、ここで明示的に確認する手順を踏みます。

問い合わせの中で仮設計と現実の間にずれが見つかった場合は、その場で手順1から3に戻り、各フェーズの工数や設計を調整します。手順5に持ち越すのは、すべての問い合わせが終わった時点で工数全体に余りや不足が出た場合の最終調整だけです。

5 仮設計を本設計に確定させる

手順4の問い合わせで返ってきた情報を受けて、手順1から3で組んだ仮設計を本設計に確定させます。手順4で調整しきれなかった、工数全体の余りや不足も、ここで調整します。各フェーズの担当が決まり工数の上限が見えたうえで、フェーズ内のオブジェクト分割もこの段階で確定させます。オブジェクトの基本的な性質やフラクタル構造、ブラックボックス許容といった一般的な原理については、オブジェクト指向プロジェクト設計を参照してください。

フェーズ内のオブジェクト分割には、工程設計に特有の二つの原則があります。

一つ目は、シングルスレッドを基本にすることです。フェーズはシングルスレッドという制限がありますが、フェーズの内部のオブジェクトには厳密な制限はありません。並列に走らせることも理論上は可能です。ただし、並列処理は管理コストが高いため、基本的にはシングルスレッドを推奨します。例えばシステム開発であれば、UXデザインからコーディング、そしてテストへと、ひとつの流れで進めることが多いです。

二つ目は、PMの解像度に合わせて分割粒度を決めることです。PMの解像度が高い領域では、行けるところまでオブジェクト設計を進めて構いません。逆に解像度が低い領域では、オブジェクトを大きいまま置き、最低限INとOUTをきちんと握ります。

6 営業日に並べて内部工程表を作る

ここまでの設計が確定したら、フェーズやオブジェクトを営業日上に並べます。並べたものが、内部用のスケジュールである内部工程表です。

クライアントへの提示と内部工程表の関係

工程設計のアウトプットである内部工程表は、クライアントが要求する納期より必ず短くなるように組みます。ミニマックス思想にもとづき、最悪のケースでも要求納期に間に合うようにするためです。

クライアントには、内部工程表と要求納期の差分を等分なり加重なりで配分したマイルストンを提示します。

PM術では、内部工程表と要求納期の差分を、制御対象のバッファとしては扱いません。ミニマックス思想で組まれた内部工程表は理論上必ず間に合うものであり、差分は成り行きの余りにすぎないので、利用も管理もしません。

計画に入れる余りは、計画的バッファだけ

PM術では、計画上の余りと、実行中に結果として生じる余りを、別のものとして扱います。

計画的バッファは、予算設計で意図的に確保した余りです。予算のうち利益として確保した分を人日に換算したもので、下振れを吸収するために事前に計画して持ちます。

偶発的バッファは、プロジェクト進行中に、計画した工数を実際には使い切らなかった結果として生まれる余りです。ミニマックスで上限値を取って見積もったオブジェクトが下振れずに終わったときに、上限値と実際の値の差として生まれます。事前に計画するものではなく、走らせてみて初めて見えるものです。

計画に入れるのは、計画的バッファだけです。偶発的バッファを当てにして計画を組むなら、当てにした分は、はじめから計画上の余りとして見積もっておくべきで、見積もりが誤っていることになるからです。生まれた偶発的バッファを何に使うかは、PMがその場で決めます。

作業ではなく、成果物を分解する

工程設計は、最終OUTから逆算して成果物を分解していく手順です。作業を洗い出して並べていく分解とは、性質が異なります。PM術が作業の分解を採らない理由は、漏れなく重ならない状態（MECE）を論理で保証できるかどうかにあります。

成果物の分解には、MECEを論理で保証する道筋があります。前工程のアウトプットが次工程のインプットになるという制約が、分解の完全性を保証するからです。一方で、作業は目的を達成するための手段であり、目的が同じでも経路は複数あり得ます。よって、ある作業の集合が必要十分であることを、論理で保証する手段がありません。PM術が作業の分解ではなく成果物の分解を採るのは、保証できるかどうかに差があるためです。

PMBOK の WBS は、プロジェクトのスコープを、成果物を単位に階層で分解したもので、PM術の成果物の分解と同じ考え方です。実務では、WBS という名前で作業の一覧を作ることも多いですが、PM術の工程設計が近いのは、PMBOK の WBS のほうです。