人を増やしてもらえないまま、もっと速くと求められたら、どうしますか?

Question

Accepted Answer

そもそも人を加えても短期的にチームが速くなることはめったにないので、本当の問いはこうです: チームの*時間は実際どこへ行っているのか*、そしてそれについて私は何を変えられるか? 私は「もっと速く」を、長時間働けという要求ではなく、レバレッジを見つけるための合図として扱います。

## どこで速度を探すか

- **手抜きではなくスコープを削る。** より速く出荷する最速の方法は、より少なく作ることです。PMと協力して容赦なく優先順位を付け、価値を届ける最小バージョンを見つけます。ほとんどの機能は、作業の20%で80%の価値です。
- **摩擦と待ち時間を取り除く。** ボトルネックはしばしばコーディング速度ではなく、遅いCI、flakyなテスト、苦痛なデプロイ、遅いレビュー、承認待ちです。30分のビルドや2日のレビュー回転を直すことが、無料で本物のvelocityを買います。
- **仕掛り中の作業を減らす。** 10個を同時にこなすチームは何も終わりません。並行する項目を減らして集中すれば、物事がより早く出荷されます。
- **繰り返しを自動化する。** 手動テスト、手動リリース、手動の環境構築 — 一度投資して、永遠に節約します。
- **積極的にあなたを遅くしている負債を返す。** すべてではなく、チームが毎日つまずく部分だけ。
- **集中時間を守る。** 会議と割り込みを減らすことは、どんなツールよりも大きな勝利になりえます。

## 依頼にどう応えるか

私は単に「不可能だ」と言ったり、黙って受け入れたりしません。**トレードオフ**で応えます: 「機能AとBを削るか、テストのリスクを高めることを受け入れるなら、その日付に間に合わせられます。私の推奨はこれです。」これは速度を、静かな品質の賭けではなく、共有された意識的な意思決定にします。

## 避けるべき落とし穴

- **残業を命じる。** 短いスプリントを買い、燃え尽き、バグ、離職で返済します。
- **テストとレビューを黙って飛ばす。** 今日の速度、来月の障害。
- **何も変えずに日付にイエスと言う** — それは単なる希望であり、希望は締め切りを逃します。

## なぜ重要なのか

持続可能な速度は、人を絞ることからではなく、無駄を取り除くことから来ます。プレッシャーに対して明確なトレードオフとプロセス改善で応えるTech Leadは、本当に速く、耐久性のあるチームを築きます。全力疾走し、墜落し、最高のエンジニアを失うチームではなく。