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

ふつうは、目の前で起きている障害から片づけます。田村屋は最初の1か月を、システム全体の監査に使いました。

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

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

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

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

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

この結果を境に、経営者との関係が変わりました。

その後に必要だったのは、サービスが一時的に止まるかもしれない、より大きな判断でした。開発環境を新しく作ることと、本番へのリリース手順を作り直すことです。田村屋はこのとき、技術用語で説明しませんでした。「開発環境と本番環境が分かれていません」とは言わず、「開発中の未完成な機能がお客様の画面に出てしまう事故が、すでに一度起きています」と伝えました。対策の選択肢ごとに、かかる期間とサービスが止まるリスクを並べ、どれを選ぶかは経営者に委ねました。二つとも承認され、実行されました。

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

開発も、一人に頼らない体制に戻りました。田村屋は必要な技術スタックを採用向けの要件として書き出し、新しく入ったエンジニアが初日から作業できる手順を用意しています。いまは複数人のチームで開発を進めています。

このサービスでは現在、請求業務の自動化とAI機能の開発が進んでいます。守りに使っていた時間を、攻めの開発に回せるようになりました。

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