プロジェクト計画とは？立て方・計画書の項目と確認点

プロジェクト計画とは

プロジェクト計画とは、プロジェクトを進める前に、目的・作業範囲・成果物・予算・スケジュール・役割分担・リスク・連絡方法などを決めるためのものです。

 

システム開発であれば、「どの業務を改善するのか」「どの機能を作るのか」「どこまでを見積もりに含めるのか」「誰が承認するのか」といった内容を決めます。

 

開発会社から計画書や見積もりを提示されたときは、まず次の内容が決まっているかを見ます。

 

決めること	発注者が確認すること
目的・ゴール	何を達成したいのか、成果を何で判断するか
作業範囲	作るもの・作らないものが分かれているか
成果物	何が納品されるのか
予算	見積もりに含まれる作業と追加費用の条件
スケジュール	いつ確認・承認が必要か
役割分担	自社と開発会社の担当範囲
連絡・承認ルール	誰が、いつ、何を確認するか
リスク	遅延・仕様変更・追加費用が起きる条件

 

この内容が曖昧なまま進むと、関係者ごとに完成イメージがずれやすくなります。特にシステム開発では、作る機能や承認のタイミングが後から変わると、費用や納期にも影響します。

プロジェクト計画の意味

プロジェクト計画は、単にスケジュールを作ることではありません。プロジェクトを始める前に、目的・作業範囲・成果物・費用・納期・役割・変更時の扱いを決めるためのものです。

 

たとえば、予約管理システムを作る場合、「予約できる画面を作る」だけでは計画として不十分です。電話予約の対応時間を減らすのか、予約ミスを減らすのか、管理画面で何を扱いたいのかまで決める必要があります。

 

目的が曖昧なままだと、開発会社はどの機能を優先すべきか判断しにくくなります。発注者側も、完成したシステムが自社の業務に合っているかを見極めにくくなります。

プロジェクト計画が必要な理由

プロジェクト計画が必要なのは、関係者の認識違いを減らし、途中で判断に迷う場面を少なくするためです。

 

システム開発では、発注者・開発会社・利用部門・承認者など、複数の関係者が関わります。それぞれが違う前提で動くと、「この機能も含まれていると思っていた」「この日までに返答が必要だと知らなかった」といった問題が起きます。

 

プロジェクト計画では、主に以下の内容を決めます。

 

• 何を達成するためのプロジェクトか

• どこまで作るのか、どこからは作らないのか

• 何を納品物として受け取るのか

• どの作業が見積もりに含まれるのか

• いつ誰が確認・承認するのか

• 変更や追加依頼が出たときに、誰が判断するのか

 

計画は、予定どおりに進めるためだけのものではありません。途中で変更が出たときに、費用・納期・作業範囲を見直すための基準にもなります。

プロジェクト計画・計画書・スコープ・作業計画の違い

プロジェクト計画に関連する言葉には、プロジェクト計画書、プロジェクト憲章、プロジェクトスコープ、作業計画などがあります。意味が近いため、違いを押さえておくと読み進めやすくなります。

 

用語	意味
プロジェクト計画	目的、範囲、予算、スケジュール、役割、リスクなどを決める考え方・進め方
プロジェクト計画書	プロジェクト計画の内容を文書にしたもの
プロジェクト憲章	プロジェクト開始時に目的や責任者を明確にする文書
プロジェクトスコープ	作業範囲や成果物の範囲
作業計画	実際のタスクや作業手順を落とし込んだ計画

プロジェクト計画で決めること

プロジェクト計画では、プロジェクトを始める前に決めておく内容を整理します。ここで決めた内容は、計画書にも反映されます。計画書の形式よりも、目的・範囲・費用・納期・役割・リスクが具体的に書かれているかを見ましょう。

目的・ゴール

目的は、プロジェクトで解決したい業務上の課題です。ゴールは、目的を達成できたか判断するための状態や数値を指します。

 

システム開発では、「システムを作ること」ではなく、業務上の何を改善するかを目的にしましょう。

たとえば、予約管理システムを作る場合は、以下のように整理できます。

 

項目	内容
目的	電話予約の対応時間を減らす
ゴール	Web上で予約・変更・キャンセルを受け付けられる状態にする
発注者が見る点	どの業務時間を減らしたいのか、誰の作業を減らしたいのか

 

目的が「便利なシステムを作る」だけだと、必要な機能の判断がぶれます。何の業務をどう変えたいのかを言葉にしておくと、開発会社との会話でも優先順位を決めやすくなります。

