プログラマとして飯を食っていくつもりなら『Joel on Sotfware』は必読だと思う

Joel on Software

別に書籍で読む必要は無い.
webに日本語訳された氏のエッセイが公開されているから.

http://japanese.joelonsoftware.com/

でも、書籍だろうとWebページだろうと、プログラマとして飯を食っていくつもりだったら一度目を通しておく必要はあると思う.
プログラムを生涯の職業と決めたんだったら読んでおく価値は絶対にある.

さて、軽く気になった章を振り返っておくことにしよう.

『第３章 ジョエルテスト: いいプログラムへの12ステップ』

私の職場環境の採点を行ってみたら、わずか2ポイント.
色々と、作業環境の見直しを進める必要がある立場なだけに、恥ずかしいやら情けないやら...

テストの項目を振り返ってみると、「ワンステップでビルドできる？」とか「デイリービルドしている？」なんかは導入の予定があれども、日々の業務に追われてしまって手が出ないでいた部分だと反省.
「アップデートされているスケジュールがある？」とか「仕様書はある？」なんかも言い訳をつけて怠けている部分だよなぁ

「プログラマは静かな環境で作業している？」「手に入る最高のツールを使っている？」「テスタはいる？」「採用面接のときにコード書かせている？」あたりは、私の立場だけでの改善は少々難しいんで協力者が必要な項目.
上手に理解者を増やしていく必要がある部分だな.

前12項目中、5〜6項目ぐらいは比較的改善しやすい部分で効果も高いと思うので意識して改善を進めていこうかと思う.

『すべてのソフトウェア開発者が絶対確実に知っていなければならないUnicodeとキャラクタセットに関する最低限のこと（言い訳なし！）』

UTF-8とUTF-16があるのに、ひとまとめにしてUnicodeって呼ぶのは何でなんだろう？
なんてことを考えている人は必読.

Unicodeは文字コードの名前で、UTF-8・UTF-16は符号化の名前.

『第５章 やさしい機能仕様パート1: なぜわざわざ書く必要があるのか?』

仕様書を書くのはめんどくさいと言うけれども、自分を守るためにも必要なこと.
また、仕様書の修正はコストが安いけれども、プログラムの修正のコストは高いことを認識しておくこと.
ゲーム開発なんかの現場だと仕様書なんかは「(この先は)実際に動かしてみなければわからない」なんて言葉をよく聞くけれども、半分は正解で半分は不正解.
でも、正解と言った部分も『第１３章 ペーパープロトタイピング』や『第３４章 何ごとも見た目ほど簡単ではない』から学べる部分は多い筈だ.

『第９章 やさしいソフトウェアスケジュール』

仕事だろうが趣味だろうが、ソフトウェア開発にはスケジュールは必要だと思う.
仕事においては特に重要な要素となり得るが、「無理を通せば道理が引っ込む」とばかりに軽視されてしまう傾向があるのも確かだ.

スケジュールを管理する上で意外に忘れられてしまうのが、「当初見積もり」と「現在見積もり」を併記しておく必要があると言うこと.
自分の工数見積もりのスキルをアップするためには必須な項目にあることに加えて、「無理を通せば...」というタイプのマネージャの再教育のためにもこの項目は忘れてはいけない.

『第１２章 5つの世界』

私が住んでいる世界は、「ゲーム」...かな？
「ゲームソフトの開発はヒット指向」という点においては異存ないが、「ゲーム開発における大きな問題点は、バージョンがたった一つしかないことだ」とするのは時代遅れな印象を受ける.
ま、Joelさんはゲーム屋じゃないんだから気にすることでもない.

それぞれの世界にそれぞれの道理があるってことを理解しておく必要がある.

自分の世界に閉じこもっているだけでも、他の世界の話を鵜呑みにしすぎるのもよろしくないことだ.

『第１５章 射撃しつつ前進』

こういった本で、

