SHIFTが予見する、テスト業務がなくなる未来

岩瀬氏：本日はよろしくお願いします。今日のテーマは、「AI駆動開発（AIDD）の時代、テストエンジニアは不要になるのか？」。

気になるこのテーマについて、SHIFTさんだからこそわかるリアルなお話をお聞きしたいと思います。 

SHIFTさんは、先の決算発表で「人手中心のテスト業務は、将来なくなる可能性がある」といい切りましたよね。現場としては、どう思われましたか？ 

森川：経営陣としては、AIの進化を見据えれば、いずれそうなるという見立てがあったんだと思います。 

岩瀬氏：SHIFTさんといえば、独自のスクリーニング検定で未経験者を大量に採用・育成し、圧倒的な人の数と体制でテスト事業を拡大されてきた背景がありますよね。

まさに人手で成長を牽引してきたSHIFTさんが「なくなる」といい切ったのは、業界的にも非常に大きなインパクトがあります。 

森川：おっしゃる通りです。実際、いまやSHIFT単体でも数千人がテスト業務に携わっています。 

もはや、人手だけに頼るビジネスモデルのままではいられない。IRで宣言しただけではなく、内部構造も変えようとしています。

現在、AI活用を軸にした大規模なリスキリングがはじまっています。また、新規採用もAIに特化した人材へとシフトしています。 

岩瀬氏：育成に携わる方も今日は会場にたくさんおられるようですが、リスキリングって超難題ですよね。具体的にどう進めているんですか？

森川：まずは、生成AIへの適性を見極めています。要するに、プロンプトを上手く扱えるか、生成AIを制御できるかという点ですね。そのうえで適切な配置や、成長を促すわけですが、正直まだ模索中ですね。

岩瀬氏：適性がある人とない人では、何が違うのでしょう？

森川：「人に指示を出すのが上手いかどうか」というマネージャー適性と非常に似ています。自分の業務の目的や背景をきちんと言語化して説明できない人や「背中を見て学んで」というタイプは、生成AIを使いこなせない傾向にありますね。

LLMと画像解析技術がもたらす、“AI打鍵”の圧倒的ポテンシャル

岩瀬氏：では、具体的にテストエンジニアの役割はどう変わっていくのでしょうか。「なくなる」といっても、業務は多岐にわたりますよね。

森川：そのとおりです。私たちはテストエンジニアをざっくり３つのレイヤーに分けて考えています。

結論からいうと、ドメインエキスパートの重要性は引き続き高いと考えています。真ん中のテスト設計者は、必要ですが役割が大きく変わります。そして一番下の打鍵者は……AIへの置き換えがもっとも進む領域だと考えています。 

岩瀬氏：私は自動化オタクなので、「E2Eテストを組んで自動化すればいいのに」とつねづね思っていました。なぜこれまで、手動の打鍵テストがなくならなかったのでしょうか？ 

森川：コストと予算の壁があるからです。E2Eテストを組んで自動化するには、それなりの投資や運用コストがかかります。一方で、手動で打鍵してもらう方が、投じられるコストとしては安く済むケースが多かったんです。 

岩瀬氏：それが、いよいよAIに置き換わるんですね。具体的にAIはどうやって打鍵するんですか？

森川：私たちは“AI打鍵”と呼んでいるのですが、単にコードを生成するだけではありません。

従来の自動テストはDOMに依存するため、例えばCSSが崩れてボタンが画面上から見えなくなっていても、DOMが存在していればテスト成功と誤認してしまいます。

しかし、AI打鍵は実際のスクリーンショットを高度な「コンピュータビジョン（画像解析）」で検証し、ユーザーが実際に見る画面状態そのものを合否判定することもできます。

特にエンタープライズ領域では、事故発生時の監査対応やクライアントへの証明材料として、実際に画面を触って確認した証跡が強く求められます。

AI打鍵は、そうしたニーズに応えつつ、従来の自動テストがむずかしかった画面崩れの検知などを実現できる可能性があります。

岩瀬氏：しかし、画像解析はトークン消費量が爆発的でコストが厳しくありませんか？

森川：おっしゃるとおり、現在はトークン費用などのランニングコストが最大の課題です。

また、SHIFTでは累計1.4億ケース以上にのぼる膨大なテストケースを効率よく、かつ安全にまわすため、将来的には自社GPUサーバーの導入も視野に入れ、検討を進めている段階です。

