個人的にとりわけおもしろかったのが、iPod がなぜクールなのかを扱った4章です。デザイナーのジョナサン・アイブ氏にインタビューして、 iPod のデザインで目指していたゴールとは、なぜ白なのか、といった質問をぶつけます。それらの回答もおもしろいのですが、特に印象に残ったのが、スティーブ・ジョブズ氏が自分のデザイン観についてアイブ氏に語ったという次の言葉です。

「人が最初に問題にぶち当たったときには、単純な方法で簡単に解決できるように見える。それは、まだ問題の複雑さを理解していないからだ。でも解決策が単純すぎたら，それはうまくいかない。そうしていったん問題の細部に足を踏み入れると、そこではたくさんの問題が複雑に入り組んでいることがわかってくる。込み入った問題のそれぞれに、手の込んだ解決策を考え出さなきゃならなくなるわけだ。たいていの人はこの段階で止まってしまう。確かにこういう方法でもその場しのぎはできるからね。でも、本当に優秀な人材はそこに留まらずに、問題の背後にある本質を見つけ出す。そして、美しくて簡潔明瞭で、しかも見事に機能する解決策を思いつくんだよ」

これはデザインに限らず、問題解決において共通する話だと思います。私が関わるソフトウェアの開発では、一見簡単にみえるような機能でも、実は実装するのが異様に大変で、調べれば調べるほど、あちこちをいじらないといけないことがわかってきて絶望的な気分になるということが多々あります。たとえばこんな感じです。

「これさあ。ちまちまファイルアップロードするの面倒だから、.zipファイルで一気に送れるようにできない？」「ああ、できると思いますよ。んーでもやってみないとわからないかも」「そのくらい難しいわけないでしょ」「いや、私の勘だとこれはやっかいなことになると思いますね。まあみてみますけど。えーと、ファイルのアップロードはここで処理されてるから、ここで zip を展開して、と。ああやっぱり、この先のロジックが全部、入力が１ファイルを仮定しているからそう簡単にはいかないよな。ここでループ回してもいいけど、ファイル多いとすごく遅くなりそう。かといってここでスレッド作るのもやりたくないなあ。そもそもこれ zip ファイルの中身が巨大だったらメモリすごい食うんじゃない？展開すると10GBみたいなゴミファイル入ってたらサーバ落ちちゃうし。ああ、zip ファイルにはディレクトリ情報が入ってるからそこみればファイルのサイズが事前にわかるか。ってここにウソの情報を書かれてたら終わりじゃん。んー、しかもこのライブラリ、段階的に展開するAPIが提供されてないし。じゃあプロセスサイズをリミットして別プロセスで開くとか？いやほんと、すごい面倒なんですけど」

というように一見簡単そうなことが実は激ムズで、うまく解決するには元のアイディアとは根本的に違うやり方（たとえば、バッチ的に要求を処理するキューイングシステムに投げて、結果を非同期的にユーザに戻すとか）が必要になったりします。

自分のやってることを振り返ると、あちこちいじくりまわして何とか解決する、というケースの方が圧倒的に多い気がします。問題の背後にある本質を理解して簡潔明瞭な解決策を見つけ出す、というのは非常に難しいことですが、こういう目標は忘れずに心がけておきたいものだと、くだんのジョブズ氏の言葉を読んで思った次第です。

まとめ

iPod が大成功したことは異論の余地がなく、本書は、なぜそんな奇跡のようなことが起きたのかを理解する上で助けになる一冊だと思います。今となっては iPod の成功は新鮮さがありませんが、やはり偉業だったのだなと再認識しました。

ちなみに、スティーブン・レヴィ氏の本はこれまでに『ハッカーズ』『暗号化 - プライバシーを救った反乱者たち』『マッキントッシュ物語』を読んでいます。他の三冊と比べるとこの『iPod は何を変えたのか?』は少しものたりない気もしましたが、十分に楽しめました。

ソフトウェアの複雑さが人間の扱える範囲を超えるという点では、個人というレベルではとっくに破綻しているので、集団として扱える範囲を超えるのはいつかという話になると思います。これについては複雑さの限界より、製品や組織の寿命の方が早くやってくるような気がします。現在、広く使われているソフトウェアもいずれ使われなくなる日が来るでしょうから。

そうやって長い時間をかけてソフトウェアの世代交代が進んだときに、新しい世代のものがどのように作られて、どのように複雑さを抑えこむことができるのか、あるいは結局、同じようなものになってしまうか、興味深いところです。

