ベンダー選定がようやく終わり、数週間後にキックオフミーティングが控えている。そんなとき、ベンダーから「キックオフの資料はこちらで用意します」と言われ、ふと不安になった方は多いのではないでしょうか。「発注者である自分は、当日座っていればよいのだろうか。それとも何か準備すべきなのだろうか」と。
キックオフミーティングが何かは理解していても、発注者として「いつ・何を・どこまでやればよいか」の判断基準を持っている人は意外と少ないものです。当日の資料も進行もベンダーが用意してくれるため、発注者はどうしても受け身になりがちです。しかし、その受け身の姿勢こそが、後の仕様の認識ずれや納期遅延といったトラブルの入り口になります。
システム開発のプロジェクトは、キックオフ期にプロジェクトの土台が固まります。ここで発注者が主体的に動けるかどうかが、プロジェクト全体の成否を大きく左右します。とはいえ、専門知識のない発注者がいきなり「主体的に動け」と言われても、何から手をつければよいか分からないのが実情でしょう。
そこで本記事では、システム開発のキックオフで発注者がやることを「キックオフ前」「キックオフ当日」「キックオフ後1〜2週間」の3つの時期に分け、それぞれの具体的なアクションを解説します。各時期の終わりにはそのまま使えるチェックリストも用意しました。要件がまだ固まっていない状態でキックオフを迎えるケースへの対処も取り上げます。読み終えるころには、発注者として自信を持ってプロジェクトに臨めるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜキックオフ期に発注者の動きが重要なのか
「キックオフはベンダーが進行してくれるのだから、発注者は任せておけばよい」という考えは、システム開発では通用しません。キックオフ期は、発注者にとってこそ動くべき時期です。その理由を、プロジェクトの構造と発注者の法的な立場の両面から説明します。
キックオフ期に決まることが、プロジェクトの成否を左右する
キックオフ期（キックオフ前からキックオフ直後まで）は、プロジェクトの「土台」が固まる時期です。具体的には、何を作って何を作らないかというスコープ、誰がどの役割を担うかという体制、どのように情報をやり取りするかというコミュニケーションルールが、この短い期間に決まっていきます。
この土台は、一度固まると後から変更するコストが急激に大きくなります。たとえばスコープの認識がずれたまま開発が進み、テスト段階で「想定していた機能がない」と発覚した場合、設計からやり直すことになり、納期もコストも大きく膨らみます。基礎工事を終えた建物の間取りを後から変えるようなものです。
逆に言えば、キックオフ期に発注者がしっかり関与して土台を固めておけば、その後のプロジェクトは格段に安定します。発注者にとってキックオフ期は、最も少ない労力で最も大きな効果を出せる「投資効率の高い時期」なのです。
発注者には「協力義務」がある
システム開発では、発注者にも法的に「協力義務」が求められます。協力義務とは、ベンダーだけに任せきりにせず、発注者も必要な情報提供や意思決定に積極的に関与する責任のことです。
この点を象徴するのが、旭川医科大学とNTT東日本の電子カルテシステム開発をめぐる裁判です。この事件では、システムの納入が遅れたことについて、最終的に札幌高裁が発注者である旭川医大側にほぼ全面的な責任を認め、約14億円の支払いを命じました（札幌高裁判決の解説：イノベンティア、STORIA法律事務所）。仕様確定後に発注者が大量の追加要望を出し続けたことが協力義務違反にあたると判断されたのです。
もちろん、これは極端な事例です。しかし重要なのは、「発注者だから守ってもらえる」「うまくいかなければベンダーの責任」とは限らない、という事実です。発注者がベンダーに丸投げする姿勢は、トラブルを招くだけでなく、法的にも発注者自身のリスクになり得ます。キックオフ期から主体的に関与することは、プロジェクトを成功させるためであると同時に、発注者自身を守るためでもあるのです。
キックオフ前にやること｜社内準備とベンダー連携
キックオフ当日に向けて、発注者には当日より前にやるべきことが数多くあります。むしろ、当日の成否は事前準備でほぼ決まると言ってもよいでしょう。ここでは、ベンダー決定からキックオフ当日までに発注者が社内で進めるべき準備を解説します。
社内の意思決定権者と承認フローを確定する
まず最初に固めておきたいのが、「このプロジェクトで誰が何を決めるのか」という意思決定の構造です。最終的な決定権者は誰か、現場の担当者はどこまでを自分の判断で決めてよいのか、予算や仕様の変更には誰の承認が必要か――これらを事前に整理しておきます。
なぜ事前に必要かというと、キックオフ当日にベンダーから判断を求められたとき、「持ち帰って確認します」を繰り返すとプロジェクトの初速が大きく落ちるからです。意思決定の構造が曖昧なままだと、その後も決定のたびに停滞が発生します。誰が決めるかを先に決めておくことが、スムーズな進行の前提になります。
社内キックオフを先に開く
ベンダーとのキックオフの前に、社内だけのキックオフを開くことを強くおすすめします。経営層・業務部門・IT部門・現場担当者に対し、「なぜこのシステムを作るのか」「どんな体制で進めるのか」を発注者側であらかじめ共有しておくのです。
社内には、必ずと言ってよいほど温度差があります。プロジェクトに前向きな部門もあれば、業務が増えることを警戒する部門もあります。この温度差を解消しないままベンダーとのキックオフに臨むと、当日に社内の意見が割れ、ベンダーの前で議論が紛糾しかねません。社内の足並みは、社内で揃えておくべきものです。
実際に新システムを使う現場担当者を巻き込む
意外と見落とされがちなのが、実際にそのシステムを日々使うことになる現場担当者の巻き込みです。プロジェクト責任者やIT部門だけで話を進め、現場が蚊帳の外に置かれたままキックオフを迎えると、後になって「現場の実態と合わない仕様だ」という問題が噴出します。
キックオフの段階から現場担当者の代表に参加してもらうか、少なくとも現場の声を吸い上げてプロジェクトに反映できる仕組みを作っておきましょう。現場を巻き込むタイミングは早ければ早いほどよく、キックオフ前がひとつの目安になります。
ベンダーと事前にすり合わせておくこと
キックオフ当日の進行はベンダーが担いますが、その内容を「当日初めて知る」状態は避けたいところです。当日のアジェンダ、参加者、所要時間、そして「現時点で何が前提になっているか」を、事前にベンダーとすり合わせておきます。
特に、ベンダーが当日どこまでの内容を確定させたいのかを把握しておくと、発注者側も誰を出席させるべきか、どんな準備が必要かを判断できます。事前のすり合わせは、当日を「合意の場」にするための仕込みです。なお、キックオフに向けたステークホルダーの整理と社内調整の詳細については、ステークホルダー管理とは｜発注者が押さえる洗い出しから合意形成までも参考にしてください。
キックオフ前チェックリスト
- プロジェクトの最終意思決定権者を明確にした
- 現場判断と承認が必要な事項の線引きを決めた
- 社内キックオフを開き、関係部門に目的と体制を共有した
- 経営層・業務部門・IT部門・現場の温度差を把握し、調整した
- 実際にシステムを使う現場担当者を巻き込む仕組みを作った
- ベンダーと当日のアジェンダ・参加者・所要時間をすり合わせた
- 当日に確定させたい事項を発注者側でも把握した
キックオフ当日にやること｜発注者が確認・合意すべきこと
キックオフ当日は、発注者にとって「ベンダーから必要な情報を聞き出し、重要事項を合意する場」です。資料や進行はベンダーが用意しますが、何を確認し何を合意するかは発注者が主体的に判断しなければなりません。ここでは、発注者が当日に押さえるべきことを解説します。これは本記事で最も重要なパートです。
ベンダーのアサインメンバーを確認する
最初に確認したいのが、「実際に誰がこのプロジェクトを担当するのか」です。提案や見積もりの段階で説明を受けたキーメンバーが、本当にプロジェクトに参画するとは限りません。営業段階のエース級メンバーが、実際の開発では別の案件に移っているケースもあります。
当日は、プロジェクトマネージャーや主要なエンジニアの氏名・役割・経験を確認し、可能であればそれぞれの稼働率（このプロジェクトにどの程度の時間を割くのか）も聞いておきましょう。あわせて、担当者が途中で交代する可能性があるか、交代する場合の引き継ぎ方針も確認しておくと安心です。
スコープ（やること・やらないこと）の認識を合わせる
キックオフ当日に最も丁寧に合意すべきなのが、スコープです。「何を作るか（In Scope）」だけでなく、「何を作らないか（Out of Scope）」を明文化することが重要です。
トラブルの多くは、「これは当然やってくれると思っていた」という発注者側の期待と、「それは契約範囲外」というベンダー側の認識のずれから生まれます。曖昧な部分を曖昧なまま進めず、当日その場で「この機能は含む」「この対応は含まない」を一つひとつ確認し、書面に残しましょう。境界線が曖昧な項目こそ、優先的に話し合うべきです。
変更管理・追加要望の手続きを合意する
開発を進める中で、仕様変更や追加要望が出てくることは避けられません。重要なのは、それを「どう出すか」のルールを最初に決めておくことです。追加要望はどの窓口に、どんな形式で出すのか、誰が承認するのか、コストや納期への影響はどう判断するのか――これらを当日合意しておきます。
先ほど触れた旭川医大の事例が示すように、仕様確定後の無秩序な追加要望は発注者自身のリスクになります。変更管理のルールを最初に握っておくことは、ベンダーのためではなく発注者を守るための取り決めです。
検収基準とマイルストーンを合意する
「何をもってこのシステムが完成したと判断するのか」という検収基準は、開発の終盤ではなくキックオフの時点で握っておくべきものです。終盤になって検収基準を議論し始めると、「完成した・していない」をめぐる対立に発展しかねません。
あわせて、プロジェクトの主要なマイルストーン（要件定義完了、設計完了、開発完了、テスト完了など）と、それぞれの時期に発注者が何を確認するのかも当日に合意します。いつ・何を確認するかが見えていれば、発注者は計画的にプロジェクトに関与できます。
コミュニケーションルールと窓口を決める
最後に、プロジェクト期間中のコミュニケーションのルールを決めます。定例ミーティングの頻度、日常的な連絡の手段（メール、チャットツール、課題管理ツールなど）、そして発注者側の「単一窓口」を誰にするかを合意します。
発注者側の窓口が複数いて、それぞれがバラバラにベンダーへ要望を出すと、現場は混乱し優先順位もつけられません。発注者側の意見を一本化する窓口を明確にすることが、円滑な進行の鍵になります。開発プロジェクトで活用できるプロジェクト管理ツールの選び方については、システム開発で使うプロジェクト管理ツール5選！発注者が炎上を防ぐ選び方と運用方法も参考にしてください。
キックオフ当日チェックリスト
- ベンダーの担当メンバーの氏名・役割・経験を確認した
- 主要メンバーの稼働率と交代可能性を確認した
- In Scope（やること）を明文化して合意した
- Out of Scope（やらないこと）を明文化して合意した
- 仕様変更・追加要望の提出方法と承認フローを合意した
- 検収基準（完成の定義）を合意した
- 主要マイルストーンと各時期の確認事項を合意した
- 定例ミーティングの頻度と連絡手段を決めた
- 発注者側の単一窓口を明確にした
- 当日の合意事項を議事録に残す段取りを確認した
キックオフ後1〜2週間にやること｜立ち上がり期の関与
キックオフが終わると「ひと区切りついた」と感じるかもしれませんが、発注者の役割はここからも続きます。キックオフ後の最初の1〜2週間は、開発体制が本格的に立ち上がる重要な時期です。この期間に発注者がやるべきことを解説します。
議事録で合意内容を確認・文書化する
キックオフで合意したことの多くは、その場の口頭でのやり取りです。これを文書として確定させなければ、後で「言った・言わない」の食い違いが起きます。
ベンダーが議事録を作成する場合でも、発注者は必ず内容を読み込み、自分の認識と一致しているかを確認します。少しでも違和感があれば、その場で指摘して修正しましょう。認識のずれは、開発が進むほど修正コストが大きくなります。立ち上がり期のこの段階で潰しておくことが肝心です。
社内へ合意内容を展開する
キックオフに出席していなかった社内の関係部門へ、合意した内容を共有します。スコープ、体制、スケジュール、そして各部門に依頼することがあればその内容を伝え、必要に応じて社内の承認フローに乗せます。
キックオフは発注者の代表者が出席するのが一般的ですが、プロジェクトは関係部門全体で動かすものです。情報が代表者のところで止まっていると、後で「聞いていない」という反発を生みます。
開発・テスト環境やアクセス権を手配する
システム開発では、発注者側で用意しなければならないものがあります。開発やテストに使う環境、既存システムへのアクセス権、テスト用のデータ、関係部門への協力依頼などです。
これらの手配が遅れると、ベンダーが作業に着手できず、プロジェクトの初速が落ちます。キックオフで「発注者側で用意するもの」が示されたら、すぐに着手し、いつまでに何を用意するかをベンダーと共有しておきましょう。
最初のマイルストーンまでの関与方針を決める
立ち上がり期のうちに、次のマイルストーンまで発注者がどう関与するかの方針を固めます。定例ミーティングには誰が出席するのか、ベンダーから上がってくる成果物のレビューは誰が担当するのか、フィードバックはどんな形式で返すのか――こうした関与の「型」を決めておきます。
特にアジャイル開発では、発注者の関与がキックオフ後も継続的に求められます。短いサイクルで開発と確認を繰り返すため、発注者が定期的にフィードバックを返せる体制がプロジェクトの品質を左右します。「キックオフが終わったら任せきり」ではなく、「いつ・誰が・どう関与し続けるか」を明確にしておきましょう。発注者側の体制設計とRACI表を使った役割分担の明文化については、システム開発 発注者の体制の作り方｜RACI表で役割分担を明文化する手順で詳しく解説しています。
キックオフ後チェックリスト
- キックオフの議事録を確認し、認識のずれを修正した
- 合意内容を社内の関係部門へ展開した
- 必要な社内承認フローに乗せた
- 開発・テスト環境、アクセス権、テストデータを手配した
- 定例ミーティングの出席者とレビュー担当者を決めた
- 次のマイルストーンまでの関与方針とフィードバック方法を決めた
要件が固まっていない状態でキックオフを迎えるとき
ここまでは要件がある程度見えている前提で解説してきましたが、現実には「要件がまだ固まっていないのにキックオフをしてよいのか」と悩む発注者も少なくありません。最後に、このケースへの対処を解説します。
要件が固まっていなくてもキックオフは開催できる
結論から言えば、要件が固まっていなくてもキックオフは開催してかまいません。むしろ、要件が曖昧な段階でこそキックオフの価値があります。
要件定義そのものが、プロジェクトの重要な一部です。「何が決まっていて、何が決まっていないのか」をベンダーと発注者で共有すること自体が、キックオフの大きな目的になります。「決まっていないことを決まっていないと正直に共有する」ことは、後の認識ずれを防ぐ第一歩です。要件がすべて固まるまでキックオフを待つ必要はありません。
未確定の要件は「いつ・誰が決めるか」を決める
要件が固まっていない場合、キックオフで合意すべきは「要件の中身」ではなく「要件をいつ・誰が決めるか」です。未確定の項目を洗い出し、それぞれについて確定の期限と責任者を当日決めます。
ここでも協力義務の観点が関わってきます。仕様の確定が遅れることは、プロジェクト全体の遅延に直結し、発注者側の責任が問われ得るからです。「いつまでに誰が決める」を明確にしておくことが、発注者自身を守ることにもつながります。
次フェーズの要件定義への橋渡し
要件が固まっていない状態でキックオフを迎えた場合、その後に控えるのが本格的な要件定義のフェーズです。キックオフは、この要件定義をスムーズに始めるための助走と位置づけられます。要件定義で発注者が何をすべきかについては、要件定義の進め方【発注者向け完全ガイド】ステップ別に解説で詳しく解説しています。
まとめ｜キックオフ期の発注者アクション一覧
システム開発のキックオフで発注者がやることを、時系列で振り返ります。キックオフ期は「前・当日・後」の3つの時期に分けて捉えると、発注者の動きが整理しやすくなります。
時期 | 主なアクション |
|---|---|
キックオフ前 | 意思決定権者と承認フローの確定／社内キックオフの開催／現場担当者の巻き込み／ベンダーとのアジェンダすり合わせ |
キックオフ当日 | ベンダーのアサインメンバー確認／スコープ（やること・やらないこと）の合意／変更管理ルールの合意／検収基準とマイルストーンの合意／コミュニケーションルールと窓口の決定 |
キックオフ後1〜2週間 | 議事録での合意内容の文書化／社内への展開／開発・テスト環境とアクセス権の手配／関与方針の決定 |
これらのアクションに共通するのは、「発注者がベンダーに丸投げせず、いつ・何を・どこまで関与するかを自ら判断する」という姿勢です。キックオフ期の発注者の動きは、プロジェクト全体の失敗を防ぐための土台づくりにほかなりません。
専門知識がなくても、本記事のチェックリストに沿って一つひとつ準備すれば、発注者として十分な役割を果たせます。受け身にならず、最も投資効率の高いキックオフ期にこそしっかり関与し、プロジェクトを成功へと導いていきましょう。キックオフ期を乗り越えた後も、システム開発が失敗する原因とは？フェーズ別に解説する防止策と発注側のチェックポイントやプロジェクトリスク管理とは？発注者が知るべき4つのリスクと対策を参考に、継続的なリスク管理を実践してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
