本格的なスタートの前の準備!プロジェクトの立ち上げでは何をするのか?【プロジェクトマネジメントの基礎】

2022年8月22日

プロジェクトを本格的に始める前の準備を「立ち上げ」と言いますが、今回はこのプロジェクトの立ち上げについて解説していきます。

プロジェクトの目標(ゴール)は何か?

まずはプロジェクトのゴールを明確にしていきます。プロジェクトの目標は、プロジェクト中に選択を迫られた時の判断軸になります。
プロジェクトのゴールを明確にするというのは当たり前のように聞こえますが、ゴールをあいまいにしたままプロジェクトを進めていることは多々あります。たとえば「Webサイトをリニューアルしよう」とプロジェクトが開始されることはよくありますが、このようなあいまいな目標では、後々にトラブルへ発展します。
たとえば、Webサイト1つとっても、10代・20代向けにするのであれば、アニメーションの多い、動きや見た目を重視したもののほうが効果的ですが、高齢者向けにするのであれば動きを抑え、文字の大きさやコントラストに気を配らなければなりません。
このように二律背反の選択を迫られた時の判断軸になるのがプロジェクトの目標です。この目標があいまいだと誰にとっても100点の製品(サービス)を目指してしまい、プロジェクトが座礁してしまいます。
「高齢者でも閲覧しやすいような、アクセシビリティの基準を満たしたWebサイトにする」「Webサイトから採用の応募が年20件は来るようなWebサイトにする」というように、明確な目標を立てておけば、判断に困ることはありません。

使う人(ユーザー)は誰か?

具体的なプロジェクトの目標を形成するためにも、プロジェクトで生み出そうとしている製品やサービスを使う人(ユーザー)を特定しなければなりません。先程のように、Webサイト1つとっても、対象とするユーザーによってデザインも求められる機能も変わってきます。
どのような人にとっても100点の製品やサービスはないため、誰にとっての100点を目指すのかを決めておく必要があります。

何が求められているのか?(要求事項を集める)

ユーザーを特定したら、次はそのユーザーが何を求めているのかを考えていきます。
ユーザーが求めている事柄を要求事項と呼びますが、最終的にはこの要求事項を一覧にしてまとめていくと管理がしやすくなります。
ここからは要求事項を集める方法をいくつか紹介していきます。

ヒアリング

ユーザーが社内にいたり、すぐに話を聞けたりする場合は、ヒアリングが最も効率よく要求事項を集められます。
ヒアリングを行う際は、漠然と話を聞くのではなく、事前にアンケートシートを送付し、聞きたいポイントを明示するなど、限られた時間で効果的な話ができるようにしましょう。

ブレインストーミング

ユーザーへのヒアリングが難しい場合や、これから全く新しいサービスを生み出すため、ユーザーがいない場合は、ユーザーが求めるものを自分たちで想像しなければなりません。
最も一般的なアイデア出しの方法がブレインストーミングです。プロジェクトのメンバーたちでアイデアを出し合い、ユーザーが求めるものを考えていきます。

ブレインストーミングについては下記の記事もご参照ください。

KJ法

ブレインストーミングで出てきた意見をまとめる方法はいくつかありますが、その1つがKJ法です。
KJ法ではカードを使ってアイデアをまとめていき、いくつかのカテゴリーに分けていきます。そしてカテゴリー分けされたアイデアを見ながら、図解化や文書化をしていきます。

KJ法については下記の記事もご参照ください。

ペルソナ分析

ペルソナ分析は具体的なユーザー像を文書化し、ユーザーが求めているものを考える手法です。年齢や性別、果ては趣味や嗜好まで具体的なユーザー像を考えていき、そのユーザーに求められている製品やサービスを考えていきます。

ペルソナ分析については下記の記事もご参照ください。

ディシジョン・ツリー

ディシジョン・ツリーとは、意思決定のために作成された樹形図のことです。ほしいものを文書化することは容易ではないため、質問を繰り返しながらほしいものの輪郭を浮き彫りにしていきます。

ディシジョン・ツリーについては下記の記事もご参照ください。

情報をまとめる

要求事項トレーサビリティ・マトリックスのイメージ画像
要求事項トレーサビリティ・マトリックスのイメージ(PMBOK第6版、149頁を参考に作成)

収集した要求事項はリスト化や、表組みでまとめることで管理がしやすくなります。
表組形式で要求事項をまとめたものを「要求事項トレーサビリティ・マトリックス」と呼びます。

