エンジニアもロジカルに企画・デザインできる!ハイパーエンジニアデザイナーへの道」

iQONさんの画像
こんにちは。GeNERACEのエンジニアのみきあらいです。

今日はiQONさん主催のイベント「人気ファッションアプリiQON★クリエイティブワークショップ ~女子をつかむUIの作り方&デザインワークショップ~」に参加したときのお話をします。

すでにご存知の方もいるかもしれませんがiQONとはどういうアプリかというと、女性向けのファッションを取り上げたアプリで、ユーザーは自分で考えたコーディネートをアプリ上にアップできたり、他のユーザーがアップしたコーディネートで欲しいものがあったら買えるというものです。

百聞は一見に如かずということでアプリの詳細については以下をご覧ください。facebook×amazonといった感じで面白いです。

http://www.iqon.jp/

イベントに参加してどういうことをしたかというと、iQONの方々のお話を聞いたあとは参加者同士でグループワークをしました。グループワークのテーマは「アプリの登録情報入力画面とログイン画面をデザインする」です。

以下、イベントとグループワークを通して聞いた話とそれに対する気付きを紹介してきます。

  • 「面倒なこと」「つまんないこと」が斬新なデザインを生む!

イベントで聞いた話の概要(以下、イベント):「名前とか住所とか入力するのめんどくせーなあ」→「やっぱ登録するのやめるわー」

といったように登録する直前でアプリから離れてしまうユーザーは少なくないようです。そういったユーザーの動きを止めよう!という傾向があります。
例えば対話型や穴埋め式のログインフォームにするといったような工夫が必要です。アメリカですでにそんな画期的なログインフォームがあります(例:私の名前は「    」です。)

気付き:ネガティブ要素を潰すことが新しいデザインやコンテンツを生むようです。
例えばソーシャルゲームで遊んでいて「挨拶機能とか面倒だな」と思ったら、挨拶機能をなくして別の機能でユーザーに特典をあげる、などというアイディアを企画チームにも話して、その仕様で実装するということができそうです。

  • データ至上主義

イベント:「なんとなーくこれがやりたい」「なんか良さげ」で企画やデザインを決めないし決めさせない!
「LINEの新しいスタンプを売る」という企画があるとします。スタンプを売るということで例えばディズニーのスタンプを売ろうという意見があり、それを採用するとします。
もしこの「ディズニーのスタンプを売りたい」ということを実現するためには、大抵の場合「なぜディズニーのスタンプを売るのか」「売り方・宣伝の方法はどうするのか」ということを考える、つまり「1. 売りたいものを考える → 2. 売り方を考える」という流れになると思います。

まず、ターゲットをすでにスタンプを高頻度で使ってるユーザーに絞ります。これによって、スタンプを買わないユーザーではなく、スタンプを買うユーザーに絞ります。
次に、スタンプを使っているユーザーが別のスタンプを買い換えるタイミングを調査します。
調査の結果、ユーザーがスタンプを買い替えるタイミングがわかったら、「新しいスタンプができました」というメッセージをターゲットであるユーザーに一斉送信します。
そのあと、スタンプをよく使うユーザーが実際にどういうスタンプを買っているのかを調査します。
調査してどのようなスタンプがよく売れているのかがわかれば、そのスタンプと似たようなスタンプを新しいスタンプとして売ります。

このように、イベントで聞いた話によると、「1. 売り方を考える → 2. 売るものを考える」といったように、はじめに書いた「1. 売りたいものを考える → 2. 売り方を考える」という順番とは異なります。
なぜ順番が異なるのかというと、「1. 売りたいものを考える → 2. 売り方を考える」という順番では、データ分析の前に「ディズニースタンプを売る」と決めているのに対し、後者の「1. 売り方を考える → 2. 売るものを考える」という順番では、データ分析に基づいて売る方法を考えた上でそれのあとに何を売るのか決めているからです。

