「最初から人間が書いた方がはやかった」という手戻りの罠

AI駆動開発によって、実装未経験のジュニアメンバーであっても、一定レベルのコードを圧倒的なスピードで量産できる環境が整いつつあります。

しかし、これは裏を返せば、「人間側の指示のあいまいさが、そのまま成果物の品質や設計のばらつきに直結する」という新たなリスクの顕在化を意味します。 

つまり、これからのAI駆動開発の主戦場は「いかに早く書かせるか」から「いかに手戻りなく制御するか（開発品質をいかに標準化するか）」へと移行しつつあります。 

この課題を解決するカギとして、私たちは仕様（Spec）をIssueに落とし込んで開発を制御する、“Issue駆動開発”という新たな開発手法への転換を考えました。

本記事において、Issueとは「AIが迷わず自律実行し、1〜2日程度で完遂できるアトミック（最小単位）な作業チケット」と再定義します。

具体的には、JiraやGitHub Projectなどのタスク管理ツールで用いられるチケットをイメージしてください。

しかし、「そもそもチケットをどのように記述すべきかが標準化されていない」というケースもあるでしょう。

チケットの書き方が開発者ごとに属人化していると、AIへのインプットが統一されず、アウトプットの品質もばらつきが生じます。

Issue駆動開発は、チケットに「何を、どう書くか」という記述のフォーマットを仕組みとして定義し、AIへのインプット品質を揃える“Issue設計”のプロセスを踏みます。

詳しくは後述しますが、AIにタスクを渡す前に、設計の妥当性を人間同士で議論し合意形成する“Issue設計レビュー”を徹底することで、指示の属人性を排除し、AIが迷わず完遂できるレールをあらかじめ敷いておくのです。

ただしIssue駆動開発は、Issueだけで開発を進めるわけではありません。そうすると、AIはそのタスクの範囲内だけで閉じた、局所最適な解決を図ろうとするからです。

その結果、リポジトリ全体で見たときのシステム整合性が崩壊し、コードの重複や責務の混乱といった技術的負債が一気に蓄積してしまいます。

これを防ぐためには、判断基準や一貫性を担保するSpecの責務と、作業境界や完了定義を示すIssueの責務を切り分け、双方が同期するループ構造を構築することが重要です。

AI駆動開発では暗黙知は通用しない。2つの失敗事例と解決策

私たちはIssue駆動開発を確立するまでに、2つの壁に直面しました。

壁1：変更範囲の肥大化

最初の壁は、変更範囲の肥大化です。人間同士であれば「今回はここだけ移行すればいい」という暗黙知が働きます。しかし、AIエージェントにはその前提が通用しません。

AIは気を利かせて推論を勝手に拡大し、スコープ外の関連クラスまで一気に書き換えてしまいます。

その結果、数十ファイルに及ぶ巨大な変更が含まれたプルリクエストが生成され、レビュー不能な状態に陥ってしまいました。 

そこで、散在するロジックの共通化といった大きなタスクを、実装単位まで細分化しました。

その上で、チケット内に「変更を許可するファイル」と「変更を絶対に禁止するファイル」を明記し、達成すべき期待結果（完了定義）をテンプレートに沿って記述。

AIが余計な推論を行わず、定められた範囲で動作できるようにしました。

壁2：作業の重複とコンフリクト

2つ目の壁は、複数のAIを並行して稼働させたときに起きた“作業の重複とコンフリクト”。

例えば、新しい画面の実装において、フロントエンドのタスクチケットとバックエンドのタスクチケットを、それぞれ別々のAIエージェントに同時に割り当てて開発を依頼しました。 

すると、フロントエンド担当のAIが「まだAPIがない」と判断し、勝手にAPIまで実装してしまいました。

プルリクエストの段階で作業の重複が発覚し、コンフリクト解消に無駄な時間を費やすことになります。 

この解決策として、関連するタスクを束ねる“親Issue”という概念を導入しました。親Issueに全体設計、スコープ、使用するテーブルなどの共通ルールを握らせます。

そして、個別のタスクである“子Issue”を実装するAIには、必ず事前に親Issueを確認するよう指示します。 

これにより、並行して走るAIエージェント同士が全体の文脈や順序依存を理解し、作業重複を早期に検出・回避できるようになりました。

これらの失敗から得られた教訓は、AI駆動開発においては「人間同士の暗黙知に依存してはならない」ということです。

システムの境界を定義・言語化し、AIが脱線することのないようにレールを敷くこと。これが、手戻りの削減につながる重要な考え方です。

実践！仕様と実装を乖離させない、Issue駆動開発のプロセス

ここからは、私たちのチームが実践している、具体的な開発プロセスの全貌をご紹介します。このプロセスは、人間が行う「上流のIssue設計」と、AIエージェントが自律的に実行する「下流の自動実装・同期」の2つのフェーズに分かれています。

【Issue設計】

1.仕様書を用意：要件定義書や基本設計書などのドキュメントを、リポジトリ内に格納し、一元管理します。

2.機能単位で抽出：仕様書をもとに、画面単位や機能単位（親チケットの粒度）で整理を行い、既存実装の調査や問題となりそうなポイントの洗い出しを行います。

3.Issueに分解：機能Issue単位に分解し、依存関係、見積もり、完了定義を明確にします。

★Issue設計レビュー：AIにタスクを渡す前に、「完了定義に漏れはないか」「作業境界は正しいか」「このチケット記述で、開発メンバー全員が同じ認識をもてるか」をチームメンバー間でレビューし、合意を形成します。

4.チケット自動生成：タスク管理ツールのAPIを介して、一括でチケットを生成します。

【実装・同期プロセス：後半】

5.実装（自動化）：システムがチケットの完了定義を読み込み、AIエージェントがコードの自動生成からプルリクエストの作成までを自動で完遂します。
もし誤った実装が発生した場合は、実装用プロンプトの修正だけでなく、「Issueの粒度が適切だったか」と設計フェーズまで遡って改善を回します。 

6.レビュー・merge：レビュー専用のエージェントを用意し、標準のGit hooksなどを活用してレビュー作業を自動化。レビュー指摘を集約したMarkdown形式のドキュメントを用意し、日々の知見を蓄積していきます。 

最後に行うのが、実装完了後の仕様同期です。開発の現場では、実装が進むにつれて設計書が陳腐化していく実態との乖離が大きな課題でした。 

そこで私たちは、AIが実装完了した際のソースコードの差分を検出し、リポジトリ内の仕様書ドキュメントに対して自動で書き戻し（追記・更新）を行うコマンドを構築。 

この双方向同期ループを回しつづけることで、ドキュメントがつねに“システムの現在地”を示しつづけるようになり、次のIssue設計も常に最新かつ正しい仕様前提で進められます。 

仕組みがエンジニアの力量差をカバー。開発チーム全体の“品質の下限”を引き上げる

Issue駆動開発を導入した最大の成果は、AIモデルの性能や開発メンバーのスキルへの依存を抑えられることです。

私たちは、高度な推論やアーキテクチャの決定といったプロセスをIssue設計という人間の上流フェーズを主に切り出しています。 

そのため、異なるAIモデル（Anthropic、OpenAI、Googleなど）を利用しても、出力品質のブレが少なくなります。

実際、私たちのチームで実施した検証においても、最上位モデル（例：Claude 3 Opus）と中位モデル（例：Claude 3.5 Sonnet）を比較した際、最終的な実装品質に予想以上の差は見られませんでした。 

優秀な特定のエンジニアの個人スキルや、過剰に高性能なAIモデルの力に依存する開発から脱却し、仕組みによって開発チーム全体の“品質の下限（ボトムライン）”を引き上げる。

これが、Issue設計の真の価値です。 

AI時代のエンジニアの役割は、ハーネスエンジニアリングのデザイナーへ

仕様、実装、テスト、そしてドキュメントへの同期までもが完全に自動同期ループする未来の開発環境において、エンジニアが担うべき専門領域は、自らコードを書くことではなく、ハーネスエンジニアリングへとシフトしていく可能性があります。 

ハーネスとは、自律的に動くAIエージェントが暴走しないように敷く「制御用のレールと境界線の仕組み」です。

今後のエンジニアに求められるスキルは、コードを書く力ではなく、このハーネスをデザインし、適材適所にエージェントを配置して監督する能力が重要になると考えられます。 

そして、ハーネスエンジニアリングという新たな役割を担ううえで、エンジニアが実際に行うもっとも重要な役割が、先述のIssue設計レビューなのです。

これまでは出来上がったコードをレビューしていましたが、それでは手戻りコストが大きすぎます。 

これからは、AIにタスクを渡す前のチケット作成段階において、「完了定義は妥当か」「作業境界は正しく閉じているか」「実装方針に問題はないか」を人間同士で事前に議論し、合意形成を行う必要があります。 

現在、私たちは個人が受けたレビュー指摘などをMarkdownで蓄積し、自分特化のレビュー指摘エージェントをつくるなど、個人の特性に応じた最適化を実験しています。

今後は、個人の知見をチーム全体へ共有し、組織の資産として統合することを課題としています。 

標準化によって“品質の下限”を引き上げると同時に、個人のナレッジによって“品質の上限”を引き上げる。この両輪を回すことが今後の最適化に繋がると考えています。 

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

AI活用を前提とした短納期プロダクト開発の幕開け

村田製作所 中矢氏：AIを活用した新規プロダクト開発は、チャレンジングな状況でスタートしました。というのも、私たちが越えなければならない高いハードルが同時に3つ存在していたんです。 

1つ目は、半年後にはリリースが求められるというビジネス上の要求があったことです。決められた期間内でのリリースが求められていました。 

