CDK導入の壁は“ハードモード”？ 現場の悲鳴を救うDevOps Agentの登場

AWS CDKの最大の魅力は、高い再利用性と抽象化にあります。

TypeScriptなどのプログラミング言語を用いてAWSリソースを定義できるため、たとえば一度作成した構成のリージョン設定だけを変更して別環境に複製するといったことが容易に行えます。 

Constructによって一部設定が抽象化されるため、開発者の負担は大きく軽減されます。 

一方で、学習と保守といった観点では扱いづらさが残ります。AWS CDKを実務で使いこなすためには、インフラの知識だけでなく、TypeScriptの型システムやアルゴリズムの理解、さらには複雑な環境構築が必要です。

初学者にとってこの学習コストはまさに“ハードモード”であり、チーム全体へ定着させる際の大きな足かせとなっていました。 

この壁を乗り越える希望となるのが、2026年4月に一般提供が開始された生成AIサービス「AWS DevOps Agent」です。 

AWS DevOps Agentは、AWSアカウント内のリソースをモニタリングし、インシデント管理から予防保全の提案までを自動で行うAIアシスタントです。

性能はアップデートのたびに向上しており、現在では日本語にも対応しています。さらにGitHubやSlack、PagerDutyといったサードパーティツールとの統合も可能です。 

本格的な導入にあたって気になる利用料金ですが、エージェントの実行時間に対して課金され（1秒あたり約0.0083ドル）、仮に24時間稼働させた場合は1日約10万円のコストがかかります。 

個人利用としてはハードルが高いものの、企業向けのサポートプラン等に加入していれば一定の割引が適用されるため、法人利用においては十分に導入を検討できる範囲といえるでしょう。 

こうした数ある機能のなかでも、AWS CDK運用において特に期待が高まっているのが、2026年6月にプレビュー版として登場したリリース管理機能です。

この機能は、AWS CDKやTerraformで定義されたコードをAWS環境へ本番適用する前に、AIがコードの不備を事前チェックしてくれるというものです。 

どれほど熟練したエンジニアであっても、本番環境への変更適用には心理的な不安が伴います。

リリース管理機能を活用し、本番前にコードレベルでの評価を行うことで、「確実に動く」という安全基準を担保し、デプロイ時の不安を大きく取り除くことができるのです。

なお、本機能は現在プレビュー版であるため、現時点での業務適用は困難かなと思われます。

バージニア北部リージョンに構築したAWS DevOps Agentでのみ利用可能という制約がありますので、検証やテスト導入を行う際は、この点にご留意ください（※2026年7月18日時点の情報です。最新情報は公式サイト等でご確認ください）。 

実務を想定した徹底検証！現場目線で挑んだ6つの独自シナリオ

「AIが事前チェックをしてくれるのは素晴らしいが、はたして実務の複雑な要件にどこまで通用するのか？」 

私は、そんな疑問を抱いていました。

初学者がAWS CDKを定着させるためのハードルを、AWS DevOps Agentは本当に下げてくれるのか。コードベースの検証において、AIはどのような精度で、どのようなアウトプットを返してくるのか。

自らの目でAIの現在地を確かめるべく、実務を徹底的に想定した検証プロジェクトをスタートさせました。 

検証環境を構築するにあたり、誰もがイメージしやすいよう、Amazon CloudFront、Amazon Simple Storage Service（S3）、Amazon Elastic Compute Cloud（EC2）を用いたシンプルな構成の、中小規模のWebサービスを想定しました。 

真の実用性を測るため、単に正しいコードを読ませるだけでなく、意図的にさまざまなトラブルを混入させた6つのシナリオと15の検証観点を用意しました。

一般的なHTTPS未対応といった障害だけでなく、AWS CDK特有のアンチパターンであるAMI IDやアカウントIDのハードコーディングを注入。

さらに、構築済みのインフラをAWSコンソールから直接操作してしまう手動ドリフト（コードと実環境の乖離）や、環境構築パッケージが未インストールの状態まで網羅しました。 

現場で実際に起こりうるトラブルをAIがどう捌くのか。その実用性を検証する準備が整ったのです。なお、今回の検証で使用したCDKコードはGitHub上で公開しています。

記事を読んでAWS DevOps Agentの実力に興味をもたれた方は、ぜひご自身の手でも検証を試してみてください。

今回の検証で使用したCDKコードはこちら

AIの実力とハルシネーションのリアル。検証から見えた得意領域と課題

検証の結果、AWS DevOps Agentコードレビューにおいて大きな成果をあげました。特にGitHubと連携させたシナリオ（パターン１・２）では今回設定した検証項目をすべて検知しました。 

AWS CDK特有のハードコードAMI IDやアカウントIDといった問題については、高い精度で検知できることが確認されました。

さらに、GitHubのプライベートリポジトリとのセキュアな接続も問題なく行えるため、高いセキュリティ要件が求められるプロジェクトでも導入できること、そしてコードレビューにおけるAWS DevOps Agentの有効性が確認できました。 

一方で、実環境の検証だからこそ見えてきた課題もありました。手動で行われたリソース変更（ドリフト）の検知において、ハルシネーションが確認されたのです。 

検証では、Amazon Elastic Container Service（ECS）の設定を手動で変更しました。しかしAIは、変更していないはずのセキュリティグループの設定が変更されたと判断してしまったのです。

また、EC2上に直接格納されたコードをチェックするシナリオでも、AIが対象を上手く読み取れないケースが発生しました。 

これらの結果から、リリース管理機能はまだプレビュー版であり、ドリフト検知やプロンプトに改善の余地があることが分かりました。 

しかし、これは決してツールが使えないという意味ではありません。

「GitHub連携によるコードレビューには極めて強いが、実環境の直接的な手動変更検知はまだ発展途上である」という特性を正しく理解し、得意領域に絞って活用することが重要です。

適切な環境と設定を用意すれば、AWS DevOps Agentは強力な味方となります。

プロジェクト固有ルールもAIが担保。属人化を防ぐスキルセット機能の威力

AWS DevOps Agentの機能のなかで、現場のエンジニアにとって有用な機能のひとつが、スキルセット機能です。 

開発現場では、プロジェクトごとに固有のルールやセキュリティ要件が存在します。スキルセットを活用すれば、こうした独自のドメイン知識をAIに注入することができます。

不特定多数のメンバーが開発に関わり、品質にブレが生じやすい環境であっても、AIがプロジェクト固有の基準に照らしあわせてコードをチェックし、デグレードのリスク低減が気体できます。 

また、AWS DevOps Agentは、初学者にとってむずかしかったAWS CDKの学習環境を劇的に改善します。 

例えば、エラーが発生して行き詰まった際、エラーログを読み解く代わりに、AWS DevOps　Agentに対して「なぜこのエラーが起きたのか？ どう直せばいいか？」と自然言語で質問することができます。

AIが対話形式でスムーズに調査をサポートしてくれるため、初学者が挫折しにくく、AWS CDKの概念や実装方法をキャッチアップできるようになります。

AIは便利な道具から“開発パートナー”へ。AI SDLCが描く共創の未来

私は、この検証を通じて、これからの開発プロセスの未来像を実感しました。それは、近年ソフトウェア開発の現場で普及しつつある「AI DC」（AI駆動開発ライフサイクル）という考え方への統合です。 

生成AIアシスタントであるAmazon Qを活用してインフラのコードを書き、そのコードをAWS DevOps Agentが検証し、フィードバックを行う。

人間はそのフィードバックをもとに改修を重ねる。複数のAIが連携し、コード作成からレビュー、テスト、運用までをシームレスに支援するこのサイクルは、開発生産性を引き上げるものと考えています。 

複雑で学習コストの高いAWS CDKですが、AWS DevOps Agentのリリース管理機能やスキルセットを活用することで、その保守工数の削減や、品質向上に寄与する可能性が確認できました。 

プレビュー版ゆえのハルシネーションなどの課題は残るものの、それを補って余りある高いコードレビュー精度と、初学者を支える学習サポート機能は、現場の課題を解決する力をもっています。 

AIはもはや単なる便利ツールではなく、共にシステムをつくり上げる「開発パートナー」へと進化しています。AIと共創する新しい開発体験の第一歩として、ぜひご自身のプロジェクトでもAWS DevOps Agentの活用を検討してみてはいかがでしょうか。 

※本セッションの登壇動画は、こちらからご覧ください。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

実は構造が原因。改善活動が消える5つの共通パターン

熱意をもって自発的にはじめた社内勉強会やグループ横断施策を、1年後には自分も含めて誰もやっていない。 

あるいは上司の立場として「いい取り組みをしているな」と思っていたのに、知らないあいだにひっそりと終了していた。 

そんな経験をもつ人は多いのではないでしょうか。 

改善活動が自然消滅するのは偶然だけでは片づけられない要因があります。そこには構造的な問題があります。私のこれまでの経験から、消えていく改善活動は大きく5つの共通パターンに分類できます。

1. 属人化：推進者が異動した瞬間に終わる
2. バーンアウト：熱量が保てなくなった瞬間に終わる
3. 成果の不可視化：「何が変わったの？」に答えられない
4. 組織再編：「方針が変わりました」の一言で消える
5. 言語の断絶：現場の熱量が上層部に届かない 

なぜこのようなことが起こってしまうのでしょうか。その背景には改善活動を進めるプロセス上の要因が大きく影響しています。 

ここからは改善の火を消さないための3つの打ち手――「翻訳する」「巻き込む」「仕組み化する」について、実際の事例を交えてご紹介します。 

【打ち手1：翻訳する】決裁者を動かす言葉の選び方

最初は、「翻訳」の失敗事例から。 

これは翻訳が不足していた典型的な例です。 

「チームの雰囲気がよくなる」という言葉では、問題と改善の因果関係がみえません。結果として、マネージャーには「コストをかけて勉強会をする」という提案に聞こえてしまったのです。 

また、「複数チームで実施したい」という提案は投資規模が大きい印象を与え、マネージャーに重い判断を迫るものになっていました。 

