自前で作ってよい業務システムの見分け方｜データの更新頻度で考える

こんにちは、株式会社TIMEWELLの濱本 隆太です。

高額なSaaSを解約して自社で作り直す、というテーマの5本シリーズの2本目です。1本目の判断基準の記事では、解約を考えるときに見る項目を並べました。今回はその手前の問いを扱います。社内で使っている数十のSaaSのうち、どれから作り直しの候補にすればよいのか。

私の見立ては単純で、データの更新頻度が低いものから、です。契約の台帳、社内FAQ、社内ポータル、備品や購買の申請、見積の台帳。こうした仕組みは項目の形がめったに変わらず、1日に書き込まれる件数も多くありません。生成AIで開発の手間が下がった今なら、自前で作って持っても困りにくくなった、と感じています。

ただ、この言い方には落とし穴があります。業務システムを変化の速さで分ける代表的な枠組みはガートナーのペースレイヤーですが、その原典を素直に読むと、変化の遅い基幹系こそ標準パッケージで持つのが基本、という結論になります。「遅いから作れる」とだけ言えば、原典と逆のことを言ってしまいます。そこで今回は、変化の速さにもう1本、重さ（複雑さ、取引量、法令対応）の軸を足して業務を4つに振り分けます。台帳やFAQのように遅くて軽いものは自前の候補、会計や給与のように遅いけれど重いものは引き続きSaaS、という書き分けです。業務別の早見表も付けました。

先に断っておくと、データの更新頻度で作るか買うかを分ける公的な枠組みは、調べた範囲では見つかりませんでした。2軸の整理は当社の見立てです。当社がFDEとして現場に入るときも、この順番で候補を選んでいます。

SoR、SoE、SoI、ペースレイヤー。まず言葉をそろえる

業務システムを性質で分ける言葉には、主に3つの出どころがあります。

いちばん古いのは、米国の経営コンサルタント、ジェフリー・ムーアが2011年の白書で示したSoR（Systems of Record、記録のシステム）とSoE（Systems of Engagement、つながりのシステム）です。ムーアはSoRを、企業が過去数十年にわたって業務プロセスを載せてきた道具やデータの置き場所、システムだと説明しました。SoEは、そのSoRへの大きな投資の上に重なり、Webからの利用、さまざまな端末での使いやすさ、組織をまたいだ協働を提供するもの、という位置づけです¹。会計や受発注の記録を正しく残すのがSoR、社員や顧客とのやり取りの場になるのがSoE。そう覚えておけば、大きく外すことはないでしょう。

2015年には、米調査会社Forresterのブライアン・ホプキンスがSoI（Systems of Insight、洞察のシステム）を加えました。データから洞察を取り出し、それを一貫して効果的な行動に変えるための、業務上の規律と技術という定義です²。SoRにたまった記録とSoEで起きたやり取りを、判断や行動につなげる層だと考えてください。

ペースレイヤーは、これらと切り口が違います。ガートナーが2012年2月に発表した枠組みで、アプリケーションを変化の速さで3つの層に分けます³。1層目のSoRは、中核の取引処理を支え、組織の重要なマスタデータを管理する、確立したパッケージか昔からの自社開発システムです。変化の速さは低く、その理由を原典は、プロセスが確立していて大半の組織に共通であり、規制要件の対象になることも多いから、と書いています。2層目のSystems of Differentiation（差別化のシステム）は、その会社独自のプロセスや業界固有の機能を支える層で、寿命は1〜3年と中くらい、業務のやり方や顧客の要求に合わせて頻繁に設定を変える必要があります。3層目のSystems of Innovation（革新のシステム）は、新しい要求や機会に応えるためにその場で作られ、0〜12か月で役目を終える層です。

ムーアのSoRとガートナーのSoRは名前が同じでも、軸が違います。ムーアは役割（記録か、つながりか）で分け、ガートナーは変化の速さで分けています。「SoR SoE 違い」で検索すると両者が混ざった説明によく出会いますが、作るか買うかを考えるときに効くのは、ガートナーの速さの軸のほうです。

日本でもこの言葉は定着しています。経済産業省が2024年9月の第1回レガシーシステムモダン化委員会で示した資料は、基幹系システム（SoR）のデータがフロント系（SoE）やデータ分析・洞察の領域（SoI）にも活用されうると整理し、フロントのサービスはクラウドの浸透とともにSaaSなどの活用が進む、と書いています⁴。ITパスポート試験のシラバスにも、SoRとSoEが用語例として載っています⁵。

