＜前編のあらすじと後編のお話＞
本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。

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

【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。

▲最近、日本酒の味を覚えたというnaoyaさん。勧められるままに杯を傾けていますが、最後まで持つのでしょうか（不安）

— naoya：チーム名のカラーネーミング（*前編参照）と関連することかもしれませんけど、2014年1月に『フリークアウト』の役員になったじゃないですか。当然、CEOからの「これをやって欲しい」という期待があったと思うんですが、具体的には何をやってくれっていう話だったんですか？

— 明石：まず言われたのは、「上場企業とか100人規模を超えた企業なんて経験したことがないので、そこの組織づくりを手伝ってほしい」ということですかね。

— naoya：組織の枠組みが若干弱かったんですかね？

— 明石：そうですね。うーん……当時は組織図もないような状態だったんですね。組織がまだできてない、なんとなくチームができてるという状態で。

— naoya：僕の持ってた『フリークアウト』のイメージもそういう感じでしたよ。ロックなエンジニアが集まってて、マネジメントらしいことはあまりなされてなくて、馬力で乗り越えていくっていう雰囲気で。

— 明石：あとは、時代の状況とか流れに対応しきれていない部分もあったりして……それまではトラフィックの増加と売上が連動してたんですよ。だけど、ちょうど僕が入る一年くらい前ぐらいから、競合がどんどん参入してきて、その中でトラフィックだけを増やせばいいという状況じゃなくなってきてました。一方で、スタートから3年くらい経って、プラットフォームとかインフラも問題をはらみ始めているような状態だったので、競合に先んじて新しいものをつくるというのもなかなか難しい。まずは、そこをなんとかしようっていうのもありましたね。

— naoya：そうか。いわゆる技術的負債がちょっと出始めてた感じですね。

— 明石：これはもう仕方がないですよ。3年くらい経ってしまえば負債も出始めます。

— naoya：エンジニアの仕事って、昔つくったものを使いながらどんどん積み上げていくものですけど、一方で時代的なトレンドがあって、数年前はなかったアーキテクチャなんかが登場したりする。そうすると、まだ技術的負債がない新しい会社の方が基本的に有利ですよね。だから、負債があるような大きい会社は、蓄えた資産や人といった体力で勝負するしかない。新しい会社は新しい技術を使えて、大きい会社は資産があって体力があると。フットワークで勝てる会社と体力で勝てる会社の競争ですね。

— 明石：そうなりますね。

— naoya：でも、大きい会社に新しく入ってきた若いエンジニアは、技術的負債に怨念を抱くじゃないですか。「君たちが今、会社の体力っていう恩恵に預かれているのは、この負債があることとのトレードオフなんだよ」といっても、やっぱりなかなかピンとこなくて、なんで俺がこんなシステムをメンテナンスしなくちゃいけないんだって憤るみたいな。

— 明石：とはいっても、そこでリプレイスかけたいサービスっていうのは、それなりの規模になってるんですよね。そのサービスにガタが来てるときは、そのリプレイスが相当シンドイんです。難しい判断も求められます。

— naoya：自分の経験でいくと2005年頃には、Web2.0とかで、どこの会社も新しいことをやってた時期なんで、技術的負債がとかレガシーシステムがとか言って頭抱えている会社は、まだ周りに多くなかった記憶があります。あれから10年経って、最近この話をよく聞くようになり…

— 明石：ちょうど一回りした感じですかね。

— naoya：ちょっと申し訳ない気がしますよね。自分たちが創ってきたものが負債となり、それで後続の人たちが困っているというのを見たり聞いたりすると。

— 明石：Webに限らず、ITとしては昔からある話じゃないですか。

— naoya：『フリークアウト』では、今の技術基盤なんかが技術的負債にならないように、そこをコントロールしていってほしいということも期待されているんですか？

— 明石：いや、僕はもう手を動かせないんで、そこは現場のエンジニアたちに考えてもらおうと。なので、負債化する前に気付かせるであるとか、問題提起するとか、そういう存在として機能できればなと。

