つれづれなる・・・

■[Dev] Titanium Mobile で開発した iPhone アプリに AdMob を導入する 12:24

バージョンアップ開発中のすき間iPhoneアプリDM@chatにAdmobを表示したくて調べたけれど、あまりきれいにまとまった手順がなかったので、自分のためにも残しておく。

Titanium Mobile の提供元である Appcelerator から AdMob 用のモジュールも提供されたので、それを iPhone アプリに導入するための手順です。

Appcelerator Developer Blogよりmodules提供のお知らせのポストだと手順がわかりづらかったので、それより新しめのAndroid導入用のポストの動画を参考にさせてもらった。

1. Appcelerator の github から AdMob modules をダウンロードする

いくつかのmodulesがgithubで公開されている。

1. 今回必要なのはiPhone用のAdMobモジュールなので、この階層(admob/mobile/ios)まで移動する。
2. このディレクトリ内にある、「ti.admob-iphone-***.zip」というファイル名を見つける。
   • 自分が確認したときは ti.admob-iphone-1.0.zip と ti.admob-iphone-1.1.zip が置かれていた。
   • このファイルはビルドされた時に生成されるべきzipファイルだと思うけど、すでにが置かれていたのでビルドの必要はなかった。
3. zipファイル名をクリックする。
   • 今回の場合、「ti.admob-iphone-1.1.zip」にした。
4. 次に表示された画面にて「raw」リンクをクリックする。ダウンロードできるので適当な場所に保存する。

2. Titanium Mobile プロジェクト内へ配置する

1. ダウンロードしたzipファイルをプロジェクトディレクトリ直下(Resourcesやtiapp.xmlと同じ階層)に移動する。
2. zipファイルを開き解凍する
3. modulesディレクトリが作成される。
   • 中身は今回の場合、iphone/ti.admob/1.1/... のようになっている。
4. 不要になったzipファイルを削除する。

以下のように、Resourcesディレクトリとtiapp.xmlファイルと同じ階層に「modules」ディレクトリが置かれればOK。

3. tiapp.xml を編集する

1. tiapp.xml を適当なエディタソフトで開く。
2. <modules></modules>の部分記述を変える。
   • 今回はバージョン1.1なので、以下のように記述した。

	<modules>
	    <module version="1.1">ti.admob</module>
	</modules>

4. (一度動作確認したければ、)example/app.js で動かしてみる。

1. プロジェクト内の app.js を適当な名前にリネームして、modules/iphone/ti.admob/1.1/example にある app.js をコピーしてくる。
2. Titanium Studioのメニューより、該当のプロジェクトに対して、Project > Clean を実施する。
   • すでに作成済みなプロジェクトに AdMob を導入しようとしている場合は実施しないと、シミュレータ起動時にエラーになる。
   • ビルド時に生成されたファイルを削除してくれる。
3. Titanium Studioのメニューより、Run > Run を実行して、シミュレータを起動する。
4. AdMobが表示されればOK。
5. exampleからコピーしてきた app.js を削除し、リネームしたものを app.js に戻す。

5. オリジナル app.js に追記する。

起動時に app.js がビューする場合は、以下を app.js に追記すれば良い。adviewをWindowに入れれば表示される。

publisherID の部分は事前に AdMobサイトでアプリを登録した際に発行されるIDを入力してください。

var Admob = require('ti.admob');
var win = Ti.UI.createWindow({
    backgroundColor: 'white'
});

var adview = Admob.createView({
    top: 0, left: 0,
    width: 320, height: 50,
    adBackgroundColor: 'black',
    testing: true,
    keywords: '',
    publisherId:'***************' // 取得したIDに置き換えてください。
});

win.add(adview);

自分の場合、app.js は tabGroup の設定のみなので追記した先は app.js ではなく、tab 内の window で指定されているファイルにそれぞれ以下のように追記した。

AdMob が上部で、その下が TableView を表示したかったので top を定義している。

var win = Ti.UI.currentWindow;

// Admob
var Admob = require('ti.admob');
var adview = Admob.createView({
    top: 0, left: 0,
    width: 320, height: 50,
    adBackgroundColor: 'black',
    testing: true,
    keywords: '',
    publisherId:'a14f1d41c54f42c' // Replace this string with your own API key!
});

win.add(adview);

var data = [];
var tableView = Ti.UI.createTableView({
    data:data,
    top:50, left:0,
    width:320,
    minRowHeight:58
});

win.add(tableView);

6. シミュレータを起動してみる。

