「要件定義 → 設計 → 開発 → テスト → リリース」。開発会社から渡されたスケジュール表を眺めながら、「自分はこの中で、どこにどれだけ関わればいいのだろう」と手が止まってしまった——システム開発の発注を任された方なら、一度はこの不安を抱えたことがあるのではないでしょうか。
任せきりにすれば「思っていたものと違う」が出来上がるかもしれない。かといって、すべての工程に細かく口を出す時間も技術知識もない。過去に一度、要件のすり合わせ不足や終盤の仕様変更で予算と納期が膨らんだ経験があると、なおさら「今度こそ関与の塩梅を間違えたくない」という気持ちが強くなります。
実は、この悩みの正体は「全工程で同じように関わろうとしている」ことにあります。発注者の関与は、工程によって濃くすべきところと、開発会社に委ねてよいところがはっきり分かれます。そして、本当に大切なのは「何をするか（作業）」よりも「何を決めるか（意思決定）」です。発注者にしか下せない判断を工程ごとに押さえておけば、任せきりにも過干渉にもならない「ちょうどいい関与」が設計できます。
本記事では、システム開発の発注者の役割を工程別に整理し、各工程で「発注者が決めること／開発会社に委ねてよいこと／発注者が確認すること」の3つに分けて線引きします。要件定義から運用保守まで、各工程の意思決定ポイントを早見表つきで解説しますので、いま手元にあるスケジュール表に「関与の濃淡」を書き込めるようになるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
工程別に見る発注者の役割——なぜ「全工程で同じ関与」ではダメなのか
システム開発のスケジュール表には、工程の名前と期間は書かれていても、「発注者がどの工程でどれだけ関わるべきか」までは書かれていないことがほとんどです。これが発注者を不安にさせる最大の原因です。
結論から言うと、発注者の関与は全工程で一定ではありません。深く関わって自ら判断すべき工程と、開発会社のプロに委ねたほうがうまくいく工程が、はっきり分かれているのです。
発注者の関与は工程ごとに濃淡をつける
発注者の関与度を1本の曲線でイメージすると、上流（要件定義・設計の前半）で最も高くなり、開発（実装）の最中はいったん下がり、テスト（受け入れテスト）とリリース判定で再び高くなる、という二つの山ができます。
なぜこの形になるのかというと、発注者が深く関わるべきなのは「ビジネス上の判断が必要な工程」だからです。「何を作るか」「どの業務を優先するか」「これで本番にしてよいか」といった問いは、業務を一番よく知っている発注者にしか答えられません。一方、「どんな技術で実現するか」「内部のデータ構造をどう設計するか」といった問いは、開発会社の専門領域です。
つまり、関与の濃淡は気分や忙しさで決めるものではなく、「その工程の判断にビジネス知識が必要かどうか」で決まります。この物差しを持つだけで、「ここは踏ん張る」「ここは任せる」の見当がつくようになります。
本記事の判断フレーム——「決める」「委ねる」「確認する」の3分類
関与の濃淡をもう一段具体的にするために、本記事では各工程での発注者の関わりを次の3つに分類します。
- 決める: 発注者にしか判断できないこと。業務要件、優先順位、予算・納期の制約、本番化の可否など。ここを曖昧にすると後工程で必ず手戻りが発生します。
- 委ねる: 開発会社の専門性に任せたほうが品質が上がること。技術的な実現方式、内部設計、テスト手法など。発注者が口を出すと、かえって最適解から遠ざかります。
- 確認する: 自分で決めるわけではないが、見落としがないかをチェックすべきこと。要件定義書の網羅性、設計の使い勝手、進捗の健全性など。「決める」と「委ねる」の中間にある関与です。
本記事では、システム開発でよく使われる6つの工程——要件定義／設計／開発（実装）／テスト／リリース・移行／運用保守——を、この3分類に沿って一つずつ見ていきます。各工程を読み進めるうちに、「自分が踏ん張るべき場所」が自然と浮かび上がってくるはずです。
なお、発注の手順そのもの（構想からRFP作成、検収、保守契約まで）を全体の流れとして押さえたい場合は、システム開発の外注プロセスもあわせてご覧ください。本記事は「手順」ではなく「各工程での意思決定」に焦点を当てています。
上流工程ほど発注者が深く関わるべき理由
工程別の話に入る前に、「なぜ上流（要件定義・設計）でこそ発注者が深く関わるべきなのか」を押さえておきましょう。これが分かると、関与の濃淡を自分で判断する物差しが手に入ります。
手戻りの多くは上流の意思決定に起因する
ソフトウェア開発で発生する手戻り（やり直し）の多くは、要件定義や設計といった上流工程での判断のあいまいさに端を発します。IPA（独立行政法人情報処理推進機構）も、システム構築の品質と費用を左右する鍵として上流工程の強化を一貫して重視しており、要件定義の進め方をまとめたガイドや、超上流工程の取り組みに関する資料を公開しています（IPA システム構築の上流工程強化 関連情報）。
なぜ上流のミスは尾を引くのでしょうか。それは、上流で決めたことが下流のすべての工程の土台になるからです。要件定義で「この業務はシステム化する／しない」を決め、その上に設計が乗り、設計の上に実装が乗り、実装の上にテストが乗ります。土台にあたる要件定義の判断が一つ食い違っていると、その上に積み上げたものをまとめて作り直すことになります。
実装が終わった段階で「やっぱりこの機能が必要だった」と気づくと、要件の見直し・設計のやり直し・実装の修正・テストの再実施が連鎖します。同じ修正でも、要件定義の段階で気づいていれば文書の数行を直すだけで済んだはずです。「上流で見つければ安く、下流で見つけるほど高くつく」というのが、手戻りコストの基本構造です。
IPA は、開発全体の中で要件定義と基本設計といった上流工程に十分な工数（おおむね全体の3割超を目安とする考え方が示されています）を割り当てることで、後工程の手戻りを抑えられるという立場をとっています。発注者が上流で深く関わることは、この「上流に投資して下流の手戻りを防ぐ」という考え方を、お金の使い方だけでなく意思決定の面からも実践することにほかなりません。
「決めるべきことを決めない」と後工程で何が起きるか
上流で発注者が判断を先送りすると、開発はどう転ぶのでしょうか。よくあるのは、開発会社が「発注者は決めてくれないが、開発は前に進めなければならない」という状況に追い込まれ、現場の推測で仕様を埋めてしまうケースです。
推測で進んだ部分は、たいてい後から「思っていたものと違う」という形で表面化します。そのとき初めて発注者が「本当はこうしたかった」と判断を示しても、すでに作り込まれた後では修正の範囲が大きくなっています。判断を先送りした分だけ、手戻りのコストが積み上がっているのです。
ここから導けるのは、「発注者が関与の濃淡を決める基準は、その工程での判断ミスが後工程にどれだけ波及するか（手戻りコストの大きさ）である」ということです。波及が大きい上流の判断ほど、発注者は時間をかけてでも自分で決め切る。波及が小さく専門性が高い判断は、開発会社に委ねる。この原則を頭に置いて、次から各工程を具体的に見ていきましょう。
要件定義工程の発注者の役割——「何を作るか」を決めるのは発注者
要件定義は、発注者の意思決定が全工程で最も濃くなる工程です。ここで決まる「何を作るか」は、開発会社がどんなに優秀でも代わりに決めることはできません。なぜなら、自社の業務を一番よく知っているのは発注者だからです。
発注者が決めること（業務要件・優先順位・予算/納期の制約）
要件定義で発注者が決め切るべきことは、大きく3つあります。
ひとつ目は業務要件です。「このシステムでどの業務を、どう回したいのか」という、システム化の目的そのものです。現状の業務フローのどこを効率化したいのか、どんな課題を解決したいのかは、現場を持つ発注者にしか言語化できません。
ふたつ目は優先順位です。やりたいことを並べると、たいてい予算と納期に収まりきりません。そこで「絶対に外せない機能（Must）」「あれば望ましい機能（Want）」を発注者が仕分けする必要があります。この優先順位づけを開発会社に丸投げすると、ビジネス上重要でない機能に工数が割かれてしまう恐れがあります。
みっつ目は予算・納期の制約です。「いつまでに、いくらで」という枠は、ビジネス判断そのものです。この枠を最初に明示しておくことで、開発会社は枠に収まる実現方式を提案できます。
要件の詳しい固め方や要件定義書の作り方については、要件定義の進め方で具体的に解説しています。
開発会社に委ねてよいこと（技術的な実現方式の提案）
一方で、「その業務要件をどんな技術・仕組みで実現するか」は、開発会社に委ねてよい領域です。
たとえば「申請から承認までをオンライン化したい」という業務要件に対して、それをどんなアーキテクチャで、どのクラウドサービスを使い、どんなデータ構造で実現するかは、技術的な専門判断です。ここに発注者が「この技術を使ってほしい」と特定の手段を指定すると、より適した選択肢を開発会社が提案する余地を狭めてしまいます。
発注者が伝えるべきは「実現したい状態（What）」であって、「実現の手段（How）」ではありません。手段は開発会社のプロに委ね、複数の選択肢が提案された場合に「業務にとってどれが望ましいか」を判断する立場に回るのが、ちょうどよい関与です。
発注者が確認すること（要件定義書の合意・抜け漏れチェック）
要件定義の最後に発注者が担うのが、要件定義書の確認です。これは「決める」でも「委ねる」でもない、中間の関与にあたります。
確認の観点は「自分が伝えた業務要件が、抜け漏れなく・誤解なく文書化されているか」です。専門用語の正確さをチェックするのではなく、「この通りに作られたら、実際に自社の業務が回るか」を業務の目線で読むことが大切です。
ここで「だいたい合っていそうだから」と斜め読みで合意してしまうと、認識のズレがそのまま設計・実装に引き継がれます。要件定義書への合意は、後工程の手戻りを防ぐ最後の関門です。違和感があれば、この段階で遠慮なく質問・修正依頼を出すことが、結果的にプロジェクト全体を守ります。
設計工程の発注者の役割——画面と業務フローの「使い勝手」を判断する
設計工程は、「外部設計」と「内部設計」の2つに分かれます。発注者が関わるのは主に外部設計で、内部設計は開発会社に委ねる、という線引きを押さえると関与の濃淡が明確になります。
発注者が決める・承認すること（外部設計＝画面/帳票/業務フロー）
外部設計とは、利用者の目に触れる部分の設計です。画面のレイアウト、入力項目、帳票の様式、操作の流れ（業務フロー）などがこれにあたります。
この領域は発注者が承認責任を持つべきポイントです。なぜなら、画面や業務フローが「実際の業務で回るかどうか」を判断できるのは、現場を知る発注者だけだからです。技術的に正しく作られていても、現場の手順と噛み合わなければ、そのシステムは使われません。
設計レビューで発注者が確認すべきは、技術的な正しさではなく「この画面で、現場の担当者が無理なく業務をこなせるか」という使い勝手です。たとえば「毎日100件処理する画面なのに、1件ごとに何度もクリックが必要では現場が回らない」といった指摘は、業務を知る発注者にしかできません。画面イメージや業務フロー図を見て、自社の実際の業務シーンを頭の中で再生しながらチェックするのが効果的です。
開発会社に委ねること（内部設計＝DB・アーキテクチャ）
一方、内部設計——データベースの構造、システム内部の処理方式、アーキテクチャ——は、開発会社に委ねてよい領域です。
これらは利用者から直接は見えない、システムの「内臓」にあたる部分です。性能・拡張性・保守性といった技術的な観点で最適化すべきものであり、発注者がビジネス目線で判断する種類の事柄ではありません。「使い勝手は自分が見る、内部の作りは開発会社に任せる」という分担を意識すると、技術の細部に踏み込む自信がなくても、設計工程で果たすべき役割を過不足なく担えます。
なお、こうした設計を担う開発会社側のメンバー（プロジェクトマネージャーやシステムエンジニアなど）がそれぞれどんな役割を持つのかを把握しておくと、誰に何を確認すればよいかが見えやすくなり、設計工程でのやり取りがスムーズになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発工程の発注者の役割——進捗を「見える化」させ判断材料を確保する
開発（実装）工程は、発注者の直接的な作業がもっとも少なくなる工程です。実際にコードを書くのは開発会社であり、発注者がここで手を動かすことはほとんどありません。
だからといって「任せきりでよい」わけではありません。発注者はこの工程で、仕様変更の意思決定窓口であり続け、進捗の健全性を見守る役割を担います。関与は薄くなっても、判断者としての立場は降りない、というのがポイントです。
開発中に発注者が決めること（仕様変更の採否・優先順位）
開発が進むと、ほぼ必ず「当初想定していなかった事態」が出てきます。「実際に画面を触ってみたら、この項目も必要だと分かった」「業務側の事情が変わって、ある機能の優先度が上がった」といった変更要望です。
このとき「その変更をやるのか／やらないのか／後回しにするのか」を決めるのは発注者の役割です。仕様変更には必ず追加の工数（=コストと納期への影響）が伴います。開発会社は「変更すると、これだけ時間と費用がかかります」という見積もりを示すことはできますが、「その費用と納期延長を受け入れてでもやるべきか」というビジネス判断は、発注者にしか下せません。
ここで発注者が判断を曖昧にすると、変更要望が宙に浮いたまま開発が進み、後でまとめて反映しようとして大きな手戻りになります。変更要望が出たら、その場で「やる・やらない・後回し」をはっきり決めて開発会社に伝えることが、開発工程での発注者の最大の仕事です。
確認の型——定例で見るべき進捗指標と「赤信号」の見極め
開発工程の関与は、定例ミーティングを通じた進捗確認が中心になります。ここで大切なのは、「順調です」という言葉を鵜呑みにせず、判断材料を確保することです。
定例で確認したい代表的なポイントは次のとおりです。
- 予定と実績の差: 計画していた作業が予定どおり完了しているか。遅れがある場合、その原因と挽回の見通しが説明されているか。
- 未解決の課題（懸念事項）: 開発側が抱えている判断待ち・調整待ちの項目が放置されていないか。発注者の判断を待っている課題があれば、速やかに決める。
- 仕様変更の影響: これまでに発生した変更が、納期や予算にどう影響しているか。
逆に「赤信号」として警戒すべきは、「課題が毎回同じ状態で繰り越されている」「進捗の説明が抽象的で具体的な数字が出てこない」「悪い報告がいつも遅れて出てくる」といったサインです。こうした兆候を早めにつかみ、原因を一緒に掘り下げる姿勢が、終盤の炎上を防ぎます。
工程全体を通じた発注者の関わり方（意思決定・品質確認・関係調整）を横断的に整理したい場合は、発注者のプロジェクトマネジメントもあわせてご覧ください。
テスト工程の発注者の役割——「業務で使えるか」の最終判断者になる
テスト工程は、発注者の関与が再び濃くなる二つ目の山です。テストにはいくつか種類がありますが、発注者が主役になるのは「受け入れテスト（UAT）」です。
発注者が主役の工程＝受け入れテスト（UAT）
テストには、開発会社が品質を担保するための「単体テスト」「結合テスト」と、発注者が業務目線で確認する「受け入れテスト（UAT：User Acceptance Test）」があります。
このうち単体テスト・結合テストは、「プログラムが仕様どおり正しく動くか」を技術的に検証するもので、開発会社の責任領域です。発注者がここに踏み込む必要はありません。
一方、受け入れテストは発注者が主役です。受け入れテストの目的は「仕様どおり動くか」ではなく「実際の業務で問題なく使えるか」を確かめることにあります。仕様書どおりに作られていても、現場の実際の使い方を想定すると「この手順では業務が回らない」といった問題が見つかることがあります。それを発見できるのは、業務を知る発注者だけです。
効果的な受け入れテストのコツは、機能を一つずつ単独で試すのではなく、「実際の業務シナリオを最初から最後まで通しでなぞる」ことです。たとえば「申請を受け付け、承認し、帳票を出力し、データを集計する」という一連の流れを、現場の担当者が普段どおりの手順で実行してみる。こうすると、機能単位のテストでは見逃しがちな「業務の流れの中での使いにくさ」が浮かび上がります。
検収可否を決める判断基準
受け入れテストの結果を受けて、「このシステムを検収する（受け入れる）か、まだ受け入れないか」を決めるのも発注者の役割です。これはプロジェクトの中でも特に重い意思決定の一つです。
検収可否を判断する基準は、「想定した業務が、実用に耐える品質で回るか」です。判断にあたっては、発見された不具合を重要度で仕分けることが欠かせません。「業務が止まる致命的な不具合」が残っていれば検収は見送るべきですが、「軽微で、運用でカバーできる、あるいはリリース後の改修で対応できる不具合」まで完璧を求めて検収を止めると、いつまでも本番化できなくなります。
大切なのは、すべての不具合をゼロにすることではなく、「どの不具合は本番化前に直すべきで、どれは後回しにできるか」を発注者が線引きすることです。検収・受け入れテストの具体的な進め方やチェック項目は、受け入れテスト（検収）の進め方で詳しく解説しています。
リリース・移行〜運用保守工程の発注者の役割——「いつ本番にするか」を決める
プロジェクトの終盤、そして本番稼働後も、発注者には「決める役割」が続きます。むしろ、ビジネスへの影響が最も大きい判断が、この局面に集まっています。
リリース判定（Go/No-Go）と移行の業務影響判断
開発・テストが完了すると、「いよいよ本番システムに切り替える（カットオーバー）」という局面が訪れます。このとき「予定どおり本番化を進めるか、それとも延期するか」というリリース判定（Go/No-Go）を下すのは発注者です。
リリース判定で発注者が考えるべきは、技術的な準備状況だけではありません。「いまの業務の繁忙期にぶつかっていないか」「現場への操作説明（教育）は済んでいるか」「もし切り替え当日にトラブルが起きたら、業務を止めずにリカバリーできる体制があるか」といった、業務側の準備とリスクです。技術的にはリリース可能でも、業務側の準備が整っていなければ「No-Go（延期）」を選ぶ判断も、発注者の重要な役割です。
また、既存システムからの移行（データの引っ越しや、旧システムとの並行稼働など）にあたっては、「移行作業中に業務をどこまで止めるか」「休日に作業するか」といった、業務影響を伴う判断が発生します。これらも、現場への影響を見通せる発注者が決めるべき事柄です。
運用保守フェーズで発注者が決めること（保守範囲・改善の優先度）
本番稼働は、プロジェクトの終わりではなく、システムを使い続ける運用フェーズの始まりです。ここでも発注者には決めるべきことがあります。
ひとつは保守範囲と体制です。「障害が起きたとき、どのくらいの時間で対応してほしいか」「どこまでを保守契約に含め、どこからを都度依頼にするか」といった条件は、コストと安心感のバランスを見て発注者が決めます。
もうひとつは改善の優先度です。システムは使い始めてから「ここをこう変えたい」という要望が必ず出てきます。それらの改善要望を、限られた予算の中でどの順に実現していくかを判断するのも発注者の役割です。運用フェーズに入っても、「何を優先するか」という意思決定者であり続けることに変わりはありません。
工程別 発注者の意思決定 早見表
ここまで見てきた各工程の意思決定を、「決める／委ねる／確認する」の3分類で一覧にまとめます。手元に置いて、いまのプロジェクトの関与度を点検する物差しとしてお使いください。関与の濃淡は、◎（最も濃い）／○（濃い）／△（薄い）で示しています。
工程 | 関与の濃淡 | 発注者が決めること | 開発会社に委ねること | 発注者が確認すること |
|---|---|---|---|---|
要件定義 | ◎ | 業務要件・優先順位（Must/Want）・予算/納期の制約 | 技術的な実現方式の提案 | 要件定義書の網羅性・業務が回るか |
設計 | ○ | 外部設計（画面・帳票・業務フロー）の承認 | 内部設計（DB・アーキテクチャ） | 設計が実際の業務で回るか（使い勝手） |
開発（実装） | △ | 仕様変更の採否・優先順位 | 実装方法・コーディング | 定例での進捗・課題・赤信号の有無 |
テスト | ◎ | 検収可否・不具合の対応優先度 | 単体・結合テストの実施 | 受け入れテストで業務シナリオが通るか |
リリース・移行 | ◎ | リリース判定（Go/No-Go）・移行時の業務影響 | 移行手順・技術的な切り替え作業 | 業務側の準備・教育・リカバリー体制 |
運用保守 | ○ | 保守範囲・体制・改善の優先度 | 障害対応・保守作業の実施 | 保守報告・改善要望の進捗 |
この表を眺めると、発注者の関与が「要件定義」「テスト」「リリース」で濃く（◎）、「開発」で薄く（△）なる二つの山が見えてきます。これが冒頭で触れた「関与曲線」の正体です。
よくある質問（FAQ）
発注者が一番関わるべき工程はどこですか？
要件定義工程です。「何を作るか」を決めるのは発注者にしかできず、ここでの判断が後工程すべての土台になるためです。要件定義であいまいに決めたことは、設計・実装・テストへと連鎖的に引き継がれ、後で気づくほど修正コストが大きくなります。時間が限られている場合でも、要件定義への関与だけは削らないことをおすすめします。
技術が分からなくても発注者として正しく判断できますか？
できます。発注者が判断すべきことの多くは「技術の良し悪し」ではなく「業務にとって望ましいか」というビジネスの問いだからです。画面の使い勝手、機能の優先順位、本番化のタイミングといった判断は、技術知識ではなく業務知識で下せます。技術的な実現方式やデータ構造といった専門領域は開発会社に委ね、発注者は「自社の業務が回るか」という土俵で判断すれば十分です。
開発会社に任せきりにすると、なぜ失敗しやすいのですか？
発注者が判断を示さないと、開発会社が現場の推測で仕様を埋めてしまい、後から「思っていたものと違う」という形で表面化するためです。特に上流（要件定義）での判断の先送りは、下流の工程で大きな手戻りを招きます。「任せきり」と「過干渉」の中間で、ビジネス判断が必要な場面では発注者が決め切り、専門領域は委ねる、という使い分けが失敗を防ぎます。
社内に専任の担当者がいない場合はどうすればよいですか？
すべての工程に深く関わるのが難しい場合は、関与の濃淡を意識して、力を入れる工程を絞るのが現実的です。本記事の早見表で◎がついている「要件定義」「テスト（受け入れテスト）」「リリース判定」に重点的に関与し、開発工程は定例での確認に絞る、という配分です。また、社内に判断を整理する余力がない場合は、発注者の立場に立って意思決定を支援してくれる開発会社を選ぶことも有効です。
まとめ——「決めるべきことを決める」のが発注者の最大の役割
システム開発において、発注者の関与は工程ごとに濃淡が変わります。要件定義・テスト・リリースでは深く関わり、開発工程では委ねる。けれども一貫して変わらないのは、発注者が「意思決定者」であるという立場です。
各工程を「決める／委ねる／確認する」の3つに分けて考えれば、「どこまで口を出して、何を自分で決めればいいのか分からない」という不安は、「ここは自分が決める」「ここは開発会社に任せる」という明確な線引きに変わります。技術の細部に踏み込めなくても、「業務にとって望ましいか」という発注者ならではの土俵で判断すれば、過不足のない関与が設計できます。
まずは、いま手元にあるスケジュール表に本記事の早見表を重ねて、「この工程で自分が決めるべきことは何か」を一つずつ書き込んでみてください。それだけで、任せきりにも過干渉にもならない「ちょうどいい関与」の地図が手に入ります。
発注の手順全体を確認したい場合はシステム開発の外注プロセスを、要件定義をさらに深く固めたい場合は要件定義の進め方を、検収の進め方は受け入れテスト（検収）の進め方を、それぞれあわせてご覧ください。各工程の判断軸を押さえておけば、次のプロジェクトには、もう同じ不安を抱えずに臨めるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
