「見積もれ」には「わかりません」で答えた
Hacobuがフルリプレイスを成功させるまでの道のり

HacobuのCTO

ーーまずは戸井田さんに、自己紹介をお願いしてもよろしいでしょうか。

戸井田裕貴氏（以下、戸井田）：僕は、そもそものキャリアでいうとソーシャルゲームの開発が長くて。2011年から丸6年ぐらいなので、まさにソーシャルゲームバブル、スマホバブルがあったあの超加熱していた状態で、その時トップランナーだったgloopsという会社で、ソーシャルゲームをバンバン作っていました。そこの新規プロダクトのリードばかりをやっていた経緯があって、完全にスタートアップでというか、ハードワークをしていたエンジニアです。

そのあともCandeeというスタートアップで、ライブ動画配信サービスの立ち上げを1年半ぐらいやって、toCはやりきったかな？みたいな。いろいろなチームを見ていろいろなプロデューサー、ディレクターを見て、一通りやりきったなと思ってtoBの会社を探していました。それでHacobuに出会って、ビビビときて入社を決めました（笑）。

（CEOからは）「MOVO2.0という構想があるんだけど、これできる？」って言われて。確か「余裕です」みたいな回答をした記憶があります。CEOに「どんな視点で、自分が働く会社を見ているの？」って聞かれて、ストレートに「何をするかよりも誰と働くかです」って答えました。そしたら、次の面談で、取締役の2人と当時在籍していたすべてのエンジニア10人に会わせてもらえて。いろいろな企業をみてましたが、ここまで振り切った面接はなかったので、とてもポジティブなエピソードとして僕の中で残っています。

ーーありがとうございます。今の肩書き的にはCTOですか？

戸井田：そうですね。執行役員 CTOとして、テクノロジー本部というHacobuの開発組織を統括しています。

ーーCTOはHacobuが初めてですか？

戸井田：初めてです。EMはそのソーシャルゲームの会社の時にやっていましたが、CTOは初めてです。

ーーなるほど。では、日本CTO協会にはHacobuに入ってから？

戸井田：そうですね。当時は同じぐらいのタイミングで、日本CTO協会が組織を作られていて、情報がほしかったのと、CTOの友だちがほしかったので。「みんな同じような悩みを抱えているんだろうな」と思って、出来立ての時にパッと入った記憶があります。

日本CTO協会の理事

ーー広木さんはそのCTO協会で理事もやっていますが、簡単に自己紹介をお願いできますか。

広木大地氏（以下、広木）：はい。広木です。僕はもともとミクシィという会社にいて技術系のスペシャリストをやっていました。ミクシィも、SNSサービスが落ち込んできた時に、「会社自体も立て直さなきゃいけないよね」というタイミングで、僕がその立て直しのプロジェクトなどを行って、経営やビジネスも見ていくようになっていきました。

そこからマネジメントのキャリアとかも歩むようになって、組織をより良くしていくとか、それによってイノベーションを生み出せる組織にしていこうというようなことをやっていたりしました。運良くいろいろなヒット作が生まれたりして、会社は再成長していったので、僕は「そろそろ休もうかな」と思って退職しました。

（一同笑）

新卒で入る会社の期間としては7年ぐらいで、小学校より長くて、もうそろそろ別のところに行ってもいいのかなと思って。しばらく声をかけてもらったいろいろな会社の手伝いをしているうちに、やはり技術と経営の間のところにメチャクチャ課題があるなというのがあって、そこを解決するために、CTOのメンバーでそういった技術・経営の課題を解決するような会社を作りました。今はそのレクターという会社をやっています。

これに関連して、もともとはミクシィ時代や、ミクシィを卒業したあともCTO仲間たちを集めていて、「この中でしゃべったことは忘れてね」という秘密の勉強会みたいなことをどんどんやっていました。そうしたらサイズがどんどん大きくなっていって、これを運営する母体をまた別に作らなきゃいけないよね、というところでCTO協会を設立。今は個人会員が800名近く、支援してくださる法人会員が100社近くあったりします。

