「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」社内プロジェクトマネジメント勉強会第1回を開催しました!

リチャード 伊真岡 blog

「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」社内プロジェクトマネジメント勉強会第1回を開催しました!

twitter:RichardImaokaJP

こんにちは、リチャード 伊真岡です。私が勤務しているマーベリック株式会社で行ったプロジェクトマネジメント勉強会第1回の内容について書き起こします。この勉強会は営業、営業企画、インフラエンジニア、エンジニアリング・マネージャーなど少人数ですが技術者と非技術者が参加したにぎやかな会でした。

社内の有志メンバーで業務時間外に行い、内容は私が準備し、また業務機密を一切含まない内容なので私の個人ブログに掲載しています。

以下発表内容です

どうも、今日の発表は15分という短い時間でリチャードがITプロジェクトマネジメントの本流をおさえつつも、他ではあまり聞けない内容を紹介します。面白いと思いますよ！面白くないと学ぼうという気にならないですからね！全5回のシリーズでお届けする予定で、今日は記念すべき第1回目、テーマはこれです。

ディズニーアニメ映画の桁違いな「制作やり直し」

以下の表はディズニー映画の中でもアニメ映画の興行収入を並べたもので、興行収入1000億円を越えたものです。

タイトル 興行収入 (1ドル=100円) 公開年
アナと雪の女王2 1431億円 2019年
アナと雪の女王 1279億円 2013年
インクレディブル・ファミリー 1242億円 2018年
トイ・ストーリー3 1063億円 2010年
トイ・ストーリー4 1053億円 2019年
ファインディング・ドリー 1028億円 2016年
ズートピア 1023億円 2016年

出典: Wikipedia - 世界歴代興行収入上位の映画一覧

そして、今日注目したいのは一番下の… ズートピア！！ まず、こちらのブログから引用しますが、

『ズートピア』は5年の歳月をかけて制作された。と、聞くと「さすがは天下のディズニー。5年もかけてじっくり… (中略) … …実際はそんな単純な話ではない。ズートピアの辿った道程は一言でいえば、紆余曲折。それも最終カーブが殺人ヘアピンの難産だった。 『ズートピア』の制作史、および『ズートピア』のテーマは「差別」であるのか？

ズートピア、制作時期は以下のようになっています。

『ズートピア』の製作時期はざっくり三つに分けられる。

  • 初期、立ち上げからサベージというウサギを主人公にしたスパイ映画をハワードが構想していた時期（2011~12年?）
  • 中期、『ズートピア』のアイディアに転換して、ニックを主人公にストーリーを練っていた時期（2012~2014年11月）
  • 後期、主人公をニックからジュディへと変更し、今の『ズートピア』が完成するまでの時期（2014年11月〜2015年10月）

注目してもらいたいのは、この3つの時期全て主人公が違うことです。もちろん映画の主人公が違うとなれば根本から作り直すレベルで、しかも3つに分けたうちの最後の後期は1年弱しかありません。

1年弱で映画作り直しって、これがどれくらい大変かちょっと想像してもらうためにこちらにツイートを御覧ください。ピクサー展という六本木ヒルズ森美術館で行われた展示に関するツイートの紹介です。

これなにが吐き気をもよおすか説明しますね。緑色の太い矢印でスタート…からレンダリングまで9工程あります。そして内側の細い矢印見えます？見えますか？細い矢印を逆にたどるとこれ手戻りなんです。例えば最終工程のレンダリングまでいって満足できないと、1つ前のライティング工程に戻る、あるいは2つ前のシミュレーション工程に戻る、ひどいときは最初から2番めのモデリングまで戻ることもあるっていう図です。モデリングまで戻ると途中の全行程やり直し、吐き気がしてきましたね。(笑)

2つ目の画像は「このイメージをレンダリングするのに33時間かかりました」ってリテイク1回でこれだけ消費するわけです。それもレンダリング工程だけで。他の工程含めるとリテイク1回でどれだけ時間食うのか考えたくもないですよね。吐き気が強くなってきました。(笑)

リテイク1回だけでこの大変さなのに、何度も何度もリテイクを重ねて、完成間際の公開前1年を切った段階でズートピアは根底からひっくりかえったんですよ。主人公差し替えてつくりなおしです。先程のブログからもう一度引用しますが、

