変化のスピードが速い現代におけるシステム開発では、できるだけ早くプロダクトを世の中に出してフィードバックをもらい、またプロダクトを磨く…というリーンな開発サイクルを高速で回すことが重要です。

しかし、「余裕のない状態で、負債を作ってでもサービスをつくり提供する」開発のトレードオフとして生まれるのが、「技術的負債」です。とくにスタートアップの開発では、将来の開発効率を犠牲にスピードを重視しなければならないシーンも多くあります。

では、技術的負債に対して現場はどのように向き合うべきなのでしょうか？ SELECKではそうした課題に向き合う企業の声をお届けすべく、9月1日（木）に技術的負債をテーマにしたオンラインイベント「SELECK LIVE! for Startup」を開催いたしました。

今回は、今最も勢いのあるスタートアップ企業であるカミナシ社、キャディ社、atama plus社の3社からそれぞれゲストスピーカーをお迎えし、個別発表、トークセッションを実施しました。

当日は350名近い方から参加申込みをいただき、Twitter実況等も大変な盛り上がりを見せました。今回の記事では、その内容の一部をダイジェスト版でお届けいたします！ぜひご覧ください。

▼ゲスト
株式会社カミナシ 執行役員CTO 原 トリ さん
キャディ株式会社 Tech Lead 河合 俊典（ばんくし）さん
atama plus株式会社 Dev Unit Success 深澤 良介さん

▼モデレーター
株式会社ゆめみ 取締役 / SELECK株式会社 取締役 工藤 元気

登壇各社の「技術的負債」に対する取り組みについて

1. キャディ株式会社 Tech Lead 河合 俊典（ばんくし）さん

「モノづくり産業のポテンシャルを解放する」をミッションに掲げ、製造業の課題を解決する受発注サービスや図面データ活用クラウド事業を展開するキャディ社。同社のTech Leadとして活躍する河合さん（以下、ばんくしさん）からは、「製造業×AI領域における技術負債解消の取り組み」をテーマにお話いただきました。

▼過去にキャディ社の開発組織について取材したこちらの記事も、ぜひ一緒にご覧ください。
【連載：成長組織のリアル】製造業×BtoBの「スルメ的」面白さを伝えたい。キャディ開発組織が挑む壁 – SELECK

2.atama plus株式会社 Dev Unit Success 深澤 良介さん

「教育に人に社会に次の可能性を」をミッションに掲げ、AI教材の「atama＋」を日本全国の塾や予備校に提供しているatama plus社。同社のDev Unit Successとして活躍する深澤さんからは、「急拡大しても成長速度を失わずにいるための組織と技術の変化」をテーマにお話いただきました。

3.株式会社カミナシ 執行役員CTO 原 トリ さん

「ノンデスクワーカーの才能を解き放つ」をミッションに掲げ、現場DXを支援するプラットフォームをSaaSとして開発・提供しているカミナシ社。2021年7月に同社のCTOに就任された原 トリさん（以下、トリさん）からは、「激撮！カミナシ技術的負債返済プロジェクト！～目撃者は語る～」をテーマにお話いただきました。

▼過去に、トリさんにカミナシ社のエンジニア組織について取材したこちらの記事もぜひ一緒にご覧ください。
「CTO不在」の5年間を乗り越えて。進化し続けるカミナシのエンジニア組織の現在地 – SELECK

▼また、トリさんの登壇資料をWeb上に公開していただきました。こちらもぜひご覧ください。
カミナシでの技術的負債プロジェクトとその決断 / Beyond tech debts at Kaminashi

本記事では、各社の発表のあとに続けて実施したパネルディスカッションの内容をまとめてお届けします。

負債に対して、共通認識をとるためのコミュニケーションはどうする？

ーーまずは、「負債もしくは将来的に負債になりうるリスクに対して、共通認識をとるためのコミュニケーション指標はありますか」というテーマですが、深澤さんはいかがですか？

深澤　そうですね、前提として弊社はビジネス側と開発側の距離が近い文化が形成できていると思っていて。

