LASSIC Media らしくメディア

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

候補のSESパートナーに対応範囲を尋ねると、「開発から保守まで一通り対応できます」という答えが返ってくることがあります。ところが参画が決まってから、保守とはアプリケーションの改修のことでサーバーの管理は含まない、テストは頼めるが結果の判定は自社で行う、といった食い違いが見えてくる——。SESパートナーの選定で対応範囲を確かめるとは、任せたい作業を工程・対象システム・分担・体制・稼働の条件に分けて言葉をそろえ、候補ごとに同じ表で答えてもらうことを指します。

手がかりにするのは、IPA（情報処理推進機構）の「共通フレーム2013」と、IPAと経済産業省がまとめた「情報システム・モデル取引・契約書〈第二版〉」です。どちらもSESの契約そのものを扱う資料ではありませんが、作業の範囲と役割分担を書き表すための項目がそろっています。本記事では、開発の現場を預かるマネージャーに向けて、範囲が食い違う理由、工程と対象システムの聞き方、役割分担表の使い方、体制と稼働の条件、範囲が変わるときの扱い、候補を比べる表の作り方を整理します。

対応範囲が食い違う理由

食い違いの多くは、同じ言葉が指す範囲の違いから生まれます。モデル契約の保守運用の部分には、アプリケーション保守サービスと、オンサイト型アウトソーシングサービス（委託する側の拠点などに要員を置いて運用を受け持つ形）の2つのサンプルが載っています。どちらも保守を含むサービスですが、オンサイト型の説明は、保守のうち「アプリケーションプログラムの保守を除く」ハードウェア、OS、ミドルウェアの保守が範囲に入るとしています。^*1 一方のアプリケーション保守サービスでは、保守のプロセスの大半が範囲に入ります。

同じ「保守に対応できます」でも、アプリケーションの改修を指す会社と、サーバーやOSの面倒を見ることを指す会社があるわけです。候補の会社が大げさに言っているのではなく、自社の得意な範囲に沿って言葉を使っているだけ、ということもあります。

モデル契約は、保守と運用の仕事が幅広いことを前提にしています。保守運用の基本契約の解説は、業務のうちどの部分を委託する側が自らの要員で行い、どの部分を委託するかは「その時々のユーザのニーズに依存する」としています。^*1 範囲は相手が決めるものではなく、頼む側がまず線を引くもの、というのが資料の立場です。

工程は共通フレームの名前で聞く

工程の範囲は、共通フレーム2013のプロセスの名前で尋ねると食い違いが減ります。共通フレームは、システムの企画から開発、運用、廃棄までの作業を、プロセスという単位で体系立てて並べた枠組みです。開発の作業だけでも、システム開発プロセスが8つ、ソフトウェア実装プロセスが9つの下位のプロセスに分かれています。^*2

ソフトウェア実装の9つは、開始の準備、要件定義、方式設計、詳細設計、構築、結合、適格性確認テスト、導入、受入れ支援です。「設計から対応できます」と言われたら、方式設計からか詳細設計からか、テストは結合までか適格性確認テストまでか、と名前で確かめられます。

共通フレーム2013の第3部のガイダンスは、供給者（受注する側）の提案について、「プロジェクトの仕事の進め方を共通フレームで表し」、プロジェクトの特性に合わせたテーラリング（修整）案を含めることが望ましいとしています。^*2 取得者（発注する側）が、供給者の提案するプロセスを評価できることも書かれています。 SESパートナーの選定でも、候補に対応できるプロセスへ印を付けてもらえば、言い回しの違いに惑わされずに比べられます。

技術領域は対象システムで聞く

技術の範囲は、扱える言語や製品の名前だけでなく、対象のシステムで尋ねます。保守運用の基本モデル契約の第3条は、個別契約で決める項目として、業務内容とあわせて「対象とする情報システムの範囲及びその詳細」を挙げています。^*1 解説は、委託する業務内容、対象となるシステム、役割分担は取引ごとに異なるので、詳細は個別契約に添付する業務仕様書や受託条件明細で取り決めることを想定しているとしています。

