プロジェクト進行を円滑に進めるためのスケジュール作成について

はじめに

私は、受託開発がメインのIT企業でプロジェクトマネージャーやっています。
開発手法はガチガチのウォータフォールからスクラムを取り入れたアジャイル開発まで多岐に渡りますが、今回はスケジュールを作成するにあたり、個人的に気をつけていることを書いていこうと思います。
(スケジュールは作成するよりも管理することの方が重要ですが、そこはおいおい気が向いたら書こうかなと思います。)

スケジュールを立てるのが苦手なんて人の参考になれば良いなと思っています。

いきなり細かく書かない

プロジェクトの進行においてスケジュールは非常に重要な要素になります。
もちろん最初から完璧なスケジュールを作成することは難しく、プロジェクトが進むにつれて遅延が発生したり、想定外の問題が発生することがあります。

完璧なスケジュールやWBSを作成しようとするあまりに最初からフォーマットを細かくしたり上から順に細かく描きたくなってしまいますが、いきなり全てを網羅しようとするとかなりシンドイですし、精度もよくありません。また、バチバチの細かいものをいきなりクライアントに提出するとビックリされることがあります。
(WBSのような細かいスケジュールに慣れていない人はアレルギーを起こす可能性があります)
大きい粒度から順番に合意を取りながら進めていく事をオススメします。

自分の場合、まずは大枠を見やすい形で作成して徐々に詳細化していくことを心がけています。大まかに分けて下記の3つになります。

・粒度[大] : ロードマップ
・粒度[中] : マイルストーン
・粒度[小] : タスク

ロードマップ

ロードマップはスケジュール全体に対してやることのフェーズをザックリ書きます。
大まかに分けて、企画・要件定義・デザイン・設計・開発・検証・リリースくらいの粒度で1週間 ~ 1ヶ月くらいの期間で埋めていきます。

複数の関係者にまたがるタスクがある場合は縦軸で担当を分けて記載します。この時点でクリティカルパスを明確にしておいて、アウトプットのデッドラインを関係者同士で認識を揃えておくのが良いでしょう。

マイルストーン

マイルストーンは↑のロードマップで書き出したフェーズに対してのやる事をもう一段階細かい粒度記載していきます。
(例えば要件定義なら、追加機能の検討・検証・決定など)

ここで気をつけている事としては、各要素に対しての完了条件(アウトプット)を明確にする事です。
経験上、完了条件が定められていない・曖昧な状態だとなし崩し的にズルズル行ってしまい、要件定義と開発が平行状態になったりカオスな状態になりやすいです。

要件定義なら要件定義書の作成・設計なら仕様書の作成など各フェーズの完了時に作成されるドキュメントなどのアウトプットを完了条件とするのが良いと思います。

自分の場合、このマイルストーンの備考欄に実績を記載していっています。
会議の議事録や検討・決定内容のリンクなど時系列で記載していて、進行状況が一目でわかる状態にしています。
そうする事で、他の人が見たときに状況わかりやすいのと、あとで見返したときに当初のスケジュールとの乖離や作業ボリュームがわかるので次のスケジュル作成時の参考になります。

注意点として、実績は細かく書きすぎない事と主観的な記載はしない事になります。
表で管理すると縦に伸びていきますので、細かく書きすぎると見辛くなるのと、スケジュールとの線引きが難しくなるので管理が大変になります。議事録やドキュメントのリンク・一言メモくらいで留めておきます。
仕掛り中の場合はTODOなどアクションリストを入れておくと、次にやる事がわかりやすくなるので良いです。
また、ドキュメント全般に言えますが、主観的な内容は記載せずに両社間で合意の取れている決定事項のみを記載します。(現場が混乱します)

タスク

ここは各マイルストーンでのやる事に対してさらに細かい粒度で記載していきます。
ここの管理方法はプロジェクトそれぞれかと思いますが、自分の場合はJIRAやバックログのチケットで管理したり、エクセル・スプレッドシートで管理したりします。
マイルストーンの段階で割と細かい粒度になっているのでタスクを書き出しやすい状態ではあると思います。

JIRAで管理する場合はエピック : ロードマップ、ストーリー : マイルストーン、タスク : タスク(またはサブタスク)みたいな構成だと管理しやすいかもしれません。

スケジュールはアクセスしやすい場所に置く

スケジュールは一種のコミュニケーションツールでもあるので、見やすい場所に置くのが良いです。
Confluenceやスプレッドシートなどクラウドで管理されているのが望ましいです。ファイルで管理する場合、他の人が古いものを参照し続けて認識齟齬が起きるなんてこともあるので、スケジュールを修正したらその周知と管理を徹底する必要があります。

ここを見ればプロジェクトの状況が一目でわかる！という状態にしておけば自然とそこに人が集まるので、共通認識が形成しやすくなります。(もちろん大きいリスケなどが発生した場合はちゃんと周知しましょう)

見やすさも重要

細かいスケジュール(方眼エクセルのバチバチのWBSとか)は人によってアレルギーを引き起こしたり、小さすぎて読めなーい！(なんとかルーペ)となるので、見た目の良さや見やすさも重要です。
絵を使ってグラフィカルにしたり、適度に色をつけたりフォントのサイズを大きくしたり、文字数を減らしたり工夫しましょう。

自分の場合はConfluenceで管理しているので、↑のロードマップはdraw.ioで作成してます。もちろん管理が大変なので細かく書かないです。
(draw.ioオススメなのでどっかで記事書きたいなぁ。)

おわりに

ザックリしすぎて参考になるか不安ですが、自分のプロジェクト進行におけるスケジュールの作製方法をご紹介しました。
やはりスケジュールはコミュニケーションツール的な側面があるので、プロジェクトの性質やお客さん、メンバーなどが変わるとそれに合わせたものが必要になりますので、これでやればOK！というものはありませんし、スケジュールは進行状況を逐一監視してメンテナンスしていくことの方が重要になります。
スケジュール立てて終わり！ではなくて、メンテナンスや他のことに振れる体力を残しておくためにも簡素・完結かつメンテナンスしやすい仕組みを考えると良いと思います。
また、うまくいった事行かなかった事を振り返りながら自分なりのやり方を作っていくのが良いのではないかと思います。

以上！