Posted 10月 6th, 2011 by Tom
ものすごく悲しい知らせだった。
今朝、何気なくアップルのトップページを見たら、Steve Jobs の写真が大きく貼ってあった。
最初、何かのプロモーションと思って、ブラウザを閉じた。「待てよ」と思ってすぐに開き直した。
1955-2011 ？
それから、もしかしてと思って、彼の写真をクリックした。
信じられなかった。それから、ニュースサイトを見た。twitter や FBをチェックした。
その後、しばらく涙が止まらなかった。
彼を初めて見たときは、アップルの社員食堂だった。いつもの黒のタートルネックとジーンズ姿で、
アラビアの人とランチをしているときだった。小柄な男だと思った。その姿が思い出された。
今、僕が毎日元気に生きているのは、本当に彼のお蔭だ。
彼の発表した初代 iPhone をシアトルで買ってから、その後の今日までの僕の時間のほとんどは、iPhone をはじめ、彼がデザインした Apple 製品とともにあった。
それから、くる日もくる日も、iPhone , iPad のアプリを開発した。
彼の作った製品を手にする多くのユーザさんが、どんな思いを持って、アプリをさわるか、いつもそこには、
「Jobs ならこう考えるだろう」
という思いが、僕にはあった。鏡のような存在だ。
彼は数百数千の素晴らしいアイディアに対して NO と言い続け、彼の世界観で製品やサービスを出し続けてきた。彼を見ていると、多数決を押し切って、自分が信じられるサービスを出していくことが、いかにこの業界で大切かというのを再認識できた。
多くの孤独なCEOたちに、模範を示してきたと思う。
そして、今、僕らは彼の作った製品とサービスの上で、僕らが作ったアプリに大きな夢を託し、人生の多くをそれに費やし、毎日を生き生きと過ごしている。
Thank you, Steve Jobs. R.I.P.
Posted 5月 10th, 2011 by Tom
毎年５月（昨年は加えて１０月）に、母校の早稲田大学で非常勤講師として Start up に関する授業を担当させてもらっています。
例年、
- 学生でのスタートアップ
- シリコンバレーでのスタートアップ
- 映像配信事業
について、授業していたのですが、今回は３回目は映像配信ではなく、
- スマートフォン事業
についての内容になります。
２年前の授業で、twitter を知っている人というのを聞いたところ、あまり学生で知っている人がいませんでしたが、昨年はかなりの人が使っていました。
昨年の授業では、DropBox や Evernote について知っている人を聞いてみましたが、あまり知っている人がいませんでした。今年はかなりの人が使っていると思います。
東京にシリコンバレーで産まれたサービスが伝播してくるまでに、今でも３年くらいの時差があります。
そこから、日本の地方に伝播するまでに、さらに２年くらい掛かります。
もちろん、単純に情報を知るだけならば、そんなに時間が掛からないのですが、それが生活にしみ込むには、結構、長い時間が掛かります。
これをふまえた上で、サービスをどうやって組み立てていくか、というのは非常に面白い課題です。
Posted 3月 17th, 2011 by Tom
昨日から、僕のところに「今は東京を去った方がいいか？」と訪ねる人が数人いた。
僕は即座に答える。
「YES. すぐに移動した方がいいよ」
僕は心配性だから、朝から晩までずっと放射線の計測値を、色々なサイトで見続けている。数値が問題ないことを確認してオフィスに向かうし、帰宅もそうだ。
その結果、言えるのは、まだ安全だということ。
そして、原発事故に関していうと、歴史的な事例と比較しても、現段階で東京から移動するのに十分な理由はない、と判断している。
だけど、友人たちには、移動できるならすぐ移動するようにと伝える。
理由は、これまでとは少し違う街に適応するには、体力がいるから。
これは、長期戦になる。
人によっては、少々厳しい現実を、毎日受け止め、
それを希望に変えながら、突き抜けていく力が必要だ。
今、東京から離れたいと思っている友人は、
僕以上に不安を抱えていると思う。
少し休んでから、戻ってきてもいいと思うし、
より安全なエリアで、次の準備をしてもいいと思う。
とにかく移動する必要がある人は、早く移動。
休養をとったら、
例えば、原発に替わる安全なエネルギーを開発するとか、
例えば、津波の心配がない場所だけで人が生活できるシステムをつくるとか、
例えば、燃料や食料がそうそう不足しない社会構造を作るとか。
そういうところに、時間を使っていった方が良いと思う。
Posted 3月 14th, 2011 by Tom
Tom です。写真は、３月１２日土曜日、地震の翌日の朝一番の新宿駅京王線の改札前に溢れる人です。
３月１１日（金）の昼過ぎ、大きな地震がありました。
僕は東京の早稲田大学インキュベーションセンター内のオフィスにおり、大きな揺れを社員とともに体験することになりました。
いつもにない大きな揺れ。。。
その夜から、翌朝にかけて、いわゆる、帰宅困難者でした。
最初の地震のあと、僕と社員は、いつもよりは早く仕事を片付けて、18:00すぎくらいに帰ろうと思ってバスに乗ろうとしたら、満員すぎて乗れずにおりました。（仮に乗れたとして、大渋滞の道を走り、ようやく駅についても、電車が動いていなかっただけでしたが。）
タクシーもつかまらずでした。道には、自宅に向かう公共交通機関を失った、大量の人が歩いていました。
結局、僕はそのままオフィスに泊まりました。 そして、オフィスで津波の様子を改めてみました。これはやばいことになったなと、そこで強く実感しました。
帰宅に向かった社員が戻ってくることも考えて、コンビニに食糧買いに行ったら、オニギリとパンは売り切れ。仕方ないので、カップケーキ数個と、コンニャクだけのおでん、それから、焼きそば弁当を何個か買って、オフィス待機してました。
オフィスでまず考えたのは、身の安全。ガラスが多いし、物が多いし、危ないので、なるべく生き埋めにならないように、ガンガンにNHKを付けて寝ないようにしてました。
実際、地震が来るたびに、大きな音で緊急地震速報が流れるので、ほとんど寝ることなく、朝までいけました。
それから、自分たちが人のためにできること。これは、ライブ配信すべきだろうと思い、NHKに配信許可の打診を2回したけど、相手がつかまらず。
結局、配信は無許可ではできないので諦めました。
早稲田オフィスには、他社もみんないたので、適当に時間を過ごしながら励ましあって朝になりました。
朝の始発のバスに、オフィスの事務所の人たちと乗って、今朝の7時前に新宿に。ところが、大混雑の新宿駅。いつになったら乗れるのか分からないくらいに改札の前の人だかりでした。 これが写真の様子です。
仕方ないから、しばらく歩こうと言うことになり、早稲田オフィスの事務局の人と、西へ向かって歩き出す。。。
途中、あまりにも寒くてビルの中に入ると、
どこも避難所になってて、ビニールシートに、
サラリーマンやOLが寝転がってました。まさに、ドラマでしか見たことない光景。
歩き続けてると、やはり寒くて、最後は、途中の駅にいき、何とかそこから、電車に乗れました。
家に帰って、取り合えず、寝ようとすると、停電の恐れありとのことで、すぐに買い出しに。
携帯トイレと、電池買ってきました。
その後も眠ることなどできずにいました。こんな感じの一日でした。
まだ、どこも、とても大変な状況だと思います。皆さまと、ご家族のご無事をお祈りします。
Posted 1月 14th, 2011 by Tom
ウェブサービス、携帯サービスの仕事に関係するに当たって、エンジニアの基本的なチェック項目を洗い出そうという目的で、このページは書いています。多くは実際の失敗を元に書いています。
主に、以下のようなことです。
「受託の仕事は気をつけて、安易に請けないこと（エンジニアが最終責任を持つ事が多いし時間の負担が大きすぎる）」
「ネット環境では、OSやブラウザの更新時にも、未知の障害が必ず生まれるから、常に試験を繰り返し繰り返し行うこと」
「新しい機能追加、設定変更したら、そこにはだいたい障害が発生すること」
「デザインや仕様の企画が遅れにともなって開発が遅れるなら、迷わず納期を遅らすこと。試験だけは絶対に省略しないこと」
くどいですが、どんなサービスでも、事前の繰り返し試験が重要だということを書いています。
[計画段階] 基本的に全体がベストエフォートで動いているインターネットで、事故のないサービスを創るのは不可能。どんなサービスでも事故があることを前提にして、取り組みその事故をなくすような計画をしていくこと。そして、自分たちが経験不足の時点では、事故が起きてからでないと分からないことが、無数にあることを自覚すること。受託仕事の場合は、うんと予算を確保してもらうこと。
[計画段階] 技術をネタに企画する人のことは、基本的に無視すること。多くの場合、本番でトラブルを起こすのは、不安定なネットに乗っかっている技術の部分。
[計画段階] サービス開始時には、必要最小限の機能しか入れない。演出は最後。企画する人、デザインする人は機能追加したいと言ってくるけど、考えを改めるように説得するべき。必要最小限のことしかしない。未来永劫、OSやブラウザの更新があるだけで、新しいバグが生まれ続ける。機能過多のサービスは機能しなくなるのは時間の問題。ネットサービスなら対応ブラウザは、できれば１個か２個まで。機能は後で増やせばいい。
[計画段階] ウェブサービスが本番に入ったあと、大切なタイミングで障害が起きたら、エンジニアが責任を持って対応することになる。その時間的負担は大きすぎる。事前にそのことを考えた上で、仕事に取り組む事。小さなエンジニアの会社は、受託開発を安易に受けるべきではない。
[計画段階] 実際に試した結果以外は、基本的に信じてはいけないし、設計に組み入れてはいけない。予測値は大切だけど、現実社会はエンジニアの予測を裏切る。
[開発段階] 顧客の用意する、セキュリティがしっかりとしたデータセンターに納品しなければならないような仕事は、その作業だけで３ヶ月は、取られてしまうことを自覚すること。顧客の環境にぴったりと合ったシステムを最初から開発しないと、納品時に変更が大きくなることも自覚すること。
[開発段階] サービス本番と同じ試験を行わないで本番に乗せないこと。最低３回くらいやらないと駄目。できれば１年間無料でユーザさんに使ってもらうこと。それでも、ユーザ環境がかわり続けるため、バグは永遠になくならない。
[開発段階] デザイン会社の納期の遅延が発生した場合は、サービスの主体者は、リリース時期を遅らす事。無理に進めると、システムでは、ろくな試験もできずに本番に入り、失敗する。エンジニアはそのことを、きちんとサービス主体者に伝えること。
[運用段階] サービスに使う新しいマシンが Windows の場合、Windows update を一度施したら解除しておくこと。そうしないと、サービス停止する日がやってくる.
[運用段階] ロードバランサ、リバースプロキシ、Firewall の設定を行った際に、domainname.com の他にも、www.domainname.com など、頭に www. をつけたサブドメイン設定が完了しているかどうかも確認しておくこと。
[運用段階] DB を手動で変更したときには、それがユーザ環境に関係することなら、その影響を受けるユーザのアカウントと同様の環境を作って、すべてのページにログインして、チェックする事。それをやっておかないと、ユーザに多大な迷惑を掛ける。
[運用段階] 緊急対応時、通常のフローと違う対応を行ったら、十中八九、そこに新たなバグや事故が発生する。だから、試験をすること。新しい機能を追加したときも同じ。エンジニアは基本通り設定したかもしれない。でも、すべてのユーザ環境で試験することはできないから、バグが発生する。
今後、また、ここに追記します。
Posted 1月 2nd, 2011 by Tom
新年あけましておめでとうございます。
本年もよろしくお願い申し上げます。
今年は書き初めに「瞬」という字を選びました。
何事も、瞬く間に過ぎ去る毎日の中で、
テンポ良く、仕事をやっていけるように。
Posted 12月 13th, 2010 by Tom
先ほど、ご案内したマナビューイングですが、
来年の１月からは、連続して、武田双雲先生の授業が受けられますので、
ぜひ、この機会にご覧ください。
よろしくお願いいたします。
Posted 12月 13th, 2010 by Tom
本日、日宣さんとウタゴエで、学びのライブ配信局 manaviewing をリリースしました。
このサイトは、普段、なかなか受講することができないような有料セミナーを、
インターネット上で多くの人が受講することができるように、という思いで
リリースしています。
今まで、ありそうで、なかなかなかったサイトですので、
よろしければ、ご覧ください。
初回は、武田双雲先生の講義が無料受講できます。
先生、日宣さんの皆様をはじめ、ご協力頂いた、
関係者の方々に、心より御礼申し上げます。
Posted 10月 19th, 2010 by Tom
本日、夕方１８：３０より、早稲田大学の授業で講演します。
早稲田出身の Quality Experience Design さんの太田社長もご一緒とのことで、とても楽しみです。
最近、ブログや twitter ではかけないような出来事が多いのですが、主に、ライブ映像配信の事業で、中長期的なサービスの立ち上げに時間を割いています。
今年は、スマートフォンへの対応に時間を割いていて、もうじき、あるアプリを世の中に出していけると思います。
Posted 4月 30th, 2010 by Tom
Tom です。
今朝がた、nobi さんのポストで気がついたのですが、Jobs が Flash を使わない理由のレターを出していました。
http://www.apple.com/hotnews/thoughts-on-flash/
Twitter に書いておくと、流れていってしまうので、ここにメモしておきます。
理由１：オープンなものを採用。Flashはオープンではない。(HTML5 や WebKit など Apple はオープンなものを採用）
理由２：the full Web であるかどうかの検討。Adobe の主張は正しくない。
理由３：信頼性、セキュリティ面（Mac をクラッシュさせる１番の原因が Flash)
理由４：バッテリー寿命の問題。Flash は、H.264 のハードウェアエンコードができない.
理由５：タッチデバイス向けかどうか。Flash が要求するマウスオーバーはタッチ向けではない。
理由６：最も大切な理由。Apple は、開発者に、世界の誰も経験したことないような最高のものを創ってもらいたい。Adobe Flash は、クロスプラットフォーム対応を最優先するので、この Apple の目的とは異なる。
結論：FlashはPC 時代のもの。もしかしたら、Adobe はすごい HTML5 のツールをつくるべきかもしれないね。
