移行案件の打ち合わせで、アドオンの一覧を前に「新しく作る本数は、ほとんどありません」と言われる場面を考えてみます。数百本の追加プログラムが並ぶ画面を見ながら、自分の出番はもう無いのかと思いかけたところで、相手がこう続けます。「どれを残して、どれを標準に戻すかを決めてほしいんです」。ABAPの案件には、書く本数ではなく、残す本数を決める仕事に変わってきているものがあります。作り込みを減らす流れと生成AIが進んでも、アドオンを書いてきた経験の行き先は残るのか。その不安に、資料と書き手の見立てを分けながら答えます。

1. 「ABAPのアドオン開発」と書かれた案件の中身が違う理由

同じ一行に入る3つの仕事

案件の説明に「ABAPのアドオン開発」と一行あっても、任される仕事が同じとは限りません。この節は資料ではなく、書き手の見立てです。アドオンは、標準の機能で補えない部分のために追加するプログラムのことで、この一行の下には、大きく3つの仕事が入ると考えています。

1つ目は、要件を受けて追加のプログラムを新しく作る仕事です。2つ目は、すでにあるアドオンを1本ずつ見て、いまも使うのか、標準の機能で代わりがきくのかを決める作業です。3つ目は、残すと決まった部分を改修し、その変更が正しいかをレビューする役目です。

図の作成：Remogu編集部。書き手の整理であり、統計データではありません

同じ一行でも、打ち合わせで聞く中身が違えば、求められる経験も変わります。たとえば1つ目は、書く速さと設計の腕が問われやすい仕事です。2つ目は、業務の流れを知っていることが判断の材料になります。3つ目は、既存のプログラムを読み解く力と、変更の影響を見渡す力が土台です。

作り込みを見直す案件が生まれる場面

S/4HANAは、SAPのERP製品の新しい世代を指す呼び名です。こうした新しい基盤への移行では、過去に積み上げた作り込みを見直す案件があります。見直しでは、アドオンをそのまま持ち込むか、標準の機能に寄せるか、作り直すかを分ける作業が出てきます。

どの案件にこの作業が含まれるかは、案件ごとに異なります。ここで挙げたのは一般的な説明で、SAPの製品の方針や期限を述べたものではありません。この記事は、移行の進め方ではなく、アドオンを扱う側の役割に絞って書いています。

だからこそ、案件の説明文だけで中身を決めつけず、打ち合わせで3つのうちどれを任されるのかを聞く価値があります。聞くときの観点は、後半の節で整理します。では、作り込みを減らす考え方は、どんな資料に書かれているのでしょうか。

2. 作り込みを減らし、業務の側を見直す考え方

報告書の本編が導入する側に求めていること

2025年度のソフトウェアモダナイゼーション委員会報告書の本編は、レガシーシステムからの脱却に向けて、従来の慣行を前提に製品側を適合させるのではなく、自社の業務やサービスの在り方そのものを見直す転換が、導入する側に求められるとしています¹。

これはシステムを導入する企業に向けた記述で、フリーランスに向けた義務ではありません。また、ERPやS/4HANAを名指しした文でもなく、ここから先の当てはめは書き手の見立てです。製品側を業務に合わせて作り込む割合を下げ、業務のほうを標準の形に寄せる方向と読むと、アドオンの一覧の性格が変わって見えます。

作るための一覧だったものが、残すかどうかを決めるための一覧になる。冒頭の場面の「新しく作る本数は、ほとんどありません」は、この読み方と重なります。

ノンコア領域にパッケージとSaaSが選ばれている

IPAのDX動向2025は、日本・米国・ドイツの企業へのアンケート調査です。ノンコア事業と非競争領域のソーシング手段を尋ねた設問で、日本は「パッケージソフトウェアの導入」「SaaSの導入」の回答率が高く、「内製による自社開発」「外部委託による開発」の回答率は低い結果でした²。

ただし、この調査はSAPの導入率やERPの数字ではありません。割合の数値もここでは取り上げず、高低の傾きだけを受け取ります。ERPが受け持つ業務の多くはノンコア領域にあたる、というのは書き手の見立てです。その見立てに立てば、競争力の源泉でない領域は、作らずに導入で済ませる回答が多い、という方向が読み取れます。

標準機能への適合は専門家の腕の見せ所

同じ報告書に掲載された寄稿のコラムは、カスタマイズをいかに最小化し、標準機能へ適合させるかが専門家の腕の見せ所だとしています¹。腕の見せ所という言い方は、最小化の判断そのものを専門家の仕事として位置づけています。

この寄稿はソフトウェア開発全般についての論考で、ABAPやSAPには触れていません。それでもアドオンに置き換えると、新しく作る腕だけでなく、作らずに済ませる判断の腕が問われる場面がある、と読めます。置き換えは書き手の見立てとして受け取ってください。

