QCon London 2026: 退屈な問題の隠れた力
Personio社のリードソフトウェアエンジニアであるYinka Omoleは、QCon London 2026において、最新技術の習得と地味だが長期的価値のある基礎的問題への投資という、エンジニアが直面するジレンマを探るセッションを発表した。
キーポイント
エンジニアのジレンマの提示
エンジニアが直面する、最新技術の習得と地味だが基礎的で長期的価値のある問題への投資の間の選択のジレンマについて探求している。
「地味な問題」の価値の強調
一見刺激的でないように見える基礎的な問題（boring problems）に投資することが、長期的な価値をもたらす可能性があるという視点を提示している。
実践的なエンジニアリング洞察
カンファレンスのセッションとして、実際のソフトウェア開発現場における意思決定とリソース配分に関する実践的な議論を提供している。
影響分析・編集コメントを表示
影響分析
この記事は、AI/ソフトウェア開発業界において持続可能なエンジニアリング文化と技術選定の在り方についての重要な議論を提起している。短期的なトレンド追従ではなく、長期的な価値創造に焦点を当てることで、技術負債の軽減とシステムの堅牢性向上に寄与する可能性がある。
編集コメント
技術トレンドの激しい変化の中で、基礎を疎かにしないバランスの取れたエンジニアリング戦略の重要性を再認識させる内容。実務者にとって非常に現実的な課題を扱っている。
QCon London 2026において、PersonioのリードソフトウェアエンジニアであるYinka Omole氏は、エンジニアが直面する繰り返されるジレンマについてセッションを行いました。それは、最新の技術やフレームワークを習得するために時間を費やすべきか、それともより刺激的には見えないかもしれないが長期的な価値をもたらす根本的な問題に投資すべきかという選択です。
この講演では、ハイプサイクルが定期的にプログラミングを変革したり、あるいは置き換えたりすると約束する一方で、最も価値のあるエンジニアリングの専門知識は、特定のツールではなく根本的な問題に基づいている場合に、時間とともに複利のように蓄積されると主張しました。
プログラミングの終焉に関する予測の長い歴史
ソフトウェアエンジニアリングの衰退に関する予測は、コンピューティングの歴史を通じて繰り返し現れてきました。2023年にMatt Welsh氏がACMコミュニケーションズに掲載した記事では、AIの進歩がプログラマーの役割を大きく変える可能性があると示唆しました。
同様の主張は数十年も前に現れています。1950年代後半には、FORTRANなどの言語が、専門的なプログラマーなしにビジネスプロフェッショナルがソフトウェアを書けるようにするものとして推進されました。1965年、コンピュータサイエンティストのHerbert Simon氏は、機械が今後20年以内に人間の知的タスクのほとんどを遂行できるようになると予測しました。
1990年代には、Computer-Aided Software Engineering（CASE）ツールが、図面から直接完全なアプリケーションを生成すると約束しました。しかし、生成されたシステムは現実世界のエッジケースで頻繁に struggled し、経験豊富なエンジニアの介入が必要となりました。
より最近では、AI 生成コードを巡る同様の議論が再燃しています。2025 年、Anthropic の CEO である Dario Amodei は、AI が 1 年以内にソフトウェアコードの大部分を書き上げられるようになるだろうと予測しました。
これらの繰り返される予測にもかかわらず、世界中の開発者数は増え続けています。推計によると、グローバルな開発者人口は 2019 年の約 1,400 万人から、2025 年には約 2,100 万人に増加したとされています。
なぜこの職業は成長し続けるのか
むしろ減速するどころか、エンジニアが解決する根本的な問題が業界や技術を超えて繰り返し現れるため、この職業は拡大を続けています。
これらの反復される問題クラスを理解することに投資する開発者は、時間をかけて蓄積される知識を築きます。特定のツールは急速に変化しますが、多くの基礎となるエンジニアリングの概念は安定しています。
今回の講演では、技術が急速に進歩しているように見えても、その根幹はしばしば同じであるという考えが強調されました。異なる業界、スタック、アーキテクチャのトレンドを超えて、エンジニアたちはデータモデリング、信頼性、分散システム、ワークフローオーケストレーションに関する類似の問題に引き続き取り組んでいます。
複利効果を生む基盤
議論された例の一つは、PostgreSQL の進化です。長年にわたり、MySQL がオープンソースデータベースのデプロイを支配しており、特に LAMP スタックの一部としてその地位を築いていました。
時が経つにつれ、PostgreSQL は徐々に支持を集め、2023 年頃のいくつかの開発者向け調査で MySQL を抜きました。
この変化は、PostgreSQL が初期に正しさ、トランザクションの保証、拡張性に焦点を当てていたことを反映しています。その重視が初期の採用を遅らせたものの、堅牢なアーキテクチャ基盤を築きました。
全文検索、JSON サポート、AI ワークロード向けのベクトル拡張機能など、新たな機能が重要になるにつれて、データベースは主要なアーキテクチャ変更なしにそれらを組み込むことができました。コア機能への長期的な投資により、システムは新しい要件が現れるたびに自然に進化することができました。
技術と問題のマッチング
もう一つの例は WhatsApp の背後にあるアーキテクチャから来ました。Facebook が 2014 年にこのメッセージングサービスを買収した際、約 32 名のエンジニアチームで数億人のユーザーをサポートしていました。
このシステムは、極めて高い信頼性が求められる通信システム向けに Ericsson が 1980 年代に開発した Erlang という言語を用いて構築されました。
Erlang は障害発生時でも可用性を維持しなければならない分散型通信システム向けに設計されているため、グローバルなメッセージングプラットフォームのニーズと密接に一致していました。この適合性により、小規模なエンジニアチームが 1 日に数百億件のメッセージを処理するインフラストラクチャを運用することが可能になりました。
システム書き換えのリスク
本講演ではまた、複雑なシステムを一から書き直すことの危険性も検討されました。よく知られた例として、1990 年代後半に Netscape がブラウザのコードベース全体を再構築した決定が挙げられます。
書き換えには数年を要し、その間、会社は競争の重要な時期に新機能をリリースすることができませんでした。エンジニアのジェイミー・ザヴィンスキーは後にこの取り組みを歴史上最も大きなソフトウェア災害の一つと評しました。
システムの書き換えは、単に時代遅れのコードを破棄するだけではありません。また、エッジケースへの対応やアーキテクチャの決定に埋め込まれた何年もの蓄積された運用知識をも失い、すでに解決済みの問題に対する解決策をチームが再発見することを強いることになります。
シンプルなアーキテクチャが勝つ
より最近の事例では、Amazon のエンジニアが Amazon Prime Video 内の動画品質を分析するために記述したシステムが取り上げられました。
このシステムは当初、AWS Step Functions と Lambda に基づいた分散サーバーレスアーキテクチャを用いて構築されました。しかし、その設計は予想されるワークロードのごく一部を超えてスケールすることに苦戦しました。
遅延の多くは動画分析自体ではなく、サービス間の状態転送に起因していました。
エンジニアたちは最終的に、分散型デザインを ECS で動作するよりシンプルなアーキテクチャに置き換えました。ネットワーク呼び出しやストレージへの往復といった外部処理ではなく、メモリ内で操作を保持することで、チームはコストを約 90% 削減しつつスループットを倍増させました。
イノベーションの慎重な管理
新技術を評価するチームを支援するため、本講演ではエンジニアのダン・マッキンリーが導入した「イノベーショントークン」という概念が参照されました。
このモデルは、組織には新しい技術を導入する能力に限界があることを示唆しています。各新しいフレームワークやアーキテクチャパターンは、これらのトークンの一つを消費するため、チームは慎重にそれらを使うべきです。
重要な問いは、新しい技術が実際の課題を解決しているのか、それとも単に業界のトレンドに従っているだけなのかという点です。
永続的なエンジニアリング問題の特定
この講演ではまた、個々のエンジニアが学習時間をどこに投資すべきかを決定する方法についても探求しました。
決済システム、銀行インフラストラクチャ、給与計算プラットフォームなど、異なる役割において、一貫したパターンが見られます。それは、エンティティが発行済み、処理中、承認済み、または却下済みなどの状態間を移動する多段階ワークフローを管理するシステムです。
このパターンに気づくことで、エンジニアは特定の導入ツールではなく、ワークフローオーケストレーションや状態機械という根本的な概念に焦点を当てることができます。
カスタムロジックでもプラットフォームでも、実装方法は異なれど、根本的な問題はほぼ同じままです。これらの反復される構造に気づいた開発者は、業界、組織、技術スタックを超えて転用可能な専門知識を築くことができます。
AI ツールとエンジニアリングの未来
セッションは、急速に台頭している AI コーディングツールの問題について取り上げることで締めくくられました。
特定のモデルやプロンプト戦略に紐づく技術は、モデルの進化に伴って急速に変化していく可能性があります。しかし、複雑なシステムの分解、信頼性の高いアーキテクチャの設計、正しさの評価といったコアとなるエンジニアリングスキルは、コードがどのように生成されるかにかかわらず、引き続き価値あるものとして残ると考えられます。
AI ツールの台頭以前に堅固な基礎を築いてきたエンジニアたちは、現在もチームを率いる立場にあります。これは主に、彼らの専門性が実装に用いられるツールそのものではなく、根本的な問題解決に焦点を当てているためです。
業界がさらに進化していく中で、これらの退屈だが永続的な課題に取り組むことに注力することは、長期的なエンジニアリングの専門性を築くための最も信頼できる方法の一つとなる可能性があります。About the Author
Daniel Dominguez
Daniel は SamXLabs のマネージングパートナーです。SamXLabs は AWS パートナーネットワークに所属する企業です。彼はスタートアップおよびフォーチュン 500 企業向けソフトウェア製品開発において、13 年以上の経験を持っています。ワシントン大学で工学の学位を取得し、機械学習（Machine Learning）の専門分野を修了しています。AI とクラウドコンピューティングを活用して革新的なソリューションを生み出すことに情熱を注いでいます。機械学習（Machine Learning）ティアの AWS コミュニティビルダーとして、Daniel は知識の共有とソフトウェア製品におけるイノベーションの推進に尽力しています。
詳細を表示表示しない
原文を表示
At QCon London 2026, Yinka Omole, lead software engineer at Personio, presented a session exploring a recurring dilemma engineers face: whether to spend time mastering the newest technologies and frameworks, or to invest in deeper, foundational problems that may appear less exciting but deliver long-term value.
The talk argued that while hype cycles regularly promise to transform or even replace programming, the most valuable engineering expertise tends to compound over time when it is rooted in fundamental problems rather than specific tools.
A Long History of Predictions about the End of Programming
Predictions about the decline of software engineering have appeared repeatedly throughout computing history. A 2023 article by Matt Welsh in Communications of the ACM suggested that advances in AI could significantly change the role of programmers.
Similar claims appeared decades earlier. In the late 1950s, languages such as FORTRAN were promoted as enabling business professionals to write software without specialized programmers. In 1965, computer scientist Herbert Simon predicted that machines would soon be capable of performing most human intellectual tasks within twenty years.
In the 1990s, Computer-Aided Software Engineering tools promised to generate complete applications directly from diagrams. Generated systems frequently struggled with real-world edge cases, requiring experienced engineers to intervene.
More recently, similar discussions have reemerged with AI-generated code. In 2025, Dario Amodei, CEO of Anthropic, predicted that AI could write most software code within a year.
Despite these recurring predictions, the number of developers worldwide continues to grow. Estimates suggest the global developer population increased from roughly 14 million in 2019 to around 21 million by 2025.
Why the Profession Keeps Growing
Rather than slowing down, the profession continues expanding because the underlying problems engineers solve repeatedly reappear across industries and technologies.
Developers who invest in understanding these recurring problem classes build knowledge that compounds over time. While specific tools change quickly, many of the underlying engineering concepts remain stable.
The talk highlighted the idea that although technology appears to move quickly, the fundamentals often remain the same. Across different industries, stacks, and architectural trends, engineers continue to deal with similar issues involving data modeling, reliability, distributed systems, and workflow orchestration.
Foundations That Compound
One example discussed was the evolution of PostgreSQL. For many years, MySQL dominated open-source database deployments, particularly as part of the LAMP stack.
Over time, PostgreSQL gradually gained traction and eventually surpassed MySQL in several developer surveys around 2023.
This shift reflects PostgreSQL’s early focus on correctness, transactional guarantees, and extensibility. Although that emphasis slowed early adoption, it created a strong architectural foundation.
As new capabilities became important, such as full-text search, JSON support, or vector extensions for AI workloads, the database was able to incorporate them without major architectural changes. Long-term investment in core capabilities allowed the system to evolve naturally as new requirements emerged.
Matching Technology to the Problem
Another example came from the architecture behind WhatsApp. When Facebook acquired the messaging service in 2014, it supported hundreds of millions of users with a team of roughly 32 engineers.
The system was built using Erlang, a language developed by Ericsson in the 1980s for telecom systems requiring extremely high reliability.
Because Erlang was designed for distributed communication systems that must remain available under failure conditions, it aligned closely with the needs of a global messaging platform. That alignment allowed the small engineering team to operate infrastructure handling tens of billions of messages per day.
The Risks of Rewriting Systems
The talk also examined the dangers of rewriting complex systems from scratch. A well-known example is Netscape’s decision in the late 1990s to rebuild its browser codebase entirely.
The rewrite took several years, leaving the company unable to ship new features during a critical period of competition. Engineer Jamie Zawinski later described the effort as one of the biggest software disasters in history.
Rewriting a system does not only discard outdated code. It can also remove years of accumulated operational knowledge embedded in edge-case handling and architectural decisions, forcing teams to rediscover solutions to problems that had already been solved.
When Simpler Architectures Win
A more recent case involved a system described by Amazon engineers for analyzing video quality within Amazon Prime Video.
The system was initially built using a distributed serverless architecture based on AWS Step Functions and Lambda. However, the design struggled to scale beyond a small percentage of its expected workload.
Much of the latency came not from analyzing video but from transferring state between services.
Engineers eventually replaced the distributed design with a simpler architecture running on ECS. By keeping operations in memory rather than across network calls and storage round trips, the team reduced costs by roughly ninety percent while doubling throughput.
Managing Innovation Carefully
To help teams evaluate new technologies, the talk referenced the concept of innovation tokens, introduced by engineer Dan McKinley.
The model suggests that organizations have limited capacity to adopt new technologies. Each new framework or architectural pattern consumes one of these tokens, so teams should spend them carefully.
The key question becomes whether a new technology solves a real problem or simply follows industry trends.
Identifying Durable Engineering Problems
The talk also explored how individual engineers can decide where to invest their learning time.
Across different roles in payments systems, banking infrastructure, and payroll platforms, a recurring pattern appears, systems that manage multi-step workflows in which entities move between states such as initiated, processing, approved, or rejected.
Recognizing this pattern allows engineers to focus on the underlying concept of workflow orchestration and state machines rather than specific implementation tools.
Whether implemented with custom logic or platforms, the underlying problem remains largely the same. Developers who recognize these recurring structures can build expertise that transfers across industries, organizations, and technology stacks.
AI Tools and the Future of Engineering
The session concluded by addressing the rapid emergence of AI coding tools.
Techniques tied to specific models or prompt strategies may evolve quickly as models improve. However, core engineering skills, such as decomposing complex systems, designing reliable architectures, and evaluating correctness, are likely to remain valuable regardless of how code is generated.
Engineers who built strong foundations before the rise of AI tools continue to lead teams today, largely because their expertise focuses on the underlying problems rather than the tools used to implement them.
As the industry continues to evolve, focusing on these boring but durable problems may be one of the most reliable ways to build long-term engineering expertise.
About the Author
Daniel Dominguez
Daniel is the Managing Partner at SamXLabs an AWS Partner Network company. He has over 13 years of experience in software product development for startups and Fortune 500 companies. Daniel holds a degree in Engineering and a Machine Learning specialization from the University of Washington. He is passionate about leveraging AI and cloud computing to create innovative solutions. As an AWS Community Builder in the Machine Learning tier, Daniel is committed to sharing knowledge and driving innovation in software products.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み