原典を素直に読めば「変化の遅いものほど買う」

ここで、冒頭の見立てとぶつかります。原典はSoRを、確立したパッケージか昔からの自社開発システムと定義したうえで、中核の業務を支える環境には安全さと費用対効果を求めています³。この定義に沿えば、変化の遅いSoRは大半の組織に共通だからこそ、各社が作るより、多くの会社で費用を割り勘にできる標準パッケージで持つのが合理的です。更新頻度が低いから自前で作れる、という主張は、原典をそのまま読むと逆向きになります。

国内の公的な指針も同じ方向を向いています。経済産業省のDXレポート2（2020年12月）は、企業は協調領域については自前主義を排し、業務プロセスの標準化を進めることでSaaSやパッケージソフトウェアを活用すべきだ、と書きました⁶。デジタル庁が2025年5月に改定した政府情報システムのクラウド利用の基本方針（DS-310）は、SaaSは開発量削減の観点から幅広く優先的に利用を検討すること、とし、「作らないアプローチを徹底させる」という項目まで立てています⁷。先ほどのモダン化委員会の資料にも、新しいシステムやSaaSに業務を合わせて載せ替えるFit to Standardの重要性が書かれていました⁴。

企業の実態もそうなっています。IPAの「DX動向2025」によると、ノンコア事業・非競争領域のソーシング手段として、日本企業はパッケージソフトウェアの導入が33.8%、SaaSの導入が24.4%で、内製による自社開発は16.6%でした。同じ設問で米国は内製が40.1%、SaaSは11%です⁸。業務の周辺部分をSaaSとパッケージで賄ってきたのが、日本の企業の姿だと言えます。

では、原典と公的指針を踏まえたうえで、それでも「遅いものから作れる」と言える余地はどこにあるのか。手がかりは同じDS-310の中にあります。DS-310はSaaSを強く推奨しながら、無条件に推奨されるわけではない、と念を押しています。利用者数が段階的に増える見込みの場合など、運用段階でSaaS利用料が高額になるケースがあるので、ライフサイクルコストの観点から本当にコスト削減効果が出るかを慎重に評価する必要がある、という書き方です。SaaSと同様の機能を他のマネージドサービスで実現できるなら両方式を比べて評価すべきだ、とも書き、アカウント数に対して課金されるSaaSや高額なSaaSには特に注意するよう求めています⁷。そのうえで同じ文書は、開発への生成AIの活用も求めています。

政府の指針自身が、SaaSを選ぶ理由と、選ばない場合の条件を並べて書いているわけです。私は、この例外の書き方に見分けの鍵があると考えています。

変化の速さに「重さ」の軸を足す

ガートナーがSoRの変化が遅い理由として挙げたものを読み直すと、2つあります。大半の組織に共通であること。そして、規制要件の対象になることが多いこと。どちらもパッケージを選ぶ理由になりますが、性質はまったく違います。

「共通だから買う」は、開発費を割り勘にする理屈です。同じものを100社が別々に作るより、1社が作って100社に売るほうが安く済みます。この理屈は、作る費用が高いほど強く効きます。生成AIで開発の手間が下がると、単純な仕組みほど割り勘の得は小さくなり、利用者の数に比例して毎月払い続ける費用のほうが目立ってきます。

「規制の対象だから買う」は、法令の変化を追いかける費用を割り勘にする理屈です。こちらは生成AIを使ってもほとんど縮みません。改正を読んで計算の仕様に落とし、期日までに試験を終え、間違えたときには責任を負わなければなりません。どれも、コードを書く速さとは別のところにある仕事です。

そこで私は、変化の速さの軸に、重さの軸を足して考えています。変化の速さは、データの更新頻度を2つに分けて測ります。1日に何件の記録が書き込まれるか。項目や画面やルールを年に何回変えたいか。重さは3つで見ます。計算や例外の複雑さ。取引量（件数、同時に使う人数、止まったときに止まる業務）。法令対応（外から変更を迫られる頻度と、誤ったときの責任）。

	軽い（単純、少量、法令が薄い）	重い（複雑、大量、法令が厚い）