作業範囲

作業範囲では、プロジェクトで対応する内容と対応しない内容を分けます。

 

システム開発では、話し合いの途中で「この機能も必要だった」とわかることがあります。最初からすべてを予測するのは難しいです。しかし、作るもの・作らないものを分けておくと、追加費用や納期変更の話をしやすくなります。

 

予約管理システムの例では、以下のように分けられます。

 

区分	内容
作るもの	予約登録、予約変更、予約キャンセル、管理画面
作らないもの	決済機能、会員ランク機能
発注者が見る点	後から追加した場合に、費用や納期がどう変わるか

 

「作らないもの」を書いておくと、見積もりに含まれていない機能を後から判断しやすくなります。開発会社に追加依頼をするときも、「今回の範囲に含まれるのか」「別見積もりになるのか」を確認しやすくなり、判断の基準を持って話を進められます。

成果物

成果物は、プロジェクトの結果として納品されるものです。

 

システム開発では、完成したシステムだけが成果物とは限りません。画面・管理画面・設計書・テスト結果・操作説明資料なども成果物に含まれる場合があります。たとえば、予約管理システムなら、利用者が予約する画面、担当者が予約状況を見る管理画面、操作方法をまとめた資料などが成果物になります。

 

計画書では、納品時に何を受け取れるのかを確認します。運用開始後に社内で使う操作説明資料や、保守時に参照する設計書が含まれているかも見ておきましょう。

予算

予算では、見積もりに含まれている作業と、あとから追加で費用がかかる作業を分けて確認します。

 

ここで大切なのは、合計金額だけを見ることではありません。どの作業までが見積もりに含まれているのか、どこからが追加費用になるのかを具体的に確認しましょう。

 

たとえば、以下のような内容です。

 

• 要件整理や打ち合わせの回数

• 画面や機能の数

• 修正対応の回数

• テストや受け入れ支援の範囲

• 操作説明資料の作成有無

• 仕様変更が出た場合の見積もり方法

 

予算の内訳が曖昧だと、追加機能を依頼したときに「見積もりに含まれていると思っていた」という認識違いが起きやすくなります。

スケジュール

スケジュールでは、作業期間だけでなく、発注側が確認・承認するタイミングも決めておきます。

 

システム開発では、発注側の返答が遅れると、開発会社の作業が止まる場合があります。開発会社の作業期間だけでなく、自社側がいつまでに何を見るのかも計画に入れておきましょう。

 

特に見ておきたいのは、以下のタイミングです。

 

• 要件を確認する日

• 設計内容を確認する日

• 画面や機能を確認する日

• テスト結果を確認する日

• リリース可否を判断する日

• 自社の承認者が判断できる日

 

納期は、開発会社の作業期間だけで決まるものではありません。発注側の確認期間も含めて見る必要があります。

役割分担

役割分担では、誰が何を担当し、誰が最終判断するのかを決めておきます。

 

システム開発では、開発会社が作業する内容と、発注者側が準備・判断する内容があります。たとえば、業務ルールの説明、既存資料の共有、利用部門への確認、承認者の判断などは、発注者側で対応することが多いです。

 

役割分担では、以下を見ます。

 

見る点	内容
発注者の担当範囲	業務要件の説明、資料提供、社内確認、承認
開発会社の担当範囲	要件整理、設計、開発、テスト、資料作成
最終判断者	費用、納期、仕様変更、リリース可否を決める人
利用部門の関わり方	画面や業務フローを確認するタイミング

 

「誰かが確認するはず」という状態では、判断が止まりやすくなります。特に、費用・納期・仕様変更・リリース可否を誰が決めるのかは、計画時点で明確にしておきましょう。

連絡・承認ルール

連絡・承認ルールでは、誰に、どの方法で、いつまでに確認を依頼するのかを決めておきます。

 

たとえば、日々の質問はチャットで行い、費用や納期に関わる承認はメールや文書で残す、といった形です。仕様変更や追加依頼は、口頭だけで進めないようにします。

 

決めておきたいのは、以下のような内容です。

 

• 日々の質問はどの連絡手段で行うか

• 仕様変更は誰に依頼するか

• 承認は会議で行うのか、文書で行うのか

• 何営業日以内に返答する必要があるか

• 決定事項をどこに残すか

 

