読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

今やれることをやる、後で困らないことは後でやる

SIer

見積もり工数は、あくまでも個人的にざっくりベース(SI用語)で出した数字なので、ズレがあるわけで。事前にタスクを割り振る場合は見積もり時間を基準にする必要があると思うけど、見積もりのズレや個々人の状態によってかなりブレるのが普通で、途中でタスクの振り直しが発生する。絶対に。ということで、全体を事前に決めず、「今からどれをやろうか」を決めながら進めるようにした。

http://d.hatena.ne.jp/katzchang/20090924/p1

SIで不毛なのは完全なスケジュールの作成だと思います。不確定な要件から引いたスケジュールで「計画と実績の乖離」とか言われてもなぁ、というのは同感。

いま私が持ってるチームも同じような進め方をしていますが、インフラまわり*1を担当していることが大きな違いです。基本的にアプリ開発チームからの要望や苦情で50%以上の工数を使い切ってしまうので、「今やれることをやる、後で困らないことは後で」を方針に進めています。幸いにして、インフラについては計画と実績うんぬんを言われないのでやりやすいです。

用意するもの

少人数のチームを管理する時の三種の神器は下記です。私の場合。

目的 今回用意した手段
いつまでに何をやるか Microsoft Project
何を決める必要があるか Excelの課題表
とりあえず目の前にあること メールでタスクリストを流す

Projectは上手く使えば工数管理までできると思いますが、如何せん手間がかかるのでタスクのブレイクダウンとマイルストン管理にしか使ってません。稲妻線がガタガタになるので、スケジュール管理にうるさいプロジェクトでは難しいと思います。

Excelの課題表ですが、RedminetracのようなチケットベースのWebアプリを使えばよかったですね。Excelでも共有モードを使っているので機能的不足はないですが、課題を入力する心理的障壁はWebアプリの方が低いと思います。普段からネットを使ってる人はですけど。まあExcelだと解決済み課題がどんどんグレーアウトされてくので気分が良い。

最後のタスクリストですが、これはメールが最良ですね。チーム内で気軽にポストできる雰囲気を作ることも大事かなと思います。とりあえず目の前にあるタスクを吐き出すこと。これ重要。

続けること

ここに述べた三種の神器は、必ず定期的に棚卸しを行ってください。少なくとも週に1回は対面での打合せを行うべきです。打合せの時は資料をディスプレイに表示し、リアルタイムに修正しながら進めていきます。間違っていればツッコミが入るし、全員が理解できます。

唯一の欠点は進捗報告が難しくなることですね。完全かつ詳細な当初計画がないので、計画と実績の乖離について説明を求められたらハッタリで答えるか、そうでなければ非生産的な資料作りが必要になります。

ちなみに過去形で書いていますが、今のプロジェクトはまだまだ続きます。。。絶賛炎上中!えんじょい!

*1:表現が難しいが、アプリより下のレイヤを受け持つ。TomcatやらOracleからL2スイッチまで色々。