開発計画書のテンプレート 必須の記載項目と書き方・流用するときの注意点を解説

システム開発の立ち上げで、まず求められるのが開発計画書です。とはいえ社内に決まった様式がなく、前任者が作ったファイルを探して流用している、という現場は少なくありません。何を書けば十分なのかがはっきりしないまま、体裁だけ整えて提出することになりがちです。

開発計画書は、プロジェクトをどう進めるかを関係者で合意し、後から判断の基準として使うための文書です。作成そのものが目的ではなく、進行中に立ち返れる状態になっていなければ意味がありません。テンプレートをそのまま埋めただけの計画書が形骸化しやすいのは、この点が抜けているためです。

本記事では、開発計画書の役割と似た文書との違いから、テンプレートの骨格になる記載項目、見落とされやすい項目、テンプレートの選び方と流用時の注意点、書き方の手順、そして運用で活かすための工夫までを順番に整理します。

確認したいポイント	結論	詳細
開発計画書とは何ですか？	進め方を合意し判断基準にする文書	目的、範囲、体制、スケジュール、成果物を定め、進行中の判断で立ち返る場所として使います。
何を書けばいい？	骨格5領域＋見落とし5項目	概要・スコープ・体制・スケジュール・成果物に、前提条件、品質基準、リスク、変更管理、予算を加えます。
テンプレートは使っていい？	使ってよいが必ず調整する	不要な項目は削り、自社の承認フローや業界特有のリスクを追加してから使うことが前提です。
形骸化させないコツは？	参照と更新を運用に組み込む	定例で開く習慣をつけ、変更を承認したら計画書も改訂する一連の作業として定義しておきます。

この記事でわかること

• 開発計画書の役割と、プロジェクト計画書や要件定義書との違い
• テンプレートの骨格になる必須項目と、見落とされやすい項目
• 無料テンプレートを流用するときに必ず調整すべきポイント
• 目的の言語化からレビューまで、開発計画書を書く5つのステップ
• 承認されない計画書、形骸化する計画書に共通する原因と対策

▼ 社内のドキュメント整備や開発体制の見直しを検討中の方へ 業務の棚卸しから自動化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

開発計画書とは何を定義する文書か

書き始める前に、役割を整理しておきます。似た名前の文書が複数あり、どれに何を書くのかが曖昧なまま進めると、同じ内容を重複して書いたり、逆にどこにも書かれない項目が出たりします。

開発計画書の目的と役割

開発計画書の役割は大きく2つあります。1つは関係者の認識をそろえることです。目的、範囲、体制、スケジュール、成果物を1つの文書にまとめ、全員が同じ前提で動ける状態をつくります。

もう1つが、進行中の判断基準になることです。追加要望が出たとき、遅延が発生したとき、品質に疑義が生じたとき。判断の根拠として立ち返る場所があるかどうかで、議論の生産性がまったく変わります。

この2つの役割から逆算すると、書くべき内容は自然に決まります。後から「どう決めたんだっけ」と迷いそうな項目は書く、迷わない項目は省くという基準で取捨選択すれば、分量も適正に収まります。

なお、分量は多ければよいというものではありません。数十ページの計画書を作っても読まれなければ意味がなく、小規模案件なら数ページで十分に機能します。規模に見合った厚みに収めることも、作成者の仕事のうちです。

プロジェクト計画書・要件定義書との違い

厳密な定義があるわけではありませんが、一般的には次のように使い分けられます。プロジェクト計画書はプロジェクト全体の進め方、開発計画書は開発工程に絞った進め方を示す文書です。小規模な案件では両者を1つにまとめることもあります。

要件定義書との違いははっきりしています。要件定義書は「何を作るか」を定める文書であり、開発計画書は「どう作るか」を定める文書です。作るものの中身は要件定義書に書き、計画書からは参照するだけにとどめます。

重要なのは、社内でどの文書に何を書くのかを決めておくことです。文書名にこだわるより、この整理ができているかどうかが実務では効いてきます。

いつ、誰が作るのか

作成のタイミングは、要件がある程度固まり、開発工程に入る直前が一般的です。要件が流動的な段階で細かいスケジュールを引いても、すぐに書き直しになります。