1. Titanium Studioのメニューより、該当のプロジェクトに対して、Project > Clean を実施する。
2. Titanium Studioのメニューより、Run > Run を実行して、シミュレータを起動する。
3. AdMobが表示されればOK。
   • もしこれでもエラーが起きる場合は、Titanium Studioで新規プロジェクトを作成し、Resouces フォルダをコピーしてやり直すのが良いと思う。

以下のような感じで無事表示できましたと。

参考URL

• 大体の手順のイメージを捉えるのに役に立った
  • http://m-50.jugem.jp/?eid=9
  • http://d.hatena.ne.jp/kaz_konno/20110305/1299344159
• Appcelerator Developer Blog
  • http://developer.appcelerator.com/blog/2011/07/building-apps-with-modules.html
  • http://developer.appcelerator.com/blog/2011/09/admob-for-android-module-tutorial-and-code.html

ツイートする

■ twitterのユースケースを考える 17:02

最近メール以外の手法として、twitter, facebookで連絡を取り合うケースが増えている。twitterでフォローしあっていればDMを送る。もしくはfacebookのフレンドになっていればMessageを送る。という具合で、face to faceで会ってお互いのプロフィールが分かっていて、それなりに関係が継続できている人に使っていると思う。多分、スマホにtwitterクライアントアプリやfacebookアプリを入れていれば、push通知よりリアルタイム性の高いやり取りが取れることを期待してる面もある。

半年くらい前までiPhoneのtwitterクライアントアプリとして、Echofonを使っていた。Echofonが買収された後はフリー版でもMentionやDMもpush通知してくれるようになり、通知が来るたびにEchofonを立ち上げて確認していた。

しかし、ある時Echofonを起動する時にすごいストレスを感じていることを自覚した。その理由はアプリ起動時にタイムラインも読み込むので、たった1つのMention or DMを確認するために無駄なトラフィックが流れている、またタイムラインの未読部分がずれてしまう。ためだと分かった。

Echofonのいいところは、タイムラインをどこまで読んだか情報を保持して異なる端末間でも同期してくれることだ。例えば、iPhoneで読み終わったタイムラインは、その後起動したPC上のEchofonでは表示されないので、未読から読むことができる。今回の場合、タイムラインを読むつもりがないのに、起動するたびに読み込まれ既読扱いにされて、本当の自分の未読部分がずれてしまう。

Echofonはtwitterが提供する機能をすべて網羅している素晴らしいアプリケーションなのだけど、Mention/DMだけをやり取りするアプリには向いていない or 想定していない事がわかった。

なぜこういうことが起きるのか考えたところ、twitterを中心としたユースケースに問題がある気がして、簡単な図を作ってみた。

twitterにはタイムライン、Mention、DMと主な機能があるが、やり取りする相手はタイムラインの場合は全てのユーザとなり、逆にMention/DMは特定のユーザに対してコミュニケーションする。同じサービス上に対象者の規模が大きく異なる手段が混在している。コミュニケーションの形態として、対象が不特定多数の場合は言いっ放しになり、リアルタイム性は低くなる。だからタイムラインは暇な時に見る場合が多い。一方、対象が特定の一人の場合は会話形式になり、リアルタイム性が高くなる特徴がある。twitterの場合文字数制限があるので、チャットのように短めの文章で何回かやりとりしてコミュニケーションを進めるため、この特徴は強くなる。

全く特徴の異なるユースケースなので、この場合コミュニケーションを取る対象者で分けることができる。タイムラインとMention/DMは分離できる。むしろ分けないとEchofonのような不都合が生じた。

スマホアプリとpush通知機能のおかげでリアルタイム性の高いコミュニケーションが可能になった。だから、ユースケースとして異なる特徴を持つ機能は分けてアプリを提供する方がユーザビリティが高まると言える。これはPCとは異なる常時身につけるデバイスならではの特徴なのだろう。facebookがMessenger機能だけを持つiPhoneアプリをリリースしたのは、今までの話にそっており、理解しやすい出来事だ。

では、twitterではどうか？と考えると、有名なtwitterクライアントは数多くあれど、ほとんどがタイムラインとMention/DMを1つのアプリで取り扱う「全部のせ」に近い機能を持っている。

ということで、ないなら作るかというノリで、自分のプライベートカンパニーで、Mention/DMのやり取りだけに特化したtwitterクライアントアプリ「DM@chat」を作った。

スマホならではのユースケースを満たすために、あえて機能を削ってしまうというアプローチが成果を出せるか、という実験の意味もあって、ほとんど宣伝もしていないけれど、いろんな国から地味にじわじわダウンロードされていて、方向性としてはOKだったと思っている。今後、1:1コミュニケーションを行う上で便利な機能を充実させて行こうと思っているところ。良かったら使ってみてフィードバックください。

ということで、考察から始まって結局自分のアプリの宣伝で終わってしまった。。。