例えば、技術的な知識・経験のないメンバーが「Reactについて勉強したいんですけど、おすすめの本はありますか？」と質問した際に、「どういう目的で学ばれるんですか？」「それだったら、こういう学び方もありますよ」など、前のめりなコミュニケーションが活発です。なので、そもそも共通認識を作りやすい環境なのだと思います。

▼過去に、atama plus社のカルチャー形成について取材した記事もぜひ一緒にご覧ください
【連載：成長組織のリアル】カルチャーへの投資が「変化に強い組織」を作った。atama plusの軌跡 – SELECK

指標は定量的なものと定性的なものに分類されると思います。まず、定量的な指標でいうと、ソフトウェアは年月が経つにつれサポートが切れることがありますよね。そういった事前にわかることは、いつ何が発生するのかをリスト化しています。

定性的な指標は、メンテナンスコストを大・中・小で分類して、「この機能は価値提供につながっているね」とか「この機能はリファクタリングが必要だね」「コスパが悪いからこの機能は無くしていこう」など、定性的な観点からコミュニケーションをとっています。

これらの指標を元に「負債」と見做されるものに関して、改めてすべてリスト化し、いつまでに何をするべきか整理を行っています。

ーーばんくしさんにも質問がきていまして、負債を許容するか返却するかの判断をもしばんくしさんが個人でするとしたら、どのような基準でされますでしょうか。

ばんくし　あくまで個人の考え方ですが、負債返却がお金に繋がるかどうかがすべてだと思っています。たとえ負債を返却して技術的に素晴らしい環境になったとしても、 そのサービスが儲からなければ意味がないと思っていて。

負債返却を行うことで、最終的にどれくらい開発スピードが上がって、機能がいくつ生成されて、いくら儲かるのかまでを算出するのが技術的負債に対する責任かなと思ったりします。ただ、組織としては「お気持ち」で判断することもあるので（笑）、少し違うかなと。

ーー先ほどの深澤さんは「対話」を重視してる印象だったので、ばんくしさんのような合理的な判断とのバランスを取っていく感じですかね。

ばんくし　そうですね。組織という文脈では深澤さんのお考えにとても共感します。ビジネス側と開発側は、持ちつ持たれつの関係だと思うので。例えば、こういう機能を開発するので負債解消までこのくらいの期間をくださいと伝えることもありますし。

また、負債に焦点を当てすぎて開発が遅れてしまい、他のチームの目標達成を阻害するのは避ける必要がありますし、うまくバランスをとるようにしていますね。

負債解消にあたって、どうコミュニケーションをとっていくべき？

ーー次にトリさんへの質問なのですが、冒頭で事業がうまくいっていたから負債解消について経営陣にも理解してもらえたという話がありましたが、事業がうまくいってなかった場合はどうお話をされますか？

トリ　おっしゃる通り、事業がうまくいっているから理解してもらえた部分はあると思います。では、そうでない時にどうすべきか…というと、そもそも負債を解消する必要があるのかは見直すべきではないかと。

事業がうまくいってないのに開発を進めるのは、プロダクトマネジメントのアンチパターンをやっているだけな気もします。

細かい技術的な負債の返済より他にやるべきことがある場合もありますからね。例えば、ユーザーが全く使っていない機能を捨てるとかが最適解な場合もあると思います。

ーーなるほど、ありがとうございます。では、先ほどのコミュニケーションの話も絡めて、このような場合にどうチームを動かしていくべきかのアイデアがあればと思ったのですが、深澤さんいかがですか？

深澤　そうですね…個人的な考えではありますが、新しい機能を作るときに生まれてしまう「本当は不要だった」オーバーヘッドを技術的負債と定義すると思っていて。

今最も優先すべきことは何か、開発にどのくらいの時間がかかるのか、最短で成果を出すためには何を優先すべきか、最短ではなくとも中期の方が成果を出せる可能性があるのではないか、など複合的に考えた上で論理的な議論ができるのであれば、そもそも事業がうまくいっているかどうかは問題にならないのかなと。

ーー次の質問なのですが、「将来性や開発のスピード感が変わると、エンジニアリングチームはどう負債を捉え直しますか。また、その際にどうビジネスサイドとコミュニケーションをとりますか。」について、ばんくしさんはどうお考えでしょうか。

