前の版にはフリーになった年にだいぶお世話になって、いまでも時々リファレンスとして使っていたのですが、改訂版が出ているのを知ったのでさっそく買ってきました。入れ替えて置くことにします。
手引きや他の本を読んで「こう書いてあるけど、少し違うこういう場合はどうするんだろう?」って思うようなことが、こちら側視点で具体的に書かれているのが魅力です。
残念ながらアマゾンでは売り切れちゃってますが、大きめの本屋さんなら確定申告コーナーにあると思います。これはおすすめ。
[via] ヲハニュース
StarChartLog – 九天社が倒産したらしい
Twitter経由Pickles weblogによると、九天社が倒産したらしいです。公式サイトは現在メンテナンス中です。いましばらくお待ちください。状態。今のところ公式発表・マスコミ報道はないようです。

いつかは触りたいなーと思って欲しい本リストに入っていたのだけれど、これを見て即注文した。
どうしようかなーと思っていたあなた、急いで急いでっっ!
仕事でこの辺の知識が必要だなーと思ったところでお借りできたのでサクッと読んだ。
ポイントごとに上手くまとめられていて、なんとなく分かっているような分かっていないような感じでいたところがつながった気がする。
本屋で見かけてはいたのだけれど、素通りしてた本。先日の木下さんのプレゼンに影響されて読んだ。
夢をかなえるためのプラクティスは、正直どこかで聞いたことがあるものだったりするんだけれど、それをまとめて、普通のサラリーマンが変な神様に育てられるという物語にしたのがいいところ。
「ちゃんと実行すればいいんだろうけど、普通はそんな感じで流れてしまうよねー。」というような、ありがちな「自分に近い」視点なのだ。
こういう本は、トリガーになる。自分もすぐに根が生えて新しいことを面倒くさがってしまうので、その根を刈るきっかけにさせていただいた。
すでに動いているものを加速するより、止まっているものを動かし始めるほうがエネルギーがいる。
でも、その「動かし続ける」っていうこと、
続きを読む…
- いつの間にか相手の思い通りになってしまっていた。
- 自分で選んだはずなのだけれどなぜか腑に落ちない。
そんなことになってしまうのはどんな原因があるのか、よく使われる手口について著者が実際に仕掛ける側に回った体験に基づいて書かれた本。
たしかに自分がその状況になったらそうするだろうな、と思う場面ばかり。
積ん読になっていた初版を最近やっと消化したと思ったら次が発表されていた。
予約した。カチッ・サー
ケータイがパソコンの代用品という発想ではじまると、たどり着かないところ。
初めてネットに繋ぐのがケータイってどんな感じだろ。
技術的には同じようなことなんだからと知ったかぶっていたよ。
・・・!?、オジサンか。
ソフトウェアを量産品と見立て、フェーズごとに分業が容易、また担当者の代替が容易なものであるという前提にあることのメタファを「ソフトウェア工学」、対してソフトウェアを工芸品と見立て、担当者の技能が製品の品質に大きく関わり、それぞれのフェーズは簡単に区切れるものではなく、それらをまたいだ知識が必要であることのメタファを「ソフトウェア職人気質」と呼んでいる。(だいぶザックリ)
残念だけど訳がわかりにくいところが散見された。たとえば意味としてセットになっているものの表記に統一感がないところ。
文中で上中級、初心者をそれぞれ熟練職人、ジャーニーマン、アプレンティスとしているのだけれど、熟練職人をクラフトマンにするとか、そのほかを見習い、駆け出しとするなど統一感をもたせて欲しかった。
しかし、ソフトウェアを工芸品ということでそれに対するこだわりやプライド、徒弟制度ということで後続教育のあり方を表しているところは理解しやすい。
職人というとなにやら偏屈だっていうイメージがついて回るけど、それは見方を変えれば自分の作るものにこだわりを持って妥協をしない、ということでもあると思う。
とにかく早く、とにかく安く、というプロジェクトをよく聞くのだけど、いいものにはそれだけ時間と金がかかるという認識、かけるという考え方がもっと当たり前になって欲しい。
その「いいところ」がなかなか数値化できないから難しいのだけれども。
そして、この本はこう締められている。
ソフトウェア開発は楽しくなければなりません。そうでなければ、そのプロセスは間違っているのです。
かくありたい。
つぎは達人プログラマーへ。
[ref.] ソフトウェア開発の名著を読む。
トム・デマルコつながりの3冊目。ピープルウェアやゆとりの法則と違って、小説形式になっている。
有能なのだけれど会社都合でリストラ対象になってしまったプロジェクト管理者がとある国のスパイに見込まれて拉致されて国家プロジェクトの担当にさせられてなんだかんだあるというお話。
ストーリーとしては「ん?」て感じだけど、それぞれの章の末尾に日記という形でまとめられている、プロジェクトの中で主人公が誰かから学ぶ(または自身で気付く)ことが読者へのアドバイスになっている。
ただでさえタイトなスケジュールを上司の都合でさらに短くされてしまったりだとか、プロジェクトメンバ間で対立が起きたりだとか、そんな実際のプロジェクトにありうるトラブルが次々と起こり、そのたびに専門家がやってきて助けてくれて乗り切るという展開が、前述の2冊の内容を実際のプロジェクトに照らし合わせるとこんな感じになるよ、そしてその時にはこうするといいんだよ、と示されているような感じ。小説形式になっていることですんなりと楽しく読めた。
さて、つぎは「ソフトウェア職人気質」へ。
[ref.] ソフトウェア開発の名著を読む。
ピープルウェアの兄弟ってことで。
帯にある「人は時間的プレッシャーをかけられても速くは考えられない!」にすべてが凝縮されている。
いっぱいいっぱいの状態では目の前の(本当にあっているんだか間違っているんだか分からない)ことの山を切り崩すのがやっとで、新しいことを(その作業効率を改善することすら)始めようという気持ちはなくなる。
進む先に光が見えなければモチベーションも下がるわけで、当然のごとくアウトプットの品質も下がる。
スケジュールを短くして人員を減らしてって、コストを削っているつもりが投資まで削っていては節約した以上のマイナスになるよ、と。
チームでなくて自分一人でも言えると思う。しっかりやりたいことやって、モチベーション上げていこう。
ということで、寄り道しましたが次は「デッドライン」だッ!!
[ref.] ピープルウェア。
[ref.] ソフトウェア開発の名著を読む。
ハードウェアでもソフトウェアでもなくてピープルウェア。モノより人ですよ先生、てこと。
オフィス環境についての部分が一番印象に残ったのでそれについて。
よく見られる「開放型オフィス」では業務時間中に「本当の」仕事はできないと言っている。
集中している状態のことを心理学者はフロー(Flow)状態と呼ぶそうだけど、普通の状態からフロー状態に遷移するまでが15分、電話が入ったり話しかけられたりしてその状態から出てしまうのは一瞬だと。これを20回繰り返すと実質丸一日何もやってない事になるとのこと。
電話や相談がメインの仕事ならいいのかも知れないけど、ソフトウェア開発の現場ではそれらをメインとしているのは得てして少数派。
顔が見えるところにいないとコミュニケーションが云々て話があるが、それはまた別の話だよなぁ。
会社よりも喫茶店だとかファーストフード店だとかでカタカタやってる方が進捗がいいってのはよく聞く話で。
集中が必要な作業と、他の人との会話が必要な作業はサンドイッチにはできない。
順番では次は「デッドライン」ですが、あとがきでお勧めされてしまったので「ゆとりの法則」に脱線です。
すでに両方とも手元のAmazonロゴがついた段ボールの中に・・・。
[ref.] ソフトウェア開発の名著を読む。