ツイートする

■[Book] 心を整える。 長谷部誠 11:09

イビチャ・オシムの本を読んでからサッカーの奥深さを感じられるようになり、プレミアリーグやセリAの試合を見ながら、「勝つために必要な要素ってなんだろう」と素人ながらに考えたりする。また、サッカー選手と仕事をする自分自身の振る舞いを重ねあわせて、共通項をつくろうとするようになった。最近では、高いレベルで仕事をするにはアスリートのような振る舞いが必要だと思っていて、かなりサッカーから学べることは深いと思っているところだった。

勝つための要素としてよく言われるのがメンタルという単語で確かに必要だとは思うが、じゃあメンタルをどのように身につけ発揮していくのか。というところまで話は行かない。精神主義は好きではないので根性論はナンセンスに思えていた。そこで「心を整える」という言葉、自分の中でしっくりした気がした。読者に聞けば自己啓発本のようだということで読んでみたいと思っていた。

この本は、長谷部誠選手が自分自身の経験を通じて守っている生活する上でのルール、ノウハウなどを解説している。

普段は知ることができない、監督や選手との会話、チームの練習風景、プライベートなど単純にへぇ〜と思う新たな発見がある。と同時に、選手もサッカーという職業を仕事にする人間であって、仕事へのスタンスや自己管理について共通項は多いと気づく。むしろ、体を使う仕事なので、お酒は基本的に飲まない、食事の栄養バランスを気にするなど、派手に勘違いされやすいサッカー選手の振る舞いは実は堅実で、自らを律する強い意志やルールの元、行われていることに気付いた。

普段、これはっと思う点にポストイットを貼っているが、貼った箇所のタイトルだけ載せておく。

• マイナス発言は自分を後退させる。
• お酒のチカラを利用しない。
• 組織の穴を埋める。
• 勇気を持って進言すべきときもある。
• 読書は自分の考えを進化させてくれる。
• 遅刻が努力を無駄にする。
• 正論を振りかざさない。

読み終わって思ったことは、メンタルはその時々の状況で変わっていってしまうものではなく、自分自身で常に意識的に整えようとするものだと思えた。不安定な情緒やパフォーマンスの幅がある人は、やはりプロフェッショナルとしての要素が不足しているということだろう。

やはりアスリートのような自己管理意識やパフォーマンス重視なスタンスが、今後自分が仕事をする上でさらに向上する際に助けてくれる要素になると思えた。

ツイートする

■[Life] 一日の過ごし方 2011年10月編 19:06

サラリーマンを辞め自分の会社を始めた時に、一日のスケジュールを見なおしたことをブログに書いた。

あれから2年が経過して自分の会社でも仕事をしてきた実績があり、去年3月からはfluxflexをスタートして環境は変わったので改めて見直してみようと思った。

今一日の過ごし方はこんな感じ。

6:00	起床、朝食、仕度
6:30	子どもに算数/理科を教える(最近なくした)
7:00	今日一日のTODOをリストアップして、順番を決める
7:30	work time1 (4.0h)
11:30	昼食、休憩 (1.0h)
12:30	work time2 (4.0h)
16:30	休憩 (1.0h) : 散歩 or 本読む or RSS読む
17:30	work time3 (1.5h)
19:00	残業 or 自由時間 (2.0h)
21:00	夕食、休憩、風呂 (1.5h)
22:30	private time (1.0h) : study or blog書く
23:30くらい	寝る

2009.02時点ではwork time が合計10.5h、work timeの間の休憩が2hくらい。今は work time 合計が9.5-11.5h、休憩は2hくらい。仕事できる時間はそんなに変わっていないし、これ以上多く設けることは難しいだろう。

最近は外出が多めだけど基本的にはこの枠に収まるようにスケジュールしている。夜の会食とか懇親会とかが入ると一気に夜のスケジュールが崩れて拘束時間も多くなるので、あまりたくさん入れないようにしている。完全プライベートで飲むことはほとんどなくなった。

土日は家族と一緒にリフレッシュするために完全に仕事から離れることにしている。PC全く触らない時もある。と言ってもどうしてもの時は土曜の午前中から夕方でやるときもある。

2008年のサラリーマン時代の時間の過ごし方を円グラフで示したブログを書いたが、同じように書いてみるとこんな感じ。

一番変わった点は基本自宅で仕事するので出勤時間がなくなり、仕事時間を増やせるようになった。ただ、今以上仕事時間を増やすと睡眠不足や集中しにくくなり次の日以降に悪影響が出るので、やはり仕事時間のMaxは12時間だと見ている。1日のタスク処理の量もこの時間で収まるよう、朝一のTODOリストアップ時に考慮している。

