標準機能とアドオンの考え方（Fit to Standard・RICEW・拡張手段の選び方）

Fusion は SaaS です。アプリケーションのコードもデータベースも変えられません。使えるのは、Oracle が用意した設定・拡張ポイント・API だけです。「作れるか」より先に「標準で満たせるか」を確かめます。
進め方は Fit to Standard です。要件を標準機能に当て、「Fit／設定で Fit／Gap」に判定します。Gap は「業務を変える → 運用で回避する → 拡張・連携で作る」の順に検討し、理由を残します。
作るものは RICEW（帳票・連携・変換・拡張・ワークフロー）に分け、区分ごとに手段を決めて、アドオン台帳で管理します。
作ったものは四半期アップデートのたびに確認が必要です。アドオン 1 件は「開発費」と「毎回の確認費」の両方を生むため、見積りは複雑度で分類して両方を積みます。

SaaS で変えられるもの・変えられないもの

変えられないもの：アプリケーションのコードと、データベースへの直接アクセスです。Fusion にはデータベースへの直接接続がなく、外部とは API・ファイル・イベントで連携します（連携方式の全体像）。
変えられるもの：構成（設定タスク）、パーソナライズ、拡張（フレックスフィールド、Visual Builder Studio など）、連携、PaaS の 5 つです。標準に近いものほど、アップデートの影響を受けにくくなります（拡張の全体像）。

原則は次の 3 つです。

設定が先：設定で済むものを拡張にしません。拡張で済むものを PaaS にしません。
公開された手段だけを使う：ドキュメントにない API や内部の画面構造への依存は、互換性が保証されず、アップデートで壊れます。
作ったものは自分たちの資産：Oracle が保守するのは標準機能と拡張の仕組みです。拡張の中身（ルール、SQL、連携フロー）は、設計書・ソース管理・テスト・台帳を含めて導入側が管理します。

Fit to Standard の進め方

SaaS の Fit & Gap は、オンプレミス時代と順序が逆です。「標準と合わない所を作り込む」のではなく、「業務を標準に合わせる」を先に検討します（このサイトの推奨する進め方です）。

進め方

要件を「達成したいこと」で書く：「支払日を自動計算するプログラムがほしい」ではなく「月末締め翌月末払いにしたい」と書きます。現行システムの機能名で書くと、現行踏襲の Gap が増えます。
標準を実演して当てる：業務シナリオ（P2P・O2C・R2R など）ごとに、テスト環境で標準の画面・設定・ジョブを動かして見せます。資料だけで判定しません。
判定する：下の表で分け、根拠（実演の結果、ガイドの該当ページ）を残します。
Gap を分類し、方針を決める：下の検討順で判断します。
業務オーナーが合意する：Gap を作る・作らない、業務を変える・変えないは、業務側の責任者が承認します。
設計書・台帳・テストに反映する：作ると決めたものだけを台帳に登録し、受入基準をテスト項目にします。
見直す：標準は四半期ごとに増えます。AI 機能（事前構築のエージェントなど）も標準の一部として確認し、標準が追いついたアドオンは廃止します。

判定と対処

判定	意味	例（架空：サンプル商事）	対処
Fit	標準機能・既定の設定で満たす	月末締め翌月末払い（支払条件の Day of Month）	標準のまま使う
設定で Fit	設定・構成で満たす	AP 請求書に管理番号を持たせる（DFF）	構成して設計書に記録
Gap：業務変更	業務側を標準に合わせれば解消する	部署独自の承認画面 → 標準の承認ルールと通知	業務オーナーと合意
Gap：運用回避	件数が少なく、手作業で統制できる	年 2 回だけの特殊な振替 → スプレッドシートで仕訳入力	手順書で運用
Gap：作る	必要性が高く、標準で代替できない	経費システムの請求書を AP に取り込む	RICEW に分類して台帳へ

標準・設定で満たせる？ ───────────── はい → Fit／設定で Fit
 └ いいえ
