フランス語キーボードとの闘い

闘いというのも大げさだけど、Poderosaがフランス語キーボードで動かねえ、という問合せに対応するために現物を入手して調査したところ、いろいろ知見が得られたのでQiitaに書きました

新生Poderosa

超久々の更新です。ブログは書かなくなりましたが、忙しくしています。
本日から、SSHクライアント Poderosaが完全リニューアル してβリリースながら公開の運びとなりました。

今回は以前のような放置のオープンソースではなく、商用製品ですが、その分きっちり運営する方針です。
なお商用ではありますが、試用は無期限にできます。

ぜひお試しを。

価値の大小を他人と定量的に議論するには金しかない

　よく、起業は飛行機の離陸に例えられる。滑走路の残りの長さ＝手持ち資金で、速度を上げながら（＝時間あたりの資金消費量を増やしながら）進み、手元資金が尽きるまでに離陸できればOK、でなければ離陸失敗で事故、というわけだ。
　この例えでは、もし途中で離陸できそうにないと判断した場合は、強引に滑走路を延長する（＝増資）か、離陸できることに賭けてそのまま突き進むことになる。

　僕の仕事スタイルは、これでいくと小型のグライダーだ。滑走路は要らなくて、小高い丘があればいい。よほど条件が悪くない限り離陸はできる。その後も小回りはきくし、景色もよく見える。でも１人しか乗れないし、速度はジェット機より比較にならないほど小さい。

　この比喩はけっこうよくできている。

　とくにエンジニアであれば、「小回りがきく」ことはきわめて重要だ。ちょっと気になるライブラリが出たり、面白そうな本に出会ったりしたときに、その日の仕事の予定を変更して今興味あるものにとりかかれる自由を確保する、ということだ。
　もちろん重要な締め切り間近とかではそうはいかないが、僕の場合はタイトな期限というのは年２～３回なので大抵の日は融通が利く。

　でもサラリーマンではこうはいかない。個人的興味でフラフラその日のタスクを変えるのは、仮に長期的には何かの役にたつのだとしても、株主の時間と金を無駄にしていることになる。それがオーナー社長であれば、株主としてだけでなく実務を遂行する上司としての立場からも無駄であるのでとうてい受け入れられない。

　逆に、ある程度大企業になれば、興味のあることを手当たり次第やって情報収集するのが任務、というケースもあるだろうけど、中途半端な規模の組織だとそれは難しい。エンジニアとして好きなテーマを選択してそれを仕事にすることを優先するなら、自営でやるか大企業かどっちかだ。中間はない。

　つきつめると、組織で仕事をするとなると、価値観は個人個人でバラバラだから、金銭的効率をもって仕事の価値とするというルールを設けないと収集がつかなくなるというのが真の理由である。何かの価値の大小を他人と「定量的に」議論するとなると、結局は金以外に基準の置きようがない。

　僕が人を雇うことを極力避けてきたのはそこが大きい。自分が忌み嫌ってきた不自由を他人に強制するのはどうしても気持ちのうえで抵抗があるのだ。

執念深さ

　どんな分野でも、成否がアイデアとモチベーションにかかっているような仕事をする場合、もっとも大事な要素は執念深さだと思うわけです。
　少々の失敗ではたじろがない心がないとやってられないので、手がける分野が好きでないと。いくら失敗しても執念深く継続するためには、好きな分野であることは必要条件。

　ソフトウェアというのは道具なので、何のための道具なのかというのが常につきまとう。純粋にコンピュータの世界で閉じているソフトウェアは例えばOSとかコンパイラとかVMとか仮想化環境とかだけど、それはソフトウェア全体からみればごくわずかな世界で、ほとんどのソフトウェアは「ソフトウェアの世界に生きていない人」が使うためのものである。

　なので、良いソフトウェアを作るためには、そのソフトウェアがターゲットとしている世界もよく知っている必要がある。
　プログラマとして優秀だが会計は素人、という人が会計ソフトウェアを作ってもろくなものにならないのは容易に想像できるけれども、実際の世界ではそういうのばかりである。
　知らない分野のソフトウェアを持ち込まれても機能の良し悪しを判定できないし、ましてや自分でアイデアを思いつくことはできない。同様にユーザの目からみても、基本的なところから説明しないと要望を伝えられないので無駄が多い。

　僕の場合は、トレーディングツール（しかも最初はクライアントサイド）を選択したのはそこが大きい。自分がよく知っていて、かつ興味ある分野なので、

* 機能のデザインを他人より（少なくとも相場を知らない人よりは）よくできる自信があった
* 既存のツールには「つけいる隙」がたくさん見えた
* もしデザインに失敗したり、他社に時期的に先行されたりしても、別のアイデアで挽回できそうな気がした
* ビジネス面でベストな結果にならなくても、自信のある分野で勝負して敗れたならそれはそれで満足感はありそう（失敗の理由を、不得意分野で勝負したから、としたくはなかった）

