プロジェクト計画書を書くとき、意外と手が止まりやすいのが「ゴールイメージ」です。
- ゴールイメージって、何を書けばいいの？
- どこまで具体的に書くのが正解？
- 要件定義と何が違うの？
こんな疑問を持ったことがある人も多いのではないでしょうか？実際の現場でも、ゴールイメージをうまく言語化できずに悩んでいるケースをよく見かけます。
そもそも、プロジェクト計画書の中にゴールイメージが明示的に書かれていないケースも少なくありません。そのため、「どう書けばいいかわからない」のも無理はないと思います。
この記事では、あまり解説されることのない「ゴールイメージの書き方」について、実務目線で整理していきます。
この記事でわかること
- なぜゴールイメージを作るのか
- ゴールイメージは何をどう表現すればよいのか
- ゴールイメージを作成する具体的な手順
そもそも、ゴールイメージとは？
まず、プロジェクト計画書の中で作成する「ゴールイメージ」とは、どのようなものなのでしょうか？
言葉のとおり「ゴールのイメージ」ではあるのですが、プロジェクト計画書の文脈で言い換えると、次のように表現できます。
プロジェクトが完了した状態を「ざっくり」可視化したもの
ポイントは、大きく次の2つです。
- 完了状態を可視化していること
- ざっくり可視化していること
順番に解説します。
完了状態を可視化する、ということ
ここで重要なのは、「プロジェクトで何をするか？」を書くことではありません。
そうではなく、
- すべての対応が終わったあと
- このプロジェクトは「どんな状態になっているのか？」
を想像して表現する、という点です。
タスクや作業内容ではなく、やり切った結果どうなっているかにフォーカスします。
「ざっくり」可視化するのが正解
もうひとつ大事なのが、「ざっくり」可視化することです。
ここで作るのはゴール定義ではなく、あくまでゴールイメージです。しかも、これはプロジェクト計画書の中の要素であり、計画段階で作成するものでもあります。
この時点では、
- 要件も固まりきっていない
- 解決手段もこれから詰めていく
という状態が普通です。つまり、詳しく書きようがないのが前提です。
だからこそ、自信を持って「ざっくりとした完了イメージ」を書けば問題ありません。
このように、何がどうなっていれば、このプロジェクトは「終わり」と言えるのか？を表現したものが、プロジェクト計画書におけるゴールイメージです。
なぜゴールイメージを作るのか？
では、なぜわざわざゴールイメージを作るのでしょうか？
理由はシンプルで、プロジェクト完了時の状態を事前に共有するためです。まず前提として、ゴールイメージはプロジェクト計画書を構成する一つの要素です。
そして、そのプロジェクト計画書自体は、主に次の目的で作成されます。
- プロジェクト全体の見通しを立てるため
- プロジェクトに関わる人を動かすため
ゴールイメージは、この中でも特に「プロジェクトの完了状態」にフォーカスしたパートです。
完了状態を事前に共有することで、プロジェクトの見通しが立ちやすくなり、関係者を動かすための材料にもなります。
プロジェクト計画書の役割については、以下の記事でも詳しく整理しています。
プロジェクトメンバーに対して
まず、プロジェクトメンバーに向けた観点です。
ゴールイメージを作ることで、
- 何をもって「終わり」なのか
- どこまでやればよいのか
を、プロジェクトメンバー全員で共有できます。
もちろん、計画段階で作るゴールイメージなので、内容は「ざっくり」したものになります。それでも、ゴールが見えている状態と何も見えない状態とでは、メンバーの安心感は大きく違います。
また、プロジェクトが始まったあとも、ゴールイメージがあるだけで「どこに向かっているのか」がチーム全体で揃いやすくなります。
特に、関係者が多いプロジェクトほど、ゴールイメージは認識ズレを防ぐための重要な役割を果たします。
マネジメントラインに対して
一方で、ゴールイメージはマネジメントラインに対しても効果を発揮します。
マネジメント層にとって重要なのは、
- このプロジェクトで何が得られるのか
- 最終的に、どんな状態になるのか
が、直感的に理解できることです。
ゴールイメージにこうした情報が整理されているだけで、
- メンバーのアサイン判断
- 予算やスケジュールの承認
といった意思決定がしやすくなります。
ゴールイメージは、プロジェクトを前に進めるための交渉材料としても機能します。
ゴールイメージには何を書くのか？
では、ゴールイメージには何を書けばよいのでしょうか。
「完了状態をざっくり書く」と言われても、なかなかイメージが湧かない人も多いと思います。そこでここでは、実務でよく使われるゴールイメージの3つの表現パターンを紹介します。
今回は、「申請・承認業務の改善プロジェクト」を例にして解説していきます。
① テキストで表現するパターン
ゴールイメージを、文章（テキスト）のみで表現するパターンです。
最も手軽に作成できますが、テキストだけだとイメージの共有が難しくなる点には注意が必要です。
メリット
- テキストだけなので作成が簡単
- 要点を端的に伝えやすい
デメリット
- 読み手によって解釈がブレやすい
- 内容を補足する説明が別途必要になりやすい
使い所
- 関係者の前提知識が揃っている場合
- とにかくスピード優先で整理したい場合
テキストのみで表現する場合でも、箇条書きやマトリクスを使うなど、できるだけ構造的に書く工夫をするのがおすすめです。
② システム構成で表現するパターン
システムの導入・改修を伴うプロジェクトで、よく使われるゴールイメージの表現方法です。
このパターンでは、細かく書きすぎないことが特に重要になります。
メリット
- エンジニアなどIT関係者にもゴールイメージを伝えやすい
- 改修内容や影響範囲を俯瞰しやすい
デメリット
- 図の作成にある程度時間がかかる
使い所
- システム導入・改修を伴うプロジェクトの場合
システム系のプロジェクトでは、システム構成で表現するのが基本になります。その際、関係するユーザーや業務もあわせて記載すると、よりゴールイメージが伝わりやすくなります。
③ 業務プロセスで表現するパターン
業務の変化が大きいプロジェクトや、システム改修を伴わないプロジェクトでよく使われる表現パターンです。いわゆる BPMN図 を使った表現が代表例になります。
メリット
- 新しい業務の流れを直感的に伝えやすい
- 業務担当者との認識合わせがしやすい
デメリット
- 作成に時間がかかる
使い所
- 業務の変化が大きい場合
- 関係する業務範囲が広い場合
業務プロセスの流れに加えて、利用するツールやシステムもあわせて記載すると、ゴールイメージがより具体的になります。
このように、ゴールイメージの中身は同じでも、表現方法はいくつか選択肢があります。
プロジェクトの性質や、誰に説明したいのかを意識して、最適な表現パターンを選ぶことが重要です。
ゴールイメージの作り方
ここからは、ゴールイメージの具体的な作り方を見ていきます。
ゴールイメージは、いきなり「完成形」を描くものではありません。すでに整理している 課題 や 対応方針 をINPUTとして作成します。
基本的な考え方はシンプルで、対応方針に沿ってプロジェクトを進めた結果、最終的にどんな状態になっているかを可視化する、というものです。
進め方の全体像は、次のようなイメージになります。
ここからは、次の申請・承認業務の改善プロジェクトを例に、具体的な手順を見ていきます。
目的
- 申請・承認業務をシステム化し、業務の属人化を防ぐ
課題
- Excel・メール・紙が混在している
- データが分散し、管理・集計ができない
- 承認履歴が残らず、後から追えない
対応方針
- 申請・承認を一元管理できるシステム基盤を用意する
- 関係システムと連携し、二重入力をなくす
STEP1：対応方針の先にある完了状態を考える
まずは、上記の対応方針に従ってプロジェクトを進めた結果、最終的にどんな状態になっているかを想像します。
今回の対応方針は、次の2点です。
- 申請・承認を一元管理できるシステム基盤を用意する
- 関係システムと連携し、二重入力をなくす
これを踏まえると、完了状態としては次のようなイメージが浮かびます。
- 申請・承認を扱うシステム基盤が存在している
- その基盤を中心に、関連システムと連携している
- 申請関連の二重入力が発生しない状態になっている
このSTEPでは、ここまでイメージできれば十分です。
STEP2：表現パターンを選ぶ
次に、イメージした完了状態を どう表現するか を考えます。
ゴールイメージの表現パターンは、次の3つでした。
- テキスト
- システム構成
- 業務プロセス
今回の例では、システムを導入・改修することがほぼ確定しています。
テキストだけでは、
- システムの全体像
- システム間の連携関係
を表現しづらいため、システム構成で表現するのが適切だと判断できます。
STEP3：可視化する
選んだ表現パターンで、実際にゴールイメージを可視化します。今回は「システム構成」です。このときのポイントは、STEP1で整理した完了状態を 漏れなく表現すること です。
- システム基盤が存在していること
- 関連システムと連携していること
- 二重入力が発生しない状態になっていること
これらを踏まえて可視化すると、次のようなゴールイメージになります。
なお、「システム構成」といっても、
- クラウドの詳細構成
- 製品名や技術要素
などを細かく書く必要はありません。この時点では、まだソリューションは決まっていないからです。
大事なのは、完了状態が「ざっくり」伝わること。関係者が同じイメージを持てるレベルで十分です。
STEP4：見直す
最後に、必ず見直しを行います。チェックするポイントは、次の2つです。
- 目的が達成された状態になっているか
- 課題が解決された状態になっているか
改めて、目的や課題とゴールイメージを照らし合わせ、それらが満たされているかを確認します。
ゴールイメージを作る過程で、
- この内容だと目的が達成できない
- 課題が中途半端にしか解決できていない
と気づくこともあります。
その場合はゴールイメージを修正します。
基本的には、目的や課題は固定したまま、ゴールイメージ側を調整するのがポイントです。
（もちろん、ここで課題設定そのものがズレていると気づいた場合は、課題を見直すのもOKです）
まとめ
ここまでの解説で、ゴールイメージは「細かく決め切るもの」ではなく、完了状態を「ざっくり」描くものだということがイメージできたのではないでしょうか。
プロジェクト計画の段階で、完了状態を完璧に描き切ることは、正直かなり難しいです。不確実な要素が多い中で、すべてを決め切ることはできません。
それでも、「ざっくり」で構わないので、完了状態を可視化しておくことで、
- このプロジェクトは、どこを目指しているのか
- チームとして、何をゴールに頑張ればよいのか
が明確になります。
こうしてゴールイメージを共有することで、関係者間の認識が揃い、プロジェクトを前に進めやすくなります。プロジェクトは、不確実性の塊です。だからこそ、チーム全員が同じ方向を向いて進むことが重要になります。
そのための強力なツールとして、ぜひプロジェクト計画書の中でゴールイメージを活用してみてください。
おまけ：よくあるNGパターン
最後に、ゴールイメージを作るときによくあるNGパターンを紹介します。
どれも実務で本当によく見かけるものなので、「自分は大丈夫かな？」という視点で、チェックしながら読んでみてください。
NGパターン①：内容が細かすぎる
ゴールイメージが、必要以上に詳細になってしまっているパターンです。
これは、
- 長く温めてきた企画だった
- 担当者がその領域に詳しい
といった場合に、特に起こりがちです。
例えば、ゴールイメージの中に次のような内容まで書かれているケースです。
- 画面項目の詳細
- 機能仕様レベルの記載
- システムの詳細構成
- 利用する具体的なソリューション名
一見すると「よくできている」ように見えますが、次のようなリスクをはらんでいます。
- ソリューション先行になってしまう
- 後戻り（手戻り）が発生しやすくなる
プロジェクトは、段階的に具体化していくものです。
そのため、プロジェクト計画の段階では、あえて抽象度を高く保ち、「完了状態をざっくり示す」ことの方が重要です。
NGパターン②：目的とズレている
ゴールイメージは作られているものの、
- なぜそれをやるのか
- 何を達成したいのか
と、目的とつながっていないケースです。
このパターンでは、
- やりたいことは整理されている
- 一見すると「やった方がよさそう」
という内容が並びがちです。
しかし、「何のためにやるのか？」とズレたゴールに向かって進んでしまうと、プロジェクトとしては失敗になります。当然、投資判断や承認も得られません。
この場合は、目的や対応方針と照らし合わせながら、ゴールイメージを修正していく必要があります。
NGパターン③：課題が解決されていない
やりたいことは書かれているものの、最初に設定した課題が解決されていないパターンです。
一見すると、
- 今よりは良くなりそう
- 何かしら改善されていそう
に見えるのですが、実際にゴールに到達しても、肝心の課題が残ってしまいます。
すでに対応方針に沿ってゴールイメージを作っているにもかかわらず、課題が解決されていない場合は、ゴールイメージではなく、対応方針側を見直す必要があります。
ゴールイメージは、あくまで「課題が解決された結果」を表すものです。
関連記事