2つ目は、村田製作所内でも事例の少ない、商用向けWebシステムの開発だったこと。確立された正解がないなかで、走りながら学習し、プロダクトを形にしていく必要がありました。 

そして3つ目のハードルが、AI活用を前提とした新しいチーム開発への挑戦です。そのために、村田製作所の内製開発メンバーと、SHIFTのメンバーによるスクラムチームを結成しました。 

村田製作所はAI駆動開発に力を入れて実装速度向上を狙い、SHIFT側には、村田製作所の別システムを開発した知見を活かして要求分析での支援を行ってもらう。これらを掛け合わせることで、短納期を乗り切ろうと考えました。

また、このプロジェクトでは、AIを使ってはやくつくるための環境も用意していました。内製チームには「開発速度を1.5倍以上向上する」という目標が課せられていたため、AIと親和性の高い技術スタックを採用しました。 

例えば、AIがプロジェクト全体を横断して参照しやすいようにソースコードを単一のリポジトリで管理するモノレポ構成を採用しました。

また、責務や関心を分離するクリーンアーキテクチャを取り入れ、AIが構造を理解しやすく、制御しやすい状態をつくりました。 

さらに、開発者の意図したコードをAIが高い精度で出力できるよう、仕様駆動開発（SDD）を取り入れたり、AI用のハーネス（実行環境）を整備したりと、生成速度と品質をコントロールする機構を初期段階でつくり込みました。 

この仕組みが功を奏し、プロジェクトが走りはじめると、開発初期から目標としていた「開発速度の1.5倍以上の向上」をあっさりと達成できたんです。

人間の手による従来の開発と比べて、スプリントごとに生み出される成果物（インクリメント）の量は目に見えて増えました。 

このスピード感には、プロダクトオーナー（PO）やステークホルダーからの評価も上々で、短納期のプロジェクトの達成も見えてきました。

スピードを追求した“先回り実装”は、すべて無駄になった

SHIFT 髙橋：AIの圧倒的な速さに刺激され、私たちは「もっと開発速度を上げられるのではないか」と考えるようになりました。そこで、従来の進め方を変える、新たな挑戦をしました。 

それまでは、画面とAPIをセットでつくって動作検証しながら進めていました。しかし、AIを使えばコードがあっという間に書けてしまう。

それなら、「先のフェーズで必要になるであろうAPIを、いまのうちに全部つくってしまおう」と考えたのです。

我々は最初から用意されたデザインを見て、「将来必要となるAPIであれば、簡易的なものであれば、AIで一気につくれば効率的だ」と捉えてしまったのです。 

最初は、この試みが成功したかのように見えました。5本ものAPIを一気につくり上げることができたからです。 

しかし、その後に要件がなくなったり、仕様が変わったり、そもそもそれまでつくってきたAPIで十分代用ができることがわかり、先行してつくった5本のAPIは、すべてが使われなくなりました。 

さらに、ただ無駄になっただけではありません。コードベースには使われないソースコードや、これまでと違う形式での仕様記述が残ってしまいました。人間にもAIにも読みづらい技術的負債となってしまったのです。

失敗から気づいた「YAGNI」原則の重要性。そしてアプローチの転換へ

SHIFT 髙橋：この失敗から、AIでどれだけはやくコードが書ける時代になっても、ソフトウェア開発の原則は変わらないと痛感しました。

それが「YAGNI（You Aren’t Gonna Need It）」原則、つまり「それはいまつくる価値があるのか？」という問いです。 

「最初からデザインがあるからつくる」のではなく、「スプリントごとに、いまつくる必要があるものを吟味し、一つずつ確認しながら進める」という当たり前の進め方の重要性をあらためて学ぶことができました。 

村田製作所 中矢氏：私たちの失敗の要因は、PO とデザイナーが作った初期デザインを、確定仕様のように扱ってしまった点にありました。

実際には、初期デザインはPOの頭の中のイメージを具現化しただけの“初期仮説”に過ぎなかったのです。 

プロダクトの中心となるコア機能については比較的確度が高かったものの、その周辺機能に関しては、ビジネスの状況やユーザー理解が進むにつれて変動しやすい特性をもっていました。

先回りしてつくった5本のAPIは、まさにこの「変動しやすい周辺機能」に関するものでした。 

この失敗を通して、私たちはリファインメントの進め方を根本から見直しました。これまでは、「この仕様をシステムとしてどうつくるか」「機能の振る舞いをどう実装するか」を主に議論していました。 

しかし、この失敗を経てからは「これは本当に必要な機能なのか？」「ユーザーに届けたい価値は何か？」をチーム全体で問い直す場へと再定義しました。

問い直すことで掴んだ、短納期リリースの成功

村田製作所 中矢氏：POを交えたリファインメントの結果、初期デザインに従うだけではなく、以下のような判断をPOとともにすることができるようになりました。 

・価値の不確かな機能のスコープアウト：主要な業務フローから外れる、ユーザー価値が曖昧な機能は思い切ってスコープから除外する。 

・管理機能の廃止と既存機能での代替：管理者用の特別な制御や画面を重厚に開発するのをやめ、既存の運用フローや簡易的な機能で充足させる。 

・簡易スクリプトによる代替：利用頻度やユーザー価値が低い機能については、システムとしての作り込みを行わず、バッチスクリプトなどでの代替を採用する。

「いま必要のないものはつくらない」「つくるにしても、もっともシンプルかつ最適な形を探る」。リリースするプロダクトのあるべき姿をチーム全体で考えることができたことが、その後の開発における大きな転機となりました。 

一連の経験を通して、私は「AIは増幅器である」という言葉の意味を身をもって知りました。AIは、開発速度を増幅してくれる反面、私たちが目的を見失えば「本来あるべき姿とのズレ」まで増幅してしまうんです。

今回、私たちはAIの速さに流されず、プロダクトのあるべき姿を問い直しました。その結果、不要なものをつくる時間を削り、短い期間のなかで本当に価値のある形に洗練させてリリースすることができました。

AI時代にこそ求められる、人間がプロダクトに向き合う価値

SHIFT 髙橋：今回のプロジェクトを振り返ると、もし従来通りの人間の手による開発だったなら、求められていた半年という短納期のリリースには間にあわなかったと思います。

AIの速さは、間違いなくプロジェクトを支える巨大な力でした。 しかし、速さを追い求めるあまり、無駄なものまでつくってしまった。

実装速度を上げるのはAIの役割ですが、「いま何をつくるべきか」「価値あるプロダクトとは何か」に向き直り、軌道修正するのは人間の役割なのだと強く実感しました。

また、DevとPO、内製とベンダーといった立場を超えて、いっしょにプロダクトのあるべき姿を考え、対話できたからこそ、最適な形でのプロダクトのリリースを迎えられたと思っています。 

AIによって誰もが簡単に、高速にモノをつくれる時代になりました。だからこそ、コードを書く前の対話が何よりも重要になります。

立場を超えて「これは本当に必要なのか？」と問い直せるチームの文化。それこそが、これからのAI時代にいままで以上に求められることになると信じています。 

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

年間約100万件にのぼる電話対応。品川区が取り組む自治体DX

品川区 西澤氏：現在の自治体は「深刻な担い手不足」と「業務量の増大」という二つの課題に直面しています。

日本の人口減少と高齢化により、2050年には高齢者の割合が約2.6人に1人になると予測されています。これにより、自治体職員の担い手不足が深刻化しています。

特別区（東京23区）の採用倍率はここ10年で3分の1まで低下しました。

職員の確保がむずかしくなるなか、年々変わる法制度への対応や、多様化する住民ニーズへの対応など、行政特有の業務は増えつづけています。

一方で、住民対応業務の多くにはアナログな業務がまだ残っており、住民との主要な接点も窓口や電話に集中しています。

そこで品川区が着目したのが生成AIを使った電話対応の自動化でした。

AIで対応できない内容は人へ引き継ぎながら、定型的な問い合わせはAIが担い、職員は判断を伴う対応に集中できる体制への移行を目指しています。

品川区の代表電話には年間約100万件の電話が寄せられており、戸籍住民課や税務課、国保医療課といった窓口系部署への問い合わせが大半を占めています。

そのため、本実証実験では、代表電話からの転送件数がもっとも多かった戸籍住民課の転入手続きを対象に設定しました。

「AIと人の役割分担」を明確に切りわけ

品川区 西澤氏：戸籍住民課のAs-Is（現状）の電話対応は、代表電話で受付担当者が要件を確認したあと、担当課へ転送し、オペレーターがFAQやマニュアルを参照しながら回答するという流れです。

回答がむずかしい場合は職員へエスカレーションしており、人手中心の対応を行っています。

To-Be（AI導入後）では、住民からの電話を直接AIが受けて要件を聞き取り、AIがFAQやマニュアルを参照して定型的な問い合わせに回答します。

AIが答えられない場合のみ人間のオペレーターへ、さらにむずかしければ職員へ転送する仕組みを実現しようと考えました。

以下の5点に期待し、Amazon Connectを採用することに決めました。

この取り組みでは、最初からすべてをAIに任せようとは考えていません。「何をAIに任せ、何を人が担うのか」という役割分担を切りわけていきました。 

AIには、一般的な問い合わせへの回答とマニュアルに沿って答えられることを任せ、AIがわからないことは人につなげてもらいます。

個別事情への配慮や例外的なケースの判断、専門部署との連携が必要な業務は人が担う領域として定義しました。

AI活用の現場で直面した3つの課題

品川区 西澤氏：この取り組みを進めるなかで、大きく3つの課題に直面しました。

1つ目は「条件や属性をどう聞き出すか」。
行政手続きは複雑な手続きフローや条件が絡みあっており、申請者の属性によって必要な案内や必要書類などが変わってきます。

