色んな人が集まって何かするって大変ですよね＞＜
そんな私のための講座に参加してきました。
「プロジェクト」マネジメント講座 〜物事を「推進」する力を身につける

講師は「予定通り進まないプロジェクトの進め方」著者の後藤洋平さん（増刷決定！4月には起業予定！）
みらいけんオーナーの後藤さん（親戚ではない）とみらいけん設立前から
「一緒に何かやりたいですね～」といいながら数年越しのコラボ企画実現！

参加者にも現役PMっぽい方がいたりして初心者ながらわくわくします。
（進まないPJ問題、PMの立ち位置の難しさなどなど、開催前からPMあるあるで盛り上がってる）

イントロ：講師紹介

「世界で一番わかりやすくて、実際に使えるプロジェクト推進フレームワークを構築する」ことが個人的なミッション
プロジェクトに関わるほとんどの人はプロジェクトのプロではない
プロじゃなくても誰もがプロジェクトマネジメントができるように。
現在、各地での講演やワークショップなどで活動中！

今日のテーマ：なぜプロジェクトマネジメントが必要か

Chapter①プロジェクトとは一体何か。プロジェクトマネジメントのスキルで解決できることとは？

「プロジェクト」という言葉を定義すると・・・？
参加者のこたえ例：
これまでやったことのない取り組みを期限をつけてやる、始まりとゴールがあるもの、1回限りのもの、期限があるもの、期限中に変化があるもの、成果を求められるもの、1つの目的を持ってメンバーが集まり行動するもの、etc..？？？

世の中にあるほとんどのプロジェクトは、
なんだかよくわからないうちに始まって、いろいろ試しながら形を作っては直したりして、これだという確信が得られないなか、終わりを迎える

↑のように感じることが多い背景は2つ
①未知に取り組むから（課題、目的、手段、環境、、みんな初めて！）
②有限の資源でやるから（知識、人、お金、時間、設備、、限りがある！）

プロジェクトにおいて、
「手にしているもの」「制約条件」「目標」
は時々刻々と変化していくからプロジェクトマネジメントは難しい・・・！

いつでも理想は単純で、現実はややこしい。。

インプットとアウトプットの相関関係が明確でマネジメントしやすい
のがルーティンワークだとしたら、
実施した施策が思ったような結果を招かないのがプロジェクト。

・ルーティンワーク例：
営業担当を1名増員すると、売上がN万円増える
単語を100個暗記すると、TOEICでN点UPする
・プロジェクト例：
採用広告に100万円使ったが、ひとりも採用できなかった
システム開発プロジェクトが炎上して、納期に間に合わなかった

とはいえ、プロジェクト・ワークとルーティン・ワークはハッキリ分かれているわけではない。同じワークでも実行者の経験の有無によって違う

例えば、料理をしたことがない人にとって、美味しいご飯を作ることはプロジェクト・ワークだが、プロのシェフにとってはルーティン・ワークに近い

ルーティンワークでないあらゆる社会的活動は、プロジェクトである。
では、どうやったらプロジェクトをうまく進められるのか？
その手段が「プロジェクトマネジメント」

Chapter②PMって、どういうこと？プロジェクトマネージャの、よくあるイメージを検証

今日のビジネスプロジェクトマネジメント
・環境：たくさんの情報、ツール、成功事例
・組織：プロジェクトは多くが部門横断でメンバーは皆兼任
・働き方：短い時間で最大の成果を求められる、工数不足。。
とはいえ、
経営として、スピード・量・クオリティどれも妥協できない・・・！
→結果、プロジェクトリーダーが疲弊

人が多ければ良いというわけではない。。
・ゴールや動機は人によって違う
・色んな意見を統率する必要がある

マネジメント＝思い通りにする、望んだ通りの結果を出すこと
では対象となる「プロジェクト」とはどんな性質のもの？

目に見えるモノがないので、評価できない
そんな「プロジェクト」を思い通りにするのがプロジェクトマネジメント

