Lispとハッカー
正直言うと、Lispは10年くらい前に一度一通りなめただけで、「なんでこんな使いづらい言語を有り難がる人がいるんだろう」と思って放置していました。
こんな僕は当然、ハッカーを名乗る資格も語る資格もないのですが、最近Lispをもう一度勉強しようといろいろな本を読んでいます。
そのきっかけはこの本
- 作者: ポール グレアム
- 出版社/メーカー: オーム社
- 発売日: 2005/01
- メディア: 単行本
Lispハッカーとして著名なポール・グレアムの本で、彼はLispを使って実際にWebサイトを作り、Yahooに買収され、Yahoo Storeになるなど、実際にLispで商業的成功を収めたという、珍しい人です。
ハッカーと画家、ブログの抜粋らしく、前半は退屈な部分も多いのですが、後半になるとぐんぐん面白くなります。
いかにして彼が世間と戦ってきたか。ライバルが一年かけて作った実装を一日で追加できたか。その武器はLispなんだと。
全ての高級言語はLispに向かっているのだと。
実際、最近話題に登るような言語、JavaScriptやRubyの特徴とされるいくつかの機能は、確かにLispがもともと持っているようなものが多いです。
僕が個人的に面白いと想ったのは、Lispは開発されたのではなく「発見されたのだ」という表現。
Lispはもともとプログラム言語としてではなく、ラムダ算法の計算モデルを論文で表現するために発明されたもので、考案者のジョン・マッカーシー自身もこれで実用的なプログラムが書かれることを想定していなかったといいます。
そもそも僕がなぜLispに興味が持てなかったのか、いま思い出しましたが、記号ばかりでなにが書いてあるのかわかりにくく、しかも方言が多くてライブラリに関するドキュメントも全て英文で、まあもちろん、一般的に動作する処理系が高校時代に手元になかったのも原因ですが、要するにそのとき最も興味のあったゲーム開発、とりわけプレステで動くゲーム開発に全く使える見込みが無かったというのが原因でした。だいたい、LISPで書いたコードがどうやってマシン語になるのか解りにくかった。それもこれも、これは人間の側からみたプログラムで、機械の側から見たプログラムではなかったのが原因だと思われます。
機械の側から見ると、マシン語をどんどん抽象化していくのが発展の方向性です。
だから、純粋な機械語を英略語(ニーモニック)に直訳してアセンブリ言語、数値計算をやりやすくしてFORTRAN、もっと解りやすくしてPascal、BASIC、それをさらに抽象化してC言語、それにオブジェクト指向っぽい機能を付け足してC++、メモリ管理を抽象化してJava･･･というように発展してきました。
マシン語大好きッコとしては、C++ですら許せなかった時期があったくらいですから、Javaに移行しようというのも随分勇気がいることでした。
そもそもなぜマシン語大好きッコになったかと言えば、BASICで書いたプログラムがあまりに遅かったため、当時の非力なハードを限界まで酷使しようと思えば、当然、マシン語の力に頼る必要があったからです。要するに3Dのゲームが作りたかった。
当時の僕は3Dのゲームが作れない言語なんか全部オモチャにしか見えなくて、そのための最短距離をずっと探していました。別にマシン語が使いたかったというわけでもなく、それが最短だった。LISPでも原理的には同じことができたはずですが、道のりが遠すぎたのでしょう。
現在はLispの方言の一つといわれるSchemeの実装のひとつ、GaucheでOpenGLのライブラリなどが公開されているので、その気になればLispで3Dゲームを実装することができます。
C言語野郎のまま家庭用ゲーム機のプログラマになって、それが生業になってしまったので、もうナチュラル・ボーン・マシン語人間。マシンの都合でしか物事を考えられない身体に。
ところがLISPは違う。まるで逆。
数学上の概念からスタートして、人間がどうやって思考をまとめてアルゴリズムの形にするか。人間から出発した「思考のまとめ方」をどんどんトップダウンしていったのがLISPの実装。だから機械語と完全に一対一で対応しないのです。
学生時代も、UnixよりもDOSで作業することの方が圧倒的に多かったので、EMACS-LISPの恩恵を受けることもなく、大学の授業もマジメにでていなかったのでそもそもUNIX環境を日常的に使うこともなかったため、せっかく面白い言語を学ぶ機会をみすみす手放していたのでした。大学はやはりマジメに通っておくべきだった。
三十路になって改めてLispを眺めてみると、これほど美しい言語はないかもしれない、と評価が180度変わりました。
まあこれは、もう、とにかくC言語大好き、マシン語大好きッ子だった自分が、PHPみたいな疑似言語を生業にするまでに丸くなったことの副作用かもしれません。
要するに社長になってみて初めて、「手早く書けた方が効率が良い」という当たり前のことに気づきました。
それまでは「相手よりも一枚でも多くの三角形を描画する」とか、「競争相手よりも一マイクロ秒でも早くHTMLを返す」とか、そういうことに血道を上げていたので、とにかくオーバーヘッドになりうるものは全て切り捨てていたわけで。
しかし実際に社長になってビジネスというものを根底から見直してみると、そもそも、相手より数秒処理が速いことは、経営効率を何ら向上させないのです。
待ち行列問題を考えてみても、サーバが二倍の速度で動作するよりもサーバを二倍の数に増やした方が結果的に多くのリクエストを処理できます。特にいまのサーバマシンはCPUパワーよりもバス幅やメモリ・ストレージアクセスの方がボトルネックなので、CPU時間をどれだけ節約してもバス待ちでサーバが仮眠状態になる時間が延びるだけです。
そうしたら短く簡単に書けるプログラムを沢山書いた方が良い。今のプログラムを2倍高速化する間に、マシンが2倍速くなって1/2のコストになっている可能性の方が高い、すなわちそれは4倍の効率化が自動的に行われるということです。
ということに今頃気づいて、近年はPHPやRuby、Pythonなども一通りかじってみたのですが、導入の簡単さではやはりPHPに軍配が上がってしまいました。最もダメそうな言語だけど、最も手軽だったからコレでいいやと思ってしまったのですね。実際、プログラムは最も早く完成します。javaなら「よーしやるか」と気合いをいれるまでの時間も含めて1日かかりそうな仕事が、PHPなら1時間で終わる。これならPHP使いますよね。
しかしPHPを使い込んでくると、「やっぱりこの言語はダメなんじゃないか」という思いもまた強くなってくるのです。
なにしろライブラリの名前に一貫性がない。
PHP3とPHP4とPHP5の間にろくな互換性も確保されていない。
PHP3で書いたコードをクライアントから引き継ぐと、もうぐちゃぐちゃでそのままではPHP4では絶対に動作しませんから。これは結構致命的です。
ではポストPHPとなると、候補はPerl、Python、Rubyのどれかとなりそうな予感がして、一通り調べたのですが、PHPよりも見た目の開発速度が上がるような気がする言語が凄く少なかったのです。
学習時間も考慮すると、どの言語も学習に時間が掛かります。この点、PHPは本当にアッという間にくだらないプログラムを書く程度には覚えられるので、誰かが書いたコードを見て修正するのがとても簡単。もちろん、それはコードがごく短い場合に限定されるのですが。
さらに、以前ここでも書いたように、PHP以外の言語を選択するとなると、今のところ趣味の問題として処理されそうなことがあまりにも多いわけです。例外はPerlくらいかな。mixiも使ってます、というのは言い訳としてでかい。
しかしPerlに移行するんならPHPとあまり変わらない気もしたり。
PHPの醜さはとにかく行き当たりばったりで発展してきたように見える、その増築構造にあるような気がして、では増築に最も耐性のある言語はなんですか、という話になったとき、もしかしてそれはLISPか?と思ったわけです。
たとえばLISPの場合、言語構造がこれ以上ないくらいにシンプルです。
覚えることも実は極端に少ない。
ただしいくつかひどい専門用語があって、たとえばcarとかcdrとかなぜその名前なのか、どうしてそうなっちゃってるのかわからないものが予約語だったり、tという、そのまんまな、いかにも変数に使ってしまいそうな文字がtrueを意味する予約後だったり、nullとnilという、似て非なる予約語(しかも他の言語とは意味が違う)が出てきたりと、「わざとやってるのか?」と思うくらい紛らわしい予約語もいくつかありますが、慣れてしまえば忘れてしまえるくらいにシンプル。
むしろtrueをtrueと書かずにtと書けることの喜びの方が大きいかもしれません。
また、LISPはANSIで定義された標準言語で、PHPのように会社の都合によって変わったり、PythonやRubyのように作者に万一のことがあればそれ以上発展するのが難しい言語とも違います。
まあなによりLISPは「スクリプト言語」ではない、本物のプログラミング言語です。LISP自体の大部分がLISP自身によって書かれています。そのうえ、やりたければマシン語にコンパイルも出来ます。ただ、それはLISPをLISPらしくないやり方で使う愚かな方法と呼ばれるかもしれませんが。
ボール・グレアムは「ハッカーと画家」の中で、「百年後の言語」という章を用意して、それを夢想してみようと語りかけます。
機械の都合ではなく、人間の創造力で発展させ、継続的に使える言語。
グレアムの主張によれば、言語にはそもそも優劣があるハズで、そもそも優劣がなければマシン語またはアセンブリ言語とPHPなどの汎用言語は等価ということになってしまう。実際にはそうではないから言語の優劣があるのだと。
時代時代で言語の流行が変わるのは、要するに、後の時代になった方が「より優れた言語」が生まれていくからだと。
その中でLISPは、FORTRANの次に生まれた高級言語でありながら、FORTRANとともに現在でも実用的に利用されている極めて珍しい言語です。
それがWebの時代にも通用するものだということを、グレアムは自らがViaweb(後にYahooに買収されてYahoo Store)というキラーサービスを開発して証明してみせました。
ではなぜLISPがマイナーなのかというと、単に「難しそう」に見えるからではないでしょうか。
カッコが多すぎて解りにくい。
普通のテキストエディタで書いたらかなり厳しい。
ところがEMACSのLISPモードで書くと、ビックリするくらい綺麗に書けます。
ほとんど迷いません。
EclipseにもLISP環境が最近リリースされたのですが(CUSP
)、これもEMACSとひけをとらない操作性です。
まあ今後どんな言語をメインにするか検討するのも重要なことなので、まずはこのLISPをもう一度覚えてみようか、と真っ先に購入したのが同じくグレアム著の「ANSI CommonLisp スタンダードテキスト」
- 作者: ポール グレアム
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2002/08
- メディア: 単行本
なんでこの本をもっと早く読まなかったんだろう。
その言語を本当に愛している人が本当に解った上で解説する本って素晴らしいです。
言語の本というと、その言語の考案者が書くのがバイブル化するのが通例ですが、それだとどうしても他の言語との差異を強調するに留まり、「なぜその機能が便利なのか」「どのくらい便利なのか」ということについてはあまり強調されません。
もちろん、それはその言語を作った人があまりに思い入れたっぷりにそういうことを書くと、教科書としてはちょっとアレなので、ある意味で抑圧されて書いているのだと思います。
けど、グレアムはいろいろ差し引いて見ても心の底からLISP信者。LISPが他のプログラムよりなぜ素晴らしくて面白いのか、二ページ目で早くも解説しています。
Amazonの評価は決して初心者向けではない、みたいなものでしたが、LISP初心者の僕としては最初の出だしだけで引きつけられました。
言語解説の"スタンダードテキスト"としては出色の面白さではないでしょうか。
LISPの強力な機能。そしてグレアム自身が「オブジェクト指向なんか凌駕する」と呼ぶLISPの強力な再利用のための仕組みについて、ジェットコースターのように進みます。
この本、久しぶりに読んで得をしたと思える名著です。
LISPでWebサービスを作りたければ、いまはGauche+Kahuaなどの国産処理系やCLISPにはFastCGIパッケージが含まれているなど、いくつか選択肢がありますし、画像処理より記号処理に近いWebサービスにはもしかするともってこいかもしれません。
Kahuaを使うと、他の言語ではなかなか実現の難しい継続ベース(と言う言葉も最近知った)のWebプログラムもごく自然にできます。それにしてもKahuaはLeopardでうまくコンパイルできないので、なんとかして欲しいところです。
七人のサムライと百人の野武士。シニカルに前向きな奴ら
昨夜の"iモードパーティ二次会"は予想通り大盛り上がり大会で、帰宅したのは午前6時。
しかし、みんな年を取ったのか、昔にくらべると朝まで頑張る参加者は少なめでした。
「俺たちが作ってきた歴史を大事にしよう」
誰ともなしにそう言いだし、自主的にパーティが開かれる。
ケータイメールの転送だけで参加者を集めて、数日で100人も集まってくる。
しかも主催しているのは、いまや転職してドコモの某競合企業の舵取りをするKさん。
それでもみんなiモードが大好きで、というか、もう大好きという言葉が当てはまらないくらい好きで、みんなにとってiモードが本当に大切なものだから、ずっとずっと守っていきたいと思っている。そんな集まり。
「どこかの代理店の営業マンが"俺ケータイに命かけてますから"って言うのは、嘘っぽいし、見てて痛々しいよね。ここに来てる連中は、誰一人としてそんなことは言わないと思う」
「"ケータイ?まー仕事だからね"とシニカルに嗤うよ」
「おれたちにとってiモードは家族なんだよ。家族に面と向かって"愛してる"なんて言うのはアメリカ人だけ。俺はもちろん仕事だからiモードをやってる。愛してるなんてガラにもなくて恥ずかしくて言えない」
「けど、iモードはとっても大切なものなんだ。俺たちにとって」
「メジャーリーガーにバットをどれくらい愛しているかって聞いたら、"バットはただの道具だ"と言うだろうね。おれたちにとってのケータイも同じ」
黎明期の有名なサイトを"実質的に"創った、プロデューサーだけが集まって、自分たちにとって大切なものに思いを馳せる。
「波伝説が2万人で自慢してた時代が懐かしいな」
「釣りゲームも5万人で大騒ぎだったよ」
「某社の株なら売るほど持ってるよ。紙クズ同然だけど」
「夏野さんと松永さんが、へんてこな電話を売り込みに来てさあ」
「某端末の在庫処分には苦労したよ」
本当を言うと、本来、社会階層が違う人たちが集まっている。
キャリア、起業家、上場企業重役、クリエイター、販売店、流通。
収入も違えば価値観も違う。本来は商売敵、同じ社内でもライバル。
けれどもとにかく彼らは前向き。
かといって熱病にうかされたような、お題目をもごもご唱えるような、そんなヤバイ前向きさではなくて、もっとずっとシニカルな前向きさ。スマートかつクレバーでなければ戦えない。かといって驕らない。みんな根拠のない自信がある。涙と汗とで掴んできたささやかな成功がある。
「だいたい、おまえがあんな端末を出したせいで、俺たちがどれだけ苦労したと思ってんだ」
「だけどいい電話だったろ?」
「そりゃあな」
たった7人で始まったiモード開発の歴史。リクルートからドコモへ"とらば〜ゆ"した松永真理さんは「7人のサムライ」と呼んだ。
- 作者: 松永 真理
- 出版社/メーカー: 角川書店
- 発売日: 2001/07
- メディア: 文庫
かつてサムライの末席だった男が、いまは実質的な戦略を仕切っている。
本来、キャリアとコンテンツプロバイダはお互いの利害を求めて駆け引きをする対象。
彼らがサムライならば、僕らコンテンツプロバイダは野武士だった。
実際、ケータイコンテンツのパイオニアとして知られるサイバードの求人広告には長らく「脳みその詰まった野武士の集団です」と書かれていた。
あらゆる業界から集まったエキスパート。新規事業に投入されるのは常に才能を持った若手だった。そうでない場合もあったかもしれないが、レースには残れなかった。
実は、iモードのサイトを作るのは、技術でも資本でもない、とんでもなく高い壁が存在した。
それは「コンテンツ開拓全国会議」
ドコモ社内で毎月開かれるイベントで、全国のドコモのコンテンツ担当者が80人集まり、全員の承諾を得ないとコンテンツプロバイダの企画は承認されない。
企画が承認されないということは、商売がまるでできないということ。
我々コンテンツプロバイダにとっては死活問題。しかも採択率は1〜5%と言われ、あるプロバイダなどは
「20くらいの企画を出して、ひとつも通らなかったときは愕然とした」
と当時を振り返る。
企画といっても、お手軽なものではない。
コンテンツ企画は、ふつう100ページ程度の膨大な資料を要求される。
「企画書の厚さが採択率を上げるポイント」
という、まことしやかな噂まで流れた。実際、ある時期まではたしかにそうだった。
こんなものは一朝一夕に書くことはできない。
だから、企画書をひとつ創るのに軽く一ヶ月はかかる。それを20本も一気に提出したこと自体も凄まじいが、それが全部拒絶されたら、20人月ぶんの損失である。笑えない。
なぜここまで高い障壁が用意されているか、それはとにかく「エンドユーザを失望感から守る」という崇高な目的があった。
僕は最初、
「うちのゲームは面白いから、パケ代を払ってくれるユーザが沢山でるはずですよ」
と売り込んだ。
「そんなことをしたら、ダイヤルQ2の二の舞になってしまうよ」
と真っ向否定された。夏野さんは最初からかなり長期的な視点でコンテンツプラットフォームを捉えていた。並大抵のサラリーマンには出来ない芸当だ。なにしろ彼は本気でそれを信じていた。iモードがいまのように生活の必需品になること、最終的にケータイがお財布になること。10年前は完全に夢物語でしかなかったことを信じていた。
しかも、恐ろしいことに、彼はいまよりもずっとiモードが成功すると信じていたと思う。
1兆円ものケータイ課金市場を創り出しておいて、まだ不満なのだ。それでいて給料は中小企業の社長並みでしかない。これは労働組合が強いからだ。
とある外資系企業のCEOは夏野さんを評してこう言った。
「You're slave」
野武士は彼の夢に乗って大金を稼いだ。
しかし夏野さん自身が大金を稼いだわけではない。これだけの巨大市場を独創し、旧態依然とした巨大企業にベンチャーのカルチャーを持ち込み、感化し、熟成し、増大させていった。夏野剛という男のスケールの大きさを想像すると、未だに足がすくむ思いだ。
とはいえ、実際、キャリアとCPとの衝突は何度もあった。けれども、その繰り返しのなかで、確実にお互いを認め合い、尊重し合う信頼関係が生まれていった。
「あいつらにゲームの何がわかるってんだ。おれの企画にケチをつけるなよって思ったよな」
「でも俺たちだって電話のことはなにひとつ知らなかった」
「結局、両方正しかったわけだ」
彼らはびっくりするくらい前向きだ。
たとえば、こんな質問をしたことがある。
「有り得ない話だけど、もし来年からケータイが法律で禁止されて、おれたちの業界がまるごとなくなったらどうする?」
同じ質問を、昔別の既得権益業界でしたことがあったけど、そのときはこうだった。
「そんなことは有り得ない」
いや、だから有り得ない話をしてるんだってば。
そういう答えが出てきてしまうのは、要するにそんなことは想像したくもないからだ。自分の安心の拠り所が、業界やスペシャリティに依存しているのである。職種にも依るかも知れないが、クリエイターというのは実は驚くほどメディアの制約を受けているのである。
ところが、モバイル業界の古株に同じことを聞くと、みんなが口を揃える。
「別のメディアを探すか、俺たちが創るか、ま、どうにでもなる」
ケータイで稼ぎつつも執着しない。
野武士、山師、そんな有象無象。魑魅魍魎が集まるから、この業界は面白い。
とにかく前向き。シニカルに前向き。
あんな何も出来ない環境で商売ができたんだから、他のことだって出来るはず、という根拠のない自信が、彼らにそう言わせる。
この業界で職がなくなって本当に困る人は少ない。
転職したり、独立したりする人もユニークだ。
実を言うと初期のモバイルに関わった人間で、金儲けが目的で仕事をしている人は、たぶん一人もいないのだ。
金儲けが最大の目的だったら、そもそもモバイルみたいな小さい市場に参入してこない。
僕らですら、モバイルがここまで拡大するとは信じ切れなかったくらいだ。
9年前、1999年の春、ハドソンの創業者で、プログラマーとしても高名な中本伸一さん(当時常務)と、六本木のラビアンローズの前でこんな会話をしたことを思い出した。
「中本さん、実は僕、MSの仕事やめようと思うんです」
「どうすんだ?」
「僕は大学も出てないし、3Dプログラマとしては三流です。だからやめようと思います」
「何言ってんだ。お前から3Dをとったら、何も取り柄がないタダの生意気なガキじゃねえか」
「僕、来週から電話屋になります」
「デンワぁ?デンワって、モシモシハイハイの、あの電話か?」
「そうです。携帯電話向けのゲームを創りたいと思います」
「やめとけ。そんなものが商売になると思ってる馬鹿は、世界でお前くらいだ」
10年前にケータイコンテンツに投資するというのは、これくらい馬鹿げていると思われていたわけで。後は運でしかなかった。
強敵と書いて"とも"と読む。そしてiモード9周年おめでとう記念日
実は今日、2月22日はiモードの生まれた日。
9年前、まだ右も左もわからなかった22歳の僕がiモードに出会って、夏野さんに出会って、天地がひっくり返るほどの衝撃を受けた日。
- 作者: 夏野 剛
- 出版社/メーカー: 日経BP企画
- 発売日: 2002/07
- メディア: 単行本
蛇足ですが、この本にちょうどそのときの夏野さんから見た僕との邂逅記録が載っています。
それから10年。
iモードは本当にいろんな人を儲けさせる最強のツールになりました。
昨夜はiモード業界の古い友人とひさしぶりに酒を酌みかわしました。
彼は、9年前は敵でした。
当時の彼と僕とは同じ市場で一、二を争うコンテンツプロデューサー。それまでオリジナルコンテンツでは無敗だった僕のゲームが、彼の指揮する大ブランドにやすやすと抜かれてしまったときは悔しいというよりも清々しいほどでした。
当時100万人しかいなかったiモードのオリジナルコンテンツというニッチなフィールドで、手応えのある相手。本気で物作りに賭けてる相手というのを確認して、悔しい、困ったというよりも僕はゾクゾクするように嬉しかった。
当時のiモードのゲームプロデューサーはとにかくとんでもない怪物みたいな連中が多くて、彼も務めていた会社では若手ナンバーワンのホープと言われていて、そいつが戦場をプレステからケータイに変えて戦いを挑んできた。生き馬の目を抜くようなゲーム業界にくらべると、どちらかといえば牧歌的だったケータイゲームの世界に、戦国時代が訪れた。そういう相手です。
血で血を洗う戦い。倒れるまでゲームを作って、それでも「あいつはさらに上を行くかも知れない」という不安がぬぐえず、脳から血が滴り落ちるような感覚に陥るほど考えに考え抜き、戦い抜いた。
その当時のライバル達は、自分の同僚や部下なんかよりもよほどお互いのことが分かり合える。年に一度しか合わなくても、何年も合わなかったとしても、とても強い絆で結ばれているのです。
何年かして、僕が独立したときに、真っ先に声を掛けてきてくれたのは昨日飲んだ彼でした。
彼は老舗のゲーム会社の辣腕プロデューサー。僕は成功したベンチャー企業を上場直前に退職したばかりのヒネクレ者。
暇つぶしに本を書いたりとかして。
- 作者: 清水 亮
- 出版社/メーカー: 翔泳社
- 発売日: 2002/09
- メディア: 単行本
社会が僕という人間の評価をどうすべきか迷っているときに、会社から切り離して僕という人間を真っ先に信じてくれたのはかつての最強の敵。
あの頃の仲間達とは、今でも時々会う。
仕事をするときでも、遊ぶときでも、不思議な連帯感がある。
毎年、2月22日はドコモがホテルの宴会場を借りてとてつもなく盛大なパーティが開催されるのだが、9周年目の今年、なんとドコモはパーティを自粛。あろうことか忘れていたらしい。
その知らせを聞いて、残念に思った僕は「二次会だけ開催したら?」と誰ともなしに言った。
気がつくと、総勢100人弱が参加する「一次会なしの二次会」が開催されることになった。
「みんなと会えないなんて哀しい!」
そんなこと、誰が言うともなしに、ケータイメールの転送だけで、100人が集まった。凄いよね。みんなドコモとかそっちのけだもの。
初期のiモードパーティは金融機関や新聞など、いわゆる「モバイル専業」以外の会社を入れても500人程度だったから、その1/5が参加することになる。
みんなケータイが好き、というよりもケータイ業界が大好きで、仲間が好きで、そこの戦友達と酒を飲むのが死ぬほど好き、という連中。
今夜ばかりは会社の枠を超え、利害や対立を超え、業界の古狸と猛者達が朝まで飲みまくり暴れまくるモバイル業界で年の一度のお祭り騒ぎ。
僕にとってはスティーブ・ジョブスの講演よりもずっと重要な日。
iモードちゃん、9歳、おめでとう。
※10周年って間違って書いちゃったけど9周年でした
Web価格早見表を見て就活とグッチを思い出す
「業種が絞れない? だったら給料の高い業種を選びなさい」
そんな衝撃的なことを言うのはもちろん僕ではありません。ニューヨークの草刈機と怖れられたヘッドハンターの白川義彦です。
残念ながらこの人は実在しないんですけど。
就職活動漫画「銀のアンカー」に出てくるメンター役の人です。
- 作者: 三田 紀房, 関 達也
- 出版社/メーカー: 集英社
- 発売日: 2007/03/23
- メディア: コミック
三田紀房氏の漫画はどれも激しくて大好きです。ある意味、ビジネス版カイジというか。
この漫画は就職活動に悩む学生をなぜか超一流のヘッドハンターである白川義彦が指南し、学生達が自分探しに決着をつけていくという話です。
「営業が出来ませんなんて言う奴は就職するな!」
「迷ったら給料の高い会社へ行け」
「世の中カネだ」
学生が読むには刺激的すぎる内容ですが、これを読んでいて、最近はてブで話題の○○円ならどこまでできる!? ウェブサイト制作の相場早見表を思い出したわけです。
まず一巻の終盤で主人公は
「給料で決めろと言われたって、人生にはやりがいとか、充実感とか、もっと大切にしたいことはある」
と悩むわけですが、ふと立ち寄ったコンビニで、168円の値札をついたお菓子を手に考え込みます。
「これを168円で売るとどれだけ利益が出るんだろう」
するとコンビニの商品の陳列棚が戦国時代さながらの戦場に見えてきて、なぜ業種によって生涯賃金に5億円もの開きがあるのか、ということを想像してみるようになります。
要するに、儲かる業種、競争の少ない既得権益の業種、国策企業が圧倒的に安定していて、故に給料が高いのではないかと主人公は思うわけです。
そんなことを頭に置きながら、このWeb制作単価早見表を見たら、「この業界、やばいんじゃないの」と思いました。
でももっと驚いたのは、この早見表に対するはてブのコメントです。
「高すぎる!」
逆に僕は「こんなに安かったら大変だな」と思いました。
他の記事によると、web屋の相場が公開。高いとか安いとか、全く議論ならない本当の理由(どうでもいいtypoだけど、"web屋のネタ帳"がCMSをCSMと誤記するのはいかがなものか)を見ると、20万円くらいのサイトが相場らしく、お客様によっては5万~10万円でWebページを作れると思っているのだとか。
このレベルになると、もうパンフレットとか、名刺とか、そういうものと変わらないですね。
これとは全く関係なしに、クルマでの移動中で良く若い社員と話しをするのですが、
「僕たちが10年、20年と会社を続けていくためにはどうすればいいか」
というテーマについて話をしていたときに
「結局のところ、お客様のお役に立つ仕事、お役に立つ方法を考えていくしかない」
という結論に至るわけです。
「世の中には、人の役に立たずに儲かる仕事はひとつもない。B2Bに限定すれば、お客様を儲けさせて自分も儲ける商売以外は成功しない。会社はツールに徹するべきだ。
GoogleもYahooも電通もテレビ局も、広告というツールを提供する会社だし、楽天はEコマースというツールを提供する会社。ハワード・ヒューズの両親が一代で莫大な富を築いたのも、ヒューズ・ツールズ社という、採掘用機械の会社だった。
ソフト業界でマイクロソフトは何故儲かるのか。世界で最も汎用的なツールを販売しているからだ。
映画制作の会社、例えばスピルバーグのユニバーサル映画だって、"映画"というコンテンツを創り出して、それを上映すると映画館が儲かる、という意味では映画館が儲けるためのツールを提供しているのだ。
ゲーム会社だって、ゲームソフトを開発することで、流通が儲かり、ゲームショップが儲かるし、ゲームセンターが儲かる。
我々のモバイルCMSをお客様に買っていただけるのは、そうすることで儲かるからだ。
Eコマースサイトの経営で月に100万円の利益を出すのは並大抵のことではないけれど、モバイル公式サイトなら簡単だからだ。
そして、お客様が儲かっている限り、我々は存在を赦されるのだ。お客様がさらに儲かるように、僕らは日夜工夫して努力しなければいけない」
モバイルの公式サイトを20万円で受注する会社はたぶん存在しません。
なぜならHTMLを書いて終わり、ということには永久にならないからです。
キャリアとの折衝や、極めて厳しい審査、日々変化する課金システムや端末の仕様の変動。
こうしたものに柔軟に対応していくためには、「キャリアの空気を読む」能力が不可欠で、これは長い時間をかけて培った経験と人間関係、要するに信頼と実績でしか生まれません。
そうした会社、実績のある会社に頼むと、正直高いです。20万円どころか200万円でも門前払いでしょう。
しかし、結局のところ儲けの近道となって、そういう会社に注文が殺到するのです。
だから他の業者がどんなに安い価格を提示しても、その何倍もの価格を提示する経験豊富な会社が受注を勝ち取っていくわけです。
それは要するに、ある種の既得権益です。
PCのサイトの多くが、どちらかというと看板やパンフレットの役目か果たさないのに対し、モバイル公式サイトは直接エンドユーザから情報料を頂いて儲けを出すことが出来る。この違いは大きいです。
前者は単なる広告宣伝費ですから、体力のない会社、要するに日本の企業の90%くらいの会社は広告宣伝に掛ける予算なんか取ってないか、あっても最低限に抑えたいと思っているはずです。だからせいぜい20万円くらいなのかもしれません。
後者は収益を産む新規事業ですから、そこに使うのは広告宣伝費ではなく事業投資です。
事業投資で初期費用をケチって失敗するくらいなら、沢山の賭け金を積む、というのはごく自然な発想と言えます。
モバイル公式サイトの年間予算はPCサイトの少なくとも10倍、それでも収益を産むのだから、収益に繋がっているかどうかがわかりにくいPCサイトよりもずっとお金は払いやすいということになります。PCサイトの場合、お金は出ていくだけですが、モバイルサイトの場合、悪くても収支トントン、良ければお金が増え続けるわけです。
これが僕がモバイルに拘っている理由でもあります。
モバイルは地味だからみんなあまりやりたがらない。
Web2.0とか、CSSとか、カッコイイからみんなやりたがる。
けど、みんながやりたがる仕事は単価が下がっていくのです。価格競争に巻き込まれていく。
その点、モバイルは地味で、故にやりたい人が少ない。さらに経験と人脈、実績がものを言う。
開発の内容自体はPCサイトより遙かに複雑で高度。MovableTypeやワードプレスみたいなオープンソースのCMSでお手軽に構築できるような代物はひとつもない。全てがオートクチュール。UEIがCMSパッケージではなくCMSソリューションを提供するのもそういう理由で、パッケージを売っておしまい、という商売ではなくて、サイトごとの特徴をきちんと反映できるCMSに変幻自在に変えていかないとニーズを完全に満たすことはできないわけです。
ある意味で、こういう表を公開しただけでブクマが1000もついてしまうというのは、それだけこの業界の人が多いんだろうなと思いました。僕からすると対岸の火事のようですが、似たような仕事だけにモバイル業界に飛び火する可能性もなくはない。
けれども、結局、開発費で相見積もりをとって、とにかく安い方に発注する、というやり方の商売では、結局稼げない。雪国まいたけは高いけど美味しいから売れるわけで。
かのグッチオ・グッチが掲げていたスローガンは
「価格は忘れるが、品質は生涯残る」
どんなに高くても、逆にどんなに安くても、値段というのは忘れてしまうものです。
会社はWebサイトの制作費なんか、期が変われば完全に忘れてしまう。それが時給1000円のバイトにつくらせたものだろうと、20万円で発注したものだろうと。
けど、自分の担当するWebサイトは毎日のように見るわけで、そのときそれがショボイと、「なんだかなあ」という気分になるわけです。
そのうちそもそも爆安価格で発注したことすら忘れて、「やっぱあの会社じゃダメだ」と結論づけて結局別の会社にまた相見積もりをとることになる。
これじゃあ安売りした方も浮かばれないわけです。
だからうちは値引きはしません。その代わり、予算にあわせて機能を削って頂く。
価格を削ると品質にダイレクトに跳ね返ってしまい、結局お互いが不幸になるのです。
よほど無謀な予算を組まなければ、結局はきちんと作られたものの方が良いに決まっているのです。
そもそも私たちのお客様はリピーターが圧倒的に多い。売上の8割はリピーターです。
だから新規営業担当が居ない。それはそれで問題ですが、それでも会社はてんてこ舞い。
なぜリピーターが多いのかというと、儲かっているからです。私たちの提供するツールを使って、きちんと儲かるところまで持って行く。儲からなかったら、ご相談に乗る。
急拡大してしまったから、会社にいろいろとひずみはあるのですが、そういうことも含めて、品質を高める努力と対応をし続ける。重要なのはまずお客様が儲かること。そのお手伝いをさせていただいて、私たちの仕事を確保すること。これが上手く回る必要があるわけです。
品質は残るわけですからね。
画期的なアイデアをひねり出すためのブレインストーミング、5つの鉄則
誰でもサラリーマンから独立して会社を作る場合、なにかひとつ自分の「ウリ」がないといけません。それもできれば、他人に一発で説明できるようなキャッチフレーズの形になっていると最高です。
僕の場合はそれが「プログラムが書ける企画屋」でした。
残念ながら僕はプログラマとしては一流になることはできませんでしたが、企画職に専念するようになってから、いくつかヒットを出すことができるようになりました。滅多に参加しませんが、いわゆる"企画コンペ"で負けた事はありません。
そういうわけで僕にとってアイデアをひねり出すというのは日常的なことなのですが、企画屋の部分に注目されると、単なるアイデアではなくて「画期的なアイデア」というものを求められる、期待される、という立場になってしまいます。
今週は、週の最初からずっといろいろと「画期的な」アイデアを考える必要性に迫られて、あれこれ工夫することになりました。さすがに月に一度くらいなら「画期的な」アイデアを思いつく事もありますが、一日ひとつの「画期的」アイデアを考えつくのは相当難しい。
再び自分が困った時のために、今回「やはりこうするしかないよな」という鉄則というか、教訓を並べておきます。
- リラックスせよ
- 音楽をかけろ
- 普段行かないところへ行け
- 人を集めて美味いものを食え
- 一気にアイデアをまとめよ
これ、順番があります。
僕は上から順番にやります。
■第一段階 リラックスせよ
まずはリラックスです。
できるだけ裸足、できればゴロ寝できるような環境を探してください。
お金に余裕があるならシティホテルを借りて昼間から一人でゴロゴロしてください。
とても空しくなります。
お金に余裕がなかったら、朝日を見にドライブしたり、海を見に行ったり、露天風呂で全裸になったり、とにかくリラックスして自分を解放してください。
心のデトックス、というか、アイデアの神が降りてくるための準備を行うのです。
そのために、まずリラックスしましょう。
都内のリラックススポットとしては、大江戸温泉やラクーアなどのスパリゾート。お台場公園などの海の見えるスポット、横浜ベイブリッジやレインボーブリッジや海ほたるなどの海に囲まれたスポットがお勧めです。ある意味、水口さんが砂漠に行くのと似ています。
お腹が空いたり、眠かったり、イライラしていたりしたら絶対に良いアイデアは出てきません。
あらゆる欲望を満たし、「いつ死んでも悔いはない」というくらいにリラックスするのが良いと思います。
■第二段階 音楽をかけろ
十分リラックスしたら、その状態でなにか音楽を聞いてください。最初はクラシックで良いと思います。モーツァルトやドヴォルザークなどがいいでしょう。
しかもなるべく管弦楽がいいと思います。
- アーティスト: ロストロポーヴィチ(ムスティスラフ), ボストン交響楽団, 小澤征爾, ドヴォルザーク, チャイコフスキー
- 出版社/メーカー: ワーナーミュージック・ジャパン
- 発売日: 2000/06/21
- メディア: CD
だんだん頭が起きて来たら、ピアノを使ったものを聞いても構いません。
この段階でギターやジャズピアノ、テクノみたいなのはやめたほうが無難です。
好みの問題もあると思いますが、いきなり激しい音楽を聞くと、突然脳がもとの状態に戻ってしまい、リラックスした意味がなくなりそうです。
管弦楽の奏でる納豆のように尾を引くなめらかな旋律とともに、自分の意識に今回のテーマをぼんやりと問いかけてみましょう。
だんだんやる気が出てくるはずです。
■第三段階 普段行かないところへ行け
僕は月曜日は大崎ゲートシティの喫茶店、火曜日は東大医学部のカフェテラス、水曜日は東京ドームホテルのバーに行きました。
普段行かないところへ移動すると、今までのものごとを違った視点から見つめることが出来ます。
リラックスするときには広いところへ行きましたが、エンジンがかかってきたら高いところへ行くのが僕は好きです。上記で挙げたほかには、六本木ヒルズ、丸ビル、溜池山王パークタワー、パークハイアット、ロイヤルパークホテルなどです。
ずっとオフィスの机の前に座っていて、思わぬ画期的なアイデアがホイホイでてくるわけはありません。
この段階は単なるイニシエーションです。自分の脳や感情をクリエイティブなモードへと演出していくのです。
まだクラシックでもいいですが、場合によっては激しい音楽を聞いても大丈夫です。
ノートPCを忘れずに。
もちろんただ行くだけではダメです。
テーマを決めて、アイデアをいくつも考えましょう。
このとき、画期的なアイデアを考えようとしてはいけません。
そんな簡単に画期的なアイデアを思いつくなら、みんなやってるはずです。
この段階ではまだ情報を集めたり、自分の中でテーマを咀嚼するのです。
それがどんなに馬鹿げていたり、ありふれていたり、実現不能なものだったりしてもとりあえずは書いてみます。GTDと同じで、アイデアは一度書いてしまうと脳の別のところに記憶されます。
とにかく最初に書くのはものすごく解りきった事です。
クライアント様が居て、その要望を満たさなければならないのであれば先方の要望を自分なりに咀嚼して、3つ程度の項目にまとめます。最終的には
「要するに、○○を××したいのだ」
という要素まで絞り込みます。これが「ゴール」です。
■ 第四段階 人を集めてうまいものを食え
自分なりに十分な時間と知的資源を使ってアイデアの端緒を掴んだら、次の段階に進むことが出来ます。
次の段階はより重要で、美味いものを食べながら人と話をすることです。
アイデアをぶつけ合う必要があるので、これは社員にしかできないことです。また、秘密の話をするのであれば、会社で食べるか、個室のある店で喋る必要があります。これがブレインストーミングになります。
自分で十分アイデアを練っているので、ブレインストーミングの焦点はブレません。
お酒は飲まない方が望ましいと思いますが、飲みたければどうぞ。脱線しそうになったら誰かが止めないと行けません。
ファシリテーター役の人はみんなの言ってる意見をまとめつつ、ちゃんと方向性がずれないように誘導する必要があります。
食べるものはなるべく美味いものがいいです。
なぜなら、ブレストは長時間やっていると脳が疲れて来て、食べ物を欲するからです。
できるだけ長い時間ダラダラと食べるためには、できるだけ美味いものでないと持続しません。
焼き肉や寿司、すき焼きなど、なるべく解りやすいご馳走がいいと思います。
席もゆったりしたところが良いでしょう。
また、ブレストに呼んだ人たちも、美味いものが食べれるなら喜んで参加するようになります。
ブレストに呼ぶ人たちは、できるだけ本来の業務とかけ離れている人が良いです。
僕は大学生のアルバイトや、総務やデザイナなど、普段企画と直接関係ないことをしている人を集めてブレストをすると一番良いアイデアが産まれるように思います。
このときのルールは、一般のブレストのルールで言われるように「反対意見を出してはダメ」などという狭量なものであってはいけません。
全体主義社会みたいなやり方ではうまいアイデアは浮かばないと思います。
十年ほど前、とある大企業の社内ブレストに呼ばれたときに仰天したのですが、「さあブレスト開始します。では左から順番にアイデアを出してください」という進行で、合計20人もの人が順番にアイデア(らしきもの)をひたすら言って、一周する頃には時間がなくなっている、という型式のものがありました。
「みんなに意見を聞かなきゃ」ということなのでしょうが、みんな考えるのが面倒なので「○○さんと同じで」とか「○○さんの意見に同意します」とか、無難なことしか言わなくなって全く時間の無駄です。たまに意見が出ても、おそろしく平凡なものしかでません。これは、ブレストを開催する人が、企画を自分でよく咀嚼せずにいきなりブレストを開催しているのが原因です。
ブレストの人数は、少な過ぎると意味がなく、多過ぎるとブレストではなくアンケートになってしまいます。
最低5人、最大でも20人にした方が良いでしょう。
ブレストの冒頭で、自分が考えた「平凡・馬鹿げた・実現不能」な企画のリストをかいつまんで説明するだけで、同じ意見が出てくるのは防ぐことが出来ます。
また、アイデアを考えるのに時間制限を設けると実はいいアイデアが出やすくなります。
人は
「なにか面白いこと言って」
と突然言われても、
「えっ・・・えっと・・・」
と口ごもってしまう事が殆どです。
しかし
「10分間、○○に××を組み合わせるとどんな面白いことがおきるか考えよう」
と言うと、一生懸命考えるようになります。
また、10分間というのはひとつの題材について議論するには短すぎる気もするのですが、全員の脳が活性化していれば十分長い時間です。
それに、最初の5分くらいで、いわゆる「ありそうなアイデア」は全部出てしまいます。
そのときふと気が緩みます。
「さすがにもうないだろう」
ところが、実は本当の目的はこれから5分を過ごさせる事です。
10分間、同じ題材について集中的に考えるのはかなりの重労働です。
一日8時間仕事をしていても、10分間、それまで考えた事もなかったようなことについて考えを集中するというのはとても疲れます。
慣れない参加者は五分くらい経過すると
「もうアイデアでないから次に行こうよ」
と言われることもあります。
そのときに絶対許してはいけません。
「ダメだ。このテーマであと5分考えるんだ」
すると、人はヒマなので一所懸命考えるようになります。
「もうダメだ」と思ってから3分くらい経過すると、山を超えて次のアイデアが浮かぶようになります。長時間思考には驚くほどそういう効果があるのです。
この10分考えようという方法は、7人未満なら10分間で雑談ベースで、それ以上なら、ポストイットみたいな紙を配って思いつく端から吐き出してもらうようにします。アイデアを図で描いてもらう方が望ましいです。
この10分のアイデア出しは脳のマラソンといってもいいほど疲れます。
しかし間髪いれずに次の話題に移ります。
やはり最初の数分は解りきった答えしかないようですが、後半5分に驚くほど画期的なアイデアが浮かんできます。
しかし間違えないでください。
画期的なアイデアを考えるのは、参加者の誰かではありません。
それを聞いた貴方なのです。
参加者は、この場合、貴方のブースターでしかありません。
参加者がどんな天才で、素晴らしく画期的なアイデアを提案したところで、企画者の貴方が理解できなかったら全くの無駄です。
逆に言えば、貴方が参加者とのやりとりのなかで画期的なアイデアを思いつかなかったらこのブレストはまるっきりの無駄ということです。
もし万が一無駄に終わってしまったら、全く別のメンバーを集めてもう一度開くしかありません。
しかしそれは本当に最後の手段です。
だから絶対にアイデアをつかみ取るつもりで、みんながお酒を飲んだとしても自分は我慢しましょう。
第五段階 一気にアイデアをまとめよ
さあついに最終段階。
ブレストで掴んだ画期的なアイデア、成功へのヒント、そうしたものが全て集約されたメモが手元にあるはずです。
会社に戻ったら、そのメモを一気にアイデアまでまとめあげます。
もし、一気にまとめあげることができなかったら、一気にまとめあげることができるようになるまで、そのメモをもとに自分で別のアイデアを考えます。
とにかくこれは一気にやらないとダメです。
ブレストの後に飲み会を設定するなど言語道断。
とにかくせっかく活性化した脳を休める事なく、休憩も挟まず、一気にアイデアの形にします。
PCが手元になかったり、マウスなどいろいろな環境が揃っていなかったら、紙とボールペンでもいいので一気にアイデアをまとめてください。
ここが上手く行けばほとんど成功したと言っても過言ではありません。
他人が絶対に思いつかないようなアイデアの完成です。
アイデアをまとめる時の注意点としては、なるべく平凡にまとめるというものがあります。
企画屋の経験が浅い人は、「とにかく斬新なものを」と気負いすぎて、宇宙電波を直接紙に印刷したようなアイデアをまとめてしまうことがありますが、これは間違いです。斬新すぎて理解できる人は本人も含めていないのではないでしょうか。
宇宙的な発想の企画は、あまりに多くの人を不安に陥れるので、仮に作ってしまったとしても、先方には見せない方が無難です。
僕は昔、うっかり見せてしまったことがあります。まあそのときはいくつか企画案をだしてくれ、ということだったので、ダミー企画として笑い飛ばしてもらえましたが、精神的に追いつめられると、そういうものを作ってしまいます。
宇宙的な企画というのは、たとえばそのとき僕が作ってしまったのは、「関ヶ原をテーマにしたコンテンツ」という依頼が来たときで、いわゆる「これは定番だろう」と思われるものを5つくらい、「ちょっと冒険かな」と思われるものを4つくらい、しかしどうしてもあとひとつ、なにか欲しくて絶対に実現しないであろう企画をひとつ考えたのでした。
その名も
「戦国宇宙世紀IEYASU」
毎晩銀河系で征夷大将軍IEYASUの称号を巡って牛の奪い合い(キャトルミューティレーション)をしている、という設定のインターネットUFOキャッチャー(奪うのは牛)を書いたのですが、どう考えてもそれはないだろう、という話です。確かに誰も考えなかったけど、それは「考えないなりの理由がある」からだということを考えた方が良いと思います。
まああまり沢山出せ、と言われるとなかにはこういう全くのダメ企画を出す羽目になってしまうものです。
できるなら企画はひとつかふたつに絞って出すのが無難です。というか、その方が精度が絶対に高い。
斬新なアイデアは、そのまま取り入れても斬新な企画とはなりません。
シリコンにごく僅かな不純物が混じって半導体になるのと同じように、斬新な企画とは、平凡なアイデアにごく少量の斬新なアイデアがまじったものです。
辛さのもとと言われる純粋カプサイシンは、たった一粒で1600万スコーヴィル。これは普通のタバスコの1万倍の辛さです。
これを、単なるお湯に入れると
この有様。
斬新なアイデアというのは、この純粋カプサイシンのようなものです。
普通の人には辛すぎて飲めません。
いかにうまく薄く、普通の人でも食べれる味まで、要するに1万倍くらいまで希釈化できるかが企画屋の本当の腕の見せ所なのです。
はてなとマッキンゼーとUEIとマイクロソフト、社内コミュニケーションについて
はてなが京都に戻る？ ふふふ予定通りやを読むと、はてなという会社のブレのなさにさすがと思ってしまいますが、はてなの京都移転でコミュニケーションについて考えてみた。を読んで、そういえばコミュニケーションと距離の問題ってあるなあと思ったのでした。以下、いつも通り長いブログ。
いま、僕の会社UEIは2階、5階、6階ととても縁起の良い数字、すなわち0x100に別れているのですが、そもそもビルが小さいので、フロアも小さい。結局会社の成長にあわせて引っ越しもなんどか検討しているのですが、場所がいいんですよ。いまの会社は。東大の赤門からすぐだから、学生向けの食堂や書店がたくさんあるし、そもそも東大の学内だけで10以上の学生食堂がありますからね。
おまけに学生街だから、家賃も安い。近隣に住む社員も通い安い、秋葉原に近いから、会社行く前にちょっと秋葉に寄ったり、一日に何度も秋葉と往復したりということが可能。上野にも近いから、接待などに便利というメリットがあります。
なにしろいわゆるIT企業の人なんて、滅多に上野なんかで飲みませんからね。
でも上野の飲み屋はどこもすごく安くて、かなり美味しいです。目黒や六本木が根城の人たちは絶対に寄りつかないような、坊や哲にそのまんま出てきそうな飲み屋が多くて、ちょっとビックリしますがみんなその味の美味さと安さに驚いて喜んでくれます。
哲也 玄人立志編 坊や哲VS.不死身のリサ―雀聖と呼ばれた男 (プラチナコミックス)
- 作者: 星野 泰視, さい ふうめい
- 出版社/メーカー: 講談社
- 発売日: 2007/10
- メディア: コミック
反面、営業マンを募集すると、沿線が良くないのか、ぜんぜん人が集まらないのが悩みのタネです。
(ちなみに秋葉が好きな営業マンの人、大募集中です。新卒でも)
さて、そんなUEIですが、ふつうの会社と同じように、2階、5階、6階で機能を分けています。
2階は来客や一般事務・総務などがあるフロア。5階は主にモバイルなどの開発を専門に行ったり、法人サポートがあるフロア。6階は、"特殊部隊"と呼ばれる特殊な開発をする開発チームとデザイナーと営業と、先週できた新しい部署"戦略情報セクション"があるフロア。
Peoplewareに基づき、働きやすい空間は社員に自分で決めさせたのですが、結果的に5階と6階であまりにもカルチャーが異なってきていて驚いています。つまり、言いたいのは京都と東京、東京とシリコンバレーに別れていなくても、コミュニケーションやカルチャーは微妙に異なってくる、ということ。
そして、コミュニケーションの問題を円滑に解決するのは経営者の重要な使命だということです。
昨夜飲んでた後輩は、入社基準がめちゃくちゃ厳しいことで有名なマッキンゼーのコンサルタントなのですが、こんなことを言っていました。
「マッキンゼーは世界50カ国に7000人のコンサルタントが居て、なにかのエキスパートを探そうとすればすぐにデータベースで出てくる。プロジェクトごとにタスクフォースが組まれるようになっていて、世界のどこのプロジェクトでも希望をだせば参加できる。海外のエキスパートの意見だけをテレカンファレンスで聞くこともできるような仕組みがあるんですよ」
そういう本人はドイツに行っていた。けど、ドイツ支局に所属していても、実際の仕事はサウジアラビアやインドで行い、週末は彼女を日本から呼び寄せてドバイで遊んで過ごした、のだそうな。とはいえ週末も殆ど仕事らしいけど。
まあマッキンゼーの場合、派遣型頭脳労働者組織のようなものなので、こういうダイナミックな組織編成も可能なのだと思いますが、うちみたいな会社はそもそもそんなデータベース化するほどの人数でもないし、仕事も短期のものが多いから難しいなあと思いました。
僕もマッキンゼーからインタビューを受けたことが何度かあって、UEIとしてもマッキンゼーから依頼されて仕事をしたこともありますが、本当に彼らは頭が良くてしかも猛烈に働く。以前うちにインタビューに来たのはマッキンゼーのサンフランシスコ支局からで、モバイル業界におけるコンテンツの動向がどうなるか、というテーマで4時間くらい。そのビデオを撮影してクライアントに見せるのだそうな。誰かがそれを英訳したのだとしたら、そのビデオ欲しいって頼んだのですが、くれませんでした。当たり前か。
ところで同じ外資系の大企業でも、マイクロソフトは製造業なので全くそんな感じではなかったです。
僕は学生時代、東京のマイクロソフト株式会社(MSKK)が直接学生を雇用できないという理由で、間に代理店や適当な会社を挟んでギャラを貰っていたのですが、その後レドモンドのMicrosoft Corp(MSHQ)の仕事を請けることになって、海外の会社で働こうとするとビザの問題があって学生が就労することはまず不可能だったので、またしても下請けの下請けという形で報酬を受け取りながら仕事をしていました。
5万人以上の従業員が居ても、拠点ごとに方針はバラバラ。MSHQは全員が個室。MSKKは大部屋に低めのパーティション。僕がウロウロしていた頃はまあフロアごとにパーティションの高さも違っていて、だいたい部長の好みで決まってました。パーティションを選んだ部長は「みんなの顔が見れるからこういうオフィスの方が働きやすい」と言っていました。けど僕は個室
でも結局製品開発そのものはほとんどMSHQでしか行われていなくて、僕の使命は当時世界最先端と言われていた日本のゲーム業界の現場の声を吸い上げて製品開発チームに伝えること、そして逆に製品の優位性や魅力を日本のゲーム業界に伝導(エヴァンジャライズ)することでした。
だから僕らは当時とある大手ゲームメーカーの一角に狭いブースを貰い、開発現場から出る苦情や難問といったものをその都度HQにエスカレーションしたり、時には開発中のゲームのソースコードを解析してOS実装レベルのバグや矛盾を発見し、電話をかけて開発チームと喧嘩したりといったことがメインでした。ある意味、東京とシアトルをつなぐハブみたいな仕事だった。
そのとき思ったのは、海外とうまく仕事をすると二倍速いということでした。
夜HQに電話を掛けて、あーだこーだと注文をつけ、家に帰って朝メールを見ると、新しいビルドが届いている。
こっちが休んでいるときに相手が働いてくれるので、ダブルバッファリングというか、大変効率が宜しい。
それから五年して、シアトルのDWANGO North Americaに行ったとき、日本の開発チームとやりとりして新作ゲームを作ることになりました。といっても、途中までは日本で作っていたんだけど退社日になってしまったのでアメリカに行っても作業が続いてしまっただけなんですけど。
これも同じで、まず宇宙船のデザインを考えて、デザイナーにFAXを送り、ボスの攻撃方法を考えてプログラマーにFAXを送り、家に帰る。
翌朝起きると、布留川君から最新のビルドがJARファイルで届いていて、エミュレータで実行して動作を確かめる。ステージエディタでステージを微調整して、そのデータを布留川君に返す。その繰り返し。
STARDIVERSIONというゲームはそのようにして出来ました。
まあ日本でも、昼間だれかが働いて、夜誰かが起きて作業、みたいなバトンタッチをすればできなくはないですけど。
個人的には距離が離れていてもコラボレーションはあまり問題がないと感じていたのですが、それはやっぱりiアプリのようにビルドが小さくて転送が簡単なものに限られるようです。
その後、Xbox360用のローンチタイトル開発の仕事で、グラフィックに関連した小さなモジュールを作っていたのですが、開発キットそのものが物理的に少なくて、本郷と目黒を一日に何度も往復することになってしまいました。もちろん僕はプログラムを書いてるわけではないのですが、プログラマに実装させるコードはプロデューサーから非常に微妙なニュアンスを出すように言われていて、彼が「気体と固体と液体の要素を全て持った物質。しかも角度によって異なる映像が現れる」と呼ぶものをなんとか作るためには、教科書を渡して「これを作れ」と言うわけにも行かず、いろいろな方程式や理論を適用してその架空の物体をつくるためには、トライ&エラーが必須でした。しかもリアルタイムで動かないといけない。
こういう作業に、ネットワークは殆ど無力で、iBookとiSightを先方に設置して、なんとか本郷で作業指示を出せないか工夫してみましたが、HD解像度のゲーム画面の微妙なニュアンスやキーパッドとのレスポンシビリティまではiBookで再現することはできず、最後はやっぱりつききっきりであーだこーだと指示を出さなくてはならなくなり、深夜タクシーで訪れ、良く先方の床で寝てました。
一連の経験で解ったことは、コラボレーションワークでコミュニケーションをとらないとどうにもならない場合と、そうでもない場合がある、ということです。
STARDIVERSIONの場合は、そうでもなかった場合。これはきっと僕一人だけが海外に居て、他のスタッフは東京に残っていたからでしょう。
Xbox360の仕事の場合は、どうにもならなかった。これは物理的な制約によります。
MSHQと某ゲームメーカーの場合、作るものが完全に別れていたので距離が離れていても問題がなかったと言えます。あったとすれば使う言葉が違うことくらい。それでもプログラマーなのでAPI仕様書をみれば自分たちがなにをすればいいのか分かり合えました。
じゃあはてなの場合はどうだったんでしょうか。
僕ははてなに知り合いが居ないのでなにが原因だったのか想像することしかできませんが、やっぱり小さい会社は社長の「思い」をいかに社員と共有するか、ということに全力を挙げないといけないのではないか、と思います。
たぶん単独のプロジェクトの話ではなくて、全体的な話として、社長の「念」が伝わってないといけない。
また、開発チームがあまりにも離れていると締め切りのプレッシャーを感じない、というのもひとつの問題としてあると思います。
やっぱり目の前で怒ってる人や困ってる人がいるのと、メールで「しっかりやってくれ」と言われるのとでは、プレッシャーの感じ方がぜんぜん違うわけで。
規模がある程度小さい時は、やはりなるべくコンパクトな場所に集結した方がいいのかもしれません。
さて、翻って我らがUEIですが、去年は海外出張、一昨年は4回の入院生活で、だいたい同じくらい社長が会社に居なかったわけですけど、一昨年と去年とで明らかに会社の経営に違いが出てきました。
一昨年、入退院を繰り返していた時期は、僕が入院した二ヶ月後に必ず売上が落ち込みました。まあ当時、営業していたのは僕一人で、リクルートから転職してきたバリバリの営業ウーマンが出社したその日に僕は第一回目の入院生活となったのだからある意味、当然です。
でも東大病院だったので、会社から数分で病室まで来れるし、一日二回は会社と病院の間に定期便が来て、会社での課題や問題などを聞いたり、指示を出したりといったことができました。けれども売上は落ち込む。みんな不安だったのかもしれません。ナニワ金融道でも、立ち上げたばかりの会社の若社長が入院して会社が潰れてしまう話が出てきますが、入院中は何度もその話を思い出して戦々恐々としていました。だから手術をするかどうかで迷う暇も無かった。
全身麻酔の手術をするときには、「死んでも構いません。未知の病原菌に冒されたりしても文句は言いません」という誓約書にサインをするわけですが、最初の手術ではさすがに躊躇しました。けど、5分くらい悩んでサインしました。手術しないと、治ってもまた入院することになるし、そのときに会社が潰れてしまったら困るからです。二回目の手術のときはもう即答で決断した。
同じ病気を持っていて、一回だけ手術した親父に
「おまえ、死ぬかも知れないんだからもう少し考えろ」
と言われたのですが、
「万が一、死んでしまったら、会社に保険金が入ってきて、しばらくは会社の資金が潤沢になる。だから大丈夫だ」
と答えました。会社の資金繰りに行き詰まって自殺する社長の気持ちがそのとき初めて解りました。会社というのは死ぬほど大事なのです。
それほどの覚悟をもってしても、売上は落ちてしまった。けど、会社は僕が手術を乗り越える度に強くなっていきました。明らかに落ちる売上も減ってきた。
去年、一年で5回くらいの海外出張と、3回くらいの地方出張があったのですが、売上には全く影響がありませんでした。
会社が強くなったこともそうですが、なによりもインターネット環境があったことが大きいと思います。
世界中、どこにいても情報を集め、指示を出せる。これはとてつもなく凄いことです。
病院では通信は御法度ですから、いくら顔をあわせても仕事がまとまりません。その点、インターネットの威力は文字通り絶大です。
飛行機などでインターネットと電話が不通になると、そのときだけはさすがに困ります。早く機内インターネットを復活させて欲しいと願うことしきりです。
ではリーダーは会社に居なくても会社が機能するのか、という問題に関してですが、僕にはまた別の教訓があります。
サラリーマン時代、部下が十分成長したので、僕が指示を出すことがほとんどない案件がありました。
あまりにも暇なので、彼らの仕事ぶりをビデオに撮影してプロジェクトX風にまとめたりしたくらいです。
ある週末、接待で大切な取引先の担当者とスノーボードに行っていたら、会社から電話が。
進行中のプロジェクトのプロジェクトマネージャからでした。
「清水さん、遊んでないですぐに戻ってきてください」
「え、なにかあったの?」
「なにもかも進んでません。戻ってきてください」
「え、いや、でも、僕が戻ったって進むわけじゃないだろう」
「とにかく、私じゃだめなんです。戻ってきてください」
そういうわけで、僕はとるものもとりあえず、ただでさえノーマルタイヤのFRは雪道に危ないというのに、昼の高速を飛ばして大急ぎで会社に戻りました。
それで彼女と直接話をしてみると、もう信じられないくらい怒っています。
「どうしたの?」
「なにもかも進んでないんです。プログラマの進捗報告は常に"予定通り"というものだったので安心していたのですが、バグだらけでリリースは不可能です」
「僕も"予定通り"と聞いていたよ。バグだらけでリリースが不可能と解ったのはいつなの?」
「さっきです。プログラマを責めたら、"バグが入るのは仕方がないし、どのくらいバグがあるかは事前に予想できない。作業は予定通り進んでいた"と言うのです。でもあと三週間でまともに動くようになるとは思えません」
「僕はどうすればいい?」
「座っていてください」
「は?」
「そこに座って、みんなに睨みをきかせてください。私じゃプログラマに舐められてしまう。私が技術のことがわからないから、言い訳を聞いても相手が悪いのかわからないんです」
そして僕はうまれて初めて、「お飾り」という仕事を全うすることになったのです。
でも確かに「お飾り」の効果は抜群で、みるみる仕事が進んでいきました。僕は結局、ミーティングに出席したり、クライアントを社内で接待したりと、ほとんどなにもしなかったのですが、開発チームは見違えるように積極的に働き、バグはみるみるとれていきました。
通信対戦のゲームというのはもの凄くデバッグが難しく、おまけに携帯電話というのは電波が切れたり繋がったり電池が切れたり電話がかかってきたりするので、PCやゲーム機の通信対戦の何倍も異常系が多く、バグの原因もわかりにくいので、確かにとてつもなくデバッグは大変でした。
プログラマも全員ゲーム開発経験がない人ばかりだったので、そういうことがわからず黙々と仕様書通りにコーディングを"予定通り"進めていたのです。
僕の仕事は、プログラマを叱咤し、テスターを勇気づけ、取引先担当者に平謝りして宥め、必ず予定通りに完璧なものをリリースするのだと言い続けることだけでした。
軍隊におけるラッパ吹きみたいなものです。
しかし実際に、プロジェクトは絶望の淵から立ち直り、予定通りリリースすることができました。
完成した製品は驚くほどバグが無く、完璧に動作しました。
これは僕にとってはとても良い経験になりました。
どんなに開発チームが優秀でも、リーダーが傍にいなければチームは方向性を失い、失速し、どれを優先すべきで、どれを切り捨てるべきか迷い、進捗の全貌が把握できず、なんとなく遅れていく、ということです。リーダーは常にプロジェクトの完遂したイメージを想像し、それに近づけるようスタッフに全力を尽くさせるのです。
その後もいくつもプロジェクトを経験しましたが、遅れているプロジェクトは圧倒的にリーダーが弱い。どんなに優秀な開発者でも優れたリーダーの元にいなければその実力を発揮することは永久に出来ないということがわかりました。
その意味で、やはりはてなも近藤さんという強力なリーダーが開発チームを常に導いてこそスタッフの能力を発揮できるのかもしれません。
そういえば、UEIでも、あまりに優秀なスタッフが居たので彼らに新製品の開発を完全に任せていたことがあるのですが、結局何が欲しいのか、何を作りたいのか、それを定義するのが僕だったので、最終的に僕が中心になってチームを再編成すると、ようやく開発が前に進んだという経験もあります。人は同じ過ちを繰り返してしまうものなのです。
思えば、海外チームとコラボレーションしたときも、それぞれ現地に強力なリーダーが居ました。だからこそうまくいっていたわけで、リーダーは仕事を進める強力な原動力です。
ソフトウエア開発の仕事というのは、ほとんどが疑似派遣と言われています。
会社から取引先に出向し、そこで作業するのです。これが一番会社にとってはリスクが少なく確実に利益を生み出す方法なのだそうです。
しかし、その方法で利益が生まれたとしても会社として何が残るのでしょうか。
会社の個性はチームとして動いたときに初めて発揮されます。
そういう意味で、変な会社ほど社長がみんなの傍にいて「変」を保ち続ける必要があるのかも知れません。
冒頭にでてきた後輩はうちの2階を見て
「ここは玩具部屋?」
と本気で聞いてました。ミーティングのためのフロアだと何度言っても信じませんでした。6階に連れて行ったら
「ああ、そこが清水さんの机ね」
と一番散らかってる机を指差しました。当たっているだけに悔しい。
僕が普段うろついていない5階を改めて見ると、もの凄く綺麗に整頓されていて、余計なものが一切ない部屋でした。
「ここは別の会社みたいだね」
やっぱりそういう「変」な空気は、属人的なもので、意識的にそういうものを作らないとなかなか浸透していかないのかもしれません。同じビルの5階と6階ですらそうなのですから、オフィスが遠く離れていたらかなり難しいのでしょうね。
というわけでそろそろ会社行こうかな
後輩の顔や同級生の顔はもうほとんど思い出せない
高校の後輩がふらっと日本に帰ってきて、三年ぶりに飲みました。
おかしな奴で、高校時代はアセンブリでリアルタイムボクセルレンダリングのプログラムを書いていたクセに国際文化科の奴で、そのまま文系の一流大学に進んで、五人くらいしかいない頃の楽天やegroupでバイトしながら大学を卒業して、世界最大の戦略コンサルティングファームに新卒で入って昨年末までドイツ支局に配属されていた、と。
ボクセルレンダリングのプログラムなんか、相当面倒くさいですよ。僕も未だに書いたことがないくらい。しかもリアルタイムだったから。そういう奴はいるもので。なのに文系の仕事をすると。「コンピュータはあくまで手段」と言い切る。そんなお前が羨ましいよ。どっぷりハマッちゃった僕からみると。
まあでもこういう奴はロジカルな発想と文系的な発想の両方ができるから、戦略コンサルタントにはまさにうってつけの人材だな、と思っていい会社に就職したね、という話をしたりしてたのでした。
んで、「あいつやあいつも清水さんのこと絶対覚えてますよ」って言われたのですが、後輩の顔がぜんぜん思い出せない。
確かにサッカー部の後輩とか(そう、驚くべきことに僕はサッカー部のOBなのだ)、沢山いたハズなんだけど、3,4人しか思い出せない。
こりゃ俺も相当モウロクしたな、と思ったわけです。
一人は編集者になりたかったけど夢破れて時計職人になって、もう一人はトラック運転手と結婚して離婚して高校の同級生と再婚して、さらにもう一人は高校の熱血教師になったそうな。彼らとはたぶん何度も話をしているので覚えている。でもそのくらいが覚えている限界。年だな僕も。
それどころかサッカー部のチームメイトすら殆ど思い出せない。マネージャは覚えてるけど。顧問の内田有紀に似た顔は思い出せるけど、名前がサッパリ思い出せない。それどころか自分が部長だったはずの情報技術研究会(要するにパソコン部)のメンバーも殆ど思い出せない。たしか特攻野郎Aチームマニアと、太っちょと、卓球が得意な奴と、ロケットが得意なやつ、クルマのマニア、それと女子が数名。
昔、「人間交差点」みたいな漫画で、昔の同級生と名乗る詐欺師から声を掛けられて金を巻き上げられた、みたいな話があって、そんなのいくらなんでも思い出せよ、と思ってたわけですが、この年になると忘れるものなのか。凄い。忘れるって。
確かに、たまに雑誌やテレビに出ると、昔の同級生からメールとか電話とかを貰うことがあります。
けど、向こうは僕を覚えていても僕はぜんぜん覚えてないので基本的に知らない人。そういう人からいきなりメールとか貰っても怖いですよね。どう対応していいか解らず放置してるとそのうちメールが来たことそのものも忘れてしまうわけです。
他人の記憶からなくなるのって哀しいですね。
ホリエモン事件のときも、テレビが少年時代の同級生にインタビューすると「影が薄かったからあまり覚えていない」とか「目立たない子供だった」とか言われていて、「同級生なのにひどいなー」と思ったものですが、今、僕、その酷い同級生になっていました。
高校の同級生で思い出せるのはどんなに頑張っても10人くらい。今誰かが現れても間違いなく忘れている自信があるので、同級生詐欺には引っかからないと思います。
中学の同級生はもう少し強烈だったのでだいぶ思い出せるのですが、小学校まで遡ると壊滅。
たまに実家に戻ると、両親から「八百屋のケンちゃんが結婚した」とか「パーマ屋のマキちゃんが離婚した」とか、どうでもいいゴシップを聞かされるのですが、もうぜんぜん覚えていないのでそんな人が存在したかどうかすら全く思い出せず、哀しい気分になります。
とはいえ、覚えている連中は覚えているだけあって、面白くて楽しい人たちばっかりです。
人間はこういう場面でも取捨選択をするのだなと妙に納得してしまいます。
そんなわけで同窓会には全く顔を出していません。
Macbook Airと過ごした一週間
Macbook Airが来たのがちょうど先週の水曜日で、それから一週間と少し経ちました。
Macbook Airを空港や、飛行機や、砂漠や、ラスベガスのホテルで使ってみた感想を書いてみたいと思います。ちなみに僕が買ったのはSSD版です
- 軽くて薄くて持ち歩きやすい!
Macbook Proだとブリーフケースが変形するくらい重かったのですが、Macbook Airは書類と同じ感覚で持ち歩けて凄く便利です - 電池持ちは思ったより悪い
公称4時間なので、3時間くらいは持つと思ったのですが、E-mobileやWiFiを使っていると、2時間半くらいで切れてしまいます。バッテリ交換が気軽にできないので、これはけっこうモバイルマシンとしては致命的かも - SSDは思ったより悪くない
SSDの容量が64GBと少なすぎることをけっこう心配していたのですが、通常の使用では全く問題ありませんでした。まあ僕のMBPもデータ入れすぎて空き容量が常に10GBくらいで使っているので、通常の使用では問題ないのは間違いないんですけどね。噂通りほとんど風船が出ないので、場合によってはMBPより快適に感じることもあります - CPU速度はややもっさり
風船が出ないので普通の使用では問題ないのですが、Erlangのインストールなどのときに、コンパイルにかなり時間がかかったりして、目的は限定した方がいいかもと思いました。 - 解像度は物足りない
普段MBP15インチの解像度に慣れていると、MBAの解像度は少々物足りないのは事実です。とはいえメール、スライド作成、Web閲覧には充分です。Final Cutによるムービー編集やEclipseの動作は正直厳しいと思います。前の環境がMacbookだったらもしかしたら我慢できるかもしれません。でも液晶は本当に美しいです。さすがAppleというところです。 - キーボードは打ちやすい
Macbookと同じような感覚でタイプできます。この薄さでこの打ちやすさは素直に凄いと思います。Macbook Proのキーボードよりもキーピッチが広いぶん打ちやすいかもしれません。MBPのキーボードは美しいのですが、間違って隣のキーを押してしまうことも多い(特に寝ながら操作するとき)ので、これは重要なポイントです。飛行機の中だと、いろんな姿勢でキーボードを打ちたいので、この点は良かったです
総合評価としては、持ち歩いて使う人には文句なしにお勧め。ただし、家でたまに使うMacとしてはやや物足りないのは否めません。
僕はいまのところ、家にはMacbook ProとMacbook、会社ではQuad CoreのMac Pro、移動にMacbook Air、という構成で使っています。移動にMacbook Airを使うことで、Macを持ち歩く機会が増えました。MBPはどうしても気合いが必要ですからね。
でもSSD版とハードディスク版でバッテリーの持ちも動作速度もあまりかわらないようなので、ハードディスク版で良かったかも知れません。僕はけっこう乱暴に扱いたいので機械部品がなるべくないものが嬉しいのですが、普通の使い方ならHDD版で問題ないと思います。HDD版のほうが20万円くらい安いし、その方がお勧めです。
うちのバイト研究員の近藤君もHDD版を買って、毎日会社に持ってきています。ちょっとしたプログラム開発に使うには、これほどカジュアルに持ち歩ける環境は貴重かもしれません。
Apple MacBook Air 13.3/1.6GHz Core 2 Duo/2G/80G/micro-DVI/BT MB003J/A
- 出版社/メーカー: アップルコンピュータ
- メディア: エレクトロニクス
ネタとして、封筒型ケースも必携でしょう。僕も注文しようと思ったら在庫切れでした。
ハンドメイドフェルトケース MacBook Air用 オレンジ
- 出版社/メーカー: buzz-house design
- メディア: エレクトロニクス
はてな京都移転に思うこと
僕がアメリカをふらふらしてみて、漠然と感じた事がありました。
「こんなに広くて誰にも会わないんだったら、別に日本に居てもいいんじゃなかろうか」
シアトルの会社に行ってる頃、こんなことも思いました。
「都会の喧騒もいいけど、こういう町でのんびり仕事に集中できるとしたら、幸せだなあ」
アメリカに行った多くの日本人がそうであるように、僕もアメリカに行って思った事は
「僕は日本人だ。それを好むと好まざると」
ということでした。
日本人だから、日本人としての根っこを大事にしないといけない。そこを武器に、世界と勝負していかないといけない。
僕が趣味で京都に行くようになったのも、まさにそういう動機からでした。今でも毎年二回はふらりと行ってます。ひとりで。
京都の素晴らしいところは、町並み全てが歴史を宿しているということです。
優雅で、ポップで、古都の魅力にあふれています。いつでも日本人であることを強く意識させられます。
アメリカ人が大草原を見てインスピレーションを得る事ができるなら、日本人は法隆寺を見てインスピレーションを湧かせる事だってできるはずです。
そういう意味で、京都に会社をつくれたら、楽しいだろうなとずっと思っていました。
でも僕は新潟の生まれで、関東甲信越地方のおしりにくっついているような田舎ですから、僕にとって最も身近な都会は、やはり東京で、暮らしやすいのも働きやすいのも東京だったのです。
そういう意味で、パロアルトも京都も同列に拠点を移動できるはてなを本当に羨ましく思います。はてなはきっと香港でもベイルートでもやっていけるでしょう。まさにそれが新時代の会社、新時代のビジネス、という気がします。
京都に戻ったはてなが、次にどんなサービスを作ってくれるのか、今から楽しみです。
重厚長大なフレームワークはあまり好きになれない
MVCフレームワークというのが昔からどうも好きになれません。
MVCパターンと言っても良いですが。
どうも好きになれない理由はなんだろうかと自分なりに考えると、僕があまり好きになれない環境は以下の要素が多く含まれていることに気づきました。
- ファイルが不自然に分散する
- ファイルの命名規則やファイルごとの規則が決まっている
- 本筋のプログラム言語以外にフレームワーク固有の設定ファイルを書く必要がある
- ディレクトリ構造が規定されている
- デプロイしにくい
- 独特のルールやしきたり(制約と呼ばれることもある)を覚える必要がある
- ちょっと想定から外れることをしようとするとなんにもできない
- 一部分をコピーしても動かない
ほとんどファイルに関する問題でした。
まあクラスごとにファイルを分けたい、という気持ちも解るのですが、分けたくないという気持ちもあるわけで、特にさほど大袈裟でもないプログラムを書くのにクラスごとに異なるファイルを作ることを要求されると弱ります。ぜんぜん楽しくないのです。
いわばこれって他人の敷いたレールの上を漠然と歩くような不思議なストレスがあって、そもそもそれができたらコンピュータ屋なんて因果な商売はやってないわけで。
それでさらに上記のなにが問題なのか、僕なりに共通項を見つけると、要するに、開発スピードを犠牲にするようなこと全般がイヤなのでした。
ポール・グラハムの「ハッカーと画家」によると、そもそもコンピュータ科学(計算機科学)とハックは違うものなのだと。優れたソフトウェア設計者はエンジニアではないのだと。
確かに、イメージでしかないけど、クラス階層ごとにディレクトリを整然と分け、命名規則に従ってコードを書くのは全くハッカーのように見えないような気がします。偏見ですけど。
グラハムによれば、ハッカーは設計図から書き始めたりせず、ハッカーにとってのプログラミング言語は清書用のペンではなくてラフスケッチを描く鉛筆なのだという。
こういう話にはもの凄く共感してしまうのです。
実際、プログラマと名乗る人には二種類の人種が居て、考えてからプログラムを書く人と、プログラムを書きながら考える人です。
前者は職業プログラマにとても向いていて、後者は趣味に留めるか、研究者になった方が良いと思います。考えながら書かれたプログラムは、それ自体がどれだけ画期的な代物であったとしても、実用には全く供さない、いわば良くできた模型だからです。
僕は残念ながら自分がとても後者のタイプであることを繰り返し思い知らされる出来事が成人する前にあり、それからはプログラムは研究と割り切ってプロトタイプだけを作るようにして、事業化できそうなネタがみつかったら、それをもとにアーキテクトが仕様書を書き、職業プログラマが完璧な製品に仕上げる、というプロセスを自然にとるようになっていました。
独立した直後は会社に僕一人しかいなかったので職業プログラマのまねごとをしてみたのですが、やっぱりテンで向いてませんでした。そういうわけで今は全くその手のものは書いていません。適材適所というやつです。
そういうやり方でプログラムを書くとき、重厚長大なフレームワークはもの凄い足枷になります。
でも不思議です。これはなぜなんでしょうか。
たとえば、Rubyそのもの、Pythonそのもの、HaskellやErlangでもいいですが、そうした言語そのものに触れるときは、とても楽しく快適に学べるのです。
しかしその上で動くフレームワークを勉強しようと思ったとたん、とてつもない拒絶反応が全身にジンマシンのように駆けめぐります。
フレームワークとそうでないものの違いのひとつは、部分と全体という話にも近いかもしれません。
フレームワークには大きな枠組みがあって、そのなかで変えるべきところを自分なりに変えれば、そのシステムを好きにすることができます。しかしあくまで「変えるべきところ」がどこなのか、「どのように変えるべき」なのかは他の数多くの制約に従わなければいけません。
たとえば、JavaのStrutsでごく普通のショッピングカートをプログラミングするのは簡単ですが、とあるリクエストが来たらサーバでサイトイメージのスナップショットをレンダリングして、そのレンダリングにはHotJavaなどの外部のクラスライブラリを使って･･･もしくは、その部分だけWindowsのIE7コンポーネントを使ってレンダリングするとか、リクエストを受け取って3Dのレンダリングを行ってその結果をJPEGエンコーディングして返すとか、とにかくそういうことをする、と考えると、もうStrutsでやるべきことではなくなります。
そんな処理をJavaでやるべきかどうか、という議論もありますが、Javaには一応、Java3Dなどのレンダリング機能やJNIがあるので、どちらかといえばできるはずですが、Strutsの設計時にはおよそ確実に想定されていないであろう処理をそういうフレームワークでやるのは不安です。というかたぶんそれは誰に聞いても正気ではないと言うでしょう。
しかしそれでもたとえば「サラ」のJavaで、つまりサーブレットやStrutsやその他プログラムの外的環境は言語処理系しかないという状況で、HTTPサーバの実装自体から始めれば、そんなややこしいプログラムも安心して書けます。
なにが怖いのかというと、なにかの環境やフレームワークに依存するプログラムを途中まで作ってしまってから、「この先にはどうも進めない」という事態が起きるのが怖いのです。
これは事前に緻密な設計をして、フレームワークの性能評価をしてから開発にかかるようなウォーターフォール式の開発スタイルではまず起きないことです。
しかしゲーム的なものの作り方というのは、ある意味でこうした行き当たりばったりなところというのがどうしてもあります。
「ここをこうしてみたらどうだろう?こうしてみたら?」
そういう細かい試行錯誤を繰り返して、まるで一刀彫りの彫刻のように全体から細部へと削りだしていくのがゲーム的なプログラミングです。
たとえばゼビウスは、もともとベトナム戦争を題材にしたゲームとして作られていましたが、開発者がいなくなってしまったため、新入社員の遠藤雅伸さんがSFものに作り替えたという伝説があります。それくらいドラスティックに変わるのです。
Webサービスに強引にあてはめるとすれば、mixiを作ろうとしていたら途中で2ちゃんねるになってしまった、ようなものです。
ゲームのα版と普通のWebサービスのα版というのはその意味ではぜんぜん違って、ゲームのα版は最初から棄てるのが前提ですが、Webサービスのα版からβ版をゼロから作り直すことはほとんどありません。あるとしたらよほど設計がまずかった場合だけです。
そういうときにフレームワーク、特になにからなにまで揃った、All in Oneのフレームワークを見ると、いつも尻込みしてしまうのです。
お仕事で使うぶんには、こうした重厚長大なフレームワークというのは、実に様々なことに配慮されていて、様々なところで実績を積んでいて、様々に役立ちます。
なのですが、エンドユーザ向けコンテンツというのは、常にオンリーワンのシステムであることが要求される場合があるので、無茶苦茶特殊なクエリーが発行されるとか、普通なら有り得ないところに凄く負荷が掛かるとかということが実際に良く発生し、そうなるとやっぱり最初からフレームワークは怖くて使えない、ということになるのです。
実際、Strutsで作ってもらったシステムをしばらく運用していたのですが、どうしてもあることができなくて、PHPで作り直したりしました。
この手のフレームワークを使っていると、最後はフレームワークのソースコードまで修正する羽目になるので、結局は自分で作ってもそれほど劇的には変わらない、ということになることもしばしばです。
ソフトウェア工学の常識では、「メジャーなフレームワークを使え」が当然なのですし、それを否定する気は全くありませんが、フレームワークは巨大すぎると怖くて使えない、というフレームワークアレルギーみたいな可愛そうな人間がいることも事実なのです。僕のことですが。
それでもなんども似たようなコードを書いていたら、フレームワークとまではいかないまでも、自分なりに処理を綺麗にするものが欲しくて、PHP向けのフレームワークで軽いものはないのか調べてみたのですが、なんだかどれも重厚長大で、PHPを使うメリットがむしろ殆どなくなっているような気さえするものばかりでした。この場合のメリットってデプロイが簡単、くらいしかないかもしれません。
特にフレームワークというやつが、どれもこれもMVCパターンをベースに作っているというのが本当に怖い。そりゃ確かに分けた方が安全だと思いますが、僕はもう書き始めてから1分でなにか動くものが見たいのです。
ロクロを回すように、コードを書き始めたら少しずつでも実行結果が変化していって欲しい。
だから僕はいまでも echo "Hello"; から書き始めます。
とりあえずWebサーバが動作しているかとか、保存先のディレクトリはあってるのかとか、そっちのほうが気になる。
さすがに最近は自分のライブラリが揃ってきたので、require_once 'mylib.php"; echo "helo" みたいに書くことも多くなってきましたが、極論それだけです。
データ構造ですらも、特に分けたいとも思わないので、PHPでプログラムを書くときにクラスなんかまず作らないです。部下がクラス作らなかったら怒るけど、僕は作りません。製品じゃあるまいし。
そこから本当に面倒だと思っているロジックや機能だけとをとりあえず書いてみます。
「勝手にブログ評論」なら、まずストップワード認識。といっても数行。
それを書いたら、即実行。
実行結果を見て、考えて、なおして、また実行結果を見て考えてなおす、この繰り返し。
これがまさに彫刻を削る作業なワケです。
ものによっては、これで完成しちゃうこともあります。
実行結果を綺麗に見せたかったら、結果をRSSで吐き出してSafariにでもなんでも食わせればいい。
画像を出力するならJPEGでもPNGでも吐き出せばいい。
そしてそういう細かいプログラムを紡いで、なんとなくシステムっぽいものができる、と。
それでなんとなく一丁上がり。事業化できそうなら、開発部にまわして、設計からやり直して貰う。
こういうやり方で果たしてあっているのかわからないのですが、そういうものをポコポコつくるときに、重厚長大なフレームワークはむしろ邪魔です。
僕が肯定するのは、全体で500行くらいのフレームワーク。
たとえばprototype.jsはフレームワークと違うかもしれませんけど、あれはとても使いやすいし、いざというときにもソースが読みやすい。
使うのもソースをインクルードするだけで簡単だし、覚えることも少ない。それに、なにかprototype.jsの機能を使おうとするときにprototype.jsに精通していなければならないというわけでもないのです。
たとえばprototype.jsで最も便利な機能は $('hoge')でHTMLエレメントが拾えること。これだけで手放せなくなります。
こういう感じのフレームワークがもっと増えてくれて、用途にあわせて選べるといいと思うのです。
アンケートフォーム作成用とか、リッチテキストエディタ用とかゲーム開発用とかブログ用とかSNS用とか。
それぞれ500行程度だから、ドキュメントなんかなくてもソースを読めばだいたい動作が想像できるような。
まあこれくらい小規模だとフレームワークというよりもスケルトンコードに近いですが。
PHPみたいな言語もどきにはそのくらい気軽な方が合ってる気がするのですよ。
そういう、小粋なフレームワークってないのでしょうかねえ。
