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時代のエンジニアの生存戦略”や“エンジニアの真の価値”について言及した記事も、ぜひご一読ください。

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

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の活用を検討してみてはいかがでしょうか。 

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

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

営業改革が成果創出フェーズへ――大型案件とAI案件が拡大

SHIFTがこの1～2年にわたり取り組んできた営業改革が成果として表れはじめています。

引用：SHIFT_2026年8月期第3四半期決算説明資料 4p

今四半期は、AI関連事業の成長が顕著で、AI売上は第２四半期の約25.5億円から約79.2億円へと飛躍的に上昇し、前四半期比で3.1倍に伸長。

AI売上の総利益率も約43.0％と高い水準を維持し、SHIFTの成長を牽引する事業へと成長しています。

SHIFTでは月額プロジェクト単価とプロジェクト数を売上高を構成する重要なKPIとして開示していますが、いずれも継続的に成長しています。

特に注目すべき点は大型案件の増加です。SIerの枠にとどまらず、お客様の経営課題を解決し利益貢献まで支援するサービスインテグレーターを目指し、さまざまな施策を進めています。

その結果、月額3,000万円以上の大型案件が売上構成比の約20％を占めるまでに拡大。しっかりと大型案件が取れる体制、営業力、デリバリー力が備わってきました。

さらに、案件終了後も継続的に提案することで売上の減少を抑制し、リピート率も向上。新規案件の獲得だけでなく、既存のお客様との取引拡大により安定的な成長基盤を構築しています。

引用：SHIFT_2026年8月期第3四半期決算説明資料 17p

現状181名体制ながら、営業1人当たり年間5.6億円の売上を創出。生産性向上を重視し、人員を大幅に増やすのではなく営業力の強化に取り組んできました。一般的なSIerでは1人あたり平均約2億円程度ともいわれるなかで、約3倍の売上をつくることができる営業のケイパビリティを構築しました。

今後はトップアプローチ営業、アカウント営業、フォローアップ営業と3つの役割を明確化した体制へ変更。大型案件の獲得は引き続き強化しつつ、小型案件の獲得や既存案件の深耕を担うフォローアップ営業の強化にも注力していきます。

フォローアップ営業は、安定した売上基盤の構築に貢献しています。

現状は98名体制ですが、来期に向けて2倍程度に増員する計画です。

コンサルティング事業――上流支援の拡大で、顧客数・顧客単価が伸長

引用：SHIFT_2026年8月期第3四半期決算説明資料 19p

総合コンサルティングと業務・専門特化型コンサルティングを合わせた国内市場は約1.7兆円規模とされています。

SHIFTはこの市場において、ITコンサルティング（RFP作成・プロジェクト支援）およびPMO・推進支援領域でのシェア拡大を目指しています。 

今年に入り、コンサルティング領域の売上成長が加速。その背景として、特に3点が挙げられます。 

1.　現場経験を活かした上流支援

SHIFTはこれまでテストや開発の現場で培った豊富なノウハウを蓄積。

現在では、その知見をRFP（提案依頼書）の作成や業務改善などの上流工程にも活用できるようになり、コンサルティングサービスの競争力が高まっています。 

2.　中小企業向け需要の取り込み

中小企業が気軽に相談できるパートナーは不足しています。

SHIFTは企業規模を問わず幅広いサービスを提供するため、こうした需要を着実に取り込んでいます。 

3.　AI活用コンサルティングへの需要拡大 

AIソリューションを活用した業務変革・生産性向上への関心が高まるなか、「AIを活用したサービスを構築したい」といったお客様からの相談も増加中です。

SHIFTはこうしたニーズに対応し、AI活用を含むコンサルティングサービスを提供することで、新たな成長機会を創出しています。

引用：SHIFT_2026年8月期第3四半期決算説明資料 21p

これらの強みを背景に、SHIFTは上流戦略企画領域へのシフトによる単価向上と顧客基盤の拡大を両輪に、コンサルティング事業の成長を加速させていきます。

AIモダナイゼーション――レガシーシステム刷新市場で存在感を拡大

AIモダナイゼーションは、取り組み開始から約半年で受注残高28.3億円を積み上げるなど、順調に拡大しています。その背景には、主に以下の3つのポイントがあります。 

① 中堅企業向けの一気通貫支援が評価 

SHIFTはAIを活用したリバースエンジニアリングによって、既存システムの課題を可視化するサービスを提供。

システムの現状を迅速かつ正確に把握できることから、お客様から高い評価を得ています。

参考：SHIFT DQS for リバースエンジニアリング

② システム可視化から保守運用まで支援を拡大 

AIモダナイゼーションによるシステム可視化を起点に、保守運用まで支援できる点もSHIFTの強みです。

