リモートワークをきっかけに、見積もりと進捗管理について考えた
最近の自分のテーマが、見積もりと進捗管理であるという話をしようと思う。
上記のために必要になるため、テスト、およびテスト駆動開発についても大きなテーマである。
きっかけ
きっかけはテレワークだった。
テレワークしていれば天国、テレワークにさえなれば天国と思ったんだけれど、全くそんなことはなかった。
もちろん良いこともあった。気分をDaylioというアプリで記録しているんだけど、テレワーク期間、ストレスがないためか気分の浮き沈みがなく、安定して「良い」気分に保てていた。
ただ、仕事においてしんどさを感じることが度々あった。
進捗
その原因は、進捗である。
思えば、出社している状態であっても、進捗に余裕があり自身を持って進められている状態であれば、しんどさを感じることなく、むしろ楽しいまであった。
一方、進捗が遅れている状態では精神状態は地獄と化す。
その状態で、作業において詰まってしまったときなどは尚更である。
これを解決する方向性として、「スキルを上げて作業スピードを向上させる」というものもあるのだが、これはいたちごっこなところがある（当然、僕らはこちらの方向性においてもベストを尽くさなければならないのだけれど）
で、もっと妥当に解決できる方法がある。見積もりである。
スケジュールが逼迫するような見積もりを出さなければよい。そうすれば、余裕を持って仕事ができる。
見積もり
さて、じゃあどこまでスケジュールを長く取ればよいのかという疑問が浮かぶ。いわゆるバッファである。
行くところまで行くと、「完成したときが締め切りです」となる。しかし、それでは通らないであろう。
Clean Coderという書籍が、この点非常に参考になった。
Clean Coder
Clean Coderでは、締め切りについて以下のように原則をおいている。
締め切りは、絶対に遅れてはならない。「間に合います」と自信を持てる箇所に設定するというものである。
これは、顧客と「この日に納品します」という約束（コミットメント）を行っており、顧客がその日に納品されることを「期待」しているからである。
顧客は、納品とサービスの稼働を前提に、プロモーション等の準備や手配を勧めているかもしれない。
その状態で締切を破るということは、顧客に危害を加えるに等しい。
じゃあめっちゃ長い見積もりを出していいの？というと、そういうわけではない。
筆者のボブおじさんは、エンジニアが自分の作業について高い確度で見積もれることを前提としている。
プロとしてどう振る舞うか？みたいなことについて書いた本なので、そうなる。
じゃあ、どうやって、「高い確度での見積もり」を行うのか
高い確度での見積もり
三点見積もり法
Clean Coderで紹介されている方法である。楽観値、標準値、悲観値を出し、それに係数をかけて見積もり日数を算出する。
積み立て法
一般によく行われている方法で、タスクを細かい作業に分解して、分解したそれぞれについて所要時間を見積もり、それを合算する（積み立てる）というもの。
この手法で見積もると、工数が膨れ上がってしまう傾向があるため、注意が必要。
現在やっている方法
現在やっているのが、積み立て法と三点見積もり法を併用するというものである。
すごく単純だけれど、
- 与えられたタスクを、極力細かく分割する
- それぞれのタスクについて、三点見積もり方による見積もりを行う。
- それぞれの作業時間を積み上げ、合算した楽観値、標準値、悲観値を得る。
というのを行い、悲観値を見積もりとして提出している。
情報はスプレッドシートにまとめ、実績値を記入し、進捗把握と振り返りに利用している。
正直、かなり泥臭い方法である。ただ今の所、これ以上の方法は見つけられていない。
思いもよらぬメリット
作業を進めていて、ここの見積もりはもう少しこうすべきだったなと思ったところは、そのセルにコメントをつける。
作業完了後、全体の振り返りとして、実績値欄の合計値箇所にコメントをつけて、全体的な振り返りを行う。
このスプレッドシートにまとめて、毎度細かく振り返りを行っているところに、今現在、価値と期待を見出している。
PDCAサイクル、個人的に好きなTDD界隈の言葉を使うと、「フィードバックループを回す」って表現するのだけれど、これを行うことで、以下のような気付きが得られた。
改善点については随時取り込んだり、設計技法等、習得に時間のかかるものは事骨取り組んで身につけたりしている。
リリース単位を小さくすると、見積もりは簡易になる。 プロトタイプ開発のように、まず画面を、次に最低限の機能を実装したリリースを、と段階的にリリースを行うと、見積もりは簡易となる
可能な限り作業単位を分割したほうがよい
- 見積もりが容易になる
- 考慮漏れが防げる
- ガンガン質問することで、進捗はスムーズになる
- 最もよく発生する作業遅延は、詰まり。これは他人に聞くことで回避できるケースが非常に多い。
- 進捗を出したければ、遠慮せずガンガン質問する
考慮漏れしやすい作業工程
設計する力が大事 設計が甘く、実装工程で予定が変わると死ぬ
テストをしっかり書くことも大事 すでに終えた工程において、後から不具合等見つかると死ぬ
更に見積もりを高めるならば
採用しなかったが、更に徹底するなら、ファンクションポイント法などを併用して、突き合わせて確認する（積み上げ法は工数が膨れ上がりやすいという特徴があるため、組み合わせることで誤差を小さくする）方法などがあった。
また、Clean Coderでは同僚と協力する方法、複数人で見積もって突き合わせたり、同僚に相談する、自分の見積もりを評価してもらうことが推奨されていた。複数人で見積もることで、誤差を小さくすることができる。
また、現在プロジェクトは1人での担当だが、体調を崩すなどが発生すれば、コミットメントを果たせなくなる（別日出社する等は可能であるが、長期入院してしまう等発生した場合は難しい）
そのため、盤石を期すのであれば、構成員についても冗長するなど、体制を整えるというアプローチも必要になるだろうと思った。
メリット
まだバッチリ正確な見積もりをすることはできていないが、現時点で以下のようなメリットがあった。
自信をもって仕事に取り組めるようになった
概算見積もりよりも根拠を持って見積もりを出すことができるため、自分の見積もりに自信がもてる。
また、自分で見積もったタスクを、自分の引いたレールに沿って勧めていくことになるため、タスクを自分でハンドリングしている実感が得られ、主体的に仕事に取り組めるようになった。
「質問しにくい...」問題が解消された
あと、リモートワーク下で特に申告になりやすい「質問しにくくて...」問題だが、前述の「# 思いもよらぬメリット」の箇所においても書いたとおり、質問したほうが進捗が出ることがわかっている。
かつ、締切に間に合わない、すなわち死（大げさだけど）という意識で仕事に取り組むようになったので、詰まった際、
先輩の都合なんぞ知るか、質問せんと進捗遅れて俺が死ぬんじゃ〜！という意識で、ガンガン質問できるようになった（なお、もとからわかっていたことだが、大概相手は質問されたことを不快になど思っておらず杞憂である）
現在地、ゴールを把握しながら仕事が進められるようになった
また、細かく見積もることは進捗管理の面でも有用であり、自分が今どこまで進んでいて（現在地）、ゴールまであとどれくらいなのかを把握しながら仕事を進められるようになった。
これも、自身を持って仕事を勧めていけるという面に寄与してくれた。
終わりに
現在の自分のテーマは、見積もり、進捗管理、そしてそれを支えることになる、テストとテスト駆動開発である。
しばらくじっくりと、これらの課題に取り組んでいきたい。
