Life is beautiful

「逃げ切りメンタリティ」とは、私が執筆中の書籍（エンジニアとしての生き方）で初めて使った造語だが、「サラリーマン経営者が、『とりあえず自分の退職金が出るまで会社が存続してくれれば良い』と問題を先送りして、リスクを避けた経営をする心理状態」のことを指す。

使い方は、こんな感じだ（一つ前のエントリーより引用）。

しかし、そんなことをするとハードウェア全盛の時代に働き盛りだった４０代５０代の人たちは自分たちの居場所がなくなるし、万が一失敗した場合は自分たちの退職金も危うくなるわけで、今の経営陣にこんなことを言っても馬の耳に念仏。彼からからすれば、とにかく自分が円満退職するまで会社が存続してくれることがなによりも大切。余計な冒険などせずに、問題をできるだけ先送りにして、今のままの形で次世代にバトンタッチするのが一番の得策。そんな「逃げ切りメンタリティ」が今の日本をだめにしている。

「最近の若者が元気がない、会社に入ってもすぐ辞めてしまう」などの年配の人の言葉は良く聞くが、逆に今の若い人たちが今の社会に漠然と感じている不公平感や将来への不安を作り出している現状を表すにはどんな言葉が良いかを考えて作った言葉だ。

もちろん、すべてのサラリーマン経営者に当てはまる話ではないが、やはりソフトバンク孫さんやユニクロの柳井さんとかが魅力的なのは、オーナー経営者ならではの「当事者意識」が発言の端々に見られるからだと思う。全盛時代のソニーやホンダが魅力的だったのも全く同じ理由だ。

会社の株の１%も持っていないサラリーマン経営者に「当事者意識を持って、株主価値を最大化することを考えて経営しろ」と言ってもなかなか難しい。ストックオプションなどの仕組みはあるにはあるが、この問題を最も手っ取り早く解決するには、やはり企業の新陳代謝しかない。

JALの様に経営破綻した会社を無理矢理存続させたりするから当事者意識が欠けたサラリーマン経営者ばかりの社会になってしまうのだ。破綻した会社・新しい価値を生み出せない会社にはさっさと消えてもらい、オーナー社長が率いるベンチャー企業に新しい雇用をどんどんと生み出してもらった方が日本全体もずっと活気づくし、若い人たちの元気も出ると思うんだがいかがなものだろう。

昨日の「日本のケータイが『ガラパゴス化』した本当の理由」には沢山のコメントをいただいたが、その中には、「じゃあ、日本はこれからどうすれば良いのか」という質問があったので、私の考えを少し書いてみる。

まず、ケータイやテレビのように消費者向けのデバイスを作るのであれば、世界規模でビジネスをすること以外は考えない方が良い。先のエントリーで書いた通り、日本の携帯メーカーは、単に「ソフトウェアの開発能力・デザイン・おもてなし」で負けているだけでなく、ビジネスの規模の違いから、部品の調達コスト・製造コストでAppleに大きく引きはなされているのだ。「悪かろう高かろう」では勝てるわけがない。

もし、日本のメーカーがAppleやSamsungと本気で戦おうとするのであれば、（１）コスト面での徹底的な合理化をはかり（役員のお抱え運転手を廃止する、年功序列で給料だけが高くなってしまった人たちに辞めてもらう、系列会社からのなあなあの部品調達をやめる、製造は中国にアウトソースする、ミーティングと仕様書作りに時間をかけるのをやめる、ボーナスを現金ではなくストックオプションで支払う、など）、（２）ソフトウェア重視の会社に大きく変革し（トップをソフトウェアが分かる人にする、ソフトウェアの開発を子会社や派遣社員に任せるのはやめて正社員に自らソフトウェアを書かせる、GoogleやMicrosoftから理工系の修士号・博士号を持ったトップエンジニアを高給で引き抜く、など）、（３）最初から海外でのマーケットシェアを死にものぐるいで取りに行く（AppleやSamsungに匹敵する規模での部品調達をして一気に勝負をかける）、ぐらいの極端なことをするべき。

