■要約≪アート・オブ・プロジェクトマネジメント　前編≫

今回はScott　Berkun氏の「アート・オブ・プロジェクトマネジメント」を要約していきます。マイクロソフト社で多くのプロジェクトマネジメントを成功に導いてきた氏の経験に裏打ちされたプロジェクトマネジメントにおける急所を体系的にまとめた本です。本書は三部構成となっており、Ⅰ部はプロジェクトマネジメントにおける計画・Ⅱ部はプロジェクトマネジメントを行うに必要なスキル・Ⅲ部はマネジメントの技法を解説しております。今回はⅠ部の計画部分の要約を行います。

「アート・オブ・プロジェクトマネジメント」

■ジャンル：開発管理

■読破難易度：中（主にソフトウェア関連のプロジェクトワークを想定していますが、サービスや製品のプロジェクトマネジメントにおいても示唆に富んだ内容になっております。実践経験があると自分自身の実務の棚卸と合わせて学べてオススメです。）

■対象者：・プロジェクトマネジメントのベストプラクティスを理解したい方

　　　　　・非定型業務に従事する方全般

　　　　　・コトマネジメントにおける手順・思考法を体得したい方

≪参考文献≫

■エンジニアリング組織論への招待

■要約≪エンジニアリング組織論への招待≫ - 雑感 (hatenablog.com)

【要約】

■プロジェクトマネジメントの簡単な歴史

・プロジェクトマネジメントはソフトウェア開発は勿論、ハードウェア開発や建設などの分野で歴史的に多く実践されてきました。プロジェクトマネジメントはその複雑さと膨大な処理量故に、部分と全体を統合・最適化して付加価値を高めるというそれ専門の営みです。プロジェクト初期は「曖昧さを許容」しながら権限や指示命令系統を整理し、後半フェーズでは「実行の完全性にコミットする」というしなやかさが欠かせません。文書による要件や価値基準を明記したり、議論過程や意思決定プロセスを記録に残して承認を募っていくというのは大規模開発・利害関係者が複数のPJにおいては絶対感覚とされます。

■プロジェクト計画について

・プロジェクト計画は「何をする必要があるのか？」という問いに対する解の要求定義・「どうやって行うのか？」の問いに対する設計・仕様書作成・実際に行う実装の3パートに別れます。優れた要求書は理解しやすく、多義が及ばないように記述されるものです。「誰が何をいつまでに行うか」・「何をもって成功・失敗とするか」を明確に記述するというのはプロジェクトワークの基本動作です。その上で、「納期・予算などの制約条件下でスコープや目的・ビジョンを明確にし、上位組織や戦略に叶うようにアウトプットイメージを作りこむ」・「不確実性を解いていく優先順位付けをする」といった思考を回し、ステークホルダーと方向性や判断基準を揃えていくというのが一般的なステップです。

・プロジェクトワークは「何を明らかにするためなのか？」という問いや目的の設定・事前調査による構造化して筋の良い施策やテーマ設定することがワーク全体の生産性のカギを握ります。プロジェクト計画・定義などは顧客・ビジネス・テクノロジーの専門家数人を招いて少数精鋭で一気に作り上げるのが基本原則とされます。たとえアジャイル開発であったとしてもウォーターフォール形式のような「プロジェクト要求書やワークフローを可視化して論点やアジェンダを設定する」・「シニアステークホルダーと定期的にすり合わせをしておく」などがポイントになります。

■プロジェクト計画の羅針盤となるビジョンについて

・ビジョンはプロジェクト目的・判断基準を明文化することにあり、書き留めておき参照し続けることで意味を持ちます。ビジョンをドキュメンテーションする際はシンプル・意図重視（目標駆動）・統合・閃き・覚えやすいという5つの性質を有するべきとされます。「誰をどんな状態にする」・「何を○○にする」など明瞭であり、立ち返りやすいものにするのが基本の表現法の配慮すべきポイントです。具体的で測定可能・行動志向・現実的であるなど抑えておくべき性質も明確に決まっています。