承認ルールが決まっていないと、後から「誰が了承したのか」がわからなくなります。費用や納期に関わる判断は、記録に残す前提で進めましょう。

リスクと変更時の扱い

リスクとは、プロジェクトの進行に影響する可能性がある問題です。システム開発では、仕様変更・確認遅れ・外部サービスの制約・既存データの不足・関係者の追加要望などがリスクになります。

 

計画時に、リスクを細かく分析しすぎる必要はありません。ただし、遅延・仕様変更・追加費用が起きる条件は決めておきましょう。

 

特に、以下の内容は発注者側でも把握しておきたい項目です。

 

• 仕様変更を依頼する方法

• 追加費用が発生する条件

• 納期が変わる条件

• 発注者側の確認遅れが全体日程に与える影響

• リスクが出たときに誰が判断するか

 

変更時の扱いを決めておくと、後から要望を追加する場合も、費用や納期への影響を見たうえで判断できます。

プロジェクト計画の立て方

プロジェクト計画は、いきなり計画書を書き始めるより、考える順番をそろえたほうが進めやすくなります。基本の流れは、以下のとおりです。

 

 

この順番で考えると、目的と作業内容のズレに気づきやすくなります。システム開発では、目的より先に機能一覧を作ると、業務改善に関係の薄い機能まで入ってしまう場合があります。

目的とゴールを決める

最初に決めるのは、目的とゴールです。この2つが、作業範囲や成果物を決める基準になります。システム開発では、「システムを作ること」ではなく、「どの業務をどう変えたいのか」を先に言葉にします。

 

たとえば、予約管理システムを作る場合、目的は「電話予約の対応時間を減らす」ことです。ゴールは「利用者がWeb上で予約・変更・キャンセルでき、管理者が予約状況を画面で確認できる状態」と整理できます。

 

目的とゴールが決まっていれば、後から機能を追加するか迷ったときも、業務改善に関係する内容かどうかを判断できます。

作るもの・作らないものを分ける

目的とゴールが決まったら、作るものと作らないものを分けます。予約管理システムの場合だと、初回リリースで作るものを「予約登録、変更、キャンセル、管理画面」とし、作らないものを「決済機能、会員ランク機能」とします。

 

作らないものを決めるのは、要望を切り捨てるためではありません。初回で対応する内容と、後から検討する内容を分けるためです。この区分があれば、追加機能を依頼したときに、費用や納期への影響を見ながら判断できます。

必要な作業と成果物を洗い出す

作るものが決まったら、必要な作業と成果物を洗い出します。システム開発では、開発だけでなく、要件整理・設計・画面作成・テスト・操作説明資料の作成などの作業があります。

 

成果物として見ておきたいのは、以下のような内容です。

 

成果物	見る点
画面	利用者が使う画面がそろっているか
管理画面	管理者が予約状況を確認・変更できるか
設計書	合意した機能や画面が資料に残っているか
テスト結果	想定した操作が確認されているか
操作説明資料	社内担当者が使い方を確認できるか

 

成果物が曖昧だと、納品時に何を見ればよいかわからなくなります。計画段階で、受け取るものを具体的にしておきましょう。

予算とスケジュールを確認する

作業と成果物が見えてきたら、予算とスケジュールを確認します。予算では、見積もりに含まれる作業を見ます。スケジュールでは、開発会社の作業期間だけではなく、発注側の確認日や承認日も入れます。

 

確認したいのは、以下の内容です。

 

• 見積もりに含まれる機能と作業

• 見積もりに含まれない作業

• 追加機能を依頼した場合の見積もり方法

• 自社が確認する資料と期限

• 承認が遅れた場合の日程への影響

 

予算とスケジュールは、作業範囲と連動します。たとえば、予約管理システムに「メール通知機能も追加したい」と後から依頼した場合、その分の開発費用が増えるだけでなく、動作確認やテストの期間も延びる可能性があります。

 

機能を追加する場合は、費用だけでなく、確認期間やテスト期間も変わるかを見ておきましょう。

 

スケジュールを具体的に検討する段階では、どのような開発手法を採用するかも確認しておきましょう。たとえば、アジャイル開発とウォーターフォール開発では、確認するタイミングや変更の扱いが異なります。

役割分担と承認者を決める

プロジェクトでは作業する人だけではなく、確認する人や判断する人も決めます。

 

システム開発では、開発会社が設計や開発を進めても、業務内容の判断は発注者側で行う場面があります。たとえば、予約のキャンセル期限、管理者が見られる情報、通知を送る条件などは、業務側の判断が必要です。

 

