読者です 読者をやめる 読者になる 読者になる

母校でプロダクト作りについて講義をしてきた

既に1ヶ月近く前だけど、年始に函館にある母校の先生に呼んでいただいて、大学院生向けの科目のなかで1コマ分講義をしてきた。

先方のオーダーを踏まえて、Web業界の事業会社という文脈で、プロダクト開発をどう捉え、どのような手法で、どんな問題に立ち向かいながら作っているのかという話を、これまでの経験をベースにざっくりした。普段話すような勉強会やカンファレンスとは違って、講義だと学生の関心もマチマチなので、なるべくテクニカルな話は抜きにしたつもり。

社内の新卒研修で何度か話してきた内容を、外向きにまとめられたので良い機会でした。去年末はほぼこれの準備でなくなってしまったけど、受講生アンケートを見る限り、好評だったようでほっとした😌

2016年の振り返り

今更ながら1ヶ月遅れで2016年を五月雨に振り返ってみる。

対外的な活動

例年に比べると、サービス開発やサービスデザインについての発表を外向きにできた年だった。

1月: Cookpad Techconf 2016

確かめながらつくるユーザー体験 #CookpadTechConf - deglog

200人ぐらいの前で、この手の話をするのは初めてだったので良い経験になった。

3月: Think User First #3

staffblog.cookpad.com

CookpadとFablicさんが共催しているデザイナーイベントでメンターをやらせてもらった。自社のデザイン手法をWS形式で伝えるのは初めての経験。 Think User Firstシリーズは#1, #2, #4は参加者として参加させて貰ってるけどいつも満足度が高い勉強会なので、また開催されるといいなあ。

6月: 某社でのサービス開発について講演 (クローズド)

例年Cookpadで新卒向けにサービス開発 (特に検証フェーズについて) の研修の講師を担当させてもらっている。 その8時間分の資料をぎゅっと圧縮して、某社でサービス開発について話をする機会をもらった。去年からたまーにクローズドな会に呼んでいただける機会が増えてきた。

8月: Cookpad Techlife Blog

techlife.cookpad.com

自分の中では4番煎じぐらいではあったんだけど、重要指標の建て方と活用について自社ブログにまとめてみた。 850ブクマもつくとは思ってなかったのでびっくり。

9月: dots React勉強会

【React勉強会】ランサーズ × Sansan × ビットジャーニー × キュア・アップ - dots.[ドッツ]

めずらしくReactについての登壇の機会をもらったので、今の会社でReactをどう取り入れていったかを話した。技術について話すのは苦手意識があるので緊張したものの、意外に反響 (400ブクマ) がありびっくり。

サービスデザイン周りへの時間の投資

去年に引き続き、自分の中でUXD, HCD, サービスデザインといった分野を知ることに結構時間を使っている。サービスの成功確度をあげるためにはやはり重要な要素だと思っている一方で、そろそろ自分の中で一回りしてきた感がある。

HCD-Net認定 人間中心設計スペシャリスト の合格

エンジニアが人間中心設計スペシャリストを受けて合格した話 - deglog

自分がHCDという分野について意識し出してだいたい1年ぐらい立ったので、現状確認の意味で受けてみた試験。テストを受ける類の試験ではなく、過去のHCD関連の業務実績をもって合否が判断される試験なので、これに受かったのはそれなりに自信になった。

産業技術大学院大学 人間中心デザイン講座

人間中心デザイン|産業技術大学院大学

9月から半年間週末に学生をしている。履修証明プログラムというやつで、界隈で著名な人達が講師として、UCD・UX・サービスデザインについての座学から手法の演習までみっちり教えてくれるプログラム。毎年応募殺到で抽選なんだけど、運良く受かった。座学編、方法論編、応用編と3部構成になっているのだけど、仕事のなかで実戦の機会は多いので、個人的には座学編で得られるものが多かった。3月末で全ての授業が終わるので、またまとめようと思う。

仕事

