暗号を解く：統合の量を見積もる「Steve のゼロの数」！
はじめに
Steve Tech Arc の統合シリーズの新しい回へようこそ！ 今日は、統合プロジェクトの設計段階で統合の量を見積もるという重要な側面を掘り下げます。私が「Steve のゼロの数」と呼んでいる方法が中心です。
なぜ見積もりが重要なのか
システム間で転送されるデータの量を理解することは非常に重要です。それが規模の判断、仕組みの選択、そして特に MuleSoft のような統合レイヤーを使う場合のコンポーネントのスケーリングを左右します。目標は、ビジネスの大まかな目安から出発して、1秒あたりのトランザクション数（TPS）のような重要な指標を導き出すことです。
見積もりのプロセス
基準となる前提：ビジネス側が理解でき、約束できる基準の前提から始めます。正確な数値が得られなければ、「Steve のゼロの数」を使って、扱うのが数十なのか、数百なのか、数千なのか、数百万なのかを見極めます。
業界の指標への換算：この大まかな数字を、統合の見積もりに欠かせない業界標準の単位、たとえば TPS、1秒あたりのレコード数、1秒あたりのバイト数に換算します。統合の活動が持続的なのか、特定の時間帯に集中するのかという活動のパターンも理解します。
実践的な見積もりの例
こうした計算に役立つサンプルのテンプレートを共有しました。1日の活動、トランザクション、レコード、バイトサイズに注目したものです。活動時間帯も、8時間、12時間、あるいはもっと短いのかを決めます。
例となるシナリオ：
ビジネス活動の転送： 成立した商談をリアルタイムで ERP に転送する場合、取引先の数、取引先ごとの月あたりの成立商談数、商談ごとのレコード数、各レコードのデータサイズを見積もれます。
トラック配送の通知： トラックがさまざまな通知を送るシナリオでは、トラックの台数、1日あたりの配送数、配送ごとの通知数、通知ごとのデータサイズを見積もります。
予約の通知： 顧客に予約の通知を送る場合、店舗数、1日あたりの予約数、予約ごとの通知数、通知ごとのデータサイズを見積もります。
エージェントによるケース対応： ケースに取り組むエージェントについては、エージェントの人数、1時間あたりの対応ケース数、ケースごとの更新レコード数、トランザクションごとのデータサイズを見積もります。
まとめ：統合プロジェクトのための実践的な見積もり
プロジェクトの早い段階で統合のトラフィックを見積もることが鍵です。Salesforce を扱うときは、制限を超えないことを確認し、活動時間帯全体で負荷がなめらかになるよう適切なコンポーネントをスケールさせてください。キューやワーカーといった実装の詳細を理解することも、統合チームにとって欠かせません。
こうした方法と前提は、抽象的なビジネス要件を統合チームのための具体的な詳細に落とし込む実践的なアプローチであり、正確な見積もりの基準になります。
お楽しみに
技術のプールに飛び込んでいただきありがとうございました。
さらなる知見と驚きは、この www.SteveTechArc.com と YouTube チャンネル @SteveTechArc (opens in a new tab) で。チャンネル登録して、Salesforce と、それをほかのシステムとどう統合できるかの理解を深めてください。
アーキテクト仲間やアーキテクトを目指す人たちと統合の知識を共有して、世界を変える手助けを！
STA 1.5