アートオブプロジェクトマネジメントを読み返している

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

6章の「アイデアを得た後にすること」の6.5「プロトタイプはあなたの友達」から6.7「懸案事項の一覧」までを読んだ。

以下感銘を受けたところを箇条書きにて。

  • 優れた設計を行うには、優れた意思決定を行う必要があり、それには問題と解決策に関する情報をできるだけ多く仕入れておく必要があります
  • これは大工の名言である「まず寸法を測り、もう一度寸法を測り、そして切る」
  • 経験豊富な設計者は、どこから手を付ければ良いのかを本能的に知っています
  • 設計において最も難しい、あるいは最も重要な疑問の一覧を作成し、それらの疑問に対して答えを出せるようなプロトタイプ(複数の場合もあり)を作成する
  • プロトタイピングはトップダウンで行うべきです。つまり、ユーザが目にする部分を彼らが目にすることになる順に従って作成していきます
  • 可能なかぎり早い段階で、ユーザビリティの専門家や設計の専門家を巻き込むべきです。画面が作成されない限り、データベースやXMLスキーマに時間を費やす必要はありません
  • プロトタイピングによって、実装工程を開始する前に、リスクに取り組んだり、行って置く必要のあることを学習するチャンスが得られるわけです
  • プログラマの時間が貴重であると主張するのであれば、彼らの時間は入念に計画した上で使うべきなのです
  • 設計者が、設計プロトタイプの存在なくして複雑な設計上の疑問に自信をもって答えられないのと同様、エンジニアは、エンジニアリングプロトタイプ(彼らがなんと呼ぶかに関係なく)の存在なくして複雑なエンジニアリング上の疑問に自信を持って答えられません
  • 全員が同じイメージを想い描いていなければ、いくら同意を取り付けたかのようにみえたとしても、その同意はまったく効力を持っていないも同然なのです
  • 設計選択肢の領域が狭まるに従って、プロジェクトマネージャーには、懸案事項の一覧を管理するという新たな責任が課されることになります
  • 懸案事項の一覧は、本質的には疑問の一覧です
  • 聡明なプロジェクトマネージャであれば優先順位に従って懸案事項の一覧を2つに分類しているはずです。つまり、仕様書作成を開始する前までには解決しなければならない懸案事項と、それ以降に解決してもよい懸案事項に分類しているのです

後半に書いたプロジェクトの運用で気をつけなければならないところが特に腹落ちする。

アートオブプロジェクトマネジメントは非常に実践的な意見が詰まっていて面白い。著者の歩んできたプロジェクトマネジメントの歴史を追体験できる。僕はこの本を読んでプロジェクトマネジメントに興味を持ち始めました。

最近勉強熱心なエンジニアと酒を飲みながら話をして感銘を受けたので情報処理技術者試験のプロジェクトマネージャー試験を受けようと思う。