【約12,000字】スタートアップにおけるプロジェクトマネジメントマニュアル
プロジェクトマネジメントマニュアルについて
皆様はじめまして。堤です。私はこれまで新卒から一貫してスタートアップ企業で働いて来る中で数人規模〜数百人規模の幅広い組織でのプロジェクトマネジメントを経験してきました。その他学生時代やプロボノを通じて、NPOやボランティア活動でのプロジェクトマネジメントも行ってきました。
このマニュアルは「スタートアップ・ベンチャーにおいてプロジェクトマネジメントを推進し、成功させる型・知識」を、私のこれまでの複数のスタートアップ・NPO・プロボノ活動の経験と本や書籍からの知見、諸先輩からのアドバイスを元に体系化し、まとめたものです。
プロジェクトマネジメントは、実践で活用できてこそ意味のあるスキルになると思います。そこで、このマニュアルでは、実務で活用できるフレームワークや、私が実際にプロジェクトを推進するときに使うテンプレート、気をつけるチェックポイントなど、とにかく「実践で使える」ものをまとめました。
1万字超えのかなりのボリュームとなりましたが、ぜひ現在進行形で悩んでいる方や、これからプロジェクトマネジメントにチャレンジしてみたい方に読んでいただけると嬉しいです。
それでは、以下から本編になります。
プロジェクトマネジメントとは何か
Wikipediaによると以下の通り
プロジェクトマネジメント（プロジェクト管理、英語: project management）とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。
ちょっと長いですが、要は「プロジェクトをちゃんと推進して成功に導いてね。」というのが１番求められることです。
プロジェクトマネジメントには、システム開発の業界での定義やもっと広い一般的なビジネス活動全般におけるプロジェクトマネジメントの定義などで幅があるのでそれぞれですが、今回はビジネス活動全般においてプロジェクトを推進して成功させるには何に気を付けるべきか？という観点でまとめます。
スタートアップのプロジェクトマネジメントの特徴
通常プロジェクトマネジメントでみなさんが想像するのはどちらかというと、「決められた範囲のものを、もともと予定されている期限通りに、期待通りのクオリティーとコストで終わらせる」ことだと思います。
ただしスタートアップにおいては、プロジェクトが開始した時点では想定したアウトプットが予見仕切れないパターンも多くあると思います。（実際にプロジェクトを始めたら、当初の想定と状況が大きく変わってしまった、リサーチした結果、仮説が大幅に異なっていた、想定以上にポジティブなインパクトがありそうなので、プロジェクトの範囲や規模を拡大したい、などなど）
そのため、今回はそういった「攻め」のプロジェクトマネジメントを進める時の考え方をまとめています。
プロジェクトマネジメントの大まかな流れ
先に全体像をお伝えすると、大まかな流れは以下の通りです。
全部で5つのフェーズに分かれており、その中でも11個のステップを進めていきます。
フェーズ①：プロジェクトの大枠の合意
1. プロジェクトのオーナー（意思決定者）、リードを決める
2. このプロジェクトのゴール、成功の定義/やらないことをすり合わせる
3. プロジェクトのタイムラインを擦り合わせる
フェーズ②：プロジェクトの詳細の設計
4. プロジェクトのスケジュール、メンバー、会議体、マイルストーン、大枠の論点を作成する（プロジェクト概要書の作成）
フェーズ③：プロジェクトの詳細の合意・キックオフ
5. 4.を元に進め方をプロジェクトのオーナーと再度合意する
6. 5で合意ができたら、プロジェクトメンバーとのKick off mtgの実施 & 社内への情報伝達
フェーズ④：プロジェクトの進行〜意思決定
7. 4. のプロジェクトの大枠の論点を、論点表に落としていき、
スケジュールの設定と担当者のアサインを行う
8. 7の論点表シートを元に、リサーチ、社内外のヒアリング、各部署との会議などを行い、検討・検証・アウトプットの作成を進める
9. 検証結果やアウトプットを、プロジェクトオーナーに共有し、マイルストーンに沿ってディスカッション・意思決定を繰り返す
フェーズ⑤：プロジェクトアウトプットの完了と振り返り
10. 当初のプロジェクトスコープが完了するアウトプットが共有された、 意思決定がされた、成果がされた場合はプロジェクトを完了する
11. 必要に応じて、残論点や追加のプロジェクトの立ち上げの有無などもディスカッションを行い、対応する
ここからは、上の11個のステップのそれぞれについてポイントも加えながら解説していきます。
フェーズ1： プロジェクトの大枠の合意
step1. プロジェクトのオーナー（意思決定者）、リード（いわゆるプロジェクトマネジャー）を決める
これは当たり前のように見えて、意外とふわっとスタートしてしまうこともあるので要注意です。
そもそも全てのプロジェクトは、会社の各組織のミッションやOKRなどの各チームのKPIを実現するために取り組むものなので、メンバーが勝手に思いつきで始めてしまっても、それが組織が目指している方向と合致しなければ、いま進めるべきでない、そもそもはじめるべきプロジェクトではない、というジャッジもされうると思います。
大体のPJは自身の上長から「XXについて取り組んでほしい」と言われてやることが多いと思うのですが、その場合も「プロジェクトの意思決定者は誰か」というのを明らかにしましょう。
例えば複数の経営チームの合意が必要、複数の部の部長の合意が必要などの場合にはオーナーは1人でも、オーナー以外にしっかりと合意を取る人が複数いる前提でプロジェクトを進めていく意識を持つと、後々の認識の齟齬が起こりにくいです。
その上で、このプロジェクトのリーダーは誰かも上長と相談をして決めましょう。自分で勝手に「このプロジェクトやるぞ！」と思っていても、上長が「あれ、なんでこの人が仕切っているんだ？」となる可能性も0ではないので、上長とメンバー双方がPJに対してオーナーシップを持ち、役割を持つことを合意しましょう。
step2.このプロジェクトのゴール、成功の定義/やらないことをすり合わせる
プロジェクトリーダーは、周囲から質問された時に以下について答えられなければいけません。
Why：なぜ？このプロジェクトをやるのか？
What：このPJはどうなったら/どういう状態になったら/どういうアウトプット・成果が出せたら成功なのか？
そのために、Why/Whatについて疑問点があれば、プロジェクトオーナーに確認し、言語化をしましょう。MTGのその場でメモを書いて認識をすり合わせて置けると安心です。
「このPJでやらないこと」も併せて確認するのがとても重要です。なぜなら成功の定義は擦りあっても、その中のスコープの認識が微妙にずれてしまって、オーナーはやってくれると思っていたものが抜けてしまったり、逆に不要なものに取り組んでしまうリスクがあるからです。
ex. スコープをすり合わせるやりとりの例
オーナー：「プロダクトロードマップを検討してほしいです」
リード：「わかりました、それは自身が所属するXXチームのものだけで良いでしょうか？」
オーナー：「はい、それで大丈夫です」
リード：「ちなみに、スコープとしては、今期のロードマップだけで、来期以降については不要でしょうか？」
オーナー：「今期のロードマップが詳細であると嬉しいですが、加えて、10期以降にどの領域まで自社で開発をしていくかの方針も併せて合意したいです」
スコープをすりあわせるときの観点は以下のようなものがあります。
対象の範囲（自チームのみか、複数チームにまたがる、サービス単体、複数サービス）
期間（Qの目標、年間計画）
アウトプットの粒度（1年のうち前半の半年は具体的な月次のアクションプラン、後半の半年は大きくやること3つの方向性の記載のみ）
step3.プロジェクトのタイムラインを擦り合わせる
社内外のステークホルダーが関わる場合は、「CFのプロジェクトの公開日」「リリース日」「イベントの当日」などわかりやすいゴールがあると思うので、それを確実に合意をしにいきます。
社外の人が関わらない場合は、以下のようなタイミングが無いかを確認しましょう。
PJのアウトプット/成果を元に、経営チーム・事業本部などで意思決定を行うタイミングがあるか
社内のキックオフや全社MTGなど、大勢の人に伝達をするタイミングがあるか
上記のいずれの場合でも、その「X Day」にはどんなアウトプットや成果が必要なのかも併せて確認しましょう
フェーズ2： プロジェクトの詳細の設計
step4. プロジェクトのメンバー、会議体、スケジュール&マイルストーン、大枠の論点を作成する（プロジェクト概要書の作成）
1-3までが決まったらいよいよ、プロジェクトマネジャーっぽい仕事になります！
実際に、メンバーを巻き込んでいくには、プロジェクトの内容を言語化していく必要があります。その中で明確にしていきたいのが以下の4つです
1. PJを前に進める上で、今の時点で明らかになっている論点
2. PJに関わるメンバー
3. PJを進める上での会議体
4. PJのゴールに向かう上でのスケジュール&マイルストーン
2-4については、プロジェクト概要書に盛り込まれているので、このテンプレをコピペしてドキュメントを書き始めると抜け漏れが無く進めることができるのでオススメです！
言語化をしていくプロセスとしては、1.の論点を具体化してから、2-4を詰めていくパターンも、先に2-4をプロジェクト概要書で書いてしまって、1を別途論点で具体化していくパターンのいずれもありますので、やりやすい方で進めてください。
4つの観点について、ドキュメントにまとめていく上でのポイントは以下の通りです。
1. PJを前に進める上で、今の時点で明らかになっている論点
PJを成功に導くためには、様々なことに取り組む必要があります。よく「ガントチャートや、WBSなどでタスク管理をしよう！」というようなアドバイスがプロジェクトマネジメントの本や記事を読むと書いてあると思いますが、PJの開始時はタスクを漏れなく洗い出せるほど解像度が高くありません。そこでオススメなのが 「論点を洗い出す」 ことです。
論点については奥深いので、詳細は専門の本に譲りますが、ざっくり言うと「PJを成功するために説くべき問題・問い」です。
要はPJを進める上で解かなければいけない問いが何かを明らかにして、それを優先的に解いて行くのです。
私は前職のREADYFORで数々のプロジェクトマネジメント経験をさせていただきました。そこで、PJを進めていく際には「論点表」という問いをリストアップしていく方法があることを学び、今でも活用しています。
論点表は下の図のような形で、取り組むPJにより、大論点・中論点・小論点などに分けて整理していきます。（実務では大論点とその中に含まれる小論点という切り方が多いと思います）
論点を洗い出す作業は慣れが必要ですが、2つのプロセスが大きくあると思っており、やりやすい方で進めていけると良いと思います。
1: 大論点・中論点を洗い出す→小論点を書き出す
大論点・中論点はとにかく、MECE（もれなく・だぶりなく）書き出すのが重要ですが、やり方のアプローチは以下の2つがあるかなと思いますA: 関わるステークホルダーを洗い出し、それに紐づく問いを分類する
ex. 「新サービスをリリースするPJ」であれば、関わるステークホルダーごとに問いを立てる
B. 本やインターネット（ex. Google,ChatGPT）で同じテーマに取り組むときに、どういった観点がポイントになっているかを明らかにして、自分のPJに参照する
ex. 「新サービスをリリースするPJ」であれば、スタートアップに関する本やネット情報から以下のような中論点について検討すべきと示唆を得る
2. 思いつく小論点（or タスク）を洗い出して、グルーピングして抽象化して大論点・中論点を作る/ 洗い出した論点を抽象度で構造化する
ex. 「新サービスをリリースするPJ」であれば、以下のような小論点を洗い出した上で「オペレーション構築」というより抽象的な大論点&中論点を生み出していく
最初から上の大論点-中論点-小論点が全部洗い出されている必要はなく、歯抜けな状態で構いません。思考が進化する、リサーチ・議論によって明らかになった事実によって新たな論点・細かい論点が生まれるため、論点表は一度作って完成ではなく、PJ期間中ずっとアップデートし続けるものだと思ってください。
自分で1-2時間考えて、これ以上分からない！となったら社内の知っていそうな人や上長に相談してみるのも大事です。
そもそも論点表はステークホルダー間で検討事項の認識を揃えるためにも使うので、自分で全部論点を洗い出し切ろうと思わずに、周りの人を巻き込みながら作っていくものと考えてください。
論点表を書いた時点で、一度レビューをしてもらうのも有効です。間違った論点で検討を始めてしまうと時間を無駄にしてしまうため、実際の作業に入る前での合意形成を意識しましょう。
私が普段使う論点表のサンプルは以下の通りで、論点の隣に現時点での仮説とそれを検証するためのTo DOも一緒に書いてしまいます。
論点に関するオススメ書籍：
2. PJに関わるメンバー
1.で論点表を作ると、なんとなく「この問い、XXさんに聞かないと解決できなそう」「このタスク進めるのにXXチームの人の協力が必要そう」というのがぼんやりと見えてくると思います。
スポットのヒアリングなどの協力をしてもらう場合は、タスク管理を進めていく中で誰に聞くかを明らかにすれば良いですが、定期的にPJの進捗を共有して議論をしていく必要がありそうだったり、必要なアウトプットの一部の作成に他のメンバーの協力が必要そうであれば、そういったメンバーの時間をもらうために他チームの上長にPJメンバーのアサインを依頼する必要があります。
PJが始まってから都度メンバーのリソースを他チームの上長に確認するのは大変ですし、他のチームの日々の業務にも影響を及ぼしてしまいますので、アサインを依頼する必要があるメンバーはPJが始まる前に最低限明らかにしましょう。
もちろん、PJ開始時に全てを予見できない場合もあるのでできる範囲で、です。
余裕があれば、スポットで関わりそうな人にも先に頭出しができると良いので、検討をつけておけるとベターです。
なお、プロジェクトマネジメントの本などでも良く書かれていますが、PJの成否を決めるのは「適切なメンバーがアサインされているか」だと言われているので、自分で全部検討しきれない場合は、上長や周囲に積極的に意見をもらいましょう。
3. PJを進める上での会議体
1-2が決まってきたら、実際のPJ進行の土台となる会議体の設計です。
よくある会議体としては以下のような形です。
これらを事前に設計して、カレンダーで押さえておくのが重要です！（だいたいみんな忙しいので直前に日程調整をしようとするとカレンダーが空いていないことが多いのです）
またそれぞれの会議の頻度や時間、メンバーは初期の段階でPJオーナーとすり合わせて進めながら、PJの進捗によって変えていくことがほとんどです。
すり合わせないで勝手に進めてしまうと、認識が違ってしまい、一から設計し直すこともあるので注意が必要です。
4. PJのゴールに向かう上でのスケジュール&マイルストーン
最後は、PJのゴールを踏まえたときに、何をどれくらいのスケジュールでやるか具体的にしていきます。
アプローチとしては以下の2つがありますが、どちらも結構見積もりをするのに慣れが必要だったりします。
経営チームやステークホルダーへの共有会などのマイルストーンを先に仮置きしてしまう
それぞれの論点を進めるのに現実的にかかる時間を見積もって、マイルストーンを決める
プロマネ初心者のうちでも、自分の見積もりと実際の進捗を振り返るためにも、PJの最初から仮置きでも定めてしまうことが大切です。
スケジュールの見積もりに関しては、ワークプランという考え方があります。コンサル出身の先輩から教えていただいた、やるべき業務を優先度に沿って整理するフレームワークです。
上記を応用して、PJのワークプランを1週間ごとの区切りで、以下のようなFMTで立ててみると全体像が見えやすくなります。
最近の私のスケジュールの立て方としては、READYFORに入ってから編み出したプロジェクトを進めるときの論点/仮説/TO DO/担当/進捗/検討の開始日-終了日をWBSっぽく見えるように管理するシートを使って論点ごとの見込みのタスク完了日を仮置きして、マイルストーンを設定していきます。
Workplanとこのシートを両方使うと、仮置きしたスケジュールの精度が高まると思います。
よければご自身のPJを進めるときにコピペしてお使いください。
フェーズ3：プロジェクトの詳細の合意・キックオフ
step5. 4.を元に進め方をプロジェクトのオーナーと再度合意する
4.でPJの概要書と自分なりのPJを管理するシートができたら、再度PJオーナーと内容について合意するMTGをセットしましょう。
ここが抜けると、自己満足なPJ設計になってしまうので要注意です。
この段階でPJオーナーと合意ができると、当初よりPJリーダーの解像度が高まっているので、PJへの期待値もずれにくいです。
MTGをして、修正点などが出たら、追記/スケジュールの修正を行い、いよいよPJのKick offです！
step 6. 5で合意ができたら、プロジェクトメンバーとのKick off mtgの実施 & 社内への情報伝達
ここまで読んだ方は、「やっとキックオフするの！？」という感じだと思いますが、、、笑 そうなんです。PJは準備がとっても重要なので、ここでようやく関係各所への伝達やKick off mtgを実施していきます。
社内に新規のプロジェクトを立ち上げた際に、情報共有をする適切なslackチャンネルがあれば、そこにプロジェクト概要と関係するメンバー、チームを投稿をしましょう。
slackなどの非同期コミュニケーションで関係者に周知をすることで、Kick off mtgを実施しなくても良い場合もありますが、プロジェクトマネジメント初心者の時や、自身の想定していなかったチームからのコメントがある・巻き込まれたいチームが多い場合はKick off mtgを行い、関係者の認識を合わせることをオススメします。
キックオフMTGを実施する場合、アジェンダについては以下のような内容を盛り込みます。
1. 今日のアジェンダ共有
2. PJ概要（PJを実施する背景・目的とゴール、成功状態）
3. 参加メンバーの役割
4. PJのマイルストーン・スケジュール
5. PJを進める際のルール（どのslackチャンネルで議論する？今後の会議体は？ドキュメントは何を見れば良い？など）
6. 質疑応答
7. ネクストステップ
1-4はこれまでの準備で作った資料を参照すればOKですが、5のPJを進める際のルールは、キックオフMTGまでに各種セットアップをしておきましょう。
セットアップするべきこととしては以下です。
Google Driveに専用のフォルダを作成
Slackのチャンネルの作成と関わる/見ておいてほしいメンバーの招待
議事録ドキュメントの作成（PJ概要書にそのまま記載していく形でもOK）
Workplanや論点表など作成していくスプレッドシートの作成
よく使うドキュメントやスプレッドシートをslackチャンネルの関連ページに追加する
3.の参加メンバーの役割を伝えるときは、タスクを依頼する関係ではなく、PJを成功するために解決すべき「論点・問い」を一緒に考える仲間なんです！ということを伝えましょう。
フェーズ4： プロジェクトの進行〜意思決定
step7. 4. のプロジェクトの大枠の論点を、論点表に落としていき、スケジュールの設定と担当者のアサインを行う
プロジェクトリーダーが論点表を作成することができて、かつプロジェクトメンバーが複数いる場合は、それぞれの論点を誰が担当するかを割り振っていきましょう。
最初から全部埋める必要はありませんが、「そもそもこの論点を担当できる人は誰なのか？」という視点で整理ができると、自分が担当しなければいけない範囲の広さ、他のメンバーに頼むべきタスクの量などが見積もれるので、最初のうちにできる範囲で埋めるとその後のPJ進行の見通しがよりクリアになります。
step8. 7の論点表シートを元に、リサーチ、社内外のヒアリング、各部署との会議などを行い、検討・検証・アウトプットの作成を進める
いよいよPJの開始です！！！7-8はプロジェクトが開始したら、日々アップデートを繰り返しながら継続して進めていくものになります。
プロジェクトマネージャーは自分で作った論点表、ワークプラン、スケジュールを元に、どの論点を誰に取り組んでもらうかをアサインし、メンバーと協働しながら1つ1つの論点を明らかにしていきます。
論点を明らかにしていく際に重要なのが、実際にアクションを取る前に、それぞれの論点の仮説＝「論点に対するその時点での仮の答え」を持つことです。
仮説がないと、闇雲にリサーチやヒアリングをしてしまい時間を無駄にしてしまうので、論点を作ったら、仮説を立てて、その仮説を明らかにするためにやるべきタスクを整理していきましょう。
リサーチの手法についてはnoteを別途まとめているので、そちらをご覧ください。
論点を明らかにしていく作業は大きく分けると以下の4つになります。
①デスクトップリサーチ
②社外のヒアリング
③社内メンバーとのMTG
④PJメンバーとのディスカッション
②③などの他者が関わるものが時間がかかるので、早め早めにアポの設定などに着手をすることをオススメします。
ただし、②③はともに前述した「明らかにしたい論点と仮説」がない状態で望むと、結局論点を明らかにするために知りたい情報を再度聞きなおす必要が出てきてしまいますので、まずは論点と仮説を具体化し、それを検証するためには、誰にヒアリングをするのが良いのか？を突き詰めた上で社内外の人とのMTG・インタビューをセットしましょう。
論点に対する検証が進んできたら、もともとの論点から更に新たな論点が派生して生まれたり、当初おいていた仮説が全然違っていたなどの「論点・仮説の進化」が起きます。
しっかりと進化のログを残すためにも、論点表のシートの内容は最新の状態にして、メンバー間でのすり合わせを行いましょう。
この辺りの論点や仮説の進化などはPJリーダーとメンバーで1on1でDaily MTGなどで少しでもディスカッションする時間を持つと進みやすくなります。
自分ひとりで考えていると煮詰まることが多いので、とにかくそういった時間を減らす。困ったらテキストやMTGで第三者にアウトプットするがポイントです。
このフェーズに来たPJリーダーの心得としては、以下を意識するといいです。
必要に応じて意思決定者とタイムラインは変更する
プロジェクトリーダーが論点を更新できる余裕を持つ（毎日論点表を眺める）
PJが進んでいく中で、さまざまなことが明らかになると、PJでわかったことをまとめるためのアウトプットが求められます。
よく使うフォーマットはドキュメント、スプレッドシート、スライドなどがあります。
プロダクトチームと仕事をする中では、MiroやFigmaなどのデザインツールも使ったりしていますが、PJのアウトプットの内容に応じて使いやすいツールでまとめましょう。
社外のクライアント相手の場合は、スライドでの共有がベストかと思いますが、社内の場合は無理にスライドにせず、ドキュメントやスプレッドシートでまとめる形でも問題ないかと思います。（スライドが高速で作れる人はスライドでももちろんOK）
大事なのは、PJを進める中で何が明らかになったのかを関係者に伝えられることです。
step9. 検証結果やアウトプットを、プロジェクトオーナーに共有し、マイルストーンに沿ってディスカッション・意思決定を繰り返す
PJを進めていくと、色々なことが明らかになっていきます。その中で、プロジェクトオーナーはもちろん、経営チームや、他チームに伝えた方が事業上良いという状況になることも多くあります。
また、プロジェクトの状況を適宜、プロジェクトの主要なメンバー以外にも伝えることで、大きな出戻りや方向性の修正をする必然性を避けることができます。
ポジティブな観点としては、少し離れた立場から意見をもらえるので、PJが煮詰まっている時などに新しい視点を取り入れることもできます。
以上の観点から定期的なPJのアウトプットを共有し、ディスカッションする機会を設けることは非常に重要ですが、その進め方はPJの状況や関わるステークホルダーの多さなどにもよってきます。
私が過去に携わったPJでも、経営チームのみなさん1人ずつと議論をするMTGをセットした場合もあれば、経営チームのみなさんに一斉に共有する場を設けたこともありました。
その場もメインを情報伝達と質疑応答に絞った場合もあれば、ディスカッションの時間を多く設けた場合もありました。
この辺りはPJオーナーと相談して、1番良い形を検討しましょう。
フェーズ５： プロジェクトアウトプットの完了と振り返り
step10. 当初のプロジェクトスコープが完了するアウトプットが共有された、意思決定がされた、成果がされた場合はプロジェクトを完了する
PJが進み、無事当初の目的が達成された場合は一旦プロジェクトは完了となります。お疲れ様でした！！！
PJが終わると達成感と疲労感で少し休んで、また次の仕事に取り掛かろう！となる方が多いと思いますが、余力があればぜひやってほしいのが、「PJの振り返り」です。
振り返りの仕方としては、
①PJリーダーがドキュメントでまとめる
②PJメンバーとKPTを振り返る
の2つがあると思いますが、いずれも今後同様なPJに取り組むメンバーが資料を漁ったときに参考になると思うので、可能な範囲でやりましょう。
step11. 必要に応じて、残論点や追加のプロジェクトの立ち上げの有無などもディスカッションを行い、対応する
PJが一旦完了しても、体制の変更や会社の注力領域が変わることで、全ての論点に取り組みきれなかった 、という場合もあると思います。
その場合には、これまでやってきたことと残論点がわかるような資料を作成したり、然るべき人に引き継ぎと行ったりすると、大事な論点が宙ぶらりんになりにくいかなと思います。
最後に：プロジェクトリーダー（マネージャー）の心持ちとして大切なこと
問題が発生する前に、対応するのが重要。常に全体像を捉えて、どこの検討が遅延しそうか、リスクを察知しましょう。
メンバーの反応速度やアウトプットレベルから、リスクとなりそうな検討分野を特定することも重要です。
PJは予定通りには進まないと思うべし。当初考えていなかった到達地が見えてくることもあり、当初の目的に固執せず、臨機応変に変化する状況を上手く捌く必要があります。
プロジェクトマネジメント力とは、完璧なプロジェクト計画を描くことではなく、予定外の事態にも柔軟に対応する臨機応変力です。
PJに関わってくれる全ての人に感謝をし、その人たちがワクワクするような進め方、コミュニケーションを取るようにしましょう！
日々の業務がある中で、みんなPJに関わってくれています。忙しい中でも、このPJを一緒に成功させたい！と思ってもらえるメンバーを1人でも増やすのもPJリーダーの腕の見せ所です。
プロジェクトマネジメントは大変なことも多いですが、1人ではできない規模の大きな取り組みに関われるチャンスでもあるので、ぜひ機会があれば積極的にチャレンジしてみてください！
プロジェクトマネジメント講座のお知らせ
ここまで読んでいただき、本当にありがとうございます！
皆様の日々のプロジェクトマネジメントにどこかのパートが生きればとても嬉しいです。
そしてここでお知らせを少しさせて下さい。
このマニュアルの内容を元に、プロジェクトマネジメントの実践力を高めるための講座を2024/2-3で開催します。
初めての試みなので無料で実施予定です。
プロジェクトマネジメントは、中々体系的に学ぶことがない領域なので、共に学べる仲間を作れたらという思いで開催します！
詳細は下記のnoteにまとめておりますので、よければご覧下さい！
参考文献
OGP画像利用：Loose Drawing 様
この記事が気に入ったらサポートをしてみませんか？