土日も含めた1週間でみると以下になった。

睡眠と仕事でかなりの割合を占めるのは前と変わらないところ。やっぱり家族で過ごす時間が少ないよなぁ。朝食を家族一緒に取ることを決めているが、短い時間だけど大事な事だということが分かる。

時間の使い方を客観視するのは、自分の環境変化に影響を受けていることが分かるし、マネージメントしやすくなるので、今後もふとした時にまとめてみたいと思う。

ツイートする

■[Dev] Titanium Developerで開発したiPhoneアプリをAppStoreに登録する方法 19:25

Titanium Developer はもう古くて TitaniumStudio だとは思うのだけど、一応メモしておいたので公開。

事前に以下のことが終わっていること

• 実機でのテストが終わっていること
• iOS Dev Center, iTunes Connectへのログインが出来ること
  • ￥10,800の支払いがが終わっていること

参考にしたページ: http://blog.livedoor.jp/tattyamm/archives/2957285.html

1. Distribution Certificate作成用CSRファイルの作成

1. 手元のMacのキーチェーンアクセスから作成する
2. Distribution用フォルダに保存する
3. ファイル名: CertificateSigningRequest.certSigningRequest

2. iOS Provisioning PortalにてDistribution用Certificateを作りダウンロード

1. ローカルに保存したCSRファイルをアップロードする
2. Distribution用フォルダに保存する
3. ファイル名: distribution_identity.cer
4. 同じページより、AppleWWDRCA.cerもダウンロードする
5. 2つのファイルをダブルクリックして実行し、キーチェーンアクセスに登録する

3. Distribution用Provisioningファイルを作成する

1. developmentと同じprofile nameは使えないので変える
   • どうやら大文字小文字区別は付けていないようだ
2. Distribution用ファルダに保存する
   • 参考 ファイル名: dmatchat_distribution.mobileprovision
3. ダウンロードしたファイルを実行し、Xcode上に登録する

4. Titaniumでパッケージを作る

ここからの参考: http://webtech-walker.com/archive/2011/02/22130853.html

1. Test & Package - Distributeより、Distribution用Provisioningファイルを指定する
2. Select Distribution Locationで適当なフォルダを指定する
3. Provisioningファイルを置いたDistribution用フォルダにした
4. Packageボタンを押す、エラーがなければXcodeのArchivesに表示される

5. iTunes Connect にてアプリ登録する

ここからの参考 http://blog.livedoor.jp/tattyamm/archives/1177705.html

1. iTunes Connectにログイン
2. Manage Your Applications - Add New App
3. Ready to Upload Binary を押して No を選ぶ
4. statusがWaiting For UploadになったらOK

6. XcodeのArchivesからSubmitする

1. 該当のアプリを選択して、Submitボタンを押す
2. iTunes Connectへのログイン情報を入れる
3. 証明書をdistributionを選択をする
4. しばらく待つと完了

7. iTunes Connect上のステータスを確認

1. Waiting For Review になっていればOK
2. 完了

ツイートする

■[Book] ダントツ経営 10:10

テレビでコマツが世界規模での販売やサーポートを展開しているグローバル企業として紹介されていて、そんなイメージが今までなく結構意外に思った。あるブログでこの本を紹介していて、コマツが世界的に展開する際の視点やノウハウをもっと知ってみたくなって買ってみた。

コマツ 現会長 板根氏が長いコマツの社歴の中で経験したことを交え、世界の中で勝負するために何を考えてきたかが分かる。

読んで気づいたことは、世界で展開するためには割り切りが必要で、日本標準もしくは常識と思われがちな基準を一度捨て、世界的な基準に変えていること。具体的に文章内では以下のような実践があった。

• 2010年春から新入社員の研修に中国語の授業を取り入れ
  • それまでは英語の研修だったが、今時の学生はTOEICでも高い点数をとれるので
• 子会社を1.5年で300社から110社減らす
• 他国と比較しての日本の強味と弱味を把握している
  • ものづくりにおける日本の力は突き抜けており、アメリカとは比べものにならない
  • 生産技術者を日本でじっくり育て、世界の工場に送り込むのが早道
• 社内システムを独自システムから汎用ソフトに一本化する
  • 仕事のやり方をシステムに合わせる
• これからはアジアの時代

これらの根幹となる意識の持ち方で、日本の現状を指摘している文章があった。

少子高齢化などさまざまな背景がありますが、私は「日本人の誰もが傍観者になってしまっている」ことが根本の理由に思われてなりません。

日本の現状にある程度の危機感は持っているものの、明確な処方箋が示されないので、何をどうすればいいかわからず、呆然と事態を見守っている、という感じでしょうか。