現状としては肥大化するコードと付き合っていかざるを得ないので、これは必ずしも悪いことではないと認めた方が精神衛生上よいなと、そういう意図で書いた記事でした。

数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい（具体的な数字は忘れました）といって、何千万行もある Windows NT を引き合いに出して、Squaek がいかにシンプルであるか等々と話し始めました。

一瞬、すごい！と思いましたが、よく考えてみると、実際に世の中で使われているのは Windows NT の方なので、実装がシンプルなことはそんなに重要なことなのか、と疑問に感じました。

広く使われるソフトウェアでは、次のようなループが発生します。

ユーザに使われる→もっとよくする→もっと使われる→もっとよくする→...

• Windows XP の SP2 以前のときはXXXというバグがあるので、回避するにはこうする
• プロセス起動時にオートアップデートが発生するとクラッシュすることが稀にあるのでこうする
• プロセッサが SSE3 対応のときはこっちの命令の方が速いのでこうする

一方で、あまり使われないソフトウェアの場合、上のようなループは発生せず、プロジェクトはすぐに終焉を迎える傾向があります。コードは小さいままです。

あまり使われない→もうやめよう→おわり

シンプルで使いやすいソフトウェアの実装はシンプルとは限りません。たとえば、ドラッグアンドドロップを実装するのは、ボタンを追加するより多くのコード必要とします。アニメーションさせようと思ったらもっとコードが増えます。こういった工夫もコードの肥大化を促進します。

プログラマから見れば実装や設計がシンプルなことに越したことはありませんが、ユーザから見ればどうでもいい話です。言ってみれば当たり前の話ですが、コードのことばかり考えていると、つい忘れてしまいがちです。

まとめ
ソフトウェアの肥大化について考察しました。ソフトウェアの肥大化は必ずしも悪いことではなく、広く使われるソフトウェアでは、ほぼ必然的に起こることだと思います。開発者であれば、肥大化を嘆くより、コードが使われていることをありがたく思ったほうが精神衛生上よさそうです。

ちなみに、肥大化と関係する話題で、プログラマがやたらとコードを一から書き直したくなる衝動、を戒める Joel 氏のエッセイThings You Should Never Do, Part Iもおもしろいです。このエッセイの翻訳は Joel on Software の書籍版に「あなたが絶対すべきでないこと PART I」という題で掲載されています。

エキスパート戦略

この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門性があれば、そう簡単に他の人に置き換えられることはなさそうです。

この戦略の問題点は、そういった仕事が常にあるとは限らないという点です。たとえば、コンパイラの専門家がコンパイラの仕事で活躍できる企業は限られているでしょうし、そういった会社の中でも、自分にとって最適なポジションにつくのは難しいかもしれません。また、分野によっては参入障壁が低すぎて簡単に追いつかれたり、そもそもその分野の市場価値がなくなってしまう可能性もあります。適切な専門分野で一流になり、よいポジションを確保し続けるのは簡単ではなさそうです。

ジェネラリスト戦略

幅広いスキルと柔軟性を身につけて、自分が活躍できるプロジェクトの幅を広げていくという戦略です。IT業界は時代に応じて、求められるスキルが変わります。また、ひとくちにプログラマといっても、さまざまな分野の仕事があり、必要とされるスキルは異なります。幅広いスキルと柔軟性があれば、その時々で最も必要とされているプロジェクトに加わり、経験を生かした活躍ができそうです。

この戦略の問題点は、差別化がしにくいという点です。エキスパートであれば、「この問題に取り組めるのは彼しかいない」という差別化が可能ですが、ジェネラリストだとそうはいきません。差別化がしづらい分、他の人に置き換えられる可能性は高いかもしれません。また、目下のプロジェクトに忙殺されていると、手持ちのスキルがいつのまにか時代遅れになってしまう危険性もあります。常にスキルを磨いて、生産的なジェネラリストであり続けるのは簡単ではなさそうです。

テクニカルリーダー戦略

技術に加えてリーダーシップのスキルを身につけて、テクニカルリーダーとしてのキャリアを築くという戦略です。複数人、あるいは複数のグループが関わる複雑なプロジェクトを遂行する上では、リーダーシップは不可欠です。適切な技術的判断ができる熟練のテクニカルリーダーは他の人に簡単に置き換えられることはなさそうです。

