PMBOKが教えない成功の法則 の商品レビュー

本園明史(著者)

2024/06/01

目次の感じから悪くないかと思ったけど、なんだか異様に読みづらく2割ぐらい読んで離脱。なんだろうこの感覚。
・その段落の話がネガな話かポジな話かよくわからない
・小段落とか見出しの立て付けがよくわからない(構造が見えてこない)
・挿絵が何を言ってるかよくわからない
編集者(がいるかわからんが)のせいな気がする

2024/05/01

プロセスマネジメントに対して、実務の教科書的な内容が網羅されている印象。ただ、個別具体的なトラブルに即効性があるか、意外性があるかという観点では特に大きな学びはないかもとも感じた。

2020/04/01

『PMBOKが教えない成功の法則』本園名史（日経BP社, 2017）
【感想】
・先ほどのPMBOKの公式書の補足で、でもこんなトラブルってあるよね、その時は…が書かれている
・PJ推進にあたって要件が膨れてきたり、納得感をもって進めてもらうために話し合って離、実際に自分もぶち当たっている壁がまさに書いてあったので、試してみようと思えるチップスがつまっていました

2021/08/08

プロジェクトマネジメントのお勉強。確かにPMBOKに書かれた通りに物事はうまく進められないが、本書に書かれていることを実践するのも難しい気がする。断片的にはうなずけるところもあったが。

・精緻な計画を立てるのは工数の無駄遣い
・順次戦略と累積戦略を計画化する
　順次戦略：一つひとつステップを踏みながら、順序立ててロジカルに。結果を推定しながら進めていく。
　累積戦略：役に立ちそうなことが見つかり次第、すぐに実行する。成果との因果関係を証明するのが困難なケースもある。
・ステークホルダーマネジメントはPMBOKガイドの5％以下。
・プロジェクトの挽回策
　・非生産的な活動を発見する
　・ファストトラッキングを実行する
　・クラッシングを実行する
　・負荷バランスを調整する
　・新規要員を追加する
　・要員を交代する
　・中間成果物を削減する
　・開発規模を縮小する
　・段階的納入を検討する
　・要員を残業させる
　・再スケジューリングを顧客に申し入れる
・多忙な時こそ会議をあえて増やす

2018/09/29

PMBOKを学びたいと思い購入。著者の本園氏は三菱電機系列ほか数社でご活躍されたＩＴコンサルタント。

感想
PMBOKについては一切学べない（もともとそういうコンセプト）。しかし、困難なプロジェクトを達成に導くためのノウハウがたくさん紹介されていて、これはＩＴコンサルではない私にとっても、とても勉強になった。

備忘録
・この本が対象にしているのは不確実性の少ない簡単なプロジェクトではなく、暗闇を手探りで進めざるを得ないプロジェクト。
・プロジェクトの完全合理化は無理。曖昧さを無くすことに尽力すると一向に前に進まない。
・壁にぶつかった時、計画を一つずつ順番に進める順次戦略だけでは弱い。何らかの効果を狙ってある種闇雲に複数進める累積戦略も一考。この場合、偉い人に状況を説明しにくいがそこはマネジャーの腕の見せどころ。
・教科書が教えてくれるのは、教科書で扱える領域だけ。利害関係者の調整とか、信頼関係の構築方法とかは正解がない。
・マネジメント方法は、ジャイアン型・スネ夫型・のび太型それぞれを使い分けるのが良い。
・「雨が降ったこと」すらマネジャーの責任と思え。
・あら探し大臣には専用の囮を用意。それで満足してもらう。
・「合理的で正しい解決策だから受け入れてもらえる」は子供の考え。選ばれるのは正しい提案ではなく、意思決定者が理解できる提案。スンナリ分かってもらえるシンプルなプレゼンが大切。
・暗闇プロジェクトは、何が起きても想定内の事象と考えるべし。マネジャーは自信満々に「想定内」とウソをつくべし。
・原因究明や調査に過度に時間をかけるのは、時にマネジャー個人の納得感が得られるだけで、付加価値が低いこともある。
・合意と意見の一致は別物。意見は違くても、合意はできる。
・マネジメントにとって最も大切な仕事は、計画の策定や管理ではない。社会的・文化的問題の処理、チーム内の問題解決だ。
・言い訳ばかりの部下にイライラするが、そこはぐっと我慢し、言い訳を分析し、問題の本質を探す態度をとるべき。
・感情の力は、合理的で理論的な判断すら上回る、強い力。
・暗闇プロジェクトで難問にぶち当たった時、今目の前に仕事の付加価値があることを喜べ。
・部下に「対策を立てろ」と指示するマネジャーは無能。部下が対策を立てられるなら大した問題ではない。また、問題を無くすのは不可能。問題はやり繰りしろ。

