本を読もう：『プログラマーのジレンマ』＋自分の経験談

アキヒトさんが紹介してくださった『プログラマーのジレンマ』、ようやく読み終えました。結構分厚い本なので荷物が多いときに持ち運べなかったのと、内容が濃いので時間がかかったのですが、プログラマーなら誰もが経験する内容が書かれていると思いました。

プログラマーのジレンマ
スコット・ローゼンバーグ著
伊豆原弓訳
日経BP社
ISBN978-4-8222-8380-3

プログラムは規模が大きくなるほど成功する確率が下がり、期間も予定通りにいかないものなのですが、私もまさにそのような経験を社会人になりたての頃に経験しました。すこし長くなりますが、書いてみましょう。

私は1986年の夏から今の会社でプリント基板設計用CADシステムの開発のアルバイトをはじめました。大学2年のときです。当時、X-Windowはすでにありましたが、CADに使えるほどの性能はとてもなく、専用のグラフィックエンジンを作ってCADシステムを作っていました。ミニコン(masscomp)やワークステーション(NEWS)でUNIXを使って作っていました。

1989年に今の会社に入社し、PLASMA-8800という名前の新シリーズの開発をはじめました。とはいえ、データフォーマットなどはそれまでのものを継承し、JRC製の結構高価なグラフィックエンジンを使うバージョンとして作りました。半年くらいで完成させたのですが、その頃ワークステーションのグラフィックが高性能になり始め、高価なグラフィックエンジンがないと使えないというのは売れない、ということで、PLASMA-8800/XというX-Window版の開発をはじめました。私ともう一人の二人で1年くらいで完成させ、社内での運用と外販をはじめました。ざっくりでソースコードが100万行、プログラム数180個という、かなり巨大なシステムですが、ユーザインターフェース以外は旧バージョンからそのまま移植したものも多くありました。ここまではデータフォーマットを基本的には継承しながら、足りない部分だけ拡張して構築した感じです。

外販をはじめると、本当にさまざまな要望が出てきました。PLASMA-8800/Xのデータフォーマットでは実現できない内容も非常に多くありました。なにしろこのデータフォーマットは、2000万円するUNIXのミニコンのハードディスクがたった80Mバイトだった頃に考えたフォーマットで、フラグはビットとしてちりばめられ、固定的で拡張性がないフォーマットでした。もっとも、当時はRAMも少なかったので、データはファイルを直接読み書きして動作するものも多く、こういうデータフォーマットにするのは仕方なかったのです。

そこで、1992年から、データフォーマットも全て考え直し、全く新しいPLASMA-9000を作ろうということになりました。開発メンバーはあいかわらず私ともう一人の2名です。そのもう一人のメンバーは今考えてもすばらしい技術者で、なにしろコンパイラやインタープリタも入社前から自作していたくらいのメンバーでした。彼と私で新たなシステムの構想を練り、当時としては・・・いやいや、今考えても相当ぶっ飛んだ仕様を考え出しました。

・データフォーマットはテキスト形式とし、構造的で自由に拡張ができる形式
　今で言うところのXMLみたいな発想です。
・システムはマネージャー・GUIモジュール・簡易言語モジュール・特定機能モジュールの連携で構成し、拡張性・汎用性を持たせる
　UIはGUIモジュールの編集機能でグラフィカルに構築でき、その動作はインタープリタの簡易言語で定義でき、特定機能ごとのモジュールをマネージャー経由でネットワーク連携させてシステムを構築するという感じで、モジュールはネットワーク越しに他のホストとも連携でき、今で言うところのエンドユーザーコンピューティングとグリッドコンピューティング（言い過ぎ）みたいな発想です。

ユーザは自分でシステムをカスタマイズでき、CADのみならず、どんなシステムでも構築できるフレームワークを提供するという大胆な発想でした。

こんなものを二人で作り始めたのですが、それでも当時は雑用仕事などはほとんどなく、相当開発に集中し、1年くらいでそれなりに動く状態になったのでした。途中で二人新入社員が開発に加わりました。

ところが、実際に設計で使ってもらうと、

・速度が遅い
・何でもできすぎて使いにくい
・カスタマイズなんかしたくない
・もっとシンプルなものが欲しい

