Sansanとラクスルが語る、技術的負債からの脱出　負債は「ある」のが大前提　

技術的負債の脱出

戸辺淳一郎氏（以下、戸辺）：本日は「技術的負債の脱出」ということでお話しいただいたわけですけど、ここではこのテーマを深掘りしつつ、雑談していければと思います。

すでに10件以上質問をいただいています。ざっと見た感じ、とくに重複もないので、この中からお話をしていきたいと思います。

このパネルディスカッション中にもどんどん新たな質問があればお寄せいただければと思います。今日はお二人ともよろしくお願いいたします。

藤倉成太氏（以下、藤倉）：よろしくお願いします。

二串信弘氏（以下、二串）：よろしくお願いします。

戸辺：さっそくなんですが、わりと本質的な質問がいきなり来ています。まず「技術的負債の返済のための作業と、新しい価値を作るための開発作業の優先順位はどうやって付けているのかを聞きたい」という質問です。

私も実際に自分自身エンジニアとして開発に携わっているわけなんですけど、非常に気になるところです。自分なりの解はあるんですが、ここはぜひお二人に聞いていきたいと思います。まず藤倉さんはいかがですかね？

藤倉：そうですね。確かに難しいテーマだなとも思います。ぜんぜん違う軸のものを比較したり、優先順位を検討したりするのは、技術的負債みたいなテーマだけじゃなくても、だいたい難しいんですよ。

なので、僕は日常的に少しずつ解消していくものを織り交ぜていくことで、開発は開発でやるのと同時に、常時ずっとリファクタリングをし続けるテクニックは有効なんじゃないかと思っているんですね。

戸辺：なるほど。

藤倉：どうしてもプロジェクトとして立ち上げなきゃいけない。でも、リソースは限られている。どっちだ!?　という場合には、これは二串さんもおっしゃっていましたけど、事業の状況に応じてどちらにアクセルを踏むべきなのかとか、「数値をずっと測り続けておく」ということで、どこかでこれを解消しておかないとアクセルを踏みたいときに踏めなくなる事実はわかっていて。

常時、新機能開発にリソースを振っていくけど、どこか一瞬落ち着いた瞬間とか、先の打ち手のために今、準備しておかないとまずいタイミングをちゃんと取っていく考え方をしないといけないんだろうなとは思っていますね。

戸辺：なるほど。わかりました。二串さんはどうですか？

二串：端的に言うと経営の意思が重要なのかなとは思っており、限られたリソースの中でどういうかたちで事業の価値、会社の価値を上げていくかが1つ重要なところかなと思っています。

あとは藤倉さんのトークでもあったと思うんですけど、技術的負債のリスクの度合いなどもしっかり測る必要があるのかなと思っています。

例えばセキュリティのリスクがあるのであれば重要度を上げるべきですし、そういったところをしっかり分析するところですかね。あとは負債の度合いなどによるんですけど、一定のパーセンテージを割いていくところのやり方もあるかと思います。

戸辺：なるほど。二律背反ではなく組織で動かす、要は組織のリソースの一部をその技術的負債の返済に当て、残りのメンバーで新規開発をするパターンということですね。

技術的負債の返済が新たに生むもの

戸辺：次はとくにラクスル、二串さんへの質問なんですけど、「モノリスからマイクロサービスにする際にはその分割の良し悪しもあり、それ自体が設計が難しい話なので、新たな負債を生み出すということにもなりかねないのでは？」「なので、そこに対して考えていたこととか気にしていたことはありますか？」と。

これは例えばSansanさんでもそうなんですけど、もう少し考えると要は技術的負債の返済が新規の技術的負債を生むことに対して、回避する取り組みを何かされていないかをお聞きしたいと思います。二串さんからお願いできますか？

二串：なかなか良い質問ですね。おっしゃる通りで、一歩間違うと新しい負債というリスクは非常に高いと思っています。

実際にラクスルでも私が関わっているプロジェクトというか、1つのサブプロジェクトの中で私自身が負債を生みかけたことがありました。最初はこれが一番良いと思っていたんですね。

