計測で分解不十分なタスクを可視化し見積もり改善する方法（研修振り返りレポート）

この記事を読んでくれている人は、

実装の見積もりって難しくてやってないんだよなあ
見積もりと実装スピードって関係あるの？

など、思って読んでくれていると思います。

僕自身もバイトなどで開発をしていた時は、同じことを思っていました。しかし、社会人として働く上で機能の実装にどれくらいの時間がかかるかを見積もって周りに共有することは必須スキルです。この記事では、僕なりに考えた見積もりの方法について解説していきます。

就職前の僕と同じように、見積もりに対して苦手意識を持っている学生の方に特に読んでいただきたいと思っています。記事の中では僕が実際に使った方法やツールについても紹介しています。簡単に実践できると思うので、気に入ったものがあれば是非取り入れてもらえると嬉しいです。

見積もりができると何がいいのか？

研修の中で、「エンジニアがやりたいことに対して、やれる時間はかなり限られている。実際にどれくらいのことができるのか把握することが大切。」と言われたことがありました。正直、これを言われた瞬間は「まあやれるとこまで頑張るしかないよなあ」と思っただけでした。とは言っても、真面目に見積もりに関して考えないといけないことはわかっていたので、研修中に見積もりに関して自分なりに考え始めました。

当たり前ですが、見積もりができると、チームとして計画を立てやすくなるというメリットがあります。これに加えて、見積もりをすることができれば実装のスピードが上がるというメリットがあります。見積もりができる状態というのは

機能の要件
必要なライブラリ
実装にあたっての影響範囲
どれくらいテストを書くか
実装に使う技術の学習コスト

が分かっている状態です。

逆にこれらがわからないまま実装を進めていくと、途中で思わぬところでハマったりして、手戻りが出てしまったりするために時間が余計にかかってしまいます。

なんで見積もりってむずかしいの？

見積もりができると

計画が立てやすくなる
道筋がわかって実装スピードが早くなる

といったメリットがあるにもかかわらず、見積もりをしてこなかった原因は、見積もりをしても大体見積もり通りにいかないからです。

僕が見積もりが難しいと感じた理由は以下です。

エラーで時間を溶かすことがある
機能の実装に必要な学習コストがわからない
実装を進める前は簡単だと思っていたけど、意外にいろんな場所いじるのに時間かかっちゃう

どうすれば見積もりができるようになるのか？

見積もりが難しい理由について把握した上で、解決策を考えました。

経験を積む

エラーで時間を溶かす
学習コストがわからない

に関しては、経験を積むしかないと思っています。

見積もりをする ⇄ 振り返る

というサイクルを繰り返して、自分の中に経験値を貯めることにしました。

このようにスプレッドシートを使って、見積もり時間に対して実際の実装時間がオーバーした原因を振り返るようにしていました。エラーと学習コストに対する見積もりの精度を上げるには、地道に経験を積むしかないと思っています。

想定外のタスクが何だったか把握
タスクの規模に対して、どれくらいのエラーが発生しうるのか記録
類似のタスクでどれぐらい時間がかかるかの参考値を貯める

これらについて考察することで経験値を貯めることができました。

タスクを分解する

上であげた

エラーで時間を溶かすことがある
機能の実装に必要な学習コストがわからない
実装を進める前は簡単だと思っていたけど、意外にいろんな場所いじるのに時間かかっちゃう

のなかで、比較的、方法論で解決できるのが「実装を進める前は簡単だと思っていたけど、意外にいろんな場所いじるのに時間かかっちゃう」です。

どういう状況かというと、「実装を進める前は簡単だと思っていたけど、意外にいろんな場所いじるのに時間かかっちゃう」ということを想定しています。

データベースからデータ引っ張ってくるだけだと思っていたけど、接続の設定に時間がかかった
JSONリクエストを受け取るだけだと思っていたけど、バリデーションが多くて時間がかかった

が例です。

