プロダクト筋トレ図書館LT「ソフトウェア開発にChatGPTは使えるのか？」

プロダクト筋トレ図書館LT「ソフトウェア開発にChatGPTは使えるのか？」
プロダクト筋トレとは
https://www.productkintore.org/

ソフトウェア開発にChatGPTは使えるのか？ ――設計からコーディングまでAIの限界を探る
https://gihyo.jp/book/2023/978-4-297-13615-4

Transcript

1. 図書館LT ソフトウェア開発に ChatGPTは使えるのか？ 設計からコーディングまでAIの限界を探る
2. 自己紹介
 やまぐち よしと
 • SIer TIS株式会社 所属
 • 〜2022 歩数計アプリのPdM
 • 2023 〜 コーポレートエンジニア
 ◦ 開発者体験(Developer Experience) 向上
 ▪ ChatGPT Plusをよく使っている人
 ▪ 「みんなでより良く使うには？」を考えている人

3. 読む本 ソフトウェア開発に携わる筆者がプロの目線で、ChatGPTの限界と利用方法を探りま す。
 
 (中略)
 ソフトウェア開発でその威力はすさまじく、プロが現場で使用する、UMLのクラス図や シーケンス図などソフトウェア設計にかかわるドキュメントをいとも簡単に生成しま す。データベースのER図もあっという間に出力します。プログラムコードの誤りも指摘 し、さらによりよいコードにリファクタリングまでしてくれます。まさに人知を超えた存在 です。
 でもこれは正しいコードで内容なのでしょうか。
 
 
 筆者の豊富な開発経験でChatGPTを多面的に試し、その有用性をつまびらかにして いきます。道具としてAIを活用するか、それともただ驚くだけか、本書は積極的に人 工知能を活用するための手引きになるでしょう。
