こんにちは。ソリューションアーキテクトの水野です。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 です。趣味は、ドラマや映画のエキストラに参加することです。

はじめに Power BIでレポートを作成する際、データの取り込み元としてExcelやCSV、あるいはSQL Serverなどのデータベースを利用するのが一般的です。 しかし、インポートモードで扱うデータが「数十GBクラスの大容量」になったとき、その運用に頭を抱えたことはありませんか？今回は、30〜60GBという膨大なデータを扱うプロジェクトにおいて、運用効率化のためにSharePoint接続を検証・導入した際の知見を共有します。 対象読者 ・Power BIで扱うデータ量が肥大化し、パフォーマンスや運用に課題を感じている方 ・複数人でダッシュボードを共同開発しており、ファイルの

技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。 しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。 人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。 その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。 今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 「教える」から「引き出す」への転換 QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。 しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。 テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。 そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。 もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。 しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。 そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。 そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。 私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。 図：銀座コーチングスクールのコーチングピラミッドを参考に作図 https://www.ginza-coach.com/overview/feature/curriculum.html （参照日:2026/3/21、最終更新日2026/1/20） 自己基盤 まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。 これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。 これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。 安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。 泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。 コーチングマインド コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。 コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。 今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。 相手の中にある視点や気づきをどのように発見し、どう繋げていくか。 この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。 その「答え」は、実は相手が自覚していない場合があります。 むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。 そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。 コーチングの技術を品質保証に活かす コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。 上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。 一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。 ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。 専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。 第３回 でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。 QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。 「どういう状態になれば、自信を持ってリリースできますか？」 「あなたがステークホルダーであればこの製品に対してどう感じますか？」 「あなたが知っているステークホルダーはどのような人ですか？」 このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。 自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。 専門性の組み合わせ：テスト実行との組み合わせ テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。 テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。 「今、テストを実行していて何に気づきましたか？」 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」 「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。 これが、テスト実行における個人のスキルアップや深い洞察に繋がります。 おわりに QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。 それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。 QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。 例えば、バグが放置されがちな現場があったとします。 ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。 コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。 プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。 そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。 コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。 しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。 この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts .