Life is beautiful

　昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。

　まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。

　ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部分の見極めのためのコーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大切。

　まだ半信半疑の人も多いだろうから、具体的な例をしめそう。先日のエントリーにも書いたCloudReadersとneu.Notesのコードを組み合わせて「PDFの赤入れ」を可能にしようというプロジェクト。当初計画していたアーキテクチャではうまく行かず、次のアーキテクチャで作ってもうまくいかず、ようやく三番目で「商品化する価値のあるアーキテクチャ」にたどり付けた、という典型的な「大幅な仕様変更を伴う」プロジェクトだ。

　実際にどうやって作ったか言えば、「仕様書も書かず、UIの細かな設計もせず、とにかく肝となる部分をスタートダッシュで手早く作る」を三回繰り返しだだけのこと。一つ目のアーキテクチャに基づくプログラミングに約３日かけた後、それを破棄、二つ目のアーキテクチャに基づくプログラミングに約２日かけた後、それを破棄、そして三番目のアーキテクチャに基づくプログラミングに同じく２日だ。

　この段階で大切なことは、

• 書いたプログラムを捨てることを恐れないこと
• この段階で仕様書を書くことは時間の無駄と認識すること
• 細かなことを無視して、一番難しい部分を最初に作ること
• できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと
• コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること

の５つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定しているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと（たとえば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど）に時間を使わず、とにかく一日でも早く「見極め」ができるところまで持って行く。

　この「見極め」の段階で、「このアーキテクチャではだめかも知れない」「これではユーザーモデルに矛盾ができて使いにくくなる」と感じたら、ばっさりと切り捨てて、もう一度作り直す。アーキテクチャに不安を抱えながらずるずると作り続けても決して良いことはない。

 【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで８割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す（コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など）。

　二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。

　しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ（デス・マーチ）にハマるのがこのパターン。

　かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。

　ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。

　「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分がデタラメな人はいないのに、プロとして仕事をしているプログラマーの大半が、明らかに弊害の多い「ラストスパート型」だというのはあまりにも情けない。

　そんな思いを込めて書いたのが、今回の「WEB+DB PRESS Vol.57」に書いたコラムー「『締め切りは絶対に守るもの』と考えると世界が変わる」（リンク先に全文が公開されている）。

　たぶん、いつものように１００人中９９人の人は実行に移すことはできないだろうが、一人でも二人でもこのコラムに影響を受けて、プロとしての自覚を持って「スタートダッシュ型」で仕事をする人を増やすことができれば幸いである。

[追記]　特に学生の人たちにぜひとも実行していただきたいのが、このコラムの最後に書いた「授業の前の予習に8割の時間を割き，残りの2割の時間を授業直後の復習に使う。そして，試験前は一夜漬けなどけっしてせずに，体を十分に休めてフレッシュな頭で試験に臨む」という勉強スタイル。この手のリズムは、出来るだけ若いうちに体にしみ込ませておくことが大切。学生時代に「試験前日の一夜漬け」スタイルで勉強をする癖がついてしまうと、そのスタイルが社会人になってまで尾を引き、このコラムで書いたようなラストスパート型のだらしない仕事スタイルで毎回苦労することになる。「いつも締め切りに追われていて仕事が辛い」と愚痴をこぼす社会人プログラマーに知り合いがいたら、学生時代にどんな勉強の仕方をしていたか質問してみると良い。ほぼ確実に「一夜漬け型」か「学生時代には勉強なんかしていなかった型」だ。

　CloudReadersというPDF/マンガリーダーを個人で、neu.Notesという手書きノートアプリをneu.Pen LLCを通して開発・リリースしている私だが、当然のようにその二つを組み合わせて「PDFの赤入れアプリ」を作って欲しいというユーザーからのリクエストは聞こえて来るし、私自身も欲しい。

　これまで二つのプロトタイプを作っては見たのだが、どうも気に入らないのでリリースは見合わせている。