— naoya：それこそ負債を返却しようとすると、売上とかにはインパクトはないけど、結構リソースを費やさいといけないじゃないですか。設計をもう1回やり直すとか。そこの判断って技術者出身の人しかできないんで、そういう存在がいない会社っていうのは、負債を返却するタイミングすら持てずに、ずっとビジネス主導でやって、5年後くらいに、「限界です！」みたいなことになっちゃうんですよね。CTOというか技術マネジメントが必要な理由はそこで、このタイミングで負債を返すという意思決定をし、ビジネスのことしかわからない人たちにも理解してもらわなきゃいけない。そのことを現場のエンジニアが言ったところで、「今は売上の方が大事でしょ？」とか、受け入れてもらえないことの方が多いでしょうからね。

— 明石：なので、会社がこれから大きくなるための組織の基盤づくりと、技術的なマネジメントとか、エンジニア採用とか、この辺りをサポートするという感じです。それでいろいろと動き出したのですが、人事関連では、評価採用システムをやっと1回まわしたところですね。

— naoya：それも再設計してくれっていう話だったんですか？

— 明石：評価システムは上場するために整備が必要だったため、どうしようかという話し合いが既に行われていた状況でした。

▲ホタテのヒモと卵巣は炙りとゴマ油がけ、そして脂の乗った内房の太刀魚は塩焼きでいただきます。

— 明石：『フリークアウト』に入って最初に感じた問題は、テック企業としてやってきたがために、営業サイドからはエンジニアが何をやってるのかまったくわからないということだったんですよ。ブラックボックス化していて。

— naoya：エンジニアが優秀だったがゆえのジレンマですね。エンジニアが優秀な会社って、いろんなこと任せるじゃないですか。裁量も大きく持たせて。そうすると、その他の部署の人はエンジニアリングの何が正しいのか判断つかない。数字化しづらいし。そうすると、アイツら優秀なんだから、やらせりゃいいじゃんってなって…

— 明石：それだったらまだいいんですけど、実態としては、新しいアドネットワークとつなぐことやちょっとした機能改修といったことが多くなってきていて。それで、営業が困り出していたんですよ。営業が新しい案件を持ってきても、売上が上がってこないんです。で、エンジニアは何やってんのって。

— naoya：ビジネス上の戦略の転換と、エンジニアリングの転換の歯車が噛み合ってないんですかね。

— 明石：とはいっても、営業的に確固たる戦略があるわけでもなく、全体として、どこに行こうかっていう状態だったんですね。CEOからはタッチポイントを増やしていきたいっていう話はあるんだけれど、営業なんかは特に他人事ですよね。エンジニアも意外と他人事だったりするんです。そのために、どういうことをやるとタッチポイントが増えてくるのかっていうやり方もみんな知らない状態だったので、そこで何をやったかというと、いくつかの新しい施策をプロジェクト化したんです。タッチポイントを増やすとか今ある課題を解決するとか。5つくらいかな？ エンジニアと営業を混在させたチームを作ってプロジェクト化しました。

— naoya：エンジニアと営業を敢えて混在させる。非常によくわかります。

— 明石：それによって両方の会話を増やし、エンジニアが営業の声を聴くような状況をつくりたかったんです。

— naoya：僕、まったく同じようなことを最近やったんで、そうなるよなって思いました。この組織構造がうまく回りだすと、目に見えて変わりますよね。

— 明石：営業側が持っている課題って、目の前の案件を獲るためにはどうするかっていう課題なんですね。必ずしもプラットホーム化するものじゃなかったりするので、エンジニア側からしたら、「売上より俺のコストの方が高いし」みたいな、そういう状況に陥っちゃうわけですよ。でも、「これがないと、この案件取れないから急ぎで！」みたいなオーダーが来ちゃう。で、突貫工事でつくらせるから、なんの汎用性もないし、そんなもん作らせられた日にゃあ、エンジニアは超ストレスを感じますよね。で、1回そういうのを受けると、次にほんのちょっとだけ違う似たような仕事が、また入ってくるんですよ。

