ソフトウェア開発の未来についての考察

xguru · 2024-03-25T10:31:01+09:00

大規模言語モデル（LLM）は、画像、テキスト、コードを生成できるようになり、創作分野に大きな波紋をもたらしている当初は、人の手が不自然に描かれた画像や、誤った事実を語るなど、笑ってしまうような結果が多かったが、徐々に改善されているこうしたモデルが登場する前は、機械は創造的に考えることができないという点が自動化に対する主な反論だったが、今ではその主張は次第に弱まっているでは、次にどこへ向かうべきだろうか？ Framework: ソフトウェア開発能力レベルソフトウェア開発は、単にコードを書くこと以上のものプログラマーのイメージは、暗い部屋でコンピュータを見つめながら一生懸命コードを打ち込む人だが、実際にはコードを書く以外の作業により多くの時間を費やしているビジネスユーザーから要件を収集する要件をコードでモデル化できるように整理するデザイナーやプロダクトマネージャーのようなチームメンバーと解決策を可視化し、計画を立てる他の開発者と技術設計を行い、洗練させるインフラ設定、構成、ボイラープレートなど実際のコードを書くデバッグ、他人のコードの理解、ドキュメント作成など本番環境へのデプロイ本番障害への対応その他多くの作業「AIが開発者を代替する」という言葉は、AIが上記のすべての作業に習熟していなければならないことを意味するしかし上の一覧を見ると、これらの作業の一部は今後自動化されるかもしれないが、まだ自動化できないように見える自動運転車の自動化レベル分類自動運転車の分野では、自動化レベルを分類する方法が開発されているこの分類は、現在の技術が何をできるのかを明確に説明し、白黒思考を避けるこの分類をAIベースのソフトウェア開発に当てはめてみると最も低い段階は、以前からあったもの、つまり業務にAIが関与しない段階。もちろんコンパイラやビルドプロセスなど、別種の自動化は存在していたが、これはAIではなく人間が書いた決定論的な自動化にあたるその次の段階は、現在私たちが持っているもの開発者がChatGPTやGitHub Copilotを使って支援を受けること開発者はテスト作成、定型コード、リファクタリング、コードやエラーの理解のためにこれらを使うチャットを通じて同僚の開発者と会話するように質問したり助けを得たりできるが、コンピュータへのアクセス権はないため、ファイルを作成したりビルドコマンドを実行したり、本番環境へデプロイしたりはできない最も高い段階は、プロジェクトの一部または全部を「AIコーダー」に委任すること AIコーダーが要件を受け取り、コードを書き、エラーを修正し、最終製品を本番環境へデプロイするこうしたことが起こるまでにはまだ数か月かかると思っていたが、今は単純な開発作業しかこなせないとしても、今後改善される可能性があることがDevinのデモによって示された Devin、最初のAIソフトウェアエンジニア AIモデルの能力に加えて、ソリューションがどれほど正確かも考える必要があるこうしたモデルはハルシネーションに弱かったり、望む結果を得るために特定の方法でプロンプトしなければならない傾向があるこのため導入時の摩擦が生じ、多くの人がこの時点でAIアシスタントを使うのをやめてしまうしかし、これも改善されており、最新モデルではこのレベルのプロンプトエンジニアリングは必要ないまた、モデルは学習データに依存する代わりに、Webを探索して「学習」できる必要があるこれはライブラリやプログラミング言語の新しいバージョンが導入されるにつれて重要になる Framework: アウトソースされたソフトウェア開発では能力が構築されたとして、チームや組織構造にはどのような影響があるだろうか？会社はさまざまな形でソフトウェア開発を行っている: 完全にインハウス少数のベンダーを併用しつつ大半はインハウス多数のベンダーを併用しつつインハウスは少しだけ完全にベンダー任せ AIコーダーは、アウトソースされたソフトウェアベンダーやコンサルタントとして捉えることができる社内チームがベンダーの仕事を監督することは重要契約によってこの問題に対処することもできるが、契約は通常、特定の供給業者やプロジェクトにしか適用されず、この方法では長期的な目標を強制できないベンダーを導ける小規模な社内チームでも持っておく方がよい同様に、EC2インスタンスのようにAIコーダーを借りられる場合でも、ソフトウェア開発者からなる社内チームがその作業を監督する方が有利 Framework: ソフトウェア開発は複雑性のモデリングビジネス上の問題を解決することを考えるとき、例としてExcelを挙げることができる。 Excelは参入障壁が非常に低く、これでデータを整理したり、データ分析を行ったり、一部のプロセスを自動化したりできるしかし、細かなアクセス制御、未対応システムとの統合機能、テスト可能性、再利用性、ベンダーロックインといった観点の機能がないため、複雑なビジネスワークフローには向いていない Power Automateのような「ローコード」ソリューションも同様「ビジネスユーザーは、ソフトウェア開発者の助けなしにAIコーダーを使ってこのような複雑なワークフローを作れるのだろうか？」考えてみれば、Excelやローコードツールは何十年も存在してきたのに、なぜソフトウェア開発という職業は今も存在しているのだろうか？それは、ソフトウェア開発を単にコードを書くことだと考えているから複雑な問題には、その複雑さを効果的に管理し、ビジネス上の問題を現実のドメインからデジタルモデルへ変換できる人が必要言い換えれば、土木技術者の助けがなくてもYouTubeのチュートリアルで木造の物置を建てられるからといって、10階建ての建物も同じように建てられるし、そうすべきだという意味ではないこの仕事を正しく行う方法を学んでいけば、徐々に土木技術者になることもできるただし、きちんと学ぶために時間を投資するのか、それとも熟練したエンジニアを雇うのかという問題にすぎないしたがって、Excelを使うにせよ最新のAIコーダーを使うにせよ、複雑なロジックをモデリングしているなら、依然としてそれはソフトウェア開発者だと思う違うのは、スプレッドシートの数式、コード、プロンプトなど、ビジネス要件を表現するための道具だけ Framework: パイの大きさこのテーマをめぐる不安の大半は、ソフトウェア開発市場の規模がそのまま維持されるという仮定、つまりAIコーダーが徐々に人間から「市場シェア」を奪っていくという仮定を前提としている「ビジネス上の問題解決」市場の規模はソフトウェア開発よりはるかに大きいため、ソフトウェア開発がすぐに消えることはないだろう Framework: 形式的なビジネスロジック定義ビジネスロジックは常に明確な形式で定義されなければならないだからこそ、プログラミング言語は if、switch などの英単語を使っていても、その単語の意味を非常に厳密に定義しており、誤った単語を使うと動作しない。考えてみれば、Excelの数式やローコードのフローも同じ将来、AIコーダーが対話型の英語で与えられた命令を通じてソフトウェア製品を生成できるようになったとしても、バックエンドで生成されるビジネスロジックについての基本的な形式定義は依然として存在すると思うそれは今日私たちが使っている言語やフレームワークとは大きく異なって見えるかもしれないが、ビジネスロジックの形式的な定義は「コード」と非常によく似たものに聞こえる AIコーダーがこうしたビジネスロジックを決定論的な形で対話型の英語から生成できるようになるまでは、バックエンドで生成されたコードを理解し、必要であれば変更できる人が依然として必要。それがソフトウェア開発者結論仕事の性質は変わり、私たちが使う道具も今とは大きく異なるものになるだろうが、近い将来でもソフトウェア開発者のための市場は依然として存在すると考える