「グローバル企業」という何となくなイメージで進んでいるわけでは決してなく、世界を舞台に競合や市場を相手に実践し続けてきた成果と実績が確かにあり、この実践主義がコマツをグローバル企業にしていることがわかる。やはり実践しながら進めていくことでしか前進はありえない、ということをコマツは示してくれているのだと思う。

文章としては事実に基づいて意外とあっさり書かれている。もう少し深い考察や洞察、論理的な解説があると、読者が他の場所で試してみるような、普遍的動きが作りやすくなると思うけど。その点が唯一残念な点で、内容は実践的なのでとても参考になった。

ツイートする

■[Book] 「51歳の左遷」からすべては始まった 川淵三郎 17:13

Jリーグ発足時にチェアマンだった川淵三郎さんの本。サッカー協会にいる間というよりかは、サラリーマン時代より共通して重要だと思った事項をまとめた付属的なお話といえる。自分の中で日本サッカーの躍進と基本思想といえば、この人が象徴的な存在になっている。

タイトルに「左遷」とあるが、実際は子会社へ部長職での出向なわけで「左遷」というには大げさかと思う。さらにサブタイトルの「大逆転のリーダシップ論」とあるがリストラされて職を失ったわけでもないから、大逆転というのも釣りっぽい感じがする。

ただ、51歳という人生における「何らかの落ち着いた職に就くだろう年代」から日本サッカーリーグに入り、Jリーグを発足させ、トップのポジションに就いたことを考えると、新しいことをなす時には年齢は関係ない。ことを実践しているわけで、これは40歳以降のキャリアデザインができない自分にとっては大きな励みになった。

というのも、転職する、起業するなど手法がどうあれ、職種を変える、今いるフィールドを変えることはとても大きなリスクであって、確実に自己実現につながるキャリアアップになるか、経済的にも成り立つのかの問に対して、確実なことは何も言えない。

特に年齢が上がるほど、キャリアが上がっていることを想定すると、よりスケールの大きなことを望むはず。「スケールが大きい = 失敗のリスクが高い」だろうから、本当にチャレンジしていいものかどうか、それを現実的なプランにしていいのかどうか。まだよく考えられていない状況がある。

励みになったからといって、今からJリーグのチェアマンになるという目標はたてないと思うけど、なにか今と違ったフィールドを想定するのもいいなぁと思った。

書かれている内容は川淵さんが古河電工のサラリーマン時代に得た経験やノウハウで、チェアマン、キャプテンとして日本サッカー協会の中でも使ってきたものを紹介している。

大企業でたくさんの役割の人の中でのふるまい方というのは確かにあって、スタートアップの経験とはまた異なるノウハウは確かに存在すると思う。これはこれで貴重な経験、ノウハウだと思っている。

Jリーグの地域密着とか芝生の校庭の小学校をとか好きなのだけど、その思想がどこから来たかはこの本からはわからないが、サラリーマン時代のノウハウというのはスポーツ界でもいろんな場で生きるものだと思えた本。

この本が出版された年が2009年でこの時70歳で、キャプテンも辞められているが、実に20年以上も時が流れ、携わり続けたことが何とも素晴らしいキャリアだと思う。

ツイートする

■[Book] 日本人よ！ イビチャ・オシム 17:04

いきなりだが日本代表前監督イビチャ・オシムが好きだ。

今はもう日本代表監督は岡田監督をへてザッケローニ監督になり、日本の世界サッカーでのポジションもワールドカップ以降、急激に成長した。この躍進に直接関与しなかったこともあり、日本の中では過去の人になっているのかもしれない。

自分にサッカーの面白さ、奥深さ、世界視点でのサッカーを教えてくれたのはこのオシムだった。いくつかのオシムに関する本を読んできたが、この本も同じように色々なことを教えてくれる。

書かれた時代は日本代表監督就任後、1年ほど経過したとき、脳卒中で倒れる前になる。

この本は日本でジェフ市原(現、ジェフ千葉)の監督時代から日本に住み、日本サッカーの発展を牽引してきた、オシムなりの日本に対するメッセージが詰まっている。話好きなオシムのことだから本当はもっと多くのことを述べたかったのかもしれない、それを思うとボリュームを抑えたページ数は彼の思いが凝縮された一冊だと思う。

サッカーというものへの向かい方、捉え方、世界のサッカーのトレンド、世界の中の日本というポイントで彼なりの思想、伝えたいことを示している。

日本のサッカーに携わる人達、協会、マスコミ、サポーター、ファン、それほどでもないファンがもう一つ奥深くレベルを上げてサッカーというものに取り組むときに必要なエッセンスが散りばめられている。

