創業6年目のリアル〜開発を止めない技術的負債との向き合い方〜ミツモア開発チームはどのような組織を目指しているのか

ミツモアは創業6年目を迎え、顧客のためのサービス向上を重ねてきました。一方プロダクト内は変更や改善の連続により、増改築を重ねた「ハウルの動く城」のように、いつかは改修に取り組まなければいけないことが増えてきます。多くのテック企業が抱えるこうした課題、エンジニア界隈では「技術的負債」といわれる課題に、ミツモアは実際どのように向き合ってきたのか、また今後の対応策は？　これからのミツモア開発チームの組織運営方針までを、CTO柄澤とテックリード白柳に語ってもらいました。

柄澤史也 Fumiya Karasawa
株式会社ミツモア 共同創業者 兼 取締役CTO
ヤフーにて4年間勤務。ヤフオクにてプロダクト開発、オフショアマネージメントに携わったのち、CTO室に異動。ヤフー全体を横断した技術支援などを担当した後、ミツモアを共同創業。東京大学大学院 理学系研究科卒。
https://github.com/fmy 
https://twitter.com/fmy

白柳 広樹 Hiroki Shirayanagi　
プロダクト部 テックリード
ヤフーにてヤフオク!の運用・基盤開発などを経て、フロントエンドのプラットフォーム刷新のPMとして主導。慶應義塾大学大学院 理工学研究科卒
https://twitter.com/yanaemon169
https://github.com/yanaemon

技術的負債はどのように生まれるのか

ーミツモアは技術的負債の解消に向けて、注力して取り組まれているということですが、簡単に経緯をご説明ください。

柄澤：ミツモアは最初の3年ぐらいは、当時、会社のバリューとして「Faster than ever」というものを掲げていまして、ものすごく素早くプロダクトを開発し、顧客に価値をどんどん提供していくことを優先していました。そして、不具合が見つかった場合も、それをどんどん改善していくという方針でずっとやっていました。そのおかげさまで2022年７月に累計依頼総額200万件を突破し、多くの方々にご利用いただけるようになってきたのかなと思っています。そういった中で、3、4年経つと、コードの量も増えて、ここを修正すると全く別のところでバグが出るとか、修正するときに考慮しなければいけないことがたくさん出てきました。そこで、技術的負債を徐々に解決していこうと、 プロダクト開発チームで時間を取って動き始めました。

白柳：簡単に言うと、求められてるものを最小限で作るという思想で作ってきたんですね。そうすると、トレードオフスライダーとよく言われるんですけど、要は機能を全部揃えようとすると時間がかかりますし、逆に時間を短くすると、最小限の機能で品質の優先度がちょっと下がる。当時のミツモアではバリューにあるように、いかに素早くリリースするかというところを1番重視してました。そうすると、トレードオフで品質というのが多少犠牲になったり、必要な機能を全部揃えず最小限で出すということをやっていました。
だんだん規模拡大していくに当たって、最小限で出していたものに追加機能を作り、さらに追加機能を作り、どんどん追加していく。このようなつぎはぎの状態のプロダクトは、たまに「ハウルの動く城」に例えられます。

ー「ハウルの動く城」は視覚的にわかりやすいですね。

柄澤：増改築のイメージが1番イメージに近いですね。はじめは1階建ての予定だったにもかかわらず、途中で2階建てにしたら、階段が変なところにしか作れなくなってしまう。最初から2階建てで考えておけば階段はもっといいとこにあるべき、というイメージに近いです。

白柳：きれいに1から作り直したいというのもありますが、そういうわけにもいかないので…。
例えばミツモアで依頼者のやりたい仕事の要件定義に使われている質問機能。最初は選択式と回答式の最小限のもので出していたのですが、それが、この回答をしたら他のサービスに飛ばしたい、といったように、機能が継ぎ足されていきました。
それから、ミツモアはサービスの数がすごくたくさんあります。各サービスごとに最適化された体験があって、ハウスクリーニングだったら仕事の内容は定型化できるので希望のスケジュールを選択することで仕事の予約が済むとか、税理士はちゃんとチャットや対面でコミュニケーションがとれるとか、それぞれサービスによって商慣習が違うので、最適化されたものに変えていきたいんですけど、それをうまく切り替えようとすると複雑になってしまうんですね。出来る限り作り込みたいけど、複雑にならないようにバランスを見ながらやっています。

皆が主体的に負債解消に取り組むべき

ー技術的負債というと、具体的にどういった種類があるのですか？

柄澤：本当にさまざまなんですけど、簡単に言うと、①コード自体が入り組んでいる。②同じことをする処理が2、3か所ある。③ちょっと古いバージョンのライブラリーを使っている。④インフラストラクチャーを途中でコンテナベースに移し替えたけど、その移行が不完全。などです。他にもいろいろあります。

ーでは、実際どのようなアプローチで負債を返していこうとしているのですか？

柄澤：まずは時間をちゃんと取ることを心がけています。通常の開発業務でいっぱいいっぱいだと時間が取れないので、とあるチームは「この1週間は負債を返す」みたいなやり方をしてみました。 それまでにタスク管理ツールに技術的負債をちゃんと貯めて書いておいて（実際2週間かかりましたが） 一気に修正していくやり方ですね。
毎週金曜日をそれに当てるというのも試したこともありますし、人で分けたりもしたこともあったかな。