いざ切ってみて走り出してみたら当初気付かなかったところで課題もいろいろと見つかったことがありました。

その時はサンクコストを意識するしかないなと思いました。走り出しちゃったので、「もうやるしかないだろう」みたいなところに対するコストですね。それを私自身がメンバーに「すまなかった」と言って、「これは止めたほうがいい」と、腹を割って話したのが1つありましたね。

戸辺：なるほど。

二串：なのでそういった「言いやすさ」も非常に重要なのかなと思っています。

戸辺：なるほど。要は新たな負債を混入する率を下げる。例えば心理的安全性で……これは新たな負債を混入していないかを言いやすくすることで、組織的にそういうことを起こりにくくするアプローチですよね。

二串：そうですね。

戸辺：藤倉さんはどうでしょう？

藤倉：この手の話は粒度の観点が少しあるかなと思っていて、例えば本当はアーキテクチャとか今のご質問にあったマイクロサービスみたいな話はすごく粒度が大きいというかレベルの高い話ですよね。

例えばマイクロサービスというサービスの切り方が難しいことは、僕もその通りだと思っていて。なぜ難しいかというと、その切り方が未来永劫正しいかが誰も保証できないからだと僕は思っているんですね。

今日この瞬間の事業ドメインをテーマにしていいのであれば、「この切り方が妥当だよね」と答えられると思うんですね。ただ、それがもしかしたら来年、再来年には事業ドメインが変化しているとか、外部環境の変化や自分たちの事業の変化みたいなもので、「おっと、この切り方はおかしくないですか？」みたいなことになる可能性が常に内在しているからこその難しさだと思っています。

僕の中では今見えている景色、今持っている情報、もしくは経営の意図としてこっち方向に行くと、今は決めている。だからこうする。その前提がずれたらこれは負債にしかならないと思っているので、そういう説明はしていきますし、前提条件をできるだけ明らかにしておいて、それがずれていくということをアラートとしてしっかり捕らえるということは非常に重要かなと思っていますね。

戸辺：ありがとうございます。

開発現場の実態をどう把握しているか

戸辺：いただいている質問の中に「活動の状況を正しく計測するという点にとくにSansanさん側のところで共感した」ということで……。あ、すみません。これラクスルのCTOからだと思うんですけど。

（一同笑）

二串：CTOが質問するんですね（笑）。

戸辺：ラクスルの場合、ソフトウェアのケースだとソフトウェアの資産化をすることによって、新規とメンテ開発をどれだけの比率でやっているかを経営的な数値で大雑把に把握できるようにしています。

なので、同じようなかたちでSansanさんでは新規開発や運用開発などを、それぞれをどういう作業方針で、どう計測してやっているかをお伺いできればと思います。

藤倉：ラクスルさんのやり方を詳しくは知らないですけど、たぶんニュアンスとしても近いんじゃないかなと思うんです。

まず1つは、これもよく会社の現場ではやりますけどプロジェクトコードの管理をするじゃないですか。どういうプロジェクトがあって、それの趣旨がどんなもので、エンジニアが毎日どれだけの時間を果たして使ったかは、みんなに工数入力をしてもらっています。

そのプロジェクトが、これが新規開発の資産性のある行為なのか、メンテナンスというコスト的なものなのかをラベルを付けていって、そこを常に集計できるようにしていますね。

戸辺：ほぼラクスルと似たかたちではありますね。今まで聞いているお話で、なんだかんだ言って、ビジネスサイドとか経営の理解を得るためには、計測や数値として見える化がわりと大事なのかなと思っているんですけど、そこでそれ以外に経営メンバーとかをより説得しやすい自分なりの手段や手法などをお持ちだったりしますか？

藤倉：あまりないですね。と言いますか、基本的に経営に対しては事実ベースで、人の感情やモチベーションというニュアンスを含まない状態で話すようにはしています。

なので例えば、「このプロジェクトは、技術的負債がなければ1人月で終わるんだけれども、あるので2人月かかります」以上、という……。それ以上でもそれ以下でもないですね。

