コード生成やエージェント型AIによって実装は加速している。しかし現場では、AIが大量に作るほど人がボトルネックになり、レビューと手戻りに時間が消えていく。ツールを導入し、既存の工程を少し速くするだけでは、この現象は解けない。必要なのは、AIが作ることを前提に、価値の定義から開発プロセス、チームの役割までを組み替えることだ。

本記事では、シアトルを起点にAIを前提とした開発プロセスを組み立てるSlalomの3名が、開発全体をどう再設計しているのかを語る。企画構想をその場で形にするConcept Designer、ビジネスとテクノロジーを繋ぐSolution Owner、そして、人とAIが同じ文脈を参照するコンテキストハブ。自らの開発現場で試し、改善し、実プロジェクトに適用してきた学びを交えながら、AIネイティブ時代の開発の姿を描き出す。

アーカイブ動画

シアトルから始まる、AIネイティブ開発の全景

Slalomは、クラウドやAIの構想を示すだけでなく、自ら手を動かし、実際に使われる仕組みまで形にすることを重視してきた。冒頭のセッションでは、そのSlalomがなぜAIネイティブ開発を語るのか、現場での実践を支える全体像が示された。

Slalom
Japan Country Leader / 社長執行役員
渡邉 知志（わたなべ さとし）氏

構想から実装までを一気通貫で提供する会社が見ている景色

Slalomの仕事は、クラウドやAIを活用しながら、クライアントのビジネスや業務そのものを変革ところまで支援することにある。方法論を説明して終わるのではなく、クライアントとともに考え、実装し、実際の現場で使える状態まで持っていく。

「最近ではほとんどがAIの仕事になっている」と渡邉氏は語る。AIを使いながら業務や会社そのものを変えていく仕事が、今の主戦場だ。

2025年から2027年、開発の焦点は個人から組織へ移る

渡邉氏は、AI駆動開発の変化を年単位で整理してみせた。2025年はAI駆動開発が個人の道具として広がり始めた時期。今は、個人利用のままでは企業システムや社会インフラに通用しないため、開発プロセスそのものを工夫することで、ようやく世の中に出せる段階に来ている。

そしてこれからは、組織・ガバナンス・役割分担といったレイヤーを整えていく時代に入る。「AIネイティブ」というアプローチは、この延長線上に位置づけられる。

4つの要素で捉えるAIネイティブ

Slalomは、AIネイティブ開発を「設計」「開発」「プロセス」「組織」の4つの要素で構成される取り組みとして整理している。このイベントで扱うのは、プロセスと組織だ。

プロセスは新田氏が担当し、要件定義から実装までがAI駆動でどう変わるかを掘り下げる。組織については日永氏が、Slalomが実践する「Solution Owner（ソリューションオーナー）」を軸に語る。

開発プロセスと組織を、同じ土俵で語り直す

ここで示されたのは、AIツールの選定論ではない。価値の定義、開発プロセス、組織を、AI活用を前提に一つの仕組みとして組み替えること。SlalomがAIネイティブ開発で重視するのは、この全体設計である。

次のセッションでは、その全体設計のうち、AI駆動開発の現場で実際に起きている変化と、そこから生まれた仕組みがライブデモとともに語られる。

AIが作るのが当たり前になる、開発プロセスの再設計

エージェント型AIの登場で、開発プロセスはどう変わるのか。新田氏は、AI導入で失敗する典型パターンを提示したうえで、企画構想から改善運用までを一つのループとして捉え直すアプローチを、ライブデモとともに紹介した。

Slalom
Delivery, Solution Ownership / Senior Principal
新田 哲也（にった てつや）氏

新田氏は金融系IT企業で15年以上、大規模プロジェクトのリードとしてビジネスとITの最前線を走り続けたのち、2023年により広いフィールドを求めてSlalomへ移った。現在はSolution Ownerチームのリーダーとして、AIを含めたテクノロジーを織り込みながら、幅広い業界のクライアントと共にプロジェクトを推進している。

人間駆動開発から、AI駆動開発へ

