なぜベテラン開発者は自身の専門能力を説明できないのか

なぜベテラン開発者は自分の専門性を説明できないのか

著者：Tuhin Nair**

原文：Why senior developers fail to communicate their expertise

次の言葉に対して、あなたはどう感じるでしょうか？

「AI エージェント (AI agents) はソフトウェア開発の未来です。もはや業務を遅らせるだけの開発者は必要ありません。」

あなたがベテラン開発者で、この発言に同意するのであれば、あなたの専門性について疑問を抱かざるを得ません（理由は後ほど説明しますが、単なる挑発ではありません）。

しかし、もしあなたがベテラン開発者ではなく、それでもこの発言に同意するならば、おそらくあなたは正しいでしょう。

え？一体どういうことでしょうか？

コピーライティング (Copywriting) の本質とは、情報を適切な対象者に正確に届けることです。

つまり、私というコピーライターから見れば、ここで起きていることはこうです：同じ一文でも、2 種類の異なる聴衆にとっては全く異なる意味として聞こえるのです。

あなたがベテラン開発者で、すでに驚くべき AI エージェントや大規模言語モデル、そして様々な派手な AI スキルを体験済みでありながら、それでも直感的に「皆がプログラマーの失業を叫んでいるが、どうも違和感がある」と感じているなら、この記事ではその言葉にできない直感を、明確な文章として表現してみせます（これが優れたコピーライターのすべき仕事です）。

しかし待ってください！現在、多くの経験豊富な著名開発者たちが「プログラマーは死んだ」と宣言しています。

これはどうしたことでしょうか？一体誰の直感が正しいのでしょうか？この対立を生み出している要因は何なのでしょうか？

私がチームに参加する際、通常 2 種類のベテラン開発者に遭遇します。

1 番目のタイプは次のように言います：

「新しいツールを見つけたんだが、すごくクールだぜ……」

「あそこの会社（我々の事業とは全く関係のない企業）就是这样やってるから、だから……」

「HackerNews のあの投稿を見てくれ、そこではこれがベストプラクティスだと書いてあるし、僕たちもそうすべきかもしれない……」

正直なところ、私はこうしたタイプのベテラン開発者があまり好きではありません。彼らは往々にして自己防衛本能が強く、業界で長く活動しており、人望もあるかもしれません。しかし、私たちは同じ周波数には乗れていません。

続いて 2 番目のタイプ：

「本当にその機能が必要なのか？」

「もしこれをやらなかったら、何が起きるのか？」

「まずは妥協して乗り切れないか？もっと重要になった時点で改めて取り組めばいいのではないか？」

ああ、これが私の理想のベテラン開発者です。彼らは回避者であり、簡素化の達人であり、廃棄物利用のエキスパートです。あらゆる手段を講じてコードを書くことを避けようとします。

なぜでしょうか？彼らは専門的なソフトウェア開発キャリアにおいて、生涯にわたって恐ろしい怪物「複雑性 (Complexity)**」を狩り続けてきたからです。

様々な特殊ケース、無数の if 条件分岐、新規のデータベーステーブル、新しいコンポーネント。これらすべてが頭痛の種です（システム全体の保守性と理解可能性を著しく高めるため）。ベテラン開発者はこれらの要素を極力減らしたがり、本当にこのコードを書く必要があるのかどうかを何度も確認するために時間を費やします。

システムに何かを追加することは、すなわち複雑性のリスクを増やすことを意味するからです。

はい、はい、そう言うと少し言い過ぎかもしれません。確かに、未解決の難題を克服し、創造的な新アーキテクチャを提案できるベテラン開発者も大勢います。

しかし究極のところ、安定して稼働しているシステムに責任を負うのであれば、あなたは複雑性を恐れるようになります。

では、なぜそうなるのでしょうか？複雑性にはいったいどのような悪影響があるのでしょうか？また、なぜ他の人たちはこの恐怖を理解できないのでしょうか？

私たちは 2 つの「循環圏」を用いて、企業の運営様式を簡略化して説明しようと思います。

これが最初の循環圈です。マーケティング担当者、営業担当、プロダクトマネージャー、そして CEO はすべてこの圏の中にいます：

最初のループ：ビジネスチームは、迅速な試行、市場からのフィードバック、そして学習を通じて、不確実性を継続的に低減させています。

このループの核心的な目標は、試行と学習です。企業は製品を市場に投入し、フィードバックを得て、自分たちが作り出したものに本当に価値があるかどうかを確認したいと考えています。

このループの中にいる人々が直面する怪物とは何かというと、不確実性 (Uncertainty) です。

不確実性は残酷なものです。なぜなら、どんな戦略も 100% の成功率を保証するものはないからです。この不確実性が時間と絡み合ってくると（例えば、マーケティングや営業の給与、創業者への給料支払い、あるいはプロダクトマネージャーが急務とするデータなど）、デッドラインが迫る前に、いかに早く製品を市場に投入するかこそが、不確実性を減らす唯一の方法のように感じられます。市場に投入するものが増えれば増えるほど、得られるフィードバックも増え、（潜在的には）排除される不確実性も多くなります。

このループ——そしてすべての企業がスタート時に通らざるを得ない道程——は、純粋で原始的なスピードを追求しています。

しかし、企業が顧客を獲得し始めるとどうなるでしょうか？

アハ、ここで私たちの2つ目のループが登場します。人々がサービスの対価を支払うようになります。

2つ目のループ：有料顧客は既存のサービスに依存しており、シニアエンジニアは複雑性を制御することで長期的な安定を維持します。

多くのシニアエンジニアはこのループの中にいます。このループの核心的な目標は、サービスの継続と安定性の保証です。

