SIerとは？システム開発で依頼できる仕事と、発注前の確認点

SIerは提供側、SIは仕事、SEは職種として読む

SIerは、システムインテグレーター（System Integrator）を指す日本で使われる呼び名です。顧客の業務や目的に合わせ、ソフトウェア、機器、ネットワークや外部サービスなどを組み合わせて、使う仕組みをつくり支える仕事に関わります。新しく全てを開発する場合だけでなく、既存製品の設定や組み合わせを検討する場合も、依頼先に相談する候補になります。

厚生労働省の職業情報サイトは、SIerを企業向けシステムの開発・構築や運用に関わる企業として説明しています。NISTの用語辞書も、開発・試験・運用・保守などの個別化されたサービスを取得側へ提供する組織という定義を示します。どちらも、今回の依頼に全作業が含まれるという回答の代わりにはなりません。

厚生労働省 job tag：IT・通信の仕事／NIST CSRC：System Integrator

企業の分類だけで、今回の担当範囲や優劣を決めない

メーカー系・ユーザー系・独立系といった説明は、主に資本関係などから企業を整理する見方です。名称だけで、特定製品を扱える、安い、品質が高い、全作業を同じ社員が担当するとは判断できません。SESなど別のサービスの呼び方が出ても、呼称だけで今回の作業や体制、取引条件を決めず、提案の実際の担当と窓口を確認します。

技術方式を決める前に、今の仕事と使う資料を見せる

この会社が最初に相談したいのは、貸出状況を確かめる仕事です。いきなり製品名や画面一覧を決めるより、誰がどの資料を持ち、どの場面で探し直しが起きるかを説明すると、依頼先も調べる対象を絞れます。

受付が貸出依頼票を見て何を判断し、返却担当がどの記録で状態を確かめるのかを伝えます。資料が同じ番号を指すか、更新した人や確認した時点が分かるかも、業務側が説明する材料です。ここで渡すのは実顧客の記録ではなく、項目の意味を伝えるための架空例や、情報を伏せた資料です。

希望する状態と、任せきらない判断も分けてください。この例では、貸出の可否と返却状態の判断は、業務担当が確かめることを残します。画面に表示されたことだけで、機器を貸し出してよい、返却確認が終わったとは扱わない仕組みを相談します。

図で見る問い：今の貸出業務の紙から、どんな仕事をSIerへ相談するのでしょうか。受付と返却担当が使う資料と、整理・設計・試験・導入後の支援へつながる相談の対象を見てください。

この解説図を原寸で見る

図の読み方：図は相談する仕事のつながりで、実装済みのシステムや全工程の受託を示しません。自社が持つ資料と判断を伝え、依頼先に調べてもらう仕事を絞るために使います。具体的に誰が何をするかは、次の表で見比べます。

同じ仕事ごとに、自社の説明・判断と依頼する候補を並べる

直前の資料と相談する仕事の図も使い、自社が説明することと、支援を依頼する候補を見比べてください。

システムをつくる作業を外部へ相談しても、自社の仕事の事実や、業務で何をよい結果とするかが自動的に決まるわけではありません。SIerに頼む候補と、利用する企業が説明・判断することを同じ項目で並べると、どちらにも担当がいない仕事を見つけやすくなります。

これは相談用の候補で、決まった工程順や一社への一括依頼を強制するものではありません。目的の整理だけを先に依頼する、設計や構築の範囲を別途決める、導入後の支援を別の窓口へ頼む、といった組み方も、提案の対象と責任の境目を確かめて判断します。

業務側が答える人と、判断する人を用意する

受付・返却などの実際の仕事を説明できる人と、対象や優先することを決める人を明らかにします。小さい会社では同じ人が役割を兼ねてもかまいません。人数を増やすことより、誰にどの質問を戻し、誰が結果を確かめるかが分かることが大切です。

MicrosoftのDynamics 365向け指針は、業務の目標に沿った役割・権限を明らかにし、業務利用者が要求の説明、業務面の了承、試験へ参加する仕事も計画する考え方を示しています。特定製品のチーム構成をそのまま義務にせず、今回の仕事を担う役割へ当てはめてください。

Microsoft Learn：プロジェクトの役割と責任の整理

提案では、作業範囲・成果物・窓口を具体の仕事に戻して確かめる

「システム一式」「導入支援込み」といった表現だけでは、資料を整理する作業、データの準備、試験、現場への説明、導入後の対応のどれを含むかまでは分かりません。提案にある作業を、先ほどの貸出業務のどこに当たるかへ戻して質問します。