白柳：やり方は結構いろいろと試しましたね。プロジェクトの終わりにやったこともありました。「計画を立てて開発して、最後QAしてリリース」という基本的な流れがあるんですが、リリースで何かあった時（トラブルや不具合）に対応できる時間プラス、そのプロジェクトでやり残したことはもちろん、過去の修正や小さな改善をその期間でやる、みたいな取り組みです。

柄澤：そうですね、色々なやり方ではやってますけど、技術的負債はどんどん解消されているというのは実感としてありますね。

ーそれは良いですね。取り組みの試行錯誤をされていて、その成果が出ているんですね。

白柳：やり方は、チームによって、あとプロジェクトによって合う合わないがあるんですよね。例えば今のチームだったら、こういうやり方がやりやすい。こういうプロジェクトだったら、あれがやりやすいというのがある。

ー例えば柄澤さんから「技術的負債返していくぞ！」みたいな大号令をしたこともあるんですか？

柄澤：そういうのはないです（笑）。上意下達みたいにはしたくないので、都度「負債をどう返していくか」という話題を出したりしてますね。いろいろ試した中で「言われてやる」というのは、あんまりうまく進まないんですね。

ーなるほど。

柄澤：いろんなメンバーがそれぞれ、いつも開発してる中で、その開発を遅らせるような技術的負債に直面して、これをなんとかしたいなと思ったものを、ちゃんとみんなの意見としてまとめておく。 以前は洗い出して優先度をつけたりもしていました。スプレッドシートにまとめて、白柳が主導してくれてましたね。

白柳：自分の業務としてまさに今開発してる機能に関して、こういった書き方した方がいいよとかは、 担当範囲内で細かい話は良くしていました。ただし、全体で見た時に、何が1番の課題で、どういう順番でやるべきかというのは、うまく集約できてなかったというのが正直なところです。自分の普段からやって見えてる範囲だけではなく、他のチームが何をやっているのか把握していないと、全体の課題は見えないので。
それぞれのエンジニアリングマネージャーたちが全体をみているので、マネージャーたちで課題を出し合ったり、順番を決めて、それぞれメンバーと一緒にやっていくみたいなこともありましたね。
2022年の初めぐらいからは、みんなで課題を持ち寄って、あんまりマネージャー陣はあれこれ言わず、サポートだけしていこうという取り組みもしています。全員で何が課題なのかを話し合う場を設けて、そこで決めたことをどれぐらいで、それぞれの業務に応じて割合も考えてやるという試みですね。それが、OKRに紐付けてリファクタリングをしていく、というものですね。

責任の所在も含めたアプリケーション分割

ーアプリケーションの分割というものに取り組んでいるそうですが？

白柳：サービス領域とソフトウェアの領域は本当に体験が違うので、初めからアプリケーション分割して作ってます。それ以前で言うと「ミツモアメディア」や「ミツモア大学」は、最初一緒でしたが途中で分割しました。最近は新しいものを作りましょうと言えば、初めから別個に作りましょうとなりますが、もう既に出来上がった大きなものがあって、それを整理していきたいというのが「分割」としてあります。

ー既存のものを分割していきたいと。

白柳：はじめの数年はエンジニアも1チームで、コミュニケーションロスが少なかったので、苦労せず開発できていました。全体に関わるような変更でも、ちょっとみんなで集まってすぐやりましょうみたいに、スピード感を持ってやっていました。
組織拡大に伴ってミツモアで3チーム、MeetOneで1チームというようにチームが増えてきたというのもあって、全員が認識を合わせながら大きなアプリケーションを修正するという進め方が難しくなってきました。チームごとに決済、見積もり、依頼者関係といったように機能が分かれていて、みんなで大きなアプリケーション1個を動かしています。
だんだん規模が大きくなってきて、開発速度もだんだん遅くなってきました。開発環境でアプリケーションの起動にかかる時間がどんどん遅くなっていったりだとか、リリースする前のデプロイに最初は5分かかっていたものが10分かかったり、リリース前にビルドするのに時間がかかるというのが一番大きいですね。
また、機能担当をチームごとに分割していき独立して開発していけるようにしたいというのもあります

ー課題は何でしょうか？

白柳：一番大きな課題は、アプリケーション分割はしていきたいんですけど、いろんなプロジェクトがあって、さらに機能をどんどん追加していったり、仕様を変えていったりしているので、 そことどううまくバランスを取りながらやっていくかですね。他社の事例では「マイクロサービスに変えるチームを作る」というように、1年や数年単位のプロジェクトになることがあります。実際、今のミツモアの規模では、流石にそこまで時間をかけられないのでいかに普段の開発に組み込むかというのが課題です。

ープロジェクトを止めずに分割をしなければならないと。