例えば転入手続きでも、新規転入なのか、外国籍なのか、代理人による申請なのかによって必要書類が異なります。そのため、申請者の属性を正しく把握する必要がありました。 

2つ目は「知識や制度をどう読ませるか」。
元々使っていたExcelベースの業務マニュアルは、セルの結合が多かったり、画像データを使っていたりして機械可読性がよくありませんでした。

人間向けにつくられたものを、どのようにAIが扱える形にするのかが課題となりました。 

3つ目が「ハルシネーションをどう防ぐか」。 
転入手続きの問い合わせであっても、会話の流れのなかでマイナンバーカードや児童手当、国民健康保険といった関連手続きの話題に及ぶことがあります。

こうしたスコープ外の内容について、AIが誤った案内をしてしまうリスクをどのように抑えるかも重要なテーマでした。

多段階対話設計とAIネイティブ変換で挑んだ解決策

SHIFT 寅野：現場でみえてきた課題に対して、どのような技術的アプローチを実施したのか、2つご紹介します。

まず1つ目は、属性ベースの多段階対話設計です。 

問い合わせ者の属性の組み合わせによって、必要な案内が変わってくるため、一問一答形式では問い合わせ者の正しい属性を把握することができません。

そこで、問い合わせ内容の確認を終えると、問い合わせ者の属性確認を進めるという多段階の問い合わせ対応フローを設計しました。

Amazon Connectの標準機能にAmazon Bedrockを組み合わせ、 AIが利用者の回答に応じて必要な情報を確認する仕組みを設計しています。

従来のルールベースのチャットボットではなく、業務マニュアルをベースにしたRAG（検索拡張生成）と、AIオペレーターとして定義されたふるまいをAIエージェントが活用し、まるで人間のオペレーターのように「ご本人の手続きですか？」「転出証明書はおもちですか？」といった形で対話を進めながら属性を確認していきます。  

一方で、こうした対話を実現するには、AIが業務知識を正しく理解できることも欠かせません。

そこで必要になったのが2つ目のアプローチである業務マニュアルのAIネイティブ変換です。

既存のExcelベースの業務マニュアルは、セルの結合があったり、補足情報が欄外にあったりと、人間が文脈を補いながら読むことを前提につくられていました。

そのため、そのままRAGに取り込んでも、AIが正確に理解できず、適切な回答を生成できませんでした。 

そこで、AIエージェントが正しく回答できることに加え、職員の作業負担を最小限に抑える形で、Amazon Simple Storage Service（S3）に格納された業務マニュアルを、AWSとAmazon Bedrockを使ってAIネイティブな形式へ自動的に変換するアーキテクチャを構築しました。

ハルシネーションを防ぐために、変換プロセスのなかで決定木モデリングやセマンティックチャンキングも実施しています。

また、転入手続きに関する問い合わせ中に児童手当などスコープ外の質問があった場合には回答しないよう、ガードレールも設定しました。

自治体、SIer、プラットフォーマーの専門知を結集

品川区 西澤氏：今回の実証実験は、品川区とSHIFTさん、AWSさんとともに取り組んでいます。

自治体の業務現場における課題解決に向け、自治体とSIer、プラットフォーマーの方々と本取り組みを進められたことは、品川区にとっても非常によい機会になったと考えています。 

SHIFT 寅野：西澤様と同感です。技術的な対応が困難なところも、AWSのアーキテクトや、SHIFT社内の生成AIのスペシャリストの方々の力をいただきながら進めることができました。

各領域の専門家の力を結集して推進でき、よいプロジェクトになったと感じています。 

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

このままAIツールの紹介者で終わっていいのか

――前職でもAI導入コンサルタントとして活躍されていたそうですね。なぜ転職を決意されたのでしょうか？ 

田中：はい、前職でもAI導入コンサルとしてお客様の支援に携わっていました。当時はまだみんながAIを触りはじめたばかりの時期だったので、多くのお客様から導入のご相談をいただいていたんです。 

ただ、提案の中心になるのは、すでに社内で構築されたプラットフォームや、ChatGPTなど世にあるAIサービスを活用する「ツールありき」の案件。

お客様の業務課題をお聞きして、手元にあるツールを当てはめて「こう使えば効率化できます」と提案するスタイルがメインでした。 

技術の裏側、つまり「AIがどのように構築されているか」という構造的な部分まで深く理解する機会があまりなくて。

でも、AIはこれからさらに急速に変化・成長していく領域ですよね。このままツールの紹介者で終わってしまっていいのだろうか、という強い焦りがありました。 

変化に対応しながら、より高い技術を身につけてお客様に提供できる価値を広げていきたいという思いが、新たな挑戦へのきっかけになりました。 

――転職活動では複数の企業を検討されたと思いますが、SHIFTを選ばれた理由は何だったのでしょうか？ 

田中：最終的にSHIFTを含めて3社検討し、他には大手ITコンサルティングファームと、技術に特化した企業がありました。 

コンサルファームからは年収面で非常に魅力的な提案をいただきましたが、自分が一番やりたかった“技術に深く踏み込むこと”からは遠そうだなと感じました。

もう一方の技術特化型の会社は、高い技術力を学べる点では申し分なかったのですが、出社の頻度が高く、自宅からも距離がありました。

共働きで子育ての真っ只中の自分にとっては、働きやすさや家庭との両立の面でどうしても不安が拭えなかったんです。

決め手は圧倒的なスピード感と、“熱い仲間” 

――そのなかで、SHIFTがフィットしたわけですね。 

田中：SHIFTはAI領域での技術力もあるし、学び続けられる環境もあるし、働きやすさのバランスもうまく取れていると感じました。 

それと選考プロセスの圧倒的なスピード感も決め手になりました。一次面接のその場で「ぜひ来てほしい」と評価をいただけたんです。

意思決定のはやさを感じましたし、人をちゃんとみて大切にする姿勢は、面接官（現在の上長）との会話のなかでも感じました。 

また、内定をいただいてから入社するまでの間に、社内の表彰イベントであるSHIFT AWARDに招待してもらったんです。

会場は、「ここにいる全員が本気で社長賞を狙っているんだ」と感じるほど、エネルギーに満ちあふれていました。「この組織なら、自分も刺激を受けて成長できる」と直感し、入社を決めました。 

――実際に入社されてみて、SHIFTの熱量に対するギャップはありませんでしたか？ 

田中：むしろ想像以上でしたね。とにかくみなさん勉強熱心で、最新技術トレンドや事例を共有する勉強会、デモ会を自発的にどんどん立ち上げているんです。 

最初は勉強会で飛び交う技術的な専門用語が理解できず、焦りました。しかし、受け身にならず自走する周囲の姿勢に引っ張られ、私も刺激を受けて必死でキャッチアップし、Microsoft AzureのAI関連の資格などを取得することができました。 

また、わからないことをチャットで相談すると、顔をあわせたことがなくても他部署のエキスパートが多様な回答やアイデアを送ってくれるんです。「生成AIについて本気で語りあえる仲間がいる」というのは本当に心強いですね。

“組織知”をハブとして手繰り寄せ、CS調査で得た手ごたえ

――そうした組織の知見が、実際の案件でも活かされたエピソードはありますか？ 

田中：現在担当している製造業のお客様のプロジェクトがまさにそうです。 

この案件では、設計管理フロー全体のリードタイム短縮を目的に、生成AIのPoC（概念実証）を行っています。 

一般的に、コンサル会社は現状分析（As-Is）やあるべき姿（To-Be）の整理、業務プロセスの細分化までを業務範囲としています。

一方で、SHIFTではそれらを含めて「細分化した業務プロセスを具体的にどう生成AIの技術に落とし込み、構築し、精度を上げていくか」という技術的実装も担います。 

これは、SHIFTが提供する「アドバンスドFDE（フォワード・デプロイド・エンジニアリング：特定のプロダクトに縛られず、お客様の現場に伴走して技術を実装・定着させる役割）」というスタンスそのもの。

戦略を提示するだけでなく、実際に技術を落とし込むところまで責任をもつのが、SHIFTのAIコンサルのやり方です。 

例えば、今回のお客様に関しては「いまのPoCのやり方で行き詰まった、何か他の方法はないか」と悩まれているのをみて、私は普段から社内の勉強会や成果発表会、公開デモで収集していた情報をフルに活かしました。 

「その課題なら別チームで類似の技術を使っています」「社内に詳しいメンバーがいるので聞いてきますね」と、SHIFT全体のAI知見をハブとなって手繰り寄せ、スピーディーにお客様へ提案しつづけたんです。 

その結果、CS（お客様満足度）調査で、「田中さん個人の知見にとどまらず、SHIFT全体として膨大なAIノウハウを提供してくれる点が非常に素晴らしい」と高い評価をいただきました。 

個人の知識だけに頼らず、組織の強みを引き出してお客様を勝たせる姿勢こそが、SHIFTでAIコンサルタントとして働く強みだと実感しました。

消極的だった現場の顔が変わった。“手触り感”の届け方

――PoCの進捗は順調ですか？ 

田中：ええ。一定の効果がみえてきており、そうしたユースケースに関しては本番環境の構築に進んでいます。一貫して関わることで、お客様の現場に価値が生まれていく過程をみられるというのがすごく楽しいですね。 

――反対にAI案件ならではのむずかしさを感じるのはどんなところですか？ 

田中：AIならではのむずかしさは、やはり技術進化のスピードが異次元に早いこと。それからお客様の運用コストを意識した設計も不可欠です。

AIは優秀ですが、すべてをAIに丸投げすると、従量課金（トークン量）のコストが莫大になってしまいます。 

そのため、「プログラムで処理できる構造化された部分はプログラムで、文脈の解釈が必要な部分だけAIを使う」といった、精度・コスト・レスポンス速度をすべて考慮したアーキテクチャ設計を日々行っています。 