私の１日の多くはこんな感じだ。
(1)仕事取りかかる。(2)e-mailをチェックしたり、Webをみたり、その他のことをする。(3)仕事に取りかかる前にランチをとった方がいいと判断する。(4)ランチから戻る。(5)e-mailをチェックしたり、Webをみたり、その他のことをする。(6)いい加減始めた方がいいと心を決める。(7)e-mailをチェックしたり、Webをみたり、その他のことをする。(8)本当に始めなきゃいけないと、再び決心する。(9)くそエディタを立ち上げる。(10)ノンストップでコードを書いていると、いつのまにか午後7:30になっている。

なんて書かれているのはちょっとおもしろい.
結局、生産性の鍵を握っているのは「ただ始めること」でしかない.

『第１８章 二文化主義』

Unixは、プログラマの人達に価値のあるプログラムを共有する文化.

Windowsは、プログラマでない人達にとって有益なコードに価値がある文化.

多角的に物事を把握するというのは、難しけれども重要なことだと感じた.

『第２３章 人のタスク切り替えは有害であると考えられる』

マルチタスクが効率が悪い理由はタスクのスイッチングコストが発生するのが原因だと考えていたが、本書を読んでスイッチングコストを0とおいてもマルチタスクは効率が悪いということを確認させられた.

日頃諸々の雑務に追われて仕事が思うようにはかどらないと感じている人には必読の部分だと思う.

『第２４章 あなたが絶対するべきでないこと　PART I』

職業プログラマをやっていると、人から引き継ぎされたプログラム(そして時に過去の自分の書いたプログラム)を書き直したくなる衝動にかられるものだ.
当然、私もそうだ.
だって、あのプログラムは読みにくくて、保守性に悪くて、性能が悪いんだもの...
でも、ぐっとこらえて踏みとどまることが必要な時もある.

関連するトピックとして『第３５章 「ここで発明されたものじゃない」症候群を擁護する』があるので、併せて読んでおきたい.
こちらは、車輪の再開発を行う場合の指標が示されている.

戦略上重要な機能であるならば、すべてを自分でそろえて、それを簡単に手放さないことが重要.

『第３１章 下っ端でも何かを成し遂げる方法』

激しく同感.
ここに書かれているようなことを実践してきたからこそ今の自分があるのだと思う.
新人のプログラマには是非実践して欲しいと思う.

自分が動いたからといって確実に何かを変えられるといった保証は無いけれども、周りを恨んでいるだけで確実になにも変わらない.

『第３６章 ストラテジーレター�: Ben & Jerry's 対 Amazon』

自分たちのビジネスモデルが、有機的な収益をあげるモデルなのか、急成長モデルなのかを把握することは重要.

成功しているベンチャー企業は急成長モデルをとっていることが多いので、あたかも急成長モデルが正しいという誤った認識が横行しがちだが、有機的な収益を上げるモデルというのも存在しているはずだ.

自分たちのとるべき戦略が、有機的な収益を上げるモデルなのにもかかわらずに急成長モデルのように振る舞うのはとても悪い傾だ.

ゲーム屋は、一発当たれば急激に成長する可能性はあるのは確かだが、根本的には有機的に収益をあげていくしかないと思う.

『第４０章 ストラテジーレターV: オープンソースの経済学』

あらゆる製品には、代替するものと補完するものがある.
発泡酒はビールの代替財だし、ガソリンは車の補完財だ.

企業活動は製品の補完財をコモデティ化しようとする動きを見せるため、自分が*何をビジネスにしようとするのか*ということを把握しておくことはとても重要なことだ.

通信会社は携帯電話をコモデティー化して、携帯電話を利用する際の通話料で儲けを出したい思惑があるけれども、携帯電話メーカーは通信料をコモデティー化してハードウェアのビジネスを行う必要があったんだと思う.

でも通信料がまかり通るのは、流れる情報に対する価値ではなく通信網にながれるビット量に価値があるってことを言っているんだよね？
コモデティ化が進むべきなのは、携帯端末じゃなくって通信料の方じゃ無くって？

この先コモデティー化が進むのは、どの部分なんだろう？
...なるほど、だからdocomoはi-modeといった閉じた世界を守りたかったわけだし、auにしてもsoftbankにしてもサービスへのシフトを考えているんだ.

このあたりは、次の読書課題とすることにしよう.