AI駆動開発Conference Spring 2025にオンライン参加しました。
前日までは現地に行く気でしたが、急遽体調崩してしまい終日動画を浴びていました。
イベントの概要
生成AI・LLMの登場からGitHub Copilot, Cursor初めとする開発ツールの登場により、コード生成・自動補完のみならず、要件整理、UIデザイン、設計、テスト作成、ドキュメント作成においてもAIを駆使する新たな開発スタイルが生まれつつあります。 更に「AI駆動要件定義」「AI駆動テスト」とも言える新たなパラダイムシフトにより、今後アプリケーション・システム開発プロセス全体の大きな変化が予想されます。
AI駆動開発カンファレンスでは、AI技術を使った開発に興味を持つ方々向けに、ChatGPTやGitHub CopilotなどのAIツールを使った開発のノウハウや、AIによる開発プロセスの最適化、生成AI・LLMを最大限に活用した新たな開発方法・開発スタイルやテクニックや今後の新しい開発スタイルについて共有・議論していきます！
引用：
イベント参加の背景
- 生成AIのソフトウェア開発にもたらす影響を風の噂レベルで聞きつつも、自身のエンジニア生活に取り込めていない。
- 勉強したいという気持ちはありつつも、どうしても優先度をあげられずじかんが過ぎてしまっていました。
- AI駆動開発カンファレンスの開催を聞き、今こそ勉強を始めるタイミングだと参加しました。
AIセッションメモ
- Opening keynote: The Making of Windsurf, Why We Built It
■メモ
□Varun Mohan
AIによりソフトウェア開発の生産性が劇的に向上している。
エンジニアが対処すべきことに注力できるようになってきている。
エンジニアにとって課題であるビルドに対してもAIは有能である。
HOWの部分は任せることができる。
今後数年後はエンジニアが本来すべき本質的な課題である何をビルドするかに注力できる。
今後ソフトウェア開発について生産性があがり民主化が進んでいく。
ソフトウェアエンジニアの特権ではなくなっていく。
従来型のエンジニアは専門的な知識により大きな価値を醸成できるようになる。
ソフトウェア開発にかかる時間を大きく（99%）削減していく。
そうした野心的な目標により、モデルをスピーディーに変革していっている。
新しいバージョンを2,3週間ごとにリリースしている。
目指す目標は６か月ごとに現状が些細なことに見えるような変革を生み出すこと。
色々な試行錯誤を経て、いくつかが成功すればよいという思考で動いている。
□ガードナー
プロフェッショナルなソフトウェア開発者の76%がAI開発を実施する想定。
地球規模で3000万人開発者がいる中で4年後には4000万人に増える想定。
大規模なAI企業の中でWindSurfは第三位。
ソフトウェア開発の開発者体験に対するインパクトを観測している。
平均的に44.6%がWindSurfの書いたコードとなっている。現状は60%以上。
人によっては100%WindSurfを使って書いているコアユーザーもいる。
主軸を置いているのはエンタープライズ企業の顧客。現状は1000以上の企業で導入されている。
今JPMorganでは2万人以上のユーザーが利用している。
結果、ユニットテストの書き込み時間の短縮ができている。（40%削減）
コード理解の時間も短縮されている。（31%削減）
JPMCの毎年２社のみ受賞できる革新の伝統も受賞した。
フォーチュンNo1のリテール企業の事例。
WindSurfが書いた新規コード43%埋め込まれた。
PRサイクルタイムを17%短縮している。
大規模なリテール企業にとってはPR時間短縮は大きな意味がある。
AIコーディング短縮により、40万のエンジニアの時間短縮につながった。
プラットフォームから最大限の価値が得られるようにサポートも実施している。
■感想
WindSurfがアプリケーション開発にもたらした変革に驚きました。
ソフトウェアエンジニアがプログラムを書く時間は、今後AIの進化によって大幅に削減されていくと感じました。
そのうえで、他に価値あることに注力できるという話も魅力的な未来と感じました。
その一方で、これまでエンジニアがコーディング体験を通じて蓄積してきた知見を、これからの世代がどのように獲得していくのかは、大きな課題になるとも思いました。
例えとして適切かはわかりませんが、学校で学んだ知識が社会に出て直接役立つとは限らないものの、その知識を得るまでのプロセスには確かな意味があったと感じています。
同様に、エンジニアとして苦労しながらコードを書く中で得られた経験も、非常に価値あるものだと思います。
AIによって開発者の負担が軽減される時代だからこそ、そうした「苦労を通じて得た経験」をどのように醸成し、継承していくのかが、これからの課題になる気もしました。
もっとも、もしかするとエンジニアという存在そのものが、将来的には今ほど長期的な視野で語るべき存在ではなくなるのかもしれない、という考えも頭をよぎりました。 - システムインテグレーション・未来を掴むシナリオ 〜AI駆動開発が強いるビジネスの再定義〜
■メモ
今までと同じように人間がコードを書くことを前提にビジネスの収益構造を成り立たせることはもはや無理になっている。
その前提に立ってこれからのビジネスを再定義する必要がある。
アナログな世界をコンピューターの扱えるデジタルデータに置き換えていく必要がある。
その結果、現実世界のコピーであるデジタルツインができあがる。
ただ、その中には不要な情報もあるため、ソフトウェア化により再構成・最適化する必要がある。
その結果、本物ではないが本物と同じバーチャル世界が生まれる。
ただ、その世界を活かすためにはデジタルだけではできない。
既存の業務をデジタル、新しい技術に置き換えるだけでは意味がない。
デジタルのスピードを活かせるように企業が適用する必要がある。
それがDXと呼ばれるものである。
改革と改善の違い。
改革：Transformation⇒現状とは違う新しい形に作り変える。
改善：Improvement⇒より良い状態に移行する。品質や状態を向上させる。
それぞれ違う取り組みであり、目指すゴールが違う。
DX。大事なのはDegitalではなく、Experience。
改善は現状ベースの不満や問題に対する取り組み。
改革は自分たちが描くありたい姿に対する取り組み。
デジタル化：改善と適応
DX：競争力の強化
ユーザー企業のやりたいことにITベンダー／SI事業者が答えられない。
人件費の高騰で今までの外部依存を続けてよいのかの課題感が生まれてきている。
AI駆動開発／AIエージェントが発展することで外注に頼らなくてよい世界が生まれていく。
AIエージェントがチームの一員になっていく。
ITベンダー／SI事業者に特別な何かが無い限り優位がなくなる。
IT前提の業務改革・新規事業開発支援に傾倒していく。
AIツールによって開発が可能な時代になる。
変化が予想できない時代には開発に圧倒的なスピードが求められる。
圧倒的な開発スピードを実現するのには自前で実現する必要があり、AI駆動開発が前提になっていく。
結果、開発を外注する需要が減っていく。
AI導入支援などでビジネスを再構築する必要が発生していく。
エンジニア人材もSI事業者からユーザー企業に流れていく。
XAI（Explainable AI）が今後フォーカスされていく。
AIが書いたコードをリバースしていく。
モダンIT前提でAIを利用する企業と、ウォーターフォールでAIを利用する企業とでは大きく違う。
ウォーターフォールからアジャイルへの移行はハードルが高いため、遅れは生じる。
ちょっとした差が圧倒的な格差になる。
モダンITで進めないとAI駆動開発が価値を発揮できない。
既存プロセスの改善ではなく、変革が必要となる。
今後80点のコードを人が書くのではなく、AIが実現するようになる。
それを100点にしていくのが人の仕事になる。
今後、事業構造は受発注型から共創型のモデルに移行していく。
■感想
ITベンダーの立場にいる者として、非常に身につまされる内容でした。
改めて、「御用聞き」にとどまらず、事業領域にまで踏み込んでいく共創型のエンジニアリングの重要性を強く意識しました。
スライドの内容が濃密だったため、ぜひもう一度じっくりと読み返したいです。
ブログ記事も気になる。 - AIによるコードレビューで開発体験を向上させよう！
■メモ
現在のソフトウェア開発の課題
1. 開発スピードと品質の両立
2. 人的リソース不足
3. AIを利用した開発スタイルへの進化
4. 技術的負債の解消・共存
5. セキュリティ対策
1,2,3にフォーカスする。
・1. 開発スピードと品質の両立
開発スピードとは？
作ることを決めてからデプロイされるまでの速さ。
品質とは？
要件にどれだけ適合しているか、満たしているか。
開発スピードと品質はトレードオフの関係にあるとされてきたが、必ずしもそうではない。
・安定性を確保するために、必ずしもスピードを犠牲にする必要はない。
・テストは一見、開発のスピードを遅らせるように思えるが、長期的にはバグの削減や再作業の防止により利益をもたらす。
ただし、スマートなチームであれば実現できる話である。
不具合とは？要件とテストで検出されたものの差。
この差を第三者の目線を通すことで軽減するためにレビューを取り入れる。
・2. 人的リソース不足
エンジニアが少ない。エンジニアは多いけど各チームが小さい。
専門化が進み他領域のビジネス・技術知見が浅い。
シニアエンジニア少ない。ジュニアエンジニア多い。
ガイドラインが無い。
・3. AIを利用した開発スタイルへの進化
コーディング、テスト周りでAIツールが多く存在している。
使わない手は無いが、費用面で選択と集中が求められる。
CodeRabbitの解約理由も、他AIの導入による費用増加などがある。
ただ、AIに取り組まないのがリスクとなり、取り組みは必須。
・AIコードレビューのメリット
生産現場ではバグ修正にコストがかかっている。
CodeRabbit導入で、PRが4倍速くマージできる。50%多い機能が開発できる。コード品質が90%向上する。
導入前によくある課題。時間的課題、人的課題、スケール。
人的課題：コードレビューに一貫性がない。レビュアーとエンジニアに業務知識の差がある。ミドルクラスのエンジニア不足。
LinuxFoundationにおける課題。手作業。担当者の知識依存。タイムゾーン。
導入にあたる決定要因。セキュリティ。AI。運用。
コードを学習に利用しない。ベストプラクティスに基づく提案。時間とともに学習し最適化される。
CloudSignの事例。自動レビューとサマリー機能。サブスク型料金体系。コードを外部に出さない。
メリット。時間。スキル。チーム。
PRコスト削減。ジュニアレベルがベストプラクティスを得られる。エンジニアがより重要な問題に入り組める。
Relic事例。効率化と質向上。オンボーディング活用。本質的なレビューに集中。
■感想
特にジュニアレベルの育成やコードレビューの標準化において、非常に効果的だと感じました。
人によるレビューはどうしてもレビュアーの思想やクセに依存しがちですが、AIを活用すればベストプラクティスの共有による全体の底上げが期待できると思いました。
コードレビューに限らず、AIが底上げしてくれる未来を感じました。 - Re-wiring Software Development: AI との協調はいかにソフトウェアエンジニアリングの手法を再定義するのか？
■メモ
これからどうゆう風にAIを用いて開発していけば良いのかを考えていく。
AI開発は世の中の中心になっていく。
AIを使ったツールはたくさんあり、何を利用すれば良いのか分かりづらい。
エンジニアに対する認知負荷（Cognitive Load）も高まっている。
AIを使った開発の現状。
・AI支援開発が現実のものになっている
・開発の仕方が宣言的になっている（今までは手続き的）
・AI支援ツールを提供するプラットフォームエンジニアリングが重要になっている
・AIネイティブのソフトウェア開発のライフサイクル
GitHubCopilotの次のステージでは、人間の意志（issue）をもとにAIエージェントが開発していく。
人間が今までやってきたことをAIが代替していく。メンバーの一員となっていく。
では、人間が何をやるのか？意思を伝えること。自律的に動いていくこと。
今までは、何をしなければいけないかをロジカルに構造解析しコードを書いていっていた。
抽象度があがればあがるほど、手続き型から宣言型に移行していった。
今後意志からAIが開発を進めていく状態が基本になっていく。
今までは、要件定義、設計を行ってから実装に落とし込んできた。
今後はそれをAIにお願いする。結果を検証していく。
出来上がったものをソースコードにマージしていく。
いかに意志をAIに伝えるかが重要になっていく。
急激に増えた変化に追従する必要がある。
それを実現するのがプラットフォームエンジニアリングになる。
これからのAIを利用した社会においては必要な存在になっていく。
AIアシスタントではなく、AI駆動。本当にAIが主軸になるのか？
AIが自律的にソフトウェアを開発する世の中になっていく。
今後のAI駆動開発の世の中を迎えるにあたり、意志が重要になる。
これまで設計書は、主に人間間の意志疎通のためのドキュメントだった。
今後は、AIが正しく理解・実行可能なかたちで意志を表現し、構造化する手段が求められる。
ソフトウェア開発に置いて、作ったものを定義し、定義した状態からドリフトした場合、それを評価し元に戻していく取り組みが重要になっていく。
今後、アプリケーション開発に当たり何を宣言的に定義し、継続的に洗練していくかを考えていくことが求められる。
ベロシティ、安全性、認知負荷の解消をAIが担っていく。
それを実現するために、
・プロンプトを書くにあたる意図を管理する。
・企業内で守るべきものを意図に込める。
・テストケースがソフトウェアの目的を基に実施されるようになる。
・外部とどう連携するか（MCP連携）。オーケストレーション。
・AIに対するガードレール。
・テスト環境も自動化していく。実行環境の差分を無くす。
・作ったものをメンテナンスしていく。パイプラインを有効化していく。
アプリケーション開発者のAI利用をプラットフォームエンジニアリングが支援していく。
プラットフォームエンジニアリングにとってのカスタマーはディベロッパーである。
プラットフォームエンジニアリングの中で、DRE（Developer Reliability Engineering）が重要になっていく。
今、AI駆動開発ではなくAI支援開発。人間を拡張した機能。
今後、自律的なAIが我々のソフトウェアを駆動していく。
我々は今後どうやってそれを実現していくかをAIとともに考えていく。
■感想
AIの進展によって、開発者はこれまで以上に多くの概念や技術を学ぶ必要が出てきています。
その中で、認知負荷を軽減しながら開発者を支援するプラットフォームエンジニアリングの役割がますます重要になっていると感じました。
同時に、「何を実現したいか」という明確な意志を持つことが、ソフトウェアエンジニアに今後求められていくことも感じました。
この考え方は、プロダクトエンジニアリングとも強く接続しているように思います。 - AI駆動開発にはAI駆動品質保証 : 生成AIで変わるQAプロセス
■メモ
テストに生成AIを利用した話。
AIを利用した開発系ツールはかなりある。
半分ぐらいの企業では開発の1/3ぐらいの費用がテストに使われている。
時間がかかってコストがかかることに悩んでいる。
結果、テストにもAIの導入が求められている。
できる部分とできない部分がある。
単体テスト：コードの振る舞いに対するテスト。
単体テストより上に行けば行くほどシステムの振る舞いに対するテストになる。
結果、難易度があがる。
単体テストと違い、開発者の視点だけでなくユーザーの視点も必要となる。
抽象度が高くなればなるほど、総合的かつ専門的な知識・経験も不可欠になる。
AIツールの得意領域。
単体・結合テスト：AI開発ツールの得意領域
結合・システム・受入テスト：AI品質保証ツールの得意領域
AutifyGenesisは後者を実現するために開発された。
テスト対象の振る舞いが書かれた文書を入力すると、テストシナリオ、自動テストコードが出力される。
仕様書だけでなく、バグチケットや操作マニュアルも入力に使える。
・メリット
３アミーゴスでのテストケース作成について、
QAエンジニアがドラフトを使って議論を行っていた。
Genesisで自動生成したらドラフトと同じものが出力できた。
自動生成されたものが網羅されていたので、時間削減ができた。
人員削減でQAがいなくなった。
簡単なメモからテストケースができたため、QAの代替となった。
■感想
他カンファレンスなどでもお話お伺いさせて頂いていますが、Autifyさん凄い。
特に、GenesisによるAIベースのQA支援の実例は印象的でした。
そして、ご登壇者さんが先日読み終わった『入門 監視』の訳者さんでした…！ - AI駆動で進化する開発プロセス ～クラスメソッドでの実践と成功事例～
■メモ
AI駆動開発は、ソフトウェアやシステム開発の全工程に生成AIの技術やツールを積極的に組み込み、開発スピードや品質、効率を飛躍的に高める開発手法。
仮説提案での実用。
顧客と会話した内容を素早くプロトタイピングできる。
開発の全工程で使える。
要件⇒設計、機能命名、レビュー、コード・ドキュメント生成。
Rule作成でトレードオフが発生する。
Rule整備やタスク分割には時間がかかる。なので大規模PJの方がメリットが出る。
逆にプロジェクトが小さい場合は、Rule整備やタスク分割の時間が無駄になることもある。
設計での利用。
新しい機能要求に対して、既存の実装やライブラリがないか調査できる。
従来の開発では、ビジネス側が仕様について確認したり、新しい機能を作りたい場合、開発者を通した確認が必要であったが、 今後はエージェントが集めた情報から確認することが可能となっていく。
テストでの利用。テスト、CI/CDでの利用。
運用保守。すべてのレポジトリの情報をプロンプトに変換。
プロンプロ化したものをGeminiに渡し、設計書を生成。質問も可能。
バイブ・コーディング。
非エンジニアも70%迄簡単にいける。残り30%が高い壁になる。
バイブ・コーディングでコード理解が不要になることは現状では無い。
使いどころは考えていく必要がある。
■感想
開発レイヤでのAI活用の具体的な実践事例として非常に参考になりました。
特に、仕様情報を人に依存せずAIを通じて取得できる状態を整えるという点は、今後の開発効率を大きく左右すると感じました。
自チームでもどうやったら実現できるかなど検討したいと思いました。 - 生成AIが変えるソフトウェア開発とそのリアル
■メモ
現在、生成AIを開発の全工程で利用している。
・チャット型生成AI・API（46,00employees）
商談状況分析や経営レポート作成にも利用。
提案書作成業務で67%時間短縮。
・GitHub Copilot（3,200developers）
2023年頃はコード生成で利用していた。単体テストコード生成で-60%の効果。
開発とテストにGitHub Copilotが適用が始まった。
ソフトウェアの障害対応で原因分析から単体テストまでに生成AIを利用した。
利用者の声にプラスの意見が目立ち、品質が下がったという声はない。
生産性32%UP。
テクニカルアドバイザーの役割がCopilotの使い方の説明が多くなり、既存の役割はCopilotが代替してきた。
・SI開発（ローカルLLM環境）
独自環境を作ってセキュリティを守った。
設計書生成ツール、コード生成ツールなどを用意している。
生成AIを利用するためのINPUT情報の整理も必要だった。
・富士通AI技術（Kozuchi）
展開にあたり。
全社での推進部門を用意し、セキュリティなど周辺部門とも協力して進めた。
社内横断コミュニティを設け、自律的に集合した。
今後。
自律的なAI駆動開発を実現していく。
そのために、人間が生成AIをハンドリングしていく必要がある。
エンジニアの役割・定義が変化していく。
■感想
開発領域だけでなく、ビジネス領域での具体的な活用とその効果の話が非常に参考になりました。
特に、SI開発における生成AIの活用方法は、長年ITベンダーに関わってきた自分にとっても現実的かつ魅力的なアプローチに感じられました。 - システム開発上流工程におけるAI時代のデファクトスタンダード ～大手SIerでの活用事例を交えて～
■メモ
■感想
AIを使った要件定義。
海外プロダクトのシステム生成プロダクトについて。
土台が無いところに要望を継ぎ足していって、何を作りたかったよくわからない、保守運用が難しい状態が目立つ。
これは、アジャイル開発でしばしば見られる問題とも共通している。
変化への柔軟性はあるものの、メンバーのスキルに強く依存し、結果として後工程での改修や整合性の維持が難しくなる傾向がある。
それに対して、AIを利用した高速ウォーターフォールが解決策になる。
ウォーターフォール型の開発は、ドキュメントベースの進行が中心であるため、AIにとっても扱いやすい形式であり、親和性が高い。
ジャパニーズアジャイルとも適合できる。
人がウォーターフォールで開発していく流れと、
エージェントに支持して開発を進めていくことに変わりはない。
ウォーターフォールとアジャイルの比較について。
良いウォーターフォールと良くないアジャイルの比較になっている印象も受けましたが、
一方で、アジャイルの導入が文化的・組織的に難しい企業にとっては、高速ウォーターフォール開発という選択肢は非常に魅力的だと感じました。
特に、ドキュメント文化が根付いている組織にはフィットしやすいアプローチだと思います。 - 【対談】生成AI時代のアジャイルについて徹底議論！
■メモ
2023年下：GitHubCopilot
2024年上：Cursor、Bolt
2024年下：WindSurf、Devin、Cline
アジャイルのサイクル。
ビジネス戦略やUXデザイン・PoC支援でも素早い検証が重要。
アジャイルとの親和性が高い。
どのフェーズでも生成AIの活用は必須となっている。
開発工程より前の段階でAIを活用することが、今後ますます重要になる。
開発期間は今まで数か月から数年だったのが、今は数日から数週間になっている。
アジャイルプロジェクトでは、POがボトルネックとなることが多い。
今後は顧客とエンジニアが直接会話をしていくスタイルが一般化する可能性もある。
但し、非機能要件を見落としがち。そこのフォローは必要。
POがもっと顧客に近くなる姿もある。DevがPOの領域に染み出す姿もある。
PO：なぜつくる、Dev：何をつくる、どうつくる
Devの方が具現化しやすい。
AIが何を作るでDevの見方にはなるが、その妥当性を確認する抽象化した判断にはPOが必要。
生成AI時代のユーザー体験・インターフェースの姿。
生成AIにより顧客と対話しプロトタイプをすぐに提供ができるようになる。
アイデア、データからの学習にエンジニアの希求が生まれる。
エンジニアにフルスタックが求められる。
AI時代のアジャイル開発宣言。
スピード感が変わる。ビジネスと開発者のやり取りのスピード感が必要。
自己組織化のためのチーム規模も変わる。
AIの能力を最大に引き出すノウハウを持った人間が必要となる。
ユーザー体験。AIエージェントでの開発ができるようにする必要がある。
DevにAI駆動開発スキルが必要となる。
アジャイルの土台の上にスピード加速のためのAI駆動開発が乗る。
■感想
生成AIがDevをサポートすることで、スクラムチーム内の役割や関係性が再定義されていくという視点は非常に興味深く感じました。
個人的には開発チームはプロダクト領域にも染み出すべきだと思っており、PO：なぜつくる、Dev：何をつくる、どうつくるの役割が理想と思っています。
そのうえで、今までDevが何をつくるに介入するには余裕が無いと難しかったのが、生成AIの力によってそれが現実的になりつつあることに、強い可能性を感じました。 - モノタロウのAI駆動開発の実践
■メモ
組織的な推進には、トップダウン・ボトムアップ・横の連携の組み合わせが効果的。
AI駆動開発チームは、ボトムアップで各開発チームにAIツールを提供し支援する役割。
AI駆動開発の方法を体得するために、開発者が自律的に触る仕組みづくりを行った。
上からばらまく形で情報共有を行った。下から支えるためにAI活用リテラシーを底上げする。
実際、Devin、Cline、Cursor、GitHub Copilot利用している。
・Devin
マネージャ、リーダー、ＰＭ向け。使う人を選ぶ。
最初の1週間で23本のPR作成、費用は$400程度。一か月330本、$4000。
CIによる仮実装自動化、調査＆壁打ち、bqコマンドの導入。
エンジニアが一人増えたような印象がある。
・Cline
一番人気。200名に配布し、100名アクティブ。
アンケート結果で生産性が向上したという声一番が多い。
面白いと思いつつ、実際の生産性に繋がっていない可能性もある。
認知負荷はそこまで変わらないという声もある。
・Cursor
速度補完レベルでGitHubCopilotに勝る。
・GitHub Copilot
コスト面で有利
生成AI開発ツール導入すべき理由。
成果を出せる可能性が非常に高い。
開発チームは新しいパラダイムを学ぶ経験が必要。
導入ハードルは金銭面のみ。参入しないで劣後するリスクもある。
目標：生産効率100%アップ。
人間がAIを使いこなす。から、AIが自律的に価値を生む状態に。
「AIが自律的に価値を生むプロセス」を実現できるか、そしてそれを前提にした組織設計・チーム運営に自ら進化できるかが問われている。
実験の大規模な実施と継続的なトレンド追従による適応を戦略とする。
自分たちが変化していけるかが試されている。
■感想
モノタロウの取り組みには、いつも大きな刺激を受けています。
生成AIを活用してレガシーシステムの再活性化を図るというアプローチは非常に興味深く、実現すれば大きな可能性があると感じました。
もしこの手法が汎用化できれば、これまで外部委託に頼ってきた企業のシステムにも、新たな再生の道が拓けるのではないかと思いました。 - Closing Keynote: Building the Future: Innovate with AI powered Apps on Azure
■メモ
生成AIをどうソフトウェア開発に活かせるか。
様々な企業・業界で生成AIを活用が始まっている。
生産性向上により創造性を発揮できるようになっている。
AIの活用により、ロールの進化や再定義が促進されている。
ソフトウェア開発では、ビジネス、テクノロジー、経験の３つの要素が重要になる。
これまで長期にわたりそれぞれの領域はサイロ化されていた。
こうしたサイロを壊し、それぞれの役割が協業できる状態になったのが大きい。
AI活用によりそれぞれの役割に対する学習が進み、コラボレーションが加速する。
変わらないこと。ソフトウェア開発はチーム開発。
マイクロソフトでは各ロールがAIを活用している。
生成AIアプリケーションの主要な要素。
既存のアプリケーションとデータを生成AIに使えるようにする。
■感想
生成AIを活用した開発と聞くと、どうしても開発者としての自分はコーディングやテストなど、開発そのものへの影響を中心に考えてしまいがちです。
しかし、今回のセッションを通じて、生成AIがもたらす変革は開発者個人にとどまらず、ビジネスやUX、マネジメントなど、周辺のあらゆる役割にも及ぶものだと実感しました。
開発者の働き方が変わるということは、それに関わるチーム全体のコラボレーションのあり方や役割分担までも変わっていくという未来像がイメージ出来ました。
まとめ
全11本のセッションを聞くことができました。
現地に行きたかった気持ちは残りつつ、最高の体験でした。
11本のセッションを聞く中で、生成AIが確実に今までの開発者が行ってきたタスクの多くを実現していく未来をイメージしました。
先日のHelpfeelさんのカンファレンスでCTO秋山さんがお話されていたハッカーを楽しむを思い出しました。
そのうえで、時間が空いた開発者が何を実現していくのかが重要になっていくと感じています。
個人的にはプロダクト領域に攻めるエンジニアに魅力を感じつつも、いろいろな可能性を検討していきたい。
貴重な体験を得た１日となりました。ありがとうございました。