あくまでオシムは自分の考え方の押し付けはせず、日本人に問いかけ考えさせる。答えはこちらにあり、それを見つけだせるように促してくれる。

Jリーグが発足して以降、日本においてサッカーは市民権を得て、日本代表はワールドカップ出場、アジアカップ優勝の実績をあげてきたわけだが、そこに対して我々は何かフィーバーのような感覚で接していなかったか、相手の実力や実績を知らずに根拠なく、勝ち続けることができるような気がしていなかったか。

より相手を知って、己を知って、サッカーを知って、世界を知って、より客観的に捉えるように戒めを与えてくれる。

オシムの指摘は的確だと思う。それは彼自身、日本の文化、歴史について学んだ上で述べているからであり、文章中でも日本の歴史的背景を踏まえている部分が見つけられる。

この本を読んでからサッカーの試合を見るとなにか印象が変わっていることに気づく。試合を冷静に考えつつ見ることができて、サッカーが起きることが何か荘厳な人生の教訓を教えてくれるようなものに感じられた。

サッカーをもう一つ深い視点で見たい人、サッカーともう少し深い付き合いにしたい人にこの本を薦めたい。

ツイートする

■[Book] オンラインゲームを支える技術 14:42

元コミュニティーエンジン社長のringoさんから「オンラインゲームを支える技術」を献本していただきました。ありがとうございます。

ringoさんとは2007年に meet-me の立ち上げの時に初めて出会って、独立した後の2009年に ShakeSoul としてバーチャルコミュニティーサービスの立ち上げプロジェクトで声をかけてもらって一緒に仕事させてもらった。帰り道に電車の中で色々言い合ったことがとても楽しい記憶に残っていて、今後も一緒にできたらと思っている人だ。

この本はオンラインゲームをつくり、運営/運用するための要素がまとめられている。

タイトルに「支える技術」とあるが、トータルとして必要な要素に触れているので、技術だけでなくオンラインゲームそのものの奥深さを実感できると思う。エンジニア以外のソーシャルアプリプロバイダーの経営的な立場にいる人にとってはMMORPGのような規模の大きいゲーム作りへの模索が可能になるかと思うし、逆にエンジニアにとっては技術を知るだけにとどまらず、技術がオンラインゲームを構成する上でどういう重要度や立ち位置なのかを知ることができると思う。

曖昧な解説にとどまらず、概念から具体化していくようなアプローチが取られており、筆者の10年以上オンラインゲームづくりに関わってきて血肉化された経験の結晶だと思う。

オンラインゲームのシステム構成やその技術手法はWebとは異なる歴史があり、ゲーム会社がそれぞれ独自に開発してきたことやゲームシステム自体に閉鎖性が必要なためブラックボックス化されてきた。各ゲーム会社の技術ノウハウが共有されることはなかった。やっとオンラインゲームの技術情報がオープンになりつつある。そのきっかけとしてこの本の役割は大きい。

この本を読めばオンラインゲームを作るための必要な要素が分る。本格的なMMORPGを作るための要素はにはWebサイトをつくるととは全く異なるため、Webの延長では簡単には参入できないことが実感できる。Webの参入障壁の低さに比べ、オンラインゲームをちゃんと作ることはとてもシビアな世界だと言える。すでにWebの技術要素が単純で効率化され整った環境が用意されているし、特に最近はRuby on Railsなどのフレームワークによってより効率的な環境を利用することがはやりの方向なので、なおさらかと思う。今後オンラインゲームも同じ方向に進むと思われるし、そんなサービスも作ってみたいが、まだまだ超えるべき技術的な壁が数多くある現状かと思う。

オンラインゲームの求める要件は高く、特に限りあるサーバスペック、ネットワークレイテンシーの中でどう収めるかがエンジニアの課題になることが具体的に書かれている。抽象化された部分からでは解決できない、低レイヤ部分への考慮から始まりそれを実現するためのの実装につながる。幅広い技術知識を有する必要性も感じる。エンジニアが実際設計や開発する際に役立ちそうな、作法を載せていたり具体的な数値を使ってサーバ台数や処理スピードなどを算出している部分は、現場で是非真似してほしいとても重要なノウハウだと思う。

さらに企画やデザインの様々な要件課題を技術的アプローチで解決する。すべては可能にならないので、企画とのすり合わせでベターな技術的手法を探る。技術ドリブンではなく「ひとつの世界観を創り上げるための手法としての技術」の位置づけは、Webとは異なる部分かと思う。

ページ数が多く、技術要素も多岐にわたり、やや冗長な印象もあるが階層的に丁寧に説明を進めるので、必要な時に読み返しつつじっくり付き合うような本かと思う。読み終わればオンラインゲームの基礎概要はしっかり理解できるはず。

