4-2 プロジェクトマネジメントとは？（R先生ver）

こんにちは、こんばんは、おはようございます、inaです！

あと2週で学校がおしまいのため、毎日せっせと資料作りだの、
課題と格闘だの、しておりまして、、、、
更新を全くしていませんでした！！！！！！

というのは建前で、やはり先生の力ってとてもすごくて、
毎週テイクアウェイできるものはあるのですが、
忘れてもいいかもぐらいの自分にとっても重要度だったりして、
やる気と元気がゼロ状態でした。

今週は！久しぶりに！
2ターム目でお世話になった大好きな先生が代講をしてくれて、
やっぱりこの先生から学ぶことがありすぎる！と思ったので、つらつら書いていこうと思います。

プロジェクトマネジメントの5段階

プロジェクトをどのように細分化するかは本当に人それぞれ。
その一つがこちら。

1. Initiation

2. Planning

3. Executing

4. Monitoring

5. Closing

特に1を忘れて2から始まってしまう例が多いらしい。
1のイニシエーション（初期化）では、まず現状把握を深く行います。
「今持っているResourceを全て見える化する」
※Resourceは、お金、人間、時間、フィジカルなものの4つのカテゴリで見ていくと良い。
これだけでその後のタイムロスやお金のロスが全然変わってくる。

2の段階に入ったら、Deliverable/Task/Milestoneの3つの線引きをしっかりして進めていくことが大事。
例えば、起業家コースを終了するというのを「プロジェクト」とするなら、
Deliverable（成果物）が課題の提出だとして、
Milestoneは各課題の締切日や1ターム・2タームといった時がベースになり、
Taskは課題を提出するために必要な資料作成、情報収集などの具体的な行動のことを指す。

これをごちゃ混ぜにして管理していることが多いため、
結局タスクが見えなくなってしまっていて3の実行段階で躓いてしまう。
（間違いない、、、自分のプロジェクトマネジメントできていないのに、職場の管理できるわけ・・・と心の中でしょんぼりでしたけど、これからの自分に期待。）

リスクをどのように扱いますか

どんなプロジェクトにもリスクはつきもの。定期的にリスクを予想して見直すことは大前提。

リスクの大きさを測る要素は
「リスクが起こる確率の高さ」×「リスクが起こった時の影響力」で決めます。

定番の図だけど、5×5 Risk Matrix が一番参考になるしわかりやすかった。

リスクが起こった時にどうするか。ここも忘れちゃいけない。
1. Avoid （避ける）
2. Transfer　（別のところへリスクを移動させる）
3. Mitigate　（軽減する）
4. Accept　（受け入れる）
5. Finance　（財政的に対処する）

ここでTransfer と Mitigateについては特に大事だし、それができるように優先していくと良いとアドバイスがありました。

Stakeholderのコンセプト

これが個人的には目から鱗レベルだった、、、（きっと普通なんだろうけど）。

ステークホルダーはいわゆるプロジェクトに関わるすべての関係者という意味で、inaがステークホルダーを考えるときは常に中心に自分がいて、そこからマインドマップ上にステークホルダーが360度いますというのがinaのコンセプト的理解だった。

こんな感じ↓

昨日までのinaにとってのステークホルダーのコンセプト

でも、先生はステークホルダーなんて基本2つしかいなくない？って言い始めたんです。
2つ以上あるだろー！！って思っていたら、
「自分に影響を与える人」か「自分が影響を与える人」
って考えた方が早くない？って説明をしていて、脱帽。本当に脱帽。

つまりはこういうこと（先生が書いたホワイトボードそのまま書き写していた）

今日からのinaにとってのステークホルダーのコンセプト

inaが影響を与える存在に対して投資をしようとする人や団体がいるのだから、そこまで考えましょうねという結論でした。

勉強。

質って何で測る？

プロジェクトマネジメントは本当に用意する資料がたくさん。細かいところまで全部共有されるのですから、文書化しないといけないんです。
クラスメイトはこのタームの課題の多さにげっそりしています（笑）

その中にStatus reportというのがありまして、いわゆる進捗報告書みたいなものです。

報告することは山ほどあるのですが、その1つにQuality statusというのがありまして、プロジェクトにおける成果物がどのような質であるかという項目です。

例えば、成果物が公式ウェブサイトの作成だと見える「もの」であれば質は測りやすいのですが、顧客満足度の向上なんてざっくりとしたものにしてしまうと質・・・？ってなってしまうのです（クラスメイトがもっとわかりやすいのに設定すればよかったと嘆いていたけど実際そういうプロジェクトも現社会で存在しているので良い練習になったのではと思うinaです）。

先生は「今の時代Happinessですら測れるのよ！何が測れないっていうの！！あはは〜」とスーパーポジティブでしたが、先生からのアドバイスは

質を測るための材料が出来上がったら、以下の基準を元に測ってみなさいと。
1. Output
2. Performance
3. Efficiency
4. Effectiveness 

ここでinaの持論展開ですが、逆算してこれが測れるような「もの」を作った方がいいんじゃん？って思ったわけですね。
例えば、顧客満足度の向上ならば顧客満足度を測るための調査方法がプロジェクトの前後でどう改善しているか測ると。

これすっごく面白いけど、職場でやるって相当・・・・って思いました。
inaの私生活や家族周りのイベントについて資料を全部作って実践して練習していった方がいい気がする！笑

Deliverableをどうやって決めるかが重要なんだと気づきました。Deliverbleを曖昧な文言ではなくて、最終的な成果物として出すように考える力は多分幼い頃からの両親の教えのおかげな気がするな。感謝ー！！！

（ちなみにinaの人生初のPitch presentationは8歳。犬が飼いたいということで、両親に犬を飼ってもらうという『投資』をお願いしたのがきっかけ。「犬が欲しい？じゃあ資料作ってパパとママに見せて」から、本当に問題定義、解決策（犬を飼うこと）、市場調査、タイムライン（トラクション）まで手書きでまとめて提出しました笑）

ダラダラと書いてしまいましたが、プロジェクトマネジメントはみんなが実生活をしながら自然と最低限のことはやっているけど、上手に管理・遂行できる人が少ないから、職種として必要な存在なんだなということがとてもよくわかりました・・・。
いつかプロジェクトマネジメントディレクターとか言ってみたい（？）

あと2週は、最終プレゼンテーションのため突っ走ります！！