社会人4年目の年。2015年に苦しんで撒いた種がようやくちょっと芽生えたかなって感じ。大きな変化はチームメンバーが増えたこと。年明けに社長と2人だったのが、最終的に7人になった。人が増えるのに合わせて自分の役割も、エンジニアからプロダクトマネージャーに変わった。自分の時間をどこに使うのかという意識が変わったのが、去年と比べた大きな変化だった。

気が変わるかもしれないけど、エンジニアに戻るつもりは今は無い。ただエンジニアリングはずっと続けていきたい。抽象的な事柄を具現化する力は、サービス開発する上で絶対に必要だと思う。その質と速さが試行の回数にもつながるし、サービス自体の成功にもつながる。今後、肩書がどうなるかわからないが、コードを書くということは、目的はどうあれずっと続けていきたい。

健康

2015年の振り返りに、健康を害しそうって書いたんだけど、まじで害した。腰痛に始まり、度重なる風邪、結膜炎、脚に良性神経腫瘍、年末にはノロ…。健康診断はオールAなんだけど、外傷とスポットでの病気が多い。

ただそれによって、意識が高まって、家にスタンディング環境をつくったり、バランスボールをオフィスに導入したり、自転車買ったり、フットサル始めたり、プールに通ったりをしはじめたのは良かった(寒くてどれも最近はサボりがち…)。特に自転車を買ったのはQOL上がった。

週末学生を始めてから、本を読む時間が取れなくなってしまったので、読んだ数は少なかった。読んでよかったのは以下かな。

2017年

定期的に環境を変えたくなる性格で、これまでも2, 3年スパンでそうしてきた。環境というのは仕事内容や住む場所、人間関係とかライフスタイル全体的に。なんとなく東京を出たいなあという気持ちが最近うっすらあって、それは海外でもいいし、地方でもいい。幸い今の仕事はリモート可なので、その気になればやれる可能性はある。 いま携わってるプロダクト的に今年は勝負の年でもあるし、色々変化がありそうだなという予感がしている。あとそろそろ騙し騙しやってきた英語をなんとかせねばという気持ち。

サポートとのやり取りから見える Intercom の思想

いま携わっているプロダクト内で、Intercom をがっつり使っている。個人的にもすごく好きなサービス。最近ちょっと面白いなと思うことがあったのでまとめてみる。

Intercomとは

Intercomはカスタマーサポート (CS) 向けのSaaSで、チャット形式のサポートツールを主軸に、顧客管理やマーケティングメールの配信など、CSに留まらず所謂CRM (顧客関係管理) までをカバーしてくれるサービス。最近のSaaSだとちらほら使ってるのを見かける。

f:id:dex1t:20161222083937p:plain

Intercomの価値はこの図がよく表している。CS、マーケティング、行動分析、課金など目的の違いだけを見てシステムを導入した結果、ひとりの利用者にまつわる情報が分散してしまうというのはよくある話。CSはGmailで、マーケティングメールの配信はMailchimp、行動分析はMixpanel、課金はStripeでみたいな。Intercomはそれら分散しがちな顧客にまつわるあれこれをまとめてくれる。

プロダクトを作る人間として、目的はどうあれプロダクトと顧客の接点から得られる情報は、どんな些細なものでも無駄にしたくない。単なるCSのSaaSという以上の価値をIntercomに感じるので、すごく気に入っている。もちろんこの手の役割を担う製品は、CRMの分野で昔からあるんだけど (Zendeskとか)、うまくスタートアップ向けにパッケージング (機能の分け方や料金設計含め) していたり、プロダクト設計の巧さを感じる。

CSは最近だとCustomer Successと呼ばれたりもするが、IntercomもCSとは何なのか、何を考えどうすべきなのかというのを積極的に発信している。自社ブログも超気合が入ってるし、電子書籍を出版したり、Podcastをやったりもしている。この辺りのコンテンツマーケティングみたいなのもすごく参考になる。