「やりたいことがあるならデータ分析に裏付けされていないと企画としてみなさない」ということもこの例え話と同時にイベントで聞きましたが、この考えが売れるコンテンツを生み出す秘訣なようです。

気付き:正直デザイナーの方々は感性とかを何より大事にされるだろうという認識があったので、(会場にはデザイナーとディレクターの方々がいたわけですが)どちらかというと感性がものを言うことより、論理的なデータ分析の話をたくさん聞けたのがとても新鮮でした。

—————————————————————————–

☆その他気づいたこと、聞いたこと

  • 足を使って情報を稼ぐ!

「プログラマー=超絶運動不足」と思われがちですが、とにかく足を使って色んなイベントに参加してみると、他の会社の方々と情報交換して自分たちの仕事に活かせられます。(「skypeでいいじゃん」という意見もありそうですが、直接会場に出向くのが一番だと思います。また、ただイベントやセミナーの話を聞くだけでなく、実際にイベントの会場でグループワークをしてみたり、その場にいる人と情報交換をするなど、イベントに参加するときは受け身にならないという心意気も大切だと改めて思いました。)

今まではどちらかというと、企画チームに受身的に仕様を聞いて実装していたのですが、仕様やデザイン案をただ聞くだけではなく、自分から提案していく姿勢が大切なのかなと思いました。

最後までお読みいただきましてありがとうございました。

【2週間で3万円!!】無課金から課金ユーザになるまで ~ソーシャルゲーム体験記~

kunshiro

こんにちは。ピンキリエンジニアのひろゆきです。

本日は技術的な話ではなく身近にソーシャルゲームにハマってた人@弊社プロデューサーがいたので、どうやってそういった状態になったかを聞いてきた話を書いてみます。

ユーザー心理的なもので何かのお役に立てたら幸いです。

ちなみに僕は前職でソーシャルゲーム開発をしていたため、純粋なユーザー目線というのは持てなくなってる気がしていましたが

今回の話を聞いて、忘れていた気持ちを思い出しました。

ソーシャルゲームをそれほどやりこんでいない状態から、ついつい課金までしてしまうところまでいっちゃう感じが新鮮でした。

回復する時間に合わせて、タイマーをかけてプレイしている様子はハマってるなーって感じです。

さて、以下からが聞いてきた話です

Continue reading

Ubuntuのススメ ver 2013/04

20090433-11

こんにちは、GeNERACE CTO けんたろです。

僕のメインの開発環境のOSはUbuntu 12.10です。
Ubuntuをメインの開発環境にしてから約2年。
今回はUbuntu 12.10で僕がよく使っている便利なソフトやツールについて書こうと思います。

Continue reading

効率が良いペアプログラミング

こんにちは。エンジニアのみきあらいです。今回はペアプログラミングについて書きます。