オンサイト型のサンプルは、運用の対象の機器を、顧客先またはアウトソーシングセンターに置いたサーバーやPC、ネットワークとしています。 選定の場面に置き換えると、どのシステムの、どの層（アプリケーション、ミドルウェア、OS、ネットワーク）を任せるのかを先に書き出し、候補には層ごとに経験のある技術者がいるかを聞く形になります。

書き出すときは、システムの名前、使っている言語やフレームワーク、動いている環境（自社のサーバーかクラウドか）、つながっている外部のサービスまで並べておくと、候補が「できます」と答えた根拠を具体的に聞けます。

役割分担表で線を引く

工程と対象システムが決まったら、作業ごとにどちらが受け持つかを表にします。モデル契約は、保守運用のサンプルの受託条件明細として「ITサービスマネジメントの視点での役割分担表」を載せています。^*1 行にプロセスを16並べ、委託する側（甲）と受託する側（乙）のどちらかの欄に○を付け、備考に例外を書く形です。

2つのサンプルを並べると、インシデント管理からサービスレベル管理までの7行は、どちらも受託する側の担当です。違うのは3行で、キャパシティ管理とICTインフラストラクチャ管理はオンサイト型だけが受託する側に、アプリケーション管理はアプリケーション保守だけが受託する側に付いています。

備考の欄も見逃せません。アプリケーション保守のサンプルでは、可用性管理を委託する側の担当としたうえで、「アプリケーションプログラムの可用性管理は乙の担当」と例外を書いています。^*1 オンサイト型では、ICTインフラストラクチャ管理を受託する側に付けつつ、広域ネットワークと施設管理は委託する側に残しています。

資料の注釈は、この例ではプロセスの名前しか書いていないが、実際は「各プロセス毎の運用作業項目に分解し」て役割分担を定めるとしています。定義があいまいだと「甲と乙どちらが実施すべき作業か不明な事態が多々発生し」、サービスの実施に支障が出るとも書いています。^*1 選定の段階では、16行のうち自社に関係する行を選び、候補に1行ずつ答えてもらうのが現実的です。

体制と窓口を確かめる

誰が受け持つかの次は、どんな体制で受け持つかです。アプリケーション保守の業務仕様書のサンプルは、双方が「本件業務の履行のための連絡、確認を行う窓口責任者」とその他の実施体制を定め、相手への要請や依頼は窓口責任者を通じて行うとしています。^*1 窓口責任者が変わるときは、ただちに書面で相手に知らせることになっています。

開発のモデル契約の参考文書3は、受託する側の体制の例として、総括責任者、プロジェクトマネージャー、プロジェクトリーダー、システム監査担当、品質管理担当、PMO（プロジェクトマネジメントオフィス）を挙げています。総括責任者には「最終的な履行責任を負う役員クラスの者」を任命するとされ、品質管理担当はプロジェクトの遂行を品質管理と品質保証の視点から支える役です。^*1

SESパートナーの選定では、参画する技術者だけでなく、その技術者の後ろにいる人が誰かを聞いておきます。連絡の窓口になる人、技術者が困ったときに相談を受ける人、品質を見る人がいるかどうかで、対応範囲の実際の幅は変わります。

稼働の時間帯と場所

対応範囲には、いつ、どこで動けるかも含まれます。アプリケーション保守の業務仕様書のサンプルは、受託する側が業務を行う時間帯を、曜日と時刻を空欄にした形で書き、祝日と受託する側が指定する休業日を除くとしています。^*1 同じサンプルは、障害の連絡を受けてから最初に応答するまでの時間を守った比率など、3つのサービスレベル（達成目標の数値）を設けています。

場所について、開発のモデル契約の第4条の解説は、ユーザの環境で開発の作業を行わざるを得ない場合には、作業場所などの作業環境の使用条件を個別契約で定めるとしています。^*1 第39条第3項は、委託する側の事務所などで作業する必要があるとき、委託する側が作業の場所と、そこで要る機器や設備を提供すると定めています。