— naoya：それを解決する方法は何か、僕も悶々と悩んだ結果、解決策としてみつかったのは、営業や企画とエンジニアを一つのチームにして、常に一緒に行動させて価値観を共有させるっていうのが、まず重要なんじゃないのかなと。隣の同僚が何をやっていて、どういう価値観で動いているのかを理解させて、さらにそこにちょっと先を見据えたミッションを掲げてもらう。それにチームとして一緒に当たらせると、まあまあ上手くいく。この辺の組織構造いじるってマネジメントでしかなしえないことだと僕は思ってて。現場の人たちが勝手にその領域に到達するなんでことは、まずないですから。

— 明石：営業とエンジニアってプロトコルが違うじゃないですか。それをお互いが合わせない状況。でも、組織ってやっぱり人と人なんで、その人と人とがコミュニケーションをとれる状況を創り出して、信頼し合える状況をつくってあげるというのは、マネジメントの役割かと…

— naoya：いやあ、すごく共感します。ようやく同じ話ができる人と巡り合ったって感じですｗ 僕は今日、明石さんとお話しするまで、どういうマネジメントをされる方なのか、想像すらできてなかったんですが、僕個人の価値観からしても、とても共感できるマネージャーだなあと。営業とエンジニアのプロトコルを合わせてあげるのがマネジメントの役割ですという話を何の前提もなく聞けるというのは、今までやってきて非常に珍しいことで。

— 明石：いやいや、よくある話ですよ。

— naoya：基本的には営業とエンジニアリングって、放っておくと逆を向いちゃう性質のある職業だから、現場の人たちだけで同じ方向を向くっていうのは、確率として相当低いんですよ。それを向いていくように組織の構造を調整するってなると、それはもうマネジメントの仕事だと僕は思ってて、自分もそういうことをよくやるので。でも、それを今まで人に説明しても、みんな、何の話してんの？って顔されてきたから。今日こうして話ができるのは、大先輩に向かって僭越ですけど、話が通じる人がいた！って感じなんです。

— 明石：ｗｗｗ

— naoya：今の話で僕が驚いたのは、会社を移ってすぐにそれをやれるような状況をつくれていたっていうことなんですけど、これは経験の賜物なんですか？

— 明石：そこだけはトップダウンにしちゃったんです。CEOのメッセージとして落としてもらったんです。

— naoya：ああ、なるほど。僕『Kaizen Platform, Inc.』では、やれたんですよ。ていうのは、僕が企画側のリーダーと仲良かったんで、こういう体制にした方がいいよねっていうことですぐにできたんです。でも、いつもそう上手くいくわけでもなくて。とある別の会社では、エンジニアがまとまってなかったんで、それをまとめるのに1年くらい費やして、じゃあ次はどうやってビジネス側の人たちと同じ方向を向いてもらうかってことで四苦八苦して。ちょっとビジネスの方が強かったんで、なかなか体制を切り替えるっていう話にまとまらなくって…

— 明石：まず自分が壁にならないとダメですよね。

— naoya：そうなんですよ。でも、そこでは僕は外の人間だったんです。だからトップダウンで落とすってことをやってもらわないとダメかなあって。でも、それが正しい手法なんだなってことが今日わかりました。自分の経験上、1～2回しか上手くいってないから、それが汎用的に正しいやり方かどうか、ちょっと判断つきかねてたんだけど、それが解消された気がします。

— 明石：状況によると思うんですけど、エンジニアと営業とのコミュニケーションを増やすことと、経営陣が言っているビジョンに対しての道筋っていうのを個人で経験してもらう。あとは自分たちが考えてモノをつくってると思える環境に整える。この3つくらいですかね。

— naoya：ビジネスとエンジニアを一体化させて、どういう組織構造にしたんですか？

