Yunicode

nanapiプロデューサー永田ゆにこの日記 ←この人だれ?はこちら

「生活のたのしみ展」のバイトで、サービス設計やコンテンツについて考えた

2018.06.12

株式会社ほぼ日が主催する 「生活のたのしみ展」というイベントで4日間アルバイトをしました。そこで、サービス設計やコンテンツに関係・共通する体験をしたので、ブログに書いてみます。

生活のたのしみ展とは

2018年6/7〜6/11に恵比寿ガーデンプレイスで開催された「生活のたのしみ展」。普段ほぼ日で取り上げられる商品や扱われている商品を実際に販売する、というほぼ日がまるっとリアルに飛び出てきたような催しです。前回と前々回は六本木ヒルズで開催され、今回3度目の開催。 1度目は普通に客として参加し、2度目はほぼ日の塾生としてイベントレポートで参加し、3度目の今回はアルバイトとして主催者側での参加。

する方はあってもされる方の面接はめったにないので、バイトの面接はすごく緊張した… 無事採用して頂けてよかったです。

4日目から天候が崩れる

合計5日間の開催だったわけですが、4日目と5日目は雨でした。台風きてましたからね。 会場は一応屋根はあるもののほぼ野外。ガーデンプレイス側ともいろんな調整があったようで、4日目の日曜日は直接雨が当たってしまう約半分ぐらいの店舗を、少し離れた内部の別会場「グラススクエア」に移しての営業となりました。

この日の主な業務は、メイン会場からこの別会場に人を送ること。ここにサービス設計と同じような考察と試行錯誤がありました。

どうしたら別の会場に人を送れるか?

メイン会場の入り口から少し入ったところで、別会場「グラススクエア」への誘導。

ちょっと話が反れますが、前の日、階段の上にもお店があるのにそのエリアへはあまりお客さんが流れず、声がけをして誘導する、ということをしました。階段の上のお店はマップにも記されているし「上にもお店があります」という案内板もあるのに、お客さんは想像以上に「階段の上にあるお店」を認識しません。階段の下から上のお店は見えないので、直接目で見えていないものは非常に認識されづらい。 そのようなことがあったあとだったので、階段の上へ人を送るだけでも結構な難易度なのに、全く別の会場に人の興味を向けるのは更に難しい、という想像はつきました。

しばらく案内板通りに「グラススクエアはこちらです」と声がけをしてみましたが、なかなかお客さんは動いてくれません。

なぜ案内を聞いてもらえないのか

なぜ聞いてもらえないのだろうと考えたとき、そもそも前提として、

  • お客さんは見えている範囲のメイン会場しかないと思いこんでいる(階段の上へ誘導の経験上から)
  • お客さんは雨で半数の店舗が別会場に移動したことを知らない
  • お客さんは店舗が別会場に移動するという発想がない
  • お客さんは別会場の名前がグラススクエアだということを知らない

ということがあるなと思いました。

基本的に、お客さんはメイン会場しかないと思っているので、閉まっているお店を見てもその店舗が別会場に移動しているとは思いません。「ここの店舗が目当てだったのに!」という人以外は、閉まっているお店を見ても、ここは今日やっていないんだな、程度の認識なのかも。 「雨だから店が別の場所に移動する」という、主催者側からすると何でもない情報が、お客さんからするとイレギュラーな発想なので、そこにまずハードルがあるのですよね。そして、別会場の名前が「グラススクエア」だという情報は「雨だから店が別の場所に移動している」のさらに先にあるので、いきなり「グラススクエアはこちら」という案内板を見せられても何のことだかわからないのです。

ほぼ日の塾に通っていたとき、塾長の永田泰大さんから「人は、他の人の言っていること・やっていることに対して初めは、しらんがな、としか思っていない」という話を聞きました。自分に関係がある、もしくは何か興味を惹かれる、というポイントがないと聞いてももらえない、とはまさにこのことだなと。

どうしたら自分に関係あると思ってもらえるか

雨だから別会場があるというイレギュラーな状態であることを伝え、そこには期待するものがあるよ、という言い方なら耳を傾けてもらいやすいのではないか?

そこで、

  • 今日は雨です(雨だよね)
  • 雨なのでお店が移動しています(ここにはないよ)
  • メイン会場以外にお店が移動した別会場があります(移動する必要があるよ)
  • そこにたくさんのお店がある(そしたら楽しいことがあるよ)

