広範囲のリファクタリングで立ちはだかる「3つの壁」
ミノ駆動氏の講演は、負債解消と設計改善の対象としているDMMプラットフォームについての説明から始まった。これはDMMのさまざまなサービスで共通的に利用されている基盤であり、会員管理や決済、ポイント付与や不正対策などマイクロサービスで構成されているものの課題を共通的に解決するプラットフォームだ。
対象となるサービスは40種類以上にわたるため、「広範囲の負債解消にどう取り組むべきか、これまで経験したことのない広いスコープに直面している」と言うミノ駆動氏。組織で負債解消に取り組む際に立ちはだかる3つの障壁について、以下のように示した。
1つ目は、チームごとに取り組む場合の弊害だ。技術負債の解消には、変更容易性に関する設計スキルが求められるが、チームごとのメンバーの設計スキルにはバラつきがある。品質向上活動やリファクタリングをチーム主体で行うと、上手くできるチームとそうでないチームの差が生じてしまう。
とくにリファクタリングは機能開発に比べて後回しにされがちなため、取り組みのスピードにも格差が生じやすい。さらには各チームが同じような検討を行うことで、工数の無駄が生じる問題もある。
2つ目は、リファクタリングの対象スコープだ。ミノ駆動氏は技術的負債を「将来の変更コストが高いコード」、リファクタリングを「未来の変更コストを低減する活動」と再定義する。この定義に則れば、将来的に変更される可能性が低い箇所までもを手当てする必要はないわけだ。「開発リソースは有限なので、必要な箇所に狙いを定めてリファクタリングを行うことが大切だ」。
3つ目は、質と学習コストがトレードオフの関係にあることだ。目の前のコードが負債化しているかどうかは、そのコードが理想的な構造かどうかを知って初めて認識できる。つまり、コードの良し悪しを認知できなければリファクタリングもできないわけだ。
「リファクタリングとはすなわち、理想の構造と現実とのズレを解消することだ。そして理想の構造を知るためには、学習コストをかけてシステムを適切に設計するスキルを手に入れなければならない。しかもこのスキルは、本などを通じてインプットするだけでなく、実際に手を動かし、試行錯誤を重ねて初めて身につくものだ」。ミノ駆動氏はそう話し、効果的なリファクタリングには質の高い知識が欠かせないと強調した。
「教育」と「レビュー」でレガシーを解消
続いて、ミノ駆動氏はDMM.comがこれまで行ってきた負債対策について語った。具体的な内容は以下の3点だ。
- さまざまな負債を横断的に解決する専門チームの編成
- 問題のあるコードや変更頻度の高い箇所を解析するツールの導入・開発環境の整備
- 負債解消の専門チームによる、他チームのプルリクレビューのレビュー
これらの取り組みにより一定の成果は得られたものの、期待していたほどの効果は得られず、コード品質に関するリテラシーの向上も十分ではなかったという。そこで、2024年5月よりDMM.comに入社したミノ駆動氏が見直しに入り、4つの改善策を挙げた。
1点目は、設計リテラシー教育の実践だ。技術的負債の弊害や特性、理想的な構造を知らなければ負債かどうかを認知できない性質を理解してもらったうえで、セキュリティ教育と同様に設計に関するドキュメントやスライドを読んでもらい、理解度テストを実施する形式を考えている。
2点目はミノ駆動氏の著書『良いコード、悪いコードで学ぶ設計』をベースにした設計ガイドラインの策定だ。例えば、プルリクエストのレビュー時に「このコードは本の○ページの問題コードと同じ問題を抱えています」というコメントを付けることで、レビューコメントのコスト低減や指摘内容の一貫性向上、エンジニアのスキルアップが期待できるとしている。
3点目は、各チームの設計責任者の育成だ。マーケットシェア理論の10.9％という数字を参考に、開発本部122人の約10％にあたる12人程度を設計責任者として育成。育成した責任者が自チームのプルリクエストをレビューすることで、設計改善の取り組みを拡大する取り組みをする。
4点目は、ミノ駆動氏自身によるモブプログラミング巡業だ。これは各開発チームに対してモブプログラミングを実施する試みであり、「私の経験上、スキルアップに非常に効果的」だと自信をのぞかせる。この活動はすでにスタートしているといい、「まだ1週間半ほどはあるが、すでにかなり品質の高いドメインモデルを設計できるようになってきている」と成果を述べた。
さまざまな難しさを内包する技術負債の解消は、一筋縄ではいかない。それでもミノ駆動氏は「多面的な対策を通じて、DMMプラットフォームの品質向上を図っていきたい」と決意を示し、講演を締めた。
