APIをつなぐ仕事は、コードを書く前に境界を決める仕事です。どこまで自分が保証し、どこから相手に委ねるか。この線を引かないまま実装に入ると、障害が起きたときに誰が動くのかが定まらず、現場の消耗だけが積み上がります。IPAの調査を手がかりに、つなぎ目の設計をどう引き受けるかを整理します。

1. つなぎたい意識と、引かれていない境界

作る側に根付くAPIやデータ形式をそろえる意識

サーバーサイドの案件で最初に問われるのは、コードの書き方ではなく境界の引き方です。APIを介して外部とつなぐこと自体は、もう特別な作業ではありません。IPAの調査でも、APIの活用や標準的なデータの形式をそろえる取り組みは、作る側を中心に意識が高いと示されています¹。

つなぐことへの抵抗が薄れたのは、現場にとって前向きな変化です。ただし、意識が高いことと、境界が明確なことは別の話です。つなぐ準備はできても、つないだ先の責任をどこで切るかは、別に決める必要があります。

現場に追いついていない境界の設計

IPAの調査では、モジュール性やデータモデルを意識した設計に取り組む企業は、依然として少ないことも示されています¹。つなぐ意識よりも、境界を設計に落とし込む力のほうが、現場に届いていないということです。

この差は、案件の現場で日々目にする感覚と重なります。外部のAPIをつなぐこと自体は難しくありません。難しいのは、そのAPIが変わったとき、止まったとき、どちらの側が何を確かめるかを、あらかじめ決めておくことです。つなぐ技術よりも、境界を決める判断のほうが、経験の差になります。

図の作成：Remogu編集部。責任の境界という考え方を整理したもので、統計データではありません

この判断がどこで身につくかは、案件によって差があります。境界がすでに引かれている現場では、その線をなぞる経験になります。境界がまだ無い現場では、自分で線を引く経験が積めます。積み重なる力は、それぞれ異なります。

境界が引かれていない現場では、障害の一報が来た瞬間に「誰が見るか」から話し合いが始まります。この遅れは、技術の巧拙ではなく、設計段階での取り決めの有無から生まれています。つなぎ目を設計する立場に立つなら、まずこの取り決めを言葉にすることが仕事の起点になります。

境界を引いた記録は、次の案件で自分の経験を説明するときの材料にもなります。何を保証し、何を相手に委ねたかを言葉にして残しておくと、参画先が変わっても同じ形で伝えられます。

境界を決める作業は、地味に見えて骨が折れます。だからこそ、そこを引き受けられる経験は、参画先にとって価値のある材料になります。次章では、外部との接続がどれだけ前提になっているかを、数字で確かめます。

2. 外部との接続が前提になっている

一部の判断ではなくなった外部サービスの利用

つなぐ相手は、社内のシステムだけではありません。IPAの調査では、外部のサービスや製品を、一部での利用を含めて6割強の企業が活用していると示されています¹。つなぐか、つながないかという選択肢は、すでに現場から消えつつあります。

外部への接続が前提になった以上、案件の現場で問われるのは「つなぐかどうか」ではなく「つないだ先をどう扱うか」です。つなぐ技術よりも、つないだ後の運用を見立てる力のほうが、評価される場面が増えています。

利用の広がりに追いつかない方針の整備

一方で、外部サービスの利用に関する方針を整備している企業は、全体の約半数にとどまっています¹。つなぐ実態が先に進み、決め事が後から追いかける形です。境界を設計する立場からすると、この差が仕事の入り口になります。

方針が整っていない現場に入るときほど、境界を自分から言葉にする動きが役立ちます。決め事の不在を嘆くよりも、最小限の合意を先に置くほうが、つなぎ目の設計者としての仕事になります。

利用の広がりと方針整備の差

