20年ABAPを続けてきた私が、いまBTPを学び始める理由
はじめに
はじめまして。「頑張れABAPer」というnoteを始めることにしました。
私はSAPのABAP開発者として、かれこれ20年ほどこの世界で仕事をしてきました。R/3の時代からECC、そして今のS/4HANAまで、時代の変化を現場で見てきた人間です。
ABAPという言語は、正直なところ「地味」だと言われることが多い言語です。派手なフレームワークの話題に上ることもなければ、勉強会で盛り上がることも多くありません。それでも、企業の基幹業務を支え続けてきたという意味では、ABAPほど「実務に効く」言語もなかったのではないかと思っています。
安定していた20年間
この20年、SAP案件は単価が高く、仕事も安定していました。私が所属してきた会社の売上も、SAP関連の案件を軸に右肩上がりで成長してきました。景気の波はありましたが、「SAPを触れる人がいない」という状況は変わらず、ABAP開発者は常に引く手あまたでした。
正直なところ、「このままABAP一本でやっていけば安泰だろう」という気持ちも、心のどこかにありました。
BTP案件が増えてきた
しかし、ここ数年で状況が明らかに変わってきました。SAP自身が「クリーンコア」を掲げ、標準機能への追加開発(アドオン開発)をできるだけ避け、拡張はSAP Business Technology Platform(BTP)上で行う方針を明確に打ち出しています。
実際、私の周りでも、これまでECCやS/4HANAのアドオン開発を依頼していたお客様から、「BTPでの拡張開発をお願いしたい」という相談が増えてきました。ABAPだけをやっていればよかった時代は、静かに終わりを迎えつつあると感じています。
なぜ今、学び始めるのか
私がBTPを学び始めようと思った理由は、大きく3つあります。
1つ目は、案件の変化に対応するためです。ABAPの案件がすぐになくなるとは思いませんが、BTPを扱えるかどうかで、今後受けられる仕事の幅が大きく変わってくるはずです。
2つ目は、ABAPerとしての強みを活かせる場所がBTPにもあると気づいたからです。特にCAP(Cloud Application Programming Model)は、データモデルの設計やビジネスロジックの実装という点で、ABAPやCDSの経験がそのまま活きる部分が多くあります。まったくのゼロから学ぶわけではない、というのは大きな安心材料でした。
3つ目は、単純に「新しいことを学びたい」という気持ちです。20年同じ言語を使い続けてきたからこそ、新しい技術を学ぶことへの抵抗感もありました。ただ、いざ触れてみると、Javaやクラウドの世界にも、ABAPの世界とは違う面白さがあることに気づき始めています。
このnoteでやりたいこと
このnoteでは、私自身がABAPerの視点からBTP、特にCAP(Java版)を学んでいく過程を、ハンズオン形式で記録していきます。
- ABAPの知識や経験を、BTPの学習にどう活かせるか
- ABAP脳のままではつまずくポイントはどこか
- 実際に手を動かしながらアプリを作っていく過程
「自分と同じように、長くABAPをやってきたけれど、そろそろ次の一手を考えたい」という方に向けて、実体験ベースの情報を発信していきたいと思います。
第0章では、本格的なハンズオンに入る前に、なぜABAPerがBTPを学ぶ必要があるのか、ABAPの経験はどこまで通用するのか、といった土台となる考え方を整理していきます。
一緒に、頑張りましょう。頑張れABAPer。
ABAPerの仕事はなくなるのか?BTP時代に考えたいキャリアの話
「ABAPはもう終わり」なのか
SNSや勉強会で、「ABAPはもう終わる」「これからはBTPの時代だ」という声を見かけることが増えました。20年ABAPをやってきた身としては、こうした言葉に少なからずドキッとします。
結論から言うと、私は「ABAPの仕事がすぐになくなることはないが、ABAPだけで戦える時代は終わりつつある」と考えています。この違いは、キャリアを考えるうえでとても重要です。
クリーンコア方針が示していること
SAPは近年、「クリーンコア(Clean Core)」という方針を明確に打ち出しています。これは、S/4HANAの標準機能に対して直接的な改修(モディフィケーション)を極力行わず、拡張が必要な場合はBTP上でSide-by-side拡張として実装する、という考え方です。
この方針が意味するのは、「ABAPという言語が不要になる」ということではありません。実際、S/4HANA上でのRAP(ABAP RESTful Application Programming Model)開発や、既存アドオンの保守にはこれからもABAPが必要とされ続けます。
一方で、新規の拡張開発の受け皿が、従来のECC・S/4HANA内アドオンから、BTP上のアプリケーションへとシフトしていくことは、ほぼ間違いない流れです。
「仕事がなくなる」ではなく「仕事の中身が変わる」
私が周囲の案件を見ていて感じるのは、「ABAPの仕事がゼロになる」というより、「ABAPの仕事の中身が変わっていく」ということです。
- 既存アドオンの保守・移行案件
- S/4HANA移行にともなうRAP開発案件
- BTP側との連携を前提とした設計・実装案件
このように、純粋な「オンプレ完結のアドオン開発」は減っていく一方で、「BTPと連携することを前提としたABAP開発」は今後も一定数残っていくはずです。つまり、ABAPだけを知っていればよい時代は終わりますが、ABAPを知らなくてよい時代が来るわけでもありません。
キャリアとして考えたい3つの選択肢
20年目のABAPerとして、これからのキャリアを考えたとき、大きく3つの方向性があると感じています。
1. ABAPの専門性をさらに深める
保守・移行案件は今後も一定数存在します。特にS/4HANAへの移行はまだこれからという企業も多く、ABAPの深い知識を持つ人材へのニーズはしばらく続くでしょう。
2. ABAP × BTPのハイブリッド人材になる
ABAPの経験を土台にしながら、BTP(CAPやRAP、Integration Suiteなど)にも対応できる人材になる道です。私自身が目指しているのはこの方向です。既存の強みを活かしながら、対応できる案件の幅を広げていくアプローチです。
3. BTP・クラウド開発に軸足を移す
思い切ってABAPから離れ、クラウドネイティブな開発に軸足を移す道です。若い世代や、これから新しくSAPの世界に入る方には有力な選択肢だと思いますが、20年の経験を積んできた身としては、それを手放すのはもったいないとも感じています。
私が選んだ道
このnote「頑張れABAPer」では、2番目の「ABAP × BTPのハイブリッド人材」を目指す過程を記録していきます。
理由はシンプルで、20年積み上げてきたABAPの経験と、SAPの業務知識は、決して無駄にはならないと考えているからです。次回は、その中でも特に「ABAPの経験はCAP開発でも通用するのか」という点について、具体的に掘り下げていきます。
ABAPの経験はCAP開発でも通用する|20年の経験は無駄にならない
「ゼロからのスタート」ではないという安心感
BTPやCAPの学習を始めるにあたって、多くのABAPerが感じる不安は「今までの経験がリセットされてしまうのではないか」ということだと思います。私自身、学習を始める前はそう感じていました。
しかし、実際にCAP(Cloud Application Programming Model)に触れてみると、ABAPの経験がそのまま活きる部分が思った以上に多いことに気づきました。この記事では、具体的にどこが通用し、どこが新しく学び直す必要があるのかを整理します。
通用する部分①:データモデリングの考え方
ABAP開発において、テーブル設計やCDSビューの作成は避けて通れないスキルです。エンティティ間の関係(1対多、多対多)、キー項目の設計、正規化の考え方などは、長年の実務の中で自然と身についています。
CAPでは、CDS(Core Data Services)という共通言語でデータモデルを定義します。実はこのCDS、ABAP CDSと文法の思想がかなり近く、ゼロから「データモデリングとは何か」を学び直す必要はありません。むしろこの部分は、ABAPerにとって大きなアドバンテージになります。
通用する部分②:ビジネスロジックの設計力
在庫管理、受発注、会計といった業務ロジックを、長年ABAPで実装してきた経験は、言語が変わっても価値を失いません。「どういう業務要件を、どう実装に落とし込むか」という設計力そのものは、Javaで書こうがABAPで書こうが変わらないスキルです。
CAPを学ぶというのは、「新しい構文を覚える」ことがメインではなく、「今まで培ってきた設計力を、新しい道具でどう表現するか」を学ぶことに近いと感じています。
通用する部分③:SAPの業務知識そのもの
これは地味に大きなポイントです。BTP上のアプリケーションであっても、多くの場合はS/4HANAなどのバックエンドと連携して動きます。伝票の構造、マスタデータの持ち方、業務プロセスの流れといった知識は、20年の実務で積み上げてきたものがそのまま武器になります。
BTPを新しく学ぶ若手エンジニアが苦労するのは、実はこうした「SAPの業務知識」の部分だったりします。ここは、経験豊富なABAPerが持つ大きな強みです。
新しく学ぶ必要がある部分
もちろん、すべてがそのまま通用するわけではありません。特に次のような点は、新しく学び直す必要があります。
- プログラミング言語そのもの(Javaの文法、オブジェクト指向の考え方)
- フレームワークの作法(Spring Bootの仕組み、DIやアノテーションの考え方)
- クラウドネイティブな開発スタイル(コンテナ、CI/CD、マイクロサービス的な設計)
- 開発環境の違い(Eclipse ADTからVS CodeやBusiness Application Studioへ)
これらは確かに新しい学習コストですが、「土台となる設計力」がすでにあるぶん、ゼロから学ぶ人よりも習得は早いはずだと感じています。
20年の経験は無駄にならない
「今さら新しい技術を学ぶのはしんどい」と感じるABAPerは多いと思います。私もその一人です。ただ、実際に手を動かしてみると、20年培ってきたものは、言語や環境が変わっても確実に土台として機能することを実感しています。
RAPとCAPは何が違う?ABAPerが最初に知っておきたい開発モデル
最初にぶつかる「RAPとCAP、何が違うの?」問題
BTPやS/4HANAの拡張開発を調べ始めると、必ず出てくるのが「RAP」と「CAP」という2つの言葉です。どちらも「アプリケーションを効率よく開発するためのモデル」という説明がされますが、名前が似ているうえに、どちらもCDSを使うため、最初はかなり混乱しました。
この記事では、20年ABAPをやってきた立場から、この2つの違いを整理します。
RAPとは何か
RAP(ABAP RESTful Application Programming Model)は、S/4HANAの中で動くABAPアプリケーションを、モダンな作法で開発するためのフレームワークです。
- 開発言語:ABAP
- 動作場所:S/4HANA(ABAPスタック上、Embedded/Steampunkシナリオ)
- 主な用途:S/4HANA内での拡張、Fiori向けアプリのバックエンド実装
- データモデル定義:ABAP CDS
つまりRAPは、「ABAPという言語はそのままに、開発の作法だけをモダン化したもの」というイメージです。ABAPerにとっては、文法自体は馴染みがあるため、比較的入りやすいフレームワークだと言えます。
CAPとは何か
CAP(Cloud Application Programming Model)は、BTP上で動くクラウドネイティブなアプリケーションを開発するためのフレームワークです。
- 開発言語:JavaまたはNode.js
- 動作場所:BTP(Cloud Foundry環境やKyma環境)
- 主な用途:Side-by-side拡張、BTP上の独立したアプリケーション開発
- データモデル定義:CDS(ABAP CDSとは別物だが思想は近い)
CAPは、S/4HANAの外、つまりBTPという独立したクラウド環境で動くアプリケーションを作るためのモデルです。開発言語もABAPではなく、JavaかNode.jsを選ぶことになります。
一番の違いは「どこで動くか」
RAPとCAPの一番の違いを一言でまとめると、「S/4HANAの中で動くか、BTPの中で動くか」です。