逆に僕は現場エンジニアのモチベーションみたいなものをそういう判断にあまり入れ込みたくないんですよ。例えば、技術的負債があるので1ヶ月終わるものが2ヶ月かかっちゃいます。

これは生産的じゃないというか自分たちのパワーがフルに発揮できていない気持ちになっちゃうのはわかるんですけど、今の技術的負債も過去のある時点で判断した結果として今連綿と受け継がれているものなので、これには意味がある。

それを今は返せない・返さないという判断をしているんだと。なのでこの現状の中でベストエフォートで結果を出そうよということに対して合意していきたいなと思いますね。

ただやっぱりどこかで返す必要があるので、それは適切な経営の判断の中で返していこうということで、ポジティブな技術的負債を自分たちのものとしてしっかり抱え込んでおくというか。先人というか、過去の開発者に対して、今の人たちが文句を言うという構造は僕は健全ではないとは思いますね。

戸辺：なるほど。わかりました。僕がSansanさんの話を知らないから、より藤倉さんに質問しがちなんですが。

二串：関心して聞いています。

技術的負債はあることが前提

戸辺：今のモチベーションのところはお二人にも聞きたいと思いまして、ただ一方でモチベーションが感情的なものなので、発するところはそうかもしれないけど、それが生産性の低下だったり、離職率が上がることにつながっているとしたならば、そこは少し捉え方が変わるんじゃないかと思います。

仮に、モチベーションの低下が生産性や退職率の先行指標などになっていて、それで技術的負債の存在が相関があるとした場合に、そこをどう捉えるかを聞きたいです。二串さんから先に、どう取り組んでいるかを教えてください。

二串：そうですね。先ほど藤倉さんのお話で、経営メンバーとはわりと数値を使ってドライに話すということで、そこに関してはまったくアグリーではあります。とはいえ、弊社の場合は定性コメントとして感情と言いますか、一定のエンジニアの感情みたいなところを定性コメントとしては伝えるようにしています。

離職リスクに対する、技術的負債の解消というアプローチも1つはあると思うので、ラクスルでは複雑なドメインをビジネスとして扱っていることもあり、一人ひとりの戦力が実務上重要です。そこに関しては定性コメントとしては添えるようにしています。

戸辺さんのご質問でいうと……モチベーションは重要ではありますね。構造の品質や妥協などによって技術的負債が積み重なっていくところはあるとは思いますね。

戸辺：わかりました。ありがとうございます。藤倉さんはどうですか？　モチベーションは基本あまり気にしないですか？

藤倉：いや、モチベーションが重要なのは絶対的にそうです。例えば人を採用することもコストがかかる話なので、せっかく加わってくれた仲間を手放すことは感情面も含めて残念なことなので、それは重要なものだと思います。ただ、当社の中では技術的負債はあることが前提の営みだと思っているんですね。

僕はこれがなくなることはないと思っているんですよ。なので技術的負債だなと個人的に感じるものがまったくない世界を望むんだったら、そもそもそういう人はこういう業界に来るべきじゃないとも思っていたり、あとは僕らは事業体なので事業を前に進めるということが開発の目的ですよね。

そういうことを、きちんと話をして「ですよね。それはわかります」と言ってくれるような、仲間でいたいなということはまず前提として思っているんですね。

戸辺：なるほど。

藤倉：その中で先ほど言ったように経営の判断としては今これは返すべきじゃない、返せない。それよりも事業のアクセルを踏むべきなんだと、”今は”そう判断をしている。なので解消に関しては、こういう前提条件が揃ったら、もしくはこういうタイミングがくれば「そっちに舵をしっかり切るんだよ」ということはきちんと伝えるようにしていますし、そこで理解・納得・共感をしてもらうように、できるだけ努力はしているつもりですね。

戸辺：なるほど。わかりました。二串さんどうですか？

技術力のある一級のエンジニアの定義

