藤井 拓 翻訳
藤井 拓 原著
Joe Marasco 著
本書は、ラショナル社のインターネットコミュニティ誌(E-Zine)であるRational EdgeのFranklin's Kite(フランクリンの凧)と言うコラムに2000年から2002年にかけて20以上の投稿した記事を中心に編集したものである。記事はプロジェクト開発のマネジャー向けで、プロジェクト開発やソフトウェア開発チームを待ち受ける落とし穴の回避に役立つ内容である。コンピュータ科学の専門家、問題を抱えているプロジェクトマネジャー、活躍中のビジネスマン、疑い深いプログラマーのような多様な読者層にも広範囲にわたって学ぶべきものがある。まさに21世紀版の『人月の神話』です。
第1部 一般的な管理
第1章 そもそもの始まり
良質なソフトウェアの重要性
沼に横たわる堅い岩
読者
反復的な問題解決時計
まとめ
第2章 計算の原点
騒動を引き起こしたもの:スプートニクショック
打開案
このプログラムがどのように機能したか?
この世代のエンジニアがなぜ特別だったのか?
計算
数字と友だちになる
それでこれらのコンピュータはどうだったのか?
われわれの計算の伝統
まとめ
第3章 登山する
大きな山に登る
失敗の共通原因
成功するための材料
人的要因
まとめ
第4章 管理する
チームを管理する
まとめ
第2部 ソフトウェアが違うところ
第5章 最も大切なこと
反復的な開発
ロスコー・リロイ
ウォーターフォールを超える
もう一方の極端
ロスコーの最初の絵
ロスコーの2番目の絵
待てよ!
ベクトルを短く保とう
ソフトウェア開発への適用
学習の応用と短ベクトルの方向
リスクターゲット
以前このことを聞いたことがあるか?
さらに学習の応用について
ビジネス上の意味
要員の効果
世間の常識
まとめ
第6章 モデリング
UMLをどのように説明するか?
UMLは何であり、どうして重要なのか?
2番目の少し歯ごたえのある例
3番目の例
そこで、ソフトウェアで大事なことを…
抽象のレベルを上げる
まとめ
第7章 コーディング
マネージャーはどのように新たなプログラミング言語を学ぶことができるか?
より良く定義された問題
標準的な問題に何を含めるべきか?
動物ゲーム
動物ゲームは条件に合うか?
「それがどうしたんだ」テストに合格するか?
あなたのゲームだ
まとめ
第8章 ドアの外に送り出す
それをビルドすれば、彼らが来るだろう
最初に、サンドボックスありき
製品のビルドがなぜ難しいのか?何だかんだ言っても
反復型開発はどうなのか?
まとめ
第3部 プロジェクト管理の視点
第9章 トレードオフ
プロジェクトピラミッド
4ではなく、5
ピラミッドに入る
高さの変数
ピラミッドの体積は一定である
統計的な間奏曲
アイデアは正しいが、分布は間違っている
実際のプロジェクトに対する暗示
何がそれをコイントスにならしめるのか?
より多くの自信
大事な警告
すべてはリスク次第だ
まとめ
第10章 見積もりをする
常識を働かせたらどうなるか?
チョコレート対バニラ
ロスコー、説明する
ロスコー、さらに深いところに行く
ロスコーのカレンダー
ロスコー、計算する
ロスコー、ソフトウェアに参入する
ロスコー、報告に来る
何か正しく、ことを行ったか推測する(1)
ロスコー、まとめる
ロスコー、苦言を呈する
何か正しく、ことを行ったか推測する(2)
ロスコー、プロジェクトマネージャー同好会に入る
まとめ
第11章 スケジューリング
ロスコーが出した問題:どのぐらい遅れるだろうか?
ジョー、少し言い返す
ロスコーの逆襲
ロスコーの犯罪者写真集
ロスコーのグラフ
最後の反論
ロスコー、分かれ際に一撃する
まとめ
第12章 リズム
物理学者がプロジェクトの進捗を眺める
現実が介入する
反復型開発はどうなのか?
最後のグラフ
まとめ
第4部 人的要素
第13章 政治
背景
定義
3つのシナリオ
政治は避けられないが、…
ものごとが政治的になる時
工学的な対応付け
高い信頼に基づく環境
悪い政治の他のバリエーション
まとめ
第14章 交渉する
コミュニケーションがすべてである
ロスコー、自分の理論を説明する
もう終わったの?
まとめ
第15章 約束する
ロスコー、鼻血を出す
…そして、すぐに要点を理解する
ベスビオ火山、噴火する
テキサスではどのようにやったのか?
ソフトウェアとの関係
犬が私の宿題を食った
仕様の戦争?
最も一般的な3つの言い訳
そして、別のことが…
フェンシング―突き、受け流し、突き返し
ビッグプロジェクトチキンゲーム
われわれが知っているようなソフトウェア開発の終わり?
「推敲」対「作成」
厳しい愛
まとめ
第16章 処遇
「フローに行く」
フローとソフトウェア開発の業績
処遇にフローモデルを適用する
お金でいつも解決できるわけではない
まとめ
第5部 水平に考える
第17章 歴史の教訓
王様にアーキテクトをさせるな
ものごとはいつも思ったようなものではない
設計をチェックする
自分が知らないということを知る
リーダーシップの連続性
いつものように急いだ
間違ったフィーチャーに力を注ぐ
設計が悪い場合…
テスティングの重要性
「プロトタイプ」対「製品」
判決
まとめ
第18章 悪いアナロジー
こちらヒューストン、問題発生
フィグニュートン
あらゆるものは相対的
量子ナンセンス
熱力学的死
他の例
良い科学
まとめ
第19章 リフレッシュ問題
組み込みソフトウェアをリフレッシュする
現在の状況
ソフトウェアアップグレードゲーム
つつましやかな提案
ソフトウェアアップグレードを再考する
素敵なものが、ただでいくつか手に入る
なぜこれが機能するのか?
改良
ソフトウェアの違法コピーはどうなのか?
太陽が支配する時までは
まとめ
第20章 それほどランダムでない数
ロスコーが準備をする
バッターをシミュレートする
第1ステップ
第2ステップ
さらに確率を生成する
むろん、野球の世界からすでに離れている
現実は醜い
マンデーの解決策
教訓
まとめ
第6部 進んだトピック
第21章 危機
魚の5日間
鮮魚店
1日目:気づかない
2日目:問題を避ける
3日目:「火消し」の登場
4日目:転換点
5日目:2つのクリティカルパス
この物語の教訓
まとめ
第22章 成長
成長の問題
素朴なモデル
モデルの帰結
説明のための例
非線形性
取るべきアクション
結論
ノモグラフ
スプレッドシート
まとめ
第23章 文化
文化とは何なのか?
強い文化と弱い文化
企業の価値を定義する
そして、ソフトウェアに適用できることは…
強い文化を作る
職を探しているならば…
突き詰めること
まとめ
第24章 すべてをまとめる
シュレッパー
マッチャー
メンシュ
さらにメンシュについて
人口の分布
モデルについて最後にいくつか考察する
まとめ
内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。
正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。
本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。
emscri さん
2009-03-25
実践的と思われるアドバイスがわかりやすく書いてあり、おおむね理解できた。(翻訳の関係でよくわからない表現もあった) 問題解決時計、リーダーとマネージャーの違い、エンジニアとの話し方、コミットすることとはどういうことか、価値(誠実さ、顧客重視、結果)、3つのリーダーシップと継続性。などなど、数年後に読み返したり、同僚や上司とディスカッションできそうな話題が豊富にあった。
茶幸才斎 さん
2011-09-11
筆者の実務経験から、ソフトウェア開発におけるプロジェクト管理の要諦についてまとめた本。なぜプロジェクトは遅れ、ときにデスマーチに至るのか、「なるほど」と頷ける興味深い話が、数学的解析をまじえて説明してあり面白かった。個人的には、地場企業より大手ベンダーのSEさんの方が、技術面と対人コミュニケーション面における質の低さを強く痛感する。そして、それがシステム開発の進捗に直接影響しているように思える。「大丈夫です、間に合います」と、後に信頼関係を損ねるような言葉を簡単に使う前に、この本を一読されることを勧める。
matsu0310 さん
2009-04-15
信じてしまえる年頃に読むべし