本来なら一からジュディの物語を組み立てなければいけない。… (中略) … 「普通なら二年かけてやらなきゃいけないことを、僕たちは一年でやった」とはムーアの言だが、監督を二倍に増やしたからと作業期間を半分にカットできるとは、簡単な算術なようでいて、そうとうトチ狂っている。 『ズートピア』の制作史、および『ズートピア』のテーマは「差別」であるのか？

これがどれくらいの規模の話かと言うと

『ズートピア』…は、制作費の1億5000万ドル(150億円) Wikipedia - ズートピア

制作期間5年、150億円のプロジェクトをラスト1年未満でひっくり返す度胸って想像できます？たとえばズートピアの町並みのシーン、ほんの数分間だけのシーン作るだけで550人の人手がかかったんです。

観客の方に「ズートピアってこういう場所なんだ！」と序盤で理解してもらうために、…大都市ズートピアへ向かうシーンには特に力を入れました。…550人のスタッフが９ヶ月がかりで作っているんです。 animeTimes - 「子どもが大人を連れて行くべき映画」と評判!?　ディズニー映画『ズートピア』共同監督＆プロデューサーが語る、リアリティーへのこだわりがものすごい

映画全体で関わった人数は1000人は超えるんでしょうね。

主人公差し替えの時点で、当然脚本も完全に書き直しで、脚本書いてる最中に何もかも同時並行ですすめるんですけど、そもそも脚本がないから何を作るか伝えられなくて、そんな中1000人、もしかするとそれよりはるかに沢山の人が関わったかもしれないプロジェクトの舵取りとコミュニケーションをする大変さ想像できます？

これ、ズートピアだけが特殊なんじゃなくて、アナと雪の女王でも似たようなことが起こってます。

「その当時は…エルサは悪役だったの」と驚きの事実を明かした。… (中略) … 楽曲「Let It Go」を含めたミュージカルの構成について…「その共感を描いた曲からエルサが悪役ではなくなり、エルサのキャラクターも改稿することになったの。つまり、あの曲が全てを変えてしまったわけ」と語った。 シネマトゥデイ - 『アナと雪の女王』の脚本兼監督を直撃、「Let It Go」がストーリーを変えた！

これはアナ雪の脚本件監督ジェニファー・リーさんのインタビューなんですが、最初の筋書きにしっくり来なくて、世界観を変えようと思ってテーマ曲をつくりなおしたら、それがピッタリハマって全部作り直したらしいですね。アナ雪が好きな人達の間では有名な話です。

ピクサーの映画作りについてはピクサー創業社長で、コンピュータサイエンス界のレジェンドでもあるエド・キャットマル博士が本を書いています。

そのなかで「できるだけ早く失敗しよう」とか「カールじいさんの紆余曲折」という節をさらっと書いてるんですけど、失敗したら数百億円規模の損失、1000人を超えるだろう人数が関わるプロジェクトを頻繁にやり直すの、すごいですよね。カールじいさんも3回作り直したそうです。

ゲームでも似たような状況が起きている、映画産業だけではない

スマホゲーム市場は年々拡大していて、今では1兆円を超える産業だという統計もあるようです。

統計の裏取りはしていませんが、市場が拡大し大規模タイトルが増えているのは間違いないようで、以下引用したセガ社員のインタビューからもそれがうかがえます。

市場は成熟してきていると感じています。既存タイトルのダウンロード数は伸びていないですし… (中略) … もうひとつ顕著なのが、開発費の高騰です。初期開発の費用だけではなくマーケティング費用、運営開発の費用、このあたりを足すと、国内だけで初年度15億円 Social Game Info -【年始企画】「低コストかつ迅速な海外展開を」…昨年複数のヒット作を生み出したセガゲームスが次に見据えるのは “世界に通用するタイトル”の創出

こちらはかえるDさんというゲーム・ディレクターのnoteからの引用です。

ゲーム開発の抱える一番の難点はここだ。面白くするためには、何度も作り直しをしないといけないけど、これを行いすぎるとあなたも含めたチームが不安定になり、プロジェクトが崩壊する。 予定通り開発が進んだからと言って面白くなるわけではないし、経営側が不安になられて、煮えている鍋の鍋蓋を高速で開けられるようになっても困る。 note - 良いゲームを作るためのディレクターの戦い。面白さの探索と不安のトレードオフ かえるD