業務を標準に合わせられる？ ────────── はい → 業務変更
 └ いいえ
手作業で統制できる件数・頻度？ ────── はい → 運用回避
 └ いいえ
法令・統制・外部との約束で必須？ ───── はい → 作る（RICEW へ）
 └ いいえ → 見送り（理由を記録し、リリースごとに再評価）

判断の観点は次のとおりです。

法令・会計基準・内部統制で必須か。
使う人数と頻度はどれくらいか。
代替案のコスト（業務変更の負担、運用回避の統制リスク）はどうか。
今後のリリースで標準化される見込みがあるか。Readiness で確認しますが、提供は約束ではないため、期限のある要件は待ちません。
作った後の維持コスト（台帳、アップデート確認）に見合うか。

RICEW と実現手段の対応

RICEW は、アドオンを成果物の種類で分ける呼び方です（Reports・Interfaces・Conversions・Extensions・Workflows）。区分ごとに「先に標準を確認する場所」と「使う手段」が決まります。

区分	典型例	主な手段	先に確認すること
R 帳票・分析	仕訳明細、請求明細書、経営ダッシュボード	OTBI（照会・分析）、BIP（体裁が決まった帳票・大量出力・配信）、Financial Reporting Web Studio・Smart View（残高・財務諸表）、FDI（履歴・横断分析）	事前定義の分析・レポートで足りないか（レポーティング）
I 連携	外部システムとのデータ授受	REST・SOAP、FBDI＋erpintegrations、BICC・Data Extraction、ビジネスイベント。実行基盤は OIC	標準の取込・送信機能で足りないか（連携方式）
C 変換・移行	初期データ・残高の移行	FBDI、ADFdi（スプレッドシート）、HCM Data Loader（人事）、FSM（設定データ）	移行手段の選択（データ移行）
E 拡張	項目の追加、画面の制御、新しい画面	DFF・EFF、VBS（Redwood ページ）、Page Composer・Application Composer（従来型）、PaaS（Visual Builder・APEX・OCI）	設定タスクで足りないか（拡張の全体像）
W ワークフロー	金額・部門別の承認、通知	承認ルール（BPM Worklist、各業務のルール設定）、ビジネスイベント＋OIC（外部の稟議システムとの連携）	標準の条件・承認者で表現できないか（承認ワークフロー）

1 つの要件が複数の区分にまたがります。「外部の請求書を取り込む」は I（連携）が中心ですが、取込時の変換（C）、エラー一覧（R）、承認（W）が付くことがあります。台帳では区分ごとの行に分け、複雑度を別々に付けます。
BIP を大量データの抽出に使うのは最後の手段です。BICC や Data Extraction ツールを先に検討します。
画面で項目を隠しても、セキュリティにはなりません。権限はロールとデータアクセスで制御します。

アドオン台帳のテンプレート

台帳は、アドオンを 1 件 1 行で管理する表です。「作る」と決めたものだけを登録し、台帳に ID がないものは本番に出さない運用にします。拡張の全体像の拡張一覧は、この台帳の E 区分を詳しくしたものです。

項目	書く内容	例（架空）
ID	区分と連番	I-001
要件	業務の言葉で 1 行	経費システムの請求書を AP に取り込む
Gap の理由	標準で足りない理由と、検討した代替案	取込形式が標準と合わない。取引先側を変えられない
実現手段	使う技術と拡張ポイント	OIC＋FBDI（importBulkData）
複雑度	S／M／L／XL（次の見積りの節）	L
オーナー	業務側の責任者と、保守する担当	経理部・IT 部
影響範囲	触れるモジュール・テーブル・API・ジョブ	AP、請求書インポート
アップデート時の確認	リリースごとに何を確かめるか	FBDI テンプレートの版、ジョブ名
状態・廃止条件	稼働中／廃止予定。標準で代替できたら廃止する条件	稼働中。標準の取込が提供されたら再評価

