「誰かがやるだろう」をやめた記事の取り組みを前提環境から分解する

カケハシのテックブログ「誰かがやるだろう」をやめた1年間の記録を読んで、取り組みの中身よりその取り組みが成立した前提環境が気になったので整理する。

記事の取り組みサマリー

記事では以下の改善が紹介されている。

取り組み	成果
レポート機能テンプレート化	実装工数 半日 → 1時間
リリースフロー3段階化	手続き時間 30分 → 3分
Lambda自動化	手作業をゼロに
DeepDive会	システム知見の共有
Claude Codeプラグイン整備	PR description自動生成

転機は「追い込まれた」こと

著者の転機はテックリードの異動だった。有識者がいなくなって初めてチームの課題が自分ごとになった、という話で、自発的に気づいたわけではなく外圧によるもの。

この点は記事の中で美談として語られているが、正直に読めば「追い込まれるまで動けなかった」とも言える。

取り組みが成立した前提環境

各取り組みを成立させるために必要だったと考えられる環境を分解する。

1. レポート機能テンプレート化

必要な前提

• コードベースに触れる裁量がある
• リファクタリングを「余計なこと」と止められない
• 関連機能を触るタイミングでついで改善できる隙間がある

2. リリースフロー3段階化

必要な前提

• プロセス変更の提案を現場が出せる文化がある
• マネージャーが「なぜ変えるのか」に納得できる
• チームが新しいフローを受け入れてくれる

3. Lambda自動化

必要な前提

• 自動化ツール（Devin・Claude Code）を試せる裁量がある
• 「先に温度感を合わせる」ことでチームの協力が得られる
• ある程度まとまった実装時間が確保できる（または黙認される）

4. Claude Codeプラグイン整備

必要な前提

• 新しいツールの導入を試せる文化がある
• メンバーが使ってフィードバックをくれる
• プラグイン化の提案を受け入れてもらえる

共通する前提

個別の前提を横断すると、以下の3つが共通している。

1. 改善の価値をマネージャーが信じている（または黙認している） 改善に使う時間を「意味があるのか」と止められる環境では、Lambda自動化レベルの取り組みは不可能。小粒な改善しか動かせない構造になる。

2. 現場の提案が通る プロセス変更・ツール導入・リファクタいずれも、上に「なぜやるのか」を説明して合意を取るか、少なくとも止められない環境が必要。

3. チームが協力してくれる 「温度感を合わせれば動いてもらえる」という前提がある。バラバラで個人戦になっているチームでは成立しない。

まとめ

記事は「追い込まれたことで動けるようになった個人の成長記録」だが、その背後には改善を許容する組織・チームの前提がある。

前提が揃っていない環境でこの記事を読むと「自分もやってみよう」より「なぜ自分の環境ではできないのか」が先に来る。

取り組みの参考にする前に、自分のチームにどの前提が欠けているかを確認するのが先だと思う。