啓史さん夜行バス+ネットカフェで1週間滞在という常人ではとてもまねできない荒業が大変インパクトのある発表でした。工夫次第でこんなに安価で東京の往復・滞在ができるのだという人間の無限の可能性!?を感じました。結論「行けば何とかなるよ!」とのこと。今回フリューからは私と同僚の谷口の2名がスピーカーとして発表しました。前半はペアプログラミングについて導入から8年になる自社での導入の歴史と近況についてとその効果について私が話をさせていただきました。後半はペアプログラミング導入政治編として政治的問題を交えながら同僚の谷口が話しました。導入・政治編への質問が多く寄せられたのでペアプロ自体の効果などは情報で知っているが職場にどうやって導入するのか悩まれている方が多いのだと感じました。さん最近のJavaにまつわるニュースについてお話されていました。ここまで今回の関ジャバは若干(かなり)Javaの成分は薄めでしたが、このセッションが過去参加した関ジャバの中でも1番じゃないかというぐらいに開発プロセスの話題を中心に盛り上がりました。これだけ開発プロセスで盛り上がるというのは普段、「なぜこんなやり方なんだろうか」とか「もっとよりよく開発をしたい」という思いを強く感じているからでしょうね。フリューの中でも開発プロセスについて今の状態がとてもベストとは思わないし、これからもより良く変えていく必要があります。実はいつの間にか自分自身が老害になってしまうそんな恐怖心と戦っているのかもしれません。社外のエンジニアと話すことで自社の様子が俯瞰して見えたり、自分自身を見つめ直したりといった刺激をもらえるのが社外勉強会の魅力でもあります。さいごに東京では毎週や毎日のように勉強会が開催されていますが、大阪でも毎週に近いくらいに盛んに開催されています。みなさんもこういった刺激を受けることができる社外勉強会にぜひ参加してみませんか!フリューモバイル事業部では毎週社内勉強会を開催しています。開催回数もなんと270回を超えています。機会があればぜひまたこの話についてもお話したいと思います。Servicesクラウドみなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。Javaを用いてSimpleDBを操作するプログラムについて解説しました。1ヶ月導入記』と省略表記にしています。今回はSimpleJPAを使って、プログラムからSimpleDBへの接続を行うを方法を解説したいとおもいます。API(JPA)実装です。mapping)フレームワークです。SimpleDBのドメインから取得したアイテム情報をJavaオブジェクトに変換して操作することができます。Persistence特徴SimpleJPAには以下のような特徴があります。依存するライブラリSimpleJPAは以下のライブラリに依存しています。Javaを利用しています。SimpleJPAの制限SimpleJPAはAWSのサンプルプログラムでも利用されるフレームワークですので、非常に便利なのですが、その便利さの反面制限もあります。私が利用して気づいた制限は以下のとおりです。Javaで実装することをおすすめします。ドキュメントが少なく、日本語の資料はほとんど無いというデメリットも挙げられます。ちなみに弊社プロジェクトではSimpleJPAの利用も検討しましたが、上記のような制限が多く、自由度が低かったという点で利用は見送りました。サンプルプログラム前回と同じく、東京リージョンで以下のようなドメインを作り、データを投入し、情報を取得するといったサンプルプログラムです。factory.createEntityManager();クライアントはデフォルトのままではus-eastリージョンに接続するようになっているので、東京リージョンに設定するようにリージョンの設定を行います。SimpleJPAではEntityManagerを使って、データの操作を行います。リージョン情報などの情報を設定したMapを使ってEntityManagerのFactoryを生成し、FactoryからEntityManagerを生成します。EntityManagerFactoryImpl生成時に渡している”TEST”という文字列は、ドメイン名の接頭辞に使われます。Javaを利用しているため、アカウント情報はAWSCredentials.propertiesから読み込みます。Credentials.propertiesファイルの内容は以下のようになっています。Credentials.propertiesファイルをパス上に生成しておくことで、アカウント情報を自動的に設定してくれます。Javaではデータの投入前にドメインの作成を行なっていましたが、SimpleJPAではデータの投入時にドメインが存在しない場合は、自動的にドメインを生成します。Factory生成時に”TEST”という接頭辞を渡しているため、データ投入実行時に『TEST-Employee』というドメインが生成されます。ちなみにこの接頭辞は省略することはできません。空文字を渡した場合『-Employee』というドメイン名になってしまいます。データの投入はEmployeeドメインを表すJavaオブジェクトを生成、値の設定を行い、EntityManagerのpersistメソッドに渡すだけです。ドメインを表すクラスには@Entityアノテーションを付ける必要があります。ドメインを表すクラスには必ず@Idアノテーションが付いたフィールドが必要です。@Idアノテーションが付いた項目の値がそのままアイテム名となります。サンプルプログラムでは@Idがついたidフィールドの値がアイテム名となります。(上の例では『Emp1』がアイテム名となります。APIに相当するのがEntityManagerのfindメソッドを利用します。findメソッドにはドメインを表すクラスとアイテム名を引数で渡して、該当するドメインのアイテムを取得します。APIを呼び出すためにはJPAQueryを利用します。APIに渡すのと同等のクエリを渡します。『:unit』となっているのはプレースホルダーで、QueryのsetParameterで渡した値に置き換えてくれます。SimpleDB上ではドメイン名は『TEST-Employee』となっていますが、createQueryメソッドに渡すクエリ内では『Employee』で問題ありません。内部でSimpleJPAが『TEST-Employee』に変換してくれます。}1234}finally{entityManager.close();factory.close();}SimpleJPAではEntityManagerFactoryとEntityManagerは必ずcloseメソッドを呼び出す必要があります。上記のサンプルプログラムを実行した結果は以下のとおりになります。age:26]数値型の扱いサンプルプログラムではageフィールドが数値型となっています。フィールドの値』を文字列にした値が保存されています。上記Emp1の場合は『09223372036854775839』(9223372036854775808+31)となっています。SimpleDBの制限を回避する』で紹介した基準値を決めて数値型を扱う方法で、『9223372036854775808』を基準値としています。これにより64ビットの符号付き整数を扱うことができます。9223372036854775807となっているからだと思われます。SimpleDBからデータを取得したときにはSimpleJPAが内部で通常の数値型に変換してくれます。数値型のデータを実際に見ると24桁の数値なうえ、計算しないと元の値がわからないので、データを把握しづらいので注意が必要です。まとめ今回はSimpleJPAを用いてSimpleDBを操作するプログラムを解説しました。SimpleJPAでのSimpleDBプログラミングではEntityManagerからドメインを表すオブジェクトを通じてドメインの操作を行うドメインは存在しない場合は自動的にドメインが生成されるドメイン名には接頭辞が付く@Idがついているフィールドの値がアイテム名となる数値型はSimpleDBでは『9223372036854775808』を基準値とした文字列として扱われる。いうことを確認しました。SimpleJPAをつかえばSimpleDBから簡単にJavaオブジェクトへのマッピングを行うことができます。制限も強く自由度が低くなってしまうので、利用を検討する際には、制限やデメリットを確認して、要件にマッチするかを確認することが必要です。次回以降はSimpleDBから離れ、AWSでのデータバックアップなどについてお話ししたいと思います。Servicesクラウドみなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。実はプロジェクト自体は終了しているのですが、気にせずそのまま行きます。前回はSimpleDBの制限の回避方法についてお話しました。Javaを使って、プログラムからSimpleDBへの接続を行うを方法を解説したいとおもいます。Javaとは、AWSが提供しているJavaのプログラムからAWSのAPIを簡単に呼び出すためのライブラリです。アカウントに関する設定を少し行うだけで本当に簡単にAPIを呼び出すことができます。Javaを利用していますが、その他の言語向けにも以下のようなSDKが提供されています。Javaから利用可能なAWSのサービスは以下のとおりです。Balancing上のサービスに先日追加されたばかりのElastiCacheが含まれていることからも分かることなのですが、AWSが提供しているライブラリなので、AWSに新しいサービスが提供されたり、既存のサービスに新しい機能が提供されたりして、APIに変更が加わった際には、リリースとほぼ同時にSDKもバージョンアップが行われているのも大きな特徴です。Javaを利用条件は以下のとおりです。Logging)が利用できること利用するAWSサービスのサインアップが完了していること※上記は2011年9月15日現在の情報です。最新情報はAWSのホームページを参照してください。Javaサンプルプログラム今回は東京リージョンで以下のようなドメインを作り、データを投入し、情報を取得するといったサンプルプログラムです。SDKではAmazonSimpleDBインターフェースを実装するクライアントを生成し、クライアントのメソッドを通じてAPIの操作を行います。クライアントの生成時にアカウントの情報を設定します。Keyの情報を読み込みます。Credentials.propertiesファイルの内容は以下のようになっています。ID}また、クライアントはデフォルトのままではus-eastリージョンに接続するようになっているので、東京リージョンに設定するようにリージョンの設定を行います。Javaではクライアントに準備されているメソッドに対し、各メソッドに応じたRequestを渡します。Requestにはドメイン情報やアイテム情報など操作対象の情報を設定します。ドメインの作成ではCreateDomainRequestにドメイン名を設定し、createDomainメソッドに渡して実行しています。APIの二種類があります。投入するアイテムはReplaceableItemとしてアイテム名を指定して生成し、属性はReplaceableAttributeとして生成したReplaceableItemに設定します。同じ属性に複数の値を設定する場合は、同じ属性名のReplaceableAttributeを複数設定します。(下記Emp1のunitの例を確認してください)BatchPutAttributesAPIの場合は生成したReplaceableItemをListにしてリクエストに渡し、batchPutAttributesメソッドに渡して実行します。APIはドメイン名とアイテム名を指定して属性情報を取得します。実行結果はAPIに応じた形のGetAttributesResultで返されます。GetAttributesResultには該当アイテムの属性情報であるAttributeのリストが設定されています。APIはSelectのSQLに対応した表現を用いてデータを取得します。下記の例ではSQLそのままになっています。指定できるSQLには制限はありますが、ほぼSQLそのままで実行することが可能です。実行結果はAPIに応じた形のSelectResultで返されます。以下のようになります。Javaを用いてSimpleDBを操作するプログラムを解説しました。JavaでのSimpleDBプログラミングではAmazonSimpleDBを実装するクライアントを生成するクライアントにアカウント情報・リージョン情報を設定するクライアントに準備されているAPIのメソッドを実行する。各メソッドに沿ったRequest,Resultが準備されているということを確認しました。Javaを利用すれば簡単にSimpleDBを操作することが出来ることを確認していただけたと思います。Javaには準備されています。次回はSimpleDBのデータとJavaオブジェクトのマッピングを行うことのできるO/Rマッパーである『SimpleJPA』について、サンプルプログラムを交えて解説したいと思います。Servicesクラウドみなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。現在、あるソーシャルプラットフォーム上のアプリケーションを構築するプロジェクトでの、クラウド環境の導入の進行状況をそのまま記事にしています。前回はSimpleDBの詳細な特徴と制限についてお話しました。整合性の制限その他の制限の4つをあげました。基本的にサイズ・容量の制限を超えそうな大容量のデータを扱うのであればRDSを選択する方がよいかもしれませんが、それでもSimpleDBを使う必要があるのであれば、以下のような方法で制限回避方法を検討するのがよいかもしれません。1アイテムあたりの属性数の制限の回避SimpleDBではJoinができないという制限もあり、冗長なデータ構造をとることが多くなり、属性数が通常のRDBより多くなることが予想されます。1アイテムあたりの属性ペアの数が256個までという制限もあるので、無制限に属性を追加することができません。このような制限を回避するために以下のような方法が考えられます。動的に属性・属性値が増えるような設計をしないSimpleDBはスキーマレスなデータベースなので、アプリケーションから新たに属性を追加することが可能です。アプリケーションから動的に属性を追加することができるようになっている場合、この属性値のサイズ制限を超えてしまうことになりかねません。属性は複数の値を持つことができますが、この属性値が動的に増えることによっても同じ制限に引っかかってしまうことになります。動的に属性・属性値が追加されるような構成の場合は、事前にアイテムの属性数を確認し、アプリケーション側から属性・属性値の追加を制限する必要があります。属性数が256個を超えそうなことが予測される場合は、ドメインを複数に分割し、保存先を複数にすることで、1ドメインあたりの属性数を削減することができます。属性値サイズの制限SimpleDBには属性名・属性値・アイテム名のサイズの上限は1,024バイトまでという制限があります。日本語の文字列にして500文字ちょっとですので、ちょっと長いテキストデータを保存したい場合には、以下のような方法で制限を回避する必要があります。複数の属性を利用する保存するデータのサイズに応じて属性を予め複数用意しておく、または動的に変更できるようにしておくことで上記の制限を回避することができます。最大2,000文字のテキストを保存する場合、属性名にdescription-1,descrption-2,description-3,description-4の様にサフィックスをつけて属性を作成し、データを分割してサフィックスの値の小さな順に保存していくことで、大きなサイズのテキストデータも保存することができます。上述の属性値数の上限に注意しておかないと制限に引っかかってしまうことが考えられます。S3を利用する保存したいデータがあまりに大容量の場合は、属性値を複数にする対応にも限界があります。このような場合は、データそのものをテキストファイルとしてS3上に保存し、属性にはS3の保存先情報を保存しておくという方法が考えられます。この方法を使えばバイナリデータも扱うことができ、保存するデータサイズにほぼ上限がなくなりますが、データが一意になるような保存先の情報管理をアプリケーション側で行う必要があります。1ドメインあたりの容量および属性数の制限の回避SimpleDBにはドメインあたりのサイズが10GBまで、ドメインあたりの属性数が10億個までという制限があります。履歴データのような増え続けるデータの場合は、運用を続けている内にデータが増え、この制限に引っかかってしまうことが想定されます。このような事態が予想される場合、以下のような方法で制限を回避することが考えられます。シャーディングデータの水平分散手法であるシャーディングを行い、ドメインを複数に分割し、1ドメインあたりのサイズ・属性数を減らすことで制限を回避します。シャーディングではIDや日付といった特定の属性の値によって保存先を変更します。IDが数値として管理されているような場合、IDの値が奇数の場合はドメイン1に、偶数の場合はドメイン2に保存するといったような方法で、データの保存先を分散させます。この方法ではアプリケーション側でデータ操作の際に、分散のキーとなる属性(パーティショニングキー)の値によって、操作対象ドメインを変更するといった対応が必要になります。分散のキーとなる属性(パーティショニングキー)の設定次第では、データの参照効率が落ちることが考えられるので、よく検討して設計を行う必要があります。文字列型の制限の回避SimpleDBのデータ型はすべて文字列型となっています。それゆえ、数値型として扱い、ソートを行う場合に制限があります。詳細は前回の記事を参照していただくとして、数値型でソートを行うような場合、以下のような制限回避方法を行う必要があります。ゼロ埋めを行う数値型のソートで問題となるケースとしては以下のようなケースがあります。『1』,『9』,『50』,『10』を昇順でソートすると、辞書順になるので『1』,『10』,『50』,『9』の順になる。このようなケースを回避するために、予め数値として扱う属性毎に桁数を決めておき、指定桁数に満たない部分に関しては『0』を埋め、正しくソートを行えるようにします。『001』,『009』,『050』,『010』を昇順でソートすると、辞書順になるので『001』,『009』,『010』,『050』の順になる。となり想定した通りの結果となることがわかります。基準値を決めるマイナス値を含む数値型のソートで問題となるケースとしては以下のようなケースがあります。『9』,『8』,『−8』,『-9』を昇順でソートすると、辞書順で『9』,『8』,『−9』,『−8』という順になる。このようなケースを回避するために、予め基準値を決めておき、基準値と値を合算した値を保存します。(-9)』を昇順でソートすると、辞書順で『091』,『092』,『108』,『109』という順になる。なり、想定した通りの結果となることがわかります。基準値からの計算を行わないと値がわからないので、パッと見て値がわからないというデメリットもあります。整合性の制限の回避こちらに関しては特に制限を回避する方法はなく、アプリケーションの要求に応じ、呼び出し箇所の整合性オプションを適宜変更する必要があります。その他の制限の回避ドメイン名の制限SimpleDBにはRDBでいうところのデータベースのようなものが存在しません。1つのアカウントの1つのリージョンに対して、1つのデータベースが与えられているというイメージになります。データベース内でテーブル名が重複してはいけないように、SimpleDBでもドメイン名の重複は許可されていません。これによって何が困るかというと、同じアカウントで開発環境と本番環境を構築した場合、同じドメイン名を利用することができないという事態が発生します。このような事態での対応としては以下のような方法が考えられます。同じドメインをテスト環境と本番環境で共同利用する例えば、『Employee』というドメインがあったとして、属性『environment』が『PRODUCT』のアイテムは本番環境、『TEST』のアイテムはテスト環境というようにして区別します。同一ドメインにテストデータと本番データが混在することになるので、データの誤操作が発生する可能性があります。ドメイン名にプレフィックスを用いる例えば、『Employee』というドメインがあったとして、テスト環境では『TEST-Employee』、本番環境では『PRODUCT-Employee』といったケースです。同一アカウントの同一リージョンにテストデータと本番データが混在することになるので、データの誤操作が発生する可能性があります。本番環境とテスト環境でアカウントを分ける本番環境とテスト環境で別々のAWSアカウントを利用することで同じドメイン名が利用することができます。AWSの操作やアカウント管理が煩雑になります。本番環境とテスト環境でSimpleDBのリージョンを分ける同じアカウントでも別リージョンであれば同じドメイン名を利用することができます。本番環境は東京リージョン、テスト環境はシンガポールリージョンと分けることで、同じドメイン名を利用することが出来ます。AWSの操作やアカウント管理は簡単ですが、別リージョンとの通信が発生するため課金が発生することと、東京リージョン以外との通信をおこなうため、ネットワークのレイテンシが発生します。まとめ今回はSimpleDBで発生する制限の回避方法について説明しました。制限の回避方法を簡単にまとめると以下のようになります。Javaを利用するケースを説明したいとおもいます。Connectカジュアルゲームゲーミフィケーションみなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。Seattle』に、我々フリューのモバイル事業部より中島、九岡、鷲見の3名で参加してきました。Seattleへの参戦記を参加した3名それぞれの観点で掲載していきます。今回はpart.3ということで、わたくし鷲見の特に印象に残ったセッション2つについて解説したいと思います。Gamification最近は日本でも耳にするようになった『ゲーミフィケーション』という言葉。ゲーム分野で使われるユーザを夢中にさせる要素をゲーム以外の分野に取りいれるという考え方で、日本ではWebやソーシャルアプリケーションの分野でよく使われるようになった感じがします。日本では抽象的な話を語られることは多いものの、具体的にどうするべきかといったことが説明されていることが少ない気がします。そんなゲーミフィケーションについて、具体的にどのように構築するべきかといった方法論を5つのキーワードから紹介したセッションです。ユーザーを没頭させるための5つのキーと題して以下のような点をあげています。1.ユーザーのソーシャルスタイルを知るどのような人がユーザーなのか。そのユーザーはどのようにすれば没頭してくれるのかを考える必要がある。コラボレーション』の4つに分類し、その4つの分野に該当する動詞にあたるアクションをゲーム内に散りばめることでユーザーが没頭しやすくする。ファン』の3段階に分類される。それぞれの段階ごとにユーザーが求めることが異なるので、それぞれの段階のプレーヤーが楽しめるようデザインする必要がある。初心者はゲームのコツを覚えることを求める常連は新たなコンテンツ・活動・挑戦を求める熱狂的なファンは独占・認知・反響を求めるこれらの段階別のユーザーの欲求を考慮してデザインを行うことが重要。3.活動にPERMAを導入するポジティブ心理学という分野のPERMAというフレームワークを活動の中に導入することでユーザーが没頭しやすくなる。Emotion・・・ポジティブな感情。喜び・楽しみ・面白さ・安全の経験Engagement/Flow・・・没頭。・協力できるような他の人との交流Meaning・・・意義・目的のある物語を作る。Accomplishment・・・ゴールの達成の頭文字の略です。これらPERMAの要素を導入することで、ユーザーが没頭しやすくなる。4.簡単にマスターになれるような成長のメカニズムを導入する良いゲームにはユーザーを学習させ、マスターに向かわせるようなガイドのメカニズムがある。ガイドのメカニズムを利用し、ユーザーのスキルを上げ、没頭させる仕組みが重要です。認知欲求や所属欲求のような個人の内発的な欲求を満たす報酬の方がユーザーのモチベーションを高める。認知欲求や所属欲求などをみたせるような報酬も準備することでユーザーがゲームを使い続ける動機付けとなる。これらの5点をちゃんと考慮することで、ゲーミフィケーションを盛り込むことができるようです。今後のソーシャルゲームの企画・開発に使える。非常に有意義なセッションでした。Review2011年のソーシャルゲーム市場を振り返るセッション。日本では一つ一つのアプリの特徴について触れる機会は多いのですが、市場全体を見た傾向がどうかといった情報があまりないような気がします。そんな市場全体の傾向について、成功事例や失敗事例を交えて発表してくれるセッションでした。今後のソーシャルゲームの流れを把握し、さらに先を行くために非常に参考になりました。2011年の傾向としては以下のような点が挙げられています。TAILSランキングTOP50内で、1年以内にリリースされたものは6個。リリース後1年以上立っているものが1/3を占め。成功したゲームの寿命が非常に長くなっている。メンテナンスを定期的に行い、週ごとに改善していくような努力をして寿命をのばす努力が必要。WELLFBのゲームのリクエスト、通知のようなバイラルが新規ユーザ獲得でなく、現状のユーザの維持のために役だっている。FRONTIER2009年から2010年は農場系のゲームが元気だった。現在でも農場系のゲームが多いけど、農場の真似をしただけのゲームが多くなってきた。農場の真似をするだけでなく、フロンティアとして新しい分野を開拓していく必要が出てきている。QUALITY同じゲームでもここ数年ですごく高品質化しており、高品質の時代がやってきている。ユーザーは一度いいものを味わうと元に戻れなくなるので、機能・コンテンツを磨き続ける必要がある。目新しい機能・コンテンツばかりになると、ユーザーが学ばなければならないことが多くなってしまうので、バランスの調整が退治。クオリティが高く、新しいものであることが大切。ITERATION似たようなゲームが大量に発生。User(以下、DAU)が多かった。2010年−2011年にはDAUが低下していき、そして、ほとんど消えてしまった。INVASIONテトリスのような昔からあるゲームが売れていたり、売れていなかったりしており、ケースバイケースの様相を呈している。考えたところ?以下のような原因が考えられる。CONFLICT2010年の対戦型ゲームは、誰が進んでいるのかといった進み具合を表示するようなタイプのゲームが多かった。これは構築型のゲームには適していた。他のユーザと協力することはできても、他のユーザーの邪魔をすることができない。2011年になって戦争ゲームのような競争系のゲームが売れるようになってきた。考えると、以下のような原因が考えられる。I.P.ライセンスを購入して作成するようなゲームはプロバイダーの助けになるのか?答えはある程度のインパクトは与えるけど、それだけでどうにかなるようなものではない。ライセンス系のゲームのメリットとデメリットはメリットユーザを獲得しやすいコンテンツが揃っているデメリットライセンスコストが高いライセンサーの承認が必要プレッシャーが挙げられる。ライセンサーからのニーズがあり、決められた期限内のリリースが必要で、スケジュール的にきつくなるようなことも多い。U:CollegeTownはゲームバランスが悪く、チュートリアルもあまりよくなく、納期的にもピンチだったけど、現在は質のよいユーザを獲得できている。ケースバイケースなので注意が必要。RPG?FacebookアプリのRPG分野は2010年はすごく調子が良かったが、現在は下降傾向にある。アイソメトリックミッション系・・・2011年は調子が良いモンスター収穫系・・・同じく調子がいいダンジョン探検系・・・調子が悪い。これから健全な多様化が行われていくことが今後期待される。ROADソーシャルゲームの会社は結構多くの数がクローズしている。大きな会社でもDAU稼げていないところが多い。?ソーシャルゲームは難しいソーシャルゲームは本当に難しいソーシャルゲームは本当に本当に難しいリリースしてからも、ブラッシュアップし続けていかなければならない。2,3回失敗しても、持ちこたえるような体力が無いと成功するのは難しい。Seattleに参加して特に印象に残ったセッション2つを解説させていただきました。Gamification』ではユーザーの段階に応じて、ユーザの所属欲求や認知欲求を考慮して、動機付けすることが大切であるということを学ぶことができました。Review』では、ゲームがどんどん高品質化し、ユーザーの求めるレベルが高くなってきているモノマネだけでなく、新しい試みが必要であるブラッシュアップをつづけ、ユーザーを飽きさせないことが必要であるということを学ぶことができました。これら2つのセッションから学べば、ヒットするソーシャルアプリを作れるかもしれませんね!私もこれらのセッションから学んだことを活かして、アプリをヒットさせてみたいと思います。Seattleに参加した中島・九岡からのレポートとなります。