白柳：今は、変更が頻繁に起きるようなところは手を加えず、基盤となりそうな通知基盤、LINE通知やメール通知から手をつけようとはしています。そういった、そこまで修正はされないけど、1つの機能として、 シンプルで独立しているものを切り出していくと、あとあと、ミツモアからもMeetsOneからも使える機能を作れたりするので、そういったところから変更していっているところです。

柄澤：そうですね。なんでもマイクロサービスにすればいいわけではない。そのチームとそのチームが持つ機能、マイクロサービスの責任分担みたいなものが対応していかないと、うまくメンテナンスも回っていかないかなっていうのは考えてるところです。
さっき白柳が話したように「通知周り」つまり、依頼者の方や事業者の方にメールやアプリのプッシュ通知を送る部分を、切り出そうとしているところですけど、そういった共通基盤みたいな部分を、開発メンテナンスしていくチームを作って、そのチームが責任を持ってマイクロサービス化するように進めているところです。

ー責任分担まで考えての分割が必要なのですね。具体的にクリアしたい課題などあれば教えてください。

柄澤：さっき出たビルド速度ははやくしたいですね。すごく地味なんですけど、ビルドがはやくないと、リリースするのがどんどん大変になりますし、バグがあった時の修正反映も時間がかかってしまうので結構優先度が高いと思ってます。リリースしようとしてからリリースできるまでの時間が、それが短くなるといいですね。 5〜10分以内にリリースできるようにしたいです。

白柳：前からスピードアップというのは取り組んでいて、1つのアプリケーション内でできることは、やり切ったところがあります。 さらにはやくするための壁で、今の大きいものを分割しないと、これ以上はやくするのは大変ということで、分割に取り組んでいますね。
長期的な話で言うと、分割もいろんなやり方があって、物理的にサーバーという単位で分割するやり方もあれば、物理的ではなくソフトウェア的に分割されている状態だけど1つのサーバーで動いてるみたいな状態の2種類があります。 分割しすぎると、さっき柄澤もいいましたけど、どんどん細かくなって、複雑になっていくんです。まだ速度をいかに上げていくか、はやくリリースしていくか、みたいなところが重要なところの1つなので、最終的にはきれいな状態にできるよう下準備をしてる感じですね。
通知のサービスは物理的に切り離せるようトライしている。一方で、それとは別に各チームで内部的にきれいに整理していくというのを進めています。内部的に整理したものをあとは別でサーバーを動かすだけ、ぐらいにな状態にして、いつでも切り離せる状態に持っていく予定です。

将来的には技術的負債解消プロジェクトのない組織が理想

ーこれからミツモアはどういった人材でどういった組織にしていきたいのでしょうか？

柄澤：そうですね、もちろんマイクロサービス化するとか、その既存の複雑な行動を分割したり、リファクタリングして、きれいにするという熱意ある人がすごく必要だと思ってます。でも、それに加えて、既存の仕組みをしっかり理解して、中長期的な運用ができる人がいいのかなと思ってます。分割するだけではなく、その後の開発、改善していく部分を見通したことができる方ですね。

白柳： 将来的に技術的負債解消がプロジェクトとして立ち上がらないような組織にしていきたいというのが、まずベースとしてあります。
技術負債解消プロジェクトは、単純に古い技術を変更するというか、借金を返済しているみたいな感じなので、ネガティブなイメージもあり、いかに開発以外の人にこの重要さを伝えるのかがすごく難しい。技術的負債を解消している間は、開発のプロジェクトが止まるので、これだけのお金をかける必要が本当にあるのか、やっぱりどうしても説明しにくいです。確かにきれいになったら、速度もはやく、開発の時間がはやくなるんですが、ビジネスサイドにその辺りを理解をしてもらって進めていかなきゃいけないっていうのは難しい。
だからこそ、はやめに手を打ちたい。メンバーも常にそういう意識を持って働いてる環境を作っていきたいです。普段からそういうことを考えながら、 改善というのをポイントで入れて、きれいにしていってるというような状態を加速させていきたいですね。

ー技術的負債を日常的にコツコツ返しながら、開発も止めない。

白柳：技術的負債を返すエンジニアリングだけが好きという方もいるとは思いますが、ミツモアとして求めてることは、そこだけではなく、ビジネス面も含めてプロダクト開発をしてプロダクトアウトにしていける方なので、あくまでその一環でこうそういった負債も考えながら解消したり、そもそも負債にならないような仕組みを作れる組織にしていきたいですね。

柄澤：技術的負債をなんで返すのか、もちろんエンジニアがよりはやく開発するためなんですが、本質的にはユーザーにより素早く価値を届けるためなんでしょうね。顧客にいかに価値を届けるかという部分が根底にあって、そのために開発チームが効率的に開発してプロダクトを届けていく、個人的には、そこまで考えられる組織にしていきたいですね。

ーありがとうございました！

（ライティング　字と図 吉田千枝子）

======================================

ミツモアでは、現在事業拡大を進めており、エンジニア・デザイナー・PdMをはじめ多くの職種で積極採用中です。

Wantedlyにて募集しているので、カジュアルに面談に来てみませんか？

デザイングループも所属するプロダクト部の詳しいご紹介は「ミツモア エンジニア向け会社説明資料 / about meetsmore for engineers」を公開しております。