すごくよかった。品質曲線の下りはまさにで顧客と何度も対話しないと不和が生まれ、そのまま推進すると失敗確定のプロジェクトになってしまい誰も幸せにならない。今の業務とも近い領域なので考え方を取り入れたり実務で落とし込んでいきたい。
章立て
- 第１章 プロジェクトマネジメントの優先順位
- 第２章 品質曲線
- 第３章 PMBOKのポイント
- 第４章 PMがITプロジェクト全体で考慮すべき事項
- 第５章 SEとして重要なシステムデザインの視点
- 第６章 プロジェクト計画の策定
- 第７章 要件定義フェーズでのプロジェクトマネジメントの要諦
- 第８章 設計・開発フェーズでのプロジェクトマネジメントの要諦
- 第９章 検証フェーズでのプロジェクトマネジメントの要諦
- 第１０章 移行でのプロジェクトマネジメントの要諦
- 第１１章 PMの心得
- 第１２章 ソフトウェアエンジニアリングの今後と対応
メモ
- 品質＝顧客満足度
- 機能性・信頼性・信用性・効率性・保守性・移植性の6つの特性からなると定義されている
- 求められる品質は可能限り具体化することで納品トラブルを回避することができる
- QCDの関係
- 品質>納期
- 納期＝コスト
- 品質>納期=コスト
- 品質曲線
- 要件定義フェーズにピークを迎え、設計・開発~検証・リリースの間はアップダウンする
- 品質調整のキモは実現可能性とコスト・納期の調整
- 要件定義時点で無理はないか、後出し事項はないか、オーバースペックではないか、そもそもの目的と合致した要件になっているかなど
- 納期についても法的な対応やトラブル発生時の方針と代替策を立てておかないと遅延や納期遵守のための追加コストが発生してしまう
- コツは小さく産んで大きく育てる
- 最初は必要最低限に絞り、徐々に機能追加していく
- 目標品質と顧客の要求品質（期待値）はイコールではない
- 要求通りのものを納品しても満足度はそこまで高くない
- 期待値を超えることで初めて満足する
- 想定より使いやすい、見やすい、プロセスがすごく丁寧など
品質中心で見た要件定義フェーズ
最大限顧客の要求品質を反映させた上で、実際に提供できる機能を、想定の製造品質で、予定の期限が守られる前提で、『提供可能な機能品質』を定義すること
- 顧客の要求事項の把握が不十分だと要件定義フェーズ時点で品質が下がり（この時点で顧客とズレ）、不和を抱えたままリリースを迎えることになる。結果、顧客満足度は下がり、最悪プロジェクトの延長や自社のブランド毀損につながる
- PMBOKではプロジェクトは独自性・有期性・特異性があると定義している
- 有期性は期限ありということなのでまあそうだよねという感じ
- 独自性と特異性は曲者で案件毎に状況や求められる成果物がことなるため、再現性や標準化が難しいという点があげられる
- なので過去のプロジェクトの成功体験をそのまま別案件で使えないということはままあるので注意
- 応用するならローカライズが必要
- ネットワーク図ではクリティカルパスがどこにあるのかを意識する
- ボトルネックになりがちだから
- PM自身がボトルネックにならないよう注意する
- PMはプロジェクトメンバー及び顧客全員と信頼関係を作らなければならない
- そのため誠実さ、顧客思考、専門性、スキル、マネジメント力、リーダーシップが求められる
- 世の中にこれらすべてを兼ね備えているPMはどのくらいいるのだろうか、、
プロジェクト・コミュニケーション・マネジメント
プロジェクト情報の生成、収集、配布、保管、検索、最終的な破棄を、適宜、適切、かつ、確実に行うために必要なプロセスと活動
- リスクマネジメントのコツはリスクが小さいうちにかたづけること
- もちろん防止策の徹底とアラートが上がりやすく、検知できる仕組みも重要
- 体制図、サブスケジュール、サブシステム構成図は三種の神器
- 軽視されがちだが、プロエクトのできる範囲を標準化することで最低品質を守ることができる
- 使えるツールはどんどん使い自動化する。空いたリソースは品質向上や創造的業務に投下する
- プロの基本
- 基本に忠実
- 逃げない
- 愛情
- 一歩先を行くマネジメントスタイルの確立
- 検証力を鍛える
- 必要条件ではなく必要十分条件で考える
- 網羅性を意識しすぎた結果、無駄なタスクの紛れ込みはないか
- あとでもよいタスクはないか
