2025/12/05 22:07
Most technical problems are people problems
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
テクニカルデットは単なるコードの散らかりではなく、コミュニケーションの崩壊であり、保守作業を重複作業の無限ループに閉じ込める可能性があります。著者が所属する会社では、数百万行にわたるレガシーコードにユニットテストがなく、古いフレームワークが使われていました。Windows 専用モジュールをクロスコンパイルせずに Linux にコピーしたため、機能ごとやバグ修正ごとに別々のメンテナンスが必要になる二つの分岐コードベースが生まれました。
リファクタリングの試みは「ほぼ同じ結果」だったとして却下され、プロジェクトは停滞し、チームメンバー間の信頼も失われました。根本原因は人に関係するものです：要件が不明確であること、不合理な締め切り、古い技術へのこだわり、反応的な中止、エゴ、そして開発者の変化への抵抗—コードはしばしば個性を映します（「Andrew Harmel‑Law」の洞察）。
デットの整理は救急トリアージに例えられます。すべてを修正する前に出血を止めなければならないのです。これにはステークホルダーとの明確なコミュニケーションと、非技術的リーダー向けの定量化された技術価値が必要です。人間側を無視すると、企業は信頼喪失、作業重複、納品遅延というリスクに直面します—これらは業界全体で横断的な協力によって緩和できます。
著者はまた、「エンジニアのエンジニア」（深い技術志向）と「ヘッドアップコーダー」（深さとリスク認識、チーム指揮をバランスする人）の対比を示し、シニアエンジニアは横断的協力を学ぶ必要があることを強調しています。CS 教育では個性・エゴ・盲点が見落とされる傾向があります。
本文
ほとんどの技術的課題は実際には人間関係の問題です
私はかつて、数百万行に及ぶコードベースでテクニカルデット（技術負債）が膨大な会社に勤めていました。単体テストがなく、10年以上古いフレームワークを使っている状態です。あるプロジェクトでは、Windows 専用のモジュールを Linux で動かす必要がありました。クロスコンパイルを行う代わりに、別チームが数十万行のコードをコピー＆ペーストし、Windows 固有のコンポーネントを Linux 用に差し替えたのです。
非技術者にはこれが大きな問題です。二つのバージョンのコードが同時に存在するため、すべての機能とバグ修正を別々のコードベースで行わねばならず、時間とともに分岐していきます。この話を聞いた私は、若くて未熟な自分として状況改善に乗り出しました。テクニカルデットプロジェクトは管理職への説得が難しく、すべてが順調に進んでもコードは以前とほぼ同じ動きをします。このプロジェクトも例外ではなく、見た目にも良くありませんでした。私は多くのエンジニアが行うように「政治を無視し」、頭を深く入れて実行しました。しかしプロジェクトは長引き、管理職からの信頼を失いました。
結局、私は人間関係の問題を技術的解決策で解こうとしていたことに気づきました。この会社のほとんどの開発者は、今日も昨日も五年前も同じやり方で作業しており、Andrew Harmel‑Law が指摘するように、コードは書いた人の性格を反映します。変化を強く嫌う性格の人ほど、将来の変更を想定した設計をしません。
ほとんどの技術的課題は本質的には人間関係の問題です
技術負債が存在する理由を考えてみてください。要件が作業開始前に十分に明確化されなかった、営業担当者が顧客に非現実的な締め切りを提示した、開発者が快適さから古いテクノロジーを選択した、経営陣が反応的すぎて途中でプロジェクトを中止した、誰かのエゴが改善策を見逃す原因になった、といったケースです。
このプロジェクトの根本問題は、リファクタリングが必要だと認めることが、会社のソフトウェア構築手法が壊れていること、そして個々のスキルセットが大幅に時代遅れであることをも意味するという点でした。私の小さなチームは数多くあるモジュールのうち一つを修正しようとしましたが、他の開発者たちは何十年も続けてきたやり方を変えませんでした。「新しいことを学びたくない」とオープンに言われました。結局、テクニカルデットは他人が作る速度より速く掃除できるものではありません。救急室でのトリアージのように、まず出血を止めてから壊れた部分を修復する必要があります。
理想的な世界
このプロジェクトは私に、エンジニアが「政治を離れて作業だけに集中し、締め切りや顧客の存在を無視できる」理想の世界を信じていたという幻想を打ち砕きました。実際にはほとんどのプロジェクトは非技術的なステークホルダーが関わっており、「ただ私たちに任せてください」と言うだけでは不十分です。チームが多くの仕事をこなしているという認識自体が、実際に多くの作業を完了する以上に重要であると気づきました。
非技術者は必要な労力やテクニカルデットのクリーニングの重要性を直感的に理解できません。エンジニアリング側が初期見積もりからプロジェクト更新まで、これらを効果的に伝える必要があります。リーダーシップが技術背景を持っていない場合は、テクニカルデット作業の価値をビジネス価値として定量化し示すことが求められます。
注意喚起
これらはより上位のポジションへ進むために必要なレッスンかもしれません。私見では、シニアエンジニアを超えるレベルになると、技術的トラックであろうとマネージメントトラックであろうと、クロスファンクショナルに協働できることが必須です。大学はコンピュータサイエンスを教えますが、人間関係やエゴ、自己の盲点をナビゲートする方法は教えてくれません。
私は素晴らしいエンジニアたちと共に働いてきました—自分よりも優秀で、どんなテクノロジーでも深い知識を持つ人々です。若い頃は「エンジニアのエンジニア」になりたいと思っていましたが、今ではそれが自分の性格に合わないと悟りました。私は ADD が強くて完全に頭を入れて作業することが難しいのです。
彼らの多大な技術的能力にもかかわらず、多くは対人関係を避ける傾向があります。個々として非常に生産的であっても、単一のプロセッサコアのように「速さ」に限界があるため、大きなイニシアチブでは失敗することがあります。そこで重要なのは、「頭を上げるコーダー」—技術的には深くて、同時にリスク（技術的・非技術的）を先読みし、チームを導ける人です。