ITプロジェクトは他のどのタイプよりも失敗しやすく、通常はスコープが不明確、依存関係の見落とし、コミュニケーションの弱さが原因です。Trupeerなら、無料のITプロジェクト計画テンプレートから始めて、ブランドアイデンティティでカスタマイズし、計画を動画アップデートに変換することで、技術部門とビジネス関係者の認識を揃えながら計画にかかる時間を何時間も節約できます。

ITプロジェクト計画とは何か、なぜ汎用テンプレートはすり抜けるのか

プロジェクト計画とは、何を、いつまでに、誰が、そしてそれを実現するために何が成り立っていなければならないかを示す文書です。この検索で上位に表示されるテンプレートは、通常はタスクリストとして、開始日、終了日、担当者、そしてガントバー付きで、その内容をすべて提供します。

タスクリスト自体が問題ではありません。問題は、そこに記入する順番です。

汎用テンプレートは、まずあなたの作業から始まります。タスクを列挙し、所要期間を見積もり、順序付けし、担当者を追加すると、終了日は下の方に落ちてきます。依存関係はその後、列としてメモの形で追加されます。

ITプロジェクトが遅れるのは、見積もりが間違っていたからではありません。計画に入っていなかった何かが到着し、それが「変更できないもの」として議論の余地なく突きつけられるからです。たとえば、リリース週を覆う変更凍結、6週間のキューがあるセキュリティレビュー、四半期末まで予約で埋まっているベンダーの実装コンサルタント、代替が準備できる前に更新されるライセンス、環境を1か月ロックする監査などです。

それらはリスクではありません。リスクとは「起こり得ること」です。これらは計画を始めるその日にはすでに事実であり、誰かが最初の週に質問すれば、どれも把握できるものです。

そこでこのテンプレートは順番を逆にします。まず、動かせない日付を先に引きます。次に、残りの期間が実際にどれくらいの幅なのかを把握します。そして、その中に作業をスケジュールします。タスクリストは存在し続けますが、最初に書くものではなくなります。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したいテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、位置や関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新されたテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるかを確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが思い通りに表示されることを確認できます。

ITプロジェクト計画テンプレートでできること：

• 計画にかかる時間を節約： ITイニシアチブ向けに構造化された空白ページをスキップできます。

• 技術的な複雑さを管理： アーキテクチャ、依存関係、リスクのための組み込みセクション。

• ブランドに合わせ続ける： Trupeerのブランドキットでロゴ、フォント、カラーを適用します。

• ビジネスとITを揃える： 技術計画を、ビジネス関係者が理解できる動画アップデートに変換します。

• プロジェクト間で標準化： すべてのITイニシアチブで同じテンプレートを使用します。

• グローバルチームに対応： 1クリックで計画とアップデートを65+言語に翻訳します。

動かせないものと、その見つけ方

動かせないものとは、プロジェクトに報告していない誰かによって設定された日付または期間のことです。プロジェクト内で交渉することはできず、後になって見つけると、それが制約から危機へと変わってしまいます。

初週に運用するための一覧はこちらです。各担当者に2つの質問をしてください。「あなたの期限はいつですか？」そして「リードタイムはどれくらいですか？」

このうち2つは特に注意が必要です。なぜなら、最も見落とされがちなものだからです。契約上の通知期間は、更新日より前に存在する動かせない日付であり、つまり実際の締切は日記に書かれたものより早くなります。そして、ソースシステムにおけるデータ品質は、その規模を参照できない唯一の動かせないものです。実際に測定しに行く必要があるため、ソースデータのプロファイリングは移行フェーズではなく初週に行うべきです。

何かを見積もる前に、これらを1つのカレンダーにまとめて描き出してください。探しているのは「ギャップの形」です。多くの場合、そのギャップはプロジェクト期間よりもはるかに狭く、スコープについての率直な話し合いは7か月目ではなく2週目に起こります。

計画に入れるもの

動かせないものを描き出したら、計画自体には12のセクションがあります。見出しをコピーし、この順番で埋めてください。

1. サマリー。 1文で：何が変わり、誰に影響し、その後は何が成り立たなくなるか。

2. 成果と成功基準。 測定可能で、日付付き。たとえば、置き換える対象について少なくとも1つの基準を含めます。例：レガシーシステムは、指定した日付までにトラフィックがなく、ライセンスコストも発生しない。リリース（go-live）で終わる計画は、企業が2つのシステムに対して支払い続ける原因になります。