――現場の定着や啓蒙も大きなハードルになりそうですね。 

田中：まさにそこが重要です。

AIを導入することがゴールではなく、現場に定着してはじめて価値が発揮されますが、「本当に現場が継続して使ってくれるか」という不安は、多くのお客様が抱えられています。現場で使いやすい仕組みづくりや、利用イメージの共有が大切です。 

またAIのアウトプット精度を担保するには事前のデータ整備も欠かせません。できればそのままAIに扱ってほしいと思うお客様に対して、前処理の重要性を理解いただき、いかに効率的に進めるかも重要なポイントです。 

実際、私が参画した別のあるお客様の案件では、経営層の「AIを導入するぞ」という号令に対して、現場は消極的でした。 

社内の別部署がAIの使い方に関する勉強会を開催していたのですが、オンラインの一方通行の説明や配信資料では、現場にとって「自分たちの仕事がどう変わるか」の実感が湧いていなかったんですね。 

私は「現場の方々に“手触り感”をもってもらうしかない」と考えました。そこで、現場の方々から実際の業務データを直接お預かりして、活用シナリオとユーザープロンプトを書いたんです。 

それを実際に使ってもらった瞬間、現場のみなさまの表情が一変しましたね。「あの作業にも使えるのでは」「この面倒なデータ処理も自動化できる？」と、主体的なアイデアが湧き出てきたんです。 

最終的には、現場の方々も積極的にPoCの検証に参加してくださるようになったんです。

目まぐるしい変化を楽しむ。「まずは触ってみる」好奇心が武器になる

――入社してまだ1年弱ですが、転職前の「技術のわかるコンサルタントになりたい」という課題はクリアできたと感じますか？ 

田中：はい。いまでは要件定義からアーキテクチャ設計、UIの仕様書作成、そして本番導入、コスト設計まで一貫して関われるようになり、自分のケイパビリティが圧倒的に広がったと感じています。

評価の面でも、SHIFTには不条理な相対評価や年功序列はありません。さきほどのCS調査での高い評価をみて、上長から「（評価結果を）期待しておいてね」と言葉をかけてもらえて、モチベーションが上がりましたね。

頑張った分だけ正当に評価される。この安心感があるからこそ、さらに高いレベルに挑戦しようと思えます。 

――今後はどのような挑戦をしていきたいですか？ 

田中：これまでは個別のお客様の課題解決にコミットしてきましたが、今後はそこで得た知見や成功パターンを抽象化し、他のお客様にも横展開できるようなソリューションや新サービスの企画・仕組み化に挑戦したいと考えています。

――最後に、これから AI領域でキャリアを築きたいと考えている求職者の方へ、メッセージをお願いします。 

田中：AI領域は、明日何が起こるかわからないほど目まぐるしく変化します。しかし、新しい技術に触れるのが好きで、変化を楽しめる人にとって、これほど刺激的で面白い環境はありません。 

新しい技術を前に「まずは自分でどっぷり浸かって、触って、確かめてみる」。そんな知的好奇心をもった仲間と、この変化の激しい最前線の領域をいっしょに楽しめたら、これほど面白いことはないと思っています！ 

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

国境と組織をまたぐ、複雑案件のハンドリング

――忠田さんは現在、幅広い案件を担当されていると聞いています。まずは、現在の具体的な業務内容について教えていただけますか？ 

忠田：PM兼プリセールスとして、主にMicrosoft 365（M365）や生成AIに関するプロジェクトの提案から伴走支援までを担当しています。 

具体的には、お客様の課題や期待される成果を整理し、要件の確認や解決策の提案を行っています。

プロジェクト開始後はPMとして、現状調査やアセスメント、要件定義、運用設計、導入後の定着化に向けた伴走支援まで、一貫してプロジェクト推進に携わっています。 

直近では、国内製造業の海外グループ会社におけるM365テナント統合でPMを務めています。また、建設業のお客様におけるM365 Copilot活用に向けたDX人材育成支援では、PMと研修講師を担当しています。 

――海外拠点も絡むような複雑でスケールの大きな案件を、スピーディに推進できる背景には何がありますか？ 

忠田：こうしたプロジェクトで大きな障壁となるのは、国境や部署の違いによって生じる利害や権限を調整するコストです。 

例えば、海外グループ会社のM365テナント統合では、国をまたいだ契約手続きや、グループ会社・事業部間での利害調整など、多くの関係者を巻き込むため、検討や意思決定に時間を要するケースも少なくありません。

しかしSHIFTでは、構築や運用保守を担う部署はもちろん、ときにはグループ会社の垣根を越えて、必要な知見や人的リソースを柔軟に組みあわせられます。社内調整にかかる時間をお客様との対話や課題整理、提案活動に充てられるのです。 

こうした環境があるからこそ、複雑なグローバル案件にもスピーディに対応できているのだと思います。

提案からPMまで。自ら「現場をデザインし、動かす」醍醐味

――組織間の壁がないからこそ、迅速に動けるのですね。忠田さんは提案活動からPMまで一貫して携わっていますが、そのスタイルへのこだわりはありますか？ 

忠田：はい、あります。「PMが提案もやるの？」と驚かれるかもしれませんが、私は「どちらか片方だけやって」といわれたら、多分「嫌です」といっていたと思います（笑）。 

私は、お客様の課題整理や提案活動の段階から関わり、いっしょにゴールを描いて具現化するスタイルにやりがいを感じているんです。 

“提案は営業の仕事”と割り切っていては得られないおもしろさがありますし、SHIFTにはそうしたスタイルを後押ししてくれる環境があると感じています。 

――課題の整理から入り込んで自分で形にしたいという想いは、これまでのキャリアのなかでも感じていたことですか？ 

忠田：そうですね。それまでのキャリアでは、運用保守から運用品質管理、サービス企画・販促まで幅広い経験を積んできました。契機となったのは、販促活動を通じてお客様の困りごとを直接伺ったことが転機でした。 

お客様の生の声に応えようと組織横断の取り組みを推進するなかで、丁寧な合意形成の大切さを学ぶ一方、組織規模や事業特性による制約から、適用範囲が限定的であったり、運用が複雑化したりと、総合的な判断のむずかしさを実感することもありました。  

こうした背景から、「もっとお客様に近い場所で、いっしょに課題を整理し、事業をよりよくするプロジェクトマネジメントに挑戦したい」と考えるようになりました。

そうした想いから転職活動を行い、コンサルティングファームからも内定をいただきましたが、「幅広い案件があり、自分の可能性を広げられそう」「一番自由度が高く挑戦できそう」と感じたのがSHIFTでした。

目的を失ったプロジェクトに息を吹き込む、対話型のアプローチ

――実際のプロジェクト現場で、停滞や困難に直面したときはどのように紐解いているのですか？ 

忠田：例えば生成AI領域のプロジェクトでは、「生成AIを活用する」という方針だけが先行し、自分たちの事業をどうしたいかという目的が曖昧なまま進んでしまうケースがあります。 

そうしたときは、「何のために活用するのか」「その施策はいま必要なのか」という問いに、お客様とともに向き合います。お客様のカルチャーや立場なども考慮しながら、目指すべきゴールをお客様といっしょに再定義していきます。 

また、プロジェクトの立て直しや推進においては、「メンバーとの対話」によって目的を揃え、チーム自体の自走力を高めることを意識しています。 

――「メンバーとの対話による自走」とは、具体的にどのようなアプローチでしょうか？ 

忠田：生成AIの黎明期に担当した、自治体向けの生成AI導入PoC案件がまさにそうでした。PMとして参画した際、メンバー間の認識のズレから議論が発散し、プロジェクトは遅延していました。 

そこで、社内外のステークホルダー一人ひとりとの対話の機会を設けました。対話を通してそれぞれの期待や懸念、本音を聞き取り、発散していた意見をプロジェクトの目的に照らして整理しました。 

SHIFTのフラットな環境があったからこそ対話を最優先できましたし、それによって「お互いの強みを尊重し、同じ目的に向かえる」という安心感が生まれました。

加えて、チームが自律的に機能しはじめ、最終的には予定していたPoCを完遂することができました。その後の継続的な支援にもつながり、プロジェクトを成功へと導くことができました。 

――そうした「自走型マネジメント」は、他のプロジェクトでも活かされていますか？ 

忠田：はい。タイのお客様のM365テナント統合案件も同様でした。この案件では、日本にいる私がPMを務め、ベトナムを拠点とするグループ会社、SHIFT ASIAの技術メンバーと国境を越えて連携しました。 

国も言語も異なるチームだからこそ、細かな指示や過度な確認によるマイクロマネジメントを避けることを意識しました。

代わりに「プロジェクトの目的」「今後の見通し」「契約上の対応範囲」を丁寧に共有し、メンバーが安心して判断できる環境をつくりました。 

その結果、ベトナムのメンバーがもつ専門性とお客様視点が発揮され、タイのお客様に寄り添った対応につながりました。距離や言語の壁を越えて、お客様から感謝の言葉をいただいたときは、胸が熱くなりましたね。

曖昧な課題を解き明かす“デザイン力”こそ、PMのプロフェッショナリズム

――これからの時代において、PMが身につけるべき本質的なプロフェッショナリズムとは何だと思いますか？ 

忠田：単なるツールの知識や進捗管理のテクニックではなく、曖昧な課題を正しく捉え、実現に向けた道筋を描く“デザイン力”こそ、これからのPMに求められる本質的な力だと思っています。 

この“デザイン力”は、複雑な課題を「分解して描く力」と、状況の変化を捉えて「評価し、描き直す力」の2つで成り立っていると考えています。 