これまでの30年、開発の焦点は「どう作るか」に置かれてきた。ウォーターフォール、アジャイル、DevOpsといったメソドロジーが整備されても、結局は人が作り、人が確認する流れは変わらなかった。

エージェント型AIの登場で、この構図が動き始めている。AIが自律的に思考し、計画を立て、実装する。人間の役割は、指揮管理側へ移りつつある。論点は「どう作るか」ではなく、「誰が作って、誰がどう判断するか」に変わったと新田氏は語る。

AIを入れたはずが、なぜ人がボトルネックになるのか

早く作れる、大量に作れる、時間が浮く。AI導入時の期待は明確だ。だが現場ではどうか。「実際、皆さんいかがでしょうか。本当に効率化できていますか？」と新田氏は問いかける。

大量のアウトプットに押されて、レビュー側の人間がボトルネック化する。中身の確認や修正に時間が奪われ、AIによって浮いたはずの時間が手戻りに消えていく。多くの人が経験している現象だ。

AI導入の失敗は、ツールの問題ではない。プロセス設計の問題だと新田氏は指摘する。

織田軍と武田軍が教える、前提の再設計

新田氏はここで歴史の話を挟む。長篠の戦いで、織田軍は鉄砲で武田の騎馬軍を破った。だが、武田軍も鉄砲を織田軍と同じ割合で導入していたとされる。

差を分けたのは、鉄砲を持っていたかではなく、それが機能する前提で全体を再設計していたかどうかだった。調達、配置、連携、継続的な運用まで含めて、戦い方の前提が変わり始めていた。

これはそのまま今の開発に重なる。問われているのは、AIを使っているかではなく、AIが機能する前提で開発全体を作り変えているかだ。

上流と下流に注力する、ループ型の開発へ

企画・要件定義・設計・実装・テスト・リリース。上から下へ流れる一方通行の開発を、AIで単に置き換えても、大量生産の末に負債が積み上がるだけになる。

Slalomは、価値を継続的に生み続けるループとして開発を捉え直している。企画構想の段階では、なぜそれを作るのか、本当は何が必要なのかを見極めることにAIを使う。改善運用の段階を見据え、継続的に価値を生み続ける仕組みを最初から作り込む。

「いかに開発するか」の中央部分ではなく、その左右、上流と下流にこそ注力する必要があるという。

コンセプトデザイナーで、レビュー会議をスプリント会議に変える

上流の企画構想を、Slalomはどう変えているのか。ビジネス部門とIT部門の間で起きがちな対立構造を、新田氏は「持ち帰って議論して、1〜2週間後に返す」という進め方が生む構造として説明する。自然とお互いがお互いのことを見始め、本来向くべきビジネス価値から目がそれていく。

Slalomが社内で開発している「コンセプトデザイナー」は、この構造を変えるための事例の一つだ。目の前で議論しているものがその場で具現化され、業務部門と同じものを見ながらフィードバックをかけてその場で改善していく。これにより、レビュー会議が、スプリント会議に変わる。

会話しながら要件・設計・モックが生まれる

新田氏はここでライブデモに入る。画面には自然言語のチャット、左にエージェントのタスクカード、真ん中にキャンバス、右に生成中の要件が並ぶ。

初期情報としてエンタープライズナレッジ管理AIのプロジェクトブリーフや議事録をアップロードすると、エージェントが内容を整理する。次に「競合製品、技術トレンド、日本企業の導入事例、セキュリティ要件」の4視点でリサーチを依頼すると、エージェントが自らタスクを分解して報告書をまとめる。

さらに「プロジェクトブリーフから要件定義ドキュメントを生成してください」と伝えると、What、Why、Who、Wowの観点で要件が整理される。「AzureベースのRAGパイプラインと認証フローを含めたアーキテクチャをdraw.ioで作ってください」と依頼すればダイアグラムが、「Slack風のシンプルなUIでチャット検索画面のモックアップを」と伝えれば動くモックが生成される。

