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

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

Observation Product

いま携わっているプロダクト内で、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のサービス設計的な所感

Observation Diary

ポケモン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 を触ってみた

Tech

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

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

Design

最近、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

Presentation Design Product

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

なぜこの話をしたか

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

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

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

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

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

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

サービス開発も技術

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

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

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

2015年の振り返り

Diary

振り返りを書いてみる。2015年は何かと難しい年だった。

仕事

社会人3年目。よく3年目の壁とかなんとか言うけど、確かにめちゃめちゃ悩んだ1年だった。 年明けに本体サービスのデザイン部門に異動し、5月に社外のスタートアップに出向した。

デザイン部門に異動したことも、社外に出向したことも後悔していない。どれも良い経験になった。またその過程で、色んな人から色んなお誘いをいただいて、人が環境を変える上でタイミングって重要な要素なんだなあと思った。

以前の環境が居心地が良すぎただけに、外に出たことで失うものが予想外にあった。ただ、得るものの質を変えたことで、成長の角度が上向いたのは良かった。いまのところは、出向したことでより成長できたと自信を持って言える。ただその過程では苦しかった記憶がほとんどだ。 (追記: イトイ新聞の対談記事にあったコンフォートゾーンの話に近い感覚だな、って思った)

苦しかったけど、自分の頭で考える機会が格段に増えた。特にサービス開発プロセスそのものについて考えることが増え、理解が深まった。エンジニアとしても、インフラからWebフロントエンドまで、浅く広くではあるけど、新しい技術的経験を多く積めた。

今年は苦しんで種を撒いた年。来年はそれを数値結果に結び付けたい。プロダクトでお金を稼ぐのが目標。

読書スピードが遅い自分としては結構量を読めた。良かったのは以下。最初の3冊は、ブログも書いた。 このなかでも、ピクサー本はダントツでよかったな。

ピクサー流 創造するちから―小さな可能性から、大きな価値を生み出す方法

Inspired: 顧客の心を捉える製品の創り方

『takram design engineering|デザイン・イノベーションの振り子』 (現代建築家コンセプト・シリーズ18)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

コンテンツの秘密―ぼくがジブリで考えたこと (NHK出版新書 458)

なるほどデザイン〈目で見て楽しむ新しいデザインの本。〉

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

デザイン

色々思うところがあって、狭い意味でも広い意味でもデザインのスキルを身に着けたいと思って、UXDの勉強会にいくつか行ってみたり、後輩と一緒にIAの勉強会をしてみたり、本社のデザイナーに相談しつつWebデザインを自分でやってみたりした。

表層に近いデザインほど、やったことがないので新鮮で楽しい。アウトプットとしては、会社のコーポレートサイトを一人で作った。Sketchのプラグインを書いてみたりもした。

やってみて思ったのは、ビジュアルのデザインも自分でできるようになると、モノ作りが不可逆ではなくなる。これまでモノ作りのどこか一部は、他の人にお願いする必要があった。ただ自分で一貫してできると、デザインとエンジニアリングを行き来しながら試行錯誤がいくらでもできる。仕事として何かデザインができるわけじゃないけど、この感覚が得られたのは良かったなと思う。来年も続けたい。

映画

出向して以降、1人の時間が増えたこともあり、モチベーション維持が難しくなった。その改善策として、レイトショーを1人でよく見に行くことが増えた。結構効果あるので、来年も続けたい。

音楽

今年もフェスやライブにそこそこ行った。フェスはViva La Rock、Metrock、Rock In Japan、Count Down Japanに行った。来年はフジロックに行ってみたい。

コーヒー

家で仕事することが増えたので、自分でコーヒーを淹れるようになった。毎日のささやかな楽しみ。

引っ越し

オフィスが変わったので、恵比寿から学芸大に引っ越した。今年一番良かったことかもしれない。 美味しいパン屋やカフェ、深夜までやってるラーメン屋が多いのが最高。東横線も便利で最高。

その他プライベート

秋以降、色々あって落ち込んだ。ここには書かないけど。こっちはどうしたら良いのか分からず、難しい。相変わらずワーカホリックで仕事ばっかりしてるけど、それは別に良いかなと思ってる。あとは周りに結婚が増えてきたのは、ついにこの波が来たかという感じで面白い。

改善したいこと

相変わらず運動をろくにしてない。まあ別にいいかなと思ってるけど、身体に不調な箇所が増えてきた。とりあえず年明け病院いこ。