しかし、そんなことをするとハードウェア全盛の時代に働き盛りだった４０代５０代の人たちは自分たちの居場所がなくなるし、万が一失敗した場合は自分たちの退職金も危うくなるわけで、今の経営陣にこんなことを言っても馬の耳に念仏。彼からからすれば、とにかく自分が円満退職するまで会社が存続してくれることがなによりも大切。余計な冒険などせずに、問題をできるだけ先送りにして、今のままの形で次世代にバトンタッチするのが一番の得策。そんな「逃げ切りメンタリティ」が今の日本をだめにしている。

などとネガティブなことばかり言っていてもしょうがないので、もう少し建設的なことを言うと、「ガラパゴス状態であるからこそ、世界にない進化をとげた技術・商品・サービス」に目を向けて、それを本気で海外でビジネスとして展開すべき。

ちょっと考えただけで、お財布ケータイ+スイカ、ウォシュレット、ワンセグ、瞬間湯沸かし器、コンビニ、やたらにおいしい果物（桃、イチゴなど）、などがある。日本に住んでいるとあたりまえすぎて気がつかないかもしれないが、日本企業が日本国内で「世界に誇るべきおもてなし」を提供している分野はまだまだたくさんある。それぞれのお国事情があるので、必ずしもそのままの形で普及するとは限らないが、すくなくともやってみる価値はあると思う。

特にお財布ケータイは米国でもかなり注目されており、ここ１〜２年が勝負（ひょっとするともう遅いかもしれないが）。日本のメーカーは例によって「技術力と実績」で懸命に売り込みをかけているとは思うが、大切なのは政治力とスピード。本気で取りに行くなら、「VISAとQualcommとの三者で合弁会社を作って力技でAT&TとVerizonに押し込む」みたいなことをするべき。お財布ケータイ回りのパテントと、強い円の力を持ってすれば、Qualcommあたりをたらし込むのは十分に可能だと思うんだがいかがだろう。

「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。

まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな意味ではない。

当時は、まだ（今は亡き）Sun MicrosystemsがJ2ME/MIDPの仕様とそれをパソコンの上でエミュレートするWireless Toolkitを発表したばかりで、米国の通信キャリアが販売している携帯電話はJava VMを搭載するどころかまともなブラウザーさえ載っていない旧式のものであった。それに対して、日本はiモードのおかげて世界初の携帯コンテンツ・ビジネスまですでに立ち上がっており、欧米よりは少なくとも２４ヶ月は進んでいるというのが私の見立てであった。

当時、米国の通信業界では「これからはデータ通信の時代だ」というかけ声だけはありながら、日本という島国で起こっている「ケータイ・ビジネス」「ケータイ・ライフスタイル」の急速な進化のことを知らない業界人ばかりだったので、警告を与える意味でも、日本で何が起こっているかをドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えるスピーチをしたのである。

あれからもう１０年近くになるが、当時は世界のどこよりも進化している携帯電話を作っていた日本のメーカーも、今やAppleの横綱相撲とAndroidを担いだアジア勢のコモディティ戦略の狭間で生き残りさえ難しい状態である。

私が本来ポジティブな意味で使っていたガラパゴスという言葉も、今や「日本国内だけの独自規格を作って世界に通用しなくなること」という一方的にネガティブな意味になってしまったのも、この状況を見ればしかたがないのかも知れない。

しかし、一つ困ったことは、この「ガラパゴス化」という言葉が、独創的だったりリスクの高かったりする意見に対する格好の逃げ口実に使われてしまっていること。そもそも、合議制で「出る釘（もしくは杭）は打たれる」という突出したものを嫌う文化の日本で、これを言いはじめたら何も新しいことができなくなる。

考えてみて欲しい。MicrosoftのWindowsにしろ、AppleのiPhoneにしろ、結果的に勝っているから誰も何も言えないが、ガチガチの独自規格である。日本のケータイが世界に通用しなかったのは、独自規格だったからではなく、ドコモや日本のメーカーのやり方が生温かったからに過ぎない。

私は、当時たまたま、AT&T Wirelessの重役連中と近い位置にあったので良く知っているのだが（当時のUIEvolutionの会長は、元AT&T Wireless CEOのSteve Hooper）、ドコモはせっかく大株主になって取締役の座を持ったにも関らずAT&Tからは完全にただの「財布のヒモの緩いダンナ」と見られていたし、ドコモと一緒に米国に進出するはずだった日本のメーカーも「AT&Tはドコモみたいな大量の発注を約束してくれないから、先行投資はできない」と全くの及び腰であった。

