進め方を明確にする過程で発注者として気を付けるポイントとは、「(1)発注者が理解できる程度に進め方が詳細化されているか」「(2)進め方を考慮したスケジュールになっているか」の２点です。

また、プロジェクトの規模や難易度によっては「(3) 実際に試してみてどうか」という点もチェックします。

最後に、(1)～(3)まで確認してできあがった進め方について「(4) 資料化され関係者が共有できるようになっているか」ということ確認するようにします。

以下にそれぞれのポイントについて説明します。

(1) 発注者が理解できる程度に進め方が詳細化されているか

まず、成果物の作成を始めてから成果物が完成するまでに、「どんな作業手順で実施するのか」「誰が何を実施するのか」「それぞれの作業手順でどのような成果を出すか」について発注者が理解できる程度に進め方が詳細化されているかを確認します。

その後、「発注者の作業が進め方として考慮されているか」や「役割分担が具体的になっているか」といった点についても確認を行うようにします。

「発注者の作業が進め方として考慮されているか」

成果物の作成には、発注者での確認や指摘などベンダーと発注者のやりとりが必要なことが多くあります。

特に要件分析や基本設計などの上流工程はその割合が大きくなります。

ところが、ベンダーから最初に提示される進め方やスケジュールは、発注者側の作業内容の考慮がされておらず、その前提でスケジュールが組まれているということが多く見られます。

事例プロジェクトにおいても当初の進め方やスケジュールでは発注者とベンダーとのやり取りが発生する作業での進め方やスケジュールの想定が不十分な箇所がありました。

一例を挙げると、図4の作業のうち「成果物確認・指摘」の作業が業務所管部門の職員数を考慮していない赤入れの分量と期間で、実質的に困難なものでした。

また、「成果物確認・指摘」と「プレヒアリング」の位置づけが曖昧で、発注者の成果物指摘は赤入れでもプレヒアリングでもどちらでも良い様な形になっていました。

そのままだと、赤入れ期間が短いため、「成果物確認・指摘」作業でやるべき確認や指摘が「プレヒアリング」で行われてしまい、ヒアリングの長時間化やヒアリングが時間内に到底終わらないという懸念がありました。

そこで、プロジェクト計画のタイミングでベンダーと共に後述するモデルヒアリングやカレンダーに落とし込んだスケジュールのシミュレーション結果などを踏まえて、進め方やスケジュールを調整しました。

「役割分担が具体的になっているか」

ベンダーから提示される進め方に記載されている役割分担は、それぞれの作業手順のなかで、具体的に役割を担う人がどのような観点で成果物を作成・確認し、成果物の品質を高めていくかということが曖昧なことがよくあります。

役割ごとの観点やさらに具体的に落とし込んだチェックリストを作成するといった方法で、役割を担う作業者が具体的な内容をイメージできるレベルになっているかを確認します。

事例プロジェクトでは業務範囲が広いことや業務所管課の専任職員の人数が限られることから、発注者側の確認作業には専任職員だけでなく本庁や区で実際に業務を行っている職員を含めて作業体制を組んでもらう形を取っていました。

その結果、それぞれの関係者の役割が同じなのか違うのかという点が曖昧になった役割分担となっていました。

そこで、それぞれの関係者でどのような確認を行うかをチェックリスト化することにしました。

(2)進め方を考慮したスケジュールになっているか

作業手順が詳細に想定できるようになったら、立てられているスケジュールが、それらを見込んだものになっているかを確認します。

全ての成果物を作り上げてから次の作業手順に行くのは非効率なため、ある程度の数量をまとめて1つの塊とし、複数並列させて作業することになります。

私たちはこの1つの塊のことを「ロット」と呼んでいます。

作業手順ごとにかかる日数を積み上げて、1ロットが完了するまでに必要な日数を計算し、成果物の総量からロット数を算出して全体スケジュールに収まるように調整しながら作業スケジュールを組み立てます(図6)。

この、ロット単位で作業を管理するという方法は、進捗を図る際において、現在どのロットまで作業が終わったのかといった形で進捗を把握しやすくできるというメリットもあります。

「作業手順ごとの日数は妥当か」

ベンダーから提示されるスケジュールには、作業手順ごとにかかる日数の積み上げが不十分なことがあります。

ある作業から次の作業に移行する日数の考慮が不足していたり、土日は作業日数に含めるのかどうなのかが曖昧だったりということがあります。

