developers summit 2024というイベントで講演を聴いてきたので、自分用のメモ目的でまとめます
Developers Summit 2024

1日目の分はこちら
https://techblog.ponponpopon.com/developers-summit-2024-01

セッションごとの感想

ChatGPTを使って開発生産性を10倍あげる方法

一言で言うと、ChatGPTの効率的な使い方開発を高速に行うための 使い方。

関連資料: ChatGPTを使って開発生産性を10倍あげる方法 – Promptのチカラを知る –

• 添削をさせる場合は、改善点を示させる
• メールからタスク遂行に必要な項目を抽出する
• LLMで文章を生成させる場合、音声入力は相性が良い
  • 音声入力で誤入力が発生するが、誤ったまま入力しても大方よしなに解釈されるため。
• 余談）ChatGPTを使うサービスを作るなら、ユーザに文字入力などさせないのが良い
  • させるとしても、高々コピペで収めるべし
• 開発の手順
  • 要件
  • システム構成
  • データモデル
  • サンプルデータ
  • 最後に全てのファイルをダウンロードできるように指示を出す
    • code interpreterのおかげでうまくできる
  • 論理レイヤー以外はChatGPTに任せられる
• インプットのトークン数が増えるとノイズは大きくなる。音声入力をするとこのノイズが大きく発生しがち。
• 開発の構成要素の多くはテキストで管理できるようになっているので、十分ChatGPTで制作することができる

感想

• chatgptの効率的な使い方に関してはいろんな記事があったが特に音声入力をすると良いというのが収穫だった
• オフィスソフトを使う人、特にスライドを作成する人にとっては思いませんね非常に効率的だと思う
• bing copilotは、ChatGPTなどと比べて、使い心地が大変良いと思う

Elasticが目指す生成AI 活用の将来像

一言で言うと、生成AI系システムにおけるElasticの使い方の話

• RAGにおける検索エンジンの話
• RAGにおいて社内データからコンテキストを抽出するステップが必要になるが、ここにはelasticの検索エンジンが使える(ESREというのを使う)
• 実はelasticにはweb crawlerも存在する

感想

• 生成AIを使って必要な情報を得られるようになって以降、検索エンジンは単に欲しい情報を取得することに使う機会は減りそう（なくなりそう）
• 検索エンジンはRAGの構成において一つの部品を担っていて、検索エンジンを作る側の人たちはその需要に合わせた発展を目指していくのでしょう。
• RAGというシステムがどういう展開をするのか自体も気になるところ
  • MuRAGの次はどうなるのか。

GitHub Copilotは開発者の生産性をどれだけ上げるのか？ ZOZOでの全社導入とその効果

一言で言うと、社内にGitHub Copilotを導入するにあたっての費用対効果・リスクの検討と、導入後の効果の話

関連資料: GitHub Copilotは開発者の生産性をどれだけ上げるのか？ZOZOでの全社導入とその効果

• 費用対効果に関しての検討は当然する
• リスク （脆弱性の混入・社会への機密情報流出・ライセンス侵害）に関しても丁寧に検討されていた点が良かった
• Copilotを最も有効に活用していたのは ML を扱う Python エンジニア
  • 勉強会を開いたりしてた
  • 生成AIへの興味が強いメンバーだった

感想

• 評価の過程が非常に丁寧で、一般的な評価の場面に参考になりそう

マルチモーダルRAGの社会実装への技術アプローチ

一言で言うと、MuRAGの技術的な解説とAssistant AIとの関係の話

• MuRAG (Multimodal RAG)は、テキストだけでなく表・画像・動画等のデータも同等に扱うRAG
• Assistant APIは便利だが、課題はある
• 評価の際には、参照あり/参照無しのいずれかがある
  • 参照とは、「入力の中のいずれの画像・表などから知識を獲得するか」の情報である。

感想

• マルチモーダル対応のための技術の発展について整理されていてよかった
• 参照ありの方が参照無しの場合より精度が下がる場合があるらしいが、原因は気になるところ。

探索型のプロダクト開発を始めよう～正しいものを正しくつくる2.0～

一言で言うと、カイゼンを進める際の考えかたについての話

↑アウトカムと収益の違い、ソフトウェア開発とプロダクト開発の違い、考え方のイメージ

• プロダクト開発とソフトウェア開発は異なる
• プロダクトオーナーと開発チームはいがみ合いがち
• 収益は、その後のプロダクト作りの動力源になるものである。
  • 収益を大きくしようと努めるのは必要
• ユーザーに対するアウトカムの改善が、収益の向上につながるまでには遅延がある。
  • ユーザーのアウトカムを追求するのが良いがこれは収益とは見て非なるものである
  • 収益をKPIに据えるのは、バックミラーを見ながら運転するようなものである。
• チームとプロダクトの両方を健全に保つことを目指すべき
• 仮説を立てるためには調査が必要になる。悩んでいるだけでは出ない
  • 進めなければ変化は起きない。
    • 最適な方法の検討には終わりがない（最適化の罠）
• まず探索のためのバックログを一つ持とう

感想

• 業務においては、どのような状態を目指すかは常に意識しておくべき。
• 収益は当然目指すべき指標と思っていたが、遅延については確かに意識を持っておくべきだと思った。

製造業におけるAWSを用いたリファレンスアーキテクチャの構築と実プロジェクトへの適応

一言で言うと、社内でのシステムのAWS移行を行なった際の振り返りの話

• 事業チームのデータ基盤をAWSで構成した
• ドメイン理解が大変だった
• 事業部横断で共用できる汎用性の高いテンプレートを作ろうとしたが、事業ごとに必要な仕様が異なることなどから難しかった
• 社内でAWSの学習するコミュニティーを立ち上げ進行している

感想

• メーカーでのAWS化の取り組みを聞ける場面は少ないので興味深かった
• 当然社内でのノウハウの少ない挑戦的なタスクのように思われたが、丁寧に対処し価値が生まれているように思われた
• 組織全体でのAWSの理解を進める取り組みなどは、有意義に感じられるし、かっこいい。

生成AIで開発生産性向上！リレーセッション

一言で言うと、生成AIの活用事例の紹介
以下、個人的に特に好きだった「生成AI を使った命名のプロセス」のみについて記載

• 命名は大変
• 以下の手順で対応するのが良さそう
  • 名前を提案してもらう
  • 提案してもらった名前から逆に概念を説明してもらう
  • 考慮が漏れていた役割について補足して命名をブラッシュアップする

感想

• chatGPTに提案してもらう使い方はよくしていたが、逆に概念を説明させるのはやったことがなかった
• 説明をさせるということは、「周辺のコンテキストが未知の状況で、関数や変数の役割を推測させる」ことなので、これが上手くいくなら良い命名であると判断するのは合理的だと思われた