【中編】華麗なるキャリアの道程は、『ドワンゴ』から逃げ出したい一心から！？｜飲み会で探るエンジニアのホンネ #naoya_sushi 編

＜前編のあらすじと中編のお話＞
夏の訪れを感じさせる某日、大のお寿司好きであり、ゲーム好きでもある、伊藤直也氏（以下「naoya」）が、本企画の最終回にゲストとして招待したのは、『株式会社ドワンゴ』の川上量生氏（以下「川上」）。普段から大のゲーム仲間でもあり、親交の深い二人の話は、過去の『ドワンゴ』を振り返る話から、アニメ業界とIT業界の話まで、多彩に展開されます。そして、話はいよいよ川上氏が考えるモノづくりの根幹の部分に迫っていくのであった――

⇒【前編】の記事はこちら

— naoya：エンジニアが自分の好きな言語を使うのにあれこれそれっぽい理由を捻り出すという話が出ましたけど、スクラムやDDDの導入に際しても、やっぱりそんな感じだったんですか？

— 川上：うん。もちろんスクラムやDDDが言っていることは正しいんですよ。でも、それを前提に開発をすべきというみんなのこだわりはなんなのか、って言ったら、やっぱりイデオロギーだと思うし、なぜイデオロギーが必要なのかというと、出発点は仕事が面白くないからだと思うんだよね。仕事への不満なんですよ。それの解決策で手近に思いつけるものがスクラムやDDDだったんだと思います。

— naoya：スクラムは全世界的に流行ってますよね。僕は教科書通りのスクラムはあまり好きじゃないから、苦々しく思っているところもなくはないんですけど。一方、DDDは、スクラムほどではないんですけど国内のWeb系だと、その活用の代表格って『ドワンゴ』っていう印象がありました。やっぱエンジニア退職問題の頃にDDDに関してもいろいろあったんですか？

— 川上：あの頃辞めていったエンジニアの中にも、「DDDをやらないからダメなんだ！」的な主張が多かったですよね。僕も現場から、いろいろとDDDが如何に素晴らしいかという話を聞いてみました。あれ、もともと原点はアジャイルとかですよね。僕にとっては当たり前の主張にしか聞こえなくて、逆に社内でなにが争点で対立しているのか、当時はよく分からなかったです。いや、まあ、正論だし、じゃあ、やりたければやればいいじゃん、反対する人いるの？　みたいなｗ

— naoya：なるほど。ところで話は少し変わりますが、最初は、開発現場の課題を解決する方法がほしいっていうことで、アジャイルとかDDDとかに目をつけて、やりはじめてはみるんだけど、だんだんやってるうちに、そっちの方が面白くなってくる。あるいは、他に目的が見いだせられないからなのか、スクラムをやるとか、プロセスの方を目的化しすぎて、だんだん話がおかしくなっていくということなんかもよくありますよね。それこそ、スクラムをやればうまくいく、とか宗教みたくなっちゃうっていう。

— 川上：そうね。やり方が重要になってきちゃうんだよね。

— naoya：まあ、アジャイル開発やスクラムの文脈で、それに盲目的になってはいけないというのは、識者の間ではよく言われることなんですけどね。警鐘が鳴っていても、やっぱりみんなは落とし穴に落ちる、という話です。それで、僕が気になっていたのは、川上さんがどこかで「スクラムは限定的な場面でしか役に立たない」って、言っていたような気がして。わかりきったものをつくるときには、スクラムっていうのは機能するかもしれないけど、そうじゃないときには機能しないんじゃないかって。

— 川上：はいはい。それはどういうことかっていうと、スクラムって開発する人が、最終的な製品イメージを共有するところからはじまるじゃないですか。で、共有ってほとんどはできないからｗ

— naoya：あー、そういうことだったんですか。

— 川上：いや、アイデアってさ、例えば『ドワンゴ』って、これまでに会社が急成長したタイミングがふたつあって、ひとつは『着メロ』で、もうひとつは『ニコニコ動画』なんですよ。でも、あのふたつって、基本みんな成功するって信じてなかったんですよ。社員のほとんどは信じてない。もちろん大多数のエンジニアも含めてです。で、信じていないものをスクラムでつくったら、みんな、「こんなものどうするのかな？」って思いながら手を進めるわけですよｗ きっとダメだという共通の考えやビジョンを持ちながらつくるってことになるでしょ？