変化が遅い	① 自前の候補（台帳、社内FAQ、社内ポータル、申請、見積の台帳）	② SaaSやパッケージを続ける（会計、給与、基幹が参照する正本のマスタ）
変化が速い	③ 作って、役目を終えたら捨てる（試作、一時的な集計、キャンペーン）	④ 体制を組んで判断する（顧客向けのサービス、CRMの中核、生産計画）

ガートナーの3層と重ねると、②は原典どおりのSoR、③はSystems of Innovation、④はSystems of Differentiationにおおむね当たります。①は原典ならSoRに入る仕組みですが、パッケージを選ぶ理由のうち「共通だから」の片方しか残っていない領域です。生成AIで作る費用が下がったとき、最初に損得がひっくり返るのはここだ、というのが当社の見立てです。

研究の数字も、この線引きとは矛盾しません。GitHub Copilotを使った群が、JavaScriptでHTTPサーバーを実装する課題を55.8%速く終えたという2023年の実験は、小さく仕様のはっきりした課題でした⁹。一方、METRが2025年に行った無作為化比較試験では、平均でスター数2万2,000超、100万行超の大規模なオープンソースのリポジトリに何年も貢献してきた経験豊富な開発者16人が、AIを使える条件のほうで課題に19%長くかかりました。本人たちは事前に24%速くなると予想し、終わったあとも20%速くなったと感じていたそうです¹⁰。METRは2026年2月に、2025年末のツールでは所要時間が18%短くなったという推計を出しましたが、信頼区間はマイナス38%からプラス9%で0をまたいでおり、参加者の選ばれ方の偏りで本当の効果が見えにくい、と自ら注記しています¹¹。GoogleのDORAの2025年の報告も、AIの利用は開発の処理量とは正の関係、配信の安定性とは負の関係にあるとし、AIはチームを直すのではなく、すでにあるものを増幅する、とまとめました¹²。

小さく単純なものでは速くなり、大きく込み入ったものでは速さも安定も保証されない、というのが私の読みです。①が作りやすく、②と④で慎重になるべき理由は、ここにあります。

以前、AIの内製化はどこまで自社でやるかの記事で、変更の頻度が高いものほど内側に置く、と書きました。今回と逆に聞こえるかもしれませんが、問いが違います。あちらはプロンプトや確認手順のような「調整を誰が持つか」の話で、調整のたびに外へ発注していると改善が止まる、という理屈でした。今回は「月額を払い続けるか、一度作って持つか」の話です。変化の遅い仕組みは、作ったあとに触る回数が少ないので、作る部分に外の力を借りても、持ち続ける負担は小さく済みます。二つを合わせると、変化の速い調整は社内で持ち、変化の遅い器は安く作って持つ、という分担になります。

業務別の早見表

具体的な業務に当てはめます。下の表は、一般的な会社を想定した当社の目安です。

業務	変化の速さ	重さ	判定	判断の分かれ目
社内FAQ、ナレッジ	遅い。記事の追加は週に数件、項目はほぼ固定	軽い	① 自前の候補	部署ごとに見せる範囲を分ける必要があるか
社内ポータル（お知らせ、規程、リンク集）	遅い	軽い	① 自前の候補	既存のグループウェアと二重管理にならないか
契約、備品、資格などの台帳	遅い	軽い	① 自前の候補	電子の契約書そのものを保存するか
稟議や購買の申請と承認	遅い。承認経路の見直しは年に数回	軽い〜中	① 自前の候補	例外の経路がいくつあるか、会計へ仕訳を渡すか
見積の台帳（番号、履歴、案件とのひも付け）	遅い	軽い	① 自前の候補	見積の計算そのものが競争力になっていないか
経費精算	書き込みは毎月、全員	重い（インボイス、電子帳簿保存法）	② SaaSを続ける	申請の入口だけ自前にする手はある
勤怠管理	書き込みは毎日、全員	重い（全員が毎日使い、給与計算につながる）	② SaaSを続ける	打刻の入口だけ自前にする手はある
会計	形は遅いが、仕訳は毎日	重い（税制、インボイス）	② SaaSを続ける	周辺の台帳から仕訳データを渡す
給与計算	月次。ルールは毎年のように変わる	重い（税制の改正、年末調整）	② SaaSを続ける	―
品目、取引先などの正本のマスタ	遅い	重い（基幹が参照する）	② 基幹側で持つ	自前の台帳は正本を読むだけにする
分析のダッシュボード、試作	速い	軽い	③ 作って捨てる	使い終えたら消す決まりがあるか
顧客管理（CRM）の中核	速い	中〜重（営業全員、他システムとの連携）	④ 体制を組んで判断	周辺の台帳だけを切り出せないか

