GoogleAppEngineをいじる(1日目)

理解したこと

  • GoogleAppEngine(GAE)は、GoogleCloudPlatformが提供するPaaS
    • Passとは、ハードウェアやOSなどの一式を提供するサービス

GAE利用にあたり

  • まずはアプリケーションの作成が必要
$ gcloud app create
$ gcloud app deploy
  • ただこれだけだとエラーになる
  • インスタンスを生成するための記述をしたapp.yamlが必要

「ユーザーテスト」について本気出して考えてみた

前提

筆者はユーザーテストのプロでもないし、知見を持っているわけでもない。業務上、「ユーザーテスト」を行う必要があり、自身の考えをまとめるという名目のもと、本内容を記述している。実施に向けた準備と進め方についても記述しているが、その通りに行えば必ず上手くいくという保証はない。但し、上手くいく可能性を少しでも上げられるよう、本気を出して考えてはいるので、参考になる部分があれば幸いである。(自身の評価にも繋がるので、失敗は許されないのだ...)

何のために行うのか

自身が管理運用しているwebサービスを、より多くのユーザーに使ってもらうためには、「改善」という行為を怠ってはならない。けれども、闇雲に改善を行っても中々求める成果には繋がらないし、下手したらKPIに悪影響を及ぼす可能性もある。では、より精度の高い(成果に結びつく)改善を最短で打つにはどうすればいいのか?そう、ユーザーに聞けばいいのだ。

本社で「あーだこーだ」議論をしたところで、それがユーザーに刺さるかどうかは誰も知らないしわからない。考える時間があるなら、「ユーザーテスト」を行って答え合わせをした方が、最終的なゴールにたどり着く時間は短くなる。

但し、「出てきた答えを100%信じない」という前提のもと行う必要がある。たかが数人にテストを行い、出てきた答えをサイトに訪れている何百万人のユーザーの声と捉えるべきではないのは当たり前の話だ。

あくまで「改善策が当たる可能性を高めるため」と念頭においた上で、「ユーザーテスト」を行うことが重要だ。

実施準備

準備すべきものは大きく分けて「シナリオ」と「機材」の2つだ。この2つを準備しないまま、実際にwebサイトを触ってもらってリアルな声を聞いたとしても、「精度の高い改善策」は生まれない。以下、「シナリオ」と「機材」について、持論も含めて記述していく。

シナリオの準備

「何のために行うのか」という問いに対して、「改善策が当たる可能性を高めるため」と前述した。これ自体に間違いはないのだが、更にもう一歩踏み込んで考えたものが「シナリオ」に結びつく。

例えば、「検索機能がユーザーニーズにマッチしていないのではないか?」という仮説を立て、それを検証するためにユーザーテストを行う場合を考える。この場合、検索機能が本来全うすべき役割は何で、それを検証するためのユーザーの理想行動が「シナリオ」になる。今回の場合、「検索」という機能を使ってもらわなければそもそも検証ができない。ランキングや特集で探す姿を観察しても意味がないのだ。なので、検証対象を明確にした上で、しっかりと検証するための「シナリオ」を準備する必要がある。

ここで注意しなければいけないのは、「シナリオ通りにユーザーを操作しないこと」だ。「次は◯◯をしてください」「ここでは◯◯を選択してください」と、単一的な指示をしてしまってはテストにならない。あくまで「◯◯を見つけてください」と自由度をもたせた上で行動させ、道を外れた場合のみ軌道修正の指示を出すぐらいにとどめておくのがポイントだ。

機材の準備

これは調べればわりと出てくるが、実際に何度かユーザーテストを実施した上で、一番良いテストができた際に使用したものを記述していく。(なお、テストは社内の雑音が入らない個室で行った)

  • MacBook2台(iPhone画面収録用と記録用)
  • iPhone1台(ユーザーテスト用)
  • MacBookiPhoneを接続できるケーブル1本
  • QuickTimePlayer(iPhone画面収録用)

「ユーザーテスト やり方」とかでググるとよく出てくるのは、ビデオカメラで手元を撮影しつつ、手元の動作を見ながらテストを進めていくやり方だ。それでもできなくはないのだが、ユーザーに対して不必要な圧がかかり、自然体でのテストができなくなる。また、遠目から撮影した映像になってしまうため振り返りもし辛い。

