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

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

なぜこの話をしたか

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

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

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

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

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

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

サービス開発も技術

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

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

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

2015年の振り返り

振り返りを書いてみる。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 顧客の心を捉える製品の創り方を読んだ

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

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

ひさびさのブログ。

少し前だけど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自体に凄く興味が湧いた。

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

Yahoo!プレミアムの解約フロー 2015年夏

ヤフオクに出品する度にYahooプレミアムを契約、出品終わったら即解約ってのを定期的にやってるんですが、 約半年ぶりぐらいに解約したら、いろいろと変化があって面白かったのでメモ。

今季は、解約までに7ページかかりました。

1ページ目: ヤフオク軸での訴求

f:id:dex1t:20150830210143p:plain:w200

ヤフオクに出品できなくなるよ!っていう訴求。 これはヤフオク使ってる人限定なのかな。

2ページ目: Tポイント軸での訴求

f:id:dex1t:20150830210434p:plain:w200

プレミアム会員だとTポイントが増えるチャンスがあるよっていう訴求

3ページ目: コンテンツ軸の訴求

f:id:dex1t:20150830210622p:plain:w200

Gyaoやクーポンなどプレミアムコンテンツがありますよっていう訴求

4ページ目: 機能軸の訴求

f:id:dex1t:20150830210740p:plain:w200

買い物保証や、Yahooボックスの容量アップなど機能的な訴求

5ページ目: 解約理由アンケート

f:id:dex1t:20150830210905p:plain:w200

ここまで行くと訴求は諦め、解約理由のアンケートに。 全部任意なので、入力しなくてもOK。

6ページ目: 解約の最終確認

f:id:dex1t:20150830211041p:plain:w200

ここからはYahooウォレットの管轄。一般的な解約に関する注意事項と確認。

7ページ目: 解約完了(とダメ押しの訴求)

f:id:dex1t:20150830211214p:plain:w200

7ページ目でようやく解約完了!でもダメ押しの訴求も忘れずに。

所感

  • 7ページかかるものの、「次に進む」ボタンは認知しやすく、どのページも同じ位置にある。
    • 解約に手間はかかるが、迷うことは無いので、イライラしない。
    • 2ページ目だけ、「次に進む」が左にあるので、ここだけグレーな感じ。
  • 事業側の解約抑止したいって意図と、デザイナーのユーザビリティは守りたいっていう意図が垣間見えて、その落とし所として勉強になった。

ということで、結構好感を持った。
ユーザーを迷わして解約抑止するのと、ユーザーに価値を伝えて解約抑止するのは全然違う。 そのどちらを選ぶかで、会社のユーザーに対する姿勢が垣間見える気がする。

サービス開発におけるUXデザインを要素分解する

UI/UXデザイナー?

Webサービス開発において、「UI/UXデザイナー」という肩書をよく目にする。なんとなくデザイナーというと、「イラレやフォトショを使う人」をイメージしてしまう。僕もそうだった。

確かにUIは目に見えるため、UIをデザインする上ではイラレやフォトショを使うんだと思う。でもUXは違う。 UIはUXのいち要素でしかなく、UXは目に見えない要素も包含する。

The Elements of UX

次の図は、Adaptive Pathのジェームス・ギャレット氏が2000年頃に提唱したThe Elements of UXというモデル。(オリジナルの図はこちら)

f:id:dex1t:20150823055659p:plain:w400

この図はUXを考える上で、すごく分かりやすい。イラレやフォトショ作業を伴うであろう、ビジュアルデザインやインターフェースデザインは、あくまでUXの表層でしかない。

UXってサービス開発そのものだ

UXは、情報アーキテクチャや、サービスの戦略など、目に見えない部分も含めて構成される。エンジニアリングだってUXに含まれると思うし、カスタマーサポートやコミュニティマネジメントのようなサービス運営面もUXを構成する要素だと思う。

つまり、UXを作り上げる行為は、サービス開発とほぼ同義だと思う。少なくとも、このThe Elements of UXの5要素はサービス開発において必要不可欠だと思う。

