はじめに
この記事は、レガシーコードによって引き起こされる影響について考察しています。
実体験に基づいて書かれているものの、実際のデータを参考に書いている訳ではありませんので、この辺りを差し引いて読んでいただければと思います。
レガシーコードとは
レガシーコードとは、単にテストのないコードである
レガシーコード改善ガイド より引用
これは良く引用される文言で、実際にレガシーコードについて説明するときにも良く使われる定義です。
ただし、テストコードがあっても技術的負債になるケースは存在します。
そのため、この記事では「メンテナンスに時間が掛かるコードのこと」という定義を使います。
レガシーコードの問題点
「メンテナンスに時間が掛かる」という言葉を、もう少し具体的にしていきます。
- 少しコードを変更したら他の部分が壊れる
- コードの変更をすると大量のテストを行わないといけないため、実質的にコードを変更することができない
- なぜそのコードが存在するのかわからず、変更できない
- 可読性が極端に低い
- 依存関係が無駄に複雑で、循環依存も発生している
このようなものが挙げられます。
つまり、「レガシーコードは無ければ無いほうが良いもの」と言えます。
どのような状況でレガシーコードは発生するのか
いくつか、例を挙げてみます。
- テストコードを書かない
- 実装スキルが著しく低い
- 時間の経過により、実際のモデルと乖離が発生し、意図が伝わらない
- ビジネスを最優先するために、品質を捨てる
このようなものが考えられます。
もう少し詳細に見ていきましょう。
教育の問題
- テストコードを書かない
- 実装スキルが著しく低い
上記のふたつは、教育の問題と言えます。
スキルや知識は勉強していけば伸びるものなのですが、学習コストが掛かります。
この学習コストを払わないことを選択していると、レガシーコードを作り続けることになります。
時間の問題
- 時間の経過により、実際のモデルと乖離が発生し、意図が伝わらない
これは、時間が経つことによって、知識の継承がうまくいっていないと発生します。
つまり、その瞬間はレガシーコードではないものの、人の入れ替わり等の理由によってレガシーコードになってしまう、というパターンです。
ビジネスの問題
- ビジネスを最優先するために、品質を捨てる
ビジネス上の都合で、品質を捨ててスピードを重視する、という選択をすることがあります。
これは、ソフトウェア開発の世界では完全に否定されているものですが、このような選択をする企業も存在します。
市場からの要求が強ければ強いほど、このような選択をしてしまうことがあります。
詳細については、下記の記事を参照ください。
レガシーコードを許容する正当性はほぼない
ここまで見てきたように、レガシーコードは忌むべきもので、存在することに正当性はほぼありません。
レガシーコードを含む、技術的負債の返済の必要性をほとんどの人が理解しており、あらゆる企業で、技術的負債の解消に向けて努力している、というのが現状です。
レガシーコードの改善を阻む壁
「テストを書いている余裕はない」
「リファクタリングするよりも、新機能を開発するほうが優先」
「リファクタリングは後でやればいい」
「リファクタリングしても儲からない」
これらのセリフは、様々な書籍で紹介されていたり、実際に聞いたこともあります。
ですが、前述した通り、これらの主張に正当性はありません。
ではなぜ、このような主張がなくならないのでしょうか。
仮説①
🖊️教育が行き届いていないため。
誤った主張をするのは知識が追いついていないからであり、知識があれば解決する、というスタンスです。
この仮説が正しかった場合、プログラミングが義務教育で教えられるようになったため、20~30年程待っていれば勝手に解決する問題、と言えます。
仮説②
🖊️外部の攻撃から身を守るため
誤った主張をするのは一種の防衛本能であり、仕方がない、というスタンスです。
現状維持バイアスというものがありますが、これは「新たな選択のリスクを軽減できるというメリットがある」と言われているようです。
確かに、部外者から言われたことをすべて信用してしまったら、社会を生き残れそうにありません。
この考えを元にすると、「現状維持バイアスが欠落している人は自然淘汰されてきた」と言えるかもしれません。
村社会
レガシーコードを放置している企業は、村社会に近いかもしれません。
村社会（むらしゃかい）とは、集落に基づいて形成され、有力者を頂点とする序列構造を有し、余所者を受け入れようとしない古くからの秩序を保つ排他的な社会を指す。
ウィキペディア 村社会 より引用
下記のような特徴があったように感じます。
- 独自のやり方があり、それに従わないのであれば排除する
- 新しくやってきた人はスキルが低いと断定する
- 今のやり方を続けたいので、フィードバックは受けたくない
これらも、「外部の攻撃から身を守るため」と言われれば納得できます。
仮説③
🖊️労働力を搾取されすぎないため
労働者の搾取は産業革命時代から指摘されており、それに抗う手段としてレガシーコードを作っている、というスタンスです。
100年後には週15時間働けば十分な時代が到来する
この言葉を聞いたことはないでしょうか。これは、ケインズが1930年に予想した内容です。
つまり、100年後とは、2030年のことです。
なぜこの予想が外れた(と言って差し支えないでしょう)のかと言うと、「生産性が向上しても、労働時間が短くなる訳ではない」からです。
これはマルクスの資本論でも指摘されている内容で、これらは、現代の資本主義にもほぼそのまま当てはまります。
つまり、労働者目線では、生産性をあげるメリットがありません。
そのために、レガシーコードを放置、または新しく作っているのではないか、という考え方です。
レガシーコードの功罪
今まで、レガシーコードの「罪」の部分ばかり論じられていたのではないでしょうか。
ここでは、「功」について書いていこうと思います。
レガシーコードがあることによって、需要が生まれている
エンジニアの人手不足が謳われてから何年も経っていますが、これが改善される見込みはありません。
IPA(独立行政法人 情報処理推進機構)の調査によると、「大幅に不足している」と回答した企業が62.1%でした。
参考：https://www.ipa.go.jp/digital/chousa/discussion-paper/dx-talent-shortage.html
また、経済産業省は「2025年の崖」と称し、DXの重要性を訴えています。
参考：https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
上記のように、レガシーコードは社会問題となっています。
では、これによって助かっている人は誰でしょうか。
これは、実際に働いているエンジニアです。
これほどまでに大きな問題があるのであれば、職を失うことはほぼ考えなくてよくなります。
エンジニアバブルがおさまらない理由もここにあるかもしれません。
レガシーコードがあることによって、ストライキをしなくて済む
ストライキは現代の日本ではほとんど行われていません。
ですが、働きながらストライキをしていると考えることはできないでしょうか。
レガシーコードはその最たる例だと言えそうです。
参考：https://www.nippon.com/ja/currents/d10003/
レガシーコードがあることによって、スキルが低くても働ける
TDD、DDD、BDD、クリーンアーキテクチャー、ペアプロ、モブプロ、ふりかえり、プランニング、CI、CD、マイクロサービスアーキテクチャー、Lean、DevOps、アジャイルソフトウェア開発、等。
ソフトウェア開発をするにあたって必要な知識・スキルについて軽く挙げただけでもこれだけの量があります。
ソフトウェア開発を行っている人の何％がこれらの知識を持って働いているでしょうか？
数えた訳ではありませんが、5%未満、というのが体感です。
これらの知識・スキルを持っており、実践できている人はごくわずかで、ほとんどの人はこれに当てはまりません。
ですが、需要(仕事)はいくらでも存在します。
つまり、エンジニアを採用したい企業は、市場の原理に負け、スキルが低い人をそこそこ高い給料で雇わなければなりません。
最近、「賃上げ」というワードが注目されていますが、ソフトウェア開発業界では、既にこの仕組みが回っていることになります。
おわりに
レガシーコードについて見てきました。
レガシーコードは撲滅する、というのが主流の考え方ではありますが、エンジニアという職業を考えたとき、レガシーコードに助けられているのではないか？という主張をしてみました。
レガシーコードに頭を抱えて、憤っている人も、この記事を読んで心を鎮めてもらえればと思います。