こうした場合の打ち手は、「現場の言葉」を「上層部にとっての判断材料となる言葉」へ翻訳することです。 

例えば「雰囲気がよくなる」ではなく、「相談コストが下がる」「手戻りが週○時間減る」といった表現に変えると、改善が業務や成果へ与える影響の大きさを伝えられます。

なぜなら、上層部がみているのはコストや納期、品質などのKPIだからです。改善活動の話も、コストや納期、品質などのKPIに翻訳して説明する必要があります。 

したがってまず活動をはじめる前に「この施策を実施すれば、この数値が変わるはずだ」という仮説をたてる必要があります。

そして、まずは1チームで試して結果を示し、上層部が投資判断を行うハードルを下げることが重要です。 

また、同じプロセス改善でも、重視されるKPIは相手の立場によって異なります。誰に打診するのかを意識し、その人が判断しやすい言葉に置き換えることも大切です。

【打ち手2：巻き込む】人を動かす「体感」の場づくり

2つ目の事例は「巻き込む」に関係するものです。

この例で意識していただきたいのは「言葉で伝えれば、推進者と同じ熱量で動いてくれる」は幻想であるということです。 

巻き込んだ相手が提案内容を理解するだけでなく、納得して協力できる状態をつくることが大切です。 

そもそも、ふりかえりとはアクションそのものよりも、「体感の場」を設計することでプロセスをいっしょに体感することが大事なのです。 

そのうえで部長に「部長にきてもらえたらチームの士気があがります。一度、ふりかえりに参加していただけませんか」と声を掛け、場に招きます。

その際、「最後に一言いただけると助かります」と役割を渡しておくことで、当事者として関わってもらいやすくなります。 

さらに、あらかじめ自身のチーム内でもすりあわせを行い、活動の成果と魅力が120％伝わるよう意図的に設計しておくことも大切です。 

効果を報告するだけでは、動きにつながりにくい場合があります。そのために、巻き込み方も事前に設計しておきましょう。 

【打ち手3：仕組み化する】推進者がいなくてもつづく、設計の引き渡し

最後に紹介するのは、「仕組み化」にかかわる事例です。

表面上はうまくまわっているようにみえていましたが、参加者には「毎回素晴らしい資料を作らなければならない」という暗黙のハードルがあり、加えて誰がどの役割を担うのかも明確ではなかったのです。

運営の進め方も決まっておらず、一度エンジンが止まった際に再起動するスイッチ（改善の場）がなかったことが消滅の原因です。 

ここで本当に必要だったのは、「設計の引き渡し」です。

たとえば「資料作成は任意」などハードルを下げて無理なく継続できる形をあらかじめ整え、次回の担当決定や運営のふりかえりをプロセスに組み込んでおく。

参加者が自分ごととして関われる動機づけも設計しておくことが重要です。 

個人の熱量は、仕組みに変換されてはじめて組織の文化になります。推進者がいなくてもまわりつづける設計こそが、改善を定着させる鍵になります。 

改善の火を絶やさない、実践ロードマップ

前述の3つの打ち手を踏まえ、改善活動を組織に定着させるための具体的な5つのステップを紹介します。

STEP1：小さくはじめて事例をつくる
いきなり壮大な計画を上層部に提案しても、なかなか通りません。まずは自分が動ける範囲（週1時間を1ヶ月程度など）で小さくはじめて成功事例をつくります。 

このとき、「ここまでやって成果が出なければ一旦やめる」という撤退基準もあらかじめ決めておきます。うまくいかなければ無理につづけず、静かに閉じましょう。 

STEP2：成果を周囲へ「魅せる」
事例ができたら、その結果を周囲を巻き込むための材料にします。このとき、上層部への説明を想定し、仮のKPIを事前に設計しておきます。 

KPIが適切かどうかは、ふりかえりを通じて見直していきます。「何のためのKPIなのか」という観点も含めて改善しつづけることが大切です。 

STEP3：味方をみつけ上層部を巻き込む
まずは話を聞いてくれそうな味方をひとりみつけます。その味方とともに材料を整理し、有効な打ち手を考えます。

上層部にもち込む際は「数ヶ月後にふりかえりを実施し、必要に応じて軌道修正します」と上層部が判断しやすい提案を心がけましょう。 

STEP4：興味のある層を巻き込む
上層部の承認が得られたら、いきなり全社に広げるのではなく興味をもってくれた層から徐々に巻き込んでいきます。活動の一部を少しずつ渡し、巻き込んだ人が成功体験を積めるようにします。 

STEP5：仕組み化して広げる
人が集まってきたら、Aさんがやったら次はBさん、その次はCさんというように、無理のないもちまわりの仕組みをつくります。手上げ制だけにせず全員が少しずつ関わる形にすることで、負荷が分散されます。 

あわせてふりかえりを継続し、ゴールや進め方を更新していきます。みんなが無理なくつづけられる形に整えていくことが大切です。 

明日からできる「最初の一歩」

「いっていることはわかるけれど、どこからはじめればいいの？」という方へ、今日からできる具体的なアクションをお伝えします。 

相手の求める指標（KPI）がわからないとき 
上層部が何を求めているか想像するのには限界があります。わかる人（先輩や視座の高い人）を探して、「とりあえずの指標」を立てたうえで相談する形で巻き込んでみましょう。 

協力してくれる味方がみつからないとき 
チャットで募集しても返信がない場合、募集に「いいね」を押してくれた人に直接DMで「興味ありますか？いっしょにやりませんか？」「助けてください」と声をかけてみてください。 

仕組み化の第一歩がわからないとき 

まずは誰にも依存しない形で、自分一人で3回はつづけてみてください。3回つづけば型がみえてきます。型がみえてから、新しいメンバーに巻き込んで渡していきましょう。 

最後に

いきなり仕組み化しようとしても、人はついてきません。味方をつくらないまま一人で進めてしまえば、自分の熱量が切れたときに活動も止まってしまいます。

小さくはじめ、成果を示し、味方を増やし、ふりかえりながら広げていく。順番を守ることで、改善活動は組織のなかに根づいていきます。 

改善の火を、いっしょに燃やしつづけましょう。

経験を積むほど見失う「自分らしさ」と、40代で直面した限界

キャリアを長く積めば、自然と自信がつくとは限りません。私の20代から30代にかけての歩みは、まさにその葛藤の連続でした。 

20代のころ、私はSESとして、1〜3ヶ月で終わるような短期案件を転々としていました。

ウォーターフォール開発における実装や単体テスト、詳細設計から結合試験までといった一部の工程のみを担当することが多く、目の前の仕事をこなして経験の量は増えるものの、それらは散らばったままで、大きな自信には結びつかなかったんです。

その状況を打破しようと、30代ではお客様と直接関わる一次請け企業へ転職します。

テックリードやプロジェクトマネージャーとして案件に深く関わるようになりましたが、プロジェクトが終わるたびに経験がリセットされる感覚に陥りました。 

「点」としての経験はあっても、それらが「線」として繋がる感覚が得られず、自分自身のエンジニア像を描けずにいたのです。

自身のエンジニアとしてのあり方に自信がもてない状態は、外部交流に対して心理的な壁を生み出しました。 

当時、社外の勉強会などに参加して活発に交流するエンジニアに、私は強い憧れを抱いていました。

しかし、勇気を出して参加してみても「自分には縁がない、場違いだ」と疎外感を覚えてしまい、継続することができませんでした。 

それはスキルの問題ではありません。ほかの参加者が「エンジニアとしての自分のあり方」をしっかりともっているように見えるのに対し、自分にはそれがないという後ろめたさが原因でした。

キャリアの長さに反比例するかのように、自分らしさを見失っていったのです。

自分の失敗は“アンチパターン”だった。外の世界が教えてくれたこと

そんな私に、40代で大きな転機が訪れます。それは、新規プロダクト開発のプロジェクトマネージャーを担当したときのことでした。 

私は、スクラムマスターやQAリードなど複数の役割を兼務し、自身の経験だけを頼りに最適な手法だと信じてプロジェクトを推し進めました。

高稼働によってなんとかリリースには漕ぎ着けたものの、結果として極度の属人化を生み出してしまいます。

無事にリリースできた喜びよりも、「このやり方は二度と繰り返せないし、繰り返したくない」という再現性のなさに直面し、大きな後悔を味わいました。

「自分の知っているやり方だけでは、もう通用しない」。これが、私が直面した自己流の限界でした。

そこで私は、自分にはない知識を求めて、再び外の世界へと足を踏み入れます。 

最初はオンラインを中心とした勉強会やカンファレンスから参加しはじめました。オンラインであれば、かつて感じたような疎外感を抱くことはありませんでした。 

懇親会には参加せずセッションを聞くだけのスタートでしたが、自分とは異なる開発組織で働く人々の話や、未知のコンテキストのなかでの開発について知ることは、多くの学びと刺激をもたらしてくれました。 

こうしたインプットは、私が過去の経験を大きく捉え直すきっかけとなりました。 

私は、DevOpsやスクラムを改めて学び直しました。属人化を生んでしまった前述の失敗や、過去にぶつかった数々の問題が、業界ではすでにアンチパターン（避けるべき失敗例）として語られていたことを知りました。

自分が抱えていた苦しさや違和感を、外の言葉で少しずつ理解できるようになったのです。外部からの視点で捉えなおすことで、断片的に感じていた自身の経験が、意味のあるケーススタディとして整理されていきました。 

学んだことをただ通り過ぎる情報にしないため、私はブログへの投稿をはじめました。書籍や登壇から得た新しい発見や、自分ができていなくて魅力を感じた部分などを、自分の言葉で文章に整理していったのです。 

ある日、書籍の感想をブログに書いたところ、X（旧Twitter）で「いい話だな」と反応をくれた人がいました。 

自分自身の学びの整理のために書いた文章が、見知らぬ誰かの気づきに繋がった。この小さな成功体験が、自分の経験が他者と接続されるという初めての実感となり、私をさらなるアウトプットへと突き動かしました。

「いまやらなければ後悔する」。恐れを乗り越えたアウトプットへの挑戦