つなぐ実態が先に進み、決め事が後から追いかける状態は、案件に入ってから戸惑う原因になります。どの程度の開きがあるのかを、事前に数字で押さえておくと、境界を設計する立場としての動き方も変わってきます。以下は、外部サービスの活用の広がりと、利用に関する方針の整備という、2つの観点を並べたものです。整備が追いついていない現場ほど、境界を自分の言葉にしておく価値は大きくなります。

観点	目安となる割合	何を示すか
外部サービスの活用（一部での利用を含む）	6割強1	つなぐこと自体は、すでに現場の前提になっている
利用に関する方針の整備	約半数1	決め事の整備は、実態を追いかけている状態

表からも分かるとおり、利用の広がりと、決め事の整備には開きがあります。この開きを埋めるのは、規約を書く作業だけではありません。つないだ先が変わったときに、誰が最初に気づき、誰が判断するかという合意を、案件の初期に言葉にしておくことです。

この合意は、契約書の条文でなくても構いません。関係者が同じ理解を持てる形であれば、簡潔なメモでも役に立ちます。形式よりも、共有されているかどうかが、つなぎ目の安定を左右します。

3. つなぎ目に出る維持と運用の不安

機能ではなく運用に出る外部サービスへの不安

つないだ先が増えるほど、現場の不安も増えます。IPAの調査では、外部サービスについて、メンテナンスや運用に対する不安を抱える企業は多いと示されています¹。機能が動くかどうかではなく、動き続けるかどうかが不安の中心です。

この不安は、技術の選び方だけでは解けません。外部サービスの仕様が変わったとき、誰が最初に気づき、誰が影響範囲を確かめるか。この役割が決まっていない現場ほど、不安は運用の場面で表に出ます。

不安の正体にある境界の曖昧さ

図の作成：Remogu編集部。境界が曖昧なときに起きる状態を整理したもので、統計データではありません

境界が引かれていない状態を放置すると、責任は滲みます。自分の担当だと思っていた範囲に、相手も同じように手を出さずにいる。その隙間に不具合が落ちる、という構図です。設計の巧拙よりも、この滲みをどれだけ小さくできるかが、つなぎ目を扱う仕事の実力になります。

滲みを小さくする方法は難しくありません。誰が何を保証するかを、実装の前に言葉にしておくことです。曖昧なまま進めるよりも、狭くても明確な境界を先に引くほうが、後の運用は安定します。

この安定は、参画先にとって数字に表れにくい価値です。だからこそ、境界を言葉にできる経験は、次の案件で自分の立ち位置を選ぶときの材料になります。案件の90%以上がフルリモート可能です。場所に縛られず、この経験を積み重ねられる環境を選べます。

不安を消す方法は、機能を増やすことではありません。誰が何を確かめるかを先に決めておくことです。この順番で進めれば、新しい外部サービスをつなぐたびに、同じ手順で確かめられます。

不安の芯を運用に置くか、境界の設計に置くかで、次に取る行動は変わります。次章では、その備えがどれだけ用意されているかを確かめます。

4. 止まったときの備えは半分

五分五分のリスク管理と業務継続の備え

外部への依存が前提になった以上、止まったときにどう動くかも設計の一部です。IPAの調査では、ITのリスク管理と業務継続計画は、全体の5〜6割程度の企業が整備していると示されています¹。備えがある現場と、まだ整っていない現場が、ほぼ並んでいるということです。

五分五分という割合は、案件を選ぶときの手がかりにもなります。備えが整っている現場では、境界を設計する仕事にすでに土台があります。整っていない現場では、その土台づくりから任されることがあります。つなぎ目を設計する立場にとっては、どちらも仕事の範囲に入ります。

境界の引き方と表裏の関係にある備え

図の作成：Remogu編集部。障害対応の役割分担の考え方を整理したもので、統計データではありません

この割り振りを言葉にしておくと、障害発生時に誰が動くのかを探す時間を省けます。誰が検知し、誰が切り分け、誰が復旧を判断するか。この3つの役割が決まっていれば、障害のたびに担当を話し合う場面は生じません。