こういうところで、僕らとしては（戸井田さんが）言っていたように、CTOは孤独な職業でもあるしいろいろな意思決定で悩むこともあって。その場に行けば、同じような苦しみというか大変だった時代を過ごしてきた人がいて、そういう人たちが交流できる場所があったらいいのにね、というのが最初のストーリーです。

そこからも大きくDXという悩みが起きてくる背景の中で、やはり置いてけぼりにされちゃう開発者や、その開発者を内部で持つことの効率性をどうやって追及していくかという部分について、もっと多くの人に届けなきゃなということで、そういった社団法人化をして行政であったりとかあるいはいろいろな発信とかイベント活動ができるように、今は一般社団法人でやらせてもらっています。そういう背景になります。

Hacobuのフルリプレイス

ーー今回のフルリプレイスの話にこれから入っていくんですけど、そもそも広木さんがHacobuさんのフルリプレイスを聞いた時は、どういう感想だったんですか？

広木：フルリプレイスをやろうとすることはあれど、やりきるのはけっこう大変なことだな、と思っています。古くなってしまったアーキテクチャを新しく作り直す決断って、新規機能の追加を止めないといけないし、全部移行しきらないといけないから。しかもそのあと、その投資分だけ回収できるような仕組みを立てないといけない。

だからなかなかやろうと思っても、やりにくい部分はあるんですよ。それをけっこう組織が大きくなりきる前に移しきったというのは、なかなかできないことというか。中途半端になってしまいがちなので、聞いた時に「え？　やりきったの？」みたいな。

（一同笑）

まず「すごいな」と感じました。よくあるケースとしてはフルリプレイスと言いつつ、半分ぐらいのリプレイスで終わって残っちゃう部分があって、そこが長いこと足を引っ張ったり。「1年でやります」と言ったけど、2年半とか3年半かかっても終わらないようなこともけっこう聞く中で、それをやり切った話を聞いたので「大したものですね」みたいな。

（一同笑）

ーーそれって珍しい話なんでしょうか？

広木：そうですね。本当に小さかったら、たぶん作り直すこと自体はあり得ると思うんです。数人でやっているサービスが、ある程度当たり始めていたら「ゼロから作り直しましょう」とかならまだわかるんですけど、ある程度大きくなってある程度サービスのラインナップもある中でリプレイスをしかけるというのは、体力がないとできない。先ほど「ハードワーク」と言っていたけど、ハードワークなんですよ。

（一同笑）

戸井田：そうですね、ハードワークには割と耐性がある方なんですが、今まで経験してきたどんな仕事よりもハードでした。

広木：なので、そこをやり切れるというのは、けっこうエグゼキューションの部分が大事で。アイデアとか考え方の部分は誰もが持っているんですけど、「セカンドシステム症候群」という言葉がよくあって、「次に作り直すんだったら良くできるはずだから作り直したいんだよ」とみんな思って、そこにいろいろな夢とか希望を詰め込んでしまった結果、夢と希望が詰まりすぎてしまって完成しない。

あるいは、完成しても思ったとおりにはいかないみたいなことが、言葉としてはあるぐらいに、この界隈では新しいものを作り直すということに対しては、「まあ、そういう考え方もあるよね」と言いつつも次善策を考えていくという、大人的な振る舞いになってしまっている部分もあって。

一方で、自信だけのカラ自信というか、本当の実力に伴わない自信だったりすると、やろうとするとそこでこけてしまって、「途中までやったから退職します」という感じのケースをけっこう見ていて。だからそういうフラグはビンビンに立っているのに、やり切っているという話を聞いて「なんで辞めていないんだろう」ぐらいの感じで、すごいなと思った感じですね。

（一同笑）

戸井田：辞めるという選択肢があったんですね。いま気づきました（笑）。

（一同笑）

ーー戸井田さんにお聞きしたいのですが、今の話でも出てきたように、フルリプレイスをしない、あるいは少しずつごまかしながらやっていくことも考えられたわけじゃないですか。でもここで、あえてそのフルリプレイスをするという判断を下した理由はどこにあるんですか？