この戦略の問題点は、中途半端な立場になりやすいという点です。技術的な仕事を自分でもこなしつつ、チームを率いていくのは簡単な仕事ではありません。他のグループとの調整や議論、各種の会議への出席など、リーダーにふりかかる仕事は無数にあります。こうしたことに時間をとられすぎると、いつのまにか自分の時間がなくなり、手を動かすわけでもなければ、マネージャーでもないという、中途半端な状況に陥る危険性があります。その結果、自分の成果も中途半端なものに終わってしまうかもしれません。手を動かすこととリーダーシップを両立させるのは簡単ではなさそうです。

オーナー戦略

重要な製品や機能を手がけ、そのプロジェクトのオーナーとして君臨するという戦略です。たとえば、すべての自社製品で使われる共有のライブラリやシステムを開発して、その改良やメンテナンスを続けます。そのプロジェクトについてはオーナーが一番詳しいわけですから、他の人に簡単に置き換えられることはなさそうです。

この戦略の問題点は、長続きするプロジェクトはそれほど多くないという点です。長くヒットする製品はそれほど多くありませんし、ライブラリやシステムもある程度枯れてくると、やることがなくなってしまいます。設計の刷新など、大幅な変更を定期的に行わないと、すぐに飽きてしまうかもしれません。プロジェクトのオーナーとして君臨し続けるのは簡単ではなさそうです。

 イノベーター戦略

 よいアイディアをコンスタントに生み出し、プロジェクトを自分で立ち上げて実現していくという戦略です。自分で立ち上げたプロジェクトであれば、やる気もでますし、成功した暁には最高の評価が得られるでしょう。よいアイディアをコンスタントに思いつくのは、なかなか真似できませんから、そう簡単に他の人に置き換えられることはなさそうです。

この戦略の問題点は、アイディアが枯渇したら終わりという点です。次々とヒット作を生み出した作家でもスランプの時期はありますし、スランプから一生立ち直れない場合もありえます。時代に合わせて求められているものを見出し、アイディアを形にしていくには並々ならぬ才能と、日々の努力が必要そうです。イノベーターであり続けるのは簡単ではなさそうです。

セレブリティ戦略

この人はすごいというブランドを作り上げて、セレブリティ的な地位を確立するという戦略です。何かわかりやすい業績を持っている人は評価されやすいものです。そうした業績を積み重ねて組織の内外で一目置かれる存在となれば、何かと得をすることが多く、そう簡単に他の人に置き換えられることはなさそうです。

この戦略の問題は、評価と実態が必ずしも一致しないという点です。過大に評価されると、実態との落差が後から判明して失望させてしまうおそれがあります。また、調子に乗っていると無用に敵を作ってしまうかもしれません。とはいえ、特に組織の中では過小評価されるのは困りものですから、自分がやった仕事を正当にアピールしていくのは得策といえそうです。評価と実績をバランスさせて、うまくやっていくのは簡単ではなさそうです。

ハイブリッド戦略

 以上に挙げた戦略は相反するものではなく、組み合わせが可能です。たとえば基本はある分野のエキスパートだけど、実は他の分野にも詳しいというジェネラリスト的な要素もあれば、ひとつの分野しか知らない人では真似できない仕事ができるかもしれません。いわば二刀流の戦略です。

まとめ

 以上、思いついた戦略を挙げてみました。当然簡単な方法などなく、どれもなかなか難しそうです。他にもいろいろな戦略が考えられると思います。何か名案があったら教えていただければと思います。

以前に書いた記事で関係がありそうなもの：

• プログラマについて - 以前に生産的なプログラマについて考察しました。
• 年を取ると環境設定がどうでもよくなる現象 - いろいろ面倒になるものです。
• 研究と研究マネジメント - だいぶ昔に研究について何やら書いていました。
• 身近な人の偉大さは半減する - これも古い記事です。セレブリティ戦略を書いていて思い出しました。

• プログラミングの光景 (2007年度)
• BK通信 (2008年度)
• バッドシグナル通信 (2009年度)

個人的に割と印象に残っているのは以下の記事です。

• プログラミングの光景 - プログラマについて
  これは私が目指したいと思っているところの姿について書いた記事です。実践はぜんぜんともなっていませんが。。
• BK通信 - ブラウザのバッドノウハウ <form> 編
  BK通信はバッドな話題ばかりでしたが、なかでも _charset_ という隠しパラメータはこれはひどいと衝撃を受けた記憶があります。