前置きが長くなったけど、IntercomはIntercom自身のサポート対応も凄く丁寧で考えられている。海外製品のサポートに問い合わせると、時差もあるので返答に1日かかることはザラだけど、Intercomは遅くとも2, 3時間で初回返答が得られる。内容も変に堅苦しくなく、テンプレ対応ではなく親身に接してくれるな、というのを言語の壁を超えて感じる。Intercomを使い始めて3ヶ月ぐらい立つが、サポートを求めたり、フィードバックを送ったり、2-30回はやりとりしていると思う。

Jobs To Be Done

話は飛んで、JTBD: Jobs To Be Done という考え方がある。詳しくはググるとすぐ出てくるけど、日本語だと 片付けるべき仕事 とかそんな感じ。僕の理解だと、製品作るにあたって、利用者の要望をそのまま実現するんじゃなくて、利用者の言葉の裏にある、「何の仕事を片付けたいのか」を考えましょう的な話。

マーケティングとかリーンスタートアップとかでよく言われる、「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」とか「ドリルを買いに来た人が欲しいのはドリルではなく穴である」とか、これ系の話を総じてJTBDと言うらしい。

Intercomはプロダクトを作るにあたって、このJTBDの考え方を大事にしているらしい。この話は、以前参加した、SaaS Conference Tokyo 2016でもIntercomのマーケティング担当が話してて凄く面白かった。

hiromaeda.com

Intercom Educateでテーブル記法が使えない件に文句を言った話

話の本題。つい最近Intercom Educateというナレッジベース (ヘルプ記事を書くためのCMSみたいなもの) がリリースされた。ここ数日触ってるものの、まだリリースされたばかりなのもあってちょっと機能が貧弱で、ちょくちょく問い合わせたりフィードバック送ったりしている。

先日いち利用者として困ったのは、テーブル (表) を書くための記法がサポートされていないこと。ヘルプを見てみると、なんと表は画像として埋め込めって書いてある…。HTMLタグのべた書きもできないらしい…。

このときは「はーまじかよ!」とおもって、思わず記事の下にある 😞 ボタンを押した。すると自動でチャットが開き、「ごめん、なんかできることある?」と自動返信が来た。

f:id:dex1t:20161222091059p:plain

Intercom Educateにこの自動返信機能があるのは知っていた (このヘルプ記事もまたIntercom Educateでできている)ので、「はいはいあの機能ね」と思いつつ雑に「Please support table syntax.」とチャットに書いて、ページをそっ閉じした。

"美学 aesthetics"に反するからやらない

そうすると、数時間後IntercomのCS担当からこんな返信がきた。 (原文一部抜粋)

For the time being this isn't possible as it would ruin the aesthetics of our help center and thus cause damage to the overall look and feel of your article - we instead recommend you take a picture of the table for the time being and upload it in its place 👍 I'll provide your feedback to the team all the same - is there a particular use case or reason you could give me for wanting to see the table as a syntax option within the article editor?

ようは「ヘルプセンターの美学を損なうから、 テーブル記法のサポートはできない」「記事の見た目を損なう」「表は画像で埋め込め」だそう。

これには、お前らの美学とか知るかよ!と思ってイラっとしたので、こんな感じで返した。(実際は英語)

その方針は残念。画像として表を埋め込むと、記事を読んでる人がコピペしたくてもできないじゃん。それって利用者に不便かけてるよね。ヘルプセンターの美学よりも、利用者の利便性のほうが重要じゃないの? それと、記事のローカライズの観点でも、表を画像として埋め込むのは筋が悪いよね。テキストを翻訳するのに比べると、画像の翻訳ってめっちゃ手間なんだけど。

自分で書いたことだけど、めっちゃ正論だと思う。同じようなフィードバックを送ってる人たくさん居るだろう。 そしたら5分後に返信がきました。

Understood Takaya - thanks very much for the feedback here and I'll make sure to pass it on👌 I must emphasise that when I say aesthetics, I'm not only talking about looks - we also believe that each product has a job to be done and we want to make sure functionality is at its height. This means that, sometimes, the 'aesthetics' may interfere with the functionality of the product and make things unusable, not visible, or disturb the layout in a way which wouldn't benefit the users ability to use the product. We therefore avoid these situations, and tables are a syntax which can currently strongly disturb this - however, we are working on improving what extra HTML components we will support and ensuring they fit in with our overall product without taking away from the users experience. Once again, thanks for understanding, and if you have any more feedback then let me know 😊