備えの整備よりも先に、この割り振りを決めておく方法があります。仕組みを一から作るのではなく、決め事を先に言葉にする作業だからです。

備えの有無で変わる動き方

備えが整っている現場と、これから整える現場とでは、つなぎ目を設計する仕事の中身が変わります。既存の枠組みがある現場では、その枠に沿って境界を磨く動き方になります。枠組みがまだ整っていない現場では、境界を引く土台づくりから任されることがあります。以下は、この2つの状態と、それぞれで求められる動き方を並べたものです。

現場の状態	目安となる割合	つなぎ目の設計者に求められる動き方
備えが整っている現場	全体の5〜6割程度1	既存の枠組みに沿って境界を磨く
備えの整備がこれからの現場	—	境界を引く土台づくりから任される

備えの整っていない現場では、障害が起きてから役割を決める場面が増えます。この後追いを減らすのが、境界を先に引く設計です。備えが整っているかどうかは、案件に入る前の確認でも見えてきます。どちらの状態にあるかを見分けてから動き方を決めると、参画後の負荷を読み違えずに済みます。

備えを整える作業そのものは、一人で完結しません。ただし、どこに備えが必要かを言葉にして示すことは、つなぎ目を設計する立場から始められます。次章では、この備えが進んでいる領域とそうでない領域の違いを見ていきます。

5. 進んでいる領域とそうでない領域

作る側で先に進むクラウドとAPIの導入

つなぎ目を設計する仕事は、どの現場でも同じ深さでは求められません。IPAの調査では、クラウドやAPIの導入は、ベンダー企業を中心に比較的進んでいると示されています¹。つくる側の現場では、つなぐこと自体はすでに前提になっています。

前提になっている領域では、境界を設計する仕事の比重が上がります。つなぐ技術そのものよりも、つないだ先との責任の分け方を整理する力が問われる場面が増えるからです。

進んでいる領域とそうでない領域の見分け方

一方で、導入がまだ進んでいない領域では、つなぐ手前の合意形成から仕事が始まります。どちらの領域に関わるかによって、つなぎ目の設計者としての動き方は変わります。前提が整った現場よりも、これから整える現場のほうが、境界の設計をゼロから任される場面は多くなります。

案件を選ぶときは、この違いを見分ける視点が役に立ちます。すでに前提が整った現場で境界を磨くのか、これから前提を作る現場で土台から関わるのか。どちらも経験として積み上がる方向は違います。

自分がどちらの経験を積みたいかを言葉にできると、案件を選ぶ基準がはっきりします。技術の得意分野だけでなく、境界を「磨く」のか「作る」のかという軸を持っておくと、参画先を選ぶ基準になります。

この軸は、報酬や条件をクライアントと協議する場面でも使えます。境界をゼロから作る仕事は、磨く仕事よりも負荷が高いことを、自分の言葉で説明できるようになるからです。

経験を数える基準を変えると、案件の見え方も変わります。つないだ数ではなく、境界を引いた回数で自分の経験を語れるようになると、次の参画先を選ぶ会話が具体的になります。

6. 決める人がいない現場での合意

約半数の現場にいない意思決定の責任者

境界を設計しても、それを決める人がいなければ、決め事は宙に浮きます。IPAの調査では、CxOクラスの責任者を設置していない企業が、約半数に上ると示されています¹。境界を引く相手が、そもそも定まっていない現場があります。

決める人がいない現場では、境界の設計者自身が合意を取り付ける動きを担うことになります。誰かの決裁を待つよりも、小さな合意を積み上げるほうが、つなぎ目の仕事は前に進みます。

決める人がいなくても作れる合意

図の作成：Remogu編集部。決めておく項目の並びを整理したもので、統計データではありません

決める人がいない現場で効くのは、大きな仕組みづくりではありません。誰が何を保証するかという最小限の合意を、関係者の間で先に交わしておくことです。この並びを一つずつ埋めていくと、決裁者が不在でも、現場の合意として機能します。書いたものが少なくても、範囲と応答の目安が共有されていれば、つなぎ目の混乱を防ぐ土台になります。