　という要因がこの分野にチャレンジした理由である。そしてなにより、「成功・失敗にかかわらずやっていて楽しそう」なのがポイント。
　大きなプロジェクトをイチからやるには最低３年はかかるので、新しいことにチャレンジできるのは20～40歳の20年と考えると、チャレンジの回数は多くとも６～７回となる。人生全体で６～７発しか持っていない弾丸をここで発射できるか？というのは大きな決断をするときにいつも考えることです。

　今日はこのへんで。次はお金の話をしようかと。
　あと、今のシリーズは、トレーディングのツールを作るというテーマでは自分の仕事はあと３年かそこらで収束できそうな見通しが立ってきたから書いているものです。（もちろんちっとも収束しない可能性もあります）
　次は全く新しい分野にチャレンジするつもりで、徐々に勉強を開始します。

価値をマーケットに判定してもらう

　前回の続きです。
　ソフトウェアの重要な性質である、

「作るのは大変だけど、価値のあるソフトウェアが安定稼働しはじめれば膨大な利益を生む」

　という状態にどうやってもっていくか？　というのがテーマです。

　まず大前提として、価値をマーケットに判定してもらうようなものでないとこの状態にはもっていけない。
　この対極にあるのが単純な人月単位の請負仕事で、作る製品が最悪のクソでまったく売上があがらなかったとしても契約の金額はもらえる（＝損失は発注側がかぶる）一方、大きな利益があっても当初の約束分しかもらえない（＝利益は青天井で発注側のものになる）というものである。

　価値をマーケットに判定してもらうということは、製作経費も回収できない可能性も相当高いということなので、何の実績もないまま参入するのは無謀である。もとの資金が最初からその覚悟を負っている場合（VCなど）に比べ、完全に自己資金でやるとなるとリスクはいっそう高い。少なくとも、プロジェクト初期から人をバンバン雇ったり立派なオフィスを構える余裕はない。

　前回書いたように、僕は資質的に経営は無理っぽいのと、他人資本でスタートしたためにたいへんな苦労をしている起業家を複数知っていた（他人資本だったというだけが苦労の理由ではないけども）ことから、自己資金でスタートするというのは確実に決めていた。
　もっとも独立当時での経験では大した知見はもってなかったけど、自己資金でスタートして後から情勢によって他人資本を入れるのは可能だけど、逆向きは不可能ということだけでも自己資金でスタートするには十分な理由である。

　さて自己資金で人を雇わずやる場合、どうしても長期戦になる。
　仮に自分が並のプログラマーの３倍の能力があったとして、
　ウォーズマン理論を適用した場合でも、素の能力で３倍・長時間労働で２倍・コミュニケーションによるロスがないことで２倍の効率で12倍のパフォーマンスを出すのがせいぜいである。
　これは純粋に技術面だけの話で、非技術的なことについての能力は自分は凡人と同等以下だし、長く続けるうちにはモチベーションの下がる時期もあるから、どうみても最初に売り上げがたつまでは最低１年は無収入で乗り切る必要があるわけだ。

　当時は独身だったし、相場での収益もあったので、１年間無収入という金銭面の負担は何とかなりそうだったが、それだけの時間を投入しつづける意欲が維持できるかどうかはちょっと自信がなかった。

　そこで最重要だったのが、「好きな分野のソフトウェアであるかどうか」である。これは本当に重要で、好きなことであるから長くつづけられるし、いいアイデアを思いつく可能性も高くなるし、そしてなにより、仮に無収入期間が長くなったりプロジェクトの失敗が見えてきたりした場合でも、精神的に乗り越えられそうな気がしたからである。

　僕の場合はその分野として相場に関するツールを選択したわけです。
　また続きを書きます。

ソフトウェア業でどう食っていくか

　ソフトウェア業でどう食っていくかを考えたら、次の３つのコースがある。

(1) 既存の会社の社員になって組織の一員になる
(2) (1)の組織を作って運営する側になる(新規に作るか、昇進を目指す)
(3) 組織から距離をおき独自に活動する(フリーランスなど)

　もちろん、この３つに優劣があるわけではない。どのコースになるかは個人の資質と意志と運で決まる。

　僕の場合は(3)を選択しているわけだけど、その目的はやはり「作りたいものを作りたいペースで作る」というのが最大だ。
　サラリーマンだと当然上からの指令で動くわけだけども、自分の意に合わないものを作るときのストレスといったら思い出すのもイヤである。その指令が出てくる理由というのも大抵それなりに合理的で、有効な拒否ができないのがまた嫌らしい。