もちろん、エンタープライズ企業が求める監査や信頼性の証明をどう担保するかといった課題もあるため、多角的に模索をつづけています。

これからのテスト設計者は、“トリアージャー”に

岩瀬氏：打鍵者がAIに置き換わる一方で、テスト設計者の仕事はどう変化するのでしょうか？

森川：トリアージャーという新たな職種に変化すると考えています。AI駆動開発が進むと、仕様通りのテストはAIエージェントが自動でつくってくれます。

しかしAIは、あらゆる可能性を考慮するあまりエッジケース（極端な条件のテスト）を激増させてしまいます。 

岩瀬氏：AIは放っておくと無限にテストコードを書きますからね（笑）。 

森川：そこで必要になるのが、リリースされる新機能の性質やビジネスリスクを考慮して、「このケースは今回必須」「これはやらなくていい」と優先順位を決める（トリアージする）役割です。

開発現場の“痛み”を記憶する人間。AIにはないメタ認知能力

岩瀬氏：AIがテストの大半をこなすようになっても、「どうしても人間にしかできないこと」って残るのでしょうか？ 

森川：それは、“ビジネスリスク”への気づきです。例えば、プロダクトに変更が加わって重要な購入ボタンが画面の端に見切れてしまったとします。

人間なら、画面を見た瞬間に「これはダメだ」と気づきますよね。これは過去の失敗事例を覚えていたり、お客様目線を理解したりしているからです。 

しかし、AIにまったく同じ判断をさせようとすると、コンテキスト全体を読み込みにいってしまい、かなりの時間がかかってしまいます。 

もしルールベースで無理やり検知させようとすれば、今度はあらゆる小さなズレに対して「これもユーザーが減ります！」とアラートを上げつづけるでしょう。ここには、人間の圧倒的な優位性があります。

岩瀬氏：人間が1秒で気づける直感的な判断力や、いわゆるドメイン知識って、どうやって身につくものなんでしょうか？ 

森川：私の経験則ですが、結局のところチームで経験した過去の痛みに由来するのだと思います。

「あの時、このバグを見逃してビジネスに影響が波及した」「このボタンの配置を変えたら売上がガタ落ちした」という経験があるからこそ、人間は「これはやってはいけない」と判断できるんです。

AIを導入する前にやるべきこと。仕様が属人化している組織では、AIの効果を十分に発揮しづらい

岩瀬氏：SHIFTさんには、AI駆動開発を導入した企業からの相談も増えているとお聞きしました。 

森川：「AI開発を導入したものの本番で障害が発生した。リカバリーをどうすればいいか」というご相談が急増しています。

しかし現場で、日々テストの相談を受けているマネージャーたちに聞くと、「外部ベンダーへの丸投げで炎上したプロジェクトと、まったく同じ匂いがする」と。相手が人間からAIに変わっただけで、起きている炎上の構造は同じなんです。

岩瀬氏：なぜオーナーシップの喪失が起きるのでしょう？

森川：開発のスピード感がはやすぎるというのもありますが、背景には、経営層やビジネスサイドからの「とにかくAIを使え！」という強いプレッシャーがあります。

特に、AI特有の障害として、次の3つのパターンが目立っています。

岩瀬氏：これらを防ぐためには、どうすればいいのでしょうか？私が経営層なら「ドメインエキスパートのもつ暗黙知を言語化して、AIに食わせろ」というと思うんですが。 

森川：よくそういわれるのですが、実は少し違います。 

そもそも、ドメインエキスパートは非常に少ないですよね。そこで私たちがいま構想しているのは、設計情報・ビジネス要件・CI/CD・オブザーバビリティ（o11y）といった情報をAIエージェントが束ねてコンテキスト化し、テスト設計者やトリアージャーが1日でも早くドメインエキスパートに成長できるよう「判断・通知でヒトを支援する仕組み」をつくることです。 

しかし、いざ情報を集約しようとしても、重要な仕様が誰かの頭のなかにしかなかったり、仕様書が単なる「スクリーンショットの貼り付け」でAIがテキストとして読み込めなかったり、過去の障害対応の経緯がチャットツールの海のなかに沈んでしまっていたりするのです。 

岩瀬氏：そもそも情報管理がずさんな状態では、いくら優秀なAIを導入しても、AIはどうしようもないと。 

森川：まさにその通りです。「ネクストアクションが決まらず終わっている会議」はもってのほかで、まず自分たちの日々の業務や決定プロセスを、情報資産として整理して残すといった「AI Readyな状態」ができていないと、AI駆動開発を成功させることはできません。 