「ペアプログラミング」「ペアプロ」などといった単語でgoogle検索すると様々な記事が紹介されますが、今回は初めてのペアプログラミングを行ったときのやり方と気づいたメリットをまとめていきます。

    ☆ペアプログラミングしたときの状況

  • ペアを組んでもらった人:自分よりも経験があり技術力もある(コードを書くのが速い、知識が豊富なため問題解決が速い)人
  • Gitでソースコードを管理しました。コードを書くときは各自のPCを使用しました。
    ☆メリット
    実は効率が良い:「二人で一つのコードを書くので効率が悪い」と思われがちですが、以下のメリットがあります。

  • 良い実装方法を共有しやすい:自分よりも経験があり技術力がある人に見てもらってペアプログラミングをすることにより、一人でコードを書くよりも良い実装ができます。
    さらに技術力がある人がコードを書くのを見てるとコーディングの勉強になる上に、開発を行う際にもどのように実装されたかをリアルタイムで見ているので情報共有がしやすいです。

  • 手戻りが少なくなる:一人がコードを書いてもう一人がそのコードを同時に見ているので、問題点があればその場で指摘でき、解決もその場でできます。
  • ソースコードを確認する時間が短縮できる:例えばGitでソースコードを管理しているときにもメリットがあります。GitでPull Requestを送って第三者にマージしてもらう場合、その第三者がリクエストした人とペアプログラミングをしていれば、リクエストされたコードを読むのに時間をかけなくてもどういう実装がされているのかがわかるので、すぐにマージをすることができます。
  • コーディングとコードレビューをほぼ同時に行うことができる:一人がコードを書き、もう一人がそのコードをほぼリアルタイムでレビューすることができるので、実は効率が良いです。
  • コードに責任を持てる:チーム開発ではつい自分の書いたコードに集中し、他の人が書いたコードに注意が向かなくなりかねないこともなきにしもあらずですが、それを回避するためにも「二人以上の人が書いて確認する」ことにより、そのコードに対して責任を持ちやすくなります。従って万が一障害などが起こった場合も、責任を持っているコードならより対処がしやすくなります。
    ☆今回のペアプログラミングのやり方とポイント

  • コードを書く人と書いてるのを見る人の2人で行います。30分交代でコードを書きます。
    その際は時間配分を計算して「どの処理まで書いたら交代」ということをあらかじめ決めておきます。
    具体的には、今回ペアプログラミングでやる実装の範囲を決めて、その中で行う実装をわけて作業をするとスムーズです。
  • コードを書くときはそれぞれのPCを使います。交代の段階でGitにコミットし、相手に引き継ぎます。
  • コードを書くときは「今どういう処理を書くのか」「何のためにこの条件分岐を行うのか」などを発言しながら書きます。
    実際にコードを読めばどういうことをしているのかわかるといえば確かにそうなのですが、ペアプログラミングで重要なのは「常に認識合わせを行うこと」なので、常に会話をしてコードを書くようにします。
    認識が少しでも合わなくなると二人でコードを書いている意味がなくなってしまいます。ただ会話すればいいという訳ではなく、コードを書く人も見る人も互いに認識確認をすることが大切です。
  • デバッグをこまめに行います。これはペアプログラミングに限った話ではないですが、バグを未然に防ぐためにもこまめに行います。
    ペアプログラミングならデバッグも一人ではなく事実上二人で行うため、より確実にデバッグを行うことができます。
  • コードを見る人は、書いてる人のモニターに張り付く勢いで30分間見ることに集中します。
    (当たり前のことのようですが、本当に30分間なら30分間集中しないとペアプログラミングではなく単独でコードを書くことになってしまうためです。)
  • コードを書いてる人のミスを発見したときは、「なぜそのような実装をしたのか」を見ている人が質問します。
    質問に答えることによって、コードを書いている側も「自分が本来やりたかった実装」と「今自分が書いてる実装」の違いに気付き、ミスの解決が速くなります。
    また、不要なメソッドの有無、変数名の付け方、インスタンスの生成の場所などに関しても指摘事項があればすぐにそれを共有します。
  • 書いてる人は見てる人の言う通りにコードを書くのではなく、見てる人にアドバイスをもらいつつも主体的にコードを書きます。
    これも当たり前のことのようですが、見てる人の方が書いてる人より経験がある場合、書いてる人はつい見てる人の指示通りにコードを書いてしまうようなこともありえます。が、それだと結局二人ではなく、見てる人が一人で書いているのとほぼ同じになってしまうため、ペアプログラミングの意味がなくなってしまいます。
  • コードを書くことからは少し外れますが、コードを書いてる人が自分よりも技術力がある人の場合、その人が調査してるときのやり方も見るべきポイントとなります。自分が一人でコードを書いていて調査するときの参考になります。

まとめました。

  • コードを書く人と見る人は交代制
  • 常に認識合わせをすること
  • 「一人」ではなく「二人」でコードを書くという認識を忘れずに!
  • 今回のペアプログラミングに関するメリットとポイントについては以上です。今回は具体的なコードの公開などは割愛させていただきました。
    最後まで読んでいただきまして、ありがとうございます。