クリーンコアの文脈で言えば、「S/4HANAの中で完結する拡張はRAPで、外に出す拡張はCAPで」というのが基本的な住み分けになります。
なぜ私はCAPから学ぶことにしたのか
RAPは言語がABAPのままなので、正直、学習のハードルとしてはCAPよりも低く感じます。ただ、私が今回CAPから学ぶことにした理由は次の2つです。
- BTP上のSide-by-side拡張案件が増えており、CAPのニーズが高まっている
- RAPはABAPの延長線上で学びやすい一方、CAPはJavaやクラウドの考え方そのものを学ぶ必要があり、今のうちに挑戦しておきたい
もちろん、RAPも今後このnoteで扱っていく予定です。ただ、まずは自分にとって難易度の高い「CAP」に挑戦し、その過程を記録することの方が、これから同じ道を歩むABAPerの参考になるのではないかと考えました。
BTPには何がある?ABAPer向けに全体像をやさしく整理
BTPは「1つの製品」ではない
BTP(SAP Business Technology Platform)について調べ始めると、あまりに多くのサービスや略語が出てきて、正直なところ最初は面食らいました。ABAPしか知らなかった私にとって、BTPは「1つの製品」ではなく「たくさんのサービスが集まったプラットフォーム」だと理解するまでに、少し時間がかかりました。
この記事では、これからBTPを学ぶABAPerが迷子にならないように、全体像をできるだけシンプルに整理します。
BTPを構成する4つの柱
BTPは非常に幅広いサービス群ですが、大きく次の4つの領域に分けて理解すると整理しやすくなります。
1. アプリケーション開発(Application Development)
BTP上でアプリケーションを開発するための基盤です。今回このnoteの中心となるCAP(Cloud Application Programming Model)や、Fiori/UI5によるフロントエンド開発がここに含まれます。実行環境としては、Cloud FoundryやKyma(Kubernetes環境)があります。
2. インテグレーション(Integration Suite)
S/4HANAや他のSAP製品、外部システムをつなぐための領域です。従来ABAPerがPI/POで実装していたようなインターフェース連携を、クラウド上で実現する仕組みだとイメージすると分かりやすいです。
3. データ&アナリティクス(Data & Analytics)
SAP Datasphere(旧SAP Data Warehouse Cloud)や、SAP Analytics Cloudなど、データ活用・分析のための領域です。ABAP開発者としては馴染みが薄い分野ですが、今後のレポーティング系案件では重要になってきます。
4. AI・自動化(AI / Extensibility)
SAP AI Core/AI Launchpadや、Business Rules、Workflowなど、AIやプロセス自動化に関わる領域です。
ABAPerがまず押さえるべきは「アプリケーション開発」領域
これだけ幅広い領域を全部いきなり学ぶのは現実的ではありません。ABAPerとして、拡張開発の実務にすぐ関わってくるのは、まずはアプリケーション開発(CAP/RAP/Fiori)の領域です。
このnoteでも、まずはこの領域に絞って学習を進めていきます。具体的には以下のような要素が関わってきます。
- CAP(Java / Node.js):ビジネスロジック・データモデルの実装
- CDS:データモデルの定義
- SAP Fiori Elements / UI5:画面(UI)の実装
- SAP BTP, Cloud Foundry環境:アプリケーションの実行基盤
- SAP HANA Cloud:データベース
実行環境の話:Cloud FoundryとKyma
BTP上でアプリケーションを動かす実行環境には、大きく「Cloud Foundry」と「Kyma(Kubernetes環境)」の2種類があります。
- Cloud Foundry:アプリをデプロイすれば動かしてくれる、比較的シンプルなPaaS環境
- Kyma:Kubernetesをベースにした、より柔軟だが学習コストの高い環境
これからCAPを学び始めるABAPerにとっては、まずCloud Foundry環境から入るのが現実的です。このnoteのハンズオンでも、Cloud Foundry環境を前提に進めていく予定です。
ABAP開発との対応関係で理解する
自分の頭の中を整理するために、ABAP開発の要素とBTP(CAP)の要素を、大まかに対応させてみました。