ブラックボックス化したシステムを可視化することで、明朗会計な見積りで保守コストの適正化を実現。その結果、本決算発表時点で10件の案件を獲得しています。 

③ 公共系を中心とした大型案件の獲得 

高い技術力とコスト競争力を強みに、公共分野を中心とした大型案件の入札でも成果を上げています。AIモダナイゼーション領域における実績と提案力が評価され、着実に案件獲得が進んでいます。

引用：SHIFT_2026年8月期第3四半期決算説明資料 25p

SHIFT DQS for リバースエンジニアリングの提供スキームが順調のため、解析済ソースコード量は1億STEPから3ヵ月で2億STEPへ倍増しました。 

オポチュニティを受注から実行に繋ぐ専属体制の構築を強化し、非常に高い技術力をもつストラテジックアーキテクト人材の採用を強化し、受注率の向上とさらなる売上成長を目指します。

テスト――AI時代でも高まる品質保証ニーズ

AIの普及によりソフトウェア開発の進め方は大きく変化していますが、品質保証・テストの重要性は変わらず高く、SHIFTのテスト事業も堅調に成長しています。 

1.　AI活用の拡大に伴い、テスト需要が増加

AIを活用した開発の普及に伴い、システム開発が内製化できている企業では開発量が増大し、品質保証・テストが追いつかないという事態が発生しています。

SHIFTは、AIを活用することによって、少人数体制であってもテストを効率よく回せる仕組みを提供しており、多くの引き合いをいただいている状況です。

2.　AIでは代替しにくいUAT領域を強化

システムの複雑化に伴い、ユーザーシナリオが増大。ユーザー検証のニーズが高まっています。

UATはAIで自動化することが難しい領域ですが、SHIFTはプロフェッショナル人材とAIが協働する仕組みを作り、網羅的な観点を備えた高付加価値で効率的なUATを提供できることが強みです。

3.　大規模システム開発における品質管理のAI実績を構築

SHIFTは先行して品質管理のAI化を推進した結果、AIによる精度やコスト効率化の可視化によってAI活用の価値を明確化。

大規模システム開発における品質保証ニーズの高まりを背景に、売上成長を後押ししています。

引用：SHIFT_2026年8月期第3四半期決算説明資 28p

SHIFTは、AIを活用したテスト実行自動化サービス「ネムラナイ」の提供を開始。特にWeb領域において高い効果が確認され、導入が着実に進んでいます。 

2026年6月からはテスト設計領域にも拡大しました。

テスト設計は「何を、どこまでテストするか」を定義する品質保証の中核工程であり、ハードウェア、モバイル、Webなど開発環境を問わず活用できる点が特徴です。

AI BPaaS――社内AI活用の成果を社外向けサービスへ展開

AI BPaaSでは、社内業務のAI化による生産性向上と、そのノウハウを活用したサービスの拡大を進めています。

引用：SHIFT_2026年8月期第3四半期決算説明資料 32p

SHIFTでは、バックオフィス業務へのAI活用を推進。業務を分解・可視化し、AI化を推進した結果、わずか半年で110人分に相当する工数の削減を実現しました。

今後もさらなるAI化を進めることで、生産性向上とリソースの最適配分を図っていきます。

引用：SHIFT_2026年8月期第3四半期決算説明資料 34p

AI BPaaSでは、情報システム領域を中心に事業を拡大。自社サービス「ワスレナイ」を起点として、PCのセットアップやセキュリティ設定、問い合わせ対応、監視業務などの運用支援を提供し、これまでに19.2億円の受注を獲得しています。

また、AI活用の知見をサービス化した、FDEによるAI定着化支援も開始。2026年1月の立ち上げ以降、導入企業は35社、売上は3.8億円に上っています。

社内で4,400体以上運用しているAIエージェント「天才くん」で培ったノウハウを活用し、AI特化コンサルタントとAI特化エンジニアがAI活用の定着支援から業務生産性向上、さらにはAI開発支援まで一貫して提供することで、お客様への提供価値を段階的に高めています。

参考：ワスレナイ

参考：天才くん

事業成長の中核を担う積極採用ポジション

今回の決算説明会では、SHIFTのさらなる成長を実現するうえで重要な役割を担うポジションとして、「営業職」と「AIモダナイゼーション領域のストラテジックアーキテクト」が紹介されました。 

 ■ 営業職  

お客様の経営課題を起点に、SHIFTグループの多様なアセットやソリューションを組み合わせながら、事業成長に直結する提案をリードします。 

10億円規模の大型案件に携わる機会や、大きな裁量のもとで経営者視点でビジネスを動かす提案を通じて、圧倒的な市場価値の向上を実現できます。 

営業系新設ポジション セールスエキスパート採用情報 

