プロジェクトマネジメントの原理原則を、おでん作りストーリーで学ぶ
•Télécharger en tant que PPTX, PDF•
5 j'aime•3,486 vues
プロジェクトマネジメントって、非常にとっつきにくいです。 PMBOKなどはいろいろ書いてますが、難しいですし。 ただ、プロジェクトマネジメントの原理原則はシンプルです！その幹の部分をストーリー形式でわかりやすく身につけて、その上で様々なプロジェクトマネジメントのテクニックを学んでいければ！という内容になっております。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Dernier
Dernier (12)
プロジェクトマネジメントの原理原則を、おでん作りストーリーで学ぶ
- 2. 今日のテーマ
- 3. おでん！ プロジェクトマネジメントは抽象的！ ● ノウハウ集で伝えても中々実践しづらい ● 覚える知識はわかりづらい！ ● でも、原理原則は同じだし、そこが大事！ ● なので、ストーリーでお伝えします！
- 22. 期待とは？ 期待には、いくつかの要素があります。 ● いつまでに応えてほしい ● このくらいのレベル（質）で応えてほしい ● このくらいの安さで応えてほしい などなど
- 23. プロジェクトマネージャーの仕事とは？ 期待をしっかり満たす＝「完了」させること。 ● おでんを用意する仕事は、「おでんを買え ば」終わりじゃない ● おでんで妻が満足させるのが仕事であり完了 ● 終了はただ終わってしまうということ
- 25. ある調査では。。。
- 31. 期待のトレードオフとは？
- 50. そこで、PMの原則2まとめ だいたいこれを押さえると計画といえます。 ● やること・やらないこと ● 関係者とその役割 ● スケジュール ● 起きたら困ること、とその対策
- 58. 太郎は計画を始めた 今回の期待は、「おでんで満足させ ること」だから。。 やること やらないこと ● おでん作り ● キレイな盛り付け ● 食べる環境を和風に ● 美味しいお酒 ● 来るまでの体験作り ● 泊まりの対応 ● 帰りの手配
- 59. 太郎は計画を始めた 今回の期待は、「おでんで満足させ ること」だから。。 ● 来るのは、妻・本社長・同僚。彼らを満足さ せる必要がある ● 妻がきっと味の好みに責任は持ってくれる ● 一緒に作る祖母・姉・甥の役割は。。。。
- 61. 太郎は計画を始めた 今回の期待は、「おでんで満足させ ること」だから。。 困ること 優先度 困る度 起こる率 材料買えない 15 5 3 お酒が足りなくなる 4 2 2 隕石が落ちて料理が台無し 0 500 0.0...
- 62. episode.3 流派を選ぶ
- 65. そして当日
- 71. ウォーターフォール（滝）流派
- 72. アジャイル（機敏）流派
- 73. 流派の特徴 ウォーターフォール アジャイル ● 計画変更が容易にできな い、建築や調査のPJで効 果的 ● ただし、要件漏れや計画 ズレには対応しづらい ● 計画変更や要件漏れに対 応しやすい ● コマ目に作れないものや、 正確なコストを初めに出 さないといけないものは 厳しい
- 74. PJの3つの真実 ● PJ開始時点で、全ての期待は集められない ● 集めても、期待は必ず変わる ● やるべきことは、いつも与えられた時間やお 金よりも多くなる
- 75. 「おでん」の場合は？ ● 作り直しが可能 ● 今回は、味の好みがわかりづらい＝期待の明 確化が困難 ● 食事は、特に期待の変化が激しい →アジャイル流派が合っていそう？
- 95. 具体的なビジョンの共有
- 96. 具体的なビジョンの共有 下記のようなepisode1の情報を整理 ● 背景 ● 目的 ● 成功基準 ● 完了基準
- 98. チームビルディング ● 自分は何が得意？ ● 自分はどうやって貢献する？ ● 自分が大切に思う価値観は？ ● チームメンバーが自分に期待している成果と は？
- 101. episode.4（再） おでんPJ始動
- 106. 太郎はPJを始めた みんなのことを知りたいな ● どんなことで貢献したい？何が 強み？ ● おでん作りにかける想いは？ ● みんなは君に何を期待している と思う？
- 109. 切るリスト ● 大根カット：1h ● ゆでたまご作成：3h ● こんにゃくカット：2h ・・・・などなど
- 116. 夫婦関係は冷え切ってしまった。。。
- 118. 計画は常に不完全。 未来のことは誰にもわからないので。。。 ● 現状把握 ● 原因分析 ● 対策立案 ● 再発防止
- 129. そして当日。。。
- 131. episode.6 困難ゲーム
- 143. episode.final エピローグ
- 150. 原理原則まとめ ● PMの仕事は、PJの「完了」 ● 期待を正確に捉え、トレードオフを把握する ● 計画は下記4つは最低押さえよう ○ やること・やらないこと ○ 周りの関係者の役割 ○ スケジュール ○ 起きたら困ること ● PJの流派をPJの性質から選ぶ
- 151. 原理原則まとめ ● メンバーのマネジメントをする ○ 具体的なビジョン・計画の叩き ○ チームビルディング ○ 計画のすり合わせ ● 計画は完璧なものはないので、管理する ○ 現状把握 ○ 原因分析 ○ 対策立案 ○ 再発防止
- 152. 追加で覚えてもいいこと ● PMBOKの習得 ● 正確な見積もりを出す ● 担当PJに必要な専門知識をつける ● 仕様書をうまく書く（伝えやすくする） ● PJの流派をもっと学ぶ ● PJの数値管理手法をもっと学ぶ（バグ率）
Notes de l'éditeur
- いかんせん、マネジメントは仕事のための仕事、なのですごく抽象的です。 そのため、ノウハウだけ聞いても実践しづらいし、 覚える知識は複雑だしよくわかりません。経験がある人＝抽象を具体に体験している人が固める向け（PMBOKしかり） ただ、知識をなぞることではなくて、原理原則を押さえることが大事なので、それを「おでん」をめぐるストーリーでお伝えします！その原理原則だけ持ち帰っていただければと思います！
- テレビゲームとかのゲームではなく、ゲーム理論のゲームですよ！
- なので、何かが過剰でもよくない！なぜなら、大抵イノベーションでもしない限り、安さと質はトレードオフだから！ そしてイノベーションは現実的に考えうるものではないので、プロジェクトマネジメントの範疇外です！
- 一番PMが不要なのは、左下。 普段の仕事で、「定例の資料作って」など。ただ、資料の中身は確認したりなどは必要だが、1人でできるし確認を取るのも用意なので楽。 左上は、「ブランド特集のページ作って」など。期待は明確だが、仕事はデザイン・開発・文章作成が関わる。そこで、そのスケジュールやクライアントなどとの調整が必要。 右下は、「忘年会のお店選びをして」など。どんな忘年会？禁煙？喫煙？料理は？飲み放題は？など、仕事自体は単純だが、期待のコントロールが必要。 右上は、「新規サービスのPM」そもそも、何が当たるのかわからないので、期待も不明確だし、やることも複雑になりがち。
- らしいです。恐ろしいですね。そして、私の経験といろんなPM仲間の意見を聞くと、ほとんどの原因は期待の部分にあります。
- 発注している側は、仕事も複雑だし、そもそも期待も不明確だと、できる？できない？の判断ができない。そこをうまーく調整して、成功に持ってくのが、PMの仕事です。無理なものは、無理なのでこれなら期待に応えられますという調整が必要なんです。PMは現実世界で生きています。
- これは完全計画のとき以外必要です。完全計画というのは僕の勝手な用語ですが、全て期待を正確に捉えられていて、完璧な品質・コスト・納期で計画ができていて、どんな不祥事が起きてもOKなのだー！ということです。 そんなのはほぼないので、譲れないところと譲れるところを聞いておくことで、そこを調整して期待を応えられる状態で進めることができます。
- ってことで
- ここが個人的に一番大事なことなんですが、伝わりました？ 期待に関してより細分化して把握して、トレードオフ関係もしっかり聞いておくのが大事という内容です。 普段の仕事だと、目的とかを聞いておくってのがよくありますよね。
- PMBOKだと、何個のエリアとかありますが、too muchですし、疲れます。 期待に応える上で、困りそうなことを事前に考慮しておくのが本質です。なので、本をなぞっても意味がないですよ。 計画の本質は、「期待に応えられる＝完了できる、と思える見通しが立つことです」 そして、これをドキュメントにまとめることがポイントでもないです。ドキュメントにまとめる意味は、認識統一したり、確認をしておく意味合いがあります。
- 数値のシミュレーションとかもやる意味があるときにすればいい。プロジェクトマネジメントは、期待に応えることが目的で計画を綿密に引いたり、ドキュメントを作ることが仕事ではないです。なので、それの調整ができれば最悪計画は不要だし。 でも、ある程度引いておくのは基本重要ですよ。 ここでは原理原則をお伝えしているので、綿密に計画を引くことを否定しているわけでも、計画がないことを否定している訳でもないです。重要なのは、「PJの完了の見通しを立てる」ということです。
- そしてこれらは絶えず見直しましょう。
- 負債って初めは小さい額に見えるんですが、どんどん後になって取り返しのつかないことになるんです。 承認者が複数いたりとか。
- 見通しを立てることが大事です。いつ終わるのか？わからないのでは非常に問題なので、いつ終わるのか？どのくらいの品質なのか？どのくらいかかるのか？の期待の調整をしましょう
- このやることのリストが管理できる単位になります。これを、「デザイン」「コーディング」などでまとめてしまうと、実はそこまでいらないものに時間をかけてデザインの見積もりをしたりなどあります。 なので、ユーザーの達成したいことで書くとより、そういった問題が減ります。 例えば、キレイな盛り付けは、「まず見た目が和の雰囲気で食べる前でも、美味しそう！と感じてもらう」などです。 そういう形にすれば、例えば「過剰に、全ての食器を高級のものにしよう」など、やりたいことのレベルでできますよね。 そしてこれのメリットはそれだけでなく、より伝わりやすくなります。「ああ、こういうやりたいことを達成すればいいのね、そのための食器は、、、、テーブルは、、、など」 そうすると、さらなるメリットはメンバーが言われたことをするだけから、自分で考えるようになりますし、これが自主性も引き出します。
- 滝のように、上から順番に計画を立てて、作って、テストして、運用して、と進むやり方です。滝なので後戻りはできず、前の工程がしっかり終わってから進める感じです。
- 少しずつ、何度も繰り返して開発していきます。
- どちらがいい？悪い？ではありません。そのPJの性質に合わせて柔軟に流派を選択することが大事です。
- 期待は集められないし、変わるし、マネジメントが必要なんです
- なので、初心者はアジャイル流派がおすすめです。ウォーターフォールは、かなりマネジメントスキルと計画を正確に作るため、PMスキル＋その対象物の知見がだいぶ必要になります。
- ビジョンを具体的に共有します。アウトプットイメージも大事ですが、それよりもみんながどう幸せになっているか？どうしたいのか？を描きます。（WEB施策の場合は、ユーザーストーリーですが、そもそもそれ以前の戦略が必要なことが多いです） 要は、なんでこれをやるの？というコンテキストを与えることが大事です。 どんなにPJメンバーの自発性を重んじていても、これがないのそもそもどの方向に何をすればいいのか？わからないので、自発性が湧きようがないです。
- ココに来て、ドキュメント化しておくといいかもですね！忘れがちなので
- 大抵、PJメンバーは自分にはない専門性を持っています。なので、計画自体は自分で全て作る必要はないです。 しかし、その分マネジメントをするためには、「コンテキスト＝やりたいこと」を押さえている必要があります。 そのやりたいことを、その出してきたことで実現できるのか？をすり合わせましょう。 今回は原理原則をお伝えしているので、最低限の要件をお伝えしています。 なので、各メンバーよりも専門性があって綿密な計画を作成して渡してもいいですよね。ただしそれは、ベターであってマストでないです。 それに、逆に厳密な計画を作りすぎてしまって、やる気がそがれることもあるんです。。。
- これはPJメンバーが完全に自分のアサインになった時にやるといいです。というのも、価値観などは結構踏み込んだ話にもなるので。 ただし、すごく重要です。（一部ステークホルダーマネジメントとも被ります）
- 各自のやり方に正解を打ち出していく必要があります。例えば、やりたいことの実現で期待の要素＝時間・予算・品質とバランスを取りながら最適なものを作っていくイメージです。そして、各トレードオフ要素のバランスに最終的に責任を持つのもPMです。
- ここらへんは個人的な思惑があったりして大変です。組織が中々変われないのも、ここらへんの文面にすると笑ってしまうような都合を上手くマネジメントするのが大変だからです。だからこそ、できるだけベクトルを揃えていけるようにしましょう。 各自のやりたいこと・強みと、仕事内容が一致していければベストです。
- 見積もりは、初期段階だと最大400%ずれるといいます。また、要件も漏れがちです。初期段階でいくら話しても詳細な計画は詰めれないんですね。PJが進むに連れ、100％実際の値と近づいてくるので。 ここまで具体的になったからといって、任せるだけでOKになるわけではありません。 しかし、見積もりは重要です。なぜなら、これがないと、いつ終わるのか？どのくらいお金がかかるのか？のジャッジができないためです やることのタスクを数値に落とす作業が重要です。
- 数値化してタスクの終わり具合と、その速度で終わるのか？をチェックしましょう。 そして、1個1個の作業が終わったと言っているけど、本当に終わっているのか？をやりたいことの基準と照らし合わせて、テストしましょう。テストのためには、完了の意味がわかってないといけません。完了の司さどるのが、PMなので、完了ってどうなればいいの？はおさえておきましょう。品質に関わる要素なので重要ですよ。 また、数値でいい感じに進んでいるのか？を把握することも重要です。定性的では終わるのかどうか？という、疑問に答えづらいためです。期限に間に合うのか？も期待のトレードオフコントロールなので重要です。 しかし、これはPMがやってチームを監視するため、と勘違いしないでくださいね。PJの現状を把握するのは、どの流派やPJでも大事な原理原則です。 チームメンバー自身が自分たちの今いる位置を確かめる必要もあって自発的にやる意味合いもあるし、PMがしっかり監視する場合もあるけど、いずれにしても原理原則として必要ということなんです。
- 有効にできるものもあれば、時と場合によっては何かを犠牲にしないといけないときがあります。 期待の要素の中で何をいじれるでしょうか？ ・品質 ・スコープ ・期限 ・予算 期待要素で今回いじれそうなのは、予算！期限ですよね。 もしかしたら、スコープもいじれるかもですね。 しかし、品質は厳守。 残業をして対応する、などは今回はできないですが、最終手段ではいいかもですがあまりおすすめしません。 それは期待に応えるためにリソースを調整するということですが、せいぜい2倍くらいしかいじれないですし、健康面でもきっと無理がでてきて、PJ負債になります。 PJ負債はためていくと、いつか病気で1週間いないなど、ガタが出てきてしまいます。 PMは現実的にPJを完了させないといけないので、頑張ってなんとかする、といった不確定なものに頼るのは不安でできないです。
- 予算には余裕があるので、包丁を購入しました。
- とにかく、いいものを作る！という期待要素だけを見ていて、他の予算や時間、他メンバーのスケジュールを考えずに決めてしまうことです。原因は、いいものを作ることが大事＝品質偏重主義。もちろん、品質が低いことは駄目なのですが、それはPJの期待によります。
- 丸投げや、言ったことは全て確約しろなど、依頼者のコミットメントが薄く、外注感覚で無理な丸投げをするパターンです。 大抵は地雷です。 結果的に依頼者もいいものができないので、誰も幸せにならないんですが。。。
- 案外いいようですが、管理のしようがなくなります 「他の仕事のマネジメント」までできない以上、どうしようもない状態になり、大抵崩壊します。ｌ
- 現実をいかに説明して、満足行くようにしても、根性論で片付けるタイプの人もいます。
- タスクをブラックボックス化しようとする人がいます。管理のしようがなくなり、約束したことをじゃあ、完全丸投げでやってね？となります。 しかし、大抵遅れたりなどして、PMに結局調整しろ！などと言ってくるので要注意
- 願望が最重要戦略になっている人がいます。しかし、願望だけでなんとかなるのは、魔法の杖があるときだけです。
- いつまでも叩きや（仮）で、何も約束しないことはよくありません。しかし、スケジュールや計画はあくまで未来の推測です。 推測は外れます。 なので、それをいかにズレないように持っていくのか？が重要になります。仮決めしながら進めていくのが大事です。
- 政治の問題は大きく2種類あります。プロセスの問題と、モチベーションの問題です。 プロセスの問題は、不明確な意思決定プロセス・コミュニケーション不良・リソースの割当が不明確・説明責任の欠如・不明確な目標など、なんでこうするの？が微妙で、根回しが発生します。これは、プロセスを明確にしてすり合わせをお互いがしていけば解決します。 逆に何も言わずに、いじいじしてたりすると、どんどん闇だけたまります モチベーションの問題は、難しいです。 しっかり全体の目的とベクトルを統一する作業をしたり、価値観をお互いにすり合わせしておくこと、自己理解を進めることが重要になります。
- PMは詳細は知らなくてもいいですが、やりたいことや基準は持っていないといけません。みんなに聞いて決めるのは、考えるのを周りに委ねて思考停止している証拠です。※もちろん、自分はこう思うけど、これに関してどう思う？など現状把握は必要ですが。 意思決定の時は、意思決定の意思決定をすることが重要です。 この意思決定って、どのくらい影響がある？意思決定にミスったとしてどういう問題が出る？どのくらい時間かけて意思決定できる？誰が決めるべきこと？情報収集する必要があるのは誰？誰の承認が必要？などなど 当事者意識を持って、自分でこういう風にしたい、がないと決められないです。 それができれば、メリデメでも論点整理でも決めるのは比較的カンタンです。
- 実は、今までスライドでお伝えしていない、PJの原理原則で重要なことが1つだけあります。それは振り返りをする。ということです。 太郎君は、タイムリープできるんで時間を巻き戻して全部やり直せるんですよね。 自分もたくさん炎上案件などを経験してきました。成功ばかり求めていくと、いろんな知識を集めるだけになってそれをなぞることや、何にも意見を言っていないような綺麗事ばかり並べてしまいます。失敗の経験を通してこそ、物事の本質に近づけたりすると思うし、みんなタイムリープなんてできないです。 今やってるチーム制でも、今日話したみたいなことが、あ！できてないってことや、これは無理だよなーということが実はあります。 PMの本で熊とワルツを。という本があって、リスクと一緒にPJは踊るようなものだ！という本です。 失敗とワルツを刻むような、そういう働き方をしていくくらいのほうが余裕があっていいと思ってます。 一度失敗したからといって、全てが否定されるわけでもないですし！ 環境が否応なく変化する時代なので、たくさん失敗もしていくことが多くなっていくと思います。しかし、強い組織ってのはこういう変化に失敗しないことでなく、変化に合わせて柔軟に対応していける組織かなとも思っていて、そういった自己対応して、学習していく組織を作っていくことが大事と思うんです。 何度もいろんなことを試してみるって、自分個人としては結構大事にしている価値観です。 まあだから何度も転職しちゃうんですけどねｗ
- チープなエンディングでしたが、まとめです。
- ただ、ここは枝葉のことで、より詳しく知ってもいいけど、枝葉なのでPJの成功の完成度は上がりますが、劇的なものではないです。 本質をしっかりやった上で、よりスケジュールを正確にしれた方がいいよな、見積もりを正確にしていこう、ということが大事で原則は期待に応えるために、完了のための道筋をざっくり立てること、ですよね？ ただ、見積もりが正確にこしたことはないので、正確にする数々の手法があります。しかし、見積もりが正しいから、マネジメントや調整をしなくていいわけではないです。それに、見積もりはどこまでいっても、推測・当てずっぽうの域を出ないんですよね。なので、本質を大事にしていきましょう。