AI駆動開発をどのように組織に取り込んで実践していくか / How can we drive AI driven development in my company

2026/1/17に行われたJAWS-UG情シス支部×熊本支部コラボでのチョークトークです。
AI駆動開発を組織で実践していくにあたって発生しうるさまざまな問題や課題についてディスカッションを行いました。

Transcript

1. チョークトーク AI駆動開発をどのように組織に 取り込んで実践していくか 2026/1/17 JAWS-UG 情シス支部 第33回 × 熊本支部コラボ会
2. チョークトークの進め方 • チョークトークとは対話型のセッションで学校の授業やゼミに近いものです • 途中、質問があります ▪ 質問について発言したい方は手を挙げてください • チョークトークはクイズではないので正解も不正解もありません • 積極的に発言と議論をして、みんなで知見の共有をしましょう！
3. 申込時アンケート結果 AI駆動開発をしていますか？業務外でも OKです 1. はい：14名 2. いいえ：7名
4. 申込時アンケート結果 AI駆動開発をしている人へ、 AI駆動開発をしている上での悩みを教えてください • 成果物の品質の担保をどうするか？とレビューの数の多さ（見きれなくなっている）が悩みです。 • いつの間にか頼んでいないことまでやってくれて、 3割ぐらいの打率でいいこともしてくれるので、やめ させるかどうか悩みます。 • どのAI使うのがいいのかはずっと悩んでます。 AWSならKiro(IDE/CLI)かなと思ってるけど。 • コードを書けない人なので、AIさんが言っていることが正しいかどうか判断できない場面が多々・・・ • AIエディタやモデルによってvibe coding中のイライラ度がかなり変わるが、みんなこの辺をどう乗り 越えてるのか知りたい • いくら時間があっても足りない • どこまでコードを理解して進めるべきか。 •
5. 申込時アンケート結果 AI駆動開発をしていない人への質問です。 AI駆動開発を始めるにあたって何かハードルはありますか？ • 回答なし
6. 申込時アンケート結果 チョークトークで AI駆動開発について議論したいトピックはありますか？ • 初心者のため特にトピックは出てきませんが、沢山皆さんとディスカッションしたいです！ • チームでAI駆動開発するときにどのように一貫性を持たせたらいいか？ある程度チームの方向性と ルールは決めないといけないと思っています。 • AI駆動開発を、組織で導入する際のセキュリティ懸念について • AIにどこまで説明するべきか？ついつい細かく指示を出しすぎることにより、想定を超えた結果を出 す可能性を摘んでしまっているのじゃないか、危惧しています。 • 私はPMなので実際に手を動かしてはないのですが、テックリードから 1プルリクに対するコード量が 増えがちでレビューが追いつかない現象が起きていると相談を受けており、そういった「生産に絞る と効率は向上したが品質担保に関する部分を皆さんがどう工夫して乗り切っているか」お聞きしたい なと思います。 • 手でコーディングしてます？ • 成果物のレビューをどのように効率的に進めればよいか • AI駆動開発の際どのような注意点があるか
7. 申込時アンケート結果 チョークトークで AI駆動開発について議論したいトピックはありますか？ • 興味がある分野ですので、みなさんがどのようなもの作られているのかお話をお聞きしたいです。 • プロトタイピングツール, MCPなど選択肢 • 課金して使ってます？ • 既に動いているプロダクトの開発についての AI駆動開発への移行の進め方。 • コードを書けない人でも活用できるようになるためのコツとか、こう付き合ってみたらよさげだった、み たいな経験談！ • まだ手探り状態の組織が多いと思うけど、標準化（使うツールの指定とか）ってどう考えてるか皆さん に聞いてみたい • AI駆動開発の現在の課題
8. シチュエーションの説 明 みなさんがイメージしやすいようにモデルとする 架空の企業を作りました。 この企業のシステムで発生する課題に対して、 どのようなアプローチをとるかという観点で進め ます。
9. 想定企業とシステムについて 企業概要 • 企業名：シャークフィン株式会社（ SharkFin Inc.） • 事業内容： ◦ 海洋データ分析プラットフォームの開発・運営 ▪ 海洋の水温、潮流、塩分濃度などのビッグデータを収集・分析するクラウド基盤 ▪ 漁業・海運業の意思決定を支援するダッシュボードや APIを提供 ◦ 漁業・海運業向けSaaSサービス提供 ▪ 漁場推薦、最適航路計算、燃料コスト削減などの業務支援アプリケーション ▪ 月額課金モデルで、スマホやPCから誰でも使える使いやすいインターフェース ◦ リアルタイム海況予測システム ▪ 機械学習を活用し、6時間先までの海況（波高、風速、潮流）を高精度で予測 ▪ 漁船や貨物船の安全運航と効率的な操業計画をサポート
10. 想定企業とシステムについて 企業規模 • 売上規模：年商12億円 • ユーザー数：約5,000ユーザー • 取引先企業数：約300社（漁業協同組合、漁業会社、海運会社） • 本社所在地：JR池袋駅徒歩10分（サメが輝く水族館の近く） 企業の特徴 • シリーズB調達済みの急成長スタートアップ（前年比売上150%成長） • 海洋データ分析で国内トップ3のシェア、顧客満足度90%以上 • 3年以内のIPOを目指し、フラットな組織で意思決定が早い • マスコットキャラクター：「フィンちゃん」　　　　　　　　　　 • 企業カラー：シャークブルー（#1B4B65）
11. 想定企業とシステムについて • 技術スタック ◦ AWS（ECS, Lambda, RDS, S3, CloudFront） ◦ バックエンド：Python（FastAPI）、Node.js ◦ フロントエンド：React、TypeScript ◦ インフラ：AWS CDK、GitHub Actions • 現状の課題 ◦ 急成長による開発スピードの要求増加 ◦ レガシーコードの技術的負債 ◦ ドキュメント不足 ◦ 新人エンジニアのオンボーディング期間の長期化
12. 主な登場人物 • 経営層 ◦ 真黒CEO（38歳） ▪ 元漁師の家系出身で業界課題を肌で知る若手起業家。 ▪ 「テクノロジーで海の仕事を変える」という強い信念を持ち、 鮫島CTOを口説いて共同創業。 ◦ 鮫島CTO（47歳） ▪ 元大手SIer出身、シャークフィン創業メンバー。 ▪ 「全員AI使おう！」と号令をかける熱血タイプだが、現場の細かい状況は把 握しきれていない。 ◦ 深海CFO（48歳） ▪ 財務・経営管理のプロ。 ▪ 「数値で示してください」が口癖で、 コストには厳しいが合理的な判断をする。
13. 主な登場人物 • 開発チーム ◦ 尾鰭さん（45歳・バックエンドリード） ▪ 20年のキャリアを持つベテラン。 ▪ レガシーコードの守護神で「自分で考えて書く」ことへのプライドを持つが、若手の育成 にも関心がある。 ◦ 青鮫さん（32歳・フルスタックエンジニア） ▪ 新しい技術への適応が早く、プロンプトエンジニアリングが得意。 ▪ チーム内で頼られる存在で、面倒見が良く教えるのが好き。 ◦ 真子さん（28歳・エンジニア） ▪ 入社5年目の中堅エンジニア。 ▪ スピード重視で「まず動かしてみる」が信条、学習意欲は高い。 ◦ 海野さん（23歳・エンジニア） ▪ 入社半年の新人。 ▪ 真面目で責任感が強く、先輩の指示をしっかり聞くタイプだが、 ▪ まだ経験が浅く学ぶことが多い。
14. 主な登場人物 • QAチーム ◦ 虎島リーダー（38歳） ▪ QAチームリーダーでテスト設計のスペシャリスト。 ▪ 品質へのこだわりが強く、チームメンバーの士気を守りながら開発チームとの調整役を 担う。 • QAチームメンバー（5名） ◦ 手動テストのプロフェッショナル集団。 ◦ 品質を守ることに誇りを持ち、開発スピードの変化に対応しようとしている。
15. シャークフィン株式会社の AI駆動開発導入の背景 なぜ今、AI駆動開発なのか？ • ビジネス要求 ◦ 競合他社の台頭により、開発スピードの向上が急務 ◦ 新機能リリースサイクルを月1回→週1回へ短縮したい ◦ 品質を落とさずに生産性を向上させる必要 • エンジニアリング課題 ◦ コードレビュー待ち時間の増加 ◦ 単純作業による疲弊 ◦ ドキュメント作成の後回し ◦ テストコード作成の負担
16. 導入フェーズ 1：試験導入期（ 1-2ヶ月） 課題1：どこから始めるべきか分からない シャークフィン社で起きた問題 • いきなり全社展開して混乱 ◦ 鮫島CTO「全員AI使おう！」→現場「何をどう使えばいいの？」 ◦ 40名のエンジニア全員にGitHub Copilotを配布 ◦ 使い方の研修なし、ガイドラインなし ◦ 2週間後の利用率：わずか15% ◦ 「使い方がわからない」「何に使えばいいの？」の声多数 ◦ 月額コストだけがかさみ、効果が見えない ◦ 経営層から「本当に効果あるの？」と質問されるが、 データがなく答えられない • 結果：予算継続の承認が得られず、プロジェクトが頓挫しかける
17. 課題1：どこから始めるべきか分からない • Q1: ◦ もしあなたがシャークフィン社のエンジニアだったら、 この混乱をどう防ぎますか？ • Q2: ◦ 鮫島CTOに「スモールスタートにしましょう」と提案するとしたら、 どう説得しますか？ • Q3: ◦ あなたがパイロットチームのリーダーだったら、 どんなKPIを設定しますか？
18. 課題1：どこから始めるべきか分からない ベストプラクティス：スモールスタートで成功体験を積む 1. パイロットチームの選定 • 1チーム（5-7名）に絞って試験導入 • 新しい技術に前向きなメンバー • 比較的新しいプロジェクト（レガシー依存が少ない） • 成果が可視化しやすい領域 • チームリーダーが協力的 • 他チームへの影響が少ない独立したプロジェクト 2. 明確なKPI設定例 • コードレビュー時間の削減率 • PR作成から本番デプロイまでの時間 • コード行数あたりの作成時間 • エンジニアの満足度スコア（5段階評価） • バグ発生率の変化
19. 課題1：どこから始めるべきか分からない ベストプラクティス：スモールスタートで成功体験を積む 3. 短期間での効果測定 • 2週間スプリントごとに振り返り • 週次で簡易レポート作成 • 成功・失敗の両方を記録
20. シャークフィン社の実践例 実践概要 • プロジェクト：「リアルタイム潮流予測API」（新規開発） • メンバー：5名（リード1名、シニア2名、ミドル2名） • 期間：2ヶ月間の試験導入 • ツール：GitHub Copilot + Kiro併用評価
21. シャークフィン社の実践例 2ヶ月後の成果 • コードレビュー時間：平均45分→25分（44%削減） • 単純なCRUD実装時間：2時間→1時間（50%削減） • テストコード作成時間：40%削減 • チーム満足度：4.2/5.0 • 「次のプロジェクトでも使いたい」：100% 得られた知見 • CDKコード生成で特に効果大 • 複雑なビジネスロジックは人間が書く方が早い • ドキュメント生成は全員が便利と実感 • ペアプロ時にAIを「3人目」として活用すると効果的
22. 導入フェーズ 2：ガイドライン策定期（ 2-3ヶ月） 課題2：AIが生成したコードの品質担保 シャークフィン社で起きた問題 • AIの提案をそのまま採用して脆弱性混入 ◦ パイロット成功後、他チームも使い始める ◦ しかしガイドラインなしで各自が自由に使用 ◦ Lambda関数のコードをAIが生成 ◦ AWS認証情報がハードコードされていた ◦ レビュアーも気づかずマージ ◦ 本番デプロイ後、セキュリティスキャンで検知 ◦ 緊急ロールバックと全コードの再監査が必要に ◦ 2日間のサービス停止、顧客への謝罪対応 • 結果：「AIは危険だ」という声が社内に広がり、導入推進が停滞
23. 課題2：AIが生成したコードの品質担保 • Q1: ◦ もしあなたがシャークフィン社のレビュアーだったら、 このインシデントを防げましたか？どうチェックしますか？ • Q2: ◦ あなたがガイドライン策定チームのメンバーだったら、 どんなルールを最優先で作りますか？ • Q3: ◦ 新人エンジニアに「AIコードの安全な使い方」を 教えるとしたら、何を最初に伝えますか？
24. 課題2：AIが生成したコードの品質担保 ベストプラクティス：ガイドラインで安全な活用を実現 • AIコード利用の 3原則 ◦ 理解できないコードは採用しない ◦ セキュリティ・パフォーマンスは必ず人間が検証 ◦ AIはアシスタント、最終判断は人間
25. 課題2：AIが生成したコードの品質担保 ベストプラクティス：ガイドラインで安全な活用を実現 • 使って良い場面 ◦ 定型的なCRUDコード ◦ テストコードの雛形 ◦ ドキュメント生成 ◦ リファクタリングの提案 ◦ コードの説明・解説 • 慎重に扱うべき場面 ◦ 認証・認可ロジック ◦ 金額計算・決済処理 ◦ データベースマイグレーション ◦ セキュリティ関連の設定 ◦ 本番環境の設定ファイル
26. 課題2：AIが生成したコードの品質担保 シャークフィン社のガイドライン例 • セキュリティ関連 ◦ AWS IAMポリシーはAI生成後、必ずセキュリティチームレビュー ◦ 環境変数・シークレットは必ずAWS Secrets Manager使用 ◦ 外部API連携コードは統合テスト必須 ◦ pre-commitフックでシークレットスキャン実施 • コード品質関連 ◦ AIコード採用時は「なぜこのコードか」をコメントに記載 ◦ パフォーマンスが重要な箇所は必ずベンチマーク実施 ◦ データベースクエリはEXPLAIN ANALYZEで確認 ◦ 複雑度が高い関数は人間がレビュー
27. 課題2：AIが生成したコードの品質担保 シャークフィン社のガイドライン例 • プロセス関連 ◦ PRに「AI使用箇所」をラベル付け ◦ 週1回「AIコードレビュー勉強会」を開催 ◦ 失敗事例を「ポストモーテム」として共有 ◦ ガイドラインは月1回見直し • プロンプトエンジニアリングのベストプラクティス ◦ 「AWSベストプラクティスに従って」を必ず付ける ◦ 「セキュリティを考慮して」を明示 ◦ 既存コードのスタイルを例示として与える ◦ 「テストコードも含めて」と指示
28. 課題2：AIが生成したコードの品質担保 ガイドライン策定後の効果 • セキュリティインシデント：ゼロ（3ヶ月間） • コードレビュー指摘事項：40%削減 • 「AIコードの品質に不安」：80%→20%に改善 • ガイドライン遵守率：95%以上
29. 導入フェーズ 3：組織展開期（ 3-6ヶ月） 課題3：ベテランエンジニアの抵抗感 シャークフィン社で起きた問題 • ベテランが「時代遅れ」扱いされて組織が分断 ◦ 若手エンジニアがAIを使って爆速で開発 ◦ ベテランの陣辺さん（50歳・シニアインフラエンジニア）は 「手作業の方が確実」と使わない ◦ 若手：「陣辺さん、遅いですね。AIを使えばいいのに」 ◦ 陣辺さん：「自分の30年のキャリアが否定された気分だ」 ◦ 他のベテラン数名も「自分たちは不要なのか」と落ち込む ◦ チーム内の雰囲気が悪化、ベテランと若手の溝が深まる ◦ ベテランの1人が「もうついていけない」と退職を検討 • 結果：組織の分断、貴重な技術の継承が途絶える危機
30. 課題3：ベテランエンジニアの抵抗感 • Q1: ◦ もしあなたがシャークフィン社の若手エンジニアだったら、 陣辺さんにどう声をかけますか？ • Q2: ◦ あなたがベテランの陣辺さんの立場だったら、 どんな言葉をかけられたら前向きになれますか？ • Q3: ◦ ベテランを「AIチャンピオン」に任命するとしたら、 どんな役割・ミッションを与えますか？
31. 課題3：ベテランエンジニアの抵抗感 ベストプラクティス：ベテランを味方につける • 1. 価値の再定義 ◦ AIは「敵」ではなく「パワーアップツール」 ◦ ベテランの経験 × AI = 最強の組み合わせ ◦ 「AIが書けないコード」を書けるのがベテランの価値 • 2. 段階的なアプローチ ◦ 無理に使わせない（選択肢として提供） ◦ 小さな成功体験から始める ◦ 得意分野から導入（例：ドキュメント生成、テストコード）
32. 課題3：ベテランエンジニアの抵抗感 ベストプラクティス：ベテランを味方につける • 3. ベテランの知見を活かす ◦ AIコードレビュアーとして活躍の場を提供 ◦ ガイドライン策定にベテランを巻き込む ◦ 「AIが間違える場所」を教える役割 • 4. ベテランエンジニアとの向き合い方 ◦ 強制ではなく「選択肢」として提示 ◦ 成功事例は同世代のベテランから共有 ◦ 「AIチェッカー」として新しい役割を提供 ◦ 1on1で個別の不安をヒアリング
33. 課題3：ベテランエンジニアの抵抗感 シャークフィン社の転換事例 • ケース1：尾鰭さん（ 45歳・バックエンドリード） ◦ 当初：「AIなんて使わない」と明言 ◦ 転機：レガシーコードのリファクタリングで AIに解説させたら便利さを実感 ◦ 現在：「AIドキュメンテーション職人」として社内で有名に ◦ コメント：「AIは若手の道具だと思ってたけど、むしろベテランこそ使いこなせる」 • ケース2：陣辺さん（ 50歳・シニアインフラエンジニア） ◦ 当初：「手作業の方が確実」と頑なに拒否 ◦ 転機：深夜障害対応でAIに助けられた経験 ◦ 現在：CDKコード生成でAIを活用、レビューは人間が徹底 ◦ コメント：「AIは新人エンジニアみたいなもの。 育てて使うのがベテランの仕事」
34. 課題3：ベテランエンジニアの抵抗感 シャークフィン社の転換事例 • ケース3：浪岡さん（ 42歳・アーキテクト） ◦ 当初：「若手の基礎力低下」を懸念 ◦ 転機：AI活用ガイドライン策定のリーダーに任命 ◦ 現在：「AIとの付き合い方」を教える社内講師 ◦ コメント：「AIを使うからこそ、基礎が大事だと教えられる」 • 組織全体での取り組み ◦ 「シャークハック」：月1回のAI活用ハッカソン（世代混合チーム） ◦ ベテランエンジニアを「AIチャンピオン」に任命 ◦ 新人研修にAI駆動開発を組み込み（ベテランが講師） ◦ Slackチャンネル「#ai-dev-tips」で世代を超えた知見共有 ◦ 「ベテランに聞く！AIの落とし穴」勉強会を定期開催
35. 導入フェーズ 3：組織展開期（ 3-6ヶ月） 課題4：チーム間での温度差と組織分断 シャークフィン社で起きた問題 • 「AIに仕事を奪われる」不安で QAチームが反発 ◦ 開発チームがAIで生産性2倍に ◦ 社内で「AIチームすごい！」と話題に ◦ QAチーム：「テスト自動生成で自分たちの仕事がなくなる」と不安 ◦ QAチームリーダーの虎島さんが「AIツールは使わない」と宣言 ◦ 開発は早く進むが、QAが追いつかずボトルネックに ◦ QAチームのモチベーション低下、2名が転職活動を開始 ◦ 経営層：「なぜQAだけ遅いの？」とプレッシャー • 結果：部署間の対立、全体最適ができず効果が半減
36. 課題4：チーム間での温度差と組織分断 • Q1: ◦ もしあなたがシャークフィン社のQAチームメンバーだったら、 どんな不安を感じますか？ • Q2: ◦ あなたが開発チームのリーダーだったら、 QAチームをどうサポート・説得しますか？ • Q3: ◦ 経営層から「なぜQAだけ遅いの？」と言われたら、 どう説明しますか？
37. 課題4：チーム間での温度差と組織分断 ベストプラクティス：全社展開と文化醸成 • 1. 段階的な全社展開計画 ◦ フェーズ1：パイロットチーム（1-2ヶ月） ◦ フェーズ2：アーリーアダプター（3-4ヶ月） ◦ フェーズ3：全社展開（5-6ヶ月） ◦ 各フェーズで成功事例を共有 • 2. 役割の再定義 ◦ AIは「仕事を奪う」のではなく「仕事を変える」 ◦ 単純作業→創造的な仕事へシフト ◦ 新しいスキルセットの習得機会 ◦ キャリアパスの明確化
38. 課題4：チーム間での温度差と組織分断 ベストプラクティス：全社展開と文化醸成 • 3. 知識共有の仕組み化 ◦ 週1回「AI活用Tips共有会」（全社参加） ◦ 月1回「失敗事例から学ぶ会」 ◦ 部署横断のペアプログラミング ◦ 社内Wikiでの知見共有 • 4. 組織文化の醸成 ◦ 成功事例は全社に公開 ◦ 失敗も隠さず共有（学びの文化） ◦ 世代・部署を超えたメンタリングプログラム ◦ 「AI活用度」を評価指標にしない（プレッシャー回避） ◦ 使わない選択肢も尊重
39. 課題4：チーム間での温度差と組織分断 シャークフィン社の全社展開戦略 • フェーズ1：パイロットチーム（ 1-2ヶ月目） ◦ 対象：1チーム（5名） ◦ 「リアルタイム潮流予測API」で試験導入 ◦ KPI測定とガイドライン策定 ◦ 成功事例を経営層に報告
40. 課題4：チーム間での温度差と組織分断 シャークフィン社の全社展開戦略 • フェーズ2：アーリーアダプター（ 3-4ヶ月目） ◦ 対象：3チーム（開発2、インフラ1） ◦ パイロットチームがメンター役 ◦ 週1回の合同勉強会 ◦ 成功事例を経営層に報告 • フェーズ3：全社展開（ 5-6ヶ月目） ◦ 全40名のエンジニアに展開 ◦ 部署別のキックオフミーティング ◦ 「AI活用ガイドブック」を配布 ◦ サポート体制の構築（Slackチャンネル、相談窓口）
41. 課題4：チーム間での温度差と組織分断 不安解消のための取り組み • 経営層からのメッセージ ◦ 「AIは人員削減のためではなく、成長のため」 ◦ 「新しいスキルを身につける機会」 ◦ 「評価制度は変えない」と明言 • キャリアパスの提示 ◦ AI活用スキルを持つエンジニアの新しい役割 ◦ 「AIアーキテクト」「プロンプトエンジニア」などの職種 ◦ スキルアップ支援（研修費用の補助）
42. 課題4：チーム間での温度差と組織分断 • QAチームの事例 ◦ 当初：「テスト自動生成で仕事がなくなる」と不安 ◦ 実際：単純なテストはAI、複雑なシナリオテストに集中 ◦ 結果：テスト品質が向上、やりがいも増加 ◦ コメント：「AIのおかげで本当に大事な仕事に集中できる」 • 成果 ◦ 全社AI利用率：15%→85%（6ヶ月で） ◦ 「AIに仕事を奪われる不安」：70%→10% ◦ チーム間の協力度：3.0→4.5/5.0 ◦ 組織の一体感：向上
43. 導入フェーズ 4：最適化期（ 6ヶ月以降） 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） シャークフィン社で起きた問題 • Vibecodingで本番実装して技術的負債が爆発 ◦ 真子さん(28歳・エンジニア)がAIと対話しながら「漁獲量予測機能」を実装 ◦ 「動いた！」と喜んで本番デプロイ ◦ 設計書なし、ドキュメントなし、テストも最小限 ◦ 3ヶ月後、機能追加の依頼が来る ◦ 誰もコードの全体像を理解できない ◦ 真子さん本人も「なぜこう書いたか覚えてない」 ◦ リファクタリングに2週間、本来の機能追加に3週間 • 結果：技術的負債の増加、「 AIで作ったコードは保守できない」 という評判
44. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） • Q1: ◦ もしあなたがシャークフィン社の真子さんの先輩だったら、 どんなアドバイスをしますか？ • Q2: ◦ あなたがコードレビュアーだったら、 「これはリファクタリングが必要」とどう判断しますか？ • Q3: ◦ 真子さんのコードを引き継ぐことになったら、 まず何から始めますか？
45. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） ベストプラクティス：場面に応じた使い分け • Vibecoding（ノリと勢い重視） ◦ AIと対話しながら即座にコードを生成 ◦ 「とりあえず動かしてみる」アプローチ ◦ 素早いプロトタイピング ◦ 試行錯誤を繰り返しながら完成させる • Spec Mode（設計重視） ◦ 要件定義・設計を先に行う ◦ 仕様書をAIに渡して実装 ◦ 計画的な開発プロセス ◦ レビューしやすい構造化されたコード
46. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） ベストプラクティス：場面に応じた使い分け • Vibecodingを使う場面 ◦ プロトタイプ・PoC開発 ◦ 技術調査・検証 ◦ 個人の学習・実験 ◦ スパイク（技術的な調査タスク） ◦ 社内ツール・スクリプト • Spec Modeを使う場面 ◦ 本番環境への実装 ◦ 複数人で開発する機能 ◦ セキュリティ・金額計算など重要な処理 ◦ 長期運用が前提のコード ◦ APIなど外部インターフェース
47. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） ベストプラクティス：場面に応じた使い分け • ハイブリッドアプローチ ◦ フェーズ1：Vibecodingで探索（要件が曖昧な段階） ◦ フェーズ2：設計の整理（知見を元に設計書作成） ◦ フェーズ3：Spec Modeで実装（構造化されたコード） ◦ フェーズ4：継続的な改善（小さな改善はVibecoding） • スタイル選択の判断基準 ◦ 要件の明確さ：曖昧→Vibecoding、明確→Spec Mode ◦ 規模：小→Vibecoding、大→Spec Mode ◦ 重要度：低→Vibecoding、高→Spec Mode ◦ チーム：個人→Vibecoding、複数人→Spec Mode
48. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） シャークフィン社の成功事例：新機能「漁場推薦システム」の開発 • Week 1（Vibecoding） ◦ 推薦アルゴリズムの検証 ◦ 3つのアプローチを試作 ◦ 精度を比較して最適な方法を選定 • Week 2（設計） ◦ 選定したアルゴリズムを元に設計書作成 ◦ API仕様、データモデル、セキュリティ要件を定義 ◦ チームレビューで合意形成 • Week 3-4（Spec Mode） ◦ 設計書を元にAIで実装 ◦ テストコード、ドキュメントも生成 ◦ コードレビュー、QA、本番デプロイ
49. 課題5：開発スタイルの選択（ Vibecoding vs Spec Mode） シャークフィン社の成功事例：新機能「漁場推薦システム」の開発 • 結果 ◦ 開発期間：4週間（従来は8週間） ◦ コード品質：高い保守性を維持 ◦ チーム満足度：「適材適所で使えた」と好評 • ガイドライン策定後の効果 ◦ 開発スタイルの衝突：80%削減 ◦ 「どっちを使えばいい？」の質問：ほぼゼロ ◦ プロトタイプから本番までの期間：30%短縮 ◦ コード品質の満足度：3.5→4.3/5.0
50. 導入フェーズ 4：最適化期（ 6ヶ月以降） 課題6：コスト管理と ROI測定 シャークフィン社で起きた問題 • CFOから「効果が見えない。予算打ち切り」と通告 ◦ 導入半年後、月額200万円のコストに ◦ GitHub Copilot、Cursor、ChatGPT、Claude、KIROなど乱立 ◦ 深海CFO：「ROIは？効果は？」 ◦ 現場：「便利です！」（感覚的な回答のみ） ◦ 深海CFO：「数値で示してください」 ◦ 現場：「...データがありません」 ◦ 深海CFO：「では予算は継続できません」 • 結果：せっかく定着した AI活用が中断の危機、現場から不満の声
51. 課題6：コスト管理と ROI測定 • Q1: ◦ もしあなたがシャークフィン社のエンジニアだったら、 深海CFOにどんなデータを見せて説得しますか？ • Q2: ◦ あなたがツール選定の担当者だったら、 どんな基準で選びますか？ • Q3: ◦ 月額200万円のコストは高い？妥当？ あなたならどう判断しますか？
52. 課題6：コスト管理と ROI測定 ベストプラクティス：データドリブンなコスト管理 • 1. 利用状況の可視化 ◦ ツール別の利用率ダッシュボード ◦ エンジニア別の利用頻度 ◦ 機能別の活用状況 ◦ 週次・月次レポート • 2. ROI測定の仕組み構築 ◦ 開発時間の削減効果を測定 ◦ コードレビュー時間の削減 ◦ バグ修正時間の削減 ◦ オンボーディング期間の短縮 ◦ 金額換算して可視化
53. 課題6：コスト管理と ROI測定 シャークフィン社の ROI測定方法 • コスト（月額） ◦ ツールライセンス：150万円（40名分） ◦ 研修・教育：20万円 ◦ サポート体制：30万円 ◦ 合計：200万円 • 効果（月額換算） ◦ 開発時間の削減 ◦ コーディング時間：20%削減 → 160時間/月削減 ◦ コードレビュー時間：40%削減 → 80時間/月削減 ◦ ドキュメント作成：50%削減 → 40時間/月削減 ◦ 合計：280時間/月削減 ◦ 金額換算（@5,000円/時間）：140万円/月
54. 課題6：コスト管理と ROI測定 シャークフィン社の ROI測定方法 • 品質向上による効果 ◦ バグ修正時間：30%削減 → 60時間/月削減 ◦ 金額換算：30万円/月 • 採用・育成コストの削減 ◦ オンボーディング期間：3ヶ月→1.5ヶ月 ◦ 新人1人あたり：150万円削減 ◦ 年間採用5名として：月額換算62万円 • 離職率の改善 ◦ エンジニア満足度向上により離職率低下 ◦ 採用コスト削減：月額換算50万円
55. 課題6：コスト管理と ROI測定 シャークフィン社の ROI測定方法 • ROI計算 ◦ 効果合計：282万円/月 ◦ コスト：200万円/月 ◦ ROI：1.41倍（月次）、年間で約1,000万円の効果 • ダッシュボードの構築 ◦ Amazon QuickSightで可視化 ◦ リアルタイムで利用状況を表示 ◦ 経営層向けレポートを自動生成 ◦ 四半期ごとに経営会議で報告
56. 課題6：コスト管理と ROI測定 シャークフィン社の ROI測定方法 • ツール最適化の実施 ◦ 利用率5%のツールAを解約 → 月額20万円削減 ◦ KiroとGitHub Copilotを併用評価 ◦ 企業版に切り替え → セキュリティ向上 • 成果 ◦ コスト最適化：200万円→150万円/月 ◦ ROI：1.41倍→1.88倍に改善 ◦ 経営層の理解：「数値で効果が見える」と好評 ◦ 予算承認：次年度も継続決定 ◦ エンジニア満足度：15ポイント向上
57. 導入フェーズ 5：スケーリング期（ 9-12ヶ月） 課題7：AIスキルの属人化 シャークフィン社で起きた問題 • 「AIの達人」青鮫さんへの依存でボトルネック化 ◦ 導入から半年、青鮫さん(32歳・フルスタックエンジニア)がAIを使いこなす ◦ 青鮫さん：的確なプロンプトで高品質なコード生成 ◦ 他のメンバー：「コード書いて」だけで低品質な結果 ◦ 同じタスクで3倍の時間差が発生 ◦ 「AIのことは青鮫さんに聞けばいい」文化が定着 ◦ 青鮫さんへの質問が1日20件、本来の業務が進まない ◦ 青鮫さんが休むとチーム全体が困る ◦ 青鮫さん：「自分がボトルネックになってる...」とストレス • 結果：属人化リスク、青鮫さんの負担増大
58. 課題7：AIスキルの属人化 • Q1: ◦ もしあなたがシャークフィン社の青鮫さんだったら、 どうやって知識を共有しますか？ • Q2: ◦ あなたが新人エンジニアだったら、 青鮫さんからどうやってスキルを学びますか？ • Q3: ◦ プロンプトライブラリを作るとしたら、 どんなカテゴリ・項目が必要だと思いますか？
59. 課題7：AIスキルの属人化 ベストプラクティス：知識の組織化と共有 • 1. プロンプトライブラリの構築 ◦ 社内Wikiに成功プロンプト集を作成 ◦ カテゴリ別に整理（CDK、API実装、テストコードなど） ◦ 「なぜこのプロンプトが良いのか」解説付き • 2. AIスキルマトリクスの導入 ◦ レベル1：基本的なコード補完を使える ◦ レベル2：プロンプトで意図したコードを生成できる ◦ レベル3：複雑な要件を分解してAIを活用できる ◦ レベル4：チームにAI活用を教えられる
60. 課題7：AIスキルの属人化 ベストプラクティス：知識の組織化と共有 • 3. 定期的な知識共有会 ◦ 週1回「今週のベストプロンプト」共有会 ◦ 月1回「AIハック大会」で技を競う ◦ 四半期ごとに「AIスキルアップ研修」 • 4. 知識共有の仕組み ◦ プロンプトライブラリ（社内Wiki） ◦ Slackで「#ai-prompt-share」チャンネル ◦ ペアプロでのOJT ◦ 録画した実演動画の共有 ◦ 「今月のAIマスター」表彰制度
61. 課題7：AIスキルの属人化 ベストプラクティス：知識の組織化と共有 シャークフィン社のプロンプトライブラリの例 カテゴリ：AWS CDK / ECS Fargate構築 プロンプト： 「ECS Fargateのタスク定義をAWS CDK (TypeScript)で作成。 要件： - コンテナイメージはECRから取得 - 環境変数はSecrets Managerから注入 - CloudWatch Logsに出力 - ヘルスチェック設定を含む - AWSベストプラクティスに準拠 既存のコーディング規約： [リンク] なぜ良いのか： - 要件を箇条書きで明確に指定 - セキュリティ要件を明示 - 既存規約を参照させることでスタイル統一
62. 課題7：AIスキルの属人化 • AIスキルアップ研修プログラム ◦ 月1回、2時間の実践ワークショップ ◦ レベル別のカリキュラム ◦ 達人が講師を担当（持ち回り） ◦ 実際のタスクを題材に • 成果 ◦ 全エンジニアのAI利用率：30%→85% ◦ 平均的なプロンプト品質：2.5→4.0/5.0 ◦ 「AIが使えない」の声：ほぼゼロ ◦ 青鮫さんへの質問：1日20件→5件
63. 導入フェーズ 5：スケーリング期（ 9-12ヶ月） 課題8：セキュリティとコンプライアンス シャークフィン社で起きた問題 • 新人が顧客データを AIに入力して緊急停止 ◦ 新人の海野さん(23歳・エンジニア)が顧客の実データをプロンプトに貼付け ◦ 「このSQLを最適化して」と個人情報を含むクエリを送信 ◦ セキュリティ監視ツールが検知、アラート発報 ◦ セキュリティチームから緊急停止命令 ◦ 全社でAI利用を一時停止、全エンジニアに再教育 ◦ 顧客への報告義務が発生、信頼関係に影響 ◦ 海野さん：「知らなかった...」と落ち込む • 結果：1週間のAI利用停止、現場から「使いづらくなった」の声
64. 課題8：セキュリティとコンプライアンス • Q1: ◦ もしあなたがシャークフィン社の海野さんの先輩だったら、 どう教育しますか？ • Q2: ◦ あなたがセキュリティチームのメンバーだったら、 どんな対策を最優先で導入しますか？ • Q3: ◦ 顧客から「AIツール使ってますか？」と聞かれたら、 あなたならどう答えますか？
65. 課題8：セキュリティとコンプライアンス ベストプラクティス：セキュリティガバナンスの確立 • 1. データ取り扱いガイドライン ◦ 機密情報の定義を明確化 ◦ AIに入力して良いデータ・悪いデータの基準 ◦ データマスキングの徹底 • 2. 技術的な対策 ◦ DLP（Data Loss Prevention）ツールの導入 ◦ プロンプト内容の自動スキャン ◦ 機密情報検知時のアラート • 3. 契約・法務面の整備 ◦ AIツールの利用規約確認 ◦ 顧客契約書のAI利用条項チェック ◦ ライセンス管理の徹底
66. 課題8：セキュリティとコンプライアンス ベストプラクティス：セキュリティガバナンスの確立 • 入力して良いデータ ◦ 公開されている情報 ◦ サンプル・ダミーデータ ◦ 匿名化・マスキング済みデータ ◦ 自社の公開コード • 入力してはいけないデータ ◦ 顧客の個人情報 ◦ 認証情報・APIキー ◦ 未公開の機密情報 ◦ 契約で保護された情報 ◦ 本番環境の実データ
67. 課題8：セキュリティとコンプライアンス シャークフィン社のセキュリティ対策 • 技術的対策 ◦ Kiro PRO版を導入（データ保持なし） ◦ プロンプト監視ツールの導入 ◦ 機密情報パターンの自動検知 ◦ 違反時の自動アラート＋上長通知 • 教育・啓発 ◦ 全エンジニア向けセキュリティ研修（必須） ◦ 「やってはいけないプロンプト集」の作成 ◦ 月1回のセキュリティリマインド ◦ ヒヤリハット事例の共有（匿名化）
68. 課題8：セキュリティとコンプライアンス シャークフィン社のセキュリティ対策 • プロセス ◦ AI利用前のセキュリティチェックリスト ◦ 顧客案件でのAI利用は事前承認制 ◦ 四半期ごとのセキュリティ監査 ◦ インシデント発生時の報告フロー • データマスキングの実践例 ◦ 悪い例： ▪ 「このSQLを最適化して ▪ SELECT * FROM users WHERE email = 'yamada@example.com'」 ◦ 良い例1（ダミーデータ）： ▪ 「このSQLを最適化して ▪ SELECT * FROM users WHERE email = 'user@example.com' ▪ ※実際のデータ構造：id, name, email, created_at」
69. 課題8：セキュリティとコンプライアンス シャークフィン社のセキュリティ対策 • 成果 ◦ セキュリティインシデント：ゼロ（6ヶ月間） ◦ 機密情報の誤入力：検知システムで100%防止 ◦ セキュリティ意識スコア：3.2→4.5/5.0 ◦ 顧客からの信頼度：向上
70. まとめ：成功の 5つのポイント シャークフィン流 AI駆動開発 • スモールスタート ◦ いきなり全社展開せず、小さく始めて成功体験を積む • ガイドライン策定 ◦ セキュリティとコード品質の基準を明確に • 文化の醸成 ◦ 失敗を恐れず、学びを共有する文化を作る • 継続的な改善 ◦ 定期的な振り返りと最適化 • 人間中心 ◦ AIはツール、主役はエンジニア
71. ありがとうございました！ 鮫島CTOからのメッセージ 「サメは泳ぎ続けなければ死ぬ。エンジニアも同じだ。 AIは波だ。乗りこなせば加速できるが、飲まれれば沈む。 恐れるな。この新しい潮流に乗って、俺たちは泳ぎ続ける。」 — 鮫島CTO