伊豆原弓のレビュー一覧
-
-
-
-
Posted by ブクログ
計画に対する乖離を早い段階で把握し、手遅れになる前に適切な対策を打てるかどうかが、プロジェクトの成否に大きく関わってきます。そのために、プロジェクト・マネージャーはプロジェクトのQCDに関するデータを収集して現状を分析しようとします。（監視・コントロール）
しかしながら、こうしたQCDデータに現れない事象がプロジェクトを思わぬ方向に導くことも少なくありません。
本書は、こうしたプロジェクトの「兆候」を86のパターンに抽象化してユーモラスな名前を付けて紹介しています。
中には自分の身に覚えのあるパターンも沢山あって耳が痛い限りですが、ありがちなものをピックアップして目に見えるところに書き出しておくだけでも役に立つのではないでしょうか。独特のネーミングも相まって、印象に残るトッピクスが多いと思います。
内容としては、チームビルディングやファシリテーションなど「人」に関する教訓めいたものが多い印象です。 -
-
-
Posted by ブクログ
ネタバレ[読んだ理由]==================
「100人のプロが選んだソフトウェア開発の名著」にあった。PM、特にリスク管理って全然わからないので一度読んでみたいと思った。
[読んだ後の感想]==============
主なポイントは下記かなぁ、と思った。
・プロジェクト着手前に、想定しうる最悪のリスクまで徹底的に出しきっておく。
・「やらなければならない」作業だけでなく「やらなければならないかもしれない」作業も予想しておくべき。
・「コスト」と同様に「効果」も数量化すべき。でないとプロジェクトの「効果」が測れない。
・プロジェクトの最短だけでなく最遅の完成期日も予測し、その両方の結果から現実的な期日を予想する。
・リスクの大きな作業は極力先に済ませる事で、プロジェクトの柔軟性を極力確保する。
[読書録]======================
■第一部：なぜリスクを管理するのか
リスクのないプロジェクトには手を付けるな。全くリスクのないプロジェクトに手を出すのは負け組だ。必ずといっていいほど、何もえるものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。
■第二部：なぜリスクを管理しないのか
リスク管理をすべきでない理由の一つ：はっきり不確定幅を決めると、出来の悪い仕事を許すことになる。
⇒SWマネージャは「予測と目標は同じである」という標準ルールに従う傾向がある。しかしリスク管理のルールによれば、マネージャはいつも部下が最高の仕事を目指して努力するように目標を設定すべきである。その一方、クライアントや上層部に約束をする時には、目標とは全く別の予想を使うべきである。
「間違えるのは構わないが、不確かなのは駄目だ」と言うルールが自分の会社に当てはまったら、おしまい。このルールの意味は、約束した納期に間に合わなくても良い、大幅に遅れても構わないが、その日までの間、期日に間に合いそうもないといってはならないということだ。
「近づく電車が見えない症候群」「選択的近視」：
⇒これを避けるには、リスク管理をはじめる時点で、思いつく限りの破滅的な結果を並べて見ること。
つまらない心配事より、悪夢を攻撃せよ。
SWプロジェクトでは概して、且つために特別なことをするより、負けの程度を抑えるほうが大事なのだ。この仕事では、どんな組織も負けることがある。他の時に勝ったことがあろうがあるまいが、負けた時に最も痛手を受けたものが本当の負である。
■第三部：リスク管理の方法
SWプロジェクトマネージャの殆どは、「やらなければならない」作業についてはほぼ正確に予想できるが、「やらなければならないかもしれない」作業は正しく予想できない。
この業界は、予定より早く終わるという第三の結果を事実上不当なものとみなすことで、期日通りに完成する可能性をほぼゼロにしているのだ。いい加減なスケジュールを許さないがために、むしろいい加減なスケジュールが例外ではなく当然になっている。
全体リスクの不確定性は、成否を決める各々の原因の不確定性を積み重ねた結果である。
Ｎ（ナノパーセント日：その日に完成する可能性がゼロではない最初の日）：
人は楽観的な声質を持っており、過去の経験から、可能な範囲で最も楽観的なスケジュールであるNを見積もることにはかなり熟達している。しかし、Nに完成すると約束するのではなく、本当に約束すべき納期を決定するためのデータとしてNを使うことが重要。
プロジェクトでも損は早めに出してしまうに限る。其の様なときは一旦主導権を失い、成り行きに任せることになる。しかし、早めにそうしておけば、強みを温存しておいて主導権を取り戻すことができる。システムのウチ技術的に軌跡に頼る部分は、初期のバージョンに組み込むべきである。そうすれば、奇跡が起きなかったとしても、いざというときの選択肢が最大限に多い。
インクリメンタル開発計画：
・制約の1つ：詳細設計図に、設計の分割を最低レベルまで全て示さなければならないこと。通常は、高レベルの設計を適当に済ませて設計が完了したと宣言し、後の設計分割作業はコーディングの副産物として行われているのが現状。
・メリット：区切りが多いため、プロジェクト要員の士気が保たれる。状況が目に見えやすい。プロジェクトの最後に残るのはほとんど余計なお飾りの機能だと分かり、その部分をカットできる可能性がある。
■第四部：数量化の方法
コストと効果は同じ精度で表す必要がある。「どうしても要るのだ」としか効果を言い表せないのなら、コストも「相当かかるだろう」とするべきである。
開発者と発注者の説明責任は平等であるべきだ。発注者には、価値が生み出されることを確認する責任がある。ところが、我々のアンケートによれば、企業はプロジェクトの完了後に、効果を実現できたかどうかを追跡調査していない。
製品が大きくなることでコストが比例以上に増大するとしたら、製品を小さくすればコストを比例以上に節約できるはずだ。システムの中で価値コスト比率の低い部分を削減することは、時間と予算に対する制約を緩める最も簡単な方法。ソフトウェア開発者は「もっと小さなソフトウェアを」をスローガンにしようと考えるべきだというと妙に聞こえるかもしれないが、そのほうが有利なことは明らかだ。
デスマーチの正当化にいつも使われるのは、プロジェクトの重要性である。「このプロジェクトは極めて重要なものだから、プロジェクト要員には精一杯頑張ってもらわねばならない」。だが、プロジェクトがそれほど重要なら、どうして会社はそれを適切に遂行出来るだけの時間と資金を使えないのか。
我々の経験では、デスマーチプロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが成果を上回ることが明らかだからだ。
■第五部：嘘か真か -
Posted by ブクログ
名著らしいが初めて読んだ。
さすがに２５年も経てば事例は陳腐で技術的・資源な事は進歩しているが、大事なことはだいたい同じ。
要するにプログラミングというのは人の状況判断であって、単純作業ではないということだ。
それも個人としての観点や社会活動としての観点でそれぞれ心理的問題は深い。
チーム・グループに関する話はプログラミングに限定されない話題ではあるが、
いかに理屈で動いているように見えるプログラマー業であっても、集団心理といったものは働く。むしろより強いのではないかと思う。
また、チームに関して言えば、個々メンバーは交換できるものでもなければスキルすら定量化できるものでもないという、当たり前だが大事な問題がある。
だからこそ仕事にチームを当てるのはでなく、チームに仕事を当てたほうが良いというのは、経験者なら誰もが感じていることだと思われるが、そうなると人単価で頭数集められるチームというのは不幸な話だ。
そしてプログラミング言語は言語かという話題も面白い。
全体的に挙げられている問題点は近代的な開発手法で考慮さてて普及してきている。
（TDD的結論があったのは驚いた）
まだ今日はそれも十分ではないが、次なる四半世紀後はどうなるかわからない。
ただ、今日の自分にこの本は価値があった。それは言える。 -
-
Posted by ブクログ
「人間の側面からみたソフトウェアテスト」についての本です。
ワインバーグはこの本で繰り返し、「テストは情報を得るために実施するものである」と書いています。例えば、
キーを打つかどうかにかかわらず、何らかのアクションに影響を及ぼす情報を求めるものでなければ、テストとは呼べない。
といったようにです。
そして、その情報の質については、例えば、第10章の「テストはキーを打つだけではない」の「よくある間違い」に書いてある、
4. カバレッジテストが何かをテストした証明になると思っている
コードのすべての部分を何らかのテストでふれたことを証明できたからといって、その部分が完全にテストされたとはいえない。また、コードをすべてカバーしたからといって、すべての機能を完全にテストしたとはいえない。そういえるためには、テストの関係性と包括性を分析する必要がある。別の言葉でいえば、考え方を分析する必要がある。
や、第16章の「コンピュータを使わないテスト」の「テスト担当者は貴重なレビューアになる」に書いてある、
1. 開発者にありがちな思考パターンの欠点を観察することで、より良いテストを作成できるようになる。
2. 早い段階から仕様書をレビューすることで、テスト計画のスコープを早く決められる。
3. 設計を熟知することで、より迅速にバグを発見し、その絞込みに協力できるようになる。
4. レビューに参加することで、自分たちのテストケース、テスト計画、テストドライバ、ツールの良いレビューアーになる方法を学ぶ。さらに、関係者からテストするものを渡されるのをじっと待っているだけのテスト担当者にくらべ、はるかに早くプロジェクトのスピードに着いていけるようになる。
の1のように、「思考パターンの欠点を観察すること」の重要性を主張しています。
にしさんの「不具合モード」、智美塾、今回のSSでのＷモデルの議論の方向性が間違っていないことを本書で確信しました。
よし、いまやってる活動を自信を持って進めよう！と思える一冊でした。 -
-
-
-
Posted by ブクログ
ソフトウェア開発プロセスを、小説仕立てで語っている。なので、読んでいてとてもおもしろい。
ただ、物語の舞台が非現実的かなーと思った。というのも、自分のような一介のエンジニアには、到底想像もできないようなプロジェクト規模だから。
でも、もしかしたら世の中には、物語の舞台と似たようなプロジェクトを管理している人はいるのかも？（きっといるよね）
本の内容については、自分のようなエンジニアでも直面したことある、もしくは直面しそうな事象を取り上げている。事実、自分でも「あー、こんなことあったなー」とか、「自分のことだ・・・」とか思うような内容だった（逆に、こういうことに直面するのは自分だけじゃない、ある意味、正常なことなのかもと思ったが）。
特に、15章以降は、多くのエンジニアが直面したことのある話題ではなかろうか。主人公がメモっていることは、画期的な解決方法ではないにしろ、きっと参考になると思う。
出版された当時と比べて、今はいろいろな管理・開発手法が生まれて、そして流行っている。しかし、多くの人が直面するプロジェクトの問題点の本質的な部分は、今も昔も変わらないんだと思う。
そういった点を踏まえ、この本で学べることを、現在主流の管理・開発手法でいかにして解決を図るかというアプローチが、この本の良い使い方なのかなあと思う。
プロジェクト管理者でなくても、ぜひ、一読していただきたい。読み始めたらとまらないはず。
ちなみに、物語の最後でほろっとした。 -
Posted by ブクログ
201009石榑統括塾 課題図書 20100929 伊豆での人間ドックを期に、一気に読破。☆その他、気になったキーワード・P38 瞬間があるからこそリーダーという仕事が好きだということが否定できない。 →キャスリンは、チーム作りに長けているリーダーという設定だが、これからメンバに対して、この会社の課題（競合から遅れを取っていること）に対する原因分析をするという難題を出す際に、ワクワク感を楽しむなんて、非常に高い視点で物事を考えているものだと感心した。（課題が難しければ難しいほど、得られる成果も大きい、ということを十分に把握している）・P82 もちろんすぐに把握できるぐらい明快に、すぐに対応できるくらい具体的に、目標を、結果を定義することが大事です。 →リーダーの立場で指示を出す（何かを打ち出す）際に、非常に良いセンテンスだと感じた。・P149 自分にとっての第一のチームはどこか？ →SGLとしては、自SGを重視することは重要だが、”課長代理”という役割を担っている以上は、第一のチームは、会社としての意思（部課長）を優先すべき。・P162 お互いが何に時間をつかっているか、十分に前進しているか、しっかり追及する必要がある。（他SGのことだからといって、放置するのではなく、それが例えば会社としての利益につながることであれば、どんどん進言し、衝突すべき。衝突することで信頼感がうまれる。）
-
-
-
-
-