3. 制約カレンダー。 上の動かせないものの表を埋め、結果としての納品ウィンドウを、平易な言葉で日付範囲として明記します。

4. スコープ。 3つのリスト：含む（in）、含まない（out）、延期（deferred）。延期リストが役に立つのは、スコープが削られたときにそこへ移動し、同じ会話が4回も繰り返されなくなるからです。

5. フェーズとマイルストーン。 観測可能な答えを伴うイベントです。例：「セキュリティレビューに合格」や「最初の店舗が稼働開始」などで、「設計フェーズ完了」ではありません。

6. 作業分解。 タスク、担当者、見積もり、順序付け。ここが、他のすべてのテンプレートが最初に始める部分です。

7. 依存関係。 内部と外部を分けます。外部の依存関係には、相手組織の担当者名と、合意済みの日付を入れます。あなたが想定した日付ではありません。

8. 環境とデータ。 どの環境が存在するか、各環境にどんなデータがあるか、テストで本番データがどのように保護されるか、そしてソースデータのプロファイリング結果。

9. カットオーバーとロールバック。 切り替えの時間ごとのシーケンス、止める判断ポイント、誰がその判断をするか、そして戻り方。これは実行可能な手順として書きます。ここに 手順テンプレート が該当します。

10. トリガー付きのリスク。 確率と影響のマトリクスではありません。各リスクには、観測可能なトリガーと、そのトリガーが見つかったときに発火するアクションを設定します。「ベンダーのコンサルタントが5月12日までに確定していない」はトリガーです。「ベンダーが遅れる可能性がある」はトリガーではありません。

11. コミュニケーション、トレーニング、定着。 誰に、いつ何を伝えるか。そして初日（day one）にユーザーができるようになることが期待される内容。

12. ガバナンスとクローズ。 誰が決めるか、誰がエスカレーションするか、意思決定記録がどのような形になるか、そしてプロジェクトが完了と宣言され、運用へ引き渡される条件。

実例と、そのコスト

Ashmore Retailは、84店舗と3つのディストリビューションセンター（DC）を持ち、2月に全3つのDCで倉庫管理システム（WMS）を置き換えるための計画を開始しました。作業は9か月、go-liveは11月中旬を予定。キックオフデッキでは、ピークより十分に前倒しで着地すると説明されていました。

そのキックオフ当日に存在していた動かせないものは2つあり、どちらも公開されていました。どちらも計画には入っていませんでした。

1つ目は変更凍結です。小売の運用は毎年1月にこれを公開し、11月1日から1月15日まで実施され、繁忙期の取引をカバーします。これらの11週間の間は、どのような本番変更も一切入れられません。

2つ目はレガシー契約でした。これは12月31日にさらに12か月間更新され、金額は186,000ポンド。加えて90日間の通知が必要だったため、実際の締切は10月2日になりました。

プロジェクトは春の間は計画通りに進みました。セキュリティレビューは、提示されたSLAが2週間のところ4週間かかりました。ベンダーの実装コンサルタントは10月まで利用できませんでした。7月に依頼していたためです。どちらの遅れも、go-liveを11月中旬から11月下旬へ動かすことで吸収されましたが、凍結カレンダーを見ている人が誰もいなかったため、誰もそれを問題として指摘しませんでした。

凍結は9月上旬の変更アドバイザリーボードの会議で表面化しました。11月のgo-liveは不可能で、次に実行可能なウィンドウは1月16日に開きました。

そこで、10月2日までに決める必要がある選択肢は1つでした。レガシー契約に通知して、1月1日から開始し、事業全体が依存していたシステムにはサポートを付けないのか。それとも、更新して、11月に切り替える予定だったシステムの1年分の費用を支払うのか。

彼らは更新を選びました。新しいシステムは3月4日に稼働開始しました。レガシー契約は、52週間のうち9週間分に使われました。つまり、186,000ポンドの請求に対して約32,000ポンドの価値しか得られていません。およそ154,000ポンドは何も買っていないのです。

学びになるのは、このプロジェクトが「遅れた」という意味で遅れていたわけではないことです。人々が言う「遅れ」とは違います。作業は妥当な水準で、妥当なペースで行われました。問題は、ウィンドウが誰も描いていなかったより6週間も狭かったこと、そしてそれを定義する2つの日付が、プロジェクトが存在する前から公開されたカレンダーと署名済みの契約に載っていたことです。

