LASSIC Media らしくメディア

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

初めてシステムの作り直しを任され、候補の会社を調べ始めたものの、SIerと名乗る会社と受託開発と名乗る会社をどう呼び分け、どちらに頼めばよいのかも分からない。そうした発注の窓口の方に向けた記事です。

答えを先に示すと、SIerは企画・要件の整理から開発・運用までの工程をまとめて請け負う会社の業界での呼び方で、受託開発の会社は主に作る工程を請け負います。見積もりを頼む前に、頼みたい工程に印を付け、要件を社内でまとめられるかを見極めると、まとめて頼むか工程で分けるかを選べます。

頼む相手の違いを知らずに発注すると起きること

要件（作る物が満たすべき条件）をまとめる工程を誰が持つかがあいまいなまま発注すると、作る工程に入ってから作り直しや追加の費用が出て、納期が延びやすくなります。相手がSIerを名乗るか受託開発を名乗るかより先に、どの工程を誰が受け持つかを決めておく必要があります。

悩みごとに、先に読むとよい章を次の表にまとめました。

工程の受け持ちがあいまいなまま進んだ案件は、後から争いになりやすい種類のものです。IPA（情報処理推進機構）は、工程ごとに契約を分ける多段階契約について、下流の工程でトラブルが起きたときに発注した側が上流の工程まで遡って解除や代金の返還を求めるといった「紛争が頻発している」と整理しています。^*3

公的な分類では、SIerと受託開発の会社は同じ枠に入ります。日本標準産業分類（令和5年7月改定）は、受託開発ソフトウェア業を「顧客の委託により、電子計算機のプログラムの作成及びその作成に関して、調査、分析、助言など並びにこれらを一括して行う事業所」と説明し、その事例にシステムインテグレーションサービス業を挙げています。^*1

図のとおり、違いは業種の名前ではなく、引き受ける工程の広さにあります。解決したい方向ごとに、答えを短く示します。

• 要件の整理から頼みたいなら：企画・要件の段階から引き受ける相手（SIerと呼ばれることが多い会社）を候補にする
• 要件は社内でまとめられるなら：作る工程を受託開発の会社に頼み、要件の判断は社内に残す
• 工程ごとに比べて選びたいなら：工程を分けて別々に頼み、工程の間の調整は自社で受け持つ

つまずきの元は会社の大きさより「要件を誰がまとめるか」

相手の会社の大きさで選びがちですが、合う相手を分けるのは、要件をまとめる工程を自社が持てるかどうかです。IPAのモデル契約（情報システム・モデル取引・契約書 第二版）のひな型でも、要件定義書を作るのは発注する側（甲）で、受託する側は「甲による要件定義書の作成作業を支援する」役割として書かれています。^*4

大きな会社に頼んでも、業務の手順を説明できる人が社内にいなければ、要件の中身は決まりません。反対に、目的と範囲を社内で書けるなら、作る工程だけを頼む選び方も取れます。次の3つのうち、当てはまるものを数えてみてください。

• 作りたい物の目的と範囲を1枚に書けない
• 業務の手順を説明できる社内の人が決まっていない
• 入れた後の運用を誰がするか決めていない

1つでも当てはまるなら、要件の整理から一緒に進められる相手を候補に入れるのが無理のない選び方です。3つとも当てはまらなければ、作る工程だけを頼み、企画と要件の判断を社内に残す道も選べます。

頼む相手を選ぶ4つの基準

候補の会社を比べる前に、次の4つの基準で自社の条件を決めます。条件が先に決まっていれば、各社の提案の違いが、範囲の違いによるものか、力の違いによるものかを見分けられます。

最初に決めるのは頼む工程の範囲です。範囲が決まると、残る3つの基準で何を相手に求めるかもはっきりします。つなぐ範囲が広い場合は、つなぎの調整を誰が受け持つかが、まとめて頼むか分けるかの分かれ目になります。

受発注の仕組みの作り直しで頼む相手を決める

注文を受けてから仕入先へ発注するまでを管理する仕組み（受発注の仕組み）を作り直す場面で、業務の手順をまとめられる人が社内にいないとき、発注の窓口を受け持つ担当者がどう判断を進めるかを表にしました。

