AMOREPACIFIC が Kiro でレガシー SAP ECC に AI 駆動開発を導入した方法

概要

この記事はもともと AWS Korea Tech Blog に韓国語で掲載されたものです。韓国語版はこちら。

AMOREPACIFIC の ERP Platform Planning チームは、Kiro の spec-driven development（仕様駆動開発）、MCP サーバー、そして Steering ファイルを活用し、SAP ECC 6.0 上の ABAP と SAPUI5 に AI 駆動開発を導入しました。4 つのプロジェクトを通じて、同チームは最大 72% の生産性向上と 80% のドキュメント作成時間の削減を計測しました。

本記事では、同チームがどのように Kiro をレガシーな SAP システムに接続し、チームのコーディング標準に従うよう構成したかを紹介します。また、Kiro が同チームの Jira ベースのワークフローにどのように組み込まれたか、そしてチームが計測した成果についても取り上げます。

AMOREPACIFIC はグローバルな化粧品企業です。そのブランドには Sulwhasoo、AESTURA、LANEIGE、HERA、IOPE などがあります。市場は韓国、アジア、南北アメリカ、ヨーロッパに及びます。販売は自社店舗、AMOREMALL、および各ブランドの公式オンラインモールを通じて行われています。これらのコマースチャネルは成長を続け、変化し続けています。

図 1: AMOREPACIFIC のオンライン販売チャネルの 1 つである AMOREMALL ライブコマースチャネル。

このブランドポートフォリオとコマースインフラストラクチャの背後には、数十年にわたって構築されてきた SAP ERP システムがあり、ビジネスの大部分を支えています。AI がソフトウェアの書き方を変えていく中で、AMOREPACIFIC の ERP Platform Planning チームは 1 つの問いを立てました。

AI 支援による開発は、レガシーな SAP 環境で機能するのか？

背景

AMOREPACIFIC は NetWeaver 7.40 上で SAP ECC（ERP Central Component）6.0 EHP7 を運用しています。FI、CO、SD、MM といったコアモジュールに加え、同チームは拡張 ERP 機能と SAPUI5 フロントエンドを運用しています。開発者は ABAP バックエンドを SAP GUI で、SAPUI5 フロントエンドを NWDS（NetWeaver Developer Studio）で記述しています。

これらのツールは長年にわたってチームを支えてきました。チームは AI のトレンドに乗り遅れないよう、AI ツールを使って開発者の生産性を高めたいと考えていました。そこで AWS と共同で AI-DLC（AI-Driven Development Life Cycle）フレームワークを定義するプロジェクトを開始しました。プロジェクトは 2025 年 8 月から 2026 年 3 月まで実施されました。

チームは複数の AI コーディングツールを比較し、Kiro を選択しました。汻め手となったのは spec-driven development（仕様駆動開発）です。Kiro はまず、要件・設計・実装計画を網羅した構造化された仕様を作成します。その後、その仕様からコードを生成します。SAP 開発はすでにこの順序で進められています。開発者はコードを書く前に FS/TS（機能仕様書／技術仕様書）を作成します。これにより、チームは Jira ベースのワークフローを変更することなく AI を採用できました。Kiro に SAP システムへのアクセスを与えるため、チームは AWS ソリューションアーキテクトが構築した SAP 専用の MCP サーバーを使用しました。安定性と長期的な保守性の観点から、これが最適だとチームは判断しました。

プロジェクト開始前、チーム独自の分析では、SAP のコンテキストやチームの規約を考慮しない AI コーディングツール単体による生産性向上を 20% から 30% と見積もっていました。

図 2: Kiro の spec-driven development（仕様駆動開発）: コードを書く前の要件・設計・実装計画。

SAP 開発に AI を適用する際の課題

1. GUI ベースの環境

SAP 開発は Web ブラウザではなく SAP GUI 上で行われます。さらに重要なのは、SAP 開発の多くがそもそもコーディングではないという点です。それは GUI を介した構成作業です。SE11 でのテーブル作成、SPRO での設定、PFCG での権限設定などです。これらの作業は AI コーディングツールでは自動化できません。

