1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ポエム:生成AIで変わったこと・変わらないこと

1
Posted at

駄文

ソフトウェア開発の流れ

まずソフトウェア開発のフローチャートを考えてみる。

まずはウォーターフォール。作るべきものを開発の初期段階で比較的明確に定義でき、その後の変更は限定的であるという前提に寄る。

一方アジャイル開発の場合、開発開始時点では作るべきものを完全には確定しきれず、変化や学習を前提として、反復しながら「何を作るべきか」と「どう作るか」を更新していく。

生成AIは何を変えたのか

  1. 「課題の解決方法・作るべきもの(=要件定義)」を考える際の議論の速度が向上した
  2. 「どう作るのか(=設計)」もある程度の案が出てくる
  3. 特に「作る(=開発)」工程のコストが著しく低下した

→ いったん方向さえ決まればそこまで到達するコストが小さくなったことで、仮説を素早く形にして試す探索的なアプローチを以前より取りやすくなっている。

image.png
https://zenn.dev/dove/articles/b1b9573baea863 より引用

一度矢印を決めることができれば、その地点まで移動するコストが小さくなった。

変わっていないこと

  • 「課題」は必ずしも自然に湧いてくるものではなくて、見つけようと思わないと見つからない
  • 間違った方法では課題は解決しない。「作る」ことだけが課題の解決方法ではない

→与えられた前提条件から問いを正しく設定すること(矢印を決めること)は、今までもこれからも必要な技能。

「問い」は、ソフトウェアが相手にする現実の課題かもしれないし(業務効率化、研究開発…)、ソフトウェアの具体の議論かもしれない(機能追加、バグ修正…)。

例えば上記のフローの大半を生成AIが代替してしまったとしても、「課題を見つけて言語化する」という行為が無くなることはないのではないか(=矢印の定義・LLMへの入力としての言語)。また、生成AIが十分に賢ければ、「顧客が本当に欲しかったもの」を一発で特定できるのかというと、そうではないはずで、そもそも「欲しいもの」を言語化できていないはず。これはミームになるほどに古典的な問題である。

image.png
出典不明の例の画像

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?