--- title: "発注する側のプロジェクト管理。担当者がすること｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/client-side-project-management/ description: "システム開発を外部に頼むとき、発注する側の担当者がすることを、はじめての方向けに整理します。決める人を決める、社内の意見をまとめる、会議と課題の一覧で進み具合を見る、受け入れを確かめる、という4つの役割と、準備しておく道具を説明します。" updated: 2026-11-12 publisher: "アメリア・テクノロジー株式会社" --- # 発注する側のプロジェクト管理。担当者がすること システム開発を外部に頼むとき、発注する側の担当者がすることを、はじめての方向けに整理します。決める人を決める、社内の意見をまとめる、会議と課題の一覧で進み具合を見る、受け入れを確かめる、という4つの役割と、準備しておく道具を説明します。 2026.11.12 [開発の発注と契約](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) 執筆 [桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/)（取締役COO） 開発の発注と契約（OUTSOURCING）のコラム ## この記事の要点 - システム開発は開発会社に任せきりにはできず、何を作るかを決め、社内の意見をまとめ、できたものを確かめるのは発注する側の役割です - 最初に、最終的に決める人と、日々の窓口になる担当者を決めておくと、判断の遅れや食い違いを減らせます - 定例の会議と課題の一覧で、決めることと遅れの兆しを早く見つけ、決めたことは記録に残します システム開発を外部に頼んでも、発注する側の仕事はなくなりません。何を作るかを決めること、社内の関係者の意見をまとめること、できたものが業務に使えるかを確かめることは、発注する側にしかできない役割です。 担当者がすることは、大きく分けて、決める人と窓口を決める、社内の意見をまとめる、会議と課題の一覧で進み具合を見る、受け入れを確かめる、の4つです。はじめて担当になった方向けに、順に説明します。 ## 発注する側にも、プロジェクト管理の役割がある [プロジェクト管理](https://www.ameliatechnology.co.jp/glossary/project-management/)とは、決めた目的・期間・費用の中で、作業を計画し、進み具合を確かめ、問題に手を打つ活動です。開発の作業そのものは開発会社が管理しますが、発注する側にも、自社の中の段取りを管理する役割があります。 IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」の第二版は、見直しの論点の1つに「プロジェクトマネジメント義務及び協力義務」を挙げています。システム開発の契約では、開発会社がプロジェクトを管理するだけでなく、発注する側にも、必要な情報を出し、決めるべきことを決めて協力する役割があると考えられています。 出典：[情報システム・モデル取引・契約書（第二版）（IPA）](https://www.ipa.go.jp/digital/model/model20201222.html) 発注する側が判断を先延ばしにしたり、必要な資料を出すのが遅れたりすると、開発会社がどれだけ急いでも全体が遅れます。発注する側の段取りも、プロジェクトの一部と考えることが大切です。 ## 1. 決める人と窓口を決める 最初にすることは、最終的に決める人と、日々の窓口になる担当者を決めることです。 - **決める人**：作る範囲、費用、時期など、大きな判断をする人。部門の責任者や役員が担うことが多いです - **窓口の担当者**：開発会社からの質問を受けて答える人、社内に確かめる人。この記事の読み手の多くは、この役割だと思います - **業務に詳しい人**：実際にシステムを使う部門で、業務の流れや例外を知っている人 誰が何を決め、誰に相談するかを表にしたものを、[RACI（責任分担表）](https://www.ameliatechnology.co.jp/glossary/raci-chart/)と呼ぶことがあります。大きなプロジェクトでは、関係する部門の責任者が集まって判断する会議（[ステアリングコミッティ](https://www.ameliatechnology.co.jp/glossary/steering-committee/)）を置くこともあります。 窓口が決まっていないと、開発会社が部門ごとに違う答えを受け取り、作り直しが起きやすくなります。 ## 2. 社内の意見をまとめる 発注する側の担当者の大切な仕事は、社内の意見を1つにまとめて開発会社に伝えることです。部門によって欲しい機能や優先順位が違うのは自然なことなので、ばらばらのまま伝えるのではなく、社内で話し合って決めてから伝えます。 - 目的を確かめる：システムで何を良くしたいのかを、最初に言葉にしておきます。迷ったときに立ち返る基準になります - 優先順位をつける：「欠かせないもの」と「あるとよいもの」を分けておくと、時間や費用が足りないときに範囲を調整しやすくなります - 決めたことを伝える：決めた内容と理由を、関係する部門に知らせます 要件の決め方は[要件定義で決めること：はじめての方へ](https://www.ameliatechnology.co.jp/blog/requirements-definition-basics/)で説明しています。 ## 3. 会議と課題の一覧で進み具合を見る 進み具合は、定例の会議と、課題の一覧で確かめます。 ### 定例の会議 週に1回など、決まった間隔で開発会社と打ち合わせをします。毎回、次の3つを確かめると、話がそれにくくなります。 1. 予定と比べた進み具合 2. 発注する側が決めること、出すもの（期限つき） 3. 困っていること、心配なこと [キックオフ](https://www.ameliatechnology.co.jp/glossary/kickoff/)の会議では、目的、範囲、体制、会議の進め方、連絡の方法を双方で確かめておきます。 ### 課題の一覧 課題の一覧とは、決めること、確かめること、問題を1つずつ書き、担当と期限、状態を記録する表です。表計算のファイルでも、プロジェクトの管理の道具でも構いません。 | 書く項目 | 例 | |---|---| | 内容 | 請求書の締め日の扱いを決める | | 担当 | 経理部の○○さん | | 期限 | 決めた日付 | | 状態 | 未着手・対応中・完了 | | 決まったこと | 決めた内容と日付 | 発注する側が持っている課題の期限が過ぎていないかを、毎週見ておくことが大切です。遅れの兆しの見つけ方は[開発プロジェクトの遅れに早く気づくには](https://www.ameliatechnology.co.jp/blog/project-delay-early-signs/)で説明しています。 ### 決めたことは記録に残す 会議で決めたことや、仕様の変更は、議事録や課題の一覧に残します。後から「言った、言わない」の食い違いが起きたとき、記録が判断の材料になります。仕様を途中で変えたいときは[開発の途中で仕様を変えたいときの進め方](https://www.ameliatechnology.co.jp/blog/change-request-handling/)の手順で進めます。 ## 4. 受け入れを確かめる 開発会社がテストを終えたら、発注する側が、業務に使えるかを確かめます。これを受け入れのテストと呼びます。業務に詳しい人に、いつもの業務の流れでシステムを使ってもらい、困る点がないかを確かめます。 確かめる観点は、早めに準備しておくと安心です。テストの種類と、発注する側が見るものは[発注者が知っておきたいテストの種類と確かめ方](https://www.ameliatechnology.co.jp/blog/testing-for-buyers/)、検収の手順は[検収の進め方：受け入れテストから検収書まで](https://www.ameliatechnology.co.jp/blog/acceptance-inspection-howto/)で説明しています。 ## 担当者が準備しておく道具 はじめから大がかりな道具は要りません。次のものがあれば、多くのプロジェクトは回せます。 - 体制図と連絡先の一覧（決める人・窓口・業務に詳しい人・開発会社の担当） - 全体の予定表（大まかな工程と、発注する側が決める日） - 課題の一覧 - 議事録の置き場所 - 仕様書や設計書などの資料の置き場所 資料の置き場所は、開発会社と共有できる場所にしておくと、どれが最新の版かで迷わずに済みます。 ## 担当者が一人で抱え込まないために 窓口の担当者は、ほかの業務と兼ねていることが多く、一人で抱え込むと判断が遅れがちです。決める人に定期的に状況を伝え、判断が要ることは早めに上げることが大切です。社内に経験のある人がいない場合は、発注する側に立って進め方を手伝う外部の専門家を使う方法もあります。 複数の開発会社に頼む場合の取りまとめは、[複数の開発会社に頼むときの役割分担](https://www.ameliatechnology.co.jp/blog/multi-vendor-management/)で説明しています。 ## 当社のご支援 何をシステムに任せ、どの順番で進めるかの整理は、[AI・DXコンサルティング](https://www.ameliatechnology.co.jp/service/consulting/)でご相談いただけます。当社が開発をお受けする場合は、[Webシステム開発](https://www.ameliatechnology.co.jp/service/web-system/)として、要件定義で作るものと最初の範囲をお客様と一緒に決め、区切りごとにできたものを確かめながら進めます。 - プロジェクト管理 - 発注者 - 要件定義 - 課題管理 ## この記事に出てくる用語 - [システム開発](https://www.ameliatechnology.co.jp/glossary/system-development/) - [プロジェクトマネジメント](https://www.ameliatechnology.co.jp/glossary/project-management/) - [情報システム・モデル取引・契約書（IPA）](https://www.ameliatechnology.co.jp/glossary/model-contract-ipa/) - [RACI（責任分担表）](https://www.ameliatechnology.co.jp/glossary/raci-chart/) - [ステアリングコミッティ](https://www.ameliatechnology.co.jp/glossary/steering-committee/) - [要件定義](https://www.ameliatechnology.co.jp/glossary/requirements-definition/) - [キックオフ](https://www.ameliatechnology.co.jp/glossary/kickoff/) - [検収](https://www.ameliatechnology.co.jp/glossary/acceptance-inspection/) ## 関連する法令・指針（参考情報） - 指針 独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（第二版（2020年12月22日）） 情報システムの受託開発（一部の企画を含む）と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。 [発行元の公式ページで開く](https://www.ipa.go.jp/digital/model/model20201222.html) 法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。 この記事を書いた人 [桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/) 取締役COO システムエンジニアとして、ビジネスモデルの策定から要件定義、開発、コードレビューまでを担当してきました。運送管理、飲食業向けのDX、ECサイトなど、さまざまな業界のシステム開発に携わっています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/) - [取適法（中小受託取引適正化法）とシステム開発の発注](https://www.ameliatechnology.co.jp/blog/toriteki-act-system-development/) - [システム開発の成果物の著作権は誰のものか](https://www.ameliatechnology.co.jp/blog/software-copyright-ownership/) [開発の発注と契約のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### 現場に入るチームに任せる 技術者がお客様の現場に入り、要件定義から開発・運用までを担います。 [FDEを見る](https://www.ameliatechnology.co.jp/fde/) ### まずは30分、オンラインで話してみる 何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。 [無料で相談する](https://www.ameliatechnology.co.jp/contact/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「発注する側のプロジェクト管理。担当者がすること｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/client-side-project-management/