工数見積りについて見直してみたこと
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2022（2022年12月12日）の投稿です！
12月12日（月）は、ウイングアーク１ｓｔのテストエンジニアytakahashiが時をお知らせします。
突然ですが、最近、私ラーメンのスープを自分で作ってみたんですよね。
鶏がら（あるだけ）と豚脂（これまたあるだけ）、玉ねぎ1個、人参0.5本、生姜2かけ、お酢小さじ1杯を12時間煮込む。
煮込み終えたあとに、醤油だれを作ってー♪、煮込んだスープにブレンドしてー♪、市販の麺をゆでてー♪、盛り付けしてー♪、食べたんです。いやぁ、実に美味しかった。我が家の海原雄山こと息子にもお墨付きをもらいました。
煮込みの12時間は別として、そのあとの醤油だれや麺ゆで、盛り付け作業は大して時間がかからない工程です。
ですが、しかし…
実際は1時間くらいかかってしまいました。醤油だれのレシピを調べるのに没頭して時が過ぎてしまったんです。そう、予想していた時間よりも長くかかってしまいました。
さて、前振りはここまでにしておいて。
今回は、「予想よりも時間がかかってしまった」ことに注目します。
少々強引に仕事に当てはめますが、この「予想よりも時間がかかってしまった」は「予実の差」、ひいては「工数見積もり」に関わってくる部分になりますよね。
本記事ではこの「工数見積もり」に関してお話させていただけたらと思います。
■本題です
ある程度自分なりに仕事がこなせるようになってくると、決まって言われる言葉。
「アサインした業務っていつまでに終わりそう？」
依頼された仕事（検証そのものやテスト設計などの作業ですね）が一体いつまでに終わるのか。。
テスト計画を立てる上でもとても重要なことにもかかわらず、これほど厄介なものはないかもしれません。
ここからは時系列とともにいくつかのセクションに区切って私が工数見積もりに対して行ってきたことをお話していきたいと思います。
■なんとなくの経験則から作業をしていた過去
「あぁ、これ新機能で影響範囲広そうだし大体5人日くらいかかりますねぇ」
明確な根拠なく、今までの経験則から仕様書をみたりして「なんとなく」で作業ボリュームを頭の中で考えて返答。ちょっと心配だから多めにバッファを積んでおこう。
恥ずかしながら自分は可視化されたデータもなく、己の主観だけで作業をこなしていたことがありました。
結果的に、予想通りの日数で終わることもあれば、予想以上に時間がかかりメンバーやリーダーに迷惑をかけてしまったりしたことが多々あったことも事実です。
「経験則で工数を予想する」
このこと自体に問題があるわけではなくて、すべて頭の中にあることを随時呼び出して根拠にしていたことが問題だった気がします。人の記憶は、儚いです。そして、常に美化され続けます。
「あの時の機能テストはほんと大変だったけど、確か最後盛り返して終わったんだった。俺ってばスゲェ！」などなど。。
何を盛り返したんでしょう？まっ、いっか。そう、記憶は都合よく改ざんされます。
■実践したこと（していること）
なかなか見積もりの予実が安定しない私は、この状況をどうにかするべく、振り返りなどを行いながら見つめなおす時間を作ることにしました。
そこでまずは以下を実践していくとにしました。
- 1週間の大まかなやることを書く（予定の可視化）
- 1日のやることをその日の朝に書く
- 作業時間を30分単位で測ってみる
1週間のタスクと1日のタスクを書く際には、弊社ウイングアーク１ｓｔの渡辺大輔(Watanabe Daisuke)さんの記事が助けてくれました。
■見えてきたもの
- 1週間の大まかなやることを書く（予定の可視化）
- 1日のやることをその日の朝に書く
↓
私は紙に書くようにしました。Outlookの予定表に書いてあるものでも改めて書いていく感じです。
言わずもがなといわれればそれまでですが、「書く→予定表を改めて見る」ことを1週間したことでわかったことは、
「驚くほど作業のみに費やせる時間が少ない」ことでした。
例えば、1人日かかると宣言した作業を月曜日に始めたとしてもその日に終わらないことが改めてわかった感じです。なぜなら、月曜日は午前午後合わせて会議が4時間あるからという具合に。。
- 30分単位で測ってみる
↓
とにかくまずは、自分の作業の予想工数（時間）を書いてみて、実際のかかった時間を計測しました。
ここでみえてきたものは…
「仕様をきいたり、質疑応答のやりとりしている時間が予想以上にかかかっていた（コミュニケーションに費やす時間）」
「インシデントの切り分け作業が重なると大幅に時間をとられる」
「あ、あれ。。こんな時間かかってたの。。」
ちなみにこの画像は私が使用しているタイマーです（各面に時間が区切られていて、ぱたんと倒すとタイマーが始まります）。
■記録し終えた作業時間の分類分けをしてみる
30分単位で計測したことを書きましたが、ただ計測しただけでは生かせないと感じたので私なりに以下のカテゴリに分類して振り返ってみました。また、作業が終わったあとプチメモを書いています（特に苦戦したタスクを対象）
- 一人でも自力でこなせるもの
- チーム内のメンバーにヒアリングすることでこなせたもの
製品の担当機能がわからないなど - 開発部署にヒアリングすることでこなせたもの
主に詳細な仕様や再現方法がわからないなど - 事前知識などなく、調査から入らないとこなせなかったもの
そもそも検証前の事前知識(リテラシー含めて)などが身についていないなど
一人で自力でこなせるもの以外は、下にいくほど予想工数が提示しにくいですよね。逆にいえば、ここで一度でもとったデータが非常に次の工数見積もりに役に立つことがいえます。ご自身を取り巻く環境によってこのカテゴリは増えたり減ったりするかもしれません。
■実績を基準に工数を予想してみる
ある程度、データがたまってくると与えられたタスクによって、自分なりに工数の予想が立てやすくなってきます。
「〇〇のタスクは、分類的には開発部署にヒアリングしないとわからないカテゴリだな。前回は、16Hかかったけど今回も近い時間がかかりそう。いや、まてまて。同じ機能なら習得にかかった時間は省けるから8H以内に収めることができそう。」などなど。
各カテゴリに1つでも計測した実際のデータがあれば、それを基準にして思考を巡らせることができるわけです。
そして、話し合いのベースにもなりえるところも強いですね。
■副次的効果
工数のデータを記録していくと必然的に検証内容を振り返ることになると思います。
「メモに切り分けに時間がかかったって書いてあるけど、次回類件の作業を振られた場合はこの時間は半分に圧縮できるかもしれない」
「予実の差がないのは、疎通確認メインだからだな。なので別の人が実施したとしても同じ工数で作業は終わるかもしれない。」
などなど。一人振り返りを自然にしているわけですね。
■まとめ
簡単にまとめると以下①と②の繰り返しをすることにつきます。
①工数の記録をとってみる（30分単位）
↓
②予実の差を振り返り更に次の工数見積もりの指標にする
使用前：
「あぁ、この機能って前回実施したとき1週間くらいかかったので今回もそのくらいかかるかと思います」
使用後：
「依頼されたタスクは、前回実施時2人日ほどかかりましたが、1人日は仕様把握などの時間に費やされているので、今回担当者が同じ私であれば、仕様把握の時間を圧縮して1人日で終了すると思います」
なんということでしょう。まさに輪廻転生した気分ですね。
★終わりに
ごくごく基本的なことで、わかりきってることを書いたかもしれません。
それでも、実践してみると思いのほか再認識させられることが多く学びがありました。また、本記事ではあくまで自身が作業した場合を例にとりましたが、対象が委託企業になった場合は、「製品知識取得」の要素が加わったり別視点を加味したうえで見積もりできたりするかと思います。
計測時間は、私は30分単位でしてみましたが作業の性質を踏まえて1時間でも2時間でもいいのかなと思います。要は「記録をとる」ことが大事なわけです。
簡単に記録をとると言っていますが、習慣づけるのは大変かもしれません。例えば、私が以前講習を受けさせていただいた「日経BP社主催のタイムマネジメント研修」のようなものを受講して
「時間に対する意識を変えてみる」のもおすすめです。
タイムマネジメントと検索すると講座や研修などヒットするので是非調べてみてください。
とはいえ、そんな簡単にできたら苦労しないし、見積もりの予想が毎回100％うまくいくことはありません。だからこそ、記録することが大切なのだと思います。手の込んだ料理がおいしいように、こつこつとりためたものはきっと役に立ちます。
ですので、ぜひ作業時間を意識してデータにとることを実践してみてください。
つらつらと長文を書いてしまいましたが、ここまで読んでくれた方がいましたら感謝の念に堪えません。
それでは、みなさん、今年も残りあとわずかですが、よきクリスマスライフをお過ごしください。