僕の解釈だと、「美学ってのは見た目だけのことをいいたいんじゃない、俺達はどのプロダクトにもJTBDを大事にしてる」「テーブル記法は美学 (JTBD) を損なう。美学はときに利便性を妨げるかもしれない。」「美学を損なわずにいい感じテーブル作れる方法に取り組んでる」ってことらしい。

僕自身も記事を書くプロダクトを作っているので、この話はよくわかる。MarkdownにしろHTMLにしろ、テーブルをテキストで書くのは大変難しい。

JTBDでいえば、僕がIntercom Educateを通して片付けたい仕事は、「自分のプロダクトの利用者のために、分かりやすいヘルプ記事を書く」ことであって、「表をテーブル記法で記述する」ことではない。テーブル記法を使うのは慣れていても難しいし、間違いなく時間かかる。記法を実装し、それを記事にテーブルを入力する方法として安易に提供することは、利用者の仕事を増やしてるともいえる。

結果としては、短期的には不便を被ってるんだけど、Intercomのプロダクトに対する思想が改めて見えたし、じゃあ期待して待ってるよって素直に思えた。

改めてIntercomすごいなと思った

相手を見て話を選んでる感

正直、初回の返事でいきなり"美学 aesthetics"なんて言ったのは悪手だと思う。ニュアンスが分からないのもあり実際イラッとした。ただ、最後の返答は納得感あった。これはたぶん僕のIntercom上のプロフィール (RoleにProduct Managerって書いてる) を見た上で、"美学"なんて話をしてきたんだと思う。

プロダクトの思想がサポートチームにも行き渡ってる

Intercom自身もスタートアップとはいえ、地理的に離れた拠点が複数あるような規模の組織なのに、プロダクトチームだけじゃなくてサポートチームにまでちゃんと思想が行き渡ってる。組織の規模が大きくなればなるほど、プロダクトの思想への理解はブレるのが普通だと思う。前述したSaaS Conferenceの話やIntercomの自社メディアを見てると、プロダクトの思想を会社として大切にしているのは知っていたが、それを行動として直接見せつけられた感覚だった。

正論に流されない

なんでもそうですが、正論言うのは簡単。今回僕が送ったフィードバックなんて、世界中から色んな人がIntercomに同じこと言ってると思う。その正論に流されて、プロダクト作って良い物ができるかと言われたらそんなことは無い。安易に正論に流されないようにするのは、プロダクトを作る上で大事なことだと思う。

僕自身も自分のプロダクトでCS対応してて思うのは、フィードバックに対して「検討しますね」って言って終わるほうが絶対に楽。でもそこで正直に「美学に反するからやらない」って返すのは凄い。でも、実際そう返すのは怖い。だからこそ、相手を見て話を選ぶのが大事であり、その思想の体現として、Intercomでは顧客ごとに属性が紐付けられるようになっている。

とはいえ…

さっさとテーブル書けるようにしてくれ頼む 🙏(ってのが利用者の素直な気持ちなのはまた事実だから難しい…)

Pokémon GOのサービス設計的な所感

ポケモンGoにハマってる。先週末の土日で計30キロ歩くぐらい遊んでみて、サービス設計的に感じたことをまとめてみる。

ポケモンと僕

小学校低学年のころ初代ポケモンを遊んでいたポケモン世代。151匹集めて嬉しかったのを今でも覚えてる(その後バグでデータが消えたのはトラウマ…)。アニメも毎週楽しみに欠かさず見ていた(ポリゴン事件の回も見てたな…)。ポケモンスタジアムで友達と対戦しまくった。金銀の発売延期にやきもきしたし、ジョウトが終わったらカントー地方に行けたのには感動した覚えがある。