戸井田：一刻も早く理想の開発組織とスケールするシステムを具現化し、その先の構想に向け走り出したかったからです。何よりも時間です。Hacobuは時間をかけているフェーズじゃなかったので、少しづつ行う方法は選択肢としてとりづらかった。後は、3つのプロダクトの中身をマイクロサービス化し、統合していくという完成形は想像できていたので、出来ないことはないというのが一つ。リスク算定に関しては、最初に行うのではなく、走りながらの方が精度があがるし効率が良いというのが一つ。一番大きかったのが面接を通して会った仲間となら良いチームを作れると思っていたことです。なので、これはやるかやらないかの問題だと思ってました。

ただ実際にHacobuに入社し、いろいろ進めていく中で、少しづつ青ざめていきましたね。入社したてのイチエンジニアが、既存の組織構造を変えにいくというのは、予想以上に大変なミッションであるというのと、思った以上に既存のシステムがカオスってるなーという印象で、予想の3倍カオスってました（笑）。

（一同笑）

戸井田：3つプロダクトがあったんですけど、各プロダクトで利用されている技術スタックがバラバラだったんですよね。一部プログラミング言語が一緒のものもあったんですが、利用されているWEBフレームワークが違っていたり、ORMが違っていたり、ソフトウェアアーキテクチャの書きっぷりも大分違っていました。

後は思っていたより3倍ドキュメントが足りなかったです（笑）。各プロダクトの仕様の詳細は特定のメンバーの頭の中にのみあるという状態。解決したい課題や要件定義に至る背景等もしっかりとは残っていなかったです。なので、これは文字通りゼロベースでやらなきゃならんなと、ちょっと身震いしたのを覚えてます。

ーーそこで、逃げ出そうとは思わなかったんですか？

戸井田：その選択肢があることに気づかなかったです（笑）。プロダクト開発を通して誰かの課題を解決するというのが、自分の幸せかもというのがあり、それをHacobuで実現したかった。目の前に大きな壁はあるけど、まぁ突破すればいいかなと。その先にやりたいことがたくさんあるから、そういう視点でしたね。

やりたいことの手前に課題があって、それはしかも解決可能であるという手応えはあったので。過去の経験からすると「まぁ、いけるでしょ」みたいな、ということで、まずは突っ込んでいったという感じですかね。最初はかなり楽観的に入りました。どんどん悲観的になりましたけどね。

（一同笑）

ーー戸井田さんがおっしゃっていた「社会の課題を解決したい」というのは、エンジニアとしてみたいなものなのか、例えばCTOとしてというものなのか。そこらへんはどういうものですか？

戸井田：どっちでしょうね。エンジニアとしてチーム開発することが好きだったので、すごい楽しいし、チームで何か共通の目的を解決するということがけっこう幸せの根幹だと思っていて、なのでそこが中心にあるのは間違いないです。

（前職で）チームとして開発をする楽しさはtoCで理解できたので、あとはその活動を通して顧客の課題を解決したかった。そうすれば最高にハッピーだろうというのと。

一方で、（前職までは）トップじゃなかったので、もっとこうしたら良いのにというのは実現できなかったんですよ。なのでCTOになったからには、それを思いっきり全部やりたいなとは思っていましたね。

だからこういう組織でこういうチームで、こういう文化でこういう開発をしたらどうなるんだろうと。それの答え合わせがしたかったし、そこの答え合わせの先に、良いチームとプロダクトができて顧客の課題を解決できる感覚もあったので、ここは気合い入れてやってやろうと、そんな感じでした。

ーーエンジニアの中ではやはり「プログラムだけをやっていればいい」と思っていたりする人もいるわけじゃないですか。でもそうではなくて、今はチームをまとめてやることに喜びを感じたというのは、それはある意味CTOとかマネージャーとかだったりそういうことにも向いているのでしょうか？

