LASSIC Media らしくメディア
業務委託エンジニアとシステム連携、機能とデータの数え方の違い
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 規模の数え方は2系統に分かれている：機能の出入りを数える側と、データを数える側です。*1
- 改修は母体・追加・変更・削除の4つに分ける：IPAの資料が、この4つで記録すると定めています。*1
- EIやILFが何を指すのかは書かれていない：資料にあるのは区分の名前と、区分どうしの対応関係までです。*1
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
業務委託エンジニアにシステム連携を頼むとき、「連携を3本つくってほしい」という言い方で依頼していないでしょうか。これだと作業の量が決まりません。同じ1本でも、毎日1回まとめて取り込む連携と、画面を開くたびに相手へ問い合わせる連携では、やることが違うからです。
量の数え方を項目ごとに決めている資料があります。IPA（独立行政法人情報処理推進機構。情報処理の分野で国が設立した法人）が公開している「ソフトウェア開発分析データ集2022」です。*1 この資料は、開発の規模をFP（ファンクションポイント。システムが持つ機能の数と複雑さから規模を点数にする数え方）で記録するとき、その内訳をどう分けるかを決めています。*1
本記事は、開発の現場を回しているマネージャに向けたものです。前半で資料が定めている区分を見て、後半でシステム連携の依頼書への落とし方、つまずきやすい点、外部に頼むときの確認事項を整理します。
目次
IPAが定める規模の数え方の内訳
IPAの「ソフトウェア開発分析データ集2022」には、システム規模という節があります。*1 ここで決められているのは、FPの合計値だけでなく、その内訳をどう分けて記録するかです。*1
| 区分 | IFPUGという計測手法の場合 | それ以外の計測手法の場合 |
|---|---|---|
| 機能の出入りを数える側 | EI（External Inputs）／EO（External Outputs）／EQ（External Enquiries） | トランザクションファンクション |
| データを数える側 | ILF（Internal Logical Files）／EIF（External Interface Files） | データファンクション |
IFPUGという計測手法を使う場合は5つに分かれます。*1 IFPUGは、資料が計測手法の選択肢として挙げている名前の一つです。*1 資料は、この手法を使った場合とそれ以外の手法を使った場合で、記録する区分の数を変えています。*1 5つの区分はEI、EO、EQ、ILF、EIFです。*1 英語の名前をそのまま訳すと、EIは外部からの入力、EOは外部への出力、EQは外部からの問い合わせ、ILFは内部の論理ファイル、EIFは外部とのインタフェースファイルになります。これは名前の訳であって、資料が示した定義ではありません。
それ以外の計測手法を使う場合は2つで、トランザクションファンクションとデータファンクションになります。*1
この2つの対応関係が、資料にはっきり書かれています。トランザクションファンクションはEI、EO、EQに相当し、データファンクションはILF、EIFに相当する、と。*1 つまり、規模の数え方は「機能の出入りを数える側」と「データを数える側」の2系統に分かれています。
なお、EIやILFがそれぞれ何を指すのかという定義は、今回参照した資料には書かれていません。書かれているのは、区分の名前と英語の名称、5つと2つの対応関係、そして記録の細かさまでです。*1
「連携を3本」では量が決まらない
システム連携の依頼に置き換えると、ここが大事になります。「連携を3本」という数え方は、機能の出入りだけを数えていることが多いからです。データを数える側の作業が抜けます。
この読み替えは資料が述べていることではなく、2系統という分け方からこの記事で考えたものです。ただ、2系統に分かれているという事実自体は資料のとおりです。*1
「連携を3本」と書いた依頼書を受け取った業務委託エンジニアは、データの側で何をするのかを自分で決めるか、こちらに聞き返すことになります。聞き返してもらえれば良いのですが、決められてしまうと、あとから食い違いが出ます。
この2系統という分け方は、見積もりを受け取ったときにも使えます。相手が出してきた見積もりが、機能の出入りとデータのどちらを数えたものなのかを聞けば、抜けているほうが見えます。これも資料が述べていることではなく、2系統という分け方からこの記事で考えたものです。
記録の細かさも決まっています。IFPUGの場合、5つのそれぞれについて「機能数：大、中、小」とFP数を書く形です。*1 同じ区分のなかでも、大・中・小の3段階に分けて機能の数を書きます。*1 大・中・小が何を基準にした区分なのかは、今回参照した資料に書かれていません。
改修は4つに分けて記録する
もう一つ、改修のときの決まりがあります。既存のシステムに手を入れる場合、FPを4つに分けて記録します。*1
母体FP、追加FP、変更FP、削除FPの4つです。*1 母体はもとからあった分、追加は新しく作る分、変更は作り直す分、削除は取り除く分だと読めます。ただし、それぞれの正確な定義までは資料に書かれていません。
システム連携に手を入れる作業は、この4つのどれに当たるのか。新しくつなぐなら追加、既存のつなぎ方を作り直すなら変更、古い連携をやめるなら削除です。母体は、もともとあった分を表す欄なので、これから頼む作業には当たりません。1つの依頼のなかに追加・変更・削除が3つとも入っていることもあります。
さらに、計画値は1回ではなく4つの時点で記録します。*1 システム化計画後、要件定義後、基本設計後、詳細設計後です。*1 実績値は総合テストの完了時に記録します。*1 つまり資料は、規模の見積もりが途中で動くことを前提にしています。
つまずきやすい難所
一つめのつまずきは、業務委託エンジニアに連携の本数だけで依頼することです。本数は機能の出入りの数であって、データを数える側の作業量は表しません。資料の分け方に沿って両方を書いておくと、抜けが見つけやすくなります。これは資料が指示していることではなく、2系統という分け方からこの記事で考えたものです。
二つめは、改修の4区分を分けずに頼むことです。追加と変更と削除をひとまとめにすると、終わったあとに何がどれだけ増えたのかを残せません。*1
三つめは、最初の見積もりを最後まで固定することです。資料は計画値を4つの時点で記録させています。*1 工程が進むほど中身がはっきりするので、量が動くのは当たり前だという前提に立っています。これは資料の書きぶりからこの記事で読み取ったもので、なぜ4時点なのかについて、今回参照した資料に説明はありません。依頼書に「どの時点で見直すか」を書いておくと、量が動いたときに話し合う場所が決まります。
外注時に確認しておきたい点
業務委託エンジニアにシステム連携を頼むときは、依頼書に3つのことを書いてください。1つめは、機能の出入りとデータの両方について何をするのか。2つめは、それが追加なのか変更なのか削除なのか。3つめは、量を見直す時点をいつにするのかです。いずれも資料が依頼書について指示していることではなく、記録の区分からこの記事で組み立てたものです。
たとえば「受注データを基幹システムから毎日1回取り込み、自社側のデータベースにためる仕組みを新しく作る」。こう書けば、機能の出入り（毎日1回取り込む処理）と、データ（自社側にためる）の両方が書けています。さらに「新しく作る」とあるので、追加だとも分かります。
正社員を採用するのか、外部の要員（自社の社員ではなく、作業を委託して働いてもらう人。個人のフリーランスのほか、開発を請け負う会社に所属している人も含みます）に頼むのかを決めるときも、この分け方は使えます。追加が多い依頼なら期間を決めて外部に頼みやすく、変更が多い依頼なら既存の作りを知っている人が要ります。
工数をどこまで数えるかの決め方は外部人材活用のトラブル｜社内工数と外部委託工数の違いで扱っています。
案件の技術条件をどこまで必須と書くかはエンジニア人材紹介で紹介されない｜条件は規模の大きい順に絞るにまとめました。
うまくいかなかったことの残し方は外部人材活用はなぜ失敗する？IPAが定める変更の4段階で整理しています。
入ってもらう人のスキルの確かめ方は外部エンジニアのスキル確認、4つの軸で評価するにあります。
まとめ：依頼書に書く前に決める3つのこと
業務委託エンジニアにシステム連携を頼むときに、決めておきたいことは3つです。第一に、機能の出入りとデータのどちらの作業なのか。IPAの資料は、開発の規模をこの2系統に分けて記録すると定めています。*1 第二に、それが追加なのか変更なのか削除なのか。改修では母体・追加・変更・削除の4つに分けて記録します。*1 第三に、見積もりが途中で動く前提で時点を決めておくこと。資料は計画値をシステム化計画後、要件定義後、基本設計後、詳細設計後の4つの時点で記録させています。*1 この3つが決まっていれば、業務委託エンジニアに渡す依頼書は「連携を3本」よりもはるかに具体的になります。なお、各区分の中身の定義までは、今回参照した資料に書かれていません。
よくある質問
IPAは開発の規模をどう分けて記録していますか
「ソフトウェア開発分析データ集2022」のシステム規模という節で、IFPUGという計測手法の場合はEI、EO、EQ、ILF、EIFの5つ、それ以外の計測手法の場合はトランザクションファンクションとデータファンクションの2つに分けています。*1 確認日は2026年9月19日です。
5つと2つはどう対応していますか
トランザクションファンクションがEI、EO、EQに相当し、データファンクションがILF、EIFに相当する、と資料に書かれています。*1 確認日は2026年9月19日です。
EIやILFの意味は書かれていますか
書かれていません。今回参照した資料にあるのは、英語の名称と、5つと2つの対応関係、記録の細かさまでです。*1 確認日は2026年9月19日です。
改修のときはどう記録しますか
母体FP、追加FP、変更FP、削除FPの4つに分けて記録します。*1 計画値についても同じ4つに分けます。*1 確認日は2026年9月19日です。
見積もりは何回記録しますか
計画値はシステム化計画後、要件定義後、基本設計後、詳細設計後の4つの時点で記録します。*1 実績値は総合テストの完了時です。*1 確認日は2026年9月19日です。
依頼書の中身が決まったら相談
「受注データを取り込む仕組みを新しく作る」という形で追加か変更かまで書けていれば、そのままご相談いただけます。まだ連携の中身を詰めている段階でも構いません。
Remoguとリラシクなら、新しくつなぐ仕事も、既存の連携を作り直す仕事も、作業と期間を決めたうえでお探しいただけます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *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 参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）
