本記事は 2025 年 5 月 19 日に公開された How Amazon maintains accurate totals at scale with Amazon DynamoDB を翻訳したものです。翻訳は Solutions Architect の嶋田 朱里が担当しました。 Amazon の Finance Technologies Tax チーム (FinTech Tax) は、世界中の法域で税額計算、税額控除、納付、報告といった重要なサービスを管理しています。このアプリケーションは、複数の国際マーケットプレイスで年間数十億件の取引を処理しています。 この投稿では FinTech Tax チームが Amazon DynamoDB のトランザクションと条件付き書き込みを使用して、段階的な源泉徴収を実装した方法を紹介します。 これらの DynamoDB の機能を使用することで、拡張性と回復力があるイベント駆動の税額計算サービスを構築し、大規模でもミリ秒レベルのレイテンシーを実現しました。 また、一貫したパフォーマンスを実現しながら、データの正確性を厳密に維持するための設計上の決定と実装の詳細についても探ります。 要件 Amazon は複数の法域にまたがる複雑なフィンテック (金融技術) 分野の税制環境で事業を行っており、さまざまな源泉徴収税の要件を管理する必要があります。同社には、膨大な取引量を処理できる堅牢な税処理ソリューションが必要です。このシステムは、毎日数百万件の取引をリアルタイムで処理し、個人ごとの累積取引額の正確な記録を源泉徴収税計算のために維持する必要があります。主な要件には、段階的な源泉徴収税率を正確に適用すること、および Amazon の既存システムとのシームレスな統合が含まれます。このソリューションはデータの整合性と高可用性を維持し、さまざまな源泉徴収税制度に対する規制遵守をサポートする必要があります。 課題 主な課題は世界中の複雑に絡み合った税法に厳密に準拠することにあります。特に、段階的課税モデルでは、個人の総取引額が財務年度内の特定の閾値を超えるかどうかに基づいて、異なる源泉徴収税率が適用されます。個人の累積取引額が増加し、あらかじめ定義された閾値を超えると、その取引に適用される源泉徴収税率が変更されます。例えば、総額が 100,000 インドルピー (INR) に達するまでは低い税率が適用され、その閾値を超えると、より高い税率が適用されます。 次の図は、累積取引金額の閾値に基づいて税率が段階的に変化する様子を示した、3 段階の税率モデルを示しています。 段階的課税モデルの課題は、源泉徴収についてリアルタイムの計算を行いながら、各個人の累計取引額を正確に追跡・記録管理することにあります。 Amazon は 1 日に数百万件のトランザクションを処理しなければなりません。 さらに、正の取引・負の取引（例：プラスまたはマイナスの会計調整）に関わらず、正しい源泉徴収税率をリアルタイムで適用することが求められます。 これには高い取引量 (個人あたり約 150 トランザクション/秒) を処理しながら、正確な記録を維持できるシステムが必要です。 ソリューションの概要 次の図は Amazon の源泉徴収税計算サービスの全体アーキテクチャです。 ワークフローは以下のステップで構成されています: クライアントが Amazon API Gateway に源泉徴収税計算リクエストを送信します。 API Gateway が税額計算 (Tax Computation) AWS Lambda を呼び出します。 税額計算 Lambda 関数が、DynamoDB の個人の累積トランザクションストア（Cumulative Transaction Store）テーブルを取得します。累積トランザクションストアテーブルは過去の累計値をもとに、ユーザーごとの累積取引金額をリアルタイムで管理します。これにより、段階的な税率を適用するための個人の累積取引金額の合計を正確に追跡できます。 Lambda 関数は取引の詳細と個人の累計金額に基づいて、ルールエンジンライブラリから適用される税率を取得します。取得した税率と取引データをもとに、税額が計算されます。 計算結果は取引データの監査と履歴管理のために DynamoDB の取引監査ストア (Transaction Audit Store) に格納されます。 現在の取引金額をもとに、個人の累積取引金額が累積トランザクションストアに更新されます。 DynamoDB 操作中に発生する一時的なエラー (例: ConditionalCheckFailed 、 TransactionConflict ) は、 Amazon Simple Queue Service (Amazon SQS) キューに送られ、再試行されます。 クライアントエラー (400 Validation Exception、401 Unauthorized、403 Forbidden など) や永続的なサーバー障害によるエラーは、SQS DLQ で処理されます。 実装上の考慮事項 トランザクションを受信すると、システムはルールエンジンから導出された閾値に対して個人の累積取引額を評価して、適用される税率を判断します。その後、累積取引金額は累積トランザクションストアに更新され、監査証跡も記録されます。 複数のスレッドが同一個人のデータベースを同時に更新しようとすると、競合が発生します。一般的な 楽観的排他制御 (OCC) の手法は、累積値を読み取り、指定範囲の値に対する税率を計算し、累積値が読み取り以降変更されていないという条件付きでトランザクションを書き込みます。もし値が変更されていた場合はループの最初から処理をやり直します。 トラフィックが多い場合、この再実行が頻繁に発生する可能性があります。 私たちのアプローチは、一般的な OCC パターンを改良したものです。条件の判定を「累積値が最初に読み取った時点の範囲内に留まっているか」のみに絞っています。 累積値が変化しても、その値が閾値を超えない限り、ループを再実行する必要はありません。 この方法により、条件の不一致が少なくなるため、スループットが上がります。個人の累積値がより高い範囲に移行した場合は、書き込み操作が失敗します。 その場合は、更新された値をもとに、読み取りと書き込みを再試行する必要があります。 OCC 戦略とは異なり、このアプローチでは最後の読み取り以降に値が変化していても処理が成功します。これにより、競合を最小限に抑え、スループットを向上させることができます。同時更新（累積合計が閾値を超えるケース）によって条件付き書き込みが失敗し、 ConditionalCheckFailedException が発生することがありますが、これは想定された動作であり、データの不整合を示すものではありません。 一時的なエラーを処理し、同じトランザクションの重複処理を防ぐために、クライアント要求トークン (Client Request Token, CRT) を含んだ TransactWriteItems 操作を実行することで、インクリメント操作を冪等性のある状態で行えます。 TransactionCanceledException は、 エクスポネンシャルバックオフ などのエラー処理メカニズムで処理されます。 この戦略の組み合わせにより、システムはデータの整合性を維持しながら、高いスループットとスケーラビリティを実現できます。 複雑なロック機構が不要になり、従来のOCCソリューションと比べて効率性が向上します。また、大規模な設定やチューニングを必要とせず、さまざまなトランザクション量や同時実行レベルに柔軟に対応できる、高性能なソリューションを提供します。 累積トランザクションストア 累積トランザクションストアテーブルは、特定の個人の取引金額の累積和を維持するために使用されます。以下のデータモデルを使用します: { "indvidual_id": { "S": "TIN1" // 累積合計を管理する単位となる一意識別子 }, "cumulative_amount_consumed": { // 使用された金額の累積合計を表す "N": "0" } } 税控除対象品目の在庫管理 税額控除監査ストア（Tax Deduction Audit Store）テーブルは、各取引の税控除率の監査記録を保存するために使用されます。以下のデータモデルを使用します: { "transaction_primary_key": { "S": "XXX111#2024-01-01T13:05:28" // トランザクションの一意識別子(PartitionKey#SortKey) }, "transaction_amount": { "S": "1000". //トランザクション全体の金額 }, "transaction_tax_amount": { "S": "100". //控除される税額 }, "transaction_tax_rate":{ "S":"10". //このトランザクションに適用される税率(パーセント表記) } ... } 条件付き書き込みのコード 次のコードは dynamodb.transact_write_items() を使用して、累積トランザクションストアと取引監査ストアの 2 つの DynamoDB テーブルにまたがるアトミックな条件付き書き込み操作を示しています。累積トランザクションストアから既存のレコードを取得し、現在の取引金額と既存データに基づいて cumulative_amt_consumed  （累積消費金額）の更新値を計算します。同時に、取引監査ストアに新しいレコードを記録し、ID、値、税額、税率などのトランザクション詳細を記録します。 transact_write_items() メソッドは、取引トランザクションストアテーブルへの更新操作と取引監査ストアテーブルへの put 操作を 1 つのトランザクションとして実行します。 2 つの操作がともに成功すれば、両方のテーブルに変更がコミットされます。そうでない場合は、トランザクション全体がロールバックされ、データの整合性が保たれます。 SAMPLE_TIN = 'TIN1' # 累積トランザクションストアにおける一意の識別子を表す SAMPLE_AMOUNT = 5000 # transact_write_items で処理される売上値を表す SAMPLE_TRANSACTION_ID = 'XXX111' DEFAULT_TAX_RATE = 10 # 既定の税率(パーセンテージ値) LOWER_TAX_RATE = 5 # 低い方の税率(パーセンテージ値) RETRYABLE_ERRORS = ( 'TransactionConflictException', 'ConditionalCheckFailedException', 'ProvisionedThroughputExceededException', 'ThrottlingException', 'ServiceUnavailableException', 'InternalServerErrorException' ) MAX_RETRIES = 3 RETRY_DELAY = 0.1 # 秒 def send_to_error_queue(error_message, is_retryable, transaction_id): queue_url = 'TransientErrorQueue' if is_retryable else 'NonTransientErrorQueue' message_body = { 'error_message': error_message, 'transaction_id': transaction_id } try: sqs.send_message( QueueUrl=queue_url, MessageBody=json.dumps(message_body) ) except Exception as e: print(f"Failed to send message to {queue_url}: {str(e)}") def process_transaction(tin, amount, transaction_id): for attempt in range(MAX_RETRIES + 1): try: response = dynamodb.get_item(TableName='CumulativeTransactionStore', Key={'cumulativeStore_primary_key': {'S': tin}}) item = response.get('Item') if not item: print("Record not found.") return cumulative_amount_consumed = int(item.get('cumulative_amount_consumed', {}).get('N', '0')) threshold_value = int(item.get('threshold_value', {}).get('N', '0')) current_amount = amount if (cumulative_amount_consumed + current_amount < threshold_value): update_expression = 'SET cumulative_amount_consumed = cumulative_amount_consumed + :val, tax_rate = :tax_rate' tax_rate = DEFAULT_TAX_RATE max_value = threshold_value min_value = 0 else: update_expression = 'SET cumulative_amount_consumed = cumulative_amount_consumed + :val, tax_rate = :tax_rate' tax_rate = LOWER_TAX_RATE max_value = sys.maxsize min_value = threshold_value expression_attribute_values = { ':val': {'N': str(current_amount)}, ':tax_rate': {'N': str(tax_rate)}, ':lo': {'N': str(min_value)}, ':hi': {'N': str(max_value)} } dynamodb.transact_write_items( TransactItems=[ { 'Update': { 'TableName': 'CumulativeTransactionStore', 'Key': {'cumulativeStore_primary_key': {'S': tin}}, 'UpdateExpression': update_expression, 'ConditionExpression': 'cumulative_amount_consumed < :hi AND cumulative_amount_consumed >= :lo', 'ExpressionAttributeValues': expression_attribute_values, } }, { 'Put': { 'TableName': 'TaxDeductionAuditStore', 'Item': { 'transactionID': {'S': transaction_id}, 'transaction_amount': {'N': str(amount)}, 'transaction_tax_amount': {'N': str(amount * tax_rate / 100)} } } } ], ClientRequestToken=transaction_id ) print(f"Transaction processed successfully on attempt {attempt + 1}") return # Success, exit the function except Exception as e: error_code = e.response['Error']['Code'] error_message = f"Error accessing DynamoDB: {error_code} - {e.response['Error']['Message']}" is_retryable = error_code in RETRYABLE_ERRORS if is_retryable and attempt < MAX_RETRIES: print(f"Retryable error occurred on attempt {attempt + 1}. Retrying...") time.sleep(RETRY_DELAY * (2 ** attempt)) # Exponential backoff else: send_to_error_queue(error_message, is_retryable, transaction_id) # If we've exhausted all retries error_message = f"Max retries ({MAX_RETRIES}) exceeded. Last error: {error_message}" send_to_error_queue(error_message, True, transaction_id) # Main execution try: process_transaction(SAMPLE_TIN, SAMPLE_AMOUNT, SAMPLE_TRANSACTION_ID) except Exception as e: print(f"Transaction processing failed: {str(e)}") 結果 システムのパフォーマンス評価では、実行時間を 30 秒に固定し、スレッド数を変えながら一連のテストを実施しました。 各実行後に累積トランザクションストアをゼロにリセットすることで、さまざまな負荷条件下でのシステムの動作を包括的に分析しました。 1 スレッドから 130 スレッドにスケールアップするにつれて、処理されたトランザクション数が一貫して増加したことから、システムが大規模な並列処理の場面においても高い並行性を効果的に処理できることが示されました。 しかし、この処理能力の向上には一時的な競合の増加が伴いました。これは、大規模な並列処理の場面において、パフォーマンスと競合管理のトレードオフを浮き彫りにしています。 一時的なアクセスの競合は、複数のトランザクションが同時に同じアイテムを更新しようとしたときに発生し、一部のトランザクションがキャンセルされることになります。このデータが示すのは、スレッド数を増やしても競合管理のオーバーヘッドが増大するため、スループットが大幅には向上しなくなるということです。 次のグラフはスレッド数とトランザクションメトリクスの相関関係を示しています。 これにより、スループットと競合率が同時実行スレッドの増加に伴ってどのように変化するかがわかります。 結論 この投稿では、Amazon Fintech チームが DynamoDB の強力な条件付き書き込み機能を使用することで、段階的税率アプリケーション向けのシンプルかつ高いスケーラビリティを持つソリューションを実装した方法を紹介しました。 この手法を採用し、まれに発生する ConditionalCheckFailedException を先に見越して処理することで、大量の同時トランザクションが発生するシナリオにおいても、高いスループットとスケーラビリティを実現しながら、データの一貫性を維持することができます。 この手法は、同時リクエスト数が増加するにつれボトルネックになりがちな楽観的ロックの必要性をスマートに排除しています。代わりに、Amazon Fintech システムは DynamoDB の組み込みの同時アクセス制御メカニズムを活用し、高負荷状況でも一貫したデータと効率的な更新を可能にしています。 拡張性のあるトランザクション処理システムを独自に実装するには、DynamoDB の 条件付き更新 機能を確認してください。詳しいガイダンスが必要な場合は、DynamoDB の ドキュメント を参照するか、AWS サポートにお問い合わせください。 著者について Jason Hunter はカリフォルニア在住の Amazon DynamoDB 専任のプリンシパルソリューションアーキテクトです。2003 年から NoSQL データベースに携わっています。Java、オープンソース、XML への貢献で知られています。 DynamoDB の投稿 や Jason Hunter が書いた他の投稿は、 AWS Database Blog で見つけることができます。 Balajikumar Gopalakrishnan は、Amazon Finance Technology の Principal Engineer です。 2013 年から Amazon に在籍し、Amazon の顧客の生活に直接影響を与える技術を通じて、実世界の課題を解決してきました。 仕事以外では、ハイキング、絵画、家族と過ごすことを楽しんでいます。また、映画好きでもあります。 Jay Joshi は、Amazon Finance Technology のソフトウェア開発エンジニアです。 2020 年から Amazon に在籍し、主に世界各地の法域での税額計算とレポーティングのためのプラットフォームの構築に従事しています。 仕事以外では、家族や友人と過ごしたり、新しい料理の行き先を探索したり、バドミントンをするのが好きです。 Arjun Choudhary は 2019 年からAmazon の Finance Technology 部門でソフトウェア開発エンジニアとして働いています。主な業務は、グローバルな法人税の源泉徴収プラットフォームの開発です。仕事以外では、小説を読んだり、クリケットやバレーボールをしたりして楽しんでいます。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 以前は自社の戦略について書きましたが、今回は視点を変えてみます。 これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。 目次 はじめに：SaaSの普及と、残された「巨大な壁」 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 1. Fit to Standard（ERP一本足打法） 2. Two-Tier ERP（2層構造：ERP × SaaS） 3. Composable ERP（レゴブロック型） 4. SaaS Unbundling（脱SaaS・完全内製回帰） 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか SI（システムインテグレーション）の課題 ── 「要件定義」の壁 AI × BPOの課題 ── 「ブラックボックス化」の壁 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology 「データ」に「意味」を与える (Ontology) 異なる言語を翻訳する「万能翻訳機」 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 AIが「働く」ための地図 おわりに：バックオフィス・プロダクトの解像度を高める はじめに：SaaSの普及と、残された「巨大な壁」 ここ10年で、日本のSaaS市場は劇的な進化を遂げました。クラウド上の優れたツールを契約し、IDを発行すれば、その日から最新のUI/UXで業務ができる──。これが「当たり前」となり、多くの企業で生産性が向上しました。しかし、この成功法則が通用しない領域が依然として存在します。それが、巨大な歴史と複雑な業務構造を持つ「エンタープライズ企業」の基幹業務領域です。 「SaaSを導入したけれど、既存の基幹システムとデータがつながらない」 「現場独自の複雑なオペレーションが、標準機能ではカバーしきれない」 「結局、CSVデータを手作業で加工してアップロードする業務が残った」こうした声は、SaaSベンダーとエンタープライズ企業の双方が抱える深い悩み（ペイン）です。なぜ、便利なSaaSが増えても、現場の苦しみはなくならないのか。その解像度を高めるためには、まず現在企業が置かれている「システム・アーキテクチャの現在地」を知る必要があると思っています。 本記事では、企業の基幹システムが辿ってきた自分なりに整理した「4つのアーキテクチャ」と、既存の「SIやBPO」が抱える課題を整理した上で、その全てを突破するために現れた新しいアプローチ──「専属シェフ（FDE）」と「万能翻訳機（中間システム）」について自分なりに市場の状況を踏まえて解説をまとめてみました。 これは単なるツールの話ではなく、これからのバックオフィスプロダクトが向かうべき、ひとつの進化系統樹の話と思ってもらえればと思います。 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 「専属シェフ」や「万能翻訳機」という新しい概念を理解するために、まずは現在、エンタープライズ企業がどのようなシステム構造の上に成り立っているのか、その類型を見ていきましょう。大きく4つのパターンに分類されます。 1. Fit to Standard（ERP一本足打法） 最も伝統的かつ、かつての「理想形」とされたモデルです。SAPやOracleといった巨大なERPを導入し、会計・人事・販売・在庫など、企業のあらゆるデータを一つの巨大なシステムで管理します。 特徴： 「業務をシステムに合わせる」思想。データが一元管理されるため、経営層には理想的です。 課題： 現場にとっては「使いにくさ」が壁になります。UI/UXよりもデータ整合性が優先されるため、単純な経費精算にも多大な工数がかかります。また、日本固有の商習慣に合わせるための追加開発（アドオン）により、保守コストが高騰しがちです。 2. Two-Tier ERP（2層構造：ERP × SaaS） 現在、多くの日本企業が採用している現実解です。「本社やコア業務（会計など）は重厚なERPで守り、現場業務（労務、SFAなど）は軽快なSaaSで攻める」というハイブリッド構成です。 特徴： 守りと攻めのバランス型。現場はモダンなSaaSを使えるため、生産性が上がります。 課題： 「データの分断」が最大のネックです。社員マスターがERPにもSaaSにも点在し、それらをつなぐために「月末にCSVを吐き出し、手加工して取り込む」というアナログ作業が残ります 3. Composable ERP（レゴブロック型） Two-Tierをさらに推し進め、巨大なERPを置かずに「各業務における最強のSaaS（Best of Breed）」をレゴブロックのように組み合わせてシステム群を構成する考え方です。 特徴： 「会計はfreee」「人事はSmartHR」「営業はSalesforce」のように最適解を選べ、変化に強い構成です。 課題： インテグレーションの難易度が極めて高い点です。API連携がうまくいかないとデータがサイロ化（孤立）し、全体が見えなくなります。強力な情シス（コーポレートエンジニア）組織が不可欠です。 4. SaaS Unbundling（脱SaaS・完全内製回帰） AIの進化により、近年テック企業を中心に注目され始めた「揺り戻し」です。「SaaSは機能過多で高い。AIを使えば自分たちで必要なシステムを安く作れるのではないか？」という発想です。 特徴： 汎用SaaSを使わず、自社DBの上にAI支援で独自アプリを構築します。コスト削減と業務への完全適合がメリットです。 課題： 「作った人しか直せない」という属人化リスクと、セキュリティや品質保証をすべて自社で担う重責が発生します。 欧州フィンテック大手Klarnaが有名な例です kigyolog.com 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか 上記の4つのアーキテクチャには、それぞれ一長一短があります。「あちらを立てればこちらが立たず」の状況です。 この課題を解決しようとする際、企業が次に検討するのは、 伝統的な「SI（システムインテグレーション）」か、あるいは近年台頭してきた「AI × BPO（AIを活用した業務委託）」 だと思います。しかし、エンタープライズの「ラストワンマイル」においては、これらもまた決定打になり得ない現実があるように思います。 SI（システムインテグレーション）の課題 ── 「要件定義」の壁 SIは「建物を建てる（＝システムを作る）」ことには長けています。しかし、SIモデルの前提は「要件が固まっていること」です。 「今の業務をそのままシステム化してください」と依頼しても、現場の業務は複雑怪奇なマクロや暗黙知で動いており、誰も正解を知りません。結果、要件定義に半年かかり、完成した頃にはビジネス環境が変わっている──。これが「ウォーターフォール型の限界」です。 AI × BPOの課題 ── 「ブラックボックス化」の壁 一方で、「AIを使って業務ごとアウトソースする（AI × BPO）」というアプローチも増えています。これは即効性がありますが、本質的には「人の作業をAIに置き換えただけ」です。 業務プロセス自体がブラックボックス化し、社内にデータ資産やノウハウが蓄積されません。また、AIが誤った判断（ハルシネーション）をした際、背後にあるデータ構造（オントロジー）が整備されていないため、原因究明が困難になります。 「SIのように外から作る」のでもなく、「BPOのように外に出す」のでもない。 既存のSaaS群も、SIも、BPOも解決しきれなかった「断絶」。これを埋めるために必要なのが、 「内側に入り込み、業務を回しながらシステムを進化させる」 という、第3のアプローチがでてきています。 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) そこで登場するのが、 FDE（Forward Deployed Engineer） という概念です。 彼らは「SIer」とも「BPOスタッフ」とも異なります。あえて言うなら、 「エンジニアリング能力を持った、現場専属の解決請負人」 です。「調整」ではなく「実装」で解決する。 SIerが「仕様書」を作る間に、FDEは「プロトタイプ」を作ります。 BPOが「マニュアル通り」に作業する間に、FDEは「マニュアルを不要にする自動化」を行います。彼らは顧客のオフィスの最前線（Forward）に入り込み（Deployed）、以下のように動きます。 APIがない？ → 「ならDBのダンプから直接データパイプラインを作ります」 現場のエクセルが複雑？ → 「そのロジックをPythonで解析し、システムに移植します」 SIのような「納品して終わり」ではなく、BPOのような「作業代行」でもない。 既存の冷蔵庫（レガシーシステム）にある食材（データ）を、その場で極上の料理（モダンな業務フロー）に調理して提供する「専属シェフ」。このアジャイルなアプローチは、全体最適の大改修ではなく“詰まりやすい部分”から小さく改善を重ねることで、エンタープライズの組織・プロセスの制約下でも変革を進めやすくします。 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology FDEという高度人材が活躍するためには、彼らが振るう「包丁」となるシステム基盤が必要です。それが「中間システム」であり、その核となる「Ontology（オントロジー）」です。 「データ」に「意味」を与える (Ontology) 従来のデータベースは「行と列」の羅列に過ぎません。SIで開発するシステムや、AI × BPOで使うツールも、往々にして「その業務専用のデータ定義」になりがちです。 しかし、中間システムにおけるOntologyは、データそのものではなく「業務の実体（Concept）」を中心にデータを再定義します。 従来： Table_A.col_1 と Table_B.id を結合（人間が都度判断） Ontology： Customer has many Contracts（データ自体が意味を持つ） 現実世界の業務の関わり合い（コンテキスト）をそのままデータ構造として定義することで、システムは裏側の複雑なDB構造を知らなくても、「顧客の契約状況を教えて」と問うだけで正しいデータを引き出せるようになります。 異なる言語を翻訳する「万能翻訳機」 エンタープライズには、SAPやOracle、野良エクセルなど、異なる言語（プロトコル）で話すシステムが乱立しています。 ここに「 中間概念（データやシステム）」を配置することで、レガシーとモダンをつなぐ「万能翻訳機」 としての役割を果たさせます。 入力（レガシー）： 古いシステムからFDEがパイプラインでデータを吸い上げる。 処理（翻訳）： 吸い上げたデータをOntologyに基づいて「意味のある情報」に変換・統合する。 出力（モダン）： AIエージェントやSaaSが、整理されたデータにアクセスする。 この「中間概念(データやシステム)」が存在することで、企業は巨大な基幹システムをリプレイスすることなく（＝冷蔵庫を買い替えることなく）、最新のAI活用（＝プロの料理）を享受できるようになります。 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 この 「FDE × 中間概念（Ontology）」 という構造は、これからのバックオフィスプロダクトにおいて、AIを活用するための必須条件となります。 AIが「働く」ための地図 生成AIやAIエージェントが実業務で機能するためには、コンテキスト（文脈）が必要です。単にマニュアルを学習させるだけでは不十分で、「今、この瞬間の会社の状態」を正確に把握していなければなりません。 中間システム上のOntologyは、まさに 「AIにとっての地図」になります。 「A社の請求書が遅れている」という事実だけでなく、「A社は重要顧客であり、過去に同様のケースでは担当者が電話でフォローしていた」という文脈をAIが理解できて初めて、AIは単なるツールを超え 、「自律的なエージェント」として機能します。 つまり、中間システムを構築することは、単なるデータ統合ではありません。 SIのように「箱」を作るのでもなく、BPOのように「人」で埋めるのでもなく、「企業そのものをデジタルツイン（デジタルの双子）化し、AIが自律的に働ける環境（ワークスペース）を整えること」なのです。 おわりに：バックオフィス・プロダクトの解像度を高める 「Fit to Standard」から「SaaS Unbundling」まで、企業のシステムは揺れ動いてきました。しかし、どの時代、どのアーキテクチャにおいても、「データをつなぎ、業務を流す」という本質的な課題は残されたままでした。 「専属シェフ（FDE）」と「万能翻訳機（中間システム）」のアプローチは、既存のSaaS群やSIモデルを否定するものではありません。むしろ、過去の遺産（レガシーデータ）と未来の技術（AI/SaaS）を、技術と泥臭さで接着する新しいアプローチなのではと思っています。 古い文字コードとの戦い、複雑怪奇な勘定科目のマッピング、例外だらけの承認フロー......。 そうした「泥臭い現実」を、高度な抽象化技術（Ontology）と実装力（FDE）で包み込み、ユーザーには「魔法のようなシンプルさ」として提供する。これこそが、この領域のプロダクトマネジメント、エンジニアリングの真の面白さであり、深淵なる魅力ではないでしょうか。 それを支える中間概念（Ontology）思考。 これらはまだ耳慣れない言葉かもしれませんが、数年後には企業のバックオフィス構造を支える、当たり前のインフラになっているかもしれないと感じています。 もし、こうした「複雑さを技術で解きほぐす」アプローチや、社会の基盤となるバックオフィスプロダクトの進化に興味を持っていただけたなら、ぜひこの広大なフィールドを一緒に探求していければと思います。 この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

はじめに KNと申します。 2025年2月に株式会社 エニグモ に入社し、プロダクトマネージャー(PdM)として約1年が経過しました。 前職では新卒でWeb系企業にエンジニアとして入社し、3年間従事しました。 文系出身ながら AWS でのインフラ構築・メンテナンスからバックエンド・フロントエンドの開発まで、幅広く経験しました。 その後、社内転職でPdMへとキャリアをシフトし、 フィンテック サービスのグロースを担当していました。 私が エニグモ への転職を決めたのは、20年続く「 BUYMA 」というプロダクトが持つ圧倒的な蓄積に惹かれたからです。 しかし同時に、「歴史があるがゆえに、動きが遅く、 部分最適 の調整に追われるのではないか」という懸念もありました。 結果として、この1年間で得られたものは予想を遥かに超えるものでした。 この記事では、 エニグモ で経験した学びと、20年続くプロダクトの「厚み」がもたらす価値について記します。 自身の業務領域 BUYMA は世界180カ国、22.5万人以上のパーソナルショッパー(出品者)が支える、唯一無二の「お買い物代行」プラットフォームです。 現在、私は BUYMA の 「出品者領域(SELL)」と、決済・配送・基盤を支える「サービスインフラ(SI)」 の2つを横断して担当しています。 SELL領域: 出品者がいかにストレスなく、質の高い出品を行えるか SI領域: 配送、決済、CS、 経理 。取引の全工程を支える「心臓部」 この2つを同時に見ることは、一見すると負荷が高いように思えます。 しかし、「出品の仕様変更が、数カ月後の 経理 処理やCSの問い合わせにどう影響するか」を予見しながら動く経験は、プロダクトを「機能の集合体(点)」ではなく「エコシステム(面)」として捉える視座を私に与えてくれました。 エニグモ の組織図 入社の決め手:20年の蓄積がもたらす土壌 転職活動をしていた当時、私が最も重視していたのは「自身の仮説構築や施策立案の精度を向上させること」でした。 前職の新規事業では、スピード感を持って施策を回していましたが、比較対象となる過去データが少なく、「打席には立つが、なぜ当たった(外れた)かの深い洞察」が不足している感覚がありました。 2005年から続く BUYMA には、膨大な成功と、それを上回る「失敗の経験」があるのではないかと仮定していました。それは、自身が望む次の仮説を研ぎ澄ませるために非常に魅力的な場所だと感じました。 あえて歴史のある環境に身を置くことで、中長期的な時間軸での「判断の軸」を手に入れ、今後どのようなフェーズのプロダクトでも通用するPdMになりたいと考えたのが、入社の最大の理由です。 www.buyma.com 入社後の学び ①バランス感覚が求められる エニグモ で最も鍛えられたのは、複数の視点を同時に持ち、 全体最適 を追求するバランス感覚です。 入社後に手がけた印象的なプロジェクトに、 経理 が企画を行った出品者に関連する機能開発がありました。 このプロジェクトは、 経理 、カスタマーサポート、出品者側の マーケティング 、エンジニア、デザイナーという多様な職種が集まったチームで進行しました。 プロジェクトの仕様決めの場面で、私は初めて「歴史の重さ」を実感しました。 経理 上の運用フローもあり、社内ニーズとユーザーニーズを調和させた運用となっていました。 その上で、機能開発という観点から出品者にとっての使いやすさ(ユーザービリティ)も確保しなければなりません。 さらに、問い合わせが発生した際のカスタマーサポートの対応負荷も事前に検討しておく必要がありました。 このように、1つの意思決定が複数の部署に影響を及ぼします。 そして、20年の歴史があるプロダクトでは、1つのルールを変更するだけでも、システム的にもビジネス的にも背景が膨大にあるため、定点を見て結論を出すことができません。 エニグモ では「出品者・購入者・ プラットフォーマー としてのルール作り・ルールを維持するための運用的可能性」という多面的な視点を同時に持つ必要があります。 この多面的なバランス感覚こそ、今後どのようなプロダクトに関わっても活かせる、PdMとしての 生存戦略 の核だと感じています。 ②組織のノウハウに対する レバレッジ エニグモ には、社歴が長い人が多く在籍しています。 先輩方は BUYMA の歴史を肌で知り、過去の成功と失敗を体験してきています。 ※平均勤続年数は6.3年（2025年10月時点) 入社当初、私は自分がまだ知らない領域について不安を感じていました。 しかし、実際に働いてみて気づいたのは、「自分がすべてを知っている必要はない」ということでした。 重要なのは、知識を持っている人が何を気にしていて、どのようなデータがあり、組織としてどこでバランスを取るべきかを考え、意思決定に繋げることです。 多くのプロジェクトでは、過去の事例やデータが膨大にあるため、各部署の担当者の背景理解や考慮すべき点の想定を事前から広く取ることが可能です。 例えば、カスタマーサポートのメンバーに相談すると、「過去に類似の仕様変更を実施した際、こういった問い合わせが急増した」という実例を教えてくれます。 経理 企画のメンバーに相談すると、「この処理フローは○年前にこういう理由で導入された」という背景を共有してくれます。 また、過去の意思決定に関するドキュメントが残っているため、ノウハウの探索がしやすいのも大きな利点です。 考慮しなければならない箇所や、とある対応策を取ろうとした時のメリット・デメリットの整理がしやすくなります。 これらの知見は、組織に蓄積された「ノウハウ」です。 エニグモ では「誰に聞けば良いか」「どのデータを見れば良いか」「過去のどのドキュメントを参照すれば良いか」を知っていれば、圧倒的に速く、精度の高い意思決定ができます。 そして、PdMの役割は、そのノウハウを レバレッジ として活用し、最適な意思決定を導くことです。 この組織知へのアクセス能力は、AIが進化しても決して代替されない、人間ならではの強みだと考えています。 ③意思決定の質とスピード エニグモ では、開発案件に応じて スクラム や アジャイル を使い分けながら開発を進めています。 サービスインフラ(SI)領域を例にとる、ビジネスサイドは10〜15名程度、エンジニアが5〜8名程度、PdMが2名程度で進行しており、密に連携しながら施策を推進します。 驚いたのは、意思決定のスピードと質の両立です。 前職では、スピード重視で施策を回していましたが、データが不足しているために「やってみなければわからない」という状況が多くありました。 一方、 エニグモ では20年分のデータとノウハウがあるため、「過去の類似施策ではこうだった」「このセグメントのユーザーはこう動く」という根拠に基づいた意思決定ができます。 また、AI活用も積極的に進められています。例えば、 BUYMA には「AIでさがす」機能があり、Vertex AI SearchやGeminiを活用し、より BUYMA らしい商品提案が可能になりました。 『「AIでさがす」サービスのリニューアル』について このように、歴史という「深い土壌」とAIという「速い道具」が揃っていることで、意思決定の質とスピードが同時に高まっています。 AIによって解決できる課題の量と幅は拡張されていますが、「何を解くべきか」を判断するのは人間の役割です。 そして、その判断の精度を高めるのが、プロダクトの厚みから得られる「物事の見方」と「意思決定プロセスの判断軸」です。 歴史の重さと向き合う難しさ ここまでポジティブな面を中心に書いてきましたが、正直に言えば、苦労したポイントもあります。 各部署との調整と、歴史の重さを考慮した意思決定は、想像以上に難しいものでした。 1つのルールを変更するにしても、その変更がシステム的にもビジネス的にも背景が膨大にあるため、定点を見て結論を出すことができません。 複数の部署の意見を聞き、過去のドキュメントを読み込み、データを分析し、そして 全体最適 を追求する。 このプロセスは、スピード重視の新規事業とは異なる難しさがあります。 しかし、この「難しさ」こそが、PdMとしての成長を促してくれていると感じています。 なぜなら、今後どのようなプロダクトに関わっても活きる「面と深さを考えながらプロダクトを進行する」という実践知を経験できているからです。 今後やっていきたいこと この1年間で、私はプロダクトを「点」ではなく「面」で捉える視座を手に入れました。 SELL領域とSI領域を横断して担当することで、出品者の体験、購入者の体験、そしてそれらを支える基盤( 経理 ・配送・決済)、すべてが繋がっていることを実感しています。 しかし、まだ「面」のすべてを理解しているわけではありません。 今後は、一部門だけでなく、ユーザー体験全体を「面」で捉え、形にしていくことに挑戦したいと考えています。 エニグモ には、歴史という「深い土壌」と、AIという「速い道具」が揃っています。 この環境だからこそ、幅広く、深く、そして「形」にして、面としてのプロダクト磨きに取り組めると確信しています。 BUYMA は20周年を迎え、さらなる進化を続けています。私自身も、この蓄積の中で、PdMとしての 生存戦略 を磨き続けていきたいと思います。 エニグモ で働く魅力 最後に、 エニグモ で働く魅力をまとめます。 プロダクト・人材面でしっかりとした土壌がある 20年分のデータとノウハウ、そして社歴の長いメンバーが持つ知見。これらは、新規事業では決して得られない「厚み」です。 過去の意思決定に関するドキュメントが残っているため、ノウハウの探索がしやすく、考慮すべき点の整理が圧倒的に速くなります。 幅広く・高速にチャレンジができる AI活用や アジャイル 開発により、意思決定のスピードと質が両立されています。 若手でも裁量を持ってプロジェクトを推進できる環境です。 「AIでさがす」機能や類似画像検索の内製化など、最先端の技術を活用した施策に取り組めます。 バランス感覚が磨かれる 経理 ・出品者・カスタマーサポート・プロダクト全体という多面的な視点を持つことで、どのプロダクトにも通用する「究極のバランス感覚」が身につきます。 　「専門性か、汎用性か」で迷うあなたへ。 エニグモ には、専門性を深めながら、汎用性も高められる環境があります。 AIに奪われない組織知を レバレッジ として活用し、プロダクト開発を通じて自己成長できる場所です。 もし、あなたがキャリア形成に不安を感じているなら、 エニグモ という「最強の土壌」で、一緒にプロダクトを磨いていきませんか。 株式会社 エニグモ すべての求人一覧 hrmos.co