【ITニュース解説】Why I Deleted 10,000 Lines of Code and My Manager Promoted Me

あるシステムエンジニアが、自身が3ヶ月かけて開発した推薦エンジンが稼働停止した経験を通じて、ソフトウェア開発における「複雑さ」と「シンプルさ」の価値について深く考察している。その推薦エンジンは、機械学習の高度な技術を駆使し、1万行のPythonコードで構成された複雑なシステムだったが、ダウンした際に誰もその複雑な内部を理解できず、修復に手間取った。この経験から、筆者は「コードが賢すぎた」という気付きを得る。そして6週間後、彼はその1万行のコードのほとんど、具体的には847行にまで削減し、その結果、上司から「シニアレベルの思考」と評価され、昇進することになった。

筆者は、若手開発者が陥りがちな「複雑性の罠」について説明している。多くの若手は、書いたコードの行数や、どれだけ多くの設計パターンを盛り込んだかで成功を測りがちだ。これは、複雑さや難解さを洗練されたものだと誤解している状態である。筆者の推薦エンジンもまさにその典型で、リアルタイムのカスタム特徴ストア、マルチアームドバンディットアルゴリズム、動的なモデル再学習、7つのマイクロサービスからなるアーキテクチャ、独自のキャッシュレイヤーなど、個々のコンポーネントは技術的に優れていた。しかし、それらが集合することで、特定の専門家でなければ理解できない、非常に複雑な「ピタゴラ装置」のようなシステムになっていた。トラブル発生時、シニアエンジニアの最初の質問は「どうやって直すか？」ではなく、「なぜこれが存在するのか？」だったという点が、この問題の核心を突いている。

シニアエンジニアは、「1万行のシステムを見せたら、そのうち9000行は不要なものだと示すことができる」と述べた。この言葉は、コードの削除がいかに重要であるかを強調している。コードの各行は、バグの温床となり、理解のコストとなり、将来の変更に認知的な負担をかける「負債」であると筆者は言う。優れた開発者は、何を作るかではなく、何を作らないかによって定義されるというのだ。コードの削除は、自身の成果を捨てる勇気、本当に重要なものを見極める知恵、そして複雑にしすぎたことを認める謙虚さが必要なスキルである。筆者はトラブル後、「これを除去したらどうなるか？」という問いをあらゆるコンポーネントに投げかけ、不要な機能を次々と削除していった。例えば、リアルタイム更新のカスタム特徴ストアは、結局バッチ処理で十分だったため削除。複雑なマルチアームドバンディットアルゴリズムは、単純な人気度に基づくランダム選択で代替可能だったため削除。マイクロサービスアーキテクチャも、ドメイン境界に沿った2つのサービスに集約。カスタムキャッシュも、Redisの標準機能で十分だったため削除された。

削除によって生まれた新しいシステムは、筆者自身が「恥ずかしいほどシンプル」と感じるものだった。複雑な機械学習パイプラインの代わりに、2009年からの実績ある協調フィルタリングと行列因子分解を用いた。リアルタイム処理の代わりに、夜間に推薦を事前計算し、シンプルなキャッシュから提供した。マイクロサービスの代わりに、チームのどの開発者でも理解・デバッグ可能なモノリスを構築した。この新しいシステムは、同じデータ量を処理し、より良い推薦を生成し（最適化が容易になったため）、リソースを60%削減した。さらに重要なのは、システムが停止しても、どの開発者でも数分で理解し修正できるようになったことである。上司は、コードを削除したからこそ彼を昇進させたのであり、その判断を「チームの成功のために最適化し、個人のエゴのためではなかった」と評価した。

ソフトウェア開発には「知性のパラドックス」が存在すると筆者は指摘する。最も賢そうに見えるコードは、往々にして最も未熟な開発者によって書かれる。若手開発者は自分の能力を証明するために複雑なコードを書くが、シニア開発者は自分が賢すぎないことを証明するためにコードを書く。キャリアの初期段階では、複雑さが能力のように感じられ、あらゆるパターンや言語機能を使い、精巧なアーキテクチャを構築する。しかし、システムは単独で存在するわけではない。チームや組織の中で、他の人々が理解し、変更し、拡張する必要がある。最も「知的な」コードとは、最も巧妙なものではなく、最も「思慮深い」コードなのである。複雑なシステムは、複雑なデバッグ、複雑なデプロイ、そして安全に変更するための複雑な知識を必要とし、オリジナルの開発者しか効果的に変更できないというボトルネックを生み出す。対照的に、シンプルなシステムは、どのチームメンバーでも理解・変更できるため、自然と所有権が分散され、拡張可能なエンジニアリング文化を築くことができる。

ビジネス的な観点から見ても、エンジニアリングの決定は複利効果を持つ。あらゆる抽象化レイヤーは認知負荷を増やし、マイクロサービスは運用を複雑にし、カスタムソリューションは開発者が退職すると失われる「部族の知識」を生み出す。筆者の元のシステムは、3つの監視ダッシュボード、カスタムデプロイスクリプト、小説よりも長いドキュメントを必要とした。新しいシステムは標準ツール、標準パターンを使用し、既存のダッシュボードで監視可能だった。ビジネスの観点からは、複雑なシステムはシニアエンジニアのリソースを保守に縛り付け、特殊な知識を必要としたのに対し、シンプルなシステムはジュニア開発者でも保守でき、基本的なウェブサービスの知識を持つ誰でも拡張可能だったため、選択は明らかだった。