— naoya：それは僕も実体験としてわかります。だけど、世の中の人たちは、「スクラムのような教科書が通用しない、じゃあどうしたらいいの？」っていうのがわからないんだと思うんですよ。

— 川上：結局、分散処理って難しいんですよ。みんなエンジニアだったら分散処理が難しいってことはわかるじゃん？　きれいにタスクを切り出して、平行して振り分けられるアルゴリズムなんて限られているわけです。分散処理可能なタスクっていうのは、並列性の高い相互依存しない形にしなければいけない。ちょっと難しいロジックになっちゃうとそれは無理なんです。それで新しいコンテンツやサービスをつくるっていうのは、基本、並列化が難しいジョブなんですよ。ビジョンをつくるような仕事は、複数の人間でやると人間同士のデータ転送の帯域も狭ければ遅延も大きいから、逆に極端に遅くなる。簡単に言っちゃえば、一人でやった方が効率がいいんだよね。

— naoya：わかります。

— 川上：スクラムは、プログラマという人間の行う情報処理を並列化するツールだから、コンセプトをつくるっていう並列化が困難なジョブに対して適用することに、根本的なところで矛盾がある。そのことを並列コンピューティングをやっているエンジニアは理解しなくちゃいけないと思うわけ。全部をスクラムでやることがいかに難しいことなのかっていうのを。そんなのできるわけねーだろっていうｗ

— naoya：リソース競合を考えた上で、全体の状態を正しくマルチスレッドで処理するのは難しいから嫌だ、って計算機の文脈ではみんなそう言ってるのに、人間でそれをやろうとしているとは何事ぞっていう。

— 川上：そうそうｗ そりゃおかしいでしょって。

— naoya：そう説明されたら、多くのエンジニアは簡単に理解できるかもしれないですねｗ

— 川上：でしょう？　どう考えたってさ、毎朝、仕事する前に話し合ったとしても、人間の脳の中で処理する帯域幅の方が広いに決まってるんだから、言語でいくら情報を共有化しようとしたところで、効率が悪いわけですよ。そもそも、なにを共有すればいいかが決まってないわけだから。実際、誰かの明確なビジョンがあって、それをスクラムで共有していくのであれば意味があるかもしれないけど、問題なのは、特にエンターテイメントコンテンツにおいては、ビジョンをつくっている人間がビジョンたり得るものを脳の中に最初から持っているわけではないってことなんですよ。

— naoya：そうそう、ビジョンはやりながら固まっていったりしますよね。

— 川上：多くの場合はつくりながら考えてるわけ。

— naoya：確かに。

— 川上：つくりながら考えているものを共有するっていうのはとても難しくて、自分の中で説明しながらも、「あっ、間違えてた！」なんてこともあるわけでしょ？　それを、都度ごとに毎回言葉で説明して共有していくなんてあり得ないですよ。だいたい、どんな優れたビジョンだって、必ず自己矛盾を抱えながら進んでいくものなんです。ある自己矛盾した体系を少し修正した、でも、やはり別の自己矛盾は残っている体系に変えていく過程をいちいち共有したってしょうがない。そして、結局、エンターテイメントコンテンツの場合は、最後まで自己矛盾が解決しないまま完成する。そういうものなんです。そういうプロジェクトでビジョンをつくる情報処理システムとしてスクラムを採用するのは、アーキテクチャとして間違っているんです。

— naoya：その視点はなかったですね。アジャイルやスクラムは試行錯誤のためのツールでもある一方、個人の脳みそレベルの試行錯誤となると粒度が合わない。

— 川上：共有可能な情報が常に確定していれば、まだ可能性はある。時間をかけてでも共有すればいいじゃん、という理屈も成り立ちますけど、新しいコンテンツとかサービスって、何をつくっていったらいいのかなんて、リーダーもわかってないわけですよ。試行錯誤で煮詰めていくわけでしょ？　その試行錯誤を一人でやっても大変なのに、人を増やしていったら破綻するか、なんの面白みもない平凡なものをゆっくりと作ることにしかならないです。

— naoya：なので、自分がやるときは分業可能になる場面まで、基本一人とか二人で膝突き合わせて、ある程度のところまで形をつくってから渡す、みたいな感じで切り替えているんですけど、そこの手前の部分の開発をどうするのか？　っていうのは、実は世の中で全然体系化されていなくって、並列可能になった部分しか体系化されていない。結局スクラムっていう後者の方法論だけしか存在してないがために、それが一人歩きしちゃっているんですよね、きっと。

