チーム組成、リアーキテクチャ、AI活用。多角的に技術的負債と向き合うLT大会【イベントレポート】

進化し続けるWeb開発の世界において、「技術的負債」は避けては通れない課題。限られたリソースの中で、常に「負債」と隣り合わせの状態をどのような現状をどう打開すれば良いのだろうか。

9月12日に開かれたレバテック主催のライトニングトーク（以下・LT）大会「Tech-Debt Meetup ～技術的負債と向き合うLT Night～」では、弁護士ドットコム、SmartHR、Resilire（レジリア）、リンクアンドモチベーションの4社からゲストスピーカーが登壇し、技術的負債の解消に向けた取り組みについて共有した。

本レポートでは、各LTの内容を抜粋して紹介する。

• keyboard_arrow_down 技術的負債を社内で解消した5つのパターン【SmartHR 迫康晃氏】
• keyboard_arrow_down 組織を巻き込んだ負債解消の裏側【弁護士ドットコム 井田浩義氏】
• keyboard_arrow_down エンジニア社員数「1」で始めたリアーキテクチャ体験記【Resilire 彌冨輝彦氏】
• keyboard_arrow_down AIとともに歩む技術的負債返済の道【リンクアンドモチベーション 中上裕基氏】
• keyboard_arrow_down 目的に応じて個人情報開示ロジックを共通化した実例【レバテック 馬塲俊弥氏】

最初に紹介するのは、クラウド人事労務ソフトを開発するSmartHRの迫氏によるLT「SmartHRにおける技術負債への対応パターンと実例」。

技術的負債への向き合い方を5つのパターン別に紹介した。

まずは、技術負債を解消するための専門チームを組成する「チーム組成型」だ。 新しくチームを立ち上げるケースや、 すでにある1チームで問題にあたるケースがある。

「リアーキテクチャなど、長期対応が必要な時によく取る手段だと思います。 専門チームを組成すれば、腰を据えて負債解消にあたれます。ただ、長期でチームを張るという意思決定自体はかなり難しいと思っています」（迫氏）

SmartHRでは実際、「部署不定問題」を解消するプロジェクトでチーム組成型を利用して取り組んだという（※）。
SmartHRのプロダクトチームが直面した「部署不定問題」とは、サービスに登録する従業員データに結びつく部署情報の内部順序が固定されていない事象により、部署情報に変動が発生すると、参照先が変わってしまい、権限やその他アプリに影響を及ぼす問題だ。
そこで、従業員と所属する部署に関する情報の紐づけ構造を変更するために、テーブル構成の変更とそれに伴うデータコンバートを2年半ほどかけて行った。
※参照記事：https://tech.smarthr.jp/entry/2024/02/29/091419

タスクフォース型は、期間を限定して専門チームを作るという点でチーム組成型と似ているが、2、3名ほどの少人数で短期の問題に対応するという特徴がある。
より期限の迫った問題に人を募って注力するケースが多いといい、迫氏は「緊急で担当者をアサインする分、もとの開発チームから人が離れるのでそのチームのベロシティ（作業量や作業速度）が下がってしまうというデメリットもあります」と付け加えた。
実際に、給与明細の配信機能を改善した事例、 インフラを google クラウドに移行した事例では、タスクフォース型を用いたという。

イネイブリング型は、会社として経験したことのない課題に対して、 社内のイネイブリングチームと協力して負債解消に当たるという方法だ。
SmartHRでは、コード量が多いプロダクトに対し、単一プロセスで一つのアプリケーションを区分されたモジュールに分割する「モジュラーモノリス」 というアーキテクチャの導入を進めている。膨大なコードの中から依存関係を洗い出し、モジュールを分割する境界を探索するという作業は難解だが、 DPE（Developer Productivity Engineering）ユニットがRuby動的解析ツールを作成し、各チームにインプットする形式をとった。

4つ目のコミュニティ型は、普段、各チームで開発しているエンジニアが有志が集まって定期的に活動する方法だ。ライブラリのアップデートのように、放置すると後々負債になってしまう問題に少しずつ時間をかけて対応していく。
具体的には、1週間に1度、1時間ほど集まり、その中で課題を洗い出して少しずつ対応していく。ただ、限られた時間で大きな問題には対応しきれない場合もあるのが難点だ。
例えば、Railsのバージョンを上げるのに、 特定のライブラリの機能に依存していて、機能を改善するにはどうしても時間が足りないという場合だ。迫氏によると、そのような場合はタスクフォースを組むなど別の方法に切り替えて対応するという選択肢があるという。