デザイナーはみんな超人なのか

じゃあ所謂「UI/UXデザイナー」と呼ばれる人は、これらを全てこなせるスーパーサイヤ人なんだろうか。

グラフィックデザインもできて、UIデザインもできて、インタラクションデザイン、情報アーキテクチャへの理解があり、さらにサービス企画、可能であればフロントエンドのコードも書ける人…。

確かにそういう人も居る。クックパッドにはこういう超人デザイナーが多かった。ただ、それが普通だと思って、どのUI/UXデザイナーにもこれらを求めると、サービス開発は失敗する。と、社外に飛び出してみて気づいた。

考えてみれば当然なんだけど、例えばIA (情報アーキテクチャ) のような抽象的なスキルと、ビジュアルデザインのような目に見えるアウトプットを出すスキルは全く別物。デザイナーのなかで得意不得意があって当たり前。

エンジニアは技術スタック毎に役割が分かりやすい。インフラエンジニアに対して、Swiftを書いてくださいとは誰も言わないだろう。

逆にデザイナーは役割の違いが分かりづらいのはあるなと思う。xxxデザインの違いって、デザインに対する理解がないと分かりづらい。だから、あれもこれもデザイナーに求めるんだと思う。

デザイナーでなくてもUXをデザインできるはず

「UX=デザイナーの領域」と考えると思考停止だと思う。全デザイナーに対して、超人的スキルセットを求める必要がでてくる。

加えて、UXデザインがサービス開発そのものだとすると、「サービス開発エンジニア」と呼ばれる人は何をするのか(ひたすらコードを書く…?)。「Webディレクター」と呼ばれる人は何をするのか(制作進行…?)って話にもなる。

話を、The Elements of UXに戻すと、UXにおいて、ビジュアルデザインはあくまで表層でしかない。ビジュアルで表現する技術がなかったとしても、それはUXデザインができないことにはならないと思う。

つまりエンジニアや、ディレクターだってUXはデザインできるはず。UXを要素分解し、一つ一つのスキルを身につければ、デザイナーの役割の一部を補完することができるはず。 そうして、チーム全体でUXをデザインする、サービス開発することが重要だと思う。

実際やってみてる

今一緒に仕事をしている外部のデザイナーさんは、ビジュアルデザインが得意な人で、逆に抽象レイヤーが苦手な人。自分はこれまでにサービス開発エンジニア兼プロダクトオーナー的な役割をしていた時期があり、コンセプト作りのような抽象レイヤーは経験してきた。

なので、The Elements of UXでいう戦略~構造レイヤーまでは自分が担当し、骨格や表現のレイヤーをデザイナーさんにお願いするような役割分担にしたところ、少し開発がうまく回るようになった。(逆に言えばその前は、機能の要件定義の一部までデザイナーに丸投げしていた…)

ただ、構造レイヤーについては僕も知識や経験が足りないし、可能であれば骨格(情報デザイン)のスキルも付けたい。 ということで、最近はIAを勉強してみてる。

IAシンキング Web制作者・担当者のためのIA思考術

IAシンキング Web制作者・担当者のためのIA思考術

役割分担することによって、抽象レイヤーで考えたことを適切な形で、次のレイヤーを担当する人に共有する必要がある。 例えば、戦略を表現するために、アプリケーション定義ステートメントや、リーンキャンバスみたいなフレームワークを使うんだと思う。

同じ組織にいて、意思疎通がとれる人であれば、少し会話するだけでも共有できるんだろうけど、外部にいる人だとそれもまた難しい…。長くなってきたので、またそれは別途エントリにしたい。

「ピクサー流創造するちから」をサービス開発者視点で振り返る

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

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

  • 作者: エド・キャットムル著,エイミー・ワラス著,石原薫訳
  • 出版社/メーカー: ダイヤモンド社
  • 発売日: 2014/10/03
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (10件) を見る

ピクサー創業者のエド・キャットムルが、創造的な組織を作る上での考えや体験をまとめた本。 同僚のデザイナーがオススメしていて、ずっと気になっていたのだけど、最近やっと読み終えた。