— 川上：そうそう。解決している部分だけがクローズアップされてイデオロギー化しているんですよ。

— naoya：で、スタートアップとかが、まだ製品がマーケットに受け入れられていないのに、いろいろ試行錯誤しなくちゃいけないフェーズで教科書通りのスクラムを回し始めてしまって…、まあ、なかなかうまくないですね。

— 川上：そう。せっかくベンチャーで受託じゃないのに、スクラム入れてやった途端に、そのスタイルはものすごく受託に近くなっちゃうわけ。

— naoya：あー、なるほどですね。

— 川上：仕様をみんなですり合わせて、それをみんなで作るっていう作業になっちゃうでしょ？

— naoya：もともと、アジャイルとかスクラムって、僕の理解だと時間と予算に制約がある。それこそ、受託開発のスキームをいかにウォーターフォールではなく、もう少し柔らかくやるかっていうところで出てきた方法論だと捉えていました。新サービスを作るみたいな、制約が緩い環境の中で活用しても、あんまり意味ないんじゃないかっていうのはありますね。

— 川上：受託企業がウォーターフォールでやられると現実的に無理だろ、っていうような作業を強いられることが多いから、受託企業にとっての最も理想的な仕事の環境っていうのが、アジャイルであり、スクラムなんでしょうね。発注元企業の横暴から受託企業が身を守るための責任回避のシステムとしては、とても優れていると思う。自社開発のプロジェクトで、何をつくるのかすらわかっていない状態で試行錯誤しながら、なにかをつくり出していく、というのには向いていない手法ですね。

▲続いての料理は、ゴマサバとつぶ貝の岩塩のせ。濃厚な味がお酒と会話をさらに弾ませます。

— naoya：そうするとですね、『ドワンゴ』で、なにか新しいサービスをつくろう！　ってなったとき、どういうフォーメーションでやるんですか？

— 川上：いや、よく知らないｗ

— naoya：えっｗ そこは指示とかしないんですか？

— 川上：いや、僕、仕事は本当にしてないんですよ。

— naoya：ｗｗ いや、まあ、CTOとしては『ドワンゴ』ではそうなのかもしれないですけど、一方で、今みたいな話って、普通に人から言われた通りにやってきた人たちにとっては、感覚的にわからない話だったりするのかなって。

— 川上：そうかもしれないですね。

— naoya：つくりながら試行錯誤を繰り返して正解を見つけていくって、プログラミングとかモノづくりしたことない人たちには、なかなか伝わらないんだろうなって思います。それが面倒に感じる場面もちょいちょいありますし。

— 川上：これって、ひとつのものを一人でつくりあげたことがある人じゃないと多分わからないんですよ。ほとんどの人が一人でものをつくったことなんてないでしょ？　だから、ほとんどの人が、もののつくり方がわからないから、アジャイルとかスクラムとかって、ある意味精神的なサプリメントとしての機能もあるんじゃないかな。みんな、どうやっていいかわからないから、そういう不安感を鎮めるためのサプリメント。

— naoya：はは。それって、まさに宗教なのでは？

— 川上：救いを求めているんですよね。

— naoya：その辺の微妙なニュアンスがわからない組織だと、合う合わない関係なしにスクラムみたいなものも、容易に導入されてしまうというのはありそうですね。

— 川上：そうそう。で、いつまでたっても、ものができない。できたとしてもヒドイっていう。

— naoya：川上さんが一番最初に言ってた、なんで言ったものができあがってこないんだ問題も、この辺と関係あったりするんですか？

— 川上：なんかね、『ドワンゴ』の中で起こってる問題っていうのは、もっと低レベルなんですよ。

— naoya：低レベル？

— 川上：低レベルっていうのはね、僕がいつも社内で言っているビジョンが、なぜ社員に伝わらないのかって問題なんですよ。僕が考えていることって、いつも実は簡単で単純なことなのに、どうしても難しくみんなが思うらしくて、なかなか理解してもらえないのはなぜだろうということです。

— naoya：簡単でシンプルだけど難しい？