最後の割合型は、スクラム開発のスプリント内に改善を加えるアイテムを1つ組み込む方法である。
大きな負債の解消には不向きだが、リリース前に見送った修正をリリース後に組み込んで対応する、といった比較的小さな負債の解消に適している。

「技術的負債といっても、内容も大きさも様々なので、絶対的にこういう方法がいいというのはなくて、その時々でやり方を 詮索しているという形になります。 チームを組むなど、 周りと協力をしながら解決に向けて取り組んでいます」。迫氏はこう語り、発表を終えた。

先の５つのパターンのうち、「チーム組成型」の事例を深掘りしたのが、契約マネジメントプラットフォーム「クラウドサイン」を手がける弁護士ドットコムの井田氏だ。LTでは、負債解消にあたる専門チームの設置経緯や社内で理解を得る工夫が語られた。

弁護士ドットコムでは、PdMやデザイナー、エンジニアらが横軸で連携する「レーン」をつくって、クラウドサインの開発にあたっている。
ここで技術的負債の解消にあたるのが、「改善レーン」と呼ばれる2つの専門チームだ。

開発開始当初は無かった改善レーンだが、プロダクトの成長とともに技術的負債が膨らみ、EOLを迎えるミドルウェアからの移行やパフォーマンス改善などを、片手間で進めるには手が足りなくなっていた。
そこで組織改編のタイミングで社内交渉を試みると、幸いにも理解を得られ、最初の1レーンを設置できた。

ただ、設置した１チームはバックエンド主体となり、フロントエンドでも専門チームが必要となった。増やすとなれば、「機能開発するレーン増やせないの？」と意思決定者に渋られる可能性も出てきて、説得の難易度は上がった。
なによりも「意思決定者に理解をしてもらうことを大切に考えた」という井田氏は、技術的負債についてたとえ話を用いて経営幹部に説明した。

経営幹部たちは「わかりやすい」と納得し、専門チームの拡大に合意してくれたという。

井田氏は「技術的負債解消の取り組みはエンジニアによる技術手法の課題だけではありません。より多くの人を巻き込んで、組織で技術的負債の解消に取り組んでいってもらえればと思います」と力を込め、発表を締めくくった。

サプライチェーン管理サービスを展開するResilireの彌冨氏は、表題のLTにて社員エンジニア数1からいかに組織を形成していきながらリアーキテクチャをやりきったかを説明した。既存のデータ構造やインフラに起因して始めたプロダクト全体のリアーキテクチャ経験と、そこから得た教訓を伝えた。

Resilireは2018年創業のスタートアップだ。プロダクトのリアーキテクチャに踏み出す背景として、彌冨氏はデータが正規化されておらずプロダクトの今後を踏まえると再利用の難易度が高かったことを挙げた。それに加えて、Proof of Concept（概念実証）としてつくり上げたプロダクトのエンタープライズ企業による利用により想定外の負荷となり障害が多発していた。リリース当時のエンジニアが残っていなかったこともあり今後を見据えて、データ構造やインフラからつくり直すことを決めたという。

発表では、彌冨氏が開発チームに加わった2022年の10月からリアーキテクチャをリリースした2024年の4月までの約１年半を６つの段階に分けて振り返った。

1. 1. 土台設計 / 土台調査期
2. 2. 開発準備期
3. 3. 仕様設計期
4. 4. 低迷期
5. 5. 仕様再設計期
6. 6. 圧倒的飛躍期

 

最初の土台設計のフェーズでは、ミッションやバリューの再定義を含む組織設計、エンジニアの採用活動のほか、プロダクト仕様のキャッチアップ、既存プロダクトの運用保守とインシデント対応、新規プロダクトの設計に追われた。

開発準備期には、アーキテクチャの検討、インフラの構築、技術選定を行い、その後の仕様設計期には、顧客が使うウェブシステム部分と、データを取ってくるクローラー部分の仕様設計を一気に進めた。

しかし、その後仕様が二転三転し、リソース不足やプロダクトの仕様設計と実装の分断が起因して、うまく開発が進まない低迷期に入る。

そこで、仕様再設計期に開発プロセスや責任の明確化を進めて体制を立て直し、リードクラスのメンバー増員が圧倒的推進力となり、その後のリリースにこぎつけた。

最後の圧倒的飛躍期では、仕様スコープの限定、スケジュール管理の徹底、打鍵テストの積極的な実施、実装の修正を進めることがスピードアップにつながった。