また、ほとんどの AI コーディングツールは、ファイルシステム上にソースコードが存在することを前提としています。ABAP コードは SAP サーバー内部に存在し、ローカルファイルとしては利用できません。ソース統合がなければ、AI コーディングツールは作業対象を持ちません。

2. MCP サーバーの不在と、限定的な ADT サポート

AI ツールが SAP システムを理解するには、MCP（Model Context Protocol）サーバーが必要です。2025 年 8 月にプロジェクトが始まった時点では、SAP 向けの公式 MCP サーバーは存在しませんでした。チーム独自のカスタム RFC ファンクションモジュール、ABAP の命名規則、SAPUI5 フレームワークのパターンをモデルに渡す手段がなかったのです。

NetWeaver 7.40 上の SAP ECC 6.0 は、SAP S/4HANA と比べて SAP ADT（ABAP Development Tools）のサポートも限定的です。AI ツールはシステムからテーブル構造や RFC ファンクションモジュールを読み取ることはできますが、生成したコードをシステムに書き戻すことには技術的な制約があります。

3. 非標準の SAPUI5 フロントエンド

SAPUI5 開発は ABAP よりも複雑な環境で行われていました。チームは標準の SAP Fiori を使用していません。NWDI（NetWeaver Developer Infrastructure）上で Portal Application Standalone プロジェクトを運用しています。

領域	ABAP バックエンド	SAPUI5 フロントエンド
開発ツール	SAP GUI	NWDS 上の Portal Application
コーディングスタイル	標準 SAP ABAP	社内カスタムフレームワーク
AI 適用の障壁	GUI ベース、ソース統合が限定的	非標準フレームワーク、多数の社内規約

4. モデルが知っておくべき規約

モデルに通常の ABAP や SAPUI5 コードを生成させること自体は難しくありません。本当の課題は、このチームが書くのと同じやり方でコードを生成させることです。

ABAP 側では、チームは長年にわたって蓄積した標準を持っています。TOP、F01、C01 の Include プログラムのパターン、ALV レポートのスケルトン、選択画面の定義などです。SAPUI5 側には、カスタムフレームワーク、IIFE（即時実行関数式）パターン、そして Jira チケットに対して管理される FS/TS ドキュメントシステムが加わります。

ソリューション

AI コーディングツールを単にインストールするだけでは不十分です。これらの課題に対処するため、チームはまず MCP サーバーを通じてシステムのコンテキストを、Steering を通じてコーディング標準を取り込む必要がありました。その両方を AWS とともに解決したことが、このプロジェクトの出発点です。

AI-DLC: SAP 開発に AI を適用する

チームが AWS と共同で設計した AI-DLC フレームワークは、既存の開発ツールを置き換えるものではありません。設計、コーディング、ドキュメント作成の全体にわたって、AI を既存のワークフローに統合するものです。

開発パラダイム	これまで	Kiro と AI-DLC を用いた場合
開発者の役割	コードを書く	要件を定義し、生成されたコードをレビューする
設計とコードの連携	FS/TS を読み、頭の中で翻訳する	Kiro が FS/TS を仕様ドキュメントに構造化する
反復的なボイラープレート	毎回、オートコンプリートを使いながら手作業で記述	確立されたパターンから生成
コーディング標準	各開発者が記憶して適用する	Steering ファイルから自動的に適用される
ドキュメント	開発完了後の別作業	コード生成に合わせて仕様ドキュメントが同期し続ける
知識の依存度	経験豊富な開発者に集中	コンテキストは Kiro から提供され、チーム全体に広がる

要点は、ツールではなくチームの働き方を変えることでした。従来の SDLC（ソフトウェア開発ライフサイクル）では、人が主導しツールが補助します。AI-DLC は重心を移します。人が意思決定し、AI が実行を加速するのです。