ブログでの手応えを得て、「自分がどうなりたいかを知るためのインプットと、実践したアウトプットの積み重ねこそが、自分自身になる」と確信し、次なるステップとして技術同人誌の執筆に挑みます。 

もちろん、「自分に書けるのか」という不安やプレッシャーはありましたし、やらない理由はいくらでも探せました。

しかし、「40代のいまやらなければ、50代でも60代でもやらない。人生を後悔したくない」という強い危機感があったんです。 

さらに、運営者の「書いてみたい気持ち最優先で突き進んでほしい」という言葉に背中を押され、応募最終日に決断しました。 

いざ書きはじめてみると、1日1ページ進めれば20ページの本は20日間で完成することに気づきます。

「アウトプットは一つひとつの積み重ねに過ぎない」。この気づきと共に書き上げた本は、過去の経験をDevOpsの観点から再整理したもので、読者から温かいフィードバックを得ることができました。 

同人誌につづいてカンファレンスでの登壇にも挑戦し、プロポーザルが採択されました。しかし、いざ採択されると「本当に自分が話していいのか」「がっかりされないか」と恐怖に苛まれました。 

そんなとき、またしても運営スタッフの言葉が私を救いました。「全員を採択したいが枠に限りがある。涙を飲んで不採択になったプロポーザルも、どうにか発表できる未来をつくりたい」。 

この言葉を見て、私は「自分の裏には不採択になった数多くの人たちの想いがある。選ばれた以上、覚悟をもって登壇すべきだ」と決意しました。

登壇の舞台に選んだのは、北海道で開催されたカンファレンスでした。私のことを知らない東京から離れた場所ということで安心できそうだと感じていました。 

テーマは、「新規プロダクト開発における属人化の失敗からの学び」です。 

勇気を出して失敗談を語った後、参加者から直接フィードバックをもらいました。オンラインや文字越しではない、生身の反応です。

ありふれていて価値がないと思い込んでいた自身の経験が、異なる組織で働く人たちの心に届き、彼らの学びに変わりました。 

「自分の経験が輪郭を持ち、明確な意味をもった」。この体験を経たことで、私のなかからアウトプットへの恐怖は大きく和らいだのだと思います。

ありふれた失敗談が誰かの学びに。経験のオーナーシップを取り戻す

一連の挑戦を通して、自分の経験が価値あるものへと変わっていきました。与えられた役割を越え、エンジニアとしてのオーナーシップを取り戻した瞬間でした。

アウトプットがもたらす他者との対話や交流の価値を深く理解したことで、現在では、新たな挑戦として「コミュニティづくり」に取り組んでいます。 

郊外に住む人、地方で働く人、子育て中で時間的制約がある人など、普段なかなか出会えない人々がもつ多様な学びや経験を交差させる場をつくりたい。

かつて外部コミュニティに疎外感を感じていた私が、いまは自ら居場所をつくり出す側にまわっているわけです。

輝かしいキャリアでなくても、遠回りや迷い、失敗を含めて、あなたにしかない経験が必ずあります。

40代まで積み重ねてきた経験があったからこそ、語れることがあるはずです。自信がない人こそ、その経験を言葉にして他者と交流してほしい。それが必ず誰かの学びに変わっていくと私は思います。 

今日の発表が、次にアウトプットの一歩を踏み出すあなたの背中を押すきっかけになれば幸いです。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

AIによる開発の高速化と、意思決定という新たなボトルネック

いまや多くの現場でAIを用いたコーディングがあたり前になりました。かつてエンジニアが手作業で書き、デバッグしていたコードの大部分をAIが瞬時に生成してくれます。 

実装やテストにかかる負荷はかつてないほど低下しました。重要なのは、この生産性の劇的な向上は開発現場だけにとどまらず、プロダクトマネジメントの分野にも起きているということです。

「Agentic Everywhere」という言葉が示すように、AIによる効率化の波はコーディングという枠を大きく越え、さらにあらゆる業務領域へと波及しています。 

しかしあらゆるタスク実行がAIに委ねられ、超高速で処理される流れが加速した結果、新たな問題が顕在化しはじめました。それが「AI疲れ」です。 

AIによって短時間でプロトタイプや提案を生成できる一方で、それらを「本当にリリースしてよいか」「ビジネス的な価値があるか」を判断するのは人間の役割です。

つまり人間の意思決定速度が追いつかず、確認や判断に追われる現場が疲弊してしまうのです。 

これは、システム開発におけるボトルネックが、もはや実装ではなく意思決定へと移行したことを意味しています。

AI時代にPdMが本来の役割へ回帰するための「4つの柱」

意思決定が最大のボトルネックとなったいま、プロダクトマネージャー（PdM）に求められる役割も大きく変える必要があります。 

これまで、日本の多くの現場ではPdMとプロジェクトマネージャー（PM）との境界があいまいであり、PdMは要件定義の作成やステークホルダーとの調整、進行管理といった業務に多くの時間を奪われてきました。 

しかし、AIがこれらのタスクを支援してくれるようになったことで、PdMは本来の役割に回帰することが可能になったのです。 

具体的には、企画・戦略フェーズではAIをシニアリサーチャーのように競合分析や市場調査に活用し、実行・検証フェーズではプロトタイプ作成やABテストのデータ分析を任せるといった具合です。 

このように業務サイクル全体をAIに支援させることで、PdMは「本当に価値あるプロダクトは何かを判断すること」、つまり事業判断という、本来あるべき役割に集中できるようになるのです。

一方で、AIが超高速でプロトタイプやレポートを生成しつづけることは、人間側が常に判断を迫られるという新たなリスクも生んでいます。 

AI時代において、PdMが質の高い意思決定を下すためには、次に説明する4つの柱を意識する必要があると考えています。それぞれを詳しく説明しましょう。 

起点となる1つ目の柱があり、そのほかの「3つの検証ループ」を最速で回しつづけ、学びを次の投資へ還元していくイメージをもちながら聞いていただければと思います。

1. 投資最適化（選球眼の強化） 

解像度の低い指示でも、AIを使えば数時間でプロトタイプができてしまう時代です。

だからこそ、「つくれるからつくる」という安易な機能実装の量産を防ぎ、事業価値に結びつくものだけを厳選する「選球眼」がPdMには不可欠です。 

2. アジリティの解放 

開発生産性が10倍になっても、「リリースの承認は月1回の会議で」という従来の承認プロセスのままでは期待した効果を得にくい可能性があります。

経営層やステークホルダーを巻き込み、組織全体の意思決定プロセスを開発スピードと同期させる舵取りが求められます。 

3. 経営リスクの遮断 

AIは自信満々にもっともらしい嘘（ハルシネーション）を出力することがあります。したがって、その結果を鵜呑みにせず、内容の妥当性を見極めることが重要です。

出力された結果が自社のビジョンに合致しているか、ビジネス上適切なのかを最終確認し、リスクを遮断するのは人間の重要な役割です。最終的な判断と責任は人間が担う必要があります。 

4. 競争優位性の構築 

独自の価値をいかに生み出すかは、AI時代においてもっとも重要なポイントといえます。AIは膨大な一般的なデータを学習しているため、そこから導き出されるのは平均的で無難な正解になりがちです。

一般的な情報から「売れそうなもの」をつくることは得意ですが、それだけでは他社との差別化は図れませんよね。 

汎用的なAIの回答を超えて真の価値を生み出すためには、現場特有の深いドメイン知識やユーザーへの理解、そして自社の理念という「人間ならではの文脈」を掛け合わせる必要があります。

こうした要素が、模倣困難な競争優位性の源泉の一つになります。

PdMの意思決定の生命線となる「エンジニアリング基盤」

本来の役割に回帰できるとはいえ、PdM個人がAIをうまく使えたとしても孤軍奮闘するだけではAI疲れからは逃れられません。局所最適ではなく、全体最適の視点で組織として基盤をつくることが大事だと私は考えています。

事業判断のスピードと精度を根本から引き上げるには、組織全体で事業判断を支えるシステム、すなわちエンジニアリング基盤の構築が不可欠です。 

例えばプラットフォームエンジニアリング。彼らはCI/CD、カナリアリリース、フィーチャーフラグといった仕組みを提供します。

これは例えるなら、「開発チームが安全に失敗できる検証用の高速道路」です。この基盤があるからこそ、PdMは躊躇することなく仮説検証のサイクルを回すことができます。 

また、SREとの協働も重要です。システムの利用状況やパフォーマンスを高度に可視化することで、迅速な判断が可能になります。 

例えば、通常は慎重にならざるを得ない機能停止の判断。

私自身も前職で、「1年かけてつくった機能を誰も使っていないから、半年で提供を停止する」という苦渋の決断をしましたが、データという客観的な裏づけがあれば、スピーディーに下すことができるようになります。 

さらに、お客様と直接向きあうCREとの連携は、明確な3つのステップで機能します。 

STEP1でAIがお客様の声から真のペインを見出して構造化し、STEP2で同じくAIが分析して文脈を付与・情報加工します。そしてSTEP3でPdMが判断を下す。

このAI・CRE・PdMのリレーにより、「誰も使わない機能をつくる悲劇」を未然に防ぐことができるのです。

最大の競争優位性「組織の学習」をいかに加速させるか

AI時代における真の勝者は、単に開発スピードが速い組織ではありません。

プロダクトマネジメント・事業判断とエンジニアリングが分断されることなく、ワンチームとして掛け合わさり、組織全体の「学習率」を最大化できる組織です。

個人の局所最適ではなく、開発ライフサイクル全体を意識した全体最適をつくること。これこそが、事業の命運を分ける最強のシステムとなります。 

では、組織が適切に学習し成長していることを、どのように観測すればよいのでしょうか。 

その結果は最終的に、P/LやB/SあるいはROI（投資利益率）やROIC（投下資本利益率）といった定量的なビジネス指標に表れます。

「単に機能を開発した」という単純なアウトプットではなく、それが実際にどれだけ事業の売上や価値に貢献したかが重要になるからです。 

もう一つ重要なのが、従業員エンゲージメントといった社内の指標です。

