LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

「連携を3本つくってほしい」と頼んだのに、できあがったものを見るとデータの持ち方が思っていたものと違う。見積もりの根拠を聞いても、何を数えたのかがはっきりしない——。業務委託エンジニアにシステム連携を頼む現場では、こうした食い違いが起こりがちです。システム連携とは、別々に動いているシステムどうしでデータをやり取りできるようにすることで、同じ1本でも、毎日1回まとめて取り込むものと、画面を開くたびに相手へ問い合わせるものでは作業の中身が違います。

作業の量をはっきりさせるには、連携の作業を「機能の出入り」（データの入力・出力・問い合わせといった処理）と「データ」の2つに分けて数える考え方が役に立ちます。IPA（情報処理推進機構）が公開する資料でも、開発の規模はこの2系統に分けて記録されています。ただし万能ではなく、分けたあとで中身をどこまで細かく決めるかは、頼む側が考える必要があります。本記事では、業務委託エンジニアに開発を頼むマネージャーに向けて、資料が定める規模の区分、改修の区分と見積もりの時点、依頼書への書き方、そして外部に委託するときに確認したい点を整理します。

機能とデータの数え方とは

IPAの「ソフトウェア開発分析データ集2022」には、システム規模という節があります。ここでは、開発の規模をFP（ファンクションポイント。機能の数と複雑さを点数にした規模）で記録するときの、内訳の分け方が決められています。^*1 合計の点数だけを書くのではなく、どの区分に何点あったかまで残す形です。区分の数は、使う計測手法（FPの数え方）によって変わります。

IFPUGという計測手法を使う場合、区分はEI、EO、EQ、ILF、EIFの5つです。IFPUGは、資料がFPの数え方の一つとして挙げている手法です。それ以外の計測手法では、EI、EO、EQに相当する分をトランザクションファンクション、ILF、EIFに相当する分をデータファンクションとして、2つに分けて記録します。^*1

つまり、手法が違っても、規模は「機能の出入りを数える側」と「データを数える側」の2系統に分かれています。記録の細かさも決まっており、IFPUGの場合は5つの区分それぞれについて、機能の数を大・中・小の3段階に分けて書き、FP数を添えます。^*1

なぜ連携の本数では量が決まらないのか

システム連携の依頼に当てはめると、この分け方で、依頼から抜けている作業が見つかります。「連携を3本」という数え方は、多くの場合、機能の出入りだけを数えています。受け取ったデータを自社側のどこにためるのか、相手のシステムのデータをどう扱うのかといった、データの側の作業は本数に表れません。

「連携を3本」とだけ書いた依頼書を受け取った業務委託エンジニアは、データの側で何をするのかを自分で決めるか、こちらに聞き返すことになります。聞き返してもらえればよいのですが、相手が自分の判断で決めてしまうと、できあがってから食い違いが見つかります。

この分け方は、見積もりを受け取ったときにも使えます。出てきた見積もりが、機能の出入りとデータのどちらを数えたものかを尋ねれば、抜けているほうが見えてきます。なお、依頼書や見積もりへのこうした当てはめは資料が示しているものではなく、2系統という分け方をもとにした勧めです。

改修の区分と見積もりの時点

既存のシステムに手を入れる改修では、FPを母体FP、追加FP、変更FP、削除FPの4つに分けて記録します。^*1 名前のとおり、母体は改修前からある分、追加は新しく作る分、変更は作り直す分、削除は取り除く分に当たります。

システム連携の作業に置き換えると、新しくつなぐなら追加、既存のつなぎ方を作り直すなら変更、古い連携をやめるなら削除です。母体は、これから頼む作業には当たりません。1つの依頼のなかに、追加・変更・削除の3つがすべて入ることもあります。

見積もりについても決まりがあります。資料では、FPの見積もりにあたる計画値を、1回だけでなく、システム化計画後、要件定義後、基本設計後、詳細設計後の4つの時点で記録します。^*1 工程が進むと中身が決まり、規模の見積もりも変わっていく——資料の記録の形は、それを前提にしています。

依頼書にどう書くのか

ここまでの区分を依頼書に当てはめると、書いておきたいことは3つになります。1つ目は、機能の出入りとデータの両方について何をするのか。2つ目は、それが追加なのか、変更なのか、削除なのか。3つ目は、見積もりをどの工程で見直すのかです。

たとえば「受注データを基幹システムから毎日1回取り込み、自社側のデータベースにためる仕組みを新しく作る」と書いたとします。毎日1回取り込む処理が機能の出入り、自社側のデータベースにためる部分がデータに当たり、2系統の両方が書けています。「新しく作る」とあるので、改修の区分では追加だということも分かります。

見直す時点は、資料が計画値を記録している時点に合わせると決めやすくなります。要件定義が終わったとき、基本設計が終わったときのように、工程の区切りごとに量を見直すと依頼書に書いておけば、見積もりが変わったときに、どの時点で話し合うかをあらかじめ決めておけます。

つまずきやすい点

一つ目は、連携の本数だけで依頼することです。本数は機能の出入りの数であって、データの側の作業量は表しません。依頼書に両方を書いておけば、抜けが見つけやすくなります。

二つ目は、改修の区分を分けずに頼むことです。追加と変更と削除をひとまとめにすると、終わったあとに何がどれだけ増えたのかを残せません。^*1 依頼の段階で分けておけば、終わったときの記録も同じ区分で残せます。

三つ目は、最初の見積もりを最後まで変えないことです。工程が進めば中身が決まり、見積もりも変わります。最初の見積もりはその時点での見込みとして扱い、依頼書に書いた見直しの時点で改めて相手と確かめると進めやすくなります。

外部に委託するときに確認しておきたい点

業務委託エンジニアに依頼書を渡す前に、前の節で挙げた3点が書けているかを確かめておきます。3点がそろっていれば、見積もりを出してもらうときにも、何を数えた見積もりなのかを相手とそろえやすくなります。

もう一つは、追加と変更のどちらが多い依頼かです。追加が多い依頼なら、作るものと期間を決めて外部に頼みやすくなります。変更が多い依頼では、既存の作りを知っている人が要ります。正社員を採用するのか、業務委託エンジニアに頼むのかを決めるときにも、この見方が使えます。

工数をどこまで数えるかの決め方は「外部人材活用のトラブル｜社内工数と外部委託工数の違い」で、案件の技術条件をどこまで必須と書くかは「エンジニア人材紹介で紹介されない｜条件は規模の大きい順に絞る」で扱っています。

うまくいかなかったことの残し方は「外部人材活用はなぜ失敗する？IPAが定める変更の4段階」で、加わってもらう人のスキルの確かめ方は「外部エンジニアのスキル確認、4つの軸で評価する」で整理しています。

まとめ：依頼書で確かめておきたい3つの点

業務委託エンジニアにシステム連携を頼むうえで、確かめておきたい点は3つに整理できます。第一に、機能の出入りとデータの両方について何をするのかを書くこと。第二に、その作業が追加なのか変更なのか削除なのかを分けること。第三に、見積もりが途中で変わる前提で、見直す時点を決めておくことです。この3点を踏まえておけば、「連携を3本と頼んだのに、できあがったものが思っていたのと違う」という事態を避けやすくなります。依頼書の書き方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。A5.2.8「システム規模」のFP詳細値の区分、改修FPの4区分、FP計画値を記録する4つの時点の一次情報として。IPAの資料は無断で改変したり配り直したりできないため、この記事は示された区分を引用し、表と図は内容をもとに作成した。資料の図表そのものは写していない（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）

Tweet