このフレームワークは 3 つの構成要素、すなわち Kiro、MCP サーバー、Steering の上に成り立っています。

1. Kiro: 設計を起点とする開発

Kiro は、spec-driven development（仕様駆動開発）をサポートする AWS の AI 駆動開発環境です。チームは目の前の作業内容に応じて、Kiro の 2 つのモードを使い分けました。

図 3: Spec モードと Vibe モードの選択、Steering の構成、MCP サーバー接続を示す Kiro IDE。

Spec モード: 構造化された新規開発。 Spec モードは新規プロジェクトや複雑な機能に適しています。Kiro は要件、次にシステム設計、そして実装計画という 3 段階の設計プロセスを実行します。

図 4: 要件から実装計画までの Spec モードによる自動設計フロー。

Vibe モード: チャットによる高速な反復。 Vibe モードは、すでに仕様ドキュメントが存在するプロジェクトで、会話を通じてコードを素早く変更します。開発者が変更内容を自然言語で説明すると、Kiro は既存の仕様ドキュメントを参照し、コンテキストに適合した変更を行います。

図 5: Vibe モードのプロセスフロー: チャットベースの反復開発。

Spec か Vibe か: どちらのモードをいつ使うか？

領域	Spec モード	Vibe モード
適した用途	新規プログラム、複雑な新機能	既存プログラムの変更、バグ修正
前提条件	Jira チケットと FS/TS ドキュメントまたは要件	仕様ドキュメントがすでに存在すること
Kiro の動作	要件 → 設計 → タスクの 3 つの構造化された段階	チャットでの会話的な変更
スピード	最初に設計へ時間をかけ、その後は体系的に開発	即座のコード変更
成果物	3 つの仕様ドキュメント、ABAP または SAPUI5 コード、DDIC*	更新されたコードと更新された仕様ドキュメント
典型的なシナリオ	新規レポート、新規インターフェース、複雑なビジネスロジック	フィールドの追加・削除、ロジック変更、UI テキスト変更、バグ修正

*DDIC（SAP Data Dictionary）: テーブル、構造、ドメインを定義する SAP のメタデータリポジトリ。

この中核的な実験は、新規要件には Spec モードを、変更には Vibe モードを使うことで、初期設計の品質と保守の俊敏性を同時に実現できるかどうかというものでした。

注: チームは Kiro IDE 0.x を使用しており、チャット開始時に Spec セッションか Vibe セッションを選択します。Kiro IDE 1.0 では、セッションは Vibe モードのように動作する汎用エージェントで開始し、Spec はいつでも開始できる組み込みワークフローになっています。詳細は Kiro IDE 0.x リファレンスを参照してください。

2. MCP: Kiro と SAP をつなぐコンテキストの橋渡し

MCP は、AI IDE と外部システムの間でコンテキストを共有するためのオープンプロトコルです。Kiro を SAP システム内の既存コード、データ構造、ビジネスロジックに接続し、Kiro がそれらを読み取り参照できるようにします。

図 6: MCP サーバーを介して SAP タスクを実行する Kiro。

汎用モデルはプログラミングの方法は知っていますが、この SAP システム内のカスタム RFC ファンクションモジュール、テーブル構造、ビジネスロジックは知りません。MCP サーバーがそのコンテキストをモデルに渡します。Kiro に ZXXX_GET_EMPLOYEE_DATA RFC ファンクションを呼び出すコードを生成するよう依頼すると、MCP サーバーはそのファンクションのパラメータ構造、戻り値、使用例をリクエストとともに提供します。

チームは MCP サーバーをユーザーレベルで一度 ~/.kiro/settings/mcp.json に構成し、ABAP RFC ファンクションモジュールと SAPUI5 バックエンドの RFC の両方を分析するようにしました。この構成は AMOREPACIFIC の SAP 開発者のすべての Kiro プロジェクトに適用されるため、新しいプロジェクトごとに環境を再構築する必要はありません。

