月額料金が高いだけでは、内製化の対象にならない

外部のSaaS(月額課金で使うクラウドサービス)や外注業務を見直すとき、多くの現場はまず「毎月いくら払っているか」から候補を選びます。しかし私たちが業務現場で観察してきた限り、支出額の大きさそのものは、内製化すべきかどうかを決める良い基準にはなりません。業界ごとに存在する「業界特化型の隙間ツール」、つまり汎用のSaaSでは埋まらない、その業界固有のやり方に合わせた小さな作業の集まりこそが、置き換えの狙い目になります。

英国政府のデジタル調達ガイダンス(Government Digital Serviceの「Define your purchasing strategy」)も、Build(自社で作る)かBuy(既製品を使うか)かを判断する際は、利用者のニーズがどれだけその組織や業界に固有かを最初に見るべきだとしています。逆にいえば、どの業界でも同じように使える汎用的な機能を内製で置き換えても、削減できる金額の割に開発と運用の手間だけが増えることが少なくありません。私たちが最初の選別軸に置いているのは支出額ではなく、この「業界固有性」です。

「隙間ツール」かを見極める四つの問い

では、目の前の業務が本当に内製化に向く「隙間ツール」かどうかは、どう見極めればよいのでしょうか。私たちは現場で次の四つの問いを使っています。

第一に、その業務は例外処理を含めて繰り返されているか。単発の作業であれば、内製の手間に見合いません。第二に、汎用SaaSの設定では埋まらない業界固有の判断が含まれているか。設定変更やプラグインで解決できるなら、既製品のままで十分です。第三に、現場の担当者がその入力・判断・例外処理の中身を自分の言葉で説明できるか。担当者が「なんとなく」でしか説明できない業務は、仕様化そのものが難しく、内製しても属人化が残ります。第四に、内製化した後の責任者と、継続的に改善していく場を社内に置けるか。

この四つのうち、特に効いてくるのが「現場知識が設計に効くかどうか」です。業界の慣習や例外パターンを知っている人が仕様を決められる業務ほど、内製化によって外部の汎用ツールより使いやすいものが作れます。逆に、現場の誰もその業務の背景を説明できない場合は、内製化の前に業務そのものを整理し直す必要があります。

現場知識が曖昧なまま開発に着手してしまうと、既存のSaaSで実現できていた細かな例外処理が抜け落ち、開発後に現場で使われないツールが生まれる原因になります。そのため、担当者が日常の判断理由や例外への対処手順をロジックとして書き出せるレベルまで整理できているかを、必ず事前に確認することが大切です。

比較すべきは月額ではなく、総費用と責任の移り方

候補が絞れたら、次は費用の比較です。ここで陥りやすいのが、「今払っているSaaSの月額料金」と「内製にかかる初期開発費」だけを比べてしまうことです。しかし本来比較すべきは、現状維持・内製化・既存製品の設定変更や乗り換えという複数の選択肢を、初期費用だけでなく移行費用、継続的な改善費用、日々の保守費用、そしてやめるときの停止費用まで含めた総費用で並べることです。

AWSが公開している「Creating a directional business case」というガイドでも、移行や近代化の判断は現状維持との比較を、総保有コスト(TCO、導入から廃止までにかかる費用の合計)や投資回収期間まで含めて具体化すべきだとされています。また、対象が小さな業務であるほど、費用の見積もりに置いた前提の小さなズレが判断全体に大きく影響するとも指摘されています。隙間ツールのように規模の小さな業務ほど、雑な見積もりで進めるのではなく、丁寧に費目を並べる価値があるということです。同時に見るべきなのが「責任の移り方」です。SaaSを解約した瞬間、それまでベンダーが担っていた保守や障害対応の責任は、自動的に社内へ移ります。この責任の所在まで表に含めて初めて、公平な比較になります。

特に見落とされやすいのが、既存ツールからのデータ移行コストや、現場の利用者が新しい操作に慣れるまでの学習コストです。毎月のライセンス料という目に見える費用だけで判断せず、移行に伴う一時的な負荷や運用定着までの費用まで洗い出しておくことで、導入後の想定外の支出を防ぐことができます。

内製化は、運用責任を引き受けられる組織だけが進める

外部SaaSを内製ツールに置き換えるということは、そのSaaSが裏側で担っていたセキュリティ対応や不具合修正の責任が消えるのではなく、そのまま社内に移ってくるということでもあります。米国国立標準技術研究所(NIST)が示すセキュアなソフトウェア開発の枠組み(SP 800-218)でも、開発する側には脆弱性を減らし、影響を抑え、再発を防ぐための取り組みをソフトウェアの開発工程全体に組み込む責任があるとされています。内製化は「タダで自由にできる自社ツールを持つこと」ではなく、こうした責任を丸ごと引き受けることだと捉える必要があります。

さらに私たちが現場で強く感じているのが、社内ツールの重複です。似たような目的の内製ツールが複数のチームでばらばらに作られると、あとから統合しようとしたときの調整コストが跳ね上がります。だからこそ、誰がどの業務領域の内製ツールを持つかという位置づけを、最初の段階で誰かが管理しておく必要があります。責任者、保守にかける時間、セキュリティ対応の体制、データの扱い、そして既存ツールとの重複関係を言葉で説明できない候補は、たとえ魅力的に見えても見送るべきだというのが私たちの判断です。

ツールの役割と担当領域をあらかじめ明確にしておけば、似た機能の重複開発を防げるだけでなく、将来の機能拡張やシステム同士の連携もスムーズに進められるようになります。

最初の一件は、小さく置き換え、次の事業余力をつくる

ここまでの基準を並べると、内製化の検討は重厚な意思決定に見えるかもしれません。しかし実際に動き出すときは、最初から複数の業務を一気に置き換えようとせず、一件だけを選んで小さく始めることを私たちは勧めています。

具体的には、まず候補となる業務を支出額、反復頻度、業界固有性、責任の所在で棚卸しします。次に、その中から代替する範囲とあえて代替しない範囲をはっきり決めた一件だけを選びます。そのうえで、責任者、保守の進め方、うまくいかなかった場合にやめる条件、既存ツールとの関係をあらかじめ決めておきます。そして実際に使い始めたあとは、総費用と現場の負荷を見直し、その結果を踏まえて次に横展開するかどうかを改めて判断します。一度うまくいったやり方をそのまま他の業務へ広げるのではなく、案件ごとに条件を確認し直すことが欠かせません。

内製化によって浮いた時間や予算は、人を減らすためだけに使う必要はありません。私たちは、これを新しい事業や顧客への価値提供に振り向けられる余力として捉えています。SaaSの請求書を見て「高いから作ろう」と考えるのではなく、その業務が本当に業界固有で、現場の知識が生き、社内で責任を持って運用し続けられるかどうか。この判断基準を持つことが、内製化を単なる置き換えではなく、事業の余力を生み出す一手にするための出発点になると考えています。