SaaS の技術診断とロードマップ

課題は、現場が一番よく知っていた

この SaaS では大手企業への導入が増えるにつれ、初期の設計のまま運用してきた箇所が、同時アクセスの増加や顧客ごとの環境の違いに耐えきれなくなりつつありました。現場のエンジニアは問題に気づいていたものの、改修の優先度を経営に認めてもらえずにいました。

現場は気づいている。でも、いまの新機能開発を止めて直せと言える材料がない。

大手向けの SaaS でよく見られる構図です。新機能のリリース速度、利用者増への備え、既存顧客と約束したサービス品質（SLA）。このすべてを同時に満たそうとするうちに、技術的負債の解消だけが後回しになります。直せる人は社内にいるのに、直す根拠が経営に届かない状態が続いていました。

Kmetric が参画した時点で問われていたのは、直すかどうかより、直す優先順位を経営判断として通すための材料を作れるかでした。

「課題リスト」だけでは、経営会議を通らない

多くの技術診断は「課題リスト」を提出して終わります。しかし課題リストのままでは、経営会議でほとんど承認されません。読み手が開発リーダーから経営層に移ると、なぜその順番で直すのかという根拠が抜け落ちるからです。

診断レポートを経営会議で取り上げてもらうには、各課題について次の三点を書き揃える必要があります。

• 何が起きるか：同時接続数の上限、リリース時のサービス停止、顧客ごとの個別対応コスト
• いつ顕在化するか：売上が何倍になった時点で限界に達するか、既存顧客の契約更新の時期
• その時点で損益にどれだけ響くか：失う既存契約・取りこぼす新規契約・対応にかかる人件費の合計

三つ目まで書き切らない限り、技術的負債の解消は経営会議の議題に上がりません。損益への影響額と時期が示されていない技術リスクは、いつまでも後回しにされます。

課題は、仕組み同士のつなぎ目に集まっていた

問題は、システムを構成する個々の仕組み（サブシステム）の内側より、そのつなぎ目に集まっていました。そのため診断も、サブシステムごとに区切らず横断して進めました。

診断の対象は、クラウド上で複数のソフトウェアが連動して動く運用基盤の全体でした。それぞれ単独では問題なく見えても、つながっている別の仕組みからの使われ方が変わると、処理が滞る箇所が出てきます。

11ヶ月の伴走で、ロードマップを実行に移す

診断レポートを納めたあとも、改修フェーズの最初の11ヶ月を継続して支援しました。診断で描いたロードマップを、実行に移すところまで責任を持つためです。

• 診断レポートと実行ロードマップを納品
• 11ヶ月の改修支援を継続

顧客に影響を出さずに、改修と診断を並行して進めること。これが、成長期の SaaS で改修をやり遂げる条件でした。稼働中のプロダクトの上で運用チームと一緒に改修を進めたことで、机上の計画が、現場で実行できる計画に変わっていきました。

技術的負債がいつ・どれだけ損益に響くかを示したとき、経営ははじめてその解消を決断できる。