2018/02/25

プロジェクトというのは1回限りという特徴から、
必ずといっていいほど問題が発生する。

その度苦悩するとは思うが、
問題が発生するのは逆に健全と捉えて、
それを解決するために事前に対策を考えることや
そういった問題が起きても対処できるような体制を組む
ことが極めて大切である。

成功事例というのは綺麗なところしか教えてくれず、
実はどんなに成功したプロジェクトであったとしても、
実は泥臭い仕事であるということを理解するには、
良かったかなあと思う。

要するに、その場その場に応じてやり繰り出来ていれば、
十分マネジメントとしては出来ているとみなしてよい、
炎上したとしてもマネジメントとしては成功していた
と自信を持ってプロジェクトに立ち向かいましょう
っていうのを教えてくれているのかなと思った。

【勉強になったこと】
・暗闇プロジェクトの計画で唯一当てにできるのは、
　体制、つまりどんなメンバーが参加するか。
　参画したメンバーでプロジェクトの成否は、
　半分以上決まってしまう。

・現場の問題が分かるのは、その場限りでやってくる
　ITコンサルタントではない。実際にその業務に
　携わっている人が分かっている。
　ITコンサルタントは現場の意見を聞いて集約し、
　それを上位層に説得するための肉付けをすることが
　大事だが、意外と現場に聞きに行かない。

・報告書は先に作ることが大事。
　どんな報告を上げるかを考えてから作業に臨む
　＝作業のダンドリを整理することに他ならない。

・期待値コントロールで大切なのは、
　プロジェクト完了時の満足度の最大化を目指すこと。
　途中下がってしまうことは気にしないこと。

・工程開始時の作業前提は、当たり前の前提しか
　書けないことが多いが、そうであれば仮説を立てて、
　それを前提として提示するくらいの意気込みがないと
　マネジメントが出来ているとは言い難い。

・暗闇プロジェクトでは、試行錯誤しながら進む
　つまり、手戻り覚悟で突き進むくらいのメンバーで
　ないとプロジェクトが成功することは無い。

・マネージャーに取って一番大事な仕事は、
　計画の策定や管理ではなく、人にかかわる問題対応。
　この時間を削減してはいけない。

・根拠はないけど、説得するということも時には必要。
　感情に訴えかけて進めることも大切。
　もう少し言うと、嘘をついてでも説得することも大事。

・増員によって遅延をカバーするときは以下を検討すること。
　①遅延タスクが人月工数に換算できるタスクである
　②遅延タスクの原因が質的な問題ではない。
　③スケジュールを25%短縮したければ、
　　要員を75%増加する必要がある。

・「何でも反対する人」には解決の権限そのものを
　渡してしまうことも解決策の1つ。

・会議のムダを排除する際の視点
　①会議の無い曜日を作る
　②会議の時間を深く考えず短縮する
　③会議の頻度を減らす
　④途中退席を許可する
　⑤参加者を絞り込む
　⑥リモートでの会議参加を可能にする
　⑦会議を統廃合する