そんな思い出話が沢山でてくる、ポケモンGoの (おそらく) ターゲットどまんなか。ポケモンが綺麗なグラフィックで動いてて、鳴き声が聞こえるだけで楽しめる。

ポケモンGoをやってみて

以下、家の近所 (23区内) 、代々木公園、世田谷公園で遊んでみた所感。地方だとだいぶ感想が変わりそう。

世田谷公園に集まったトレーナーたち

  • 性別, 年齢, 属性(サラリーマン, 女子大生, おばちゃん, 柄悪い兄ちゃん…)問わず、色んな人が遊んでる
    • 母親と叔母からポケモンGoやってるかと連絡がきた
    • カップルや家族でポケモンしながら散歩してる人も多く見かけた
  • ルアーとレアポケモンの集客力
    • 世田谷公園はミニリュウが異常に出現する。それを求めた人で深夜までお祭り状態だった。
    • 企業とコラボしてポケモンやアイテム配布のような展開も今後ありそう
      • toCのマネタイズは弱い (ソシャゲのように課金しても差が出づらい) が、toBのマネタイズのほうが展開が豊富そう
      • 映画館やコンビニでポケモン配布等、似たようなことをこれまでもやってるし
  • バックグラウンドで歩数カウントされなかったりローカルPush通知がされないことがサービス設計上のキモ
    • この仕様のおかげでアプリを立ち上げっぱなしにせざるを得ない
    • 日本でのサービス開始前にこの話聞いた時は、アプリの出来が悪いだけだと思っていたが、これは狙ってやってそう
    • それを考慮してなのかアプリの通信量は控えめ
    • 他のアプリのDAUが軒並み下がったという話は納得。実際Twitterを見る回数が減った
  • 基本的には作業ゲー
    • 現状はいかに自分の行動をゲームに最適化するかの世界
    • 適宜報酬 (ポケストップ) があるから単純作業でも没頭できる。Cookie Clickerをやってる気分に近い。
  • ゲーム内のソーシャル性はほぼ無い
    • それもあって作業ゲー感が強まっている
    • 友達数人でブツブツ言いながら歩きスマホしてる人たちをよく見た。ゲーム内での交流ができない。
  • AR機能は実はポケモンと一緒に写真を取る機能だった
    • 使われ方として凄く面白い。インスタにシェアする流れも多く見かけた
      • 写真とった後にシェア導線を置くとか、普通のサービス開発だったらやりそう
      • そんな導線なくてもユーザーが工夫してやるのが、コンテンツ (キャラクター) の強さだよなあ
    • ゲーム的にはARをoffにしたほうがポケモンを捕まえやすかったりする
  • 中期的なゴールが無いのが課題
    • fladdictさんも同じことを言っていた
    • 実際2日間ガチで遊んだ (30km歩いた) だけで、ポケモン図鑑の6割 (90匹) が埋まった
      • その結果、やることが無くなってしまった…
      • 個体値でのモンスター選別や、151匹コンプまではやる気が起きない (かなり長期的ゴール)
    • 米でDAUが下がってる話も納得だし、Niantic的にも折り込み済みな気がする
  • ゲーム寿命の短さはポケモンGO Plusでは改善されない気がする
    • 専用デバイスを買ってしまったから続けようという心理になるかもしれないが、それは本質的でない
    • むしろポケモン収集が効率化されることにより、飽きが早くなりそうな
  • アプリ自体のアップデートに期待
    • モンスター (ジョウト編) や アイテム (わざマシン) の追加はもちろん、ソーシャル性 (友人対戦、交換、リーダーボード等) の拡充あたりあってもよさそう

アプリ外の体験

世田谷公園の非日常的な光景だったり、ポケモン捕まえてたら外国人に話しかけられて盛り上がったり、同僚とオフィス付近のジム制圧してみたり、同世代とポケモン昔話で盛り上がったり、ゲーム外の体験が楽しさに繋がっている。アプリに完結したサービス設計しがちだけど、(UXの文脈でよく言うような) アプリ外の体験も重要というのが身に沁みた。これらを狙って設計できるようになりたい。

