目次
■ソフトウェア設計とメンテナンス
2023.07.10 2024.03.05 約4分
| この記事は 2023年5月23日発売 『レガシーコードとどう付き合うか』著者 めもりー 氏による connpass勉強会 を再編集し、記事化したものです。 |
エンジニア視点の結論としては、レガシーコード改善のためには、経営層と議論・解決していくことが必要です。経営層と効率的に、円満に、スムーズにコミュニケーションを取るためには、エンジニアリングを経営視点で理解することが重要です。
|
『レガシーコードとどう付き合うか』第1章・第4章をもとに、長年のソフトウェアエンジニアとしてのキャリアとCTOとしてのキャリアを持つ めもりー氏 が解説します。（注）本講演は、レガシーコードを「資金不足や人材不足によって生じたコード」、技術的負債を「技術的な課題全般」と定義します。
スタートアップにとって切っても切れない “資金調達” 。この過程では、品質をおざなりにしてでも開発プロセスの短縮を経営層から求められることがあります。求められた結果 “とりあえず開発されたコード” は、将来的に多くの課題を抱える可能性があります。なぜ経営層はそうまでしてプロダクトを世の中に出さなければいけないと考えるのでしょうか。（注）「スピードと品質はトレードオフの相関関係にない」という主張もあります。
詳しくはこちらで解説しています。ぜひご覧ください。
|
なぜレガシーコードを許容してまで、エンジニアリングを推進するのでしょうか。
掲げているビジョンを達成したい、お金持ちになりたい、起業家との交友関係を作りたい、株主に還元したい……さまざまな思惑があるでしょう。十人十色です。
どのような目的であれ、これらを達成するためには会社の存続が絶対です。そのためには、継続的なトップラインの確保と利益が必要です。
ビジネスモデルにも色々な種類があります。ITエンジニアが必要な事業ばかりではありません。
◾️労働集約型ビジネス
| 小さな飲食店やクリニック、建設現場など、人間の労働力に頼る割合の大きなビジネス。
直接 ITエンジニアを雇用せずとも、外注や SaaS で事足りることもあります。 |
◾️資本集約型ビジネス
| 製造業やエネルギー産業など、電気・ガス・水道などの資本投資を多く必要とするビジネス。 |
◾️知的集約型ビジネス
| ITサービスや弁護士、コンサルティングなど、人間の知識に基づくビジネスです。
ITビジネスで近年主流の経営戦略には大きく2つあります。
PLGの場合、SLG と比べ特にエンジニアリングの重要性が高まります。 |
SLG、PLG について詳しくは下記の記事でも解説しています。
エンジニアリングを推進する理由は、大きく2つ考えられます。
|
理想は自身がその会社で不要になること、さらに言えば従業員が0人でも回る組織が、結果として最大のエンジニアリングといえます。現実的には無理な話なのでどこまで実現できるかは経営層含めた CTO や VPoE が考えていくことになります。
レガシーコードの存在によって、ひとつの機能を改修するにも開発工数がかかるうえ、人件費も大きくなり、結果として生産性が悪化します。あらかじめモダンに作っても、それがオーバーエンジニアリング（※）であれば、開発工数がかかることによってエンジニアリングに投資したものを回収するにも時間が必要となります。ゆえに、オーバーエンジニアリングしたものを扱えるチームでないのであれば、それは技術的負債となってしまうことも容易に想像ができるでしょう。まとめると事業戦略・採用戦略、財務諸表上においても、そしてエンジニアたちのモチベーション担保のためにもレガシーコードの改善は必要だとわかります。もちろん技術的負債も同時に解消していく必要があります。※ いま時点では必要のないものまで想定した技術選定や、一般的なエンジニアが扱うには難しいような技術選定など
生産性が悪化すれば、本来描いていた成長ストーリーとの間に乖離が起こります。
「事業貢献度の高そうなエンジニアが良い」「エンジニアなら誰でも良い」など多様な観点から、どういったエンジニアを採用するかは経営層が判断することになります。とはいえ、その観点に見合ったエンジニアを採用できるかは別の問題です。
（とくにスタートアップの場合）採用費は資金調達額によっては限定され、経営層がエンジニアとのコネクションも少なく、仮に採用できたとしても、エンジニアの成果や貢献を正しく評価するための制度が整備されていることやカルチャーが醸成されていることは稀です。
経営層がやりたいことは、（先程「事業の目的を理解する」で述べたように）会社を継続的に成長させていくことでビジョンを達成することです。一方でエンジニアがやりたいことは「事業貢献」であったり「クリエイティビティの高い仕事をしたい」など多種多様です。そのため、経営層が「自己満足的にコードを書くエンジニア」よりも「プロダクトに共感をしてくれるエンジニアを欲している」という理屈もよくわかります。しかし、スタートアップはエンジニアとのコネクションもほとんどない中、採用戦略として「猫の手も借りたいから、コードを書いてくれるエンジニア」を採用するという戦略を取ることもあれば「カルチャーマッチするエンジニア」を採用するというブレない戦略を取ることもあります。
いずれにしても（今日時点では）売り手市場であり、年間 1800 社ほど設立する有象無象のスタートアップの中から自社を選んでもらうこと自体が難しいです。そして技術職の労働人口は 130 万人前後であり、他業界と比べると非常に人口が少ないのです。
エンジニアの採用がうまく行き、エンジニアが納得行くカルチャーが醸成できたと仮定します。次に差し掛かる課題は「アプリケーションの品質の評価を誰がするのか」です。PoC や PMF を急ぐあまり「生まれてしまった技術的負債やレガシーコード」を誰が適切に管理するのでしょうか。それは他でもないエンジニアです。経営層に振り回されて対応をさせられたエンジニアが自らその代償を負うことになるのです。経営層がアプリケーションの品質に対しての代償を負うことはありません。
そしてエンジニア経験がない経営層はアプリケーションのコードを読んでも、その品質を適切に評価することはできません。もしそれができるのであれば、その経営層は「エンジニア」です。レガシーコードを改善するためには経営層に対して、アプリケーションの品質の現状と問題提起を行えなければならないのです。
エンジニアの評価はエンジニアにしかできない点、経営層がやりたいこととエンジニアがやりたいこと、そしてアプリケーションの品質の評価から、これらを経営の言葉に翻訳して経営層に伝える人材が必要になることは言うまでもありません。特にエンジニア経験がない経営層であれば、ボードメンバーには CTO や VPoT，VPoE が必要となるでしょう。
変化の少ないマーケットでは、保守に注力したとしても売上が見込める可能性は高いです。
しかし、変化の大きいマーケット、例えば翌日にサービスの性質が変わるようなスピード感のある事業モデルの場合は、保守を続けても多くの新機能の追加によってツギハギだらけになってしまいます。そうならないためにも保守と改善のバランスが非常に重要です。人が足りなければ採用するほかありません。
これがレガシーコードですってコードを見せてもわからないですもんね。例えば、こんな見せ方は、いかがでしょうか。
|
ソフトウェアには（財務戦略によりますが）会計上、ソフトウェア資産という概念があります。これは減価償却の対象になるので「減価償却が近づいてるのに、これをずっと使い続けるってやばくないですか？」というアプローチもアリですよね。
経営層が求めるのは数字での評価です。「レガシーコードがあってヤバい！」とだけ伝えても経営層は理解してくれません。特にエンジニア出身のボードメンバーがいなければ尚更です。
改善する時間や予算を獲得するには、どうにかこうにか AsIs に対して、レガシーコードを改善するにあたっての pros/cons とそれによって数字がどのように変わるのか、ToBe がどうなるか説明するしかないのです。
受け手の状況によりますよね。
|
『レガシーコードとどう付き合うか』のほかにもミノ駆動さんの書籍など、良い書籍がたくさんあるので、ぜひ目を通してみてください。
— 『レガシーコードとどう付き合うか』は、諸悪の根源を暴く内容、『良いコード／悪いコードで学ぶ設計入門』諸悪の根源を断つ方法、といったところでしょうか。
そうですね。両方買っていただくのが良いかと！
— いまから新規開発していくエンジニアの方からの質問ですね。
新規開発の話なので、基本的に今モダンであれば大丈夫かと。ただ、レガシーに書かない方法を知らない人がチームメンバーにいると、レガシーコードが生まれる背景にはなるだろうと。
— t_wadaさんの影響で「質とスピードはトレードオフではない」が啓蒙されるなか、いまだに「テストを書かずにスピードを上げよう」みたいな議論も見かけます。
遅延価値割引という概念があります。将来もらえる1000万円より今もらえる100万円を選ぶ人っているんですよ。テストを書けば将来的に恩恵を受けられるけど、今、目の前の報酬を選んでしまうんですよね。でも会社の場合だとそもそも存続していない場合も普通にあるわけで 1000 万がもらえないこともある。だから100万円を選ぶ経営者があとをたたないのです。
*遅延価値割引……報酬が得られるまでの待ち(遅延)時間によって報酬の主観的価値が低下することである。
— 「とにかく新しいものを！」が求められると
「新しいもので数字上がるんですか？」って私は聞いちゃいますけどね。
— 既存のもので数字が上がってるかによるかも
ああ、そうですね。それによってディスカッションが変わってきますね。
既存のもので売上が上がっているなら、更に売上を伸ばすための新しい手段ということで、じっくり練った方がいいだろうし、その逆であれば「そもそもPMFしてないよね」という話になりますね。
毎日のように考えるテーマですね。会社の状況によるのですが、本当にメンテナンス不可能な場合、もしくは潤沢な資金がある場合はフルリプレイスも選択肢のひとつ。過去の企業では、minify された JavaScript しか残っておらず、そもそもメンテナンス不可能だったのでフルリプレイスという選択をしました。
当たり前のことですが、基本に沿ってこのあたりを実施しています。
|
複数のスタートアップを経て，GameWith や BASE といった上場企業でソフトウェアエンジニアとして従事。2020 年に株式会社トラーナに一人目のエンジニアとしてエンジニアリングマネジャー兼テックリードとして入社。2022 年 1 月に執行役員 CTO として就任。2023 年 5 月末に，執行役員 CTO を退任。同年 6 月より暫定無職。PHP 関連のカンファレンスやイベントなどで数多く登壇。拙著に「Swoole で学ぶ PHP 非同期処理」，「レガシーコードとどう付き合うか」，そのほか Software Design などに寄稿。