「As-Is / To-Be」モデル
「As-Is / To-Be」モデルのイメージ

また、「今がどのような状態で、どのような状態になりたいのか?」を図示した「As-Is / To-Be」モデルを作成していると、プロジェクトの参加者の中で目標のイメージを共有することができます。

これら2つの手法については以下の記事もご参照ください。

スケジュールと費用はどの程度かかりそうか? ~スケジュールと費用の概算見積~

要求事項を集め、プロジェクトの目標が明確になってきたら、本格的にプロジェクトを始める前に概算のスケジュールと費用を見積もっておいたほうがよいでしょう。

同じ組織に専門家がいるのであれば協力を仰ぎ、身近に相談相手がいなければ、外部のベンダーなどに参考見積を依頼します。

実際にプロジェクトが始まった後は、再度スケジュールと費用を詳細に見積もりますが、プロジェクトの最中に「ここまで時間がかかるとは思っていなかった」「そこまでお金は出せない」ということが無いように、大まかな見積は用意しておいたほうがよいでしょう。

プロジェクトの主要な関係者は誰か?

プロジェクトを本格的に開始する前に、プロジェクトの参加者などの関係者を洗い出していきます。たとえば社内にユーザーがいるとします。この場合、彼ら自身が関係者になりますが、プロジェクトに参加してもらうとなれば通常業務で忙しい中会議に参加してもらうということもあるので、その上司にも許可を取る必要があります。

このように、プロジェクトの関係者は直接的にプロジェクトに参加する人だけでなく、その人たちがプロジェクトに参加することで影響を受ける上司や同僚なども含めて特定しておいたほうがよいでしょう。

こうしたプロジェクトの関係者を「ステークホルダー」と呼びますが、このステークホルダーはプロジェクトの進展とともに増えていきます。

ステークホルダーと良好な関係を築くことがプロジェクトの成功の秘訣ですが、これはプロジェクトが実際に動き出してから、「ステークホルダー・マネジメント」として再度考えていくことになります。

プロジェクトの成功基準・失敗基準は何か?

成功基準

次にプロジェクトの成功基準失敗基準を考えていきます。
成功基準とは、プロジェクトがどのような状態になったら成功したと言えるのかを定めていきます。
プロジェクトマネジメントでは、プロジェクトの目的達成もさることながら、スケジュールが遅れていないか、予算超過を起こしていないかも厳しくチェックする必要があります。品質・コスト・納期、いわゆるQCDに注目しながら、成功基準を決めていきます。

成功基準とは、このプロジェクトの成否をどのように判断するのかを文書化したものです。
成功基準は以下3つの質問に答えられるような形にするとよいでしょう[1]PMBOK第6版、34頁

  • このプロジェクトの成功とはどのようなことか
  • 成功はどのように測定されるか
  • どのような要因が成功に影響するか

2点目の「成功はどのように測定されるか」という質問に対しては、具体的な数的根拠をもって答えられることが望ましいです。
たとえば営業支援ツールであれば、投資収益率(ROI)の計測や、1ヶ月当たりの商談数などの目標を定めるとよいでしょう。

終了基準

プロジェクトの成功基準を定めた後は、プロジェクトの終了基準も定めておきましょう。
つまり、「○○の開発が完了し、△△による検収が完了したら」であるとか「○○のイベントが終了したら」というものです。

失敗基準

成功基準とは逆に、失敗の基準をプロジェクトの企画を立てる際に明確にしておくと、価値のないプロジェクトをずるずると続けることがなくなります
成功基準で用いた指標の中で「どの水準を下回ったらこのプロジェクトを見直すか」をあらかじめ定めることで、プロジェクト見直しのタイミングを逃すことがなくなります。

さいごに ~これまでの内容を文書にまとめ、周囲の合意を得る~

今回はプロジェクトを立ち上げる際に検討すべき事項をまとめていきました。
プロジェクトの目標、求められているもの(要求事項)、概算スケジュールと費用、プロジェクトの関係者、そして成功基準や失敗基準は1つの文書にまとめて、後から参照できるようにします。
この文書をPMBOKなどでは「プロジェクト憲章」と呼びますが、プロジェクトの企画書のようなものだと考えて差し支えありません。
このプロジェクト憲章を稟議などにかけ、記載されている内容でプロジェクトを進めてよいかの確認を取りましょう。

ここまででプロジェクトを開始するための準備である「立ち上げ」は終了です。

1PMBOK第6版、34頁