出てきたモックを見ながら、従業員が問い合わせをしたときにどんな情報を出すのか、参考情報をどのように出力するのか、フィードバックをどう受け取るかまで、動くものを前提に要件を詰めていく。最後にはCDO（最高デジタル責任者）が30秒で状況を把握できるエグゼクティブサマリーまで、同じ会話の流れで作り上げてみせた。

自社の開発現場から生まれたシステム

このコンセプトデザイナーは、外販するプロダクトとして作られたわけではない。プロジェクトをAI駆動で進めていく上で必要だったから作り始めた、と新田氏は明かす。

アイディアをベースに1日で動くモックを作り、その次にエージェントごとの得意領域を分けてオーケストレーションレイヤーを構築、会話・要件整理・モック作成といったスキルをプラグインとして追加していった。裏側のLLM層では、リサーチが得意なGemini、音声会話が得意なOpenAIといった特性を組み合わせて使い分ける構成にしている。

チームで使う必要が出てきた段階で、別のメンバーがAWS上に用意していたAIエージェント本番実装用のテンプレートに乗せ、今は本番運用している。AnthropicやOpenAIとの協業、AWSなどのクラウドプロバイダーとの強固な関係がある環境が、この働き方を支えている。

コンセプトデザイナーが象徴するのは、Slalomが方法論を語るだけでなく、自らの現場で必要な仕組みを作り、活用し、改善する姿勢である。外販するために作られたものではなく、プロジェクトを前に進めるために生まれ、チームでの利用を経て本番運用まで進んだ。

自分たち自身が最初のユーザーとなり、そこで得た知見を次の開発やクライアント支援に反映していく。ツールそのものだけではなく、この実践と改善のサイクルが、SlalomのAIネイティブ開発を支えている

AIを前提に、プロセスごと作り変えられるか

新田氏は最後にメッセージをまとめた。問われているのは、AIを前提にプロセスごと作り変えられるかどうか。作って終わり、少しずつ保守する、という流れの時代は終わりつつある。

AIが作ることが当たり前になる時代には、人はAIが作ったものの価値をコントロールし、価値を生み続けるループを回す側に立つ。責任の重心が、そちらへ移っていく。

続くセッションでは、この重心の移動を組織側の役割としてどう定義しているのか、Solution Ownerという新しい役割を通じて語られる。

価値定義と実装をつなぐ「Solution Owner」の役割

エンジニアの実装は加速する。しかし、方向を間違えれば、使われないものが高速に量産されるだけだ。日永氏は、実プロジェクトのチーム構成とアウトプットを開示しながら、ビジネスとテックをつなぐSolution Ownerの責任と、その根底にあるコンテキストハブの考え方を語った。

Slalom
Delivery, Solution Ownership / Senior Consultant
日永 悠貴（ひなが ゆうき）氏

日永氏は2022年、アメリカ・シカゴでSlalomに入社。Solution Ownerとして約3年間、ヘルスケア・エネルギー・保険など多業界でクラウドやデータ戦略を中心とした開発プロジェクトをリードしてきた。2025年にSlalom Japanへ異動し、米国での経験と日英バイリンガルの強みを活かして日本市場でもプロジェクトを推進している。

エンジニアが2〜4人でも、開発スピードが2.5倍になる

日永氏は、Slalom Japanで進行中のAI駆動開発プロジェクトのチーム構成から話を始めた。Solution Owner、テクニカルアーキテクト、UI/UXデザイナー、そしてエンジニア2〜4人。当該プロジェクトでは、従来と比べてエンジニア数は20〜50%に抑えながら、開発開発スピードは約2.5倍になっているという。

エンジニアが加速しているからこそ、進むべき方向をビジネス側と正しく合わせることの重要性は増している。方向がずれれば、使われないものが高速にでき上がるだけだ。

この方向合わせを、他ロールと連携しながらメインで担うのが、Solution Ownerだ。

既存ロールの複合として、新しい責任の形を担う

Solution Ownerは、スクラムマスター、プロジェクトマネージャー、ビジネスアナリスト、プロダクトマネージャーという4つのロールを複合的に併せ持つ役割として整理されている。