— 川上：なんていうかね、僕が話す内容って、いつもその場で考えながらしゃべっているんですよ。昔、考えた結論を思い出して喋るということはやらないんですね。常にリアルタイムレンダリングなんです。だからいつも、ぶれずに同じことを話せるんです。

— naoya：普通はその場の思いつきで喋ると、毎回話す内容は変わっちゃいますよね。

— 川上：それは脳内のレンダリングエンジンの設計が悪いからですよ。記憶って間違えることが多いから、答えをひとつの記憶だけで格納すると記憶エラーを防げない。複数の記憶から演算して答えを出すようにすると、チェックサム計算を毎回やっているようなものだから、冗長ですけど正しい答えを常に出せるんです。だから、僕は話すときに答えの前に理屈をつけることが多いんですが、それは途中の計算を公開しながら話しているんです。でも、相手は途中の計算は聞き流して、結論の答えだけを覚えようとするんですよね。で、その結論というのは、しばしば一般的な常識とはかけ離れたものだったりするわけです。

— naoya：言ってることはシンプルなんだけど、みんなは自分の常識と照らし合わせてしまうから、なかなか理解できないでいると。

— 川上：本当は途中の計算が重要なわけですよ。前提条件が変わると計算結果も変わってきますから。結論だけ覚えるのはリスクがあるわけです。で、だいたい社員の持っている前提条件と僕のそれとじゃ、そもそも、まったく違うんです。そうするとどうなるかというと、僕の言った結論を無理矢理盛り込んだ企画を1週間後くらいに持ってくるんですよ。こういうことでしょうか？　って。もう全然違うわけですよ。で、僕はそれを全否定するのね。話にならないと。で、このやりとりを2、3回やると、大抵相手の心が折れます。

— naoya：そりゃあそうですよｗ

— 川上：で、心が折れたときにどういう風な対応をするかというと、だいたい企画の人間が、「じゃあ僕が現場と川上さんとの窓口をやります」って出てくるんですよね。「みんなが混乱しちゃうから、川上さんの言っていることは、僕が全部吸収します」って。でも、だんだんとミーティングの回数が減っていくんだよね。1ヶ月毎とか、2ヶ月毎とか、だんだんと間隔が空いてくる。つまり、僕の影響を排除して開発しちゃおうとするわけですよ。

— naoya：あー。

— 川上：それで何ヶ月後くらいに、ほぼ完成したものが出てくるんですよ。そうしたら、やっぱり全然違うから、全然違うって言うんだよね。そうすると、もう完全にプロジェクトが崩壊しちゃうんですよ。

— naoya：ｗ

— 川上：結局さ、着メロサービスとか『ニコニコ動画』とか『ニコニコ生放送』とか、成功したプロジェクトって、僕が24時間コミットしてつくったものなんですよね。そのときは、ICQだとか、メッセンジャーとかで24時間、メンバーとコミュニケーションしてる。そういうのは、うまくいくことが多いんですよ。じゃあ、なんで他のサービスはコミットしないのかというと、まあ、半分以上は僕のせいなんですよ、やっぱりｗ 僕はなかなかやる気がでないんです。でも、なぜ、じゃあやる気のない僕に社員がどうすればいいのかを聞きにくるかっていうと、それは僕に聞いてないってことで、社内で責められるからなんですよ。「なんで川上さんに確認しないんだ！」って怒られるから聞きにきているわけ。本当にわからないからじゃなくて、仕方なしで聞きにきているんだよね。そして、僕に聞いてみたら、余計に混乱するようなことを言われ、これじゃプロジェクトが進まないから、川上さんに聞いたフリだけして、実際には勝手に進めようというようなことをしちゃうわけ。そうするとロクなものができないから、僕は否定するわけですよ。

— naoya：なるほどｗ

— 川上：そこでパニックに陥る。だいたいこのパターンで崩壊ですね。

— naoya：それがずっと起こっているんですか？

— 川上：思い起こせば、ずっと起こっていますよね。こりゃマズイなぁって。

— naoya：根本的な原因は、川上さん一人のビジョンに依存しすぎているからじゃないんですか？

— 川上：というのとも違うんだよね。いや、依存するんだったら、本当に依存してくれた方がまだいいと思うだけど。みんな自分の常識を捨てるのは難しいんだよね。

— naoya：そりゃそうですよね。

▲続いての料理は、食べるのがもったいないほど美しい、夏野菜のジュレがけです。

