背景
どのチームの責任とも言えない理由で、開発の速度は落ちていました。サービスを一つ立ち上げるのに設定のコピーで何日もかかり、CI は統一されておらず、安全なリリース方法が自明であることは稀でした。その代償は障害ではなく、慎重さという形で表れていました。
取り組んだのは、開発者の日々の道のりをプロダクトとして扱うことです。どこが痛いのかを計測し、正しい選択が最も手間のかからない選択になるようにしました。
アプローチ
最初のコミットから本番までの実際の道のりを洗い出し、各工程の所要時間を測りました。最も遅く、最も間違いが起きやすい工程 — 環境構築、リリース判定、ロールアウト — を最初の対象にしました。
ドキュメントを増やすのではなく、指針をツールに埋め込みました。規約に沿ったサービスを生成するスキャフォールド、変更をプレビューする単一のコマンド、そして安全なロールアウトを既定にしたパイプラインです。
良いツールは目に見えません。打鍵数ではなく、判断そのものを取り除きます。
成果
- 1 日 → 1 時間
- 新規サービスの初回デプロイまで
- 40%
- リリース失敗の削減
- 1 コマンド
- 変更から共有プレビューまで
主な意思決定
強制ではなく、整備された道を
後からポリシーで縛るのではなく、規約に沿った道を最も簡単な道にしました。利便性が普及を後押ししました。
古びないスキャフォールド
生成されるサービスは生きたテンプレートを参照するため、改善は移行プロジェクトなしに全チームへ届きました。
ツールではなく道のりを測る
成功の指標を本番までの時間とリリースへの自信に置き、エンジニアが実感できる成果に紐づけ続けました。