　最初に作ったのは、CloudReadersに "Annotation Mode" (赤入れモード)を追加したバージョン。とりあえず赤入れが出来るところまでは三日ぐらいであっさりと動いたのだが、「シンプルでサクサク読める」ことを最優先に設計されているCloudReadersの場合、追加した書込みを常に表示するのかしないのかでかなりパフォーマンスに影響が出るし、「赤入れモード」という明示的なモードを追加してしまうことが、そのシンプルさを失わせてしまうという点がどうも気に入らない。

　それに加えて、ユーザーがiTunesから見ることのできるファイルはオリジナルのPDFなのか、赤入れ後のPDFなのか、というユーザーモデル面での曖昧さも生じてしまうため、「そちらの方向で押し進めるといつかどっかで破綻する」という「エンジニアの勘」が強く働き、この方向は見送ることにした。

　次に作ったのが、neu.NotesにPDFを読み込む機能を付け加えた neu.Annotateという別アプリ。CloudReadersともneu.Notesとも違う、別のアプリとして作れば、ユーザーモデル面での曖昧さも回避できるし、「赤入れモード」のような「モード」を避けることができる。しかし、作っているうちに、iOSのPDF関連のAPIに致命的な欠陥があることを発見した。埋め込みフォントをちゃんと処理できないのだ。

　PDFには受け取り側で送り側の表現したいものを１００％再現することを可能にするために、フォントを埋め込む機能が付いているのだが、iOSのAPIを使ってPDFを再構築すると、この埋め込みフォントが抜け落ちてしまい、ちゃんと表示できないのだ。

　元のPDF原稿を画像として埋め込むという荒技まで含めて色々と試したのだが、「どんなPDFを与えても、それに赤入れしたものを新たなPDFとして出力することができる」ようにするためには、自前PDFパーサーを作らねばならないという結論に達し、これも断念した。

　第三の手段として、現在開発中なのが、CloudReadersとneu.Notesを別アプリのままで連携させるという方法。CloudReaders側で文章を読んでいる時に「Annotate（赤入れ）」ボタンを押すと、そのページのみを画像としてneu.Notesに渡してそこで赤入れができる、という仕組みである。

　この仕組みであれば、neu.Annotateのような別アプリをインストールしてもらう必用もないし、それぞれのアプリのユーザーモデルを妙に変化させる必用もない。ページも画像渡しなので、埋め込みフォントの問題もない。唯一の欠点は、赤入れした文章がばらばらになってしまうことだが、そこは使い方・運用しだいで色々と工夫ができる。

　ようやくプロトタイプが動きはじめたので、次のアップデートではこの仕組みを含めたものをリリースしようかと思う（たぶん、CloudReaders 1.13 とneu.Notes 1.3）。

　ちなみに、この仕組みの興味深い点は、CloudReadersからneu.Notesに画像を渡す部分のプロトコルを公開してしまえば、他のアプリからでも画像をneu.Notesに渡して赤入れしたり、上に文字や絵を書くことが可能になること。neu.Notesをアップデートした際には、プロトコルの仕様をここで公開する予定なので、iPad/iPhoneアプリの開発者の方々にはぜひともお試しいただきたいと思う。

　この仕組みを作りながら思ったのだが、各アプリは出来るだけシンプルに作っておき、それをこんな風にユーザーが自由に連携させながら使いこなして行く、というのがiPhone/iPadアプリの本来あるべき姿なんじゃないかということ。

具体的には、

1. 初項のPDFを編集者からメールで受け取る

2. そのPDFをDropboxにしまっておく

3. 出先で時間のある時に、Dropboxから"Open With..."でCloudReadersで開いて推敲する

4. 気になった部分を含むページをneu.Notesに渡して赤入れする

5. それをメールで編集者に送り、同時に、自分のEvernoteアカウントにCCしておく

のような感じだ。Microsoft Officeに代表されるパソコン用のリッチ・クライアント・アプリは、すべての機能をアプリそのものに含めようと肥大化の一途をたどったが、iPad/iPhone用のアプリはの進化の軸というのは、こんな風にそれとは大きく異なったものになるのでは、と思う今日この頃である。