　一方、組織を運営する側になるのも、エネルギーの大半を人間関係の調整に費やすことになるのでちょっとこれは得意分野ではない。技術者出身の経営者というのは自分のスキルと他人を鼓舞する力の両方に優れているのだろうけど、僕は資質的にそうじゃない。
　加えて、従業員を食わせていくために売り上げを維持しなければならないプレッシャーに耐えるのは相当つらい。特に、全員が頑張らないとその売り上げが維持できない場合には...
　これは大学生のときに経験済みだし、サラリーマン時代にも上司のやっていることを見てこれは自分には無理そうだと思った。

　そんな具合で、１～２年位前までは「(1)(2)が無理そうだから」という消極的理由で(3)を選択していた感がある。そうはいっても収入はサラリーマン時代の数倍になったし、それでもなお、顧客から見れば余所の会社に頼むより費用対効果は良いものを提供できたと思う。それで家族との時間もたっぷりとれるんだから、これで文句を言ったらバチがあたるというものである。

　これはモデルとしては漫画家とか映画監督の仕事のスタイルに近い。フルに雇うのはごく少数の人数で、本人は作品作りに集中し、他の必要人員はプロジェクト単位の契約で回していくというやり方である。「作りたいものを作りたいペースで作る」だけならこのスタイルが最適に近いだろう。

　しかし、その方法で自分の実力がわりと世間に通用するらしいことがわかってくると、徐々に飽きてくる。今の延長をしていくだけでも食うには困らないとわかるとリスクの許容度も上がってくるので、何か冒険をしたくなってくる。何か新しいチャレンジのネタはないかと考えはじめたけれども、僕はソフトウェア以外のことは大して知らないので、ソフトウェアの大きな特徴である

「最初に作るのは大変だけど、価値のあるソフトウェアが安定稼働しはじめれば膨大な利益を生む」

ということの本当の意味を真剣に考えた。しかも、今はAWSなどのおかげでサーバは何台立ててもタダ同然だし、開発ツールも優秀になっているので、個人レベルでも相当戦える時代である。
　そうしているうちにこのメリットを生かして勝負できるプロジェクトが舞い込んできたのでスタートを決定したのが約１年前のことである。

　続きは次回。

【予告】更新再開

　ここのところずーっと更新が絶えてましたが、そろそろ再開します。
　この間主に仕事面でいろいろあり、36歳ちょい前にしてようやく自分の仕事のやり方というか、「楽しくて儲かる」ソフトウェア業のための方程式のようなものを体得しつつある実感があるので、この話題で何回かに分けて書いてみようと思います。

　まあそんなに普遍的なものではなく、僕の性格と、主にこの時期の日本で活動しているという時代性から到達した方程式だけれども、「ソフトウェア業で仕事をしているが現状と先行きに不満/不安がある」という読者の興味を引ければと思います。

　全部一気に書ききれるボリュームではないので、今後２～３日に１回の更新を目指してやっていきます。

電気自動車買いました

　なんか最近は月イチくらいでしか書いてませんね。
　今年は仕事は激動の年でした。最近の情勢からいって来年はもっと凄いことになるのはほぼ確定なので、ひきつづき頑張ります。動きが公表できるようになるのは来夏くらいかな？

　最近のトピックとしては、自動車。
　僕は車は大して興味ないし、そもそも運転免許も持ってないが、子供２人いると何かと不便、ということで結局最近買いました。運転は専ら妻がやりますがね。
　必要な都度タクシーを使うとしてもトータルでは安上がりなのは確実なのだけど、考えた結果「所有する利便性」は確かにあるなあ、ということで買うことに決定。
　７～８年前のサラリーマン時代に、当時の同僚から「子供ができたら車は絶対必需品になるよ」と言われたことがあり、僕は「都心に住んでるなら不要」と反論した記憶があるが、見事に僕の負けになった。

　妻は最初、安い軽自動車でOK、と言ってました。
　一方自宅は、大きな一軒家風の建物に３世帯が入っている構造になっており、隣に住んでいる人はなぜかポルシェを２台持っている。家賃40万以上の家に住んで軽自動車というのも釣り合わないし、せっかく買うならテクノロジーの点でも新しい経験がしたいと思って考えた結論は「電気自動車」。

　そのカテゴリで選んだところ、三菱自動車のiMiev一択でした。ガタイが小さいので、運転経験豊富ではない妻でも余裕で車庫入れできそうだし、三菱といえば岩崎弥太郎やゼロ戦のイメージが強く好感度高いです。（その理由で決める人は少ないかもしれない）
　純粋に費用対効果でいえばプリウスとかのほうがよかったのかもしれないけど、それをいうなら全部タクシーで通すほうがいいことになってしまう。電気自動車のような未来的なテクノロジーに触れるのは面白い。なにしろ音が全然しないし、もし震災がなくてガンガン原発推進してればもっとも空気を汚さない自動車になったはずだし、いろいろ想像は膨らむデバイスである。