SESパートナーの候補には、平日の何時から何時まで動けるか、夜間や休日の障害に応じられるか、リモートで作業するか自社に来てもらうか、来てもらうなら週に何日か、を同じ書式で聞きます。自社のどの機器やネットワークに、どこからつないでもらうかもこのときに決めておくと、受け入れの準備を進めやすくなります。

範囲が変わるときの扱い

対応範囲は、始めた後に動くものとして扱います。オンサイト型の業務仕様書の注釈は、サービス開始後に「運用要件やシステム範囲が変更・追加になることは少なからず発生する」とし、そのときは受託条件明細と運用手順書を正確に直して合意しなければならないとしています。^*1 受託条件明細は、サービス開始前にサービス範囲と役割分担を合意したうえで契約を結ぶための文書だとも書いています。

アプリケーション保守のサンプルでは、受託条件明細の中身を変えたいときは委託する側が書面で知らせ、双方で協議して決めます。契約金額や契約条件に響くときは、別に変更の契約を結ぶとしています。 選定の段階で候補に、範囲が広がりそうなときにどう申し出てもらえるか、やり取りをどこに残すかを聞いておけば、参画後に範囲の外の作業が積み上がるのを防ぎやすくなります。

候補を比べる表の作り方

最後に、ここまでの項目を1枚の表にして、候補ごとに同じ形で埋めてもらいます。共通フレーム2013の第3部のガイダンスは、提案を評価するときに考える要素の例として、システム構築の能力・成熟度、対象領域の専門知識、過去の実績、経営上の安定性を挙げています。^*2 対応範囲の表は、このうち何ができるかを比べるための土台になります。

表の左の列を自社で先に埋めておくのがこつです。左が空いたまま候補に聞くと、答えは候補の得意な範囲に寄っていきます。左の列が書けないときは、任せる作業がまだ決まっていないということなので、選定の前に社内で詰めておきます。

実績の確かめ方はSESパートナー選定の実績確認、公開情報で裏づけを取る手順で扱っています。

下請負や監査の権利など、選定で聞いておきたい取り決めはSESパートナーの選定で聞ける5つの項目、下請負と監査の権利にまとめました。

複数の会社に分けて頼むときの調整はSESパートナー複数社のベンダーコントロールで整理しています。

まとめ：対応範囲で確かめておきたい3つの点

SESパートナーの選定で対応範囲を確かめるうえで、押さえておきたい点は3つに整理できます。第一に、工程は共通フレーム2013のプロセスの名前で、技術は対象のシステムとその層で尋ねること。第二に、役割分担表の形で作業ごとの担当を1行ずつ決め、例外は備考に書いてもらうこと。第三に、体制と窓口、稼働の時間帯と場所、範囲が変わったときの扱いまで、候補ごとに同じ表で比べることです。この3点を踏まえておけば、「保守まで対応できると聞いていたのに、頼みたい作業は範囲の外だった」という事態を避けやすくなります。任せたい範囲に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA・経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉」（2025年4月8日更新）（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：保守運用の部分の「保守運用業務の全体構成とサンプル事例」、情報システム保守運用委託基本モデル契約書の第1条の解説と第3条とその解説、業務仕様書サンプル（アプリケーション保守サービス・オンサイト型アウトソーシングサービス）とその注釈、ITサービスマネジメントの視点での役割分担表（2種）、ソフトウェア開発委託基本モデル契約書の第4条の解説（第8号）・第39条第3項、参考文書3を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：IPA「共通フレーム2013」第3部 共通フレームとガイダンス（PDF）（https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf）。出典：プロセスの一覧（2.3システム開発プロセス・2.4ソフトウェア実装プロセスの下位プロセス）、合意プロセスのガイダンス1.1.3.2・1.1.4.1・1.2.2.3を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：IPA「情報システム・モデル取引・契約書（第二版）」掲載ページ（https://www.ipa.go.jp/digital/model/model20201222.html）。公開日2020年12月22日。Word版〈第二版〉（2025年4月8日更新）の掲載元（確認日2026年10月2日）（2026年10月確認）

Tweet