はじめに コンスタナイズー！（気さくな挨拶） ココナラのDevOpsグループCREチームのy.s.(@inu_no_hou)です。 皆さん、constantize というメソッドをご存知でしょうか。文字列からRubyの定数（クラス）を動的に解決するActiveSupportのメソッドです（ぎえー）。 私がココナラの会計システム（のちに自らマイクロサービス化することになる）のコードで初めてこれを見たとき、正直に言うと震えました。 def factory(acct_event, option = {}) klass = acct_event.event_code.gsub(/^eve

こんにちは。ソリューションアーキテクトの水野です。AWS のプロフェッショナルサービスでは、ブラザー工業株式会社 プリンティング＆ソリューションズ事業にてアジャイル導入をご支援しています。今回、同事業のエンジニアの方々に AI-DLC を用いた新しい働き方を体験していただくため 2026 年 2 月と 3 月にそれぞれ 3 日間にわたって「AI-DLC 体験会」を開催しました。本ブログでは、私が聞き手となり、体験会に参加された八十嶋様、宇野様、前田様、梅本様にインタビューした内容をまとめました。 AI-DLC（AI-Driven Development Life Cycle）は、ソフトウェア開発ライフサイクルに AI を全面的に組み込んだ新しい開発手法です。コーディング支援にとどまらず、要件定義や仕様検討といった上流工程から、実装、テスト、デプロイまで、開発の全フェーズで AI を活用します。また、ダイナミックなチームコラボレーションが特徴で開発サイドとビジネスサイドが短期間に集中して一緒に作業を行い素早くアウトプットを作り上げます。詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 をご覧ください。 想像を超えた可能性 水野（AWS）: AI-DLC 体験会 への参加のきっかけと、参加前後での印象の変化を教えてください。 前田: 上司との面談で話を聞きました。最初は普段使っている AI コーディング支援程度のものかと思っていましたが、実際に受けてみると全く違いました。目先の細かいアシストレベルではなく、もっと先を見据えた、将来的にスタンダードになるであろう開発手法を学べたと感じています。 宇野: 当初はコーディング支援やペアプログラミング程度のものかと想像していました。しかし、実際には上流工程から AI を活用し、エージェントを使ってペルソナ作成やユースケース作成、モックアップ作成まで行うことができました。過去に企画業務を 3-4 年経験していましたが、その頃やっていたことを AI にやらせるという新しい体験に驚きました。 梅本: 参加前から関連記事を読んでいたので、とても楽しみにしていました。記事では具体的にどう要件定義工程から進めるのかイメージできなかったので、実際に手を動かして体験できることに期待していました。社内のアジャイル開発において、アンテナを高く持って情報収集していた中でのワークショップだったので、非常に興味深かったです。 八十嶋: AWS から体験談や効果を直接聞いていたので、自分のチームで試せることに対して懐疑的な気持ちは全くなく、純粋に楽しみでした。AI のうまい使い方が見つからない中で、ようやく見つけることができたという気持ちでした。 2026 年 2 月開催時の様子 開発プロセスの変化と実践での工夫 水野（AWS）: 従来の開発プロセスと比較して、大きく変わったと感じる点は何ですか？ 梅本: 要件定義や仕様検討といった上流工程から AI を混ぜて議論していくところが大きく変わりました。実装段階では比較的 AI に渡しやすい部分もありますが、リファインメントで行っていた濃密な議論にどう AI を混ぜるのか、自分だけではイメージできませんでした。AI-DLC を取り入れた時にチームのプロセスとして変わる部分だと感じています。 八十嶋: プロダクトオーナーとデベロッパーの距離が縮まり、お互いが補完して理解し合う関係になると感じました。 宇野: 既存システムに対して AI を活用する際、ドメイン知識が必要だと痛感しました。事前情報として「既存ではこういうことをやっているので、これを前提にユースケースを考えてください」という指示をしないと、的外れな回答が出てきてしまいます。AI への問いかけ方が重要だと感じました。AI の回答は思ったより的確でしたが、どう問いかけるか次第で結果が大きく変わるので、問いかけ方の重要性を感じました。 水野（AWS）: 体験会で直面した困難について教えてください。 前田: 既存システムのデータベースから直接データを引っ張ってくる部分が最大の困難でした。データベースのスキーマのドキュメントがない状況で、どうやってデータを取得するか悩みました。最終的には、データベース定義の DDL 文とソースコードをまるごと解析して、「データをどうやって取ってくるか調べてください」と AI にお願いする戦略を取りました。やらせてみたらできてしまい、繋がった時には感動がありました。 宇野: 既存システムにどう適用するかが最大の困難でした。プロンプトで指示を出してもなかなか伝わらない部分がありました。協力会社が作った 500 ページぐらいの PDF ファイルがあったので、それをまるごと AI に渡してみることにしました。今回は時間の制約があったため、最初のコンテキスト作りに 1 日目の半分ぐらいしか時間をかけられませんでしたが、本格的にやるならもう少し時間をかけるべきだと思いました。 梅本: 集中力の維持が大変でした。私はインセプション（開始フェーズ）が一番集中力を維持するのが大変でしたが、プロダクトオーナーの方はコンストラクション（構築フェーズ）が一番疲れたと仰っていました。既存のポジションによって、集中力が途切れやすいフェーズが違うと気づきました。解決策として、1 時間に 1 回休憩を取るというアクションと自分が得意なフェーズでドライバーをやるということを実施しました。私はコンストラクションでドライバーを担当し、インセプションでは手を貸す側に回りました。普段慣れている情報に触れる方が楽に感じやすいと思います。 必要なスキルと人材育成 水野（AWS）: AI-DLC のように AI を中心とした開発の場合、エンジニアに必要なスキルセットは何だと思いますか？ 前田: 一般的なプログラミングはすべて AI がやってくれる世界になりつつある中で、複雑なシステムになればなるほど、ドメイン知識の重要性が非常に大きくなっていくと感じています。それを持っているか持っていないかで大きく変わります。組織としてドメイン知識を教えていくような体制が整っていれば、活躍できる場はあると思います。 宇野: 問いかける力が非常に重要だと思います。特に既存システムに関しては制約があるので、それを見越した上で論理立てて話さないといけません。AI はパッと見それっぽい答えを出してきますが、よくよくコードを見てみると全く使い物にならないこともあります。エンジニアは普段集中してプログラミングしているとコミュニケーションをしませんが、どう問いかけるかというのが新しいスキルセットだと感じました。 水野（AWS）: ジュニアエンジニアの育成についてはどう考えていますか？ 八十嶋: 今回ジュニアエンジニアの方は大変そうでした。スクラムの時は手を動かしながら教えてもらえる時間がありましたが、AI がアウトプットを出す中で、ジュニアエンジニアがキャッチアップする間がないまま進んでいきます。ジュニアエンジニアの方がキャパオーバーを起こしていたので、そこをケアする開発サイクルを考えないと課題になると感じました。プログラミング経験が少ないメンバーは、一見活躍できるように見えても成長していない可能性があるので、成長機会の提供が必要だと考えます。 梅本: 実務では AI が書いてしまうため、技術的なところを学ぶのが難しくなってきています。社内でも、データベースなどの領域で代表的なハマりどころを経験して、それを自力で解決するという体験をする機会を設けた方がいいという意見がありました。コードを自力で書き直す経験が実務だと取りづらいので、そういう研修が必要だと感じます。 　　　 2026 年 3 月開催時の様子 組織展開に向けて 水野（AWS）: AI-DLC を組織に展開する際、どのようなプロジェクトが向いていると思いますか？ 梅本: コンテキストが少ないプロジェクト、つまり新規プロジェクトの方が比較的 AI-DLC を取り入れやすいと感じました。 宇野: 私は既存プロジェクトでも可能性はあると思います。ドキュメントがある程度しっかり作られていれば、それをコンテキストとしてインプットすることで、AI を簡単にオンボーディングできます。逆に新規プロジェクトだと、まだ関係者間での合意形成や目的・ビジョンが見えていない場合があります。既存プロジェクトであれば、合意形成やコミュニケーション範囲がある程度決まっているので、そういう意味では既存プロジェクトでも十分実施可能だと思います。 水野（AWS）: 組織展開における最大の課題は何だと考えますか？ 八十嶋: 品質管理やセキュリティの方々は、これまで門番的に振る舞うことが是とされてきました。AI-DLC ではこれらのゲート型のプロセスがボトルネックになりそうです。 水野（AWS）: 具体的にどのような展開戦略が有効だと思いますか？ 八十嶋: 内部向けサービスで使いながらプロセスを作り、その後外部向けシステムでも使えるようにしていきたいです。他部門への AI-DLC の価値説明としては、企画の人が言語化できれば、シニアエンジニア 1 人いれば 1 日か 2 日ですぐ試せる状態になる、つまりスクラップアンドビルドが非常にしやすくなったという点を強調したいと思います。 まとめ 今回の AI-DLC 体験会 を通じて見えてきたのは、AI-DLC が単なる効率化ツールではなく、ソフトウェア開発の在り方そのものを変革する可能性を秘めているということです。参加者の皆様が口を揃えて語ったのは、「想像していたものと全く違った」という驚きでした。コーディング支援という枠を超え、企画段階から AI が開発パートナーとして機能する世界を体験できたようです。 一方で、この変革には新たな課題も伴います。AI が高速でアウトプットを生成する中で、人間はどこまで検証すべきか。ジュニアエンジニアはどう成長機会を得るのか。品質管理やセキュリティ部門とどう協調するのか。これらの問いに対する答えは、まだ完全には見えていません。しかし、参加者の皆様が実践を通じて得られた知見は、これから導入を検討される組織にとって貴重な道標となるでしょう。 特に印象的だったのは、「ドメイン知識」「問いかける力」「言語化能力」という、一見古典的とも思えるスキルの重要性が、AI 時代においてむしろ高まっているという指摘です。AI が技術的な実装を担う時代だからこそ、人間は「何を作るべきか」「なぜそれが必要か」を明確に定義し、AI に的確に伝える能力が求められます。これは、エンジニアリングとビジネスの境界が曖昧になり、全員がプロダクトの本質に向き合う必要がある、新しい開発文化の萌芽と言えるかもしれません。 インタビューさせていただいたブラザー工業 P&S 事業 SC 開発部のエンジニアの皆様 左から 八十嶋 瑞穂（チーム・マネージャー） 梅本 匠 前田 康佑 宇野 大　（敬称略） 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

なぜGoogle Workspaceは組織の力を引き出すのか Google Workspaceは、個人の力に頼るのではなくチーム全体の生産性向上を重視するGoogle独自の思想を体現しています。その本質は、単に個人の作業を効率化するだけでなく、従来の情報を送る・交換するやり方から、クラウド上で共有するコラボレーションの働き方へ、仕事のあり方そのものを根底から変える力を持つ点にあります。