プロジェクト管理 その１

　今まではプレイヤーとして業務に取り組んできましたが、そろそろマネージメント業務も任されるようになりました。ということで３冊プロジェクト管理の本を読んでみました。

　まずは１冊目「ソフトウェアプロジェクト管理」から。ここでは本の概要とそこでの要点をメモ書きで読み進めながら追記していきます。

知識ゼロから学ぶソフトウェアプロジェクト管理

１章　まえがき

1-1 本書のゴール

　まずPMBOKの悪口を言っているところに好感がもてます。そもそもPMBOKのような教科書的な机上の知識だけで解決できるなら誰も苦労しない...。

• ソフトウェア開発プロジェクトは、ロラブルの連続・仕様変更の連続・バグの連続。基本的にうまくいかない。
• 週４０時間労働で完遂できるように計画・実行させるのが優秀なPM。
• 「忙しいから業務改善ができない」という「忙しさのループ」に罹らないようにすること。

２章

2-4 まとめ

• 失敗するソフトウェアプロジェクトではプロジェクト進行中に屍臭が漂う。PMは屍臭が漂ったら即座に対処すること

３章　人がすべて

チームのメンバを増やせば増やすほど、開発に関係のない人の割合＆コミュニケーションコストが増大するというのは、自分の会社を見ていると肌感覚的に理解できる...

• 少人数でコミュニケーションロスを少なくし、個々の生産性を上げるのが最も効率的な開発。

４章

たしかに周りを見ていても「技術的課題」で詰まっているPJよりも、顧客の要求が決まらないでおくれているPJの方が圧倒的に多い。

• ソフトウェア開発における最大のコストは「要求仕様の間違え・抜け」。だから「すごい要求や抜けのない要求を書ける人」がプロジェクトを進める上での真の功労者。
• 要求仕様を厳密に落とし込むのが一番難しく、PJを進めていく上で要求抜けや要求間違えが発見されると想定して、修正コストを見積もっておく。
• 要求仕様を落とし込む場合は、テスト可能な粒度に落とし込むこと。
• 非機能要求（品質特性）を完璧に網羅し、要求仕様に完全に落とし込むのは困難。

結局

PMが打てる手立ては以下で回避するのが良いかもしれない。

• 仕様変更が不可避である以上「優先順位をつけてもめそうな機能から実装していく」のが現実的な対応策。
• 変更が避けられないなら、開発手法の変更（ウォーターフォール→アジャイル）もありうるが、要求仕様の変更が大きな困難さを伴うのは同じ。
• そもそも最初から必要期間や人員を過大に伝える。「トラブルがゼロならば理論上すすめられる人員・期間」というのは必ず破綻する。
• スケジュールの議論は定性的な議論でなく定量的な議論に落とし込むこと。具体的な数値とデータを上げて相手に説明することが必要。

５章

• 品質特性を満たしていないことが下流のシステムテスト段階で発覚すると、確実にデスマーチ化する。
• そのため非機能要件には上流から下流まで特別扱いすること。
• とりあえず機密性（security）・信頼性（reliability：耐障害性）・パフォーマンス（性能）の３点はしっかり考えておく。