作成者はプロジェクトマネージャーや開発リーダーですが、1人で書き切るものではありません。体制や工数は上長、品質基準は品質管理担当、スケジュールは各担当者と、関係する人から情報を集めながら組み立てます。

承認者も先に決めておきます。誰の承認をもって計画が確定するのかが曖昧だと、後から「聞いていない」という話になります。

標準的な枠組みを参考にする

自社に様式がない場合、公的な枠組みを参考にする方法があります。IPA（情報処理推進機構）が公開する共通フレーム2013は、ソフトウェアライフサイクルプロセスの国際規格であるISO/IEC 12207（JIS X 0160）をベースに、日本独自のプロセスを追加したもので、企画から開発、運用、保守、廃棄までの作業項目と役割が体系的に整理されています（出典：IPA「共通フレーム2013」）。

この枠組みは、発注側と受注側で用語や工程の認識がずれないようにすることを目的としています。社外との取引を伴う開発では、計画書の工程名や成果物名をここに合わせておくと、認識の相違を減らせます。

ただし、すべてを適用する必要はありません。プロジェクトの規模に応じて作業項目を取捨選択することが前提とされています。自社に合う部分だけを取り込む使い方で十分です。

テンプレートの骨格になる記載項目

ここからは具体的な項目に入ります。規模を問わず必要になるのは5つの領域です。まずはこの骨格を押さえ、必要に応じて肉付けしていきます。

プロジェクト概要（背景・目的・ゴール）

冒頭に、なぜこのプロジェクトを行うのかという背景と、達成したい目的、そして完了時に何が実現されているのかを書きます。ここが曖昧だと、以降のすべての判断がぶれます。

ゴールは、可能な限り測れる形にします。「業務を効率化する」ではなく「月次集計にかかる時間を20時間から5時間に短縮する」と書けば、完了の判定もできますし、途中の意思決定でも基準として使えます。

背景の部分は、テンプレートの定型文をそのまま使わず、自社の言葉で書いてください。読み手が納得できる理由が書かれているかどうかで、承認の通りやすさが変わります。

複数の部署が関わる場合は、それぞれの部署にとっての完了状態も書き分けておくと親切です。開発側は稼働開始がゴールでも、業務側にとっては運用が回り始めた状態がゴールというずれは頻繁に起こります。

スコープ（対象範囲と対象外）

何を作るのかと同じくらい重要なのが、何を作らないのかです。対象外の範囲を明記しておかないと、進行中に「当然含まれていると思っていた」という食い違いが起きます。

対象となる業務範囲、システムの機能範囲、連携する外部システム、対応する環境やブラウザなどを列挙します。あわせて、今回は対象外だが将来検討する項目も書いておくと、要望を受け止めつつ線引きができます。

文章で書きにくい場合は、対象と対象外を2列の表にして並べる方法が読みやすくなります。境界が曖昧な項目は、どちらの列に入れるかを関係者と確認する過程そのものが、認識合わせになります。

体制と役割分担

誰がどの役割を担い、どの判断を誰が下すのかを明記します。名前だけを並べた体制図ではなく、意思決定の権限がどこにあるかまで書かれているかがポイントです。

社外のベンダーが関わる場合は、発注側と受注側の作業分担も明確にします。テスト用データの準備、環境の用意、承認作業など、発注側が担う作業を見落とすと、後で工数の問題が表面化します。

スケジュールとマイルストーン

工程ごとの開始と終了、そして関係者が集まって判断する節目であるマイルストーンを置きます。要件確定、設計完了、テスト開始、リリース判定といった節目です。

細かいタスクを全部並べる必要はありません。計画書には工程レベルの粒度で載せ、詳細はWBSや工程表に分けるほうが、後の更新が現実的になります。

バッファの置き方も決めておきます。各工程に少しずつ持たせるのか、終盤にまとめて置くのか。方針を書いておくと、遅延が出たときの対応が早くなります。

成果物一覧

各工程で何を作り、誰が承認するのかを一覧にします。設計書、テスト仕様書、マニュアル、移行手順書など、名称と提出時期と承認者をセットで書くのが基本形です。

この一覧があると、作業の抜けを防げるだけでなく、見積もりの根拠としても使えます。社外との契約では、成果物の定義が請負の範囲を決める重要な要素にもなります。

▼ ドキュメント整備の型づくりからご相談いただけます 計画書や設計書の様式をどう標準化するか、どこまで書くべきか。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

