プログラマ必読の書---お薦めの本：Joel on Software

プログラマやプロジェクト・マネージャ必読の書といわれる本です。私もようやく読み始めました。英語版で読んでいるのでなかなか進んでいないのですが、うなずけることばかりです。日本語の本と英語の原書へのリンクを張っておきます。

Joel on Software, Joel Spolsky著

この本は、著者Joel Spolskyのブログ "Joel on Software"を編集加筆したものなので、実はWeb（英語ですが…※）を読めばだいたいのことはわかってしまいます。しかし、画面上ですべてを読むのは大変なので、私は本を買って読むことをお勧めしたいと思います。
※日本語訳も一部あるようです。

さて、コーディングのことというよりは、プロジェクトマネジメントに近い話が書いてあるこの本をなぜプログラマがなぜ読むべきなのか？ということなのですが、私はこれはプログラマが効率をアップさせるために、ひいては無茶を言ってくるマネージャの論理を粉砕するために（もっとも粉砕したところで、往々にしてスケジュールには影響しなかったりしますが（泣））必要なことが書いてあると思うからです。

残念なのは原書に載っているものは8年前だったりするので、今やJoel Spolsky自身が「これは読まないで！」とWebに書いてあるようなものもあります。たとえば、

Painless Software Schedules, March 29, 2000

と

Evidence Based Scheduling, October 26, 2007

ですね。本に載っているのは "Painless ..." の方なので、Joel Spolskyいわく学んで進化したスケジューリング方法を合わせて読んでみるとよいと思います。

とはいえ、今開発の現場で7年前の教訓でさえできていないところがあるのではないかと思うのです。マーフィーの法則によれば

"If it can happen, it will happen."
「起こる可能性のあることは、いつか実際に起こる。」

だそうですから、きっとどこかの現場ではDeath Marchまっただ中というプロジェクトがあるかもしれません（あまり想像したくありませんが…）

私が一番コーディングに費やす時間（コーディング量ではないところに注意）が多かったと思われる1990年代には、まだWindows95は出てきていませんでした。表計算ソフトはExcelはMacintoshではあったものの、DOS版のはMultiplanという高ーいソフトがあったくらいでしょうか…当時流行りだったLotus1-2-3のような表計算ソフトを、Joelがいうようなやり方でスケジュール管理に使おうなんて思ってもみませんでした。これを知ってたら、多少なりとも改善できたのになぁ…と思うわけです。

もっとも、その当時、バージョン管理ソフトなんて知らなかったし、汎用機で開発していたので、その辺の仕事は全部ライブラリアン任せでした（遠い眼）

つまり、自分で進捗管理するためのツールはOASYSで作った表がすべて。作って提出したらそれでおしまいで、日付を数値として扱って、どれだけの日数を費やして、どれだけ予定から遅れているかor進んでいるか、などを振り返るようなことはありませんでした。

あるプロジェクトにかかわった時は、最後のほうは、ほとんどデス・マーチといってよい状態でしたから（そういえば当時はデス・マーチなんて言葉はなかった）、自分で細かい進捗管理なんて余裕はなかったし（爆）プロジェクト全体はともかく（管理者でないから手に負えない）、もうちょっと自分のことを管理できるスキルがあったら、体を壊すなんてこともなかったなぁと、しみじみと思い出します。そういう発想さえなかったこと自体、ワーク・ライフ・バランスをいかに崩していたかという証左でしょう。

何かを改善しようと思ったら、今の言葉でいう「見える化」（この言葉は私は好きではないので「可視化」といいかえたいと思います）をしなくてはいけないと思います。それが「Evidence Based Scheduling」であったり、「可視化」の作業だったりするわけです。何をどうすればよいかという話は、ぜひJoel Spolskyの書いた本Joel on SoftwareやBlog "Joel on Software"を読んでみてください。

「可視化」に絡めて、私には心配なことが一つあります。この「可視化」やら「Evidence Based」で仕事をするためには、なにかしら開発者の作業logを取る必要があります。私のように一人プロジェクトで自ら率先してするのはいいのですが、ある程度以上の規模の会社だと、逆に労務管理が行き過ぎたりとかする心配もあります。あくまでも、取得したlogは、プロジェクトの生産性の向上にのみ使われるという了解があって成り立つものだということを、運用管理する人は肝に銘じてほしいなと思います。悪意のある管理者は、コンピュータのシステム上では何でも出来てしまいますから…

そうそう、本題とはちょっと話が横にそれますが、プログラマなど実際の作業をする人は、先ほど述べたような作業logを取られていることの潜在的な危険性もあることをよく理解して、言い訳のできない内職などはすべきではない、ということをよーく考えてほしいと思います。就業時間中や大学の講義やら演習中に、全然関係ないWebサイト（たとえば、Mixiやら人に見せられないWebサイト）を大学や会社のネットワークから覗きにいったりしていませんか？そういうことをしている人に親切心から注意すると逆切れされたりすることもあるのですが（私は、そういう人に限って注意した時に逆切れしたり、あとから別件での文句をいうが多いことに、演習や講義を担当してはじめて気がつきました…彼or彼女らは自分のしていることが分かってないのでしょうか？）それって、大学や企業の管理者にはバレバレだってことを、理解しているのでしょうか？大学だったら真面目にやってない証拠と教官に理解されて、場合によっては単位を取れなくてもおかしくないでしょうし（悪質な場合は退学だってありうる）、企業だったらクビになりかねません。（アメリカではE-Mailは管理者がすべてフィルタにかけて、怪しい人をチェックするそうです。こういうことがあると、産業スパイなどの嫌疑をかけられても申し開きをするのは難しそうです。）

生産性の向上だけでなく、自分のための危機管理（過労死を労災申請するときには、この日報や作業ログが重要な証拠と成り得ます）という意味でも、日報やら日々の作業ログは自分で自覚的に取るべきだと思いますが、いかがでしょう。