まず、複雑な課題を「分解して描く力」とは、お客様が抱える課題に対し、それぞれの立場や本音を対話で紐解きながら、前提条件やリスクの関係を細かく要素分解するとともに、「何を実現すべきか」「何を基準に判断すべきか」という道筋を描く力です。 

そして、状況の変化にあわせて「評価し、描き直す力」とは、計画は流動的なものだと捉えて、「前提は変わっていないか」「解釈にズレはないか」を絶えずたしかかめながら、状況の変化にあわせて素早く道筋を修正する力です。 

――チームの自走も“デザイン力” の一部ということですか？ 

忠田：はい、チームマネジメントもまさに“デザイン”の領域です。PMの役割は樹木が育つ環境に整えることに似ていると思っています。木が育っているか心配だからといって、毎日根元を掘り返して確認する人はいませんよね（笑）。

プロジェクトも同じで、細かく管理しすぎると、メンバーは自ら考えて動く機会を失ってしまいます。 

樹木は異なる役割をもつ高木、中木、低木が、風通しや日差しなどを調和させることで健やかに育っていきます。チームも同じで、異なる経験や専門性をもつメンバーが自律的に動き、お互いを補完しあえる環境をつくることが大切です。 

チームが自然と自走し、力を発揮できる環境を設計する。これこそが、私が考える”デザイン力”です。 

―― “進行役”としてのPMから脱却するための核心ですね。 

忠田：そうですね。生成AIが情報整理や進捗管理を支えてくれるようになるからこそ、これからのPMは”進行役”ではなく、プロジェクトにとってよりよい意思決定につなげていくことが重要になると思います。 

関係者の背景や感情を捉え、複雑な利害関係のなかから進むべき道筋を描くこと。そして、状況の変化を評価し、道筋を柔軟に描き直していくこと。

これら人間ならではの”デザイン力”の価値は、AI時代において高まっていくはずです。

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

AI×セキュリティの最前線に身を置く、「自称ジェネラリスト」

――入社してもうすぐ丸1年ですね。仕事に部活にと、あっという間だったのではないでしょうか？ 

村木：本当にそうですね。仕事はもちろん、入社3日目で立ち上げたキーボード部の活動など、公私ともに目まぐるしく、一週間が本当に早く過ぎてしまう1年でした。 

――そのスピード感がまさにSHIFTらしさですね。では本題に入りますが、 村木さんが現在担当されている現場は、ハイレベルな環境だと伺いました。 

村木：そうですね。私が身を置いているのは、取得難易度の高い情報セキュリティの国際的な認定資格をもつプロフェッショナルが多数集まる現場です。そこで業務利用される各種AIやクラウドサービスの安全性を評価・担保する審査業務を主導しています。 

AI×セキュリティという領域には、大きく2つの軸があります。ひとつは、AIを活用して日々の業務やセキュリティ管理の効率化・高度化を図る「AI for セキュリティ（セキュリティのためのAI）」の実践です。 

私たちのチームでも、膨大な審査を遅延なく進めるために進捗管理システムを自作・公開したり、現場の運用コストを削減したりと、改善活動を能動的に推進してきました。 

――もうひとつの軸は？ 

村木：生成AIやAIエージェントそのものを未知の脅威から守る「セキュリティ for AI（AIのためのセキュリティ）」です。

こちらが私たちの手がける審査業務のメインターゲットであり、プロンプトインジェクションをはじめとするAI特有の脅威に対するリスクとコントロールの評価などを行っています。 

さらに、現在ではAIシステムに対する「攻撃演習（AIレッドチーミング）の内製化」も手がけるようになりました。これは、国内でも支援実績がほとんど存在しないといわれています。 

――それほど高度な案件を担当できるのは、村木さんがその領域の“専門家”だからなのでしょうか？ 

村木：実は、まったく逆なんです。世間一般でいう“器用貧乏”とも捉えられかねない“ジェネラリスト”なんですよ。しかし、このスタンスがいまの私を支える強みになっています。

専門の枠にとらわれないからこそ、「専門家が壁をつくって立ち止まってしまう境界線」に直面しても、壁をつくらずに隙間を埋めることができる。

ただ、私が自分の専門を限定せず、必要な技術をその場で獲得するというスタンスの裏には、ある信念と、前職での葛藤がありました。

幅広い分野を何でも貪欲に学び抜く。SHIFTは私の経験を正しく理解してくれた

――その信念と、前職での葛藤について教えてください。 

村木：私の行動原理の根本には、「山を高くするために裾野を広げる」という信念があります。

「すぐ役に立つものほど、すぐ役立たなくなる」という格言がありますが、これは「一見何に役立つかわからない知識ほど、実は寿命が長い」というもの。私はこれを、興味の赴くままに何でも学んでいく自分への免罪符にしているのです。 

そうして自分の知識や技術の裾野を広げておくことは、人生において”選べない状況”に陥る確率を下げるための、私なりの防衛策でありキャリア戦略でもあります。生きる上で一番不幸なことは”選択肢がないこと”だと思っていますから。 

その考えに従って、これまでITインフラ技術にとどまらず、総務、経営企画、社内情シス、そのほか管理部門の業務まで、横断的に知識を吸収してきました。

しかし、それを活かして合理的と思われる改善提案をしても、専門外の意見と受け止められ、実現に至らない歯がゆさを味わいました。 

――そこから転職活動を行われたと。 

村木：はい。しかし転職活動でも、「法務からITインフラまで何でもできる」というアピールは、一般的な面接官から「専門性がない」と、自分の本質的な価値が伝わらないもどかしさに直面しました。

そんななか、私の経歴の全容を正しく理解してくれたのがSHIFTでした。 

面接官がAI BPaaSの前身であった当時の部署を紹介する言葉として選んだのが“カスタマーサクセス”だったんです。

「お客様の欲しがるものではなく、お客様にとって本当にためになる価値（カスタマーサクセス）を提供しよう」という思想にも惹かれましたし、私のなかの改善志向と合致していました。 

SHIFTなら自分の強みが活きる、私の経験が価値になると直感して入社を決意したんです。 

「セキュリティ for AI」の最前線で、ジェネラリストが活躍できる理由

――その直感は正しかったとおもいますか？ 

村木：ええ、入社後、確信に変わりました。専門外の領域に躊躇なく手を伸ばす“領域侵犯”が、SHIFTではむしろ歓迎されたのです。 

もともと私にとって、技術の勉強や検証環境の構築は20年来のライフワークなんです。これまでも自宅ラボに個人でM365テナントやゼロトラスト環境を構築して検証をつづけてきましたし、買い込んできた専門書も累計で400〜500冊にのぼります。 

ですから、AI×セキュリティという領域への挑戦が決まった際も、その延長線上で自然と没頭しました。改めて数十冊の専門書を買い足し、手元の検証環境をさらに広げて検証を重ねていったのです。 

国内に日本語の資料が存在しない「セキュリティ for AI」の手法については、洋書や海外の論文、OWASP LLM/Agentic Top10、MITRE ATLASといった一次情報を、自前のClaudeも活用しながら解読しました。 

――SHIFTと出会ったことで、村木さんのジェネラリストとしての強みが花開いたのですね。その強みは、現場でどのような価値を生んでいるのでしょうか？ 

村木：大きく3つあります。1つ目は、「AI×セキュリティの境界線を埋められる」ことです。“AI×セキュリティ”は双方の専門家同士でも相互理解がむずかしい領域です。

しかし、私のように「専門にこだわらず、興味の赴くままに何にでも手を出して体当たりで学ぶ」ということを20年もやりつづけてきた人間だからこそ、専門家が壁をつくって立ち止まってしまう隙間を、滑らかに繋ぐことができます。 

――なるほど、領域のエアポケットを埋められるのはジェネラリストならではですね。2つ目は？ 

村木：2つ目は、「技術にとどまらず、多角的なリスクを検知し網羅できる」点です。 AIセキュリティ審査は、単にシステムの穴をハックする技術的な側面だけでは完結しません。

生成画像を利用する際の著作権問題や、企業ブランドを損なうレピュテーションリスク、さらにはお客様の社内規程や業務プロセスに落とし込めるかといった“会社全体のリスク”を見抜く総合力が問われます。 

管理部門や法務、契約実務まで横断して学んできた“裾野の広さ”があるからこそ、技術単体にとらわれない多角的なリスク評価と安全性の保証を提供できています。 

――3つ目は何でしょうか？ 

村木：3つ目は、「枠に囚われない改善志向で、現場の不合理を改善できる」点です。 

自分の役割を限定せず、現場の不合理を見つけたら先回りして解決する。その結果が、お客様からの強い信頼につながっています。

――「AI BPaaS」というビジネスモデルについては、最先端の現場での実践を踏まえてどう感じますか？ 

村木： AIによって個々の技術や単純作業は急速にコモディティ化し、業務は劇的に“工業化”されていきます。 

現在、AIの高度な活用現場では、メインエージェントが複数のサブエージェントを統制し、チームとして自律的に業務を回す“マルチエージェント協調による工業化”がすでにはじまっています。 

一例としてあげると、あるAIエージェントがタスクを実行し、別のサブエージェントがそのためのテストを設計・実行し、さらに別のエージェントがそのテスト品質を評価・判断するというサイクルを自動で回しあう進め方です。 

こうなると、もはや個々のタスクを誰がこなすかというレベルではなく、全体プロセスをいかにロジカルに組み立てるかという全体設計の勝負になります。 

それはいわば「AIプロセス全体の品質保証」であり、品質を武器に価値を提供してきたSHIFTには、これまでの強みとノウハウを活かせるフィールドが広がっています。 

一般的なIT企業が「技術やシステム（商品）を売る」のに対し、SHIFTは技術がコモディティ化するリスクを見越し、「技術ではなく業務そのものを請け負い、成果に責任をもつ」という極めて合理的なAI BPaaSというビジネスを打ち立てました。 