それに比べて、なりふりかまわずにシェアの拡大に走ったSamsungの実行力にはすごい勢いがあったし、消費者のニーズを的確につかんだRIMのBlackberryはまたたくまにシェアを伸ばした。

その結果、iPhoneが引き金となったスマートフォンの時代が来る前から、日本の携帯電話メーカーは海外からほぼ撤退していたし、それがソフトウェアの開発投資の面でも、部材の調達コストの面でも大きく不利に働くことは目に見えていた。

つまり、日本の携帯電話メーカーが今の窮地に陥ったのは、「日本独自の規格のケータイを作っていたから」でも、「iPhoneとAndroidが世界を席巻したから」でもなく、iPhoneが登場する以前の、２０００年代前半の経営判断のミスにあるのである。

日本のメーカーにiPhoneに対抗するケータイが作れない原因はいろいろとあるが、もっとも致命的なのは「ターゲットにしている市場が小さすぎる」ことにある。こんな状況では、ソフトウェアの開発に莫大な資金を費やすことは到底無理だし、部材の調達コストもAppleやSamsungよりもはるかに高くなる。

分かりやすく言えば、「世界を相手に巨大なビジネスをしているハリウッドには、日本市場だけをターゲットにしている日本の映画業界は予算面だけ見てもかなうわけがない」のと全く同じ状況が日本のケータイ業界に起こっているのである。

ということで、再度繰り返すが、日本のケータイ・メーカーがこんな状況になってしまったのは、独自規格のためなんかではなく、ドコモからの「調達」という甘い蜜に飼いならされた日本のメーカーの経営陣が、２０００年代の前半にリスク覚悟で海外に本気で進出する、という戦略を取らなかった・取れなかったことにある。言い換えれば、ケータイがガラパゴス化したから負けたのではなく、メーカーの経営陣が（肉食獣のいない島国で）ガラパゴス化したから負けたのである。

週末はクリスマス休暇でロスに住む長男が遊びに来ていたのだが、金曜日の朝になって面白そうなFacebookユーザー向けのサービス案を提案して来たので、さっそく作ってみた。２４日にはクリスマスパーティもあったし、テニスも毎朝していたので、正味プログラミングをしていた時間は３０時間ぐらいしかなかったのだが、発案からわずか３日でサービスがローンチできてしまうとは（Google App EngineとFacebook APIのおかげ）、ずいぶんと便利な時代になったものだ。

日本ではまだまだだが、米国では人口の７割以上がアカウントを持つと言われるFacebook。Twitterでの不特定多数向けの「つぶやき」よりも、友達・知り合い間での「プライベートなコミュニケーション」向けのFacebookは、どちらかと言えばmixiに似ている。mixiとの根本的な違いは「大人も使っている」点。

特に最近は、「プラットフォーム」としてのAPIを充実させて来ており、簡単なソシアル・ネットワーク・アプリを作るのであれば、Facebook APIを使った方が、アカウントの管理も楽だし、「フレンド・ネットワーク」にもアクセスできるし、Wall（自分専用の掲示板のようなもの）にメッセージをポストすることによりバイラル・ネットワーク効果も狙える、という一石三鳥のすぐれものだ。

今回作ったもの（Facebookアカウントを通じたネットワーク効果の測定中なので、まだここにはURLを公開しない）は、まさにそんなアプリの典型。Facebookアカウントでログインしてもらうと、Facebook APIを利用して友達のリストを取得し、その友達との間の「遊びの場」を提供する。この仕組みを使うと、Facebookの中と同じように「友達間に限定したコミュニケーション」をFacebookの外に簡単に築くことができるのがすばらしい。

ちなみに、このサービスは最近だいぶ慣れて来たGoogle App Engine上に作った。特にフレームワークのようなものは使わず、今まで作って来たアプリのコードをあれこれと再利用しながら構築したのだが、とにかくユーザー認証の部分を１００％ Facebook API に頼れるというのが何とも楽。クローズなアプリなのでSEOの必要もないので、データはすべて json over HTTP で取得して、JavaScript側でHTMLを生成するという方法で構築。

