ID:83154さん

エンジニアとWebディレクター計11名のチームと、大手企業との協業で展開するふるさと納税サイトなど計6プロダクトの開発・保守を、課長（プレイングマネージャー）として統括しています。2024年5月から課長の業務を担い、同年12月に正式に就任しました。 担当は、1on1、半期ごとの目標設定と評価、採用、開発プロセスと開発基盤の設計です。設計や実装も自分で手を動かしています。

「メンバーが迷わず開発に集中でき、自律的に成長できる状態」をつくることを目標にしています。 具体的には、年末の繁忙期でもシステムを止めずに、技術負債を少しずつ返していくこと。誰が担当しても同じ手順で品質を確かめられること。ディレクターとエンジニアの間で、仕様の手戻りを減らすことです。 指示を出すときは、何をやるかだけでなく、なぜやるのかも伝えるようにしています。メンバーが目的を分かったうえで、自分で判断できるようにするためです。

■ 進め方の基本 依頼を受けたときは、まず目的を聞きます。目的が分かっていれば、言われた方法をそのまま作るだけでなく、別のやり方も提案できるからです。仕組みを作るときは、まず1つのプロジェクトで自分が使い、1〜2人に試してもらって意見を聞き、調整してから全体に広げます。自分にとって使いやすいものが、ほかの人にも使いやすいとは限らないので、この順番で進めるようにしています。 ■ 品質 当時はバージョン管理がSVNのままで、レビュー文化・コーディング規約・テストを書く文化がありませんでした。課の全プロダクトをGitへ移し、MRレビューの手順を決めたうえで、MRごとに自動検査が走る品質ゲートを整備しました。あわせて課標準のLaravelテンプレートとテストの書き方のルールを用意し、新しく立ち上がった4リポジトリは、すべて最初から品質ゲート付きで動いています。 ■ ディレクターとエンジニアの手戻り ディレクターの要件定義の精度が上がらず、開発の段階で手戻りが起きていました。GitHub Copilotのプロンプトテンプレート13本で仕様定義を標準化し、ディレクターの声を聞いて直してから課の全プロダクトに配布しました。その結果、ディレクターが単独でイシューを起票できるようになりました。その後のClaude Codeの開発ループも同じ順番で配布し、時間の配分は要件定義が約7割・開発が約3割に変わっています。 ■ TiDB移行の合意 年末のアクセス集中でDBが止まるリスクに対し、アプリ改修とDBレイヤー刷新を比較して、TiDBへの移行を立案しました。クライアントと航空会社グループのIT統括部門に工数とリスクの比較を示して承認を得て、移行後の年末繁忙期はダウンタイムゼロで乗り切りました。 ■ 組織と採用 全メンバーと個別に面談して課題感を聞き、何が問題かをチームでそろえました。顧客別に分かれていたチームの情報共有は、週1の朝会で横断化しました。採用は38名の選考に関わり、エンジニア3名・ディレクター1名を採用し、4名とも定着しています。 現在は、顧客ごとの固定チームから、イシュー単位で担当を割り振るリソースプール制への移行を設計しています。評価に指標を使う場合は数字だけを追う動きが出る前提で、半期ごとに見直す仕組みを組み込んでいます。