2012年6月27日水曜日

消えて無くなりそうなベンチャー会社と付き合う前に聞くたった一つのこと

このエントリーをはてなブックマークに追加
独自の技術を売りにきた新進気鋭のベンチャー会社とお付き合いするかどうか判断する際に必ず聞いている一言があります。
 「もし、あなたが死んだらこのシステムはどうすれば良いですか?」 
意地悪で聞いているわけでも、相手に死んで欲しいわけではもちろんないのです。むしろ良いベンチャーさんとは末永くお付き合いしたい。ではなぜこんな話になるのかというと、


本気の提案をさせるために

例えば基幹システムに組み込むような大きな話になった場合、もし相手の会社が消滅したことによってシステムの一部ないし全部がブラックボックス化され、誰も手をいれることができなくなった瞬間、こちらの事業が立ち行かなる可能性が出てきます。

この自体を鑑みて、先ほどの質問を言い直すと、
 「もし、あなたが死んだら我々の事業がストップしてしまう可能性があります。  そうなったら会社として大きな損失を被りますし、導入を推した私も責任を取る  ことになります。それほどのリスクを冒して導入する価値がこのソリューションにありますか?」 
となります。


さて、こちらのことを真剣に考えた提案をしてきてくれる会社はほとんどありません。試しに自分の会社のコーポレートサイトに掲載されているプレスリリースの内容についてそれとなく話しをふってみてみてください。半分以上の人は「初耳です」的な感じになります。


その瞬間、目の前に置かれた提案書や、プレゼン用のスライドをこの人はどうやって作ってきたんだろうという疑問がわきます。たぶん使いまわしているファイルのロゴや社名を変えただけでしょう。ひどい時はそのままだったりしますよねw 


それが悪いことだとは言いませんが、適当な提案しかしてこない会社の技術を取り入れるのはちょっと怖いですよね。その時点で切ってしまっても良いかもしれませんが、何か光るものがあってもう少し相手と話したい場合に、じゃぁうちの会社に導入するとしたらどうすればいいの?本当に効果があるの?という部分に話しをフォーカスする必要があるわけです。


こちらの状況を説明した上で、相手側から建設的な提案を引き出す際に、先に上げた質問が活きてくるというわけです。




そもそも、向こうがこちらの状況の一歩先を読んだ提案をしてきてくれる、そのような会社は今後伸びていくでしょうし、こちらも成長できるきっかけとなるかもしれません。もし出会うことができたら、ぜひお付き合いを検討すべきでしょう。




権利の所在をハッキリさせるために

どんな会社でも死が訪れます。
会社が潰れてしまうこともあれば、キーマンがいなくなり契約していたシステムが事実上メンテ不可能な状態になり死んでしまうことがあります。会社間で喧嘩別れすることも珍しくありません。 

そんなときに問題にあげられるのが権利問題です。
例えば
  • とあるサービスの開発を依頼していた会社と条件面で折り合いがつかず契約を切ったとします。 
  • しかしサービス自体はすでにリリースされているため、他の会社に開発を引き継がせようとしました。
ここで問題が発生します。  
  • 実行加工なファイルは納品されていたのですが、 開発に必要なソースコードが納品されていませんでした。

担当者であるあなたは慌てて先方に電話をしますが 
  • 「ソースコードは弊社独自のノウハウがあるので開示できないし、契約にも含まれていない」 と言われてしまいました。
  • 確かに契約書にはソースコードの納品について明示されておらずグレーな状況です。 

上記のケースだと相手がまだ存在していますので交渉次第で何とかできるかもしれませんが、もし会社が解散していたり、それこそ行方がつかめない状態になっていたとしたら、そのサービスを一から作り直すか、捨てるかの決断を迫られますもちろんその間もサービスに手をいれることは難しいでしょう。 


ここで前述の質問を言い直すとしたら、 
 「もし、あなたが死んでも我々はサービスを継続する必要があります。  その時でも私たちは問題なく継続することができますか?」 
 とでもなるのでしょうか。 


以前、まだ立ち上げたばかりのベンチャー企業の代表の方にこの質問をぶつけたところ、 
今の会社には私しか専任はいません、もし私が死んだらすべてのソースコードや仕様をまとめた資料を自由に使ってくださいとおっしゃったのがきっかけで、提携の話がするすると決まったことがあります。 もちろんその会社の技術が素晴らしかったから、というのが前提にありますが、 その方の覚悟を聞いて、背中を後押しされたというのは否定できません。




別れは必ずやってくる

もちろん、上記の質問をパーフェクトに回答したとしても、肝心なソリューションがダメダメではお話になりません。

