Gパスカルザカリーのレビュー一覧
-
Posted by ブクログ
* 当たり前なのだけど、みんな価値観が違うというのを最確認できた。
** 読む前は NT 開発時のデスマの話ぐらいしかイメージがなかったのだけど、登場するエンジニアの価値観の多様さに驚かされた。漠然と MS であればスキルが高いエンジニアがいるのだから、それなりにまとまっているのかと思っていたのだけど、スキルが高い以外は全く共通点がなく、まとまりがあるようにも見えなかった。
** 自分の周りにもいろんな価値観の人がいるわけで、それはあたり前のことなんだと再認識できた。
* アメリカでも一部は無茶苦茶働くという話は聞いたことがあったが、その実例を見ることが出来た。
* 別に難しいことは書いてないのだけど、普段より読むのに時間がかかった。つい、考えこんでしまう内容だったのかもしれない。 -
Posted by ブクログ
いまさら?という感じですが読みました。Windows NTの開発物語ということですが、古さは感じませんでした。今と違うのはスケールだけであり、同じような光景はきっとあちこちで繰り広げられているのでしょう。それは進化がないということを意味するのではなく、進化を凌駕する複雑さの爆発的拡大を意味するのだろうとぼんやり考えてしまいます。
ということで、ソフトウェア開発に少しでも関わっている人にはおすすめです。
個人的に興味深かったのは、テストをする人がコードを読み込み、コードの間違いまで含めてバグを報告すると言うことと、100%ではないということの許容の仕方です。私は、テスターさんの役割について、バグを洗い出しその状況を再現できるだけの十分な情報をコーディング担当者に伝えること、と硬直的に考えてしまっていたなあと反省しております。 -
Posted by ブクログ
1994年に発売されたWindows NT開発をひたすら追ったドキュメント。DECから移ったデイブ・カトラーがリーダーとして剛腕を発揮し、軋轢を生みながらもプロジェクトを推進する。部下に100%の献身と完全さを求めるリーダーで癇癪もよく起こす。原著は1994年に出ているので、まだ関係者の記憶も新しい頃に出た本。
コーディング-テスト-バグ取り-修正ビルド-テスト...という大規模ソフトウェアプロジェクトお馴染のプロセスが、終わりがいつなのか、そもそもあるのか分からない状態で続く。著者はインタビューで得た事実を元にして、まるで何かに憑かれたかのように、その経緯を関係者の実名を挙げて漏れがないようにという熱意を持っているかのように書きつける。果たして、それは作品として必要な表現やプロットなのか分からない。ただ、最初は違和感があったが、読み進むにつれて妙な迫力を作品に与えている。
NTはこの後、Windows XPにその成果が引き継がれる。Windowsがいつのころからかブルースクリーンを見なくなったのは、このNTのプロジェクトがあったからだと言える。
そういった話を離れて、巨大ソフトウェアプロジェクトとはつまるところこういうことなのだ、という思いを抱くのは、著者の期待するところ以上のものなのかもしれない。
性格と能力を考えると、自分は実はプログラマーに向いているんじゃないかと思っている。タイミング的に環境がそうならなかった。よかったのか悪かったのか、この本を読むとそう思う。
そう思う人は少ないかもしれないが、不思議な本だ。 -
Posted by ブクログ
難易度の高いソフトウェア開発プロジェクトにおいて、「カリスマ」が必要不可欠であることをまざまざと見せ付けてくれます。
なんか、こういう「絶対できる!!俺についてこい!!」と、自ら模範を示しながらひっぱっていく凄腕リーダーなんてみたことないし、興味深い。やっぱこういう狼がひっぱれば羊の群れも強くなれそう。
ソフトウェア開発って理屈と理論でわりきれそうだけれど、こういった人間の精神に奥深く影響を与えひっぱっていく指導者ってやっぱり必要だよなぁと感じる。
プロジェクトって、技術的選択肢はそれこそ山のようにあるけれど、一度決めたら、もうそれで突進していく意志の強さをリーダーは示すべき。いたずらに他の可能性を追ってぶれるべきではない。そう認識させられた。
デビッドカトラーはWindowsAzureの開発も担当しているらしく、もう相当なおじいちゃんだと思うけれど、これだけ技術の移り変わりの激しい業界で、まだ第一線で活躍していることは脅威だと思います。 -
Posted by ブクログ
復刊されていたということで、読んでみました。
NTというと、当時 Windows 95の、次がNT4.0という長いつきあいです。
気がつけば、Windows 2000/XP/Vista とNTを基盤をするWindowsにシフトしていったことを思うと、
NTはマイクロソフトにとっては最大のプロジェクトだったんだなと思います。
ただ、その道のりは厳しかったようです、この本から当時の状況が伺えます。
技術書と言うより読み物としての側面が強いで、読みやすくなっていますが、
現実は、ここで書かれている以上に大変だったんだろうなと思います。
3年ぐらい同じプロジェクトでデスマーチをした経験から、そのすさまじさが目に浮かびます。
しかしデスマーチが死の行進というタイトルがついているのには笑いました。
そう、死の行進なんですよね。 -
Posted by ブクログ
ネタバレWhat does this all mean?
要するになんなのかがよくわからない。
訳の問題なのか、そもそも文章が拙いのか、読むのに疲れた。
もし読むのであれば、エピローグだけでもいいんじゃないかとも思った。
得た知識をメモメモ。
大きなプロジェクトを動かすには、資金と優秀な人材が必要。システムを作るのに優秀な人というのは、コードが書ける人だと思う。コードが書けないと見積もりもできないし、何が正しいかわからないし、品質を評価できない。で、コードをかける人って、独学で勉強してきた人が多いように思う。プログラミング中毒みたいな人。自分はそういうタイプではないけど、本文にもあった「管理者になってもコードを書き続けるべき」という言葉にはすごく共感する。マネジメントだけなんてって。
そして、こんな大きなプロジェクトだと、バグも多く、一日の遅れが積み重なり、一年の遅れとなる。いつまでたっても終わんないんじゃないかって。基本的に予定から遅れると、期限を延ばすか、機能を削るのが筋だけど、「どちらを削りましょうか?」「両方やれ。」が面白かった。うん。
あとは働き方。ものすごいハードワーク。ストックオプションがモチベーションになるのはわかるけど、本文にあった「死の床でもっと働けばよかったって思うやつはいない」はまさにその通り。家族との時間を犠牲にしてまでやるべきかはよく考える必要があるなあと。で、外資系特有?かはわからないけど、泳げない奴は沈めばいいっていう考え方もまた惹かれる。今の自分のスキル微妙だなあって。月並みな仕事しかできないのは、意思に問題があるからだそうなので、もっと吸収していかなきゃ。 -
Posted by ブクログ
スクラッチで開発する場合、
ソフトウェア会社以上のプログラミング能力、マネージメント力が必要になると思うのだが、
現実としてそのようなSIerはない気がする。
まして本来であれば一発でいいものなんて作れるわけが無いはずなのに、
バージョンアップされることもない。
あっても5年に1回と、10年に1回の刷新で、
それもまた前と同様に0からの新規と同じ。
企業で使われているシステムというのは、意外にしょぼいのかもな。
以下抜粋。
○私が本当にやりたかったのは、コンピューターを使うことであって、
コンピューターで問題を解決することではなかった。(P.19)
○自分の成功から学んでいく。次の機会にはもっとうまくやる。
そのたびに、ひとつ上のレベルに上っていく。(P.27)
○経営管理のプロにソフトウェア・チームやソフトウェア会社の管理を任せると、
悲惨なけっかになる。
有望なソフトウェアとくずを見きわめることも、
スケジュールや製品設計を評価することもできない。(P.45)
○ゲイツの最大の長所は、柔軟性にある。
ぴったりの時期に、たくみに進路を変える。
絶対的な基準にしがみつく人間が多い世界で、
ゲイツは首尾一貫性よりも、
正しい行動をとることを選ぶ。(P.45)
○最初は成功したソフトウェア会社が、
コードを知らない管理者の失敗で急激に転落した例はいくつもある。(P.145)
○NTを使いつづけたい。
自分たちでバグを経験したい。
そうすれば、早く修正できるだろう。(P.177)
○泳げないヤツは沈めばいい(P.180)
○カトラーは、オペレーティング・システムを開発するときは、
機能を増やすより、スケジュールを短縮するべきだと考えている。
最初のバージョンは、機能を減らしても、早くリリースした方がいい。(P.183)
○猛烈にはたらき、最初の一年間で一万五千行のコードを書いた。(P.194)
○グループの中での力は、肩書きによるものでも、才能によるものでもなく、
「何を達成したかによる」とカトラーは信じている。(P.255)
○自分に怒りが向けられたら、なるべく早く、だれかに罪を転嫁するのがいい。(P.259)
○コードを書いているにしろ、遊んでいるにしろ、
いつもキーボードをたたいているプログラマーが多いのは、
コンピュータがおもしろくてたまらないからだ。(P.276)
○息子はしぶしぶドアを開けながら言った。
「試合が終わったときに来てくれるんだったら、
おもちゃを全部すてるって約束するんだけど」。
この言葉に、「ナイフを胸につきたてられたように」感じた。
その日は一日、息子に付き合うことにした。(P.272)
○「ほとんどのプロジェクトでは、
当初のバージョンはほとんど使い物にならない。
あまりに遅いか、あまりに大きいか、あまりに使いにくいか、
あるいはこの三つの欠陥を三つともかかえている」(P.292)
○ラシッドは科学者のように考える。
なにが可能なのかを考える。
カーネルにページングを取りいれて、『どこがこわれるのか、みてみよう』と言う。
こわれた部分は、ページングをやめればいい。
これに対してカトラーは、エンジニアとして、状況を検討している。
解決策をあらかじめ設計しておこうとする。
どの部分でページングが使え、どの部分で使えないのかを、あらかじめ決めておく。
こうすれば、信頼性の高いソフトができる。(P.318)
○忘れてはならない。
いまが人生で最良のときなのだ。
いまはそう思えないかもしれない。
しかし、何年かたって振り返ってみれば、
自分たちがなし遂げたことに驚嘆するようになるだろう。(P.350)
○会議に参加している幹部のほとんどは、
あるバグを取り除くべきかどうか、
判断できるわけではない。(P.362)