画家とソフトウェア開発者の共通点が沢山あることを教えてくれた本である。子供の頃から絵を描くことが好きだった自分が今ではソフトウェア開発者であり、この本を読んで思うところが多々あった。

印象に残った言葉をキーワードをもとに感想を書いてみる。

  • 神は細部に宿る
  • クールダウンの必要性
  • 協調開発の進め方
  • あるべき姿、究極のプログラムとは
  • Webアプリ
  • ベンチャービジネス
  • 良いデザインとは
  • 何でも屋のLisp
  • 継続の必要性
  • 再デザイン

神は細部に宿る

すべての見えない細部が組み合わさることにより、まるでほとんど聞こえないかぼそい声が幾千も合わさってひとつの旋律を歌っているかのように、ある種圧倒される何かが生まれる。

芸術作品やソフトウェアに限らず、本当に素晴らしいものは何であれ一目で人を魅了するものだと思う。そして、素晴らしいものには欠点がない。細部に至るまで一点の曇りがないのである。

クールダウンの必要性

エンストしてしまいそうな時のために、楽な作業を少し取っておくことは良いアイディアだろう。ハッキングの場合は、バグを取っておくのもいい。(中略)プログラムはxをするはずなのに、yをしている。どこでおかしくなっているんだろう。自分が最終的に勝利を収めるのは分かっている。これはまるで、壁を塗るくらいに気楽なことだ。

自分もプログラムに没頭することがしばしばある。熱中し過ぎて一日が一瞬のように感じることさえある。結果、自分の想像どおり動いてくれれば疲れは吹き飛ぶものだ。でも、上手くいかないときもある。そのときは、それまでの疲れがどっと押し寄せてくる。これからは、たまにデバッグ作業をするくらいの余裕をもって作業していかないと。。。

協調開発の進め方

あるコードが、特定の所有者を決めずに3人も4人もの人間にハックされると、それは共有部屋のようになる。雑然としていて見捨てられたような雰囲気が漂い、埃が積もってゆく。私が思うに、協調開発の正しい方法は、プロジェクトをはっきりと定義されたモジュールに分割し、各モジュールの所有者を決め、そして注意深く、できればプログラミング言語そのものほどに明快に設計されたインタフェースをモジュール間に定めることだ。

これはソフト開発をしている人は良く分かると思う。他の人が書いたコードはエラーが無い限り、多少アルゴリズムが最適でなくても訂正を入れにくいからである。きちんと壁を作り、第三者の立場から意見を言える状態にしておくことが大事。

あるべき姿、究極のプログラムとは

良いソフトウェアを書くには、ユーザがどれだけ何も知らないかということを理解する必要がある。ユーザは何の準備もなくやって来て、いきなりソフトウェアに向かい、マニュアルなんか読もうとしないだろう。ソフトウェアはそういう人が期待するように振る舞うべきだ。(中略)ソースコードもまた、一目でその内容が分かるものであるべきだ。

たしかに本当に素晴らしいプログラムは、全く何の知識も持たない、それこそコンピュータを触ったことのない初心者でも、すべての機能を操作できるものであると思う。故に、最高のハッカーには、人間工学も含めありとあらゆる知識を持つことが要求されるのである。ソースコードに関しても、筆者は「計算機プログラムの構造と解釈」(ピアソン・エデュケーション)の引用を提示することで、分かりやすく説明している。

「プログラムは、人々がそれを読むために書かれるべきである。たまたま、それが計算機で実行できるにすぎない。」
ユーザに対する共感だけでなく、コードを読む人に対する共感も必要だ。(中略)半年前に自分が書いたプログラムを見て、それが何をするのか全く分からなかった経験をした人も多いだろう。

コードは人間には理解しにくい、だから半年後に見ると動作内容が容易には分からない。だからこそ、注釈を付けていくのであるが、そもそも非常に高度なコンパイラ(文章の構造解析器)さえあればこんな手間は必要ない。たとえば「インターネットの○○サイトから天気情報を取得してきて、デスクトップに表示する」と日本語で書くだけで実際に動くソフトウェアを作ることができるのだ。これなら内容も一目瞭然である。実際に、こんなコンパイラができるのは当分先になると思うけれど、近いものは登場してきている。そもそも、プログラミング言語は英語である必要はなく、日本語で良いはずだ。まぁ、英語は同じ単語で別の意味を持つことが少ない、曖昧性の少ない言語であることや、グローバルで共通の言語であることも理由としてあるが。

Webアプリ

Webベースアプリケーションは、Webサーバ上で走り、Webページをユーザインタフェースとするプログラムだ。平均的なユーザにとって、この新種のソフトウェアはデスクトップソフトウェアより簡単で安く、どこでも使えて、信頼性も高く、しかもパワフルなことさえある。

最近はメールも動画再生もWebブラウザひとつあれば完結してしまうようになってきた。今までは、パソコンにソフトウェアをインストールして、時々バージョンアップをしたりするなど自分で全部管理しておく必要があった。でも、Webアプリなら専門の人がネットの向こう側でバージョンアップでも何でもすべてやってくれる。無料のサービスも次々と増えてきているし、携帯電話からでもパソコンと同じように使うことも可能だ。今後は基本ソフトウェア(OS)やハードウェアの性能はそれほど重視されず、ブラウザが快適に動くハードさえあれば何でも良い世の中になっていくだろう。

付随して、ユーザがネットの世界にいるということは、サービス提供者はユーザが今ソフトをどのように使っていることを知ることができ、より便利なソフトを開発していく手立てにもなり得る。

ベンチャービジネス

ビジネスに関しては、2つのことだけを知っておけばいい。ユーザが気に入るものを作るということと、使った金より多くの収入を得るということだ。

