LASSIC Media らしくメディア

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

A社のエンジニアとB社のエンジニアが、同じ画面の仕様を別々に理解していた。進み具合を尋ねると、各社の責任者がそれぞれ別の表で報告してくる——。開発をSES（技術者に開発に加わってもらう取引）で複数の会社に分けて頼む現場では、こうした食い違いが起こりがちです。SESパートナーのベンダーコントロールとは、発注する側が、複数の委託先の体制と役割分担、進み具合、成果物の品質を把握し、会社どうしの間の調整を自社で引き受けることを指します。

手がかりになるのが、デジタル庁が公開している「デジタル・ガバメント推進標準ガイドライン」とその解説書です。政府の情報システムを整備するときの共通ルールで、作業を複数の事業者に分けたときに発注する側が何を書き、どこで確かめるかが項目として並んでいます。ただし万能ではなく、府省の調達を前提にしたルールなので、民間の契約にそのまま当てはめられるわけではありません。本記事では、開発の現場を預かるマネージャーに向けて、ベンダーコントロールの中身、複数社で調整が増える理由、体制と会議と工程の決め方、運用と保守を別の会社に頼むときの分担、そしてつまずきやすい点を整理します。

ベンダーコントロールとは

ベンダーコントロールで扱うのは、大きく分けて4つです。誰がどの作業を受け持つか。どの会議で何を決め、決めたことをどこに残すか。工程をどこで区切って、終わったことを確かめるか。そして、納められた成果物の品質をどう見るかです。会社が増えると、会社と会社の間で、データの形や仕様、作ったものを受け渡す作業が加わります。

複数のSESパートナーが加わる形は、現場では大きく2通りです。1つは、1つのシステムの開発を、画面はA社、夜間の一括処理はB社のように機能ごとに分けて頼む形。もう1つは、開発を終えたシステムの運用をC社に、改修や不具合の修正をD社に、と工程ごとに分けて頼む形です。前者では開発の途中で、後者では利用者が使う本番環境を変えるたびに、会社どうしの受け渡しが起こります。

このとき発注する側が引き受けるのは、各社のエンジニア一人ひとりの作業を見ることではありません。各社の中の作業体制は、その会社が管理します。標準ガイドラインも、事業者の中の作業体制の管理の方法を、作業のルールをまとめた文書（実施要領）に書くよう求めています。発注する側が決めるのは、会社どうしの受け渡しのルールと、それを確かめる場です。

なぜ複数社だと調整が増えるのか

デジタル庁の解説書は、設計・開発や運用・保守の調達を分けた場合について、「分割した調達案件間での役割分担や責任分界の明確化、各事業者間のコミュニケーション管理といったオーバーヘッド作業が必要となり、発注者のリスクや負荷が増す可能性がある」と書いています。^*2 どこまでが誰の責任かを決める手間や、会社どうしの連絡を管理する手間が、本来の作業とは別に増えるということです。

そのうえで解説書は、「分離調達においては、発注者が複数の事業者間の調整を実施する責任がある」としています。^*2 分離調達とは、1つのプロジェクトの作業を複数の契約に分け、別々の事業者に頼むことです。SESパートナーを2社、3社と増やす場合も同じで、会社どうしの間で決めることは、最後は発注する側が引き受けることになります。

開発の規模が大きい場合には、「複数の事業者を束ねる高度な開発管理能力が求められる」とも書かれています。^*2 各社の進み具合をつかみ、会社をまたぐことを判断する力が要るということです。SESパートナーの数を増やす前に、その調整を社内の誰が担うのかを決めておくのが先です。

体制と役割分担をどう書くか

標準ガイドラインは、PJMO（発注する府省の担当チーム）が設計・開発事業者とともに「設計・開発実施計画書」と「設計・開発実施要領」を作ると定めています。計画書に書くのは、作業概要、作業体制、スケジュール、成果物、開発形態や開発手法、その他の6つです。あわせて、作業項目とスケジュールを細かく分けて担当者を書いたWBS（作業を細かく分けた一覧）を、附属文書として作るよう求めています。^*1

複数社のときに特に大事になるのが、作業体制の項目です。ガイドラインは、発注する側と開発を請け負う事業者だけでなく、「設計・開発に関連する全ての関係者について、その体制、関係者間の関係性、役割分担・責務等」を書くとしています。^*1 解説書はここに、同じプロジェクトに別の契約で加わっている事業者も含めるよう書いています。A社の計画書にB社の名前が出てこない、という書き方はしないということです。

解説書は、複数の事業者が作業する場合に、関係者ごとの受け持つ作業、役割、スケジュール、作業の進め方を具体的に定め、事前に合意することが重要だとしています。民間の開発に当てはめるなら、次のような1枚の表を、開発に入る前に各社の責任者と確かめておくと進めやすくなります。

表の「他社との受け渡し」の列が、ベンダーコントロールの中心です。各社の中の作業は各社の責任者が見ますが、A社とB社の間で渡すデータの形は、どちらか1社の責任者だけでは決められません。ここを誰が決め、決めた結果をどこに書くかを、発注する側が表に書いておきます。

会議と議事録で決めること

計画書と対になる実施要領について、標準ガイドラインは、コミュニケーション管理、体制管理、工程管理、品質管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策の9項目を少なくとも書くよう求めています。複数社のときに各項目で書いておきたいことを、次の表にまとめました。

最初のコミュニケーション管理では、事業者との合意形成の手続、連絡調整の方法、事業者が参加すべき会議と開催頻度、議事録の管理を書きます。そのうえでガイドラインは、仕様の認識に食い違いが生じないよう、「PJMOが議事録の正確性を確認し、修正する手順も併せて盛り込む」としています。^*1 民間でいえば、発注する側のプロジェクトの担当者が議事録を読み、間違いを直すところまでを手順にしておくということです。