(sheshbabu.com)

39 ポイント投稿者 xguru 2024-03-25 | 7件のコメント | WhatsAppで共有

大規模言語モデル（LLM）は、画像、テキスト、コードを生成できるようになり、創作分野に大きな波紋をもたらしている
当初は、人の手が不自然に描かれた画像や、誤った事実を語るなど、笑ってしまうような結果が多かったが、徐々に改善されている
こうしたモデルが登場する前は、機械は創造的に考えることができないという点が自動化に対する主な反論だったが、今ではその主張は次第に弱まっている
では、次にどこへ向かうべきだろうか？

Framework: ソフトウェア開発能力レベル

ソフトウェア開発は、単にコードを書くこと以上のもの
プログラマーのイメージは、暗い部屋でコンピュータを見つめながら一生懸命コードを打ち込む人だが、実際にはコードを書く以外の作業により多くの時間を費やしている
- ビジネスユーザーから要件を収集する
- 要件をコードでモデル化できるように整理する
- デザイナーやプロダクトマネージャーのようなチームメンバーと解決策を可視化し、計画を立てる
- 他の開発者と技術設計を行い、洗練させる
- インフラ設定、構成、ボイラープレートなど
- 実際のコードを書く
- デバッグ、他人のコードの理解、ドキュメント作成など
- 本番環境へのデプロイ
- 本番障害への対応
- その他多くの作業
「AIが開発者を代替する」という言葉は、AIが上記のすべての作業に習熟していなければならないことを意味する
しかし上の一覧を見ると、これらの作業の一部は今後自動化されるかもしれないが、まだ自動化できないように見える