実務では、スプレッドシートや CSV で管理します。次は記入例です。

ID,要件,Gap の理由,実現手段,複雑度,オーナー,影響範囲,アップデート時の確認,状態
R-001,取引先宛ての請求明細書を体裁指定の PDF で出力,標準の帳票では体裁が合わない,BIP,M,営業管理部/IT部,AR,データモデルの SQL と参照テーブル,稼働中
I-001,経費システムの請求書を AP に取込,取込形式が標準と合わない,OIC＋FBDI,L,経理部/IT部,AP,FBDI テンプレートの版・ジョブ名,稼働中
E-001,AP 請求書に管理番号を追加し必須にする,標準項目がない（DFF で対応）,DFF＋VBS ルール,S,経理部/IT部,AP,項目の有無・ルールの評価,稼働中
W-001,高額案件の追加承認を外部の稟議システムと連携,承認結果を社内システムに残す必要,ビジネスイベント＋OIC,L,購買部/IT部,調達,イベントの有効状態・承認者の決定,稼働中

運用のルールは次のとおりです。

ID を成果物の名前に付けます（BIP の /Shared/Custom 配下のレポート名、OIC の統合名、VBS の拡張名など）。
変更は台帳の更新とセットにし、リリース判定に台帳の更新を含めます。
ソースを保管します。VBS は Git、OIC はプロジェクトのエクスポート、BI はカタログのアーカイブです（環境管理）。
年に 1 回、使われていないものを棚卸して廃止します。

標準機能の探し方

「標準にない」と判断する前に、次を確認します。

手がかり	分かること	注意点
要件を目的に言い換えて検索	公式の機能名（例：「締め支払」→ 支払条件の Day of Month）	英語 UI 名と公式ガイドの用語で探す
設定と保守（Setup and Maintenance）	オファリング → 機能領域 → タスクの階層と、タスク検索	タスクがない場合は、先にオファリング・機能領域のオプトインを確認
My Enterprise の New Features・Offerings	最近追加された機能と、オプトインの要否	Allows Opt-In が空欄の機能は、有効にすると戻せない
公式ガイド	「Using ○○」は操作、「Implementing ○○」は設定が目安。REST API・Tables and Views・FBDI のガイドは技術面	対象リリース（26A〜26D）のガイドを見る
Readiness（What’s New・Feature Summary）	新機能、既定で有効になる変更、オプトイン期限	提供時期は約束ではない
事前定義のレポート・分析、AI 機能の一覧	作る前に既存の帳票・分析・AI 機能を探す	事前定義レポートは直接変更できず、`/Shared/Custom` にコピーして修正する
テスト環境での実演	実際に動くか。画面に出ない原因の切り分け	権限・オプトイン・BU や元帳の範囲が原因のことがある

確信が持てなければ、Oracle サポートに「標準で実現できるか」を問い合わせ、回答を台帳に残します（一般的な進め方です）。

アップデート時の影響確認

四半期アップデート（26A〜26D）は、テスト環境に先に適用され、約 2 週間後に本番へ適用されます（環境管理）。この 2 週間に、台帳を使って確認します。

事前：Readiness の What’s New・Feature Summary と、台帳の「影響範囲」を突き合わせます。既定で有効になる変更、オプトイン期限があるもの、将来の動作変更の予定（Feature Updates）を拾います。
テスト環境：台帳の全件について「アップデート時の確認」を実行します（回帰テスト）。API の疎通や主要帳票の件数は自動化します。
本番更新後：スモークテストで主要な連携・拡張の動作を確認し、結果を台帳に記録します。

