困難は分割せよ。既存のサービスにナレッジベースなAI駆動開発を導入していくための一つの方略

生成AIを活用した開発が注目を集める一方で、企業や開発現場では「どこから手をつけてよいかわからない」「プロダクトにうまく浸透しない」といった課題が多く見られます。本プレゼンテーションでは、既存のサービスやモノリスなシステムに対し、“困難を分割”することでAI導入をスムーズに進める実践的なアプローチを紹介します。

「箱庭」のような小さな成功体験を積み上げることで、チーム内にAI駆動開発の文化を育てていく道筋を示し、ナレッジベースな開発プロセスの構築や、ドキュメント生成、ペアプロでのAI活用など、実例を交えて具体的な方法論を共有します。

プロダクト成熟度とAIの関与度の関係性や、ADKARモデルを用いたチェンジマネジメントの視点も取り入れながら、AI活用を「劇的な変化」ではなく、「小さな分割からの変化」として提案する本セッションは、これからAIを組織に導入していきたいリーダー層にとっての指針となる内容です。

Transcript

1. 困難は分割せよ。 既存のサービスにナレッジベースなAI駆動開発を導入していくための一つの方略
2. 山本隼汰（やまもとはやた） Tied株式会社 代表取締役 好きなこと/も% # 散A # 動物全G # 会社四季報・業界地図
3. 以下のようなお話をいたしますC @A 私たちがやっている課題解決の方法のご紹% )A 課題解決の中で得られてきたインサイトの共 "A どのようにAI駆動開発を自分たちの開発チームに浸透させていくか 本日お話しすること
4. dC 生成AI自体の利用イメージを十分に掴めておらずどのような活用ができるか不g dC 事例を提供したり、具体的な活用シーンを理解する必要があu ‘C 生成AI含む、AIを活用したプロダクトや機能を十分に出せていなU dC 単にやっているだけ、もしくは十分に付加価値づくりに時間をかけれていなU tC AI使った開発プロセスは個々人で使っているものの、開発プロセスとして浸透していかなU dC 結果としてAIを活用した開発の効果を感じづらくなってしまう AIに関連して多くの企業が抱えている課題
5. y€ 生成AI自体の利用イメージを十分に掴めておらずどのような活用ができるか不5 3€ 事例を提供したり、具体的な活用シーンを理解する必要があE q€ 3€ 単にやっているだけ、もしくは十分に付加価値づくりに時間をかけれていな) C€ 3€ 結果としてAIを活用した開発の効果を感じづらくなってしまう 生成AI含む、AIを活用したプロダクトや機能を十分に出せていな) AI使った開発プロセスは個々人で使っているものの、開発プロセスとして浸透していかな) 今日は、この二つを同時に解決しているケースの話をしていきます 我々がやっていること
6. こんなケースでV s プロダクトになにがしかのAIを使った機能を提供してい9 s AIの機能はプロダクトの1機能として開発されている（モノリス% s AIに関する専門性を有した人は少ないが、AIに対する機能要望が多H s プロダクトの他の機能も必要とされており優先度を上げきれていなH s 結果、AIの機能改善が円滑に進まない状況が起きている これらを、
 ナレッジを蓄積しながらサービス分割を行い、AIの機能を切り出すことによって解決しています 同時に二つの課題を解決するケース
7. プログラム 開発者 お渡し AI Agents クライアント ドキュメント 等 イメージ
8. 移行モデル 我々 プログラム クライアント AI Agents ドキュメント 等 プログラム クライアント AI Agents ドキュメント 等 立ち上げ
 （1~3ヶ月ほど） 移行・伴走
 （3~6ヶ月ほど） 自走 クライアント プログラム 我々 AI Agents ドキュメント 等 必要であれば
 他の立ち上げを推進
9. シンプルに以下のような手順で進めま¤ mŸ 分割する対象の機能や領域、影響範囲の特定を特定す˜ wv なるべく分割することによってメリットが出る機能やサービスを選d ‚Ÿ 機能に必要なスペックなどを確認し、ある程度の要件をまとめてコードに追I wv rules のディレクトリや README など状況に合わせて少し過剰でも良いので追o v 機能が複数ある場合は整理しながら進めh Ÿ それらの機能をAI駆動に一気に開発してしま« wv 基本、AIとペアプロしたり一部タスクを任せたりしてガッと作り切りま v PR Agentも活用しレビュー自体も効率化していく どのようにやるか
10. ‍ ️ コードのドキュメントは AI に書かせる すでに書いてしまったコードは、AIに解釈させてみよう 概ね理解してくれると思うが、設計意図が反映されていない場合は フィードバックを重ねていくことで理解度を深めてあげるとよい
 手s g‡ Chat画面や Devin のUIなどを開いてドキュメントを書かせ˜ ‚‡ 作成されてきたドキュメントが設計意図を反映しているか確X ‡ 問題なければ採用してエディタが読めるルールに追7 ‰‡ 問題があれば、改善を促して再度チェック ※コーディングガイドラインなど方針や設計に関わる部分もそうだ が、コード中のコメントなどもこの方法で書かせてもよい
