見積もりは難しいが、自分的なノウハウを書いてみる。
見積もる
プロジェクトの最初期、実装にどれくらいかかるか見積もる必要があるが、ロジカルに正確な見積もりを出すのは不可能である。 これがわかってないと正確な見積もりを出そうとして無駄な労力を払うことになる。どれだけ努力しても正確な見積もりは出せない。
なぜなら未来は予想できないからである。 我々で制御できない外部変数が多くある。どれだけ努力してもそれらを事前に知ることはできない。
だからこの時点では、ざっくりと大雑把に十分以上に思えるバッファを乗せた見積もりを出すしかない。
※ 見積もりを出すまでの期間を使って、実際にモノを作ってしまう、という過激派もいる。一つの解ではあると思う。
※ 比較的正確に見積もることができる仕事も存在する。ルーティーンワークや、ライン製造業などである。これらは外部変数が少ない。1時間稼働したらどれだけ成果が出るのかがある程度定数で出せる。こういった業務は今回の話の対象外とする。
見積もりは無駄なのか？
結局正確性に欠ける見積もりしか出せないのであれば、見積もりの工程自体が無駄ではないのか？とも思える。
しかしこれは無駄ではない。 見積もりがないとまわりが動けないのである。
仕事は色々な役割の人が同時に動いている。 「いつごろ製品ができるのか」という情報がないとそれらが協調して動けない。 ある程度の目安を目指して皆が協調して動くことで、時間を有効に使うことができるのである。
測る
見積もりを出して走り始めたら、常に見積もりとのズレを測りながら走るようにする。
走り始めると「何にどれくらいかかった」という実績値がわかる。 この実績値を使って再度自分の中で見積もる。
- タスク1に1週間かかった
- タスク2のタスク量ははタスク1のざっくり2倍である
- 2週くらい掛かりそう
という具合である。
それの積み重ねで、当初だした見積もり内に収まりそうなのであれば問題ない。 そうでなくなってきた場合には、以下に記載する「調整交渉」が必要になる。
遅れの要因
遅れの原因には以下のようなものがある。 どれも事前に完全に予防するのは難しい。
仕様変更
仕様変更。必ず発生すると思っていたほうがいい。 見積もりの前提が動くので遅れの原因となる。 すでに実装済みの部分だった場合には、払った工数が無駄になり、追加で工数が必要になるなどする。
勘違い
仕様を勘違いしていたのが判明する。 発生起因が内部か外部かの違いで、状況としては仕様変更と同じ。
見積もりが甘い
「〇〇するだけなのでそんなにかからないと思う」という言葉をよく耳にしたり発したりするが、だいたい思ってた2倍以上の手間がかかる。 人間の持っているバイアスで、何事も「簡単にできそう」と思ってしまう。
品質が低い
バグの発生報告が収まらず、修正が追いつかない状況がいつまでも続き、テスト実施用に確保されている期間を食い潰す。 これが一番曲者。 ビギナーだと壊滅的な遅れに発展するケースが多い。 開発スケジュールのかなり後半で発生するのでダメージもデカい。 技術力を上げていくことで回避できるようになる。
調整交渉する
「計測する」の項目で記載した方法で常に再見積もりし、間に合いそうにないと判明した場合には調整する必要がある。 まわりは見積もり通りにできる想定で動いているので、なるべく早くズレの可能性を連携する。
以下に記載する、時間調整と機能調整を複合して調整交渉する。
時間調整
時間を余分に確保して調整する。
以下のような感じ。
- 締切を伸ばしてもらう
- 残業する
- もってる他のタスクを肩代わりしてもらって集中させてもらう
- 他メンバーに手伝ってもらう
機能調整
締切は動かさず、想定していた機能を減らしてリリースにこぎつける。 また、本当はやりたい作業（リファクタや、パフォーマンス調整など）から優先度の低いものはやらないようにして時間を捻出する。 （リリース後に改めて行うかを検討するなど）
機能調整をしやすい構成にしておく
機能調整をするには、機能単位で疎結合になっている必要がある。 そうしておかないとせっかく「〇〇機能はリリース後対応でもいい」となっても「〇〇機能が動く状態にならないと、全体として正しく動作しない」みたいな状況になり、結局実装せざるを得ない状況に追い詰められる。
最後に
上記のテクニック（主に調整交渉の項目）が使える状況とそうでない状況があると思う。 「何がなんでも初期見積もり通りにリリースしろ」という状況は存在して、それに関しては「過剰なバッファを積んでおく」くらいしか答えを持ってない。
