WBSとガントチャート - torutkのブログ で買った書籍を読み始めました。
書籍の内容は、海外企業と提携することになった日本企業の若手設計技術者が大学の先輩でプロジェクトマネジメント技術者に教えを乞うという形態でプロジェクトマネジメントを教える本。会話調で進むので読みやすいです。
- プロジェクトのチームは「その場限りの組織」、通常の意味での”PDCA Cycle"が成り立たない。（仕事の繰り返しの中で改善していく）
- プロジェクトは繰り返しがないので、結果を確実に予測できない
→「PDCA Cycleが成り立たない」は、衝撃的でしたが、言われてみると腑に落ちます。反省は次のプロジェクトに生かすしかないんですね。ただ、頭数だけ集めて終わったら即解散というプロジェクト体制では厳しいですね。
うまくアジャイルを取り入れて、繰り返しをプロジェクトの工程に組み込むのがいいと考えているのですが、仕事のやり方を「改革」することになるので抵抗が大きいです。抵抗の最大根拠は契約（客先との契約だけでなく、協力会社との契約も含めて）でしょうか。
- マネージメントとリーダーシップの違い
小規模で、スコープの自由度が高ければリーダーシップで頑張ってプロジェクトを成功に持っていけるが、スコープの自由度が低いとリーダーシップではうまくいかず、マネージメントが必要となるので、プロジェクトの性質によってやり方がことなるとあります。なるほど、確かにと頷きました。
- 納期までに要求する品質・仕様で完成し予算内におさまったが、ほとんど使われなかったシステムは、成功プロジェクトと言えるのか？
プロジェクトの利害関係者（ステークスホルダー）が自分の期待に照らし合わせてプロジェクトの成否を言うので、最初に「何がプロジェクトの成功なのか？」を明確にし、ステークスホルダーの間で共有すること（しつこく）が大切とありました。
- プロジェクトの出発にあたり、その目的・ゴール・方法などを宣言する文書を、英語でプロジェクトチャーター（Project Charter）と呼ぶ
「プロジェクト憲章」というのが作られたプロジェクトに参加したことがあり、存在は知っていましたが、大事だったのですね。
WBSの分解の仕方には、成果物（構成）によるものと、工程によるものとがあり、PMの世界でも議論になっている（結論が出ていない）と認識していましたが、「両立」ですか・・・。これは大変です。
真面目にやると、プロセスフローダイアグラム（PFD）を書いて作業と成果物を頭から終わりまで定義するのがよいと思っていますが、これはシステム開発にあたり、システム開発をする開発システムを開発するかの如くでとっても大変・・・。
- WBSのまとめ方、縦方向（設計、実装、テスト）はプロセス中心の組織、横方向（Aモジュール、Bモジュール、）は成果物中心の組織。正解はなく、どうマネージしたいかで決まる。
- タスクフォース型組織／プロジェクト型組織のデメリットは技術力の蓄積が図りにくい、会社全体として業務プロセスを改善しにくい。IT業界の受託開発中心（SIer）、建設会社などに多い形態。
なるほど、技術力の蓄積がないのはこのプロジェクト型組織だからかも。