現代のAIツールも、複雑さを減らすために活用できると筆者は述べる。AIを使ってより洗練されたシステムを構築するのではなく、よりシンプルなシステムを慎重に構築するために利用する。例えば、新しいシステムを設計する際、AIに「機能する可能性のある最もシンプルな実装」を特定するのを手伝ってもらい、そこから逆算して作業を進める。AIは最小限の複雑性を見つけるための「制約生成器」となる。コードレビューでは、AIが過剰な設計を特定し、よりシンプルな代替案を提案できる。重要なのは、「どうすればもっと洗練できるか？」ではなく、「どうすればもっと分かりやすくできるか？」と問いかけることである。AIコード解説ツールは、コードの明確さをテストするのに役立ち、AIに簡単に説明できないコードは、人間にとっても複雑すぎる可能性が高い。

筆者は「引き算の考え方」を提唱する。これは、コードを削除するだけでなく、開発全体にわたってシンプルさを追求する思考のことだ。まず「機能する可能性のある最もシンプルなもの」から始める。最もエレガントである必要も、スケーラブルである必要も、将来性がある必要もない。ただシンプルであること。複雑さは後から追加できるが、一度追加したものを削除するのは非常に困難である。また、パフォーマンスよりも「理解しやすさ」を最適化する。具体的なパフォーマンス要件が満たされていない場合を除き、6ヶ月後にそのシステムを理解する必要があるかもしれない未来の開発者のために、コードの明確さを最優先する。さらに、「退屈な技術」を選ぶことも重要だ。最も成功したシステムは、退屈でよく理解されているツールを使用している。これは、開発者の想像力がないからではなく、イノベーションはビジネスロジックレベルで行われるべきであり、インフラレベルではないという理解に基づいている。そして、作らなかったものを成功の尺度とすること。実装しないと決めた機能、作成しないと決めた抽象化、追求しないと決めた最適化といった決定は、書かれたコードよりも価値があることが多い。

この「引き算の考え方」を身につける上で最も難しいのは、技術的な側面ではなく、心理的な側面であるという。開発者は、自分の技術的な能力を誇示し、複雑さによって自分の価値を証明しようとする本能を乗り越えなければならない。筆者はかつて、シンプルなコードは自分を未熟に見せるのではないか、問題が簡単すぎて自分の給料に見合わないのではないかと心配していた。しかし実際は逆で、複雑な問題をシンプルに解決することこそが、シニアレベルの思考の証なのだ。誰もが何かを複雑にすることはできるが、本当に理解していなければ何かをシンプルにすることはできない。筆者は、自分の仕事は印象的なコードを書くことではなく、最小限のリスクと複雑さでビジネス上の問題を解決することだと学んだ。時には、複雑なイベントソーシングよりも退屈なCRUD操作を選ぶことや、マイクロサービスよりもモノリスを選ぶこと、そして数ヶ月分の作業を削除してやり直すことも、その解決策の一部となる。

シンプルなシステムは、コードだけでなく、チーム文化全体に良い影響を与える「ネットワーク効果」を持つ。システムが理解しやすいと知識が自然に広がり、変更のリスクが低いと実験が促進され、デバッグが簡単だと自信が生まれる。複雑なシステムは知識のサイロ化と恐怖に基づく開発を生み出し、チームメンバーはコードベースの一部に触れることを恐れるようになる。プロダクトの要件は、「ユーザーにとって最善なもの」ではなく、「技術的に実現可能なもの」というフィルターを通して検討され、変更コストが高いためイノベーションが停滞する。しかし、シンプルなシステムは真逆の動態を生み出す。迅速な反復を可能にし、リファクタリングへの恐れを減らし、チーム全体に所有権を分散させる。優れたエンジニアリングプラクティスを容易にし、不適切なプラクティスが誤って実装されるのを難しくする。

長期的な視点で見ると、シンプルな推薦システムは5年経った今でも本番環境で稼働している。何十人もの開発者によって拡張、最適化、変更され、新しいチームメンバーも参加後数日で理解し貢献できる。もし元の複雑なシステムが残っていたら、絶え間ない保守、専門知識、そして要件の変化やメンバーの退職に伴う完全な書き直しが必要だっただろう。エンジニアリングの真の成熟度は、コードが次のデプロイを乗り越えるかではなく、次のチーム、次の要件、次のアーキテクチャの変更を乗り越えられるかどうかで測られる。最高のコードとは、現在の実装が印象的であることではなく、将来の変更を容易にするコードである。時には数ヶ月の作業を削除することも、シンプルすぎると感じる解決策を選ぶことも、パフォーマンスよりも保守性、巧妙さよりも明確さ、華やかさよりも地味さを優先することも必要となる。しかし、長期的にはシンプルなシステムが勝利する。それらはデバッグが容易で、拡張しやすく、理解しやすく、そして時が来たときに置き換えやすいからだ。筆者が削除した1万行のコードは無駄な努力ではなかった。それは高価な教育であり、ソフトウェアエンジニアリングの最高の形は、複雑だが動作するシステムを構築することではなく、シンプルで長く機能し、他の人々がその上に構築できるシステムを構築することだと教えてくれた。