この流れで決まるのは、要件の整理から頼める相手を軸にしつつ、作る工程は別にも見積もるという方針です。窓口を1社にまとめる手軽さと、工程ごとに比べられる利点を、見積もりの段階まで両方残しておけます。

後半では、頼める工程の種類、費用対効果の見方、工程ごとの契約の確認点、比べる表を確かめられます。

SIerの役割と頼める工程の種類

企画・要件の整理・設計・開発・運用のうち、どこまでをまとめて請け負うかで会社の形が分かれます。SIerは、こうした工程をまとめて引き受け、既存の仕組みや他社の製品とのつなぎまで含めて全体を組み上げる会社を指すことが多い呼び方です。

IPAのモデル契約のひな型は、発注する業務を要件定義作成支援業務、外部設計書作成支援業務、ソフトウェア開発業務、ソフトウェア運用準備・移行支援業務の全部又は一部で構成し、業務ごとに個別契約を結ぶ形にしています（第3条・第4条）。^*4 工程の名前と中身を表に並べます。

会社の形は、この表のどこからどこまでを引き受けるかで分けると整理しやすくなります。

情報サービス産業の売上高のうち、受注ソフトウェアは53.5%（2024年）を占めます。^*2 顧客の注文でソフトウェアを作る仕事は業界の売上の半分を超える大きな領域で、呼び名だけでは引き受ける工程の広さまでは分かりません。候補の会社には、どの工程から引き受けるかを直接聞くのが確実です。

費用対効果：まとめて頼むか工程で分けるか

まとめると窓口の手間が減り、分けると工程ごとに比べられるため、自社の管理の手間と並べて見ます。金額だけを並べると、分けたほうが安く見えることがあっても、工程の間をつなぐ手間は見積もりに入っていません。

工程の間の調整を誰が受け持つかは、モデル契約のひな型にも書かれています。第13条は、全体の一部として分割して発注し、つながる部分を他の会社が開発している場合、機能の整合性や開発スケジュールの調整などについて「甲がその責任を負うものとする」としています。^*4 分けて頼む安さは、この調整の手間と引き換えです。

見積もりを受け取ったら、金額の横に次の3つを書き添えて比べます。

• 工程の間の調整に、社内の誰がどれだけの時間を使えるか
• 工程の間で受け渡す成果物（要件定義書・設計書など）の数
• 入れた後の運用まで同じ相手に頼むか、別に頼むか

どちらの形でも、今の業務の手順を社内で書き出しておくと、見積もりの前提がそろいます。聞き取りのメモの整理や要件の下書きにAIチャットを使えば、社内でまとめる時間を短くできる場合があり、作る工程だけを頼む選び方も取りやすくなります。

判断の材料：委託先を比べる表

4つの基準を列にし、同じ条件で見積もりを並べます。条件がそろっていないと、金額の差が範囲の差なのか、進め方の差なのかを見分けられません。

モデル契約のひな型は、業務に着手する前に、発注する側が示した提案依頼書（RFP）と、受託する側の提案書・見積書を基礎に取引条件を定めて個別契約を結ぶとしています（第4条）。^*4 決める条件として挙げているのは次のような項目で、見積もりの依頼で伝える条件をそろえる手がかりになります。

• 具体的作業内容（範囲、仕様等）
• 契約類型（請負・準委任）
• 作業期間又は納期と作業スケジュール
• 発注する側と受託する側の役割分担
• 納入物の明細と、検査又は確認に関する事項

小さな案件でも、頼む工程と規模を最初に伝えれば、引き受けるかどうかの返事は早く得られます。引き受ける規模は会社ごとに違うため、表の1行目の答えから確かめます。

工程ごとの契約と情報の扱いで確かめる点

工程ごとの契約の形、仕様の変更の決め方、成果物の権利、秘密の扱いと再委託をIPAのモデル契約に照らして確かめます。モデル契約は、ユーザ企業とITベンダーのいずれかにメリットが偏らない契約書づくりを目指して作られたひな型です。^*4

