を、読みました。

最近ようやくPMという略語も定着してきたようにも思います。この本はIT系の開発プロジェクトをいかに管理・進行していくかのマネジメント業務の教科書。けれどそれはあらゆる業務に対する一つのメタファーとして、あるいは言葉そのままに、活用できます。

ぼくの所属する経理室でも今かなり大がかりなIT化のプロジェクトが進行していて、システム屋さんと話をすることも多いのですが、この本を読むとユーザの立場で接する時とは違って、彼らが普段どのような思想で仕事を進めているのかがかいま見られるのはとても興味深いし、考え方として有益なものはどんどん取り入れていきたいと思わせる。

基本的に開発業務というのは

1.ユーザの要望ヒアリング
2.開発要件の定義・工数見積もり
3.開発作業
4.ユーザによるテスト
5.ユーザによる承認（あるいは細部の改変）
6.リリース

という手順を取ります。この本では2にあたる部分──外部設計書・要件定義書・仕様決定書などと言われている開発前にユーザに対して「この仕様で開発しちゃうけどいいよね」という内容を書いた文書──の書き方に始まって、実際の開発作業の中でいかにプログラマに気持ちよく仕事をしてもらうかといったところにまでかなり言葉を尽くして語られています。

さすがにシステム屋の著書だからなのか英語からの翻訳だからなのか文章が構造的・理論的・簡潔で、非常に読みやすい。

あらゆる業務を個々のプロジェクトとして捉えたとき、自らはプロジェクトマネジャーとなるわけです。そうするとさっきの進行表はこんな風になる（番号は対応してないけど）。

1.問題発生
2.現状把握→文書化→関係者に認知
3.解決策の定義（利害関係の調整）
4.いざ実行（人にやってもらうことが多いので進捗確認も）
5.問題が解決したかの検証
6.場合によっては飲み会

ルーティン業務はさておいて、予算策定や日々出来する個々の問題も全て上のひな形に当てはめることができると思います。その時、この本で語られる様々なTipsは本当に役立つと思う。

懸案事項の効果的なマネジメントは、純粋にやる気の問題となります。誰かが問題になりそうな物事を調査し、それを文書化するために時間を割かなければならないのです。ここには何の仕掛けもありません。いったん文書化されれば、優先順位をつけ、誰かに割り当て、解決することができるのです。

ことプロジェクトマネジメントに関して言えば、人が意志決定に失敗する原因は多くの場合、その意志の薄弱さや経験不足にあるのではなく、行うべき様々な意志決定にかける労力が不十分であったことに起因するのです。

精度の高い数値（例えば作業工数が5.273日）が提示されたからといって、それが大まかな数値（4～5日）よりも正確であるとは言えません。

などなど。

特に8,9,10,11章はコミュニケーションスキルについて詳説されていて、そういうのを聞くと鼻白む人も多いとは思うのですが、そしてぼく自身そういう類の人間だとは思っていたのですが、「傲慢にならずに耳を傾けろ」と著者に示唆されます。むしろ傲慢になりやすい人に対してこの本は書かれているように思います。

メールの書き方や会議の開き方など業務の中でも当たり前すぎて人に教わることのないことも改めて「こうするといいよ」と教えてくれる機会なかなか貴重なのでは。今一度、新入社員に戻った気持ちでマネジメント（ここでいうマネジメントは部下の管理ではなくて業務の進捗管理のことね）のいろはを勉強してみたいと思いました。