2021年5月18日にラクスル主催のTechイベント「技術的負債とどのように向き合い、解消すべきか」がオンラインで開催されました。
ゲストにはSansan株式会社 CTO・藤倉成太氏を迎えて、ラクスル事業本部HoE・二串信弘とともに登壇していただきました。
二人はそれぞれの会社でどのように技術的負債と向き合い、解消に向けて取り組んできたのでしょうか。
イベントの様子をご紹介します！
Sansan株式会社 執行役員／CTO
藤倉 成太
株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社。現在はCTOとして、全社の技術戦略を指揮する。
ラクスル株式会社 執行役員 ラクスル事業本部 HoE
二串 信弘
大学卒業後、IIJにてセキュリティサービスの運用・開発を担当。その後、DeNAにてモバイルゲームの共通バックエンドシステムの開発・運用、またインフラ部門においてサービスインフラを支える基盤システム等の開発を担当。現在はラクスル事業の開発をHead of Engineeringとして指揮する
１．メリット・デメリットを数字で比較して、正しい返済計画を
ファーストスピーカーの藤倉さんはこれまで日本だけでなくアメリカに長期赴任するなど、グローバルな開発経験が豊富です。
そんな藤倉さんのお話は、「どんなに優秀なエンジニアでも技術的負債を避けることは不可能だ」という結論から始まりました。
藤倉 「自社サービスの開発においては、新規プロダクトの立ち上げでも既存プロダクトの新機能追加でも、リリース前からユーザーに受け入れられるかどうかわかる人はいませんよね。仮説や見込みで取り組んで、リリース後にユーザーの反応を見ながら調整を重ねていくと思います。
またシステムは事業の成長とともに常に進化しドメインモデルも変わっていくため、最終的な形は誰にも予測できません。だから自社サービスのアーキテクチャー設計というのは、“その場その場で最適解を探す”という行為に過ぎないのです。
さらにソフトウェア技術の進化が激しいことは、みなさんご存知のとおりです。ひとつのシステムやサービスを数年かけて継続的に運用していけば、使用している周辺技術はどんどん進化して、放っておいても技術的負債は溜まらざるを得ない。この負債を回避することが難しいのであれば、“どうやって正しく返済していくか”を考えるほうが健全ですよね。」
まさにエンジニアに宿命づけられた課題とも言える技術的負債。だからこそ冷静に捉えて正しい返済方法を考えるべきだと藤倉さんは説きます。
そしてSansanで経験してきた施策をもとに、そのための具体策を展開してくれました。特に重要だと語ったのは、エンジニアの稼働状況を数値化するという点です。
藤倉 「機能の実現、またはパフォーマンスやセキュリティ要件の妨げになる技術的負債は返済が絶対条件なので、社内の合意も得やすく比較的解消しやすいと思います。むしろテクニックを要するのはメンテナンスコストの削減、あるいは将来の開発に向けた技術投資のために技術的負債の返済が必要なケースです。
まずメンテナンスコストについては、エンジニアの活動状況をしっかり数値化して投資対効果で考えることをおすすめします。エンジニアは新規開発だけを行っているわけではなく、エラーチェックや不具合の修正も行いますし、採用活動に関わる人もいます。エンジニアが使える全ての時間のうち、どれくらいメンテナンスに費やされているのか。技術的負債を解消すれば新規開発がどれほど短縮できるのか。そしてそのためのコストはいくらなのか。メリット・デメリットを数字で議論できるとスムーズですね。」
もちろん全てが簡単に数値化できるわけではありません。
藤倉さんによると、将来の開発に向けた先行投資は得られる結果を想像しにくいために、“不確実なものにどれだけコストをかけられるか”という企業の経営哲学やリスクコントロールに関わるそうです。
まずはエンジニアの稼働状況を数値化するとともに、エンジニア自身も自社の経営哲学やカルチャーを理解して返済計画を立案することが重要なポイントになりそうです。
スピーチ終盤では、気になる予算についても率直に語っていただきました。
藤倉 「リファクタリングのためのプロジェクトを立ち上げるのが一番わかりやすくて予算も確保しやすいのですが、これは容易に実現できるものではありません。当社で多いのは、メンテナンスの一環として定常的に技術的負債を返済するというアプローチです。自社サービスの開発運用を行っている場合は、プロジェクトチームのうちどのくらいの割合をメンテナンスに確保するか目安を立てるといいと思います。ちなみにSansanでは3～10％の間に設定することが多いですね。3％というと少ない印象かもしれませんが、エンジニア30人のチームで常に1人はずっとリファクタリング作業に当たれる工数です。そう考えると少し現実味がありますよね。」
まさに前者をプロジェクト立ち上げによる返済を一括返済とするならば、後者は地道な分割返済。事業状況やヒューマンリソースの多寡も踏まえた経営判断になりそうです。
最後に今回のテーマに関心を寄せるエンジニアに向けて、こんなメッセージで藤倉さんは締めくくりました。
藤倉 「技術的負債をどうしていいかわからない、解消したくても上司が承認してくれない、という話を僕自身も頻繁に耳にしています。今日お話したことは、僕が技術的負債を解消するためにSansan社内で実際に用いた手法です。いま技術的負債で困っている方が、少しでも話を前に進めるために、これらのテクニックを有効に使って役立てていただければと思います。」
２．エンジニアと非エンジニアの相互理解で協力体制を
続いて登壇した二串は、印刷や集客支援サービスを運営するラクスル事業部で2017年にスタートしたRaksul Platform Projectを率いた主要メンバーの一人です。
自社エンジニアに「これ以上リフォームできない家」と評されるほど複雑に絡み合ったモノリスアプリケーションをマイクロサービス化する試みは、“既存のラクスル の解体”と言われるほど大規模なシステム刷新でした。
はたして二串はどのように大規模な技術的負債の返済に取り組んできたのでしょうか。
▼資料はコチラから
二串 「ラクスルは2009年にスタートした歴史の長いプロダクトで、スタートアップにありがちなモノリスアプリケーションでした。しかし事業拡大に伴って技術的負債が膨らみ、エンジニアが増えても開発がスケールしないという課題を抱えていました。そしてまだ実現していない価値の高い機能も有効活用していきたい。そんな経緯でプロジェクトはスタートしました。これは非常に大規模プロジェクトで１～２時間では語り尽くせる内容ではないので、ここではあっさりと触れるだけにしておきます（笑）。
でもこの技術的負債の返済によって、非常に多くのメリットが得られました。まずはマイクロサービス化したことで、スケーラブルな開発が可能になったこと。スクラムチーム数も当初の3チームがで現在は10チームまで増えましたし、開発の生産性を測るデプロイ回数も順調に推移しています。事業として大きく成果が上がってきているんですね。
さらにグローバル規模のアジャイル開発が可能になりました。ラクスルでは昨年ベトナムとインドに開発拠点をオープンして、日本を含めて３拠点での開発体制が整いました。開発はそれぞれの拠点がプロダクト単位で協業しながら進めていて、これもマイクロサービス化なしには実現できなかったと思います。日本ではエンジニアの採用競争が激化しているので、世界規模で人材を登用できる意義は企業としても非常に大きいと思います。」
大規模なリファクタリングによって大きく向上したエンジニアの生産性。
やはり技術的負債はエンジニアにとって非常にクリティカルなテーマです。
しかし二串は「これはエンジニアだけの関心事ではない」と語ります。
二串 「私自身もこれはエンジニアだけの問題だと思っていました。でもビジネスにも新しい施策を実現できないジレンマがあるし、経営者にとっても技術的負債は事業のスタックや人件費が膨らむリスクと直結しています。技術的負債を何とかしたいのはエンジニアだけじゃない。私はプロジェクトを通じてそう気づきました。
だからこそ技術的負債の解消に取り組む際に、心がけたいテクニックがあります。それはエンジニアだけでなくビジネスやデザイナー、プロダクトマネージャーなどチーム全体の利害関係を一致させて協力体制を作ること。チームとして成し遂げたいことを掲げることで、技術的負債の改善は目標を実現する “手段” になります。その結果が新しい価値や強みの創出につながっていくわけです。この協力体制づくりでチーム内の垣根はなくなり、いい流れが生まれたなという実感がありました。」
まだまだ実質的負債はあるものの、それらを乗り越えて事業価値を上げることに成功してきたラクスル 。
二串はもう一つの要因としてラクスル の組織カルチャーについて紹介しました。
二串 「ラクスル はビジネスやエンジニア、デザイナーやプロダクトマネージャーも一緒になって普段からなんでも議論したり話し合うということが当たり前の会社です。だから技術的負債についても、問題を共有できる土壌があった。さらに言うとビジネスを巻き込むだけではなく相互理解、つまりエンジニア側も “ビジネスへの解像度を上げる” ことが重要なポイントですね。
Sansanさんでもラクスル でも言えることですが、複雑な産業やビジネスを相手にソフトウェアを作るうえで、エンジニアがビジネスやステークホルダーに対するリアリティを持つことは不可欠です。もちろんすべてを理解することは難しいですが、相互理解を大切にすることで技術的負債をうまくドライブする、というのがラクスル 流の技術的負債との付き合い方だと思います。
エンジニアだけで留まらず非エンジニアもどんどん巻き込みながら、ぜひチームで共通の目的を導入して協力体制を作ってみてはいかがでしょうか。また技術的な観点だけではなく、相互理解に基づいた組織とカルチャー作りが技術的負債の解消を後押しすることも知ってもらえればと思います。」
３．エンジニアのモチベーションはどこにある？
ラクスル株式会社 執行役員 ノバセル事業本部 HoE
戸辺 淳一郎
サッカープレイヤーを増やすことをミッションに掲げた会社の創業・経営をし、2015年4月にNewsPicksに参画し、VPoEを務める。2020年9月にラクスル株式会社へ入社。現在はノバセル事業本部の開発をHead of Engineeringとして指揮する
それぞれのお話の後はノバセル事業本部HoE 戸辺淳一郎がモデレーターとして参加し、スピーカーの2人が質問に回答する形でのパネルディスカッションが行われました。
戸辺 「まずは本質的な質問です。技術的負債の返済作業と新しい価値を作るための開発作業の優先順位をどうやってつけていますか？」
藤倉 「その2つは全く軸が異なるものなので、単純に並べて比較したり優先順位をつけたりすることは難しいと思います。
先の発表の中で紹介したように、新規の開発は続ける一方で、日常的に少しずつリファクタリングを織り交ぜておくというテクニックがひとつありますね。とはいえ事業の状況でどちらかに舵を切るときのために、エンジニアの稼働状況を常に数値化し続けておくことも必要です。新規の開発は続けながらも、わずかに落ち着いた瞬間に向けていつでも動ける準備をして、常にタイミングを計り続けておくという姿勢が大事なのではないでしょうか。」
二串 「限られたリソースのなかでどう事業の価値を上げていくか、経営の意思はやはり重要だなと思います。そして技術的負債のリスクの度合いをしっかり分析することですね。たとえばセキュリティのリスクであれば重要度を上げるべきです。
あとは負債の度合いやスピードにもよりますが、２つのことを背反と捉えるのではなく、
藤倉さんのお話のように一定のパーセンテージを技術的負債の返済に充てて、残りは新規開発に、というやり方も有効だと思います。」
戸辺 「藤倉さんはビジネスサイドや経営の理解を得るために計測したり数値として見える化することの重要性を説いていました。それ以外に経営メンバーを説得しやすい自分なりの方法をお持ちだったら教えてください。」
藤倉 「あまりないですね。僕は基本的に経営に対しては事実ベースで、人の感情やモチベーションなどのニュアンスを含めずに話すようにしています。というのも現場のエンジニアのモチベーションをあまり経営判断に入れ込みたくないんですね。例えば、技術的負債があるために１カ月で終わるものが２カ月かかる場合、エンジニアがそこに生産性の低さや、パワーを発揮できないもどかしさを感じてしまうのは理解します。でもいま抱えている技術負債も過去の判断によって受け継がれたもので、いまはそれをあえて返さないという経営判断がなされている。だからこの現状でベストエフォートな結果を出すことに合意していきたいなと思っています。」
戸辺 「なるほど。そのいっぽうで、技術的負債はモチベーション低下やエンジニアの離職率上昇と相関があると思います。その点は二串さん、いかがですか。」
二串 「経営メンバーには数値を使ってドライに話す、という点は藤倉さんと同じです。とはいえラクスルではエンジニアの感情みたいなものについては、定性コメントとして添えるようにはしています。ラクスルは複雑なドメインを扱っているため、一人ひとりの戦力が経営上も非常に重要ですし、技術的負債の解消がエンジニアの離職リスクに対しても有効に働くと思うので。」
戸辺 「藤倉さんはモチベーションの扱い方についてどう思いますか？」
藤倉 「私もモチベーションは絶対的に重要だと考えています。人の採用にはコストもかかりますし、せっかく加わった仲間を手放すのは非常に残念なことです。でも、お話した通り技術的負債はあることが前提の営みで、技術的負債がまったくない世界を望む人はこういう業界に来るべきじゃないとも思います。
なので当社のメンバーに対しては、事業を前に進めることをが開発の目的であるという前提や、いま抱えている負債を解消するタイミングや条件をきちんと伝え、できるだけ理解・納得・共感してもらえるように努力しているつもりです。」
二串 「私も藤倉さんに質問したいです。今のお話には同感で、事業へのコミットは最重視すべきです。それでも技術的負債の存在は個人のフラストレーションや成長の阻害要因にもつながります。その点はどうお考えですか？」
藤倉 「クリーンな状態だったらもっといいものがすぐ作れるのに、というエンジニアの気持ちは理解できます。ただ個人的な見解を言うとあまりクリーンではなく、影響範囲やリスクが捉えにくい環境でものを作る方がずっと難しいことですし、エンジニアとしての力が試されます。だからクリーンではない状況をあまりないがしろにしてほしくないんですね。むしろ理想的じゃない環境でも最大のパフォーマンスを出すために工夫できる人こそが、僕は本当に技術力が高い一級のエンジニアだと思っています。」
戸辺 「僕も採用や1on1の場で同じ話をするので共感しますね。ありがとうございました。
ここで残念ですが時間が来たので、最後に技術的負債からの脱出についてポイントをまとめます。
まずエンジニアは事業にコミットするマインドを持つこと。
ビジネスサイドとエンジニアが目線を合わせて協力体制を構築すること。
技術的負債を抱えながらの開発とそうでない場合の開発でROIをしっかり精査し、利息の返済（余剰なメンテと開発コスト）と元本の返済（リファクタリング）のどちらが事業成長を高めるのか、なるべく見える化すること。
こうしたポイントを押さえて行けば、技術的負債返済はする・しないのトレードオフではなく自然な意思決定できれいに返済につながっていくのではないかと思います。
本日はみなさんありがとうございました。」
ラクスル では今後もTech Talkイベントを開催します。
次回は7月7日にゲストにディー・エヌ・エー様をお迎えし、「『エンジニアの育て方と育ち方』～育成する側・育成される側に必要なもの～」というテーマでラクスル CTO泉とのCTO対談イベントを開催予定です。
是非、お気軽に参加してくださいね！
▼お申し込みはこちらから
https://raksul.connpass.com/event/213510/
Related Stories
関連するストーリー