日永氏はここで、興味深い切り口を提示する。Solution Ownerは新しい仕事というより、既存のPMやプロダクトマネージャー、テックリードが引き受けられる新しい責任の形ではないか、という捉え方だ。

「自分の仕事とは違う」と切り離すのではなく、「こういう責任の持ち方があるのだ」と受け止めてほしい、と日永氏は語る。

インテイクからリリースまで、一貫して責任を持つ

新しい責任の形とは、ビズとテックの橋渡しを、価値定義から実装、リリースまで一貫して担うことだ。

要件定義フェーズでは、価値の定義、そこから生まれる機能の定義、機能ごとの要件の定義をチームでの議論を通じて行う。開発フェーズではスプリント推進、その後は完成した機能の検証まで責任を持つ。自分が定義した価値が、機能として満たされているかを最後まで確認する。

AI駆動という文脈では、これらの業務をスキルで自動化・高速化していく。ただし、業務を自動化しただけではビズとテックがつながったことにはならない。つなぎ役として鍵になるのは、別のレイヤーだ。

コンテキストハブという統一台帳

日永氏はここで、コンテキストハブを定義する。「AIが読める状態で管理されたプロダクト文脈の統一台帳」。みんなが参照でき、コンテキストをすべて保管する場所、というイメージだ。

実プロジェクトでは、リポジトリ内にマークダウンファイルを構造的に配置して管理している。PRD（Product Requirements Document、プロダクト要求仕様書）、ユーザーストーリー、ミーティング議事録、議事録から生まれた要件のコレクションなどを恒常的に置いておく。

このハブに対して、Figma、GitHub、Jira、Confluence、Playwrightといった既存の開発ツールがMCP（Model Context Protocol）サーバーを通じてアクセスする。AIエージェントもエンジニアも、同じ文脈を見ながら動ける状態になる。

従来と何が変わるのか

コンテキストハブの効果は、従来との比較で見ると輪郭が濃くなる。

従来は、要件収集で議事録が口頭にとどまり抜け漏れが生じる。要件定義や実装では、ソリューションアーキテクト、テクニカルアーキテクト、デザイナー、Solution Ownerといった複数ロールが集まらないと決まらない。受け入れ基準は抽象的で人による解釈ブレが起き、手戻りが発生する。管理業務に時間が奪われ、機能検証は責任分離が起きがちだ。

コンテキストハブがあると景色が変わる。議事録の構造化はスキルで自動化され、要件抽出や仕様変更要求（チェンジリクエスト）の抽出まで機械的に行える。受け入れ基準はコードベース全体を参照しながら詳細に書き出せる。認識合わせの多くを非同期で、Solution Owner単独で完結できるため、集まる回数そのものが減る。手戻りも大きく減った実感があるという。

管理業務はスキル化に向く領域が多く、時間削減と効率化が進む。機能検証も、受け入れ基準からテストケースを作成しやすく、実行結果をコンテキストハブに残せる。「チームとAIで共通のコンテキストを持つ」ことで、無理をしていない、システマチックにスケーラブルな高速化が実現する。

ユーザーストーリーが10〜30分で仕上がる、実際のフロー

日永氏は、ここで自分がユーザーストーリーを作る流れを具体的に開示した。

Jira上のプロダクトバックログには、テンプレートだけが入った空のユーザーストーリーがある。Solution Ownerはまず「create story」スキルを使う。JiraからGitHub上のコンテキストに、テンプレートと指示を持たせたマークダウンファイルを作成する。

次に「write AC（Acceptance Criteria、受け入れ基準）」スキルが、サブエージェントを呼び出してプロダクト目線、エンジニア目線、テスター目線という多角的な視点から受け入れ基準を書き出す。この際、PRD、エピック、ミーティングノートといった関連コンテキストをコンテキストハブから読み込んで生成する。

ここで最初のバージョン（V1）ができるが、日永氏はAIの出力を必ず人間が確認する重要性を強調する。純度の高いコンテキストで精度は上がるが、ハルシネーションや指示違反、整合性のずれは起きる。この判断こそ、自分が積み上げてきた専門性と経験が生きるところだと語る。