注: AWS はその後、SAP 向けの Kiro サンプルエージェントを公開しました。それらには 80 以上の事前構築ルールを含む Steering ファイルが含まれ、機能仕様書と技術仕様書を生成し、ABAP コード変換と単体テストを自動化します。ABAP に加えて、SAP BW から SAP BDC（Business Data Cloud）への変換、および SAP PI/PO から SAP Integration Suite への変換のための Kiro エージェントもあります。はじめるには、Kiro で SAP モダナイゼーションを加速を読み、サンプルエージェントの GitHub リポジトリへのアクセスを登録してください。

3. Steering: AMOREPACIFIC のコードの書き方を Kiro に教える

Steering は、モデルの振る舞いをガイドする一連のドキュメントです。Kiro はコードを生成するたびに ~/.kiro/steering/ 内のファイルを自動的に参照します。チームのコーディング標準は、誰かがプロンプトを書かなくてもコードに反映されます。

汎用モデルは、このチームの変数命名規則、Include 構造、エラーハンドリングのパターン、g.get() フレームワークの使い方を自力では守りません。Steering ファイルがそのギャップを埋めます。チームがコードの書き方を一度ドキュメント化すれば、Kiro が生成するものはすべて、詳細なプロンプトなしにそれらの標準に従います。

チームは ABAP 用と SAPUI5 用の Steering ファイルを別々に用意しました。

図 7: 組織のコーディング標準ガイドとしての Steering: 汎用コードジェネレーターが Steering ファイルを参照することで社内標準に従う。

Steering ファイル	対象範囲	何を伝えるか
`product.md`	共通	SAP ECC 6.0 環境、モジュール構成、ビジネスルール
`tech.md`	ABAP	ABAP コーディング標準、命名規則、Include 構造
`structure.md`	共通	プロジェクトのディレクトリ構造、成果物フォーマット
`sapui5-development.md`	SAPUI5	NWDI Portal Application ガイド、`g.get()` API、IIFE パターン、ERP 通信パターン、`_new` サフィックスルール
`design_doc_template.md`	共通	FS/TS 成果物テンプレート、Jira チケットフィールド

アーキテクチャ: Jira から SAP まで

ECC 6.0 の書き戻し制約を回避するため、Kiro は生成したコードを共有フォルダに書き出し、開発者がそれを SAP に移します。図 8 は Jira チケットから SAP システムまでの全体フローを示しています。

図 8: Jira チケットから Kiro と共有フォルダを経て SAP GUI および NWDS に至るアーキテクチャ。

ここで FS/TS が Spec モードにマッピングされます。Jira チケットの要件は requirements.md に、FS/TS 設計ドキュメントは design.md に、作業分解は tasks.md になります。このマッピングのおかげで、チームは既存プロセスを大きく変えることなく Kiro と連携できました。Jira ベースの要件管理と AI コード生成が、いまやつながっています。

ABAP は SAP GUI（ABAP エディター用の SE38、ABAP ディクショナリ用の SE11）を介して SAP に、SAPUI5 は NWDS を介して SAP に投入されます。このアプローチはどの SAP リリースでも機能し、レビューステップが組み込まれています。生成されたコードがシステムに到達する前に、開発者がチェックするのです。

ABAP と SAPUI5 のための AI-DLC プロセス

チームの AI-DLC フレームワークは以下のプロセスで実行され、ABAP バックエンドと SAPUI5 フロントエンドの双方に同じように適用されます。

図 9: ABAP と SAPUI5 のための 6 ステップの AI-DLC プロセス。

ステップ 5 はステップ 4 にループバックします。エラーが発生すると、開発者は Kiro と協力してコードを修正し、再適用します。

