![見出し画像](https://assets.st-note.com/production/uploads/images/26578475/rectangle_large_type_2_0d7e296bfff97fee97bd33b46e0b811d.jpg?width=1200)
おい、PjMってなんなんだ?(その1/3)
勤め先で事業企画部に配属され、『プロジェクト定義書』なるものを作成することになった。作り方を悩んでいる時に紹介された『外資系コンサルが教える難題を解決する12ステップ』が非常にまとまっていてわかりやすかったので、読書メモ。基本的には、目次通りにsummaryをまとめていますが、私なりに解釈した後にまとめたものですので、詳細は本を読んでください。私的な備忘録です。
ただ、基礎研究のポスドクから急に社会(ベンチャー企業)に放り出され、試行錯誤しながらもビジネスとはなんぞやを覚えていこうとしている私が、この本を読んだときの所感も書いています。興味がある方には、少し面白いかもしれません。
序章:本書でプロジェクトマネジメントを学ぶべき理由
VUCA(Volatility, Uncertainty, Complexity, Ambiguity)時代において、全ての業務がプロジェクト化している。プロジェクトには「独自性」「有期性」がある。(本書のプロジェクトと定常業務の比較テーブルがわかりやすい)つまり、緻密な計画や厳密な管理では追いつかない。上記を前提としながらも、プロジェクトには型が必要だと主張し『D3アプローチ』という手法を提案している。
(所感:私は、幸いなことに”プロジェクト”立ち上げから”定常業務”へと作り込む経験をさせていただいている。少し形になったところなのだが・・・その時の試行錯誤は、我ながらよく頑張ったと思う。その時に感じた感覚が、見事に言語化されていた。この本では、プロジェクトマネジメントの実践的な型について述べられているのだが、プロジェクト→定常業務に昇華する際にも役立つと感じた。また、『いくら精緻な計画を立てて、厳密な管理をしても、プロジェクトでは問題は必ず起こる』については、研究計画作成の経験がドンピシャで役に立っており、失敗から多くを学ぼうという精神はビジネスにおいても重要なのだ。働いていて思うのだが、研究に真面目に取り組んでいてよかったと思うことが多い。)
第1章:定義フェーズ
![](https://assets.st-note.com/production/uploads/images/26579828/picture_pc_8f0e3fc2e6fa75e5cc3e035b5daf9faa.png?width=1200)
最終目標
ワクワクするビジョンを自分の言葉で語り、自ら達成可能だと信じるゴールを設定。SMARTな目標を立てて、それぞれの目標を因数分解した標的を定め、そこに到るまでのマイルストンを置いていく。逆算思考をする上でも最終目標は重要。
(所感:ビジョンとゴールは別物として、しっかりワクワクさせるビジョンがかけているのかを意識することが重要。チームメンバーに感想を聞いて書き直すことも必要。あとはゴールが具体的になっていれば特に問題なく設定することができる。ここで詰まったらプロジェクトいる??案件。)
対象範囲
プロジェクトを俯瞰し、対象範囲と対象範囲外を明確にする。加えて、具体的な成果物の定義をする。
(所感:実際にやってみた時には、具体的な成果物を定義→最低限の対象範囲を決定→それ以外を対象範囲外と仮置き→プロジェクトメンバーとの共有および擦り合わせの順番で考えると頭が整理できた。)
利害関係者
プロジェクト内のステークホルダーの整理、マップを書くのも有効。ステークホルダーからの過度なアクセルやブレーキを避けるために期待値管理も重要。
(所感:定義フェーズに入れるの難しいので、大雑把なステークホルダーの期待感を把握してマップを作成。プロジェクトが進むとそこに具体性が出てくるようにした。感情が入ってくるから、なんだかんだでここが一番難しい・・・。)
阻害要因
プロジェクトの「想定外」について、リスクと問題と課題に分けて整理しておく。リスク評価マトリクスから優先順位と対応策を決める。リスクの洗い出しには、プロジェクトメンバーでブレインストーミングを行うといい。
(所感:これは、経験に依存するところが大きいと思う。ただ、このセクションを設けているかどうかが重要だと思う。私は、ざっと思いつくところだけでリスクマトリックス作成し、阻害因子に対応する箱を用意しておくことにしている。)
まとめ
ここまでで、プロジェクトの背景に当たる部分が定義されました。ビジョンとゴールを混同することによって生じるマイナスの影響について、幾度となく見てきました。ビジョンで心を掴んで、ゴールでの頭を掴むってよくわからないことを書きましたが、せっかくプロジェクトを始めるのだからお互い気持ちよく始めたいよねってことです。弊社の場合は、定義するところでたたき台を作成し、メンバー(事業企画部)の意見を聞いて修正する機会を設けました。やっとプロジェクトの首が座った程度です。しかし、私はプロジェクトを定義することがもっとも重要だと感じています。これないと迷うんですよね〜。
ちょっと長くなりましたので、デザインフェーズと推進フェーズは別記事にまとめます。
この記事が気に入ったらサポートをしてみませんか?