ばんくし　非常に面白い質問ですね。先ほどのお二人は非常に大人な回答だったので、まさにその通りだなと思いながら聞いていました（笑）。

結局、その事業が儲かるかどうかが重要かと思うので、そこに対して我々が技術者として考えられてるかが最終的なポイントになるかと。

先ほども話に出ていた、「新しい機能を作るとき」の話は、プロダクトマネジメントの教科書の1ページ目に書いてあるような話だと思っていて。PDCAを回しましょう、ミニマムなモックを作って回していきましょうというのは当たり前なんですが、その上で生まれた技術的負債についてのコミュニケーションは非常に難しいと思っています。

もっと大人な回答はできる前提でちょっと壊しに行くと（笑）、コミュニケーションを取らないという選択肢も一つあるかなと思っています。つまり、エンジニアのエゴによって技術的負債を解消するというパターンですね。

例えば、1、2日ぐらいエンジニアで合宿に行って一気に直してしまうとか。または、一部の機能をOSS化することでビジネスに貢献するという違う方向から攻める形で技術的負債を解決する方法もあると思います。

ーーここで、トリさんが笑みを浮かべながら頷かれていたので、何か思いを馳せているのかなと…（笑）

トリ　僕は経営者という立場になってしまったので、経営陣や色々なチームへの説明責任を果たす必要があるのですが…。

そもそも負債解消をプロジェクト化しようと思ったのは、エンジニアメンバーが「仕事楽しくねえ」という空気感になっていたのが嫌だったからですね。だって、ゲロまみれの環境で働きたくないじゃないですか（笑）。

僕は技術的負債を片付けたからこそ得られるものがあると思っていて、それを提供したかったという思いがありますね。

ばんくし　その根源的なWillって忘れちゃダメですよね。最終的にお金の話はするものの、「メンバーが今、楽しくなさそうだ」というような気持ちは大事にすべきかなと。

そのような気持ちがエンジニアに伝わっている状況であれば、プロダクトを取り囲む状況が変化したとしても、「ま、今はちょっと状況をのんでこれを直そう」ということが伝えやすいかなと思います。なので、良くない状況だと感じていることは、日頃からメンバーに伝えていくべきかなと。

技術的負債の解消を、社内でどう評価する？

ーー何をやるか、やらないかの意思決定の根幹にWillや経済合理性が含まれているのかなと思ったのですが、これをエンジニアリングチーム内で継続していくコツや実践されてるってことはありますか？

ばんくし　もう結構言っていくしかないですね（笑）。仕組みとして相互レビューもありますが、 結局「エンジニアリング的にはこうしたいけど、ビジネス的にはこうすべきだからこうしよう」と、流れることも多くて。

会社のエンジニアの評価制度もあると思うんですけど、やはりビジネスに貢献した人の方が評価されやすい面もあるので、「ちょっと苦しい状況だけど、負債を解消しよう」という流れに行きづらい感覚もありますね。

なので、相互レビューだけではなくて一部をルールにしていくとか、絶対やらないことなどをチームで決めていて、それを伝えていくしかない気はしていますね。この辺は、お二人の意見も聞いてみたいです。

トリ　僕もやはり、評価制度はきちんと整えないといけないと思っていて。新規機能をバッと作ってリリースしたみたいな、ビジネス側のレベニューに繋がる仕事ってどうしても評価されやすいんですよ。そんな面白い仕事やってる上に評価されるとかずるくない？　というのはありまして（笑）。

負債返済もそうですが、泥臭い仕事してたりとか、運用を支えているエンジニアとか、サービスのライフサイクル全体に対して貢献しているエンジニアこそ僕は評価されるべきだと思っていて。それをうまく綺麗な言葉で評価制度に落としたいんですけどね…それが、なかなか難しいんですけど。

ーービジネスサイドや会社全体として、技術的負債を解消していることをしっかり評価してあげないとどんどん人が辞めていくリスクも高まりそうですね。