11. ‍ 一人で開発しない イシューやタスクなどを最初からAIに投げ込んでおき、 調査や対応方針の検討を一緒に検討していく 手‚ f… GitHub など MCPサーバーのセットアッm |… すでに作成している Issue などのリンクを送a x… ディスカッションを初めて、対応方針を決めていw B… （割り込みが入ったら）議論をやめてそちらに集中すR 8… 対応が一定完了したらAIにドキュメントを書かせる ※スタートアップなど忙しい時ほど重要 コンテキストスイッチが起きるので 自分の脳内に余計な記憶を残さないために重要
12. AIを使い分ける（できる場合） Chat 形式でインタラクティブにやり取りできるものと
 Devin のように async で動くものを適宜使い分ける。 できる限り、思い出した時に思い出した内容を依頼しておいて
 後からまたキャッチアップするのがベスト
 （重要だが緊急ではないことがほとんどなので） 手E dˆ Chat 形式で AI と開発したいものをやり取りす‚ 7ˆ その途中で出てきた「そういえば」タスクを async に依i –ˆ Chat でのやりとりに戻り、解決すべきタスクを終わらせ‚ zˆ タスクが終わったら、非同期で作成された PR を確認する
13. クライアント企業にとって以下のような背景があり意思決定がスムーズだからで| † 機能の開発自体がバリューに紐付きやすh g 主に、トップラインに影響が出やすいので意思決定がしやすª g コストサイドへのインパクトだと、規模が小さい時にはインパクトを感じづらª † PoCや初期機能は出せても、それ以降は異なる専門性が必C g 専門性を分けることでエンジニアが比較優位を意識しやすª g その上、分けられていることで分業できているありがたさを感じれ8 † 一方で、提供する機能や作られるリソースはある程度シンプルにできるため受け入れやすh g B/GデプロイなどもAI機能の提供においては多用するのでミスった時の安心材料もある なぜこのような進め方をしているのか
14. ² プロダクトがモノリスな場¡ n バックログを物理的に分割でき、出口も分けられるのでバリューストリームを最適化でき n 結果、半年間右往左往していた機能が、約1人月で解決するようになる、なd ² 経営陣やリーダーがAI駆動開発に積極的だが、メンバーが追従しきれていない場¡ n 分割して提供した新しいプロダクト自体がケーススタディとな n キャッチアップをしたり、具体的な開発プロセスに慣れることで価値を感じやすw n 実際に作成した人が伴走することによって考え方を移植でき ² 外部依存へのリスク軽¤ n 少なくともシステムに関してはドキュメントなどに必要な情報は組み込まれ n 引き継いだときにAIと会話することで従来よりもキャッチアップが容易に 具体的にどのような効果があるのか
15. そもそも...
16. AI駆動開発とバリューストリーム AI駆動開発において意識するべきは プロセスの効率化ではなく ️ バリューストリームをいかに短縮させるか であって、既存の開発プロセスの延長線上にはない 必要とされているのは劇的な変更
17. プロダクト成熟度とAI関与度の仮説 プロダクトが成熟してくると以下のようなことが起きy b 説明責任を果たすため人間の関与が増えy b プロダクト自体が大きくなり複雑度が増 b 既存のフローがあり、変更に対して柔軟さがなくなy b 一つの機能がプロダクト全体に与えるインパクトが相対 的に減少する 結果的に、
 AIを活用してもいまいち旨味を感じにくい事態が起きる 注）上図は仮説を可視化したものであり、統計データではありません
18. ADKARによるチェンジマネジメント ™ Awareness: 変化の必要性に気づj ™ Desire: 変化を作るのに参加したいと思V ™ Knowledge: 必要な知識を提供すy ™ Ability: 必要なスキルや振る舞いができるようにすy ™ Reinforcement: 変化を維持する 引用）
 ADKAR モデルは、
 チェンジマネジメント資格認定プログラムである Prosci によって開発されました。
 https://www.prosci.com/methodology/adkar
19. ADKARによるチェンジマネジメント ™ Awareness: 変化の必要性に気づj ™ Desire: 変化を作るのに参加したいと思V ™ Knowledge: 必要な知識を提供すy ™ Ability: 必要なスキルや振る舞いができるようにすy ™ Reinforcement: 変化を維持する 引用）
 ADKAR モデルは、
 チェンジマネジメント資格認定プログラムである Prosci によって開発されました。
 https://www.prosci.com/methodology/adkar この全てを順番にやると
 時間がかかって仕方がない！！ （重要だけども...）
