Editor's Notes 今後の振り返りのため、プロジェクトマネージャーについての考察（2011 年版）をまとめます。 5～50 名規模程度のプロジェクトを想定した内容です。 # それ以上は経験がないので分かりません。 言うまでもなく非定型業務。スコープ管理、リスク管理、チームビルディング、 etc は手段。 お客様、経営層からデフォルト値として与えられたゴールは幻想。ゴールはプロジェクトマネージャーが「いい感じ」に定義して、関係者と合意（最初は緩く！）する。 断続的なイベントドリブン（ = ハメ技から抜けられない）状態に陥ると「何とか」できなくなる。 このイベントドリブン状態を好む人（ = プロジェクト X 見すぎ）がしばしば存在し、そのようなプロジェクトが「頑張っている」と評価されたりするのは困ったもの。 品質の高い部品でも、集めて系になると！？ 優秀なエンジニアでも、チームになると！？ 大きくなると、クールな状態の維持が難しくなることを示唆する経験則なり法則なり。経験上、開発チームが大きくなるとロクなことはない。 プロジェクトマネージャーは小さな開発規模、チームで実現するストーリー展開への誘導に死力を尽くすべき。 # 死力を尽くしてなお、スケジュール圧力故に要員追加することになるのだから。 「総合力」では身も蓋もないので、特に「コミュニケーションにどれだけのコストと工夫を払えるか」に着目。 e.g. これは言わなくても分かっているだろう -> 分かってない e.g. 伝わっているはず -> 伝わっていない e.g. 指示ではなく、思いついた案を言っただけだ -> 受け手にとっては指示 e.g. 人の話を自分のフレームワークで聞く -> 分かったつもりで真意を汲み取れてない また、自らのストーリーに落とし込むための先手、準備も技術面の知識、カンを欠いては的を射ない。 あと幾つか重要視したいポイントについて。 プロジェクトマネージャーの注意点 - 自身の目的理解不足 - e.g. 会社に強制される ISO 等の施策 - 目的を伝えていない、足りない - 目的の伝え方が悪い（ = 誤認識を生んでいる） エンジニアの注意点 - 部分最適、クールなコードへの誘惑 - 何で詳細設計書を書いているの？ - e.g. 設計目的？レビュー目的？保守目的？ 指標を用いた定量化の意義 - ステークホルダーとの会話、交渉ツール - メンバーが概況を共有する - レビューのための参考情報（あくまで参考） ※ 指標と定量化への執着は罠。要注意！ 課題を出して、二、三日後にプレゼンしてもらいます。 これが採用試験であることを理解すれば、PMBOK 等からの転載や、意図不明な回答は出てこなでしょう。 受験者がアピールしたい経験を流用したストーリー組立を期待。ついでにユーモア精神も計測できます。 私が採用者ならば、ここまでに列挙したポイントをチェックします。例えば 目的を明示できない手段（取り組み）を述べてた場合は減点対象です（恐らくは、経験として身についているものでもないはず）。 オマージュです。 来年もまたまとめてみます。