結論から言うと、ここ最近読んだ本のなかで飛び抜けてよかった!

この手の本としては、今年に入ってGoogleのHow Google Worksや、37SignalsのRemoteを読んだ。それぞれ内容は良かったけど、どこか別の世界の話な感じがした。この本もHow Pixar Works的な内容なんだけど、サービス開発者の自分にとっては凄く腑に落ちる部分が多かった。

ピクサーに興味がなかったとしても、自社サービスを作ることを仕事にしてる人なら共感できる部分は多いと思う。 最近Web界隈で流行りの、プロダクトマネージャー論にも重なる部分も多い。

以下メモも兼ねて、個人的に面白かった部分を、サービス開発視点で振り返ってみる。

ピクサーの社史

ピクサー映画は何本か見たことあるけど、この本を読むまではピクサー社についてはまったく知らなかった。 ジョン・ラセターって監督がいて、アップルを追放されたジョブズが創業に関わったって程度の知識で、エド・キャットムルの名前すら知らなかった…。

ルーカススタジオから始まり、ハードウェアベンチャーとして創業したピクサー。ハードウェア事業から、アニメーション事業へのピボット。ジョブズとの出会い、ディズニーとの提携、そして買収。ピクサーの歴史を単に知るだけでもめっちゃ面白い。

創造的組織を作るために、エド・キャットムルがピクサーで実践してきた方法論を、その検証としてディズニーに適用するというスケールのデカさにも笑った。 しかもその結果、ディズニーを再建して、アナ雪が生まれてるんだからすごい…。

不確実性を受け入れる

「不確実性」という言葉は、この本の中で繰り返し触れられていた。映画やアニメ制作はもちろん、Webサービス (特にBtoCの) を作る上では切っても切れない言葉だと思う。

ユーザーが何を求めているのかは、(自分自身がユーザーでない限り)分からないのが大前提であり、この前提のなかでモノを作る以上、何をするにしても不確実性が含まれる。
不確実性に立ち向かうのではなく受け入れて、モノづくりもチームづくりもして行く必要があるなと再認識。

  • 自分にはわからないことがあることを認め、そのための余白を持っているマネージャーこそ優れたマネージャーだと思っている。 (序章 再発見)
  • 方向転換を意思の弱さの表れ、自分を見失ったと認めるのだと考える人は多い。個人的に、自分の考えを改められない人は危険だと思う。スティーブ・ジョブズは、新事実が明るみになるたびにコロコロ気が変わることで有名だったが、彼のことを弱い人間だと言う人を見たことがない。(第8章 変化と偶発性)
  • 変化は避けようがないのだとしたら、変化を止めて自分を守ろうとするか、変化を受け入れてそれを武器に変えるかのどちらかだ。言うまでもないが、私は変化に対応することこそが創造性だと思っている。(第8章 変化と偶発性)

そういえばリーン・スタートアップにも、「スタートアップの定義は、不確実な状況のなかで新しい製品を創りださなければならない組織」っていうのが書いてあった。

Story is King

  • 美術的な技巧を凝らそうと、物語がきちんとさえしていれば、視覚的に洗練されているかどうかなど問題にはならないのだ。(第2章 ピクサー誕生)
  • 「物語が一番偉い (Story is King) 」。(中略)『トイ・ストーリー』を観た人が、映画を作るために駆使したコンピュータ技術ではなく、自分がどう感じたかを語っていたのが誇らしかった。(第4章 ピクサーらしさ)

これも映画だけでなく、サービス開発において、特にユーザー投稿型サービスの場合は Contents is King だと思う。どれだけ技術的に優れていても、どれだけデザイン的に優れていても、それがコンテンツ以上の売りにはならない。

売りになったとしても、一部の界隈だけで、多くのユーザーに受け入れられるサービスであるためには、技術やデザインはコンテンツを引き出すための器であるべきだと思う。
ユーザーが投稿してくれたコンテンツをいかに魅力的に見せるか、いかに投稿しようと思えるような器を作れるか、ここがユーザー投稿型サービスの場合はキモだなと思う。