対して、プロジェクトの成果物には
色や形、匂いや味など五感に訴えかけるリアリティがある
感想が述べやすいが、当初の目的との間にGAPがあることが多い
検収条件に合致しているのか、評価をすることは、意外と難しい

あらゆるプロジェクトの過程は抽象化すると結構単純

しかし実際は、見えない中で進むのでかなり手戻りが多い。。

手戻りを防ぐため「整理→計画→実行」を行うことが定石

・整理：曖昧な目標を分解し、ミッションと成果を明確にする
・計画：目的を達成するためのアクションプランを立て、明確化する
・実行：チームビルディングをして、メンバーに割り振り、推進する

ただ、あかじめ描いた青写真に無理やり現実をあわせようとする
「演算的に管理」するマネジメントの限界を感じる人も多い。。

計画に無理して現実を合わせると結局、最後は炎上することも多い
なぜか？

①獲得目標と勝利条件を事前に確定できない
例えば、「家は3回建てない理想の家にならない」とも言われる

②要望、要求、要件、仕様、設計の混乱
例えば、要求と仕様を勘違いするとイメージと全然違うものができてしまう

プロジェクトマネジメントとは
プロジェクトが解くべき問題を定式化し関係者との間に意思疎通をすること
発生している課題を整理し、仕事が進む「流れ」を生み出すこと

Chapter③プロジェクトマネジメントができるようになるために：プロジェクト譜

マネジメントの2つのタイプ（資料ではキングダム引用で解説）
・知略型：目標設定、計画立案、戦術策定
・本能型：臨機応変、人心掌握、モチベート

演算的な、逆算式のプロジェクトに対するアンチ・テーゼは本能型にあり？
✕　事前に考えた戦略、作戦に現実を当てはめて考える
◯　火がつく場所を嗅ぎ分け、それを活かす

プロジェクトが成功しにくいチーム
・プロジェクトの全体について考えるのがPMだけ
・硬直的な役割分担
・各メンバーは自分の作業だけに注力
・自分の担当だけ果たせば、全体については気にしない
・問題が発生したら責任を問うのが優先、解決は二の次
例えば、各部門長が集まると自部門の利益ばかり考えて進まなくなりがち
それでは状況の変化に対応しきれない

プロジェクトが成功しやすいチーム
・各メンバーが全体を把握しようと務めている
・自分の役割、直近のアクションに取り組んでいる
・状況の変化に応じた柔軟な連携、結果隠れた能力の発見
・各個人が、チーム全体を到達地点までたどり着かせようとしている
・不足していることを補い合う姿勢
状況の変化に応じて柔軟に対応できるチームワーク
プロジェクトマネジメントの仕事はメンバーの隠れた能力の発見など
次に活かせそうな芽を見つけること

プロジェクトマネジメントの王道：PMBOK

勉強する人も多いが、挫折する人も多い。抽象的で難しい。。

PMBOKのメリット
・姿形のないプロジェクトというものを「どのようにして見るか」がわかる
・PMBOKに長けたメンバー同士だと共有言語化となり意思疎通しやすい
PMBOKのデメリット
・あくまでも知識集なのでそのまま現場では使えない
・抽象度が高いため眼の前の具体的な活動における「キモ」と結びつき難い
・参考書の多くは情報システム開発をベースに書かれており汎用性は低い

PMにおける頻出の悩み
・ドキュメントを書いても書いても、読まれない！
・前提条件が変わってしまい何度も何度も、書き直し！
…そんなことやってる暇があったら、作業を進めたくなる(´・ω・｀)

そんなプロジェクトを推進するためのツール
「マネジメントプロジェクト譜」

プロジェクト工学の考えをフレームワークにしたもの
もともとは設計学（日本発の学問！）をもとにしている
設計学は「どうやって考えたら良い設計ができるのか？」を考える学問

プロジェクト譜のメリット
・書きやすく、読みやすい（3階層でシンプル）
・考慮漏れを防ぎやすい
・着手前の設計にも、プロジェクト終了後の振り返りにも使える
プロジェクトを始める時、勝利条件が意外とすり合っていないことが多い！みんなで認識を揃えるにはプロジェクト譜が便利！

