トム・デマルコのレビュー一覧
-
-
-
-
Posted by ブクログ
ソフトウェア開発プロセスを、小説仕立てで語っている。なので、読んでいてとてもおもしろい。
ただ、物語の舞台が非現実的かなーと思った。というのも、自分のような一介のエンジニアには、到底想像もできないようなプロジェクト規模だから。
でも、もしかしたら世の中には、物語の舞台と似たようなプロジェクトを管理している人はいるのかも？（きっといるよね）
本の内容については、自分のようなエンジニアでも直面したことある、もしくは直面しそうな事象を取り上げている。事実、自分でも「あー、こんなことあったなー」とか、「自分のことだ・・・」とか思うような内容だった（逆に、こういうことに直面するのは自分だけじゃない、ある意味、正常なことなのかもと思ったが）。
特に、15章以降は、多くのエンジニアが直面したことのある話題ではなかろうか。主人公がメモっていることは、画期的な解決方法ではないにしろ、きっと参考になると思う。
出版された当時と比べて、今はいろいろな管理・開発手法が生まれて、そして流行っている。しかし、多くの人が直面するプロジェクトの問題点の本質的な部分は、今も昔も変わらないんだと思う。
そういった点を踏まえ、この本で学べることを、現在主流の管理・開発手法でいかにして解決を図るかというアプローチが、この本の良い使い方なのかなあと思う。
プロジェクト管理者でなくても、ぜひ、一読していただきたい。読み始めたらとまらないはず。
ちなみに、物語の最後でほろっとした。 -
-
-
-
Posted by ブクログ
開発プロジェクトにおける「ありがちなパターン」集。ダメなパターンが多めですが、「こんな感じのことをしていると、うまくいくこともある」というパターンもあります。パターンのバリエーションは豊富なので、「良かれと思ってやっていることも、ダメなパターンに陥ることもあるんだ」と気が付くところも多々ありました。
基本的にパターン集なので、これらのパターンから参考とすべきところや、改善すべきところを自分で見つけて実践していくことで、この本を初めて有効に活用できます。逆に、この本からプロジェクト運営・管理の具体的な改善方法を教えてもらいたい、と思って読むと、単なる「あるある集」で終わってしまうでしょう。 -
-
Posted by ブクログ
プロジェクトを失敗に陥れるさまざまな要因を、ユーモラスに語っている本。
失敗要因は笑うためではなく、学ぶためにある。
＞弱いチームの方が、強いチームより決定や行動を「保留」する傾向がはるかに強い
強いチームになるためには、意志決定や行動を迅速に行える覚悟が必要なのである。
時間が一番貴重な資源であり、一呼吸おいたらすぐ実行という自分の考え方と一致する。
＞約束がなされたか、また、それは正確にどのような約束だったかについて、約束した側と受け手側の解釈が異なっていると、約束のシステムは崩れる
コミュニケーション不足が大きな問題に繋がることを示唆している。
自分だけのメモに終わらず、相手と一緒に確認して、やっと約束のシステムが出来る。
以心伝心という発想は、結局双方向に良くない。
＞どんなに機能を付け足して飾りたてても、デザインはよくならない。むしろデザインを美しくするには、そぎ落とすことである
同感！
「良いデザインとはシンプルで実用的である」という自分の信念に一致する。
また、ここから「決断とは断つことである」という教訓も学べる。 -
-
Posted by ブクログ
リスクとはそもそも何か、というところから始まって、リスク管理がうまくいかない理由について述べられている。そしてリスク管理が行われない理由についても述べられている。（例：早く終わる可能性のあるスケジュールをひくことが許されないなど）この項が一番参考になった（苦笑）。
あと身にしみて感じるところがあったのが、問題の原因はより早い時期に発生しているが、問題を認識し始める時期（天罰期という 笑）についての説明とその対処法。バージョンごとにリリースするというのが意外と現実的な方法だと分かった。
この本が扱う範囲は入門から中級までかなり広いと思うがリスク管理をやる上で読んでおいてよい1冊だと思う。[2007/1/4] -
-
Posted by ブクログ
ソフトウェアは人間関係ビジネス。ITのプロジェクトで発生する問題は主に技術的なものより社会学的なもの(ピープルウェア)。オフィスで感情を刺激する最大要因は自尊心を傷つけられること。その自尊心は大抵アウトプットの量より質に結び付けられる。出荷拒否権限。開放型オフィスへの(筆者の)ヘイト。フロー状態を途切れさせない。ホーンブロワーの考えは、現代では公然と言えば袋叩きに遭うだろうが、個人的には現実に即していると思う。自信のない権威主義体制では服装や髪型に至るまで統制され、会社としての価値創造力は失われていく。最良のイノベーションでも成果を出すには反抗的リーダーシップが必要。イノベーター自身が偉大なリーダーである必要はないが、誰かがその役回りを担う。勤務時間の分割はギアチェンジに要する時間も増え、結果集中を要する設計・開発作業の進捗が割を食うが、こうした問題は往々にしてエンジニアが自分の能力不足が原因と思ってしまう。全体を通してめちゃくちゃ斬新なことを言ってるわけではなく、ずれてはいないが多くは著者の経験則ベースで根拠や出典が少なく、いまいち刺さらなかった。
-
Posted by ブクログ
エンジニア、さらに言えばプログラマの働き方に対する本。プログラマはどう働くべきか、周囲は彼らを活用させるためにどうすればいいのかを説明している。
ものすごく簡単に言えば、互いにコミュニケーションが取れる状態をチーム内に構築する、周囲（マネージャなど）は彼らの邪魔になることはしない（邪魔になること:電話を掛けたり電話対応させたり集中力が途切れるようなこと）などが挙げられている。それと似たようなことが実例とともに繰り返し述べられているのがこの本の主な内容である。実際にはプログラマが成長する際の学習環境についてなども含まれている。
さて、そうするとプログラマが勝手気ままに周囲に対してふるまえるかのように読めてしまうが、そうではなくここでいうプログラマはそれぞれ第一線で活躍できるような技量を持った存在のことであり、ぴよぴよのプログラマが好き勝手に要求していいわけではない。そんなひよこが成長できるような学習環境も提供するのが環境の責務であると述べているのは先述の通りだが、どちらかというとやはり自身で作業・責務の最適な姿が見えるプロフェッショナルなプログラマを対象としている。
そしてそれは書末にある「自由電子」という語に集約される。よい軍隊のように前線で各個人が高い能力でもって判断・連携する組織的な活動というイメージがぴったりあう。 -
-
-
-
-