　先日の「電子書籍のiPadアプリ化サービス：ベータ版プレゼント」にはたくさんのご応募をいただき、大変感謝している。個人用・商用ともにそれなりのニーズはあるようで、これから商用・非商用の両方でボチボチと電子書籍アプリをリリースして行くので期待していただきたい。

　その第一弾とも言えるのが、先日リリースしたばかりの「うさ犬の里　夏の日編」という絵本アプリ。塚本秋遷さんという絵本作家の作品をアプリ化したもので、ご本人からの許可をいただき無料で配布させていただいているので、ぜひともお試しいただきたい。

　JPEG画像をZIP圧縮したものと、CloudReadersのリーダー部分を組み合わせて、アプリ化しただけのシンプルなものだが、こうやってアイコンを付けて、起動画面を作って、ウェブサイトへのリンクを付けて、iTunesストアから配ると一人前のアプリになってしまうからなんだか楽しい。

　ちなみに、問い合わせは「商用に使いたいのでライセンス料はいくらか知りたい」「CloudReadersを使った本を出版する会社を起業したいので手伝って欲しい」というストレートなビジネス案件から「同人紙をアプリ化したいが協力してもらえないか」というものまで幅広く、多くの人がいろいろなレイヤーで電子出版に興味を持っていることが分かる。

　今後も、面白そうな本の書籍化の話であったり、実際のビジネスに結びつきそうな場合であれば、まずは評価用のベータ版を作るところまでぐらいなら対応できると思うので、submit（アット）cloudreaders.comまでご連絡をいただきたい。

 　私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。

　私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。

　私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化」がいかに米国のそれと異なった進化をしているかを一時間ぶっとうしで解説したのを覚えている。

　その講演の中で、非関税障壁で海外メーカーを実質的に閉め出し、日本という島国の中だけで数多くの日本のメーカーがしのぎを削るという特殊な環境で、携帯電話が海外と比べて異常なスピードで進化している状況を「ガラパゴス状態」と呼んだのが始まりである。

　もちろん、その当時は私自身も「日本メーカーに海外進出のチャンスあり」と見ていたので肯定的な意味で使っていたのだが、それが今や「独自すぎて海外で通用しない」というネガティブな意味になってしまっているのは何とも皮肉である。

　日本の携帯電話がなぜ海外で通用しなかったのかについては、このブログでも何度も書いて来たのでここでは繰り返さないが、ぶっちゃけて言えば、

　勝てば官軍、負ければガラパゴス

というひと言につきると思う（ちなみに、これは私が発明した言葉ではなく、ブログの読者がコメント欄で書いたことば）。

　問題は「独自」であることではなく、自分が作ったものを世界市場で成功させたり、自分が決めた仕様を「デファクト・スタンダード」にするのが下手な点にある。

　NTTドコモは、iモードを国内で成功させるだけでなく、WCDAMの標準化に大きく貢献したり、AT&T Wirelessに投資をして3Gネットワークの構築を促したり、と実は色々と努力はしたのだが、結局のところ「縁の下の力持ち」にとどまり、一番おいしいところはQualcommやAppleに持って行かれてしまった、というのが現状である。

　何が行けないかと言えば、結局のところは交渉力と政治力とマーケティング能力で、なんだかそのあたりは幕末の不平等条約以来あまり変わっていないんじゃないかと思う。

　そうは行っても、CD, DVD, Blu-rayなんかの標準化に関しては、日本のメーカーも結構活躍していたわけで、そのあたりに何か学べるものがあるはずだ。

　まあ、とにかく大切なことは、積極的に開発投資をして、自分がイノベーションを起こす側に回ること。先日も「（ePubやHTML5の標準化会議の場で）外国の人たちに縦書きの重要性を話しても理解してもらえない」と嘆く日本の技術者に会ったが、嘆く暇があったら自らがWebKitやFirefoxを進化させる側に回り、そこでリーダーシップを取る立場に立った上で、縦書きを自ら実装してしまい、既成事実としてデファクト化する、ぐらいの強引なやり方を取るべきだと思う。