と、あなたに関係あることですよ、を伝えるため「本日雨のため、たくさんの店舗が中の別会場に移動しています」という言い方に変えました。ポイントは「たくさんの店舗」「別会場」「移動」 という単語です。

その結果「ここ以外にもあるんだって〜」という声が聞こえるようになり、直接場所を聞かれることが多くなりました。グラススクエアという会場の名前は、実際に案内するときに伝えればいいので、声がけの情報として入れませんでした。案内板も「グラススクエアはこちら→」というものではなく、パッと伝わる「雨のため店舗が別会場に移動しています→」とかの方が良かったかもしれないですね。

案内板を目にしてすぐ案内の内容がわかる人もいると思うけど、生活のたのしみ展に来ている人たち全員がそうとは限らないので、できるだけ情報を伝えるハードルを下げた方が、あらゆる人に伝わるのではないかと思いました。

【追記:2018/6/14/17:00】

上記の一文を、

「ほぼ日の読者はある程度、情報の受け取り方に対してリテラシーの高さがあると思うけど、生活のたのしみ展に来ている人たち全員がそうとは限らないので、できるだけ情報を伝えるハードルを下げた方が、リテラシーが低い人にも高い人にも伝わるのではないかと思いました。」

という記載にしていましたが、「ほぼ日の読者」「リテラシーの高い・低い」という言葉から、 ほぼ日の読者と今回のイベント参加者にリテラシーの差があるような表現になってしまったこと、 そして運営側が解決すべき会場の問題を来場者のリテラシーに頼るような誤解を招く表現になってしまったことをお詫びします。 そのような意図はなかったため、該当箇所の撤回と修正をいたしました。 不快な思いをさせてしまい申し訳ありませんでした。(追記ここまで)

どういう動線での案内が最適か

同時に、伝える場所もいくつか試してみました。

最初は入り口から少し入ったところで案内していたのですが、そこだとすぐ奥にこれから向かうつもりの並んでいるお店が見えるので、お客さんの興味はそっちにいってしまい、別の会場があるなんていうアナウンスは耳に入っていないようでした。

ではどこなら一番聞いてもらえるか。会場を一周回ってきて、奥の集合レジに辿りつき「ここで終わりかな?」って思ったタイミングで案内をすれば「お、まだあるんだな」と思ってもらえるのでは?と想像し、レジ前で案内してみると効果があり、会場を尋ねられる回数が増えました。

最初に案内していた入り口付近の方が別会場に近いのですが、もう一人別のアルバイトの人にわたしのいるレジ前から別会場までの途中に立ってもらい、まずはその人までを案内し、続きの案内はその人にお願いしました。おかげで少し離れた場所を長々と説明しなくて済み、この連携は結構うまくいったと思います。

コンテンツとUX設計に共通すること

というわけで「どのような単語を使ったり、どんな情報を先に伝えると、続きに興味を持ってもらえるか」の話はコンテンツでも同じことが言えるし(この辺はかなりほぼ日の塾で学びました)、「どういうタイミングと場所で伝えると効果的か」という場所の話はUX/UI設計と同じだと思いました。

普段は画面に向かってこういうことを考えているのですが、実際にユーザー(今回でいうとお客さん)の反応を見ながら、細かくPDCAを回せる環境でやってみるとめちゃくちゃ勉強になりますね、、基本的な本質の部分の考えは何事も同じなのだな。

学ぶことが多かった

他にも、エリアマネージャーたちの、会場をいかにうまく回すか、の動きはマネジメントの勉強になったし、次々起こる予想外の出来事を目の当たりにして、イベントを主催するっていうのはすげー大変なんだなっていうことがいろいろ見られてよかったです。

5日中4日の参加で、しかもそのうち金曜日と月曜日は有給、土日も返上、それで時給1,000円っていうと「なんで会社休んでバイトなんかすんの??」と不思議がられたりもしましたが、あれだけでかいイベントの裏側を見られることには大きな価値がありましたし、上記のような学びもあり、良い経験になりました。

お世話になったみなさん、ありがとうございました。

余裕がないときほど手段の目的化に走りがちになる

2018.03.19