Content is King

色々書いたけど、結局これに尽きると思った。身もふたもないけど、ポケモンっていうコンテンツが最強。

Webサービスもコンテンツが命。時間を書けて設計したUIは器でしかない。そこにのせる料理をいかに良くするか。CGMならいかに良いコンテンツをユーザーに投稿してもらうか。それが重要だよなと改めて思った。

facebook製のReact用エディタフレームワーク draft.js を触ってみた

5月ぐらいにdraft.jsを使って、Markdownエディタを作ってみた。普段技術ネタはBlogに書かないのだけど、まだあまり日本語情報も無いのでメモを公開してみる。 draft.jsはいまも活発に開発が進んでる状況なので、この数ヶ月で古くなってる部分があるかもしれません。

draft.jsとは何か

facebookが作っているReact用のリッチテキストエディタ (WYSIWYG) のフレームワーク。

facebookのnote機能や、メッセンジャーのエディタに使われてるらしく、今年に入ってオープンソースになった。ってことでまだあまり情報が無いが、react本家のfacebookが作ってるのもあり、エコシステムができつつある (後述) 。

draft.jsの特徴

draft.jsはあくまでフレームワークなので、そのままReactコンポーネントとして使えるものでは無い。draft.jsは、素のtextareaではなく、contenteditable属性を使ったdivをベースにする。

contenteditableはブラウザ毎の挙動の違いがあって、扱いが難しい(らしい)が、そこをうまく吸収しつつ、後述するいくつかの概念によってcontenteditable内を統一的に操作できるようなデータ構造を提供するのがdraft.jsの役割。

ということで、学習コストかかるものの、素のtextareaをゴリゴリやるよりは、保守性と拡張性を保った上でエディタが書けると使ってみて感じた。

draft.jsに登場する概念

だいたい https://facebook.github.io/draft-js/docs/api-reference-editor.html あたりにまとまってる。理解があってるかはまだあまり自信がない。

EditorState

エディタそのものの状態を表す。そのものというのは、入力されている内容物の状態はもちろん、キャレットの位置や、反転選択の状態、undo/redo のための変更履歴などを含めてエディタに対するほぼ全ての変更を指す。

ContentState

入力されている内容物の状態と、キャレットの状態を保持する。EditorStateの一部。内容物は、後述する幾つかのContentBlockから構成させる (これをblockMapと呼ぶ)。キャレットの状態は、SelectionStateで構成される。

ContentBlock

基本的にはエディタ内の、1行が1 Blockに相当する。ContentBlockcharacterListという、CharacterMetadataからなる配列を保持する。

CharacterMetadata

元々draft.jsはリッチテキストエディタ用なので、プレビュー欄みたいなのは無くて、例えば文字列をboldにしたらエディタ内で太字にする必要がある。 ここで、boldが太字であるという情報を持つのが、CharacterMetadata

Entity

さっきの例でいうと、太字というのが一つのEntityに相当する。Entityは、mutabilityという属性を持っていて、ここにIMMUTABLEという値をセットすると、その文字列 (Entity) はまとめて削除される。 例えば、メンション補完をして、入力した文字列を、バックスペースで一度に削除するみたいなことができる。

SelectionState

エディタ内のキャレットの状態を指す。

Key / Offset

Keyは、エディタ内のどのブロックにキャレットがいるかを示す。 Offsetは、ブロック内のどの位置にキャレットがいるかを示す。

Anchor / Focus

Anchorはキャレットを打ち込んだ位置。Focusは反転選択した際の終点。これにより、forwardで選択してるのか、backfowardで選択してるのかがわかる。

Modifier

ContentStateを操作するための、function郡。基本的にこれを通して、エディタの内容物に変更を加える。

draft.jsとMarkdown

結論からいうと、draft.jsはまだMarkdownをサポートしていない。