自動運転車の自動化レベル分類

自動運転車の分野では、自動化レベルを分類する方法が開発されている
この分類は、現在の技術が何をできるのかを明確に説明し、白黒思考を避ける
この分類をAIベースのソフトウェア開発に当てはめてみると
- 最も低い段階は、以前からあったもの、つまり業務にAIが関与しない段階。もちろんコンパイラやビルドプロセスなど、別種の自動化は存在していたが、これはAIではなく人間が書いた決定論的な自動化にあたる
- その次の段階は、現在私たちが持っているもの
  - 開発者がChatGPTやGitHub Copilotを使って支援を受けること
  - 開発者はテスト作成、定型コード、リファクタリング、コードやエラーの理解のためにこれらを使う
  - チャットを通じて同僚の開発者と会話するように質問したり助けを得たりできるが、コンピュータへのアクセス権はないため、ファイルを作成したりビルドコマンドを実行したり、本番環境へデプロイしたりはできない
- 最も高い段階は、プロジェクトの一部または全部を「AIコーダー」に委任すること
  - AIコーダーが要件を受け取り、コードを書き、エラーを修正し、最終製品を本番環境へデプロイする
  - こうしたことが起こるまでにはまだ数か月かかると思っていたが、今は単純な開発作業しかこなせないとしても、今後改善される可能性があることがDevinのデモによって示された Devin、最初のAIソフトウェアエンジニア
AIモデルの能力に加えて、ソリューションがどれほど正確かも考える必要がある
- こうしたモデルはハルシネーションに弱かったり、望む結果を得るために特定の方法でプロンプトしなければならない傾向がある
- このため導入時の摩擦が生じ、多くの人がこの時点でAIアシスタントを使うのをやめてしまう
- しかし、これも改善されており、最新モデルではこのレベルのプロンプトエンジニアリングは必要ない
また、モデルは学習データに依存する代わりに、Webを探索して「学習」できる必要がある
- これはライブラリやプログラミング言語の新しいバージョンが導入されるにつれて重要になる

Framework: アウトソースされたソフトウェア開発

では能力が構築されたとして、チームや組織構造にはどのような影響があるだろうか？会社はさまざまな形でソフトウェア開発を行っている:
- 完全にインハウス
- 少数のベンダーを併用しつつ大半はインハウス
- 多数のベンダーを併用しつつインハウスは少しだけ
- 完全にベンダー任せ
AIコーダーは、アウトソースされたソフトウェアベンダーやコンサルタントとして捉えることができる
社内チームがベンダーの仕事を監督することは重要
- 契約によってこの問題に対処することもできるが、契約は通常、特定の供給業者やプロジェクトにしか適用されず、この方法では長期的な目標を強制できない
- ベンダーを導ける小規模な社内チームでも持っておく方がよい
- 同様に、EC2インスタンスのようにAIコーダーを借りられる場合でも、ソフトウェア開発者からなる社内チームがその作業を監督する方が有利

Framework: ソフトウェア開発は複雑性のモデリング

ビジネス上の問題を解決することを考えるとき、例としてExcelを挙げることができる。
Excelは参入障壁が非常に低く、これでデータを整理したり、データ分析を行ったり、一部のプロセスを自動化したりできる
しかし、細かなアクセス制御、未対応システムとの統合機能、テスト可能性、再利用性、ベンダーロックインといった観点の機能がないため、複雑なビジネスワークフローには向いていない
Power Automateのような「ローコード」ソリューションも同様
「ビジネスユーザーは、ソフトウェア開発者の助けなしにAIコーダーを使ってこのような複雑なワークフローを作れるのだろうか？」
考えてみれば、Excelやローコードツールは何十年も存在してきたのに、なぜソフトウェア開発という職業は今も存在しているのだろうか？
それは、ソフトウェア開発を単にコードを書くことだと考えているから
複雑な問題には、その複雑さを効果的に管理し、ビジネス上の問題を現実のドメインからデジタルモデルへ変換できる人が必要
言い換えれば、土木技術者の助けがなくてもYouTubeのチュートリアルで木造の物置を建てられるからといって、10階建ての建物も同じように建てられるし、そうすべきだという意味ではない
- この仕事を正しく行う方法を学んでいけば、徐々に土木技術者になることもできる
- ただし、きちんと学ぶために時間を投資するのか、それとも熟練したエンジニアを雇うのかという問題にすぎない
したがって、Excelを使うにせよ最新のAIコーダーを使うにせよ、複雑なロジックをモデリングしているなら、依然としてそれはソフトウェア開発者だと思う
違うのは、スプレッドシートの数式、コード、プロンプトなど、ビジネス要件を表現するための道具だけ