V1を人手で整えてV2にしたのち、「review AC」スキルでコンテキストを集め直し、複数の視点から整合性・一貫性を大量にチェックさせる。レポートとして完成度評価と推奨アクションが出るので、それを反映して修正版のV3が生まれる。最後に「sync story」スキルでフォーマットを整え、Jiraに反映する。

このフローで、今まで数人が1時間以上かけていた1つのストーリー作成が、10〜30分でより高精度かつ詳細に仕上がる。「受け入れ基準を書いたことがある方なら、感動していただけるレベル」だと日永氏は語る。

Speed to Value、8スプリント中の大胆なピボット

日永氏はここで、コンセプトを一つに絞る。Speed to Value。できたスピードを価値に活かし、価値へのスピードそのものを追求する考え方だ。

要件定義・ドキュメント作成・プロジェクト管理の高速化で生まれた余力を、価値探索に注ぐ。これが違いを生む。

実例として、8スプリントあるプロジェクトのスプリント4で、実際のユーザー検証を行ったケースが紹介された。技術検証まで済ませて、これから実装に入る予定だった機能Dよりも、機能Xの方が良さそうだという洞察が得られた。

従来なら、ここで方針を変えるのはほぼ無理だ。ステークホルダーの合意も、技術的な作り直しも重い。AI駆動開発の環境では、これを1スプリント内で覆せる。価値整理、機能定義、要件定義、データモデル構築、UIデザインまでを2週間内で完結させる。次のスプリントから、そのまま実装に入れる。「今までなら本当に考えられない」と日永氏は語った。

正しい方向に加速している状態でこそ、ユーザーの声を取り込んだ計画変更が「手戻り」ではなく「進化」になる。

Stay Hands-on / Learn how to unlearn

まとめとして、日永氏は経験から得た2つの心構えを共有した。

1つ目はStay Hands-on。まず自分の手を動かして試すこと。コンセプトで理解しているのと、手を動かして得られる解像度はまるで違う。マニュアルで繰り返している議事録作成のような作業から、小さくスキル化して始めればいい。完璧なものを作ることではなく、まず始めて改善し続けることが大事だ。

2つ目はLearn how to unlearn、再学習する姿勢。AIの進化と変化はもはや対応するものではなく、当たり前のものとして受け入れる。自分のスキルや知識は武器として持ちつつ、慣れ親しんだ開発プロセスや働き方を捨てられるか。この態度をチーム全体、会社全体が持てるかどうかが成否を分ける。

エンジニアが加速している中で、正しい方向に早く進むには、ビジネスとテックの両目線を併せ持って価値定義から実装、リリースまでを一貫して定義する役割が要る。Solution Ownerはコンテキストハブを整備し育て続けることで、正確かつ高速な開発をリードし、Speed to Valueを実現するプロセスを回していく。

ここまでの2つのセッションをつなぐと、SlalomのAIネイティブ開発の輪郭が見えてくる。

コンセプトデザイナーが企画と設計をその場で具体化し、Solution Ownerが価値定義からリリースまで進む方向を合わせ、コンテキストハブが人とAIに共通の文脈を与える。ツール、プロセス、組織を別々に変えるのではなく、一体として設計することで、Speed to Valueを実現している。

重要なのは、単に作業時間を短くすることではない。高速化によって生まれた余力を価値探索に振り向け、ユーザーの反応を踏まえて、作るもの自体を変えられるようにすることだ。Slalomが目指しているのは、速く作る開発ではなく、正しい価値へ速く到達する開発である。

Q&A セッション

Q. AIネイティブで開発速度が10倍になったとして、逆にボトルネックになった工程はありましたか？

新田氏: 正直なところ、AIがどんどんものを作ってくれるので人間がボトルネックになる、という現象は我々自身が実体験しています。Claude CodeやCodexといったコーディングエージェントが出てから、AIが大量に作れるようになった結果、レビュー側が非常に大変になりました。そこから徐々に、作らせるものを小さくする、本当に価値を生むところだけを作らせる、という形でAIの動きを制御するプロセスに変わってきました。

