Operational Ontology は組みたい、しかし居座り構造は避けたい。SIer に依頼したら 10 年常駐になるのも避けたい。DX 推進担当のあなたが、この二択の間の第三の道を探しているなら、「external build, internal maintain（外部が作り、内部が維持する）」の設計が答えの候補になります。
この記事では、1 年で作って引き渡すオントロジー移転の設計論を、契約構造、引き渡し先の育成、6〜12 ヶ月後の生存確認、失敗パターンまで整理します。DE-STK が実践している設計方針の要約でもあります。
なぜ「引き渡す」ことが難しいか
SIer も Palantir も、意図的に「引き渡さない」設計を持っています。これは悪意ではなく、ビジネスモデル上の合理性です。
| 業者タイプ | 引き渡さない理由 |
|---|---|
| SIer | 居座り継続契約が主要収益、引き渡すと収益が消える |
| Palantir | オントロジー常駐がビジネスモデルの心臓、引き渡すと拡張契約が消える |
| 外部フリーランス | 1 年で去っても、詳細ドキュメントは残らない、暗黙知が去る |
引き渡しを最初から契約と設計に組み込む業者は、少数です。これがビジネス機会でもあり、同時に業者側のリスクでもあります。「引き渡し後の生存」でしか品質が証明されないためです。
1 年契約の中身
引き渡し前提の 1 年契約は、次のような構造で組みます。
| 期間 | 外部業者の稼働 | 内部担当の稼働 | 重点 |
|---|---|---|---|
| Month 1〜3 | 100%（設計・実装主導） | 20〜30%（学習・意思決定） | 土台の構築、意思決定への内部関与 |
| Month 4〜6 | 80%（実装主導、内部と並走） | 40〜50%（実装参加、レビュー） | アプリ層と業務ルール、内部の実装参加 |
| Month 7〜9 | 50%（レビューと補完） | 60〜70%（実装主導） | 内部主導への切り替え、外部は補助 |
| Month 10〜12 | 20%（重要相談のみ） | 80%（運用と拡張の主導） | 引き渡し完了、独立運用への移行 |
外部業者の稼働配分が、Month 1 の 100% から Month 12 の 20% まで段階的に下がる形が、健全な引き渡し設計です。逆に、Month 12 でも外部業者の稼働が 70% を超えているなら、それは引き渡しに失敗しています。
引き渡し先の育成
引き渡し先の担当者を、契約開始と同時に確保することが最重要です。担当者不在で 1 年間実装を続けても、引き渡し先がなければ結果は SIer 常駐と変わりません。
| 役割 | 必要人数 | 求められる経験 |
|---|---|---|
| データエンジニア | 1 名以上 | SQL、dbt、Snowflake / BigQuery の実務経験 |
| アプリケーションエンジニア | 1 名以上 | TypeScript / Python、REST API 実装経験 |
| 業務側の推進担当 | 1〜2 名 | 業務プロセスの理解、意思決定への関与権限 |
| 経営スポンサー | 1 名 | 予算承認、部門横断の政治調整 |
30〜70 人規模の中堅企業では、この 4 役を新規採用で埋めるのは非現実的です。既存の情シス担当や業務側のエース人材から抜擢し、外部業者と並走しながら育成する形が現実的です。
6〜12 ヶ月後の生存確認
引き渡し設計の品質は、契約終了後 6〜12 ヶ月経ってからしか観測できません。この期間で次の 4 点が成立しているかで判定します。
| 観測点 | 健全な状態 | 失敗の兆候 |
|---|---|---|
| オントロジーの更新頻度 | 月 1〜2 回、業務変化に追随 | 契約終了後、更新が止まっている |
| 新規アプリの追加 | 内部で年 1〜3 個の新規アプリが追加 | 外部業者に依頼しないと追加できない |
| 障害対応 | 内部で原因特定と復旧が可能 | 外部業者への緊急依頼が発生 |
| 業務側との対話 | 推進担当が定期的に業務側と要件整理 | 業務側の要望が滞留、対応が遅れる |
契約終了後 6 ヶ月の時点で、4 点すべてが健全なら、引き渡しは成功。1〜2 点が兆候レベルなら要注意で、外部業者の追加支援を検討します。3 点以上が失敗の兆候なら、引き渡しは事実上失敗しており、再設計が必要です。
失敗パターン
引き渡し設計で陥りやすい失敗を整理します。
| 失敗 | 原因 | 回避策 |
|---|---|---|
| 担当者不在のまま実装 | 内部の任命が遅れる、または不足 | 契約開始前に、経営から公式に担当者を任命 |
| ドキュメントの薄さ | 外部業者の頭の中に暗黙知が残る | 実装と並行してドキュメント整備、レビューを内部担当が行う |
| 業務ルールの外部依存 | アクションの実装が外部業者だけが理解 | 業務ルール整理を内部推進担当が主導、外部はコード化補助 |
| 引き渡し後の急な変更要求 | 業務側の期待値と実装スコープの乖離 | 契約中に想定シナリオを共有、変更手順を文書化 |
| 外部業者の急な変更 | 業者側の都合、担当者離職 | 担当者複数体制、ドキュメントで冗長化 |
契約に書き込むべき条件
引き渡し設計を契約に落とし込む場合、次の条項を必ず含めます。
| 条項 | 内容 |
|---|---|
| 引き渡し先の指名 | 内部担当者を契約書に明記、変更時は再交渉 |
| 段階的な稼働配分 | Month 1〜12 の外部稼働配分を数値で明記 |
| 成果物の定義 | ドキュメント、コード、運用手順の詳細を列挙 |
| 引き渡し後のフォロー | 6 ヶ月後・12 ヶ月後の相談枠、料金体系 |
| 撤退時の対応 | 契約途中で内部担当が離職した場合の対応 |
| 生存条件 | 契約終了 6 ヶ月後に何が健全であるべきか、事前に定義 |
まとめ
「引き渡して去る」オントロジー移転設計は、Palantir 型の居座り構造でも、SIer 型の人月継続でもない第三の道です。契約 1 年、外部業者の稼働配分は 100% → 20% で段階的に減らし、内部担当を並行して育成する。品質は契約終了 6〜12 ヶ月後の生存で判定します。担当者不在での実装や、業務ルールの外部依存が主要な失敗パターンで、契約段階から回避策を組み込む必要があります。
オープンスタックでの Operational Ontology 構築、既存 DWH/BI からの Read/Write 統合への移行、あるいは Palantir 導入後の維持不能問題への対処など、貴社の現状を踏まえた設計は、Empower STKの初回相談でご案内できます。
あわせて読みたい
- Palantir Foundry の実体：オントロジーとリバースドメインモデリング、日本企業のDX文脈で読み解く
- FDE モデルの本質：営業装置とオントロジー常駐の二段構造
- オントロジー構築の実務：ドメインモデリングとの共通点と、逆順で組み立てる工程
- Palantir 代替のオープンスタック構成：dbt + セマンティックレイヤー + アプリ層で作る Operational Ontology
- Forward-Deployed Engineer（FDE）が去った後、AIプロジェクトを引き取る組織設計
よくある質問
Q. 内部担当が育つ前に、契約が終了してしまいそうです。
A. 契約延長 6〜9 ヶ月を最初から検討します。もし内部担当の育成が Month 8 時点で 50% しか進んでいなければ、外部稼働を 40〜50% で 6 ヶ月延ばす選択肢を残しておきます。契約書に延長オプションを明記しておくと後の交渉が楽です。
Q. 引き渡し先の担当者が離職したら、どうなりますか？
A. リスクが最大化する状況です。回避策として、内部担当を 2 名体制にする、ドキュメントを冗長に整備する、外部業者との軽い相談枠（月 20〜50 万円）を継続する、の 3 点を推奨します。
Q. 6〜12 ヶ月後の生存確認は、外部業者が実施しますか？
A. 外部業者と内部担当の両方で、独立して評価するのが理想です。外部業者の視点だけだと自己肯定バイアスがかかりますし、内部担当だけだと客観性が欠けます。第三者による監査という選択肢もあります。