このテクニックを活用するのは最後のひと押しが必要な時です。
技術は素晴らしいが、本当にこの人(この人達)と付き合っても良いものか悩んでいるときの手助けとして活かすものです。実際に導入が開始され、運用がはじまると、本当に気が遠くなるほどの時間、苦楽を共にしなければなりません

自分の中で決断を下すときは何度経験しても重たい作業です。
それは相手も同じはずです。その覚悟があるの?と相手にも重たい決断を迫りたい時、聞いてみてはどうでしょうか。

 「もし、あなたが死んだらこのシステムはどうすれば良いですか?」





社長失格―ぼくの会社がつぶれた理由
社長失格―ぼくの会社がつぶれた理由板倉 雄一郎

Amazonで詳しく見る by AZlink

2012年6月16日土曜日

JavaScriptの著作権侵害で弁護士さんに相談した時のはなし

このエントリーをはてなブックマークに追加
もう何年も前になりますが、
以前開発してたプログラムを同業他社がコピペして使っていたのをたまたま発見し、頭に来て弁護士さんに相談したときのお話しです。


あたしってほんとバカ

ある日、いつものようにお昼ごはんを食べながらニュースサイトを眺めていると、新しく競合他社がサービスを開始したというので早速チェック。

ふむふむ。中々よく出来てるなぁと感心しながら触っていたのですが、不思議なことに使えば使うほどデジャブに襲われたんですよ。どっかで見たことあるな、これ…と。

「……まさかな」と思いながらおもむろにブラウザの「ソースを表示」した瞬間我が目を疑いました。フレームワークも、もちろんそれを使ったコードもほぼそのまま。ご丁寧に変数名までバッチシ同じ。十中八九コピペされてると核心しました。思わずセブンのおでん吹くかと思いましたよ。危ない危ない。


悔しいじゃないですか。

表に見えるコードはJavaScript(以降JS)なので数十行~数百行程度の物です。
ただ、実際にはUI考えて、フレームワークの選定して、設計して、テストして、チューニングを繰り返して、という表には出ることのない苦労の末、文字通り寝る間を惜しんで世に出したコードなわけです。

このコードを書いた時の自分は、少なくとも日本には著作権という物もあるし、倫理的に競合サイトのコードをコピペして平気な顔する厚顔無恥な連中がはびこるほど、この国の民度は低くないだろうと高をくくっていたのですが、もうね、何て甘い考えだったんだろうと正直泣きそうになりました。今風に言うなら「あたしってほんとバカ」ですよ、ええもう。

それと同時に、こいつは悪だ、悪魔に違いない。
絶対に成敗してくれる、絶対にだ! と心に誓い、弁護士事務所の門を叩いたというわけです。


「これでは相手を訴えることができません」