まとめ

環境を変えたことで、仕事もライフスタイルも変化が多かった。仕事面ではサービス開発者として成長したと思うけど、何か結果を残せたわけではない。来年は目に見える結果に結び付けたい。

Inspired 顧客の心を捉える製品の創り方を読んだ

Book Design Product

顧客の心を捉えるためのサービス開発についての本。特にサービス開発における、プロダクトマネージャー (PM) の役割について掘り下げられている。

自分は普段PM兼エンジニアをすることが多いので、PMの役割そのものよりも、他の役割を持つ人(特にデザイナー)との関わり方について、なるほどなと思うところが多かった。 あとこの本は1→100の成長フェーズでの話が多く、自分自身は0→1の事業立ち上げフェーズにいま居るのもあり、その温度感の違いから、この本を読んでいて刺さる部分が他の人と違うかもしれない。

結構前に読んだので、Kindleに線を引いたところから拾ってメモ。

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

プロダクトマネージャーの仕事とは何なのか

この本のなかで言い回しを変えつつ繰り返し述べられてるけど、冒頭で出てくる以下の定義に収まると思う。

プロダクトマネージャーの仕事は、価値があって、使いやすくて、実現可能という目的を満たす上で必要最小限の(余計なものが一切そぎ落とされて洗練された)製品を特定することである。これによって、製品化までの時間と製品の複雑さを最小限にするのである。

この定義のもとで、製品の市場性を評価することと、開発すべき製品を定義することがプロダクトマネージャーの役割になる。 ただの仕様定義ではなく、「価値があって使いやすくて実現可能な製品の、必要最小限の仕様」という部分が大事だと思う。ここに全力を尽くすのがPMってことなんだろうな。

機能を足すことは簡単でも、削ぎ落とすことって難しい。必要最小限の機能で、製品の価値を最大化することが大切だな(そこが難しいし面白い)、と改めて思った。

サービス開発における役割の棲み分け

この本の中で述べられていることをざっくりまとめると以下のような感じだった。職種ではなく、あくまで役割なので、一人の人間が複数の役割を兼ねることもありえる。よほど潤沢に人が居ない限りは、何かしら兼任するのがほとんどだろうなあ。

  • プロダクトマネージャー
    • 何を開発すべきなのか、製品を特定することに責任を持つ
  • プロジェクトマネージャー
    • プロジェクトのスケジュールや進捗管理に責任を持つ
    • プロジェクトが大きくなると専任者が必要になる
  • プロダクトマーケティング
    • 製品を世界中に知らしめることに責任を持つ
    • プロダクトマネジメントとの兼務になることが多いが、この2つの役割には別の技能が必要で、本当は兼務するのは難しい。
  • エンジニア
    • 製品を正しく作り上げることに責任を持つ
  • (UX) デザイナー
    • 要求仕様とデザインを、ユーザーのニーズに合うように調和させることに責任を持つ
    • 他の役割以上に、プロダクトマネージャーとの協力が必要
    • UXデザインを細分化して、それぞれに担当者をつけることもある (後述)

プロダクトマネジメントとデザイン

この本でも明言されてるが、サービス開発においてユーザー体験をデザインすることは必要不可欠だし、それこそがサービス開発そのものだと思う。なので、プロダクトマネージャーの責任である「製品を見つけ出し定義する」を果たす上で、(UX) デザイナーとの協同が必要不可欠になると書かれていた。

いい製品にするには、優れたユーザーエクスペリエンスが必要なのである。そして、優れたユーザーエクスペリエンスを実現するには、プロダクトマネジメントとユーザーエクスペリエンスデザインがしっかりかみ合っていなければならないのである。

本の中では、UXデザインをさらに細分化して、以下の4つの役割が重要とされていた。

  • インタラクションデザイン
  • ビジュアルデザイン
  • ラピッドプロトタイピング
  • ユーザビリティテスト

大規模製品の場合は、このそれぞれに専任の担当者を置くのが必須と書かれていた。ただ、実際のところそんな潤沢なリソースがあるプロジェクトとは無縁だ。。。

たぶん本当に言いたいのは、専任の担当者が必要になるぐらい、同じ「デザイン」でもそれぞれ全く違うスキルが必要になる、というところだと思う。
そして、本の終盤には以下のように書かれていた。