計画時には、次の役割を決めておきましょう。

 

• 開発会社に伝える担当者

• 利用部門に確認する担当者

• 仕様変更を判断する人

• 追加費用を承認する人

• リリース可否を判断する人

 

承認者が決まっていないと、判断が必要な場面で進行が止まります。特に費用や納期に関わる判断は、誰が決めるのかを計画に入れておきましょう。

リスクと変更時のルールを決める

最後に、リスクと変更時のルールを決めます。システム開発では、計画どおりに進めていても、途中で要望が増える・確認が遅れる・外部サービスの仕様が変わるといったことがあります。

 

すべてを防ぐことは難しいため、「もし途中で機能を追加したくなったらどうするか」「社内の確認が遅れた場合に納期はどうなるか」「外部サービスの変更で仕様を見直す必要が出た場合は誰が判断するか」といった、実際に起こりそうな場面ごとの対応方法をあらかじめ決めておきます。

 

決めておきたいのは、以下の内容です。

 

• 仕様変更を依頼する方法

• 変更内容を誰が確認するか

• 追加費用が発生する条件

• 納期が変わる条件

• 変更内容をどこに記録するか

 

変更時のルールが決まっていれば、追加要望が出たときも、費用・納期・優先順位を見直して判断できます。

プロジェクト計画書で確認する項目

プロジェクト計画書は、プロジェクト計画で決めた内容を文書にしたものです。

 

システム開発を依頼する場合、計画書は開発会社が作成しますが、内容は発注者と開発会社で分担して決めるのが一般的です。ただし、目的・作業範囲・費用・納期・承認タイミングが自社の認識と合っているかは見ておく必要があります。

 

開発会社から計画書を受け取ったら、次の項目を順番に確認しましょう。

プロジェクト概要

プロジェクト概要に書いてあるのは、プロジェクト名、背景、対象業務、関係者、全体の進め方などです。

ここでは、どの業務を対象にしたプロジェクトなのかを見ましょう。対象業務が曖昧だと、関係のない部署や機能まで話が広がりやすくなります。

 

たとえば、予約管理システムなら、「店舗予約を対象にするのか」「電話予約も含めるのか」「管理画面を使う部署はどこか」といった内容がわかる状態にします。

 

確認する内容は、以下のとおりです。

 

• どの業務を対象にするのか

• どの部署・利用者が関係するのか

• 何を改善するためのプロジェクトなのか

• 開発会社と自社の関係者が書かれているか

 

プロジェクト概要は、関係者が同じ前提で話を進めるための土台になります。

目的・ゴール

目的・ゴールに書いてあるのは、プロジェクトで達成したい内容と達成したと判断する状態です。ここでは、目的が「システムを作ること」になっていないかを見ましょう。

 

システム開発の目的は、業務時間を減らす、入力ミスを減らす、情報を一元管理するなど、実際の仕事をどう良くするかという視点で考えます。

 

ゴールには、確認できる状態が書いてあります。たとえば「予約状況を管理画面で確認できる」「CSVで予約一覧を出力できる」などです。

作業範囲・成果物

作業範囲・成果物に書いてあるのは、プロジェクトで作るもの・作らないもの、納品されるものです。ここでは、見積もりに含まれる作業と、含まれない作業を分けて見ましょう。

 

確認する内容は、以下のとおりです。

 

• 作る機能が明確に書かれているか

• 作らない機能が分かる形で書かれているか

• 納品される資料や画面が書かれているか

• テストや操作説明資料が含まれるか

• 追加機能を依頼した場合の扱いが書かれているか

 

作業範囲と成果物は、費用や納期と関係します。ここが曖昧なまま合意すると、後から「この機能も含まれていると思っていた」「これは別料金になるのか」といった判断ができず、追加費用や納期変更の話し合いが進みにくくなります。

体制・役割分担

体制・役割分担に書いてあるのは、プロジェクトに関わる人と、それぞれの担当内容です。発注者側では、窓口担当・利用部門の確認者・費用や仕様を判断する承認者を分けておくと、たとえば、誰が最終判断するのかわからず、社内で確認が回り続けるといった状況を防ぎやすくなります。

 

確認する内容は、以下のとおりです。

 

• 開発会社側の担当者

• 発注者側の窓口担当者

• 利用部門の確認者

• 仕様変更の判断者

• 費用や納期の承認者

 

担当者名だけでなく、何を判断する人なのかまで書かれているかを見ましょう。

予算・スケジュール

予算・スケジュールに書いてあるのは、費用・支払い条件・作業期間・確認日・承認日などです。ここでは、全体の納期だけでなく、自社が確認する日も見ましょう。開発会社が資料を出す日と、発注者が返答する日が決まっていないと、日程がずれやすくなります。

 

確認する内容は、以下のとおりです。

 

• 見積もりに含まれる作業

• 追加費用が発生する条件

• 設計確認やテスト確認の日程

• 発注者側の返答期限

• 承認が遅れた場合の日程への影響

 

納期を見るときは、開発作業だけでなく、自社の確認期間も含めて判断しましょう。

リスク・課題・変更時のルール

リスク・課題・変更時のルールに書いてあるのは、遅延や仕様変更が起きた場合の扱いです。

 

システム開発では、追加機能を後から依頼すると、費用や納期が変わることがあります。打ち合わせの場で口頭で「少し変更したい」と伝えただけでは、どこまで対応するのかや追加費用の有無について認識がずれ、後から「そこまで含まれていると思っていなかった」といった行き違いが起きる場合があります。

 

確認する内容は、以下のとおりです。

 

• 仕様変更の依頼方法

• 変更内容を確認する人

• 追加費用の見積もり方法

• 納期が変わる条件

• 変更内容を記録する場所

 

変更時のルールは、トラブルが起きてから決めるのではなく、計画時点で確認しておきましょう。

承認方法・連絡方法

承認方法・連絡方法に書いてあるのは、誰が、どの方法で、何を承認するのかです。システム開発では、日々の質問と正式な承認を分けることがあります。

 

たとえば、開発会社とのやり取りで「この画面の文言はこれでいいですか？」といった軽い確認はチャットで行い、「この仕様で進めて問題ないか」「追加費用が発生する変更を承認するか」といった重要な判断は会議やメールで正式に承認する、といった形です。

 

内容によって方法を分けておくと、後から、誰がどの内容を了承したのかを確認しやすくなります。

 

確認する内容は、以下のとおりです。

 

• 日々の連絡手段

• 正式な承認方法

• 承認が必要な内容

• 返答期限

• 決定事項を残す場所

 

承認方法が決まっていないと、後から「誰が了承したのか」がわからなくなります。費用、納期、作業範囲に関わる内容は、記録に残る形で承認しましょう。

システム開発を発注する人が確認すべきこと

システム開発を発注する人は、プロジェクト計画をすべて自分で作る必要はありません。ただし、計画の中身を理解し、自社の業務に関わる部分を見ておくことが必要です。

 

ここでは、発注者が特に見落としやすい点を解説します。

要望が計画に反映されているか

発注者は、自社の要望が計画に反映されているかを確認しましょう。ここで見るのは、要望がそのまま文章として載っているかではありません。業務上の課題が、目的・作業範囲・成果物に落とし込まれているかを見ます。

 

たとえば、「電話予約の対応時間を減らしたい」という要望がある場合、計画には以下の内容が入っていることが必要です。

 

• Webで予約登録できる

• 利用者が予約を変更・キャンセルできる

• 管理者が予約状況を確認できる

• 電話対応が残るケースが整理されている

 

要望が計画に反映されているかを見るときは、自社が困っている業務が変わる内容になっているかという点を基準にします。

見積もりに含まれる作業が明確か

見積もりでは、金額だけでなく、含まれる作業を確認しましょう。同じ「予約管理システム」でも、画面数・管理機能・通知機能・データ移行・操作説明資料の有無によって作業内容は変わります。

 

発注者は、以下の点を確認しましょう。

 

• どの機能が見積もりに含まれるか

• 打ち合わせや修正対応の回数が決まっているか

• テストや受け入れ支援が含まれるか

• 操作説明資料やマニュアルが含まれるか

• データ移行や外部連携が含まれるか

 

見積もりに含まれる作業が明確であれば、追加の要望があったときに判断しやすくなります。

追加費用や納期変更の条件が決まっているか

追加費用や納期変更の条件は、計画時点で見ておきましょう。

 

システム開発では、途中で「この機能もほしい」「画面を変更したい」といった要望が出ることがあります。要望が出ること自体は自然なことで、実際に使う場面を考えるほど新しいアイデアが出てくるものです。

 