— 川上：なんかね、会議のときに、社員が一生懸命説明している内容を聞いてて、「あれ？　これ2年くらい前に同じコンセプトを僕が説明してるぞ」って思うことがよくあるんですよ。結論しか覚えないから、リバースエンジニアリングやるのに2年間かかったんでしょうね。僕はちゃんと途中の計算も最初から説明しているのに。

— naoya：話を聞いている方は、もうちょっと説明してくれないとわかんないよ！　って思っていたりしていませんかね？ｗ もう、いっそのこと本にしちゃったりするのって、どうですか？

— 川上：えっ？　なにを？

— naoya：こういう感じで。（と手に持った川上氏の著書『鈴木さんにも分かるネットの未来（岩波新書）』を指し示す）

— 川上：うーん、その本に書いたほど難しいことじゃないと思うんだよね。本当に簡単なんですよ。でも理解されない。

— naoya：だから、誰にでも、それこそ鈴木さんにもわかるように、自分のビジョンを説明するっていう前提で一回全部文字に落として、何回でも読めるっていう状態にしたら、少しは理解も進むんじゃないかなって思って。

— 川上：いや、そこの根本的な問題って、自分の頭で考えようとしないところに問題があるわけですよ。

— naoya：ああ。

— 川上：そうすると、僕の言っていることと合っているかどうか？　っていうのを気にする段階で、すでに間違っているんだよね。だって僕のビジョンとかって、マーケットに受け入れられるかどうか、って視点で考えているわけじゃないですか？　それがベースであって、なにも自分の宗教を押し付けようとしているわけじゃない。なんだけど、僕の話を聞く人っていうのは、できるだけ僕の話の再現性の高いアウトプットを生成しようとするわけですよ。そんなのいいから、僕みたいにもっとマーケットを意識して、正しいデータに基づいて再計算してくれよって思う。

— naoya：そっちの構造を理解すれば、似たような結論を導き出せるはず？

— 川上：マーケットを見て同じ結論を出す、もしくは、僕の結論が間違っているのならそれを指摘しろ、っていうところまで、本当は行かなきゃいけないんだけど、実際にはそのレベルになくって、僕の言っていることを正しく理解するってフェーズで、すべてのリソースを使おうとするから、おかしくなっちゃうんですよ。

— naoya：確かに。

— 川上：僕、夢を語るようなことはしないのね。具体的にできそうなことしか言わない。そして僕のビジョンって基本、制約条件なんですよね。こういう制約条件でものをつくった方がいい。理由はこうこうこういうものだ。でも、具体的な計算は自分で考えてね☆ っていう感じ。

— naoya：なかなかいい塩梅のものが上がってこないと？

— 川上：お願いしたときに大体のイメージはあるんだけどね。矛盾するようなことを言うけれど、僕の言ってることを100％正しいと思って、それを忠実に再現しようとするのが、トラブルの第一の原因なんですよ。で、第二の原因って言うのは、僕が言ってることを参考に、自分のオリジナルのアイデアを付け加えようとする。それがね、だいたい悲惨な結果を招くんですよ。

— naoya：自分で考えろって言っておいて、でもオリジナルのアイデアをつけたらダメだ、って言われる。結構辛いですよ、それｗ

— 川上：言われている方は、きっとそう思ってるんだろうけどさ、そこは完全に勘違いで、Webのエンジニアって、基本的に工業デザインに近いって僕は思っているんですよ。ところが、Webサービスのデザイナーって工業デザインじゃなくって…ええっと…

— naoya：クリエイターであろうとする？

— 川上：そう。自分はクリエイターであるべきと勘違いしてる人が多い。

▲続いての一品はシマアジのカブト焼き。醤油とカボスをかけていただきます。

— 川上：工業デザイナーとクリエイターって、全然違うわけです。みんなが想像しているクリエイターっていうのは、自分の発想力だけを武器にコンテンツの差別化をする人ってイメージでしょ？　でも、工業デザインって、物理的・コスト的制約の中で何ができるのかっていうことをベースに考えるわけですよ。そして、Webサービスは工業デザイン的思考でやるべきなんです。例えばユーザーインターフェイスっていうのも、実現するためにシステムに加えなければいけないコード的な変更と、それのスケーラビリティへの影響までも考えてデザインすべきだと僕は思うんだけど、みんなクリエイティブな仕事って勘違いしてる。だからね、自分のナイスなアイデアみたいなものを取り入れようとするんだけど、そんなものはいらない。

