Forkwell Press | フォークウェルプレス

SHARE

目次

目次

SHARE

ソフトウェア設計とメンテナンス

「スタートアップのレガシーコード問題:経営視点での解決策」めもりー

この記事は 2023年5月23日発売 レガシーコードとどう付き合うか著者 めもりー 氏による connpass勉強会 を再編集し、記事化したものです。

【結論】レガシーコードと付き合うためには経営理解を!

エンジニア視点の結論としては、レガシーコード改善のためには、経営層と議論・解決していくことが必要です。経営層と効率的に、円満に、スムーズにコミュニケーションを取るためには、エンジニアリングを経営視点で理解することが重要です。

  • なぜレガシーコードを許容してまでプロダクトを作るのか
  • なぜレガシーコードを許容してまでエンジニアリングを推進するのか

レガシーコードとどう付き合うか』第1章・第4章をもとに、長年のソフトウェアエンジニアとしてのキャリアとCTOとしてのキャリアを持つ めもりー氏 が解説します。(注)本講演は、レガシーコードを「資金不足や人材不足によって生じたコード」、技術的負債を「技術的な課題全般」と定義します。

レガシーコードや技術的負債が生まれる理由

スタートアップにとって切っても切れない “資金調達” 。この過程では、品質をおざなりにしてでも開発プロセスの短縮を経営層から求められることがあります。求められた結果 “とりあえず開発されたコード” は、将来的に多くの課題を抱える可能性があります。なぜ経営層はそうまでしてプロダクトを世の中に出さなければいけないと考えるのでしょうか。(注)「スピードと品質はトレードオフの相関関係にない」という主張もあります。

詳しくはこちらで解説しています。ぜひご覧ください。

目次
  • スタートアップはガチでお金がない
  • 銀行や公庫からの融資、デットファイナンス
  • 紙切れに価値を、エクイティファイナンス
  • 売上から純利益を増やす方法
  • 投資ラウンドとは?
  • 余談:会社に金があるかを確認する方法
  • 「すぐに資金調達すればいいのでは?」→ 実はそうもいきません
  • なぜスタートアップ初期のソフトウェア設計は壊れがちなのか

エンジニアリングを推進する必要性

なぜレガシーコードを許容してまで、エンジニアリングを推進するのでしょうか。

1. 事業の目的を理解する

掲げているビジョンを達成したい、お金持ちになりたい、起業家との交友関係を作りたい、株主に還元したい……さまざまな思惑があるでしょう。十人十色です。

どのような目的であれ、これらを達成するためには会社の存続が絶対です。そのためには、継続的なトップラインの確保と利益が必要です。

2. ビジネスモデルとエンジニアリング

ビジネスモデルにも色々な種類があります。ITエンジニアが必要な事業ばかりではありません。

◾️労働集約型ビジネス

小さな飲食店やクリニック、建設現場など、人間の労働力に頼る割合の大きなビジネス。

直接 ITエンジニアを雇用せずとも、外注や SaaS で事足りることもあります。

◾️資本集約型ビジネス

製造業やエネルギー産業など、電気・ガス・水道などの資本投資を多く必要とするビジネス。

◾️知的集約型ビジネス

ITサービスや弁護士、コンサルティングなど、人間の知識に基づくビジネスです。

ITビジネスで近年主流の経営戦略には大きく2つあります。

  1. 営業活動を中心に成長を実現する経営戦略 SLG(セールスレッドグロース)
  2. プロダクトを中心に成長を実現する経営戦略 PLG(プロダクトレッドグロース)

PLGの場合、SLG と比べ特にエンジニアリングの重要性が高まります。

SLG、PLG について詳しくは下記の記事でも解説しています。

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

エンジニアリングを推進する理由は、大きく2つ考えられます。

  1. コスト削減……労働集約型ビジネスの場合、仕事の供給に対して線形的に人材が必要です。つまり人件費・固定費がかかります。利益幅を向上させるためには、エンジニアリングによる変動費と固定費の削減が必要です。
  2. ペイン解消……「市場に存在しない価値」など。例えば「子供に何のおもちゃを買えばいいのかわからない」といった課題を解決すること。

エンジニアによる業務効率化の “終着点”

理想は自身がその会社で不要になること、さらに言えば従業員が0人でも回る組織が、結果として最大のエンジニアリングといえます。現実的には無理な話なのでどこまで実現できるかは経営層含めた CTO や VPoE が考えていくことになります。

4. レガシーコードを改善する理由

生産性と人件費の悪化