このアーキテクチャ（ユーザー認証はFacebookにまかせ、Google App Engine上にPythonで json over HTTP なAPIを構築し、JavaScript側でUIの生成）だと、ものすごく開発効率が高い（一度ちゃんとした解説本でも書きたいのだが、時間が...）。

Facebook APIがプラットフォームとしてどのくらい使い勝手が良いかを示すために、このアプリのソースコードを一部公開する。

まずは、「フレンド・リスト」を取得したのち、このサービス内にアカウントを持っている人のIDだけを抜き出す部分。

gdispatch.route(lambda: ('/api/friend/list', FriendListHandler))
class FriendListHandler(webapp.RequestHandler):
    @login_required
    def get(self):
        graph = facebook.GraphAPI(self.current_user.access_token)
        connections = graph.get_connections("me", "friends")
        if not connections:
            return self.response.out.write('{"success":false, "errors":["failed"]}') 
        friends = connections["data"]
        ids = ['fb:%s' % friend['id'] for friend in friends]
        users = User.get_multi(ids)
        result = ','.join('"%s"' % user.id for user in users)
        self.response.out.write('{"success":true, "result":[%s]}' % result)

login_requiredは私が作ったFacebookアカウント専用のデコレータで、ここでユーザー認証をしている（認証済みのユーザーオブジェクトは self.current_user に格納される）。そしてfacebook.GraphAPIで認証したユーザーのアクセストークンを使ってアカウントに紐づいたAPIオブジェクト（graph）を取得し、次の行で「自分（"me"）のフレンドリスト（"friends"）」を取得している。

ユーザーに代わって Wall にメッセージを書き込むのもとても簡単。

gdispatch.route(lambda: ('/api/comment/submit', CommentSubmitHandler))
class CommentSubmitHandler(webapp.RequestHandler):
    @login_required
    @gdispatch.kwargs
    def post(self, message):
        graph = facebook.GraphAPI(self.current_user.access_token)
        graph.put_wall_post(message)
        self.response.out.write('{"success":true}')

今になって考えてみると、Microsoftがいっとき力を入れて広めようとしていた Microsoft Passport（今は Windows Live IDと呼ばれている）は、まさにこんな風に他のウェブサービス向けの「ユーザー認証プラットフォーム」になることを狙っていたもの。大風呂敷を広げた割には市場に全く受け入れられず、いつのまにかベンチャー企業のFacebookにこんな大切な部分を持って行かれてしまったとはなんとも皮肉なものだ。

しかし、少なくともMicrosoftはFacebookの株主である点が救い（Microsoftとしては買収をしたかったが、Facebook側が拒否したので、しかたがなく投資をしたというのが一般的な解釈）。Facebookのプラットフォームとしての台頭が許せないのはGoogleだろう。GoogleもGoogleアカウントという仕組みを持ってはいるが、プラットフォームとしては全く不十分だし、Google WaveにしろGoogle Buzzにしろ、FacebookやTwitterに対抗しようというGoogleの試みはことごとく失敗している。Googleとしては、例によって「（facebookみたいなクローズドなものではなくて）オープンなOpenIDを使おう」という作戦に出て来ているが、今後どうなるかは何とも言えない。

私のように利害関係を持たない第三者は、とにかく開発効率を重視するので、対立関係にあるGoogleとFacebookそれぞれのプラットフォームを組み合わせてアプリを作ったりできるので、それはそれで痛快だったりする。

Google App Engine でのサービスの運用実績を積むために作った「おまかせニュース・リーダー」、細かな微調整が効いて、「人気リスト」「おまかせリスト」にそれなりに読む価値のあるニュースが並ぶようになってきた。

ただ、自分で使っていても「今は時間がないけど、これ後で読まなきゃ」と思う事がしばしばなので、「後で読むリスト」の作成のためにブックマーク機能を付け加えた。

「ブックマークは他にも色々用途はある」という人もいるとは思うが、私の場合９９％が「後で読む」ため。そこで、それに最適化するために、操作も最低限で済むように単なるトグルスイッチにした（書くエントリーの右上に表示される"[B]"がそれ。ただし、Facebookアカウントでログインした人だけに見える）。

ブックマークをしたい時はそれをクリックするだけ。コメントとかを追加する機能も無い代わり、ワンクリックですばやく出来るのが利点だ。