■ AIモダナイゼーション　ストラテジックアーキテクト

企業のDX・AI活用を構想段階からリードし、レガシーシステム刷新やAI活用戦略の実現を推進する、AIモダナイゼーション事業の中核ポジションです。 

高度な技術力とビジネス視点をあわせもち、お客様の経営課題に向き合いながら変革を実現する役割を担います。 

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

最後に：AI時代の成長をともにつくる仲間を募集

SHIFTは営業の仕組み化、AI企業への質的転換を着実に進めています。 

いま私たちが求めているのは、変化を恐れず新しい仕組みを構築できる人材です。 

次の時代の事業を構築したいと考える人にとって、SHIFTは最適な環境です。 

少しでも興味をおもちいただいた方は、ぜひ募集職種をご確認ください。 

募集職種一覧はこちら

能力はアップデートされているのに。60歳で新たな打席を求めた原点

――石井さんは長年、大手メーカーでIT系のコンサルティングに従事してこられました。そんな石井さんが、60歳という節目で転職を決意した原点はどこにあったのでしょうか。 

石井：役職定年がきっかけでした。60歳を迎えると役職が外れ、部下もいなくなります。しかしその一方で、会社から求められる売上ノルマは、現役時代と変わらない規模で課されつづけるのです。 

私自身の能力や気力が衰えた感覚はまったくなく、むしろこれまでの経験を統合して自身のケイパビリティは日々バージョンアップしているという自負すらありました。 

それなのに役職定年によって第一線から引きはがされる感覚に、違和感と悔しさを抱きました。さらに、年収がそれまでの半分以下にまで激減したことも拍車をかけました。 

――周囲からは、どんな声をかけられましたか？ 

石井：友人たちからは「これからはゆっくり過ごせばいいじゃないか」といわれました。 

しかし、私は第一線に立ちつづけたかったのです。同じ領域に固定化され、将来の成長曲線が平坦になっていくことへの恐怖もありました。

もう一度打席に立ち、自分の立ち位置を自らの手で確保したい。そう思い、転職活動を開始しました。

心を震わせた“コールオプション”の教えと、SHIFTにあったウェルカム感

――とはいえ、日本の転職市場における年齢の壁は厚かったかと思います。そんななかで、石井さんに未知の領域へ飛び込む覚悟を決めさせたものは何だったのですか？ 

石井：転職活動の前に通っていたビジネススクールで、ファイナンスの教授から贈られた一言です。 

「石井くん、人生はコールオプションだよ」。 

金融のコールオプションとは、「損失は限定的（支払ったオプション料まで）利益は大きく伸びる可能性がある」という特徴があり、これを人生に置き換えると「小さなコストやリスクで挑戦し、大きな可能性を取りにいく生き方」という意味になります。

教授は「リスクは限定的なのだから、どんどんチャレンジしなさい」とおっしゃいました。 

私の場合、子供たちは独立し、物理的なリスクは極めて限定的でした。一方で、新しい環境に飛び込んで得られるリターン（成長の可能性）は無限に広がっているはず。「失敗したって、なんとかなる」と思えたのです。

―― そこからSHIFTとの出会いに繋がっていくのですね。最終的にSHIFTへの入社を決めた最大の理由は何だったのでしょうか。 

石井：一言でいえば、圧倒的な“ウェルカム感”を感じたからです。他社は「来てもいいよ」といった雰囲気。 

一方、SHIFTの面接は全く温度感が違いました。

「ぜひ来てほしい」という温かさがあり、面接官の方からも「一緒に働けるのを楽しみにしているよ」といった雰囲気で声をかけていただくなど、歓迎されていることを強く感じました。 

また、思いがけずAI領域を打診され、「実務経験はないですよ」と正直に伝えたときも、背中を押してくれたのです。 

私をいっしょに働く仲間として迎え入れてくれる空気を感じたこと。そして、自分でも気づいていなかったポテンシャルを引き出そうとしてくれたこと。それが、SHIFTへの入社を決断した理由です。

3つのAI案件を同時牽引。自身の主戦場を再定義し、最前線で戦う

――先ほどお話に出ましたが、配属先はAIサービスグループ。配属に対して戸惑いはありませんでしたか？ 

石井：本当に想定外の打診でしたから、驚きましたよ。しかし入社から3ヶ月が経った現在、私はまったく性質の異なるプロジェクトを3つ同時に牽引しています。 

1つ目は、お客様社内のAI開発を統合・統括するCoE（Center of Excellence：目的や目標を達成するために、優れた人材、技術、ノウハウなどを集めた組織・グループ）のPMO支援。

２つ目は、金融機関における業務整理とAI導入に向けたコンサルティング。 

