履き心地がとても良く長時間歩けるという評判だったので膝を痛めていた妻向けに購入した。だがしかし、骨格や筋肉量の関係でかえって悪化し、今度は足底筋膜炎になってしまった...。柔道整復師、医師それぞれの所見としても合わない靴に起因する可能性が高いとのことだったので泣く泣くセカンダリーマーケットで売却した。

https://www.hoka.com/jp/clifton-10/1162031.html

アフィリエイト記事の最後にこれを貼ったのは戒めである。特に健康関連の器具・装具については気をつけていただきたい。

2025-12-30

「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘

雑感 AI Software Engineering

時折、「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚がはたらく。ソフトウェアエンジニアの勘といってもいい。

FizzBuzz Enterprise Editionはプログラマジョークとして解されるが、実際のエンジニアリングではもっと微妙な形で表れる。たとえば設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき、提案を実装した結果として管理すべき状態やコード量が減ったりする。(関連: 状態、結合、複雑性、コード量の順に最適化する - valid,invalid)

あるいはシステム要件や仕様について話す中で表出することも多い。「新しい画面を作ってこういう情報を見せたい」であったり「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると、既存機能で代替ができたり、大仰なインテグレーションは不要だと気づく。

不要な仕事を減らす能力

"No, AI is not Making Engineers 10x as Productive" (2025-08) ではAIはエンジニアを10倍生産的にはしない、という主張ととも不要な仕事を減らす能力の重要性が述べられていた。

(同記事の筆者が仕事を通じて見知った) 10x Engineerはコードを書くのが10倍早いわけではなく不要な作業を未然に防ぐ能力を持つ人だったと。PMを説得して実行不可能なタスクを止める、不要に複雑な開発を止める、DXに投資して全員の時間を節約する、将来のために自分の作業を文書化する...こうした活動が組織内で積み重なって10倍の差がつくことがある。

ここでは単なる勘ではなく能力 (ability) と表現しているが、自分が感じているものともかなり重なっているように思う。

ソフトウェアの設計は複雑性を管理する作業である

"What Is Software Design?" にて1992年に指摘されたことではあるが、高々数十〜数百行のコードで実行できる処理はとても複雑な内容でありうる。この点においてソフトウェアエンジニアリングにおける設計はその他のエンジニアリング分野からすると極めて特殊である。

ソフトウェアのような複雑なものをこれだけの短時間で設計できるのはほかのエンジニアリング分野では（少なくとも当時は）みられなかった。これがソフトウェアの複雑性が短期間で膨れ上がる原因でもあり、ソフトウェアの設計は複雑性を管理する作業である、とされた。

複雑性の爆発に対する不安

この「複雑性の管理」という視点で現在の開発環境を見直すと、当時とは質の違う問題が見えてくる。

30年以上が経過したいま、コード1行あたりの実現する処理の量はさらに増え、AI/LLMを用いることで自然言語1行から大量のコードおよび裏側の複雑性を生産できるようになった。しかも、そのトリガーを引けるのが専門のソフトウェアエンジニアだけではなくなってきている。

クリティカルな業務領域では、要件定義やコードレビューといった従来のプロセスを通じて、複雑性を押し留めようとする不断の活動が続いている。一方で、これまで以上に多くの人が新たな複雑性を生み出しつづけている、という構図もある。増大する複雑性の総体にどう立ち向かうべきか、この増大はいつしか手に負えなくなるのでは、と感じさせられる場面もある。

先の"No, AI is not Making Engineers 10x as Productive"が述べるAIコーディングエージェントは不要な作業を防ぐことはほとんどしない。それどころか、AIはしばしば性急な作業や過剰な構築を助長している*1という指摘は自分の不安を言い当てている。

これまで培ってきた「こんな複雑なことをしないといけないのはおかしい」という勘や不要な作業を防ぐ能力。これらに対して無頓着に逆行する振る舞いが、ソフトウェアエンジニアのAIに対する不安視の一端のように思う。

こうした勘や経験知、能力をフィードバックしたりコンテキストとして与えるべき、ガードレールを敷いたり方向づけをしていくべき、という方法論は知っている。

モデルプロバイダーやツール側の進化や創意工夫に学びつつ、自分が管理する領域や分野において同様の還元ができるかどうか、複雑性を管理するソフトウェアエンジニアの役割が問い直されていると感じる。

このような文章を書くと、オールドタイプがジョブセキュリティの不安からポジショントークしていると見えるかもしれないが、変化それ自体は面白くも感じている。

*1:2025年8月時点の記述である点に留意