MuleSoftでAPI開発工数を見積もるための実践テクニック

MuleSoftでAPI開発工数を見積もるための実践テクニック

MuleSoftは、様々なシステム間連携をハブ＆スポーク型でつなぎ合わせるiPaaS（Integration Platform as a Service）製品です。

MuleSoftは単純にAPIリクエストをルーティングするだけでなく、ローコードでAPIアプリケーションを開発することが可能で、より柔軟で要件にあったシステム間連携を実現することができます。

一方、ローコード開発が発生することから、導入初期の段階で「APIのローコード開発の工数をどう見積もればよいか？」と悩む方も少なくありません。
本記事では、MuleSoft特有の3層アーキテクチャ （Experience / Process / System） を踏まえながら、上流工程でのAPI開発工数見積もりの進め方を実践的に解説します。

なお、3層アーキテクチャについては、 マイクロサービス視点から見たMuleSoftの特徴 の記事でも紹介しております。こちらを是非ご覧ください。

本記事は、上流工程における工数見積の考え方の一例を示したものであり、その精度を保証するものではない点にご注意ください。実際の見積は、本記事で紹介する内容以外の要素も踏まえ、十分に検討してください。

対象読者

• MuleSoft導入プロジェクトの見積もり担当者
• API開発の工数算出に課題を感じている方

本記事で得られること

• API開発工数の見積もり手順（4ステップ）
• 見積もり時に注意すべきポイント
• 見積もり担当者に求められるスキルセット

本記事の対象範囲と前提

まず、MuleSoft導入に関わる見積もりは、大きく以下の3つに分類できます。

本記事では、以下の「2.のAPI開発工数」を対象とします。

1. MuleSoftライセンス費用
2. API開発工数
3. MuleSoftのプラットフォーム構築工数

本記事では、以下の範囲を対象としています。

• 工程：基本設計〜結合試験
• 対象API：MuleSoft上でローコード開発するAPI（MuleSoftの接続元／接続先システム側で必要となる開発・改修は含めない）

なお、本記事では以下の範囲を対象に含みません。

• MuleSoftのような採用技術・製品に依らずに発生する業務要件定義工程の工数
• MuleSoftの接続元／接続先システム側で必要となる開発・改修の開発工数

MuleSoft特有の見積もりの難しさ

MuleSoftにおけるAPI開発では、以下のような点が見積もりの難易度を高める要因となります。

• 3層構造（Experience / Process / System）を踏まえたAPI分割が必要
  • MuleSoftはマイクロサービスアーキテクチャを採用しており、外部からコールされるAPI等を起点に、複数のAPIを連携させることで全体の処理を実現していきます。
  • そのため、3層構造を踏まえた内部APIの構造を見積に反映しないと、想定外の設計・実装・テストが発生してしまいます。
• API再利用や統合の有無が初期段階では不明確
  • 前述のとおり、3層構造による内部APIの分割を踏まえる必要はありますが、その分割方針等は見積時点で決定していないことが多く、過剰・過少に工数を見積もってしまうリスクがあります。
• 方式面・業務面で難易度の高いIFが存在する
  • IFの中には、実現に複雑な処理方式が必要となるもの、業務ロジックの難易度が高いもの、非機能要求が高いもの、などが含まれている可能性があります。
  • これらのIF個別の難易度を考慮せずにAPIあたりの工数を一律で見積もってしまうと、過少に工数を見積もってしまうリスクがあります。
  • 特に、技術的な難易度は見積時点での見極めが難しく、見落とされやすい部分です。

本記事ではMuleSoftのプラットフォーム設計には言及しませんが、実際には、以下のようなプラットフォームに関する工数も発生します。

• Anypoint Platform上の構成・設定・公開作業
• Exchangeへの登録
• API Managerでの公開
• ポリシー設定

工数見積もりの進め方（4ステップ）

API開発工数の見積もりは、次の4ステップで進めるとスムーズです。

• Step1. 外部インターフェース情報の整理と一覧の作成
  • 接続元・接続先のシステムやプロトコルなどを洗い出し、外部IF一覧にまとめます。見積もりの粒度やスケジュールに応じて、ここで仮見積もりを止めることも可能です。
• Step2. API構成図の仮設計
  • 外部IF一覧をもとに、3層アーキテクチャに沿ってAPI構成を仮設計します。見積もりのための初期構造設計となります。ここでは再利用や統合は考慮せず、最大数でカウントします。
• Step3. 統合・再利用の検討
  • 類似APIの統合、System層の再利用などを検討し、API数を見直します。見積精度を高める際に実施するステップです。