そして３つ目が、大手メーカーのシステム子会社における「SHIFT DQS for リバースエンジニアリング（ソースコードを基にシステムの内部仕様と外部仕様をAIで可視化し、ドキュメントを生成する）」のプロジェクトマネジメントです。 

―― AIの技術的なスペシャリストではないご自身が、この最前線のプロジェクトにおいて、どのような強み（ケイパビリティ）を期待されてアサインされたと認識していますか？  

石井：自分の主戦場である“上流工程の課題抽出”に対する期待だと思います。現在のAI市場は技術の基礎研究フェーズから、いかに企業の既存業務に組み込んで利益を創出するかという“実用化・成熟期”へシフトしています。 

つまり、お客様が直面している本質的な課題は、技術そのものではなく「自社のどの業務を、どう整理してAIに落とせば、期待する効果が得られるのかがわからない」という上流工程のプロセス不全。 

本当に必要なのは、お客様の業務を構造化し、課題を分析・分類して、プロジェクトのゴールを指し示してあげることです。このプロセスにおいて必要とされるのは、長年のキャリアで培ってきた傾聴力とPM力です。 

もちろん、技術的な知識も習得しますが、お客様の真意を言語化することに徹するようにしています。

ニーズよりペイン（お客様の困りごと）をいかに引き出すか、nice to haveではなくmust haveを見出していくことが重要だと思っています。

若手の技術力×シニアの大局観。互いをリスペクトしあって生まれる、最強のシナジー

――大企業からSHIFTへ移って、組織の推進力や文化の違いは感じますか？ 

石井：もっとも驚いたのは、スピーディーな意思決定でした。前職では、1つのAI案件を立ち上げようとしても、要件定義や稟議に時間がかかり、最終的にドライブがかからず実を結ばないケースもあって。 

さらに、小さな案件にリソースを割くことに慎重になることで、お客様が本当に困っている細かな課題をこぼし落としてしまいがちでした。 

――SHIFTのアプローチはそこが全く異なると。 

石井：はい。SHIFTは「まずは短期・少額でスモールスタートしてみる」という柔軟なアプローチをとっています。 

まずは1〜3ヶ月という短いスパンでお客様のオフィスで、文字通りお客様の隣に座って伴走するのです。これによりプロジェクトがスピーディーに立ち上がります。 

特に変化の激しいAI領域やアジャイル開発においては、この「まずは一緒にやってみる」というスタイルが有効に機能しています。営業・アサイン・デリバリーが役割分担されている仕組みも、大企業にはない強みですね。 

――AIサービス部は若いメンバーも多いですよね。どのように協働されているのでしょうか。 

石井：20代の若いエンジニアたちとの間に、補完関係を構築するように努めています。 

彼らの技術力には、目を見張るものがあります。お客様の要望に対してすぐに手を動かしてプログラムやプロンプトを組み、目に見える形でお客様にパッと提示してみせます。 

私の役割は、彼らがディテールに没頭しすぎたり迷い込んだりしたとき、「いまそのリスクは考えなくていいんじゃない？」とか、「今回のプロジェクトのゴールはここだから、このプロセスは大胆に端折ろう」と、大局的にプロジェクトをみながら推進のための勘所をおさえていくこと。 

技術の最前線で手を動かす役割は若手が担い、全体の視座を引き上げ、お客様と相対する際の傾聴力やPM力を私が担保する。この役割分担があるからこそ、SHIFTでお客様の課題を切り崩していけるのだと考えています。

眠っていた潜在能力が引き出される快感。キャリア後半戦に挑む同志へ贈りたい言葉

――石井さんがこれからSHIFTで実現したいことを教えてください。 

石井：短期的な目標としては、AIサービスグループのなかに業務改善とプロセス分析を軸としたコンサルティングチームを新しく立ち上げ、若手を育成していきたいと考えています。

AIを真にお客様の利益に変えるためには、上流の業務プロセスを整理できる人間が不可欠だからです。 

そして長期的な展望としては、お客様企業のCIOクラスの片腕となり、経営戦略とIT戦略をシームレスに結びつけるアドバイザーとしてのポジションを確立していきたいですね。

――かつての石井さんと同じように、定年前後でこれからのキャリアの身の振りに悩んでいるビジネスパーソンへ、メッセージをお願いします。 

石井：50代、60代まで企業で一線を張って生き抜いてきた方なら、本人が気づいているかどうかにかかわらず、どの会社に行っても活きる強みや人間力が必ず備わっていると思います。 

ただ、それが何なのか。自分のどんなスキルが他者から高く評価されるかは意外とわからないものです。私自身、AIソリューションの門を叩くことになるとは想像すらしていませんでした。 