ブックマークを付けたものは、タブの"Bookmark"をクリックすると表示される「後で読むリスト」に追加されるので、後はそこに行って読みたいニュースを読むだけ。不要になったら、"[B]"ボタンを再度クリックしてブックマークを外すだけ。

ちなみに、当然だが、この「後で読むリスト」はFacebookアカウントに紐付けされてサーバー側に保存されるので、複数のデバイス（もしくは複数のブラウザー）からアクセスしてもリストは共有される。iPhoneでブックマークしておいたものをパソコンで読む（もしくはその逆）、という用途には便利だと思うがいかがだろう。

金曜日（日本の土曜日）にリリースしたばかりの、「おまかせニュース・リーダー（仮名）」、今のところ順調に動いている。

このわずかな間にも、色々とデータが集まったのでいろいろと勉強になった。使っていただいた方たちのおかげである。感謝、感謝。

上のチャートが過去２４時間のトラフィックを表したもの。７時間ほど前に山があるのは、appengine の cron と taskqueue を使って一日一回のデータの集計と解析を行っているために起こっている疑似トラフィック。

外部からのトラフィックはコンスタントにあるし、フィードのフェッチのためのcronタスクも動いているので、インスタンスが寝てしまうことはなく、常に２〜３個が走っている。CPUは無料Quotaの３０％ほどを使っている。

ほとんどのレスポンスは、50 cpu_ms以下で返せているが、「omakase」リストの生成だけが、1000 cpu_ms ほどかかっている。一番複雑なことをしているところではあるが、ここは少し改良の余地がある。

そんな中でも、以下の三つの点は早急に対応が必要と感じたので、最初のアップデートをした。

1. Feedのソースが少し乱雑すぎたため、クリックされやすい低俗なタイトルのものが「人気リスト」に上がる傾向があった　→Feedのソースを絞ることで解決。

2. 日本語のニュースが、英語のニュースに混ざっていた　→これはFeed側が返して来る言語コードにバグがあったため。データベースのフィールドを手動で上書きして解決。

3. 「Omakase」リストと「人気」リストが似る傾向があった　→これはアルゴリズムの問題。単純平均から加重平均にして解決。

まだまだ追加したい機能・改良すべき点はいろいろとあるが、リリース初日よりはかなり良くなっているはず。

とりあえずはこんな感じで少しずつ改良を加えて行こうと思うのでよろしくお願いする。

ここのところ、iPhone/iPad アプリの開発から Google App Engine 上のサービス（neu.Notes ユーザー向けのプレミアムサービス）の構築に少しづつ比重を移している私だが、本格的な商用サービスを立ち上げる前に、もう少し app engine 上のサービスの構築・運営に慣れておく必要があると感じて作ったのがこれ。

正式名称もないしドメインも取得していないのだが、 仮の名前は「おまかせニュース・リーダー」。世の中の動きを効率良くつかむためには、主要なニュースの少なくともヘッドラインに目を通す事は大切。はてなブックマークの人気エントリーはノイズが多すぎるし、かといって、わざわざ自分でRSSフィードを登録したりメンテナンスしたりするのは面倒。

そこで、特になにもしなくても、自然に使っているうちにしだいに賢くなって自分向けのニュースを選んでくれるサービスというのがあれば良いと思い、作ってみたわけだ。

使い方はいたって簡単。ブラウザーでこのサイト（http://cloud-readers.appspot.com/）を開くだけだ（最新版のSafari、Firefox、Cromeのみで動作確認済み）。

ログイン前は、Hot/New/人気/最新の４つのタブが表示される。このあたりは、はてなブックマークの人気エントリーや新着エントリーと同じで、特に個別ユーザー向けの情報は提供していない（というか、ログインしていないのだからできない）。私が独断と偏見で適当に選んだニュースフィードからの情報を、単に人気順・新着順に表示しているだけだ。

特別なことをし始めるのは、ログインをしてからだ（Facebookのアカウントが必要）。ログインすると、Omakase/History の二つのタブが追加される。最初はどちらも当然「空っぽ」だ。

そこで、まずはHot/New/人気/最新の４つのタブの下に表示されるニュースで興味があるものをいくつか読んでみて欲しい。その後で、History タブを開くと、読んだ記事へのリンクが表示される。あたりまえと言えばあたりまえだ。