①に並んだ業務は、どれもすでにSaaSで賄われていることの多い領域です。総務省の令和7年通信利用動向調査では、クラウドサービスを使っている企業のうち、利用しているサービスとして「社内情報共有・ポータル」を挙げた割合が61.4%で、「ファイル保管・データ共有」の73.3%に次ぐ2番目でした。「給与、財務会計、人事」も56.3%あります¹³。前者は作り直しの候補になりうる大きな母集団で、後者はそのまま払い続けたほうがよい領域、というのが今回の整理です。

②に会計と給与を置いた理由は、法令の改正の頻度にあります。日本では、2023年10月1日にインボイス制度が始まりました¹⁴。2024年6月からは定額減税が給与の源泉徴収で実施され、給与の支払者は源泉徴収税額の計算で対応を求められました¹⁵。2025年12月の年末調整では、令和7年度税制改正による基礎控除や給与所得控除の見直しへの対応が必要になりました¹⁶。およそ2年のあいだに、期日つきの変更が少なくとも3回来ています。SaaSの事業者は、この追いかけを全顧客分まとめて引き受けています。自前で持てば、改正を読み、仕様に落とし、期日までに試験する人を自社で抱えることになります。AIで縮むのはこのうち実装の部分だけで、読むことと責任を負うことは縮みません。

表の判定は出発点にすぎません。ガートナーも、同じアプリケーションでも使い方と事業モデルとの関係によって会社ごとに違う層に分類されうるし、成熟するにつれて層の間を移っていく、と書いています³。見積が分かりやすい例です。番号と履歴を管理するだけの見積の台帳なら①ですが、図面と工程から原価を積み上げる製造業の見積なら、計算そのものが競争力で④に当たります。同じ「見積」という名前でも、どこに置くかは会社によって変わります。

会計や人事労務も、まるごとSaaSに置く必要はない

早見表で会計、給与、勤怠を「SaaSを続ける」に置きましたが、正確に言えば、SaaSに残すのは原本と法定の処理です。会計や人事労務のSaaSの中には、法令が決める部分と、自社が決める部分が同居しています。自前にしてよいのは、自社が決める部分です。

業務	SaaS（または専門家）に残す部分	自前にしてよい部分
会計	仕訳の原本、決算、税務申告、電子取引データの保存	経費申請の入口、予算の管理、管理会計の集計と画面
人事労務	給与計算、社会保険と雇用保険の手続き、年末調整、マイナンバーの管理	評価、目標、研修、入社手続きの案内、社内の申請画面
見積と請求	請求書の発行、入金の消し込み、取引書類の保存	見積の計算の仕方、単価表、案件と見積の台帳

形としては、全社員が触る画面を自前で作り、データは会計や人事労務のSaaSにAPIで渡します。SaaSの画面を開くのは経理や人事の担当者だけになるので、ほかの社員の分のシートが要らなくなることがあります。利用者の数に比例して請求が膨らむアカウント課金のSaaSほど、この形の効き目は大きくなります。ムーアの言葉で言えば、SoRには手を付けず、その上に自社のSoEを重ねる形です¹。

見積は、とくにこの形に向いています。インボイス制度の要件がかかるのは請求書などの側で¹⁴、見積書で主に問われるのは、電子で受け渡したときの保存の要件です¹⁷。そして見積の出し方は、単価の決め方も値引きの考え方も会社ごとに違います。前の節で書いたとおり、製造業の見積なら計算そのものが競争力です。請求と入金の消し込みはSaaSに残し、見積を作るところは自前で持つ。この分け方が現実的だと考えています。

一つ注意があります。SaaSやパッケージの契約の中には、ライセンスを持たない人にAPIや連携を通じて間接的に使わせることを、有償とする条項を置いているものがあります（間接アクセスやマルチプレクシングと呼ばれます）。画面を自前にしてシートを減らす前に、契約書でこの条項を確かめてください。条項があれば、減らせるシートの数は変わります。

当社も、社内ポータルでは会計SaaSのデータをAPIで読み込んで表示し、仕訳の原本は会計SaaSの側に残しています。

軽く見えて重いものを見分ける

①に見えても、作る前に確かめたいことが5つあります。どれも、見た目の単純さの裏に重さが隠れているケースです。