　こうなってくると自分で運転したい気も実はかなりあるのだが、「目の前にあるものがなぜか認識できないことが多い」「子供のころに遭った事故の記憶が邪魔をする」の２つの障害を克服する必要があるのでハードル高い。
　以前教習所に通ったときも、仮免許すら取れずに放り出された実績があるので、まあ自分で免許を取るのは仕事を引退してジジイになったあとの道楽としてとっておきます。

プログラミングスキルをどう身に着けたか Part2

　前回の続きを書こうと思いつつまた時間が空いてしまいました。相変わらず仕事は忙しく、明日から上海出張だし、ドタバタしてます。あと最近の目立った事件としては、オリンパスの空売りで大きく取ったくらいかな...

【Windows95】
　日本での発売は大学１年の秋だった。これにあわせてPCとあわせて新調するため、家庭教師やらゲームセンター店員やらのアルバイトで金をためて買った。
　なにしろ衝撃だったのは、「複数のソフトウェアが同時に走る」「変なメモリにアクセスしても、そのプロセスだけが死んでOSは死なない」というところだった。当時、自分の知識はほぼ8086アセンブラとBASICだけで、プロセッサのプロテクトモードの存在を知らなかったのである。素朴に、「複数のソフトウェアが同じアドレスを使ったらどうすんの？」と思っていたのである。
　勝手な思い込みで、Windowsはある種のエミュレータなんだな、だからプロセッサが100MHzもあるくせにこんなにモッサリしてるんだな、と結論づけていた。それだけ凄いことをしてるならしょっちゅうWindowsがハングアップするのも当然だな、と思っていた（これも勝手な思い込み）

　そういえばこのころも、PCのリセットボタンを一日に何回も押すのは常識でしたねえ。今では考えられないが。

【転身と武者修行】
　その後はVisual Basicで適当なゲームを作ったりしていたが、転機は大学２年の秋。それまで目標だった物理学者の道をあきらめ、ソフトウェアの世界に進むことにした。この決断の背景はいろいろあって書くと長くなるが、小さくない役割を果たしたのが「闘うプログラマー」。

　この本を読んで、自分にはベンチャースピリッツもけっこうあるらしい、と思ったのである。

　そこで、大学は１年間休んで（実際には、必修１科目だけを意図的に落としての自主留年）、ソフトウェアの勉強と実務を猛烈にやった。たまたまアルバイトで入ったソフトウェア会社が当時流行していた「プリクラ」のソフトウェアを担当しており、僕はいろんなバージョンのビルドと動作チェックをやってました。
　このバイトが週３～４日で、この稼ぎで大量に本を買って勉強の日々でした。（この過程でプロテクトモードの存在や、現代的なOSのアーキテクチャを知り、Windows95の謎が解ける）

【大学に戻る】
　その後、自主留年後に東大情報科学科に入り直し、さすがに時間がなくなってきたのでアルバイトは辞めることになる。
　情報科学科では、つまらない授業も多かったが、いくつか面白い経験もした。最大の収穫は、関数型言語を知ったことだ。Scheme、ML、Prologの演習ではプログラミングにはいろんな発想法があるんだな、と感動した。
　あと、５～６人でチームを組み、独自に設計したプロセッサの上でSchemeで書かれたレイトレーシングのコードを走らせる、という課題を半年かけて達成するというのも面白かった。僕はこのうちコンパイラ担当で、コンパイラの専門書（ドラゴンブック）を読んで実際に実装する、というのをやった。当時身に着けた知識は地道に今の仕事にも役立っているのが面白い。

　まあ、結果的には、大学４年間でやった内容の７割はムダだったと思う。でも、残りの３割は本当に価値のある知識と経験になったし、それは大学に行く以外の手段ではおそらく得られないものなので、トータルすれば有意義だったと思う。

プログラミングスキルをどう身に着けたか Part1

C 言語や Windows プログラミングはこのようにして習得したが面白かったので自分の遍歴も書いてみます。単なる昔話なので、他の人の参考になるかは不明ですが。

●ファミリーベーシック
　僕のはじめてのプログラミング体験は小学５年のときのファミリーベーシックだった。ある年のお年玉をつぎ込んで買ったはず。
　このときは大したプログラミングはしておらず、ファミコンのAボタンを押すとマリオがジャンプするくらいのことしか作らなかったと思う。
　というか、この時点では外部記憶装置はオーディオ用のテープしかなく、しかもこのテープレコーダは予算不足で買えなかったので、FAMILY BASICのカートリッジ内のメモリ（数KB）がすべてだったのである。

