「業務システムはA社、インフラはB社、デザインは別のC社へ」。複数の外注先に分けて発注することが決まり、各社から提案や見積もりは届いている。それでも、ある一点だけが宙に浮いたままになっていないでしょうか。「全体を誰がまとめるのか」「トラブルが起きたとき、まず誰に言えばいいのか」という点です。
複数のベンダーが関わるプロジェクトでよく起きるのが、不具合が出たときに「それはうちの担当範囲ではありません」と各社の見解が食い違い、発注者として仲裁したくても判断材料がなく動けない、という状況です。各社はそれぞれ自社の契約範囲を正しく主張しているだけなので、誰も嘘をついていないのに話が前に進みません。
このすれ違いは、担当者の能力や相性の問題ではなく、「責任の境界線」が事前に設計されていないという構造的な原因から生まれます。逆に言えば、契約段階で責任境界・窓口・会議体・エスカレーション経路を設計しておけば、混乱の多くは「発生してから対処する」のではなく「起きる前に予防する」ことができます。これがベンダーマネジメントの中核です。
本記事では、発注者の視点で「ベンダーマネジメントとは何か」を整理したうえで、複数ベンダー構成で管理が失敗する典型パターン、責任境界線の具体的な引き方、発注者側に必要な管理体制、そして契約書に盛り込むべき管理条項のチェックリストまでを順に解説します。読み終えたとき、次の打ち合わせで使える「責任分担の論点リスト」を手元に持てる状態を目指します。
なお本記事は、ベンダーを「選ぶ」段階ではなく、契約後にベンダーを「統制・管理する」段階に特化しています。選定段階の進め方は別の記事で扱っているため、必要に応じて後述の箇所で案内します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ベンダーマネジメントとは｜発注者が複数ベンダーを統制する活動
ベンダーマネジメントとは、システム開発などを外部に委託する発注者が、契約後のベンダー（外注先）を統制・管理し、プロジェクト全体を当初の目的・品質・納期・予算に沿って完遂させるための活動の総称です。日本語では「ベンダー管理」「ベンダーコントロール」とも呼ばれます。
ここで強調しておきたいのは、ベンダーマネジメントは「進捗をときどき確認すること」ではない、という点です。進捗確認は構成要素の一つにすぎません。本質は、複数の関係者の間に生まれる責任の境界線を設計し、その境界を運用と契約の両面で維持していくことにあります。この視点を最初に持っておくと、後で説明する管理体制や契約条項の意味が腑に落ちやすくなります。
ベンダーマネジメントの定義｜「選定」との違いと対象範囲
発注のプロセスは、大きく「選定フェーズ」と「管理・統制フェーズ」に分かれます。
- 選定フェーズ: RFP（提案依頼書）の作成、複数社からの提案比較、デモやヒアリング、発注先の決定までの活動
- 管理・統制フェーズ: 契約締結後、複数ベンダーを束ねてプロジェクトを完遂させる活動。本記事が対象とするのはこちら
選定フェーズの進め方はベンダー評価方法4ステップで詳しく解説しています。まだ発注先が固まっていない方は、先にそちらをご覧いただくと本記事の内容がより活きます。また、SIerやベンダーといった発注先の種類や違いを整理したい場合はSIerとベンダーの違いが参考になります。
ベンダーマネジメントの対象範囲は、契約管理・進捗管理・品質管理・コスト管理・コミュニケーション管理・リスク管理など多岐にわたります。ただし複数ベンダー構成では、これらすべての土台に「責任の境界線をどこに引くか」という設計が存在します。境界が曖昧なまま進捗や品質を管理しようとしても、「誰の責任で何を管理するのか」が定まらず、管理そのものが空回りしてしまいます。
ベンダーマネジメントが本格的に必要になる場面｜簡単な自己診断
すべての発注で重厚な管理体制が必要なわけではありません。1社に小規模な開発を依頼するだけなら、相手のプロジェクトマネージャーに任せても大きな問題は起きにくいでしょう。一方で、以下のような条件が重なるほど、発注者主導のベンダーマネジメントが必要になります。
- 複数の会社に分けて発注している（業務システムとインフラとデザインを別々に発注、など）
- 1社に発注しているが、その先に再委託先（下請け）が存在する
- 開発期間が長く、フェーズをまたいで複数の契約が走る
- システム同士の連携（データ連携・API連携）が成果物の重要部分を占める
- 社内に専任のプロジェクトマネージャーがおらず、発注者側の窓口が片手間になっている
複数当てはまる場合は、本記事の後半で扱う責任境界の設計と管理体制づくりが、プロジェクトの成否を左右します。特に「複数社への分割発注」と「連携が重要」が同時に成立する場合は、責任の隙間が生まれやすいため要注意です。次の章では、その理由を構造から見ていきます。
単一ベンダーと複数ベンダーで管理が変わる理由
ベンダーマネジメントの難易度は、発注の構図によって大きく変わります。ここでは代表的な2つの構図を比較し、複数ベンダーになると何が起きるのかを整理します。
単一ベンダー（プライム一括）と複数ベンダー直接発注の構図
単一ベンダー（プライムベンダー一括発注）の構図では、発注者は1社（プライムベンダー）とだけ契約します。プライムベンダーが必要に応じて下請けに再委託しますが、発注者から見れば窓口は1つです。プロジェクト全体の取りまとめ（プロジェクトマネジメント）も、原則としてプライムベンダーが担います。
[発注者] ──契約── [プライムベンダー] ──再委託── [下請けA]
└──再委託── [下請けB]
この構図では、システム同士の連携で不具合が出ても、責任の所在はプライムベンダーに集約されます。発注者が下請け間の調整に直接関与する必要は基本的にありません。
複数ベンダー直接発注（マルチベンダー）の構図では、発注者が複数の会社とそれぞれ直接契約します。
[発注者] ──契約── [A社：業務システム]
├────契約── [B社：インフラ]
└────契約── [C社：デザイン]
この構図のメリットは、各領域に強い会社を選べること、特定ベンダーへの依存（ロックイン）を避けられること、コストを最適化しやすいことです。マルチベンダーは柔軟性の高いIT戦略として広く採用されています（NTTコミュニケーションズ「マルチベンダーとは？」）。
一方で、各社の契約はそれぞれ独立しているため、会社と会社の「あいだ」を取りまとめる役割が、契約上は誰のものでもありません。プライムベンダーがいない以上、その取りまとめ役は原則として発注者自身に回ってきます。ここが、管理の難易度が跳ね上がる分岐点です。
複数ベンダーで「責任の隙間」が生まれるメカニズム
複数ベンダー構成で最も警戒すべきなのが、「責任の隙間（グレーゾーン）」です。各社は自社の契約範囲については責任を負いますが、契約範囲の「あいだ」に落ちるタスクは、どの会社の責任でもない状態になりがちです。
典型例が、システム間の結合部分です。A社が作る業務システムとB社が用意するインフラの接続でエラーが出たとき、A社は「アプリケーションは仕様どおり動いている」と言い、B社は「インフラは正常稼働している」と言います。どちらの主張も自社の契約範囲内では正しいのですが、肝心の「接続が動かない」という問題には誰も手を挙げません。これが責任の隙間です。
実際、システムテストの実務では、サブシステム内部の結合テストは各ベンダーの責任、サブシステム間をまたぐ結合テストはプライム（取りまとめ役）の責任、というように、組織上の立場によってテストの責任範囲が段階的に分かれます。マルチベンダーでは、この「またぐ部分」の主管が宙に浮きやすいのです（Sun*「システムテストの基礎知識」）。
責任の隙間は、次の2つが揃ったときに生まれます。
- 境界が定義されていない: どこからどこまでが各社の責任か、契約・仕様で明文化されていない
- 境界をまたぐ作業の主管が決まっていない: 連携部分の検証・不具合切り分けを「誰が主導するか」が決まっていない
裏を返せば、この2つを契約段階で潰しておけば、責任の隙間は大幅に減らせます。次の章では、まず読者が自分の状況を診断できるよう、隙間が放置された結果として起きる「失敗の典型パターン」を3つに整理します。
ベンダー管理が失敗する3つのパターン
複数ベンダー管理の失敗は、いくつかの決まったパターンに収束します。ここで紹介する3つは互いに関連していますが、自分のプロジェクトがどのパターンに陥りやすいかを診断する材料として読んでください。
パターン①｜責任の境界が曖昧でたらい回しが起きる
最も多く、最も発注者を疲弊させるのがこのパターンです。
ある画面でデータが正しく表示されない不具合が見つかったとします。発注者がA社（業務システム）に連絡すると「データの取得元はB社のAPIなので、まずB社に確認してほしい」と言われます。B社（インフラ・API）に連絡すると「APIは正しい値を返している。表示側の処理はA社の領域だ」と返ってきます。発注者は両社のあいだを何往復もすることになり、その間も不具合は直りません。
このパターンの根本原因は、不具合の「切り分け（どちらの問題かを特定する作業）」を誰が主導するのかが決まっていないことです。各社は自社の範囲を調べて「問題なし」と回答するだけで、横断的に原因を追う責任を負っていません。責任分解点と切り分けの主管を事前に決めていれば、この往復は発生しません。
パターン②｜全体を統括するPMが不在で部分最適に陥る
複数ベンダーがそれぞれ自社の契約範囲だけを最適化し、プロジェクト全体としては噛み合わない、というパターンです。
各社は自社の成果物を契約どおりに納めようとします。それ自体は正しい行動ですが、全体を見渡して優先順位を調整する人がいないと、たとえば「A社は来週リリースしたいが、B社のインフラ移行は再来週でないと完了しない」といったスケジュールの不整合が、誰にも気づかれないまま進行します。各社の定例では問題が表面化せず、統合の段階で初めて発覚します。
この問題の核心は、プロジェクト全体のプロジェクトマネジメント（PM）を担う主体が決まっていないことです。プライムベンダーがいない複数ベンダー構成では、PMの役割は自動的には埋まりません。発注者がPMを担うのか、いずれかのベンダーに取りまとめを委託するのか、外部のPMOに委託するのかを、明示的に決める必要があります。この判断軸は後ほど詳しく扱います。
パターン③｜情報共有が分断しトラブル発覚が遅れる
窓口や情報共有のルートがベンダーごとにバラバラで、しかも記録が残っていないために、問題の発覚が遅れるパターンです。
A社とは担当者がメールでやり取りし、B社とはチャットツール、C社とは電話と打ち合わせ、というように経路が分かれていると、各社に共有したつもりの情報が抜け落ちたり、決定事項が記録されず「言った・言わない」の争いになったりします。課題が一覧で管理されていないため、誰がいつまでに何を解決するのかが追えず、放置された課題がリリース直前に表面化します。
このパターンは、窓口の一元化と課題管理の仕組みがないことから生まれます。情報の流れを設計し、課題を一元的に記録・追跡する体制があれば、トラブルの兆候を早期に拾えます。
これら3つの失敗は、いずれも「責任境界の不在」「全体PMの不在」「情報の分断」という設計の欠落に起因します。裏を返せば、設計でほぼ予防できるということです。次の章から、その設計方法を具体的に解説していきます。
責任境界線の設計｜複数ベンダー管理の核心
ここが本記事の核心です。複数ベンダー管理の成否は、責任境界線をどれだけ具体的に設計できるかにかかっています。抽象的な「役割分担を明確にしましょう」では足りません。発注者が次の打ち合わせで使えるレベルまで具体化します。
責任分解点を引く3つの観点｜成果物・インターフェース・障害切り分け
責任分解点（責任の境界線）は、次の3つの観点から引くと漏れが少なくなります。
観点1：成果物の境界 各ベンダーが「何を」「どの品質基準で」納めるのかを明確にします。重要なのは、完成・合格の判定基準を事前に定義しておくことです。機能要件・非機能要件・テスト内容・合否の判定方法を曖昧にしたまま進めると、最終成果物の受け入れ段階で「これは契約範囲か」を巡って揉めます。判定基準を契約・仕様書に落とし込むことが、成果物の境界を引く第一歩です。
観点2：インターフェース（連携部分）の帰属 システム同士が連携する部分は、責任が宙に浮きやすい最重要ポイントです。「A社のシステムとB社のAPIの接続仕様は誰が定義し、誰が維持するのか」「連携に変更が生じたとき、どちらが対応するのか」を、連携箇所ごとに明文化します。インターフェース仕様書の作成・管理責任を一方に明確に割り当てることで、グレーゾーンを大幅に減らせます。
観点3：障害切り分けの責任者 不具合が発生したとき、「どちらの問題かを特定する作業（切り分け）」を誰が主導するのかを事前に決めます。先に述べたたらい回しは、この主管が決まっていないために起きます。「連携部分の障害はまず◯◯が一次切り分けを行い、原因が確定したら責任ベンダーが対応する」といったルールを決めておけば、発注者が両社のあいだを往復する事態を防げます。
グレーゾーンタスクを契約前に割り当てる
3つの観点で境界を引いても、必ず「どちらの担当とも言い切れないタスク」が残ります。連携部分の総合テスト、本番移行時の立ち会い、リリース後の初期サポート、ドキュメントの統合などです。これらのグレーゾーンタスクは、契約締結前に一覧化し、一つひとつ「どの会社が」「どこまで」担うのかを割り当てておくことが重要です。
ここで有効なのが、RACIチャート（責任分担表）です。RACIは、各タスクについて4つの役割を割り当てるフレームワークです（Asana「RACIチャートとは？」）。
- R（Responsible：実行責任者）: 実際にその作業を行う担当
- A（Accountable：説明責任者）: そのタスクの完遂に最終責任を負う者。1タスクにつき1人（1社）に絞るのが原則
- C（Consulted：相談先）: 作業にあたって意見を求める相手
- I（Informed：報告先）: 結果を共有される相手
グレーゾーンタスクをこの表に当てはめ、特に「A（説明責任者）」を必ず1社に確定させることで、「誰も最終責任を負っていない」状態を解消できます。タスクごとに行を作り、各ベンダーと発注者を列に並べ、R・A・C・Iを記入していけば、責任の空白も重複も一目で見つけられます。この表は、後述する契約書の添付資料としてもそのまま活用できます。
全体PMを誰が担うか｜発注者直轄・プライム集約・PMO委託の判断
複数ベンダー構成では、プロジェクト全体のPMが自動的には決まりません。誰が担うかには主に3つの選択肢があり、自社の状況に応じて選びます。
選択肢 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
発注者直轄 | 発注者社内のメンバーが全体PMを担う | 社内にPM経験者がいる／プロジェクトが小〜中規模 | 片手間では破綻する。相応の工数確保が前提 |
プライム集約 | 主要ベンダー1社に取りまとめを委託し、他社をその下にぶら下げる | 技術的な中核を担うベンダーが明確 | 取りまとめ費用が発生。他社統制の権限を契約で付与する必要 |
PMO委託 | 外部のPMO（プロジェクト管理専門の支援者）に統括を委託する | 社内にPM人材がなく、規模・難易度が高い | 委託費用が発生。発注者の意思決定責任までは委譲できない |
判断の軸はシンプルです。「社内に、全体を見渡してベンダー間を調整できる人材と工数があるか」を起点に考えます。あるなら発注者直轄、技術的中核ベンダーに任せられるならプライム集約、いずれも難しければPMO委託を検討します。
ただし、どの選択肢を選んでも、最終的な意思決定責任は発注者に残る点は変わりません。PMO委託でも「どのベンダーの主張を採用するか」「予算超過を許容するか」といった経営的判断は発注者が負います。誰がPMを担うかを決めたら、それを契約や体制に落とし込みます。次の章では、設計した責任境界を日々の運用に落とす管理体制の作り方を見ていきます。
発注者側の管理体制の作り方｜窓口・会議体・報告ルール
責任境界を設計しても、それを運用する体制がなければ絵に描いた餅になります。ここでは、発注者が用意すべき最小限の管理体制を、窓口・会議体・課題管理の3点から具体化します。
窓口の一元化（SPOC）と発注者側の役割分担
まず、発注者側の窓口を一本化します。各ベンダーから見て「この件はこの人に連絡すればよい」という単一の窓口（SPOC：Single Point of Contact）を置くことで、情報の抜け漏れと「言った・言わない」を防ぎます。失敗パターン③（情報の分断）への直接の対策です。
窓口を一元化したうえで、発注者社内の役割も分担しておきます。最低限、次の役割を誰が担うかを決めます。
- 窓口担当: ベンダーとの日常的なやり取りの一次窓口
- 意思決定者: 仕様変更・予算・スケジュールの最終判断を下す責任者
- 業務側の確認者: 成果物が実際の業務で使えるかを検証する現場担当
小規模なら1〜2名が兼任しても構いませんが、「意思決定者」だけは曖昧にしないことが重要です。ベンダー間の主張が食い違ったとき、最終的に裁定を下すのはこの人です。
会議体の設計｜全体定例と個別定例の階層
会議体は、階層を分けて設計すると機能します。
- 全体定例（週次または隔週）: 発注者と全ベンダーが参加。プロジェクト全体の進捗・課題・連携部分の論点を共有する。ベンダー間の依存関係や日程の不整合を早期に発見する場
- 個別定例（必要に応じて）: 発注者と各ベンダーが個別に行う。各社固有の詳細な進捗・技術的論点を扱う
全体定例の最大の目的は、各社が自社のことだけを報告して終わる「部分最適」（失敗パターン②）を防ぐことです。連携部分やスケジュールの整合を、必ず全員が同席する場で確認します。会議には簡潔でよいので議事録を残し、決定事項・宿題・期限を記録します。記録の欠如が後のトラブルの温床になるためです。
課題管理とエスカレーション経路の事前設計
最後に、課題（イシュー）を一元管理する仕組みと、問題が起きたときの上申ルート（エスカレーション経路）を事前に設計します。
課題管理表（イシュー一覧）の一元化 発覚した課題を、ベンダーをまたいで1つの表で管理します。各課題に「内容」「責任者（誰が解決を主導するか）」「期限」「ステータス」を記録し、全体定例で更新します。表計算ソフトの共有シートでも、課題管理ツールでも構いません。重要なのは、課題が1か所に集約され、誰がいつまでに対応するかが追える状態を保つことです。
エスカレーション経路の事前設計 ベンダー間の主張が食い違い、現場で解決できない事態に備えて、「どの段階で・誰が・誰に上申するか」を事前に決めておきます。たとえば「担当者間で2営業日以内に解決しない技術的論点は、発注者の意思決定者と各社のPMが参加する場に上げる」といったルールです。
このエスカレーション経路こそが、冒頭で挙げた「各社の主張が食い違っても発注者として仲裁できない」という事態を防ぐ仕組みです。経路を事前に決めておけば、食い違いが起きても発注者は慌てずに「では決めておいたとおり、この論点はエスカレーションします」と主導権を持って場を動かせます。経路がないと、問題が宙に浮いたまま放置され、リリース直前に火を噴きます。なお、プロジェクト全体のリスクをどう洗い出し管理するかはプロジェクトリスク管理で詳しく解説しているので、あわせて参照してください。
ここまでで設計した責任境界・管理体制を、最後に契約で担保します。運用ルールは口約束では守られません。次の章で、契約書に盛り込むべき条項をチェックリスト化します。
契約書に盛り込むべき管理条項チェックリスト
責任境界と管理体制を設計しても、契約書に書かれていなければ、いざというとき各社に履行を求める根拠になりません。ここでは、複数ベンダー管理のために契約書へ盛り込みたい条項を、発注者がそのまま打ち合わせに持ち込めるチェックリストとして整理します。各社との契約・打ち合わせの際に、抜けがないか確認してください。
なお、システム開発契約の条項設計に迷う場合は、経済産業省・IPAが公開している「情報システム・モデル取引・契約書（第二版・民法改正対応版）」が参考になります。これはIT専門家を持たない企業とベンダーの取引を想定したモデルで、ユーザーとベンダーの役割分担・協力義務、多段階契約などの考え方が整理されています（IPA「情報システム・モデル取引・契約書（第二版）」）。
責任分担・連携協力を担保する条項
- 責任分担表（責任分解点）の添付: 前章で作成したRACIチャートや責任分解点の定義を、契約の別紙として添付し、契約の一部に組み込む。これが揉めたときの最も強力な根拠になる
- ベンダー間の連携協力義務: 自社の契約範囲だけでなく、他ベンダーとの連携・情報提供に協力する義務を明記する。システム開発では、当事者の協働・役割分担を契約で定めることが完遂の前提とされており、協力が欠けると開発が頓挫しかねません（業務委託契約書ドットコム「システム等開発業務委託契約書の重要な35の契約条項」）
- インターフェース仕様の管理責任: 連携仕様書の作成・更新責任をどちらが負うかを明記する
報告義務・SLA・契約不適合責任の条項
- 報告義務と頻度: 進捗・課題の報告フォーマットと頻度（全体定例への参加義務を含む）を定める
- SLA（サービス品質の合意）: 特に運用・保守を含む契約では、応答時間・復旧時間・稼働率などの品質基準と、未達時の扱いを定める
- 契約不適合責任の範囲と期間: 請負型契約では、納品物が契約内容に適合しない場合に受託者が負う責任を定める。民法上、不適合を把握した日から1年以内に通知すれば責任を問えるのが原則のため、検収後の不具合に備えて通知期間・対応範囲を確認しておく（コーポレートA法律事務所「システム開発の契約不適合責任」）
再委託・引き継ぎ・成果物帰属の条項
- 再委託の可否と事前承認・通知義務: ベンダーがさらに下請けへ再委託する場合のルールを定める。実務では再委託を発注者の事前承認にかからせる規定が多く、情報漏えいリスクや管理範囲の把握のために重要です（弁護士法人クラフトマン「システム開発契約における再委託規定」）
- 成果物・知的財産の帰属: 納品物の著作権・所有権が発注者に帰属するのか、利用許諾にとどまるのかを明確にする。複数ベンダーがまたぐ成果物では特に曖昧になりやすい
- 解除・引き継ぎ条項: いずれかのベンダーとの契約が中途で終了した場合に備え、成果物・ドキュメントの引き継ぎ義務、データの返還ルールを定める。1社が抜けてもプロジェクトが止まらないための保険
これらの条項を契約段階で詰めておけば、責任境界の設計が「合意文書」として担保されます。トラブルが起きてから条項を作ることはできません。だからこそ、契約前のこの段階が勝負どころです。
まとめ｜契約段階で責任境界を設計すれば混乱は防げる
ベンダーマネジメントとは、発注者が契約後のベンダーを統制し、プロジェクト全体を目的どおりに完遂させる活動です。そして複数ベンダー構成では、その中核が「責任境界線の設計」にあることを本記事では一貫して述べてきました。最後に要点を整理します。
- ベンダーマネジメントは「進捗確認」ではなく「責任境界の設計と統制」が本質。複数社発注・再委託あり・連携が重要、といった条件が重なるほど、発注者主導の管理が必要になる
- 複数ベンダー構成では契約と契約の「あいだ」が誰の責任でもなくなり、責任の隙間（グレーゾーン）が生まれる。これが、たらい回し・部分最適・情報分断という3つの失敗パターンの原因
- 責任分解点は「成果物・インターフェース・障害切り分け」の3観点で引く。グレーゾーンタスクはRACIチャートで割り当て、説明責任者（A）を必ず1社に確定させる。全体PMの担い手（発注者直轄／プライム集約／PMO委託）も明示的に決める
- 設計した責任境界は、窓口の一元化（SPOC）・全体定例と個別定例の会議体・課題管理表・エスカレーション経路という運用体制で支える
- 最後に、責任分担表の添付・連携協力義務・再委託の事前承認・契約不適合責任など、管理条項を契約書に盛り込んで設計を担保する
ここまで読んで、まず取りかかれることは2つです。1つは、自社プロジェクトのグレーゾーンタスクを洗い出してRACIチャートに整理すること。もう1つは、各社との契約・打ち合わせの前に、本記事のチェックリストで抜けがないかを確認することです。トラブルは「発生してから対処」では遅く、「契約段階で予防」するものだという視点を持って次の打ち合わせに臨めば、複数ベンダーのプロジェクトは格段に運びやすくなります。
なお、そもそもどのベンダーに発注するかをこれから決める段階の方は、ベンダー評価方法4ステップで選定の進め方を、SIerとベンダーの違いで発注先の種類を確認しておくと、選定段階から責任分担を意識した発注ができます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