見落とされやすい項目

骨格だけでも形にはなりますが、実務で効いてくるのはここから挙げる項目です。トラブルが起きたときに参照されるのは、たいていこの部分になります。

前提条件と制約条件

計画が成り立つために満たされている必要がある事柄が前提条件、逆に動かせない枠が制約条件です。「既存システムの仕様は変更しない」「本番リリースは繁忙期を避ける」といった内容を明記しておきます。

ここに書いておけば、前提が崩れたときに計画の見直しを提案する根拠になります。書かれていないと、前提が変わったのに当初のスケジュールのまま進めることを求められがちです。

前提条件は時間とともに変わります。作成時点で成り立っていた前提が、数か月後には崩れていることもあるため、定例で見直す対象として扱ってください。

品質基準と完了判定

どうなったら各工程を完了とみなすのかを定義します。テスト消化率、未解決の重大不具合の件数、レビューの実施状況といった条件を、工程ごとに決めておきます。

基準がないと、終盤で「まだ終わっていないのでは」という議論が延々と続きます。逆に基準があれば、判断に個人差が出ません。開始基準もあわせて決めておくと、前工程の未完了を持ち込む事態を防げます。

リスクと対応方針

想定されるリスクを洗い出し、発生可能性と影響度、そして起きたときの対応方針をセットで書きます。リスクの一覧があるだけで、関係者の警戒度が変わります。

典型的なのは、要件の追加、キーパーソンの離脱、外部システム側の遅延、環境の準備遅れです。過去のプロジェクトで実際に起きた事象を持ち込むと、実効性のあるリストになります。

すべてに詳細な対策を書く必要はありません。影響が大きいものだけ具体策を、残りは監視対象として一覧に残す、という濃淡をつけるのが現実的です。

変更管理とコミュニケーションのルール

進行中に必ず発生するのが仕様変更です。誰に申請し、誰が影響を評価し、誰が承認するのかという流れを先に決めておかないと、その都度もめることになります。

あわせて、定例会議の頻度と参加者、進捗報告の形式と提出先、課題が発生したときの連絡先も書いておきます。地味な項目ですが、これがあるだけで日々のやり取りが整います。

予算と工数

総工数、工程ごとの内訳、外注費、ライセンス費などを整理します。見積もりの根拠を残しておくと、変更が発生したときの追加費用の説明がしやすくなります。

工期と工数の妥当性を判断する材料として、IPAが公開する定量データを参照する方法もあります。「ソフトウェア開発 分析データ集 2022」では、多数のプロジェクトの実績データが工程別に整理されています（出典：IPA「ソフトウェア開発 分析データ集 2022」）。自社の見積もりが業界の分布から極端に外れていないかの確認に使えます。

▼ 計画段階の妥当性チェックも承っています 「この体制と期間で回るのか」「リスクの見落としはないか」といった第三者視点での確認も含めて、ご相談いただけます。 ＞ 相談予約はこちら

テンプレートの選び方と流用時の注意点

ゼロから作る必要はありません。公開されているテンプレートを土台にするのが最も効率的ですが、そのまま使うと問題が出ます。選び方と調整のポイントを整理します。

Excel・Word・PowerPointの使い分け

形式によって向き不向きがあります。Excelはスケジュールや成果物一覧など表形式の管理、Wordは文章での説明、PowerPointは経営層への説明に向いています。

実務では、本体をWordかPowerPointで作り、スケジュールや一覧は別紙のExcelとして添付する構成がよく使われます。1つのファイルにすべてを詰め込むと、更新のたびに全体を開くことになり負担が増えます。

承認の回し方も考慮してください。紙で回覧するならページ構成、共有フォルダで運用するならファイル分割、という具合に、実際の運用に合わせて選びます。

なお、ファイル形式を途中で変えるのは避けたほうが無難です。版管理が分断され、どれが最新か分からなくなります。最初に決めた形式で最後まで通すことをおすすめします。

無料テンプレートの探し方

テンプレートは、Officeのテンプレートギャラリー、プロジェクト管理ツールのベンダーが公開しているもの、ビジネス書式のサイトなどから入手できます。公的機関が公開している資料の様式も参考になります。

