スケジュール構築、どうやってる？ PMがよく聞かれる「基本の観点」をチェックリスト化してみた
データ事業本部の多久です。
クラスメソッドへはプロジェクトマネージャーとしてジョインしましたが、周りのメンバーからスケジュール構築方法や構築の際の観点、気にした方が良い箇所などを聞かれることが多いため、
今回改めて言語化してみました。
前半はチェックリスト的に利用できるように箇条書きにし、後半では解説として、それぞれの項目（箇条書きの記載）で何をすれば良いか、
気にする点は何か、という解説をしています。
なお、PJ規模を問わずに考慮すべき点をピックアップしていますので、これで全部OKとはせず、どんなに忙しくても最低限これだけは押さえておくべき、という観点で利用してもらうのが良いと思います。
計画・準備
WBSの作成
- タスクはもれなく洗い出されているか
- 各タスクのアウトプットは明確になっているか
- WBSは適切に分割されているか？
- 非機能要件（性能・セキュリティ）に関するタスクは洗い出されているか？
- 開発プロセスや承認プロセスなどが考慮されているか？
順序性・依存関係
- 順序性・依存関係は４パターンあり、それぞれ考慮されているか？
所要時間見積もりについて
作業時間の見積もり
- 見積もり方法には過去実績、類似プロジェクトなど一定のロジックをもった数値となっているか？
- 「100mを11秒で走れるなら、フルマラソンを1時間17分で走れる」というような無理な数値になっていないか？（会議や割り込みなど非作業時間を考慮されているか？）
- スケジュールバッファを設けている場合は、全体にかけるか、タスクにかけるか、のどちらかで統一されているか？
スケジュール管理と重点確認項目について
クリティカルパスの特定
- クリティカルパスは特定されているか？
- クリティカルパス上のリスクは洗い出されているか？
マイルストーンについて
- マイルストーンが設定されているか
運用ルールについて
進捗率について
- 進捗率についてチーム内で合意が取れているか？
- 完了の定義は全員一緒か？
仕様変更の管理プロセスについて
- 仕様変更の管理プロセスが定められ、チーム内で合意されているか？
課題管理について
- スケジュール構築の際に発見することができた課題について、もれなく管理されているか
詳細と解説
計画・準備について
WBSの作成の解説
WBS作成については、それだけで一つの本を書けるぐらいの分量になりがちなので、チェックポイントやチェックすべき点を記載していきます。
タスクはもれなく洗い出されているか
理想はPJ開始前に全て洗い出せているのが理想ですが、現実的にはそのようなPJはほぼ存在しないので、わかる範囲で良いので洗い出しましょう。WBSを洗い出すことで見えてくる課題や問題などがあり、それがPJの進捗を脅かすことがままあります。それがわかるだけでも価値があります。
なお、いくら不確実性が高いPJだとしても、直近２週間〜４週間でやるべきタスクを全て洗い出せない場合は、結構マズい状況です。
この場合は、WBSを洗い出す活動を全力で行いましょう。
各タスクのアウトプットは明確になっているか
後述する終了条件と一部重複しますが、WBSの各タスクのアウトプットは全て明確にしましょう。
設計であれば設計書ですし、調査であれば調査報告書になると思います。
アウトプットが明確でない場合は、各タスクの終了条件が不明確になりますし、具体的な活動を起こすことができない可能性が高いです。
WBSは適切に分割されているか？
WBSは階層構造で作成していきますが、同階層にあるタスクは同じぐらいの粒度にした方が色々と管理しやすく、また他人から理解しやすくもなります。
また、WBSのタスクをどこまで細かく砕くかについては、管理手法やPJの規模などで異なりますが、理想としては誰が作業しても同じように理解できるレベルまで砕けているのが理想です。
が、そのレベルまで砕くと場合によっては数時間レベルの作業が並ぶことになりますので、そこまで管理対象にするかはPJのコンテキストに依存します。 私個人の見解としては、週単位ぐらいの粒度まで砕くのは必須としますが、それ以上まで砕く場合はPJの規模や、タスクの依存度などが複雑であるなど高リスクな場合のみにしています。
非機能要件（性能・セキュリティ）に関するタスクは洗い出されているか？
PJによっては忘れがちになりますが、非機能要件に関するタスクも洗い出しましょう。
非機能要件はPJ前半から検討すべき内容が多く、未計画のままPJに着手してしまうと気がついた時には手遅れとなっていることが多いです。
開発プロセスや承認プロセスなどが考慮されているか？
仕様面の検討を行って成果物を作成しても、お客様の承認をいただくまでに時間がかかるとか、社内の有識者レビューを実施する必要があるが、有識者が多忙で週に１回のレビューミーティングを待たねばならないなどあれば、併せてWBSの項目として起こしておいた方が良いです。
PJのキーマンは（あくまで結果的に）ボトルネックとなってしまうことが多いので、それに対する対応を考慮するためWBSの項目として起こします。
順序性・依存関係の解説
順序性・依存関係は４パターンあり、それぞれ考慮されているか？
大体のタスクには依存関係があります。そして、その依存関係を洗い出すことを怠ると、スケジュール上着手が必要なのに、前提条件が整っていないので着手できない‥‥‥ことに、着手当日気がつく、というような悲劇が起こります。
ちなみに、辞書的には順序性や依存関係は４パターンありますが、進捗に直結するのは「終了→開始」と「開始→開始」ぐらいなのでせめてこの二つだけは把握するようにしましょう。
順序性・依存関係の種類
- 終了→開始
- Aが終わらないとBを開始できないもの、わかりやすく順序性の基本。プログラムの作成が終わっていないとテストの実施ができないとか、DBのテーブル構造の検討のためには、お客様から現行データをもらわないと無理とかそういうのを指します。
- 開始→開始
- Aが開始できればBも開始できるもの、例えばテストケースの作成とテストの実施などが該当します。（テストケースの作成がある程度進めば、テストの実施は可能）。
- このパターンはリソースの並行利用が可能なので、スケジュール短縮に繋げられる部分。
- とはいえ並行しすぎると管理が煩雑になり、不確実性にも弱くなる（横槍一本でスケジュールが瓦解する）ためやりすぎには注意が必要です。
- 終了→終了
- Aが終わらないとBも終われない。納品物の作成が終わらないと納品も終わらないとか、テストが終わらないとテスト結果報告書も完了しない、というようなもの。
- 開始→終了
- タスクAが開始しないとタスクBを終了できないようなもの。実務的にはほとんど発生しないので、あまり気にする必要はない。
- 古いサーバーBは新しいサーバーAが開始しないと終了（シャットダウン）できないなど、一部の例のみ。
- 正直概念としては理解するものの、私も実際にあったことがない感じ。。。
所要時間見積もりについて
作業時間の見積もりについての解説
見積もり方法には過去実績、類似プロジェクトなど一定のロジックをもった数値となっているか？
率直に言って、人類漏れなく見積もりが得意ではなく、システム開発における見積もりなんてものはもう50年ぐらい確度をあげようと頑張っているものの、
正直あまり成果がでていない分野ではあるのですが、見積もる際には一定のロジックを積むようにしましょう。
正確性をちょっとでもあげたいという観点もありますが、あまりにも個人の 「カンと経験と度胸（KKD）」 だけで見積もり数値を出されると、客観的なディスカッションができなくなります。
で、そうなると、他の人と会話することで気がつけた問題にも気がつけなくなる可能性が上がっていってしまうので、少なくとも過去実績からの類推とか、作業を少しやってみた結果の積み上げとか、なんらかのロジックを積んだ形で見積もる方が良いです。
もちろん「100mを11秒で走れるなら、フルマラソンを1時間17分で走れる」というような無理な数値になっているのはもってのほかで。
スケジュールバッファを設けている場合は、全体にかけるか、タスクにかけるか、のどちらかで統一されているか？
まず、スケジュールにバッファは必要です。バッファを例えるなら車の車間距離みたいなもんで、順調な時は車間距離が2cmでも走れるかもしれませんが、僅かでも何かあったら事故になります。
で、バッファをスケジュールに組み込む必要があるのですが、よくやりがちなのは各個別のタスクに10%のバッファを入れて、その後全体スケジュールにも10%積んじゃうパターンです。
この場合、バッファが雪だるま方式に増えていくので、後で見返した時になんか工数が過大に見積もられているような‥‥？ となりがちになります。
個人的なおすすめは、基本的にタスクレベルではバッファを設けずに、スケジュールバッファのみ設ける。
リスクの高いスケジュールのみ、タスクレベルにバッファを入れる、と、不確実性と全体スケジュールの長さとして適切になることが多いです。
スケジュール管理と重点確認項目について
クリティカルパスの特定に関する解説
クリティカルパスは特定されているか？
作業項目、依存関係、所要時間まで確認、計画できたらクリティカルパスの特定もしておきましょう。
クリティカルパスとは、PJの最短完了期間を決める最も長い所要時間の一連の作業（経路）です。
クリティカルパスが遅延する＝PJの終了が遅延する、となるので、最も注視する必要がある部分になります。
逆にクリティカルパスでなければ、（あくまで相対的に）すこーーし手を抜くことが可能（リソース配分の優先度を調整する余地が生まれる）です。
適切に緩急をつけて管理するためにもクリティカルパスは見つけておきましょう。
クリティカルパス上のリスクは洗い出されているか？
上記の通りクリティカルパスの遅延＝PJ完了日の遅延となるため、クリティカルパス上のリスクは入念に洗い出した方が良いです。
洗い出し方法としては、クリティカルパス上の各種タスクの依存関係ベースに見ておくと、出しやすいです。
特に、「終了→開始」関係にあるもののリスクにより着手遅延になりがちなので、重点的に。
マイルストーンについて
マイルストーンが設定されているか
マイルストーンは進捗上重要なイベントを定義します。
教科書的な意味だと設計完了期日などが例に挙げられることが多いですが、実際には外部要因と関連する重要なイベントを記載することが多いです。
例としては、顧客からもらう仕様書の提示期限であったり（この日までに貰えないと着手できないので遅延します）、変更受け入れ期限（この日以降の変更はリリース日が遅延します）を提示したりすることが多いです。
マイルストーンとして何があるかを洗い出すのは、前述のタスクの順序性に現れることが多いです。
先ほどの例でいうと、顧客に仕様書をもらわないと、設計に着手できないので、この日までに仕様書をもらう必要がある（から、マイルストーンはここ）、という感じで定まります。
マイルストーンとして管理することで、スケジュールの線表とは別にイベントとして目立たせることができるので、顧客との合意事項（お互いに約束を守る）という意味でも適切に設定しましょう。
運用ルールについて
進捗率について
進捗率についてチーム内で合意が取れているか？
進捗率については色々考え方がありますが、このチームの進捗率はこれという形で統一しておく必要があります。
やり方の例としては
「進捗率 ＝ タスクの消化量 / タスクの総数」
のように正確性を求めるパターンや
進捗率 ＝ 100%：完了
75%：テスト完了、バグフィックス、再テスト未
50%：実装完了、テスト未
25%：実装内容把握、分析完了、実装未
のように、進捗率のルールを決めて対応するパターンがあります。
正直どちらも一長一短なのでどちらを選んでも管理上は問題ないと思いますが、チーム内では意識を統一しておかないと事故りやすいです。
また、似たような観点として完了の定義についても、合意し意識統一しておいた方が良いです。
あなたが「テスト完了＝テスト実施、バグフィックス、再テストまで全て完了」と思っていても、他の人は「テスト完了＝１回テストを実施して、バグを出し切った（直すのこれから）」と認識している、なんてことは往々にあります。
仕様変更の管理プロセスについて
仕様変更の管理プロセスが定められ、チーム内で合意されているか？
小規模PJなどで一つの部署で１チームでやっているような場合は特段決める必要がありませんが、PJ規模が大きくなってきて、複数部署を跨いだチームが作成されたり、
役割が異なるチームを束ねてPJを運営する時は、いわゆる仕様変更の管理プロセスを定めておいた方が良いです。
フロントエンドだけで見ると簡単な変更が、実はバックエンドに甚大な影響を与えるが、顧客とスケジュール管理をしているのがフロントエンドチームなので、
スケジュール遅延せずに変更を取り込めますとお客様に言ってしまった、というような悲劇を防ぐのが目的です。
コミュニケーションの問題と片付けるのは簡単ですが、変更管理にどうコミュニケーションをとるのか悩むぐらいならルールにしてしまった方が良いので、チームがある程度の規模になった場合はルールを作成し、文章化した方が、結果的にスムーズです。
課題管理について
スケジュール構築の際に発見することができた課題について、もれなく管理されているか
「計画することがすべてだ。立てた計画はどうでもいい。」
ー陸軍元帥ヘルムート・グラフ・フォン・モルトケ
上記は「アジャイルな見積もりと計画づくり」でも引用されているモトルケの言葉ですが、
結局のところ、立てたスケジュールにはあまり意味がなく、立てる過程で得た学びが重要であることを説いた発言です。
PJ運営におけるスケジュール構築を行う場合、計画過程で色々な発見があるはずなので、そちらは適切に管理しましょう。
ガントチャートを引いている過程で、今まで見えていなかった着手条件を見つけた場合は、課題になりますし
他のチームの進捗の影響を受ける線を見つけた場合は、それがリスクになります。
それらもスケジュール構築で得られた成果物の一つであるので、そちらは適切に管理し対応していきましょう。
おまけ
私が所属するデータ分析基盤構築チームでは、現在採用強化活動を実施しています。
データエンジニアに興味がある方がいましたら是非カジュアル面談等に応募いただければと思います！
