【SAP基礎】ABAPプログラムの分類RICEFについて解説！

SAPの導入プロジェクトに参加すると、会議や設計書で「RICEF」という言葉を見かけることがあります。「RICEF一覧を更新してください」「この要件はIとEの開発が必要です」と言われて、戸惑った方もいるのではないでしょうか。

RICEFは、SAPの追加開発を目的別に整理するときに使う分類です。意味を覚えると、開発対象の全体像や、担当する機能の位置づけを理解しやすくなります。

本記事では、SAP初心者やSAPコンサルタント、ABAP開発者に向けて、RICEFの基本からプロジェクトでの活用方法までを解説します。

概要

RICEFとは、Report・Interface・Conversion・Enhancement・Formの頭文字を並べた言葉です。
SAPプロジェクトでは、標準機能や設定だけでは満たせない要件について、追加で開発する対象を整理するために使われます。

分類（英語）	日本語での意味	代表的な開発例
R（Report）	レポート・一覧照会	納期を過ぎた受注の一覧
I（Interface）	システム間連携	倉庫システムとの出荷データ連携
C（Conversion）	データ移行・移行用変換	旧システムからの品目マスタ移行
E（Enhancement）	機能拡張	受注保存時の独自チェック
F（Form）	帳票	独自レイアウトの納品書

RICEFはABAPのプログラム属性ではない

ここで押さえておきたいのが、RICEFは開発管理上の分類であり、ABAPの技術的なプログラム種別そのものではないという点です。

例えば、ABAPの実行可能プログラムでCSVファイルを読み込み、移行対象のデータを登録する場合、技術的には実行可能プログラムでも、業務上の分類はCになります。「REPORT文で始まるからR」と判断するわけではありません。

また、1つの開発対象が、1本のABAPプログラムと対応するとは限りません。納品書の開発なら、データを取得するクラス、帳票のレイアウト、出力を制御する処理など、複数のオブジェクトで構成されることがあります。

RICEFを判断するときは、ソースコードの書き方よりも「その機能が実現する業務」を確認しましょう。

なぜSAPプロジェクトでRICEFを使うの？

追加開発をすべて「アドオン」と呼ぶだけでは、必要な作業が見えにくくなります。売上一覧と外部システム連携では、設計の確認事項も、関係者も、テストの進め方も異なるためです。

例えば、レポートなら表示内容や検索性能、インターフェースなら接続先との調整やエラー時の再処理が重要です。移行ならデータの整備と突合、帳票ならレイアウトの確認が欠かせません。

RICEFで整理すると、どの種類の開発が多いのか、どのチームとの調整が必要なのかを把握しやすくなります。ただし、分類だけで工数が決まるわけではありません。同じRでも、単純な一覧と複雑な集計レポートでは作業量が大きく変わります。

RICEFの5つの分類

① R：Report（レポート）

Reportは、SAPに登録されたデータを検索・集計し、利用者が確認できる形で表示する機能です。

例えば、営業担当者から「納期を過ぎているのに出荷が完了していない受注を、担当者別に確認したい」と依頼されたとします。この場合、対象の受注を抽出し、得意先・品目・納期・未出荷数量などを一覧にする機能がRの例になります。

従来のSAP GUI向け開発では、一覧表示にALV（SAP List Viewer）が使われます。ALVでは、実装に応じて並べ替えやフィルタなどの操作を提供できます。一方、Fioriの一覧・分析アプリで実現する場合も、目的が照会や集計なら、開発管理上はRとして扱えます。

設計で特に重要なのは、「何を1行として表示するか」を決めることです。受注単位なのか、明細単位なのか、納入日程行単位なのかで、データの取得方法や件数が変わります。

また、「未出荷数量」の定義も確認が必要です。一部出荷、取消、返品などをどう扱うかが曖昧だと、画面は完成しても業務では使えません。大量データでの実行時間や、参照できる販売組織などの権限制御も設計に含めましょう。

② I：Interface（インターフェース）

Interfaceは、SAPと別のシステムの間でデータを受け渡す機能です。連携相手には、非SAPのシステムだけでなく、別のSAPシステムも含まれます。

例えば、販売管理をSAP、現場の倉庫作業を外部の倉庫管理システムで行うケースを考えてみましょう。

SAPから出荷指示を送信し、倉庫側でピッキングや梱包を行います。その後、倉庫側から実績を受信し、SAPの伝票処理につなげます。何を実績として返し、どの処理まで自動実行するかは、業務設計で決める内容です。

連携方向は、SAPを基準にすると次のように整理できます。

方向	意味	具体例
Outbound	SAPから外部へ送る	倉庫への出荷指示送信
Inbound	外部からSAPへ受け取る	倉庫からの出荷実績受信

連携方式にはAPI、IDoc、ファイルなどがあります。どの方式を採用するかは、利用できる標準インターフェースや、相手システムの仕様を確認して決めます。

また、同じデータを再送したときに二重登録されないか、どのデータまで正常終了したか、誰がエラーを修正して再処理するかも決めます。連携の設計は、正常時のデータ送受信と、異常時の運用をセットで考えましょう。

③ C：Conversion（データ移行・移行用変換）

Conversionは、旧システムのデータを新しいSAP環境へ引き継ぐための移行や、そのための変換を扱う分類です。

例えば、新規導入時に品目マスタ、取引先、在庫、未決済の債権・債務などを移す場面が該当します。ここでのConversionは、ECCからS/4HANAへの「システムコンバージョン」という移行方式全体と同じ意味ではありません。

データ移行は、単にファイルを登録する作業ではありません。旧システムとSAPではコード体系や必須項目が異なるため、データの整理と変換が必要になります。