区分	壊れやすい点	確認方法
R	BIP のカスタム SQL が参照するテーブル・列、事前定義レポートの更新	主要帳票を実行し、件数・金額を前回と比較。カスタムは `/Shared/Custom` に置く
I・C	FBDI テンプレートの列、REST の属性、ジョブ名・パラメータ、ドキュメントにない API	最新のテンプレートを取り直す。REST は Framework Version を固定。正常系と主要エラーを実行
E	Redwood へのオプトイン（Page Composer の変更は引き継がれない）、VBS の実行時依存の更新、DFF の表示・必須	ルールの評価結果と項目の有無を確認
W	承認ルールの条件・属性、承認者の決定（HCM の階層）、通知	新しく起票した取引で承認を通す

オプトインは本番より先にテスト環境で評価し、採用・保留の判断を記録します。戻せないものは特に慎重に扱います。
サンドボックスは、更新の前に公開か削除をします。
新リリースに上がったテスト環境で作った VBS の拡張は、旧リリースのままの本番へデプロイしません。

見積りの考え方（複雑度の分類）

アドオンの費用は「作る費用」だけではありません。SaaS では、四半期ごとの確認が稼働している間ずっと発生します。

設計〜単体テスト
＋ 結合・受入・回帰テスト、環境間の移送、手順書
＋ 年間の確認（四半期ごと × 4 回 × 稼働年数）

複雑度は、区分ごとに次の目安で S／M／L に分けます。L を超えるもの（独自アプリ、複数システムをまたぐ連携など）は XL として個別に見積もります。

区分	S	M	L
R 帳票	既存のデータモデルへの項目追加、レイアウト変更	データモデル 1 本とテンプレート	複数データソース、バースト配信、大量出力
I 連携	1 方向・1 システム、単純な項目対応、少量	変換ルールあり、エラーの再処理あり	双方向、複数システム、大量、突合、即時性
C 移行	マスタ 1 種類、変換なし	取引 1〜2 種類、変換・名寄せあり	複数モジュールにまたがる残高・未決取引、複数回のリハーサル
E 拡張	DFF 数項目、VBS ルール数件	複数画面にまたがるルール、条件分岐	新規の App UI、PaaS アプリ
W 承認	金額帯だけの承認	部門・金額・費目の組合せ、承認グループ	外部ワークフローとの連携、動的な承認者

次は説明用の架空の基準値です。実績ではないため、自社・案件の実績で置き換えてください。

複雑度	設計〜単体（人日）	結合・受入・移送（人日）	年間の確認（人日）
S	3	2	1
M	10	6	3
L	25	15	6

この基準値では、L が 1 件増えると、5 年間で確認工数が 30 人日増えます。作る費用だけを比べると、アドオンを過小評価します。
見積りに入れ忘れやすいものは、開発・追加テスト環境の費用（別途購入）、外部システム側の改修、テストデータの準備、ロールの設計、要件の確度が低い場合のリスクです。
「作る費用＋確認費」と「業務を変える費用」の比較を台帳に残すと、Gap の判断の根拠になります。

落とし穴とベストプラクティス

Gap の判定は、リリースごとに見直します。標準機能と AI 機能は四半期ごとに増えます。
設定・拡張・連携の判断理由を、台帳に残します。

試験対策ポイント

このページ専用の試験はありません。関連する知識は、Redwood 模擬テスト（拡張の手段、VBS）、OIC 模擬テスト（連携方式の使い分け）、GL 模擬テストなどの実装系の試験（設定で満たせる範囲）で問われます。
手段の順序は「構成 → パーソナライズ → 拡張 → 連携 → PaaS」です。データモデルの変更（フレックスフィールドなど）が先で、VBS で画面に出すのは後です。
連携方式は、要求応答が REST と SOAP、発行・購読がビジネスイベント、大量取込が FBDI、大量抽出が BICC です。
設定・拡張の環境間の移行手段は、設定データが構成パッケージ、画面の構成がマイグレーション・セット、VBS の拡張が VBS からのデプロイ、BI がカタログのアーカイブ、OIC がプロジェクトのエクスポートです。
Allows Opt-In が空欄の新機能は、一度有効にすると戻せません。