4. 目次
5. こんな書式です！ プロンプトの実例 が載ってて便利！
6. ざっくり感想 - ユースケースごとにプロンプト例も載っているので、これからwith chatGPTでプログラミン グする方にオススメしたい本です。 - 既にchatGPTでプログラミングされている方には？ - 半分は知っている内容かも - 個別のユースケースに自分がしらない観点はあったのでそこは良かった(後述) - 一度は読んでおくと良いと思います - Agentのプロセス自動化については言及あるが、最新のCode Interpreterは未掲載 - 出版以降の最新キャッチアップ情報は、gitに追記していくみたいです。要チェック - https://github.com/gamasenninn/gihyo-ChatGPT
7. おはなしすること 参考になった３つのポイント ①エラーが堂々巡りになる場合の対応策 ②例外処理と論理完全性の改善 ③TDD（テスト駆動型の開発）によるテストからの実装 私感 chatGPT +エンジニア が仕事の中で行っていくこと おまけ
8. 参考になった３つのポイント
9. ① エラーが堂々巡りになる場合の対応策
10. ② 例外処理と論理完全性の改善
11. ③TDD（テスト駆動型の開発）によるテストからの実装
12. ③TDD（テスト駆動型の開発）によるテストからの実装
13. おはなしすること 参考になった３つのポイント ①エラーが堂々巡りになる場合の対応策 ②例外処理と論理完全性の改善 ③TDD（テスト駆動型の開発）によるテストからの実装 私感 chatGPT +エンジニア が仕事の中で行っていくこと　　 　> 考え途中のことを書いてみます.. おまけ
14. > はじめに - (参考)転移学習とは 元の学習が行われた領域またはデータセット この領域から学んだ知識やパターンは、新しい 領域（ターゲットドメイン）に適用または「転送」 されます。 Source (既に持っている情報 ) Target (新たに実現したいもの ) 新しい問題領域を指します。 この領域は、ソースドメインから学んだ知識を 利用して学習を行います。 転移学習 => 人間の学習プロセスと基本的に同じ
15. > 多くのエンジニアが仕事の中で行っていること ほとんどのエンジニアは全くのゼロから制作を行うシチュエーションはなく、参照されるソースがある。 (PGMコードのみでなく情報全般を指す) 経験豊富なエンジニアは、 ・「全くのゼロから制作を行わない」が経験的に習慣づいている ・自身の中にストックがあり、外部環境からのソースの借り出し、検索にも秀でている ・解く課題・ソースの両方に対して、抽象化 /分解するスキルを備えているため、適用可能なソース数は格段に幅広い ・「環境条件に合わせて変更して利用」は、プログラミングの経験値そのものである 経験が浅いエンジニアは、相対的にこれらの点が弱い。 が、その点をサポートできれば同様の 生産性が発揮できる。 参照できる「良質なソース」を確保できることは極めて重要である。 Source (流用) Target (新規) 環境条件に合わせて 変更して利用
16. > chatGPT +エンジニア が仕事の中で行っていくこと これまでと構造は変わらず。 重要な変化点は、 ①ChatGPTがあることで、「環境条件に合わせて利用」の微調整タスクが簡単になった ②その変化により、個人あたりが「活用できるソースのバリエーション」が格段に多くなった 　　 ex.このtech記事内のコードで行っていることを解説/コメント付記して。コードをjsコードからpythonに書き換えて　　　　　 変わらず重要な点は、 ・良質なソースをインプットにできれば、高い生産性が見込めること（chatGPTに参考情報として渡す） この点をサポートする社内環境をつくっていくことが、組織としての注力ポイントになります。 Source (流用) Target (新規) 環境条件に合わせて 変更して利用 +
17. > 例. ソースを探して実装 with chatGPT Source Target 例.外部のgetAPIをreqして取得したjsonをS3に配置する。 配置の際にはyyyy¥mm¥ddのフォルダを作りつつ、jsonをgzip形式に変換して配置するpythonのlambda処理を流用したい。 テナント数分getreq(lambda)を繰り返し実行を行うAWS Stepfunctionのステートの記述も流用したい。 やりたいこと ソースを探す 環境に合わせて 変更する セルフレビュー する 単体テストを 書く 稼働確認 ネットで探す 過去の経験 GPTに聞く 社内の コード資産を流用 (稼働実績あり) 知り合い に聞く リファクタリング / 可読性向上 エラー ハンドリング 実行コード Wiki
18. > 組織として 注力するポイントは Source Target 例.外部のgetAPIをreqして取得したjsonをS3に配置する。 配置の際にはyyyy¥mm¥ddのフォルダを作りつつ、jsonをgzip形式に変換して配置するpythonのlambda処理を流用したい。 テナント数分getreq(lambda)を繰り返し実行を行うAWS Stepfunctionのステートの記述も流用したい。 やりたいこと ソースを探す 環境に合わせて 変更する セルフレビュー する 単体テストを 書く 稼働確認 ネットで探す 過去の経験 GPTに聞く 社内の コード資産を流用 (稼働実績あり) 知り合い に聞く リファクタリング / 可読性向上 エラー ハンドリング 実行コード Wiki ①プロンプトレシピ 各タスクセットごとのプロ ンプト例をクックブック化 社内ナレッジに集約 ②ソースレシピ 「やりたいこと」と「稼働実 績ありコード」をレシピ化 やりたいことタグ- ソース の集積。 検索性高を実現が必須
19. > アウトプットイメージ ①プロンプトレシピ 各タスクごとのプロンプト例をクックブック化 社内ナレッジに集約 事業企画 アイデア検証工程 テスト計画 工程 機能単体の製造 -UT 工程 見積もり 工程 ・ ・ ・ リスク分析 工程 タスクセット別に 同様のアウトプットを 作成・公開していく テストケース作成 工程
20. AI駆動 レベル 名称 要求定義 要件定義 作業計画 設計 製造 テスト 品質評価 環境 構築 運用 Lv.0 開発自動化なし Lv.1 開発支援 Lv.2 部分的な開発の自動化 Lv.3 条件付き開発自動化 Lv.4 高度な開発自動化 Lv.5 完全開発自動化 AI駆動開発(と呼ぶ部分) > AI駆動の２つの段階的アプローチ 自動運転のLV定義に準え、こんな感じに定義できそう
21. AI駆動 レベル 名称 要求定義 要件定義 作業計画 設計 製造 テスト 品質評価 環境 構築 運用 Lv.0 開発自動化なし Lv.1 開発支援 Lv.2 部分的な開発の自動化 Lv.3 条件付き開発自動化 Lv.4 高度な開発自動化 Lv.5 完全開発自動化 AI駆動開発(と呼ぶ部分) ②タスクの連続実行性を高めるアプローチ ①単一タスクの精度を高めるアプローチ > AI駆動の２つの段階的アプローチ ①,②を順に行っていく
22. > 自動生成の対象ブツの違い 1/ OS/アプリ/サービスのソフトウェアを作っているエンジニア 2/ データ・アナリストと呼ばれる人たち 書いているソフトウェアそのものが「製品」であり「成果物」となる。 汎用性とかメンテナンスのしやすさを重要視するし、出来るだけ再利用もする。 DRY(Don't Repeat Yourself)の発想 👉自動化する際には、 　 OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの) ２つの最適化 が必要 最終成果物は、「解析結果 (OUTCOME)」そのもの。 データを解析するために書くプログラムは道具であり、 だからこそ、アドホックなプログラミングに最適化されたJupytor Notebookを重用される （処理は直列で、単一実行の羅列） ・ソフトウェアに比べ、コード複雑度は微量。（階層の深さ、責務配置の分離などは少ない） ・処理性能が問題となることも稀 (非機能要求が顕在化してこない) ・OUTCOMEを得て以降の再利用は稀（流用新規される）
23. > 自動生成の対象ブツの違い 1/ OS/アプリ/サービスのソフトウェアを作っているエンジニア 2/ データ・アナリストと呼ばれる人たち 書いているソフトウェアそのものが「製品」であり「成果物」となる。 汎用性とかメンテナンスのしやすさを重要視するし、出来るだけ再利用もする。 DRY(Don't Repeat Yourself)の発想 👉自動化する際には、 　 OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの) ２つの最適化 が必要 最終成果物は、「解析結果 (OUTCOME)」そのもの。 データを解析するために書くプログラムは道具であり、 だからこそ、アドホックなプログラミングに最適化されたJupytor Notebookを重用される （処理は直列で、単一実行の羅列） ・ソフトウェアに比べ、コード複雑度は微量。（階層の深さ、責務配置の分離などは少ない） ・処理性能が問題となることも稀 (非機能要求が顕在化してこない) ・OUTCOMEを得て以降の再利用は稀（流用新規される） 僕らが 主に
 バリューを発揮す るところ
 現在
 AutoGPTなどで
 連続実行が実現 されている領域

24. 私感のまとめ - 「chatGPT +エンジニア が仕事の中で行っていくこと」を考えています - エンジニアがつくるプログラムコードには２つの最適化がいる - OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの) - この領域の自動化は、どう実現していくのか/していかないのか - 「ソースを探して実装 with chatGPT」という新プロセスが生まれている - 新プロセスに合致したサポート環境をつくっていくことが、組織の注力点 - ①プロンプトレシピ　と　②ソースレシピ
25. さいごに - おまけ
26. - 今回LTしたかった本(間に合わなかった..) - - プロジェクト管理についての学びがいっぱいあった AIについても言及が - 次回リベンジしたい
28. 以上です！