3つの資料の読み比べ

ここで扱った3つの資料は、同じ方向を向いているように見えて、書かれた範囲も立場も違います。報告書の本編は導入する側の転換を、DX動向2025は企業のアンケート回答の傾きを、寄稿のコラムは専門家の腕の見せ所をそれぞれ述べています。どれもABAPやSAPの案件を直接述べた資料ではなく、そこへ重ねて読むのは書き手の見立てです。資料ごとに、誰の見解でどこまで書かれているかを分けて並べます。

資料	誰の見解か	書かれていること
2025年度 ソフトウェアモダナイゼーション委員会報告書の本編	報告書の本編の記述	製品側を従来の慣行に合わせるのでなく、業務やサービスの在り方を見直す転換が導入する側に求められる1
IPA「DX動向2025」	日本・米国・ドイツの企業へのアンケート回答	ノンコア事業・非競争領域で、日本はパッケージとSaaSの導入の回答率が高く、内製と外部委託による開発は低い2
報告書に掲載された寄稿のコラム	寄稿のコラムの記述	カスタマイズの最小化と標準機能への適合が専門家の腕の見せ所1

ただ、作り込みを減らす流れが進んでも、作り込みがゼロになるとは書かれていません。次は、最小化したあとにも残る部分と、生成AIの関わりを見ます。

3. ゼロにならない作り込みと生成AI

すべてをゼロにするのは難しい

先ほどの寄稿のコラムは、腕の見せ所と述べたうえで、すべてをゼロにするのは難しいともしています¹。標準機能へ適合させる努力を続けても、どうしても残る部分がある、という書き方です。

ABAPのアドオンに置き換えて読むと、標準機能でまかなう部分を広げても、残る隙間にアドオンが入る構図になります。この置き換えは書き手の見立てで、寄稿はSAPにもABAPにも触れていません。

「標準に戻すべき」「アドオンは悪い」という話ではありません。標準へ寄せるかどうかはアドオンごとに決める問題で、一律に決まる話でもないからです。アドオンをゼロにするのは難しい、という言葉は、残す判断の仕事が無くならないことを裏から支えています。

生成AIが速める部分と、残るリスク

同じコラムは、生成AIはどうしても残る隙間の構築を加速させるとしています¹。一方で、そこは最もバグが混入しやすく、ブラックボックスになりやすい領域でもある、とも書いています¹。速くなる面と、注意が増える面の両方が、同じ文脈で書かれています。

出典：2025年度 ソフトウェアモダナイゼーション委員会報告書（寄稿）をもとに作成

書き手の見立てでは、速く書けることと安全に書けることは別の話です。書かれるコードの量が増えるほど、中身を把握して責任を持つ人の役割が重くなる、と読めます。ブラックボックスとは、動くけれども、なぜその書き方なのかが分からない状態のことです。

ABAPのアドオンでは、誰が何のために書いたかの記録が薄いまま残るプログラムが、その例になりうると考えます。ただ、これも資料の記述ではなく、書き手の見立てです。生成AIで仕事が減るのか増えるのかは、この資料からは分かりません。言えるのは、構築が速くなる面と、品質面の注意が増える面が、両方書かれているということです。

では、その隙間で書かれたコードを、誰がどう承認するのでしょうか。

4. レビューが「承認」の工程になる

人間のレビューを品質責任の承認として位置づける

報告書に掲載された寄稿は、AIに任せる領域が増えるからこそ、人間によるレビューの工程を、最終的な品質責任を担保する「承認」のプロセスとして再定義することを挙げています¹。レビューを、誤りを探す作業から、責任を引き受ける工程へ位置づけ直す書き方です。

これは、寄稿が挙げている論点のひとつです。委員会の提言や、IPAの方針として書かれたものではありません。レビューを承認の工程として読む見方も、この寄稿の中で示されている考え方として受け取ります。

テストの自動化と人手のレビューの関係

同じ寄稿は、テストの自動化などで網羅性を確保するのは大前提としたうえで、人手によるレビューを廃止してはならないとしています¹。テストが要らないという話ではなく、テストで届く範囲と、人が見る範囲を分けて考える構図です。

出典：2025年度 ソフトウェアモダナイゼーション委員会報告書（寄稿）をもとに作成

業務を知る開発者がレビューを担う見立て

ここからは書き手の見立てです。業務ロジックが妥当かを見る場面では、業務の流れとアドオンの中身の両方を知る人が役に立つと考えます。ABAPの開発者が、書く側からレビューして承認する側へ、役割を広げる余地がそこにあります。

