スケジュール管理の基本３つの言葉 / Fundamental of Schedule Management “3 words”

2016/03/17 2016/07/20

トピック；スケジュール管理をレビューするための３つの言葉ポイント；クリティカル・パスを押さえて、クラッシングとファスト・トラッキングで調整するが”対価”は必要キーワード；クリティカル・パス、クラッシング、ファスト・トラッキング
Topic: 3 words to review schedule management. Points: Recognize “Critical path” then cope with issues by “Crashing” and “Fast tracking” However they require compensations. Keywords: Critical path, Crashing, and Fast tracking. (Technical terms for project management.)

スケジュール管理の立場

自分＝管理者はスケジュールのレビューアを想定しています。
スケジュール管理のツールはいくつかありますが、レビューする立場になれば、どの粒度で、どうやって見るかの違いだけで、本質は変わりません。細かいスケジュールだと、タスクの個別問題に捕われ、対局が見えないことが多いです。私の様な技術者上がりだと「検索のパフォーマンスが出ない」とか「データベースのキー設計がまずかった」等は大好物で思わず一緒に徹夜をしたくなりますが、IT中間管理職はプロジェクト・マネージャーと一緒に全体のかじ取り、判断をすべきです。

スケジュール管理の３つの言葉

そうなると、スケジュール管理で使う言葉は割り切ってしまうと３つです。

クリティカル・パス；Critical path
クラッシング；Crashing
ファスト・トラッキング；Fast Tracking

この３つの言葉を使って、レビュー、判断していくことになります。
もちろん、スケジュール管理ツールは経験を経て精通しているのは大前提ですけれど。

クリティカル・パスとは(Critical path)～説明と私の経験

有名なデュポン社が開発したCritical Path Method;CPMなどがあり、PMPで勉強しますが、ポイントは”プロジェクトの最短距離”です。プロジェクトは規模が大きくなればなるほど並行してタスクが走りますが、一番時間のかかるタスクをつないでいくと全体で最短ｘｘ日でタスクが終わる、という線を”クリティカル・パス”と言います。プロジェクト・マネージャーをよくやっていた頃は「クリティカル・パスはどれなんだ」と上司によく言われたものです。最近はアジャイルだったり、クラウドだったりであまりとやかく言う人が少なくなった気がします。しかしながら、どんな仕事でもクリティカル・パスを押さえているかどうかはとても重要なポイントだと私は信じています。ツールとしてはPERT;Program Evaluation and Review Techniqueを使った”PERT図”が有効だと思います。下記の例では赤い線がクリティカル・パスになります。

xlsx file

クラッシングとは(Crashing)～説明と私の経験

レビューアですから要は「スケジュールが遅れていますが、どうしましょうか」という報告に対する対策案を考えなければなりません。思ったよりも早く進んでいますというグッド・リスクが発生することはまずありません。もしそうなら、見積りプロセスに問題があると思います。（見積りの精度が悪すぎる）
クラッシングは、クリティカル・パスの中に”期間を短縮できるタスクがないか、あれば短縮する”という対応を言います。
具体的には

人員追加で圧縮できる
->例えば開発者を追加で投入するとか、２つの機能に分けて並行開発するなどです
後回しにできる工程を後回しにする
->例えばドキュメントの作成をドラフトに留め、後で作成するなどです
工程そのもののスコープを小さくする、無くす
->検索や頻度の少ない帳票などの開発を後回しにして業務クリティカルな機能だけ開発するなどです

となります。

xlsx file
この例では、設計が遅延したため機能を分割し並行開発することで期間を短縮しています。しかしながら”銀の弾”はありませんので、実際には必ず”つけ”を払わなくてはならない対策になります。だからこそ管理者に判断がが委ねられることが多く、実際の調整はその後の管理者レベルでのコストの調整やクライアント、ユーザとのネゴシエーションを行うことが前提での対策です。

ファスト・トラッキングとは(Fast Tracking)～説明と私の経験

プロジェクト計画はプロジェクト・マネージャーがメンバーと一緒に一生懸命考えます。その際、タスクには必ず前後関係があります。ウォーターフォール型のVモデルであれば設計->開発->テストと順番にタスクをこなし、レレビュー＆承認後に後続タスクが開始されます。しかしながらファスト・トラッキングはこれを”見切り発車”してしまうやり方です。つまり”設計が終わって無くても見えてる機能から開発を開始する”とか、”確定していて明確に切り離せるテストは先に始めてしまう”などの期間短縮方法です。（近年はアジャイル開発などが広まってきていますので、プロジェクトの考え方としてタスクのオーバーラップは”アリ”な対応になってきていますが）見切り発車するリスクがどれくらいなのか、はよく見極めが必要です。

xlsx file
この例では設計が長引いたため、開発を見切り発車しています。”機能Ｂは確定しているが、機能Ａの調整が続いている”という状況であれば、このような選択も可能でしょう。

まとめ

まずは”クリティカル・パス”でプロジェクトの最短距離、つまり”最悪でｘｘ日かかる”ということを把握できているかが最初の認識です。
大抵は遅れがありますので、クラッシング（タスクの期間短縮）かファスト・トラッキング（タスクの入れ替え）で調整をしますが、見積り精度がかなり悪くない限り”調整の対価”が必要な対応になります。
あなたがレビューアかつ管理者であるならば、マネジメント・パワーで調整できるかをよく考えて対処しましょう。

– 17th Mar, 2016 / the 1st edition