先週、謎の焦りを感じていて、ふと「やっぱ自分でもちゃんとSQL書けた方がいいな」と思い立ち、SQLの学習方法を検討していました。

FY17のnanapiは主に立て直しや裏側の整理が中心でしたが、4月からのFY18は実際に数字を動かしていくことになるので、 ツールを使う言語を習得しておいたほうがいいだろう、という考えの元でした。SQLの基礎知識はありますが、実務としてはできないレベルなので。

でも、ある程度学習方法を絞り、なんとなくそれをエンジニアに共有したとき「欲しいもの(データ)を言ってくれればすぐ出しますよ」と言われて我に返った。 自分でデータを見にいくより(意思疎通のとれた)優秀なエンジニアに頼んで出してもらった方が何倍も速いし正確、圧倒的に工数もかからない。 だとしたら自分でSQLを叩く理由って何?勉強する時間の意味って?

改めて自分の役割とやるべきことを考えると、生のデータをどうこうすることより、 もっと今後の戦略について考えなければいけないことは歴然で、そこがないとそもそもデータをどうこうもできない。 SQLは書けた方がいいけどその時間でやるべきことは別にあるし、今じゃないよなー、と。

スキルを勉強するのは「何かを得ようとしている」ことに正義を感じるし、「勉強している自分」が気持ちいいから、安易に思いつきなんですよね、わたしの場合。 (このブログもmiddlemanを使ってslimとsassを習得することが目的だったので、作ってるときはめちゃくちゃ気持ちよかったです。)

「何に焦りを感じているのか(課題)」「それをどう解決すべきか(手段)」を整理すればすぐわかることですが、余裕がないときはなかなか冷静にそれを考えられず、 とりあえず全てを飛ばして手段の目的化に走りがちです。焦っているときほど「がんばっているような気になれる」ものに流れてしまいがちだなーというのを痛感しました。 一人だとクサクサしがちなので、もっと他の人と対話しつつ、冷静にやるべことと最適な手段を選択していきたいものです。

余裕がないときこそ、手段の目的化に走らず冷静に課題整理をしたほうがいいですね、という自戒を込めた普通のお話でした。

nanapiのレシピの下にユーザーさんのツイートを埋め込む機能を実装しました

2018.03.14

nanapiのレシピの下にユーザーさんのツイートを埋め込む機能を実装しました。

サンプル=>   税金戻ってくるかも!アルバイト(フリーター)の方向け確定申告のやり方 | nanapi

ここ最近のnanapiはTwitterをメインに様々なレシピを紹介しているのですが、ユーザーさんからいろんな反応をいただきます。

「できた!」「おいしかった!」という実際にやってみての感想や、「もっとこうした方がいいよ」や「こういうのもあるよ」など、 レシピを補充する情報をいただくこともあります。

「できた!」「おいしかった!」という声や写真は、実際にやってみるとこんな感じになるのかというイメージが湧きやすくなり、 「もっとこうしたほうがいいよ」「こういうのもあるよ」はnanapi編集部でも集めきれなかった情報なので、よりレシピの内容を充実させることができます。

ずっと、このような外からもらえる良い情報をnanapiに還元できないかと考えており、まずはレシピの下に埋め込めるようにしてみました。

今後は、

  • レシピの内容に付加情報として有益なもの
  • 実際にやってみた体験談や感想(成功も失敗も)
  • 実際にやってみて気づいたこと

というツイートをいただいたら随時レシピ下に埋め込んでいく予定です。もちろん勝手に埋め込むことはなく、必ず許可を得てから掲載します。

nanapi編集部としてもアウトプットできる情報に限界があるので、ユーザーさんからの声は非常にありがたく、大事に扱っていきたいと思います。

レシピの内容に対しての質問や、内容への指摘は、サイドメニュー(SPの場合はフッター上)に「編集部にリクエスト!」というお便りコーナーがありますので、 そちらからお送りいただければ追って対応いたします。

プログラミングを学んでおいて良かったと思う

2018.03.07

株式会社ロケットスタートに入社して、毎週月曜と木曜の二回、始業前の朝9:00〜10:00に、nanapi創業者元CTOのwadapからプログラミングを教えてもらっていました。