私は社内の勉強会などでも「AIは、自分の実力がそのまま反映される鏡である」とよく伝えています。AIの出した答えをただ鵜呑みにして使うだけの人は、これからの時代、すぐに淘汰されてしまうでしょう。 

そこで大切になる、AIを使いこなす根本的な能力とは「適切な問いを立てられるか」です。適切な問いを投げかけてAIの行動を修正し、システム全体のプロセスを設計して最終成果物の「責任と保証」を担う。

これこそが、人間にしかできない本当の価値です。この「人間の責任と品質保証」をビジネス化した「AI BPaaS」は、まさに時流を捉えた負けにくいモデルだと感じています。 

――最後に、かつての村木さんのようなジェネラリストへメッセージをお願いします。 

村木： 従来のIT支援において、現場だけでなく、事務経験などで培った業務知識や多角的な経験は、どこか「間接的な知識」にとどまりがちでした。

しかし業務を請け負いながらAIを前提に業務自体を再定義していく「AI BPaaS」においては、その業務知識がまさに再設計そのものへダイレクトに化けます。 

多様なバックグラウンドを歩んできた人ほど、SHIFTという環境で自分の裾野の広さを武器に、この最前線の面白さに挑んでほしいですね。 

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

Q1. なぜ転職を考えたのですか？

「AI時代に価値を発揮できるエンジニアでありたい」
Copilotをはじめて業務で使ったとき、「エンジニアの働き方は大きく変わる」と衝撃を受けました。

AIを使いこなせないままでは将来的に価値を発揮できなくなるという危機感から転職を決意。企業選びでは、AIへの取り組みがどこまで本気で具体的かを重視していました。（AIテックリード・30代） 

「生成AIを使って、もっとお客様の課題解決に向き合いたかった」
前職では自社製品の提案を担当していました。より幅広い選択肢のなかからお客様に最適な提案をしたいという思いが強くなり、生成AIを活用した課題解決に挑戦したいと考えるようになりました。

転職では生成AIを利用したコンサルができることや、チームで価値を生み出せる環境を重視しました。（AIテックリード・40代） 

「より大きなフィールドでAI活用に挑戦したかった」 
前職では技術責任者としてのインフラ領域に携わる一方、AI活用施策でも成果が出るなど、手応えを感じていました。

その一方で、さらに大きなスケールでAI活用を推進したいという思いも強くなり、新しいチャレンジの場を探しはじめました。（AIコンサルタント・50代） 

「これまでの経験を活かしながら、AI領域に挑戦したかった」
前職でプロジェクトが一段落したタイミングで、自身のキャリアを見つめ直しました。

ソフトウェアPMとしての経験を活かしながら、AIなど最新技術の進展にも関われる環境を求めるようになり、転職では「AI×PM」に挑戦できることを重視しました。（AI PM・50代） 

「家族との時間もキャリアも大切にしたかった」
管理職と開発を兼務するなかで、「この働き方を今後20年以上つづけられるだろうか」と将来のキャリアを考えるようになりました。

子どもが1歳半で第二子も生まれるタイミングだったことから、転職ではいまの街に住みつづけながら働けることや、リモートワークが可能な環境を重視しました。（AIテックリード・30代） 

Q2. なぜSHIFTを選んだのですか？

「AIへの本気度が伝わってきた」
選考を通じて、会社全体で本気でAIに取り組んでいることが伝わってきました。AI活用の具体性に加え、意思決定のはやさやフットワークの軽さも魅力でした。（AIテックリード・30代） 

「AIで社会課題に挑む姿勢に共感した」
最初は条件重視ではじめた転職活動でしたが、面接でAIモダナイゼーション事業への想いに触れ、「やりがい」が意思決定に影響を与えました。

AIを活用してレガシーシステム刷新という社会課題の解決に挑む姿勢に強く惹かれ、入社を決意しました。（AIテックリード・30代） 

「最もやりたいことが実現できそうだった」
AI×ソフトウェアPMという、自分が挑戦したいテーマに最も近い環境でした。働き方や年収面も希望と合致しており、長期的なキャリアを描けると感じました。（AI PM・50代） 

「AIに賭ける経営陣の覚悟を感じた」
決算資料から伝わってきたAI Native化への強い意思に共感しました。選考を通じて、現場のリアルな姿を知れたことも入社を後押ししました。（AIコンサルタント・50代） 

「AI活用だけでなく、企業理念にも共感した」
転職で重視していた条件を満たしていただけでなく、『SHIFT解剖 究極の人的資本経営』（日経BP刊）を通じて丹下さんの考え方や企業理念に共感しました。

AI活用を “誰でもできる仕組み”として広げようとしている姿勢にも魅力を感じました。（AIテックリード・40代） 

「AIを武器に成長できる環境だと感じた」 
面接を通じて、AIを武器にモダンな開発へ挑戦していることが伝わってきました。

事業運営や採用のスピード感もあり、自分次第で成長できる環境だと感じたことが応募・入社の後押しになりました。（AIテックリード・30代） 

Q3. 実際に入社してみてどうですか？

「自ら手をあげる文化が根づいていた」 
入社後は、組織の大きさや入社者研修における情報量の多さに驚きました。自ら発信し、主体的に動くことが求められる環境で、その点はSHIFTのカルチャーそのものだと感じています。（AIテックリード・30代） 

「想像以上に変化がはやい」 
入社前から変化のはやい会社という印象はもっていましたが、実際は想像以上でした。新しい取り組みが次々に生まれ、AI活用も含めて常に進化しつづけていることを実感しています。（ストラテジックアーキテクト・40代） 

「熱量とスピード感を実感している」 
入社後に最も感じたのは、会社全体の熱量の高さです。新しいことに挑戦しようというエネルギーが組織全体にあり、そのスピード感も含めて大きな魅力だと感じています。（AIテックリード・30代） 

「ワークライフバランスもいい」 
急成長企業というと激務なイメージをもたれがちですが、実際にはワークライフバランスもよく、長く働ける環境だと感じています。（AI PM・50代） 

最後に

いかがだったでしょうか？みなさんの声に共通していたのは、「AIに触れられる会社」ではなく、「AIを本気で事業や仕事に取り込もうとしている会社で働きたい」という想いでした。 

AIとともに成長し、新たな挑戦をつづけたいという想いをもつ人がSHIFTには集まっています。AIに本気で向き合える環境で、次のキャリアに踏み出してみませんか？

AIモダナイゼーション事業 採用情報

開発スピードの加速が招く “QA業務のボトルネック化”をどう防ぐか

近年、AIを活用した開発手法の進化により、プロダクトの企画から市場投入までのサイクルは劇的に高速化しています。ビジネスの競争力を高めるうえで、このスピード感は大きな追い風になっています。

しかし、その反面、開発される機能の量は爆発的に増加し、それに伴って品質を検証すべきテスト範囲も規模が拡大しています。 

開発のスピードがどれほど加速しても、つくられたプロダクトが正しく動くかを確認するQA業務の多くは、依然として人の稼働時間に依存しています。

限られた人員と時間のなかで膨大なテストをこなさなければならない旧来型のQA業務は限界に近づき、事業成長を阻むボトルネックになりつつあるのです。 

この課題を解決するうえで重要なのは、単純な人員の増強ではありません。人海戦術によるアプローチを脱却し、AIを活用してテストプロセスそのものの構造を抜本的に変革することにあります。

AI時代におけるQAの“あるべき進め方”とは？

SHIFTにおける従来のQA業務は、お客様から機能仕様書などのプロダクト情報をいただき、テスト計画やテスト設計（テストケースの作成）を行った後、お客様のレビューを経てテストを実行し、品質情報をフィードバックするという流れでした。

現在、私たちが取り組んでいるのは、この一連のプロセスのなかで、従来は人手で行っていたテスト設計と実行をAIで実施する取り組みです。

勤務時間やアサイン調整、キャッチアップによるリードタイムの増加など、人手でのテストの制約を取り除くことで、品質フィードバックをさらに高速化します。 

今回は、特に熟練の思考力が求められるテスト設計を、AIでどのように実現したのかに焦点を当てます。

機能テストを対象に「対象とするシステムを限定せず、弊社のテスト設計プロフェッショナルと遜色のない品質のテストケースをつくり出すこと」を目指しました。

AIへのインプットは、開発ドキュメントと弊社エンジニアが作成するテスト方針の2つに絞りました。

プロの暗黙知を体系化した「SQF」とAIの自己採点で、高品質を担保する

弊社の現場で運用するためには「人が理解し、必要に応じて修正できる成果物であること」が必要でした。そのため、アウトプットはテストコードではなく、自然言語で書かれたテストケースであることを要件としました。 

また、テストケースの書き方や粒度はこれまで手動のテスト設計で実践してきたとおり、SHIFT独自の品質保証標準「SQF」に準拠する必要があります。これにより、カバレッジやテスト実行時の可読性を担保します。 

SQFは、世界的品質保証標準（ISTQB、ISO／IEC／IEEE 29119）と年間4,000件の支援経験から得たナレッジを融合させたもので、テスト熟練者の深い思考プロセスや検証の観点、粒度の細かさ、正確な記述方法などを体系化した、いわば「プロの暗黙知を言語化したナレッジ集」です。

これを実現できたポイントは、大きく2つ挙げられます。 

1つ目は、SQFに基づいてテスト設計のプロセスを徹底的に分解したこと。 

AIへインプットを丸投げしても、成果物は安定しにくくなります。そこで、「スコープ決定」「ケース生成」「自己レビュー」といったSQFに準拠した役割ごとに、専用のAIエージェントを直列に配置したのです。 