二串：それについてご質問させていただいてもいいですか？　私も同感で、事業に対してコミットしていく姿勢をまず最重視して、そこにモチベーションを持ってもらうことは僕も大前提だと思っています。

その上で技術的負債があることに対する、個人としてのフラストレーションや成長阻害要因も一定あるかもしれないし、VS 新規事業の開発によるモチベーションをどう捉えていくのがいいのかを質問したかったところでした。

藤倉：そうですね。例えばレガシーな何かがあるとか、技術的負債があるとかの中で開発をしなきゃいけない。本当は、クリーンな状態だったら、生産性も非常に高いし、作りたいと思ったものがすぐ作れる、という話はあると思うんですね。

それがエンジニアとして……僕ももちろん、いちエンジニアの時代が長かったのでモチベーションにつながることは理解するんですけど、でも個人的な見解を言わせてもらったら、少しクリーンではないというか、影響範囲が読みにくいことだったり、リスクが捉えどころがないところでものを作っていくことが、テクニックとして非常に難しいことを求めていると思っているんですよ。

なので、そういうシーンをないがしろにしてほしくないなというか。技術力が高いということは、別に新しい技術のことを知っているとか、経験が深いことだけじゃないなと思っています。

むしろ、そんなものは時間をかければ誰でもできると思っているんですよ。それよりは理想的でないところでも最大のパフォーマンスを出すために工夫できる人が、本当に技術力の高い一級のエンジニアだと僕は思っているので、そういう話はしますかね。

「それが今の君にとって必要な瞬間なので、そこに今は一旦向き合おう」とか。もちろんそればかりだと疲れちゃうのであれなんですけど、それをやる意義みたいなものは事業的ないし成長観点で説明したりするケースはありますかね。

技術的負債の返済のあるべき姿

戸辺：そこは非常に共感しますね。モデレータの分際であれですけど、僕もわりと採用の場だったり、あとは1 on 1の場で「できるエンジニアとは何か」みたいな話になった時には、ほぼそれに近い話をします。

ごく限られたエンジニアだけが純粋なエンジニアリングスキルでエッジを出せますが、それは本当に限られた一部だけで、そのパターンも無きにしも非ずですが、一般的にそれを求めるのはかなり厳しくて。どちらかと言ったら、今、藤倉さんがおっしゃったところがいわゆるエンジニアとしての技術力が高いところだと私も思っています。

すみません、けっこうわりとすぐに時間が経つものでして、もうそろそろ締めないといけないところで、僕のほうで今聞いていたところの「技術的負債の脱出」を簡単にまとめさせていただきたいと思います。

聞いている中で、まず最重要なところ。エンジニアのマインドセットとしても、その事業に対してコミットするというところが大前提だと。これが非常に重要だなと思いました。

それによってビジネスサイドとエンジニアが目線を合わせることができて、対立構造にならないと。「日々の開発が大変」はけっこう視座の低い、スコープが狭い話であって、それによって低下している生産性と、それでも新規開発ができているところのROIをしっかり考える。

そこのトレードオフで、これ以上の技術的負債を抱えながら、いわゆる技術的負債を抱えている中での開発、そうじゃない時の開発に比べて、余剰にかかっている作業が、いわゆる技術的負債のメタファーにおける利息だと思うんです。

利息を返済するほうがまだ自分たちの事業スピードを高めるというところにROIがあるのであればまだ開発をして、一方で元本をある程度返さないといけない。

これがリファクタリングなどに相当するんですけど、元本を返さないと利息が大きすぎて新規開発自体のROIが、そもそもビジネスサイドや経営陣が期待している結果が得られなくなったら、リファクタリングをしていくところをある程度見える化をしていくのが重要なのかなと思います。

そうすれば今まで抱えている技術的負債の返済か、そうじゃないかみたいなトレードオフではなく、全体が事業の成長速度を意識して対応する上で、みんなが自然と同じ意思決定ができていくのが一番きれいな技術的負債の返済かなと思いました。以上です。ありがとうございました。これでパネルも含め、終わりにしたいと思います。