— naoya：最近は、そのクリエイティブな風潮が強いように感じているんですけど。

— 川上：むしろね、デザイナーっていうのは、サーバとかのアーキテクチャをわかってない人間がやるべきじゃないと思う。まぁ、サーバと言わないまでも、クライアントのレベルっていうか、今だったらアプリだったら、iOSのSDKがもってる制約とかね。

— naoya：あっ、それは絶対にそうですね。

— 川上：そう。わかっている人間がデザインをすべき。

— naoya：それ、僕もよく言っているんですけど、なかなか伝わらないですよね。やっぱり触ったことある人じゃないと無理かなぁ。

— 川上：そうそう。だからね、僕が嫌いな言葉でさ、UIとかUXとかあるけど、どうでもいいのよ。UXとか言い出すもんだから、間違ってクリエイティブな方向に行くんであってさ。

— naoya：ｗ

— 川上：もちろん、UX的な志向はとても重要なんだけど、たとえばiPhone で言えば、iPhoneのハードウェアの制約の中で実現できるインターフェイスって、自ずと決まってくるんだから。

— naoya：ああ、それはいい例ですね。Appleの SDK に関して言えば、わざわざそのためにフレームワークの中に制約を埋め込んでありますよね。SDKの中でインターフェイスは、こう書かざるを得ないっていうのがある程度APIとして提示されている。例えば、このコンポーネントはここにしか配置できない、というのが API レベルで規定されていて、そうではないことをやろうとすると、自力で一から実装しなければいけない。つまり、Apple的にはそういう使い方を想定していない。そこに素直に従えば、自ずと使いやすいものがつくれる。けど、そういう制約を知らない人がオリジナリティを出そうとして…

— 川上：そうなんだよね。

— naoya：でも、中にはそのオリジナリティを出して、SDKには則してないけど、使いやすいものをつくっちゃう人たちが世の中にはごく一部いたりしますよね。それでデファクトになった結果、Apple標準のコンポーネントとして採用されるような部品を作り出す人たちとか。

— 川上：でも、いたりはするけどさ、それって、僕はものすごい決意を持ってやるべきだと思うわけ。

— naoya：僕もそう思いますよ。基本的には、よく目にするアプリだなー、っていうものをつくるのが大前提として正しいと思うんですよね。

— 川上：そう。正しくって、それでどうしても他と差別化したいってなったとき、この機能を実現して、今後のメンテナンスも含めて運命を共にする、って覚悟をもってやるべきものだと思う。こっちの方がセンスいいじゃん、とかいうクリエイター的感性かなんかしらないけど、そんなもので安易に決めてもらったら困るんだよ。

— naoya：なるほど。それがさっき言ってた、工業デザインって意味なんですね。

— 川上：そう。

— naoya：そこは理解できました。で、工業デザインという問題で、一方でものすごく難しいなって思うことは、ハードウェアの制約とかSDKがもっている特性から物事を考えましょう、っていくと、どうしても発想がその制約に縛られすぎてしまうことはないでしょうか？

— 川上：いやいや、例えば Appleなんかのデザインっていうのは、それをやっているんですよ。そのために、新しい素材まで開発したりしているわけでしょ？　それなのに、多くの人は単純に格好良い物を見ないといけないから、とか言って、部屋の中にいろんなブランド品を並べるジョブズの逸話とかを紹介して、「これがハイセンスなものをつくる術か！」ってなってさ、そういう風に思ってるわけでしょ？

— naoya：はははｗ

— 川上：でもね、実際にジョブズがやっていたことは、世の中にないような仕組み、例えば、アルミニウムの一体成型ができる工場をつくったりとか、新しいデザインを生み出すために必要なインフラから考えているわけじゃん？　単なるジョブズのアイデアとかセンスの問題じゃない。

— naoya：現在の制約を出発にして、ものをつくろうとすると、逆にそこへの発想が縛られ過ぎることもあって、それこそ手段と目的の逆転現象じゃないですけど、みんな手段から入っちゃう。本来、その制約を飛び越えなきゃいけないんだけど、それこそ工場つくんなきゃいけないのに、工場をつくらないで、今ある仕組みでやろうとして残念なものができあがっちゃう、みたいな…