こういった例は、タスクが適切な粒度に分解できていないから起っています。

データベースとの接続設定、テストを書く、環境によって繋ぎ変えれるようにする
データを引っ張ってくる。テストを書く

みたいに、実装がしやすいような粒度で分解することが必要です。実装がしやすい粒度として、個人的には

4時間以内に終わる
変更をマージした時に中途半端でなく、システム全体が動く
プルリクを出した時にレビュワーの負担になりすぎない

ということを意識していました。

使っていたツール

これまでの話は抽象的な話でしたが、ここでは具体的な方法論やツールについて紹介します。

見積もりに関して、いろいろやっていこうと思ったものの、実際はめんどくさくて億劫になってしまいました。そこでツールを使ってなるべく見積もりに関して意識しなくてもできるようにしました。

Google Spread Sheet

見積もりに関する振り返りを簡単に表にまとめました。タスク管理ツールではなく、Google Spread Sheetをした理由は、動作が早く、ブラウザのタブに出しておけるので気軽に使えるからです。もっと複雑に管理したくなったらタスク管理ツールを使ってもいいと思います。

ポモドーロ

短い作業と休憩を挟んで集中力を維持するという、有名な手法です。作業時間が一定なので、時間と仕事量の経験値を積むのにも有効だと感じました。何よりSpread Sheetにまとめる労力が入らないので、最近はこちらも試しています。僕の場合は、アップルウォッチで使えるFlat Tomatoというアプリを使っています。

時計の画面に残り時間が表示できるので、作業を中断せずにさくっと確認できて便利です。何よりUIがかっこいい。

Github issueのtemplate機能

github issueのtemplate機能を使って、見積もりを自然とやるように自分自身を誘導しました。テンプレート機能で、予め見積もりに関する欄を作ることで、「埋めないと気持ち悪い」という心理が働き、見積もりすることを習慣化することができました。

コメントでコードを書く

実装を始める前に、コメントだけでコードを書くようにしました。これによって、実装を本格的に始める前に気づいてなかった実装に気づくことができます。もしここで、見落としてた実装に時間かかりそうなら、すぐに遅れそうということを周知できるようになりました。

画像の例で言うと、リクエストを受け取る処理を書いてから、APIの接続設定を書くよりも、APIの接続設定を一旦終わらせたほうが実装がしやすいです。こういった実装しやすい順番で実装する場面を増やすことができて開発がやりやすくなりました。

コメントでコードを書いてから実装するやり方は研修中に、キレイなコードを書く方法として教わりましたが、最後の見積もりの役割としても便利です。

Github Projects

チーム開発ではスプリント形式でタスクを設定しました。こちらに関しても、見積もりに関する枠を設けることで、「ここが埋まっていないと気持ち悪い」という心理が働くようにしました。

見積もりをやってみての感想

スプレッドシートでの振り返り
pomodoroで作業時間の単位を固定
github issue templateの活用
github projectsでの進捗管理

これらを用いて、見積もり力のレベルアップに取り組みました。見積もりに関して真面目に取り組んでみた良かったと思っています。計画を立てやすくなったのはもちろんですが、実装のスピードが上がったことと、手戻りが少なくなったので開発がしやすくなりました。

見積もりがうまくできている状態の時は

機能の要件
必要なライブラリ
実装にあたっての影響範囲
どれくらいテストを書くか
実装に使う技術の学習コスト

こういうことがわかっている状態です。

見積もりをほとんどしていなかった時には、これらが把握できておらず、何度も手戻りが発生して実装が遅くなったり、汚いコードになってしまうことがありました。もしこれまで見積もりをほとんどしてこなかったのであれば、僕が紹介した方法を１つ試してみるだけでも効果があるはずです。是非試してみてください。

以上、研修を通して振り返ったことをご紹介しました。他の研修生たちも記事を公開していきますので、もしよろしければ、 @DeNAxTech をフォローして、今後の記事もぜひご覧ください！ Follow @DeNAxTech