単一の指標に頼るのではなく、各ロールにおける多角的なメトリクスをもち、それらが最終的にビジネス指標にどう繋がっているかを観測しつづけることが求められます。

ボトムアップ×トップダウンで挑む、組織カルチャーの変革

意思決定プロセスを加速させるためには、組織カルチャーそのものの変革が避けられません。特に、階層構造や上意下達が根づいている伝統的な組織において、これを覆すのは容易ではありません。 

「これが正解です」という銀の弾丸はまだ見つかっていませんが、効果的なアプローチの1つが出島戦略です。 

特定のチーム（出島）で先進的なAI活用とアジャイルな意思決定を実践し、周囲に「自分たちもあんな風にやりたい」と思わせるカルチャーバブルをボトムアップで生み出すのです。 

同時に、組織規模が大きくなればボトムアップだけでは限界がきます。この動きに共感し後押ししてくれる経営層を巻き込み、トップダウンでの支援を取りつけることも欠かせません。

トップとボトムで挟んで変えていくオセロのようなアプローチをとることで、組織全体の意思決定プロセスを少しずつ変革していくことができるはずです。

（※本記事の内容および登壇者の所属は、イベント開催当時のものです）

技術進化に取り残される日本のITマネジメント

森實氏：エンジニアリングの世界はAIの登場などによって猛スピードで進化していますよね。現場は新しい技術を追いかけ必死に食らいついている。しかし、マネジメント手法のアップデートがそこにまったく追いついていないように感じます。 

渡会：おっしゃるとおりです。例えば、昔は「Kstepあたりのバグ密度」や「設計書の厚さ」「レビューの回数」などで価格や品質を管理していましたよね。 

しかし、AIがコードを書く時代に、Kstep単位の管理に何の意味があるのか？と。

ものづくりのスピードは上がっているのに、マネジメントだけがオールドスタイルのまま。このギャップが、いまの日本のIT組織にゆがみを生み出しています。 

森實氏：多くの国内企業では、自社の「ソフトウェア開発標準」をモデルにしてプロジェクトを回しています。

開発標準はPMBOKなどをもとにつくられているわけですが、最新の内容をどう取り込めばいいのか悩んでいる企業が多い印象です。 

渡会：歴史の長い会社ほど、古いバージョンのPMBOKをベースにした開発標準を使いつづけています。しかし、PMBOKは時代にあわせて約4年ごとに改訂されているため、本来は自社の開発標準もアップデートする必要があります。 

森實氏：一度つくったルールを変えるのは大変だからと、放置されがちですよね。 

渡会：欧米では「アジャイルか、ウォーターフォールか」という二項対立をすでに終わらせて、スピーディーに業務を変化させています。いま求められているのは、両者を統合し変化に適応することです。 

例えるなら、世のなかではステルス戦闘機やドローンといった最新の武器が使われだしたにも関わらず、日本は刀で戦おうとしている。だから「デジタル小作農」なんていわれてしまう危機的状況にあるのだと思います。 

森實氏：ここで視聴者からの質問です。『SI型（受託開発）と自社開発で、変化への対応力に差はあるのか？』という疑問ですが、これはいかがでしょう？ 

渡会：自社製品の方が自分ごとにしやすく、時代についていきやすい面は確かにあります。しかし本質的には、自社開発か受託開発かはあまり関係ありません。

つくったものが「どういう価値を生み出すのか」という中身は同じはずだからです。受託だからむずかしいというのは、自分で壁をつくってしまっている状態なんですよね。 

森實氏：同感です。たしかに自社開発の方が、企画から実運用まで見通せる分、変化に対する「感度」は高まりやすい面はあります。

一方で受託開発は、プロジェクト範囲が切り出されているため、感度を高めるのがむずかしいのも事実です。

しかし大切なのはOODAループを回しつづけ、状況の変化を感じ取ること。その感覚の重要性は、自社開発でも受託開発でも変わらないですよね。 

渡会：ええ。根本的な問題は、お客様と開発企業が「発注者と作業者」のように固定化された関係になってしまっていることにあります。

本来は、ビジネスのプロとつくるプロが協働して一つの価値を生み出すべきです。本気で思考し提案すれば、受託開発でもうまくいくと思いますよ。 

辞書から経典、そして実践書へ。PMBOKの変遷を辿る

森實氏：ここでPMBOKの歴史を振り返りたいのですが、第6版から第7版、そして第8版への変化をどう見ていますか？ 

渡会：第6版は「辞書」、第7版は「経典」のような存在でした。第6版まではプロセスが詳細に定義されていて、「このプロセスに従っていれば成功する」という誤解を生みやすい、分厚い辞書でした。 

森實氏：プロセスを守ることが正義、というのは現場にとってはわかりやすかった面もありますよね。 

渡会：それに警鐘を鳴らしたのが第7版です。プロセスではなく原理原則や価値の創出に大きく舵を切った方針書であり、精神論に近い“経典”のようになりました。 

森實氏：第7版が出たとき、あまりの急激な変化に現場は戸惑ってしまいましたよね。私も当時、「まずは第6版のプロセスを理解してから第7版を読むと腑に落ちるよ」とアドバイスした記憶があります。 

渡会：ソフトウェア開発宣言の精神に戻るような大きな視点に行きすぎて、実務を担う現場の人たちが少し置いていかれてしまったのは事実ですね。 

森實氏：そこで登場したのが第8版です。第8版は何に例えられますか？ 

渡会：第8版は、いわば“実践書”です。第7版で描かれた原理原則をちゃんとやっていくためのルールブックのようなもので、40のプロセス群に分けたモデルケースが載っています。 

これは「この40のプロセスを使うならば、自分たちのプロジェクトにあわせてテーラリング^※して使いなさい」という実践的なガイドラインになったと受け取ってもらうのがよいと思います。 

※プロジェクトの特性にあわせて手法やプロセスを最適化すること 

「真のテーラリング」は、プロセスの取捨選択ではない

森實氏：第8版でプロセスが復活したことで、「なんだ、やっぱりプロセスに従えばいいんじゃないか」と安心してしまう人もいそうですね。 

渡会：そこは誤解してほしくないですね。「プロセスに戻ったから安心だ」と盲従してはいけません。

スクラムガイドのとおりにやっても、自分たちの文化や目的にあわせてテーラリングしなければ効果的なスクラムが組めないのと同じです。 

森實氏：現場ではテーラリングのことを、プロセスの「いる・いらない」を選ぶことだと勘違いされがちです。

でも私はそういった取捨選択ではなく、用意されたプロセスを「自分たちなりにどう解釈し、どう使うかを言語化すること」こそが真のテーラリングだと考えています。 

渡会：まさにその通りです。わかりやすい例として、「トンカチ」というツールがありますよね。家を建てるときは「釘を打つ」ために、家を解体するときは「釘を抜く」ためにトンカチを使います。 

何のためにこのツールを使うのか、そしてどう使うか。それを自分たちでしっかり考えることがテーラリングです。

第8版で示された40のプロセスも、ただのトンカチと同じです。自分たちのプロジェクトの目的にあわせて、どう扱うかを考えてほしいですね。

ルールを守るのではなく、価値を創れ。新時代のプロジェクトマネジメント

渡会：プロジェクトの成功指標は何かといえば、第7版でも明記されている通り「価値を生み出すこと」です。

プロセスに従っていれば安心なのではなく、「このプロセスを使うことで、私たちは本当に価値を生み出しているか？」をつねに問いかけなければなりません。 

森實氏：ルールを守ることが目的化してはいけない、ということですね。「価値実現」という本質から目をそらしてはいけないと。 

先ほどのトンカチの例えでいえば、チームビルディングも同じですね。

「トンカチ担当」という固定の役割をつくるのではなく、いまは打つのが得意な人が使い、次は抜くのが得意な人が使う。1対1の固定された関係ではなく、必要なときに必要な人が臨機応変に関わっていく。 

渡会：ええ。ツールも役割も、自分たちで解釈して適材適所で使っていく。そういう流動的で目的志向のチームのあり方が、これからの時代には求められています。

森實氏：最後に、これからのプロジェクトマネジメントはどうあるべきだと思いますか？ 

渡会：学んでいくというよりは、「価値実現から逆算していく視点」をもつことです。そして、冒頭でも触れましたが、ビジネス側（発注者）と開発側（受注者）が本気で協働すること。 

相手の要望をただ実現するのではなく、同じ目的に向かって「自分ごと」としてプロジェクトを推進する。そのためのガイドとして、PMBOK第8版のプロセスを利用してほしいですね。

外部の権威ある実践書として、組織や上司を説得するためにもうまく使うことで、真の価値創出に向かいやすくなるのではないかとも思います。 

森實氏：古いルールや主従関係に縛られず、ビジネス側と開発側が協働して価値を生み出す。今回の内容が、変化の激しい時代に立ち向かう皆様のプロジェクトマネジメントのヒントになれば嬉しいです。 

渡会：森實さん、本日はありがとうございました！ 

イベント全編をご覧になりたい方はこちらから  

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。 

5,000名を超える登録者数！技術イベント SHIFT EVOLVEをチェック 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

ITプロジェクトに限らない。PMBOKが担う、本来の役割とは

「PMBOKはIT専用」と思われがちなのですが、これは大きな誤解です。 

そもそもPMBOKとは、全世界で約75万人の会員を擁するプロジェクトマネジメント専門の非営利団体であるPMIが、さまざまな産業のプロジェクトマネジメントに関するノウハウを取り入れて体系化した知識体系（Body of Knowledge）です。 

そのPMBOKが定義するプロジェクトとは、「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務」を指します。

つまり、明確な期間（有期性）があり、これまでにない新しいものをつくる（独自性）という条件を満たせば、すべてがプロジェクトに該当するのです。 

ITシステムの開発はもちろんのこと、新型ワクチンの開発、ジェット機の設計、さらには書籍の出版でさえもプロジェクトに含まれます。

実際に、私がPMPを取得した2005年頃には、PMI日本支部の会員の約3割を建築業界の人が占めていた時期もあったほどです。 PMBOKは決してIT専用の枠組みではありません。 