ゲームの世界でも、ディズニー映画で見たように作り直しをしないと消費者がハマるほど面白い品質のものは作れなくなっている。 それは昔からそうだったのかもしれませんが、特に近年はゲーム開発の大規模化にともなって作り直しのコストは膨れ上がっているのではないかと思います。

別の例を出してみよう。それはコンシュマーの大作RPGだった。有名ディレクターが作っており、3年ほどかけて面白いものが出来たそうだ。終盤にディレクターは通しでプレイをして、ちょっとプレイ時間が長すぎるから、町を一つ消したそうだ。 その町は、3年間それを作り続けた人がいた。

この例もすごいですよね。自分がゲームのディレクターだったとして、3年間頑張って町を作り続けた人に向かって「お前の町、いらなくなったから」って開発の終盤で言えますか？

かえるDさんのnoteは非常に面白いのでぜひゲーム作成に興味のある方はこの発表の後読んでみて下さい。今なら有料版の非常に興味深いnoteもあります。

そしてソフトウェア開発産業一般についての状況

さてディズニー映画、ゲーム市場と見てきましたが、我々が戦っているソフトウェア開発産業一般についてはどうでしょう？

ソフトウェア産業で近年盛り上がりが激しいと言われている分野の1つにSaas - Software as a Service、サブスクリプション型課金を典型的なサービス提供形態とするものがあります。

日本のSaaS市場は年平均成長率約12％の勢いで急成長しており、2023年には約8,200億円へ拡大する見込みです BOXIL - SaaS業界レポート2019販売開始 - 国内市場は2023年8,200億円規模へ

盛り上がっているSaaS市場ですが、カオスマップを見るとこのような感じ。数が多すぎて覚えるのも大変そうですね(笑)。

しかしこれだけの大きなカオスマップでも、主だったものだけを挙げているだけだと思うので、SaaSに分類される日本のサービスはこの他にもいっぱいあると思います。

これは日本だけじゃなくて海外でも同じで、SaaSといって一番最初にみんなが思いつくであろうTODO系サービスを見るとこんな感じ、超老舗のTodoistから、MicrosoftやGoogleなどグローバル大企業もTodo系ツールをつくっているんですね。

  • Todoist
  • Asana
  • Monday.com
  • OmniFocus
  • Microsoft TODO
  • Google Tasks

でもTODOアプリって個人向け課金だとあまり儲からないので、必然的に企業向けユースを伸ばそうとするサービスが多いです。そうするとプロジェクト管理機能で戦わざるを得なくなり、アトラシアンのJIRAやGitHubなど超強力なライバルと競合することになります。

ここからは持論ですが、もう「今となっては誰でも思いつくような」サービスではSaaS市場で天下を取るのは極めて難しい時代になったと思います。例を上げると以下のようなものです。

  • TODO管理
  • 文書・メモ管理
  • ファイル共有
  • 社内コミュニケーション系

むりやり特徴をまとめると、管理画面や情報の登録画面があって、ファイルをアップロードしたりテキストを打ち込んだり、ちょっとそれらにまつわる業務手順を一部自動化して便利になるみたいなサービス。こういうのはグローバル大企業がすでに市場を取ってしまっていて、資金力を背景にスタートアップじゃ追いつけない品質のサービスを提供しているケースが多いです。TODO管理も文書管理も、出てきた当初はみんな思いつかなくて本当に画期的なサービスだったと思います。しかしそれが何年も経ってしまうと状況が変わったのですね。

言い方を変えると、大学生がWebサービス作って一発当てたら数年後IPOなんていう、牧歌的というかゴールドラッシュ的な時代は終わったのかもしれません。 SaaS市場の盛り上がりに代表されるように、Webサービスがニッチではなく完全なマスになってしまったので、マスのニーズに向けてWebサービスをつくると自然とグローバル大企業と競合することになります。

大企業がいない市場をねらったつもりでも全然安心できなくて、最近だとMicrosoft TeamsがSlackを追い上げているという話もあります。以下のツイートに貼ってある画像は数字の信憑性はどこまであるかわらないのですが。