Webアプリに関するベンチャーであれば、開始資金としては50万円あれば十分だと思う。ネットワークインフラも安くなってきたし(最初はベストエフォード型でOK)。サーバも一昔前に比べると有り得ないくらい安いし。この分野で利益を上げたいなら、アイデアと、リリース&BugFix作業のスピード勝負になると思う。それこそ、そこら辺の素人でもアイデアさえあればすぐに作れて、ネットで簡単に公開できてしまう時代だから。だからこそ、著者は次のような言葉も残している。

もし私たちがソフトウェアに追加すべき機能を2つのうちから選ばなくてはならなくて、どちらもその困難度に比例した価値があったとしたら、常に難しいほうを選んだ。そちらのほうが価値が高いというだけでなく、そちらのほうが難しいという理由からだ。(中略)あなたが新しいアイディアを思いついてベンチャーキャピタルに投資をもちかけたとしたら、最初に尋ねられるのはそれを他の誰かが作るのはどれだけ難しいか、ということだ。言い換えれば、あなたと他の追跡者との間にどれだけ困難な領域が確保してあるか、だ。

いまベンチャーを起こし、作ったソフトが凄く人気を集めたとしても、簡単に実現できてしまうものであれば、次の日には大企業が作ってしまうよ。ということである。きついけれど、そこには何の価値もない。

良いデザインとは

文中で、作者は良いデザインに関する原則を述べている。

  • 良いデザインは単純である
  • 良いデザインは永遠である
  • 良いデザインは正しい問題を解決する
  • 良いデザインは想像力を喚起する
  • 良いデザインはしばしばちょっと滑稽だ
  • 良いデザインをするのは難しい
  • 良いデザインは簡単に見える
  • 良いデザインは対称性を使う
  • 良いデザインは自然に似る
  • 良いデザインは再デザインだ
  • 良いデザインは模倣する
  • 良いデザインはしばしば奇妙だ
  • 良いデザインは集団で生起する
  • 良いデザインはしばしば大胆だ

プログラムだけでなく、絵画や数式に至るまですべての事柄に対して適用できるのではないか。多少、似通っているものもあるが。Simple is best、単純で簡単に見えるものほど、作るのは難しいのである。良いものは長い間丁寧に扱ってもらえるし、長期間人々の記憶に残すことができる。また、製作過程で一旦壊し、一から再構築することも大事なことである。ソフトウェアを作っていると、途中で最初から書き直したくなってくる時期がやってくる。そこで、しっかり作り直せるかが、偉大な芸術家にになれるヒントになるのかもしれない。

何でも屋のLisp

著者はLisp使いだったらしく、以下のような特長を持つことを述べている。

  1. 条件式
  2. 関数型
  3. 再帰
  4. 動的型付け
  5. ガベージコレクション
  6. 式でプログラムが構成されること
  7. シンボル型
  8. シンボルと定数の木によってコードを表現すること
  9. 言語のすべてが常に在ること

9の文はちょっと省略しすぎなので説明。プログラムの実行に至るまでの流れは、ソースコードの”読み込み”からはじまり、プログラムを実行形式に変換する”コンパイル”を経て、”実行”される。通常のプログラミング言語では、このようなステップを辿るわけだが、Lispでは、これらのステップが明確に定められていない。つまり、実行中にコードを読んでコンパイルすることもできるし、コンパイル中に実行もできる。そして、8と9を組み合わせるとプログラムを書くプログラムを書くことができる。若干、日本語が気持ち悪いが、著者によるとLispのプログラマが日常的に行っている手法らしい。

継続の必要性

人々にメッセージが行き渡るには時間がかかるのだ。私のある友人は誰かに何かを頼まれても、1回目は何もしようとしない。人々はよく何かを思いつきで頼んで、後からそれが不要だったと分かることが多いと彼は知っているからだ。時間を浪費しないために、彼は3回目か4回目のリクエストが来るまで待つ。(中略)したがって、何か新しいものを発明した人は、人々がその価値に気付くまで、何年も根気良くメッセージを繰り返すことを覚悟しておかねばならない。(中略)人々があなたに注意を払うのは、あなたがそこにいることに気付いたときじゃなく、あなたがまだそこにいることに気付いたときだ。

メールを読むときによく使っている手なんで理解しやすかった。緊急度合いによるけれど、少しは時間を空けてから返信するようにしている。毎日数件ではあるけれど、訂正メールが飛んでくるものである。ソフトウェアを公開するときには、継続してバージョンアップを続けていくで、ユーザは改善要望を出す気になるだろうし、何より安心感があり、一度使ってみようと思うものである。

再デザイン

「最も良い書き方は書き直すことだ(The best writing is rewriting)」とE. B. ホワイトは書いた。良い作家は皆これを知っている。ソフトウェアについてもこの命題は真実だ。(中略)良いソフトウェアを書くには、2つの相反する考えを頭に置いておかなくちゃならない。若いハッカーの無邪気な自身と、ベテランの懐疑主義だ。(中略)希望と心配のバランスをうまく取れれば、それはあなたが2本の足で自転車を漕ぐように、プロジェクトを前へ押し進めてくれる。イノベーションの2サイクルエンジンを考えてみよう。最初のフェーズでは、自分はその問題を解決できるという確信に押されて、あなたは一心不乱に問題に取り組む。第二フェーズでは、あなたは自分のやったことを冷たい朝日の下で眺め、その欠陥をはっきりと目にする。

この本の中で最も好きな文章である。プログラムを書いていると途中で粗が目立ってきて、往々にして書き直したくなる気持ちになるのである。あ~、あそこはこうやって作っていた方がやりやすかったなぁとかね。その気持ちが抑え切れず、作り直したものは大抵上手くいく。

著者含め天才的なプログラマとは情熱と冷静さを兼ね合わせる人なのだと、この本を読んで分かりました。