「進め方」は、プロジェクトで行われる作業について、「作業手順」「役割分担」「成果物」を細かいレベルで記述したものです。

詳細スケジュールと何が違うのかと思われるかもしれません。違いは「予測」あるいは「仮説」として、変化を許容するところです。

通常、スケジュールは当然守らなければならないものであり、その変更は本来あってはならないものとされます。
変更はやむを得ないときに発注者と受注者の上位責任者合意のもとで行います。しかし、入れ子のプロジェクトでそのような手続きを踏んでいては事態をどんどん悪化させることになます。「進め方」はその時点で想定されているベストの予測であり、想定されている事象が起きれば、現場ですぐに変化させていく柔軟性を持たせます。

「進め方」は例えると台風の進路予測のようなものです。

台風の進路予測は台風がある時点で、どんな進路で進むはずで、どこを通過するはずで、どういった影響をもたらすかを時間ごとに積み上げたものです。
「進め方」は、「どんな手順で作業が進むか」、「誰が行うか」、「どういった成果を出すか」という予測を時間ごとに積み上げたものです。（図2）。

台風の進路予想があるから、進路にあたる地域はそれに対応する準備ができます。
同様に、「進め方」に関わる要員はあらかじめ対応の準備ができます。また、台風の進路の予想は時間とともに正確になっていきます。同様に作業の「進め方」も時間とともに正確になっていきます。

「予測できることすらしていない現実」

多くのプロジェクトにおいて、「プロジェクトは不確実で予想のしようがないもの」と予測することをあきらめてしまっている現状があります。

確かに、プロジェクトは予想もしないようなさまざまな事が起こります。しかし、予想できないといって、予測できることすら怠ってしまっているのではないでしょうか。

私たちは、プロジェクトで起きる出来事の多くが、しっかりと精度の高い予測を行うことにより、
「予想外の事態が発生する頻度を減らすことができる」そして、「予想外の事態が発生しても、軌道修正を最小限で済ませることができる」ということを、これまでのプロジェクトの経験を通して確信しています。

予測できることですら怠りプロジェクトを開始し、さまざまな事態が立て続けに起こってから右往左往するような状況では、プロジェクト管理のしようがありません。

初めから嵐の予想される海域に船出をするような無謀な行為です。

しっかり予測することによって、想定外の事態が発生する割合を減らし、発生した場合も最小限の軌道修正で済むような状況を作っておきます。
そうすることで、はじめてプロジェクトはコントール可能となり、プロジェクト管理が機能する状態となるのです。

札幌市のシステム再構築プロジェクトでは、入札によりプロジェクトのベンダーが決まった後、プロジェクト計画の策定までに約１ヶ月という期間をかけています。

この期間で、ベンダーが提案するプロジェクト計画における「進め方」を練り・共有してプロジェクト計画書に落とし込む作業をしています。

「習熟度によって異なる進め方の具体例」

「進め方」が具体的にどのようなものかを図3を使って説明します。

「進め方」は、数多くの異なる要因によって、最適なものが変わります。

例えば、現行業務の分析の場合は、さまざまな資料を参照し、関係者にヒアリングを行って分析結果の成果物を作成します。

そのため、業務の複雑さ、作業者の業務習熟度、参照資料の充実、成果物の流用可能性などによって選択するべき進め方は変わります。

図3では、作業者の業務習熟度の違いに着目して、どのように進め方が変わるのかを説明するために、習熟度の高い作業者向けの「進め方①」と習熟度の低い作業者向けの「進め方②」を示しています。

「進め方①」は、作業者の業務知見に基づいて、発注者にヒアリングしなくても成果物のドラフトを作成できます。

それを提出したものを発注者側が持ち帰って赤入れをして返すことで、成果物の修正を行うことができます。

「進め方②」は、習熟度の低い作業者なので、最初に発注者にヒアリングをする必要があります。

発注者のチェックも成果物への赤入れだけでは指摘量が多すぎて正しく意図が伝わらなくなるため、対面で確認するステップを踏みます。

習熟した作業者であれば、「進め方①」のほうが同じ品質レベルの成果物を効率的に作成できますが、習熟度が低ければ、「進め方②」でなければ十分な品質の成果物にはなりません。

こうした進め方に影響を与える要因にはさまざまなものがあります。

いくら習熟度が高くても、参照資料が少なければ「進め方①」は困難となります。逆に、過去の成果物が流用できるのであれば、熟練者でなくても「進め方①」に近い形で進めることが可能です。

これらの要因は、プロジェクトごとにも異なりますが、プロジェクト体制のチームごと、業務ごと、対象システムごとにも変わりますし、当初想定していたのとは違っていたということも起こります。

たとえば、途中から参加した作業者が、業務に習熟しているはずだったのに、実は似ているけれど違う業務の専門家で、直接の知見はなかったということが判明したりします。

そうした場合は、当初予定していた「進め方①」ではなく、「進め方②」に変更するのが適切です。逆に当初は熟練度が低く「進め方②」で進めていたが、プロジェクトを通じて習熟度が上がった結果、「進め方①」を最小しても大丈夫になる場合もあります。

要因のパターンはプロジェクトごとに異なっているので、プロジェクトの内容が明確にならない限り用意することはできません。

そのため、プロジェクトの開始時点でプロジェクトのバリエーションを想定して、それに応じた進め方の検討を行う必要があるのです。

この検討をしておくことで、想定範囲内の要因の変動があっても、慌てることなく進め方を素早く組み替えて対応すること可能になるのです。