1つ目は、電子の書類そのものを保存するかどうか。国税庁によると、書面なら保存が必要な注文書、契約書、見積書、請求書などに相当する電子データを受け取ったり渡したりした場合、その電子データの保存が義務づけられています。原則として、改ざん防止の措置、確認用のディスプレイなどの備え付け、日付・金額・取引先の3つの要素で検索できること、の3つが求められます¹⁷。契約の台帳が「どの契約がいつ切れるか」を管理するだけなら軽いままです。電子の契約書の保存場所も兼ねるなら、訂正や削除の履歴を残す作りが要ります。作れないわけではありません。最初から要件に入れるかどうかで、あとの手戻りがまるで変わります。

2つ目は、その台帳が正本かどうか。ガートナーの定義では、組織の重要なマスタデータを管理するのはSoRの役目です³。品目、取引先、勘定科目のように、会計や受発注が参照するマスタを自前の台帳に移すと、①のつもりで②を抱え込むことになります。自前の台帳は正本を読むだけにして、書き込みは基幹側に残すほうが安全です。

3つ目は、権限の細かさと、社外の人が使うかどうか。2023年のセキュリティの国際会議ACM CCSで発表された実験では、AIアシスタントを使えた参加者は、使えなかった参加者より安全でないコードを書き、しかも自分のコードは安全だと考えがちでした¹⁸。当時のモデルでの結果ですが、ログイン、権限、監査の記録は、AIに毎回ゼロから書かせる場所ではないと私は考えています。検証済みの共通の土台に載せるべきです。取引先が使うポータルのように社外に開くなら、重さの判定を一段上げてください。

4つ目は、止まったときに何が止まるか。社内FAQが半日止まっても業務は回ります。出荷の指示に使う台帳が止まれば、出荷が止まります。書き込み件数が少なくても、止まったときの影響が大きいものは重い側に置きます。

5つ目は、持ち続ける人がいるかどうか。IPAの同じ調査で、内製化を進めている日本企業が挙げた課題の1位は「人材の確保や育成が難しい」で、82.3%でした⁸。作る費用が下がっても、項目を足し、利用者の問い合わせに答え、年に数回の変更を入れる人がいなければ、持ち主のいないアプリが一つ増えるだけです。DORAの言う「すでにあるものを増幅する」は、持ち手のいない組織では、持ち手のいない状態のほうを増幅します。

この5つを通ったものに、順番をつけます。当社がすすめている棚卸しの手順は次のとおりです。

1. 使っているSaaSの一覧に、1日の書き込み件数、過去1年に項目やルールを変えた回数、関係する法令、連携している他システムの数、利用者数と課金方式の5列を足す
2. 変化の速さと重さで、①から④に置く
3. ①の中から、アカウント課金で利用者の増加とともに費用が膨らむものを先に選ぶ（DS-310が特に注意を促している類型です⁷）
4. データを持ち出せるか、形式と手順を確かめる（SaaSの解約と移行の実務）
5. 作って持つ場合と払い続ける場合の5年総額を比べる（SaaSの5年総額の試算）
6. どこに置くかを決める（業務アプリを自社クラウドに置く設計）

手順1の5列は、請求書と各SaaSの管理画面、それに現場への短い聞き取りで埋まる項目だけにしてあります。手順3の時点で候補が1つか2つに絞れていれば、上出来だと思います。

受託開発との違い

①の仕組みを作ると決めたとき、誰に頼むかで結果が変わります。

受託開発で①を作ると、会社ごとに台帳やFAQをゼロから作り、かかった工数で請求するのが普通です。ところが①の仕組みは、会社が違っても骨格がよく似ています。ログインと権限、変更の履歴、検索、承認の段。違うのは項目の名前と承認経路くらいです。骨格を毎回作り直せば、その工数は顧客が毎回払うことになります。

当社のFDEは、この骨格を製品側の共通の仕組みとして持ち、顧客ごとに違う項目や承認経路だけを、その会社の設定として置きます。現場で見つけた共通の型は製品に返すので、次の会社ではその分だけ早く、安く作れます。だから当社にとって現場の工数は、売上ではなく投資です。1社あたりの工数は、減るほど良いのです。終わり方も違います。検収で終わるのではなく、担当者が自分で項目を足し、承認経路を変えられるようになった時点で終わります。当社がいなくても回る状態が、完成です。