ステップ	主な活動	成果物
1. 環境をセットアップする	Kiro をインストールし、MCP サーバーを接続し、Steering ファイルを配置する	稼働する開発環境
2. ドキュメントを準備する	Jira チケットを確認し、既存の FS/TS を `docs/` フォルダに保存する	`requirements.md`（Jira の詳細が自動的に取り込まれる）
3. モードを選択する	新規開発 → Spec、変更 → Vibe	なし
4. コードを生成する	Kiro が Steering ルールに従ったコードを生成する	ABAP（`.abap`）、SAPUI5（コントローラーとビュー）、DDIC（TSV）
5. システムに適用する	生成されたコードを SAP GUI または NWDS を介して SAP に移す	アクティベートされたオブジェクト、トランスポートリクエスト
6. クローズアウトする	仕様ドキュメントを同期し、FS/TS 成果物を生成する	Jira チケットにリンクされた FS/TS 成果物（`.md` または `.html`）

このプロセスを支える 1 つの原則があります。コードが変わるとき、その変更のもとになったドキュメントも一緒に変わる、ということです。コードと仕様ドキュメントは常に一緒に動くため、設計とコードの乖離がその源で取り除かれます。

成果

およそ 8 か月にわたり、チームはこの働き方を 4 つのプロジェクト、すなわち 1 つの ABAP バックエンドプロジェクトと 3 つの SAPUI5 フロントエンドプロジェクトに適用しました。プロジェクト開始前、チーム独自の分析では生産性向上を 20% から 30% と見積もっていました。4 つのプロジェクトにわたるチーム自身の計測では、AI-DLC フレームワークと MCP サーバーによって生産性が最大 72% 向上しました。成果物とソースコードも最新の状態に保たれ、設計とコードが同期し続けました。

パイロット 1: ABAP バックエンド、Spec モードによる新規開発

目標: Kiro の spec-driven development（仕様駆動開発）を新規要件に適用し、AI-DLC フレームワークを検証する。

プロジェクト: 新しい SAP レポート（Jira チケット ERP-101）。

結果: 既存のフローはシンプルですが反復的でした。Jira チケットが起票され、開発者が FS/TS を書き、コードを書き、レビューに持ち込む、という流れです。Kiro はそのフローを変えました。Spec モードは FS/TS を requirements.md、design.md、tasks.md に変換します。また、TOP と F01 の Include や ALV レポートのスケルトンを含むボイラープレートを、DDIC TSV ファイルとともに生成します。反復的な作業がなくなったことで、開発者は要件の検証とビジネスロジックの実装に集中できるようになりました。

パイロット 2: SAPUI5 フロントエンド、Spec モードと Vibe モードの併用

目標: 新規開発には Spec モードを、変更には Vibe モードを使い、AI-DLC が SAPUI5 環境にも拡張できるかを検証する。

プロジェクト: HR 勤怠管理画面の改善（ERP-102）、HR 承認プロセスの変更（ERP-103）、新しい HR モバイルビュー（ERP-104）。

結果: SAPUI5 Portal Application 開発には、NWDI 独自のフォルダ構造（ui.pdk.{code}、_comp/dist/mvc/）、カスタムフレームワーク、IIFE パターン、ファイル管理ルールが伴います。経験豊富な開発者でもミスをする領域です。sapui5-development.md という 1 つの Steering ファイルを追加するだけで、これらのルールがすべて自動的に適用されました。

ドキュメントも変わりました。FS/TS 成果物は design_doc_template.md から生成されるようになり、ドキュメント作成時間が 80% 削減されました。Jira チケット番号、タイトル、依頼者が自動的に取り込まれるため、チームは 100% の要件トレーサビリティを得ました。

2 つのパイロットが改善したもの

領域	これまで	AI-DLC を用いた場合	効果
Jira チケットからコードへ	FS/TS を書き、その後に手作業でコーディング	Kiro の Spec モードが構造化する	要件の解釈にかかる時間が短縮
反復的なボイラープレート	毎回手作業で記述	Kiro が生成	初期コーディング時間が短縮
コーディング標準	レビュー時に手作業でチェック	Steering から自動的に適用	コードレビューのサイクルが短縮
DDIC 定義（ABAP）	SE11 で手作業で入力	生成された TSV から貼り付け	DDIC オブジェクト作成時間が短縮
FS/TS 成果物	開発後に手作業で記述	Kiro が生成	ドキュメント作成時間が 80% 削減
スタック間の壁	ABAP と SAPUI5 は分離されたまま	両者にまたがる 1 つのフレームワーク	開発者がスタック間を移動できる
仕様とコードの同期	しばしばずれる	100% で同期	長期的な保守コストの低減

