アーキテクチャと技術的負債

EM はアーキテクチャの細部を決める立場ではありませんが、システムの形とチームの形はつながっているので、全体像は説明できるようにしておきます。

間をとるモジュラーモノリス（1つのアプリのまま、中を機能の境界で分ける）から始め、チームが増えて境界がはっきりしてから切り出す、という進め方がよくとられます。「マイクロサービスにすれば速くなる」とは限らず、運用の土台がないまま分けると障害の調査がかえって難しくなります。

チームの分け方とコンウェイの法則

技術的負債とは、早く出すために後回しにした設計やコードの問題で、放っておくと「利子」として開発の遅れや障害が増えていくものです。負債をゼロにすることは目指しません。大事なのは、見える化して、影響の大きいものから計画的に返すことです。

負債の一覧と見積もり

チケットやスプレッドシートに「負債の台帳」を作り、次の項目を書きます。

優先順位は「利子の大きさ ÷ 返すコスト」でざっくり決めます。上の例なら、10人日の投資で月2人日が浮くので、約5か月で元がとれます。返し方は3通りを組み合わせます。

• 毎回一定の割合：スプリントの一部（例えば 15〜20%）を負債の返済に充てると決めておく。割合はチームで決める。
• ついでに直す：機能を作るとき、触る場所の周りだけ整える。
• プロジェクトにする：大きな移行（言語やフレームワークの更新など）は、ロードマップに正式に載せる。

負債の返済を事業の言葉で説明する

「コードが汚い」「リファクタリングしたい」では、事業側には伝わりません。時間・お金・リスクの言葉に直し、返さない場合に何が起きるかも並べます。

提案の形

• 投資と回収：「10人日で、月2人日が浮く。約5か月で元がとれる」のように示す。
• 選択肢：今やる・次の四半期にやる・やらない、のそれぞれで何が起きるかを並べる。
• 報告：終わったら約束した数字が改善したかを報告する。次の投資の合意がとりやすくなる。

数字は完璧でなくてかまいません。前提を書いて「ざっくりこのくらい」と示すほうが、何も示さないより判断の材料になります。

古いシステムを作り直すとき、全部を作り終えてから一度に切り替えると、途中で価値が出ず、切り替えの失敗も大きくなります。入口で振り分けながら機能を1つずつ移すストラングラーフィグ（絞め殺しの木。古い木に巻きついて育つ植物にちなむ）がよく使われます。

EM が気をつけるのは、移行中は新旧2つを運用する期間になることです。オンコールや問い合わせの負担が一時的に増えるので、計画に入れておきます。「最後の2割」が残り続けないよう、古い側を止める日もロードマップに載せます。

データは、アプリのコードと違って壊れると元に戻せないことがあります。EM は DB の細部まで知らなくても、次の点は設計レビューや計画で必ず確かめます。

特に「バックアップはあるが、復元を試したことはない」は、障害のときに初めて復元できないと分かる典型です。半年に1回など、復元の訓練を計画に入れます。

SRE の「DB運用」

アプリは多くのライブラリやランタイム（言語の実行環境）に依存しています。更新を後回しにすると、脆弱性が見つかったときにすぐ直せない、サポートが終わった版で動き続ける、といったリスクになります。

EM は、こうした作業が「誰の仕事でもない」状態にならないよう、計画の中に時間を確保します。サポート期限は事業側にも分かる言葉で伝えやすく、負債の返済の説明にも使えます。