日永氏: 開発側のプロセスは割と決まりやすいのですが、要件定義のインテイク側はかなり詰まります。人数の問題もあり、開発が加速すると要件定義や価値定義、判断のところがボトルネックになる、というのが実感です。

Q. Solution Ownerで特に大変と思うことは何ですか？

日永氏: ロールがいっぱいある分、汎用性が高くて「これだけやっていればいい」というものがないんですよね。チームがうまく回るように動きつつ、クライアントとのコミュニケーションも担う。私はよく、開発チームをクライアントから守るシールドになる、という言い方をします。エンジニアはエンジニアにフォーカスするのが一番効率が高いので、そこの翻訳やコミュニケーションのトラフィックをコントロールする役割は、時に難しさがあります。

新田氏: 場面によって帽子を付け替えて進めていくので、自分が学ばなきゃいけない領域、理解しておかなきゃいけない領域がやっぱり多いですね。AIがまとめて作ってくれても、妥当性を判断し検証するのは人間なので、自分自身の能力もAIを使いながら高めていく働きが必要になります。

Q. AIを使う開発からAIを前提にした開発へ移行する際、最初に変えるべきなのは要件定義、設計、レビュー、チーム体制のどこですか。現場で一番抵抗が落ちやすいポイントは？

新田氏: 要件定義や設計、実装をそのまま変えていくというよりは、そもそも業務部門とのコミュニケーションの仕方、情報の蓄積の仕方、成果物と承認の進め方といった全体プロセスを変える必要があります。要件定義書や計画書を作って上司が承認して、という人間のゆっくりしたペースを、AI駆動開発は待ってくれないんですね。一部分だけ変えるのではなく、成果物・承認・確認の仕方を含めた全体プロセスを見直すのがポイントです。

Q. テック×ビズによってコンテキストが膨大になるかと思いますが、AIが適切なコンテキストを選択できるようにするには、インデックスやマッピングを作るところからすべきでしょうか？

日永氏: 個人的にはインデックスやマッピングはそこまで作り込んでいません。まず膨大になるのはその通りですが、コンテキストハブは何でも入れればいいわけではないんです。今までの会議資料を全部ぶち込んでしまうと、逆にミスリーディングになる。本当に大事なものを入れるのが大前提です。適切なコンテキスト選択のためには、私はスキルに「何を参照すべきか」を明示的に書いています。ユーザーストーリーを書くならエピックや関連ストーリーは参照すべきだけど、無関係な画面は参照する必要がない。類似性のあるものを文脈に合わせて明示することが、スキルやエージェントで簡単に実行できるポイントです。

Q. SOとPDM（プロダクトマネージャー）の違いをもう少し教えてください。従来ロールの経験者がAIネイティブ時代にまず身につけるべきスキルは何ですか？

新田氏: AI駆動開発をやる上で一番大事だと感じたのは、過去に縛られないことです。アンラーンする姿勢、今までのプラクティスや自分の成功体験に縛られずに新しいやり方を学んでいく。吸収力が高い人と一緒にやると、変化の速度も速いし、課題に対しても「じゃあこう変えてこう価値を出そう」というディスカッションがすぐでき、チームの生産性も上がります。

日永氏: 大事なのはマインドセットだと思っています。スキルややり方は学べますが、変化をどう捉えるかというマインドセットがないと、いくら道具があっても動かせなくなる。アダプティブに、柔軟に対応できる心構えが非常に大事です。SOとPDMの違いという意味では、SOには足りないところを全部拾う意識がすごくあります。プロダクトだけじゃなくてチームのマインドセットやコンディションも見て、コミュニケーションがうまくいかないときはそちらに寄り、スクラムのプロセスが機能していないときはスクラムマスター寄りに動く。この足りない部分を常に埋め続ける役割が、少し違うところかと思います。

Q. AI駆動開発でSOの役割がとても重要になると感じました。特に意識しているポイントや大事にしていることは？

日永氏: チームって、変化がみんな大変だと思うんですよね。学び直しを迫られていて、エンジニアだけじゃなくビジネス側もそう。チームがそこをうまくトランジションできる場を作るのは、個人的に非常に大事にしています。方向性が見えれば、基本的にみんなうまく動けると思っています。