• Step4. 工数換算と難易度評価
  • 各APIに対して、難易度・工数を見積もります。

3層アーキテクチャをどのようなシステム設計思想に基づき、構成・詳細化していくかについては、様々な考え方があります。
本記事では、主に接続元・接続先システムの構成に基づきAPIを分割する考え方を採用していますが、たとえば、業務ドメインの観点でAPIを分割するような考え方もあるかと思います。
本記事で紹介するのは「アーキテクチャに基づいてAPIの工数を見積る」というコンセプトであり、実際のアーキテクチャは要件や設計思想をもとに、十分に検討してください。

Step1. 外部インターフェース情報の整理と一覧の作成

まずは、APIの接続元・接続先に関する情報を洗い出します。プロジェクト計画書や構成図、機能一覧、接続元・先のインターフェース一覧などから以下の観点で整理しましょう。

項目	説明
インターフェース名称	インターフェースを一意に特定できる名称。仮称でOK。
利用タイミング	当該インターフェースによる連携が発生するタイミングと頻度。オンラインであればTPS、バッチであれば月次、日次、随時など
連携元/先システム名	連携元・先のシステムを一意に特定できる名称。仮称でOK。
プロトコル	HTTP(s)、SFTP、メッセージングなど

この情報を整理した結果が、見積もりの前提となる「外部インターフェース一覧」となります。

情報が不足している場合は、お客様や接続元・先システムの有識者などへのヒアリングも検討します。

Step2. API構成図の仮設計

外部IF一覧をベースに、MuleSoftの3層アーキテクチャに沿ったAPI構成図を仮設計します。ここではAPI数を多めに見積もる（余裕をもたせる）のがポイントです。

• Experience層：ユーザー向けAPI（送信元AP用）
• Process層：ビジネスロジック統合API
• System層：データ接続用API（送信先AP用）

この段階ではAPIの統合は考慮せず、外部IFから想定されるAPIを最大限用意します。

以下のような方針で各層のAPIを想定します。

• Experience層：接続元システムから呼び出される外部IFの数だけ、E層APIを用意します。
• Process層：E層APIごとに1対1で対応するよう、P層APIを用意します。
• System層：接続先システムを呼び出す外部IFの数だけ、S層APIを用意します。

このように構成することで、現時点ではAPIの統合や再利用は考慮せず、最大数をベースに見積もることができます。

Step3. 共通化の検討

仮設計したAPI構成に対し、類似APIの共通化や不要APIの削除の可能性を検討します。

例えば以下のような観点で見直しを行います。

• Experience層
  • 単純なE層APIをまとめた多機能APIへの共通化
  • 接続元システムが同一で、処理内容が接続元に依存しないAPIの共通化
• Process層
  • 類似処理を行うP層APIの共通化
  • 複雑な業務ロジックが不要なP層APIの削除
• System層
  • 同一接続先を利用するS層APIの共通化

ただし、APIの共通化は、開発・保守の複雑化を招く可能性もあるため、共通化する処理の複雑さ・開発体制やスケジュール・再利用の見込みなどを踏まえ、適切に判断する必要があります。

Step4. 工数換算と難易度評価

Step3で見直したAPI構成に基づき、各APIごとに難易度や見積工数を割り当てます。

IF単位での実現難度、非機能要件、MuleSoft特有の処理を踏まえ、難易度ランクに応じた係数などで工数換算することが一般的です。

ここでいうMuleSoft特有の処理とは、非同期処理（Async scope等）・モックAPI（Mocking Serviceによる試作／テスト）・APIポリシー設定（認証／アクセス制御／レート制限など）を指します。

見積もり担当者に求められるスキル

上流工程でAPI開発工数を見積もる際、担当者には以下のスキル・経験が求められます。

• MuleSoftの3層構造とAPIレイヤーの役割を理解している
• IF定義書やジョブ設計書から接続内容を読み取れる
• システム構成資料をもとにAPI数や難易度を推定できる
• 業務部門とのコミュニケーションで不明点をヒアリングできる

まとめ：見積もり成功のポイント

MuleSoft導入時のAPI開発工数見積もりでは、早期の構造整理とスコープ明確化が重要です。
特に大規模案件では、早期に以下の視点を整理しておくことで、後続工程の混乱を防ぐことができます。

• どの範囲を
• どの観点で
• どの単位で

導入の初期段階では、精緻な見積もりが難しいこともしばしばあります。
しかし、APIの構造を明確にし、段階的に精度を上げていくプロセスを踏むことで「大きくは外さない」見積もりに近づくことができ、その見積もりプロセスこそがMuleSoftを有効活用する第一歩になると思います。