しかし、一歩を踏み出してみたことで、自分の潜在能力が引き出される快感を味わえています。 

「人生はコールオプション」です。限定的なリスクを認め、未知の可能性へ向かって大胆にスイングしてみませんか。 

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

お客様が目の前で解約しているのに動けない――。提供価値と成長を止めないための決断

――田邉さんは前職にて、非常に大きな成果を上げられたと伺っています。具体的にどのような挑戦をされていたのですか？ 

田邉：当時はシステム開発を行うチームで、技術レベルに関わらず誰でも安全かつ素早くシステムへ変更を加えられる共通基盤をゼロから提案し、構築しました。 

それまでは、お客様から変更要望をいただいてから本番環境に反映するまでに1週間以上かかっていたのですが、簡単なものであれば即日・最短で1時間以内システムに反映できるようになりました。 

――1週間が1時間に……！お客様もすぐに対応してもらえるようになって喜ばれたでしょうね。 

田邉：ええ。はやさという観点以外にも、システムに対して変更を加える作業は、実務を担うメンバーにとっても非常に精神的な重圧がかかる仕事だったんです。

安全な仕組みを提供したことで、「非常に簡単にできるようになった」と大きなメリットがありました。自分でゼロから提案して会社に認められて進められたのはいい経験だったと、やりがいを感じましたね。

新しい挑戦を通じて、お客様への提供価値が高まり、会社の利益が拡大し、自分も成長する。この循環がエンジニアとしての私の原点でした。 

――そこから、なぜ転職を考えられるようになったのでしょうか？  

田邉：会社のグループ化を契機に、組織の巨大化に伴う“構造的な停滞”に直面したからです。意思決定のスピードが鈍化するとともに、先進的な機能へのリソース投資の蛇口が徐々に絞られていくのを感じていました。 

例えば、あるシステム刷新のプロジェクトでは、提案から実際に動き出すまでに1年近くの歳月を要してしまいました。このスピード感では競争力を維持できないと、強い危機感を覚えたのです。 

――1年近くも。それは、やきもきさせられそうですね。 

田邉：はい。意思決定の遅れは、すなわち「お客様に価値を提供できなくなる」期間が長くなることを意味します。そうなれば他社の方が有利になり、市場における相対的な競争力は低下してしまいます。

1年待っている間にも、古いバージョンを使いつづけているお客様がどんどんサービスを解約して離れていってしまっているという事実があったんです。

大企業のアセット×機動力。「なんでもやってやる」の熱意に惹かれて

――転職活動の折、SHIFTから連絡が届いたそうですね。SHIFTにはどんな印象をもたれましたか？ 

田邉：正直にいうと、数年前に取引があった当時の「ソフトウェアテストを非常に緻密かつ頑健にやり遂げてくれる会社」という印象で止まっていました。 

SHIFTを改めて調べ直したときには驚きましたね。IT業界のあらゆるバリューチェーンを網羅する総合DX企業へと変わっていたからです。 

―――大きな企業になっていて、意思決定のスピードが遅くなっているのではないか、とは思われませんでしたか？ 

田邉：面接や面談でお話するうちに、その懸念はなくなりました。

お会いした方々が、会社の掲げる野心的な目標や利益に対して強烈な当事者意識と、「自分がこの組織をさらに大きくしてやる」という熱量をもっていたからです。 

面接資料にも、成長のキーワードとして“スピード”が明記されていました。元々は、前職のような特徴ある自社サービスを持つ小規模な開発会社やベンチャー企業を候補に考えていました。

でもSHIFTは大企業としての圧倒的なアセットをもちながら、ベンチャー企業よりも遥かにベンチャーらしい機動力と貪欲さを失っていない。 

大きい企業なのに、誰もが会社のことを自分ごととして考えていて、「そのために必要なことは恐れないで、何でもやってやるぜ」という熱意。

それを感じたときに、こういう熱意ある仲間が集まっている会社であれば、「事業会社」にこだわる必要はないし、新しい挑戦もできそうだと感じました。 

会社の成長速度を自分のエンジンに変え、お客様の利益を最大化していく。私のキャリアの軸が、SHIFTなら叶えられるなと思い入社を決めました。 

――実際に入社してみてスピード感のギャップはありませんでしたか？ 

田邉：むしろ「やっぱり早いんだな」と確信に変わりましたね。プロジェクト全体の方向性はお客様とのすり合わせになるのでSHIFTだけで勝手に決められない部分もあります。

ただ、SHIFTとして「どういう体制やアプローチでお客様に挑むか」という、社内の意思決定がとにかく早いんです。

 社内での方針決定が迅速に行われるため、それをベースにしたお客様への新しい提案や、報告内容の決定もスピーディーに展開できます。