ただし、承認する立場になれば、責任も重くなります。どこまでを任されるのか、承認の権限を誰が持つのかは、参画前にクライアントと協議して確かめる項目です。確かめる順番は、後半の節でまとめます。次は、そもそもアドオンを残すか標準に戻すかを、何を見て決めるのかです。

5. アドオンを残すか標準に戻すかの判断材料

1本ずつ見て決める作業

ここからは書き手の見立てです。資料が述べているのは、作り込みを減らす考え方と、レビューの位置づけまでで、アドオンの扱い方そのものではありません。それを移行案件のアドオンに当てはめると、一覧を1本ずつ見て、残すか標準に戻すかを決める作業が出てきます。残すにも戻すにも、決めた理由を後から説明できる材料が要ります。

その材料は、プログラムの中身を読むだけでは集まりません。そのアドオンをいまの業務が使っているのか、使っているのは誰なのかは、業務の側に聞かないと分からない情報です。コードを読む力に加えて、業務の担当者と話して事実を集める動きが、この仕事の中心になります。

一方で、標準に戻すと決めても、戻した先で業務が回るかを確かめるのは、アドオンを書いた側だけの仕事ではありません。業務の側の見直しが伴うため、決めるのはクライアントと協議したうえでの話です。開発者が出せるのは、判断の材料と、戻したときに何が変わるかの見通しです。

判断を支える5つの観点

判断材料は、5つの観点に分けて集められます。いまも使われているか、標準機能で代わりがきくか、外部システムとのつなぎや帳票か、改修の履歴と書いた人が分かるか、テストがあるかです。これは書き手の整理で、SAPやIPAが示した基準ではありません。観点ごとに、何を確かめるかを並べます。

観点	確かめること
いまも業務で使われているか	利用の記録や、使っている業務の担当者の話から、現在の利用状況を確かめます
標準機能で代わりがきくか	同じ結果を標準の機能と設定で得られるかを、業務の担当者と一緒に見ます
外部システムとのつなぎや帳票か	相手先のシステムや取引先に渡す帳票に関わるものは、変更の影響が社外に及ぶ範囲を確かめます
改修の履歴と書いた人が分かるか	変更の経緯と作成者を追えるかを見ます。追えないものは、中身の読み解きから始めます
テストがあるか	変更したときに動作を確かめる手段があるかを見ます。無ければ、先にテストを用意する作業が要ります

5つの観点は、点数をつけて合計するものではありません。観点が1つ欠けるたびに、そのアドオンは、残す前に調べる作業が増えます。反対に、使われていて、標準で代わりがきかず、テストもあるものは、残す方向で話が進むと考えます。

標準に戻すと言い切れるアドオンは、この観点だけでは見つかりません。観点が示すのは、決めるために欠けている情報がどこにあるかです。欠けている情報を集めて並べ、決めるのはクライアントという分担になります。

棚卸しは移行の範囲のひとつ

アドオンの棚卸しは、移行案件で任される範囲のひとつです。範囲の全体像は、SAPの移行で任される範囲を整理した記事にまとめています。棚卸しがその中のどこに入るかを先に押さえておくと、案件の説明文を読むときに仕事の中身を想像しやすくなります。

では、この棚卸しの仕事を、これまでのABAPの経験とどう結びつけて伝えればよいのでしょうか。

6. ABAPの経験を案件の言葉に直す

書いた本数を、判断の経験として語り直す

この節も書き手の見立てです。アドオンを数多く書いてきた経験は、そのままの言い方では、残す本数を決める案件と噛み合いにくくなります。「何本作りました」と語ると、新しく作る仕事の経験として読まれるからです。同じ経験でも、何を見て、何を判断してきたかへ語り直すと、伝わる相手が変わります。

たとえば、アドオンを改修した経験は、変更の影響がどこまで及ぶかを見渡し、動作を確かめてきた経験でもあります。これは、残すと決まった部分を直す仕事と、そのまま重なります。書いた量ではなく、見渡した範囲と確かめた手段が、案件の側から見える材料です。

経験ごとの言い換え

ABAPの経験は、案件で使われる言葉に4つほど置き換えられます。アドオンの改修、標準の拡張の仕組みを使った改修、帳票やインターフェースの開発、移行時のアドオン調査です。以下は書き手が考えた言い換えの例で、経歴書の型ではありません。自分の経験に合わせて、言葉を選び直してください。

積んだ経験	案件での伝え方
アドオンの改修	変更の影響範囲を確かめ、テストで動作を確認する仕事として伝えます
標準の拡張の仕組みを使った改修	標準に手を入れない作り方を知っている経験として伝えます
帳票やインターフェースの開発	業務で使う出力と、外部とのつなぎの棚卸しができる経験として伝えます
移行時のアドオン調査	残す・戻すの一覧づくりを経験した仕事として伝えます

