AIフレンドリーなプロダクト開発を目指して 〜MCPを橋渡しにした環境移行〜

Transcript

1. AIフレンドリーなプロダクト開発を目指して 〜MCPを橋渡しにした環境移行〜 株式会社tacoms EM かがわ 2025/05/15 #さくらのAI Meetup vol.10「MCP」
2. ⾃⼰紹介 • 2025年2月に株式会社tacomsに入社 • アプリケーション開発部 EM • マネジメント専任でそろそろ9年 • 元々はBackend Engineer • ゲームと猫を愛でることが趣味 • アジャイルと向き合ってはや4年... 加川 申祐 (かがわ/@shinpr_p)
3. 01 コンテキスト: 前提となる会社・プロダクトの情報 About tacoms
6. 飲⾷業界のオンライン注⽂‧CRMをマルチプロダクトで⽀える 売上データ‧顧客データ‧商品データ‧外部API連携 注⽂ 管理 オンライ ン決済 店頭 Kiosk CTI / IVR 対⾯ 決済 デリバ リーPF 連携 POS 連携 店外 モバイル オーダー オープン API 店内 モバイル オーダー オンライン注⽂ 顧客 管理 セグメン ト分析 サブスク 管理 メルマガ / SMS プッシュ 通知 外部 CRM連携 クーポン 公式 アプリ ⾃社 ポイント ハウス カード CRM / マーケティング
7. つまり？ • 昨今の多分に漏れずマルチプロダクト化を推進している • 1プロダクトをみる1チームを目指している ◦ 小さくて自己管理されたチーム • やれることには限りがあるため、やるべきことにフォーカスしたい • AIを積極活用して生産性を爆上げしていく必要がある！ • 開発組織としてはDevinの活用を進めてはいるものの、開発プロセス にAIががっつり組み込まれているとはいえない。まだまだこれから... ◦ https://zenn.dev/tacoms/articles/efeb008ce810f3
8. 02 本題 Main Theme
9. アジェンダ • 既存のプロセスと課題 • AIフレンドリーな開発プロセスの目標 • MCPを用いた具体的な取り組み • 工夫したポイントと得られた効果
10. 既存のプロセスと課題 • 以前は仕様書を書いていた（らしい）が、現在はプロジェクト概要 として簡易的なビジネス要求と、バックログとしてタスクが管理さ れているだけ ◦ バックログのタスクも、ユーザーストーリー（PBI）になっていたり開発タ スク（SBI）になっていたりとまちまち • 「ドキュメントは全てNotionで！」ということで書かれてはいる ものの、更新が止まった古い情報だったりタスクとして分散して記 載されていたりしており、全容が把握できなくなっていた
11. 既存のプロセスと課題：既存の開発フロー • プレーンな開発フロー ◦ 必要最低限のアクティビティ ◦ 必要最低限なプロジェクト成果物 ◦ （技術的な意思決定はADRを用いて運用されている） • バックログは共通（同じNotion Database）だが、タスクの粒度はま ちまち
12. 既存のプロセスと課題：課題 • ドキュメントやアクティビティが最小限なので、誰にどういう価値を 届けたいのか？何を目的にやっているのか？がわかりづらいまま開発 が進んでしまう • タスクもドキュメントもNotion管理だが、NotionとAIの親和性はそこ まで高くなく、AI活用はDevinに一部開発をお願いする程度に留まっ ている ◦ （ﾍｲｼｬの問題）ドキュメントが構造化されておらず散乱している ◦ 共通のバックログにしたが故に、チーム都合に合わせてタスクページのプロパ ティが作られ、結果肥大化してしまっている ◦ Notionの検索精度がそれなりなのでMCP経由で期待した結果に辿り着けない ◦ NotionのBlockデータ構造になるとAIで解釈するには冗長
13. • ドキュメントをAIで活用しやすくする • ドキュメントのメンテナンスにAIを活用する ◦ メンテナンスコストを下げる ◦ 下がったコストをドキュメントやアクティビティの拡充に充て、開発の背景情 報を理解した開発が行えるようにする • プロダクトマネジメントにおけるAI活用を推進する ◦ ユーザージャーニーの定義 ◦ 簡易的なユーザビリティテストの実施 ◦ プロジェクト計画の作成・メンテナンスの自動化 AIフレンドリーな開発プロセスの目標
14. AIフレンドリーな開発プロセスの目標 • AIを活用した開発プロセスの全体イメージ ◦ 更新の手間を考え作られていなかったPRD（プロダクト要求仕様書）をユー ザーストーリーを元にAIで生成・更新するようにした ◦ 新しくユーザージャーニーをドキュメントに加えた。SRE(ing)文脈でCUJの作成 に活用。将来のSLI/SLOの設定にも繋げていきたい
15. MCPを用いた具体的な取り組み • Notionにあるユーザーストーリーをベースに ◦ Markdown形式のPRDを生成し、GitHubで管理する ◦ チームメンバーの情報とスプリントの進め方、ユーザーストーリーの見積もりを 前提に、プロジェクト計画（ガントチャート）を生成 ◦ PRDとNotionにある補足情報を元にユーザージャーニーを生成し、GitHubで管 理する ◦ ユーザージャーニーを元に、Figmaにあるデザインを使って簡易ユーザビリティ テストを実施する
16. MCPを用いた具体的な取り組み • Notionにあるユーザーストーリーをベースに ◦ Markdown形式のPRDを生成し、GitHubで管理する ◦ チームメンバーの情報とスプリントの進め方、ユーザーストーリーの見積もりを 前提に、プロジェクト計画（ガントチャート）を生成 ◦ PRDとNotionにある補足情報を元にユーザージャーニーを生成し、GitHubで管 理する ◦ ユーザージャーニーを元に、Figmaにあるデザインを使って簡易ユーザビリティ テストを実施する 今回はここの詳細、実例 を紹介します
17. MCPを用いた具体的な取り組み • Markdown形式のPRDを生成し、GitHubで管理する ◦ PRDをAI活用させていきたいため、Markdown形式にしてGitHub上で管理する ◦ GitHub管理にしたことで、日本語はtextlintで校正し、PRで人の目を介して変 更が反映できるようになった ◦ Project Rulesもリポジトリに含め、チームで育てていけるようにした（実際に ユーザージャーニーに関する .mdc は SREが更新してくれた） ◦ 将来の展望はあれどまだまだ開発チームに布教できていないので努力が必要
18. MCPを用いた具体的な取り組み . ├── .cursor/ │ └── rules/ │ ├── prd.mdc │ ├── router.mdc │ └── user-journey.mdc ├── .textlintrc ├── package.json ├── prh.yml ├── PRD/ │ ├── PRD_template.md │ └── camel-xxxx/ │ ├── images/ │ └── 機能A.md └── UserJourney/ ├── README.md ├── UserJourney_template.md └── camel-xxxx/ ├── README.md └── ペルソナA/ ディレクトリ構成 • Project Rules(.cursor/rules) ◦ ルールディスパッチャーと各成果物に対 応したルールの格納 • PRD ◦ PRDファイル生成先 ◦ UIはFigma MCPでpngを取得し、images 配下に格納 • UserJourney ◦ ユーザージャーニー生成先 ◦ ペルソナ毎にディレクトリを掘り、配下 にジャーニー単位のMarkdownを出力
19. 工夫したポイントと得られた効果 • 工夫１: リクエスト制御によるデータ量管理 ◦ Blockの情報量が多い、Notion databaseのページプロパティが多い（自業自得） ため、基本となるNotion APIのクエリをProject Rulesに定義した ◦ 作業時点ではそもそも Cursor 上でエラーが出て進まなかったが、5/14時点で動 作はするようになった。ただし生成精度が圧倒的に落ちる # Notionの使い方 - UserStoryを参照する際は、Backlogを検索するようにしてください - BacklogのデータベースIDは `xxxxxxxxxxxxxxxxx` です - フィルターは以下のように設定してください ``` "filter": { "and": [ { "property": "team", "select": { "equals": "xxxxxxx" } }, { "property": "Status", "status": { "does_not_equal": "Backlog" } } ] } ```
20. 工夫したポイントと得られた効果 • 工夫２: タスクの細分化と段階的実施 ◦ 一度に多くの作業をさせないようユーザーストーリーを5件ずつ取得させ、PRD ファイルを生成し、結果の確認を指示者に求めるようにした ◦ 内容に問題がなければ、APIのレスポンスにある next_cursor を使って次の5件 を取得し作業を継続するようにする。以下繰り返し ◦ 全ユーザーストーリー取得後、PRDファイル間の整合性や重複の検証を行わせる ◦ 生成の単位でタスク分解し、一度に多くの作業をさせないことが大事（プロダク ト開発みたいだ）
21. 工夫したポイントと得られた効果 • 工夫３: 段階的なAI活用 ◦ 既存の仕組みをいきなりスクラップ&ビルドせず、徐々にAIフレンドリーな状況 に寄せていくことが大切だと感じた ▪ 誰の作業も阻害せず、一部を代替することで抵抗なくプロセスに溶け込ませ ることができる ▪ その観点で、既存リソース（ﾍｲｼｬの場合Notion）と繋がることのできる MCPはとても有益だと感じた
22. 工夫したポイントと得られた効果 • 効果１: 新規プロダクト開発のフォーカス向上 ◦ ユーザーストーリーさえ作ればいいため、プロダクトマネジメント業務を削減で きた（ある程度固い見積もり、PRDの作成作業を削減） ◦ 逆に、先にユーザーストーリーを作り切る必要があったことで、開発着手する前 に全体像を把握でき、エンジニア全員がプロダクトローンチ時の完成イメージを 持つことができた（と執筆時点で実施したレトロスペクティブで聞いた） • 効果２: GitHubへの集約が加速しつつある ◦ PRDなどの仕様群がGitHubへ移行できる筋道ができたことから、それならプロ ジェクト管理をNotionでする旨みはないのでは？という疑問が生まれ、プロジェ クト管理もGitHub Projectsへの移行が進んでいる
23. まとめ • MCPを活用すれば開発チームの既存資産（Notionなど）に容易にアクセ スできるため、開発プロセスに無理なくAIを取り入れることが可能 • 現時点でAIが活用しやすいドキュメントフォーマットはMarkdownなの で、ドキュメントをMarkdown形式にしていくメリットは大きい ◦ かつ、GitHubなど、コードに近いところにドキュメントが置かれることが望まし い ◦ 既存資産をMarkdownにしていく際は、得てしてデータ量が多いはずなので、コン テキストウィンドウに収まるように、取得する際の工夫や生成タスクを細分化する などの工夫が必要