— 明石：組織化したわけじゃなくって、組織としてはセールスとエンジニアのラインがあって、それに対して横ラインでプロジェクトというマトリックスをつくったんです。

— naoya：プロジェクトが組織をまたぐ？

— 明石：そういうことです。さすがに全部ひっぺがして、君はこのプロジェクト専任だよってできる状況だったら、イニシアチブごとの組織作っちゃったと思うんですけど、それやるとビジネスが終わってしまうんで…

— naoya：じゃあ兼務の人がいっぱいいて複雑なことになってるんですか？

— 明石：兼務というか、イニシアチブって新しいものを創ることなので、今の業務を継続しながらそのイニシアチブもやるみたいな。外しちゃうと本来の運用業務も何もかも止まってしまうので、組織としてはそのまま置いといて、マトリックスとしてプロジェクトを走らせる。それと、プロジェクトって時限的なものなので、それを組織にしてしまった瞬間から仕事になってしまう。それはよくないですから。

— naoya：さっきの技術的負債の文脈じゃないですけど、エンジニアリングチーム全体でやんなきゃいけないミッションがあって、一方でビジネス側とクロスでやんなきゃいけないとなると、本当は両方がハイブリットな環境で存在してるのが一番いいと思うんです。確か『クックパッド』もなんか似たようなこと言ってて技術とビジネスとクロスして、評価基準も両方に置いて、個人がどっちに軸足を置くかは自分で考えろっていうようにしたとかなんとか。

— 明石：それも悪くないと思いますが、評価のための仕事になってしてしまう可能性を忘れちゃいけないですよね。

▲日本酒は早くも三種類目に突入。名古屋の銘酒として知られる「醸し人九平次」が片口に注がれていきます。

— naoya：あれ、なんでしょうね。評価システムをつくると、人は評価のために働くっていう…

— 明石：だって、みんなお金がほしいからｗ

— naoya：いや、それはそうなんですけどねｗ

— 明石：人として、お金はあるに越したことはないから。

— naoya：いや、僕は一番ビックリした話が、KPIってあるじゃないですか。あれを決めると、時としてモラルハザードが起こるんですよ。たとえば、売上だけがKPIだってなると、社員はみんな売上を最大化するぞってなって、それこそ画面全部広告にするみたいなことが起こったりする。

— 明石：やるやるやる。

— naoya：それやったら、よくないことたくさん起こるって、誰が考えてもわかるんですけど、やっちゃうんですよ。

— 明石：経営陣って、実はモラルはあるだろうっていう前提で落とすんですけど、現場に落ちた瞬間に、KPIだけになって走り出しちゃうんですよ。

— naoya：僕はそれが逆に不思議というか、想像と違っていて、KPIはこうでも信念はみんな曲げない、モラルに維持される部分はあるって思ってたんですけど。組織全体でみたらモラルがなくなるときがあるんですよね。

— 明石：さっき、企業ビジョンの話をしましたけど（*前編参照）、そもそもビジョンがあって会社が成り立っているわけで、その上にKPIがのっかった時に、ビジョンに反する行動ってどうなのよ？って話ですよね。まあ、一応、企業ビジョンやミッションが正しい前提だとしたら、それを守るのがその会社にいる自分の存在意義なんです。且つ、今は売上頑張らなきゃいけないから、売上をKPIにしよう。でも、ビジョンが土台にあるんだから。それ忘れんなよ！のはずなんですよ。会社って。

— naoya：でも、みんな忘れるじゃないですか。KPIが下りてきたら。結局、目標を数字ではっきりさせすぎると、よくないことが起こるんですよ。どう頑張っても。例えば売上をKPIにすると、広告で画面を埋め尽くすようなことが起こり、ユーザー数をKPIにすると友達紹介キャンペーンに高額インセンティブみたいなことが起こり。どれをKPIにしたって、結局、トレードオフのネガティブな部分が大きくなってしまうというか。

— 明石：でも、それを第三者的に眺められるって、僕ら的な立場しかいないだろうなって。