作業者が成果物を受け取ってから7日で作業という期間を設定した場合に、「7日というのは8日目の朝までに相手に届くように送るのか」といった点や、「この作業は土日も日数にカウントするこのか、予定を入れることは問題ないかといった点について、実際にカレンダーに落としてみるなどしてシミュレーションします。

ここまでシミュレーションすると、ある作業から次の作業に移行するのに半日ないし1日をロストしているケースがあります。

それらは積みあがって1週間単位の誤差になることに気がついたりします。

事例プロジェクトでは、ロットごとの作業開始から終了までのスケジュールをすべてカレンダーに合わせて落とし込んだ表を作成しました。

それにより、実際に当てはめてみてどうかという検証と、複数ロットが並行して走る場合に作業が重複し無理がでないかという点を比較できるようになり、それをもとにロットスケジュールを組み立てていきました（図7）。

「成果物によって数量や期間を変える必要はないか」

また、成果物の複雑さによっては、作業の難易度が変わってくる場合があります。

その場合、進め方で定めた作業期間が変動することがあるため、注意が必要です。

その可能性がある場合は、1ロットにかかる作業期間が一定になるように成果物の数量を調整するか、成果物の量を変えずに、作業の難易度によって松・竹・梅のようなランクを付け、プロセスの作業期間を変動させるかといった方法で進め方を検討するようにします。

つまり、ロットごとに異なる進め方を採用することができるということになります。

事例プロジェクトの場合は、分析作業の手間のかかり方の違いに直結する、インプットになるマニュアルや資料などの充実度を松・竹・梅と分類し、それにあわせて１ロットあたりの成果物の数量を調整しました。

そして、資料があまり充実していない梅ランクには、成果物作成の前に業務所管部局からのヒアリングにより、不足している情報を入手するという作業を１つ追加した進め方としました。

(3) 実際に試してみてどうか

プロジェクト規模が大きい場合や、要件分析などの上流工程で進め方によって生産性が大きく変わるプロジェクトは、決めた進め方の通りに試験的に作業を実施し、想定した進め方で問題ないか、作業見積は想定通りかといった点について検証するようにします。

上流工程、特に要件分析工程はインプットになる資料が標準化されていないため、プロジェクト毎に大きくばらつくことになります。

発注者が確認をする作業も多く、想定しきれていない要素が潜んでいる可能性が高いためです。

特に発注者と受注者のやり取りは、お互いに後工程の作業者の事を深く考えずに資料を作成することや、指摘を入れることが多々あります。

すると、後工程の作業者に意図が伝わらず、指摘と修正を何度も繰り返すという事態が発生し、品質が上がらないどころか、想定した作業期間で終わらなくなる事態を起ここしていまいます。

これは実際にやってみて気づく点も多いことから、上流工程の作業の時はできる限り試行しておいた方が良いです。

事例プロジェクトでは「モデルヒアリング」という形で図4の「①成果物作成」から「のヒアリング（プレ）」までを実際に行いました。

試行した部分について多くの問題点がみつかり効果がありましたが、実際にプロジェクトを始めたときに、試行しなかった以降の進め方について役割分担と確認観点の作りこみが甘く、成果物の指摘と修正が何度も発生することや、完成まで進んだはずの成果物に後から確認が必要になってしまうということが起こりました。

振り返ってみて、試行する場合は、可能な限り本番と同じ環境で試行するべきだと考えています。

なお、実際に試してみるというのは、試行作業という作業が発生しているため、調達仕様の際にプロジェクト計画でこのような事を行う旨をしっかりと明記しておくことが必要です。

札幌市の業務仕様書でも、こういった試行作業を行う旨を記載するようにしています。

(4) 資料化され関係者が共有できるようになっているか

　(1)～(3)まで確認し、よく練られた進め方を定めても、関係者が共有できていなかったり、それぞれの認識が違っていたりしていては意味がありません。

そこで、練った進め方は具体的な資料に落として共有できるようにします。

資料化すると、関係者それぞれが認識していたことがズレていることが分かったり、他の進め方との整合性がとれていなかったりしていることに気づくことがあります。

また、関係者の認識は時間の経過とともに変化してしまうということが起こりますが、資料化しておくことによりこれを防ぐことができます。

すべての進め方について、膨大な資料を作る必要はありませんが、プロジェクトの作業のなかで作業量の多いものや、作業に関わる関係者が多い部分について重点的に資料化しておくようにします。

資料化した進め方は、プロジェクト計画書の付属資料として位置づけプロジェクトの成果物としておくと、プロジェクト終了後の評価や、後工程のプロジェクトの参考にすることも可能となりますのでオススメです。