理想的には、リッチテキストエディタで視覚的にサポートされた状態で書いたMarkdownテキストを、Markdown記法でエクスポートされると良さそう (Preview欄が不要になる)。 react-rte というReact Componentがそれをやろうとしているが、実際使うとまだいまいちなとこはあって、もう少しdraft.js側でMarkdownのことを考慮されるとよさそう (計画はあるみたい)

ということで、自分が作ったエディタでは、EditorStateにプレーンテキストを出力させて、それをMarkdownとしてレンダリングするようにしている。そして、Markdownの入力をサポートするためのModifierを自前で書くことにした。

draft.jsのエコシステム

draft.jsをプラガブルに拡張した、draft-js-plugins というものがある。メンション補完や絵文字補完は、これを通して実現できた。

その他にもプラグインや、draft.jsを使ったReact Componentがどんどん出てきてる。有名っぽいのは、 https://github.com/nikgraf/awesome-draft-js にまとまってる。

おわり

draft.jsがリリースされたのが2016年2月末とかなので、まだまだこれからな感じはするけど、勢いがある。職業柄エディタは身近なものなので、つい自分の考えた最強のエディタを作りたくなるけど、実際やってみると改善点が山程あってエディタ沼にはまって出られなくなる。フレームワークに乗っかることで本質的な部分だけに集中して早く沼を抜けられるようになるといいな。

エンジニアが人間中心設計スペシャリストを受けて合格した話

最近、HCD-Net認定人間中心設計スペシャリスト (Certified Human Centerd Design Specialist) というものを受けて、無事合格したのでその事について。

人間中心設計スペシャリストとは

人間中心設計推進機構が実施している専門家認定制度で、その人がHCD (人間中心デザイン) についての実務経験と実績があることを、審査し認定する制度です。

自分は肩書はエンジニアですが、プロダクトマネージャー的な役割をすることが多く、必然的にHCDやサービスデザインのような分野についても業務上考えることが多くあります。実際のところ第三者からみて自分のやってるHCDはどうなんだろうか、という疑問や自信の無さから、この試験を受けてみることにしました。

あくまで業務上の実績で認定されるので、勉強して試験を受ける感じではなく、HCDに特化した超事細かな職務経歴書みたいなものを書いて提出して審査を受けます。 この申請書を書くのがめっちゃしんどい。1ヶ月程度時間をかけて書くのがオススメされてます。自分は色んな締め切りが重なってしまい、24時間でなんとかギリギリ書き上げました…。

何を審査されるのか

f:id:dex1t:20160424193119p:plain

これはHCDやUCDの文脈でよく出てくる、人間中心デザインプロセスをざっくり表した図 (ISO9241-210)です。 計画~調査~企画/設計(デザイン)~評価というのが人間中心デザインの一連の流れになります。(リーンスタートアップの文脈でいうBMLループみたいな)

認定試験では、この各ステップにおいて、必要とされる能力が定義されていて、それを満たす実績をアピールする必要があります。 例えば、計画と調査のステップだと、

  • 調査評価設計能力
    • プロジェクトの目的に応じて、適切な定量/定性調査を設計できるか
  • ユーザー調査実施能力
    • 計画したユーザー調査を適切に実行できるか
  • 定性定量データ分析能力
    • 調査で得たデータを適切に分析できるか
  • 現状のモデル化能力
    • 調査結果をモデル化 (ペルソナだとかカスタマージャーニーマップとか) して周りに伝えられるか

みたいな感じ。これに当てはまる業務上の実績を示して、6つ以上の実績が認められればスペシャリストとして認定されます。 ちなみに、HCDスペシャリストは実務経験2年以上、上位資格のHCD専門家は実務経験5年以上が応募資格として必要です。

設問がよくできてる

HCD自体が ISOで規格化されてるのもあり、それに基づくこの認定試験の設問もよくできています。 HCDにどんな能力が必要なのかが体系建てて定義されているので、設問を見るだけでも結構面白いです。(エクセル方眼紙ですが、問題はここから見れます)