戸井田：マネージャーに向いているというのはまわりから言われ続けていたんですけど、僕はそこまで思っていなくて。本当は最前線で誰よりもコードを書いていたいんですよ。でもチームで働くことも好きだったので、そういう感じのリードエンジニアをずっとやってきました。教育に苦手意識があるというのもありました。育つ人と育たない人が極端だったので、そういった意味で向いてるとは思えなかったですね。

ただ、「向いているよ」とずっと言われ続けていたから、Hacobuでそういうことをやっても、そんなに迷惑をかけないだろうな、みたいなことはありましたね。ただ、未だにそんなに向いているとは思っていないですね。僕より良い人はいっぱいいるだろうなと（笑）。

（一同笑）

ーー広木さんにおうかがいしたいのですが、今の話のように、CTOに向いている・向いていないってあったりするものなんですか？

広木：大事な素質は「逃げないこと」だろうなと思っていて、それがその今の「逃げ出したりしくなかったんですか？」って聞いたら、「そんな選択肢ってありましたか？」みたいな感じだったので。

（一同笑）

それが何よりもなんじゃないですかね。

最初にぶち当たった壁

ーー逃げ出す話でいくと、開発をしていく・リプレイスをしていく中で、当然壁がいろいろあったと思うんですけど、その最初にぶち当たった壁って何だったのでしょうか。

戸井田：技術スタックがバラバラだったので、コンウェイの法則じゃないですけど、要するにチームでコミュニケーションがそんなに取れてないだろうなというのがシステムから読み取れました。なので開発チームというより個人で戦っている印象があったのと、僕がポッと入ってきて「こういうことをやりたい」と言っても、最初は「へー」くらいの感じでした。そこが最初の壁でしたね。

なので、そこから対話をし続けました。僕もそうでしたけど、エンジニアは基本的にエンジニアの話しか聞かないので、なのでエンジニアとしての実力も証明しつつ、会話をして考え方を伝えていくみたいな。それと同時に、経営チームにも伝えなきゃいけなかった。「なんでスクラム開発なのか」「なんでこのアーキテクチャで、なんでこのプログラミング言語なのか」といういろいろな「なんで？」に対して、全部「こうだから」と。「こういうことをしたいから」「それで、できるの？」「はい、できます」みたいな。「いつころできそう？」「わかりません！」みたいな（笑）。

（一同笑）

ーー今言ったバラバラだったところをまず乗り越えるために、最初は組織を変えたとか？

戸井田：そうですね。まずは、開発組織を変えることが大事です。

ーーそれは「組織＝アーキテクチャ」というのがあったんですか？

戸井田：それもそうだし、チーム開発が基本だと思うんですよね。チームが良ければ良いプロダクトが生まれてくるので。先ほど言ったように、個人で戦っている印象があったので、まず良いチームがないとそこにリプレイスするプロダクトを任せられない。3つのラインナップがあったということは、3つの良いチームが必要だった。

良いチームがいるということは、良いリーダーがいて、それをフォローする良い仲間がいるみたいなものを作るには、組織をガラッと変えて、今まで引っ張っていた人をガッと降ろしたり、文化はこうだ、心理的安全性はこういう意味だ、みたいな感じで共通言語を作っていくのが、最初の取り組みでしたね。

ーーそれはけっこう意識から変えていくみたいなところになってくるんですか？

戸井田：そうですね。ただ意識改革をていねいに進めた記憶はないので、みんながついてきてくれたんだと思います。ありがたや。

（一同笑）

ーーでもそれに対して「イヤです」と言う人たちとか、あるいは「ちょっとわからないです」みたいな人たちがいたりとかしたんですか？

戸井田：まあ、いたんじゃないでしょうか。今までの組織が変わるということは、今までの立場が変わってしまうので、それが良い時もあれば悪い時もあるじゃないですか。現状維持バイアスは常に働いているので、その現状維持バイアスに対してのストレスや不満はあったし、最初はそこでしたね。「これは俺が受け止めるものなんだな」みたいな。今までとはそこがちょっと違いましたね。EMをやっていた時は、「CTOがあれだけ言うんだからいいじゃん」みたいなのが使えたんですよ。「ワーワー言うけどさ。いいじゃん、ついてきてあげてよ」みたいな感じで。

