プロジェクト・マネジャーの仕事の範囲というのは、本来はどこかで決まってそうですが、実際には組織ごと、プロジェクトごとに、その守備範囲はことなっている印象があります。今の職場でのプロジェクト・マネジャーと、前の職場でのプロジェクト・マネジャーの具体的な仕事の内容は、けっこう違います。なので、そんなことも範疇に含まれるのか、と思うこともありつつ。
最近の個人的な課題は、変更をいかにコントロールするか、です。その視点から見た感想として気になった箇所をふたつ紹介します。
完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。現実には、ソフトウェアプロジェクトのライフサイクルのいかなる時点においても、要求が完全にわかることはありません。分析フェーズ、開発フェーズ、保守フェーズ、システムがレガシーであるときですらそうなのです。
（デイビッド・ウッド 完全な知識という誤った考え）
これはなかなかに凹む意見ですが、実際問題としてそういうことなのでしょう。矛盾だらけの要件リストで開発を始めたりしませんが、形式的な手法を用いたりしない限り、無矛盾な要件は得るのは至難の業だと思います。
とくに性能要件があるときです。性能は、多くの場合、インフラやアーキテクチャに大きく依存し、その実現可能性は使えるコストにも依存します。場合によっては、使えるコストというが性能に依存することもあります（100万ユーザを捌けるなら金を出す、など）。ってなわけで、依存関係がループします。
とういわけで、全ての条件が明確ではなくても、どこかから始めなければいけません。
経験豊富なプロジェクト・マネジャーであれば、「高、中、低」というフィーチャーの分類をしません。顧客は何もかも「高」にしてしまうおそれがあるためです。彼らはビジネス価値に基づいたフィーチャーの優先順位リストを好んで使います。すぐれたプロジェクト・マネジャーはビジネスオーナーに対して「遅れが発生した場合に、優先順位リストの下の方にあにあるフィーチャーは、このリリースでは実現できないかもしれません」とくぎを刺します。こうしたやり方は、ビジネスオーナー、特にフィーチャー同士の衝突について学んでこなかった人にとって、苛立ちの原因となるでしょう。ですが時間がたてば彼らもこうしたプロセスに慣れて、プロジェクトの現実として受け入れるようになります。
（ジョー・ゼネビッチ 約束以上にすべきか、約束以下にすべきか）
まあ間違いなく「高」ってつけられます。ABC を使っていると、いつのまにか A+ とか S とかついてます。何かを優先する、ということは、別の何かを優先しないということです。発注側が「全部大事」といって押し込んだとき、受注側は見えないところで手を抜かざるを得なくなります。それは多くの場合、品質やパフォーマンスだったりすることでしょう。
いまだにプロジェクトの中での優先順位付けを、ステークホルダ間で共有する方法というのは持っていません。ゼネビッチが書いているように、理解できない人にとっては苛立ちの原因になりますし、状況によっては単純に受け入れらません。がっかりな話ですが、まあ、そんなもんです。
絶対うまくいく法則というのはないのですが、できるだけ相手に分かる指標に変換するように心がけています。「これもやってほしい」「はい、できます。+1週間です。」というような会話です。+100万円でも、同時アクセスできるユーザ数20%減、でもなんでもいいんですけど。
この本を読んで、正解を見つけるのは大変・不可能かも知れませんが、飲み屋で先輩や同僚の話を聞く、の効率良い版だとコストパフォーマンスはよいと思います。
