ダブルメンテ状態は、なんとしても避けたかった
ーーフルリプレイスに対して、社内で反対はなかったんですか？
戸井田裕貴氏（以下、戸井田）：土日の48時間を使ってバシッと移行しきるのは、けっこうリスクがあるという雰囲気は出ていましたね。僕は絶対にやりたかったので、そこは話し合いました。
ーーそれをどう説得したのですか。
戸井田：新・旧システムのダブルメンテ状態は、なんとしても避けたかったんですよね。なんでかというと、営業はまずプロダクトを売っているから、両方を理解しなきゃいけないじゃないですか。新・旧で思想や使い勝手がぜんぜん違うし、しかも開発のスピードとかも変わってくるんですよね。こちらは速いけどこちらは遅いみたいな。
そんなことをしたら、営業もCSも辛いと思うんですよ。両方使うお客さんとかが出たら、さらに辛いと思うんです。どちらにしても、両方理解して売っていく状態になる。もう大変だし、開発者もモダンな技術と旧技術をいじる人が必要になる。これも無理だと思っていて。なぜなら評価含めた制度に影響が出ちゃう。
こちらのエンジニアはつまらなくて、こちらのエンジニアは楽しいみたいな空気が作られちゃうし。採用も大変だと思います。こういう開発組織になってしまったら、1つの文化でやるというのは無理だと思っていて。スケールしないし、「この選択肢は、僕はないと思っています。だから、どうやったらバチンと切り替えられるかだけを考えよう」みたいな感じで言い続けましたね。
リスクに関してもちゃんと説明をしました。顧客に影響が出てチャーンが止まらない、なんてことにはなりませんよと。なんでかというと、まずはQAをするので。SaaSだし基本機能はバグらないですよと。特殊な使い方をしているお客さんがいた場合は影響が出てしまうかもしれないですが、使われているデータを見る限り限定的ではあると思ってました。
ただ、もっとも警戒しないといけなかったのが、データのマイグレーションでこけて顧客データが漏洩しちゃうセキュリティ系リスク。これは100%の近い精度で対応しないといけないと思っていました。
トラブル時の影響範囲が特に大きな顧客データは本番同様の環境を再現してQAを行う。なので、セキュリティリスクは最小化する・顧客データは守る、ということでみんなで共通認識をつくりながら進めていきました。
ーー今の話は社内での説得の話だと思うのですが、例えば利用者からは「マスター登録ができないと困る」とか、そういう意見はなかったんですか？
戸井田：全社でフルリプレイスをやるんだという意識が作れていたので、営業やCSがお客さんに「こうこうこういう理由でメンテナンスを入れさせてください」と、ていねいに伝えてくれました。「フルリプレイスをすると当然旧セッションは使えなくなるので、今までのローカルストレージにあるような検索とか保存していたものも使えなくなっちゃう」みたいなコミュニケーションも事前に始めてくれていて。
なのでお客さんの意識も「MOVOさん、将来のためにがんばっているんだな」みたいな雰囲気をビジネスサイドが頑張って作ってくれていました。僕らの言っていることに対してけっこう共感してくれていたお客さんが多かった印象で、ビジネスモデル的にもお客さんと一緒に課題を解決していくスタンスなので、そこは良かったかなと思います。
うまくいった時の社内の反応
ーー今回うまくバチンとやってうまくいって、その時のバチンとうまくいった時の反応は社内的にはどうでしたか。
戸井田：お祭りですよね。
（一同笑）
一大イベントだったから。歴史を作ったなみたいな感覚はあったんじゃないですかね。全社の期初のキックオフを遅らせてまで、フルリプレイスしたもんね。
それまでの全社ミーティングでは、なんかよく飛行機が墜落する写真を見せて「もうすぐこうなるかもしれない」みたいな。「僕らがやろうとしていることは空中給油です」みたいなことは、よく言っていましたね。2日間で、飛んでいる飛行機に対して、新しい飛行機で近づいて、給油してバンッと移し替えてというのをやろうとしていて、失敗したらバーンと墜落！みたいな例を毎月よく出していたんですよ。
バーン！ ってなる可能性がだんだん低くなってきましたとかを言っていたので、「飛行機が落ちなくてよかった」となって、ワーッとなったりしましたね。
（一同笑）
ーーでもまだ可能性はあった？
戸井田：墜落って何？というのもあると思いますが、予想以上に顧客に影響が出るというのは全然あったと思います。
ーーもし落ちたら、ということは考えなかったんですか？
戸井田：なので何か起きたら本当に……。まだ覚えているんですけど「何か起きたらこういう場合は、どうやって責任を取るんだろう」みたいなのは、ちょっと考えていましたね。よく責任とって辞めるとか聞くけど、辞めるのって責任とってなくない！？という感じで。実際、リリースは、ビックリするくらいうまくいきました。当然ポツポツ障害は起きるんですが、大きいものは全く無くて、その時にチームのパワーってホントすごいなと思いました。
誰一人手を抜くことなく、チーム一丸となって戦いに挑んでいる状態の時、各人の能力の振れ幅が105%くらいになって、かつこれは掛け算になり、チーム全体で当初想定していなかったパワーが発揮されるんだな、と。じゃないとこうはなってないなと思い、改めてチームで働くことの意義を感じました。お祭り後の家に帰る道中、感動してちょっと涙ぐんだ気がする。
ビッグバンリリースはしないほうがいい
ーーこのフルリプレイスの話を聞いて、広木さん的にはどう感じましたか？
広木大地氏（以下、広木）：なんかこの記事を読む人に誤解なきように言うと、セオリーとしては、ビッグバンリリースはしないほうがいい。
（一同笑）
途中でそのすべてのサービスをフルリプレイスするのに事業を止めるというのは、なかなか大変な意思決定だよというのはあるとして、学ぶべきところとしては、その選択肢を全部排除しちゃいけないという話になると思っていて。要はWhyみたいな言い方をするんですけど、ある程度同じレイヤーを通して、ここまでは同じ動作をさせるから、こちらからは新しいもの、こちらから古いものを切り替えられるようにする。
この部分だけ新しくするけど、この部分はそのままでも統括的に使えるようにするとかをしながらというのが、私たちのセオリーといえばセオリーなわけですよ。移行も、それこそあまりtoCでずっと長くインフラ的に使える事業だったらできなかっただろうし、toBで営業時間に波があるというようなことがあったからメンテナンス時間も取れたとか。そういうのも理由があってこれが成立しているんだけど、なかなかやりきれないことではあって、それをやりきったということは間違いなくすごいなと。
だけど「セオリーとは違う」ぐらいの剛腕が出ないと、こういうことをしませんよというところは言っておきたいです。たぶん多くの、特にセカンドシステム症候群になる人は「Hacobuさんができたんだから、うちもできるかも」と思うかも知れませんが、そう言ってやるには、CTOとCEOも相当な覚悟を持ってやりきらないとできることではない、というのは言っておいたほうがいいです。
戸井田：はい、まったくおすすめしません。
（一同笑）
広木：僕はいろいろなところで止めているから。
（一同笑）
「止めたほうがいいですよ」と。「その次善策はありますよ」と。だから別のやり方はあるとは思うんですけど、当然完全移行するやつもあるんですよ。ただそれは、例えば基幹システムを移すみたいなのは、何年か周期で基幹システムを動かしていくというのはいくらでもあるわけで、SIerさんとかはそういうのに慣れていると思うんです。
だけど動いている事業をそのまま、サービス事業そのものを提供しているのに、それを動かしてリプレイスしてそっちに行きます。それで2日は、なかなかのチャレンジだと思うし、それの時期感とかも、下手に繁忙期に入っちゃったらできない。
戸井田：確かに、繁忙期や閑散期の話も出てましたね。どうやってリリースすれば影響を最小化できるかと。
広木：閑散期にそれが起きるようにするとか、そういうことを考えたら「それを伸ばしたらそのタイミングで何かあったら次にどのタイミングでやるの？」みたいなことはたくさんあった中、それを終わったあとに話を聞いたから、「え!?」ってなって。
（一同笑）
「技術的負債」と言わないほうがいい
ーー一方で、技術的負債を抱える企業がたくさんある中で、今言われたようにいろいろな解決策がある中で、自分の会社でこの技術的負債を抱えていてどうにかしたいと思った時に、別にフルリプレイスじゃなくてもいいんですけど、どういう判断基準でやっていくのがいいのでしょうか。
戸井田：技術的負債との向き合い方ですか？
ーーそうですね。
戸井田：難しい話ですね。まず「技術的負債」というワードがビッグワードすぎて、その使い方は止めたほうがいいと思っています。
実際に解像度をあげていくと、既存の設計が好みじゃない、みたいな趣味趣向の話であったり、それは技術的負債の解消ではなく、既存機能の改修だね、みたいなケースがあるので、まずはここがすごく大事。それをやっていくと、最終的にシンプルな課題として定義できるんですよね。例えば、ユーザーというモデルをラップして使うと、ユーザーに変更が入ったときに影響を最小化できるねとか。リポジトリ層にロジック入りすぎてて、ドメインモデル貧血症になってるから、ドメインに寄せていきたいね、とか。
技術的負債というビッグワードで扱うんじゃなくて、一つ一つシンプルな課題として扱う。そうすると「あ、そうなんですね」と。プロダクトの立ち上げフェーズでは、一刻も速くリリースし、売上を出すためにスピードが最優先。且つ不確実性や解像度が低すぎてすべての未来は見越せないというおまけつき。当然そういう課題は時間経過とともに、たまる一方です。なので、通常業務の中でリファクタをし続けるのが大事。
なので個人的には「技術的負債」というワードはけっこう危険だと思っています。それを違うワードに置き換えるぐらいまですごく解像度を上げて、その課題と向き合うというのが、すごく大事。その人が何に対して技術的負債と言っているのかを、まずは分解しないといけない。
広木：僕の本にも書いてある話で、技術的負債に触れる時も「技術的負債はグリム童話の『ブレーメンの音楽隊』みたいなものだ」という話をしていて。『ブレーメンの音楽隊』って、化け物がいると思ったら実はその化け物は動物が重なり合ってできているもので、それが何で出来ているか知らないから、怖いものだと思って泥棒たちが逃げていったという話だったと思うんです。
そうじゃなくて、実は可視化してしまえば、それは非機能要件の積み重ねでしかなくて、さっき言った「ユーザーが抽象化できていない」とか「ここができていないからスケールに問題がある」という具体的な非機能要件になっていくはずなんですよね。それが見えない人にとっては、「オバケワード」になっていく。
戸井田：そうなんですよね。
広木：それでオバケとして説明することになるから、僕の言い方としては、技術的負債という現象はあって、要は二進も三進も行かなくなるシステムが生まれるという現象もあるんだけど、これは技術的負債そのものが存在しているんじゃなくて、その非機能要件の積み重ねが、経営にとってもチームにとっても見える化されていない状態だとオバケになってしまって、そのオバケを扱う時に「技術的負債」というフレーズを使っているだけなんだよ、と。
というところで、そこの見える化ができていないことがけっこうそのコミュニケーション上の問題というか。エンジニアにとってはシステムの中身が見える。だけど経営者にとっては見えない。この非対称性があって、だからこそこれが雪ダルマ式に大きな経営課題になるまで大きくなっていくという話で、そこを乗り越えるところが本当に必要なんだよ、みたいな話をさせてもらっていて、なんかそういうものだと捉えています。
ーー今言った中で、やはり見える化というか言語化というか、解像度を上げるというところがなんか逆に大事になるのかなと思って。それこそCTOがやるべきことでもあるのかな、と。
戸井田：そうですね。まさそんな気がしますね。経営チームからしても負債というワードは敏感に反応しますもんね。初めて技術的負債というワードを見たときには、余計な言葉つけんなよと思いました。
（一同笑）
あれのせいで怖くなっちゃうんですよ。BS上、負債って必ずしも悪いことじゃないですけどね。そういった印象や憶測パンチに対して、解像度を上げて正しく対応するのが、仕事じゃないですかね。
やり切ったことが、止めるための説得力になる
ーー最後に、今回フルリプレイスをして「もう1回フルリプレイスをやれ」と言われたらどうしますか？
戸井田：いやー、それは正直やらないです。
（一同笑）
さすがにちょっとね、「えいや」で走りがちなところがあって、こんなに大変だと思わなかったです。
（一同笑）
ーーやらないし、おすすめもしないですか？
戸井田：うーん、おすすめもしないですね。
（一同笑）
ゴールは見えていたし、やるべきこともわかっていたからできないことではないのはわかっていたんですけど。その実行がすごい大変だったんだよね。実行の大変さは想定外でした。やるべきことはそんなに変わらなくて一個一個見えていたんですけど、一個一個が1.5倍ぐらい大変だったので、かけ算でトータル10倍大変みたいな（笑）。「こんなことが起きるのか！」みたいな、「CTOってこんな感じか！」みたいなのが両方起きちゃったので、けっこう辛かったです。なので、もうやりたくないです（笑）。
広木：いや、なんか「2回目もやります」って言われたらどうしようかなと。
（一同笑）
戸井田：もしまたやろうとしたら、止めてください（笑）。
広木：それをやらなくて済むようにしているアーキテクチャが良いですよね。やり切ったことがまた、そういう時期が来た時に止めるための説得力になると思うので。逆にHacobuだからできたこともたくさんあると思っていて、そこの舵をより伸ばしていけると、強い組織になるのかなとは思いましたね。今の話を聞いてまとめると、けっこうパワープレイでフルリプレイスをやったという話なのかなと。
（一同笑）
だからそれを許容してくれるメンバーも、そしてやりきれるメンバーも、できるとこういうのはすごく一致団結するんですよ。やりきると、なんか「良かったね」っていう話になるので、何はともあれ始めたらやりきるのが大事だと思っています。
ーー今回は通常じゃなかなか聞けない、フルリプレイスの話が聞けてよかったです。ありがとうございました。
広木：ありがとうございました。
戸井田：ありがとうございました。
※記事公開当初はリプレイスのために2日間止めていたと記載していましたが、再度Hacobu社内で確認したところ、実際はサービスを止めずにリプレイスをしていたため、その部分を修正しました（2023/07/28）。
