決して最先端ではない、けれど日常生活で人びとの役に立っているIT技術を探していきます。

【書評】プログラマーのジレンマ

»

ベスト&ブライテスト』という本をご存知でしょうか。大学などで政治学を学ばれた方にはお馴染みかもしれませんが、New York Times のデイヴィッド・ハルバースタムが著した本で、米ケネディ政権がベトナム戦争の泥沼にはまっていく過程を追ったものです。「ベスト・アンド・ブライテスト」とは文字通り「最良にして聡明」という意味で、ケネディ大統領の下で政策決定に関与した優秀な人々のこと。そんな優秀なチームがなぜ誤りを犯すのか?という疑問について考える内容になっています。今日取り上げる『プログラマーのジレンマ』という本を読み始めたとき、真っ先に思い出したのがこの本でした。本書はさながら、プログラム開発版の『ベスト&ブライテスト』と呼べるでしょう。

あえて一言で言ってしまえば、『プログラマーのジレンマ』はよくあるデスマーチのドキュメンタリーです。しかし他の類似書と異なるのは、取り上げられているチームがまさに「ベスト・アンド・ブライテスト」であるという点。ロータスデベロップメント設立者/ロータス1-2-3開発者/OASF(オープンアプリケーション財団)創立者などなどの華々しい肩書きを持つミッチ・ケイパーが、同じく華々しい経歴を持つ天才プログラマー達(Mac OS開発者のアンディ・ハーツフェルドや、ネットスケープ創業時メンバーで「クッキー」考案者のルー・モントゥリなど)を集め、「チャンドラー(Chandler)」というPIM(Personal Information Management、個人情報管理ツール)の開発に乗り出すというストーリー。しかも予算は潤沢にあり、商用ソフトを開発しているわけではないのでリリース時期も自由、という恵まれた状況です。これで最良にして聡明なチームが失敗するはずがない――と思いきや。チームは迷走に迷走をかさね、本書の副題にある「夢と現実の狭間」でプログラマー達は苦しむこととなります。

現場が分からないマネージャー。無理な予算と納期を飲んでしまう営業担当者。気楽に仕様変更を要求するクライアント。よくプロジェクトマネジメントの教則本などでも非難されるこれらの要因が、チャンドラー・プロジェクトには存在しません。もちろん開発である以上、様々な制約は存在するのですが、それでも一般的なIT企業の開発者からしてみれば天国のような状況でしょう。にもかかわらず天才プログラマー達が泥沼にはまっていく姿からは、大規模なソフトウェア開発というものが非常に困難な仕事であり、類型化や定型化によってミスを避けることも難しいという現実が浮かび上がります。

もちろん彼らの失敗を反面教師にすることも可能であり、それが本書の書かれた目的の1つでしょう。しかし本書のちょうど中間付近、238ページから239ページにかけてこんな一節があります(長い引用になってしまいますがご容赦下さい):

さて、ここまで読んだソフトウェア開発者の読者は、「いいかげんにしろ。この本のやつらはありとあらゆる間違いを犯しているじゃないか」と見放して本を放り出している頃ではないだろうか。

そのようなプログラマーの多くは、「自分ならこんなことはしない。もっとうまくやれる」と考えていることと思う。

中にはそのとおりの人もいるかもしれない。

私自身、OSAFの仕事を一年間見てきて、「彼らはいつ進み出すのだ?どれだけ時間をかけるつもりだ?何が障害になっているんだ?」と疑問を持った。ソフトウェア時間の混沌とした沼地にのみこまれ、何をもっても加速できないように思われた。

チャンドラーのチームには、自分たちがどれほど道を逸れてしまったかわからないのだろうか。プロジェクトの軌道が曲がりくねるたびに、ケイパーは、あとで学んだことを事前に知っていたら、違ったふうに進んでいただろうと率直に認める。そしてため息をつき、肩をすくめて言うのだ。「いつもあとになればわかるんだ」。そして仕事に戻っていく。

ソフトウェアの歴史をひもといてみると、チャンドラーの遅々としたペースは決して例外ではなく、むしろふつうのことだ。この分野の実績をみると、ドライバーはみな違ったところから道を逸れるが、遅かれ早かれほぼ全員が溝にはまる。

自分の方がうまくやれるという自信がある人は、過去のプロジェクトで何度次のように考えたか思い出してほしい。「たぶんこうするべきだということはわかっている」。「こう」というのは、ソフトウェア開発のベストプラクティスの聖典に載っているどんな方法でもよい。「でも、今回は特別だ。特殊なケースなんだ」。アンディ・ハーツフェルドが言ったように、「典型的なソフトウェアプロジェクトなどない。プロジェクトは一つひとつ違う」のだ。

実際、ケイパーらが犯したミスには信じられないようなものもあります。しかしチャンドラー・プロジェクトに参加しているプログラマー達は素人ではありません。開発経験が豊富な彼らでさえ、どうしてチームの迷走を避けることができなかったのか――本書はその明確な答えを用意してはくれませんが、「こういう場面ではこうすれば大丈夫」と鵜呑みにするのではなく、どんなに優れたチーム・恵まれた状況であっても「銀の弾丸などない」と肝に銘じること。彼らの経験から学ぶというのは、そういうことだと思います。

というわけでプログラム開発に携った経験のある方々には、嫌な思い出をよみがえらせてしまうこと請け合いなのですが、胃をキリキリさせながらでも是非読んで欲しいと思います。「ああ、こういうシチュエーションあるよねー」と思わずニヤリ(ムカッ、でしょうか?)とする場面が多々ありますよ。また開発経験が無くても読めるような文章になっていますので、開発者達と付き合わなくてはいけないという立場の方々にもお勧め。特に181ページからの「ギーク」に関する解説は、目を通しておくと面白いと思います。

【○年前の今日の記事】

インドネシア人に看護される時代 (2008年5月22日)
人物検索エンジン"Spock"を試してみた (2007年5月22日)
隠れたユーザーを探す (2006年5月22日)

Comment(5)

コメント

これは面白そうな本ですね!
早速注文してみました!!

小俣さん、コメントありがとうございます。
非常に面白い本でしたので、ぜひお楽しみいただければと思います。ただ僕は、過去のイヤな思い出が頭をよぎって、度々イヤな汗をかきましたが・・・(笑)

こんにちは
ようやく半分くらい読みました。
いやー、プログラマーとして「そうそう!」とうなずいてしまう内容が多いのですが、客観的に考えるとほとんどが常識外れなんですよねぇ。
とくに、再利用するより作ってしまえ、は、まさに自分やうちの一部メンバーたちにも当てはまる部分で、でも、再利用が好きなメンバーたちより底力があるので、判断が難しいところです。
残り半分もワクワクしながら読みます!

小俣さん、コメントありがとうございます。

再利用のくだりは考えさせられましたね。僕もプログラマー時代、「探すより自分で作った方が早い!」と考えてしまうタイプだったので、再利用が進まない理由に納得してしまいました(納得しちゃいけないんですが)。結局「銀の弾丸などない」で、ケースバイケースで判断していくしかないのでしょうね。後半部分もお楽しみ下さい!(どんどん辛くなりますよw)

こんにちは。
ようやく読み終えました。。
自分が社会人になりたての頃の状況を思い出しましたので、ブログに書いてみました!

コメントを投稿する