— naoya：いや、だから僕は、数字目標を立てるっていうことが、そもそも間違ってることなのかなって…

— 明石：いや、間違ってないですよ。その数字が間違ってるだけで。

— naoya：そっか。

— 明石：KPIが間違ってるか、足りないんですよ。

— naoya：それは複数のKPIを設計すればいいってことですか？

— 明石：うん。これを落とさずに、これを保つ。とかやらないと。

— naoya：そうすると、僕がちょっと、うーんって思っちゃうのは、KPIをマネジメントが正しく設計できない限り、よくないことが起こっちゃうってことで、それってマネジメントが神の視点を持たないといけないことになるのではと…

— 明石：違います、違います。そこは企業としての原点を考えましょうと。全社員が理解した上でやらなきゃいけないんだけど、人が増えるとそういう状況はできないので、KPIを複数持たせる必要もないんです。会社のビジョンはこれです。これをわかった上で、このKPIを達成しましょう、なんです。

— naoya：わかります。だからビジョンっていうものが、そこではじめて重要性を帯びて浮かび上がってくるんですけど…

— 明石：だから、あの『グーグル』のスローガンっていうのは正しいんじゃないですか？

— naoya：「Don't be evil」ですか…

— 明石：彼らは、知っているんじゃないですか？ 彼らの影響は大きいので、自分たちが神にでも悪魔にでもなれるっていうことをね。それは、教訓でもあるわけですよ。と、勝手に解釈してますｗ

— naoya：そうなってくると、土台になってるミッションっていうものを、みんなが疑っている状況は…

— 明石：よくないですね。

— naoya：いや、なんか、コーポレートビジョンを創ろうとか、スローガン掲げようとかって、結構二の次にしてましたけど…

— 明石：うん、重要ですよ。それが、わかりやすくって、でもピンポイントじゃなく、そのビジョンに対して個人個人が想像できる、考えられるようなものであると、よりいいですね。いろんな方向性があっていいと思うんですよ、そのビジョンを達成するためには。

— naoya：共感を呼ばなければいけないし、カバレッジも広くなきゃいけないし。

— 明石：なので難しいんだと思います。

▲いよいよ握りが登場。肝を乗せたカワハギと大間のマグロの中トロです。

— naoya：ところで、明石さんって、開発プロセスとかどうするかって、そこら辺のマネジメントってされてますか？

— 明石：今はしてませんね。現場に任せてます。『ヤフー』にいた頃はアジャイル頑張ろうよ！って啓蒙してたことはありますけど。そのときはたまたま、アジャイル・マスター、スクラム・マスターのエンジニアが入ってきて、その人がすごい意志を持ってたから、じゃあやろうかって。でも、まあ、開発言語をどうしようかなんてことは現場が決めるべきことであって…

— naoya：じゃあ、プログラミング言語なんかの取捨選択は？ なんか、別のインタビューを読んだら、割といろいろ使ってますよ、みたいなことが書かれてあったんですけど。

— 明石：「50mm/sec or die」じゃないですけど、やっぱりPerlが中心ですね。

— naoya：そのPerl。ここから先、どうするつもりでいます？

— 明石：Perlは…

— naoya：いや、もともと僕、ずっとPerlやってたから聞いてみただけなんですけどね。

— 明石：どうする、こうするっていうより……場所によるんですよね。フレームワークと開発した成果物の問題なので、Perlに合ってるところではPerlを使うべきだと思うし…

— naoya：一方で、エコシステムとしては他言語に比較しても過去の勢いはもう見られないじゃないですか。どこかで切り替えないと、OSSのシステムに載れなくなっちゃいますよね。

— 明石：そうですね。社内でも考えてもらっているテーマのひとつですね。

— naoya：最近、それでScalaなんかを使い始めてる組織も増えてきてますよね。でも、世の中に対するメッセージングの歯切れはよくないですが。「Scalaも使ってますよ、PerlもPHPも適材適所で使います」って。でも、そろそろなんとかしないといけないっていうコンテキストが見え隠れする感じはあります。