・実践的なコツとして、プロジェクトが対峙する顧客やビジネスケースにおけるワークフロー・ユーザーストーリーなど全体を網羅的・構造的にビジュアライズできるフレームワークでまとめておくことが重要とされます。これは「ステークホルダーの共通理解を促進し、認知コストを最小化すること」で協力や助言を適切に仰ぐ為に面倒でもやっておくことがPMの絶対感覚として求められます。また、ビジョンやビジネス目標は一度明文化・作成して終わりではなく、運用し続けアップデートすることで最終的な成果測定できるようにすることはPMが強い意志をもって行うことが大事とされます。

■アイデアの取り扱いについて

・問題解決の生産性を高めるには要求を明確にすることと設計を探究することの2つのアプローチがあるとされます。つまり、「何を果たすためのプロジェクトワークなのか？」・「何をしなくてよくて何を担保しないと成功といえないのか？」といった問いに対する解の解像度を高めれば解決策や設計は自ずと導き出されるということです。要求を定義する際には解決策に真っすぐ首を突っ込むのではなく、イシューを射抜く要求であるということを構造的に分析・調査して結論を出すというステップを踏むことが大切になります。その際には前提を疑う・失われている要求条件を炙り出すという役割を率先して設計過程に反映させていくように関与するのがPMの望ましい振舞い方とされます。

・上記に加えて、各要求の因果関係・優先順位を明確にしてステークホルダーと認識をすり合わせる・曖昧な用語・情報の定義を揃えるというのもPMワークにおける大事なステップです。要求書には詳細な記述や前提条件を明記すると設計フェーズの制約条件が増えるので、「誰のどんな問題を解決して何を成しえたいのか？」というゴール・目的をシャープにするということに拘るのがポイントです。要求と設計は相互フィードバックして軌道修正していく、イメージをすり合わせるというのが健全な関わり方であり、これを開発に入れ込んだのがリーンスタートアップやアジャイル開発です。

・アイデアが複数ある中で制約条件や解くべきお題の方向性によって「どれが仕様書に規定されるソリューションになるか」というのは必ず取捨選択されるものです。ここでしっかり検討しつくされない・不備があり手戻りになるとプロジェクトの効率は悪化の道を辿っていくことになるので、どのようにマネジメントするかはPMとして腕の見せ所となるステップです。基本原則は判断軸を複数設けて、毅然とした態度で（時に政治的な交渉に打ち克ちながら）取捨選択していくで、具体的にはコスト・実現可能性・課題解決のインパクト・戦略整合性などの切り口で判定していくものとされます。

・上記のような資源管理・優先順位付け・スコープ定義などのプロセスはキーとなるプロジェクトメンバーで発散・収束を繰り返しながら行われるものであり、定期的に明文化・可視化して共通認識を揃え続けるPMの執着的な行動が成功のカギになるとされます。後工程の開発マネジメントでの手戻りにならないように、Why・Whatを明確にするための問いを立てて課題設定やゴールイメージをシャープにするということに拘りぬくことがプロジェクトの総生産性を大幅に高めることになります。このステップは非常に精神的に胆力が求められる工程であり、フレームワークを知っているか・場数をこなしているかなどが如実に出る領域とされます。

【所感】

・本書では明確な組織図にない指示命令系統を権限をもたずに遂行する責任と不確実性がプロジェクトマネジメントの大変さの正体とされ、どちらも相応の思考や手順・精神的な胆力が必要とされる点が難しさを助長しているのだろうと感じました。プロジェクトワークを多数行う中で断片的に学んできた知識を再度理論に忠実に理解し直す為に学び直そうと思い、基本に立ち返る意味合いで本書を読みましたが非常に頭が整理されてよかったように思えます。具体的には「プロジェクトメンバーとPMでの守備範囲・関心毎の違い故に起きるコミュニケーションのズレ・断片的なソリューション先行状態をどうマネジメントするか」という判断基準・考え方や「ビジネス戦略・上位組織の目標や利害に叶うようにアウトプット・アウトカムをマネジメントする嗅覚」を忘れないなどが読みながら理解した急所です。

・また本書を読みながらプロジェクトワークはアジャイル開発・UXデザイン・プロダクトマネジメントの理論とフレームワークに通じる内容になっており、相互の関係性・必要性が増すに至った歴史的背景などの解像度が高まりました。この分野に関しては「知っているか」・「やったことがあるか」といった努力の投下が成果に比例する領域であると感じたので、引き続き探究・探索することと小さくとも実践していくことを欠かさないようにしたいと思った次第です。

以上となります！