Manage It! 現場開発者のための達人式プロジェクトマネジメント

Manage It! 現場開発者のための達人式プロジェクトマネジメント

プロジェクトマネジメントに関する良書。正直言うとアート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)のほうがいいとは思うが、それと比べるとTipsやハウツーが豊富というかテクニカルな印象がある。
なかなか示唆に富むというかニヤリとするような箇所もある。たとえば以下のような感じ。

• p113 90%完了

どのケースでも、チームメンバー自身は作業の90%が完了したと思い込んでいるが、実際には終わらせなければならない作業があと90%残っている。これが「90%完了」のスケジュールゲームだ

あー、あるある。。。

• p120 PowerPointアーキテクトにご用心

彼はさっと舞い降りてきて、PowerPointによるアーキテクチャ図という糞をどっさり放出すると、すぐに去っていった。

これは見たことないな。

• p134 チームメンバーの選択について裁量権がない

うまくやれていない人がいたらチームから外せることがプロジェクトマネージャには必要だ。それができないなら代替策を検討しよう。あなたが別のプロジェクトに移るとか、その組織から出ることを考えたほうがいいかもしれない。

これができる人はあまりいないんじゃないかと思うが。。。

• p175 こんな会議はキャンセルする

結局、たいして聞く話もないし自分が貢献することもない会議の末席に連なっていたって、自分の職務を果たしていないだけだ。

確かに。

• p223 多地点にわたるプロジェクトのマネジメント

メンバーたちの間の距離が30メートル以上あるプロジェクトは、すべて地理的に分散したプロジェクトである

確かに。

• p235 タイムゾーンがチームの進捗に及ぼす影響を認識する

マルチサイトチームの黎明期には次のように考えるマネージャが大勢いた。「私のチームはグローバルに展開して作業している。プロジェクトが24時間前進してるってことだ」甘い話はない。世界中に展開するチームで進捗できるのは、イノベーションを起こすつもりがなく、開発コストを気にしないプロジェクトだけだ。

上記を読んで若い時にプログラムを書こう、必ず人生の豊かさにつながる（2ページ目） | 日経 xTECH（クロステック）を思い出した。。。

• p238 アウトソースのミスを避ける

実を言うと、このセクションは「アウトソースを成功させる方法」というタイトルにしたかった。しかし、そうするわけにはいかない。これまで筆者はアウトソースしたプロジェクトで本当に成功を収めたとは言えないからだ。

やっぱ難しいよね。

• p254 スタッフの能力とテスターの比率

生産性は必ずしも経験に比例しない。優秀な開発者とテスターは年長者とは限らず、経験年数が長いとも限らない。生産性は自己鍛錬と理解力による部分が多く、解決策のドメインに精通していることも重要だ。スタッフの能力にはかなり幅がある。

だよねー。

あわせて読みたい

逐次的な進捗会議こそ悪であり、プロジェクトを衰退させていると言い切れる - Fight the Future

入社３〜１０年目くらいのエンジニアが読むといい本

これまでいろいろとIT関連本を読んできたのですが、そろそろ題記の観点でまとめというか整理したいと思います。

エンジニアがタイトル買い、著者買いすべき本 - Fight the Futureとかぶっているものもありますが、まあ参考になれば。

僕もそうなのですが学生時代にプログラミングをあまりやったことがなくても入社３〜１０年目くらいになれば役職はともかく役割としてはサブリーダ、リーダ、PMになっていることがおおいものです。

そういった人たちが読むといいんじゃないかとおもわれる本を挙げてみます。特定の言語に関するものやネットワーク、DBといったインフラ関連は除いています。

エッセイ、読み物系

Joel on Software

More Joel on Software

ハッカーと画家 コンピュータ時代の創造者たち

闘うプログラマー[新装版]

レボリューション・イン・ザ・バレー ―開発者が語るMacintosh誕生の舞台裏

Joelはやはり外せない。とくに「More Joel on Software」はすばらしい。
『はじめてのBillGレビューのこと』を読んでプログラムマネージャになりたいと思った人は多いだろう。僕もそうだ。
『Javaスクールの危険』もいい。このなかで「ハッカーと画家」の『普通のやつらの上を行け』が紹介されている。
監訳者あとがきにあるようにこれを読んでLisp処理系を起動してみたプログラマは多いだろう。僕もそうだ。
「闘うプログラマー」はとにかく熱い本だ。モチベーションが上がる。「レボリューション・イン・ザ・バレー」もいい。ジョブズの現実歪曲空間に巻き込まれたら大変だろうけど（笑）。

開発系

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

CODE COMPLETE 第2版 下 完全なプログラミングを目指して

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

レガシーコード改善ガイド (Object Oriented SELECTION)

「Code Complete」は長いし正直にいって途中退屈な箇所もある。それでも開発に関わるなら読むべきだろう。

Martin Fowlerも薦めている。

もっと具体的なアドバイスをすると ――プログラミング スタイルに関する良書を読むといいだろう。まず『Code Complete』は読んどくべきだ。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CodeAsDocumentation

「アート・オブ・アジャイル デベロップメント 」はアジャイル開発について述べられた良書。これも読むといい。もっとさらっと読みたいならアジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣がいいだろう。達人プログラマー―システム開発の職人から名匠への道もいいがこの本のほうが現代的な気がする。

「レガシーコード改善ガイド」はレガシーコードに対してどう取り組むかが書かれている。技術書というのはたいてい賞味期限が短いものだが、今後レガシーコードに取り組むことはますます増えるだろうことを考えると、この本の賞味期限はかなり長くなるだろう。
ただこの本を読むためにはリファクタリングやデザインパターンの知識が必要になってくる。言語はJavaに特化してしまうが、リファクタリングといえばリファクタリング―プログラムの体質改善テクニック (Object Technology Series)だろう。新しいものが良ければJava言語で学ぶリファクタリング入門になるだろう。

デザインパターンは増補改訂版Java言語で学ぶデザインパターン入門でいいだろう。がんばって原典であるオブジェクト指向における再利用のためのデザインパターンに挑戦してもいいが。
蛇足だが、増補改訂版Java言語で学ぶデザインパターン入門の姉妹本ともいうべき増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編はJavaのスレッドを学ぶのに本当にいい本だと思う。Swingのイベントディスパッチスレッドにも触れられているし。この本が理解できたら入手困難だがJava並行処理プログラミング ―その「基盤」と「最新API」を究める―に挑戦だろう。良いプログラマを目指すなら「Java並行処理プログラミング」は今すぐ読むべき - higepon blogでも薦められている。

アーキテクチャ

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

難しいけど読む価値はあると思う。ドメインモデルとトランザクションスクリプトの違いの説明はわかりやすい。

ただ若干残念なのはXPエクストリーム・プログラミング入門―変化を受け入れるもそうなんだが、僕はこの本の訳者とあまり相性が良くない気がする。なんかスムーズに文章が頭に入ってこない。

プロジェクトマネジメント系

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

Joelも薦めていた本。Manage It! 現場開発者のための達人式プロジェクトマネジメントと違って具体的なTipsがあるわけじゃない。それよりも人間系の問題にどう取り組むかということに重点が置かれている。まあそれが一番大事ですよね。よくも悪くもコンピュータから離れるほど単価が高くなるという現実もあるし。

見積もり、計画系

ソフトウェア見積り

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

この２冊で決まり！　異論は、、、たぶん無いでしょｗ

運用、保守

Release It! 本番用ソフトウェア製品の設計とデプロイのために

一言で言うと味がある。これを読むと不特定多数を相手にした商用サイトの構築がいかにタフなのかがわかる。