— 明石：正直、採用のことを考えると、言語って重要なんだと思うんですけど、ただ、僕は言語ってやっぱり適材適所だと思っていて、別にそれが最適なのであればずっと使っていればいいと思うし。何を使ってるからウチはすごい！とかって、僕はあんまりそういうのは好きじゃないんですよね。

— naoya：それは僕もそう思いますし、自分の会社のことだけを考えると、そういう結論になるんです。でも、マクロに見た場合って、新しい技術にトライできる人たちがやっぱり有利じゃないですか。新しい技術を使う新しい会社が、新陳代謝的に古い会社を駆逐していくっていうのが、それは止まらないなと思いつつ、自社のことに目を向けた時に、いかにその流れに抵抗するかってことを考えると…

— 明石：うーん…

— naoya：マクロな新陳代謝の流れではうちの会社は淘汰されて当たり前なんですよ、とは言えないじゃないですか。だから、動き出さなきゃいけないのかなって……結構、重たい問題なんですよね。

— 明石：うん。まぁ……重たい問題というか……でも、正直、エンジニアのヤル気の問題だとも思うんですよ。

— naoya：あらｗ

— 明石：なので、現場が考える問題だっていうのは、そこなんですよ。これね、トップダウンでやらせると、一生終わんないんですよ。現場が、これ変えなきゃダメだっていう状況に追い込まれないと。

— naoya：最終的には本人たちに決めてもらうっていうのは、僕も同意なんですけど……悠長なことやってると、負ける側にすぐ行っちゃうわけじゃないですか。業界全体のマクロ視点では、そういう新陳代謝は進んだ方がいいし、でも、ミクロ視点では、ウチの会社は勝てる側に行かないとダメだっていうのがあり……言語って適材適所でしょ、って言ってられないな、というのが実感なんですよ。

— 明石：なるほど。

— naoya：昔よりもサイクルが早くなってきているから、最近はそこの意思決定をテキパキやっていかないと、なんかまだ大丈夫ですとは言ってられないなと。Perlは特に日本だと、なんだかんだ言って使い続けている会社が多いから、まあまあシビアな話だなって。

— 明石：あの……多分……Perlのエンジニアほど、Perlにこだわってないっていうのがあって…

— naoya：そうなんです。

— 明石：みんなは、Perlをよく理解しているからこそ、Perlにこだわっていないんじゃないかな？

— naoya：そうですね。ただ、もし仮に個人がいつ捨ててもいいやって思ってても、会社はそれでやってるとしたら…

— 明石：会社の資産全部がそうだから、そこに対して、頑張るのか頑張らないのかという選択が迫られてるということ？

— naoya：そうなんです。だからこそ、マネジメントが、どっかで決断してあげないと、現場の人たちだけでは決められないこともあるだろうなって。

— 明石：一人じゃ無理だけど、まあ三人から声が挙がったら、トップダウンするかもしれない。でも、限界はあるので、無理な状況が来たら、もうトップダウンで行くしかないのかな。

— naoya：そうですねえ。これは別に特定の言語に限った話ではないですよね。いまデファクトといえるRubyも、5年くらいで同じ状況に立たされるかもしれないじゃないですか？

— 明石：なので、その新陳代謝は常にあると思って開発を続けるのが僕たちの仕事であって。

— naoya：その新陳代謝にうまくのっかるためのフレームワークというかセオリーをつくれたら、結構ハッピーになれるなとは思っているんですけどね。古くなったシステムをどうやってスムーズに次世代に切り替えていくかっていう。そのやり方と言うか考え方というか……でも、今のところはなんか市場の競争原理にさらされて、そういう人たちは負けて終わりでしょ、っていう結論にしかなってないから、これはあまりハッピーじゃないよなって。いや、このことがね、冒頭の話にもつながるんですけど、そういう意思決定を迫られるような場面に立たされているWeb企業のマネージャー世代っていうのは、ある意味、最初だと思うんですよ。

