同じApex開発ができる人でも、外部連携まで任される人は単価が一段違います。これは腕の差というより、要件定義の場で「設計判断」を任されるかどうかの差です。言われた仕様を実装するだけなら、その作業は誰でも代替できる。だからこそ、どの連携パターンを選び、どこで設計が破綻するかを語れる人は重宝されます。
私自身、中規模ユーザー環境で外部システムとのREST連携を何度か設計してきました。うまくいった案件もあれば、途中で設計をやり直した案件もあります。今日はその経験から、連携案件で単価を分ける判断と、後から効いてくる落とし穴を整理します。
なぜ外部連携ができると単価が上がるのか
Salesforce単体のカスタマイズは、Trailheadと数ヶ月の実務でできる人がそれなりにいます。供給が多い領域は、どうしても単価が上がらない。一方で外部連携は、Salesforceの知識に加えてHTTP通信・認証・相手側システムの事情を読む力が要ります。この「複数領域をまたぐ」性質が、代替の効きにくさを生みます。
レバテックフリーランスの単価相場を見ても、Salesforce案件はスキルの幅で提示レンジに差が出ます。ただしこれは民間の掲載案件ベースで公的統計ではないので、あくまで傾向として見てください。私の周りの感覚でも、設計から入れる人と実装だけの人では、同じ常駐でも月単価で数十万円の開きが出ることがあります。この差がどこから来るのかは、Salesforceエンジニアの年収相場をまとめた記事でも触れました。
重要なのは、連携スキルそのものより「設計判断を言語化できるか」です。指示された設計をそのまま組むだけなら、単価は上がりません。設計判断こそが評価される。
REST連携の3パターン、選ぶときにどこを間違えるか
外部連携の実装方式は、ざっくり3つに分かれます。どれを選ぶかで、後の運用コストが大きく変わります。
| 方式 | 初期コスト | 負荷への強さ | 向くケース |
|---|---|---|---|
| 同期（REST Callout） | 低い | 弱い | 件数が少なく即時応答が要る処理 |
| 非同期（Platform Event・Queueable） | 高い | 強い | 大量データ・相手側が不安定な連携 |
| ハイブリッド | 中〜高 | 強い | 処理ごとに即時性の要否が分かれる実務の多く |
同期連携は一見シンプルで、デモ環境では問題なく動きます。動くから厄介なんです。本番でレコード件数が増えると、1件ずつのCalloutがボトルネックになり、画面がスピナーで固まる。ガバナ制限（1トランザクションあたりのCallout上限）に当たって処理が止まることもあります。
非同期は初期実装が重い代わりに、相手側の一時停止やスパイクに耐えます。ただしイベント設計やエラーの追跡が複雑になり、「どこで失敗したか」を運用で追える仕組みまで作らないと、むしろ障害対応が地獄になります。
実務で最も多いのはハイブリッドです。ただし「この処理は同期、こっちは非同期」という判断基準を最初に決めておかないと、担当者ごとにバラバラな実装が増えて、設計が散逸します。基準を1枚のドキュメントにしておく。これだけで後の保守がまるで変わる。
タイムアウトとリトライを甘く見ると本番で事故る
連携障害の多くは、派手なバグではなく地味な設定不足から起きます。その筆頭がタイムアウトとリトライです。
ApexのHTTP Calloutはタイムアウトを明示指定できますが、ここを意識せず組むと、相手側が重いときに想定外の挙動になります。相手のレスポンスが遅れた瞬間、トランザクション全体が巻き込まれる。私が見た中では、相手APIの一時的な遅延で夜間バッチが毎回途中で落ち、原因究明に数日かかった案件がありました。
リトライが無い設計も危険です。相手側の瞬間的な5xxエラーで全体が止まり、しかも再実行の仕組みが無いので手動でリカバリするしかない。これを運用に押し付けると、毎週のように障害対応が発生します。
- タイムアウト値は相手側の応答特性に合わせて明示する（デフォルト任せにしない）
- 一時エラーは指数バックオフで再試行し、再試行回数の上限も決める
- 最終的に失敗したレコードは、再処理できる形でログに残す
ここを設計時に詰めておくかどうかが、連携の安定性を決めます。ガバナ制限に本番で当たってから気づくと、設計レベルのやり直しになる。
認証設計は「後から変えられない」決定になりやすい
認証・認可は、一度組むと差し替えのコストが高い領域です。だからこそ最初の判断が効きます。
APIキー方式は実装が楽ですが、キーの管理とローテーションが運用の負担になり、セキュリティ要件の厳しい環境では後から突き返されます。OAuthはトークンの更新まで含めて作り込む必要がある代わりに、権限の範囲を細かく制御できます。相手側がどちらを許すかにも左右されるので、要件確認の段階で必ず押さえる。
そしてSalesforce側では、接続情報をコードに直書きせずNamed Credentialに寄せるのが定石です。これを使わずにエンドポイントや認証情報をカスタム設定やコードへ埋め込むと、環境ごとの差し替えが面倒になり、Sandboxから本番へのデプロイで事故ります。後から「全部Named Credentialに移そう」となると、影響範囲の調査から入るので地味に重い。最初から寄せておくのが正解だ。
データマッピングはどこで複雑化するか
連携の見積もりで一番ブレるのが、データマッピングの工数です。単純なJSONの項目対応なら軽いのですが、変換ロジックが絡むと一気に膨らみます。
複雑化の引き金になりやすいのが、Salesforce側のカスタムフィールド設計です。相手システムの1項目がSalesforceの複数項目に分かれていたり、選択肢リストの値が一致していなかったりすると、変換テーブルを挟む必要が出ます。この変換が増えるほど、テストケースも増える。
判断の目安はシンプルです。定期的な一括取り込みで、リアルタイム性が要らないならData Loaderや外部ETLの出番。業務ロジックを挟んだ即時連携が必要ならApexで組む。この切り分けを曖昧にしたまま「とりあえずApexで全部」と進めると、本来ツールで済む処理まで自作してしまい、保守対象が無駄に増える。
設計判断の失敗が、修正コストをどう膨らませるか
連携案件のトラブルは、実装ミスより「最初の設計判断の誤り」から来ることが多いです。代表的なものを挙げます。
| 設計段階の誤り | 本番で起きること | 修正の重さ |
|---|---|---|
| 「リアルタイム必須」と誤読して全部同期 | 件数増でガバナ制限に抵触 | 非同期へ作り直し（重い） |
| バッチ頻度を甘く見積もる | 日中に同期エラーが堆積 | スケジュール再設計＋滞留データの復旧 |
| 失敗条件を列挙していない | 想定外入力で沈黙して止まる | エラー設計の後付け |
特に多いのが1行目です。「リアルタイムで」という言葉を鵜呑みにして全処理を同期にしてしまい、件数が増えた段階で破綻する。本当に秒単位の即時性が要るのか、数分の遅延は許されるのか。ここを要件定義で詰めるだけで、設計は大きく変わります。
正直に言うと、これは人を選びます。言われたことを素直に実装するのが得意な人ほど、「リアルタイム」の言葉をそのまま受け取ってしまう。疑ってかかる姿勢が要ります。
結局、単価を取るのは設計リスクを見積もれる人
最後に、単価の話に戻します。外部連携案件で評価されるのは、実装の速さより「どこで失敗しうるかを事前に言える人」です。
実装手順だけを見積もるエンジニアは、相手側APIの仕様が曖昧なときにそのまま進めて、後で手戻りを食らいます。一方で設計リスクを見積もれる人は、「相手の仕様が未確定なので、確認工数をフェーズに入れます」と言える。この一言が出せるかどうかで、見積もりの精度も信頼も変わります。交渉の場で技術以外の準備を持っていないと足元を見られる話は、単価交渉に失敗する理由をまとめた記事でも書きました。
見積もりを基本設計・詳細設計・実装・テストにフェーズ分けするのも効きます。一括で「連携一式いくら」とするより、どこにリスクが潜むかが相手にも見えて、設計工数を正当に計上しやすい。REST API設計の経験が案件選びと単価にどう効くかは、APIエンジニアの需要と単価を扱った記事も合わせて読むと整理しやすいはずです。
連携案件で差がつくのは、動くコードを書けるかではありません。動かなくなる条件を先に言えるかどうか。そこを語れるようになった時点で、あなたは実装者から設計者の側に回っています。
コメント