●PC-9801 RX2
　中学生になると同時(1989年)に、親にねだって買ってもらった。ディスプレイと込みで30万円はしたはずなので、決して安くない。マシンスペックはCPUが80286の12MHz, メモリ640KB, 5インチフロッピードライブ２台という構成だった。
　親にしてみれば、これだけの値段のする、何の役に立つかわからないものをポンと買い与えるのは悩みどころだったと思うが、当時はそんな心配は全くせず、ファミリーベーシックと比べてマシンスペックが何十倍にもなったことに狂喜するばかりであったのである。もちろん市販のゲームをやるのも熱心だった。
　今はNECというとダメなIT企業の代表格みたいな感じだが、当時は今のAppleやGoogleと同じくらい強固なブランドだった。

●ベーマガ
　やはりこの雑誌抜きには僕の中高生時代は語れない。毎月８日の発売日が楽しみで仕方なかったのを今でも覚えている。
　中心は読者が投稿するプログラム（殆どがゲーム）で、ソースコードが誌面に印刷されているのを１文字ずつ打ち込んでいくのである。これで手を動かしながら打ち込むことで他人の作ったプログラムの仕組みを学習し、今のプログラミングの実力の基礎ができたと思う。僕が参考にしていた投稿者は今は40～50歳くらいになってるはずで、直接には知らないけど今でも感謝している。

●アセンブラ
　投稿者のレベルは年々上がり、処理速度を稼ぐためBASICでは限界に達していた。アセンブラで書かれた作品が多くなり、ソースコードは一応BASICで書かれていても、「膨大な16進数の羅列をメモリにロードしてそこへジャンプするだけ」というのが珍しくなくなった。これの打ち込みは実に苦行である。そこで自分もアセンブラを勉強してみなくては、ということで買った本が「はじめてのマシン語」という本である。（今も売られているようだが、初版が1983年なのでたぶんこの本のはず。内容は当時とはもちろん違うはず）

　これで8086の基礎を学ぶとともに、「裸のコンピュータ」に接近した気がして、まさに寝る間も惜しんでむさぼり読んだ。VRAMが&HA8000から始まるのは今でもはっきり記憶している。

　なお、当時学校に置いてある生徒用のコンピュータは富士通のFM16βで、自分のPC-98とは違うところが多く、この本でPC-98に特化した知識に傾いてしまってからは学校のコンピュータ部とは徐々に疎遠になっていってしまった。

　印象的なエピソードとしては高校１年のとき、この本では解決できない問題にぶつかって、大きな本屋に行ったところズバリそれを解説している本を見つけたときのことである。確か、BIOSのシステムコールに関するものだったはずだ。
　本は5500円と高く（当時は小遣いが3000円/月で、ベーマガを買って数回ゲームセンターに行くと終わりである）、買うのはためらわれた。そこで本屋の床に座り込んで要点をノートに書き写し、さらにその本が売れてしまうことを警戒して本屋の中の全然違うジャンルの目立たない場所に隠し移したのを今でも覚えている。今思うと実にひどい話だ。
　だが、数日するとその本の別のページの情報が必要になり、学校帰りに本屋に行ってメモをする、というのを何度か繰り返し、ついに耐え切れなくなって親に泣きついて5500円もらって最後にはその本を買ったのである。今でもその本は実家のどこかにあるはずだ。

　なお、アセンブラをマスターしたといっても頭の中のプログラミングの発想法はガチガチのBASICのままなので、メモリは全てがグローバル変数という使い方だったし、「SPレジスタ」の用途もついに理解できなかった。
　PUSH AXでメモリに書き込むとともにSPが2下がる、という仕様が何のためにあるのかよくわからないし、このような変な動作がなぜたった１バイトの命令で実現されているのかも設計意図がまるで理解できず悶々としていた。
　自分のアセンブラのプログラムでは、大抵他のレジスタは別の用途に使いきっていたので、PUSH/POPのあとSPをわざわざもとに戻すコードを書いていたし、SPの戻し忘れは自分のコードのバグ原因で上位にきていた。

●紙にソースコードを書く
　BASICにしてもアセンブラにしても、ソースコードを方眼紙の上に鉛筆で書いてその上で「脳内コンパイル」「脳内デバッグ」をするのも多かった。
　これは、学校の授業中にもこっそりプログラミングができるという絶大なメリットがあった。嫌いな先生の授業のときにはよくこの手を使っていたものである。本や雑誌を見るのに比べて目立たないからね。

　だいたい、こういうことをしていたのは中学３年～高校３年くらいだったと思う。
　とはいってもコンピュータばかりしていたのではなくて、当時は将来物理学者になるつもりだったので、数学と物理の勉強のほうを優先してたし、PC-98あるいはアーケードゲームにも並ならぬ時間を使っていた。

　世間的には、そろそろWindows3.1の時代になっていたが、自分のPCは80286のままなのでWindowsは使えず、高校生の経済力では新しいPCは買えなかったので、BASICとアセンブラしか知らないまま大学生になるのである。

　なお、この時の経験があるので、僕は「大学で教える初級プログラミングの授業はアセンブラにすべき」という考えの持ち主だ。さすがに企業での教育はそんな回り道はできないが、大学でやるならJavaだのRubyではヌルすぎる。アセンブラをやらないと、「プログラム言語は何を解決する技術なのか」が理解できないから、というのが理由だ。(Part2へつづく)