とはいえ、エンジニアやデザイナーのような仕事をしてると、つい近眼になってしまい目の前のディテールに拘ってしまう。それは全然悪いことじゃない。

重要なのはバランスで、そのために「このサービスは何が価値なんだっけ」ってのを明文化して、いつでも思い出せる状況を作る必要があると思う。そのために、リーンキャンバスだとか、アプリケーション定義ステートメントみたいなフレームワークを活用できるといいんだろうな。

ブレイントラスト

ピクサーではブレイントラストという全社横断組織が、映画の途中成果物を都度レビューしているらしい。ブレイントラストは、監督や脚本家など、ストーリーテリングの素養がある人だけが集まる組織(逆に素養がない、ただ地位があるだけな人は参加できない)。論文の査読みたいなもの。

うちの会社*1でも似たようなことはやっていて、デザイナーを中心にデザイン成果物に対するレビューをGitHubのIssue上で行っている。エンジニア同士のコードレビューもブレイントラストと言える。

  • 監督は、提案や助言に従う必要はない。会議後、フィードバックにどのように対処するかは監督に任されている。 (第5章 正直さと率直さ)

このスタンスはめっちゃ重要だと思う。ここが欠けていると、レビュアーの顔色を伺って、折衷案的に指摘を反映する、その結果中途半端な成果物になる、みたいなことが起きがち。それならレビューとかやらないほうがいい。民主主義的にプロダクト作るのは最悪。

自分が新卒1年目だったりすると、先輩の意見は絶対に取り入れなきゃいけないんじゃないか、みたいな気持ちになる(実際なっていた)。 だからこそ、ピクサーはこういうスタンスを明文化しているのかな。

  • グッド・ノート (良い指摘) は何よりも具体的である必要がある。「身悶えするほど退屈」はグッドノートとは言えない。(第5章 正直さと率直さ)

これもレビュイー(監督)が指摘を取捨選択する上で重要だなーと思った。具体的指摘ができなかったとしても、「これは個人の感想ですが、退屈です」みたいに「個人の感想」だということを付け加えてほしい。 指摘の意図を推し量る(日本人あるある)のは、とにかく時間の無駄だと思う。

フィードバックへの対処はレビュイーに任されてるのだから、意図さえわかれば個人の感想は聞き流せばいい。逆にレビュアーには、意図さえ明かせば個人の感想でもいいから指摘してね、っていう雰囲気を作るのも必要だと思う。 そうでもないと、なかなか活発なレビューってできないな、ってのが実際やっていて思うところ。

あとはブレイントラストに関連して、

  • 人に見せる前に完璧にしようとしないこと。早く頻繁に人に見せること。途中段階はみれたものではないが、だんだん見られるようになる。そうあるべきだ。

これもめっちゃ同意。頭の中身をとにかく外化するのは、不確実性を受け入れる上では大事だな、と最近よく思う。慣れないと怖いけど。

躊躇なく外化ができ、具体的な指摘をし合えるチーム作りが重要だし難しい。だからこそ、エド・キャットムルはこの本の中で、採用の重要性と、「アイデアより人」ってのを繰り返し言ってるんだろうな。

野獣の扱い

本の中で、映画制作に直接関係しない部門や、役割を野獣と呼んでいる。悪い意味ではなく、野獣は会社にとって必要不可欠だけど、扱いは注意すべきとされていた。

  • どの部門も独自の理屈に基づいて運営され、商品の品質に対する責任を持たないか、自分たちがどのような影響を及ぼしているかをえてして理解していない。それは彼らにとって、自分の問題ではないのだ。各部門にはそれぞれ目標と期待があり、自らの食欲に応じて活動している。
  • それぞれの野獣には共通点がある。会社の中でも最も計画的な人々が野獣係を務めていることだ。上司の期待や、与えられた予算と日程どおりに物事を進めることにこだわる人々だ。そうした人々やその利害が力を増し、それに対向する、新しいアイデアを守る抵抗勢力が弱いと歯車が狂い始める。野獣の独壇場になる。(第7章 貪欲な野獣と醜い赤ん坊)

