[読了]アジャイルな見積りと計画づくり
今週、先週の通勤時間はほぼ全て本書に捧げました。
気になった箇所やあとで読み返したいところなどに付箋をつけていったらこんなんなりました。(色は特に意味はないです)
特に興味深かったのは、作業量の見積りと期間の見積りを分けて考えるという所と、狩野モデルの紹介の部分でした。
ということで、個人的には第三部、特に11章が目から鱗でした。 本書を読んで、みなさんもよい見積りを!
「アジャイルな見積りと計画づくり」読み始め
私たちの「秘密兵器」がこうして日本の皆さんの手に入りやすくなってしまうことを少しだけ残念に思います:-)
本書の訳者あとがきにはこのように書かれている。
私は、訳者の安井さん、角谷さんとは、殆ど一緒に仕事をしたことはないが、一度だけ角谷さんと同じプロジェクトで仕事をしたことがある。
そのプロジェクトはかなり厳しいプロジェクトだったが、4章で紹介されているベロシティの計測を実際に行い、自分達の作業スケジュールを見直し続け、無事に終了することが出来た。（そのプロジェクトでは期間や機能を調整することが出来なかったため、自分達の日々の作業量や、休日出勤のスケジュールを立てるのに非常に役立った）
このように、本書に書かれていることは「欧米ではこんなことが流行っているから日本でも試してみるといいかも」ということではない。訳者のお二人が「この日本の企業で実践していること」なのだ。
まだ4章までしか読んでいないが、入社してから当たり前のように教えられた見積りや計画づくりの考えかたは、本書が源泉だったのかと思えるほど、見積りと計画のエッセンスがぎっしり詰っている。
「もう、本書を読んだことがない人とは一緒に仕事できないかもしれない」
そんな風に思わせてしまう1冊ではないだろうか。
#あわせて読みたい
Eric本
先日、ようやく読み終わりました。 読み終わった日に平鍋さんが記事を書いていて、こっそり運命を感じていたのは秘密です。
小さなISV
これが自分の目指す一つの形なんだと強く感じました。
成功の定義
これが実は一番感動した点。 成功の定義は、その会社の資金調達の方法に大きく影響を受けるという話。
- どのような形であれ、外から資金を得ているなら、利益を出すことが成功
- 逆に外から資金を得なければ、自分たちが食べていけることが成功
ディベロッパー
自分は、今までエンジニアという職業・言葉に非常にこだわりがありました。 それには下のような理由があったのですが
- SEはないだろJK
- 大学ではソフトウェア工学(Software Engineering)研究室
- プログラムを書くだけの人間にはなりたくない
- 常に新しいものに挑戦し、改善していきたい
これからはディベロッパーにしようと思います。 まぁ、これは自分が勝手に思ってるだけで、業界外の人から職業を聞かれたらSEって答えるので、気持ちの問題だけです。
なので、いつか役職がついたら「(役職)兼ディベロッパー」というt-wadaライクな名刺を作りたい、というか作りますｗ でも、カタカナだとカッコ悪いのでdeveloperの方がいいなー
そんなこんなで、Eric本は他の方々も薦めている通り素晴らしい本なので、ぜひご一読ください。
読了「Googleを支える技術」
すごくいい本なんですが、あと一歩踏み込んでほしかった印象。 残りの部分は自分で論文を読めってことなんでしょうねｗ
ちなみに、自分が一番面白いと思ったのは5章の「運用コスト」について。 マシンや電力、土地に関する考え方は、かなり新鮮でした。
Google級ではなくても、それなりの規模になったアプリケーションを運用する上では避けて通れない道ですよね。この章の内容をちょっとでも生かせるようなアプリケーションを生み出せたらいいなーと思った今日この頃です。
Railsレシピブック 183の技
これはいいレシピブック！
この本のレビューは、id:ursmがオブラブメルマガに書いたものが素晴らしすぎるのでそちらをぜひ見てください。（みんな当然とってるよね！もしとってない方がいたら購読申し込みページからぜひ！） メルマガアーカイブのこちら。
で、早速Stipaに写真を貼れるようにしたかったので、レシピ155「attachment-fuプラグインでアップロードされたファイルを扱う」を見ながらファイルのアップロード機能に挑戦してみましたが、5ページをただただ写経するだけで完成してしまいました！
Rails弱者の自分にとっては、「○○ってどうやるんですか？」と聞く前に眺める本として重宝するに違いありません。
というわけで、Railsやったことある人も、これからやろうという人も、使いたいとは思わないけど空気は知りたいという人も買うといいと思うよ。
久しぶりに本購入
「まるごとRuby!」と「Googleを支える技術」前者がなかなか入荷しなくて待ってました。 感想なんかはまた後日ｗ
OnLisp #1 1
ようやくマクロのあたりまで読んだけれど、関数型弱者の自分は消化できてないところが多いので、ふりかえりながらエントリにすることしよう。 まずは、前書き～1章。
この本のテーマは「Lispとボトムアップスタイル」だということ。
- ボトムアップスタイルとは、これから書くプログラムにあわせてプログラミング言語を作っていくスタイルだ。
- たとえば、新しいオペレータが必要なら作る。
- Lispを基に(on Lisp)書いた言語でプログラムを作る(かっこいい！)
- これはDSLということかな。いや、もう一段上の考え方のようなきがするな。
- トップダウンデザインとは、「このプログラム目的は7個だから、それぞれサブルーチンにして、それをまた…」というアプローチ。
- ボトムアップとトップダウンで作ったプログラムは決して同じものにならない。
- ボトムアップは大規模な言語と小規模なプログラム、トップダウンは小規模な言語と大規模なプログラム。これはなんとなく理解できるようになってきた。
特に気になったところはこんな感じ。今までに経験したことのないアプローチ! この一冊を消化できたら、新しいステージに上がれるような気がしてくるいい導入部でした。
OnLispのエントリまとめはOnLispタグで。
Lisp始めました
冷やし中華的な意味で。
やっぱり、Geekのなりそこないとしては、Lispも中途半端にできないとだめですよね～。
というわけで、去年のオブラブでゲットしたOn Lispを読み始めてます。
正直、いきなりLispはきつ過ぎる気もしますが、1年くらいかけてでもじっくり読んでいこうと思います。
「箱」読了
約2年間積読されていた本書をようやく読み終わりました。
きっと、2年前に読んでいたら「面白い考え方だ」で終わっていたように思う。「実践しよう」とは思わなかったに違いない。(2年前の自分を振り返ると本当にそうだと思う)
「周りを変えたいけど変えられない」と思っている人は是非読むといい。
p.s. 本書の主人公が、もし転職する前の会社でこの話を聞いていたらどうなっていたのか、すごく気になる。