SNSで「エンジニアはコードに思想を持つべき」との投稿を見た時に覚えた様々な考えが、個人的に整理の価値有と感じたので書き落とす。
思ったこと
思考の時系列順で書く。
「思想」とは一体何か。個人的にはステークホルダーも巻き込んだ合意を得るための納得感あるストーリーのことなのだと思った
「思想」の正体がストーリーだとすると、思想の拠所は実装で無く設計にあるのでは。ストーリーの絵を描くのも、その内容をステークホルダー（顧客）と合意するのもフェーズ上は設計だ
そうなるとコーディング自体に思想が介在する余地はどこにあるのだろう。早い話、設計フェーズで得た筋道を自然言語で渡せば、単機能は一定の品質でLLMが作ってくれるじゃないか
問が2点ある感じだ。思想の正体と、仮説立てた思想の正体を元にするとコーディングは単純作業なんじゃ、と言う話。
ChatGPTと壁打ちした
悶々としても自身の経験・知識には限界があるので、ナレッジベース上遥か先を行くChatGPTと壁打ちをしてみた。
思想の正体
LLMはモダンな書き方等の手段案の提供は出来るが、どの手段に絞って作るか、との一貫性ある指針決めは難しい。要するにステークホルダーコンテキストを汲んだ判断を柔軟することが難しい。一貫性ある指針を定める行為を「思想」と回答をもらった
例として、命名規則やエラーハンドリングの指針（どうcatchするか、ログ出力どうするよ等）を挙げてもらった
ロジックを組み上げる上で様々なトレードオフ要素が生まれてくる、取捨選択を迫られる場面が出てくる（シンプルな物なら可読性 vs 簡潔性みたいな物はラムダ式的な部分で現場で話題になったりした）。取捨選択のポイントをどうするか、の一貫した基準は人間が周囲の環境に応じて定めろ、と言うことで咀嚼
作り物を作る上での取捨選択の判断軸を1本引け、と言うのが思想の正体と捉えた。ストーリー目線よりも実装上の文脈に近付いた気がするので、この内容で納得（ストーリーの話も重要な気はするが、起点の投稿に寄りそうと一旦無視して良いと思った）。
仮説立てた思想の正体を元にするとコーディングは単純作業なんじゃ
壁打ち前に認知の背景等を深掘りして思ったが、ぶっちゃけ現場によるな、で自己解決した。一応GPTにもあれこれ聞いてみたけど
経験上、基幹をウォーターフォール的に作る、設計開発メンバも実力差が激しい環境下で効率化を図った際、設計比重を厚くした上で開発は設計をなぞることに主眼を置いていた。これがベースであれば、取捨選択の軸を引く段階は設計にあり、コーディングは単純作業・LLM置き換え対象と見てもおかしくない
でも世の中ウォーターフォールだけでも無い。アジャイル的なサイクル・合意の場合はスコープと完了条件を定めた上で、そのゴールに行くまでの手段の選択余地はエンジニアの手腕に依る。この場合は判断軸を引く線を作る主体もエンジニアになっていきそう（自身の考えや周辺コードとの整合性、メンテメンバの力量を見てのメンテナビリティ判断等）
こうやって見ると、段階の話は結構些末で、結局はプロダクトがどう作られるのかのイメージ解像度を高めること、解像度高のイメージを元に「思想」で書いた判断軸を元に取捨選択してイメージの質を高めること、の2点は実装に携わる上で共通して必要な物なんだろうな、で一定結論が付いた気がする。
一旦の結論
対象はコードで無く、プロダクト作り自体に一定の思想（取捨選択の判断軸）を持った上でプロジェクトに参加せよ、と言うのが個人的には理解の落とし所として一番しっくり来た
その上で思想の発揮フェーズが現場によって揺れるが、設計 or 実装のどちらか、と言うだけの話
取捨選択軸の最適化目線は周辺のメンバ、ステークホルダーの事情に左右される。LLMは周辺環境の細かな事情を把握出来ないし、（元々書いていたストーリーも絡めれば）取捨選択の軸を納得してもらうための刺さるストーリーも書けない。人対人の要素はやっぱり人力がいるな
個人的にはLLMと共生する上での線引きとしても上記は納得感を覚えている。と言うかLLMにぶちこんで解決する物はLLMを使い倒したいし、LLMでは手が届かない物だけ頑張る感じで分業しないと、最近の情報量だったりにまるで太刀打ち出来ない。システム界隈に住む人間としても、この線引きは一定自身を生きやすくしてくれる気がする
追伸
この記事はChatGPTに壁打ちは依頼したし、叩きになる文章も書いてもらったが、叩き文は結局ほとんど参照しないで書いた。このブログの文章自体は純度100%の人力。よろしこ。