実際作ってみようかと思っている人にとっては「これを読めば作れるようになる」とまではいかないが、それなりに規模感のあるオンラインゲームをつくるのに必要な体制(チームづくり、人員配置、エンジニアのスキルセット)や予算規模(システム規模、収益計画)がイメージできるのではと思う。

筆者が冒頭に述べているように、ゲームがiPhone、スマートフォン、facebookなど様々なプラットフォームで提供されるようになっているので、今後ゲームはもっとコンシューマに近いものとして利用され、その数も増えていって欲しいと思う。

個人的に興味があるのは、Webのオープン性とゲームの閉鎖性のバランス。Webとゲームの境目は今後ますます曖昧になっていくのだろう。今まではWebはオープンであろうとしてきた、今後はゲーム的要素が入ってくると面白いコンテンツになるかもしれない。ゲームのようなストーリーを持たせることやレベルなどの差別要素、制限要素などはオープン性と相反するから、どこかで折り合いを付ける必要がある。やはりWebはオープンであろうとし続けるのか、ゲーム性によって新しい方向を示しつつより豊かになっていくのか、今後利用されるアプリケーションのオープン性とゲーム性のバランスはどのくらいなのか。とても興味がある。

しかし、どこかで見たサーバプロセスの構成図、サーバや帯域の算出方法、懐かしい思い出に浸ってしまう。良い経験の思い出。

iPhone, facebookをプラットフォームとしたソーシャルゲームの広がりが進み、Webとゲームの境目が曖昧になってきている今この時に、オンラインゲームの技術的な解説がされているこの本が出ることの意味は大きい。

ツイートする

■[startup] スタートアップを始めるときの優先順位 14:55

2010年3月から最初のスタートアップをやってきているが、色々やってみないと分からないことが本当に多かった。このチャレンジで自分なりのノウハウをつけたいと思ってきたし、ある程度まとまってきたような気がするのでまとめてみる。

書いている内容は実際やってみて、今のところこの優先順位で進めることが一番失敗のリスクを抑えられる方法と思っている。起業の全ては可能性なので、基本どんな方法でも可能性はあるし、この方法が絶対だ！と言うつもりもない。今も模索している最中なので、是非経験された方々と意見交換がしてみたいと思っている。コメント、twitter、メールでもフィードバックをいただけたら嬉しいです。

ここで述べている前提としているスタートアップの定義は以下。

• 何がしかのインターネットにからむサービスを自ら開発し、運営しながら高い成長率を目指す
• 個人〜3名くらいの少数の創業者で始める
• サービスの成長過程では資金調達を行い、企業価値を結果的に5倍〜十数倍程度まで上げてエグジットを目指す
• デバイスなどハードウエア系は対象としてない
• 低い成長率を目指す中小企業もしくはプライベートカンパニーは対象としていない

自分なりの優先順位は以下。

1. サービスをつくる
2. 無料をローンチ
3. 会社を作る
4. 課金サービスをローンチ
5. エンジェルからの資金調達

1. とにかく最初にサービスを作るところまでやる

まずサービスありき。少なくともインターネット系のサービスであればデモできるレベルまでつくることが必要。何よりも先に優先し、ある程度形になるまでは次の動きを始めなくて良い。

動くものがなければ単なるアイデアであって、アイデアだけには価値はない。

実際にデモが出来る前にいくつかの日本のVCに話してみたが、具体的に話がすぐ進むということはなかった。その場としては日本のVCは興味がありそうな姿勢を見せてくれて、結構好感触かと思ってしまった。実は今すぐ投資することはなくて、ローンチしたら当たるかもしれないから、それまでキープしたいがための姿勢だったというのが後から分かった。やはり、アイデアだけを示しても、それにお金がつくことはないと思ったほうがいい。あとは、そもそも日本のVCはローンチ後ある程度会社が成長してきた段階の、シリーズB以降の資金提供を行うところがほとんどということもあった。もしうまく話を進めて、投資検討できたとしても会社のバリューはすごく低く見積もられるだろうから、創業者の割合が低い悪条件が前提になるだろう。

スタートアップをやろうとするときにまず会社をつくろうと発想しがちだが、それよりも本当にアイデアが実現できているかを示せていないと、後々苦しくなってくる。アイデアの実現可能性はスタートアップを行う上では問われるシーンはほとんどない。問われてしまっている時点で投資対象にはならない。ちゃんと動くことが用意できていることが投資検討の前提になっていると思う。投資する側から見ればイメージしやすい当然のことなのだけど、意外と気付けていない点だったと思う。