岩瀬氏：組織習慣や言語化能力そのものが問われているわけですね。本日はありがとうございました！ 

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

【前回のおさらい】職人技を再現し、人間同等の精度を叩き出した「5つのプロンプト術」

開発工程にて発見されたバグ／不具合を収集・分類し、その原因やパターンを突き止める“ODC分析”。

そのボトルネックとなっていたのは、欠陥情報に種別やトリガーといった複数の属性を一つずつ付与していく分類作業でした。

分析の前処理であるこの作業だけで、全体の工数の約8割を奪われていたのです。 

SHIFTはこの課題に対し、複数の生成AIプロンプトを組み合わせて適用することで、分類作業工数を劇的に短縮。

「AIは自信満々に間違える（情報が足りなくても無理やり決め打ちして回答する）」という壁を突破し、人間同等の精度（一致率約80％）を再現した、独自の“5つのプロンプト術”の流れと要諦は以下の通りです。

＜欠陥分類のAI化プロセス＞

＜プロンプト術の要諦＞ 

対象となる欠陥情報を分類する際、SQFに基づいた分類プロセス（上の01～05）を適用し、それぞれに応じたプロンプトで処理することで分類を実現しています。

各プロンプトのポイントを以下に記載します。

・整形プロンプトによる入力品質の均一化：
書き方がバラバラな障害票を、前処理として6項目の表形式に強制整形。
情報がない場合は勝手な想像を防ぐために「ない」と書かせることが重要で、かつ“空欄禁止”を徹底することで抜け漏れを防止します。 

・判断基準（優先順位）の仕様化：
AIによる解釈のブレを防ぐため、「要件定義 ＞ 設計書 ＞ プログラム」といった重み付けを明示。複数候補がある場合はこの優先順に従って1つを選択させます。

・「救済カテゴリ（あいまいさ）」の許容：
原因が複合している場合、無理な決め打ちによる誤分類を防ぐため、「アルゴリズムorチェック（あいまい）」といったあいまいなまま出力できる逃げ道を用意。人間が再鑑すべき対象をあぶり出す仕組みを構築しました。

・結果＋理由の必須化と自己整合チェック：
結果と同時に分類した理由を必ずセットで出力させ、矛盾がないかAI自身に自己チェックさせることで決め打ちの抑止とレビューの効率化につながります。 

・実際と潜在の2軸による行間読みの再現：
文面の手順だけに依存せず、「実際（事象通りのパターン）」と「潜在（どうテストすれば発見できたか）」の2つの軸でトリガーを分析させることで、人間に近い分類を再現しました。

このアプローチの本質は、AIに分類を丸投げするのではなく、人間が普段行っている暗黙の判断ルールを徹底的に言語化し、仕様としてAIに渡したことにあります。 

【Q&A】単発プロジェクトでも、ODC分析は役立つ？

今回JaSST’26 Kansaiでの登壇では、前回登壇したJaSST’26 Tokyoでいただいたご質問も紹介しました。 

JaSST’26 Tokyoの聴講者から「ODC分析は本来、中長期のデータを大量に蓄積してはじめて活きるものでは？単発のプロジェクトでも価値はあるのか？」という疑問が寄せられました。 

これに対するSHIFTの回答は、「AIによる高速化が、単発プロジェクトにおけるODC分析の活用可能性を大きく広げた」というパラダイムシフトの提示です。 

これまで欠陥の分類作業はあまりに重すぎたため、プロジェクトの進行中に都度分析を行うことは現実的ではなく、必然的に「中長期のデータをまとめて事後分析し、組織的なプロセス改善に活かす」というアプローチになりがちでした。 

しかし、AIによって分類コストが軽量化された現在、単一のプロジェクト進行中であっても、分類・分析作業を都度行うことで「いま、どこに品質リスクが偏っているか」「次に強化すべき観点は何か」を、迅速に把握し、翌日のテスト活動に活かせるようになっています。 

中長期で組織プロセスを改善するという本来の価値も発揮しつつ、目の前のプロジェクトを安全にゴールへ導くためのリアルタイムな武器としても使えるようになったこと。

これこそが、AI×ODC分析がもたらした大きな効果の一つといえます。

【現在の取り組み】ODC分析レポート作成までワンストップ化

今回、最新の取り組みとしてODC分析レポートまでのワンストップ化について紹介しました。 

