工数見積もりとはラブレターである
前置き
システムを実装する上での工数見積もりで、どんなことを把握したいですか？
僕は個人にできるかぎり依存しない、事業価値を届けるために必要なコストを把握したいと思っています。
工数見積もりとは誰が行うものでしょうか？担当するエンジニア個人でしょうか？それともチームに属するエンジニア全員でしょうか？
僕はデザイナーや企画も巻き込んでチーム全員と関わりながら行うものであると考えています。
関係者全員で、絶対的な時間の見積もりではなく、相対的な規模感での見積もりをしていく。この辺りは所謂アジャイルな開発の思想に影響を受けているように思っています。
このような考えのもと、工数見積もりというものを通して
- 何がしたくて何がしたくないのか
- 各ポジションとどんな風に関わっていくのか
- 一番考えるべきことは何だと思っているのか
みたいなポイントで自分の考えをまとめていこうと思います
何がしたくて何がしたくないのか？
工数見積もりでしたいことはなにか？
- ユーザーにとって必要なものであることがイメージできること
- イメージ通りの機能を作りあげるために必要なものを整理すること
- 規模感の把握
工数見積もりでしたくないことはなにか？
- 実際にできあがったものが意図していないものになること
- 作業に入ろうとしたときにまだ動きだせない状態であること
- 未確定要素によって規模感すらだせないこと
こうやって改めて考えてみると、情報の整理からくるタスク分解と規模感を把握だけでなく、タスクの完了状態が与える影響がどんなものかもこの段階で意識したいのだなと思いました。
また着手時にすぐ動き出せるように、未確定要素を極力なくす調整もこの段階で一番とっていきたいと思えました。
各ポジションとどんな風に関わっていくのか
デザイナーや企画側に対して
デザイナーや企画側に対してはフィードバックをする、レビューの面もあると思っています
- どんなことをしたいのか伝わってくるか？
- 自分がユーザとしたら価値があると思えるか？
- タスク分解をイメージできるだけの情報があるか？
- やりたいことへのシステム的な解決はもっと良い方針がないか？
- これをやらないで別のことやったほうがよかったりしないか？
実装する側だから気づける点と想い、実装前段階ですり合わせていくことで出戻りを少なくしていければと思っています。
同じエンジニアに対して
同じエンジニアに対しては、いかに思いを伝えて共通のイメージを持つかが大事だと思っています。
- 他人がこの作業をするのならどんな情報が必要か？
- 新たに配属された人でもイメージできるだけの情報になっているか？
- 作業の実現アプローチは妥当なものか？
- 実現するための不明点はないか？
同じエンジニアだからこそ、スムーズに開発がスタートできるよう負担を軽減することになればと思っています。
一番考えるべきことは何だと思っているのか
やることの見積もりをするのはもちろんなのですが、僕は加えて一部やらない判断を提案していくことや、既にあるもの削除していくための見積もりこそ大事ではないかと考えています。
それは事業に対してエンジニアが一番主張できるポイントが、何を作らないのか？だと思っているからです。
やらないことが増えると、保守するコードが減ることになります。運用時のフットワークが軽くなります。
全ての企画を作るとこれくらいかかるけど、同等のこんな機能ならこれだけでできるよ？
企画のやりたいイメージをいかに、シンプルな機能だけで実現できるのか？そこを考えるのも面白いとこなんじゃないかなと思っています。
そういう意味で工数見積もりとは、事業を企画することに大きく関わる作業だと言えるだろうと考えています。
まとめ
作業担当する誰かに送る、精一杯の想い。色んな下準備をして、受け取る人に気に入ってもらえるように作る。さながらラブレターなんじゃないかと思っています(今回これがいいたかっただけかも)。
愛を持って工数見積もりをしてみませんか？きっと愛は届く！きっと。
おしまい。
