はじめに
うめりんです。
少しでも「参考になった」と感じて頂けた方は、ぜひいいね
お願いします
①すぐに近似値を出せるように、普段から時間感覚を意識して覚えて（記録して）おく
考え方はフェルミ推定に共通する部分も多くあるかもなのですが、難解なことでは無く誰でも身につけられるものです。
なぜ必要なのか？
リーダーになると何かにつけて
「ザックリどれぐらいかかります？」と聞かれる（概算を求められる）ことが、めちゃくちゃ多くなります。
その際、”詳細な仕様を元に積み上げで見積もりをすること”しか経験が無い（手法を身につけて居ない）と、回答に時間がかかり過ぎたり、一応出してみたものの見積もりと実績の差が大きくなり過ぎてしまったりすることが、よく起こります。
こういった期待に応えられない状況が続くと、リーダーとなった本人も辛いですし、周りからの信頼も上がってきません。
具体的に何をすれば良いのか
まずは、普段のフルビルド時間・デプロイ時間など、開発運用において避けて通れない（必ず発生する）ものの時間を測り、いつ誰から聞かれた時にも即答できるよう覚えておきます。
測った後に覚える時の注意点なのですが、42分なら40分、55分なら1時間、など端数を後々に何らかの計算をし易い近似値に丸めておくことが大事です（これにより覚え易くなる効果もあります）。
これをやっておくと副次的な効果として、コードや環境などに異常が発生した際に（普段より時間がかかるようになったり、終わるのが想定より早すぎる場合に）すぐ気付けるようになります（あれ？何かいつもと違うぞと感じられるようになる）。
次に、自身が過去に経験のある機能や要件ごとに、設計・実装・テストに対して、何にどれだけ時間がかかったかを洗い出します。
コツは「洗い出す時に細かくし過ぎないこと」です。細部が決まっていない時に概算が出せることがゴールなので、その時に役立つデータになるよう意識した粒度として下さい。操作可能なUI数、画面数、API数、演出(アニメーション)数、扱うデータ数などが比較的分かりやすい指針です。既存機能の流用度合いが高い場合は、調査にかかった時間やその機能を知る経験者が居たかの状況も合わせて記録しておくと重宝します。
スクラムを用いているチームの場合はストーリーポイントも参考程度にはなりますが、実績値として使えないことも多くブレが大きいのであまりオススメしません。
また、不具合修正とリファクタリングは既存実装における負債の大きさが違い過ぎることが多いので、一旦は洗い出しの対象外とした方が良く、これらを見積もる際には概算で話さず調査時間をしっかり取った方が良いです。
そして最後に、バージョンアップ開発のフェーズや運用データのリリースなど、より大きな単位に対しての数を把握します。期間(or 稼働日数)、PR(or MR)の数、不具合修正の数、関わったメンバの数、などが一例として考えられます。
これらを手元に持った上で定期的に眺めて「今回の開発は、あの時と同様の規模だな」のように感じられるようになれば、できるリーダーに必要な感覚の1つが身についたと自信を持って頂いて大丈夫だと思います。
おわりに
そこまで経験が無いけれど、もしリーダーに運良く抜擢され、何度か失敗しても長い目でみてくれて任せ続けて貰えれば、実戦の中から必要だと自覚できる人が多いとは思うのですが、この手のことは「もっと早く教えて欲しかった」となることが多く、教える側（前任者、先達）もしっかり意識して来た人でないと「慣れるしかない」のように策を持っていない人が多いので、まとめてみました。