社内の根回しや何重もの稟議で待たされる時間が極めて少ないのは、PMとして本当に動きやすいですし、入社前に期待していた以上のスピード感ですね。

年齢や立場の壁はない。 CxO向けAIからRAG開発まで、フラットに「ベストな引き出し」を出しあう

――現在はAIサービスグループで、具体的にどのようなプロジェクトに関わっているのでしょうか。 

田邉：エネルギー業界のCxO向け業績分析AIシステムの構築から、自動車業界の「部品調達・在庫最適化のための製造業システム」のマニュアルを全学習させた高精度なRAG搭載AIアシスタントの開発まで、担当プロジェクトは多岐にわたります。 

お付きあいするお客様の多くは、企業内でAI活用を推進する専門部門の方々。お客様自身もAIの知識が非常に高く、技術的な知見が豊富な方ばかりです。

だからこそ、私たちは常にその一歩先を行く提案をしなければならず、知識のアップデートは欠かせません。 

――高いレベルの提案が求められる環境なのですね。チームの雰囲気はいかがですか？ 

田邉：上司や同僚、若手メンバーも含めて、非常に優秀な方が多いですね。常に高い視座で本質的な議論に集中できるため、 不毛な悩みなしに仕事を進められるやりやすさがありますね。 

特に、いまの若手メンバーは最初から「AIを使うのが当たり前」という環境で育った「AIネイティブ世代」です。 

あるプロジェクトで、AIに自律的にコーディングさせる開発環境を導入しました。

実務での本格的な運用は私自身はじめての経験でしたが、若手メンバーたちが、自発的に高度な開発環境を構築しスピーディに成果を出していきました。 

――そんな若手メンバーたちを前に、PMとしてどう振る舞ったのでしょうか。 

田邉：私たちは年齢は違っても、同じ目的のために集まっているフラットな関係です。 

だからこそ、私が疑問に思うことがあれば、先行して環境を構築してくれた若手メンバーに「これってどうやってクリアしたの？」と率直に教えてもらいました。 

それぞれがもっているベストな引き出しを出しあうのが一番合理的ですから。若手が最先端の技術で突き進むのであれば、私は「責任は僕が取るよ」というスタンスでプロジェクトを支えればいい。

そうやって互いをリスペクトしあえる関係が、一番いいチームの形だと思っています。

時代は“利益を出すAI”へ。自身の引き出しを増やし、お客様への価値を最大化する

――田邉さんはITの新しい技術だけでなく、マネジメント手法のアップデートも日々意欲的に行われているそうですね。自身の成長も、あくまでお客様への最適な提案のためなのですね。 

田邉：はい。もし私自身の引き出しが少なければ、お客様の課題に対して「自分が知っている狭い解決策」しか提案できず、ベストではない方法を押し付けることになってしまいます。

それは結果として、お客様の利益を減らすことにつながるのです。 

いま、AI市場は劇的な成熟期を迎えており、実証実験（PoC）のフェーズは終わりました。現在の経営者が求めているのは、既存業務への正確な影響度と、導入に伴う投資対効果（ROI）です。 

だからこそ、私たちの存在価値が高まっています。事業成長に直結する果実をお客様に届けるために、私自身が「技術」「プロジェクト管理」「コミュニケーション」のすべての引き出しを増やしつづける。

それがプロとしての誠実さだと考えています。

――お客様に対し、どこまでも誠実なのですね。最後に、大企業や事業会社でPMを務め、SHIFTへの転職を考えている方々に向けて、メッセージをお願いします。  

田邉：SHIFTは規模の大きな会社でありながら、大企業にありがちなスピードの鈍化とは無縁の組織です。 

また、周りのメンバーが非常に優秀で協力的なため、 私たちが本来集中すべき「お客様への価値提供」に真っ直ぐに向きあえる体制が整っています。 

AIという変化の激しい分野で、自分が成長することで、お客様の利益、会社の利益に貢献する。この「Win-Win-Win」を追求したいという方と、ぜひいっしょに働きたいですね。

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

孤独とキャリアの壁。PMを追い詰める「つらさ」の正体

司会：本日のトークテーマでもある「なぜPMはつらいのか」。お二人はこの「PMのつらさ」の正体は何だと思われますか。

白木：今回の登壇に先立って複数のPMのかたにヒアリングをしたのですが、「不確実なプロジェクトに一人で向き合う孤立感」が際立っているように感じました。

でも深掘りしてみると、本当の理由は「システムの構造」にたどり着くのかなと。 

長年運用されているシステムでは、ドキュメントが整備されていない、または仕様を把握している人がいないことが多い。

ブラックボックス化した状況に一人で向き合わなければならず、孤立感や人間関係の悪循環にもつながっていると感じました。 