と、コンセプトと逆の要求ばかり出てくるのです。速度が遅い点は非常に悩みました。当時はワークステーション(SparcStation2)といっても今考えれば性能はまだまだ低く、複数のモジュールを通信で連携させながら動くシステムは、やっぱりどうしても重たく、さらに汎用的すぎるデータフォーマットの編集機能の実現は技術的にも非常に困難で、どうしても処理全体が重たかったのです。機能もありすぎて使いにくいという、開発した側としてはがっかりするような反応でした。まあ、完全にプロダクトアウトの発想で作っていたのが原因です。

結局1994年まで試行錯誤を続け、ソースも概算で150万行を超え、汎用のプリント基板設計用のCADシステムとしては実用は無理、という認識になり、あるお客さんの専用CADシステムのベースには使われたり、社内のゴルフ練習常用の図面作成にも使ったりと、多少は活躍しましたが、3年もかけて使い物にはほとんどならなかったのです。

今考えれば、そもそもコンセプトの検討や仕様の決定を、若いプログラマーの二人が決めて突っ走った、というのが失敗の根本原因とすぐわかりますが、『プログラマーのジレンマ』に書かれているとおり、プログラマーは自分は成功すると信じて突っ走りますし、どうせ作るなら世界があっと驚くようなものを、と考えてしまうものです。PLASMA-9000に着手する前にすでに3世代くらいCADシステムを作ってきましたので、はっきり言ってCADシステム自体に対する興味より、いかに画期的なシステム形態とするかに目が向いてしまっていたのです。データフォーマットもはっきり言ってかなりオーバースペックでした。また、言い訳すれば、EDA関連のシステムはとても閉鎖的で、後発のシステムは既存のシステムとのデータコンバートができず、実は相当がんばっても、リプレースしていくのは困難だったのです。その嫌な記憶が今の「なんでもオープン」な思考のベースになっているのは言うまでもありません。ネットワークが好きになったのも「オープン」だからです。

その後、私も含めメンバーで出向に出たり、受託開発をはじめたりして、会社に迷惑をかけた分を取り返すのに苦労することになったのですが、唯一その後に役立ったのは、どの仕事をやっても「なんて簡単なんだ！」と感じることができたことでしょう。いまだに当時のCADシステムの開発を越える困難な開発には出会っていません。ピンポイントの技術ではもちろん大変なこともありましたし、プロジェクト進行自体が元請けさんやお客さんを含めて大変なことになったことはありましたが、あの「いつ終わるかわからない不安と、完成してもどういう結果がかえってくるのかわからない恐怖」は越えてません。

1996年には受託開発などで半期で3000万円以上の荒利を出す成績をたたき出し、出来高制のボーナスではじめて人に自慢できる額をもらえていましたので、1年半くらいでCAD開発販売ビジネスから受託開発ビジネスに見事に変身できたのですが、これはあまりにも複雑困難なCADシステムの開発で鍛えられたおかげでしょう。受託開発は、最初は小さいお客さん相手に苦労し、その後大きなお客さんの仕事の孫請けくらいでチャンスをつかんで、徐々に良いお客さんとお付き合いできるようになっていったのですが、毎回「日本シー・エー・ディーの開発力はおかしい」と言われるくらい、圧倒的な開発スピード・品質・性能で開発してきました。その背景には、「CADを作るのに比べるとあまりにも簡単な仕事ばかり」という思いがあったおかげです。

長々と書きましたが、実は先日リリースした不正接続検知システムIntraGuardian2の開発も、若いメンバーが同じように苦労していたからなのです。まあ、さまざまな制約や、周囲にうるさい人たちがたくさんいたので、昔のCAD開発ほどひどいことにはなりませんでしたが、やっぱりプログラマーは自分の腕試しに走る傾向があるものです。特に若くて腕のあるメンバーは。それを押さえ込むことはもちろんできるのですが、それではメンバーが成長できませんし、暴走させすぎても会社がひどいことになります。まあ、私も当時の大失敗がなければここまで成長してなかったと思います。

昔、当時の社長（現会長）が暴走している私を見ていたときの気持ちが良くわかる今日この頃です。。

ちょっと重たい話でしたので、ついでに軽い話も。。

メンバーが岩国出張みやげに、入手困難なものを買ってきてくれました。

「岩まん」です。予約しないと買えないほどのお菓子だそうで、がんばってGETしてきてくれました。

私も岩国には何度か行きましたが、錦帯橋はすてきなところでしたし、厳島神社もすばらしい、観光でも楽しめるところですね。もちろん、仕事で行ったのですが。。

まんじゅうというより、洋菓子ですね。パイの中にあんこが入っている感じです。たまらない美味しさです！
買ってきてくれたメンバーのブログ