20211205読了。 プロジェクトマネージャーがなすべきことについて書かれた本。計画、スキル、マネジメントについて。 ボリュームがあって読むのに苦労するが、各章のまとめを読めば概要は分かる。 以下、個人的なメモ ・プロジェクトマネージャーはプロセスではなくチームに注力すべき。いい仕事をしよう。 ・優先順位によって物事が成し遂げられる。ノーというのがプロマネの仕事。 ・スケジュールは見積りによって作られる。見積は確率。よってスケジュールも確率。

20191027 マイクロソフトでブラウザ戦争時代のIEのプロジェクトマネージャーを務めていた経験をもとにした実践的なPM論 ・PMにはバランスが求められる。PMの使命はプロジェクトを成功させることであり、さまざまな状況において適切な態度を求められるから。独裁と委譲、曖昧さの許容と安全性の追及、複雑さの容認と簡潔さの支持、勇気と恐れはPMが主に直面するジレンマ ・スケジュールは下記の役割をもっており、その効果が発揮されるように作るべき -いつまでに誰が何を完了させるのかを約束させる -依存関係から成果物の想定読者を明らかにし協調を促進する -進捗を管理できるようになる ・ソフトウェア開発のプロセスはいろいろあるが、工程は、設計、プログラミング、テストの３つにわけられる ・プロジェクトにおける主な作成物は下記4つ 市場要求ドキュメント:市場分析とプロジェクトがその機会をどう利用できるか ビジョンスコープのドキュメント:プロジェクトの存在目的と目標、高レベルの機能と要求 仕様書:技術的な実現方法を定義 WBS:タスクの一覧 ・プロジェクトの検討においては、ユーザー、ビジネス、テクノロジーの3つの観点が必要 ・目的にむけた手段の検討にはアイディアが求められる。アイディアには発散と収束があり、それぞれアイディアの洗いだしと選択肢の評価というタスクに相当する ・仕様書の目的は、設計を忘れないための記録と他の人に伝えるコミュニケーションであり、レビューとフィードバックを可能にするもの。副次的には進捗管理のためのマイルストーンともなる。 ・仕様書には要求仕様、機能仕様、技術仕様がある。仕様書は設計が完了したのちのドキュメンテーションとして捉えるべきでそうしないと非効率な設計となり、不明瞭な仕様書となる。 要求仕様:実現方法に言及しないプロジェクトの成功の条件。ビジョンとスコープのドキュメント。実現したいシナリオ 機能仕様:特定のシナリオにおける挙動の定義であり、画面要素定義と挙動パターン 技術仕様:機能仕様を満足させるエンジニアリングアプローチ、テックのコンフルでシステム配置・参照API・参照DB。機能仕様から自明である場合合わせてもよいが、混同はせずどうコーディングすればよいのかに直接答えるドキュメントは必要 ・意思決定においては、何を意思決定すべきかのメタ意思決定が重要。重要な意思決定においては、Procon評価が強力 ・コミュニケーションはPMの全て。特にWBS、組織図、スケジュール、プロセスによる役割の定義が重要で、PMがそう役割定義すれば作成物を一切作らなくてもよい ・最も効果的なコミュニケーションは双方向の対話であり一方的な命令は悪手。コミュニケーションのステップは大きく5つあり想像以上に長く高い、発信→受信→理解→合意→有益な行動 ・プロセスは有用だが人を不快にさせる可能性がある、ローカライゼーションが重要。 ・難題は必ず発生する。気を落ち着けてタスクをブレークダウンし、毅然と責任をとるのが最善 ・信頼は有言実行によって生み出され、それによって獲得した力は付与された力よりも強力 ・ビジョンの一覧、機能の一覧、作業項目の一覧は紐づけられ優先順位がついているべき。機能削減などの調整が容易に行えるため ・政治とは分配をめぐる争いであり現実に存在するもの。プロジェクトの目的に照らし必要ならば影響力の関係を見極めアプローチすべき