この形は、経済産業省がDXレポート2で予想した関係に近いと考えています。同レポートは、ユーザー企業が内製へ移る過程では社内の人材ではすぐに対応できないことが多く、ベンダーが内製への移行を支援し、伴走しながらスキルを移すことへのニーズが高まる、と書きました。そしてそれを客先常駐のビジネスにせず、共に育て（共育）、共に作る（共創）関係にすべきだ、としています⁶。①の作り直しは、この関係を小さく試すのにちょうどよい大きさです。

当社のFDEでできること

当社のFDE（Forward Deployed Engineer、顧客の現場に入って課題を動くソフトウェアにするエンジニア）が、SaaSの作り直しで引き受ける範囲を書きます。

まず、棚卸しに同席します。SaaSの一覧と請求書を一緒に見て、前の節の5列を埋め、①から④に置きます。作らないほうがよいものも、この段階ではっきりさせます。②に置いたものは、作り直しの対象から外します。

次に、①から1つだけ選び、初日に、個人情報などを伏せた実際のデータで動く試作を見ていただきます。一度に複数を置き換えることはしません。期間は45〜90日で、終わりの条件（担当者が自分で項目を足し、承認経路を変えられること、など）を最初に決めます。費用は工数の積み上げではなく、期間で決めます。

置き場所は、原則として顧客のクラウドの環境です。処理する地域は、顧客の要件に合わせて選べる設計にします。使うAIのモデルやサービスは、顧客のデータを学習に使わないものだけを選びます。当社はISO/IEC 27001の認証を取得しています（登録範囲: AIテクノロジーを活用したSaaSプロダクトの企画・開発・提供）。

解約の段取りも一緒に組みます。更新日から逆算した通知の期限、データの持ち出しの試験、並行稼働の期間。シリーズ4本目の解約と移行の実務に書く内容を、そのまま手順として使います。進め方の全体はFDEのサービスページにまとめています。

当社の実践と限界

当社自身も、この線引きで社内の仕組みを分けています。社内ポータルは自社で作って運用していて、契約の台帳と期限の管理、PCや機材の資産の台帳、利用しているSaaSの台帳、稟議の申請と承認、出張の申請、規程、セキュリティ研修、週の目標、日報がそこに載っています。早見表で①に置いたものが、ほぼそのまま並んでいます。一方で、会計、人事労務、見積書の発行はクラウドのSaaSのままです。資産の台帳は自前ですが、会計上の固定資産台帳はSaaS側にあり、自前の台帳はその番号を控えておくだけにしています。正本は読むだけにする、という前の節の2つ目の確認点を、自社でもそのまま守っている形です。

勤怠は少し変わった形を取っています。打刻の入口は自前のポータルに置き、記録の原本と証跡はSaaS側に残しています。ムーアの言う、SoRの上にSoEを重ねる形そのものです。見積書の発行をSaaSに残しているのは、請求と入金までが一続きで、インボイスの要件もかかるからです。自前の側で持っているのは、案件と見積をひも付ける台帳の部分だけです。

うまくいかなかったこともあります。社内ポータルに日報の入力画面を作りましたが、作った直後はほとんど使われませんでした。あとから、前日の予定や記録から下書きを用意する仕組みと、夕方の声かけを足しています。作る費用は下がっても、使われるように設計する手間は下がりません。自前で作るなら、この手間まで見込んでおく必要があります。

引き受けないことも書いておきます。会計、給与、勤怠の原本をSaaSから自前に置き換える案件は、当社は引き受けません。②の領域で、法令の追いかけを顧客に背負わせることになるからです。基幹が参照する正本のマスタを移す案件も同じです。社内に、作ったものを持ち続ける人が一人も決まらない場合は、始めません。取引先など社外の多数が使う仕組みは、①に見えても重い側として扱い、期間と体制を別に相談します。

2軸の整理そのものにも限界があります。データの更新頻度で作るか買うかを分ける考え方は、公的な指針にも調査会社の枠組みにも見当たらず、当社の見立てにすぎません。早見表の判定も、一般的な会社を想定した目安です。そして当社は小さな会社なので、同時に入れる現場の数には限りがあります。

まとめ