工程	品目マスタ移行での作業例
抽出	旧システムから移行対象の品目を取り出す
整備（データクレンジング）	重複品目や入力不備を確認する
変換	旧単位コードをSAP側の単位コードへ対応づける
登録	対象の品目データをSAPへ取り込む
検証	対象件数、登録件数、主要項目を照合する

S/4HANAでは、標準の移行機能であるSAP S/4HANA Migration Cockpitを利用できるか確認します。この機能は初期データロードを主な目的としており、日常的なデータ連携とは役割が異なります。対応する移行対象や利用方式は、製品・リリースによって確認が必要です。

標準機能で要件を満たせるなら、移行プログラムを一から作る必要はありません。独自の変換処理などが必要な場合に、追加開発の範囲を切り分けます。

テストでは、登録成功のメッセージだけで判断しないことが大切です。在庫なら数量や必要に応じた金額、債権なら残高などを照合します。また、移行はリハーサルを繰り返すため、エラー修正後の再実行方法や、本番で許容される処理時間も確認しましょう。

④ E：Enhancement（機能拡張）

Enhancementは、SAPの既存機能に独自のチェックや処理などを追加する機能拡張です。

例えば、「特定の販売組織では、独自の管理項目が未入力なら受注を保存できないようにする」という要件を考えます。まず標準設定で対応できるか調べ、対応できない場合に、利用可能な拡張箇所で独自のチェックを行う方法を検討します。

従来のABAP開発では、ユーザーExit、カスタマーExit、BAdI（Business Add-In）などの拡張手段が使われます。ただし、すべての手段がすべてのSAP製品・環境で利用できるわけではありません。

また、拡張用の仕組みを利用して独自処理を追加することと、SAP標準オブジェクトを直接変更する「モディフィケーション」は区別します。SAPの学習資料でも、標準を変更する前に、拡張技術で実現できないか検討する考え方が示されています。

Eの設計では、「いつ処理が呼び出されるか」が重要です。画面入力中なのか、保存時なのかによって、参照できる情報や後続処理への影響が変わります。

例えば、画面からの受注登録でチェックが動いても、外部連携による登録では同じ拡張箇所を通らない可能性があります。対象となる登録経路を洗い出し、要件どおりにチェックされるか確認しましょう。

また、対象外の販売組織や伝票タイプまでエラーにしないことも重要です。追加したルールが正しく働くかに加え、既存の業務を妨げないかをテストします。

⑤ F：Form（帳票）

Formは、納品書、請求書、発注書など、決められたレイアウトで文書を出力する機能です。紙への印刷だけでなく、PDFとしての出力も含みます。

例えば、納品書に自社ロゴ、得意先住所、品目、数量、注意事項を配置し、所定の様式で出力する開発がFに該当します。

帳票技術にはSAPscript、Smart Forms、Adobeを利用したフォームなどがあります。利用できる技術や出力の仕組みは製品・対象業務によって異なるため、既存システムと同じ方式をそのまま選べるとは限りません。

設計では、レイアウトとデータ取得の両方を確認します。得意先名をマスタから取得するのか、伝票に保持された情報を使うのかによって、再印刷時の内容が変わることもあります。

混同しやすいRICEFの違い

ReportとFormの違い

RもFも「データを出力する」ため、日本語ではどちらも帳票と呼ばれることがあります。分類に迷ったら、出力形式だけでなく利用目的を確認しましょう。

Reportは、検索・照会・分析のために情報を見せる機能です。Formは、所定の書式で業務文書を作る機能です。

例えば、請求状況を得意先別に検索する一覧はR、得意先へ送る請求書はFと整理できます。一覧をPDFに保存したからといって、必ずFになるわけではありません。

InterfaceとConversionの違い

IとCは、どちらもデータを取り込んだり、形式を変換したりするため、処理内容だけを見ると似ています。判断の軸は、そのデータ連携が何のために必要なのかです。

比較項目	Interface	Conversion
主な目的	稼働後のシステム間連携	新環境への業務データの引き継ぎ
利用場面	日々・定期的・随時の業務処理	移行リハーサルや本番切替
重視する点	監視、再送、重複防止、連携先との整合	データ整備、変換、照合、移行時間

同じCSV取込でも、毎日の注文連携ならI、稼働開始時の未完了受注の移行ならCと整理できます。「ファイルだからC」「APIだからI」と技術だけで判断しないことが大切です。

なお、Cでもリハーサルや分割移行で何度も実行します。「1回だけ動かすプログラム」という説明では、実務を正しく捉えられません。

1つの要件に複数の分類が含まれることもある

例えば、「外部システムから注文を取り込み、独自チェックを行い、確認書を出力する」という要件には、I・E・Fが含まれる可能性があります。

ただし、インターフェース内部で入力データをチェックするだけなら、そのチェックを独立したEとして管理するとは限りません。標準の受注登録処理にも適用する拡張なのか、連携処理内だけで完結するのかで整理が変わります。

分類は無理に一文字へ押し込めるものではありません。主分類を付けて関連開発を紐づける、別々に設計・テストする単位へ分割するなど、プロジェクトでルールを合わせましょう。

まとめ

RICEFは、SAPの開発対象を目的別に整理する分類です。

• R：業務データを検索・集計するReport
• I：システム間でデータを受け渡すInterface
• C：新しい環境へデータを引き継ぐConversion
• E：既存機能に独自処理を加えるEnhancement
• F：決められた書式で文書を出力するForm

実務では、文字の意味を暗記するだけでなく、利用目的、関係者、設計・テストの重点まで結びつけることが大切です。同じ技術を使っていても目的によって分類が変わり、1つの要件に複数の分類が関係することもあります。