Framework: パイの大きさ

このテーマをめぐる不安の大半は、ソフトウェア開発市場の規模がそのまま維持されるという仮定、つまりAIコーダーが徐々に人間から「市場シェア」を奪っていくという仮定を前提としている
「ビジネス上の問題解決」市場の規模はソフトウェア開発よりはるかに大きいため、ソフトウェア開発がすぐに消えることはないだろう

Framework: 形式的なビジネスロジック定義

ビジネスロジックは常に明確な形式で定義されなければならない
だからこそ、プログラミング言語は if、switch などの英単語を使っていても、その単語の意味を非常に厳密に定義しており、誤った単語を使うと動作しない。考えてみれば、Excelの数式やローコードのフローも同じ
将来、AIコーダーが対話型の英語で与えられた命令を通じてソフトウェア製品を生成できるようになったとしても、バックエンドで生成されるビジネスロジックについての基本的な形式定義は依然として存在すると思う
それは今日私たちが使っている言語やフレームワークとは大きく異なって見えるかもしれないが、ビジネスロジックの形式的な定義は「コード」と非常によく似たものに聞こえる
AIコーダーがこうしたビジネスロジックを決定論的な形で対話型の英語から生成できるようになるまでは、バックエンドで生成されたコードを理解し、必要であれば変更できる人が依然として必要。それがソフトウェア開発者

結論

仕事の性質は変わり、私たちが使う道具も今とは大きく異なるものになるだろうが、近い将来でもソフトウェア開発者のための市場は依然として存在すると考える

7件のコメント

xguru 2024-03-31

Devin、最初のAIソフトウェアエンジニア
 OpenDevin - AIソフトウェアエンジニアDevinのオープンソース実装

dhlee0305 2024-03-25

OpenAIが有名になる前までは、AIの導入が最も遅れるか、あるいは不可能だと思われていた芸術分野からAIが領域を広げていくのを見ると、今「人間」にしかできないと考えていることも「安全」ではないかもしれないと、ふと思いました。

edunga1 2024-03-25

本文と https://ja.news.hada.io/topic?id=13557 の記事のように、
今後、開発者のパイは確実に縮小していき、さらに加速していくのでしょうか？

ahwjdekf 2024-03-25

AIプロンプトの重要性が日増しに高まるにつれて、より明確な仕様定義と要件整理が不可欠だと認識するユーザーが増えていき、これは結局のところ今後開発者が作業するうえで有利な方向に働くのではないかと思います。

colus001 2024-03-25

コードは人間のためのものであり、機械がコードを書くとしても人間が依然として必要だということなので、遠い未来の発展方向ではないと考えています。初期に実験していた backend-GPT (https://github.com/RootbeerComputer/backend-GPT) のように、ある種のブラックボックスに私たちが望む質問を投げ込めば、DB にアクセスしてデータを処理し、その前後の体験には人間が一部介在する形で発展していくのではないかと思います。

kaistj 2024-03-25

chat GPTやCopilotについて多く語られる中で、プロンプトエンジニアリングへの言及も多いように思います。私たちが主にプログラミングのために議論し、言葉で素早く意思疎通し、整理して確認していく過程を、いかにAIコーダーへ効率的に伝え、コミュニケーションできるかも重要な要素だと感じますね ^^.

vbmania 2024-03-25

"AIが開発者を代替するだろう"という言葉は、AIが上に挙げたすべての作業に習熟していなければならないことを意味します。

-> 人間が行うからこそ必要な手順なのかもしれませんし、結局それらの手順をすべて経たときに出てくるコードという成果物には、特定のパターンがあるのだと思います。ちょうど囲碁でも布石や定石のようなものが必要だと考えられていましたが、それは人間の認知の範囲内で情報を処理するためのやむを得ない方法にすぎなかったことが明らかになったように。