プロジェクト譜のデメリット
・初めて書く際には、どのような粒度で記載するか等、要領をつかみづらい
・タスクとスケジュールを細かくマネジメントしていくのには向かない

Chapter④ワークショップ：プロジェクト譜を書いてみよう

プロジェクト譜作成手順

まず、テーマ（扱うプロジェクト）を選定する
①獲得目標と勝利条件を書く
・獲得目標：そのプロジェクトで実際に作ろうとしているもの、対象
　例：通販サイト、スマホアプリ、コンテスト入選 など
・勝利条件：どうなったら成功と言えるのか、獲得目標によって実現したいあり方
　例：売上●円を達成する、●年●月にカットオーバーする　など
④「廟算八要素」を書く　※そもそも「廟算」ってなに？はこちら参照
・人材、予算、技術、品質、納期、環境、競合、外敵
　できるだけ簡潔に、ワンセンテンスがポイント
　目標に対して有利か不利か、不足しているものはないかを考える
　特に該当するものがなければ、項目はスキップしてもOK
③中間目的と⑤施策を書く
・中間目的：獲得目標を達成するためにキーとなるもの
　可能であれば3個。互いに独立した要素に分解できれば尚良
・施策：中間目的を達成するための具体的なアクション
（⑤事象には施策を実施した後に得られた各種情報を足していく）

プロジェクト譜作成例とポイント

全体を通して
・マインドマップツール（X Mind など）を使うのもおすすめ
・最初に皆で図を書いて、都度変化していることを一緒に感じることが重要
・プロジェクトオーナー、プロジェクトマネージャー、メンバー、外部パートナーなど関係者全員が参加して作成する
・最初は単純に考える
・進める中で状況に変化があったら更新していく
・初期条件に縛られない
（⑤事象も書き足していく。勝利条件が変わっていくこともある）
・最初は構造化できなくてもいい
例えば、「Aをすることで、Bしたい」を粒度も具体性も気にせずブレストで100個出した後でグルーピングしながら構造化してもOK
（まずはプロジェクトのパーツを出し切って帰納法的に組み立てる）

獲得目標・勝利条件
・獲得目標と勝利条件がないと始まらないが、課題設定が最も難しい。。
・動機整理と深掘りが大事（人によって動機が違うと施策もずれてくる）
・「因」と「縁」は行ったり来たりするもの　※参考：因縁果とは
　「因」（≒動機）：なぜやるか
　　例えば、トップダウンで始まったプロジェクトの場合、
　　動機はきっかけ（社長の一声など）しかない場合もあるが
　　「そこにメンバーの動機は本当にないのか？」を深める
　「縁」（≒行動）：何をやるか（何でやるのか）
・勝利条件は「どうなりたいか」must／wantも切り分けて考える

中間目的・施策
・中間目的が3階層以上になりそうな場合、階層を増やしても、サブプロジェクト譜を作ってもOK
・ただし、「3」階層にある程度こだわるのがおすすめ
（4以上になる時は整理しきれておらず、更に分解できる場合が殆ど。
　あと、ヒトは3つ以上のものを覚えられないｗ）
・施策はウォーターフォールでマネジメントできる粒度のものが望ましい
（＝何をすればどうなるのかがある程度わかる粒度）

初めて書いたプロジェクト譜（プ譜）はこちら ※赤ペン済

1人で書いてるとすぐ煮詰まっちゃって、
他の人に口出ししてもらうのすごい重要！
自分が思う以上に、最初に考えた前提に縛られていたんだなと実感です。

プロジェクトの進め方について、
これまでも全く勉強してこなかったわけではないものの
とてもシンプルに整理できてスッキリしました。
あと、すぐ試したい！と思う発見ももらうことができて（←ココ重要）
個人的には学び実感の多い講座でした！

※講座スライドについて、同じではないものの似たエッセンスを詰め込んだ資料が後藤さんのポートフォリオでもシェアされているようなので、
興味ある場合はこちらもご参照ください。