彌冨氏によると、リアーキテクチャを完遂したことで、「前向きに開発に向き合えるようになった」「プロダクトの初期フェーズからみんなで経験したことで組織、技術、プロダクトが連動した体制をつくることができた」といった収穫があったという。

一方で、リアーキテクチャの期待値が「銀の弾丸」となって結果的にスケジュールの遅延を招いたり、優先順位、責任役割、開発プロセスによどみがあると作業が停滞したりしたという反省もあった。

彌冨氏は、「プロダクト開発自体はまだまだこれから。今は負債をリセットしたことで、PMFへ向かう0の状態にリセットできたような状態です」とまとめた。

リンクアンドモチベーションの中上氏は、AI開発ツールを活用してフロントライブラリーのアップデートに取り組んだ事例を紹介した。

中上氏が直面した技術的負債というのは、Vue.jsにおける大量の非推奨構文だった。
148ファイルの計200箇所で修正する必要があり、自動化も容易でなかった。

窮地を救ったのが、AIを活用したペアプログラミングツールのAiderだ。
Aiderは、CLIコマンドで操作できるため自動化に適しており、指示に基づいてGit操作やファイル修正、テスト実行まで行える。

具体的な作業は以下の通り。
Aiderに修正箇所、方法、条件などを明記して指示を出し、その動作を確認した。例を補足するなどの工夫で、Aiderは期待通りの修正を行うようになった。

そこで、次に修正作業の自動化を試みた。Aiderにコマンド生成を指示し、生成されたコマンドを改良することで、プルリクエスト（PR）の作成まで自動化することに成功した。
この自動化プロセスを繰り返し実行することで、128件のPRが生成された。
結果として、148ファイルのうち103ファイルはAiderによって無事修正できた。
残りの約30%は手作業での修正が必要だったが、ファイル数が絞られたため負担は軽減された。

「実際にAiderを使ってみて、いろいろ試したり、手直しをしたりしたので、工数がすごく減ったというわけではないのですけれど、PR作成はすごく楽になりました。それ以上に、気持ちの負担が減りましたね」（中上氏）

単調な手作業ではなく、AIツールを試したり、自動化を工夫したりという作業の割合が増えたことで、モチベーションが維持しやすくなった。また、隙間時間を活用して作業を進められるようになったことも、負担軽減につながったという。

最後に、中上氏にとって技術的負債に向き合うコツは「小さくする」ことだと語った。
膨大な修正作業を分解して、AIツールや他のメンバーに任せられるようなタスクに細分化したことで、作業量を現実的な規模にまで縮小し、最後までやり切ることができるのだ。

最後に紹介するのは、「呼び出し元に依存しない共通化で安全に開発をする」と題したレバテック馬塲氏のLTだ。

馬塲氏のチームで開発する就活支援サービス「レバテックルーキー」は、企業に対して学生の個人情報の開示を行う際に、スカウトの承諾結果やプロフィールの公開範囲など、様々な条件が存在する。

ただ、細かな条件設定に対応すべく機能拡張を繰り返したことで、プロフィール情報を扱うロジックがコード単位で分散した状態になり、表示ロジックの改修に工数がかさむようになってしまった。
馬塲氏はこの「負債」を解消するため、ロジックを共通化するという方法を選んだ。

共通化の方針は以下の通り。

上記に沿ってロジック部分のみを共通化し、受け取ったデータを元に表示可能なプロフィール項目を判定する、そして必要なデータを渡すという形で実装した。これにより、共通ロジックの改修箇所は1つに集約され、実装自体は楽になった。

しかし、呼び出し元であるプロフィールの表示ロジックに誤りやデータの不足があった場合、表示項目に不整合が生じるようになった。これでは共通ロジック単体で動作を保証できず、安心して開発を進められない。

作業効率化がデータの正確性担保か、チームは選択を迫られたという。

データ取得の重複が生じることに伴うパフォーマンス低下の懸念はあったものの、最終的には、馬塲氏はパフォーマンスよりもデータの担保を重要視した。重複を許容しつつ、機能やプロフィール取得ロジックごとに必要なデータを取得し、結果の整合性を保証する設計を実現した。

馬塲氏はLTの最後に、共通化により負債を解消する際のポイントとして「扱うデータや機能によって共通化の方針を決めること」と「呼び出し元に依存せず、内部で完結させること」を挙げた。こうすることで負債を解消できるだけでなく、メインの機能実装に注力でき、余計な作業にリソースが奪われにくくなると、「いいことづくめ」だとセッションを締めくくった。