こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp
以前は自社の戦略について書きましたが、今回は視点を変えてみます。
これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。
目次
- はじめに：SaaSの普及と、残された「巨大な壁」
- 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ
- 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか
- 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE)
- 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology
- おわりに：バックオフィス・プロダクトの解像度を高める
はじめに：SaaSの普及と、残された「巨大な壁」
ここ10年で、日本のSaaS市場は劇的な進化を遂げました。クラウド上の優れたツールを契約し、IDを発行すれば、その日から最新のUI/UXで業務ができる──。これが「当たり前」となり、多くの企業で生産性が向上しました。しかし、この成功法則が通用しない領域が依然として存在します。それが、巨大な歴史と複雑な業務構造を持つ「エンタープライズ企業」の基幹業務領域です。
「SaaSを導入したけれど、既存の基幹システムとデータがつながらない」 「現場独自の複雑なオペレーションが、標準機能ではカバーしきれない」 「結局、CSVデータを手作業で加工してアップロードする業務が残った」こうした声は、SaaSベンダーとエンタープライズ企業の双方が抱える深い悩み（ペイン）です。なぜ、便利なSaaSが増えても、現場の苦しみはなくならないのか。その解像度を高めるためには、まず現在企業が置かれている「システム・アーキテクチャの現在地」を知る必要があると思っています。
本記事では、企業の基幹システムが辿ってきた自分なりに整理した「4つのアーキテクチャ」と、既存の「SIやBPO」が抱える課題を整理した上で、その全てを突破するために現れた新しいアプローチ──「専属シェフ（FDE）」と「万能翻訳機（中間システム）」について自分なりに市場の状況を踏まえて解説をまとめてみました。
これは単なるツールの話ではなく、これからのバックオフィスプロダクトが向かうべき、ひとつの進化系統樹の話と思ってもらえればと思います。
第1章：前提となる「企業の基幹システム」4つのアーキテクチャ
「専属シェフ」や「万能翻訳機」という新しい概念を理解するために、まずは現在、エンタープライズ企業がどのようなシステム構造の上に成り立っているのか、その類型を見ていきましょう。大きく4つのパターンに分類されます。
1. Fit to Standard（ERP一本足打法）
最も伝統的かつ、かつての「理想形」とされたモデルです。SAPやOracleといった巨大なERPを導入し、会計・人事・販売・在庫など、企業のあらゆるデータを一つの巨大なシステムで管理します。
特徴： 「業務をシステムに合わせる」思想。データが一元管理されるため、経営層には理想的です。
課題： 現場にとっては「使いにくさ」が壁になります。UI/UXよりもデータ整合性が優先されるため、単純な経費精算にも多大な工数がかかります。また、日本固有の商習慣に合わせるための追加開発（アドオン）により、保守コストが高騰しがちです。
2. Two-Tier ERP（2層構造：ERP × SaaS）
現在、多くの日本企業が採用している現実解です。「本社やコア業務（会計など）は重厚なERPで守り、現場業務（労務、SFAなど）は軽快なSaaSで攻める」というハイブリッド構成です。
特徴： 守りと攻めのバランス型。現場はモダンなSaaSを使えるため、生産性が上がります。
課題： 「データの分断」が最大のネックです。社員マスターがERPにもSaaSにも点在し、それらをつなぐために「月末にCSVを吐き出し、手加工して取り込む」というアナログ作業が残ります
3. Composable ERP（レゴブロック型）
Two-Tierをさらに推し進め、巨大なERPを置かずに「各業務における最強のSaaS（Best of Breed）」をレゴブロックのように組み合わせてシステム群を構成する考え方です。
特徴： 「会計はfreee」「人事はSmartHR」「営業はSalesforce」のように最適解を選べ、変化に強い構成です。
課題： インテグレーションの難易度が極めて高い点です。API連携がうまくいかないとデータがサイロ化（孤立）し、全体が見えなくなります。強力な情シス（コーポレートエンジニア）組織が不可欠です。
4. SaaS Unbundling（脱SaaS・完全内製回帰）
AIの進化により、近年テック企業を中心に注目され始めた「揺り戻し」です。「SaaSは機能過多で高い。AIを使えば自分たちで必要なシステムを安く作れるのではないか？」という発想です。
特徴： 汎用SaaSを使わず、自社DBの上にAI支援で独自アプリを構築します。コスト削減と業務への完全適合がメリットです。
課題： 「作った人しか直せない」という属人化リスクと、セキュリティや品質保証をすべて自社で担う重責が発生します。
欧州フィンテック大手Klarnaが有名な例です
第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか
上記の4つのアーキテクチャには、それぞれ一長一短があります。「あちらを立てればこちらが立たず」の状況です。 この課題を解決しようとする際、企業が次に検討するのは、伝統的な「SI（システムインテグレーション）」か、あるいは近年台頭してきた「AI × BPO（AIを活用した業務委託）」だと思います。しかし、エンタープライズの「ラストワンマイル」においては、これらもまた決定打になり得ない現実があるように思います。
SI（システムインテグレーション）の課題 ── 「要件定義」の壁
SIは「建物を建てる（＝システムを作る）」ことには長けています。しかし、SIモデルの前提は「要件が固まっていること」です。 「今の業務をそのままシステム化してください」と依頼しても、現場の業務は複雑怪奇なマクロや暗黙知で動いており、誰も正解を知りません。結果、要件定義に半年かかり、完成した頃にはビジネス環境が変わっている──。これが「ウォーターフォール型の限界」です。
AI × BPOの課題 ── 「ブラックボックス化」の壁
一方で、「AIを使って業務ごとアウトソースする（AI × BPO）」というアプローチも増えています。これは即効性がありますが、本質的には「人の作業をAIに置き換えただけ」です。 業務プロセス自体がブラックボックス化し、社内にデータ資産やノウハウが蓄積されません。また、AIが誤った判断（ハルシネーション）をした際、背後にあるデータ構造（オントロジー）が整備されていないため、原因究明が困難になります。
「SIのように外から作る」のでもなく、「BPOのように外に出す」のでもない。 既存のSaaS群も、SIも、BPOも解決しきれなかった「断絶」。これを埋めるために必要なのが、「内側に入り込み、業務を回しながらシステムを進化させる」という、第3のアプローチがでてきています。
第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE)
そこで登場するのが、FDE（Forward Deployed Engineer）という概念です。 彼らは「SIer」とも「BPOスタッフ」とも異なります。あえて言うなら、「エンジニアリング能力を持った、現場専属の解決請負人」です。「調整」ではなく「実装」で解決する。
SIerが「仕様書」を作る間に、FDEは「プロトタイプ」を作ります。 BPOが「マニュアル通り」に作業する間に、FDEは「マニュアルを不要にする自動化」を行います。彼らは顧客のオフィスの最前線（Forward）に入り込み（Deployed）、以下のように動きます。
APIがない？ → 「ならDBのダンプから直接データパイプラインを作ります」
現場のエクセルが複雑？ → 「そのロジックをPythonで解析し、システムに移植します」
SIのような「納品して終わり」ではなく、BPOのような「作業代行」でもない。 既存の冷蔵庫（レガシーシステム）にある食材（データ）を、その場で極上の料理（モダンな業務フロー）に調理して提供する「専属シェフ」。このアジャイルなアプローチは、全体最適の大改修ではなく“詰まりやすい部分”から小さく改善を重ねることで、エンタープライズの組織・プロセスの制約下でも変革を進めやすくします。
第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology
FDEという高度人材が活躍するためには、彼らが振るう「包丁」となるシステム基盤が必要です。それが「中間システム」であり、その核となる「Ontology（オントロジー）」です。
「データ」に「意味」を与える (Ontology)
従来のデータベースは「行と列」の羅列に過ぎません。SIで開発するシステムや、AI × BPOで使うツールも、往々にして「その業務専用のデータ定義」になりがちです。 しかし、中間システムにおけるOntologyは、データそのものではなく「業務の実体（Concept）」を中心にデータを再定義します。
従来： Table_A.col_1 と Table_B.id を結合（人間が都度判断）
Ontology： Customer has many Contracts（データ自体が意味を持つ）
現実世界の業務の関わり合い（コンテキスト）をそのままデータ構造として定義することで、システムは裏側の複雑なDB構造を知らなくても、「顧客の契約状況を教えて」と問うだけで正しいデータを引き出せるようになります。
異なる言語を翻訳する「万能翻訳機」
エンタープライズには、SAPやOracle、野良エクセルなど、異なる言語（プロトコル）で話すシステムが乱立しています。 ここに「中間概念（データやシステム）」を配置することで、レガシーとモダンをつなぐ「万能翻訳機」としての役割を果たさせます。
入力（レガシー）： 古いシステムからFDEがパイプラインでデータを吸い上げる。
処理（翻訳）： 吸い上げたデータをOntologyに基づいて「意味のある情報」に変換・統合する。
出力（モダン）： AIエージェントやSaaSが、整理されたデータにアクセスする。
この「中間概念(データやシステム)」が存在することで、企業は巨大な基幹システムをリプレイスすることなく（＝冷蔵庫を買い替えることなく）、最新のAI活用（＝プロの料理）を享受できるようになります。
第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道
この「FDE × 中間概念（Ontology）」という構造は、これからのバックオフィスプロダクトにおいて、AIを活用するための必須条件となります。
AIが「働く」ための地図
生成AIやAIエージェントが実業務で機能するためには、コンテキスト（文脈）が必要です。単にマニュアルを学習させるだけでは不十分で、「今、この瞬間の会社の状態」を正確に把握していなければなりません。
中間システム上のOntologyは、まさに「AIにとっての地図」になります。 「A社の請求書が遅れている」という事実だけでなく、「A社は重要顧客であり、過去に同様のケースでは担当者が電話でフォローしていた」という文脈をAIが理解できて初めて、AIは単なるツールを超え、「自律的なエージェント」として機能します。
つまり、中間システムを構築することは、単なるデータ統合ではありません。 SIのように「箱」を作るのでもなく、BPOのように「人」で埋めるのでもなく、「企業そのものをデジタルツイン（デジタルの双子）化し、AIが自律的に働ける環境（ワークスペース）を整えること」なのです。
おわりに：バックオフィス・プロダクトの解像度を高める
「Fit to Standard」から「SaaS Unbundling」まで、企業のシステムは揺れ動いてきました。しかし、どの時代、どのアーキテクチャにおいても、「データをつなぎ、業務を流す」という本質的な課題は残されたままでした。
「専属シェフ（FDE）」と「万能翻訳機（中間システム）」のアプローチは、既存のSaaS群やSIモデルを否定するものではありません。むしろ、過去の遺産（レガシーデータ）と未来の技術（AI/SaaS）を、技術と泥臭さで接着する新しいアプローチなのではと思っています。
古い文字コードとの戦い、複雑怪奇な勘定科目のマッピング、例外だらけの承認フロー......。 そうした「泥臭い現実」を、高度な抽象化技術（Ontology）と実装力（FDE）で包み込み、ユーザーには「魔法のようなシンプルさ」として提供する。これこそが、この領域のプロダクトマネジメント、エンジニアリングの真の面白さであり、深淵なる魅力ではないでしょうか。
それを支える中間概念（Ontology）思考。
これらはまだ耳慣れない言葉かもしれませんが、数年後には企業のバックオフィス構造を支える、当たり前のインフラになっているかもしれないと感じています。 もし、こうした「複雑さを技術で解きほぐす」アプローチや、社会の基盤となるバックオフィスプロダクトの進化に興味を持っていただけたなら、ぜひこの広大なフィールドを一緒に探求していければと思います。
この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！
●採用情報 デザイナー career-recruit.rakus.co.jp
└ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp
