開発時間の内訳を眺めてみよう
開発効率を上げたいとか、開発速度を上げたいと言うのはプログラマの自然な欲求だと思います。 「そう思いはするもののどうすればいいかわからない」のであれば、開発時間の内訳を眺めてみましょう。
この図はグルーピングが微妙だったり、重要なものが抜けていたりすると感じるかもしれませんが、雰囲気は伝わるかと思います。使用している技術要素や取り組んでいる内容によって項目レベルでなかったりもします。参考程度に。
さて、単に「開発効率」と言うと、「コードを書いている時間」に目が向きがちです。これはさらにタイピングの時間だとかに分けられるかと思いますが、実際のところ、ここに割かれる時間は全体で見れば誤差のようなものです。もちろん早いに越したことはありませんし、無意識に書けるようになれば思考を他にやりながら書けるようになります。実際ある程度慣れた方であれば、コードを書きながらコードを読み、抜け漏れに気づいたり、リファクタリングを考えたりしてると思います。ここで重要なのは、短絡的にコーディング効率を求めても思うように改善はしないと言うことです。
もし「調べている時間」の比重が大きく、プロダクト自身のコードを読むのに時間がかかっている場合（図では「同様の機能を探している時間」や「呼び出し元や呼び出し先を調べている時間」が該当します）は、リファクタリングやコメントの追加が役に立つかも知れません。コードリーディングを重ねるでもいいかも知れませんし、時間が解決する問題かも知れません。調べている時間の比重が大きい時に、コードを書く時間を短くする施策の効果があまりないのはわかると思います。
時間のとられているものが識別できれば、そこに対して具体的なアプローチが取れます。ものによってはプロセスの組み替えによってそもそもその時間をなくすこともできます。たとえばテストファーストは作ったものを確認する時間を削減できますし、型パズル（コンパイルエラーの解消）はリファクタリング機能を使ったりコンパイルエラーの即時解決によってゼロに近づけられるでしょう。もちろんそれにより他の時間が増えたりはします。良いことしかないアプローチであれば既にやってるはずなので、何かしらのトレードオフは常に発生します。合ってるかどうかを見極めるのに、対象の識別が役立ちます。
言うまでもありませんが、図の中にない「質問の返答待ちになっている時間」とか「説明してもらっている時間」とかもあります。この整理の中では、他人が絡むような自身で制御できないものを混ぜない方がいいかなと思っていますが、「ドキュメントなどの情報を確認している時間」に入れたりもできるかも知れません。別のグループを作ってもいいと思います。グルーピング（左側）は直接アプローチできるものにできるていると良いかなーと思っています。ここで「考えたり調べたりしている時間」には思考法や情報整理の技術が役立ったりします。
自分の開発の時間の内訳に向き合って、どこを改善すると効果がありそうかを考えてみるのもいいんじゃ無いかなーと思うわけです。重要なのは「時間」という単位を揃えること。違う単位は比較不能です。効率とか生産性とか、どうとでもハックできる数値を使用しない。この辺りの整理ができていると、見積もり精度が上がったり、差分がある時の説明が明快になったりします。そう言うのを外に出す目的にやると辛くなるのでお勧めしませんが。。。
一つ注意。この手の時間は体感値と実測値に大きな乖離があるので、なるべく計測しましょう。とはいえ厳密に記録しようとすると手間がかかって続きませんので、無理せず記録できるのがいいなと思います。もともとグルーピングも大雑把ですし、ポモドーロと併用して25分内の内訳は体感（25分内ならそんなズレないでしょ）とかで十分かなと。ペアプロなどをしてるならナビゲーターに記録してもらったりしてもいいと思います。
このやり方は個に閉じているので、一人でも始められます。と言うか、下手に複数人の絡むような不確定要素を混ぜない方がいいと思ってます。全体最適が要らないとか言うわけではなく、これはこれ、それはそれって感じ。
関連
「機械的な対応をしている時間」が多いと感じた場合、量を量のまま扱っている可能性があるかも知れない。