#感想等はTwitterでもOKです

実はゲーセンの世界のソーシャルゲーム

　最近話題になったCEDEC2011での本城氏の講演について。
　僕はこの手のソーシャルゲームのビジネスモデル、すなわち人の射幸心・見栄・自己顕示欲を突いて金を絞るゲームには否定的なクチだったのだけど、これを読んでむしろ逆に評価したい気持ちになってきた。

　ここまで「一見さん」の興味を引くことをがんばっているのは、昔のアーケードゲームの世界に戻ってきたなあ、と思うわけです。僕のアイデンティティのけっこうな割合は1990～2000年のゲームセンターにあり（当時は総収入の7割はゲームに消えていた）、実は当時のゲームはこのソーシャルゲームの世界に近い。

* 少数のマニアだけでなく、「ちょっと待ち合わせまで時間のある人」「ちょっと休憩中の外回りのサラリーマン」が頭数的には主要な顧客
* 何の予備知識もなくふらっと店に入ったとき、100円玉を入れたくなる仕組みが必要
* 一度ゲームオーバーになっても、10秒以内にもう100円入れればコンティニューできる仕組みは常識だった（これは実はけっこうあくどい）
* その場にたまたま居合わせた人と会話に発展することはしばしばある

　など、けっこう共通点が多い。

　舞台がリアル店舗から携帯電話になっただけで、やってることは大して変わらないな、と思います。

　僕も社会勉強と思ってこの手のゲームを過去やってみたことはあるけど、ゲーム性が低すぎて10分もしないうちに完全にギブアップしました。なのでこういう毒にも薬にもならず、時間と小銭を浪費するだけのゲームはとっとと潰れてしまえというのが個人的にはあるのですが、最終的には「マーケットから評価されるものが正しい作品」なのでここに文句をつけても始まらない。

　でもまあ、歴史的教訓でいえばこのブームは長く続かず崩壊するよなあ。どういう形から予測できないけど、いつの間にか崩壊するのは確実と思う。1993～95年のスト２全盛期には、このブームが衰えるとは夢にも思わなかったのと同様で。

　いま現場でやってる人は大変だと思いますが、自分が今から飛び込もうとは「絶対に」思わないな。

マカオのカジノ

　何か書かなくちゃと思いつつ時間が過ぎました。
　先週、初めて香港＆マカオに行ってきたのでそのことを書きます。香港は仕事ですがマカオは遊びです。

　カジノとしての売上規模はラスベガスを超えたとのことで、どんな熱気なのかとワクワクしてたけど案外それほど人はいなかった。

　扱ってる種目・ルールもだいたい同じだし、カジノホテルの設計もラスベガスとほぼ一緒（僕が行ったのは割と新しいところなので当然だが）、主な違いは

●マカオ優位
* 日本からの距離が近い。時差も１時間のみ。
* 飯がうまい
●ラスベガス優位
* カジノ以外の娯楽が充実

　となるかなあ。

　ただ、マカオと日本の直行便は少ない（関空から週２～３便ある程度）ので、多くの日本人は香港から船で入ると思うけど、ここがもっと簡単になってほしい。船に乗っている時間は１時間程度（でも船独特の揺れがあって気分悪くなりやすい）だが、香港とは一応国が違うのでパスポートのチェックがあるし、けっこう移動が大変である。香港と高速鉄道で結ばれれば完璧だ。

　僕はカジノは好きだが、それだけのために飛行機乗って行くのは時間がかかりすぎる。なにしろ東京にできてほしいと改めて思う。仕事が終わったあととか、パッと行って２時間くらい遊んで帰る、という気軽さが必要だ。東京に作るなら都心ど真ん中、妥協してもお台場くらいの立地じゃないと。

　でもパチンコは18歳の誕生日に１回行ったこっきりなんだよな。タバコと騒音が苦手だし、レートが低すぎて「勝っても負けても時間の無駄」感が強い。カジノのいいところは、各自が資金力と遊びたい時間に合わせてレートを自分で決められるところだ。これがない賭け事は面白くなりようがない。もちろん、相場の世界はこれを満たしている。

「遅れているプロジェクトに追加人員を投入するとさらに遅れる」法則を逆向きに適用

　久々の更新です。
　相変わらず忙しいですが、最近の仕事の大きなポイントは上海と香港に良いビジネスパートナーが見つかったことです。いつまでも日本だけで活動してても明るい展望は描けないのでチャンスを伺ってましたが、来月ぐらいからこちらの新プロジェクトに本腰を入れることになります。日本が総体的にはだんだんダメになっていく、というのは抗し難い流れだけれども、震災と菅政権がそれをグッと加速させたと思う。