インタラクションデザインとビジュアルデザインはまったく違う技量が要求される分野である。サイトを使いやすくて魅力あるものにするためには、デザインチームに両方のスキルが必要だ。両方のデザインをこなせるデザイナーがいてくれるという、ものすごく幸運なチームもないことはない。でも多くの場合、「デザイナー」と称する人を雇ったからどっちもできるはずだ、と期待してしまうだけで、実は両方共できるわけではないのだ。

ちょうど同じような趣旨のエントリを前に書いたが、やっぱそうだよねー…と超同意。前述の4つの役割を全てこなせる神みたいな人は、めったに居ない。かといって、専任の人を置く余裕もスタートアップには無い。この本には、ビジュアルデザインやユーザビリティテストのような(重要だけど)比較的外注しやすい部分については、外注するのもありだと書かれていた。

事業立ち上げフェーズにいる他のスタートアップの人たちが、実際ここをどうしているのかは凄く気になるな。。。ちなみに自分自身は、自分でUXDのスキルを勉強し、この役割を兼ねるという選択肢を取っている最中。

製品を見つけ出し定義することと、正しく作りあげること

ソフトウェア製品を開発するプロジェクトは、まったく別々の2つの段階に分けることができる。作るべきものを決める(正しい製品を定義する)段階と、それを作る(正しくその製品を作り上げる)段階である。

ここがこの本を読んでいて、一番はっとした部分かもしれない。この本では、この2つの段階を明確に分けるべきと書かれていた。

多くの製品開発チームはこの頭の切り替えができていない。できたとしても、切り替えるのが遅すぎるのだ。 (中略) 結果として、プロジェクトは「かき回される」のである。

あるあるすぎる…。自分がプロダクトマネージャー兼エンジニアとして、企画と開発を兼ねてしまっているのもあり、ついこの切り替えを忘れてしまう。その結果、製品を定義することに集中すべきなのに、いつの間にか作り上げること(エンジニアリング)だけに集中してしまうことがよくある。

発案力(売れる製品のアイデアを発案するためのスキル)と実行力(アイデアを実際に顧客の手元に届けることを実現するためのスキル)の両方を高めることは、絶対に必要である。

エンジニアとして後者については経験を積んできているけど、プロダクトマネージャーとして前者についてはまだまだ経験が足りない。前者の経験を集中的に積む期間を作りたいなと、この本を読んで思うようになった。

製品理念を決める

製品理念とは、製品開発のための一連の原則を定めたもので、両立させるのが難しいものがうまく折り合うところを見極めて何を優先させるか決めるときに大きな拠り所となる。製品理念は、信念や目的を社内の人たちに宣言するものである。

Amazonが製品開発の際には、プレスリリースを最初に書くという話は有名だけど、プロダクト定義ステートメントはサービス開発にとって重要だと改めて思った。なぜ重要なのかについては、この本の中でも色々と語られているが、個人的には以下がポイントなのかなと思う。

製品開発チーム内で意見が大きく食い違うのは、事実関係の捉え方が食い違っているのではなくて、製品化の目標についての解釈や、それぞれの目標の優先順位の付け方が、メンバーの間でまちまちであることが原因になっている。

受託開発とは違って、サービス開発は何を作ったらいいのか正解が存在しない (ユーザーは何が欲しいか自分では分からない) ため、常に不確実性を含んだ状況下で仕事が進む。なので、企画にしろエンジニアリングにしろデザインにしろ、常に細かい意思決定が連続する。 というのがサービス開発の一番難しいところだと思っている。0→1のフェーズならなおさら。

その中で、チームで仕事をする以上、チームメンバーそれぞれがその意思決定をする必要がある。そうすると先に引用したとおり、製品の目標についての解釈や、優先順位の付け方がチーム内で統一できている必要があるんだよなーと再認識した。

これをするためには、ただステートメントを書くだけではなくて、それをメンバーに浸透させるところもセットになる(なかなか難しい…)。

おわり

このエントリでは取り上げなかったが、この本はその他にも以下のようなトピックが書かれていた。

  • 製品の市場性評価
  • 仕様定義書としてのハイファイプロトタイプ
  • ペルソナやユーザビリティテストなどデザイン思考について
  • 見積もりについて

「プロダクトマネージャーとは?」みたいな話をざっくり知るには、世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~ をまず読むといいのかなと思った。この本はプロダクトマネージャーを実際やっていたり、これからやる人に凄くオススメできそう。