— 明石：うん。

— naoya：10年、20年やってきて、レガシーになってしまって、IT業界のほかの領域の人たちに比べると新しいことやってる人たちだったけど、ある程度年数経ってみたらレガシーを抱えるようになってしまい、さあどうしますか？っていう選択を迫られていて、答はまだないっていう。

— 明石：さっき、IT全般で言えることって言ったんですけど、ITっていうものができたときからずっと課題ではあるんですよね。Webだけじゃなくって。問題は、10年も経つとシステムがシンプルじゃなくなっているということなのかな。シンプルなまま成長できる仕組みをつくれれば、一番最高なんですけど。だけど、やっぱりビジネスだとか競合他社の状況によって、わけわかんない機能を入れてしまったりだとか、一時をしのぐための機能を入れたりだとか。で、それらの機能を全部理解している人がいないだとか。なので、本来は常に新陳代謝を続けていくべき。それだけのリソースを割いていくべきなんです。企業として継続していくために。

— naoya：そうですよね。

— 明石：そうあるべきなんだけど、やっぱり目先のこと、日々の運用だったりに追われてしまっているのがエンジニアの状況。そういうこともなくして、いかにシステムを常に健全な状態にしていくか、というところをエンジニアリングにはミッションとして持たせていくべきでしょう。『フリークアウト』も3年ほど同じ環境・仕組みですから、結構、重たいテーマです。

— naoya：ホント、サイクルが短くなってきてますよね。

— 明石：なので……僕たちの仕事って、リリースしたその仕組みがどうであった、その瞬間に、先に起こるボトルネックを発見して、この先こういう問題が起こるから、それに対しての解決策をこれから考えようよ、というところをエンジニアに対してやるべきなんです。リリースした時はその時の最適な技術です。でもそれだと、この先、こういうボトルネックが起こるから、そうなる前に次の対策を考えておこうと。そのことを常にエンジニアに対して言い続ける立場でもある気がしてます。そうすると、循環が生まれるはずなんです。でも、そんなことリリースの時に言われても、たいていリリース後にいろいろと火が噴くんで、火が噴いたら僕たちの言葉も一緒に燃えてしまうｗ だからこそ、キチンと言い続けていくべきなんです。でも、実際は何年もコミットし続けていかなきゃならないんで、そうもいかないところはあるんですよね。

— naoya：そうなんですよね。

— 明石：だから、そういう環境づくりっていうのが、本来の僕らの仕事なんだと思います。世代づくりと環境づくりですね。

▲「魚は自分で釣ったのが一番」と言っていた明石さんにもご満足いただける味だったようです。

— naoya：一方で僕、最近、逆の側面もあるなと思っていて。近頃は適当に創っていると、コードベースが古くなっちゃって、メンテナンスできなくなるというのをみんな痛感してるからか、最初からちゃんとつくり過ぎているというか。

— 明石：そうすると、リリースまでに時間がかかりすぎるという問題？

— naoya：そうですね。本来はいろいろ試行錯誤をしていくべきだと思うんです。でも、一番最初からちゃんとしたフレームワーク、ちゃんとした技術で、ちゃんとしたやり方でやらないといけないっていう強迫観念が強すぎて、それで逆に機会損失している人たちも見かけるんですね。そんな人たちになんて言ってあげたらいいのか…

— 明石：でも、それはアーキテクチャの問題だと思うんですよ。発展できるアーキテクチャってあるじゃないですか。

— naoya：そうなんですけど、結局、発展できるアーキテクチャって、それなりの経験積んで、それなりの知見がある人や組織じゃないと、正しいやり方がなにかっていうことを、それこそ選択できないですよね。エンジニアが高いレベルを要求され過ぎて、リリースが遅れるということが起こっている局面を、まま見かけるんです。もっとレベルの低い会社だったら、コピペでとりあえずつくればいいやってリリースできたはずなのに。