4つに共通するのは、書いた量でなく、判断の材料を作った経験として語っている点です。1行目の改修の経験は、打ち合わせで影響範囲の見立てを聞かれたときに、そのまま答えの土台になります。調べた対象の数や、残した理由まで話せるように用意しておくと、話が具体的になります。

言い換えるときの線引き

ただし、経験していないことを言い換えで補ってはいけません。調査をしたことがないのに調査の経験として語る、といった置き換えは避けます。言い換えは、事実を別の角度から語り直す作業で、中身を足す作業ではありません。

残る部分を改修し続ける案件では、改修の範囲と期間の聞き方も役に立ちます。SAP保守の範囲と期間を整理した記事で、打ち合わせの前に聞く項目を確かめられます。

経験の語り直しが済んだら、次は、案件に入る前に何を確かめるかです。

7. 参画前に確かめること

打ち合わせで聞く順番

移行のどの段階にある案件かで、アドオンの扱いは変わります。棚卸しの前なら判断の仕事が中心になり、残す部分が決まったあとなら改修とレビューが中心になります。段階を先に聞くと、その後の質問が絞れます。順番は書き手の整理で、次の5つです。

図の作成：Remogu編集部。書き手の整理であり、統計データではありません

2つ目の役割は、前半の図1で見た3つの仕事のどれを任されるかの確認です。新しく作るのか、残すかを決めるのか、残る部分を直してレビューするのかで、求められる経験が変わります。1つ目と2つ目の答えがそろうと、残りの質問の重みも見えてきます。

生成AIとレビューの取り決め

3つ目は、生成AIを使ってよいか、使うならどこまでかです。これは書き手の見立てとして、参画先と協議して決める項目だと考えます。資料は、生成AIが残る隙間の構築を加速させる一方で、バグが混入しやすく、ブラックボックスになりやすいとも述べています¹。使い方の取り決めが無いまま始めると、あとで責任の所在が曖昧になります。

4つ目は、レビューの成果物と、承認する人です。報告書に掲載された寄稿は、人間によるレビューを品質責任を担保する承認のプロセスとして再定義することを挙げ¹、人手によるレビューを廃止してはならないとしています¹。参画前に、レビューで何を残し、誰が承認するのかを聞いておくと、自分の責任の範囲が見えます。

リモートでレビューを担う場合は、コードを共有して指摘を残すやり取りが日々の中心になります。進め方の具体は、リモートでのコードレビューを整理した記事にまとめています。5つ目は契約で、ここまでの取り決めを、書面でどう残すかを確かめます。

残す本数を決める仕事として

冒頭の打ち合わせの場面に戻ります。「新しく作る本数は、ほとんどありません」と聞いて、自分の出番はないのかと思いかけた人が、その続きの「どれを残して、どれを標準に戻すかを決めてほしいんです」を聞けるかどうかは、聞く準備にかかっています。ABAPの案件には、書く本数ではなく、残す本数を決める仕事に変わってきているものがあります。

その仕事は、アドオンを書いてきた経験が行き場を失う場所ではありません。書いた量ではなく、残す理由を説明できる経験が、そこで使われます。Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に合う条件を確かめてみてください。

8. よくある質問

ABAPの経験だけで移行の案件に入れますか

書き手の見立てでは、ABAPの経験が土台になる案件はあります。ただし、経験の語り方が大切です。業務の流れをどこまで理解しているか、移行時にアドオンを調べた経験があるか、残す理由を説明した経験があるかを、打ち合わせで話せるように用意しておくと、任される仕事の範囲を具体的に確かめられます。

生成AIが使えるとABAPの案件は少なくなりますか

資料からは、案件が減るのか増えるのかは分かりません。資料が述べているのは、生成AIがどうしても残る隙間の構築を加速させるが、そこはバグが混入しやすく、ブラックボックスになりやすい領域でもある、という点です¹。さらに、人手によるレビューを廃止してはならないともしています¹。残る部分の構築とレビューは人が担う、という範囲までが読み取れる内容です。

ABAPの案件はリモートで受けられますか

リモートで参画できるかは、案件によって異なります。書き手の見立てでは、接続環境、権限の範囲、セキュリティの取り決めが、参画前に協議する中心の項目です。社内の環境に入る必要がある案件もあるため、打ち合わせの早い段階で、どこまでリモートで進められるかを聞いておくと、参画後のずれを減らせます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 ソフトウェアモダナイゼーション委員会「2025年度 ソフトウェアモダナイゼーション委員会報告書」（2026年3月24日・2026年10月確認）
＊2 独立行政法人情報処理推進機構「DX動向2025」（2025年6月26日・2026年10月確認）