20. 困難は分割し、箱庭を作りましょう AI駆動開発を導入する際¡ †g 既存のプロセスに大胆に導入しようとはしなa wl サブシステムをAI駆動で分割してみるのはどうでしょうz ’l AI機能をAIで作るというのは乙なものでs ©g AI駆動ありきで開発するようになって初めてみんなが理解できž wl モデルが〜、Clineが〜、などは各論で本質ではなv ’l AI駆動で作ってみて初めて自社での価値を感じ取れ Ag 取り組む課題はインパクト重視j wl みんながありがたさを感じれるテーマを選びましょˆ ’l 機能のサイズは大きくなくて十分でs #l むしろ小さいほうが箱庭としてわかりやすくてよい
21. ① 困難は分割せよ すべてを一気に変えようとせず、小さく分けて始めることが鍵。そこでは混乱が起きても良い → 「箱庭」を作り、成功体験を積み上げる ② AIはプロセスの効率化ツールではない 真の目的は、バリューストリームの短縮と価値提供のスピードアップ → “早く正しく届ける”体験を積むことが重要 ③ AI開発の実践は、学習と文化形成の場 小さく始めたプロジェクトがケーススタディになり、組織全体に波及 → ADKARで言えば、「Desire」と「Knowledge」の橋渡しに。
 小さな成功体験が、学習意欲と理解の土台をつくる まとめ：AI駆動開発導入のすすめ
22. Appendix
23. AI活用の成熟段階 支援（Assisted Intelligence) 大量のデータ分析や知見提供を通じて
 人間の意思決定を補助する段階 拡張/協業（Augmented Intelligence) 機械学習などAIの能力を業務プロセスに組み込み、
 人間の分析や判断能力を強化する段階（人間とAIの協業） 自律（Autonomous Intelligence) プロセスがデジタル化・自動化され、
 AIが自律的に意思決定し行動できる段階
 （人間がAIに権限委譲した状態） *“AI-fueled organizations”
 https://www2.deloitte.com/us/en/insights/focus/tech-trends/2019/driving-ai- potential-organizations.html
24. 支援（Assisted Intelligence) AI Agents プログラム 開発者 利害関係者 ドキュメント 等 支援 （Assisted Intelligence) AIが開発者をサポートし、開発者が主体的にプログラムを作成する Pros（利点ˆ † 開発者の生産性向Œ † 人間のコントロールが強~ † 学習効果があf † リスク管理がしやすい Cons（課題ˆ † 開発者の負担が大き~ † AIの活用度が限定— † 人間の介入が前提
25. 拡張/協業（Augmented Intelligence) 開発者とAIが共同作業を行い、それぞれが独立した役割を持つ Pros（利点E B AIの貢献度が高s B スピードと品質のバランスが取れ3 B 開発者の負担が軽減 Cons（課題E B AIの品質管理が必( B 役割分担の調整が必( B 開発者のスキルが必要 プログラム 開発者 AI Agents 利害関係者 ドキュメント 等 拡張/協業 （Augmented Intelligence)
26. 自律（Autonomous Intelligence) 利害関係者 プログラム 開発者 AI Agents ドキュメント 等 自律 （Autonomous Intelligence) AIがプログラムやドキュメントを自律的に作成し、
 開発者はAIを監督する Pros（利点d ˜ 完全な自動化が可ƒ ˜ 開発スピードが飛躍的に向y ˜ 開発者は戦略的な役割に集中 Cons（課題d ˜ 品質管理が難し‘ ˜ 開発者の役割が変わ€ ˜ トラブル時の対応が大変
27. AIと人のフォーメーション プログラム 開発者 AI Agents AI Agents プログラム 開発者 利害関係者 利害関係者 利害関係者 ドキュメント 等 プログラム 開発者 AI Agents ドキュメント 等 ドキュメント 等 支援
 （Assisted Intelligence) 拡張/協業 （Augmented Intelligence) 自律 （Autonomous Intelligence)
28. AIを活用した開発で起きうる状況 プラス要因（Positive） マイナス要因（Negative） 内部要因 （Internal） Strengths（強み） 
 繰り返し作業の自動化により開発速度向上
 コード品質の向上（エラーチェック・リファクタリング支 援）
 データ分析や予測による意思決定の強化
 24時間稼働で開発の効率化
 一貫性のある成果物を提供できる
 若手エンジニアの学習支援として機能 Weaknesses（弱み） 
 AIの判断根拠が不透明（ブラックボックス問題）
 未知の問題や新しいアイデアの創出が苦手
 AIによる成果物の品質保証が必要
 導入・運用コストが高い（学習データや計算資源が必要）
 高度なAIを活用するには技術的な知識が必要 外部要因 （External） Opportunities（機会） 
 AI技術の進化による開発効率のさらなる向上
 市場競争力の向上（短期間でのプロダクト開発が可能）
 AI活用による差別化（データ駆動の意思決定やパーソナライ ズ機能）
 エンジニア不足の補完手段としての活用
 クラウドやAPIの活用で導入ハードルが低下
 顧客サポートや運用の自動化で維持コスト削減 Threats（脅威） 
 AIの品質やバイアスによるリスク（誤ったデータ学習による 問題）
 法規制の変化による制約（GDPR、AI倫理規制など）
 AI依存によるスキル低下（エンジニアがAIなしでは開発でき なくなる）
 セキュリティリスク（AIが誤った判断をすると重大な影響）
 競合企業もAIを活用し、優位性を維持しにくい