　今日書くのは、先月の「なぜ優秀なプログラマは人を雇わないか」に関連して、いかにして少人数の非請負型プロジェクトの成功確率を上げるか、という話。前から考えていたことを、新プロジェクト開始にあたって改めて整理してみた。

　ここでいう成功、というのは、きっちり黒字を出す、ということである。

　例題として、平均的なプログラマ10人のチームで10ヶ月かかるプロジェクトがあるとしよう。100人月だから、ざっと１人月50万としてその開発コストは5000万円だ。
　これは非請負型のプロジェクトなので、この製品がいくらの売り上げを生むかは事前にはわからない。1000万円だったら大赤字だし、３億円だったら大ヒットだ。もしあなたが何か製品アイデアを持っていて、ぜひとも実行したいというとき、このリスクをカバーする方法としては、大きく３つある。

(1) 大きな企業で開発する。大きな企業はこのようなプロジェクトが複数あるので、黒字のプロジェクトで他の赤字のプロジェクトを埋めれば会社は倒産しないし、あなたのプロジェクトが赤字でも個人的負債を負うことはない。
(2) 法人をつくり、VC等の外部資金を入れてスタートする。失敗の金銭的リスクは株主が負う。
(3) あなたと、短期的報酬を求めない仲間とで細々とやってみる。

　この(3)を選択した場合を考えてみる。
　ソフトウェアのプロジェクトマネージメントの本を読むと、どの本でも、「遅れているプロジェクトを挽回するため追加人員を投入するとさらに遅れる」と書いてある。もちろん過去の経験からもそれは正しい。このことの意味することは、プロジェクトメンバーの学習とコミュニケーションコストは非常に大きい、ということだ。

　この法則を反対向きに適用すれば、「プロジェクトから人を取り除くと早く進む」、ということである。早く、というのはやや不適切だが、一人当たり・時間当たりの生産性が高まれば費用はずっと安く済む。人をどんどん追加投入するすると爆発的に費用がかさむのは確かなのだから、人を減らせば費用は爆発的に安くなる。当たり前だ。

　この100人月のプロジェクトを、やる気に満ちた２人でやれば、100/2 = 50ヶ月かかるなどということはない。長くかかった場合でもその半分、25ヶ月もあれば十分できる。ひょっとしたら同じ10ヶ月でもできてしまうかもしれない。

　ここでのポイントは、初期費用の安さだ。もし２人で25ヶ月かけたとしても、2*25*50万=2500万だし、もしこの２人が独身で、かつ「プロジェクトの売り上げが立つまでは最低限の生活でよい」と覚悟を決めているとしたら１ヶ月20万のコストで十分であるから、2*25*20万=1000万あればよいことになる。

　同じものを作るのに費用が方法により5000万と1000万とであれば、話はずいぶん違ってくる。事前に売り上げ規模がまったくわからないときは、徹底的に安く上げて損益分岐点を下げておくのが重要だ。後から値下げする余力も出てくるし、利益の増加分を他の活動のために使えるので将来的な自由度が増す。

　もちろん良いことばかりではない。一番の危険は、リリースまで時間がかかっているうちに状況が変化することだ。25ヶ月というのはソフトウェアの世界ではいろいろなことが起きるので、当初の大前提が崩れていることも多い。有力な競合が出てくる前に先制攻撃したほうがよいことももちろんある。

　長くなったのでそろそろまとめると、ソフトウェアの世界で起業を考えるなら、最初は少人数で細々とやってできるだけ低コストで最初のバージョンを上げるのは有力な手である。とくに、

* すでに競合がいて、ある程度の市場が存在することが確認できている（競合がいない場合、単に市場が存在しないのが理由であることが殆どである）
* その競合はあまり高い実力があるように見えない
* 新規参入が現れる見込みが低い
* 好きな分野のプロジェクトである（少人数でコツコツ長期間の作業をするので、好きな分野でなければ続かない)

　という条件のときはそうだ。
　また、この方法だと、失敗だと思えば撤退するのも簡単、というメリットがある。会社やVC資金でやっていると、失敗したときに不本意な方向転換を迫られることが多く、これが精神的にはつらいのである。

　一応断っておくと、これは「自分と家族と仕事仲間が楽しく仕事をして裕福に暮らす」のをゴールとする場合の考え方だ。どんどん会社を大きくして上場目指すぜ、という考えの場合はあまりお勧めできない。

　でもまあ、いろいろな働き方が選択できるのがソフトウェア業のいいところだね。他の業種だとなかなかこうはいかない。

＃コメントはtwitterでも受け付けます

regazaの驚きの機能の件

　今回引っ越したときに、ようやく家のテレビも地デジ対応になりました。
　もともとテレビは１ヶ月に１～２時間くらいしか見ないので（半分はニュース、もう半分は娘と見る子供向け番組）、買い替える意欲は乏しかったのです。待てば待つほど性能あたりの値段は下がるし。