例えば、先に挙げた調査ステップも、設計/実行/評価が明確に区別されています。 ユーザーインタビューをやるにしても、実行 (インタビュー) だけを考えがちですが、設計と評価も同じぐらい重要ですし、実行とはまた違った能力が必要とされます ってのを受けてみて、はー確かになーと改めて思いました。

調査以外にも、サービス設計、情報設計、プロトタイピングなど各フェーズでどんな能力が必要とされるのかが定義されていて、 定義があるからこそ設問に答えてると自分に足りない部分も見えてきます。サービス開発エンジニアやデザイナーの面接とか評価にも参考にできそう。

余談ですが、デザイナーにどんだけ色んな能力求められるんや…!ってのも改めて感じます。 これ全てできる人はなかなか居ないので、足りない部分は自分が埋める精神で、サービス開発におけるデザインを要素分解して考えることの重要さを痛感してます。

その他受けてよかったこと

サービス開発って、サービス自体の指標 (PV/UUとか) と切り離しての評価が受け辛いなと常々感じます。エンジニアリングについての評価はどの会社も知見が溜まってるように見えますが、プロダクト分野の評価はどこも苦労してるように見えます。

実際、丸3年間サービス開発やってきても、自分が成長してるんだかしてないんだか、いまいち自信が持てませんでした。人間中心設計スペシャリストに合格したこと自体は自己満足ですが、第三者からみて一定の実績が認められたのは自信になりました。

今後もデザインとかエンジニアリングとか分野をガンガン越境して、サービス開発をやっていく気持ちです。

確かめながらつくるユーザー体験 #CookpadTechConf

先日、Cookpad TechConf2016という自社カンファレンスに登壇しました。150名以上の方の前で話すのは初めてでした。発表資料とともに、なぜこの話をしたのか、という背景をまとめておこうと思います。

なぜこの話をしたか

昨年5月からスタートアップに出向して、新規サービス立ち上げをやっていて苦労した点を、クックパッドのサービス開発のプラクティスに紐付けて話をしてみました。

出向して以降、社外の人 (業務委託など) と一緒に働く機会が多いのですが、サービス作りに対する考え方や目線の違いによる難しさをすごく感じます。目線が違うこと自体は仕方ない(0→1段階のスタートアップで「考え方が合う人だけと働きたい!」とか言ってられない)ので、違うものはすり合わせていく必要があります。

そこで改めて重要だと思ったのが、ステートメントを定めることです。

結局サービス開発って何をすることなんだ?ってのを考えると、「意思決定を細かく連続的にしていくこと」に尽きると思っています。 どんな体験を提供したいのか、どんな機能をつくるのか、文言はこれで伝わるのか、色はこれでいいのか…などを、正解がない状況下で、決めていく必要があります。

それを目線が違う人たちが、各々の判断でやると、作るべきものから当然ブレる。 デザインレビューのような仕組みによって、ブレを矯正することはできますが、それだけに頼るのは辛い(レビューが毎回大変)

ということで、ステートメントという判断基準を定めて、各々の判断のサポートをし、判断の質を底上げすることが大事なように思います。そして、そのステートメント自体も、あくまで初期仮説なので検証が必要ですよね、って話が今回の発表です。

サービス開発も技術

サービス開発の話をブログで書いたり、社外で話すのは毎回難しいなと感じます。サービスそのものの成功/失敗談は、文脈や状況次第なところが多く、再現性があまり無いからです。他所で聞いた話をそのまま適用しても、うまくいく感じがあんまりしない。なので、今回はなるべく再現性がありそうなプラクティスを話すようにしてみました。

「技術力」というと、コードを綺麗に素早く書く力を想像したり、OSSに貢献していることを想像したり、人によって様々だと思います。僕は、サービス開発の確度やスピードを上げることも、技術の一つだと思っています。

同時にサービス開発は、総合格闘技みたいなものだと思っています。ディレクションとかデザインとかエンジニアリングだとか分野を横断 (越境) して、再現性のあるプラクティスをどれだけ身に着けていくかが技術力をあげることに繋がると思っています。