— 川上：そう。だからそこは命懸けでやろうよ、ってことですよ。Appleの基準に則らないでインターフェイスをつくる、っていうのは、反乱を起こすって話だから。それが大きな効果を生むものでないといけない。そこは相当慎重にやらないといけないって思う。そこで勝負するってことだから。

— naoya：インターフェイスだと、そういう考え方もわかるんですけど、そもそも、こういうソフトウェアをつくりたいっていう根本的なところ。それの課題を先に定義して、解決するってことだけで出発しても、夢みたいなソフトウェアを描いちゃって、まったくものになるようなものはできあがってこない。逆に、できることから出発すると、課題にミートしない中途半端なものができちゃって、結局この課題を解決するために、こっち側にはこれくらいの制約があって…、というのを両方バランスよく理解してつくれる、っていう人しか正しいものはつくれないってことですかね。

— 川上：そう。そういう結論になります。

— naoya：それって、やっぱり少ないですよね、そういうエンジニアって。

— 川上：いやぁ、当たり前ですよ。多かったら競争が大変じゃないですかｗ

— naoya：そうですねｗ

▲次の一品はカツオのお刺身。玉ねぎ酢醤油が味にアクセントを生みます。

— 川上：特に最近は専門性が強くなってきていて、自分の専門のことしかわからないことも多いじゃないですか。横断的な知識と経験を持っている人は少ないから、そういうところで勝負しようとするのが正しい。

— naoya：じゃあ、今の物理的限界とか、工業デザインっていう観点からいって、『ドワンゴ』では、例えば人工知能とかにも投資しているってことですか？

— 川上：うーんと…『ドワンゴ』ってさ、根性系のプログラマが多いんですよ。馬力はある…というプログラマ。

— naoya：それってアカデミックに少し弱いってことですか？

— 川上：例えば負荷計算っていうのも、僕はまず最初に理論値を出してほしいのに、実測値を出してくるんだよね。

— naoya：理論値って、「だいだいこれくらいの人数が来て、一人当たりこれくらい使うからこうだ、ってやっていくと、サーバはこれぐらい必要です」とか･･･そういう理詰めの仕方ですかね？

— 川上：僕は、その限界まで詰めてほしいんですよ。例えば、1台当たりのスケーラビリティは、一人あたりに最低必要なトラフィックから計算されるLAN部分で必要なバンドワイズと、それによってどういう処理をCPUでやるから、そうするとCPUで消費されるバンドワイズはこれくらいで、ワークエリアとしてはこれくらいのメモリを積まないといけない。だから、これくらいが理論的には限界なんだけど、実測するとまだその30％くらいの性能しか出ていません、とか。そういう説明がほしいわけ。

— naoya：理論的にはもっと詰められるんだけど、そこではなく、目の前の実測したパフォーマンスだけで考えてしまう。

— 川上：そう。やっぱり、理論的な計算ができないとダメでしょう。

— naoya：そうしないのは実測する方が楽で、面倒くさいからじゃないですか？ｗ

— 川上：簡単ですよ。計算するだけじゃん。テストプログラムつくって測定するほうがよっぽど面倒くさい。

— naoya：そういう思考プロセスを普段からやってないってことなんですかね？

— 川上：やってない。

— naoya：頭の中にフレームワークがないから、パッと出てこない。

— 川上：多分さ、PCからプログラムをやっている人間って、ハードウェアの制約の中でつくってきたから、そういう思考プロセスって当たり前なんですよ。それって、今だとサーバエンジニアに最も必要な資質だったりするじゃん。大規模サービスっていうのはスケールが重要で、特にサーバの性能のチューニングっていうのは、本来そういうことをやらなきゃいけないはずなんですよ。今、抽象化したプログラミングが許されるのって、クライアント側であって、クライアント側のリソースって他に影響を与えないから、ある範囲内に収まっていれば問題は無い。サーバの場合は、スケールを考えた瞬間にどんな処理であっても、そのスケールの限界で全体の性能が制限される可能性がある。

— naoya：それはそうなんですが、僕の経験から言うとサービスがヒットしないと、そう考えなきゃいけない必要性が生まれないっていう…

— 川上：そうね。だから、Webベンチャーっていうのはさ、ものを動かすことの方が重要になっちゃうんだよね。まだユーザーがいないから。