定性的な成果

数字以上に重要なのは、開発者がいま何をしているかという変化です。AI-DLC 以降、開発者はコードを 1 行ずつ打ち込む時間が減り、要件を検証し Kiro が生成したものをレビューする時間が増えました。

Steering はまた、技術スタック間の壁を下げました。ABAP 開発者がいまや SAPUI5 Portal Application の構造を読み、それを直接変更できます。ABAP パイロットに参加したある開発者は、その後 SAPUI5 である 2 つ目のパイロットに貢献しました。

新人開発者にとって、かつての主な障害はカスタムフレームワークの呼び出し構造と NWDI の複雑なフォルダレイアウトでした。Steering がその学習曲線を吸収します。開発者はいまや、その時間を構造の解明ではなく開発に充てられます。結果として、チームは新人開発者のオンボーディング時間が短縮されると見込んでいます。

4 つのプロジェクトはすべて、仕様ドキュメントとコードを 100% 同期させた状態に保ちました。仕様が先に書かれ、そこからコードが生成されるためです。Jira チケット、FS/TS、コーディング、ドキュメントという別々の段階が、いまや 1 つのフローになりました。Jira チケット → Kiro Spec モード → 生成されたコード → 生成された FS/TS 成果物です。

今後の展望

AMOREPACIFIC はこのプロジェクトを出発点ととらえ、次のステップを準備しています。

1. GitLab リポジトリ統合。 チームは Kiro プロジェクトフォルダ（.kiro/specs/、ABAP_Code/、ui.pdk.{code}/、docs/）を、バージョン管理とコラボレーションのために AMOREPACIFIC の GitLab に保存する計画です。仕様ドキュメント（.md）、生成されたコード、FS/TS 成果物を Git で管理することで、チームは変更履歴を得て、チーム全体での共有を日常的なものにできます。

2. Jira と Confluence の MCP 統合による、エンドツーエンドの自動化。 今日、開発者は Jira の Web インターフェースからチケットの詳細を Kiro にコピーしています。Jira MCP 統合が整えば、Kiro はチャットから直接 Jira の課題を照会し、それを仕様ドキュメントに取り込めます。Kiro に Jira チケット ERP-102 の要件から仕様ドキュメントを作成するよう依頼すると、Jira API を通じてチケットを取得し、requirements.md を生成します。開発後は、FS/TS 成果物を Confluence にアップロードします。これにより、Jira → Kiro → SAP → Confluence というエンドツーエンドのフローが完成します。

3. AI コーディングアンバサダー。 AI-DLC の経験が最も豊富なパイロット開発者が、Steering ドキュメントの作成を指導し、他チームに 6 ステップのプロセスを教え、トラブルシューティングを支援することで、他チームへの展開を推進します。

まとめ

AMOREPACIFIC は、手が届かないように見えていた GUI ベースのレガシーな SAP ECC 6.0 環境に AI 駆動開発を導入し、4 つの ABAP および SAPUI5 プロジェクトに適用しました。

このプロジェクトの核心は新しいテクノロジーではありません。人を中心とした開発から AI を中心とした開発へという、チームの働き方の転換です。Kiro の spec-driven development（仕様駆動開発）のアプローチ、AWS ソリューションアーキテクトが構築した SAP MCP サーバー、そして Steering ドキュメントが一体となって、AI が組織のコーディング標準に従えるようにしました。チーム自身の計測では、プロジェクト前の 20% から 30% という見積もりに対し、生産性は最大 72% 向上しました。成果物とソースコードは最新の状態に保たれ、設計とコードは同期し続けました。spec-driven development（仕様駆動開発）が SAP の既存の FS/TS 設計文化と合致していたため、開発者はほとんど抵抗なくそれを採用しました。