複数のSESパートナーが加わる開発では、この議事録の扱いが特に大切です。A社の責任者が出た会議で決まった仕様を、B社は別の会議で違う形で聞いていた、ということが起こるためです。各社の責任者がそろう定例の会議を置き、議事録は発注する側が確かめて直し、決まった仕様は1か所にまとめて全社が読めるようにしておきます。

仕様についての質問の受け方も決めておきます。A社から出た質問への回答が、同じ画面のデータを使うB社にも関係することは珍しくありません。質問は発注する側の窓口に集めると実施要領に書いておけば、回答が1社にだけ届いてほかの会社が知らないまま作業を進める事態を避けられます。

工程と品質をどこで確かめるか

工程管理について、標準ガイドラインは、作業と工程を定めて管理手法や完了判定基準を書き、「次工程に進むときには、工程ごとに完了判定を実施する」としています。^*1 品質管理では、成果物の品質を確保するための品質基準と品質管理の方法を書きます。

複数社のときは、この完了判定の基準を各社でそろえることが大切です。A社が「結合テストが終わった」と言うときと、B社が同じ言葉を使うときとで、終わった中身が違えば、発注する側は各社の進み具合を比べられません。予定したテスト項目のうちどこまで実施して合格したら終わりとするか、見つかった不具合をどこまで直しておくかを、工程ごとに1つの基準で書いておきます。

変更管理について、ガイドラインは「変更内容に応じて、影響する範囲（プロジェクト計画書、サービス・業務企画、要件定義、設計等）を判断し」て作業するよう求めています。^*1 A社の画面の変更がB社の一括処理に影響する、といった会社をまたぐ変更は、当事者の2社だけで決めず、発注する側を通して決めるようにしておきます。2社の間で決まった変更は、残りの会社に伝わらないまま進みやすいためです。

運用と保守を別の会社に頼むとき

開発を終えたあと、運用と保守を別々のSESパートナーに頼む場合にも、同じ考え方が要ります。解説書は、保守でソフトウェアを変更する際の分担の例を挙げています。保守事業者が修正プログラムを作成して検証環境（本番の前に試す環境）でテストし、発注する側が適用するかどうかを判断し、その指示の下で運用事業者が本番環境に適用する、という流れです。^*2

この流れで決まっているのは、本番環境で作業するのは運用を担う会社で、入れるかどうかを決めるのは発注する側だという点です。一方で解説書は、ハードウェアの修理や交換では保守事業者が本番環境で直接作業することもあるため、責任の所在が不明確にならないよう、業務に応じて決める必要があるとも書いています。例外になる作業を先に書き出しておくと、当日になって誰が作業するかで迷わずに済みます。

開発した会社から、運用と保守を担う会社への引き継ぎも、発注する側が確かめます。解説書は、設計・開発事業者に、設計書、作業経緯、残存課題などを運用事業者と保守事業者へ引き継がせ、引き継ぎの期間内に各事業者の習熟度を確認するよう書いています。開発を担ったSESパートナーとの契約が終わる前に、この確認を済ませておきます。

つまずきやすい点

一つ目は、各社の報告の形がばらばらのまま進めることです。進み具合を表す項目や報告の頻度が会社ごとに違うと、どこが遅れているのかを比べられません。実施要領の工程管理と体制管理の項目で、報告の形を1つに決めておきます。

二つ目は、計画書と実施要領を作ったまま更新しないことです。解説書は、これらを設計・開発工程の基本となる計画とルールと位置づけ、常に最新の情報を示す必要があるとしています。途中でSESパートナーが加わったり入れ替わったりしたら、作業体制の表から書き直します。

三つ目は、政府のルールをそのまま自社の文書に当てはめることです。標準ガイドラインは府省の調達を前提にしているので、民間の開発では、会議の数や文書の細かさを案件の大きさに合わせて選ぶとよいでしょう。

SESパートナーを選ぶ段階で聞いておきたいことは「SESパートナーの選定で何を聞く？下請負と監査の権利を確認」で、技術レビューを契約にどう書くかは「外部エンジニアの技術レビュー、契約にどう書く？検証と監査の違い」で扱っています。

まとめ：ベンダーコントロールで確かめる3つの点

複数のSESパートナーのベンダーコントロールを進めるうえで、確かめておきたい点は3つに整理できます。第一に、会社どうしの間の調整は発注する側が引き受けるものだと決め、その担当者を置くこと。第二に、全社の体制と役割分担、会議と議事録の扱いを、開発に入る前に計画書と実施要領にまとめること。第三に、工程ごとの完了判定の基準と変更の手順を全社でそろえ、他社に影響する変更は発注する側を通して決めることです。この3点を踏まえておけば、「各社の作った部分はそれぞれ完成しているのに、組み合わせると動かない」という事態を避けやすくなります。各社の間の調整を担う人が社内に足りないなど、進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。第3編第6章「契約」の再委託の審査、第7章「設計・開発実施計画の策定」の設計・開発実施計画書と設計・開発実施要領の記載内容を参照（2026年9月確認）
2. *2　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：2026年6月12日版。第1章2.（プロジェクト管理支援事業者）、第6章1.（調達単位の分割と分離調達）、第7章1.（設計・開発実施計画の策定）と9.（引継ぎ）、第9章1.（運用業務と保守業務の分担）を参照（2026年9月確認）
3. *3　参考：デジタル庁「デジタル社会推進標準ガイドライン」（https://www.digital.go.jp/resources/standard_guidelines）。出典：標準ガイドライン群の公開ページ。DS-100がルールとして順守する文書、解説書が参考とする文書という位置づけと、各文書の更新日を参照（2026年9月確認）

Tweet