開発会社から「プロジェクト計画書です、ご承認ください」と分厚いWordファイルが届いて、目次だけ眺めて承認してしまった。あるいは、自分が計画書を作らなければいけないのかと思って、テンプレートを探してここに来た方もいるかもしれません。
先に整理しておくと、システム開発計画書を作るのは開発会社です。発注側の役割は、それを読んで承認するかどうかを決めることです。そして承認は「この進め方で進めてください」という意思表示なので、後から覆すのは難しくなります。この記事では、計画書に何が書かれているのかを押さえたうえで、承認する前にどこを見ればいいのかを整理します。
この記事のポイント
- 計画書は開発会社が作る成果物で、発注側は読んで承認する側
- いちばん重要なのは前提条件の欄で、崩れると追加費用の根拠になる
- 体制欄は人数ではなく稼働率と兼任を見る
- 社内の稟議に回す企画書は、計画書とは別に自社で作る
目次
システム開発計画書とは何を書いた書類か
まず、届いた書類が何なのかを押さえます。中身が分かれば、見るべき場所も決まります。
計画書は開発会社が作り、発注側が承認する
システム開発計画書は、プロジェクトをどう進めるかをまとめた基本の書類です。プロジェクト計画書と呼ばれることもありますが、指しているものはほぼ同じです。
作るのは開発会社です。どの工程をどの順で進め、誰が担当し、いつまでに何を出すのか。これは受注した側が組み立てる話なので、発注側が白紙から書く必要はありません。テンプレートを探していた方は、その手間は不要だと考えてください。
ただし、読まずに承認するのは別問題です。承認したあとに「その進め方は聞いていない」「その日程では困る」と言っても、計画書に書いてあれば分が悪くなります。逆に言えば、承認前がいちばん自由に質問できるタイミングです。私の感覚では、計画書は契約直後から要件定義の完了までのあいだに出てくることが多く、そこが唯一の交渉の窓になります。
計画書に並ぶ項目
会社によって章立ては変わりますが、載っている要素は概ね決まっています。
| 項目 | 書かれること |
|---|---|
| 目的とゴール | 何のために作るのか、完成したらどうなるのか |
| 範囲（スコープ） | 作るもの、そして作らないもの |
| 体制 | 誰がどの役割で入るか、双方の窓口 |
| スケジュール | 工程の区切りと大きな節目 |
| 費用と支払い | 金額の内訳、支払いの時期 |
| 前提条件 | この計画が成り立つために必要な条件 |
| リスクと対策 | 想定される問題と、起きたときの対応 |
| 変更管理 | 途中で変更したいときの手続き |
参考になる公的な基準もあります。デジタル庁はデジタル社会推進標準ガイドラインとして、政府情報システムの整備と管理に関する手続や技術標準の共通ルールを公開しています。このうち「標準ガイドライン（Normative）」は順守する内容を定めたもので、その中核であるDS-100は2026年6月12日が最終改定日です。国の調達では計画書に何を書くかがルールとして決まっている、ということです。民間の案件にそのまま当てはめる必要はありませんが、自社が求める最低ラインを決めるときの参照先として使えます。
要件定義書やWBSとの違い
似た書類が複数出てくるので、役割を分けて覚えると混乱しません。
計画書は「どう進めるか」です。要件定義書は「何を作るか」で、こちらは中身の話になります。WBSは計画書のスケジュールをさらに細かく分解した作業一覧で、計画書の付属資料として添えられることが多いです。工程表（ガントチャート）はWBSを時間軸で見た図です。
順番でいうと、計画書で全体の枠を決め、要件定義で中身を固め、WBSで作業に落とす流れになります。それぞれの読み方はシステム開発のWBSとは？発注側が遅れを見抜く読み方とシステム開発の工程と流れで扱っているので、細部が気になったらそちらを見てください。
システム開発計画書を承認する前に見る項目
分厚い書類を全部読み込む必要はありません。発注側として効くのは4か所です。順に説明します。
前提条件の欄がいちばん重要
意外に思われるかもしれませんが、承認前に最も丁寧に読むべきなのは前提条件の欄です。ここは目立たない位置にあり、箇条書きで数行しかないことも多いのですが、後で効いてきます。
前提条件には、この計画が成り立つために必要な条件が書かれています。たとえば「既存システムの仕様書が提供されること」「レビューの回答は5営業日以内に得られること」「テストデータは貴社にて用意いただくこと」といった記述です。
何が起きるかというと、この条件が崩れたときに、追加費用や納期延長の根拠になります。しかも多くの場合、崩すのは発注側です。資料の提供が遅れた、レビューの返答に2週間かかった、テストデータが揃わなかった。そのたびに「前提条件が満たされていないため」という説明が返ってきます。
読み方のコツとしては、前提条件の文のうち主語が自社になっているものだけ拾い出すことです。「貴社にて」「発注者が」「◯◯が提供されること」という書き方の行が、そのまま自社の宿題になります。数えてみると、思っていたより多いことに気づくはずです。逆に主語が開発会社側の行は、相手の責任範囲なので読み流して構いません。
ですので、前提条件は「自社が本当に守れるか」という目で読んでください。守れない条件が書かれていたら、承認する前に条件そのものを交渉すべきです。5営業日で回答できないなら10営業日にしてもらう。テストデータを用意できないなら、その作業を見積もりに入れてもらう。承認してしまうと、この交渉はできなくなります。
体制欄は人数より稼働率と兼任を見る
体制の欄を見るとき、多くの方が人数を数えます。ですが人数はあまり意味を持ちません。見るべきは稼働率と兼任です。
10人が並んでいても、全員が稼働率20%なら実際に動くのは2人分です。逆に3人でも専任なら3人分動きます。稼働率が書かれていない計画書は、そこを質問してください。
もうひとつ見ておきたいのは、名前が書かれているかどうかです。「PM 1名」「SE 3名」と役割だけで書かれている計画書は、着手時点でまだ人が決まっていない可能性があります。悪いことではありませんが、誰が入るかで進み方は変わります。せめて主要な役割については、名前と経歴を出してもらうよう頼んでみてください。
兼任も同じです。プロジェクトマネージャーが他の案件と掛け持ちなのか、この案件に専任なのか。掛け持ちが悪いわけではありませんが、掛け持ちなら「連絡がつかない日がある」という前提で自社の動き方を組む必要があります。体制図の読み方はシステム開発の体制図とは？役割の一覧と発注側の確認点で詳しく扱っています。
リスク欄が空欄か定型文なら中身を聞く
リスクと対策の欄は、正直に言うと形式的に埋められていることが多いです。「要員の離脱」「要件の変更」といった一般論が並び、対策も「早期に共有する」程度で終わっている、という状態です。
ここが定型文だった場合、悪意があるわけではなく、まだこの案件固有のリスクを洗い出していないというサインです。そこで聞いてほしいのは1つだけです。「このプロジェクトで、いちばん失敗しそうな箇所はどこですか」。
聞き方をもう少し具体にするなら、「過去の似た案件で、いちばん時間を取られたのはどの作業でしたか」でも構いません。一般論ではなく経験を聞く形にすると、相手の実力と誠実さが見えます。答えが出てきたら、その作業がスケジュールのどこに置かれているかを一緒に確認してください。危ないと分かっている作業が、後半に詰め込まれていることがあります。
まともな開発会社なら具体的に答えます。データ移行の量が読めない、連携先の仕様が固まっていない、現場の合意形成に時間がかかりそう。この答えが返ってくるかどうかで、相手が本当に自社の案件を考えているかが分かります。返ってこなければ、そこがいちばんのリスクです。
変更管理の手続きが書かれているか
4つ目は、途中で変更したくなったときの手続きです。開発は必ず変更が出ます。ここが書かれていない計画書は、変更のたびに口約束と力関係で決まることになります。
ここが曖昧なまま進むと、途中の「ちょっとした変更」がすべて口頭で流れ、最後にまとめて追加請求が来る形になりがちです。あるいは逆に、開発会社側が気を遣って無償で対応し続け、どこかで関係が悪くなります。どちらも避けたいので、手続きは先に決めておくほうがお互いに楽です。発注後のやりとりを型として持っておきたい場合は、ベンダーコントロールパーフェクトガイドに手順をまとめてあります。
確認するのは3点です。変更を誰に伝えるのか。追加費用が発生するかどうかを、いつ・どうやって判断するのか。そして、いくらまでなら現場判断で進められるのか。とくに3つ目の金額の線引きが決まっていると、小さな変更でいちいち止まらなくなります。
社内稟議に回す企画書は別に作る
最後に、混同されやすい点を整理します。開発会社が出す計画書と、自社の社内稟議に回す企画書は別物です。
計画書は「どう作るか」が中心で、読み手は開発に関わる人です。一方、稟議に回す企画書の読み手は決裁者で、知りたいのは投資に対して何が返ってくるかです。計画書をそのまま添付しても、決裁者が読みたい情報は入っていません。
この書き分けを面倒に感じるかもしれませんが、稟議を通す立場から見ると、計画書をそのまま回すのはむしろ遠回りです。決裁者は開発の工程には関心がなく、投資判断に必要な情報だけを短く求めます。計画書から数字を引いてきて、自社の言葉で1枚にまとめるほうが早く通ります。
企画書には、いくらかけて何がどう改善されるのか、いつから効果が出るのか、やらなかった場合どうなるのか、社内で誰がどれだけ工数を使うのかを書きます。このうち工数の話は忘れられがちですが、稼働してからの運用負荷まで含めて書いておくと、後で追加の相談をしやすくなります。計画書の数字を引用しつつ、組み立ては自社でやる、という分担になります。
- Q. システム開発計画書とプロジェクト計画書は違いますか？
- 実務ではほぼ同じ意味で使われています。会社によって呼び方が変わるだけで、書かれている項目（目的・範囲・体制・スケジュール・費用・前提条件・リスク・変更管理）は共通しています。
- Q. 計画書は発注側が作ることもありますか？
- 通常はありません。作るのは開発会社です。ただし社内の稟議に回す企画書は自社で作る必要があり、これは計画書とは別物です。また複数の開発会社に分けて発注する場合は、全体を束ねる計画を自社側で持つこともあります。
- Q. 計画書がもらえない場合はどうすればいいですか？
- 小規模な案件では、計画書という名前の書類を作らないこともあります。その場合も、範囲・体制・スケジュール・前提条件が書面で共有されているかは確認してください。名前より、後から参照できる形で残っているかが重要です。
- Q. 計画書とWBSはどちらを先に見ますか？
- 計画書が先です。全体の枠（範囲・体制・前提条件）を確かめてから、WBSで作業の細部を見る順番になります。WBSだけ見ても、そもそも何を作る前提なのかが分かりません。
