/note/tech

ソフトウェアエンジニアの本質は“課題解決”なのか?

要約:

■ 1. 問題提起と背景

  • エンジニアの本質は課題解決であるという台詞に対し筆者はずっと軽い違和感を持っていた
  • この違和感が明確に表出したのは最近である
  • ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそこの違和感を言語化すべきと考えた
  • AIがコーディングを代替しつつありその精度は高まり担える領域も確実に広がっている
  • エンジニアという職種の本質をあらためて問い直す必要がある

■ 2. エンジニアの本質は課題解決であるという言葉の問題点

  • この言葉には限定性と多義性という性質がある
  • 範囲を絞り込み同時に意味を広げてしまうという二つの性質が同時に含まれている
  • 言葉の構造:
    • エンジニアのという限定性
    • 課題解決という言葉の多義性
    • 課題解決であるという限定性

■ 3. エンジニアのと限定する不自然さ

  • 課題解決という営みはエンジニア職に固有のものではない
  • ビジネスに関わる多くの職種にとってその本質は課題解決にある
  • 企業のミッションは抽象度をあげれば課題解決に行き着く
  • 特定の職種を指してその本質が課題解決にあると語ることに不自然さがある
  • この限定性の背景:
    • 手段が目的化しやすいというエンジニアという専門職特有の事情
    • 専門技術を追求する面白さに没頭するがあまり何のために技術を行使しているのかを忘れやすい
    • デザイナーがデザイン性にばかり気を取られ機能性を見失う構造と類似
  • コードを書くことそのものをエンジニアの仕事だと捉えすぎることへの批判が含まれている

■ 4. 課題解決という言葉への解像度の低さ

  • 課題解決という言葉は響きがビジネス的で格好良いが便利に使われすぎる側面がある
  • 何を指しているのか分かったようで分からない
  • 課題解決と呼ばれる営みに含まれるプロセス:
    • 現状把握
    • あるべき姿の設定
    • 問題の特定
    • 原因分析
    • 課題の設定
    • 解決策の実行
  • 一連のプロセス全体がエンジニアの本質なのか最後の解決策の実行だけを指しているのかが曖昧
  • 本来は三人の石切り工の話に近く解決策の実行だけを担っていても全体を通して課題を解決しているという認識を持つべきという意味
  • 課題解決という言葉は文脈によっては受託開発の構造を想起させやすい:
    • ウォーターフォール型の工程分離が前提
    • 上流工程と下流工程として異なる役割が割り当てられる
    • エンジニアが主に担う解決策の実行の役割を指す責務の話として受け取られる場合がある
  • あるべき姿と現状のギャップを対象とする課題解決だけがエンジニアリングの営みではない
  • 新しい価値を生み出すことや既にある価値を維持し将来へ継承していくことは必ずしも明確な問題から始まるわけではない
  • これらの営みも抽象度を上げれば課題解決という枠組みの中に含めて捉えることができる

■ 5. 課題解決であるとの断定による問題

  • であるという限定的な言い回しは課題解決が持つ多義性を包み込む余地をかえって狭めている
  • 課題解決が狭義の意味に閉じてしまうような印象を与えかねない
  • 聞き手の意識が価値創造や維持・継承へと向かう余地をあらかじめ狭めている
  • 話し手自身も狭義の課題解決という枠組みの中でしか物事を捉えられていない可能性
  • ソフトウェアエンジニアという職能の可能性を静かに狭めてしまう行為になり得る

■ 6. エンジニアリングの提供価値

  • エンジニアの本質とはエンジニアリングの生み出す価値そのものである
  • 三つの観点:
    • 複雑性を秩序に変換する
    • 再現性と効率性を創出する
    • 持続可能性を維持する
  • 複雑性を秩序に変換する:
    • ソフトウェア開発はそもそも不確実なものを扱う営み
    • エンジニアリングの本質は不確実性の削減
    • 不確実性コーンが示すように不確実な状態から確実な状態へと変えていく活動
    • 絶え間ない探索と論理を手がかりとして複雑性に秩序をもたらす営み
  • 再現性と効率性を創出する:
    • ソフトウェアは同じことを同じように何度でもできる
    • 再配布可能な知識やスキルのパッケージ
    • ソフトウェアで処理される知識やスキルや手続きは人間が処理するよりも速く安定している
    • 人間の能力が拡張される
  • 持続可能性を維持する:
    • ソフトウェアは完成した瞬間から変わり続けることを宿命付けられた成果物
    • 変更が容易でなければソフトとは言えずその価値が失われていく
    • ソフトウェアの稼働期間が長いほどその振る舞いに変更が入る
    • それに耐えうる構造を維持し進化させ続けることが単なるプログラミングとエンジニアリングを分ける
    • 持続可能性の維持は設計や実装の巧拙だけで決まるものではない
    • 変更を前提にした意思決定や構造への投資の積み重ねによって形作られる

■ 7. エンジニアの本質の定義

  • GeminiやChatGPTと定義の言語化を繰り返した結果導き出されたエンジニアの本質:
    • 論理の力で混沌とした現実に再現性のある秩序を与えることで価値を持続的に創出し人間の可能性を拡張し続けること
  • 短縮すると再現性ある価値の継続的な創出
  • 企業で働くエンジニアの価値は自社のミッションのもと目の前のユーザーや顧客やビジネスあるいは社会に向き合いこの役割定義を実行することで具現化される

■ 8. AI時代におけるエンジニアの本質

  • AIがコーディングを代替するようになってもエンジニアのアイデンティティが崩壊するわけではない
  • エンジニアの本質は変わっていない
  • AIが担う領域がさらに広がっても同じ
  • コーディングエージェントとの協働は新しい知的な楽しさももたらしている
  • ケント・ベックが50年に及ぶプログラミング経験の中で今が一番楽しいと述べている
  • 手段が目的化しやすいのは専門職種の宿命であり対象に深く没頭している証であり知的好奇心の表れ
  • その追求は個人の満足にとどまらず組織に新たな可能性や能力の飛躍をもたらすこともある
  • 夢中になることはエンジニアリングの原動力
  • AIとの協働で形は変わっても技術への探究心は持ち続けるべき
  • その探究の先で混沌とした現実に秩序を与え再現性ある価値として社会に残していく
  • AI時代においても変わらないエンジニアの本質がある

■ 9. 記事執筆の経緯

  • パネルディスカッションでエンジニアの本質は課題解決であるという言葉への違和感を表明したことがきっかけ
  • それをあらためて整理し言葉にしてみようとしたのが本記事の試み
  • AI時代においても本質が変わらないという点ではソフトウェア開発組織の設計原理についても同様
  • AIによって開発が加速するほど組織構造に由来する摩擦は無視できなくなる