00:05
はい、4月21日金曜日ですね。時刻は朝9時15分になりました。
えー、もうなんか毎回毎回寝坊するんで、もう開始は9時じゃなくて、9時15分にデフォルトで設定した方がいいんじゃないかと思い直している今日この頃です。
はい、おはようございます。ユメミのkeethこと久保原です。では、本日も朝活を始めていきたいなと思っております。
はい、えー、今日はですね、あのちょっともしかしたら短いかもしれないですけど、昨日読んでいた記事の続きじゃなくて別の記事ですね。
昨日はレイヤーXさんの中のゆうや4さん、ゆうや4さんっていう方が書かれていたブログ。
マネージャーであることを言い訳せずに手を動かし続けるという記事ですね。
を読んだんですけど、えー、これの中に貼られていた別の記事のリンクですね。
えー、ChatGPTや大規模言語モデルによる変化とソフトウェア開発の雑感っていうところの記事を読んでいこうと思います。
はい、まあこの辺の分野とかはレイヤーXさんはまさに本格的にやられている。
その中でCTOの松本さんが書かれた雑感の記事なので、結構知見があるんじゃないかっていうのを期待して読んでいこうかなと思っております。
はい、まあ日本語の記事なのとやっぱりその一本記事としてそんなに長くはない、やっぱ雑感でぐらいレベルのお話ですので、
ちょっと早めに終わってしまう可能性はあるんですけど、まあもしかしたらですね、
別の記事、ことに向き合いトラストフルな組織を実現するためにという別の記事のリンクも貼られているので、そこを読んでみようかなと思います。
はい、じゃあ早速いきましょう。
GPT-4とChat GPT-Plus、ただただ共感するばかりですね。
SNSのタイムラインや知人など狭い観測範囲ですが、この話題ばかりだという印象です。
レイヤーXでも毎日話題で、同時多発的にエンジニア陣がいろいろなアプローチを試してはデモをしています。
楽しいと。
この衝撃をソフトウェアエンジニアとして咀嚼してみたので、雑記としてChat GPT-Plus先生にまとめてもらいました。
この記事自体もまとめてもらったのかな。
ちなみに長々と書いていますが、雑版には書きのようなことを書いています。
一つ、コードの生成だけでなく実行で得られたエラーに対する修正も含めて、一連のプロセスとして大規模言語モデル、LLMで実現できるようになります。
合言語のジェネレーターと似た発想で、コード自体は毎度書き捨てみたいな考え方も増え、LLMに合わせた実行環境やツールが出てくる。
二つ目、テストもLLMで生成できる。ユニットテストは今日から使える。E2Eテストなども作れるだろうし、マルチモーダルモデルになればスクショからPC操作なども実現できる。
LLMに即したプロダクトが出てくるでしょう。
三つ目、コーディング面接が無意味になりました。この手段で測れる技術力はLLMに任せればいいものになってしまった。意思決定をより問う重要性が増してくるようになった。
これは既存の判断基軸でのコーディング面接が無意味になったということですね。
四つ目、人の関わる意義は課題の発見やトレードオフのある答えのない選択肢の中での方向づけなどエモーショナルな要素を混ざったタスクを中心になってくる。意思決定力がさらに重要になります。
03:05
続いて、今書いているコードは低水準言語になっていくかもしれない。
LLMに合わせた言語やツールも登場する中で、コード自体に向き合うことは減るでしょう。
これはインフラにおけるクラウド化などが例として現れていますが、そういうように重症化が進み続けていった流れの延長とも言えます。
最後6つ目、エンジニアとしてはLLMを使って新たなプロダクトの作り方を模索していくべく積極的に試していくことをお勧めしたいと。
個人的にはスマホやクラウドの登場くらいワクワクするなぁと、毎日眠るのも惜しいくらい楽しい技術ですねとおっしゃっています。
以下、GPT-4先生からミッターソフトウェア開発の変化10項目だと言っています。
1つ、効率の向上。大規模言語モデルを使用することで、コード生成やエラー訂正が自動化され開発の効率が向上します。
2つ目、品質の向上。自動生成されたテストコードによりソフトウェアの品質が向上し、マグの発見や修正が容易になります。
3つ目、時間の節約です。開発者は煩雑なゴーディング作業から解放され、より創造的なタスクやプロジェクトの全体戦略に集中できるようになります。
4つ目、イノベーションの促進。開発者がより高度な問題解決に注力できることで、イノベーションが促進され、新しい技術やソリューションが生まれやすくなります。
5つ目、学習コストの低減。大規模言語モデルがコード生成をサポートすることで、初心者でも短期間で開発を始めることができ、学習コストが低減されます。
学習コストは、学習をどこまでできたかという基準の定義によって、一概にコストが低減するとは思っていません。
もちろん、習熟度という意味でいくと速くなったかどうかは関係ありません。
学習コストが低減するときは、そこまでまだ影響はあるかというと、僕は難しいなと思っています。
やっぱり突っ込んだものとか、ニッチなケースにおけるどうしたらいいというケースバイケースのケーススタディ的な学習であったりとかになってくると、そこまで支えるかというと結構際どいところはしますね。
プロンプトをしっかり考えたりとか、情報を渡した上での答えを問うというところに関してはもちろん強いので、いけるところは全然いけると思うんですけど、
やっぱり本当の意味での学習というつまり定着と言いますかね、とかその本人に対してスキルアップになるというところでいくと、どのかはちょっと疑問だなと思ったりはしましたね。
スタートのところという意味でのスタートダッシュはやっぱり早いかなと言っていますね。
次で6つ目、技術スタックの進化というところですね。大規模言語モデルに適した技術スタックやプログラミング言語が増え、開発プロセスの柔軟性というのが向上しますと。
7つ目、コードの過読性ですね。自動生成されたコードは一定の品質と過読性が保証されるため、コードレビューや保守性というのが向上しますと。
8つ目、人材の選抜基準の変化。面接でそのコーディング能力よりも課題発見や方向づけの能力というのが重視されるようになる。開発者の役割というのが変化してくるというところですね。これは本当に完全同意だなという感じです。
06:11
9つ目、開発ツールの進化。大規模言語モデルと連携した開発ツールというのが登場し、開発環境がより強力で効率的になりますよと。
最後の10個目、人間と機械の共同だと。開発者は大規模言語モデルと協力し、プロジェクトの戦略立案や意思決定に集中することで、人間と機械の共同というのが進むでしょうと。
以下はGPT-4先生に自分の考え方をまとめてもらったブログですと。数対話でかけてしまったというところですごいですなというふうに松本さんはおっしゃっています。
1つ目ですね。じゃあ行きましょう。ここからが一応本題ですね。
GPT-4という衝撃。指示だけで簡易なアプリが作られるということですね。
GPT-4の登場はソフトエンジニアリングの世界に大きな変化をもたらしましたと。
この革新的な言語モデルは指示だけで簡易なアプリケーションを作成する能力を持っており、開発者の能力を大幅に削減することができます。
GPT-4を活用することでアイデアを素早く実現し、プロトタイプを手軽に開発することが可能になりましたと。
具体例としてブラウザで動作するテトリスのゲームを考えましょう。
従来であれば開発者はゲームのロジックやインターフェースを一から構築する必要がありましたが、
GPT-4を使用することでテトリスの基本ルールや機能を指定するだけで短時間でアプリケーションが生成されますと。
これによって開発者は独自の機能やデザインを追加するなど、より創造的な文化に集中することができます。
またGPT-4はブラウザで動作するアプリケーションを生成する際に、HTML、CSS、JavaScriptといった一般的なウェブ技術を活用してコードを生成してくれますと。
これによって生成されたコードは多くのデバイスやブラウザで互換性があり、開発者は追加の調整や最適化をほとんど行わずに済みます。
このようにGPT-4は簡易なアプリケーションの開発において開発者の作業負荷を大幅に軽減し、アイディアの実現がより迅速になることを示しています。
今後もGPT-4のような大規模言語モデルが進化し続けることで、ソフトウェア開発の効率化がより一層加速されることが期待されます。
続いて、使用に対するテストも機械がかけますというお話です。
使用に対するテストコードの作成も大規模言語モデルによって自動化されるようになりました。
これによって開発者はテストコードの作成にかかる手間を省き、品質の高いソフトウェアを効率的に開発できるようになります。
今後、エンドツーエンドテスト、E2Eテストも含め、大規模言語モデルと連携したテストコード生成が一般的になることが予想されます。
これによってアプリケーション全体の品質補償がより効率的に行えるようになります。
さらに、マルチモーダルモデルの発展によって、画面のスクリーンショットからテストケースを作成することも可能になるでしょう。
このような技術が実現すれば、開発者はユーザーインターフェースの変更に対しても迅速にテストコードを更新できるようになります。
また、将来的にはマルチモーダルモデルが実際のPC操作を行ってくれ、テストプロセスをより効率的に自動化することも考えられます。
09:05
このように、使用に対するテストコードの自動生成が進化することで、開発者は品質補償にかかる手間を軽減し、より効率的なソフトウェア開発が実現できるようになります。
大規模言語モデルやマルチモーダルモデルの進化に伴い、今後のソフトウェア開発において、これらの技術がますます重要な役割を果たすことが期待されます。
続きまして、ChatGPT Plusによりコード生成とエラー訂正です。
ChatGPT Plusはコード生成とエラー訂正のプロセスを自動化することで、ソフトウェア開発の効率を向上させています。
この技術を使えば、開発者はコーディングの煩雑な部分から解放され、より高度な課題や創造的な作業に注力できるようになります。
また、エラー訂正の自動化によりコードの品質も向上し、開発期間の短縮が期待できます。
ChatGPT Plusは実行可能なコードを指示に従って生成できる能力を持っています。
生成されたコードは少なくともある程度習熟した人のレベルに相当し、開発者が適切な指示を与えることで、効率的に非高品質なコードが生成されます。
これによって開発者はプロジェクトにおいてより重要な課題に集中できるようになります。
さらにChatGPT Plusは、実行時のエラーを検出し、修正案を提示する能力も持っています。
これにより開発者はエラー訂正にかかる時間を大幅に削減でき、プロジェクトの進行をスムーズに進めることができます。
組み合わせれば、エラーの原因となるコードを特定し、適正な修正案を提案することも可能です。
このようなChatGPT Plusを活用することで、コード生成とエラー訂正の自動化が実現され、ソフトウェア開発の効率化が一層促進されます。
開発者は従来のコーディング作業から解放され、より創造的で高度な課題に取り組むことができるようになるでしょう。
今後のソフトウェア開発においてChatGPT Plusのような技術は、ますます重要な役割を担っていくことが予想されます。
今のところ読んでいて、そうだなという感じですね。
続いて、エンジニアの面接の未来とコーディングテストより課題発見と方向付けの意思力という話ですね。
機械がコードを書く時代において、ソフトウェアエンジニアの面接では、従来のコーディングテストに代わって課題発見と方向付けの意思力が重視されるようになります。
開発者はより高度な思考だったり創造的なアプローチが求められ、問題解決能力やチームでの協力スキルが最重視されます。
これにより開発者の役割や単なる行動を書くことから、プロジェクト全体の戦略立案や意思決定により関与する方向へとシフトしていくでしょう。
大規模言語モデルがコーディングテストツールの試験問題をわずか3分で回答できるようになったことで、従来の評価基準が陳腐化していることが明らかになりました。
このような状況下では、面接の評価がより総合的なスキルに焦点を当てるべきであり、開発者がどのように問題に取り組むか、新しいアイデアをどのように生み出すかが重要な評価ポイントになります。
この流れは、そもそも開発ツールの中小化、クラウド化だったり様々なツールの登場から進んでいたが、今後さらに劇的に進むことが予想されます。
これに伴い開発者が直接コードを書くことの重要性は低下し、代わりにアイデアや方向性を与え適切な開発戦略を立てる能力では求められるようになるでしょう。
12:08
結果としてソフトウェアエンジニアの役割を変革を遂げ、機械と共同やチームでのコラボレーションがより重要になることが予想されます。
面接ではコーディングテストに代わり、課題発見と方向づけの意思力を評価することが開発者が今後の技術革新に適応するための課題となるでしょう。
プロンプト投げるとかもそうですし、その後出てきたソースコードを見て、それを良いコードか悪いコードなのかとか、それに対してバグがありそうかとか、使えるかどうかみたいな、
最終的に判断は人間がするっていうのは今の流れはまだ変わってないと思うので、もうちょっと技術力が求められる気はしますけどね。
とはいえ、いずれそれもなくなってくる可能性は多いにありますけど、今のところの制度っていうところですね、
生成されたコードの制度っていうところはまだ課題の余地が全然ありますので、まだまだ共同することは間違いないですけど、
エンジニアリングとしてのスキルっていうのは必要なんじゃないかなと思ってらっしゃいますね。
では続いて、我々が今書いているコードは定級言語になる。
このような状況では、リレーショナルデータベース自体の開発などと近い高度なタスクが求められるということが予想されます。
また、大規模言語モデルに適した技術スタックやプログラミング言語、開発ツールが増えていくことで、
開発者はこれらの新しい技術を活用し、プロジェクトの効率や品質を向上させることができるようになります。
これにより開発者の役割は、従来のコードを書くだけでなく、新しい技術を適切に選択し、効果的に活用するスキルというのが重要になります。
そうして、チャットGPTや大規模言語モデルによる変化というようなソフトウェア開発のプロセスを劇的に変えるとともに、
開発者の役割も大きく変わるということが予想されます。
今後はコードの細部にこだわるよりも、全体の戦略や方向性に注点を置いた開発というのが求められるでしょう。
これはソフトウェアエンジニアリングの新たな時代を迎えることを意味していますと言っています。
ビジネス観点とかそっちのほうですね、本来考えるべきところの観点を持ちながら、
ソフトウェアエンジニアリングをしなきゃいけないということになるんじゃないかなと思ったりしてますね。
あと気になっているのは、これによってですね、職業エンジニアかどうかというのがすごくはっきりするんだろうなと僕は思ったりしてます。
エンジニアリングとかコーディングが本当に好きな人っていうのは、そこからこれをどううまく活用するかとか、
それのためのツールを作ったりとか、さっきこの記事に出てきましたけど、
新しい言語モデル、プログラミング言語とか、そっちの開発をしたりとかですかね。
そっちの方にどんどんシフトしていく。結局はエンジニアリングをやろうとする人たちが増えていくんだろうと思いますけど、
そうじゃない人。とにかく仕事としてコードを書いていて、別にコードを書かなくてお金もらえるんだったら書かない方が楽だっていう人。
いわゆる職業エンジニアという方ですね。どんどんコードを書かないという方向にいくんじゃないかなと思っていて、
それが明確に分かれる気がしてます。さっき言ったエキスパートというのが、前者であるエンジニアリングが本当に好きな人たちというのが
エキスパートとしてゴンゴン開発していくことになるんだろうなというところですね。
それが良い悪いという意味ではなくて、そういう未来が来るんじゃないかなというのは僕の予想ですね。
予想というかほぼみなさんもおっしゃっているので、そうなるんだろうと思ったりしてますけど。
はい、という余談でした。最後まとめですね。
15:02
チャットGPTや大規模言語モデルによってソフトエンジニアリングの風景は大きく変わりつつあります。
コード生成やエラー訂正の自動化だったり、解説やテスト効能生成、そして面接プロセスとかプログラミング言語の変化というのが
開発者に新たなスキルやアプローチを求めるようになります。
これらの変化に適応し、創造的な思考や高度な課題解決能力を磨くことでソフトや開発者は未来の技術革新に貢献し続けることができるでしょうという言葉で
閉められておりました。はい、いかがだったでしょうかね。
すごく学びがたくさんあったというよりも、今の現状というところをきれいにまとめていただいたなというのがつくつく感じましたし、
共感の多い記事だったと思いますね。
今後の問題解決能力とか課題解決能力ですね。
課題をそもそも発見する能力もあるかもしれないですけど、
いわゆるソフトスキル的なところが求められるのは分かりやすく、はっきりするんだろうなと思ったりしてましたね。
とはいえどこまで進化していくかというのもありますし、
僕らがどうLLMとかと付き合っていくのかというところの話は全然行き続けると思うので、
今後ですね、僕らが今まで行動書くという行為があったんですけど、
その行動書くということそのものに対する見直しとか、
価値の聞き方とかっていうのが今後議論どんどんされていくんだろうなと思いますね。
結局書いているのはあなたではないですねって言うけど、
最終的にそれをシステムに落とし込んだり、最後ガチャンとまとめて動くようにするとかいう作業も、
最後は人が作業することになると思いますね。
さすがに機械にクレデンシャルとかを渡したり、シークレット情報を渡して、
システム環境変数も渡すので全部やってみたいな、インフラも構築してっていう、
未来が来る可能性はあるかもしれないですけど、
ちょっとまだ僕はそこ危険だなっていう感じはしているので、
そこはさすがに最後に人間がやるだろうなと思ったりしてます。
アプローチとかやり方とか手続き的なものを教えてもらうみたいなところで、
LLMを使うっていう流れがもうちょっと続くんじゃないかなと思ったりしますけどね。
でもそこまでやってしまったらもう本当に機械に全部頼ってしまうところなので、
エンジニアのそもそも存在価値がどうなんでしょうっていうところはあったりしますけど。
松本さんはエキスパーとか増えていくでしょうというところになったので、
そうすると僕がやっぱり気になっているのはエンジニアの価値そのものですね。
がやっぱり気になりますね。
つまりエンジニア単価は上がるのか下がるのかっていうところと、
エンジニアの見積もり構成とかでどうなっていくのかなっていうところですね。
一方で僕ら開発者がやっぱり今のところ大きく騒いでいる印象がすごく強いと思っています。
もしくは完全にビジネス側、営業側の人たちが資料作りのために使っているというところがあるんですけど、
その開発者とビジネスサイドの中間層にいる人たちも、
いわゆるプロジェクトマネージャーの人たちとかリードエンジニアみたいな人たちですね。
が、ちゃんとこういうLLMとかChatGBTみたいなAIをしっかり使って、
それがどれだけ有用で、どれだけエンジニアの工数を削減できるかみたいなところを理解できているかって結構ポイントだと思っています。
そういう人たちが結局見積もりをする現場が多いと思っているので、
そういう人たちがこれを使うと工数削減できると、
ちゃんと理解できているかどうかで出してくる見積もりが大きく変わってくるなと思ったりしていますので、
18:03
結果ちゃんと皆さん触りましょうっていうのは僕は思ったりします。
嫌いする方も全然いらっしゃるし、別にそれを否定する気は欠片もないです。
僕も使ってコードを書いたりしたことがあるんですけど、
それを書いたかどうかっていうのは書くの定義は置いておきますが、
正直楽しいかって言われると僕楽しくなかったんですよね。
やっぱり自分で考えつつも煮詰まったところで最後の一押しくれみたいなところでAIを使って、
なるほどこうやればいいとか、こういうアルゴリズムをはめればいいんだっていうところで頼っている感じがありますね。
でもやっぱり最後自分でものづくりをする、自分で書くこういうのが僕は楽しいと思ったりしているので、
でも仕事としては全然使うと思いますけどね。
そういう自分なりの付き合い方っていうのを皆さんも見ていただくのがいいと思っていますので、
その意味でも結局この流れは止まらないので、
まずは使ってみるというところですね。
食わず嫌いじゃないですけど、というところから入るのがいいのかなと思ったりしておりました。
そんなところで今日の朝活は終了したいと思います。
ちょっと時間短かったんですけど、スタートが遅れて申し訳なかったですね。
もう一本読もうと思っていた記事もあるんですけど、レイ・アイクさんの続きの記事ですね。
ことに向き合いトラストフルな組織を実現するためにというところですけど、
こちらはちょっと明日にしようかなと思ったりしています。
というところで今日はここで終了したいと思います。
本日の参加者はおそらく見えていないけど参加しているスーさんと高菜さんですね。
ご参加いただきありがとうございました。
また明日ものんびり読んでいきたいと思いますので、興味があれば参加してみてください。
じゃあ金曜日ですね。
今日も週末というところでしっかり締めて土日休んでいただければなと思います。
それでは終了します。お疲れ様でした。