　そこで、新しいテレビ（東芝のregza）のマニュアルを一通り見たところ、驚きの機能がいろいろ。その中でもぶっちぎりの衝撃度だったやつを紹介します。
　このテレビはレコーダー機能が内蔵されており、HDDは別に買ってくる必要があるがUSBで繋げばすぐ使える。その関連で、「メールで録画予約ができる」という機能があった。

　これが凄すぎる。録画の指定方法は気が狂っているとしか思えない。この画像（マニュアルのページを撮影したもの）をみてほしい。

　このように、決まったフォーマットでチャンネルや時刻やパスワードをテキストで書いて送る仕様なのである。

　さらに、このやり方で録画予約ができるために事前に次の準備が必要だ！

●テレビをネットワーク接続する
　イーサネットのみで、Wifiは備わっていない。これは不便すぎるが、テレビは大きな電力を使うのでハードウェア上の制約かもしれず、これはまあ大目にみる。
●POPでメールを受信するための設定
　メールアドレスの準備、サーバ名の指定、パスワードの入力、等をテレビのリモコンでやるのである！
●メールを取りに行く時刻の設定
　通信がメールなので、毎時０分とか時刻を決めてそのときにテレビにメールを取りにいかせるしかない。つまり、録画したい時刻の直前にメールを送っても間に合わないってことだ。

　これだけで、一般の人はもちろん、エンジニアだってやる気が出ないよねえ。

　でも、この機能の根本的な欠陥はそういうことではなく、

●録画予約が成功したかどうかをエンドユーザ（技術のことはわからない一般の人）が同期的に知ることができない
　→これがとにかく致命的。通信インフラにメールを使うのがそもそも誤り。メールはTCP上に構築されたUDPなんだから、この機能の発案者は世の中でTCPとUDPがどういう役割分担になっているかも知らないようだ。
●この機能を使いたいのは外出中のときであるはずだが、マニュアルがないとメールのフォーマットが全くわからない。
　→せめて、この一連の手順を確実にするためのWebサイトくらいはメーカが作るべき。Web上の番組表から選択して予約完了、くらいのインタフェースにしないとだめだろう。

　の２つだ。
　この機能を、興味本位でなく実用的な用途で使うユーザは一人もいないと容易に断言できるが、果たしてメーカの東芝はそれをどれくらい認識しているのか？　これはリリースできるレベルでないのは常識で考えて明らかだと思うが、どこかにストップをかける人はいないのだろうか？　そうだとすれば、100年経ってもAppleと同じ土俵に立つことすらできないだろう。

　むしろ、割り切ってテレビにsshでログインしてシェルでいろいろできるようにしてもらったほうが面白そうだ。

引っ越しとCATVのインターネット接続

　10日ほど前に自宅を引っ越ししました。
　前の住居は子供２人だとちょっと狭いなあ、と思ってたところに近所に良い物件が出たので。マンションと違いテラスハウス風なので子供が飛び跳ねても迷惑にならないし、新築なので設備も豪華です。近所に凄い警備の豪邸があったので「これは政治家かヤクザだな」と思ったら実は最高裁長官の公邸でした...

　ところで、今回はCATV回線が設置済みだったのでインターネット接続もCATV提供のものに切り替えたのだが、ちょっとトラブルがあったので書いておきます。
　似た症状の人に役に立つかもしれないので。

【症状】
* 接続がきわめて不安定。
* ときどき(実測で１時間に５回程度)、すべてのTCP接続が一斉に切れる。
* ただし切れても"1秒後"には復旧している

　というもの。
　Webだけならギリギリ我慢できるが、SSHやVPNや各種トレーディングツールはこれでは話にならないので困りものである。Webで検索したりした結果を総合してヒントを得たところ、「IPv6が悪い」ということがわかった。Windows側でIPv6を使わない設定にすればきれいに現象はなくなった。
　原因がOS(Windows7)にあるのか、CATVのモデムあるいはその先のネットワークにあるのかは不明だが、ルータは無罪と思われる。（ルータを介さずに直結しても現象は同じだったから）
　同じWindows環境を別のネットワークで使っていたときは正常だったので微妙な問題なのだろうけど、ごく標準的な構成のWindowsで出るのだからこれにひっかかる人はけっこういそうだ。

　この件でがっかりしたのは、CATV側に問い合わせても、「モデムの電源を入れ直せ」とかの実効性の乏しそうな指示しか来なかったことだ。いくらなんでも、この件でトラブルを抱えたのが僕が初めてだとは思い難いのだが、ひょっとするとIPv6はまだ一般の人に実用に耐えるほどには周辺のデバイスが整備されていないのかもしれない。
　確かにWifiも出始めの頃は互換性問題に悩まされたので、IPv6の実情はそのくらいなのかもしれない。