それにもかかわらず、なぜ今日において「IT業界のウォーターフォール開発専用のルールブック」という偏ったイメージが定着してしまったのでしょうか。その理由は、過去の歴史的背景にあります。

2001年に「アジャイルソフトウェア開発宣言」が出されたものの、2014年2月にPMBOK第5版が出版された当時も、世の中の大半のプロジェクトは依然としてウォーターフォール型で進行していました。 

PMBOKは実務の基盤であるため、当時の主流であったウォーターフォールを中心に記述せざるを得ませんでした。この第5版までのイメージが、いまでも多くの人の頭に強く残っているのです。 

しかし時代が変わりはじめて、PMBOK第6版でアジャイル（適応型）に関する記載と、さらに副読本のような扱いでアジャイル実務ガイドも別冊で出ました。

その後、第7版以降、現在は「アジャイルか、ウォーターフォール（予測型）か」という二元論は崩れ去っています。 

というのも、PMBOKは本来、特定のアプローチに縛られず、プロジェクトを成功に導くための方針やルール、ツールを提供する基盤だからです。

手法に囚われることなく、目の前のプロジェクトの特性にあわせて最適な開発アプローチを選択することこそが、本来のPMBOKが意図する正しいマネジメントのあり方なのです。 

「指示待ちを生む辞書」からの脱却と、第7版が生んだ現場とのギャップ

もう少し詳しく改訂の変遷を紐解いてみます。 

第6版までのPMBOKは、「5つのプロセス群」と「10の知識エリア」を掛けあわせた「49のプロセス」から成り立っていました。

インプット、ツールと技法、アウトプットが事細かに記された、辞書のような分厚い体系です。

この時代は、設計書やテスト仕様書といった成果物をいかにスケジュールや予算通りにつくるかが重視されていました。

実は当時から「プロジェクトに合わせてプロセスをテーラリング^※すること」は推奨されていましたが、あくまで考慮事項として控えめに書かれているにすぎませんでした。  

それが現場のエンジニアに「指示通りに49のプロセスを守っていればいい」という思考停止を生み出すことにもつながったんです。 

※プロジェクトの特性にあわせて手法やプロセスを最適化すること。

こうした限界を打破すべく、第7版ではプロジェクトマネジメントの歴史に残る大転換が図られました。最大のポイントは「成果物重視」から「価値（アウトカム）重視」へのパラダイムシフトです。

いわれたものをただつくるのではなく、「つくったシステムがユーザーに使われ、課題が解決してはじめて価値が生まれる」というプロジェクトの本質に立ち返ったのです。

具体的には、思考停止の要因となっていたプロセスを単に廃止したのではなく、頻繁に変わる具体的な手法やノウハウを「PMIstandards+」というWeb側に移行することで書籍の内容をスリム化し、揺るがない普遍的な「12の原則」のみを提示しました。 

あわせて単なる知識の集合体であった10の知識エリアも、行動原理にあわせて「8つのパフォーマンス領域」へ変わっています。  

これは、「マップ通りに動いていればよかった」これまでのやり方から脱却し、「用意された材料から自分たちで選び、プロジェクトにあわせて自律的にテーラリングしなさい」という、極めて理想的で素晴らしいメッセージだと私は捉えています。 

しかし、この理想的な大転換は、皮肉にも現場に大混乱をもたらしました。 

「自分で考えてテーラリングしてください」と自由を与えられた結果、これまで明確なレールに乗って進んできたPMたちが、「一体どうやってプロジェクトを進めればいいのか」と迷子になってしまったのです。 

抽象度が高くなりすぎたがゆえに、具体的な拠り所を失い、途方に暮れる現場が世界中で続出しました。

理想を追求するあまり、現場の実務との間に大きなギャップが生まれてしまったのです。 

理想と現実のベストミックス。第8版が示した「プロセス復活」の真意

現場の声を受け、いよいよ登場したのが第8版です。第8版は、第7版で生じた現場の混乱を救済しつつ、本質的なよさをさらに磨き上げた「理想と現実のベストミックス」といえます。 

時計の針を逆回しにして、第6版の辞書的なルールに戻したわけでは決してありません。

第7版が打ち立てた「価値重視」の哲学や、「自分たちでテーラリングする」という自律的なスタンスは、PMBOKの新たな核としてしっかりと引き継がれています。 

そして第7版で行動規範として掲げられた「12の原則」は、第8版において6つの原則へと整理・集約されました。

具体的には、「価値主導」「オーナーシップ」「能動的」といった分野ごとにわけられ、プロジェクトにおいてどのように振る舞うべきかという指針として再定義されています。 

さらに、現場への最大の救済措置として、「立ち上げ・計画・実行・監視コントロール・終結」という5つのプロセスが復活しました。重要なのは、これがウォーターフォール専用ではないという点です。 

例えば、スクラムに当てはめてみましょう。「立ち上げ」はスプリントゼロ、「計画」は毎週のスプリントプランニング、「実行」は日々の開発タスク、「監視コントロール」はデイリースクラム、そして「終結」はスプリントレビューやふりかえりに合致するのです。

プロセスを復活させつつも、あらゆる手法に適用できる柔軟性を確保しています。 

さらに、かつての10の知識エリアは時代にあわせて再整備され、新たな「7つのドメイン」として生まれ変わりました。

例えば、統合は「ガバナンス」へ、コストはプロジェクト単体の枠を超えて「ファイナンス」へと、より広義でビジネスの核心に迫る概念へとアップデートされています。 

プロセスも40個にスリム化され、インプット、ツールと技法、アウトプットの構成が復活しました。

しかし、それはかつてのような「これを絶対に行え」という命令ではなく、自律的なテーラリングを行うための「実用的なカタログ」として再構築されています。 

アジャイルか、ウォーターフォールか。二元論を脱却し、自分自身をアップデートせよ

第8版の全貌から明確に見えてくるのは、「アジャイルかウォーターフォールか」という不毛な二元論からの脱却です。 

どちらの手法が優れているかを議論する時代は終わりました。目の前のプロジェクトの特性やお客様のビジネス環境にあわせて、これらを自在に組みあわせる「ハイブリッド」の視点が不可欠です。 

これからのPMが本質的な価値を生み出すためには、モデル・方法・作成物というパーツを使い、最適なプロセスを柔軟に組み立てることが求められます。 

さらに第8版では、時代の変化を捉え、付録としてAIに関する言及が追加されています。

このようにつねに世の中の動向に敏感に反応しつづける姿から私たちが学ぶべきは、最新の機能やプロセスそのものではなく、PMBOKという世界標準が示した姿勢です。 

世界中のプロジェクトの動向や多様性に敏感に反応し、時には49のプロセスといった過去に打ち立てた体系を捨て去るなど、揺り戻しを経験しながらも、決して進化を止めることはありませんでした。 

世界標準でさえ、これほどのスピードと自己否定を伴う柔軟性をもって自己変革を遂げているのです。

我々エンジニアやPMも、過去の成功体験や資格取得時の古い知識にしがみついていてはいけません。 

「昔はこうだった」「この手法が一番だ」と固執することは、変化の激しい現代において致命的なリスクとなります。

PMBOKが絶えず進化しているように、我々自身もつねに知識とスキルをアップデートし、状況にあわせて自らを変化させつづける必要があります。 

イベント全編をご覧になりたい方は こちらから

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。 

5,000名を超える登録者数！技術イベント SHIFT EVOLVEをチェック 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

なぜいま、日本で「なんちゃってアジャイル」が横行しているのか

多くの現場が抱える悩みや違和感。その正体は、表面的な部分だけを模倣した「なんちゃってアジャイル」です。朝会やふりかえりは実施していても、一番重要な“魂”が抜け落ちているケースが後を絶ちません。 

なぜこのような事態に陥るのでしょうか。その背景には、日本企業に根強く残るウォーターフォール文化からの脱却のむずかしさがあります。

アジャイルを表面的に理解したまま導入し、困ったときには無意識に従来のウォーターフォール的な発想に戻り、安易なハイブリッド開発にして失敗するケースが非常に多いのです。 

さらに大きな原因として「アジャイルを導入すること」自体が目的化してしまっていることが挙げられます。最近では、経営層のトップダウンでアジャイル推進部門がつくられたものの、現場は何をしていいかわからず疲弊していく「やらされアジャイル」も増えています。 

アジャイルの真の目的は、お客様の価値を最大化することです。すなわち「価値あるものを素早く提供し、さらにその価値を高めていくこと」。 

決して開発者が楽をするための仕組みでも、計画を立てなくていい口実でもありません。しかし、経営層からの「アジャイルでやれ」という指示により、現場は手法を守ることだけに意識が向いてしまうのです。

私自身も、そんな失敗をしたことがあります。アジャイルをはじめたばかりのころ、「何でもアジャイルでやれば成功する」と勘違いしていた私は、「既存システムを安く早く移行してほしい」という要望にアジャイルを適用してしまいました。 

新しいバージョンにマイグレーションするだけ、つまり不確実性が低いのでウォーターフォールでよかったのです。結果的に不要な変更を加えて予算オーバーになり、お客様からお叱りを受けました。お客様が求めている“価値”を見失っていたんです。

いまさら聞けない、アジャイルとウォーターフォールの本質的な違い

アジャイルとウォーターフォールは、決して敵対するものではありません。欧米ではアジャイルが主流だというのは幻想です。 

グローバルのPMI（プロジェクトマネジメント協会）のレポートを見ても、実はウォーターフォール単体を採用している企業の方が割合としては多いのです。ただ、アジャイル単体とハイブリッドを足しあわせるとウォーターフォールを超える、というのが実態です。 

彼らはプロジェクトの特性や目的にあわせて、双方の手法を柔軟に使い分けているのです。

しかし、両者の特性を正しく理解しないまま「仕様決定まではウォーターフォールで行い、製造からアジャイルで行う」といった安易なハイブリッド開発に手を出すと危険です。