ロケットスタートにはデザイナーとして入社したのですが、始めの頃は本当にめちゃくちゃポンコツで何の役にも立てず「このままではわたしを雇ったことを経営陣全員が後悔してしまう!やばい!」と焦ったのがきっかけです。 当時の開発部はわたしとwadapのふたりだけだったので、プログラミングを理解することで少しでもコミュニケーションを円滑にできれば、という切実な願いでもありました。

プログラミングのセンスには全く自信はありませんでしたが、wadapみたいなnanapiをひとりでサクッと作っちゃうすごいエンジニアにプログラミングのことを初めて教えてもらえるなんてラッキーすぎるし(しかも無料)(しかも終わると挽いた豆でコーヒーを淹れてくれる)頑張ってついていったのを覚えています。人生で一番まじめに予習と復習もした。

内容はインターネットの仕組みという超初歩的なことから、PHP、DB、SQLまで広範囲に。

いまのnanapiはRuby on Railsですが、当時はPHPだったのでPHPの基礎も学習。 ループ処理、if文から始め、最終的には自作の掲示板を作成するところまで一通りやってみました。 ページングをスクラッチで書くのは本当にキツかった。いまだから笑って話せますが、当時は本気泣きしたの覚えてます。 逆にDBを作って情報をぶっこみ、SQL叩いてデータ引っ張り出すあれこれはめっちゃ楽しかったです。

01

↑夜遅くにホワイトボードに書いてもらったページングのヒント。(基礎編なので脆弱性あり)このあとwadapとtakumixが飲みに連れて行って慰めてくれた、という話はまたどこかで。

その後、ロケットスタートから株式会社nanapiになり入社する人数が増えても、入社した人(エンジニア以外)は全員wadapのプログラミング講座を受講する、という流れになりました。 編集でもディレクターでもデザイナーでもみんなです。 全員がバリバリにPHPを書けるようになる!というよりは、nanapiはどうやって動いているのか、エンジニアはどんなことをしているのか、などを理解して技術の目線を上げる、ということが目的でした。

wadap自身も2014年にブログに書いてます。→ 技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ

前提が長くなっちゃいましたが、という昔話をなぜしたくなったかというと、あれから、デザイナー、ディレクター、プロデューサー、と経験してきて 「あのときプログラミングを学んでおいてよかったなあ」ということがめっちゃあるなーっていうのと、 最近チームのエンジニアと話していてもそう思うことが多いので、ブログに書いてみることにしました。

<デザイナーの頃>

  • 実装についてエンジニアと話がしやすい
  • 主にコーディングなどで先を読んで対応できる

<ディレクターの頃>

  • やろうとしていることの先の処理が想像できる
  • データの扱い方について発想が広がる
  • 開発の工数予想ができる

<プロデューサーの今>

  • 実装イメージの抽象度が下げられる
  • プロダクトで問題が起きたときに対処法を想像できる
  • 所持しているデータについて理解し責任が取れる
  • 各業務のコストダウンに関する発想ができる
  • その他各種コストが計算しやすい

と、ざっと出してみましたが、たぶんもっとある。学んでいなかったらできなかったことも多いです。

もちろん、プログラムをがっつりと書くことはできませんが、知識として知っているだけでできることはすごく増えますし、円滑にできるコミュニケーションもめちゃくちゃ増えます。 エンジニアと話していて、わたしの知識が足りていないところは今もまだ当然あるけど、話をする上でベースがあるとないとでは全然違うな〜って思います。(まだまだだろ!と思ったエンジニアの人、ごめんね!精進いたします)

本当に学んでおいて良いことしかなかったので、エンジニアじゃない人も知識として一通り薄くでもかじっておくと、 のちに自分のスキルの底上げや、サービスを作る上での土台になるのでおすすめです、という話でした。 Gitを使っている会社だったら、自分が使ってなくてもGitの概要ぐらいは理解してみるとなんかのときに役立つかもしれないです。

いまはプログラミングを学ぶサービスなんかもたくさんあるので、わざわざ誰かに教えてもらわずとも学べるから良いですよね。(2010年はあんまなかった気がする)

違和感を無視しないで大事にする

2018.02.27

最近チームで話すときにファシリテーションで大事にしていることは「メンバーがどこで違和感を感じているのか」を注意深く見る、ということです。

少しでも「( ・⊝・ )?」「( ˘•ω•˘ )?」って顔をするタイミングを見逃さない。

