カスタマーコンサルティングチームの吉村 晃史です。
今回のお話では、システム全体のスケジューリングに関してお話できればと思います。これまでの経験上、私の中で一番フィットすると考えている方法のお話になりますが、あくまで、個人的な知見と経験に基づくものとしてお読みいただければと考えております。
スケジュール作成のプロセス
いわゆるプロジェクト（一定期間で何らかの成果を作成していくという意味）では、スケジュールを作成し進行していくというのは、粒度の差はあれど規模の大小を問わず必須の事項となります。特に、大人数が関わるプロジェクトにおいては、スケジュールの立案およびスケジュールに沿った進行が、プロジェクトの状況を把握するために必須となるのは周知の事実です。
実際に、スケジュールを作成すると言った場合には、以下のようなプロセスを踏むことが多いのではないでしょうか。
- リリース目標を作成
- リリース日から逆算で、簡易的な作業期間を作成（矢羽的なスケジュール）
- 各工程の詳細スケジュールの作成
上記のようなプロセスで大枠のスケジュールが作成されて、プロジェクト進行がなされていきます。
今回お話したいのは、この部分のお話ではありません。実際の実行スケジュールを考えていく場合の方法論に関して、お話していきます。
（実際には、関わっていますが、まずは、積み上げていく方法論になりますので、後工程のお話となります。）
スケジュール作成の問題点（リスクの蓄積）
スケジュールを作成する目的をまず考えてみます。スケジュールを作成することにより、プロジェクト全体の進捗を共通認識として持ち、その進行を明確化していくということが挙げられます。スケジュールに対して、遅延しているのかどうかといった点を確認します。
ここで重要なのは、実際の進捗を見える化しそれを明確に管理していくということが重要です。
その上で、実際にスケジュールを作成する工程を考えてみます。最終的なスケジュールに関しては、各ベンダや担当者の意見を集約しつつ、スケジューリングしていきます。その際に、リスクをどこで取るのかということが大きな問題になります。
自社内で担当者をすべてアサインしていると言った場合には、ある程度のコントロールは効きますが、ベンダを跨いだ開発などでは、各ベンダがリスクを積むこととなります。これは、契約などにもよりますが、ある程度許容されるべき事項となります。
その工数、スケジュールを受け取った側で、更にマスタのスケジュールを作成する際には、リスクを乗せる必要があります。
ここに、リスクにリスクを乗せるといったいびつな構造が出来上がります。
（ただ、コントロールできる範囲でリスクを乗せると考えると致し方ないことですが）
そのため、複数のタスクに分かれていたり、複数ベンダが係る場合には、リスクが過剰に積み上がる場合があり、また、実際の工数にリスクが乗っているスケジュールとなるため、プロジェクト全体の進行が見えづらくなるという問題があります。
リスク対応を各タスクのスケジュールに含むことの懸念点
- これは一般的に言えることですが、
- 時間が確保されている場合には、その時間を使ってしまう
- 実際には、バッファを使っている（遅れている）ことが表面化しない
といった問題点があります。
与えられた時間を、前倒してどんどん進めていくということは、今までの私の経験でもなかなか見られない状態だと思います。また、スケジュールが前倒しされても次のタスクの準備ができていないといった点で、全体のスケジュールが前倒しになるといったことはありません。
スケジュールをどう組むか
私の経験上からのおすすめは、CCPMという方法論をおすすめしたいと思います。
（基本的な概念として、カスタマイズしていただくのが良いと思います。また、詳細に関してはここでは述べませんので、詳細に関しては、別の機会とさせていただきます。）
- ベースの考え方としては、以下のようになります。
- スケジュールバッファを、各タスクに組み込まない
- バッファの作成は、プロジェクト全体で確保する。
（プロジェクト規模によって、確保するポイントを増やしてもいいかと思います。）
イメージ
上の図のように、各タスクにバッファを積むのではなく、全体としてのバッファを確保するようにします。
こうすることで、各タスクに紐付いているバッファという見えない工数をプロジェクト全体、つまりプロジェクトマネージャの管轄に引き寄せることが可能になります。
これによりもたらされる効果として、以下のようなものがあります。
- 各タスクの進捗及び遅れが明確化される
- バッファが無駄に消費されることがなく、リソースを最適化することが可能になる
- バッファの消費具合を見つつ、プロジェクトの状況が把握できる
進捗の実体が見えづらくなることが多い状況から、バッファ工数の消費を見ることでプロジェクトの状況を把握しやすくなるメリットがあります。
-
個人的な運用のポイントとしては、以下のポイントになるかと考えています。
- 作業遅延のリスクをプロジェクトとして受け持つ
→ 上記の図の通り、各作業にはリスク吸収のバッファを設けません。ここで作業担当者に遅延の責任がないことを明確化しないと、バッファを乗せないということが実現不可能になるためです。
遅延に対する取り組みをプロジェクト全体とすることで、全体としてのバッファを最適化することが可能になります。 - 作業が遅れた事自体は責めない
→ 上記のとおりです。担当者/ベンダに責任を求めてしまうと、やはりバッファを積まなければ作業できない！となってしまいます。 - 作業に対するリスク評価を実施し、遅延要因を把握する
→ プロジェクト全体でバッファを取る際に、どのようにとっていくのかの指針を決める必要があります。（一律2割といったバッファのとり方は破綻することが多いです。）
経験上、作業遅延の発生する可能性などを考慮してバッファをきめていくと、ある程度整合性の取れたバッファになる場合が多いと思います。
例）
発生すると、全体の進捗に5日程度の遅れが発生するリスクが有る。
現状だと、20%程度は発生する可能性がある。
→ 5×20% =1日のバッファを設ける。
といった形です。
これは、かなり詳細になっていますので、上記のようなプロセスを取りつつ、全体のバッファとして適切か？といった評価を実施するのが良いと考えます。上記までの、私の経験を元にお話をさせていただきましたが、運用及び、プロジェクト体制に基づいて、色々と最適化しながら実施する必要はあります。
小規模プロジェクトであれば、ここまでのプロセスは必要ありませんが、長期間/大規模なプロジェクトほど、適用していただければ効果を実感できると思います。
