システムをミニマムに保つ意思決定の重要性

大きな組織の構成が、そのまま自社の正解とは限らない

マイクロサービスや、フロントエンドとAPIを分けたSPA構成は、有力な選択肢として広まりました。複数チームが独立して開発・リリースしたい場面や、画面上の複雑な操作を実現したい場面では、その利点があります。

ただし、両者は別の設計判断です。SPAは画面の構成、マイクロサービスはサービスの分割に関わるもので、必ず組み合わせるものでも、大人数専用の技術でもありません。

少人数で一つの事業を育てている段階で、独立したサービスやデプロイ先を増やすと、連携、認証、監視、障害の切り分けまで自分たちで担う必要があります。Martin Fowlerも2015年に、マイクロサービスには分散システムとしての追加コストがあると指摘しています。

まずは一つのアプリケーションの中で責務を分ける。独立した運用や拡張が必要になった部分から切り出す。そうした進め方も、十分に合理的です。

土台を積むほど、更新時に確認する範囲が広がる

たとえばReactにNext.jsを組み合わせると、ルーティングや描画、ビルドなどをまとめて扱えます。自前で実装する部分を減らせる一方、React、Next.js、周辺パッケージ、Node.jsの互換性と更新状況を確認する必要も生まれます。

脆弱性対応では、単にバージョンを上げるだけで済むとは限りません。修正版がどの依存経路に入るか、既存機能が壊れないか、本番まで反映できたかを確かめます。直接導入していない、依存先のさらに先にあるライブラリも対象です。

未更新の機能が外部から呼び出せれば、攻撃の入口になる可能性があります。ただし、依存の数や層の深さだけで危険度は決まりません。OWASPも、悪用可能性・公開範囲・影響を踏まえた優先順位付けを勧めています。公開時にサーバーで実行する機能と、ビルド時だけ使う機能では、確認すべき経路も異なります。

ミニマムにするのは、保守する対象

依存を減らすために、認証や暗号処理まで自作すればよいわけではありません。実績のある仕組みに任せることで、実装ミスや保守負担を減らせる場合もあります。

見直したいのは、使っていない機能、役割が重複するライブラリ、理由の曖昧なサービス分割です。記事を配信するだけなら静的出力で足りないか。単純な管理画面に、独立したフロントエンドとAPIが必要か。データベースやキューを追加する前に、今ある構成で要件を満たせないか。

一方で、認証、権限制御、バックアップ、必要な監視まで削るべきではありません。小さく保ちたいのは、事業価値につながらず、管理の手間だけが残る部分です。

採用する前に、維持できるかを決める

新しい技術やサービスを加えるときは、次の3点を確認します。

AIでコードを書きやすくなっても、増えたシステムを維持する責任は残ります。作れることと、持ち続ける価値があることを分けて考える。システムをミニマムに保つのは、そのための継続的な意思決定です。