（一同笑）

戸井田：けど、初めて「あ、この技使えない！」と思ったんですよね。責任者としてすべてを受け止めるというのは初めてだったので、そこはちょっときつかったですね。「責任ってこういうことか」みたいな感じですかね。

（一同笑）

ーーその不平不満を解消する方法としては例えば話し合うことかなとか、どういう解消方法がありましたか？

戸井田：対話ですね。ただすべてを解消はできてないと思います。最終的に何人か会社を去っていった人もいました。それは未だに覚えてるし、辛かったですね。

ーーでもやっていくうちに、やはりそれなりの組織が出来上がった感じですか？

戸井田：そうですね。採用に関してもゼロベースでテコ入れし、採用フローやカルチャーフィット等の基準を見直したので、少しづつ仲間は増え、組織として徐々に変わっていったと思います。

CTOにとって、一番しんどいところ

ーー広木さんにお聞きしたいんですが、CTOが組織全体を見るみたいなことというのは、けっこうあることなんですか？

広木：もちろんあると思います。というのはエンジニアリングをする組織の長なので、組織改編とかアサインを変えるというところまでできないと、「そもそも組織を見ているとは、いったい？」になると思うんですよね。なので、かつその経営に近ければ近いほど今までの現状維持バイアスというか過去の慣性だとできないことをやらなきゃいけないというのが、一番CTOにとってはしんどいところ。

逆にまわりがうまく回っているのを「うんうん」と言っているだけだったら、回っているのを見るだけなので。楽は楽なんですよ。そうじゃなくて、そこに対して当然もともと作っていたシステムを放棄して、新しいシステムをリプレイスするということに対しては、納得いかない人もいたりなど、そういうネガティブな面も出てくるとは思うんですよね。

だからこそやりきらないといけない、そこでブレてはいけない。誰もがみんな「これまでどおりのやり方をしていたほうがいいんじゃないか」って思ってしまうし、今の実行したあとを見てみると、このタイミングでできていたことで救われるポイントって、Hacobuさんとしては多々あったんじゃないかなとは思っていて、それがもうちょっと進んだあとだと、より大変になっちゃう。

今までやってこなかったから、なんか絶妙なタイミングでできたということなんだろうなとは思いますね。特に今の世の中の市況もそんなに良くない中で、そのまま拡大路線で歩めるのか、あるいは機能を止めるような開発が堅実にできるのかというと難しいところで、うまくそれをやり切れたというのは、1つの重要なポイントなのかなと。

これも事情によってけっこうマチマチで違うかなと思うんですけど、要はホリゾンタルのSaaSの場合、アップセルの別商材を作るまでって上場しちゃったあとぐらいでも、けっこう何とかなるんですよ。1つの製品が幅広く横に広がっていくので、営業エリアはどんどん広がるんですよ。

それに対して、Hacobuさんみたいに縦にいく場合は、ある業種の数あるペインを全部解決していかないといけない。そうしないとアップセルしていかないから。その事業をスケールすることと、プロダクトのサイズを増やすことは、けっこう早い段階で直結しちゃう。

そう考えると、横展開できるようにするということは、非常に重要な部分があるのかなと思っていて、それが早いうちに手を打てたんじゃないのかなとは思っています。

ーーまさにベストなタイミングだったと。

広木：ただ想定外の結果はあったと思うので。

（一同笑）

例えばマイクロサービス的なアーキテクチャにしていくのって、エンジニアを増やせば増やすほど、ちゃんと事業開発の速度が上がってくるのを目論んでやっていく展開が多いので、「採用をフルパワーでやるんだっけ？」「そうじゃないんだっけ？」という悩みが生じる時には、けっこうアーキテクチャがバラバラになっちゃって、やりにくくなることがある。