もちろん完全に1対1で対応するわけではありませんが、こうした対応関係を意識すると、新しい概念も「あ、これはABAPで言うところのアレか」と理解しやすくなります。
なぜ最初にCAP Javaを選ぶのか|Node.js版との違いも解説
CAPには2つの選択肢がある
CAP(Cloud Application Programming Model)を学ぼうとすると、必ず最初に出てくる選択肢があります。それが「Java版」と「Node.js版」のどちらで学ぶか、という問題です。
公式ドキュメントを見ても、両方が並列で説明されており、最初はどちらを選ぶべきか迷いました。この記事では、私が最終的に「Java版」を選んだ理由を整理します。
Java版とNode.js版、それぞれの特徴
まずは簡単に、両者の特徴を比較します。

一般的には、「素早く試作したいならNode.js」「エンタープライズ用途でしっかり作り込みたいならJava」という住み分けで語られることが多い印象です。
私がJava版を選んだ理由
理由①:ABAPの静的型付けの感覚に近い
ABAPは静的型付け言語です。変数の型を明確に定義し、コンパイル時にエラーを検知できるという安心感に、20年慣れ親しんできました。
Javaも同じく静的型付け言語であり、「型をしっかり定義してから実装する」という感覚がABAPと近いものがあります。動的型付けであるJavaScript(Node.js)に比べて、心理的なハードルが低く感じました。
理由②:エンタープライズ開発との親和性
これまで20年、企業の基幹システムという「堅牢さ」が求められる世界で仕事をしてきました。Javaは、まさにそうしたエンタープライズシステムの世界で長年使われてきた言語であり、設計思想として「堅牢さ」「保守性」を重視する文化があります。この文化的な親和性も、Javaを選んだ理由の一つです。
理由③:Spring Bootという巨大なエコシステム
CAP JavaはSpring Bootをベースにしています。Spring Bootは、Java開発における事実上の標準フレームワークであり、情報量も非常に豊富です。学習の過程でつまずいたとき、Spring Bootに関する情報は世の中に大量にあるため、解決の糸口を見つけやすいという実利的な理由もあります。
Node.js版が向いている人
もちろん、Node.js版が悪いわけではありません。むしろ、次のような方にはNode.js版をおすすめします。
- とにかく素早くプロトタイプを作りたい
- すでにJavaScript/TypeScriptの経験がある
- 起動の速さや軽量さを重視したい
「習うより慣れろ」でとにかく手を動かしてみたい、というタイプの方には、Node.js版の方が最初の一歩を踏み出しやすいかもしれません。
このnoteではCAP Javaで進めます
このnoteでは、上記の理由からCAP Java(Spring Boot)を使ってハンズオンを進めていきます。ABAPの静的型付けに慣れた方にとっては、Node.js版よりもとっつきやすいはずだと考えています。
CAPを学ぶ前に知っておきたいJava・Spring Boot・CDSの関係
3つの言葉が同時に出てきて混乱した話
CAP Javaの学習を始めると、「Java」「Spring Boot」「CDS」という3つの言葉が、当たり前のように同時に登場します。ABAPしか知らなかった私は、最初「これらがそれぞれ何の役割を担っているのか」がまったく整理できず、ドキュメントを読んでも混乱するばかりでした。
この記事では、ハンズオンに入る前の準備として、この3つの関係を整理しておきます。
それぞれの役割をひとことで言うと
- Java:プログラミング言語そのもの
- Spring Boot:Javaでアプリケーションを作るためのフレームワーク
- CDS:データモデル(データの構造)を定義するための言語
これをABAPの世界に置き換えると、次のようなイメージになります。
- Java → ABAPという言語そのもの
- Spring Boot → ABAPの開発を支える各種フレームワーク(RAPのフレームワーク部分など)
- CDS → ABAP CDS(テーブルやビューの構造を定義するもの)
Javaの役割
Javaは、CAPアプリケーションのビジネスロジックを実装するためのプログラミング言語です。ABAPで言えば、クラスやメソッドの中に業務処理を書いていくのと同じ感覚です。
ただし、Javaはオブジェクト指向を前提とした言語であり、ABAPのように手続き型(関数モジュールのような書き方)で書くことは基本的にありません。この点は、慣れるまで少し戸惑うポイントかもしれません。
Spring Bootの役割
Spring Bootは、Javaでアプリケーションを作る際の「土台」を提供してくれるフレームワークです。CAP Javaは、このSpring Bootの上に構築されています。
具体的には、次のような役割を担っています。
- アプリケーションの起動・設定管理
- HTTPリクエストの受け付け(Webサーバとしての機能)
- 各種コンポーネント同士の連携(DI:依存性注入という仕組み)
ABAPの世界では、こうした「土台の部分」はNetWeaverやRAPフレームワークがある程度面倒を見てくれていたため、あまり意識する機会がありませんでした。Spring Bootを学ぶということは、これまで意識してこなかった「アプリケーションの土台部分」への理解を深めることでもあります。
CDSの役割
CDS(Core Data Services)は、データモデル、つまり「どのようなデータを、どのような構造で扱うか」を定義するための言語です。
ここがABAPerにとって、一番とっつきやすいポイントだと思います。ABAP CDSでビューを定義してきた経験がある方であれば、CAPのCDS定義ファイル(.cdsファイル)を見たときに、「あ、似たようなことをやっているな」と感じるはずです。
// CAP CDSのイメージ(擬似コード)
entity Books {
key ID : Integer;
title : String;
stock : Integer;
}
エンティティを定義し、項目とその型を定義していく感覚は、ABAP CDSと大きくは変わりません。もちろん構文の細部や、できることの範囲には違いがありますが、「データモデルを設計する」という頭の使い方そのものは共通しています。
3つがどう連携して動くのか
最後に、この3つがCAPアプリケーションの中でどう連携しているのかを整理します。
- CDSでデータモデル(エンティティ)を定義する
- CAPのフレームワークが、そのCDS定義から自動的にAPI(OData/REST)を生成する
- 標準の動きだけでは足りないビジネスロジックを、Java(Spring Boot)で追加実装する
つまり、「データの構造はCDSで宣言的に定義し、それだけでは表現できない業務ロジックをJavaで手続き的に実装する」というのがCAP開発の基本的な流れです。
ABAP CDS + RAPの世界に近い部分もありますが、実行される場所(S/4HANAの中か、BTPの外側か)が違う、という点は改めて意識しておきたいポイントです。
「頑張れABAPer」で作るアプリと、これからの学習ロードマップ
第0章のまとめとして
ここまで7本の記事を通じて、なぜ今BTPを学ぶのか、ABAPの経験がどこまで通用するのか、RAPとCAPの違い、BTPの全体像、そしてCAP Javaを選んだ理由について整理してきました。
第0章の最後となるこの記事では、これから「頑張れABAPer」で実際に作っていくハンズオンアプリの概要と、今後の学習ロードマップを示しておきたいと思います。
これから作るアプリについて
このnoteでは、CAP Java(Spring Boot)を使って、シンプルな業務アプリケーションを一つ作り上げていきます。題材は、なるべく多くのABAPerにとってイメージしやすいものにしたいと考え、次のようなテーマを予定しています。
「簡易在庫管理アプリ」
- 商品マスタの登録・参照・更新・削除(CRUD)
- 在庫数の増減を記録する入出庫処理
- 在庫が一定数を下回った商品の一覧表示
- 最終的にはFioriベースの画面をつけて、実際に操作できるアプリに仕上げる
ABAPで言えば、MARA/MARDのようなマスタ・在庫テーブルをイメージした、シンプルながらも実務に近い題材です。壮大なシステムを作るのではなく、あえて「小さく、しかし一通りの要素が揃ったアプリ」を選ぶことで、CAP開発の一連の流れを最短距離で体験できるようにしたいと考えています。
今後の章立て(予定)
第0章で土台となる考え方を整理した後は、次のような流れでハンズオンを進めていく予定です。あくまで現時点での構想であり、進めながら調整していきます。
第1章:WindowsにCAP Java開発環境を作る
- WindowsでCAP開発環境を整理する
- CAP Javaプロジェクトの作成・フォルダー構成の理解
第2章:CDSでテーブルを作る
- Entityの作成
- AssociationとComposition
- CSVファイルから初期データの登録
第3章:サービスを公開する
- service.cds
- CRUD処理
- $filter・$select・$orderbyなど
第4章:Javaで業務ロジックを作る
- EventHandler
- @Before・@On・@Afterの違いを理解する
第5章:CQNでデータを操作する
- CQN
第6章:ActionとFunctionを作る
- ActionとFunctionの作成
第7章:入力チェックとエラー処理
- @mandatory、@assert.range、@assert.format
- CAPのエラーメッセージの日本語化
第8章:ローカルDBとテスト
- CAP JavaでH2データベースを使用する
- H2 Consoleの使い方
- Visual Studio Codeでのデバッグ方法
第9章:BTPトライアルを準備する
- SAP BTPトライアルアカウントを作成する
- BTPのGlobal Account・Subaccount・Spaceを理解する
- MTAとは何か|mta.yamlの役割を理解する
- CAP JavaアプリをBTPへ初めてデプロイする
第10章:HANA Cloudと認証
- ローカルのH2からSAP HANA Cloudへ切り替える
- HDI Containerとは何か
- HANA Cloudへテーブルを作成する
- XSUAAとは何か
第11章:実践アプリを完成させる
- 実践アプリを作成します。
このnoteの進め方について
「頑張れABAPer」は、私自身が学びながら記録していくnoteです。すでに知っている人にとっては物足りない部分もあるかもしれませんが、逆に言えば、同じようにこれから学び始めるABAPerが、つまずくポイントをリアルタイムで共有できるという強みがあると思っています。
うまくいかなかったこと、ハマったポイント、ABAP脳ゆえに勘違いしたことなども、包み隠さず書いていくつもりです。完璧な教科書ではなく、「一緒に頑張る仲間の記録」として読んでいただければ嬉しいです。
次回からは、いよいよ第1章「WindowsにCAP Java開発環境を作る」に入っていきます。
引き続き、頑張っていきましょう。頑張れABAPer。

コメント