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

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として就職する方法~ をまず読むといいのかなと思った。この本はプロダクトマネージャーを実際やっていたり、これからやる人に凄くオススメできそう。

デザインイノベーションの振り子を読んだ

Book Design Product

ひさびさのブログ。

少し前だけどtakram design engineeringのデザイン・イノベーションの振り子を読んだ。 内容的には企業のPR本だけど、普段サービス作りをエンジニア(もしくはPM)という立場で関わる自分が、最近もやもや考えていたことがバシッと言語化されていて面白かった。

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

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

デザインエンジニア

エンジニアリングとデザインの両方の専門的知識や経験を経て、2つの専門性を経た状態を指すらしい。デザインエンジニアが求められるのは、前例がなく過去の経験が生きづらい0→1を生み出すような環境。まさにサービス開発って、前例が当てにならず不確実な状況下であることが多い。(リーンスタートアップもこの環境下での方法論だし)

またBusiness、Technology、Creativity (Design) の三要素を調和的につくり上げることが、新しい物事を起こす上で重要とされていた。BTCの調和がとれた状態に対して、デザインエンジニアは特にTechnologyとCreativityから担っていく存在らしい。

越境と複眼性

takramのデザインエンジニアは、ハードウェア (Tangible) とソフトウェア (Intangible) 、デザインとエンジニアリングの4象限を、自由に行き来するように経験を積んでいくらしい。最初から全てができる人は居ないので、ソフトウェアに専門性を持つエンジニアであれば、その隣の領域であるソフトウェアデザインの経験を積む。そうすことでソフトウェア領域でのデザインエンジニアとなる。

ここでいう専門性って、どのレベルを指すんだろうってのは疑問。複数の分野をこなすと、どうしても浅く広くになりがち。まさに今の自分がそうだけど、器用貧乏になってしまう。この本の中では、各分野の専門家と専門用語を使って対等に会話できる状態と軽くふれてあった。

話を本の内容に戻すと、複数の専門性を持つことで、ある分野から別の分野に越境する感覚が身につく。この越境を繰り返すことで、物事を立体的に捉えられる。この本のなかではそれを複眼性とも呼んでいた。

技術的に難しい問題でも、実はデザイン上の工夫によって問題が簡易化できる感覚は、サービス開発をやっていてよく感じる。逆に、技術的な可能性を知らないと、デザイン自体に制約ができてしまったり、または現実味の無いものをデザインしてしまったりするのも、あるあるだと思う。ここでのデザインは、単にUIデザインもそうだし、ユーザー体験の設計とか、サービス企画とかでもそう。

デザインとエンジニアリングだけの話ではなく、どんな分野でもいいから越境性を持つのは大事だと思う。Webサービスでいえば、マーケティングやコミュニティマネジメントも重要な要素だし、サポートや営業、編集だって関わりのある領域。そして一度越境を体験すると、別の分野に越境することも苦ではなくなる。

越境性を持つことで、問題を立体的に捉えて、かつ問題を変に単純化せずに進められるので、重要な情報が抜け落ちることもない。そして越境を何度も繰り返すことを、振り子思考とtakramでは呼んでるらしい。 サービスを作る上では、デザインとエンジニアリングは欠かせないし、密接に関わる分野なので、この2つを振り子思考することはやっぱり重要だよなと再認識した。

超越性

越境が水平方向なら、超越は垂直に視点を動かす感覚。ある問題に対して、虫の目(現場感覚)だけで捉えるのではなく、鳥の目(経営感覚)でも捉えることを、この本では超越性と呼んでいた。

ちょっと文章にするのが難しいけど、「それやる必要あるんだっけ?」っていうそもそもの目的から考えましょうっていう話だと自分は感じた。サービスを作っていると、考えても考えてもいい解決策が浮かばない「どん詰まり」に陥る感覚がよくある。そしてそれが続くと最悪「誰も欲しがらないものを作っている」状態になると思う。そんなときに、一歩目線をひいて考えてみて、問題を再定義(リフレーミング)してみる。すると、そもそも問題と考えていたことは問題ではなかったと分かる。

これもサービス開発やってて、あるあるだなーと思った。虫の目と鳥の目を意識的に使い分けていく。それがtakramが考える超越性なのかなと感じた。

越境と超越のタイミング

ここからはこの本を読んで自分がもやもや考えていたこと。

越境はある問題を解く上で、短いスパンで自由に行き来するのが良いと思う。逆に、ある期間は「デザイン」をする期間、次は「エンジニアリング」をする期間のように区切ってしまうのは、手戻りが大きくなる原因になると思う。まさにウォーターフォール型の開発がそれなのかな。短いスパンで越境を繰り返し、むしろいまデザインをしているのか、エンジニアリングをしているのか、それすら区別つかない状態が理想なんだろう。

ただ逆に、超越をするタイミングは注意したほうがいいと思った。越境が問題を解決する方法なら、超越は問題を定義する方法だと思う。これを短いスパンで繰り返す、特に複数人が関わるプロジェクトでやると迷走の原因になると思う。

Inspired: 顧客の心を捉える製品の創り方 のなかで、「何を作るべきかを決める」時期と、「決めたものをうまく作る」時期は、分けたほうが良いという話があったが、これと同じなのかなと思う。自由に行き来するのか、時間的な制約を作るのか、この違いは大きそう。

ただtakramでは、ストーリーウィービングと呼ばれる手法として、むしろこの具体と抽象の行き来を自由にすることを推奨しているみたい。takramという組織全体が、越境性と超越性を持っているからこそできる技なのかなと感じた。個人でやるのはまだしも、組織全体でそれをやれるのは凄いな。。。

おわり

その他にもプロトタイピングに対するtakramの考え方や、プロダクト・リフレーミング、ストーリーウィービングと呼ばれる手法、それらを実際のクライアントワークで適用した事例がでてきて面白い本でした。takram自体に凄く興味が湧いた。

分量的にさくっと読めるので、モノづくりに関わる人にはおすすめしたいです。