例えば、アジャイルの「仕様変更を受け入れる」という特性を曲解し、無計画に仕様変更を連発すれば、容易にデスマーチへと陥りかねません。

ここで一度、ウォーターフォールとアジャイルの違いを整理しておきましょう。 

ウォーターフォールは、明確なゴールが見えている“予測型”のアプローチです。ゴールまでの道筋を正確に予測し、計画通りに一直線に進むため、要件が固まっている場合にはもっとも効率的です。 

一方アジャイルは、ゴールが霞んで見えない状況下で威力を発揮する“探索型”のアプローチです。未知の山に登るように、まずは麓まで行き、その時点の天候や体力、道の状況を確認してから次のルートを決めます。 

一歩ずつ手探りで進むアジャイルは決して「無計画でよい」ということではありません。状況の変化に合わせて小さな「計画を立てつづける」アプローチなのです。 

品質の守り方にも違いがあります。ウォーターフォールは「不具合は入り込むもの」を前提とし、最後のテスト工程で一気にバグを抽出します。いってみれば「まずは大きな部屋を作ってから、あとでそこを一生懸命掃除する」ようなイメージです。 

一方、アジャイルは「無菌状態を保ちつづける」という思想です。小さくつくった機能に自動テストを組み込み、完全に動くことを担保してから次の開発に進みます。風船を無菌状態のまま少しずつ膨らませていくように、常にリリース可能な品質を維持しつづけます。

形だけの手法から脱却する「アジャイルマニフェスト」の真意

形だけの手法から抜け出すためには、「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」の真意を理解する必要があります。 

しかしアジャイル研究会の調査によれば、アジャイルを実践している人の約半数がその存在を知らない。

また、知っていたとしても「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」という一文を、「ドキュメントや計画は一切不要だ」と誤解している人が少なくありません。 

マニフェストには明確に「右記の事柄（プロセスやドキュメント）に価値があることを認めながらも、左記の事柄（対話やソフトウェア）により価値をおく」と記されています。 

つまり、計画やツールを軽視しているわけではないのです。アジャイルでも、数週間単位の「スプリント」ごとに綿密な計画を立てつづけます。ただ、それ以上に人間同士の対話や、実際に動くものを通して価値を検証することを重要視しているのです。 

個人的にもう一つ気をつけてほしいのが、アジャイルやスクラムは決して完成形ではないということです。マニフェストの序文にも「より良い開発方法を見つけ出そうとしている」と明確に記されています。 

基本をしっかりやることは当然ですが、スクラムの枠を一歩も出ないことが正義ではありません。基本を理解したうえで、自分たちなりのやり方を「守破離」で模索していく姿勢こそが重要なのです。

また、マニフェストには「自分たちがアジャイルを実践できているかどうか」を測る12の原則が記されています。今回は、そのうち特に重要な4つの原則を紹介します。 

1つ目が、「お客様満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というもの。前半の失敗談でも触れたとおり、アジャイルの真の目的はお客様の「価値創造」にあります。そのために小さな成果を素早く積み重ねていくのです。 

2つ目が、「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」です。アジャイルでは、変化を「お客様がより大きな価値を発見した証拠」と捉えます。手戻りではなく、プロダクトを改善するための機会なのです。 

しかし、これは「お客様のいいなりになる」ことではありません。ビジネス側が変更を求めた場合、開発側はプロフェッショナルとしてシステムへの影響やリスクを明確に提示する必要があります。

そのうえで、本当に競争力に寄与する変更であれば、歓迎して取り入れるのが正しい姿勢です。 

3つ目は、「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」です。

チーム内の特定のメンバーがプロダクトを生み出すのではなく、プログラムの構造やビジネスの進め方など、どんな議題であっても全員で知恵を出しあって進めようという意味が含まれています。 

スクラムマスターのなかには、「いいチームをつくること＝開発者のいいなりになること」と誤解している人が少なくありません。

開発者の味方をするスクラムマスターは一見かっこよく見えますが、単に開発者を庇っているだけでお客様の事業を前に進めていないのであれば、何の価値も生んでいないのと同じです。 

当然のことながらお客様の事業を前に進めるためにいいチームが必要なのであって、チームが強くなればビジネス価値が自然と生まれてくるわけではないのです。 

4つ目が、「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」というもの。

アジャイルを成功に導く最大のエンジンは、「ふりかえり」です。これは単に製品の反省会ではなく、製品をつくり出すチーム自身をバージョンアップさせるための時間です。 

スプリントごとにやり方を改善していくことで、チームの生産性は時間の経過とともに加速度的に向上していきます。忙しいからといってふりかえりをやめてしまうと、チームの成長もそこで止まってしまうのです。

組織アジャイルの真の成功の鍵は「ビジネスと開発の協働」

プロジェクト単体だけでなく、企業全体がアジャイルになっていくために、私は「組織を幸せにする組織アジャイル 5つの原則（ソシアジャ五良核）」という概念を独立行政法人情報処理推進機構 （IPA）アジャイルWGメンバーとして提唱しています。

これは「方向性」「協働」「敬意」「成長」「事業」という5つの原則をまわすことで、アジリティの高い組織をつくるというものです。なかでも、基盤となる「方向性の統一」と「協働」が成功の鍵を握ります。 

アジャイルにおいてもっとも避けるべきは「発注者から開発者への丸投げ」です。ビジネス側と開発側という対立構造のままでは、真のアジャイルは実現しません。 

例えば、プロダクトオーナー（PO）には、即断即決の覚悟が求められます。「社内にもち帰って確認します」と回答を保留してしまえば、アジャイルのスピード感は死んでしまいます。ビジネス側と開発側がともに考え、ともに決断する当事者意識が不可欠です。

このような背景から、アジャイルは決して楽な道ではありません。ビジネス側はつねに決断を迫られ、開発側は技術だけでなくビジネス価値にまで踏み込んで考える必要があります。

しかし、壁を越えて協働できるようになると、仕事は劇的に楽しくなります。私がなぜ20年近くもこの仕事をつづけているのか。それはやっぱり、「アジャイルで働く」って本当に楽しいからなんですね。 

開発者は自分がつくったものが直接ビジネスに貢献している実感を得られ、ビジネス側は毎週のようにプロダクトが成長していく過程を味わうことができます。この「ともに価値を創り出す喜び」こそが、アジャイルの本質的な魅力なのです。 

ビジネス側と開発側が従来の壁を打ち破り、互いに敬意をもって協働し、ともに成長しつづける。これこそが、変化に強く、真の力を引き出せる組織へと進化していくための道となるでしょう。

＼＼動画もぜひご視聴ください／／

（※本記事の内容および対象者の所属は、イベント開催当時のものです）

完遂と育成の混同が、PMを疲弊させる

私はこれまで15年以上、主に金融領域のSIに携わり、その後いくつかの事業会社を経験して現在はさまざまな 企業やプロジェクトの支援を行っています。

ただ、どこの領域においても「プロジェクトマネジメント」は切っても切り離せないものだと感じています。 

ただ、プロジェクトの話をする前の大前提として、現場で混同されがちな「マネジメント」という言葉への誤解を、まずはっきりさせておきたいのです。

私たちが普段何気なく使っているマネジメントには、プロジェクトの完遂を目指す「プロジェクトマネジメント」と、人材の育成を重視する「組織マネジメント」という、そもそも狙いの異なる2つの視点が存在します。 

しかし、「マネージャー」という言葉で一括りにされることでこれらが混同されがちです。 

組織からはマネージャーとしてのさまざまな能力を期待されるかもしれませんが、 プロジェクトの最大の目的が完遂であるならば、完遂する方法はいくらでもあるはずです。

一人の優秀なPMがすべてを抱え込むのではなく、「チーム全体で完遂する」という選択肢があってもよいのではないでしょうか。 

リスクを分散して完遂の可能性を高めることを考えると、メンバーがいかに生き生きと働けるかが 、チームの最高のパフォーマンスにつながると私は信じています。

メンバー個人が自らの得意を活かして価値発揮を最大化できる環境をつくり、主体性を引き出すこと。それこそが、チームでプロジェクトを成功させるための大前提となるのです。

脱・受け身！説明責任はPMに、実行責任はチームに

チームの総合力を引き出すためには、従来のガチガチに固められた役割分担から脱却する必要があります。 

例えば「インフラ担当はインフラの作業のみ行う」「週次の定例会議はどんな状況でも絶対に開催する」といった、これまで当たり前とされてきた型にこだわる必要はありません。

状況に応じて柔軟に動ける体制をつくることが、チームの能動性や自主性を引き出す第一歩です。 

また、チーム全員にマネジメントさせるうえでもっとも重要なのは、責任の所在の明確化です。プロジェクトにおける「説明責任（Accountable）」は、これまで通り組織に対してPMがもちます。

しかし、「実行責任（Responsible）」までPMが一人で負う必要はありません。実行責任はチーム全員で共有するのです。 

これは、タスクの責任分担を明確にするRACI（レイシー）チャートの考え方に基づいています。実行責任を共有するための具体的なアプローチには、役割の分散があります。 

例えば、会議のファシリテーターや、アジャイル開発におけるスクラムマスターといった役割を、特定の一人に押しつける必要はありません。

全員がファシリテーションを持ち回りで経験し、「今日は私が議事録を担当します」「私がタイムキーパーをやります」といった小さな役割をチーム内で分散させるのです。 

こうして一人ひとりが役割を担うことで、プロジェクトマネジメントの視点がチーム全員に宿り、「これは自分たちのプロジェクトだ」という当事者意識が浸透する、より自律的で強いチームが形成されていきます。

参考にしたい3冊の書籍

ここまでは、プロジェクトマネジメントの視点をチーム全員に宿すという、私の著書『ゼロから始めるチームプロジェクトマネジメント』の根底にある考え方をお話ししてきました。 

さて、今回はさらに2冊の本を紹介したいと思います。同イベントに登壇されている渡会さんの著書『アジャイルに困った時に読む本』と、最新の『PMBOK®第8版』です。

この3冊はそれぞれ立ち位置こそ違いますが、ベースとしているところは同じことを言っていると私は思っています。

