開発責任者の離脱から、攻めに転じるまで。

普通は、目の前で燃えているものから消します。田村屋は最初の一ヶ月を、全量の監査に使いました。

13のリポジトリとクラウドの全プロジェクトを読み切り、誰が入っても辿れる形の引き継ぎドキュメント40件に落としました。そのうえで、技術の健全度を10のカテゴリ——環境分離、テスト、セキュリティ、可観測性、属人性など——で採点しました。

出た点数は、100点満点で28点でした。

悪い点数を経営者に見せることになります。それでもあえて数字にしたのは、比較できる指標がなければ経営者は技術に投資する判断ができないからです。「危ないです」は判断材料になりません。「28点です。半年で50点まで上げます」なら、投資の話ができます。

監査で最初に見えたのは、誰も使っていないインフラが毎月費用を食い続けていることでした。前任者が去ったあと、止める判断をする人がいませんでした。

田村屋は自分でインフラをコード管理下に取り込み、既存構成との差分がゼロであることを確認したうえで、過剰な分を削りました。削ったあとは本番の全サービスが正常に応答しているかを一つずつ検証しています。インフラ費用は69%下がりました。

ここで、経営者との関係が変わりました。

以降に必要だったのは、もっと大きな——一度サービスが止まるかもしれない——判断でした。開発環境を新しく作ること。本番リリースの経路を作り直すこと。このとき田村屋は技術の言葉で説明していません。「開発環境と本番環境が分かれていない」ではなく、「開発中の未完成な機能が、お客様の画面に出てしまう事故が、すでに一度起きています」と伝えました。対策の選択肢と、それぞれに掛かる期間と止まるリスクを並べ、決めるのは経営者に返しています。二つとも承認され、実行されました。

2026年8月現在、技術健全度は50点。自動テストは0件から1,654件になり、障害を検知する仕組みが入り、インフラはコードで管理されています。

そして開発は、一人に依存しない形に戻りました。田村屋は必要な技術スタックを採用向けに言語化し、新しく入ったエンジニアが初日から動ける手順を用意しています。いまチームは複数人で回っています。

このサービスはいま、請求業務の自動化とAI機能の開発に着手しています。守りに使っていた時間が、攻めに戻りました。

田村屋は、まだ中にいます。