もし制約カレンダーが2月に描かれていれば、順序は明白だったでしょう。11月1日より前にgo-liveし、4週間のセキュリティレビュー（実際は6週間）を逆算し、6週間の調達ルートと、四半期分の通知が必要なコンサルタントを考慮すると、ベンダー契約は4月中旬までに署名する必要がありました。実際には7月に署名されました。プロジェクトはもっと速く進める必要はありませんでした。動かせない依存関係を、11週間前に開始する必要があったのです。

5つのITプロジェクトの形と、どのセクションが重いか

この検索では、ITSMの導入からインフラのアップグレード、PMOの立ち上げまで、20個のITプロジェクトテンプレートのリストがよく見つかります。しかし実際には5つの形に収束し、その形が上記のどのセクションに詳細が必要かを教えてくれます。

置き換え。 稼働中のシステムを別のものに入れ替えること。WMS、ERP、ITSMツール、ヘルプデスクのプラットフォーム、HRシステムが含まれます。セクション3、9、2が重いのは、難しい部分が「ウィンドウ」「カットオーバー」「旧システムが実際にオフになっていることの証明」だからです。

導入（Implementation）。 前任がない新しいもの。SLA管理、ITガバナンスとコンプライアンスプログラム、アセット管理、ナレッジ管理が含まれます。セクション11と2が重いのは、導入前に何も壊れていないため、定着がそれを現実のものにする唯一の要素だからです。詳しくは、デジタル定着導入ガイドをご覧ください。

移行または現行環境でのアップグレード。 同じシステムで、新しいバージョン、新しいホスト、または新しいリージョン。仮想化、統合、クラウド移行、データベースのアップグレードが含まれます。セクション8と9が重いのは、ロールバックがすべてだからです。

構築（Build）。 ソフトウェア開発とプロセス自動化。セクション4が重いのは、スコープが動く変数であり、受け入れ基準がそれを静かに動かないように止めるものだからです。

プログラムとアシュアランス。 PMOの立ち上げ、IT監査、ポートフォリオ管理、リスク管理、セキュリティのコンプライアンス。セクション12が重いのは、成果物が稼働するシステムそのものではなく証拠とサインオフであり、マイルストーンが他者によって設定されるレビュー日だからです。

もしあなたのプロジェクトがこれらのどれにもきれいに当てはまらない場合、通常は「1つの名前を付けて2つのプロジェクトがある」状態です。

1日で計画を作る

午前：動かせないものを描きます。表の各担当者に2つの質問を送り、まずベンダーとセキュリティの回答を追いかけます（それらは尾が最も長いからです）。返ってきた日付はすべて1つのカレンダーにまとめます。結果としてのウィンドウを1文で述べます。

午後：セクション1、2、4を書き、その後マイルストーンを作成します。詳細な作業分解は、週の間に納品チームが埋めるために残しておきます。ウィンドウとスコープが合意された瞬間に計画は役に立ちますが、そこに400行の行があるからといって、役に立つ度合いが増えるわけではありません。

ガバナンスの会議のたびに、ウィンドウに照らして見直してください。聞く価値がある唯一の質問は「計画通りですか？」ではなく、「動かせないものは何か動きましたか？」です。凍結は延長され、監査は再スケジュールされ、ベンダーはコンサルタントを失います。そうした変更は、遅れたタスクが起こすのとは違う形で計画を作り変えます。

入れないでおくべきもの

すべてのタスクのガントチャートは、計画文書に入れるべきではありません。ガントチャートは、スケジュールを組むために使うツールの中に置くものです。文書に複製すると、2つのバージョンができて、2週間以内に食い違いが生まれます。

スコア付きの完全なリスクレジスターも、ここには置くべきではありません。トリガーと日付があるリスクだけを残し、残りはレジスターに入れてください。

作業がどのように行われるかの詳細な手順はIT SOPに入れるべきで、あなたが構築した内容の説明は計画ではなくIT documentationに入れるべきです。運用チームへの引き渡しは適切に計画する価値があり、それがナレッジトランスファーSOPの役割です。

文書の使用をやめてソフトウェアに切り替えるタイミング

文書は、計画が議論されている間に適した入れ物であり、最初の1か月の大半がそれです。次の3つが同時に成り立った時点で、その入れ物は適切でなくなります。30件以上のタスクが稼働している、4人以上がステータス更新を行っている、そしてタスク間の依存関係が週次で変わり始める、です。