チームのエンジニアは、納得していないとき、何か疑問が残るとき、は絶対に納得していない顔をします。でも本人は最初「何に違和感を感じているか」よくわかっていなかったりするので発言はしない。なのでここで必ず声を掛けます。そうして、その違和感を丁寧に拾い上げて紐解いていくと、実は他のメンバーがそれまで誰も気づいていなかった課題に辿り着いたりする。本人が始めからそれを「課題」として認識していなくても「なんか変だな」という違和感がアラートになり話すきっかけにできる。

ここのシーンで見逃して先に進んでたら、結局後戻りになってまたここに来てたな、ということも少なくない。特に見落としていることがなかったとしても、そこの違和感についてきちんと話すことにより、本人の理解が深まり、腹落ち感がより得られるので、その先のコミュニケーションが少なくて済んだりします。

【違和感を大事にするメリット】

  • 話が進んでいるけど何か見落としていることに気づける
  • 腹落ちせずに進んでしまうことを避けられる
  • チーム内で大きな齟齬が生まれない
  • 腹落ち・納得することで熱量・コミット感が高まる
  • 結果的にコミュニケーションコストが抑えられる

【違和感を大事にするデメリット】

  • 時間がかかるのでめんどくさく感じるときもある

本質を理解しているとデメリットはさして問題じゃないので、ほぼメリットのみですね。違和感はすごく大事だと思います。幸い、いまのチームではそれを放置して前に進むことができない人ばかりなので、一見めんどくさく感じることもあるんですが、結果としてはそこがすごく安心できます。

というわけで、長期的な戦略に取り組んでいく上では、こういうコミュニケーションにとことん投資した方が、先でのエラーが少なくて済み良いです、という話でした。

構造的な文章を書くトレーニングはSlackでできる

2018.02.22

ロケットスタートという会社の頃、自分の言葉は話すことも書くことも、全く構造的ではありませんでした。

たとえば誰かに何か相談をしても、まず最初に要点の整理を相手にしてもらってから本題、みたいになり、相談内容へ行く前の事前整理にすごく時間を使ってしまっていました。 ここをもっとできると、そのぶんの時間を肝心の相談内容や解決法に時間を割けるのでは、と思い、構造を整理しながら話す、ということを意識し始めました。 話すときだけでなく、文章にアウトプットをする場合も同じで構造的になるようにしています。

構造的に文章が書けると、

  • 言いたいことが伝わりやすい
  • 相手に何をしてほしいか伝わりやすい
  • 記録に残しやすい(時間が経っても意味がわかる)
  • 結果自分も相手も時間が節約できる

みたいなメリットがあると思います。

個人的に、マークダウンで書かれた文章が一番理解しやすい。文章を整理するという意味ではマークアップとほぼ同じなので、デザイナーやエンジニアの人には馴染みがあるのかな。 文章が整理され、要点をしっかり抑えることができ非常に良いです。いまはそこそこ書けるようになってきたと思います。

構造的な文章を身につける手段としては、

  • マークダウンで議事録をとる
  • Slackでの文章も構造を意識して送る

の2点をやってます。

マークダウンで議事録をとる、は議事録じゃなくてもいいんですが「話を聴きながらマークダウンで構造の整理しながらメモる」をやりまくるとだんだん整理をしながら話を聞く癖がつきます。 カンファレンスへ行ったときに実践するとか。余談ですがnanapiはQiita:Teamを導入しており、Qiitaはマークダウンに対応しているので、そのまま議事録をアップできて便利。このブログもマークダウンに対応してます。

Slackで送るような短い文章も、構造を意識して書くようにしています。特に誰かに何かを依頼する場合。

xxxで使われているyyyに関して、zzzしたいと考えておりまして今プロトタイプを作成しております。そのプロトタイプに関してご確認いただきたいのですが、aaaa日の午前11時〜お時間をいただくことは可能でしょうか?プロトタイプの内容に関してはその打ち合わせ前日にはお送りするようにします

xxxで使われているyyyをzzzしたいと考えております。

プロトタイプを作成しましたので確認させてください。

確認いただきたいポイントは以下です。

  • ほげほげ
  • ふがふが
  • ぴよぴよ

mtgの日程は、aa日11:00はいかがでしょうか?