決める人の有無で変わる合意の取り方

決める人がいる現場と、いない現場とでは、合意の取り方そのものが変わります。責任者がいる現場では、決裁を仰いで合意を確定する流れになります。責任者を設置していない現場では、関係者の間で最小限の合意を先に交わす動き方が必要になります。以下は、この2つの状態を並べたものです。

現場の状態	目安となる割合	合意の取り方
責任者を設置していない現場	約半数1	関係者間で最小限の合意を先に交わす
責任者を設置している現場	—	決裁を仰いで合意を確定する

決める人を待つよりも、決め事を自分から言葉にするほうが早い。この動き方ができる人は、決裁者が明確な現場よりも、決める人がいない現場でこそ重宝されます。つなぎ目を設計する立場は、権限がなくても発揮できます。合意を形にする力は、肩書きに関係なく積み上がる経験だからです。

小さな合意を積み重ねる経験は、決裁者がいる現場に移っても役立ちます。合意の作り方を知っている人は、仕組みが整った現場でも、抜け落ちた部分を確かめる視点を持てるからです。

7. 評価の軸と、契約の負担

利用する側が最優先する品質

境界を設計する仕事がどう評価されるかは、利用する側の優先順位から見えてきます。IPAの調査では、利用する側の企業は、品質を最優先事項として捉えていると示されています¹。つないだ先が止まらないこと、崩れないことが、何よりも重視されています。

品質が最優先という評価軸は、境界を丁寧に設計する仕事にとって追い風です。つなぐ速さよりも、つないだ後に崩れない設計のほうが、評価の軸に沿っているからです。

品質を軸に評価される環境では、境界を丁寧に設計する経験がそのまま実績になります。崩れない設計を積み重ねてきた経験は、次の案件でも同じ形で実績として説明できます。

取引の数だけ積み上がる契約の手間

一方で、契約の負担も無視できません。IPAの調査では、システム開発の契約では、取引ごとに手間や工数がかかる点を課題として挙げる企業が多いと示されています¹。境界を決める作業は、契約のたびに繰り返される負担でもあります。

この負担を軽くするのも、境界を設計する力です。範囲や応答の目安をあらかじめ言葉にしておけば、契約のたびに一から取り決める手間が減ります。つなぎ目を整理する仕事は、目の前の案件だけでなく、次の契約の負担も軽くします。

境界を扱う経験が積み上がるほど、契約のたびに一から説明する場面は減っていきます。過去にどう線を引いてきたかを話せるだけで、新しい現場での合意形成は早くなります。

品質を軸に評価され、契約の負担も減らせる。この二つを両立できる経験は、報酬や条件をクライアントと協議する場面で、自分の立ち位置を説明する材料になります。

冒頭の問いに戻ります。どこまで自分が保証し、どこから相手に委ねるか。この線を実装の前に言葉にしておくと、障害が起きたときに誰が動くのかを探す手間がなくなります。検知・切り分け・復旧判断の割り振りと、範囲・応答の目安・変更の連絡・終了時の扱いの4項目が、その最小の形です。

境界を引く経験は、案件を選ぶときの軸にもなります。自分がどこまで保証してきたかを言葉にできると、次に参画する現場でも同じ強みを活かせます。まず登録して、自分の経験に合う条件を確かめてみることが、次の一歩です。

8. よくある質問

ITのリスク管理や業務継続計画を整えている企業は、どのくらいですか

IPAの調査では、全体の5〜6割程度の企業が整備しているとしています¹。

CxOクラスの責任者を置いていない企業は、どのくらいありますか

IPAの調査によると、約半数の企業が設置していません¹。

クラウドやAPIの導入は、どのような企業で進んでいますか

IPAの調査では、ベンダー企業を中心に比較的進んでいると示されています¹。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」つなぎ目の意識（2025年4月・2026年10月確認）