昨年末からFlutterの開発プロジェクトに参加・・・というか、立ち上げというか、関わることになりました。
これまでも何度となく新しいプロジェクトに参加するたびに、対象となる技術に関して勉強しようと本を買う。
そして、忙しさから本を読まないでプロジェクトを終える。。。という事になっています。
実際問題、私の役割としてコードを書くことはそれほど無いので、これってどこまで理解している必要あるんだっけ？といつも微妙な気分になりながら、メンバーに任せている。
任せざるを得ない感じになるんですよね。
世はAIコーディングまっしぐらな状態なので余計にその状況には拍車がかかると思います。
偉い人も呟いていました
以下のような主張。
— iwashi / Yoshimasa Iwase (@iwashi86) January 4, 2026
・ソフトウェア開発の中心地は、コードを書く場所から、意図の定義と結果の検証へと移動している
・私たちは、エージェントが活躍できる文脈豊かな環境と構造を作ることに注力すべきではないか
・これが、これからの時代のソフトウェア開発における「仕事」の正体 https://t.co/zJVuKzONwh
ソフトウェア開発というものが「AIに対して正しく意図の定義を伝えること」と「結果を正しく検証すること」になっていくのかもしれません。
でもそうなると、AIに対して”正しく伝える”の範囲も結構広くなる可能性もありそうだな？と。
”コンテキストや仕様を正しく伝える”というのは当たり前の話ですが、”ソフトウェア構造に対する注文を正しく伝える”こともまだしばらく必要になるはず。
そうなると、より解像度を上げるためには言語やフレームワークの制約、選択肢などを正しく把握しておくのは良いことだと思いました。
むしろ、それらを抜かした形はいくらでも量産できてしまい、差別化出来ずに埋もれていくことになりそうだな、と。
何で差異を作っていくのかはもちろん様々な選択肢があるとは思いますが。
そんなことをぼんやりと考えながら、Qiitaに学習メモを書いていってます。
あくまで自分の気になった部分だけなので学習コンテンツとはならないですが。