— 明石：はいはいはいはい。

— naoya：これって、結局、バランスをとらなきゃいけないっていう話にしかならないんですけど、技術的負債を積み重ねていくと大変なことが起こるってことを、みんながわかってしまったがゆえに、臆病になってるってことですかね。スタートアップって負債積み重ねてること多いじゃないですか。最初、とりあえずキレイなコードじゃなくてもいいから、リリースすりゃいいじゃんみたいな雰囲気の中で、それやると後で大変なんだって言って、慎重になってる人たちも見かけるんで…

— 明石：そもそもサービスが複雑化しすぎちゃってるんだと思うんです。

— naoya：それもありますよね。

— 明石：やっぱり発展するサービスって、シンプルなんですよ。

— naoya：僕としては、何か新しいものを創り出す側の人は、そんなこと気にしないで、技術的負債とか積み重ねることになっても構わないから、まずやりたいことやればいいんじゃないって。

— 明石：それは基本ですよね。

— naoya：業界全体としては、やっぱり負債を積み重ねるのはよくないっていうことで、少し臆病になっている。

— 明石：そういう意味だと、ステージによって違うんだなあと。

— naoya：それは僕らの観点からするとそうなんですよ。ただね「技術的負債をつくっちゃいけない」ってそこだけを切り出して話しをすると、それはあまりにも正論じゃないすか？

— 明石：正論だし、負債はつくらないに越したことはないんだけど、どんなにきちんと作っても負債は100％出るんだから。なので、その負債をなくすサイクルを創りましょうよと。

— naoya：もちろん、キレイなコードの方がいいに決まってるんですよ。

— 明石：でも、キレイなコードを書いても、その言語がなくなる可能性だって十分あるよ。

— naoya：いや、わかりますよ。だけど、キレイなコードがいい、技術的負債がないほうがいいっていうエンジニアの正論に対して、いや、きたなくてもコピペでもいいから、動きゃいいじゃんっていう妥協案はなかなか正面から言いづらい、そういう話をしてます。

— 明石：もちろん、メンテナンス性を高めるには、キレイな方がいいですよ。

— naoya：ビジネスで勝つためには、きたなくても目をつぶった方がいいっていうときもあるけど、それは例えるなら「信号無視してもいいから、急いだ方がいい」っていうことと同じなので、そんなこと言ったら世の中から批判を受けるに決まってる。みんな石を投げられるのは嫌だから、キレイなコード書いた方がいいとか、技術的負債はなるだけ少ない方がいいとか言うんだけど、でも、僕は必ずしもその正論が正解じゃないと思ってるんです。例えば、テスト駆動開発、スクラム、DDDとか、いろんな方法論があるんですけど、方法論が行きすぎるとろくなことがおこらない。

— 明石：アウトプットにこだわってない、と。

— naoya：そう。方法論にのっとってキッチリやることの方が正しいっていう正論に、僕はちょっと、水をかけたいと思うときがあります…

— 明石：いやいや。だとしたら、それはお互い理解すべきだと思ってて、アウトプットにもこだわってもらわなきゃいけないし。後々のことを考えて、ちゃんとつくらなきゃいけないし。

— naoya：お互いが理解しなくちゃいけないのはわかります。けど…

— 明石：どちらも正しいんですよ。スタートアップだったら、もう、ガンガン行けばいいし。

— naoya：それに対して追い風というか、それでいいんだよって肩を押してあげる人がもっとたくさんいてもいいのになって思いますよね。

— 明石：スタートアップで別にきっちりした開発をする必要は全然ないと思う。もっと手軽につくって、やってみて、そっから先、苦労すればいいんだよ。その苦労が楽しいし、エンジニアの経験になるんだから！ｗ

— naoya：そう、そうですね……まあ、結論は出ないですけどね。お酒も入ってますしｗ

▲今回の#naoya_sushiはここでおひらき。すっかり酔いがまわったnaoya氏は上機嫌そのものでした。