この記事はフリューAdvent Calendar 2025の7日目の記事となります。
はじめに
フリュー株式会社 プリントシール機事業部で開発部門の課長をしている久島です。 バックエンドエンジニア上がりの課長として、現在は3つの異なる目的を持ったチームを見ています。
アドベントカレンダーの記事として、「この1年の取り組み」を書こうかとも思いましたが、ふとこの1年を振り返ったとき、私が最も意識し、そして最も葛藤したのは「いかにして自分がチームの邪魔（ボトルネック）にならないか」という点でした。
元エンジニアであるがゆえに、コードを見れば口を出したくなる。 しかし、課長である私が詳細に介入すればするほど、チームの速度は落ち、自律性は失われる。
そんなジレンマの中で、私がこの1年で「あえて手放した仕事」と、逆に「手放さなかった仕事（課長の役割）」について、自戒を込めて書きたいと思います。
1. 「コードレビュー」を手放した
かつての私は、メンバーの教育目的もあり、プルリクエスト（PR）をかなり細かく見ていました。しかし、2025年前半に、私は意識的に「レビューからのフェードアウト」を決めました。
きっかけは「速度」と「現場への遠慮」
最大の理由は、チームが「教育フェーズ」から「速度優先フェーズ」にシフトしたことです。 私が全てのPRを確認していると、承認待ちの時間が生まれ、私がボトルネックになってしまう。これでは本末転倒です。
また、私の中で一つの「諦め」にも似た感情がありました。 今後ずっとそのコードの面倒を見続けるわけでもなく、手も動かさない私が、たまに顔を出して自分の好みやルールを押し付けるのは、現場の文化を乱すだけで良くないのではないか？ 「薄くしか関わらないのに、口だけ出すのは気が引ける」 そんな、現場に対する遠慮のようなものが生まれたのも事実です。
「見ない」ための物理的な工夫
とはいえ、私も元エンジニアです。変な変数名や、パフォーマンスが悪そうなSQLが見えると、どうしてもコメントしたくなります。 「気になってもコメントしない」のは精神衛生上よくないので、私は「GitHubの通知メールを全て送信しない設定にする」という物理的な遮断を行いました。
現在は、そもそもレビュアーとして指名されること自体が稀になりました。 たまに依頼されたり、気になってコメントする場合も、「これ直して」と断定することは避けています。現場の細かい文脈を追えていない私が断定するのは危険だからです。
代わりに、 「この実装は、〇〇という意図ですか？」 と、確認する形をとっています。あくまで「相談・確認」のスタンスを崩さないようにしています。
2. 「直接の指揮」を手放した
以前は、気になったことがあればメンバーに直接声をかけることもありましたが、最近は「リーダーを通す」ことを徹底しています。
指揮命令系統の統一
各チームの動きやタスク配分は、信頼するリーダーたちの裁量に任せています。私が頭越しにメンバーへ指示を出すと、現場が混乱するからです。 なので、私が求めるエンジニア像（働き方）についても、基本的には「各リーダーのカラーに合わせてくれればOK」というスタンスです。
「雑なフリ」と「プレフィックス」の活用
その代わり、リーダーへの相談は頻繁に行います。 私は思いつきで「これ確認できる？」とボールを投げることが多い（自覚があります）ので、それが現場への無言の圧力にならないよう、Slack等のコミュニケーションでは以下のような工夫をしています。
- プレフィックス（接頭辞）の付与:
【相談】: 決定事項ではなく、壁打ちがしたい時。【不急】: 今のスプリントに入れなくていい、いつか見てくれればいい時。
そもそも私から期限を指定することは稀です（上長から期限付きで降ってきたもの以外）。 いつやるか・やらないかの判断も含めて、チームの状況に合わせてよしなにハンドリングしてもらえればと思っています。
3. 手放さなかったもの：説明責任と「財布」としての役割
では、コードも指揮も手放した私が何をしているかというと、主に「外部との接続（政治・予算）」です。
上司への「翻訳」
私はメンバーに対し、細かい報告よりも「私が部長や事業部長に説明できるだけの材料（ロジック）」を求めます。
例えば、「新しい開発支援ツール（AIコーディングアシスタント等）を追加で導入したい」という提案があったとします。 すでに似たようなツールがある場合、会社としては「既存のもので十分ではないか？」「なぜ二重にコストをかけるのか？」という疑問を持ちます。
私は別に、新しいツールの導入を反対したいわけではありません。 予算を通すための「既存ツールとの使い分け」や「追加コストに見合う効果」さえ、私が上層部に説明できるようにインプットしてくれればそれでいいのです。 その「説明責任」さえ果たしてくれれば、私はすぐに承認を出します。
都合の良い「財布」として
正直なところ、自分の仕事に対して「いい仕事をした！」という誇りはあまりありません。 オブザーバビリティツールの導入や、監視体制の構築など、予算確保や決裁は行いましたが、実際に手を動かして導入・運用しているのはSREチームのみんなです。 私は彼らが走るための道路を舗装した（お金を引っ張ってきた）に過ぎません。
ただ、新しい技術的な挑戦（特にAWS等のクラウドインフラ関連）については、コストを理由に頭ごなしにNOと突き返すことはありません。 「何か試したい」という前向きな提案があれば、どうすれば会社のルール内で実現できるか、予算を通せるかを一緒に考えるようにしています。
私のことは「開発のための便利な財布兼・防波堤」として使い倒してくれればいいと思っています。
おわりに
これらの仕事を「あえて手放した」結果、どうなったか。 正直なところ、私がいなくても（むしろいない方が）、チームは自律的に、かつ高速に回り始めています。
寂しさがないと言えば嘘になりますが、リーダーたちが私の想像を超えて成長し、メンバーが生き生きと開発している姿を見るにつけ、「手放して正解だった」と安堵すると同時に、彼らの自走力に助けられています。
私は完璧なマネージャーではありませんし、日々反省の連続です。 しかし、現場の「How（どう作るか）」を手放した分、これからはより一層「Environment（どう守り、どう投資するか）」という、課長本来の役割にコミットしていくつもりです。
そんな、「技術への未練」と「マネジメントの責任」の間で揺れ動く課長を、メンバーがうまくコントロールしてくれている現状に感謝しつつ、これからも彼らが走りやすい環境を作っていければと思います。
