見積もりスキル養成ギプスとしての Redmine
本記事は Redmine Advent Calendar 2020 の 6 日目です。チケットの時間トラッキングについて書きます。年末の夜長にでもお読みください。
時間トラッキング
私はこれまで ITS (Issue Tracking System) として企業内製、Track、GitHub Issues、Redmine などを利用してきた。これらのうち Redmine の時間トラッキング機能は他の ITS に対して強力な優位点だと考えている。時間トラッキングについては以下の記事が詳しい。
ここで紹介されている方法のうち、私は
- 予定工数
- チケット更新時における作業時間の記録
を利用している。
予定工数と作業時間の記録
Redmine のチケットには開始日と期日がある。これだけでも見積もりには十分なのかもしれない。しかし単位が日なので作業によっては粒度が粗すぎるし、期間内で実際にどれぐらい時間をかけたのかは記録されない。そこで予定工数と作業時間の記録の出番だ。これらは時間単位による工数の見積もりと実態の記録を実現してくれる。
予定工数について。
時間単位といっても難しく考える必要はない。「きっかり 2 時間で終わらせる」のような想定だと厳しいが
- よほど確実なもの以外は予測される最短想定から 2 倍ほどの時間を指定
- 入力時間をパターン化して負担を軽減、例えば以下のようにする
- 1 日 = 8 時間
- 半日 = 4 時間
- 半日以下 = 1 〜 3 時間
これぐらいで十分だ。
1 があまりにも雑と感じるかもしれない。しかし長らく業務としてソフトウェア開発を経験から、これでもトントンになるものだ。複数のチケット (課題) があるなら、どれかで想定外の事故は起きるもの。その対応バッファーは十分に積みたい。バッファーが大きすぎたら、品質向上とか他の難題にあてるなどして調整してゆく。まずは時間単位で予定を立てることを習慣づけることが重要である。これを繰り返すうちに適切なバッファーの相場観も養われてゆく。
次に作業時間の記録。
作業をチケットとして管理しているなら、節目に「作業時間」を記録する。作業途中であれ完了であれ「なにか一区切りついたら作業時間を更新する」と覚えておくのがよい。同時に作業分類や注記 (コメント) も書くと更によし。例えばこんな感じで。
| チケット入力欄 | 内容 |
|---|---|
| 作業時間 | 0.5 |
| 作業分類 | 運用 |
| 注記 | 事前予告したとおり検証用サーバーのミドルウェア更新を適用して OS を再起動した。dnf update したら更新が 100 を超えてて意外に時間がかかった。再起動後に https://test.example.com/ が正常に表示されることを確認済み。 |
作業時間は予定工数と異なり実際にかかったものを記録する。そのため 1 時間以下もありえるが、その場合は 30 分 = 0.5 としておく。10 分で終わっても 30 分。これぐらいはバッファーの範囲である。無理して「〜時間ごとに記録」とかしなくても OK。人によって作業のリズムは異なるから、自分的に一区切りかなというタイミングで記録するのが負担も軽く続けやすい。予定工数と同じく習慣づけるのがなにより大事。
もうひとつ意識したいのは予定工数を超えても記録を継続すること。予定より時間がかかると「失敗」や「責任」みたいな言葉がちらついて記録をやめたくなる。しかし「記録されなかった失敗」は失敗として勘定されない。それは改善の機会を失うのと同義だ。
「責任」について過度に重く考えるのはやめよう。工数の超過で個人の責任を問われるようなら組織や仕組みが間違っている。未知の作業なら
- 見積もり精度を上げるために調査期間を用意する
- その余裕がなければ熟練者に担当させる
- それでもダメなら、いっそ見送る
といった判断も必要だが、それは個人ではなく組織でおこなうべきものだろう。その際、過去に記録された予定工数と作業時間は有用な論拠にもなる。
見積もりスキル養成ギプス
予定工数の設定と作業時間の記録を続けてゆくとどうなるか。
作業時間を強く意識するようになり「予定工数を定義できない = 不確定」であることへの嗅覚が研ぎ澄まされる。実用的なスキルを身につけるには適切な反復練習を必要とするものだが、見積もりに関しては Redmine の時間トラッキングが有用だと実感している。反復が確かな見積もり筋 (スキル) を育む。まさに養成ギプスだ。
その証拠として外的要因の大きな事故でもない限り、ここ 10 年ほど関わったプロジェクト (いずれも Redmine で管理) で私が担当した部分はスケジュール遅延していない。最も大きい要因は不確定なものを早めに処理するようになったこと。「できるできない」の話をする際に「どれぐらいで、どれぐらいなら」があることのなんと心強いことか。予定工数を立てられるか？から始めるので不確定なものをそのまま放置することがなくなった。これがスケジュール管理を確実なものとするのに役立っている。
というわけで時間トラッキング、超オススメです。騙されたと思って 1 プロジェクトを記録しながらやりとげてみてください。確実な成長を約束します。
余談 (昔話)
作業時間というものを強く意識するようになったのは、新聞奨学生として過ごした日々が大きい。
2 年間、専門学校へ通いながら新聞奨学生をしていた。朝夕の配達と集金をこなせば家と二食つきで年 100 万の学費と毎月の生活費 (基本 ¥135,000 で食費を差し引き ¥105,000 だった) が支給される。しかし集金が曲者だ。配達は慣れれば定時で終われる。集金はそうはいかない。いつ読者が在宅しているかわからないし持ち合わせのないことだってある。家もあちこちに分散。不確実性の塊だ。
そのうえノルマが厳しい。月内 90%、翌月 5 日までに 95% を集金しないと手当がでないのだ。これを苦にして自腹で立て替える人もいた。なあに、そのうち回収できるさ。そう言いながら同じ読者を数ヶ月、立て替え続けて顔面蒼白というのもありふれた光景だった。
奨学生なら通学だけでなく予習・復習も必要だ。ノルマ達成しつつ、そのための時間も捻出しなければならない。集金でまごつけば学業どころか睡眠時間の確保さえ難しくなる。立て替えはしなくても、こちらの要因で「学校をさぼる→1 年で退学→2 年目は奨学金で遊ぶ」というのもよくあった。ちなみに学校へ通わなくても契約上、仕事をこなせば奨学金はもらえる。
以上を踏まえ、私は不確実性へ向き合うことにした。
新聞配達をする家とその配置を記録した順路帳というものがある。ここへは集金に必要な情報、例えば希望する時間帯や場所なども書く。だいたいは特別な条件があるとか、それに起因するトラブルがあった読者だけ明記される。しかし私は一度、すべての集金読者に対して
- 希望の集金日時はありますか？
- 希望の集金場所はありますか？
- 自動振込はいかがですか？
と質問してまわることにした。もしかすると潜在的な条件が結構あって、それを満たさず集金して空振り続けているのでは？という疑問を解決するために。すると結構な読者が 1 か 2 を要望、または 3 を受け入れる。予想どおり。それらを順路帳へ記録してゆくと効率のよい集金ルートを構築するのも簡単だった。ほぼ確実な集金を最短でこなしてゆくだけである。
結果として毎月、安定してノルマ達成できるようになった。最後の半年間はトップを維持。私の働いていた店はトップへ報奨金 1 万を支給していたので参考書の購入などに重宝した。もちろん時間にも余裕ができる。無事に出席率 8 割ぐらいで卒業できたのも、このおかげだろう。
これらはソフトウェア開発における調査と見積もりのようなものだ。不確実をそのまま放置せず、可能な限り確度を高める。それに基づく計画と実施。順路帳という形で記録していたからだろう、後任にも共有されて効率よく集金できたとのことだった。
この成功体験から
- 見積もり重要
- 時間は作れる
と学んだ。その後、プログラマーを生業とするようになって実感は増すばかりである。Redmine の課題管理に集金の日々を思い出す。もし当時これがあればもっと楽にノルマ達成できたし、みんなにも見積もりの有用さを共有できただろうと。
というわけで時間トラッキング、超オススメです。大事なことなので二度言いました。