さらに、このサイクルを何度も回し、過去のサイクルの成果物をブラッシュアップできるような構造としました。 

2つ目のポイントは、AIの実行プロセスに「三段階の実行レベル」を組み込んだことです。 

実行レベルの一段階目では、最初のAIエージェントが、インプットとなる機能仕様書やテスト計画書の妥当性を入念にレビューする段階とします。

また、テスト設計に必要な情報が不足していると判断した場合は、弊社のエンジニアが仕様情報を整備、またはテスト計画書を修正します。 

二段階目では、AIエージェントがテストケースを一通り生成します。ここでは、全体の構成や網羅性に抜け漏れがないかを確認し、案件で求められる品質に到達する見込みが立っているかを全体像から評価します。 

三段階目では、そのテストケースに対して、SQFに基づく10個の観点に基づき、AI自身が成果物を「100点満点」で自己採点します。

もし点数が基準に満たなければ、過去のサイクルの成果物をベースに、AIが自律的に修正とブラッシュアップを実行します。 

この自己採点とブラッシュアップのループは、スコアの向上が見られなくなる（精度が頭打ちになる）まで、何度も何度も自動で繰り返されます。 

単一のプロンプトを用いたAIへの丸投げではなく、妥協を一切許さずにAIの限界まで品質を高めつづけるこの仕組みこそが、人間の熟練者に匹敵するテストケースを生み出す源泉なのです。

12,000ケースのテスト設計期間を半分以下に

この新たなテスト設計手法は、実際の開発現場ですでに高い成果を上げています。 

例えば、12,000ケースに及ぶ大規模なプロジェクトにおいて、このAI駆動のアプローチを適用した結果、人手がつくるのと遜色のないクオリティを維持したまま、通常であれば1ヶ月を要するテスト設計期間を、わずか0.4ヶ月へと削減することに成功しました。 

私たちは、この取り組みで得られた知見と技術をSHIFTのサービスに組み込み、お客様への価値提供につなげていこうと考えています。今後の発信にもぜひご注目ください。 

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

10年後の天井がみえて。盟友の誘いは、ノーリスクだと感じた

――大倉さんは前職の外資系コンサルティングファーム時代、非常に大きな実績を上げられていたと聞いています。順風満帆なキャリアのなかで、なぜ転職を検討されたのでしょうか。 

大倉：確かに客観的な評価や数字だけをみれば、何の不満もない環境でした。当時の私は、コンサルタントとして達成すべきKPIはスムーズにクリア、やり遂げたという満足感もありました。 

しかしだからこそ「10年後に自分がどんな仕事をして、どんなポジションにいるのか」が、読めてしまったんですよ。“コンサルしか知らない人間”になる前に外の世界をみるなら、30代半ばのいまだろうなと思ったんです。 

―――ファームを辞めるリスクは感じませんでしたか？ 

大倉：私の捉え方は真逆でした。賭けのようにみえるかもしれませんが、実際にはノーリスクだと確信していたんです。  

これまで培ってきた問題解決能力や事業構築の地力は、SHIFTへ移ったところで何一つ失われません。前職で実績をつくれていたからこそ、万が一のことがあってもコンサルタントとしてのキャリアにはいつでも戻れる、とも思っていました。 

失うものがないのであれば、成長企業に飛び込んで自分の可能性を試す方が、リターンははるかに大きい。そう考えると、ためらう理由がありませんでした。

丹下に感じた異次元さ。彼の元、事業を推進する“当事者”へ

――代表・丹下との出会いも、決断を後押ししたそうですね。 

大倉：はい。2017年頃から私をSHIFTへと誘いつづけてくれた佐藤さんに引き合わせてもらいました。丹下さんは、ある種、次元が違っていましたね。 

初対面の場で丹下さんが語り出したのは、売上1兆円企業へと至るまでのビジョンでした。私を驚かせたのは、その右脳的な巨大構想をぶつけてきた直後に、超左脳的な思考へとギアを切り替え、数値指標を精緻に詰めはじめたことです。 

私自身、コンサルタントとして右脳と左脳を行き来することは、徹底的に叩き込まれてきています。しかし、あそこまで極端に振り切って高速往復させる経営者を、私はみたことがありませんでした。 

「この人が描くのは夢物語ではない。信じるに足るトップだ」と直感しました。 

――コンサルタントという立場に、当時もどかしさを感じていた部分もあったのでしょうか？SHIFTなら解消できると思えた？ 

大倉：そこが最大のポイントでした。当時、私は大手クライアントの新規事業立ち上げ支援を統括していましたが、その企画が実際に世に出るまでには、数年もの歳月を要しました。 

自分の感覚からすれば半年でローンチできそうと思えた企画でも、大企業特有の社内調整や合意形成に1年半以上の時間が費やされる。そんな時間の使われ方に、自分の人生としてももったいなさを感じていました。 

「自分が当事者として動いたほうが、はるかにはやく事業がつくれるはず」－－自分の腕を試したいという気持ちが強くなっていました。 

そんな話をしたとき、丹下さんが「うちは大丈夫だよ。僕が全部その場で意思決定するから」 といい切ったんです。 

事業推進においてネックになりがちな意思決定を、トップ自らが引き受けるといっている。しかも彼とすぐそこの距離で仕事ができる。そのことが私の覚悟を固めてくれました。

報告も選択肢も不要。研ぎ澄ました企画で経営陣と対峙する

――実際に入社されてから、ファーム時代とのギャップはいかがでしたか？ 

大倉：待っていたのは、ファーム時代の作法が一切通用しない、丹下さんからの“とんち”のようなお題に、圧倒的なスピード感と実行力で応えていく日々でした。 

最初の試練は、入社直後の金曜日。当時進行していた急速な円安を受け、「この市場環境はSHIFTにとってどんなビジネスチャンスになるか」というお題が、突然丹下さんから降りてきたんです。 

「月曜日の朝に議論しよう」といわれてアイデアを練り上げ、プロトタイプを構築。そこから誕生したのが、現在も多くのお客様に提供されているSaaS・IT資産一元管理ツール「ワスレナイ」の原型でした。 

これを皮切りに、入社1年目はDAAEの新規事業立ち上げに奔走。その後も、全社的なAI戦略の主導や社内AIプロダクトの開発など、目まぐるしく押し寄せる経営直下のアジェンダに対応しつづけました。  

そして現在は、AIを活用してお客様の業務プロセス全体を請け負う次世代ビジネスアウトソーシング「AI BPaaS」の事業推進を責任者として担っています。 

――入社以来、まさにSHIFTの変革の渦中に身を置いてこられたわけですね。どのプロジェクトにおいても共通といえる、仕事の進め方の変化はありますか？ 

大倉：ファーム時代の仕事は、「クライアントの意思決定を支えるために、どれだけ緻密な分析を行い、完璧な説明資料をつくれるか」に頭と時間を費やしていました。 

しかし、SHIFTの経営陣に対してそのようなアプローチは1ミリも必要ありません。丹下さんからよくいわれるのは、「報告しに来るな、ディスカッションをしよう」ということ。

とはいえブレストベースの10個のアイデアや選択肢をもっていっても一蹴されてしまいます。 

求められるのは、最初から正解を当てにいくことではありません。いくつもの仮説を試し、現場でぶつけ、修正を重ねる。その試行錯誤のなかから、「これは効く」「ここに本質がある」という発見を一つでも多く掴んでいくことです。

――選択肢を絞り込む力以上に、試行錯誤を重ね、そのなかから本質的な発見を掴み取る力が求められている。 

大倉：経営者というよりは投資家に対して事業案を壁打ちしている感覚に近いですね。実際、丹下さんは投資家としての確かな視点をもっており、本質を突いたフィードバックをくれます。 

自分が提示したアイデアがその場で採択され、翌日には組織が動き、ダイレクトに企業の売上や株価へと反映されていく。「自分の手で企業価値をダイレクトに動かす手応え」をリアルに味わえます。

これこそが、SHIFTでしか得られない事業づくりの格別な醍醐味ですね。

企業価値と、自分の市場価値もひきあげる

――不確実なカオスのなかで、なぜそこまで自由に挑戦しつづけられるのでしょうか。 

大倉： SHIFTは「これをやったら怒られるかな」ではなくて、「やっていない方がだめ」な会社です。自分が正しいと信じた方向であれば、まずは走ってみる。間違えたら、方向転換してまた走ればいい。 

それにたとえ新規事業の立ち上げですぐには成果が出なくても、失敗を恐れず挑戦した“ナイストライ”を評価するカルチャーが根付いているんです。 

――一人で孤独に戦うのではなく、支えてくれる仲間もいるのですね。 

大倉：ええ。丹下さんからの難解な“とんち”をどう解くか、経営陣も各部署のキーマンも、垣根を越えていっしょに悩んでくれます。 

だからこそ不確実な環境であっても安心して脳を解放し、自分の意思と時間をつぎ込んだ勝負ができるんです。 

――大倉さんがSHIFTで挑戦をつづける原動力は何ですか？ 

大倉：やはり、本気で「売上1兆円」を目指しているという、その未来の可能性です。 

これは決して夢物語ではありません。私が入社してから今日に至るまで、会社の規模も景色も目まぐるしく変化しつづけています。  

組織の形ですら、状況に応じて頻繁にドラスティックに変化します。常識よりも本質的なことはなにかを重視しているんですよね。 

売上1兆円という目標に向かって疾走する企業に身を置き、当事者として企業価値を引き上げていくことこそが、結果として自分や仲間の市場価値をもっとも高める方法なんです。

この成長の真っ只中で立ち止まってしまうのは、積み上げたものを無駄にするようで本当にもったいない。だから1兆円を達成するまで走りつづけますよ。 

（※本記事の内容および取材対象者の所属は、取材当時のものです​）

