ソースをレビューして… (5)

ついでにスケジュール管理についてもちょっと(・∀・)


今回のうちのプロジェクトに関して言えば、顧客*1がちょっと特殊だったりして、実質的なスケジュール調整の余地がありません。
担当者が誰も納得していない政治的に決まったスケジュールに対して、後ろから線を引いてみたところでそんなのは絵に描いた餅に過ぎないわけですけど(´Д`)
で、そういう状況の中で形だけ間に合わせようとして、人を無理矢理かき集めて大変な事になっているわけですが(´・ω・`)


まあ、ここまでのケースではなくても後ろから線を引くみたいな事をする人達が居ますが、それは実質的にはスケジュール管理をしていないのと同じですね(´ω`)


実質的なスケジュールを押さえた上で、それとは別に客見せようのスケジュール*2を作るっていうやり方は否定しませんが…。
二重帳簿ならぬ二重スケジュールというわけで、ちょっと暗黒道入ってますけどね。


で、じゃあ、実質的なスケジュール管理ってのはなんなのかというのが今日のネタです(・∀・)


まあ、自分はちゃんとしたマネジメントを学んでいるわけではないですし、バーンダウンチャートとかの使い方とかもきちっと分かっているわけではないんですが(´ω`)


自分がやっているスケジュール管理は、基本は担当者の申告によるタスク一覧の積み重ねになります。
それをJoel's Scheduleというかやねうらおさんの進捗管理シートみたいなやつ使って管理します。


管理の目的は「本当に終わるのは何時か?」を把握するためのものです(`・ω・´)
タスク一覧の終了に必要なコストを積み上げ式で計算し、それを作業予定工数で割って終了日を割り出すという単純なやりかたです。


ぶっちゃけ、「プロジェクトが最初に決められた日時に終わらない」ことはたいした問題だと思いません(・∀・)
本当に問題なのは「プロジェクトがいつ終わるのかが分からない」ことだと思っています(´Д`;)


プロジェクトの本当の終了日を把握していれば、顧客のビジネス上優先度が高い機能だけを先にリリースするとかいう調整も出来るようになりますしね。


で、タスク管理の詳細ですが、タスクは2〜3日の作業量に分割した作業項目を使用します。
単位は時間でつけますが、作業予定工数は1人1日8hを基本にします。*3


これを10hにすれば早く終わるだろ、みたいな勘違い管理者がいるかもしれませんが、それをやっても意味はありません。
10hにしても生産性が下がるだけで、8hでも10hでもトータルの生産性は変わらない結果になるだけです(言い切り)。*4


なので、自分はこれを「8時間」ではなくて「8やる気ポイント」と言っていたりしますが(・∀・)
その日のやる気ポイントを使い切ったら、さっさと家に帰ってリフレッシュした方が生産性は高くなります。*5


…っというか、毎日22時近くに帰宅している人達って、本当にちゃんと働けてるんですかね?
だとしたらスゴイ体力と精神力だというか、自分にはちょっと真似できない部分がありますが…。
冗談でもなんでもなく、週40h労働が一番が知的生産性は高くなると思うんですけどね(´ω`)
残業なんて、単純作業レベルにまで落とせた項目をひたすらこなす時くらいしか意味は無いと思うんですが。


で、話を戻しますが、タスク管理で一番重要なのが日々のアップデートとトラッキング
タスク管理の最大の目的は「本当に終わるのは何時か?」の把握なので、タスクの増減やタスクの詳細がわかって予測工数が変動した場合には随時管理シートを更新します。


他にも細かいテクニックとかはあるんですが、とりあえずJoel本を読んだりやねうらおさんの進捗管理シートを見てみたりするといいんじゃないかと思います(・∀・)

Joel on Software

Joel on Software

*1:っというか、エンドユーザの前に居るエンドユーザと同系列のコンサル担当企業

*2:もちろん調整可能な範囲なもの

*3:つまり殆どのタスクは16h〜24h

*4:勘違い管理者にコレを見せる場合は10/8倍した値を見せるのもあり。場合によっては三重スケジュールになったりしますが…

*5:後、これは勤怠管理じゃないんで厳密に作業時間に合わせてもいません