だから今回は、テンプレートベースというか、同じGoならGoでという統一されたフレームワークの上で、マイクロサービスでやるというバランスだったので、極端なことにはなっていないと思うんです。だけど場合によっては、それこそチームごとに分けていたら、チームごとに閉じちゃって。チームの採用人数を絞らないといけないとなったら、今度は1人が複数のサービスを見なきゃいけなかったり、そういうことも出てくるので。なんかそのあたりは、想定内・外どうだったのかなと。

（一同笑）

戸井田：そうですね。まずエンジニア採用が順調に進むとは思ってなかったです。今もですが、売り手市場すぎて、Hacobuの認知度でここで成果をあげるのは難しいだろうなと。Go言語で全部揃えた理由の一つは学習のしやすさです。たとえ経験が浅くてもパッと立ち上がるだろう、みたいな想定はありました。後は複雑性との向き合い方という意味で、細かくマイクロサービス化しないことが、肝だと思ってました。たまにとーっても小さなマイクロサービス群を抱えたアーキテクチャを見ますが、あれは人間の手に負える代物ではないです（笑）。細かくするのはもっとドメイン知識を獲得してからだと決めてました。

「見積もれ」には「わかりません」

ーーそれでけっこう組織もそれなりに揃ってきて人も集まってきて、じゃあ「いざリプレイスしましょう」といった時に、例えばなんか開発している最中にここで躓いたみたいなのが何かありましたか？

戸井田：そうですね。「いつリリースできる？」って聞かれるじゃないですか。その質問に対して僕は、常にいい意味ではぐらかしてました（笑）。それはなんでかというと、シンプルに見積もれないからです。

これだけの規模のフルリプレイス、かつドキュメントがない状態で見積もれるわけないんですよね。はぐらかすというのはちょっと言い過ぎましたが、正しくは、リリース時期をレンジで答えていました。進捗が出るにつれて徐々に精度があがってきますと。「今この時点で回答するのであれば、リリース日は、夏か春です」みたいな。

（一同笑）

戸井田：こういうコミュニケーションを取っていて「なんで？」と言われたら「見積もりってこういうものなんですよね」みたいな。経営チームに対してシステム開発のイロハみたいなのを、コミュニケーションしながら取っていったんです。「春か夏」というと、気づいたら4月になっていて。「僕は春か夏って言いましたよ！」みたいな（笑）。暦上は半年ぐらいレンジがあるんですけど、みたいなのがあって、そういうのは大変でしたね。

ビジネスサイドでいうとお客さんから「機能開発をしてくれ」と言われ、「フルリプレイスが終わるまでお待ちください」というのが続いたので、それに対してもしっかり向き合い続けるのが大変でした。

ーービジネスサイド側からは、当然「いつまでに出してほしい」という気持ちがあるのは、何となくわかります。それに対して「わかりません。そういうものですよ」と、納得してもらえるものなんですか？

戸井田：いや、無理ですね。

（一同笑）

無理なので、対話です。よくビジネス側とお話してましたし、Hacobuはそもそも本部横断でのコミュニケーションが活発な組織だったので。また聞きじゃなくて、直接「見積もりって無理なんだよね」みたいな。小さい組織だったからできたんですけど。誠実に思っていることを伝え続ければ。それでなんとかなるなという感覚があるので、それはやっていきましたね。飲みが増えていた気がします。

（一同笑）

ーーCTOとして、今言った直接のコミュニケーションって大事なものなんですか？

戸井田：はい、大事だと思います。ビジネスサイド側は、お客さんのためにはこういうシステムが必要で、こういう理由でっていうことを一生懸命説明をしていたので、シンプルにありがとうを伝えたいという気持ちがありました。

結局みんなでをどう同じ方向に向けるかが、リプレイスにおいて一番重要だと思っていたので。特定の技術や特定の技術者で解決するならそうしましたが、そうじゃなくて全社の意識をどう作っていくか。その中で、僕は何にどう時間を使えば良いのか。これが一番大事だった。そればかり考えつつ、手を動かしていた感じですかね。