レガシーコードの存在によって、ひとつの機能を改修するにも開発工数がかかるうえ、人件費も大きくなり、結果として生産性が悪化します。あらかじめモダンに作っても、それがオーバーエンジニアリング(※)であれば、開発工数がかかることによってエンジニアリングに投資したものを回収するにも時間が必要となります。ゆえに、オーバーエンジニアリングしたものを扱えるチームでないのであれば、それは技術的負債となってしまうことも容易に想像ができるでしょう。まとめると事業戦略・採用戦略、財務諸表上においても、そしてエンジニアたちのモチベーション担保のためにもレガシーコードの改善は必要だとわかります。もちろん技術的負債も同時に解消していく必要があります。※ いま時点では必要のないものまで想定した技術選定や、一般的なエンジニアが扱うには難しいような技術選定など

成長ストーリーとの乖離

生産性が悪化すれば、本来描いていた成長ストーリーとの間に乖離が起こります。

どのようにエンジニアリングを推進していくか

「事業貢献度の高そうなエンジニアが良い」「エンジニアなら誰でも良い」など多様な観点から、どういったエンジニアを採用するかは経営層が判断することになります。とはいえ、その観点に見合ったエンジニアを採用できるかは別の問題です。

エンジニアの評価はエンジニアにしかできない

(とくにスタートアップの場合)採用費は資金調達額によっては限定され、経営層がエンジニアとのコネクションも少なく、仮に採用できたとしても、エンジニアの成果や貢献を正しく評価するための制度が整備されていることやカルチャーが醸成されていることは稀です。

経営層がやりたいこと・エンジニアがやりたいこと

経営層がやりたいことは、(先程「事業の目的を理解する」で述べたように)会社を継続的に成長させていくことでビジョンを達成することです。一方でエンジニアがやりたいことは「事業貢献」であったり「クリエイティビティの高い仕事をしたい」など多種多様です。そのため、経営層が「自己満足的にコードを書くエンジニア」よりも「プロダクトに共感をしてくれるエンジニアを欲している」という理屈もよくわかります。しかし、スタートアップはエンジニアとのコネクションもほとんどない中、採用戦略として「猫の手も借りたいから、コードを書いてくれるエンジニア」を採用するという戦略を取ることもあれば「カルチャーマッチするエンジニア」を採用するというブレない戦略を取ることもあります。

いずれにしても(今日時点では)売り手市場であり、年間 1800 社ほど設立する有象無象のスタートアップの中から自社を選んでもらうこと自体が難しいです。そして技術職の労働人口は 130 万人前後であり、他業界と比べると非常に人口が少ないのです。

誰が “アプリケーションの品質” を評価するか

エンジニアの採用がうまく行き、エンジニアが納得行くカルチャーが醸成できたと仮定します。次に差し掛かる課題は「アプリケーションの品質の評価を誰がするのか」です。PoC や PMF を急ぐあまり「生まれてしまった技術的負債やレガシーコード」を誰が適切に管理するのでしょうか。それは他でもないエンジニアです。経営層に振り回されて対応をさせられたエンジニアが自らその代償を負うことになるのです。経営層がアプリケーションの品質に対しての代償を負うことはありません。

そしてエンジニア経験がない経営層はアプリケーションのコードを読んでも、その品質を適切に評価することはできません。もしそれができるのであれば、その経営層は「エンジニア」です。レガシーコードを改善するためには経営層に対して、アプリケーションの品質の現状と問題提起を行えなければならないのです。

エンジニアの技術力は数字で表せない

エンジニアの評価はエンジニアにしかできない点、経営層がやりたいこととエンジニアがやりたいこと、そしてアプリケーションの品質の評価から、これらを経営の言葉に翻訳して経営層に伝える人材が必要になることは言うまでもありません。特にエンジニア経験がない経営層であれば、ボードメンバーには CTO や VPoT,VPoE が必要となるでしょう。

Q:レガシーコード、改善 or 保守?

変化の少ないマーケットでは、保守に注力したとしても売上が見込める可能性は高いです。

しかし、変化の大きいマーケット、例えば翌日にサービスの性質が変わるようなスピード感のある事業モデルの場合は、保守を続けても多くの新機能の追加によってツギハギだらけになってしまいます。そうならないためにも保守と改善のバランスが非常に重要です。人が足りなければ採用するほかありません。

Q:経営層にレガシーコードを証明する方法

これがレガシーコードですってコードを見せてもわからないですもんね。例えば、こんな見せ方は、いかがでしょうか。

  • 開発パフォーマンスが低下しています(4keys のリードタイムやデプロイ頻度だったり、ベロシティなどから)
  • デプロイの頻度が下がっています(同上)
  • アプリケーションの品質が落ちています(4keys の変更障害率や、他には本質的ではないが、カバレッジが低くなっているなど)

