アート・オブ・プロジェクトマネジメント (その一) / Scott Berkun

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 Scott Berkun 村上 雅章 オライリー・ジャパン 2006-09-07 売り上げランキング : 2838 おすすめ平均 Amazonで詳しく見る by G-Tools

というわけで、「アート・オブ・プロジェクトマネジメント」。マイクロソフトでInternet Explorerの開発に携わった筆者が、プロジェクトマネジメントはどのようにあるべきかを書き記した本なんですけど、本当に色々と示唆に富んでいるので、ザッと読んだ自分としてはこのまま紹介するのももったいない。

ところがですよ、この本については「わたしが知らないスゴ本は、きっとあなたが読んでいる」さんのところで詳細なレビュー(なんと10回にわたって！）がされているじゃないですか。もう自分が何を書けというのやら。

しかし、そんなことに臆していたらちっとも始まらない。というわけで「Babylon C@fe」始まって以来の新チャレンジ、一冊の本を何回かに渡って紹介していこう。というわけで、蛮勇を奮って自分もこの大変示唆に富む本について、自分の立場から見て感じたことを書いていこうかと。

ちなみに、自分が携わるプロジェクトとは基本的に極々小規模、もしくはこの本でいうところのスーパーマン(一人)で行う規模ぐらいですが、場合によってはシステムを作る一方、非プログラマたちを使って必要なものを作り上げるといったことも行う何でも屋でもあります。まぁ、そういった観点で言えばPM(プロジェクト・マネージャー)じみたものもやってると言えなくもないかもしれません。

しかし、そういう立場の自分からして見てもこの本は宝の山です。どうしてか、それは第一章「プロジェクトマネジメントの簡単な歴史」にある図の脚注として書かれている言葉を引用してみればおのずと見えてきます。

「多くの分野(図は、映画、ソフトウェア開発、ウェブ開発、緊急治療室、厨房の各作業プロセス)におけるプロセスは、概念的に似通っています。つまり、すべて時間軸に沿って、計画、実践、洗練となっているのです」(P9)

何であれ、ある種の創造的(クリエィティブ)な作業を行うものについては、すべて「計画、実践、洗練」といったプロセスを経ているわけです。

その中で、わけてもPMに必要なリーダーシップとマネージメントには、エゴ/非エゴ、独裁/移譲、勇気/恐れ、曖昧さの許容/完全性の追及という相反する要素に対する理解と洞察が必要だと筆者は書いています。

これは自分にもわかることで、仕様を確定するときにある程度、曖昧なものがあると知りながらスタートする場合もあるし、作業後半ではその仕様ルールの徹底が必要なときがあります。それに当てはまるなぁと深く納得してしまいました。あと「独裁/移譲」に関してはここ最近、かなり頭を悩ませている問題なのですが、これはおって・・・。

第二章「スケジュールの真実」では、スケジュールの組み立てに関して述べられていますが、ここも正直自分にとって納得というか、非常に頭の痛い指摘がありました。まぁ、具体的に書くと色々差し障りがあるのですが、「スケジュールに関する1/3の法則」(P31)は自分のような素人には示唆に富んでいました、と書かせてください(汗。
また、ソフトウェア開発に対してウォーターフォールやエクストリームプログラミング(XP)などの方法論は方法論にすぎないのだ、というくだりは、確かにまったくもって。という感想です。時々技術者はその方法やソフトや言語などについて信仰に近いものを得て唱えてしまう側面があるかと思います(大体にして、そういう方法論の先駆者をグルと呼称するあたりが、それをカンジさせますね)。自分の心情は「信頼してもいい、信用してもいいが、信仰はするな」ですが、筆者のこのへんのくだりはまったく納得してしまいました。

スケジュール同様頭を悩ませる「見積もり」についても、この章ではページを割かれています。個人的に感銘を受けたのは、見積もりに対して消極的なプログラマに対する問いかけ、「君が自信をもって見積もりを出せるようになるには、私はどのような質問に答えたらいいんだ？」(P40)ですね。確かにこう聞かれたら、能動的に問題に大してアプローチしないといけなくなりますね。

第三章「やるべきことを洗い出す」はソフトウェア・プロジェクトの様々なタイプを説明したあとに、どのような視点、立場から、プロジェクトに対する洞察を行わなければならないか、についての説明です。ここはもう説明しようがないぐらい示唆に富んでいます。独立系の一人、あるいは数人によるWebデザインに携わっている方も、是非ここは読んで見てもいいんじゃないかと思いますね。
筆者の書く、「ビジネス」「技術」「顧客」という視点から、やるべきことを洗い出す、という詳細は、興味をもたれた方が実際に読んでいただくとして、自分の立場で言えば、どうしても少人数で作っていると偏りが出てしまいます。「どうあるべきか」が「こうあるべきだ」と考えてしまう場合もありました。それはインターフェイス周りのところもあれば、システムの"内部"での振舞いもそうかもしれません。酷いときにはシステムの成り立ちからしてそうなってしまう場合もあります。それが哲学(フィロソフィ)から来ているのならまだしも、水が低きに流れるように、作り手側にとって楽なほうへ流れていることを自己欺瞞してしまうケースも少なからずあるわけです。無論、逆のケースもあります。顧客の要望ばかりを聞き入れたはいいが、それは特定の顧客に対してのみ有効なものであったためにビジネスとして効果的ではなかった(つまり、他の顧客に対して優位を発揮することができなかった)というのもありがちなケースです。
筆者はこういう三者の視点を重ねて、さらに超越した視点をもつように書いています。また「正しい疑問」(P66)を持てとも書きます。このリストは、自分も付箋をはって考えようと思いましたね。

余談ですが、P58のくだりとその脚注は筆者のユニークさが出ていてクスリと笑ってしまいましたよ(w


というわけで、長い長い読書感想文でした。また続きますよ、ええもう。先は長いですがね(w