■ 1. ソフトウェアエンジニアの勘
- 「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚が時折はたらく
- FizzBuzz Enterprise Editionはプログラマジョークとして解されるが実際のエンジニアリングではもっと微妙な形で表れる
- 設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき提案を実装した結果として管理すべき状態やコード量が減ることがある
- システム要件や仕様について話す中で表出することも多い:
- 「新しい画面を作ってこういう情報を見せたい」「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると既存機能で代替ができたり大仰なインテグレーションは不要だと気づく
■ 2. 不要な仕事を減らす能力
- "No, AI is not Making Engineers 10x as Productive"(2025-08)の主張:
- AIはエンジニアを10倍生産的にはしない
- 不要な仕事を減らす能力の重要性が述べられている
- 10x Engineerの特徴:
- コードを書くのが10倍早いわけではない
- 不要な作業を未然に防ぐ能力を持つ
- PMを説得して実行不可能なタスクを止める
- 不要に複雑な開発を止める
- DXに投資して全員の時間を節約する
- 将来のために自分の作業を文書化する
- こうした活動が組織内で積み重なって10倍の差がつくことがある
■ 3. ソフトウェアの設計は複雑性を管理する作業
- "What Is Software Design?"にて1992年に指摘された内容:
- 高々数十〜数百行のコードで実行できる処理はとても複雑な内容でありうる
- ソフトウェアエンジニアリングにおける設計はその他のエンジニアリング分野からすると極めて特殊
- ソフトウェアのような複雑なものをこれだけの短時間で設計できるのはほかのエンジニアリング分野では(少なくとも当時は)みられなかった
- これがソフトウェアの複雑性が短期間で膨れ上がる原因
- ソフトウェアの設計は複雑性を管理する作業である
■ 4. 複雑性の爆発に対する不安
- 30年以上が経過した現在の状況:
- コード1行あたりの実現する処理の量はさらに増えた
- AI/LLMを用いることで自然言語1行から大量のコードおよび裏側の複雑性を生産できるようになった
- そのトリガーを引けるのが専門のソフトウェアエンジニアだけではなくなってきている
- 現在の構図:
- クリティカルな業務領域では要件定義やコードレビューといった従来のプロセスを通じて複雑性を押し留めようとする不断の活動が続いている
- 一方でこれまで以上に多くの人が新たな複雑性を生み出しつづけている
- 増大する複雑性の総体にどう立ち向かうべきかこの増大はいつしか手に負えなくなるのではと感じさせられる
- AIコーディングエージェントに対する指摘:
- 不要な作業を防ぐことはほとんどしない
- AIはしばしば性急な作業や過剰な構築を助長している
- この指摘が筆者の不安を言い当てている
■ 5. ソフトウェアエンジニアのAIに対する不安
- これまで培ってきた「こんな複雑なことをしないといけないのはおかしい」という勘や不要な作業を防ぐ能力
- これらに対して無頓着に逆行する振る舞いがソフトウェアエンジニアのAIに対する不安視の一端
- 勘や経験知/能力をフィードバックしたりコンテキストとして与えるべきという方法論は知っている
- ガードレールを敷いたり方向づけをしていくべき
- モデルプロバイダーやツール側の進化や創意工夫に学びつつ自分が管理する領域や分野において同様の還元ができるかどうかが問われている
- 複雑性を管理するソフトウェアエンジニアの役割が問い直されていると感じる
- 変化それ自体は面白くも感じている