ただし、その内容をそのまま進めてしまうと、費用や納期にどのくらい影響があるのかわからないまま進むことになるため、事前に確認してから判断することが大切です。

 

確認する内容は、以下のとおりです。

 

• どの変更から追加費用になるか

• 追加費用は誰が承認するか

• 納期が変わる場合に誰へ連絡するか

• 変更内容をどこに記録するか

• 変更を反映する前に見積もりを出してもらえるか

 

追加費用や納期変更の条件が共有されていれば、後から要望を出す場合も、判断材料を持って話し合えます。

自社が確認・承認するタイミングが決まっているか

発注者は、自社がいつ何を確認するのかを把握しておきましょう。確認や承認のタイミングが決まっていないと、開発会社から資料が届いても、誰が見るのかわからない状態になります。

 

たとえば、設計書が届いたのに担当者が不在で確認が数日止まり、その間は開発会社も次の作業に進めず、結果として納期が後ろにずれてしまうことがあります。

 

確認したいタイミングは、以下のとおりです。

 

• 要件を確認するタイミング

• 設計内容を確認するタイミング

• 画面や機能を確認するタイミング

• テスト結果を確認するタイミング

• リリース前に最終判断するタイミング

 

自社の承認者が多忙な場合は、計画時点で確認日を押さえておきましょう。発注者側の確認も、プロジェクト計画の一部です。

プロジェクト計画で失敗しやすい点

プロジェクト計画では、専門的な管理手法を使うことよりも、基本的な確認漏れを減らすことが大切です。

ここでは、初めて計画を見る人が見落としやすい点を解説します。

目的が曖昧なまま進む

目的が曖昧なまま進むと、機能や作業範囲の判断がぶれます。

 

たとえば、「予約管理システムを作る」という表現だけでは、電話対応を減らしたいのか、予約ミスを減らしたいのか、予約状況を可視化したいのかがわかりません。

 

目的は、業務上の何を改善するかということを書きます。発注者は、目的が「システムを作ること」ではなく、自社の課題を解決する内容になっているかを確認しましょう。

作業範囲が決まっていない

作業範囲が決まっていないと、後から追加要望が出たときに判断しにくくなります。

 

特にシステム開発では、打ち合わせを重ねる中で「この機能もあったほうが便利そう」「この画面も追加したい」といった要望が後から出てくることがよくあります。作るもの・作らないものが分かれていないと、見積もりに含まれる作業なのか、追加費用が必要なのかを判断しにくくなります。

 

計画では、初回で作る機能と、後から検討する機能を分けておきましょう。

関係者の役割が曖昧

関係者の役割が曖昧だと、確認や承認が止まりやすくなります。

 

発注者側には、業務を説明する人・利用部門に確認する人・費用を承認する人・仕様変更を判断する人が必要です。すべてを同じ人が担当する場合もありますが、役割は分けて書いておくと確認しやすくなります。

 

特に、最終判断する人は計画時点で決めておきましょう。たとえば、追加機能の見積もりが出たときに「この金額で進めるか」を誰が決めるのかが曖昧だと、社内で確認が止まり、開発会社も次の作業に進めなくなります。

 

最終判断者が決まっていれば、その場で判断できるため、変更や追加費用が出たときもスムーズに進められます。

変更時の扱いを決めていない

変更時の扱いを決めていないと、途中で要望が増えたときに、費用や納期の認識がずれやすくなります。

 

仕様変更を依頼する方法や追加費用が発生する条件・納期が変わる条件・誰が承認するかを決めておくことが必要です。口頭で依頼した内容は、関係者間で認識がずれやすくなります。変更内容は、文書や管理ツールなど記録に残る形で共有しましょう。

まとめ

まずは、これから依頼しようとしている開発内容について、「何を達成したいのか」「どこまで作るのか」「誰が最終判断するのか」を簡単に整理してみてください。

 

そのうえで、開発会社から提示された計画書や見積もりを見ながら、目的や作業範囲、費用、納期、役割分担、変更時の扱いが自社の認識と合っているかを一つずつ確認していきましょう。

 

もし少しでも曖昧に感じる点があれば、そのまま進めずに質問し、納得したうえで進めることが、プロジェクトを円滑に進めるためには重要です。

 

プロジェクト計画は一度作って終わりではなく、進行に合わせて見直しながら活用していくものです。関係者と認識をそろえ、必要に応じて調整を行うことで、無理のない形でプロジェクトを進めていきましょう。