だから、資金調達をしてエンジニアを増やして最初のローンチを目指す。という流れはまず資金調達が難しい。その資金は少なくともVCからは出てこないと思ったほうがいい。その場合は、エンジニアを創業者としてタダで動いてもらうことが一番リスクを抑えられつつ、前に進める策かなと思う。

2. フィードバックをもとに改善

たくさんの人に使ってもらう or デモしながらフィードバックを集めるのがこのフェーズ。

最初のアイデアが最もユーザに適しているとは思わないほうがいい。客観的評価を得てサービスをよりよい方向に変化させていくことは必要なことで、そのための時間は優先して取るべきだと認識した方がいい。なるべく多くのターゲットとなりうる人たちからフィードバックを得て、変更を加えていく。無料サービスであればサービス内容を変更することへの抵抗は少ないはずなので、変更しやすい。

この時に初めてターゲッティングやマーケットを意識しだして、ビジネスプランを練っても遅くはない。1つのアイデアがユーザのフィードバックによって、ビジネスらしくしてくれる。むしろサービスを作る前からビジネスプランを固定化してしまうほうが、誰も使わないものを出してしまう可能性が高くて危険だ。

この時は無料でサービスを提供するので売上は上がらないから、個人名義でサービスを行っていても問題ない。ただ、サーバのホスティング費用は自腹になるので、やはりある程度の出費は覚悟しておいたほうがいい。

3&4. 会社を作るのはなるべく後

会社作りを急ぐ理由はないと思う。大事なのはサービスが多くのユーザに使われるかであって、会社が必要な状態は有料サービスを始める時で、売上を受け取るための受け皿としての役割でしかない。あとはここで示している順番通りにいかず、売上があがる前に資金調達を行う場合も、会社が株を発行する or 転換ノート(Convertible Notes)するために必要になる。

早く会社を作る必要がない理由として、売上があがる前 or ユーザが獲得できる前の会社であれば、バリュエーションはどこも同じで差別化できないという状況がある。だいたい$1Mくらいにしておくのが無難のようだ*1、*2。ローンチ直前に作っても、ローンチしない状態を半年続けてもバリュエーションは変わらないだろう。

もうひとつの理由としては、会社を作ると色々お金がかかってくる。専門家(弁護士、会計士など)への支払い。税金の支払。会計用アプリケーションの購入などなど。売上がないのにこれらの費用が発生し、しかも時間も取られるのは、自らの環境をより一層状況を厳しくさせる。

5. 資金調達は最後、必要な段階になったらがベスト

「スタートアップを始めるので、会社を作ってすぐ資金調達をする」と思ってしまうと、その後の状況が苦しく不幸な状態なる。サービスを続けていく上で、売上だけではまかなえなくて、これ以上は自腹も切れないとなったら最後の最後で資金調達をする、と思っていたほうがいい。あくまで、「必要となったから入れる。」のほうが創業者の利益確保の観点から良い。

もっとも最初からサービスをつくるために大きな開発費用が必要なデバイス系などハードウエア製品であれば、アイデアの段階で資金調達をする必要があるので話は違ってくる。

資金調達をするタイミングをなるべく遅くする理由は、サービスをローンチしている前提ならば、この耐えている時間で会社のバリュエーションが上がる or 上がる可能性があるから。「バリューが上がる => 有利な条件で資金調達が行える => 創業者の株式保有比率は高く保たれる => エグジット時の成功が大きくなる」という具合になる。

もうひとつの理由は、資金を入れる前にサービスの反応が得られているだろうから、このチャレンジを継続させる or 辞めるかの大きな判断ができる。もし辞める場合には今まで自腹を切った費用だけになるので損出を小さく抑えることができる。資金を入れてしまったら、損出がより大きくなってしまうことに加えて、投資してくれた方々への配慮が必要なので、辞めづらい状況になる。

以上まとめてみたが、この流れで行くと有料サービスを始めるまでは資金調達はしないので、自腹を切っている状態になる。実はスタートアップをするには資金調達をする前に出て行く費用は自分で何とかしなければいけない。結局、他人のお金をあてにする前に自分のお金を用意しなくてはチャレンジできないことだと思う。蓄え or 他の仕事をしながら or 親戚友人から借りる、手法はいろいろだが、どの程度のお金が必要かについては別エントリーにまとめる予定。

今のところこの優先順位で始めれば、リスクを抑えつつ大きな成功を目指すチャレンジが繰り返せるのではないかと思う。スタートアップは1回だけで終わりではないし、2回目、3回目と繰り返しながらでも成功を目指し続けることが重要だと思うので、なるべくリスクを抑えるための策を練っておいたほうがいいと思っている。

ツイートする