より詳細は追って前日にはお送りします。

みたいな感じでしょうか。

伝えたいことをだらだら書くのではなく、どうしたら簡潔にできるか。日々意識し積み重ねていくと、相手にも一層伝わりやすくなりますし、自身のトレーニングにもなり一石二鳥です。 nanapiチーム内でも、伝わらない文章だと相手の時間を無駄にしてしまうので、なるべくロスタイムを生まないような伝え方をしよう、と共有しています。

しかしながら、すべての会話を構造的に意識してしまうと、それはそれでchannelが殺伐としてしまうので、適材適所というのはある。 エモい気持ちを伝えたいとき、エモいコンテンツをつくるときは、逆になにも意識しない方が伝わったりする場合もあるので、構造的な文章のすべてが正義というわけではないかなと思います。

しょうもない失敗をしてメンバーに許してもらいたいときは、わざとバカな感じの発言をして許してもらってます!

どこの話をしているのか確認しながら話すと結果無駄な時間を抑えることができる

2018.02.20

nanapiメンバーでミーティングをするときにやってることを書いてみます。

01

いつも新しい何かを話すときは、最初に↑の図を書いて、これから何の話をしようとしているかを、一番上段のAから確認します。最初の5〜10分くらいです。特にC、具体的な手法の話をしようとしているときは特に意識してこの確認をします。

目的は以下。

  • 上段にあるAとB「目的」「やり方」から順に確認していくことで「なぜやるのか」を再確認
  • 手段の話で盛り上がりすぎるのを防ぐ(Cの話をする場合)
  • 全員の熱量と目線の高さを合わせる

よく見かける、戦略・作戦・戦術っぽいですが、そこまでちゃんとしたものでなくてもよくて「目的からちゃんとブレイクダウンした上で、これから何を話そうとしているか/何を話すべきか」だけわかれば良い。この図があると、より可視化できるのでサッと書いてます。

これからCの具体的な施策(新機能の実装や、なんかキャンペーンとか)について話そうとしている場合、Cより上のAかBに空白、もしくは不透明なままの箇所があるなら、そこを埋めてからCの話したほうが良くない?というアラートにもなる。そこを空白にしたままそこより先の話をしてしまうと、すすんでからズレがわかり、場合によってはすごい後戻りになってしまうので。 密なコミュニケーションをとってる同士でも、あとになって齟齬が発覚して無駄な時間が発生する、ということがわりとあります。

AとBのところが明確になって、じゃあ具体的なCの話をしようか、というときも、

  • AとBを実現するCは今から話そうとしているaでいいの?
  • その他にbやcになりうる案はないか検討した?
  • aとbとcがあったら本当にaが最適って明確なんだっけ?

も、一応話しとく。「aを実装したらBが実現しそう」っていう手段やアセットから逆算で考えるのとか、勢いで「一旦aをまずは実装してみますか」みたいなのをやりがちなんですが、サービス開発ってそんなに簡単なものじゃないし、経験上ほとんどうまくいかない印象。趣味やサークル的な集まりだったらいいけど、自分は天才でもないんで仕事ではあんまりやっちゃだめなやり方だと思ってます。

あと時々ブレストが白熱すると、どっか一箇所にフォーカスしてめちゃくちゃ話込んじゃったりするんですが、一旦落ち着いて↑の図で「今どこの話してるんだっけ?」を確認すると、いまそこの話をすべきかどうかが冷静にわかっていいです。Bを固めようとしているのに、まだ決まってもないbの案について白熱してもしかたないですからね…。そんなバカなことある?って感じなんですが意外にやってしまうんです、、

そこはファシリテーターとかプロジェクトを引っ張るリーダーがズレのないように牽引せえよ、とも思いますが、誰かひとりだけがわかっててもみんながついてきてないとあんまり意味ない。プロジェクトはチームで進めるものなので、全員の腹落ちのためだったり、意識を揃える意味でも、毎回こういう丁寧な確認をしていく方が、結果無駄な時間を抑えられるんじゃないかなーと思います。

今のチームのメンバーはこの辺の理解があり面倒臭がらず確認してくれるし、手段の目的化もやめようと意識しあってます。どのプロジェクト、チームにも応用できるものかはわかんないですが、今のチームではこのように進めていて結構うまくいっています、という話でした。