▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」【F17-1C】セッションの書き起し記事をいよいよ公開！10回シリーズ(その4)は、市場に出す一番最初の段階のプロダクトのコードやシステムにどの程度こだわるのか？について議論しました。MVP(Minimum Viable Product)に関して理解が深まります。是非御覧ください。
ICCサミットは新産業のトップリーダー600名以上が集結する日本最大級のイノベーション・カンファレンスです。次回 ICCサミット FUKUOKA 2018は2018年2月20日〜22日 福岡市での開催を予定しております。参加登録は公式ページをご覧ください。
▼
【登壇者情報】
2017年2月21〜23日開催
ICCカンファレンス FUKUOKA 2017
Session 1C
イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント
（スピーカー）
岩田 和宏
JapanTaxi株式会社
取締役CTO
柄沢 聡太郎
株式会社メルカリ
執行役員CTO（※2017年4月より執行役員VP of Engineering）
平山 宗介
株式会社メドレー
取締役CTO
山崎 大輔
Supership株式会社
取締役 CTO室室長
（モデレーター）
松岡 剛志
株式会社レクター
代表取締役
▲
▶「革新的なプロダクトを生み出す開発マネジメント」の配信済み記事一覧
連載を最初から読みたい方はこちら
最初の記事
【新】イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント【F17-1C #1】
1つ前の記事
優秀なエンジニアを採用するための「口説きタイミング」とは？【F17-1C #3】
本編
松岡 次のテーマは「どのくらい”コード/システム”にこだわるべきか」です。
少しエンジニアっぽい話ですね。
「ゼロイチ」でのコードやシステムに、どれくらいこだわるべきか。
ちなみに、これ、興味おありですか（笑）？
柄沢 「こだわるか」という文脈は伝わっていますかね。
松岡 確かに。
こだわるとは何か、どなたか少し解説して頂けませんか？
柄沢 このセッションのネタ出しの時に出てきたのは、Facebook、Mark Zuckerbergの“ Done is better than perfect“とか「完璧を目指すより取り敢えず終わらせろ」という言葉でした。
要するに、設計をきちんとするとか、コードが綺麗とか、その先の拡張を考えて柔軟なシステムを作るということなどを、創業当初にどれくらいするべきかということでした。
そんなことよりも、取りあえず動くというのは皆そうだと思うのですが、そのさじ加減はどうなんだっけといった話をしていた文脈でした。
あまりご興味がないかもしれませんが。
松岡 興味がおありの方？
（会場挙手）
結構いますね。ありがとうございます。よかった〜（笑）
どなたか、熱い主張はないですか？山崎さんいかがでしょう。
コードの質は低くても設計思想はしっかり練った
山崎 一般的には、サービスと言われる“toC“のビジネスなどで競争相手が沢山いるというケースに限って言うと、そんなにこだわるべきではなくて、即出すというのが重要になってくるかなと思います。
そして、弊社のシステムの場合は、いわゆる広告システムと言われる“toB“のものなので、失敗が許されません。
僕らの創業当初はライバルもたくさんいて、戦うというよりは、まず隙間を見つけてその業界に入る必要があったので、結構はっきりしたものを作らなければならないという条件が入っていました。
とにかく早く作らなければならないので、一応割り切りはあって、コードの質は結構悪かったです。
僕がコードを書いたのですが、僕は当時そこまですごいプログラマーではなかったので。
・・・「今はすごい」みたいな言い方しましたね（笑）。
ただ、アーキテクチャー（設計思想）は結構練りました。
広告システムってどんどん成長していくものなので、10年、20年戦いたいと思ったんですよね。
コードの方は結構稚拙で、後から入って来たメンバーに散々言われましたね。
ここで誤解して頂きたくないのは、皆さんエンジニアでいらっしゃるのかどうかは分かりませんが、システムの設計が綺麗できちんとしているという話と、作るコードが綺麗か汚いかというのは独立なんですね。
アーキテクチャーがしっかりしていれば、コードが汚くてもシステムが安定するというのがあって、それは結構意識してやっていましたね。
僕はそんな感じでした。
松岡 なるほど。
コードの綺麗さと、システムの綺麗さ・アーキテクチャーの綺麗さというのは独立しているということですね。
山崎 独立しています。
松岡 システムは丁寧に、コードはある程度。
山崎 ある程度乱暴に、という感じですね。
松岡 なるほど。
柄沢 「隙間に入りたい」というお話がありましたが、そこのビジネスが成り立つかどうかというのは最初は分からない訳ですよね。
当然アーキテクチャーはビジネス要件によっても変わってくると思うのですが、それをゼロイチフェーズでやった時に「しっかりやった」というのがまだあまり分かっていないというか。
今後起こる要件にフィットさせ続けられるシステムは作れる
山崎 少し技術的な話になってしまうのですが、「Lisp（リスプ）」というプログラミング言語があって、全部の要件を決めてからシステムを作り始めるというトップダウン法式と、小さな要件パーツを沢山作ってからそれを積み上げて作るというボトムアップ方式の2つがあり、僕は「ボトムアップ方式」で作ったんですよ。
要するに広告システムに必要なパーツを先に作っておいて、それを組み合わせるという手段をとったのです。
エディターで「Emacs（イーマックス）」というのがありますよね。
「Emacs」には小さなコア部分があって、その上に言語を積み上げて大きなシステムを作っているじゃないですか。
僕らは今後起きるビジネス要件を全部網羅するソフトウエアはいきなりは作れないのだけれども、要件に対してフィットさせ続けるシステムは作ることができると思っています。
つまり要件にフィットさせ続けられる拡張性を持ったプログラムは作ることができるという風に考えたんですよ。
ですから、そこは矛盾はしないのかなと思っています。
柄沢 これは難しいですよね。
色々な議論が起こりますが、僕がすごく意識しているのは、あくまでもプロダクト思考で、サステイナブルな仕組みで動けるかだと思っています。
弊社はシニアエンジニアが結構多いのですが、ライブラリのアップデートをすごく頻繁にするんですよね。
もし放っておくと累積されて、後々大規模な再編成をしなければいけないというのが読めているから常に頻繁にアップデートするのですが、そういうことを仕組み化してやっていくことが大事だと思って意識しています。
山崎 あともう一つ僕が上手くいった条件があって、広告業界というのは僕が作り始めた時点で既に10年くらいの歴史があったので、何を作ればよいかというのはかなり明確だったんですよ。
ですからメルカリさんのように、そもそもそういうジャンルがあったけれども再構築し直すぞといった話とは少し違ったんですよね。
逆にメルカリさんがどう考えてシステムを作られたかというそこのお話を伺ってみたいですね。
どちらかというと走りながら、なんなら壊れてもいいからという思想でやられているじゃないですか。
「最低限」の認識が経営者とエンジニアで違うと地獄
柄沢 そうですね。
そういう意味で言うと、平山さんと僕は似ていて、どんどんMVP、Minimum Viable Product（実用最小限の製品）を、つまり「最低の要件を定義しそれを作って市場に出して、ダメだったらどこかを変えて直す」というのをいかに早く回すかというのが、創業当初一番重要なことなのですが、このテーマは本当に文脈によるところがあります。
とはいえ、最低限のレベルはあります。
よくエンジニアではない創業者がエンジニアに対して、こういう場で聞いた話やFacebookのマーク・ザッカーバーグ（Mark Zuckerberg）の話を基に「ちゃんとやれ」とか「とにかく出せ」みたいなことを言ったりしますが、エンジニアに対して言うレベルのものと、それを実現するエンジニアのレベルというのが、きちんと釣り合っている場合はいいんです。
ですが、最低限のレベルというのが分からないまま取りあえず作るということをすると、その先は地獄です。
ですから、優秀なエンジニアには、どんなに急いでもここは守るというラインがあって、それをきちんと守れる人がそこにいるならばよいということが言えると思っています。
本当に細かい話ですけれども、昨日皆で話していた時にあがっていたことですと、例えば、早くリリースしなければならないものにバグがあって、修正して本番を直さなければならないという時に、一番早い方法は何かというと、本番サーバーにログインしてそのコードを直接書き換えるというやり方がありますが、それは僕らの世界ではあり得ない訳ですよね。
どんなに早くやったとしても、コードの管理システムにチェックインして、デプロイサーバーからデプロイする（システムを利用可能な状態にする）という、その一連の流れは作っておくというのはあります。
それを無視して、何でもいいからとにかく早くしろということで本番サーバーを直接書き換えるみたいなことはしない、そういうところに線引きをするといった話かなとは思っていますね。
松岡 なるほど。
何らかの最低限度はあって、線引きが重要だよね、でも、その線引きがどこかというのは少し曖昧だよねといった話ですよね。
柄沢 そうですね。
松岡 岩田さんいかがですか？
岩田 その「線引き」について弊社の場合について考えていたのですが、最低限テストコードはしっかり書くということや、UXなどのユーザーにとってのパフォーマンスというところは絶対に譲れないポイントがあったり、あとはCI（Continuous Integration）からデプロイしたりと、アーキテクチャーをしっかりして、ある程度そういう仕組みとしてフォローしてしまえば、それほど変なシステムはできないと思います。
例えば100行のコードが20行になる可能性があるとか、そういう細かいところまでは、状況によって見逃してもいいのかなと思います。
松岡 なるほど、ありがとうございます。
今までのお話をまとめると、作る物がある程度明確な場合は、ある程度カッチリ作ってもいいよね、アーキテクチャーはしっかり作ってコードはある程度ラフにということですね。
それ以外の、作るものが何か分からない、お客様に当てないと分からない物の場合は、ある程度最低限のラインがあるべきだけれども、なるべく最低のラインを引いた上でラフにやるべきだと。
岩田 結局プロダクトというのはどんどん成長していくものなので、どういうシステムというかアーキテクチャーがよいのかを最初に予想するのは難しいかなと思いますね。
必然的にマイクロサービス的なアーキテクチャーになるのか、お聞きしてみたかったのですが。
「マイクロサービス」的にするべきか？
松岡 マイクロサービスについて話されたい方はおられますか？
誰も目を合わされないですね（笑）。
柄沢 これに関しては、広告業界というか、山崎さんが最初に設計されたものというのは、お話を伺っていると、少しマイクロサービスっぽく作ったものかなと思うのですが。
山崎 違います。
実は弊社ではモノリシック（monolithic）な1個のシステムです。
▶︎編集注：モノリシックなシステムは全ての機能が1つのプロセスとして稼働するものであるのに対し、マイクロサービスはビジネス処理機能の単位がそれぞれサービスとして作成されたものです。あるマイクロサービスは、他のマイクロサービスとはデータも含めて完全に独立しています。ですので、他のマイクロサービスから独立して変更・置き換え等ができます。参考ブログ
僕、今のシステムを作る前に広告システムとは何かについて、1か月くらい籠って考えたんですよ。
広告システムには、当然バナーやテキスト広告や動画など色々あると思うのですが、最終的な結論としては、広告システムというのは結局、小さなテキストを自由自在に配信できる「コンテンツ配信エンジン」だという結論に達したんですよ。
なのでその「コンテンツ配信エンジン」をまず作って、その上に1アプリケーションのバリエーションとして広告システムを乗せて、その上に更に色々な広告システムを乗せたという話なので、その点ではモノリシックなんですよ。
そこの統一アーキテクチャーのようなものは、すごく考えましたね。
柄沢 なるほど。
僕も最初はマイクロサービスにしなくて、モノリシックにいこう派なので。
少なくとも、最初にマイクロサービスでしっかり設計して事業を立ち上げるというのは、ほぼあり得ないかなとは思いますね。
何をマイクロサービスにするべきかというのは、恐らく事業や組織が成長しないと分からないので、基本的には「そんなこと言っている場合じゃない」という感じではありますけれどもね（笑）。
松岡 ありがとうございます。
では、次のテーマに移ってもよろしいでしょうか。
山崎 朝から随分熱い議論になっていますね。
(続)
次の記事を読みたい方はこちら
続きは スクラム開発で革新的なプロダクトは生めるのか？ をご覧ください。
▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! ICCのYoutubeチャネルの登録はこちらから！
編集チーム：小林 雅／榎戸 貴史／戸田 秀成／横井 一隆／立花 美幸／Froese 祥子
【編集部コメント】
”Done is better than perfect.” 名言ですが、文章の内容を厳密に考えると非常に難しい。その奥深さも名言の魅力を高めているのでしょうか。（横井）
他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