ーー例えばエンジニアサイドの考え方と経営サイドの考え方がぶつかる瞬間があった時は、どちらを優先したんですか。

戸井田：それでいうと、開発チームには「リリースまでの見積もりはしなくていい」って、言っていたんですよ。意味がないから。ただ「最速で走ろう」と言っていました。「2週間後にこれを出す」と言ったら絶対に出すし、イテレーティブに「最速で走り続けていたら、それでOK。経営チームにはレンジで答えつつ、開発が進むにつれて解像度があがっていき徐々にレンジが小さくなっていくみたいな。

ごまかす奴だなとか思われていたかもですね。「最速で走っていたらよくないですか？　そこは僕が中に入って僕が見ます」みたいな。それで「どうやって判断しているの？」「こういう理由で今は最速だと思いますよ」と伝えて「そういう感じなのね」と。

「プロダクト開発ってそういう感じなんだ」みたいなものを経営チームみんなで理解して、どうやったらフルリプレイスをうまく完遂できるかで一致団結してました。これは間違いないです。完全に背中を預けている状態だったし、ここでも良いチームがあった気がしますね。やはり何でもチームワークですよね。本質を捉えていれば多少曖昧でも許してくれるというか。気のせいだったかもですが（笑）。

（一同笑）

キャラで得しているパターン

ーー広木さんもCTOとして、経営とエンジニアをつなぐような、翻訳のようなことをすることも多いと思うんですけど、今みたいなやり方というのはけっこう普通なんでしょうか。

広木：そういうこともありますよ。キャラで得しているパターンで「この人がいうんだったら」みたいな。それって要は、基本的にはそういったアカウンタビリティを持っていたほうがいいよねというのが、セオリーとしてはあるんですけど、結局そうじゃない時、どうしても難しい局面があった時に、何で判断されるかって、これまで積み上げてきた信用で判断されると思うんですよね。

それが今回のケースは、そうやって謝って「ごめんなさい」と言っても、信用の貯金があったから成り立ったという話だし、それがたぶんケースバイケースになるところはぜんぜんあるんだと思います。なので、ごまかされちゃう感じの話をして「まぁまぁ、わかるよ」みたいな感じで、仕方ないなと思ってもらうというのも1つの手だし。

逆にそのぐらいのキャラのほうが、最初から厳密な話をしようとすると難しいんですよね。そもそも難しいことなので、要はいくらやっても100点の精度が出ないんだったら、会社的には「一定最速でやってくれたほうがいいじゃん」という割り切り方だと思って、一方である程度の目論見が立つといいよね、というのも並行してあると思うんです。

このバランスで許容されるわけじゃないけど、そういうので結局「費用対効果は？」みたいな話になると、アーキテクチャの費用対効果とかはわからない。

戸井田：確かに。

広木：それに対して、合理的な算定基準がこの世にあれば、それをやっていないんだったら良くないと思うんですけど。この世にないから、ないものに対して捏造して説明したつもりになるのは、逆にあまり良くないというか、そういうのはあると思います。

戸井田：まさにそう思います。そのやり方で進めていた背景として、PMFをしかけていた、というのがあります。既存の機能でけっこう売れているなという感触があったんですよ。

なので、フルリプレイスの間一切売れなくなるみたいなことはないし、キャッシュが底をつくこともないだろうと。ただ、顧客要望を満たせないことでチャーンにつながったりは増えるだろうと、耐えるのはやはりしんどいことなので、組織のフラストレーションに対してどう向き合っていくかが本質な気がしていました。

特に経営チームは徐々に不安になっていくと思うので、そこの翻訳は意識的にやりましたね。これがもしシード期みたいな、機能がないと売れないみたいだったら無理だったと思うんですよね。まともな社長ならやらない。

（一同笑）

そこらへんのタイミングが良かったのかなと。入って状況を見て「これはいけそうだな」とはなりましたね。

（後半につづく）