選ぶ際は、自社のプロジェクト規模に近いものを選んでください。大規模向けのテンプレートは項目が非常に多く、小規模案件で使うと埋めること自体が目的化します。

流用するときに必ず調整すること

テンプレートはあくまで一般的なひな形です。不要な項目は思い切って削り、自社に必要な項目は追加するという調整を必ず行ってください。項目を埋めることが目的になった計画書は、誰にも読まれません。

特に調整が必要なのは、承認フロー、体制の呼称、成果物の名称、そして自社の業界特有のリスクです。テンプレートに書かれた役職名や工程名が自社の実態と合っていないまま提出されているケースは、非常によく見かけます。

背景や目的の欄も、テンプレートの例文を残したまま提出しないよう注意してください。ここは自社の言葉で書くべき部分です。

自社テンプレートに育てる

一度調整したものは、次のプロジェクトでも使える自社テンプレートとして保存しておきます。案件ごとにゼロから探し直す状態から抜け出せます。

育て方のコツは、プロジェクトが終わるたびに振り返ることです。「この項目は結局使わなかった」「この観点が抜けていて困った」という気づきを反映していけば、数案件で実用的な様式になります。

開発計画書の書き方の手順

項目がそろったら、実際に書いていきます。上から順に埋めるのではなく、決めやすい順に固めていくほうが早く仕上がります。5つのステップで整理します。

STEP1：目的とゴールを言語化する

最初に、このプロジェクトが完了したときにどうなっているのかを1〜2文で書き切ります。ここが書けない場合、そもそも目的が関係者間で共有できていない可能性があります。

数値で測れるゴールを1つ以上入れてください。金額、時間、件数、率のいずれかで表現できれば、後の判断がぶれません。

STEP2：スコープを切る

次に、対象と対象外の線を引きます。要件定義の成果物を見ながら、今回のリリースに含める機能と、次回以降に回す機能を仕分けます。

この段階で関係者に確認を取っておくことが重要です。計画書ができあがってから対象外を伝えると、反発を招きます。線引きの過程に巻き込むほど、後の合意形成が楽になります。

STEP3：作業を分解してスケジュールに落とす

スコープが決まったら、必要な作業を洗い出して分解します。成果物を起点にして、それを作るために必要な作業をぶら下げていく方法が、抜けが少なく確実です。

分解した作業に工数を割り当て、担当者と依存関係を踏まえて並べればスケジュールになります。ここで無理な期間になった場合は、スコープに戻って調整します。期間を縮めるのではなく範囲を削るのが原則です。

計画書に載せるのは工程レベルにとどめ、詳細な作業分解は別紙にします。計画書が更新のたびに重くなるのを防げます。

依存関係の整理も忘れないでください。ある作業が終わらないと着手できない作業がどれかを把握しておかないと、1つの遅れが全体に波及したときの影響を説明できません。

STEP4：リスクを洗い出す

スケジュールが引けたら、その計画が崩れるとしたら何が原因かという問いでリスクを洗い出します。関係者数人で30分程度の時間を取るだけでも、十分な数が出てきます。

出てきたリスクは、発生可能性と影響度で並べ替え、上位のものだけ対応方針を書きます。全部に対策を書こうとすると、作成が終わりません。

STEP5：レビューを受けて合意する

仕上げは合意形成です。開発側だけでなく、業務側の責任者、承認者、社外ベンダーにも目を通してもらいます。特にスコープと役割分担、完了基準は、認識のずれが出やすい箇所です。

指摘を反映したら、承認日と版数を明記して確定します。この「いつ時点の合意なのか」が記録されていることが、後の変更管理の出発点になります。

▼ 立ち上げ段階の伴走もご相談いただけます 計画の立て方、体制の組み方、社内での合意形成まで含めて、実務目線でご支援します。 何から着手すべきか整理したい段階でも構いません。 ＞ 相談予約はこちら

承認されない・形骸化する原因

書き上げても、承認が通らない、あるいは誰にも参照されないまま終わる計画書があります。原因はいくつかのパターンに集約されるため、事前に知っておけば避けられます。

ゴールが抽象的で判断できない

「業務を改善する」「利便性を高める」といった表現だけの計画書は、承認する側が判断できません。投資に対して何が返ってくるのかが読み取れないためです。