お相手をしていただいた弁護士さんは若手なのですが、非常にやる気にあふれた方で、このためにJavaScriptの入門書を買って勉強したと聞いた時は正直ビビリました。大した金額もお支払いできないというのに、何かすんません(^^;

で、状況を説明し少なくとも相手に止めさせることはできますか?というお話をしたところ、次のような結論をいただきました。

  • プログラムを盗用されている可能性が高いということは分かった
  • しかし変数名などが同じ、というだけでは(盗用であっても)勝つことは難しい

マジすか…(;´Д`)
え、どうすればいいの?泣き寝入りするの?



「著作物であることを証明しましょう」

こちらの様子を察したのか、弁護士さんがおもむろに立ち上がり、プリントアウトした資料を持ってこられました。


弁護士 「これは過去にあった裁判の判例なんですが、同じようにプログラムを盗用されたというものなんです。この裁判では原告(盗用された側)が勝訴してるんですよ」

かつべ 「え、どうやったんですか?」

弁護士 「プログラムがどうこうという話ももちろんあったんですが、ポイントは"工夫"したところを列挙したんです

かつべ 「工夫、ですか」

弁護士 「ええ、細かいところなんですが、例えば数字が見やすいように独特のフォーマットにして表示したとかですね、ここのところです」


なるほどなるほど。
明らかに他のシステムにはない、または第三者が見ても工夫していると分かる「表現」がそのまま別のシステムにあれば著作権侵害であると主張できると。逆説的に言うと、例えば変数名が同じであってもそれが「表現」かどうか判断が難しく、それが認められることは非常に難しいようです。



自分のことが一番わからない?

光が見えたと思ったのですが新たな壁が登場します。
何を持って工夫したポイントと言うのか、その選定作業に予想以上に手間取りました。

具体的な作業としては、JSを勉強されているという弁護士さんと一緒に、各プログラムのステップを1つずつ私が解説しながらどこで勝負をかけるかお話を繰り返すという物。同じエンジニアに対して説明することはあってもほぼ一般の方にコードを説明するという場は中々ありません。お互いに意思の疎通を測るのに相当苦労しました。

しかしそれ以上に誰が見ても工夫したといえるポイントを探しだすのは、さらなる労力が必要でした。


さて、ここでひとつ疑問が沸くかもしれません。

「自分で作ったシステムならば、どこが工夫したポイントかすぐに分かるんじゃない?」


プログラムにおける表現抽出の難しさ

では実際のシステムのロジックの一部をを見てみましょう。
実際には色々絡み合ってるのでもっと複雑なんですが、端的に言うと次のようなものです

  1. 画面上に四角形A四角形Bがある。
    1. 四角形Aの「大きさ」「位置」は固定
    2. 四角形Bの「大きさ」はユーザの入力により変化する
    3. 四角形Bは「位置」はマウスで自由にドラッグが可能
        
  2. 決定ボタンが押下された際、次のチェックを行う
    1. 四角形Aの中に四角形Bが内包されてているか

四角形AがBを内包しているかチェックするロジックを考えてみます。
最もシンプルで誰もが思いつくのは、

  1. 四角形Aの各頂点を Aa, Ab, Ac, Ad とする。
    (左上から反時計回り)
     
  2. 四角形Bの各頂点を Ba, Bb, Bc, Bd とする。
    (左上から反時計回り)
     
  3. 四角形Aの Aa の x座標は Aa.x,  y座標はAa.y として取出すことができる。Bも同様。


とした場合、次のような処理になるでしょう。

if(   Aa.x <= Ba.x && Aa.y <= Ba.y
  && Ab.x <= Bb.x && Ab.y >= Bb.y
  && Ac.x >= Bc.x && Ac.y >= Bc.y
  && Ad.x >= Bd.x && Ad.y <= Bd.y  ){

      // true

}
else{
   // false
}

泥臭いですねw
あとは関数(メソッド)化するなり色々書き方はありますが、数学的なアプローチをかけない場合、突き詰めれば上記のようなロジックになるかと思います。

で、これだと著作物として主張できない。
厳密にいうと主張はできるが、それって誰もが思いつきますよね?仮にゼロから書いていたとしてもみんなここにたどり着きますよね?という質問に反論できなければならない

おいおい、それってどこだよ…。



一度世に出した物はパクられる覚悟を

その後悪戦苦闘の末に何とか書面にまとめ、相手方に弁護士名義で内容証明を送付。
示談へと話は進行するのですが、その頃にはすでに相手システムがリニューアルされているという事態になったりとまたややこしい感じになるのですが、これ以降はデリケートな部分も含みますので、お話はここまでとしておきます。


勉強になったのは、著作権で守られているのは「表現」の部分だということですね。

例えば「料理のレシピ」は著作権の保護になりにくいとされているそうです。なぜならレシピは表現ではなく、実現するための手段というか方法であって「表現」ではないからという論理のようです。感情的にはそんなバカなって思いもありますが、逆に権利で縛ってしまうと例えばカツ丼を食べるためには毎回遠く離れた特定地域に行かなければならないといった問題も発生するんだと思います。

これはプログラムも同様ですね。
誰かが int main(){} を著作物しとして主張したら、C言語使えなくなっちゃいます。難しいですね。


さて、話はつきませんが最後にこの出来事から得られた教訓をまとめて終わりにしたいと思います。

1. 一度世に出した物はパクられる覚悟を

仮にコピペされなかったとしても、お金と時間があればサービスを複製することはいくらでもできます。パクられることを防止する、もしくは報復することにこだわって貴重な自社のリソースを消費するくらいなら、別のことで勝つ方法を考えた方が有意義と言えるかもしれません。その瞬間はハラワタが煮えくり返っても、結果的にサービスで勝てばいいのです。


2. オープンソースとして公開する

どうせパクられるなら、自社のフレームワークやソフトウェアを公開してはどうでしょう?もし本当に価値のある物であれば、それが縁で優秀なエンジニアを獲得できるかもしれません。エンジニアがいれば、いくらでも素晴らしいサービスの開発に着手できます。実際、DeNAやGREEもサーバサイドのフレームワークを公開していますし、最近はTwitter社製のCSSのフレームワークが大人気です


3. コアな部分はサーバに持たせる

当たり前ではありますが、本当に公開しなくない物の場合はサーバサイドに置きましょう。オープンに出来るもの、出来ないものの仕分けは本当に重要です。DeNAもサーバサイドのフレームワークを公開してはいますが、例えばゲームロジックなどはもちろん公開していません。なぜならここがサービス(ビジネス)の根幹とも言える部分だからです。


以上です。
一番大切なのは開発者が、お互いがお互いに敬意を持ちあうことだと思いますが!


リンク

「JASRACが他人のJavaScriptを無断流用か!著作者のソースと酷似」
http://www.yukawanet.com/archives/4219844.html?1339778157

この記事を見たのがこのエントリーを書いたきっかけでしたw


「ゲームのセーブデータは誰の著作物?」
http://nekoblog.katsubemakito.net/2010/07/blog-post_10.html





デジタル時代の著作権 (ちくま新書)
デジタル時代の著作権 (ちくま新書)野口 祐子

Amazonで詳しく見る

2012年6月14日木曜日

グリー社内で「Mobageを支える技術」読書会が開催!?

このエントリーをはてなブックマークに追加
技術評論社から今月発売された「Mobageを支える技術」はもう購入されましたか?
その名の通りDeNAの中の人たちが執筆した書籍で、発売前からエンジニアの間では非常に話題になっていおりました。

そして、話題の本が出ると有志のエンジニアが集まり読書会が開かれるのは恒例行事となっております。お約束ですよね。


今回も早々と開催が決定していたのですが、注目すべきは主催者!そして会場!



ご覧いただけただろうか? (゜A゜;)ゴクリ


すでに定員オーバー!

ちなみに、この記事を書いている段階で定員の3倍近い人数が集まっているという状態です。
いやね、そりゃライバル企業のコメントを聞きながら読み進められるとあっては参加しないわけにはいかないですよね(笑)

自分も参加ボタンを押した時は、すでに補欠状態でして、会場が大きくなることを願ってやまない感じです。


ちなみに、ドリコムさんでも同様の読書会が開かれるそうですので、こちらも興味のある方は参加されると良いかと思います!


リンク

「Mobageを支える技術」読書会 ~ グリー株式会社
「Mobageを支える技術」読書会 ~ 株式会社ドリコム




Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)
Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)DeNA

Amazonで詳しく見る by AZlink

「【第4回】Facebookアプリ勉強会」のメモ

このエントリーをはてなブックマークに追加
我ながら勉強会まっしぐらな日々を送っていますw
今回は6月13日(水)にデジタルハリウッドの東京本校(御茶ノ水)で行われた、Facebookアプリ勉強会へ行ってきました。

__________2012-06-04_18.45.09__original 

【第4回】Facebookアプリ勉強会/node.jsとhtml5とfacebook apiを使ったipad,android対応のお絵描きアプリ/Herokuで作るfacebookアプリ/fbミスコン開発事例/Facebookページ向けアプリ「Hivelo Social Apps」のこれまでとこれから


日時 :2012/06/13 19:30 to 21:30
定員 :200 人
会場 :デジタルハリウッド東京本校 (東京都千代田区神田駿河台2-3 DH2001Bldg.)

時間発表者発表内容
19:30@kurimon_node.jsとhtml5とfacebook apiを使ったipad,android対応のお絵描きアプリ
19:50株式会社ソニックガーデン 最高技術責任者 松村 章弘様「Herokuで作るFacebookアプリ〜Facebook API実行方法と認証連携を学ぼう〜」
20:10@macrocrofbミスコン〜開発事例〜
20:30株式会社ハイベロシティ Account Manager 飯高 悠太様Facebookページ向けアプリ「Hivelo Social Apps」のこれまでとこれから

今をときめくnode.jsに、国内だとあまり事例を聞かないHerokuを使ってfbアプリ開発!
ラインナップを見ると燃えますよね!

…が、結論から言うと、あまり参考になる情報はなく…(;´Д`)
という苦い話で終わるのもアレですのでトピックスを2つほど。

socket.ioの実例

HTML5の実装の一つwebSocketを、node.jssocket.io を利用して実現したサンプルが公開されました。ほぼリアルタイムの通信を比較的簡単に実現できるとか!


ここではリアリタイムにお絵かきやチャットが実行できるサンプルでした。実際にiPhoneで操作した内容が、ほぼ即時に反映されるというもの。右側にあるのはサーバに渡された情報を表示したものです。

サーバにもよるのでしょうが、同時接続が20~30くらいが限界。
ただアメーバなどでスケールして利用している例もあることから、比較的大規模なシステムにも、作りによってはできるとのことでした。



facebookとHerokuの連携

facebookでアプリを新規で作成する際に、Herokuで作成するかという選択肢が用意されています。すでにfbとHerokuはこのレベルで提携しているんですね。
このあと言語などを選ぶだけ、数ステップでサンプルプログラムが自動的に作成されます。サンプルプログラムにはログイン処理や、フレンドの情報を取得するといった代表的な処理はすでに記述されているというナイスな仕事っぷりを見せてくれます。




なぜ主催者は何もしなかったのか

誤解なきように言いますと、登壇者の方々にはもっと詳しく話を聞きたい!と思わさせられました。しかしながら割り当てられた時間も少なく、誰に向けての発表なのかターゲットが不明確なため内容も終始初心者向きか、明後日の方向になりがち…といった残念な状態。(持ち時間中、自社サービスの宣伝しかしない人もいたわけで)

これは主催者側がもっとサポートしないと、再度参加したいとはてとても思わない勉強になってしまいますよっていうか、今回でなってしまったと思われます。


進行役がもっと突っ込んで質問をしながら話を聞くなり、登壇者に参加者はこういう人が多いからこういう発表内容でお願いしますと頼むなり、いくらでも勉強会のクオリティを上げる方法はあるはずです。

これでは誰も幸せになりません。
無料の勉強会だからといっても、参加者は貴重な時間を割いて集まっているわけです。特に最近のエンジニアは忙しい。その時間を棒に振らせたといっても過言ではないでしょう。この間に新機能の一つでも開発できたかもしれないというのに。

と、珍しく苛立ってしまった(;´∀`)
参加する勉強会は選ばないといけないですな…。




実践JS サーバサイド JavaScript 入門
実践JS サーバサイド JavaScript 入門井上 誠一郎

Amazonで詳しく見る by AZlink

2012年6月13日水曜日

「第1回 AppBank Network 主催勉強会」のメモ

このエントリーをはてなブックマークに追加
ミクシィを会場に行われた、AppBank主催の第1回勉強会へ行ってきました。
今回の目玉は何と言っても飛ぶ鳥を落とす勢いのiPhoneアプリ「バズル&ドラゴン」の開発者、山本さんのお話かと思っていたのですが、発表者の皆さんの話が非常に濃い!終始楽しませていただきました。

オフレコの内容が多かったため、ブログに書ける内容も限られてしまいますがご容赦を。



Appbanknetwork-480x91_original
日時 :
2012/06/08 19:00 to 21:30
定員 :
170 人
会場 :
ミクシィ本社 (東京都渋谷区東 1-2-20 住友不動産渋谷ファーストタワー 7F)
URL :
http://www.appbank.net/2012/04/26/iphone-news/402761.php
  • パズル&ドラゴンズ プロデューサー 山本大介氏
  • MF☆ラノベコミック 宮木良磨氏
  • BOOK☆WALKER 橋場一郎氏
  • 面白革命capsule+ 山中眞一郎氏
  • genesix 取締役 冨田憲二氏
  • 前座:AppBank宮下、脇





















パズル&ドラゴンズ プロデューサー 山本大介氏

山本さんはハドソン出身者。
ガンホーに移籍して作ったのがパズル&ドラゴン。

山本さん自信、ゲームを作ることを非常に愛して
いらっしゃるのを公演を聞いていてヒシヒシと感じました。

最後の方に話されていた、死ぬ寸前まで自分はゲームを
作り続けていたい、そのためにソーシャルゲーム業界が
今のままだと無くなってしまうのではという危機感に襲わ
れている、という発言は聞いていて胸が痛みました。



そんな山本さんが、今回はパズドラを開発する際に意識
していたことを10個の項目に分けて解説されていました。

  • はじめに
    • パズドラはソーシャルゲームではない。普通に楽しいゲームを作ったつもりです。
    • 今日は「犬と私の10の約束」 風に話します!
  • 企画段階でKPIなんて考えないでください。
  • プロトタイプでは面白さだけを見て
    • 2ヶ月間プロトタイプを作り続けた
    • 面白くなければ本開発に進めないのがガンホーのルール
  • 売り方だけは先に考えてください。
    • ゲーム内で何を売りたいか。どんなアイテムかをざっくりと考えておく
    • 逆にそれ以上は考えない
      • 細かいタイミングなどは後で考える。チューニング次点で検討。
      • 企画段階で細かく考えすぎるとゲーム開発に支障がでる。
        (ゲームそのものの面白さ、という意味で)
  • 遊んでくれないのには理由がある
    • プレイ前に離脱されるケースが多々ある。
      例えば
      • 名前の登録は重複可能に
        (重複ではじかれると面倒になって普通はやめる)
      • 個人情報は絶対に入力させない
        (プレイ前なので面白いかどうかわからない状態で求められれば、即辞める)
      • プレイ前にWebに飛ばさない
        (アプリからブラウザを立ち上げるのは重い。できる限り避ける)
  • 有料販売クオリティで開発して
    • 現場には「有料で売るから」と言ってしまった方がいい
      • 結果的に無料だったとしても
    • パズドラは170円想定。AppStore内では決して安くない金額設定。
  • ソーシャルゲームを否定しないでください
    • 最近社会悪だと言われているソーシャルゲーム、しかしゲームとしていいところも多い。
    • 自分自身で良い所を体験して取り入れて!
  • 一番遊ばせたいところはサーバで管理して
    • ダンジョン生成等のメインどころはサーバで管理をする。
    • アップルの審査関連で時間を取られるので、細かくチューニングを入れる部分はサーバにまかせる。
  • できることには限界がある
    • 過度なチュートリアルは毒
    • アプリ内に要素を盛り込みすぎると悪影響を及ぼす。ゲームはユーザに説明しすぎないですむシンプルな物にすること。
  • あなたには家族や友達がいます
    • 社内の意見取りに加え、
    • 開発スタッフのそれぞれの嫁にプレイ<嫁レビュー
  • お願いです、どうか私をパクらないでください
    • 結果的にユーザー離れを引き起こす。
    • 自分自身も死ぬまでゲームを作り続けたい。それができなくなるかもしれない。

ここまでで公演は一段落。
以下は質疑応答になります。

  • 開発計画について
    • アップデート計画を1ヶ月先までひかない。
    • 自分たちがやりたいことは半分くらいに抑えて、ユーザーの定性的な要望を取り入れていく
  • ガンホーについて
    • テクニカルな部分もだが、この会社は運営がすごかった。
      いかにユーザーを喜ばせるかを常に考えて行動している。
    • これまでオンラインで食べている会社として行動指針がすごい。
  • 海外向けについて
    • 結論から言うとやってみないとわからない
    • あまり深く考えてない。とりあえず出してみないとわからない。
      ハドソン時代に「エレメンタルモンスター」を作っておりそこそこ海外受けも良かった。ダメだったらまた自分の得意な分野でまたチャレンジしたい。
  • 開発の規模
    • 社内のエンジニア2~3人。クライアント1人、デザイナー1人、プランナー、サーバエンジニア数名。
    • 大体10名程度。開発期間7ヶ月。
    • 今後は海外版、コンシューマー展開などをスタジオでやりたい。
  • その他
    • チームは10人未満でやった方が楽しい。
    • スタッフと楽しさの共感ができることが重要。

MF☆ラノベコミック 宮木良磨氏

「ラノベ」をご存知だろうか?
10~20年ほど前はいわゆるオタク層のものだった。それが最近の中高生の間ではジャンプなどに掲載されているマンガと同じ感覚で貸し借りなど行われている。

この「ラノベ」の感覚が分からない30代以上のクリエイターは、自分よりも下の感性が分からなくなってしまう危機が迫っている。自分と同じかそれよりも高い年齢層向けのコンテンツしか作成できなくなるのでは?

という、誠に恐ろしい内容でした(;´∀`)

  • 概要
    • 市場として出版、マンガは縮小しているが、ラノベは拡大している
    • ラノベはiPhoneで読みやすい
      • 余白の多さ
      • 次のページをめくる直前に単語(文章)を載せる
        以前流行したケータイ小説と同じ文脈
  • ラノベ原作のアプリ化について
    • 自分たちで小説を作っているので(中高生に人気の物がわかる)、売れているものをすぐに他のメディアに移植できる。
    • ラノベを買うと、音声がでるアプリがもらえるなどの施策を行なっているが、アニメも自分たちで作っているので、声等の素材を使いやすい。
  • その他
    • 実は、紙は若い人が多く、アプリは"卒業"した人が戻ってきている。

そのほか具体的なユーザー属性や、売上についてのあれやこれや非常に重要なデータが公開され、写真をパシャパシャ撮っていたのですが、もちろんオフレコとのことで、残念ながら書けるのはここまでとなります(^^;




BOOK☆WALKER 橋場一郎氏






http://bookwalker.jp/pc/


「ほぼすべてオフレコで!」とのことだったので、全く書けません(^^;
概要だけですが、

  • 角川グループのラノベのシェアが圧倒的
  • 継続率の話し
  • 今後の方向性や戦略
  • まだ表に出ていない提携などのお話

角川の上層部の方の資料が飛び出したりといった、聞いてる方が「この人の首飛ばないのかな」とハラハラしていましたw


その後、ライトノベルにも明るいアスキーの部長さんが登壇され、メディアファクトリーの宮木さん、角川コンテンツゲートの船場さんと三者で対談をされました。
こちらも概要だけですが、

  • 30代以上のラノベの認識と、今の世代の認識が違う
  • 若い世代は「マンガの方が難しい」
  • コンテンツは短い物にどんどんと集約されている。
    • 極論でいうと4コママンガしか生き残らないのではないか?
    • Twitterの140文字は、ラノベと親和性が高い
  • ニコニコの動画に「小説が読みたい」というコメントがついたことからノベライズされた「カゲロウデイズ」
    • ニコ動は二次創作の発表場所のような形だったが、今後はオリジナルの発表場所としても活用されそう。
    • ニコ動発でアニメ化など
など、短時間でしたがずっと聞いていたい濃い内容でした。






面白革命 capsule+


http://capsuleplus.net/

すさまじい勢いで会社を立ちあげられ、3ヵ月で22本ものiPhoneアプリをリリースされたおもしろ革命さん。以前の会社を辞めてから新聞の営業もこなすという過去も衝撃でした。実のお母さんが来場されていたのには理由があった?


  • 自己紹介
    • 2012年3月からiPhoneアプリ開発
      • 2008年12月「なんでやねん」を趣味でリリース。エンタメ無料1位。
        (自分も入れてました(^^; あの開発者さんだったとはw)
      • 3ヶ月で22本リリース
      • 3ヶ月で700万DL
    • エンジニア、デザイナーの2人でやってる
    • コナミ出身
      • ポップンミュージック(16)のメインプログラマー
  • 本日のテーマ「アドネットワークは儲かるのか?」
    • 生きていくぐらいのお金は稼げている
    • クリック単価を上げるのには?
      • 単価は2~10円。
      • CVRで単価が決まる
         ※アプリのユーザー数(DL数)などではなく、純粋な効果で決定される。
      • ドラクエやFFのような広いターゲットに遊んでもらえるようなアプリを作れればベストだが、そういった物は簡単にはできない。
      • 次のような施策をとっている。
        • タッチ、スワイプの頻度が多いところにバナーを置かない。
        • とあるアプリで実施したところ、実際に単価が5倍以上になった。
          ※ 画面下部によくタッチされるボタンがあったため、上部に移動。
  • ゲーム作りに対する想い
    • ゲーム作りは、「自分の中の面白いを人に伝えること」
    • 告白と同じ。(自分の中のエゴを出さない。何度ふられてもがんばる!

    • もともとiPhoneアプリを作ろうとした時、目標の一つは実の母でも楽しんでプレイしてもらえるようになることだった。
    • 会場にいたお母さんにインタビューしたところ、その目標はかなっているというお言葉が。湧き上がる会場。ちょっとした感動シーンでした。
  • その他
    • アニメーションなど増えたため、やはりデザイナーの負担が大きい。


genesix 取締役 冨田憲二氏







ブログを読んでいただいた方が良いかもしれませんw
非常にまじめな会社さんだという前フリの通り、久しぶりに要件定義バッチシなウォーターフォール型の堅い会社さんだなぁという印象(もちろんいい意味で(^^:)。



AppBankNetwok プラス 

※中の人からのお知らせ
  • 約500デベロッパーが利用。
  • 登録アプリのDLが増える
    • AppBankの「今日の新着・無料アプリ」に掲載
    • AppBank for iPhone の 「無料アプリ」に3日間程度表示。「最も使われている無料アプリランキング」にも掲載します。
  • DL数が数百~数千程度アップすることもあるよ!



以上です。

久しぶりに、非常に充実した勉強会でした!
次回の開催が非常に楽しみです^^




女の子のためのアプリ生活 ウーマンズ・アプス・ライフ (P-Vine Books)
女の子のためのアプリ生活 ウーマンズ・アプス・ライフ (P-Vine Books)黒田智之,石橋ふみ,小濱なつき,AppBank

Amazonで詳しく見る

2012年6月8日金曜日

「gloops流 ソーシャルゲームのチューニング勉強会」のメモ

このエントリーをはてなブックマークに追加
今回は品川にある、日本マイクロソフトの本社のセミナールームで行われた「gloops流 ソーシャルゲームのチューニング勉強会」へ行って来ました。その時のメモです。何かブログが勉強会のスクラップブックみたいになりつつありますが、気にしない(;´∀`)
※あんまり数字とかは公開しないで>< っぽい雰囲気だったのでサマリーみたいな感じです。

内容としては、高度な内容はあまりなくどちらかというと入門者向けの優しい感じの話でした。次の機会があればもう少し高度な分析や企画などの話を聞いてみたいです。



【第17回GSGL】ソーシャルゲームのチューニング勉強会 / gloops社ソーシャルゲームのキモはリリース後の運用にあり!ユーザーを見ながら一日複数回のチューニングを行うgloopsの戦略とは?ソーシャルゲーム運用勉強会
http://atnd.org/events/28042
日時
2012/06/07 19:30 to 21:00
定員
150 人
会場
品川マイクロソフト (東京都港区港南 2-16-3 品川グランドセントラルタワー)


ゲームデザインとは?

  • ゲームデザイン = システムデザイン(ルール) + バランスデザイン
  • 「バランスチューニング」とは、以下をゲームデザイナの理想に近づけるために、ゲーム内の数値を調整する作業と定義する。
    1. ゲームの難易度
    2. ユーザーの満足度

  • 具体的には「Lvの上がりやすさ」「必要消費ポイント」「必殺技の強さ」などゲーム中のあらゆる数値

リリース前に行うチューニングで大切なこと

理想を持つこと
最終的な理想系が頭にないとそもそもチューニングできない
事前のシミュレーション大切
ユーザが理想通りにプレイできているか、事前にKPIを算出できる。イベント開始後などにKPI通りに推移しているか確認。また事前にシミューレションすることで、突発的な自体を最小限に抑えることができ、結果として開発チームの工数を削減できる

リリース後のリアルタイムチューニング

なぜ必要?
ソーシャルゲームは基本無料なのでユーザーが離脱しやすい。その傾向を素早く察知し、継続率や課金率を上げる。(一概には言えないがコンシューマーは数千円払っているので離脱しにくいのではないか?)また開発段階ではユーザーの遊び方、行動パターンすべてを想定できない。そのためリリース後にチューニングすることが必須と言える。

シミュレーション例

必要任務P (イベントクリアに必要な任務P)
= 必要クリア回数 × 消費任務P × エリア数 × ステージ数

総獲得Ex(経験値)
= 必要クリア回数 × 獲得Ex × エリア数 × ステージ数

クリア後のLv: y
= ユーザLv:xから総獲得Exを獲得した際のユーザLv

指標任務P
※Lv:xのMAX任務Pをa, Lv:yのMAX任務Pをbとすると、
= a + ( y - x ) × 補正値(1/2)

MAX回復時間(分)
= 指標任務P × 回復時間(3分)

MAX消費回数
= 必要任務P / 指標任務P

無課金クリアにかかる時間 (時間)
= MAX回復時間(分) × MAX消費回数 / 60

無課金クリアにかかる日数(日)
= 無課金クリアにかかる時間(時間) / 1日のプレイ可能時間

1人あたりの最大課金額
= MAX消費回数 × 任意チャージ費(100コイン)

最大総売上
Σ(レベル毎のAU × 課金率 × 1人当たりの最大課金額)

シミュレーション実行例のポイント

難易度はどうやって決まる?
先の例だと、「必要任務P」「開催時のLv毎のユーザー分布」のバランス、「無課金クリアにかかる日数」「イベント日数」などで決まる。
その他
ユーザの生活リズムを考えながら変数を埋めて、式を作る。
例)6時間は寝るだろうから、残りの時間のうち…みたいな

リリース前に準備すること

やりこみ要素の検討
イベントなどが簡単すぎた場合を考慮。こういった追加が簡単に行えるようにシステムが作りこんであるかがポイント。途中で難易度を上げるとユーザーからクレームが入るので、原則的にイベント中の変更はやめた方が良い。



チューニング例(ケーススタディ)

DAUに対してイベント参加人数が少ない
→導線が少ない(導線を増やす)
→面白そうと感じてない(刺さる文言に変更。例えば限定の武器がどれくらいすごいか伝わっていないなどが考えられる)
ルールがうまく伝わってない
→わかりやすい説明を増やす
→ヘルプの導線を増やす
予定より進捗がよくない
→時間限定でユーザに優しくする
※時間限定にすることでバランスを大幅に崩すことを防ぐ
 
もっと遊びたい
→例えばチームバトルの回数を増やし、1回の開催時間を短くする

質疑応答にて

管理画面の作りこみが話題になっていました。
あらゆる角度からリアルタイムで数値を出しグラフ化するといったマーケティング系の機能から、明言されていませんでしたがCMSのような機能もあるっぽい。実際2010年から積み上げてきたシステムで、ゼロベースで組み上げると大変な工数がかかるとのこと。ゲームごとに管理画面は用意されているそうですが、ベースのシステムはほぼ同じ物を流用しており、全体が把握できるような仕組みも別にあるという、そこをもっと話してくれという感じでしたねw

またKPIの数値は流動的に変更していますか?という質問には、ユーザー間のせめぎ合いが常に熱く起こっている状態がゲームとして理想的と言えるため、そのために見直しは随時行なっているという回答でした。