トリ　そうですね、基本的には負債を作っているのはエンジニアリングだけではありませんからね。その事実を、ビジネスサイドにも伝える必要があると思い、社内のコミュニケーションは工夫しているところですね。

ーーでは実際に、どのように負債返済を評価していくべきなのでしょうか？

深澤　僕は、ある程度は定量的に評価できると思っています。例えば、デプロイの成功率や開発のリードタイムを計測した上で、その改善につながる施策を炙り出し、さらに課題の整備まで言語化できれば評価の対象になりうるのではないかと。それらは開発を促進させるため、あるいは巡り巡ってビジネス自体の加速に寄与していますからね。

それらの情報が蓄積されてくと、みんなの共通言語として機能し、違うプロダクトを作る際にもプロジェクトの評価として繋げられるのではないかと。

ばんくし　キャディのAIラボでは、「スモールウィンシート」という取り組みがあります。具体的には、 スプレッドシートにいつ、誰のウィン（win）がすごかったのかを書いていくだけなのですが、結構うまくワークしていると思っていて。

結局、エンジニアからすると負債を返却できて、良い座布団付きの椅子になった時に、すごい褒められるし喜ばれると思っていて。

そういった声を可視化しつつ、「エンジニアの中であの人すごい崇められてる！」のような立ち位置を作ってあげて、それを言語化してビジネスの人に伝えるような感じですね（笑）。「この人のおかげで今があるから、すごいんだよ」という、気持ちの部分を共有するのも一定の役割かなと。

ーーなるほど、とても面白いですね…！技術的負債は組織全体の課題でもあるのに、どうしてもエンジニア側に責任が寄ってしまうことに対して、どう見せていくか？　という問いに対してのアイデアが生まれましたね。

トリ　めっちゃわかりやすい評価ですよね。負債返済した結果、お客さまからの問い合わせの数が明確に減ったとなれば、サポートのチーム側から見ると画面は別に何も変わってないんだけど、言葉にして伝えることで、「すごい変わったんだな」という空気感は生まれますよね。

メンバーの入れ替わりや、新規メンバーの加入によって発生した負債はどう解消する？

ーー次の質問ですが、メンバーの入れ替わり、新規加入などによって発生する負債に対してはどう対策・解消されていますかという質問です。キャディさんは最近組織が拡大しているとのことでしたが、オンボーディングなどは実施されていますか？

ばんくし　オンボーディングは、AIラボでは一定やっていて、例えば先ほどのアグリーメントの読み合わせをやったりしています。

質問への回答としては、ある程度ルールで縛るしかないと思っています。具体的には、複数ツールの利用を禁止するとか、複数のデータベースを使わないといったルールですね。最近だとモノレポを試そうとしていて、結構厳しく複数の枠組みを持っておく必要があるなと感じています。

トリ　カミナシの話でいうと、5週間にわたって機能開発を止めてリファクタリングしていた対象が、まさに過去にエンジニアリング側が自ら生み出して負債化したものだったんです。

一つ例を挙げると、Go言語で書かれたAPIサーバーがありまして、負債返済をプロジェクト化する前のタイミングでは、それなりに複雑なパッケージやコードの構造になっていました。おそらく最初作った時は、その複雑さをアプリケーションに持たせた理由がなにかあったんだと思うんですよ。

ただ、経緯や背景はドキュメントにないし、今コード触ってる人からすると、なぜこの一行を書き換えるために5、6枚もファイルを書き換えなきゃいけないのかという疑問が生まれるんですよね。必要性が見えないから。当時必要だと思っていた複雑な設計は実は不要だったのかも、ということも今ならわかるという話で、そういったものをあるべき形に整えていくというのが6月頃にやっていた負債返済の例です。

なので、今後はこういった必要性が見えにくい複雑性を産みにくくする必要があり、その対策として取り組んでいるのがドキュメンテーションです。

とはいえ、ドキュメントって書いた経験がないと全然書けないんですよ。だから筋トレと一緒で、最初はしょぼいドキュメントでもいいから書いて、レビューをもらいながら良くするというプロセスを苦しみながら繰り返すしかなくて。なので、良いドキュメンテーションを書いたエンジニアが出てきたら異様に嬉しくなって、個人のSlackチャンネルで盛り上がったりしてますね（笑）。