この架空例で、選んだ依頼先は未確認、提案書を受領したかも未確認です。したがって、表の仕事をすでに提供してもらえると確定していません。提案が届いたら、含む作業と対象外、成果物の中身、回答する窓口を対応させ、回答がない所を質問として返します。

合意した作業範囲は未確認、契約の成立も未確認です。相談メモに希望を書いたことと、依頼先が実施を引き受けたことを分けてください。料金は未確認のため、金額や相場を作例へ補ってはいません。見積もりでは、含む作業と別途費用になる条件を一緒に確認します。

図で見る問い：提案書のどこを見れば、何を頼むかと、まだ決まっていないことを区別できるでしょうか。作業範囲、成果物、窓口の三つの資料欄と、自社に残る判断を見てください。

この解説図を原寸で見る

図の読み方：三つの欄があることだけで、役割の合意や契約が成立するわけではありません。今回の貸出業務で誰が何をし、どの資料を受け取り、疑問を誰へ戻すかを、回答と照合してください。記載がない作業は含まれると推測せず、質問して確かめます。

導入後に使う人と、困ったときの受付まで確かめる

提案の読み方の図も使い、窓口に何を伝え、どこまで支援を受けるかを確かめてください。

使い始めるための説明や操作手順、連絡先を受け取る仕事と、使い始めた後の問い合わせ・障害・修正への対応を分けます。日常の貸出入力、返却状態の判断、資料の更新を誰が担うかが曖昧なままだと、システムを渡されても現場の仕事が回りにくくなります。

保守や問い合わせの受付範囲は未確認です。受ける内容、連絡方法、対応する時間帯、必要な費用や契約の範囲を依頼先へ尋ねます。「保守あり」という一語を、いつでも無料で全て直す約束として扱わないでください。製品の提供元や別の保守会社が関わるなら、最初の受付と、その先へつなぐ担当を確かめます。

手順を受け取ったことと、業務で使える確認は別

利用者が、対象の貸出依頼と返却記録を読み、期待する情報を確かめられるかを、合意した対象と条件で確認します。この例の試験結果は未確認で、資料や画面案があるだけで合格したことにはしません。試験に使う資料・環境を扱う権限も未確認です。実際にデータを渡したり本番へ接続したりする前に、共有方法と権限を確認します。

運用する人へ渡す資料や、問い合わせ時に知らせる内容も、依頼の範囲に含むか確かめます。分からない結果が出た場合の連絡先と、業務側が続ける確認が分かる状態にして、導入する判断へ戻してください。

製品や依頼範囲が未定でも、仕事の説明から相談できる

既存製品の設定で足りるか、新しい開発が必要か分からない段階なら、その判断に必要な調査や整理を頼めるかを尋ねます。技術方式を自社だけで選び切ってから相談する必要はありません。何が分からず、どの資料や条件を調べれば判断できるかを、依頼先と具体化します。

反対に、製品名が決まっていても、今回使える機能、権限や契約、既存情報との関係、試験や導入後の対応までは決まっていない場合があります。その製品を扱えるかと、業務に合うようにどこまで支援してもらえるかを分けて質問してください。

要件や提案依頼書を詳しくまとめる段階へつなぐ

IPAの解説は、利用する企業とベンダーが業務上の要求を確認し、認識を合わせるための要件定義を説明しています。最初の相談では、目的・現状・手元の資料・未定事項を示し、必要な整理をどこまで頼むかを確かめます。完成した仕様書だけが相談の入口ではありません。

IPA DX SQUARE：要件定義の位置づけ

各社へ同じ条件で提案を求める段階では、提案依頼書で目的・対象・完成条件を整理する記事などの具体的な説明へ進みます。システム間でどの情報をどう渡すかは、連携方法と項目対応を扱う別の主題です。本稿は、その技術方式の詳細や契約条文の判断を代わりにするものではありません。

まとめ：会社の呼び名から、頼む仕事と自社の判断へ具体化する

SIerは、企業の仕事に合わせてシステムの企画・設計・構築・導入や運用などを支援する提供側です。SIという仕事、SIerという企業の呼称、SEという職種を分けて読み、名称だけで全工程や全費用が含まれるとは判断しません。

今の仕事と資料を見せ、目的の整理、設計・構築、試験・導入、運用・保守のうち何を相談するかを具体化します。同じ仕事ごとに、自社が説明・判断すること、依頼する候補、受け取るものと窓口を並べると、曖昧な境目を質問できます。相談したこと、役割を合意したこと、実施したこと、業務で確かめたことは分けて扱ってください。