それは、単なる方法論ではなく、「チームと価値をどう動かすか」というところが、それぞれの本の共通の軸になっているということです。

自律的なチームをつくる3つのアプローチ

ではこれら3冊の共通項から見えてくる「自律的なチームをつくるための3つのアプローチ」を紐解いていきましょう。

１つめ：プロジェクトは「人と関係性」でできている

プロジェクトを実際に動かしているのは、無機質なタスクやスケジュールではなく、「人」と「関係性」です。

特定のリーダーに依存せず、互いに支えあう関係性を築くことが重要と考えており、私の著書でもチーム内に「小さなリーダー」を増やすことをお伝えしています。 

渡会さんの著書でも、アジャイルがうまくいかない原因はフレームワークの構造自体ではなく、それを実行する「人の解釈」に対するアンチテーゼとして書かれています。

そして最新のPMBOK第8版でも、従来の「管理する」という領域から一歩抜け出し、リーダーシップなどチームのあり方に踏み込んだ内容になっています。

２つめ：万能なやり方は存在しない（テーラリング）

プロジェクトには「これさえやっておけば必ず成功する」という万能なやり方は存在しません。

だからこそ状況にあわせて役割を柔軟に変え、メンバーの体調不良などの不測の事態にもチーム全体でカバーしあう準備と心構えが求められます。 

「これは私の役割」「それはあなたの役割」と線を引くのではなく、「これは“私たち”の役割」と捉える「オーナーシップの共同所有」を私は提唱しています。

渡会さんの著書でも「プロダクトオーナーは一人でなくてもいい」というように、やりたいことに対して手法を踏襲する必要はないと説かれています。 

これはPMBOKが提唱する「テーラリング（※）」の考え方そのものであり、現場のリアルな課題に立ち向かうための強力な武器となります。 

（※）プロジェクトの特性にあわせて手法やプロセスを最適化すること。

３つめ：価値とは成果物ではなく「変化」である

プロジェクトの価値とは、単にシステムやドキュメントといった成果物を納品することだけではありません。プロジェクトを通じて生まれる「変化」こそが真の価値です。 

チームがプロジェクトを進めるなかで、メンバー一人ひとりが成長し、チームも成熟していく。その変化の積み重ねが重要です。

そのためには、プロジェクト完了後の世界観を共有するだけでなく、「自分たちは正しい方向に進んでいるか」をチーム全体で確認しあうことが不可欠です。 

真のチームプロジェクトマネジメントを実践するためには、個人とチームの成長や変化をリンクさせていくことが重要です。 

例えば、プロジェクト全体の「プロダクトゴール」だけでなく、1ヶ月単位の「スプリントゴール」、さらには「このプロジェクトを通じて自分はどのようなスキルを身につけたいか」という個人のゴールなど、複数のゴールを同時に設定します。 

設定したあとは、ときにバックキャスト（※）でふりかえり、それぞれのゴールがリンクしているかを確認することで、納得感をもってプロジェクトに取り組むことができます。 

（※）未来の目標から逆算して現在すべきことを考える手法。 

渡会さんの著書では、この部分を「アウトカム思考」や「継続的な価値創出」という言葉で表現しています。

プロジェクトを単発の有期的なものとして終わらせるのではなく、もっと継続性のある営みの一部として捉える視点を謳っています。 

最新のPMBOK第8版でも、プロジェクトを単なる一時的な活動ではなく、「継続的な価値創出（Value Delivery）のシステムの一部」として捉え直す必要がある、と語られています。

つまり、継続性のなかの一部分だけを切り出すと有期性のあるものであるということを謳っています。 

こうしてみると3冊それぞれが、個人の変化、チームの変化、プロダクトの変化、そして生み出されるアウトカム（成果）の変化について語っているなというのが読みとれます。

まとめ

プロジェクトマネジメントにおいて、一人の優秀なPMにすべてを依存する時代は終わりました。マネジメントの目的を正しく理解し、実行責任をチーム全員で共有することが、現代のプロジェクトを成功に導く鍵となります。 

興味をもたれた方は、ぜひ今回ご紹介した3冊を手に取ってみてください。そして、明日からあなたのチームにも変化を起こし、チームがもつ総合力を最大化していただけたらと思います。

イベント全編をご覧になりたい方は こちらから

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。

5,000名を超える登録者数！技術イベント SHIFT EVOLVEをチェック

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

自動化スクリプトが現場で眠ってしまった3つの理由

みなさんは、テスト自動化をスムーズに現場に導入できましたか？ 

私は昨年度もソフトウェアテスト自動化カンファレンスに登壇し、あるテスト自動化案件の成功事例を紹介しました。

しかし、現場への定着がなかなか進まず、当初想定していた「属人化の排除」「問題の再現性向上」「開発環境への影響の少なさ」「問題発生から解決までの迅速化」といったメリットが十分に得られないという課題に直面しました。 

なぜこれらのメリットを享受できていなかったのか。現場への定着が進まない原因を分析した結果、利用者を疲弊させている3つの壁が浮き彫りになりました。 

1. 環境構築でのつまずき 

Pythonなどのスクリプト言語を実行するには、ライブラリのインストールやパスの設定など、煩雑な環境構築が必要です。非エンジニアや初学者にとって、この準備段階こそが最大のハードルとなっていました。 

2. 環境更新によるスクリプトの早期老朽化 

PCのOSアップデートやライブラリのバージョンアップにより、昨日まで動いていたスクリプトが突然動かなくなる事象が頻発。その都度メンテナンスが必要となり、「手動の方が早い」という意識を生んでいました。 

3. データ変換への対応困難（エラー時の不安） 

テストデータ変換などでエラーが発生した際、原因の特定に時間がかかることがあります。これは技術的な難易度というよりも、問題発生から解決までが長期化することに対する心理的な不安が要因でした。 

これらの課題を解決するために、私は利用者の視点に立ち返り、解決への要件を定義しました。 

①環境構築の壁に対して：ワンアクションで完了する簡潔さを目指す。 

②老朽化の壁に対して：原因を即座に特定・追跡できる情報を提供し、迅速な解決を可能にする。 

③エラー時の不安に対して：「何が起きたか一目でわかる」状態をつくり、解決の長期化への不安を取り除く。 

これらの要件を踏まえ、私は最終的な解決方針を以下の2点に定めました。 

・簡潔なテストスクリプト実行（環境構築不要で誰でも動かせる） 

・実行するだけで取得できる、再現性の高いログの実装（エラー時の不安を解消する） 

この実現のために選ばれたのが、「PyInstallerによるパッケージ化（exe化）」と「動画記録」というアプローチでした。 

PyInstaller×動画記録。誰でも使える「配布しやすい」仕組みづくり

「簡潔な実行」を実現する手段として、一般的にはJenkinsなどのCI（継続的インテグレーション）ツールを用いた実行基盤の構築が挙げられます。ですが、私はあえてその道を選びませんでした。 

Jenkinsサーバーを立てると、リソースの確保やメンテナンスコスト、さらには社内のセキュリティガバナンスなど、導入までに高いハードルが存在します。

小規模なチームや客先常駐の現場において、重厚なインフラ構築はオーバースペックになりがちです。 

そこで採用したのが「PyInstaller」です。

これはPythonスクリプトを実行可能ファイル（.exe）に変換するツールであり、Python環境がインストールされていないPCでもダブルクリックだけでツールを実行できるようになります。

ツールをexe化して配布する手法は、「まずは現場の目の前の課題を解決する」という機動性において非常に優れています。 

・環境構築不要：受け取ったその場で実行可能 

・配布容易：ファイルをコピーするだけ 

・展開効率化：マニュアル作成や教育コストの激減 

これら3点のメリットは、現場導入の障壁を劇的に下げるカギとなりました。 

PyInstallerによるパッケージ化には、すべてのファイルを1つのexeに固める方法や、依存ファイルを含まない軽量な方法など、いくつかのレベルが存在します。

私が採用したのは、すべての関連ファイルを1つにまとめるのではなく、「Python本体やライブラリなどの実行環境はパッケージ化しつつ、ロジックが書かれたスクリプト本体（.pyファイル）はあえて外に出す」という構成（本記事では便宜上、レベル3と呼称）でした。 

この構成の最大の利点は、保守性にあります。 

もしスクリプトを含めて完全に1つのexeファイルにしてしまうと、軽微な修正であっても、エンジニアが再度ビルド（exe化）して配布し直す必要があります。しかし、スクリプトを外出しにしておけば、現場の担当者がテキストエディタでスクリプトを直接修正し、そのままexe経由で実行することが可能です。 

これにより、環境構築の手間は排除しつつ、現場での柔軟な修正対応も可能にするという、運用上のバランスを実現しました。スクリプト保守担当者に高度なPython環境知識を求めずとも、ロジックの修正だけで対応できる体制が整ったのです。 

もう一つの課題である「エラー時の不安」を解消するために導入されたのが、スクリプト実行中のデスクトップ画面を動画として記録する仕組みです。 

通常、自動化ツールのデバッグにはログファイル（テキスト）の解析が必要ですが、ログ設計が不十分だと原因特定が困難になります。しかし、操作画面そのものが動画として残っていれば、どのボタンを押したタイミングでエラーが出たのか、どのようなポップアップが出ていたのかが一目瞭然です。 

「ログが不足していても、動画を見れば何が起きたかわかる」という状態をつくることで、解析に必要な情報は十分に担保されます。また、デスクトップ全体を録画することで、スクリプト以外の要因も発見しやすくなりました。 

テスト以外の業務へも展開。パッケージ化がもたらす無限の可能性

パッケージ化によって環境構築が不要になったことで、ツールの利用者は開発者やテスターに留まらなくなりました。 

例えば、テストデータの投入作業。これまではテスト実施者が行っていましたが、exe化されたツールであれば、システムを利用するお客様自身に配布し、お客様の手でデータ投入を行っていただくことも可能です。 

職人の道具であったスクリプトが、パッケージ化によって誰でも使える業務ツールへと進化したのです。これは、テスト自動化の枠を超え、業務プロセス全体の効率化に寄与する変化でした。 