司会：構造の不明瞭さが、現場をギスギスさせてしまうのですね。竹村さんはいかがですか。

竹村：日本のベンダー業界では「プログラマーからSEになり、経験を積んでPMになる」というキャリアパスが一般的です。 

私自身もそうだったのですが、「技術的な分野でスキルを伸ばしていきたい」という方にとって、PM以外の選択肢がない一本道のキャリアは、非常につらいものなんです。 

司会：「自分の志向性をキャリアに反映しづらい」。共感してくださるPMの方は多いのではないでしょうか。

ブラックボックスを可視化する。DQSでPMの“構造的な悩み”が解消する理由

司会：そうした「PMのつらさ」を、まずはシステムの構造的課題という観点から打破するために、SHIFTが採っているアプローチを教えてください。 

白木：「AIモダナイゼーション」というサービスを提供しています。 

全体像としては、レガシーシステムの仕様を解析するリバースエンジニアリング（以下、DQS for RE）と、そこからモダンなシステムへ再構築するフォワードエンジニアリングの2つのパートにわかれています。 

サービス名にもあるDQSとは「Development Quality Standard」の略で、高品質なシステム開発を実現するための標準化されたSHIFT独自の開発フレームワークおよびプロセス群を指しています。

参考：「SHIFT DQS for リバースエンジニアリング」プレスリリース 

司会：DQSはどんな課題を解決するために生まれたのでしょうか？ 

白木：最大の目的は、システムのブラックボックス化からの脱却です。DQS for REでは、外部仕様と内部仕様をともに解析してドキュメントを生成し、システム全体を可視化することで現状を把握しやすくします。 

またもう一つの重要なメリットに、ベンダーロックインの解消があります。

フォワードエンジニアリングではオープンソースや標準的な技術を採用したボイラープレートを用いるため、特定ベンダーへの依存を防ぐことができます。 

竹村：ここに対して私たちは、AIによる現状の可視化を先行し圧倒的な短納期と低コストを実現することで、ベンダーロックインの牙城にも切り込んでいくことができると考えています。 

司会：システム構造がスムーズに可視化できることで、PMもつらい思いをせずにすみますね。 

白木：ええ。可視化の最大のメリットは、認識合わせの土台ができることです。 例えば「200画面だと思っていたら実は1,000画面あった」という事実が最初に可視化されます。

もちろん実際は年1回しか使わない画面などの濃淡があるとにせよ、まず1,000画面あるという客観的な事実が土台としてそろいます。

それをもとにお客様と認識合わせができるためPMも安心でき、後々のトラブルや認識の相違を減らせるのが非常にいいポイントです。 

また途中からプロジェクトに参画するPMやチームの負荷も激減されます。

私はエンジニアとして途中参加することもありますが、全体像を俯瞰しつつ、具体的に踏み込んだ「内部仕様（ソースコードの中身）」までツールで見られるため非常にありがたいものだと感じています。 

司会：視聴者の方からも「動いているソースコードしか信頼できない場合が多い」とコメントをいただきました。 

竹村：最近はアジャイル開発を採用するケースも増え、それに伴いドキュメントをつくらないことも多いです。

しかし、発注側である事業会社のお客様はベンダーに任せる以上、ドキュメントがないと困るため「アジャイルを進めながらドキュメントもつくりたい」というジレンマを抱えています。  

また保守運用のなかでソースコードだけが修正され、ドキュメントの更新が止まって乖離していくケースも非常に多いです。

こうした課題に対しても、ソースコードからリバースエンジニアリングで正確なドキュメントを生成する仕組みは有効で、ソースコードと合致した信頼できる状態をつくりだせます。 

ストラテジックアーキテクトという次世代キャリア、AI時代のPMが選べる未来

司会：AIモダナイゼーションが進むと、PMのつらさが解消されるだけでなく、仕事自体も変わってきそうですね。 

白木：はい。これまではエンジニアに依頼しないとできなかったシステムの課題特定やデータ抽出などを、AIを使うことでPM自身ができるようになってきています。

AIのサポートによって、エンジニアとPMの垣根がどんどん少なくなっていくと思います。 

竹村：そうですね。例えばPM業務の大きな比重を占めている、各エンジニアへの進捗確認や、それをもとにした報告書の作成などの管理業務は、今後AIが代替していくかもしれません。 

白木：すでにSHIFTのPMのなかにも、タスク管理ツールとAIを連携させ、遅延タスクや会議のネクストアクションが一目でわかるダッシュボードを自作して進捗管理をしている方がいます。  

竹村：AIを使うことで業務負荷が軽減され、より本質的な人間による判断や、お客様とのコミュニケーションに集中できるようになると思います。 