— naoya：サービスがヒットしてきて、サーバダウンとか起こるようになってはじめて、扱ってるデータひとつひとつのサイズを気にしはじめたり、IO性能を稼ぐために圧縮できる余地を探しはじめたりする。そうなって初めてスケーラビリティに意識が行くんだけども、そうなるまでWebエンジニアって、そういうことやってきてないから、最初は呆然としちゃうんですよね。

— 川上：だからね、僕なんかも新しい機能とかアイデアを出すときには、スケーラビリティから考えるんですよ。この機能を実現するのに、どのくらいの負荷がかかって、将来的に…例えば、ある機能を実現しても、発展させていかないとユーザーが飽きちゃうじゃん？　ある程度普遍的な機能であっても、改良のロードマップって最初から見えているものなんですよ。そうでないとやりたくない。サービスがヒットする中で、どういうトラブルがどの程度起こるかは、最初の段階でシミュレーションしちゃうんですよ。そうすると、この機能はやってもいいけど、こういう機能は便利になるけどやっちゃいけないっていうのは、最初からわかる。

— naoya：はい。

— 川上：なんだけど企画の人間はそういうことを無視して、こっちがいい、とかやってしまいがち。

— naoya：エンジニアリング出身の企画者は、たぶん直感的にそれをやっていますよね？　そういうトラブルが起こったときに、どれだけ辛いかわかっているから。

— 川上：そう。

— naoya：直感的というより、無意識に避けているのかも。

— 川上：大規模サービスのデザインをする人間っていうのは、負荷計算が頭の中である程度イメージできる人間じゃないと、やっちゃダメですよ。なかなかいないけどね。

— naoya：とはいえ、みんな、やりながら覚えていくんですよね。僕も最初は全然できてなかったし。

— 川上：でもね、分業体制になっていると、負荷が発生したときに、その解決を誰かに丸投げしちゃうから、そこになかなか気付かないまま育っちゃうこともある。

— naoya：僕も今の話を聞いて、なるほどなって思ったし、今の自分ならできるなと思ったんですけど、僕は理詰めというより、もっと直感的にやっちゃってますね。エンジニアリング的な制約の中から、大体この辺りまでは大丈夫かな？　っていう当たりを付けていって。でも、それは正しいと思ってやっていたというより、それしか方法論として拠り所がなかったという感じですね。世の中にもできる人はいるだろうけど、確かに分業体制が進んでいるので、昔のように簡単だったころはWebサービスなんて一人でも2、3日くらいでつくれていたから、逆に一人で頑張らなきゃいけない状況が多くて、それでフルスタックで全部覚えちゃう。そんな感じの世界だったから、それを経験してきた人なら、結構できるんでしょうね。さっき、一人でつくりきったことがある人ならできるよ、みたいな話もありましたけど、まさにこの辺りのことも絡んできますよね。

— 川上：そうですね。エンジニアリングだけに閉じた話でもなくて、マーケティングとか営業とか経営とか、全部、分かっている人がやるのが本当は理想なんですよ。

— naoya：今はつくるものも複雑になってきていて、市場も大きくなり、一人ひとりが専門性を特化しているんで、全体感持ってモノづくりに挑める人が、全体として人が増えている割には増えていない。

— 川上：現場では特にだけど、権限移譲しないと人って成長しないと思っているんですよ。だから、僕、基本は指示とかはしたくない。月に1回とか、僕にお伺いを立てて、そこで最終決定がされるっていう開発体制って、絶対にダメだと思ってるんですよ。だって、現場より僕が詳しくないのに意志決定できるわけないじゃん。1ヶ月間ずっと仕事で携わっていた人間のほうがよく分かっていますよ。それを、1時間くらいプレゼンを受けた僕が、その内容だけでジャッジするなんて、正しい判断ができるわけない。この構図って、責任回避にしかならないんですよ。でも、気がつくと、そういうミーティングがいつのまにか予定表に入っているんですよｗ

— naoya：ははｗ

▲後編では、いよいよ主役の握りが登場です！

モノづくりにおいても独自の理論と確固たる信念を持つ川上氏。前編・中編にわたりお届けしてきた本対談も、いよいよ次回で最終回。最終回にあたる後編では、エンジニア天国といわれる『ドワンゴ』の職場環境の話から、ついに会社愛に目覚めた象徴CTOの話まで話が展開されていきます。

⇒⇒⇒【後編】の記事が公開されました！