ここの部分はまだ咀嚼しきれてないけど、ある目的に対する、いち手段を役割とする人、その人が力を持ちすぎると野獣になってしまうってことかな。

例えば、ディレクターはスケジュール通りに事を進めることが、役割の1つだったりする。 でもそれは(受託ではなく)自社のサービス開発にとって目的ではなくてあくまで手段。

サービス価値そのものが間違ってたり、十分に検証されていなかったりすると、それをスケジュール通りに進めたとしても、誰も欲しがらないモノが出来上がるだけ。でもオンスケで進んでいることは良いことに見えてしまう。それが野獣にとっての餌ってことかな。

エンジニアリングだって、サービス開発の一手段であるから、エンジニアが力を持ちすぎる場合も同じだと思う。 例えば、エッジな技術を試すことが良いことのように見え、サービス開発の本筋とは外れることばかりに時間を費やす的な。

だれしもが野獣になり得る。だからチームのマネージャーは野獣に常に目を光らせる必要があるんだろうな。

メンタルモデル

サービス開発はユーザに使ってもらってこそ、やり甲斐や楽しさが生まれると思う。 個人的に、プロダクトマネージャー兼エンジニアのような立ち位置でサービス開発に関わることが多いが、リリース前のサービス開発は精神的に辛い。

リリース前だと、作っているモノに当然ユーザは居なくて、今作っているものが使ってもらえる保証は全くない。これが不確実性。 リリースしてもゴールではなくて、最高を目指して延々とBMLループを回し続いてる世界観…正直しんどい。

それでもWebの世界だと、数ヶ月で新サービスを立ち上げることがザラだと思うので、辛い時期も数ヶ月で済む。 ピクサーのような長編アニメ映画は3, 4年かかるのが普通らしい。そんな長期間、未リリースのプロダクトを、自分たちを信じて作り続けるなんて、監督はどんだけしんどいんだろう…。

この本では監督それぞれが、それを乗り越えるためのメンタルモデルを持つべきと言っている。 映画作りを、航海に例える人、迷路に例える人、車の運転に例える人、それぞれが自分なりのメンタルモデルを持って、不確実性を受け入れる例が紹介されていた。

メンタルモデルに対する言及ではなかったけど、個人的にはこの本の中にあった、次の言葉がメンタルモデルとしてしっくりきた。

  • 道は選ぶだけではだめで、進まなければ意味がない。だがそうすれば、歩き始める前には見られなかった景色が見えてくる。見たくないこと、惑わされることもあるかもしれないが、よく使う言い方をすると、「その近所を探検する」ことができる。いろいろ考え、その道を選んだことは無駄にはならない。見た景色が求めていたものと違ったとしても、そこで自然に得たアイデアはきっと今後役立つ。近所でいいものを見つけたが、今抱えている課題には使えないと思ったら、覚えておいて次回に使えばいい。

しっくりするメンタルモデルを見つけられれば、辛い時期も乗り越えられる気がする。

あわせて読みたい

たまたま、このピクサー本を読む前に、Rebuildの影響でSHIROBAKOを見て、その後にコンテンツの秘密を読んでいた。 意図したわけじゃないけど、この順番でアニメーション業界を知ることができたのは良かった気がする。
コンテンツの秘密は、川上さんがコンテンツを創造することについて、論理的にまとめた論文みたいな感じで良書。

アニメ業界のブラック体質だとか、役割を細かく分けた分業制 (海外は違いそうだけど) については何だかな、と思う一方で、 よくソフトウェア開発って建築に例えられたりするけど、サービス開発に限ってはアニメ制作のほうが近しい感じがする。 サービス開発も、アニメ制作のチーム作りや役割分担を、真似できると良い部分もあるんじゃないかなってのを、ふわっと最近思ってる。

おわり

長文になってしまったけど、まだまだ書き足りないぐらい面白かったです。