この事例は、社内のRPA運用における課題解決にも応用されました。 

多くの現場では、Microsoft Power Automateなどを用いて業務自動化を行っていますが、作成者の異動や退職に伴い、フローがブラックボックス化（属人化）してしまう問題が頻発しています。

また、実行には個人のアカウント権限が必要なケースも多く、管理が煩雑になりがちです。 

こうしたRPAのフローを、パッケージ化したPythonスクリプトに置き換えることで、特定のタスク管理者に依存しない運用が可能になります。

Excel操作やWebブラウザ操作など、従来RPAが担っていた領域を、よりポータブルで管理しやすいexeツールへと移行することで、自動化の持続可能性を高めることができました。

最後に、技術的な側面での工夫についても触れておきます。通常、PyInstallerで1つのexeファイル（One-Fileモード）にまとめると、実行のたびに内部ファイルを一時フォルダへ解凍するオーバーヘッドが発生し、起動速度が遅くなる傾向があります。 

私は利用者の体験を損なわないよう、展開済みのライブラリ群を保持する方式（onedirモード）を採用しました。 

動画デモによる比較検証でも、Pythonスクリプトを直接実行した場合と、パッケージ化されたexeを実行した場合とで、処理速度に遜色がないことが確認されています。この工夫により、ファイルサイズや起動時間のストレスを感じさせることなく、スムーズな導入を実現しました。 

まとめ

今回ご紹介したパッケージ化（exe化）の手法は、単なる技術移転作業ではありません。自動化ツールを「選ばれた人だけが使う職人の道具」から、「誰でも手軽に扱える日用品」へと変革するアプローチです。 

環境構築という最大の障壁を取り払い、動画記録によって安心感を担保する。この仕組みは、テスト自動化の現場だけでなく、あらゆる業務効率化のシーンで応用可能です。 

「つくったけれど使われない」という課題に直面しているエンジニアの方々は、配布しやすさと使いやすさを追求する姿勢を意識してみてください。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）

DB検証までカバーするAPIテストの最適解。「Karate」と「Database Rider」

今回ご紹介するのは、足掛け5年に及ぶウォーターフォール開発のプロジェクトにて、疎結合なレイヤードアーキテクチャへの移行に伴い、SHIFTの自動化アーキテクトである私が取り組んだAPIテスト自動化の事例です。

このプロジェクトは、開発規模が月に30～40人月、API数は3桁にのぼり、単体テストだけでも数万ケースという非常に大きな規模でした。

SHIFTは「全体開発推進」という立場で参画し、全体のテスト自動化を支援することになりました。 

本プロジェクトにおいて、品質を担保するためのAPIテスト自動化は必須の要素でしたが、そこには大きな壁が立ちはだかっていました。 

みなさんは、APIテストの自動化にどんなツールを使っていますか？

「APIテスト 自動化」というキーワードで調べるとさまざまなツールや事例がヒットしますが、多くの場合でDBのテストデータ投入や事後のデータ検証に関するケアが不足しているか、あるいは手動で行われている現状が見えてきます。 

しかし、実際の業務アプリケーションでは、APIの処理によってデータベースが正しく更新されたかを検証することは不可欠です。また、テストを実行するためには、前提となるデータをDBにセットアップしておく必要もあります。 

これらを別々のツールで行ったり手動で管理したりしていると、CI/CDパイプラインのなかでの自動実行を妨げる要因となってしまいます。 

この課題に対し、私たちはKarateとDatabase Riderという二つのツールを組み合わせる選択をしました。APIテスト自動化の構成は、以下の通りです。 

数あるAPIテストツールのなかからKarateを選んだ最大の理由は、Javaエコシステム（特にJUnit）との親和性とモックサーバー制御の容易さにあります。 

Karateは、Gherkin記法を用いて直感的にテストシナリオを記述できるだけでなく、Javaのライブラリとして動作するため、既存のJUnitテスト資産や開発者のスキルセットをそのまま活かすことができます。 

さらに、テストコード内でモックサーバーの起動や停止を完結できるため、CI/CD環境でも複雑な手順なしに、外部連携を含むテストを完結させることが可能になりました。

アノテーションひとつでDBを操るDatabase Rider

ここからは、Database Riderの選定理由について。これはDBUnitの思想を継承しつつ、JUnitのアノテーションを使ってDBの状態を直感的に制御できる強力なライブラリです。

例えば、`@DataSet`というアノテーションをテストメソッドに付与するだけで、テスト実行前に指定したデータ（YAML、JSON、CSV、Microsoft Excelなど多様な形式に対応）をDBに投入できます。

また、`@ExpectedDataSet`を使えば、テスト実行後のDBの状態が期待通りになっているかを自動で検証してくれます。 

これにより、複雑なSQLを書くことなく、テストケースごとに独立したデータ環境を数行のコードで定義することが可能になりました。 

KarateとDatabase Riderの最大の利点は、両者がともにJava/JUnitのエコシステム上で動作することです。

これにより、APIのリクエスト送信、モックサーバーの制御、そしてDBの事前事後処理までを、ひとつのJUnitテストとしてパッケージングできます。 

CI/CDパイプライン上では、通常の単体テストと同じコマンドを実行するだけで、DB検証を含めた高度なAPIテストが完了します。

開発者にとって馴染み深い環境で、かつワンコマンドで実行できる手軽さが、自動化を文化として定着させるための重要な要素となりました。

AI導入のターゲットを「もっとも面倒な作業」に絞り込む

テスト実行の基盤は整いましたが、実際にプロジェクトを推進するなかで、テスト実装工数のうち、実に50～60%がテストデータの準備に費やされているという事実が判明しました。 

テストロジック（Karateの記述）はパターン化されておりコピペで対応可能ですが、データのバリエーションをつくる作業は単調かつ膨大で、人間がやるには面倒な作業です。

そこで、私たちはデータ作成の自動化にAIリソースを集中させました。 

具体的な実装には、Visual Studio Code上で動作する自律型AIエージェント「Cline」と、GitLabのリポジトリ情報をAIに連携させるGitLab MCP（Model Context Protocol）が採用されました。 

まず、GitLab上にOpenAPIの仕様書やDBのテーブル定義を置いておきます。そして、開発者はClineに対して自然言語で指示を出します。

すると、ClineはMCP経由でGitLab上の定義情報を参照し、Database Riderで使用する形式のテストデータを自動生成します。 

これにより、開発者は複雑なデータ構造を一から手書きする必要がなくなり、条件を指定するだけでデータの雛形を入手できるようになりました。 

このアプローチにより、サンプルアプリを用いた試算では、テスト作成工数の約2割を削減できる見込みが立ちました。

もちろん、AIが生成したデータは完璧ではありません。しかし、ゼロから作成するのではなく、AIがつくった80点のデータを人間が修正して完成させるフローに切り替えることで、作業時間は大幅に短縮されます。

私たちは、この2割削減を目標に掲げ、プロジェクト全体への展開を進めていきました。

「銀の弾丸ではない」からこそ必要な、現場定着への泥臭いサポート

技術選定とAI活用の方針は固まりましたが、それを数十人規模のチームに定着させるのは別の次元のむずかしさがあります。AIは銀の弾丸ではありません。新技術を現場に浸透させるには、泥臭いサポートが重要です。 

私たちは、詳細なガイドラインやサンプルコードの整備に加え、全体に向けたレクチャー会を実施しました。さらに、SHIFTメンバーが各チームを横断的にサポートする体制を整えました。 

また、実際にいくつかのAPIテストを代行して実装してみせるトライアル期間を設けるなど、伴走型の支援を行いました。 

もちろん、開発手法の移行に関しては、現場からの反発も少なからず発生します。

GitLabでのマージリクエスト（MR）ベースのレビューを導入した際も、「Excelで管理していた頃の方がやりやすかった」という声が上がりました。 

こうした現場の不安や要望には、きちんと耳を傾けることが大切です。そのうえで、新手法のメリットを丁寧に説明すると同時に、本当に使いづらい部分についてはガイドラインを修正するなど、柔軟な対応を心がけました。

振り返ってみると、「強制する部分」と「現場にあわせる部分」のバランス感覚がポイントだったと思います。 

AI活用に関しても、現場からはシビアな反応がありました。「使ってみたけれど、期待通りのデータができない」「ハルシネーションで嘘のデータがつくられた」といった声です。 

実際に、企業向けプランで利用可能なモデル（GPT-4など）では、出力結果が安定しないこともしばしばありました。

特に複雑なデータ連携が必要なケースでは、AIがつくったデータをそのまま流しても動かないことが多々あります。 

私は、「AIがつくったものは必ず人の目で確認し、修正する工程が必要」という前提を周知徹底しました。

AIはあくまで初稿をつくるアシスタントであり、最終責任は人間がもつ。この期待値調整を行うことで、AIへの過度な依存や、逆に「使えない」という極端な失望を防ぎました。

ツールよりも大切なのは「使用者目線」。新技術導入を成功させるカギ

現在、プロジェクトはおおむね順調に進んでいます。進捗遅れが生じたアプリケーションについても、AIと自動化ツールの恩恵によって影響を最小限に留めることができています。

本プロジェクトを通じて、KarateとDatabase Riderを組み合わせたAPIテスト自動化は、DB検証の課題を解決し、CI/CDに組み込みやすい強力なソリューションであることが実証されました。

また、工数の大半を占めるデータ作成にAIを適用することで、工数削減の可能性も見えてきました。 

結局のところ、自動化もAIも、それだけで魔法のようにプロジェクトを成功させてくれるものではありません。

しかし、現場の一番面倒な作業にターゲットを絞ってAIを導入し、ツールを使いこなすための地道な支援をつづけることで、確実に景色は変わります。 

今回ご紹介した手法が、大規模なシステム刷新やテスト自動化に悩むみなさんの、次の一歩を踏み出すヒントになれば幸いです。

もし現場で迷うことがあれば、私の「KarateとDatabase Riderはいいぞ」という言葉を思い出してください。自信をもっておすすめします。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）