レガシーコードとどう付き合うか - Forkwell Library #25に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第25回目では2023年5月23日発売の『レガシーコードとどう付き合うか』を取り上げます。

「なぜ技術負債が生まれるのか」 「なぜレガシーコードが生まれるのか」 そういった疑問を持ったことがある人は少なくないのではないでしょうか。 本書はなぜレガシーコードが生まれるのかという背景から、レガシーコードに遭遇した場合に何から手を付ければいいのか、具体的にはどのようにレガシーコードを改善していけばよいのかを丁寧に解説しています。 基調講演では長年現場でのエンジニア経験と，直近所属していた企業では CTO としてのキャリアを歩んできた めもりーさんをお招きし、第1章「なぜレガシーコードが生まれやすいのか」と第4章「レガシーコードを改善するための準備」の解説をもとに「なぜ企業はエンジニアリングの推進が必要不可欠なのか」についてお話しいただきます。

会の様子

発表の前提

本発表の前提として、レガシーコードは「資金不足や人材不足によって生じたコード」、技術的負債は「技術的な課題全般」という風に定義をしていると冒頭に話がありました。

スタートアップの予算

最初に今日する話の前提として、スタートアップの予算の話がありました。

スタートアップでは「資金調達」をする必要があるという話や、銀行から融資を受けるデットファイナンス/自社の株を投資家に売却するエクイティファイナンスというファイナンスの分類に関する話がありました。

スタートアップでは会社が生き残るためにこのファイナンスを集めることが必要不可欠であり、エクイティストーリーやエクイティストーリーに合致したランウェイが非常に重要になってくるということです。

大企業の予算

引き続き今日する話の前提として、大企業の予算の話がありました。

大企業の場合はスタートアップと異なり、ビジネスが成立しなければ会社ではなくPJをたたむような状況になりがちだという話や、資金繰りに悩むことは少なくすでにある企業を買収してプロジェクトを始動することもあるという話がありました。

また、すでにある企業を買収する場合は、技術的負債が発生しやすい点もポイントだということです。

事業を営む目的

続いて、そもそも事業はなぜ必要なのか？という話がありました。

事業を継続する真の目的は多種多様であるものの、表向きとしては「ビジョンを達成するため」になることが多いそうです。

ビジネスモデルによるエンジニアリングの必要性

ガストの配膳ロボットなどを例とした現場のオペレーションが必要なビジネスでは、労働集約型ビジネスと呼ばれ、エンジニアを抱える必要はないという話がありました。

一方で、労働集約型ビジネスの対義語にあたる資本集約型ビジネスやITエンジニアやコンサルタントが必要な知的集約型ビジネスもあるということです。

知的集約型ビジネスには、営業主導であるセールスレッドグロース*1、プロダクト主導であるプロダクトレッドグロース*2の2種類があるということで、どちらもメリットデメリットがあるのでこのバランスを取っていくことが重要だというお話がありました。

エンジニアリングと人件費

これまでの話を踏まえて、エンジニアリングは「コスト削減」「ペイン解消」の2パターンに分けられるというお話がありました。

「コスト削減」は業務効率化などが例として挙がり、ペイン解消は子供のおもちゃをどう買ったらいいのかを提案する*3と言ったものが例として挙がるそうです。

知的労働は結果的に0にはならないものの、エンジニアリングの究極の理想の一つは従業員が0になっても問題なく回るような状態になることだということでした。

他にも、限界利益率の改善もエンジニアリングの大きな役割の一つだという紹介がありました。

レガシーコード改善の理由

これまでの話を踏まえて、レガシーコードの改善がなぜ必要か？という話に移っていきました。

レガシーコードは機能開発や機能改善にめちゃくちゃお金がかかるため、人件費が膨大に必要になったり生産性が悪化することが問題になってくるということで、これまで話をしてきた事業戦略を支えるために必要不可欠な活動だという話がありました。

また、別の側面として、エンジニアたちのモチベーション向上にもレガシーコードは重要であるというお話がありました。

Q&A

セッションが終わったあとはQ&Aがありました。以下、内容を一問一答形式かつ常体で記載していきます。

レガシーコードを改善すべきかそのまま保守すべきかの判断はどのようにすればいいのか？

マーケットの変化の幅は一つの目安として挙げられる。変化が速ければ速いほど改善が必要。また、生産性などを定量的な指標で監視しておくことも重要。

レガシーコードであることを経営層に証明するためには？

レガシーコードであることを証明するというよりは、アプリケーション品質の定量化や減価償却のメタファーを活用すると良い。(めもりーさんはビルの設計をメタファーにして話すことが多い)

エンジニアチームとして負債解消への意識付けや取り組み方を知りたい

解消する必要がないと思っている場合は、前述した経営層向けの見せ方と同じ。

リソースが全然足りていない場合は、まず余裕を作るところからになると思っている。

なお、HOWに関してはめもりーさんの著書よりも「レガシーコードからの脱却」などに詳しく書かれているので、そちらを参照すると良い。

今から新規開発する場合はどのような理由や状況でコードがレガシーになっていくのか？

オーバーエンジニアリングや遅延報酬が働くことによる知識不足(テストを書かない)でレガシーになっていくことが多い。

リファクタへの理解があまり得られないときの話し方はどうすればいいのか？

新しいものを作るところで本当に数字が上がるの？という話をまずする。
ただ、既存のPMFしていないようなプロダクトでリファクタリングが必要だと話すのはおかしいので、リファクタリング対象のプロダクトの売上を見ることが大切。

セッションの結論が今ひとつわからなかった・・・(時間の関係で最後の方はスライドを飛ばしながらの説明だった)

セッションの結論としては、CTOとエンジニアで技術的負債を目に見えるような形で表現し、会話しようということだった。

自動テスト導入の根拠はどう説明するのか？

変更失敗率だったり、機会損失額だったりを説明する。

0からフルリプレースするのかリファクタしながら既存ビジネスを活かすかなどの技術戦略に落とし込んだ知見がもしあれば聞きたい

今度1時間取るので直接話す。

エンジニアリングの適正量はどのように評価するのか？

目の前の3ヶ月を生き残る必要があるために、6ヶ月の時間がかかるならオーバーエンジニアリングだと言える。

4 key metricsに対する初見を聞きたい

これをKPIにするのは難しいと思っている。特にデプロイ頻度は事業によっては法律上認可が必要な場合もあったりするので、難しい。

コードを書く中で技術的負債にならないように気をつけていることはあるか？

Linterでルールを強制する。また、略語を使ったりしないように注意したり、関心と興味を分解することなどは特に意識している。

書籍に書いたような知識はどのように勉強したのか？

翌日納期みたいな案件を幾つもやっていたので、そういうところから割とアプリケーションに関する知識は学んだ。組織やファイナンスに関するものは、大企業〜スタートアップまでキャリアを積んできた。

会全体を通した感想

経営やファイナンスといった観点から技術的負債を語るというアプローチは(現場では当たり前にされていると想うのですが)事例としては聞くことが少な目な印象があったので面白かったです。

ただ、今ひとつ話のつながりという部分がわからなかったので、このあたりはもっと詳しく聞いてみたいと感じました。

*1:営業を増やさないとスケールしないリスクがある

*2:認知度がない状況ではそもそも売上が得られないリスクがある

*3:メモリーさんの前職