Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ymgc
July 26, 2023

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

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

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

ymgc

July 26, 2023
Tweet

More Decks by ymgc

Other Decks in Programming

Transcript

  1. 図書館LT
    ソフトウェア開発に
    ChatGPTは使えるのか?
    設計からコーディングまでAIの限界を探る

    View full-size slide

  2. 自己紹介

    やまぐち よしと

    ● SIer TIS株式会社 所属

    ● 〜2022 歩数計アプリのPdM

    ● 2023 〜 コーポレートエンジニア

    ○ 開発者体験(Developer Experience) 向上

    ■ ChatGPT Plusをよく使っている人

    ■ 「みんなでより良く使うには?」を考えている人


    View full-size slide

  3. 読む本
    ソフトウェア開発に携わる筆者がプロの目線で、ChatGPTの限界と利用方法を探りま
    す。


    (中略)

    ソフトウェア開発でその威力はすさまじく、プロが現場で使用する、UMLのクラス図や
    シーケンス図などソフトウェア設計にかかわるドキュメントをいとも簡単に生成しま
    す。データベースのER図もあっという間に出力します。プログラムコードの誤りも指摘
    し、さらによりよいコードにリファクタリングまでしてくれます。まさに人知を超えた存在
    です。

    でもこれは正しいコードで内容なのでしょうか。



    筆者の豊富な開発経験でChatGPTを多面的に試し、その有用性をつまびらかにして
    いきます。道具としてAIを活用するか、それともただ驚くだけか、本書は積極的に人
    工知能を活用するための手引きになるでしょう。

    View full-size slide

  4. こんな書式です!
    プロンプトの実例
    が載ってて便利!

    View full-size slide

  5. ざっくり感想
    - ユースケースごとにプロンプト例も載っているので、これからwith chatGPTでプログラミン
    グする方にオススメしたい本です。
    - 既にchatGPTでプログラミングされている方には?
    - 半分は知っている内容かも
    - 個別のユースケースに自分がしらない観点はあったのでそこは良かった(後述)
    - 一度は読んでおくと良いと思います
    - Agentのプロセス自動化については言及あるが、最新のCode Interpreterは未掲載
    - 出版以降の最新キャッチアップ情報は、gitに追記していくみたいです。要チェック
    - https://github.com/gamasenninn/gihyo-ChatGPT

    View full-size slide

  6. おはなしすること
    参考になった3つのポイント
    ①エラーが堂々巡りになる場合の対応策
    ②例外処理と論理完全性の改善
    ③TDD(テスト駆動型の開発)によるテストからの実装
    私感
    chatGPT +エンジニア が仕事の中で行っていくこと
    おまけ

    View full-size slide

  7. 参考になった3つのポイント

    View full-size slide

  8. ① エラーが堂々巡りになる場合の対応策

    View full-size slide

  9. ② 例外処理と論理完全性の改善

    View full-size slide

  10. ③TDD(テスト駆動型の開発)によるテストからの実装

    View full-size slide

  11. ③TDD(テスト駆動型の開発)によるテストからの実装

    View full-size slide

  12. おはなしすること
    参考になった3つのポイント
    ①エラーが堂々巡りになる場合の対応策
    ②例外処理と論理完全性の改善
    ③TDD(テスト駆動型の開発)によるテストからの実装
    私感
    chatGPT +エンジニア が仕事の中で行っていくこと  
     > 考え途中のことを書いてみます..
    おまけ

    View full-size slide

  13. > はじめに - (参考)転移学習とは
    元の学習が行われた領域またはデータセット
    この領域から学んだ知識やパターンは、新しい
    領域(ターゲットドメイン)に適用または「転送」
    されます。
    Source
    (既に持っている情報
    )
    Target
    (新たに実現したいもの
    )
    新しい問題領域を指します。
    この領域は、ソースドメインから学んだ知識を
    利用して学習を行います。
    転移学習
    => 人間の学習プロセスと基本的に同じ

    View full-size slide

  14. > 多くのエンジニアが仕事の中で行っていること
    ほとんどのエンジニアは全くのゼロから制作を行うシチュエーションはなく、参照されるソースがある。
    (PGMコードのみでなく情報全般を指す)
    経験豊富なエンジニアは、
    ・「全くのゼロから制作を行わない」が経験的に習慣づいている
    ・自身の中にストックがあり、外部環境からのソースの借り出し、検索にも秀でている
    ・解く課題・ソースの両方に対して、抽象化 /分解するスキルを備えているため、適用可能なソース数は格段に幅広い
    ・「環境条件に合わせて変更して利用」は、プログラミングの経験値そのものである
    経験が浅いエンジニアは、相対的にこれらの点が弱い。
    が、その点をサポートできれば同様の 生産性が発揮できる。
    参照できる「良質なソース」を確保できることは極めて重要である。
    Source
    (流用)
    Target
    (新規)
    環境条件に合わせて
    変更して利用

    View full-size slide

  15. > chatGPT +エンジニア が仕事の中で行っていくこと
    これまでと構造は変わらず。
    重要な変化点は、
    ①ChatGPTがあることで、「環境条件に合わせて利用」の微調整タスクが簡単になった
    ②その変化により、個人あたりが「活用できるソースのバリエーション」が格段に多くなった
       ex.このtech記事内のコードで行っていることを解説/コメント付記して。コードをjsコードからpythonに書き換えて     
    変わらず重要な点は、
    ・良質なソースをインプットにできれば、高い生産性が見込めること(chatGPTに参考情報として渡す)
    この点をサポートする社内環境をつくっていくことが、組織としての注力ポイントになります。
    Source
    (流用)
    Target
    (新規)
    環境条件に合わせて
    変更して利用
    +

    View full-size slide

  16. > 例. ソースを探して実装 with chatGPT
    Source
    Target
    例.外部のgetAPIをreqして取得したjsonをS3に配置する。
    配置の際にはyyyy¥mm¥ddのフォルダを作りつつ、jsonをgzip形式に変換して配置するpythonのlambda処理を流用したい。
    テナント数分getreq(lambda)を繰り返し実行を行うAWS Stepfunctionのステートの記述も流用したい。
    やりたいこと
    ソースを探す
    環境に合わせて
    変更する
    セルフレビュー
    する
    単体テストを
    書く
    稼働確認
    ネットで探す 過去の経験 GPTに聞く
    社内の
    コード資産を流用
    (稼働実績あり)
    知り合い
    に聞く
    リファクタリング /
    可読性向上
    エラー
    ハンドリング
    実行コード Wiki

    View full-size slide

  17. > 組織として 注力するポイントは
    Source
    Target
    例.外部のgetAPIをreqして取得したjsonをS3に配置する。
    配置の際にはyyyy¥mm¥ddのフォルダを作りつつ、jsonをgzip形式に変換して配置するpythonのlambda処理を流用したい。
    テナント数分getreq(lambda)を繰り返し実行を行うAWS Stepfunctionのステートの記述も流用したい。
    やりたいこと
    ソースを探す
    環境に合わせて
    変更する
    セルフレビュー
    する
    単体テストを
    書く
    稼働確認
    ネットで探す 過去の経験 GPTに聞く
    社内の
    コード資産を流用
    (稼働実績あり)
    知り合い
    に聞く
    リファクタリング /
    可読性向上
    エラー
    ハンドリング
    実行コード Wiki
    ①プロンプトレシピ
    各タスクセットごとのプロ
    ンプト例をクックブック化
    社内ナレッジに集約
    ②ソースレシピ
    「やりたいこと」と「稼働実
    績ありコード」をレシピ化
    やりたいことタグ- ソース
    の集積。
    検索性高を実現が必須

    View full-size slide

  18. > アウトプットイメージ
    ①プロンプトレシピ
    各タスクごとのプロンプト例をクックブック化
    社内ナレッジに集約
    事業企画
    アイデア検証工程
    テスト計画
    工程
    機能単体の製造 -UT
    工程
    見積もり
    工程



    リスク分析
    工程
    タスクセット別に
    同様のアウトプットを
    作成・公開していく
    テストケース作成
    工程

    View full-size slide

  19. AI駆動
    レベル
    名称 要求定義 要件定義 作業計画 設計 製造 テスト 品質評価 環境
    構築
    運用
    Lv.0 開発自動化なし
    Lv.1 開発支援
    Lv.2 部分的な開発の自動化
    Lv.3 条件付き開発自動化
    Lv.4 高度な開発自動化
    Lv.5 完全開発自動化 AI駆動開発(と呼ぶ部分)
    > AI駆動の2つの段階的アプローチ
    自動運転のLV定義に準え、こんな感じに定義できそう

    View full-size slide

  20. AI駆動
    レベル
    名称 要求定義 要件定義 作業計画 設計 製造 テスト 品質評価 環境
    構築
    運用
    Lv.0 開発自動化なし
    Lv.1 開発支援
    Lv.2 部分的な開発の自動化
    Lv.3 条件付き開発自動化
    Lv.4 高度な開発自動化
    Lv.5 完全開発自動化 AI駆動開発(と呼ぶ部分)
    ②タスクの連続実行性を高めるアプローチ
    ①単一タスクの精度を高めるアプローチ
    > AI駆動の2つの段階的アプローチ
    ①,②を順に行っていく

    View full-size slide

  21. > 自動生成の対象ブツの違い
    1/ OS/アプリ/サービスのソフトウェアを作っているエンジニア
    2/ データ・アナリストと呼ばれる人たち
    書いているソフトウェアそのものが「製品」であり「成果物」となる。
    汎用性とかメンテナンスのしやすさを重要視するし、出来るだけ再利用もする。
    DRY(Don't Repeat Yourself)の発想
    👉自動化する際には、
      OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの) 2つの最適化 が必要
    最終成果物は、「解析結果 (OUTCOME)」そのもの。
    データを解析するために書くプログラムは道具であり、
    だからこそ、アドホックなプログラミングに最適化されたJupytor Notebookを重用される
    (処理は直列で、単一実行の羅列)
    ・ソフトウェアに比べ、コード複雑度は微量。(階層の深さ、責務配置の分離などは少ない)
    ・処理性能が問題となることも稀 (非機能要求が顕在化してこない)
    ・OUTCOMEを得て以降の再利用は稀(流用新規される)

    View full-size slide

  22. > 自動生成の対象ブツの違い
    1/ OS/アプリ/サービスのソフトウェアを作っているエンジニア
    2/ データ・アナリストと呼ばれる人たち
    書いているソフトウェアそのものが「製品」であり「成果物」となる。
    汎用性とかメンテナンスのしやすさを重要視するし、出来るだけ再利用もする。
    DRY(Don't Repeat Yourself)の発想
    👉自動化する際には、
      OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの) 2つの最適化 が必要
    最終成果物は、「解析結果 (OUTCOME)」そのもの。
    データを解析するために書くプログラムは道具であり、
    だからこそ、アドホックなプログラミングに最適化されたJupytor Notebookを重用される
    (処理は直列で、単一実行の羅列)
    ・ソフトウェアに比べ、コード複雑度は微量。(階層の深さ、責務配置の分離などは少ない)
    ・処理性能が問題となることも稀 (非機能要求が顕在化してこない)
    ・OUTCOMEを得て以降の再利用は稀(流用新規される)
    僕らが 主に

    バリューを発揮す
    るところ

    現在

    AutoGPTなどで

    連続実行が実現
    されている領域


    View full-size slide

  23. 私感のまとめ
    - 「chatGPT +エンジニア が仕事の中で行っていくこと」を考えています
    - エンジニアがつくるプログラムコードには2つの最適化がいる
    - OUTPUT(プログラムコード自体) と OUTCOME(コードで実現されるもの)
    - この領域の自動化は、どう実現していくのか/していかないのか
    - 「ソースを探して実装 with chatGPT」という新プロセスが生まれている
    - 新プロセスに合致したサポート環境をつくっていくことが、組織の注力点
    - ①プロンプトレシピ と ②ソースレシピ

    View full-size slide

  24. さいごに - おまけ

    View full-size slide

  25. - 今回LTしたかった本(間に合わなかった..)
    -
    -
    プロジェクト管理についての学びがいっぱいあった
    AIについても言及が
    - 次回リベンジしたい

    View full-size slide

  26. 以上です!

    View full-size slide