司会：PM本来の業務に集中できるようになるのですね。一方で、これまで「技術を極めたいのにPMになるしかない」というキャリアの壁もPMを苦しめてきました。AI時代において、この一本道のキャリアはどう変わるのでしょうか。 

 竹村： 技術を追求したい方向けに、新しいキャリアパスとしてSHIFTの「ストラテジックアーキテクト」というポジションにぜひ挑戦してみてほしいです。 

司会：ストラテジックアーキテクトはどんな役割を担っているのですか？ 

竹村：「この課題を解決するためには、システムをこう変えていきましょう」というTo-Be（理想の姿）の設計と、そこに至るまでのロードマップを策定するのが主な役割です。 

 SHIFTのストラテジックアーキテクトの特長は、「AIを多用する」点です。AIを使って現行システムのソースコードを高速かつ横断的に分析し、セキュリティの脆弱性やコードの複雑化といった課題を抽出します。 

レガシーとモダン両方のアーキテクチャを理解していないと具体的な改善策は提案できません。

常に最新技術をキャッチアップする必要があるため、技術志向の方には非常に面白い仕事だと思います。 

司会：お客様は具体的にどんな課題を抱えているのでしょうか。 

竹村：65社以上のソースコードを分析した結果分かったのですが、96％ものお客様は「テスト基盤の欠如」と「コードの複雑化によるメンテナンスの煩雑化」に苦しんでいます。 

さらにセキュリティ課題も多く、脆弱なフレームワークやライブラリを使いつづけたり、パスワードが平文になっていたりするケースが、74％のお客様で発生しています。 

司会：そのようなお客様に対して、どのように提案をするのでしょうか？ 

竹村：AIが抽出した客観的なデータで現状を可視化し、To-Be（理想の姿）を描きますが、究極の理想像を一足飛びに実現できるわけではありません。実際にはお客様の予算に収まるかという問題があります。 

脆弱性対応など緊急性の高いものから優先し、お客様と相談しながら「まずは中間地点まで行きましょう」と現実的な落とし所を探っていく泥臭さも、ストラテジックアーキテクトの重要な役割です。 

PM業務で培ってきた「お客様との調整力」や「プロジェクト推進」の経験に、最新の技術知見を掛けあわせるからこそ、ストラテジックアーキテクトとして大きな価値を発揮できるのです。

現状を説明すると「大事に育ててきた子どもをけなされたようだ」と感じるお客様もいらっしゃいます。

でも私は、「大事な子どもだからこそ、つぎはぎだらけの服ではなく、新しい服を着せてあげましょう」と内心にそんな思いを抱えながら、客観的なデータをもとに真摯に向き合っています。  

AIとともに新しい道を。技術者本来のやりがいを取り戻す

司会：AI時代に新しいキャリアを描く場として、SHIFTという環境にはどんな面白さがありますか？ 

竹村：AIを活用して新しいことに挑戦できる面白さではないでしょうか。SHIFTには、やると決めたらすぐに実行に移す文化があります。  

白木：竹村さんがおっしゃった文化ですが、創業者である丹下がいまもトップでクイックに意思決定をしているのがいいポイントですね。

AIを全力で推進するという経営方針のもと、最新のAI技術を使いながらお客様の課題解決に取り組むことができます。 

新しいことに挑戦したいエンジニアやアーキテクトにとって、非常に面白くやりがいのある環境ではないかと思います。 

司会：では最後に、かつての竹村さんのように「本当は技術を極めたいけれど、一本道のキャリアの中でPMをやっている」、そんな悩みを抱えている方々へメッセージをお願いします。 

竹村：AIの登場で、キャリアは一本道ではなくなりました。

マネジメントを極める道もあれば、AIの知見を深めてとことん業務を効率化する道、技術志向の方はプログラマーのまま、もしくは私たちのようなアーキテクトやストラテジックアーキテクトになる道もあります。 

白木：加えていえば、「もう一度、エンジニアリングの世界に戻る」という選択肢もいまの時代なら大いにあり得ると思っています。

PMを務めている方の多くは、かつてコーディングや設計をとことん経験されてきたバックグラウンドをおもちのはずです。 

いまはAIがコーディングを強力にサポートしてくれる時代だからこそ、PMで培ったプロジェクト推進や全体把握の経験を武器に、再び技術の最前線に立つことも十分に現実的です。

実際に、スタートアップでCTOを務めた方がエンジニアに戻るのを拝見したことがあります。 

竹村：SHIFTには、そうした構造的なしがらみを壊し、自身の志向にあったキャリアパスを歩める環境があると考えています。 

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

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活用とアジャイルな意思決定を実践し、周囲に「自分たちもあんな風にやりたい」と思わせるカルチャーバブルをボトムアップで生み出すのです。 

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

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

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