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

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

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

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

  • 作者: エド・キャットムル著,エイミー・ワラス著,石原薫訳
  • 出版社/メーカー: ダイヤモンド社
  • 発売日: 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を見て、その後にコンテンツの秘密を読んでいた。 意図したわけじゃないけど、この順番でアニメーション業界を知ることができたのは良かった気がする。
コンテンツの秘密は、川上さんがコンテンツを創造することについて、論理的にまとめた論文みたいな感じで良書。

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

おわり

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