全体工数の8割を占める欠陥分類。手作業と属人化の壁

石井：今回はAIを活用してソフトウェアテストの欠陥分析を劇的に効率化した取り組みについてお話しします。 

まずは、この話のベースとなっている「ODC分析」についてご紹介します。ODC分析とは、テストや本番運用で発生した欠陥（不具合）の情報を分類し、傾向の可視化と品質改善につなげる強力な分析手法です。 

従来、欠陥分析には、統計的分析（数の偏りを見る分析）と原因分析（なぜなぜ分析）の2つがありました。ODC分析はこの中間地点に位置しています。

約300件程度の不具合情報から全体の傾向を把握しつつ、一つひとつの欠陥の意味を捉えて改善アクションにつなげることができる、品質改善の切り札ともいえる手法です。

有用な手法であることは間違いありませんが、ネックになるのは、欠陥を分類しタグづけする作業が重労働であることです。お客様からいただくバグデータには、最初からきれいにタグがついているわけではありません。 

例えば300件のバグに対して、「修正対象は何か」「トリガーは何か」など、5〜10個のメトリクス（指標）を一つずつ人間の目で見て判断し、タグを付与していく必要があります。

実は、ODC分析の全工程において、この分類作業だけでも工数の約80％を占めており、期間にして約2週間もかかっていたんです。

山腰さん、現場ではこのあたりに課題があったようですね。 

山腰：そうなんです。ODC分析には大きく「分類」と「分析」の2つの工程があります。分類は膨大なバグデータにタグをつける作業です。

初心者にはむずかしく、現場では有識者への再鑑（ダブルチェック）依頼が飛び交うなど泥臭い苦労がありますし、教育コストもかかります。 

一方で、その分類後に「ここが怪しい」と深掘りしていく分析工程には、専門的な知識と経験が必要で、非常に属人的な作業になっています。 

しかもプロジェクトが終わればメンバーは分散してしまうため、2つの工程それぞれにおいて「プロジェクトごとに分類者の教育が必要」「分析できる有識者が限られる」という根深い属人化の課題を長年抱えていました。

石井：そこでAIが登場するわけですね。 

山腰：はい。分類にはコツがありますし、一方の分析にも実は有識者特有の“思考パターン”が存在することに気づいたんです。

どちらの工程もパターンがあるなら、AIの得意分野ではないか？と考えたのが今回の取り組みのきっかけでした。 

一番のボトルネックであり、全体の工数の8割を占めていた分類の壁。今日はそのなかでも特に、膨大な分類作業そのものをAIで自動化することについてどんな試行錯誤があったのか、詳細をお話しできればと思います。

自信満々に間違えるAI。分類自動化に立ちはだかった“5つの壁” 

石井：では実際にAI化を担当された吉澤さんに伺います。当初からスムーズに進んだのでしょうか？ 

吉澤：いえ、最初は全く上手くいきませんでした。まずAIに分類させる試みについて、直面した“5つの壁”をご紹介します。 

1つ目は、「入力の問題」です。障害票の書き方は、お客様やプロジェクトによって異なります。情報が揺らいだままAIに渡すと、前提情報がそろわず精度が落ちてしまうのです。 

山腰：現場のリアルな話をすると、綺麗に1件1枚のチケットになっているとは限りません。

なかには、Backlogで「こういうバグが出ました」「これってこういうことですか？」というチャットのやり取りが延々とつづいているものを読み解かなければならないこともありました。 

吉澤：2つ目は、「基準の問題（思考の壁）」です。人間が分類するときは、「要件定義書とプログラムの両方を直した場合は、根本原因である要件定義の方を重く見よう」といった暗黙の判断基準をもっています。

しかし、AIには「何を重く見るのか」という基準が共有されていないため、解釈がブレてしまうという課題がありました。 

そして3つ目が、「判断の問題」です。情報が足りない場合に、AIが勝手に決め打ちをしてしまうことがありました。 

山腰：ここが一番厄介でしたね。AIは、情報が足りなくて判断できない場合でも、「わかりません」とはいわないんですよ。 

複数の原因が絡みあっていて人間でも意見が割れるようなケースでも、AIは無理やりどれか一つを選び、自信満々に回答してくるんです。中身を見ると全然違うじゃないか、ということが多発しました。 

吉澤：さらに4つ目として、「結果の問題」がありました。AIの分類結果だけを出されてもその理由が見えないと、人間がレビューをする際に判断に困ってしまい、結果的に差し戻しが増えてしまうという課題です。 

最後の5つ目は、「応用の問題」です。AIは障害票に書かれている手順や内容を強く参照する傾向があるため、人間なら行間を読んで補完する“潜在的な検出パターン”を拾いにくいというケースがありました。

逃げ道を用意する？欠陥分類の精度を飛躍させる5つのプロンプト術

石井：そうした壁を、プロンプトの工夫でどう乗り越えたのでしょうか？ 

吉澤：前提として、ここで扱うプロンプトとは「AIに何を、どの形式で、どんな基準で出させるかという指示」のことです。 

1つの大きなプロンプトにすべての指示を詰め込むとAIの出力が不安定になるため、私たちは先ほどの壁に対応する「5つのプロンプト（整形から各分類までの5段階）」に分割して処理するアプローチをとりました。 

まず1つ目は、「入力品質の均一化」です。1つのプロンプトで処理するのをやめ、前処理として整形専用のプロンプトを挟みました。

どんな障害票が来ても、必ず「ID」「タイトル」「事象」「発生条件」「原因」「対処内容」という6項目の表形式に整理させます。 

ポイントは、「要約しすぎないこと」と「空欄を禁止すること」です。情報がない場合は「ない」と書かせることで、後続の分類プロセスへ渡すデータのばらつきを抑えました。

2つ目は、「判断基準のルール化」です。AIの解釈ブレを防ぐため、「要件定義 ＞ 設計書 ＞ プログラム」といったように、人間が暗黙で使っている優先順位をAIの仕様として明示しました。

もし複数の修正対象がある場合は、この優先順位に従って代表を一つ選び、選ばなかった他の要素は理由として保持しておくよう指示しています。 

石井：先ほど厄介だったといっていた、AIが自信満々に間違える問題はどう解決したんですか？ 

吉澤：3つ目の工夫「あいまいさの可視化」で解決しました。これが一番のポイントかもしれません。 

原因が複数絡みあっていたり、情報が不足していたりする場合に無理やりどれかを選ぶことを禁止しました。その代わり、「アルゴリズムかチェックか、どちらかあいまいである」というような救済カテゴリーを用意したんです。 

山腰：人間が分類していても、迷うものは必ず出てきます。その場合、有識者に再鑑を依頼していました。 

選択肢を増やしてあえて「あいまいです」と報告させることで、人間が後から再鑑する対象を全件ではなくグッと絞り込むことができたんです。 

吉澤：4つ目は、「結果と理由をセットで出力させること」です。分類結果だけを出力させると、なぜその結論に至ったのか人間にはわかりません。

そこで、分類した理由の出力を必須にし、さらにAI自身に「選んだ結果と理由に矛盾がないか」の整合チェックをさせました。 

山腰：これによって、「AIはどう考えて間違えたのか」が見えるようになりました。

間違えた理由がわかれば、「こういうときはこっちを選ぶんだよ」とプロンプトに具体例を追加してチューニングできます。間違いの傾向も見えて、精度向上のために非常に役立った工夫ですね。 

吉澤：最後の5つ目は、「AIに行間を読ませる」工夫です。

障害票に書かれた手順だけをなぞるのではなく、「実際（障害票通りのテストパターン）」と「潜在（そうテストすれば発見できたと判断されるパターン）」の2軸で分類させるようにしました。 

例えば「ログアウトして別ユーザーでログインしたら不具合が起きた」という事象から、「同一機能を別端末で同時操作しても起きたはずだ」といった潜在的な検出パターンをAIに推測させるんです。

これも理由を必須にすることで、より人間に近い深い分類ができるようになりました。

人間の思考を仕様化。わずか1時間で分類できるようになった

石井：結果として、どのくらいの成果が出たのでしょうか？ 

山腰：分類作業にかかっていた工数が、2週間からわずか1時間へと劇的に短縮されました。 

また、精度に関しても、人間2人が分類しても100%は一致せず、だいたい80％程度の一致率なんです。現在のAIの分類精度は、人間同士がやった時の精度とほぼ同等レベルにまで到達していると実感しています。

吉澤：今回学んだのは、AIに分類を丸投げするのではなく、「人間が普段行っている分類ルールや判断プロセスを整理し、仕様として言語化すること」が重要だということです。 

山腰：工数削減だけでなく、属人化の解消という当初の悩みにも光が見えました。 いまでは、ODC分析をこれからはじめる初心者に対して、AIが教育係として機能しています。

AIのおかげで分析のハードルが下がり、より多くの人が品質改善に関われるようになる。この裾野の広がりに、とてもワクワクしています。 

石井：最後に吉澤さん、今後のビジョンや取り組んでみたい野望はありますか？ 

吉澤：今後は分類だけでなく、その後の分析プロセスにもAIを適用していきたいです。 

分析にも、ある程度のパターンがあります。ベストプラクティスとの比較や異常値の発見、共通項を見つけ出すといった作業はAIの得意分野です。

AIと人間が互いの強みを活かすことで、より高度な品質保証の形を追求していきたいと考えています。 

石井：ありがとうございます。吉澤さんが執筆を担当したSHIFTの書籍『SHIFT流 AI時代のソフトウエアテスト』にも、これからの時代に品質保証の精度を高めるヒントが多数記載されています。 

同書に書ききれなかった“AI時代のエンジニアの生存戦略”や“エンジニアの真の価値”について言及した記事も、ぜひご一読ください。

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