【登壇資料】AI駆動開発によってエンジニアの担当領域はどのように変わっていくのか

2025/06/26　AI祭登壇資料

Transcript

1. AI駆動開発によってエンジニアの担当領域は どのように変わっていくのか akira.uchihara / 株式会社エブリー
2. 2 Copyright © 2015 every, Inc. All rights reserved. 自己紹介 • 内原 章（Akira Uchihara） • 株式会社エブリー開発本部 開発2部 部長 • 経歴 ◦ 1996年 ▪ パソコン通信サービス (Nifty-Serve) ◦ 2004年 ▪ ヤフー株式会社 ▪ ジオシティーズ、社内共通基盤 ◦ 2010年 ▪ 頓智ドット ▪ セカイカメラ ◦ 2017年 ▪ エブリー
3. 3 Copyright © 2015 every, Inc. All rights reserved. エブリーは複数の日本最大級メディアを運営。 ”人々の生活に寄り添う ”プロダクトを提供しています。 プロダクト紹介 ※2021年12月時点

4. 4 AI駆動開発に対する取り組み紹介
5. 5 Copyright © 2015 every, Inc. All rights reserved. AI駆動開発取り組み：会社としての方針 • Cursor • 全エンジニア、全PdMに配布 • 業務でAI活用を推奨 • AI活用の事例や課題の共有 • 勉強会実施 • Slack共有用Ch • その他ツール類 • DevinやCursor bugbotなど • 効果検証目的で限定的な導入
6. 6 Copyright © 2015 every, Inc. All rights reserved. AI駆動開発取り組み：Cursor活用の状況変遷 • 初期 • AIと対話しつつ実装進める • あまり明確な方針やルールがあるわけではなく、アドホックに都度指示 • この時点では人間が主、AIが従といった感じ • 指示の粒度に注意 • 参照するデータは人間が都度入力 • 中期 • RuleやMemoryを活用し、徐々にAIに比重を移していく • やはり指示が雑すぎるとAIが迷走するので粒度には依然注意が必要 • システム全体をまず実装してもらい、徐々に細かい単位で実装していくなど • 後期 • MCPを利用することでデータ参照の精度が向上 • Cursor内のみで操作が完結できるように
7. 7 Copyright © 2015 every, Inc. All rights reserved. AI駆動開発取り組み：MCP活用事例 • MCP事例 • 以下のMCP利用シーンを「Findy Tools MCP導入の現在地 〜プロダクト開発での活用のリアル〜 」として寄稿させていただいているので是非！ • Atlassian MCP • Github MCP • CircleCI MCP • 他にも • terraform MCP • ブラウザで公式ドキュメント参照しつつ実装するといった手間が軽減 • Figma MCP+Puppeteer MCP • Figmaのデザインを元に実装 →Puppeteerでレイアウト確認など
8. 8 Copyright © 2015 every, Inc. All rights reserved. AI駆動開発取り組み：その他感想 • Devin検証 • Pros • 並列性に優れるため、複数の Issueを作っておいて一気に実行とかよい感じ • 簡単なタスク（LP更新）ならPdM主導でチケット作成→Github Issue化でいけそう（だが未確認） • Cons • 指示が雑だと迷走してしまう • なので外観として方向性や注意点、参考箇所など与える • 修正の戻りが多い場合、 Turnaround timeの問題でCursorのほうがよいとなりがち • ClaudeCode • Maxは今の所個人ベースで... • 言語化ムズイがなぜか評判よい • Cursorと同じモデルなのに精度高い気がする • あとはRule設定少なくてもまともに動くとか総合的に完成度高い印象
9. 9 自開発部での事例
10. 10 Copyright © 2015 every, Inc. All rights reserved. 自開発部での事例 • golang APIサーバ開発 • 指示が大まかすぎるとうまくいかないので、コード規範や利用ライブラリなど、ある程度道筋は立て ておく • TDDを実践できるようになった。テスト用テンプレコードを書く作業感が減った？ • タスク内容に対して、Plan/Actを切り替えるとよい感じ • Next.js WEBアプリ開発 • UIに対する指示は静的解析だけだとあまり精度でなかった • Playwright MCPで動的把握しやすくなり精度向上 • iOSアプリ開発※ XcodeではなくCursor • 完全未経験状態から、通信ライブラリ一式アップデート、動画プレイヤーPinP対応 • 何一つわからない状態から始めたので、系統立てて理解することがまず難しい • NotebookLMを活用して、それっぽいデータソースをとにかく放り込む • 概略や実装方法などについて説明してもらう • 課題 • Xcodeの機能じゃないので統合的でない • UI周りの確認できない • コードジャンプできない
11. 11 エンジニアの担当領域は今後どのように変わっていくのか ※個人の感想です
12. 12 Copyright © 2015 every, Inc. All rights reserved. AIが出てきたことで今後エンジニアの仕事は変わるか？ • 先に結論 • 変わるは変わると思う • けどエンジニアが一掃されるようなことはないと考えている • IT業界においても過去パラダイムシフトは何度も発生してきたが、一方で実現すべき目的そのもの はあまり変わっていない • ただそのやり方自体は都度変化してきた • なので変化に追随していく必要はある
13. 13 Copyright © 2015 every, Inc. All rights reserved. 今までに発生したパラダイムシフト※諸説あります • 1995年〜 • インターネット • 最初はなにか面白そうくらいの代物で、特になにかができるわけではなかった • toC, toB的なコミュニケーションが容易になり、そのようなシステムが必要とされた • 2000年〜 • モバイル • ケータイ＋i-modeなどでインターネットがインフラ化、iPhone登場でスマホシフト • 普段使いをするシステムのニーズが高まる • 2010年〜 • クラウド • 以前はバックエンド必修科目だったインフラチョットワカルくらいの仕事は激減 • ただしクラウド独自のエコシステムが生まれ、利用側との相互作用によって進化が加速 • 2015年〜 • AI • ひと昔前はAIと言ったら死語扱いだったが今や・・・ • AIによって様々な方面でブレイクスルーが日々発生している • ただまだインフラ化したとまでは言えない認識（高齢者も使うくらいのレベルを想定） • これからどうなっていくか予想しづらい
14. 14 Copyright © 2015 every, Inc. All rights reserved. AI駆動開発により可能になったこと • 初学者 • 学習コストの低減 • 学習は最初が一番難しい。自発的に情報収集するならなおさら • 体系的な説明や、様々な粒度・方向性の疑問に対しても的確に答えられる • 習熟者 • 開発速度の向上 • 一言でソフトウェアエンジニアリングと言っても、高度な思考力が必要とされるタスクとどちらかと言 えば作業的な側面が強いタスクとが混在していることが多い • （少なくとも現在のAIは）作業的なものや、一定のルールがあるものが得意 • 作業的なタスクは今後代替されていくかもだが、それはつまり作業に時間を取られなくてすむよう になった、とも言える
15. 15 Copyright © 2015 every, Inc. All rights reserved. 今後のエンジニア予想図 • 以下のような二極化が発生するのではないかと予想している • 複数の技術領域に広く携わり、バランス感や迅速な実装力が求められる汎用的なシステム開発 • 特定の技術領域に深く携わり、高度な抽象化や設計力が求められる専門的なシステム開発 • 過去のインターネット、モバイル、クラウドによる変化から学ぶ • それまで未整備だった環境にインフラが提供されたことで、新たな価値基準が生まれ、レガシーと なった価値は代替されていった • その代わり、インフラ活用する新たなシステム開発と、インフラ部分のより先鋭化したシステム開発 とがそれぞれ行われることになり、相互作用により共進化してきた • AIについても同じことが言えるのではないかと考えている おわり