その時点で、作業分解をスケジューリングソフトウェアへ移し、文書はセクション1〜5と12だけ残します。これらは、ツールを開くことのない人が読む部分です。文書は合意を保持します。ツールはスケジュールを保持します。

計画を、納品チームが実際に従うものに変える

計画はキックオフとステアリングミーティングで読み込まれます。カットオーバーのランブックは、どちらにも参加していない誰かが午前2時に読めるようにします。

Trupeer AIは画面録画をドキュメント化されたプロセスに変えるため、セクション9のカットオーバー手順と、セクション11の初日タスクが、説明文ではなく実際のシステムのウォークスルーになります。シーケンスを一度記録すれば、ナレッジベースに、ステップバイステップのガイド、動画、そしてドキュメントが、あなたのブランディングで揃います。

記録する。ブランド化する。翻訳する。Trupeerする。

セクション11の定着作業では、チェンジマネジメントとトレーニング動画が展開側をカバーし、ドキュメンテーションが計画、ランブック、引き渡し資料を一緒に保ちます。セットアップ手順はドキュメントテンプレートセットアップガイドにあります。

よくある質問

Excelで無料のITプロジェクト計画テンプレートはありますか？

ファイルとしては提供していません。また、そのトレードオフについては正直に言う価値があります。Excelは、セクション6の作業分解において本当に優れた入れ物です。日付、依存関係、集計はセルに入るからです。そのシートは自分で作ってください。タスク、担当者、開始、終了、依存関係、ステータス、動かせないフラグの列を用意します。セクション1〜5、9、12は文書として保持してください。これらは文章で議論され、スプレッドシートでは誰もスコープを交渉しないからです。

Word版はありますか？また、Wordの無料ダウンロードはありますか？

上記の12セクション構造は、WordまたはGoogle Docsにそのままコピーできるように書かれています。見出しを貼り付け、番号はそのままにして、指定された順番で埋めてください。限定されたダウンロードはありません。つまり、あなたと構造の間にフォームは存在しません。

PDF版はありますか？

セクションをエディターに貼り付け、計画が合意されたらPDFにエクスポートします。計画は、サインオフされた時点でPDFとして固定（フリーズ）する価値があり、それ以前は編集可能な状態で保持する価値があります。そのため、固定ファイルから始めるよりも、適切なタイミングで自分のコピーをエクスポートする方が良いのです。

キックオフデッキ用のPPT版はありますか？

デッキは別の文書で、別の役割があります。通常は6枚で十分です。成果、制約カレンダーから導いた納品ウィンドウ、スコープの含む／含まない、マイルストーン、外部の依存関係（名前付き）、そして何を誰が決めるか。作業分解をデッキに入れないでください。プロジェクターでガントバーを誰も読みません。

無料でダウンロードできますか？

構造、動かせないものの表、実例は無料で、制限なく利用できます。使って、編集して、自分の名前で自分のテンプレートライブラリに入れてください。

プロジェクト納品計画は、プロジェクト計画と同じですか？

十分に近いので、その区別が実際に役立つことはほとんどありません。組織によって分けている場合、プロジェクト計画はビジネスケースやクローズを含むプロジェクト全体をカバーし、納品計画は構築とリリースの部分だけをカバーします。ガバナンスで両方が求められるなら、上記の計画を書き、セクション5〜9を納品計画として扱ってください。

別のプロジェクトマネジメントレポートのテンプレートも必要ですか？

はい。ただし、想像よりずっと短くしてください。計画を繰り返すだけのステータスレポートは、1か月以内に無視されます。報告すべきは4つです。動かせないものは何か動いたか、ウィンドウはまだ十分に広いか、今日このグループから必要な意思決定は何か、そして前回以降にリスク一覧から何が発火したか。

ITプロジェクト計画はどれくらい詳細にすべきですか？

新しく参加した人が、次に何が起こるかを判断できる程度で、それ以上は不要です。実際には、9か月のプロジェクトで計画文書は約8〜15ページになり、その多くはセクション8と9です。文書がカットオーバーのランブックより長い場合、バランスが崩れています。

計画はどのくらいの頻度で更新すべきですか？

セクション6と7は毎週変わり、チームがすでに作業している場所ならどこでも置けます。セクション1〜5はめったに変えるべきではなく、そこへの変更はすべて誰かが承認する必要があります。毎週こっそりスコープセクションを編集しているなら、計画ではなく日記になっています。