前回のJaSST’26 Tokyo時点では欠陥分類のプロセスは「分類ステップを実施し、各ステップでユーザーがチェックを行う」という分業制でした。

現在では欠陥情報からの分類、分析、報告までワンストップで進める仕組みを整備しています。 

ワンストップ化をするにあたり、単に分類した結果をAIに渡し「これを分析して」と指示するだけでは、再現性が担保できず、毎回異なる分析結果が出力される可能性があります。

また、欠陥情報単体だけではプロジェクト特有のコンテキスト（文脈）が考慮されず、分析の精度が上がらないという課題もありました。  

そこでSHIFTは、対象プロジェクトの「背景情報」をAIにインプットしたうえで、 長年培ってきた 独自の品質保証標準である「SQF（SHIFT Quality Framework）」の分析観点をAIに組み込もうとしています。 

例えば、「画面系や帳票系の障害が多い」というファクトに対し、「単体テスト（UT）工程での画面系・帳票出力系の網羅テストが未実施、もしくは確認不足」という仮説をAIに立てさせ、具体的な改善提案までをワンセットで出力させます。 

SQFをAIにインプットすることで、AIは一定の観点に基づいて、安定して質の高い一貫した分析報告書を作成できるようになると考えています。

【新しい提案①】欠陥の起票時に自動で属性を付与する

ここからは、AI化した仕組みとその応用によって既存のプロセス改善などにつながる仕組みの示唆ということで2つの提案をしました。 

テスト活動のなかで報告された不具合情報を分析する場合、不具合を起票したメンバーが分類用の属性を判断、設定する運用フローを行うことは一般的です。 

品質の可視化や分析を精緻に行うためには、不具合ごとにできるだけ多くの属性を付与したいのが本音です。

しかし、入力項目を増やせば増やすほど現場の負担は増します。

属性を考えて設定する時間は数分でも、起票するメンバーの本質的ではない属性の判断作業が重なった場合、結果として適当な分類が付けられるなどして、継続的な分析運用は頓挫しがちになります。 

また、大規模なプロジェクトなどではすべてのメンバーが同じ分類基準を共有するということは難しいものです。 

この課題を解決するため、SHIFTはプロジェクト管理ツール「Jira」とODC分析APIをシームレスに自動連携させ、通常の手動テストプロセスの中にAIのタグ付けを組み込む仕組みを提案しています。 

Atlassian Forgeが自動でそれを検知してバックグラウンドでODC分析APIに問い合わせを行い、チケット上に分類タグを自動で反映するイメージです。 

この仕組みの最大のポイントは、完全にAI任せにするのではなく、「AIによる自動タグ付け ＋ 人間による簡単な再鑑」という形で持続的な分析運用のプロセスを構築している点にあります。 

これにより、現場の工数を増やすことなく、すべての欠陥データに品質分析用の属性が即時付与される理想的な環境の実現が期待されます。 

【新しい提案②】24時間稼働するAI×テストの自律サイクル

現在、SHIFTではAIが自律的にテストを設計し、実行するAIテストソリューション「ネムラナイ」を提供しています。

これにAI×ODC分析を組み込むことで、これまでにないスピードでテストの精度を自己向上させていく「24時間稼働する品質改善の自律ループ」の実現を目指しています。 

具体的なサイクルは以下の通りです。

1.夜間のAIテスト自動実行：夜間に、AIが自動でシステムテストを実行する。

2.AIによるODC分析：検出された不具合を、AIが即座にODC分析にかける。 

3.自律的な改善提案：分析結果から「仕様書のここが足りない」「このテスト観点が不足している」といった改善ポイントを自動で導き出す。 

4.翌朝のフィードバック：朝、AIテストを監視するオペレーター（人間）がその提案を確認し、テストの設計モデルやプロンプトを調整・アップデートする。

昨晩発生した不具合の分析結果が、翌朝には“次のAIテスト設計”へとダイレクトにフィードバックされ、日に日にテストの質が向上していく自律的なサイクルです。

【まとめ】職人の暗黙知を仕様化し、AIと共創する未来へ

AIに分類を丸投げするのではなく、人間が普段行っている暗黙の判断ルールを徹底的に言語化し、「仕様」としてAIに渡す。

これが、SHIFTの進めるAI活用の真髄です。 

SHIFTはこれからも、AIと人間の新しい共創のカタチを提示し、ソフトウェアテストの可能性を広げつづけていきます。 

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

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

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という環境で自分の裾野の広さを武器に、この最前線の面白さに挑んでほしいですね。 

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