進捗はステータスを管理してはいけない。という話

今朝は白いものやら小雨がチラチラする中を田村ゆかりの新譜をローテしながら通勤しております。そこまで寒いって感じではないんですけどね。

さて、はてブを見ていたら人気のあるエントリがあって、さっと読んで見ました。

toshiyax.hatenablog.com

そーか、そうなんだねーと思いながら読み終わりました。人それぞれですからね。あれこれ書いても関心を持っていることだけを受けれますし。

読み終わった後の感想としては、毎年4月になれば未経験のエンジニアが希望を胸に抱いて（るかどうか…）この界隈に飛び込んでくるので、それってつまり、プロジェクトマネジメントの基礎とかシステム開発の基礎とかを学ぶ一定の層が供給されるということです。

言い換えると一定の量の人材が年次で更新されるということです。それは自分が1つ歳をとって年次を繰り上げていくということです。いやーあっという間だったなー。

何を作るか成果物を定義しましょう

何を作るかがはっきりしていない状態で作業をはじめると、結果的に後からあれもやらないといけないとかこれもやらないといけないとかモグラ叩きのように作業があたかも増殖してきたように感じてしまうことになります。

何を作るのか、具体的に「コレ」と指せる成果物の完成形を決めましょう。

もし、ぼんやりとしたアイデアしかない状態で作ってから細部を詰めていこうと思っているならそのぼんやりとしたアイデアのアイデアレベルを作ることまでを成果物として定義しましょう。つまり決まっていることだけを作りましょう、ということです。この場合は、それ以外は決まっていないのでこの作業が終わった後ですよ、と明示的にしておくと作業を一旦は区切れるのでオススメです。

進捗の前に作業を計画しましょう

明確な成果物かぼんやりとしたアイデアの成果物を作るための作業を分解しましょう。

この作業計画を作るためには、成果物の作り方を知らなければ作業は分解できません。作り方を知っている場合は、成果物が完成できる作業が揃っているかを確認しておきましょう。

もし、技術的に未経験のことがあったり、初めて作るぼんやりしたアイデアを作る場合は、こうやればできるという作業の段取りを検証するフェーズを持ちましょう。ソフトウェア開発はエンジニアリングの側面を持つので、誰が同じ作業をしても、同じように成果物を得られる必要があります。このステップをすることで作業に必要な作業が何かを知ることができます。もちろん、どんな作業をしたかを記録しておきましょう。

作業の完了を明確にしましょう

作業を分解して作業計画を立ててもダメなパターンがあります。それは作業で何をしたら終わりとして良いかの基準がないケースです。

作業毎に完了基準がない計画は意味がありません。

作業の工数を見積もりましょう

成果物を作る段取りが明らかで過去にやった実績がある場合は過去の実績の工数を（あくまでも）参考にこのくらいかかるだろうという作業を見積もりましょう。

もし過去に実績がないとか記録がない場合は、計画している作業の中で一番多い似た一連の作業を抜き出して、一番最初にどのくらいかかるかを計測してみましょう。計測した作業実績をベースラインとして他の作業を類推で見積もってみましょう。

ぼんやりしたアイデアの作業の工数の見積もりは、ぼんやりしすぎているので見積もりすることは現実的ではないしあまり意味がありません。試行錯誤が入りすぎるので。ですからタイムスパンを切ってこの作業ステップまでできるかどうか、とマイルストーンと作業の紐付けだけにしておきましょう。もちろん、作業実績の記録は取っておきましょう。