ソフトウェアには(財務戦略によりますが)会計上、ソフトウェア資産という概念があります。これは減価償却の対象になるので「減価償却が近づいてるのに、これをずっと使い続けるってやばくないですか?」というアプローチもアリですよね。

経営層が求めるのは数字での評価です。「レガシーコードがあってヤバい!」とだけ伝えても経営層は理解してくれません。特にエンジニア出身のボードメンバーがいなければ尚更です。

改善する時間や予算を獲得するには、どうにかこうにか AsIs に対して、レガシーコードを改善するにあたっての pros/cons とそれによって数字がどのように変わるのか、ToBe がどうなるか説明するしかないのです。

Q:レガシーコード改善をチームへ意識付ける方法

受け手の状況によりますよね。

  1. 改善する必要がないと感じている → 解消のメリットを伝える
  2. 改善する時間がないと感じている → 時間を作るしかない
  3. 改善する方法がわからない → 書籍で学ぶ

レガシーコードとどう付き合うか』のほかにもミノ駆動さんの書籍など、良い書籍がたくさんあるので、ぜひ目を通してみてください。

— 『レガシーコードとどう付き合うか』は、諸悪の根源を暴く内容、『良いコード/悪いコードで学ぶ設計入門』諸悪の根源を断つ方法、といったところでしょうか。

そうですね。両方買っていただくのが良いかと!

Q:新規開発がレガシーコードになっていく理由

— いまから新規開発していくエンジニアの方からの質問ですね。

新規開発の話なので、基本的に今モダンであれば大丈夫かと。ただ、レガシーに書かない方法を知らない人がチームメンバーにいると、レガシーコードが生まれる背景にはなるだろうと。

— t_wadaさんの影響で「質とスピードはトレードオフではない」が啓蒙されるなか、いまだに「テストを書かずにスピードを上げよう」みたいな議論も見かけます。

遅延価値割引という概念があります。将来もらえる1000万円より今もらえる100万円を選ぶ人っているんですよ。テストを書けば将来的に恩恵を受けられるけど、今、目の前の報酬を選んでしまうんですよね。でも会社の場合だとそもそも存続していない場合も普通にあるわけで 1000 万がもらえないこともある。だから100万円を選ぶ経営者があとをたたないのです。

*遅延価値割引……報酬が得られるまでの待ち(遅延)時間によって報酬の主観的価値が低下することである。

Q:リファクタリングへの理解を得られません

— 「とにかく新しいものを!」が求められると

「新しいもので数字上がるんですか?」って私は聞いちゃいますけどね。

— 既存のもので数字が上がってるかによるかも

ああ、そうですね。それによってディスカッションが変わってきますね。

既存のもので売上が上がっているなら、更に売上を伸ばすための新しい手段ということで、じっくり練った方がいいだろうし、その逆であれば「そもそもPMFしてないよね」という話になりますね。

Q:フルリプレイス or リファクタリング

毎日のように考えるテーマですね。会社の状況によるのですが、本当にメンテナンス不可能な場合、もしくは潤沢な資金がある場合はフルリプレイスも選択肢のひとつ。過去の企業では、minify された JavaScript しか残っておらず、そもそもメンテナンス不可能だったのでフルリプレイスという選択をしました。

Q:コードの品質で気を付けていることは?

当たり前のことですが、基本に沿ってこのあたりを実施しています。

  • エンジニアによって書きぶりに差異が出ないよう linter を入れてルールを定める
  • 略語や曖昧な変数(str や res ,data など)を極力使わない
  • 説明変数なども使いつつ誰が見てもわかるコードにする
  • ドメインや関心ごとによってコードを適切に分離する

アーカイブ動画

ForlkwellPress ロゴ画像

フォークウェルプレス編集部

Follow

記事一覧へ

この記事はフォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

めもりー
めもりー
「レガシーコードとどう付き合うか」著者

複数のスタートアップを経て,GameWith や BASE といった上場企業でソフトウェアエンジニアとして従事。2020 年に株式会社トラーナに一人目のエンジニアとしてエンジニアリングマネジャー兼テックリードとして入社。2022 年 1 月に執行役員 CTO として就任。2023 年 5 月末に,執行役員 CTO を退任。同年 6 月より暫定無職。PHP 関連のカンファレンスやイベントなどで数多く登壇。拙著に「Swoole で学ぶ PHP 非同期処理」,「レガシーコードとどう付き合うか」,そのほか Software Design などに寄稿。