システム開発を外注すると、プロジェクト管理は開発会社の仕事だと考えがちです。たしかに、作業の段取りや開発チームの進捗管理は開発会社が担います。しかし、何を優先するか、仕様をどう決めるか、社内の関係者をどう巻き込むか、といった判断は発注側にしかできません。発注側の管理が弱いと、開発会社がどれだけ優秀でも、判断待ちと手戻りでプロジェクトは遅れます。
結論から言うと、発注側が持つべき管理の型は四つです。週次の定例会を決まったアジェンダで回すこと、課題とリスクを一覧で管理すること、意思決定を記録に残すこと、そして社内の関係者への共有と承認の流れを整えることです。どれも特別な道具は要らず、表計算ソフトや既存のチャットツールで始められます。
この記事は、システム開発の発注担当になった事業部門の方や、新規事業のプロジェクトを任された責任者に向けて書いています。発注側の役割の範囲、定例会のアジェンダ例、課題・リスク管理表の項目、意思決定の記録のしかた、よくある失敗とその避け方を、すぐに使える形でまとめます。
発注側のプロジェクト管理とは何をすることか
発注側のプロジェクト管理と開発会社のプロジェクト管理は、目的が違います。開発会社の管理は、決まった範囲を、決まった品質で、決まった期間に作り上げるための管理です。発注側の管理は、そのシステムが事業の目的を達成できるように、範囲や優先順位を決め、社内の体制を整えるための管理です。
| 管理の対象 | 発注側が担うこと | 開発会社が担うこと |
|---|---|---|
| 目的と範囲 | 何のために作るか、何を作り何を作らないかを決める | 範囲を作業に分解し、見積もる |
| 優先順位 | 機能の優先度を決め、変更時に入れ替えを判断する | 優先度に沿って作業計画を立てる |
| 仕様 | 業務の要件を伝え、仕様の確認と承認を行う | 仕様を設計に落とし込み、確認を依頼する |
| 進捗 | マイルストーンの達成状況を確認し、社内に報告する | 日々の作業進捗を管理する |
| 課題・リスク | 社内起因の課題を解決し、事業上のリスクを判断する | 技術的な課題とリスクを洗い出し、対策を提案する |
| 社内調整 | 関係部署の巻き込み、承認、予算の確保 | （原則として関与しない） |
| 品質 | 受入テストを行い、業務で使えるかを確認する | 開発会社のテストで仕様どおりかを確認する |
この表を見ると分かるとおり、発注側の仕事は「判断」と「社内調整」が中心です。開発会社に任せきりにすると、この二つが空白になり、プロジェクトが止まります。外注の全体の流れと発注者の仕事は、システム開発を外注する流れでも整理しています。
発注側の担当者に必要な権限
発注側の担当者を決めるときは、「誰が決められるのか」を明確にしておくことが大切です。担当者が仕様や優先順位を決める権限を持たず、すべて上司や経営層に確認しなければならない状態だと、定例会のたびに「持ち帰って検討します」が続き、開発が進みません。
どこまでを担当者が決めてよいか、どこからは上位の承認が必要かを、プロジェクトの開始時に社内で決めておきましょう。たとえば「画面の項目や文言の調整は担当者が決める」「予算や納期に影響する変更は事業責任者が決める」といった線引きです。
定例会の運営：アジェンダと進め方
発注側と開発会社をつなぐ最も重要な場は、週に一度程度の定例会です。定例会が「開発会社からの報告を聞く場」になってしまうと、発注側の判断が後回しになります。定例会は「決める場」として運営するのが基本です。
定例会のアジェンダ例
毎回同じ流れで進めると、準備と議事録作成の負担が減り、抜け漏れも防げます。たとえば、一時間程度の定例会なら次のような構成が使えます。
- 前回の決定事項と宿題の確認：前回決めたことが実行されたか、誰がどの宿題を持っていたかを確認します。
- 進捗の報告：マイルストーンに対して予定どおりか、遅れているならどれくらい、なぜ遅れているかを開発会社から報告してもらいます。
- 成果物の確認：完成した画面や機能を、実際に画面を動かして見せてもらいます。
- 課題とリスクの確認：課題・リスク管理表を上から確認し、新しく出たものを追加します。
- 判断が必要な事項：仕様の確認、変更要求、優先順位の入れ替えなど、この場で決めるべきことを決めます。
- 次回までの宿題と担当の確認：誰が、いつまでに、何をするかを確認して終わります。
特に重要なのは、3の成果物の確認です。報告書や進捗率だけを見ていると、実際にできあがっているものとのずれに気づけません。毎週、動く画面を見せてもらうことで、仕様の誤解や使いにくさを早い段階で見つけられます。
定例会の前後にやること
定例会の効果は、準備と事後の対応で大きく変わります。開催前には、開発会社から進捗報告と判断が必要な事項の一覧を事前に共有してもらい、社内で確認しておきます。事前に判断材料を見ておけば、当日その場で結論を出せる議題が増えます。
開催後は、当日中か翌日までに議事録を共有します。議事録には、議論の経過よりも「決まったこと」「宿題と担当と期限」「持ち越した論点」を中心に書きます。議事録は発注側と開発会社のどちらが作ってもかまいませんが、もう一方が内容を確認する流れにしておきましょう。
開発会社との週次の進め方は、MVP開発会社との進め方でも、短期間の開発に合わせた形で紹介しています。
マイルストーンと達成基準を決める
定例会で進捗を確認するには、比べる基準が必要です。プロジェクト全体をいくつかの区切りに分け、それぞれに「何ができていれば達成とみなすか」を決めておきます。
| マイルストーンの例 | 達成基準の例 |
|---|---|
| 要件の確定 | 機能一覧と画面一覧について、利用部署の代表者が確認し承認した |
| 主要画面の試作 | 主要な業務の流れを、試作画面で最初から最後まで操作できる |
| 機能の実装完了 | 機能一覧の必須項目が、テスト環境ですべて操作できる |
| 受入テスト完了 | 合意した合否基準を満たし、検収の判断ができる |
| 本番稼働 | 本番環境で利用を開始し、初週の問い合わせに対応できている |
達成基準は、「誰が見ても達成したかどうかが分かる」書き方にするのがポイントです。「おおむね完成」「主要部分は実装済み」のような表現では、発注側と開発会社で認識がずれます。マイルストーンごとに、定例会で達成を確認したことを議事録に残しておくと、遅れが生じたときにどこから計画がずれたかを振り返りやすくなります。
課題・リスク管理表の作り方
プロジェクトの途中で出てくる懸念や問題は、定例会で話題に出ても、記録に残さなければ忘れられます。課題とリスクを一覧で管理し、定例会で毎回確認する習慣をつけましょう。
課題とリスクは似ていますが、区別して扱うと管理しやすくなります。課題は「すでに起きていて、解決が必要な問題」、リスクは「まだ起きていないが、起きると影響がある事柄」です。
| 項目 | 記入する内容 |
|---|---|
| 番号 | 通し番号 |
| 種別 | 課題／リスク |
| 内容 | 何が問題か、何が起きそうか |
| 影響 | 起きた場合、または放置した場合に、納期・費用・品質・業務のどこにどう影響するか |
| 重要度 | 高・中・低など |
| 担当 | 発注側か開発会社か、具体的に誰か |
| 対応方針 | 解決策、または予防策・発生時の対応 |
| 期限 | いつまでに対応するか |
| 状況 | 未着手・対応中・完了・監視中 |
| 更新日 | 最後に状況を更新した日 |
この表で大切なのは、「担当」の欄に発注側の名前が入る項目をきちんと管理することです。発注側の課題としてよくあるのは、社内の別部署からの回答待ち、既存データの提供の遅れ、外部の取引先との調整、予算の承認待ちなどです。開発会社からは催促しにくいため、発注側で意識して追いかける必要があります。
リスクについては、起きる可能性と起きたときの影響の大きさの両方を考えて重要度を決めます。たとえば「連携先の外部サービスの仕様が変わる」というリスクは、起きる可能性は低くても影響が大きいため、事前に仕様の確認と代替案の検討をしておく価値があります。
意思決定の記録を残す
プロジェクトが長くなると、「なぜこの仕様になったのか」「誰がいつ決めたのか」が分からなくなります。担当者が異動したり、リリース後に改修を検討したりするときに、この情報がないと同じ議論を繰り返すことになります。
意思決定の記録は、次の項目を簡潔に残すだけで十分です。
- 決めた日と、決めた人
- 何を決めたか
- 検討した選択肢と、選ばなかった理由
- 決定の前提になった条件（予算、納期、業務上の制約など）
- 後で見直す条件があれば、その条件
たとえば「会員登録時の本人確認は、初期リリースではメールアドレスの確認のみとする。電話番号認証は、不正登録が問題になった段階で再検討する」という記録があれば、後から「なぜ電話番号認証がないのか」と聞かれたときに経緯を説明できます。
記録の置き場所は、議事録と同じ場所や、課題・リスク管理表の別のシートなど、関係者が探しやすい場所にまとめます。チャットツールのやり取りの中だけで決めたことは、流れて見つからなくなるので、必ず記録に転記しましょう。
社内の関係者を巻き込む進め方
発注側のプロジェクト管理で、開発会社との調整以上に難しいのが社内の調整です。システムを実際に使う部署、予算を承認する経営層、セキュリティや情報システムの担当部門など、関係者は多岐にわたります。
関係者を洗い出す
プロジェクトの開始時に、次の観点で関係者を洗い出します。
- システムを日常的に使う部署と、その代表者
- システムの出力（帳票やデータ）を受け取る部署
- 予算と最終的な承認を持つ人
- セキュリティや情報システムの方針を決める部門
- 既存のシステムやデータを管理している担当者
- 顧客や取引先など、社外の利用者に影響を与える場合の窓口
共有と承認のタイミングを決める
関係者全員を毎週の定例会に呼ぶ必要はありません。代わりに、どのタイミングで何を共有し、何を承認してもらうかを決めておきます。たとえば、要件定義が終わった段階で利用部署の代表者に確認してもらう、画面の試作ができた段階で操作してもらう、受入テストに参加してもらう、といった形です。
関係者を巻き込むのが遅れると、開発の終盤になって「この機能がないと使えない」という指摘が出て、大きな手戻りにつながります。プロジェクトが失敗する典型的な原因と予防策は、システム開発プロジェクトが失敗する原因で詳しく扱っています。
経営層への報告を仕組みにする
予算を承認した経営層や事業責任者は、細かな進捗よりも「予定どおり進んでいるか」「判断が必要なことはあるか」を知りたいと考えています。月に一度程度、マイルストーンの達成状況、予算の消化状況、重要な課題とリスク、上位の判断が必要な事項を一枚にまとめて報告する形にしておくと、問題が起きたときに早く支援を得られます。悪い知らせほど早く上げることが、結果的にプロジェクトを守ります。
架空の例：社内の業務システム刷新
ここでは架空の例で、発注側のプロジェクト管理を見てみます。
ある専門商社が、見積もりから受注・請求までを管理する社内システムを刷新することになり、営業企画部の担当者が発注側の責任者になりました。担当者は最初に、営業、経理、物流の各部署から代表者を一人ずつ選び、要件定義と受入テストに参加してもらうことを部長会で承認してもらいました。
定例会は毎週火曜日に一時間、担当者と開発会社のプロジェクトマネージャーで行い、二週間に一度は各部署の代表者にも参加してもらって画面を確認する形にしました。課題・リスク管理表には、開発会社からの質問のうち社内確認が必要なものも登録し、担当者が期限を管理しました。
開発の中盤で、経理部の代表者から「請求書の締め処理が月二回の取引先がある」という指摘が出ました。担当者は変更管理の手順に沿って影響を見積もってもらい、事業責任者の判断で対応を決め、決定の経緯を記録に残しました。部署の代表者が早くから画面を見ていたため、こうした指摘を終盤ではなく中盤で拾えたことが、大きな手戻りを防ぐ結果につながりました。
発注側のプロジェクト管理チェックリスト
プロジェクトの開始時と、定期的な見直しの際に、次の項目を確認しましょう。
- 発注側の担当者と、その決定権限の範囲が明確になっているか
- 定例会の頻度、参加者、アジェンダが決まっているか
- 定例会で毎回、動く成果物を確認しているか
- 議事録が定例会の翌日までに共有されているか
- 課題・リスク管理表があり、定例会で毎回確認しているか
- 発注側が担当する課題に、期限と担当者が設定されているか
- 意思決定の記録が、関係者が探せる場所にまとまっているか
- マイルストーンと、その達成基準が決まっているか
- 社内の関係者と、共有・承認のタイミングが決まっているか
- 経営層や予算の承認者への報告の頻度と形式が決まっているか
- 仕様変更の受け付け方と判断者が決まっているか
- 受入テストの担当者と期間が、スケジュールに含まれているか
よくある失敗と避け方
定例会が報告会になっている
開発会社が進捗を報告し、発注側は聞くだけで終わる定例会です。判断が必要な事項が先送りされ、開発会社は仮の前提で作業を進めるしかなくなります。アジェンダに「判断が必要な事項」を必ず入れ、決めるべきことをその場で決める運営に変えましょう。
発注側の宿題が放置される
開発会社からの質問への回答、既存データの提供、社内確認の結果など、発注側の宿題が期限を過ぎても終わらないケースです。開発会社は催促しにくく、結果として開発の遅れにつながります。発注側の宿題も課題・リスク管理表に載せ、自分たちで期限を管理します。
窓口が複数あり、指示がぶれる
社内の複数の人がそれぞれ開発会社に連絡し、矛盾する指示が出るケースです。開発会社はどれを優先すべきか分からず、作業が止まるか、間違った方向に進みます。開発会社への窓口は一人に決め、他の人の要望は窓口を通す運用にします。仕様変更の受け付け方は、開発途中の仕様変更にどう対応するかで説明しています。
進捗率だけを見て安心する
「全体の進捗は予定どおり」という報告を受けて安心していたら、終盤で大きな遅れが明らかになるケースです。進捗率は作業の見積もり次第でいくらでも変わります。動く成果物を毎週確認し、マイルストーンの達成基準を具体的に決めておくことで、実態とのずれに早く気づけます。
リリースでプロジェクト管理を終えてしまう
システムが稼働した時点で定例会も管理表もやめてしまうケースです。リリース直後は、利用者からの問い合わせや想定外の操作による不具合、運用手順の見直しなど、判断すべきことがむしろ増えます。稼働後しばらくは定例会を続け、課題管理表も運用・保守の段階に引き継ぎましょう。
よくある質問
Q. 発注側のプロジェクト管理には、どれくらいの工数がかかりますか？
プロジェクトの規模や社内の関係者の数によって異なります。少なくとも、定例会の準備と参加、議事録と管理表の確認、社内の調整にかかる時間は、担当者の業務として確保しておく必要があります。他の業務と兼任する場合は、その時間を上司と合意しておきましょう。
Q. 管理のためのツールは何を使えばよいですか？
最初は表計算ソフトとチャットツールで十分です。開発会社がチケット管理ツールを使っている場合は、発注側も閲覧できるようにしてもらうと、情報の二重管理を避けられます。大切なのはツールよりも、項目と更新のルールを決めて運用し続けることです。
Q. 社内にシステム開発の経験者がいない場合はどうすればよいですか？
経験者がいなくても、本記事の型に沿って進めれば、発注側の管理は十分に機能します。判断に迷う技術的な論点については、開発会社に選択肢と、それぞれの長所・短所を説明してもらいましょう。それでも判断が難しい場合は、発注側の立場で助言できる第三者を入れることも検討します。
Q. 開発会社のプロジェクトマネージャーとの役割の線引きはどう考えればよいですか？
開発会社のプロジェクトマネージャーは、開発チームの作業計画と品質に責任を持ちます。発注側の担当者は、何を作るかの判断と社内調整に責任を持ちます。迷ったときは、「その判断に事業上の判断が含まれるか」で考えると整理しやすくなります。事業上の判断が含まれるものは、発注側が決めるべきことです。
Otsumuに相談できること
発注側の担当者が時間を確保でき、社内の関係者を巻き込める立場にあるなら、本記事の定例会・課題管理・意思決定記録の型を使って、プロジェクト管理を自社で十分に回せます。まずは次の定例会から、アジェンダと議事録の形式を整えるところから始めてみてください。
一方で、担当者が他の業務と兼任していて手が回らない、システム開発の経験がなく技術的な判断に不安がある、新規事業のように何を作るべきかの判断自体が難しい、という場合は、外部の力を借りた方が結果的に早く進むことがあります。
Otsumuは、自らも事業を手がける実践者として、目的から逆算して必要な機能に絞り、構想から開発・運用・改善まで一気通貫で支援しています。開発プロジェクト全般はシステム開発、業務システムの例は業務システム開発、新規事業の構想段階からの整理は新規事業開発コンサルティングをご覧ください。
「今のプロジェクトの進め方に不安がある」という段階でも構いません。30分の無料相談で、状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01