オライリーから出版されている「アート・オブ・プロジェクトマネジメント」という本を読んだ。
マイクロソフトでのプロダクトマネージャ経験をもつ著者によってSEと比べあまりフォーカスされることのないPMという世界でうまくやっていくTIPSを紹介している。日本発のPM本はなんだろう、とりあえずガントチャート引いとけ的な要素が多くて、管理管理しているので違和感を感じていたが、この本でのメンバーとの折衝、モチベーションに関するいくつかの法則などはプログラミングの世界に限らず有効であると思った。ただ、すでに現場で成果をバリバリ挙げている人にとってはすでに経験的に学ばれている点も多いのかもしれない。
著作でのいくつかの気になるポイントを挙げるとすれば
- プロジェクト後半でのバグ、残課題事項のトリアージ
- 末期での少数人へのエンフォースメントによる集中課題解決チームの創設
- バグの発生数、解決数、の推移データの共有
という点ですかね。
とくにバグのトリアージについては、きっと各々の方面でいろいろなツール、たとえばExcelとかAccessとかサイボウズデジエとか、或いは自社で製造した専門のWEBアプリかVBアプリとかでやっていると思うのですが実際にはオープンソースウェアの開発管理に利用されているtrac(ウェブアプリケーション)による管理がカスタマイズ性の観点から便利。
全然関係ないですが、この本の後半のほうに、いわゆる日本の「根回し」を図解でどのように進めるか図面で解説している箇所があって、なんだか思わずニヤリとしてしまいました。
誰が読むべきなのか
むしろこの本を推奨するとなると、プログラムの品質はどのタイミングでどのように確保されていくのか学ぶという点で、PM層よりかは、PG層やTester層に推奨されるものなのかもしれない、とも思う。