• バッドシグナル通信 - チキンレース
  これは知人の間で一番受けた記事です。チキンレース的な状況はいたるところで発生しているのだと思われます。

またこの手のネタを思いついたらブログにでも書こうと思います。

WEB+DB PRESS Vol.55

posted with amazlet at 10.02.09

WEB+DB PRESS編集部
技術評論社
売り上げランキング: 13545

Amazon.co.jp で詳細を見る

一方、他のブラウザで表示すると、このような雪だるまが表示されました。これは私がデフォルトのフォントに設定しているメイリオの雪だるまです。これはかわいい。意外なところにも力が入っています。

MS Pゴシックはこんな感じでした。普通。。

他のフォントの雪だるまも気になるところです。

p.s.
他のフォントの雪だるま。見つけたら随時追加します。

• ヒラギノ角ゴW3 Pro
• VL Gothic (via twitter)
• Apple Symbols

(defun support-color-p ()
  (or (eq window-system 'x)
      (>= (string-to-number emacs-version) 21)))
(when (support-color-p)
  (cond ((eq window-system 'x)
         (set-face-foreground 'region "DarkSlateBlue")
         (set-face-background 'region "#ddccff")
         (set-face-foreground 'highlight "DarkSlateGray")
         (set-face-background 'highlight "PaleGreen")
         (set-face-bold-p     'highlight t)
         (set-face-bold-p     'region t)
         (set-face-foreground 'modeline "#222266")
         (set-face-background 'modeline "#ccccff"))
        (t   ; terminal
         (set-face-foreground 'default "black")
         (set-face-foreground 'region "blue")
         (set-face-background 'region "cyan")
         (set-face-foreground 'highlight "white")
         (set-face-background 'highlight "green")
         (set-face-bold-p     'highlight t)
         (set-face-bold-p     'region t)
         (set-face-foreground 'modeline "yellow")
         (set-face-background 'modeline "blue")))

設定ファイルにありがちな色の設定です。大昔に設定されたものと思われます。デフォルトの色で問題ないので、これらは削除です。

(autoload 'wl "wl" "Wanderlust" t)
(autoload 'wl-other-frame "wl" "Wanderlust on new frame." t)
(autoload 'wl-draft "wl-draft" "Write draft with Wanderlust." t)
(setq mime-edit-split-message nil)  ;; Don't split attachments

以前は Wanderlust を使ってメールを読んでいましたが、最近はブラウザで読むので使わなくなりました。

ちなみに、 Wanderlust は、~/share/emacs 以下に自分でインストールしたものを使っていました。Linux や Mac などのいろいろなマシンで、共通の Emacs の環境を簡単にコピーして使えるよう、~/share/emacs にいろいろつっこんでありました。

~/share/emacs を見ると、以下のようなものがありました。

apel bitmap egg elib emu flim liece lookup lsdb
mule-ucs riece sdic semi wl

このうち、現在でも使っているものは Lookup くらいなので、その他のファイルは削除することにしました。Lookup は Emacs 上で辞書を引くためのツールで、おそらく 1998 年頃から使っています。

(autoload 'python-mode "python-mode")
(add-to-list 'auto-mode-alist '("\\.py$" . python-mode))

昔の Emacs には python-mode が含まれていなかったので、python-mode.el を自分で入れていたようです。Emacs 22 には python.el が標準で含まれているのでもはや不要な設定です。

(autoload 'ruby-mode "ruby-mode" "Major mode for ruby files" t)
(add-to-list 'auto-mode-alist '("\\.rb$" . ruby-mode))

一方、ruby-mode はまだ Emacs に含まれていないようなので、キープです。

まとめ

この他にも、自分で定義してぜんぜん使っていなかった関数などをばっさり削除して、だいぶすっきりしました。物置の大掃除をしたような気分です。

export LV='-Ou8'
export PAGER='lv'

以前は Shift_JIS, EUC-JP, UTF-8 など、いろいろなエンコーディングのファイルが混在していたので、lv を愛用していました。が、最近のファイルは UTF-8 だけになったので less でよくなりました。

LANG=ja_JP.UTF-8 のように設定しておけば、 less で UTF-8 のファイルを表示できます。というわけで、PAGER=less に変更です。less なら大抵の環境で標準で入っているので安心です。

export CVSROOT=$HOME/cvsroot
export CVS_RSH=ssh
export RCSINIT=-zLT

CVSは使わなくなったので、これらの設定は削除です。最後の RCSINIT は何かと思ったら RCS が展開する $Id: ... $ という行でローカル時間を使うためのおまじないのようです。そういえば、 $Id: ... $ はカッコイイ！と思っていたものです。

export BIBINPUTS=":$HOME/share/bibdb:"
export BSTINPUTS=":$HOME/share/tex//:"
export TEXINPUTS=":$HOME/share/tex//:"
export TTFONTS=":$HOME/share/ttf//:"
export CMAPINPUTS="/usr/share/ghostscript/Resource/CMap//"

TeXの設定です。TeXもすっかり使わなくなったので、これらの設定は削除です。何やら昔は ~/share/tex にいろいろ入れてがんばっていたみたいです。

#  0:black 1:red,2:green,3:yellow,4:blue,5:magenta,6:cyan,7:white
export LS_COLORS='*.jpg=32:*.png=32:*.gif=32:*.bmp=32'
LS_COLORS="$LS_COLORS:*.avi=32:*.mpg=32:*.wav=32:*.mp3=32"
LS_COLORS="$LS_COLORS:*.tgz=31:*.lzh=31:*.zip=31:*.Z=31:*.gz=31:*.bz2=31"

元々はどこからかコピーしたものと思われる、 ls の色づけの設定です。どうでもいいので削除です。

export PERL_BADLANG=0

ロカールの設定がおかしいときに Perl が表示する警告を黙らせる設定です。最近の環境で困ることはないので、削除です。

case "$TERM" in
    xterm*|kterm*|rxvt*)
    ...
    ;;
    *)
    ...
    ;;
esac

環境変数 TERM に基づいて設定を変えています。kterm, rxvt にマッチさせるためにがんばっていますが、これらを使うことはもうなさそうですし、よく考えてみれば、if test $TERM != dumb で十分です。

などなど、不要になった設定を削っていったらだいぶすっきりしました。

まとめ

.zshrc の整理を行いました。ゴミが残っていても実害はあまりありませんが、余計なものがないほうが見通しがよくなるので、たまに棚卸するのは悪くないと思いました。

dynabook UX にしたのは、以下のような理由です。

• 作り・見た目がいい感じ
• キーボードが打ちやすそう
• RGBコネクタを搭載（ネットブックの中には外部ディスプレイ出力がないものがある）
• SD/SDHCカードスロットを搭載

少し触ってみて気になったのは、やはり画面が物理的に狭いこと（10.1インチ）、解像度が低い（1024x600）ことですが、ネットだけの用途ならこれで十分そうです。時代の進歩を感じました。

TOSHIBA dynabook UX/23JBL ネットブックPC PAUX23JNLBL コスミックブラック

posted with amazlet at 09.11.01

東芝 (2009-06-13)
売り上げランキング: 19510

Amazon.co.jp で詳細を見る

有効期限が切れたり、店がつぶれたり、といったリスクを考えて、こまめに使う方がいいと思っていましたが、早くお金を返してもらうという考え方の方がわかりやすくて強力です。

ポイントがもらえるより、その分安くしてもらった方がありがたいのですが、最近はたくさんの店でポイントを発行しているので、ポイントから逃れて暮らすのは難しそうです。

と言いつつ、ポイントプレゼントキャンペーンにつられて（新規入会 3,000ポイント+10月末までにカード2回利用で2,000ポイント）、楽天カード（ポイントにつられやすいのでアフィリエイトリンクになっています）を作ってしまいました。

が、これもよくみると、罠がいろいろあります。

• このキャンペーンに事前にエントリーしないとダメ
• 通常の新規入会特典2,000ポイントは受け取り申請をしないとダメ。申請すれば2-5日で付与される。
• 残りの分、(1,000 + 2,000ポイント) は年末しか使えない
  「本キャンペーン特典ポイントの3,000（1,000+2,000）ポイントは2009年12月20日（日）頃までに2009年12月31日(木）まで使える期間限定ポイントとして付与します。」

12月末の期間限定ポイントはいかにも使い忘れてしまいそうです。忘れないように気をつけないと、と思いつつ、余計な気苦労が増えた気もします。

最近読んだ、『まぐれ』という本によると、最適化するタイプの人（数パーセントの節税をするために住所を変えたりするタイプの人）は余計な気苦労が増えるので不幸とのこと。当たっている気がします。