　「ガラパゴス化」を恐れて、他社と違うこと本流でないこと、を避けていたらイノベーターにはなれない。「そんな特殊なことをしていたらガラパゴス化しますよ」というコンサルタントには気をつけた方が良い。

　一説によると、今の人間の先祖であるホモ・サピエンスは、ちょうどガラパゴスのような隔離された環境で短期間に異常進化をとげたのだという。強烈な生存競争に勝ち抜いたホモ・サピエンスは、島からでると、先住民をあっという間に滅ぼし、世界の覇者になったという。「ガラパゴス世界を制す」の良い例である。

　結局のところ、独自であろうとなかろうと、世界で通用する製品を作らなければだめだということ。勝たなければだめだということ。「勝てば官軍、負ければガラパゴス」である。

　最近、CloudReadersと並行して力を入れて開発しているのが、手書きノート作成用の neu.Notes。1.1が致命的なバグを抱えていたために、すぐにアップデートをしていただいたユーザーにご迷惑をかけてしまい、大変申し訳ないことをしてしまった。被害を最小にするために、ストアから一度引っ込めておいたのだが、ようやくそのバグも取れ、1.2として仕切り直しのリリースである。今度は、1.0からも1.1からもきれいにデータを引き継げるように作ってあるので、ご安心いただきたい。

　ちなみに、今回のアップデートには大小のさまざまな機能が含まれている。

１. 外部ディスプレー・サポート　

　これは私自身が欲しかった機能だが、VGAアダプターでプロジェクターに繋ぐことにより、現在描画中のページをプロジェクターに表示するようにした。この機能を使えば、会議室におけるホワイトボード代わりに使うことができる。ホワイトボードと同じく、会議の終わりにそれを全員にメールすればそれが議事録の配布になってしまうこと。

　もう一つの使い方は、インタラクティブなプレゼン。パワポで作ったスライドを画像としてneu.Notesに前もって取り込んで置けば、プレゼンをしながらそこに手書きで色々と書き込むことができるので、作ったものをただ順番に表示するだけのパワポでのプレゼンよりも、ずっとダイナミックでインタラクティブなプレゼンができる。もちろん、プレゼンの最後に、手書きメモ付きのプレゼン資料をメールで配布するなども簡単だ。

２. 高速なUndo

　neu.Notesは、すべてをベクターデータとして扱っているので、Undoの回数に制限はない。しかし、それゆえに、1.0はベクターの数が増えると、Undoのスピードが落ちるという欠点があった。1.2は、ベクターとビットマップを巧みに組み合わせたキャッシュを使うことにより、この問題を克服した。私の知る限り、（１）Undoの回数に制限がなく、かつ、高速、（２）高速に自在に拡大縮小ができる、（３）描いたものをベクターデータとしてイラストレータに渡せる、というすべての条件を満たしたiPad/iPhoneアプリは他に無い。

３. ページの削除

　1.0 に対する質問でダントツに多かったのが、「どうやってページを削除して良いかわからない」という質問。1.0にはページの削除の機能がなかったので、見つからなくて当然だったわけで...。

４. ノートのタイトル

　私自身は、「最初のページにタイトルを手書きで書けば十分」と思っていたのだが、やはりテキストでちゃんとタイトルを付けて整理したい、というユーザーの声が多かったので、1.2からはタイトルを付けることを可能にした。

５. Twitterへの手書きメモの投稿

　これもユーザーからのリクエストを反映させてのこと。ストレージはTwitPicを使っている。

６. PNG/PDFに加えて、JPEGでのメール送信

　メールで写真や画像を投稿するスタイルのサービスで、JPEGしか受け付けないものがある、というフィードバックを受けて追加した。

７. 写真の回転 

　これはすでに、neu.Kidsには入っていたもの。neu.Kidsと共有している描画エンジンのアップデートとともにneu.Notesにも追加した。

　neu.Notesはこれからもどんどん進化させて行く予定なので、ぜひともフィードバックをいただきたい。