「DeNA × AI Talks #2 - エンジニアのための、AIツール導入・活用最前線 -」に参加してきました

PocochaのAI駆動開発推進体制

yugo.matsudaさん

yuki.hirakoさん

全社ビジョンを自部門へ翻訳して現場へ
- DeNAのAIオールインの宣言
- これをすると何が嬉しいのか自分の言葉に落とし込んで伝える
- 運用でカバーしてきた業務が多くあった
  - 仕組み化するにもリソースが必要
ムーブメントの起こし方
- ホットスポットを作る
ツールのガバナンスとスピード
- トライアルフェーズ
  - 法務/セキュリティと並行して使い始めてしまう
- 利用フェーズ
  - トライアル中に確認が済んでるのですぐに利用開始できる
バリューストリーム全体を見た上での効率化
- コードを書くはやさだけ見てもだめ
- 外的負荷の影響
- 職種をまたぐ場面に多い
バリューストリームの最適化
- 設計の一次情報を共有知化
  - エンジニアしか知らないという状況の解消
- Devin
  - ローカルで個別最適化ではなく誰かが最適化したものを共有できる
  - slackやwebから使えるから職種問わず使いやすい

tamotsu.kurokiさん

要求をコードにするまでの情報
- 共有知化するのが難しい
- ドキュメントを作ったとしてもメンテするのが難しい
- 何か残したとしてみそれだけ作ってもなと
- 属人化による課題
- AI活用の阻害
人もAIも理解可能な実装設計図
- ドメインモデリングの仕様など全てgit管理するようにした
- AI活用のプロセスとあわせてまとめることで手順もまとまる
- コードと同じリポジトリに
作業の流れ
- PRD(要求)と既存コード -> ユーザーストーリー(受け入れ条件)
  - ユーザーストーリーのフォーマットを用意してそれに従って出力させる
- ユーザーストーリー -> 用語集
  - ドメイン/システム/エンジニア用語など
  - 英語名とかも
- ユーザーストーリーと用語集+α -> ドメインモデル
  - mermaidでのサンプルを渡して同じようなものを出力させる
    - クラスとフィールドのような感じ
    - バリデーション的な要件も
  - 制約や説明も出させる
- ユーザーストーリーとドメインモデル -> データの整合性確認と変化例
  - ユーザーストーリーとドメインモデルを比べて過不足をチェックさせる
  - 受け入れ条件のGivenとThenのデータ定義
    - 正常系/異常系とかも

hiroshi.onoderaさん

AIコーディング
- AIとのペアプロに似たような感覚
  - やりたいことを共有
  - 相手のコードを確認
  - 意図や意見を伝えたり
- ペアプロの知見を活用するといいのでは
ペアプロと同じ効果が出そうなこと
- 会話することによる思考整理
  - プロンプトに書くことで自分も整理される
- 可読性や保守性の向上
  - AI向けのルールを整備したり
- 結果だけでなく過程から学ぶ
  - AI相手だとそのスピードが上がる
AIコーディングするときのコツ
- ルール設定として勝手に判断して動くことを制限して進める
  - ペアプロのように対話的に進められるように
- タスクを共有して計画して対話的に進める