対処は、削減できる時間や金額、削減される作業件数といった数字を入れることです。概算でも構いません。数字があると、議論が「やるかどうか」から「どうやるか」に進みます。

スコープが曖昧で見積もれない

対象範囲がはっきりしないと、工数もリスクも見積もれません。承認者が最も不安に感じるのは、後から範囲が膨らむことです。対象外の明記は、この不安に直接応えます。

範囲が固まらない段階であれば、そのこと自体を書いてください。「要件定義の結果によって変動する可能性がある」と明記し、再見積もりのタイミングを示すほうが、曖昧なまま提出するより信頼されます。

作った後に更新されない

最も多い形骸化のパターンです。仕様変更や体制変更があっても計画書が更新されず、実態と乖離していくという状態になります。

対策は、変更管理の手順の中に計画書の更新を組み込むことです。変更を承認したら計画書も改訂する、という一連の作業として定義しておけば、更新漏れは大幅に減ります。

現場が読んでいない

承認のためだけに作られ、実際に作業する人が読んでいないケースもあります。分量が多すぎる、専門用語が多い、どこに何が書いてあるか分からないといったことが原因です。

対策としては、冒頭に1ページの要約を置く、目次を付ける、参照頻度の高い項目を前に配置するといった工夫が有効です。読まれることを前提に構成を考えてください。

作った計画書を運用で活かす

計画書は作成時点が完成ではありません。プロジェクトの進行とともに参照され、更新され続けることで価値が出ます。運用面で押さえたい点を整理します。

定例会議で参照する習慣をつける

最も簡単で効果があるのが、定例の場で計画書を開くことです。マイルストーンに対する進捗、リスクの状況、変更の有無を確認する時間を数分取るだけで、文書が生きたものになります。

参照されない文書は、更新もされません。逆に毎週開く習慣があれば、実態とのずれがすぐ見つかります。

変更履歴を残す

改訂したら、版数、日付、変更内容、変更理由、承認者を履歴として残します。後から「なぜこの判断をしたのか」をたどれる状態にしておくことが重要です。

社外との取引がある場合は特に、合意の経緯が記録として残っているかどうかが問題になります。上書き保存で履歴を消してしまわないよう、版管理の方法も決めておいてください。

共有場所も決めておきます。作成者のローカルにだけ最新版があると、本人が不在のときに誰も参照できません。関係者が誰でも開ける場所に正本を置いてください。

振り返りで次の案件に活かす

プロジェクト終了時に、計画と実績のずれを振り返る時間を取ります。どの工程で見積もりが外れたか、想定していなかったリスクは何だったか。これが次の計画の精度を上げます。

振り返りの結果は、自社テンプレートの改訂に反映します。個人の反省で終わらせず、様式という形で組織に残すことで、次の担当者が同じ失敗を繰り返さずに済みます。業務全体の整理の仕方は業務効率化アイデア55選の記事でも整理しています。

書ける人を1人に限定しない

計画書を書けるのが特定の1人だけ、という状態は組織として脆弱です。レビューに複数人を巻き込み、次の案件では別の人が書くといった運用にしておくと、経験が分散していきます。

書き方の型を社内で決めておけば、担当が変わっても一定の品質が保てます。項目の意味、記載の粒度、承認の流れ。この3点を1枚のルールにまとめておくだけでも効果があります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

開発計画書は、進め方を関係者で合意し、進行中の判断基準として使うための文書です。作成自体が目的ではないため、後から迷いそうな項目を書き、迷わない項目は省くという基準で内容を決めます。

骨格になるのは、プロジェクト概要、スコープ、体制と役割分担、スケジュールとマイルストーン、成果物一覧の5領域です。これに前提条件と制約条件、品質基準と完了判定、リスク、変更管理、予算を加えると実務で使える構成になります。

テンプレートは活用してよいものの、そのまま使うのは避けてください。不要な項目を削り、自社の承認フローや業界特有のリスクを追加する調整が必須です。一度調整したものは自社テンプレートとして育てていきます。

そして、作った後に参照され、更新され続ける状態をつくること。定例で開く習慣、変更履歴の記録、終了時の振り返り。この3つを運用に組み込めば、計画書は書類ではなくプロジェクトを支える道具になります。

▼ 開発プロセスの整備を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからドキュメント運用の設計、AI活用による効率化と社内への定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら