6
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

進捗管理とは具体的に何をやればいいのか

Last updated at Posted at 2019-02-09

はじめに

進捗管理のないプロジェクト

私の担当ではないのですが同じチーム内で取り組んでいる小規模なプロジェクトで、定例進捗会はなし、ざっくりした線引きのWBSはあるものの、あまり更新はされておらず、ふわっと進めていれば何となくうまく行くだろう的なスタンスで進んでいる隣のプロジェクトがありました。

第三者的な立場でときどき話を聞いていたのですが、稼働まで残り1か月程度になったときにこのままではうまくいかなさそうな気がしたのでちょっとだけ進捗管理することにしました。

私がうまくいかなさそうと思ったポイントは下記のとおりです。

  • 担当者が目の前のタスクしか見ていない
  • タスクの締め切りが明らかになっていない
  • 稼働までのスケジュールとタスクが詳細化されていない
  • 余裕をもった線引きがしてあるのでそこで吸収できるといつまでも思っている
  • そろそろやばいなーと言いつつ、具体的なアクションプランができていない

そこで私なりに進捗管理とは何をやればいいのかというのを改めて考え直したので、それをまとめた内容になります。主に短期プロジェクトや稼働直前の話になるかもしれません。

進捗管理で具体的にやること

※多少進捗管理の範疇からはみ出す部分があるかもしれません。

1.ゴールから逆算して必要なタスクを洗い出す

ざっくりとしたマイルストーンと工程の期間だけが決まっているスケジュールしかない場合、メンバーと一緒に具体的なタスクに落としていく作業が必要です。いわゆるWBSの詳細化というやつです。

具体的なタスクに落とすときにまず考えるのは、明日稼働できるのか?ということです。
「明日稼働できるのか?」→「NO」→「では何ができていれば明日稼働できるのか?」→「〇〇ができていること」→「では〇〇ができるためには何ができていること/どういう状態になっていることが必要か。」
をひたすら繰り返して考えます。

このとき、場合によってはまだいろいろ決まっていなくて内容が詳細化できないものがあると思います。
その場合、〇〇の内容を詳細化する、というタスクを1つ設定し「〇〇の内容を詳細化するためには何ができていることが必要か。」を考えます。

この作業を明日着手するタスクが出てくるまで繰り返します。

2.タスクの見積とデッドラインを決定する

必要なタスクの洗い出しが終わったら、タスクの前後関係の整理と、どのタスクがいつまでに終わっていれば稼働に間に合うのかということを稼働日から逆算して決めていきます。いわゆるクリティカルパスを確認する作業です。

このとき、締め切りは〇月〇日というレベルまで決められることが望ましいです。〇月〇週目としてしまうと、その週に進捗を確認したときに遅れているのか遅れていないのかわからなくなってしまいます。1日は貴重です。

タスクにかかる期間を見積もるうえで注意しなければならないのは、営業日で見積もるということです。カレンダーで見ると一見余裕があるように見えても、土日祝日をはずすと意外と日数が少ないということがよくあります。

3.いつやるの?を追及する

タスクとデッドラインが決まったら、いつやるの?をひたすら追求します。
少なくとも、向こう1週間(次の進捗確認日まで)にやらなければならないタスクは日単位の粒度で決定できることが望ましいです。

顧客の回答待ちなど、誰かから依頼の結果を受け取らないといけないものについては、いつもらえるの?をひたすら追求します。いつもらえるかわからないということがありますが、デッドラインが決まっていればおのずといつまでにもらえていないといけないか、はわかるはずなのでそれを元に期限を切ってもらいます。

4.予定通りできたのかを確認する

いつやるかまで決まっていれば後は定期的にタスクが予定通り実行できたかを確認するだけです。

5.予定通り実行できなかったタスクのリカバリプランを考える

予定通り実行できなかったタスクがあった場合、その結果を踏まえてリカバリするためのタスクを設定してもらいます。

この辺がどうやればいいか非常に難しいですが、これに関して汎用的なやり方はおそらくありません。
このときとりあえず最低限考えておいたほうがよいのは

  • 何故予定通りできなかったのか
  • 予定通りできなかった原因・理由は継続して存在するか
  • 継続して存在する場合、どうやってその原因を排除/回避するか
  • 本稼働を遅延させる必要があるか
  • 何か(顧客の要望、機能、品質など)をあきらめる必要があるか

あたりかと思います。

余裕があれば

  • 過去に戻ってもう一度やり直せるとしたらどうすればこの問題を回避できたか
  • 過去に戻ってやり直しても回避できない問題であれば、どういう備えをしておけばダメージを最小限に食い止められたか
  • どういう備えをしておけば素早くリカバリできたか

を考えておくと今後の役に立つと思います。

おわりに

文章として起こしてみると結構教科書的な内容になってしまいました。

そして記憶を掘り起こしてみるとSIer時代に先輩からだいたい同じようなことを教わった気がします。当時はそんなこと言われてもできないですよ・・・といった感想でしたが。

いくらか経験を積むと知識を実体験として消化できるということなのかもしれません。

6
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?