別の記事ではMicrosoft Teams 2000万ユーザー対Slack 1200万ユーザーとなっているので、もう少し拮抗しているかもしれません。

STRATCHERY - The Slack Social Network

どちらにせよMicorosoft Teamsが単純なユーザー数だけをみればSlackを追い上げている、もしかしたら追い越そうとしているかもしれないということは言えるでしょう。

ちょっと前に聞いた印象的な表現があったので共有します。以下はOktaという認証系サービスを提供している会社なのですが、そのCEOがインタビューで語った内容を一部抜粋します。

Okta社は5000社もの顧客企業が、「彼らの業界でのAmazon」になれるように支援しています。そうしないと、Amazonが彼らの業界のAmazonになってしまいますから。 CNBC - Okta CEO on helping 5,000 customers become ‘the Amazon of their industry before Amazon’

Amazon Web Servicesは信じられないくらいのスピードで新サービスを追加していっています。ちょっと恐いことに、Okta社が「顧客がそれぞれの業界のAmazonになれるように」助けている間に 当のAmazonはこのOkta社と競合するサービスともなりうる(*1)Amazon Cognitoをだいぶ昔にリリースしていたりします。MicrosoftもAmazonも、市場が育ってきたらそこに自社の資金力と技術力で一気に顧客をかっさらうようサービスを投入してくるかもしれないわけです。

(*1 実際にはOktaとCognitoは連携できるなど、必ずしも純粋な競合サービスではありません。)

ここで私が「モバイルアプリ1000億円説」って言っている自説を紹介したいんですが、今どきの一般モバイルユーザーの要求水準が高くなりすぎて、開発費1000億円くらい投入しないとその水準をクリアできるモバイルアプリが作れないんじゃないか？という自説です。今モバイルアプリでサクサクとストレスなく動くものといったら以下のようなものがあるかと思います。もちろんこれ以外にもサクサク動くものはありますけど。

  • Instagram
  • Google Map
  • Twitter
  • Slack
  • iPhoneのApple標準アプリ(電話など)

これらはどれも大企業が作っていて、それぞれ人件費とかいろいろ含めた開発費1000億円くらい使っているんじゃないかと推測しています。それくらいのお金と技術力がないと、一般モバイルユーザーがストレスを感じないレベルの動作は実現できないんじゃないかなと。

でも1000億円かけてればいいのか？ってわけでもなくて、グローバル大企業と言ってもいいレベルの大企業でも、アプリ通知の表示数がいつまでもずれて正しくならない、突然アプリ操作中に落るなど、びっくりする動作を見せてくれるアプリが結構あります。でも、先に例示したような非常に安定性・応答性の高いアプリの品質に、私達一般モバイルユーザーが慣らされて贅沢になってしまったのだと思うんですよね。20年前のモバイルすらなかった頃のWebサービスって、もっと鈍重でとぎれとぎれだったと思うんですよ。

さてここからいよいよ、こんな厳しい環境の中でわれわれがどう戦うべきか？という話です。繰り返しですが牧歌的な時代は終わっていて、厳しい戦いをしていくのが今の時代のソフトウェア開発産業の当たり前だと思います。「開発チームが上手くいっていれば、プロジェクト自体もうまくいく」みたいな生やさしい話ではなくなってきています。ここで「カイゼン・ジャーニー」や「正しいものを正しくつくる」などの書籍で有名な市谷さんの言葉を借ります。

プロダクトづくりには2つのモードがあると思う。チームファースト(Team Fisrt)と、プロダクトファースト(Product First)。 … (中略) …どちらも局面によって必要になる。「プロダクトファーストの局面で、チームファーストの方針を取っている」時に生じる、成果への期待と実際のギャップである。 チームとして間違ったことはしていないのに、思うような結果がついてこない note - チームファーストがプロダクトを殺す。市谷聡啓

ディズニー映画やゲーム制作でも見てきましたが、ソフトウェア開発一般でも、何度も何度もやり直しを重ねて、開発終盤になってもどんでん返しで最初から作り直すくらいの品質の追求が必要になっていてもおかしくありません。当然やり直しに耐えられるような速度をソフトウェア開発チームは保ち続けなくてはならないわけです。それは「リリース前に根性で頑張る」みたいなレベルの話ではありません。