渡邉氏: 複数の専門性と変化への適応力を併せ持つ人材を育成することは非常に難しいんです。マインドセットとともにこうした人材を育てられるのは我々の武器で、彼らには今後も次のエンジニアやソリューションオーナーを育てる役目を頑張ってもらおうと思っています。

Q. AIネイティブ開発が進むと、強いエンジニアの定義は「実装力が高い人」から「AIを使って価値に接続できる人」へ変わるのでしょうか。Slalomではどのような人材が活躍していますか？

新田氏: 「AIを使って価値に接続できる人」というのはいいキーワードだと思います。もう一段深掘りすると、価値とは何かというところです。我々はクライアント向けのビジネスをしているので、クライアントの売上や収益が上がる、成長につながるところが第一の目標です。生産性を上げて余力を作るのではなく、その余力の結果ちゃんとお金が儲かっているかが問われる。目の前の技術課題をクリアした先に何が起こるかを想像しながら開発できる人、目標意識が高くて自分で試行錯誤する人が活躍しています。

Q. コンテキストハブは重要と感じました。最初に整備するべき情報は何でしょうか。逆に最初から作り込みすぎない方が良いものはありますか？

日永氏: 最初から完璧なコンテキストハブを作るのは無理だと思っています。全体的にそうで、まず何かしら作ってみるだけでも違います。プロダクト開発ならPRDのような要件定義から、目的・ペルソナ・既存プロセスといった分かっているものをまとめるのが割と王道です。プロジェクトによって違いますが、コアの情報から入れて、それを機能に落としていく。むしろ整備し続ける方が大変で、作るのは最初は割と適当に入れてもできてしまうので、最初は小さめから始めた方がいいと思っています。

Q. クライアントも含めて認知フレームワークやマインドセットの移行が起きている事例はありますか？

新田氏: AIが入ることで、今まで技術的に難しかったことがクリアできるところはたくさんあります。ただ、我々が扱うのは1つのシステムではなく、既存システムの上に人のプロセスが乗っている構造なので、1つを効率化しても全体の効率性は生まれなかったりします。クライアントの中でも「これいいよね」と推進していくチームと、既存を守っている人たちの間には大きなギャップがある。そこを徐々に解きほぐしていく、動いた成果や結果を見せて共有しながら、認識を変えていく草の根活動も必要になります。

Q. AI駆動開発でエンジニア数が減ってもベロシティが上がる話はインパクトがあります。一方で、チームの学習機会や暗黙知の継承が弱くなる懸念はないのでしょうか？

日永氏: 個人的にはむしろ逆でした。もともと快適ではない領域にみんなが足を踏み入れているチャレンジではあるのですが、それによって個人レベルで新しい挑戦ができています。エンジニアも、もともとフロントエンドメインだった人がフルスタックに行けるようになったり、これまでやる機会がなかった領域に踏み込めるようになりました。加えて、私たちのチームにはテクニカルアーキテクトに非常に強い方がいて、PRコメントなどを通じてチーム全体が学べています。AIで進むのが速くなったからこそ、フィードバックを返せる時間が取れる。学習機会や暗黙知の継承は、むしろ機会と捉えて、それができるプロセスやフレームワークを作るのがあるべき姿だと思っています。

文：坂本 奈穂
※所属組織および取材内容は2026年7月時点の情報です。

Slalom株式会社

• Slalomでは、AIを前提とした開発プロセス、チーム体制、コンテキスト管理の設計から、実プロジェクトでの検証・実装までを支援している
• 自社の開発現場で人がボトルネックになっている、AIツールを導入したものの全体の開発スピードや事業成果につながっていない、どの業務から見直すべきか分からない。そうした課題を抱えている場合は、SlalomのWebサイトからご相談ください

https://www.slalom.com/jp/ja/who-we-are/locations/japan

Slalom株式会社の採用情報

• ビジネスとテクノロジーの両面から、AIネイティブな開発をリードするメンバーを募集中

https://www.slalom.com/jp/ja/careers