• SoRとSoEは役割の区分（ムーア、2011年）、ペースレイヤーは変化の速さの区分（ガートナー、2012年）で、軸が違う
• ガートナーの原典を素直に読んでも、国内の公的指針を見ても、変化の遅い基幹系はパッケージやSaaSが基本。「遅いから作れる」だけでは原典と逆になる
• 原典がSoRの変化が遅い理由に挙げたのは「共通だから」と「規制の対象だから」の2つ。パッケージを選ぶ理由として生成AIで弱まるのは前者だけ
• だから変化の速さに重さ（複雑さ、取引量、法令対応）の軸を足す。遅くて軽い台帳、FAQ、社内ポータル、申請、見積の台帳が自前の候補
• 会計と給与は遅いが重い。2023年から2025年にかけて期日つきの改正が続いており、SaaSを続けるほうが合理的
• ただし残すのは原本と法定の処理だけ。全社員が触る画面は自前にし、SaaSのシートを担当者の分まで減らす手がある（契約の間接アクセスの条項は先に確かめる）
• 作る前に、書類の保存、正本かどうか、権限と社外利用、止まったときの影響、持ち続ける人の5点を確かめる

振り返ると、「作るか買うか」は一度に全部を決める問いではありません。まずはSaaSの一覧に5列を足し、①に入るものを1つ見つけて、本当に軽いかを確かめてみてください。そこから始めれば、失敗しても小さく済みます。

①の候補を一緒に洗い出したい方、作り直したあとも自社で持ち続けられる形にしたい方は、FDEのサービスページをご覧いただくか、FDEの個別相談でお話ししましょう。次の記事では、候補に選んだSaaSを払い続けた場合と作って持つ場合の5年総額を、数字で比べます。

Footnotes

1. New Geoffrey Moore White Paper on Future of Enterprise IT（AIIM、2011年1月19日）。白書「Systems of Engagement and the Future of Enterprise IT」のSoRとSoEの説明は同記事による（筆者訳） ↩ ↩²

2. All your big data will mean nothing without systems of insight（Brian Hopkins、Computerworld、2015年9月21日） ↩

3. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation（Gartner、2012年2月14日。MarketScreener掲載のプレスリリース）。3層の定義、SoRの変化が遅い理由、同じアプリケーションが会社によって違う層に分類されうることは同リリースによる（筆者訳） ↩ ↩² ↩³ ↩⁴

4. レガシーシステムモダン化委員会について（経済産業省 商務情報政策局 情報産業課、第1回レガシーシステムモダン化委員会 資料3、2024年9月12日）。SoR、SoE、SoIの整理は14ページ、Fit to Standardは13ページ ↩ ↩²

5. ITパスポート試験 シラバス Ver.6.5（IPA）。戦略目標の用語例にSoRとSoEが含まれる ↩

6. DXレポート2（中間取りまとめ）（経済産業省、2020年12月28日）。協調領域での自前主義の排除は本文22ページ、内製化への伴走とスキル移転は24〜25ページ ↩ ↩²

7. DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2025年5月27日 デジタル社会推進会議幹事会決定）。アカウント課金のSaaSへの注意、ライフサイクルコストでの比較、「作らないアプローチを徹底させる」は同文書による ↩ ↩² ↩³

8. DX動向2025（IPA、2025年6月26日）。ソーシング手段は図表2-13（日本のノンコア事業・非競争領域 n=1,475、米国 n=509）、内製化の課題は図表2-16（内製化を進めている日本企業 n=334） ↩ ↩²

9. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot（Peng, Kalliamvakou, Cihon, Demirer、arXiv、2023年2月13日） ↩

10. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR、2025年7月10日） ↩

11. We are Changing our Developer Productivity Experiment Design（METR、2026年2月24日） ↩

12. Announcing the 2025 DORA Report（Google Cloud、2025年9月24日） ↩

13. 令和7年通信利用動向調査 報告書（総務省、2026年5月29日公表）。利用しているクラウドサービスの内容は図表4-3（n=2,133、複数回答） ↩

14. インボイス制度について（国税庁） ↩ ↩²

15. 定額減税＠給与サイト（国税庁） ↩

16. 令和7年度税制改正による所得税の基礎控除の見直し等について（国税庁） ↩

17. 電子帳簿保存法対応！令和6年1月以降の電子取引データの保存方法について（国税庁、2024年11月） ↩ ↩²

18. Do Users Write More Insecure Code with AI Assistants?（Perry, Srivastava, Kumar, Boneh、ACM CCS 2023）。実験に使われたのはOpenAIのcodex-davinci-002 ↩