システムが稼働し続けること、コードが読みやすい状態であること、問題がデバッグ可能であること、障害が修復可能であること、アーキテクチャが新人に伝達可能であること。そして何より、安定性を保つことです。

シニアエンジニアが安定性に心を砕くのは、企業が継続して顧客にサービスを提供し続ける責任を負っているからです。

では、それを脅かすものは何か？

複雑性 (Complexity) です。

複雑性はシステムを理解不能にし、デバッグを困難にし、修復を難しくし、引き継ぎを不可能にし、最終的にはシステムを極めて不安定なものにしてしまいます。

複雑性の増加 ＝ 安定性の低下 ＝ シニアエンジニアの失態 ＝ 最悪の結果。顧客からの支払いが停止し、全員が眉間に皺を寄せます。

つまり、最初のループの目標が「不確実性の排除」であるなら、2つ目のループの目標は「複雑性の管理」です。

では、なぜこれがコミュニケーションの失敗につながるのでしょうか？

それは、顧客を獲得すると、この2つのループが同時に稼働し始めるからです。企業は新しい可能性を探求する必要がありながら、既存の顧客へのサービスも同時に維持しなければならないのです。

顧客を獲得した後、企業は新たな可能性を探求すると同時に、既存の顧客を守り続けなければなりません。

さて、今やあなたは記事のタイトルにある問いに対する私の答えを推測できたことでしょう。

あなたが時間を主に費やすループがどちらかによって、問題に対する認識の枠組みは全く異なります（これが、開発者が AI に対する見解で分かれる理由だと私が考える所以です。一部の人は主に最初のループで働き、他の人々は2つ目のループで働いているのです）。

同じ要件に対する2つの解釈：ビジネス側はより迅速な検証を、開発者はより多くのコードパスとメンテナンスコストを見ます。

最初のループにいる人々の物語は以下の通りです：

ビジネス側の物語：彼らが求めているのはコードそのものではなく、より早く答えを知ることです。

しかし、二番目のループにいるシニア開発者の物語は以下の通りです：

開発者の物語：真のプロフェッショナルな価値とは、より少ない複雑さによってより高い確実性をもたらすことです。

この二つの物語は根本的に噛み合いません。

シニア開発者が受け取る「新機能追加」の要求が多ければ多いほど、彼らはついつい反論したくなります。「いや……それは無理だ……あまりにも複雑すぎる……保守コストが高すぎる……コードが読めなくなる……今後の開発速度が遅くなる……長期的には生産性を阻害する……」。しかし、これらの愚痴はビジネス側が「不確実性の即時排除」を切実に求めているという要請に対して何の役にも立ちません。

診断結果：自分の悩みで相手の問題を誤魔化してはいけない。

処方箋：あなたの解決策を、相手も抱える問題を解決できる形にパッケージ化しなければならない。

シニア開発者がコミュニケーションに失敗するのは、常に「複雑性の管理」という論理を使って苦衷を説明しようとするからです。本来は、「不確実性の排除」という論理で自分の解決策を売り込むべきなのです。

シニア開発者が会社の他部門が本当に求めているのは不確実性の排除だと気づけば、彼らは自らの専門性を活かして支援できるようになります。

では、シニア開発者が最も得意とするスキルとは何でしょうか？それは、不必要なものを開発したくないという気持ちです。また、既存のコードを再利用する機会を鋭く見つける能力です。

*アンケートデータの収集が必要ですか？* Google フォームを使えばいいのですよ、ベイビー。

*新機能を開発してテストする必要がありますか？* 既存の UI インターフェースにダミーボタンを追加して、誰かがクリックするか試してみませんか？（いわゆる「絵空事テスト」や検証性テストです）

*新しいデータ分析サービスが必要ですか？* データを見て下す最も重要な意思決定は何でしょうか？その一つの意思決定のために、まずはチャート一つ、指標一つだけ作ってみることはできませんか？

*わざわざ手間をかけて私に完全な誕生日ケーキを焼いてくれますか？* やめましょう。私のサンドイッチにろうそくを一本刺せばそれで十分です。

これがシニア開発者が学んだ生存の知恵です：既存のソフトウェアリソースを活用し、巧みに相手に必要なものを与える方法を身につけたのです。

では、これをどのように伝えれば、毎回相手に小論文を書かせることなく伝えることができるでしょうか？

コピーライターたちは最も得意とするのが、複雑な情報を凝縮して一言で力強く表現することです。そこで、すべてのシニア開発者が暗記すべき魔法の呪文があります：「もっと速い方法で試してみませんか？」

「より速く (quicker)」という言葉を使うことで、ビジネス側が真に求めているもの（速度）を認め、迎合しています。「何か (something)」という表現は、目標達成には別の手段があることを示唆しており、「試す (try)」という言葉は、この解決策が完璧ではないかもしれないが、おそらく十分良いものであることを暗示しています。

この一言は、他部門の核心である「速度による不確実性の排除」を完璧に捉えつつ、シニア開発者が専門性を存分に発揮できる道を開きます：機能の簡素化、コードの再利用、そして運が良ければ開発そのものの回避です。

これが答えです。私が記事のタイトルに対する回答としたいのは、皆が「不確実性」で頭を抱えている時、シニア開発者は常に「複雑さ」を口にするという点です。

しかし！大きな転換点が到来します！

現在の AI はすべてを無意味なものにしてしまったように思えますね？なぜ簡素化する必要があるのでしょうか？なぜ再利用する必要があるのでしょうか？なぜ開発を避ける必要があるのでしょうか？AI は極めて短い時間で膨大な量のコードを書き上げることができます。

ああ、そうは言っても、AI がいまだにできないことが一つあります。それがまさにシニア開発者が今もなお堅持していることです。

責任を負う (Take responsibility)——責任を被る。

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}