AMOREPACIFIC の経験が、レガシーシステムの制約を理由に AI 導入をためらっているエンタープライズの開発チームにとって役立つことを願っています。このアプローチを試すには、次のとおりです。

Kiro からはじめ、AI-Driven Development Life Cycle について読んでください。
SAP 向けの Kiro サンプルエージェントについては、Kiro で SAP モダナイゼーションを加速で詳しく学び、サンプルエージェントへのアクセスを登録してください。ABAP 向け、BW から SAP BDC への変換、PI/PO から Integration Suite への変換のためのエージェントがあります。
AI-DLC に関する別のお客様事例については、AI-DLC で Woongjin ThinkBig の Book Curator AI エージェントを構築する（韓国語）を参照してください。

ご自身の SAP 環境に向けた AI 駆動開発を計画するには、担当の AWS アカウントチームにお問い合わせください。

このエンゲージメントを当初から AMOREPACIFIC とともに主導し、その成功の鍵を握った、元 AWS SAP ソリューションアーキテクトの Sejun Kim 氏に特別な感謝を申し上げます。

著者について

Jinho Wang は AMOREPACIFIC の ERP Platform Planning チームを率い、ERP プラットフォームを担当しています。SAP ERP を中心とするエンタープライズシステムの企画と運用を通じて、ビジネスの安定性と効率性を高めてきました。現在は、日々の業務をより速くシンプルにするため、クラウドと生成 AI を ERP 運用に取り入れています。デジタルトランスフォーメーションと AI トランスフォーメーション（AX）を支える ERP プラットフォームの改善を続けています。

Dayoung Hu は AMOREPACIFIC の ERP Platform Planning チームでグローバル ERP 財務領域を統括し、ビジネスに合わせた財務・トレジャリーシステムの構築と運用を主導しています。海外子会社の複雑なビジネス要件をシステムに標準化し、プロセスを最適化することに注力し、グローバルグループ全体でデータ駆動の意思決定ができる透明性の高い効率的な環境づくりに取り組んでいます。ビジネスフローと IT の架け橋として働き、AMOREPACIFIC のグローバル展開と安定したシステム運用に貢献しています。

Jaehyeok Choi は AMOREPACIFIC の人事情報システム（HRIS）テクニカルプロジェクトマネージャーであり、SuccessFactors と SAP HR 上に構築された HR システムの統合と運用を主導しています。複雑なレガシーシステムと SaaS ソリューションの間のデータ同期とプロセス最適化を通じて、HR の意思決定のためのデータ中心の環境構築に注力しています。技術的な深さと HR ビジネスフローの架け橋として働き、安定的で効率的な HR 環境に貢献しています。

Jonghyuok Kim は AWS のソリューションアーキテクトで、小売・消費財（CPG）業界のお客様のクラウドジャーニーに伴走しています。Haein は、お客様のビジネス課題を理解し、AWS サービスを効果的に活用してイノベーションと成長を推進できるよう支援しています。

Haein Lim は AWS のソリューションアーキテクトで、製造・小売業界のお客様のクラウドジャーニーに伀走しています。Haein は、お客様がビジネス課題を理解し、AWS サービスを効果的に活用してイノベーションと成長を推進できるよう支援しています。

Whye Loong Wong は AWS の SAP パートナーソリューションアーキテクトで、ERP とエンタープライズアーキテクチャにおいて 20 年以上の経験を持ちます。ASEAN 全域の SAP パートナーおよびお客様と連携8、SAP ワークロードの AWS への移行とモダナイゼーションを支援しています。彼の焦点は、エンタープライズシステムを AI で拡張すること、すなわち SAP データを解き放ち、お客様がエンタープライズシステムと連携するエージェント型 AI ソリューションを構築できるよう支援しています。

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。

Amazon Web Services ブログ