そんな感じで１０個ほどニュースを読んだ後で、Omakaseタブをクリックして欲しい。私が作ったアルゴリズムがちゃんと動作していれば、あなたが読みたいようなニュースが（正確には、同じようなニュースを読んだ人たちが同じく読んでいるニュースが）表示されるはずだ。

アルゴリズムは、多くの人が使えば使うほど、賢くなるように作ったつもりだが、これだけはテストが非情に難しいので、実際に使っていただきながら改良して行こうと思う。

ちなみにこのサービス、あくまで「実験」段階のサービスなので、とりあえず「アルファ版」と呼んでおく。バグの報告や、ご要望などあればこのエントリーへのコメントとしていただければ、ありがたいが、過度の期待はご遠慮いただきたい。

ところで、このサイトは、以前に「RESTful MVCなアーキテクチャの話」に書いた通りに、サーバー側では、スタティックなテンプレートとJSON over HTTPのウェブサービスのみ提供し、クライアント側で View と Model の結合をしている。いずれ時間を見つけて（Google App Engine側のソースも添えて）詳しく解説したいと思うが、待ちきれない人はソースコードを読んでみると良いかもしれない。

相棒のPeteと４月に始めたneu.Pen LLCとして、４つ目のアプリになる "neu.Annotate PDF" （iPhone/iPad共通）をリリースした。PDFファイルに自由に書込みのできるアノテーション・アプリだ。例によって無料なので、iPhone/iPad/iPad touch をお持ちの方はぜひともお試しいただきたい。

neu.Notes のようにフリーハンドで手書きのアノテーションを書くだけでなく、一度書いたものを移動したり、テキストや画像やスタンプを貼付けたり移動したりなど、通常のアノテーション・アプリと比べてかなり高度な描画機能を持ち合わせているのが特徴だ。neu.Notesだけでなくneu.Drawとも共有している描画エンジンが活躍しているのだ。当然、最終出力もすべてベクターなので、アノテーション済みのPDFファイルも高画質での印刷が可能だ。

ちなみにこのアプリ、開発を開始したのは６月。最初に試作したのは CloudReaders で使っているPDFリーダーのコードに、neu.Notesの描画エンジンを組み合わせたもの。私はそれでも十分に使えると思ったのだが、「読むことに最適化されたUIでは使いにくい」とPeteからのダメ出し。

次にPeteが試作したのは、neu.Notesベースのコードに、PDFを背景として表示する仕組みを加えたもの。それなりに動くところまでは作ったのだが、アノテーションを付けたPDFを新しくPDFとして出力すると埋め込みフォントが正しく表示されないという（iOSのAPIのバグに起因する）バグを発見。そのバグを回避するために、各ページを画像に変換んしたりなどの工夫をしたのだが、どうしても商品価値のあるものには仕上げられなかったので、その時点で一旦断念。

そのまま「お蔵入り」になるかと思ったのだが、アップルが iOS 4.2 でそのバグを修正したことを１１月の初旬に発見。その時点で急遽リリースを決めた。本来なら１１月はneu.Notesの有料オプション（Google App Engine上に作っているクラウド・サービス）の開発に全力を費やす予定だったのだが、その時点では、Peteも私も「２、３日でリリースできる」と見ていたので、そのくらいの寄り道は問題ないと思ったのだ。

しかし、実際に、iOS4.2向けに作り直したものを見ると、ページ送りのUIがいまいち不自然。今度は私がダメ出しを出す番だ。「出荷前の仕様変更はすべきではない」というのが鉄則だが、その不自然さはどうしても我慢できなかったのだ。

そこでPeteがその部分を改造しはじめたのだが、そのためには neu.Notes で使っている描画エンジンも含めた大改造が必要なことが判明。その改造のために、neu.Notes、neu.Draw まで改造するはめになり、当初の予定より大幅に時間がかかり、アップルにアプリを提出したのは、１２月に入ってからだ。

「出荷前の仕様変更でリリース時期が大幅に伸びる」という典型的なパターンだ。結果的には良いものができたので、満足はしているが、neu.Notesの有料オプションのリリース・スケジュールが伸びたのが少し痛い。来年の春にはリリースしたいと考えているので、その時はよろしくお願いする。