ーードキュメンテーションはトレーニング可能なスキルであると。かつ、それをオープンにすることが大事だということですね。

トリ　そうですね、誰かが読む前提で、何のために書くかを意識するところからスタートして、 少しずつ良いドキュメントが書けるようになっていくので。設計面で考慮が足りなかった、あるいはtoo muchなものが生まれないようにするためにドキュメントはレビューの段階でとても機能すると思います。

深澤　ドキュメントの作成も大事だと思う一方で、どんな時にどういうドキュメントに当たればいいのかがその人のケイパビリティや目線の高さに委ねられてしまう点も課題だなと思っています。

なので、ある程度はコーディング規約を作ったり、自動検出するテストによって負債を防ぐ仕組みを作っていく必要があるなと。同時に、解釈の余地が大きいところは日本語で書いて、ドキュメントとして背景を把握できるようにしつつも柔軟性を持たせるということが大事かなと思います。

色々なことを同時に意識しなきゃいけないとなると、頭の認知負荷が限界になると思うので、少しずつ仕組み化していかなければならないと思いながら聞いていました（笑）。

スタートアップと大企業を比較して、技術的負債との向き合い方に違いは？

ーーそれでは最後の質問ですが、今日登壇してくださっている皆さんはもともと大企業での経験もお持ちですよね。ビジネスとしての既存アセットは価値あるけど、技術で見たら負債として大きい状態も大企業ではあるのかなと思ったのですが、皆さん転職して何か感じられましたか。

ばんくし　いい質問ですね。やはり、キャッシュフローは大企業とスタートアップでは違いますよね。大企業はある程度余裕があるので、サービス開発と同時に別のプロジェクトとして負債の返済を進めることができます。

一方で、スタートアップは次のシリーズや上場に向けて、あるいはユーザーに向けてサービスを提供していかないといけない立場であって。この例えとしてよく言うのは、「崖から落ちながら飛行機を作る」ようなことをやっていかないといけないんですよね（笑）。

どちらかが飛行機を作って、どちらかが崖からゆっくり降りてということはなかなかできなくて。そこが大きな違いだと思いますね。なので、その優先度を常々話し合う必要もあります。

トリ　僕も同じような感覚ですね。前職のAWSは大企業だったので、「これをやったら会社が潰れるかもしれない」と心配することはほとんどありませんでした。

でも、カミナシに移って負債返済をプロジェクト化すると意思決定した時、脳内では「これがカミナシを潰すことになってしまったらどうしよう…」という不安は一定ありましたね。そうならないように血を吐きながら頑張るんですけど（笑）。

深澤　僕もキャッシュフローの違いは大きいと感じますし、スケール感も全然違うなと。例えば、「標準化」って大企業にとっては足かせになる場合もあれば嬉しい場合もあって、いくつかの解釈があると思います。

とはいえ、「（大企業では）標準化がされていたからこそ、楽できたな」と今だから如実に感じることもあって。それをどう土台のレベルを上げながら育て上げていくかは、体力のある大企業とスタートアップでは全然違うので、悩みながら付き合い続ける必要があると思っています。

スタートアップだからと限定できないのですが、私たちは事業ドメイン的にも技術的負債がある意味生まれやすい環境にあって、元々こういう解釈じゃなかった？　ということが日々見つかるんですね。なので、スタートアップは刺激的な環境に晒されてるとは思います（笑）。

ーーなるほど、すごくいい締まり方でした（笑）。みなさま、本日は本当にありがとうございました！（了）

おわりに

いかがでしたでしょうか。そもそもなぜ技術的負債は生じるのか、負債に各社がどのように向き合っているのかなど、たくさんの知見が詰まったお話をしていただきました。皆さまの技術負債との向き合い方のヒントになれば幸いです。

今後も、現場で役立つナレッジをお伝えするイベント「SELECK LIVE!」を、定期的に実施していきますので、興味のある方はぜひご参加くださいませ。