品質は悪いと基本的に手戻りを生むので速度に跳ね返る。手戻っている時間は学びを産まない時間。… (中略) … 品質をすてて速度をあげようは…結局はリードタイムの増加に跳ね返るだけなのでやめましょう Speakerdeck - 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition 和田卓人

品質(*2) を落とせば開発スピードが得られる、なんていう都合のいいトレードオフはそもそも存在していなくて、品質を上げるために歯を食いしばって開発スピードを高く保ち続けなければなりません。 そのためには時間が全然足りない中でソースコードをリファクタリングし続け、インフラを見直し続け、 放っておけば品質と開発スピード両方を下に引っ張る引力に抗い続けなくてはならないのです。

(*2 ここで和田さんが言っている品質はソフトウェア利用者から直接見える品質ではなく、ソースコードの変更容易正などどちらかと言えば社内向きの品質ですが、最終的には利用者から見える品質にも跳ね返ってきます)

上図の「◯」で示したように長期間に渡って開発スピードを高く保ち続けなければなりません。「✕」のように最初だけ早くて、だんだん遅くなって行くような開発のやり方ではダメです。

そして、ただ単に長期間に渡って開発スピードを保つだけではなくて、開発終盤にどんでん返しで完全やり直しになったとしても、そこからさらにスピードを上げて開発を間に合わせるくらいの力があるチームじゃないと勝ち残れない、そんな産業になりつつあるのかなと思っています。

こちらはアジャイルコーチとして有名な「きょん」さんのインタビューで、

テスト駆動開発と言っても、実装してみないとわからない部分はあります。知識が足りないときはおこりがちで…プロトタイプをつくって削除する。そこで得た知識をもとに再実装する… …開発プロセスの元祖、Royceは「おなじものを3回作る」という手法を提唱していた。 YouTube - Episode1: Kyon Mm (take1) - TDD/15 minute sprint #qshocking

ということを言っていました。きょんさんは15分スプリントなど、通常の開発チームでは取り入れていないプラクティスを多く提唱していますが、 奇抜なアイデアというよりはソフトウェア開発手法のベストプラクティスを突き詰めた結果他の人達がやらないことを提唱しているという印象を私は持っています。 きょんさんが語る「作り直し」による学習については、多くのソフトウェア開発チームが参考にできるところではないでしょうか？

まとめ

ディズニーのアニメ映画やゲーム開発を引き合いに、ソフトウェア開発一般との類似性、どの市場も競争が激化し一つ一つの開発規模の大きいものが増えてきた現状を紹介しました。 環境は厳しくなっていくのは大きなトレンドだとおもうので、ソフトウェア開発チームも厳しい戦いを覚悟しなくてはなりません。

  • 開発チームの状態が良好ならばプロジェクトもうまくいく

というほどわかりやすい世界ではありません。開発者たちはのしかかるプレッシャーの下で、時間と資源が全然足りない中で、常に開発スピードを高く保ち、そして保ち続ける努力を続けなくてはなりません。

  • 長期間に渡って開発スピードを高く保つことは必須
  • 開発終盤のどんでん返しを覚悟する

そして開発スピードはあくまで質の高いソフトウェアを作る前提条件に過ぎないので、それによって実現するのはソフトウェアの利用者が満足する高い品質です。 品質のためには、ゲームの例で触れた「町ひとつをディレクターの指示で消し去った」ような苦痛を伴う、しかし必要な判断を下すことが重要でしょう。それには、

  • 開発終盤でメンバーが「お前の仕事はいらない」と言われても大丈夫なインセンティブづくり

が重要で、最終成果物を評価するだけでなく、常に開発途中で各人で得た学びをチームに共有する、そのチーム学習を評価する、といった取り組みが有効でしょう。あるいは何年も1つの部分を同じ人が作らないよう適宜チームメンバーの担当箇所を入れ替えることも考えられます。

とにかく、いろんなことを足りない時間の中で考えて実行していかなくてはなりません。私達はそういう世界に生きています。 厳しいけど、それだけ高い能力と難しい判断が要求される、楽しい時代でもあると思いませんか？

← Back to home