そこで、手元を撮影するのではなく、画面そのものを録画する方法を考えた。MacBookiPhoneを接続し、QuickTimePlayerを使用することで、接続されたiPhoneの画面をMacBook上に表示させつつ、画面の録画ができるのだ。これにより、不必要な圧をかけずに行動を観察することができ、かつ鮮明な映像をもとに振り返ることができるようになった。

おわりに

対象者の選定や、実際の進め方など、ユーザーテストを成功させる上で必要な内容はまだまだ沢山ある。正直なところ筆者もまだ模索中であり、今後もテストを行う予定があるため、その経験を踏んだ上でより「改善策が当たる可能性を高めるため」のユーザーテストのやり方について記述していきたいと思う。1人でも多くの見知らぬ誰かのためになりますように。

「成果」について本気出して考えてみた

成果とはなにか?

"なしとげた結果。できあがったよい結果。"

「よい」がとても重要。 ただの結果ではなく、何かしら次に繋がるモノを生み出せたことが「成果」なのだ。

金、勝利、ツール、人との繋がり。 目に見える見えないに関わらず、目標に向かって行動し、無事達成できたときに「成果」はうまれる。

「成果を出せる人間になる」と新卒1,2年目の頃はよく言っていたが、当時は売上利益に貢献することが「成果」だと思っていた。 行き着く先は売上利益なので間違ってはないが、もっと手前の「成果」があるはずで、それこそが自分が声を大にして誇るべき「成果物」なのだと思う。

成果を追う

5月中旬。 会社の経営を見る部署から、売上利益を作る部署に異動となった。 兼ねてからやりたいと主張していた「データ分析」に従事させてもらえることになり、より現場に近いところの方がいいだろう、という判断だ。 自身としても仕事を通してやりたいことがやれるのは、とてもありがたいし楽しさも感じる。 反面、今までの働き方や考え方を変える難しさもある。

間接部門にいたので、「どれだけ行動できたか」が評価に繋がる。 「データ分析」という仕事は、PDCAのPCAを担う仕事でもあるため、部署異動になっても行動量で評価してもらうつもりだった。 そんな中、「成果を追う部署に所属する以上、成果目標を立ててそれを追ってほしい」と新しい上長から話をいただいた。

正直、最初は無理に成果目標を立てる必要が本当にあるのだろうか?と思っていた。 サイト改善やプロモーションなど、直接的にユーザーと接触することがないため、自分にとっての「成果」が見えなかったのもある。

それでも最終的には「成果を追う」という気持ちになれたのは、目指したいビジョンに「分析チームを作ること」があるからだ。 会社が人材リソースを分配する上で、最大限の成果(売上利益)を出せる組み方をする。 分析チームを作ることが会社の成果を上げることに繋がる、と思ってもらうためにも、「成果を出す」ことが今は重要なのだ。

自分よがりの成果は成果と呼ばない

冒頭、「成果とはよい結果のことだ」と記述した。 ただ、会社という組織で成果を追う以上、自分よがりの成果を出しても、それは評価に値しない。 ただの自己満足であり、マスターベーションに近い何かだ。

様々なプロジェクトに所属し、他部署の人とも連携をとって仕事をしている自身にとっての成果は、「会社」という大きな範囲で考えても「成果」だ、と言えるものでなくてはならない。

「データ分析」という仕事で見ても、PDCAのDは他職種の方にお願いしなければならないので、自分だけでうみだせる成果は正直ないに等しい。 だからこそ、自分よがりにならず、広い視点で「何が成果と呼べるのか」を考えて目標を立てる必要がある。

蛇足

新卒5年目にして、やっと「成果」について考えるという中々のスロースターターだが、思っていたよりも自分の中で「成果」という言葉の定義はしっかり定まっていた。 システムエンジニア2年半、プロジェクトリーダー1年半、そして今やっと自分が本当にやりたいと思える「分析」に関わる仕事に就けている。 まだグループ会社全体でみても、存在しない職種ではあるが、だからこそ今後そのポジションを目指したい人のモデルケースとなれるよう、今は「成果」を出して、会社に対して必要性を説いていかなければならない。