ひな型では、契約類型（請負・準委任）を工程ごとの個別契約で決めます（第4条）。外部設計は準委任とする案と請負とする案の両方が用意されています。^*4 請負と準委任の違いは受託開発とSES・準委任の違いとは？発注側の選び方と確認点で整理しています。

成果物の権利は、作り直しの後の改修にも関わります。ひな型の第45条は、A案で納入物の著作権を受託する側に帰属させ、B案では汎用的なプログラムなどを除いて委託料が完済されたときに発注した側へ移し、C案では共有とする形を示しています。^*4

再委託のA案は、受託する側が「事前に甲の承諾を書面で得た場合」などに一部を第三者に再委託できるとし、再委託先にも同様の義務を負わせる契約を結ぶとしています。^*4 まとめて頼む場合ほど関わる会社が増えるため、どこまで承諾を求めるかを先に決めておきます。

• 工程ごとの契約の形（請負か準委任か）を、見積もりの依頼の段階で書く
• 仕様を変えるときの手続きと、決める場を契約に入れる
• 著作権の帰属と、再委託に承諾を求めるかを、ひな型の案から選んで決める

発注までの手順と期間

目的の整理、候補の選定、見積もりの依頼、契約の順に進め、要件の整理に最も時間をかけます。作り直しの場合は、今の仕組みが何をしているかを調べる時間も、この段階に入ります。

IPAは既存の仕組みの作り直しについて、要件定義に入る前に現行システムを調べて仕様を明らかにする必要があり、その調査には「コストと時間を要する」と指摘しています。今と同じ動きで作り直すだけ（現行踏襲）と考える発注者には「この意識が薄い」とも書いています。^*3

期間は、目的の整理と今の仕組みの調査にかかる時間で大きく変わるため、一律の目安ではなく段階ごとに見積もります。企画の段階の調査を外部に頼む方法もあり、IPAの解説は、発注者が必要に応じて、後の開発契約とは別に「準委任契約としてのコンサルティング契約」を結んで支援を受ける形を示しています。^*3

• 業務の手順を説明できる社内の人を1人決め、その人の時間を先に押さえる
• 今の仕組みにつながる仕組みと機器を一覧にする
• 企画の段階を頼むなら、後の開発とは別の契約にするかを決める

まとめ：頼む工程に印を付けてから相手を選ぶ

SIerは企画・要件の整理から開発・運用までの工程をまとめて請け負う会社の呼び方で、受託開発の会社は主に作る工程を請け負います。公的な分類では同じ枠に入るため、呼び名ではなく、引き受ける工程の広さと、自社が要件をどこまでまとめられるかで頼む相手を選びます。今日からは、頼みたい工程に印を付けた表を上長に見せ、見積もりの依頼先を決めるところから始めてください。

よくある質問

出典

1. *1　参考：政府統計の総合窓口（e-Stat）「日本標準産業分類（令和5年［2023年］7月改定）3911 受託開発ソフトウェア業」（https://www.e-stat.go.jp/classifications/terms/10/04/3911）。出典：細分類の説明と事例（システムインテグレーションサービス業）を参照（確認日2026年11月3日）（2026年11月確認）
2. *2　参考：一般社団法人情報サービス産業協会（JISA）「統計で見る情報サービス産業」（https://www.jisa.or.jp/explain/tabid/755/Default.aspx）。出典：情報サービス産業売上高/業務種類別構成比（受注ソフトウェア 53.5%、2024年、経済産業省「2025年経済構造実態調査」）を参照（確認日2026年11月3日）（2026年11月確認）
3. *3　参考：独立行政法人情報処理推進機構（IPA）「「情報システム・モデル取引・契約書」からの見直しのポイント」（最終更新日2026年9月11日）（https://www.ipa.go.jp/digital/model/review-point.html）。出典：「第二版」における見直しのポイント（4）システム開発における複数契約の関係、（5）再構築対応、システム再構築における企画プロセスを参照（確認日2026年11月3日）（2026年11月確認）
4. *4　参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（受託開発（一部企画を含む）、保守運用）ひな型（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：ページの概要と、ひな型（Word）の第3条・第4条・第7条・第13条・第14条・第34条・第37条・第41条・第45条を参照（確認日2026年11月3日）（2026年11月確認）

Tweet