開発エンジニア – RECRUITMENT|株式会社SHIFT https://recruit-wp-prod.shiftinc.biz Fri, 21 Aug 2026 07:18:25 +0000 ja hourly 1 https://wordpress.org/?v=6.2.8 12,000ケースのテスト設計を0.4ヶ月で。プロに比肩するテスト設計ができるAIエージェント構築の要点  https://recruit-wp-prod.shiftinc.biz/career/library/id1565/ Mon, 24 Aug 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=58515 JaSST’26 Tohoku 登壇レポート 

生成AIの活用により高速化するシステム開発。それに伴い、増大するテストの負担。

「高速なリリースを維持しつつ、品質をどう担保すべきかわからない」と悩む品質管理や開発現場の方は多いのではないでしょうか。

今日、QA(品質保証)業務では、 AI活用による変革が求められています。 

2026年5月29日、「生成AIと歩むテスト設計 〜AIはもう1人の仲間〜」をテーマとするソフトウェアテストシンポジウム「JaSST’26 Tohoku」が開催されました。 

本イベントのプレミアムスポンサーを務めたSHIFTからは、CATエヴァンジェリスト 石井が「高速な品質フィードバックを実現するAIテスト設計エージェント構築の要点」というタイトルで登壇しました。 

テスト熟練者の知見を体系化したSHIFT独自の品質保証基準「SQFSHIFT Quality Framework)」とAIを融合させ、テスト設計のプロセスそのものを抜本的に変革したアプローチとは? 

  • CATエヴァンジェリスト 石井

    倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入および大規模基幹システム移行への参画を経験し、2015年にSHIFT入社。CAT開発チーム内でユーザーサポートとして、ユーザーと開発メンバーのブリッジを行い、ユーザーの課題分析や新機能提案などを日々実施している。 

目次

開発スピードの加速が招く “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のサービスに組み込み、お客様への価値提供につなげていこうと考えています。今後の発信にもぜひご注目ください。 

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

]]>
限定公開:AIがコードを書く、エンジニアは理想を描く。SHIFTが示す「ストラテジックアーキテクト」としてのキャリア https://recruit-wp-prod.shiftinc.biz/career/library/id1596/ Sun, 23 Aug 2026 23:30:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=59357

このページはパスワードで保護されています。閲覧するにはパスワードを入力してください。

このページの閲覧には JavaScript を有効にする必要があります。

]]> 欠陥分類を2週間から1時間へ。AIを人間による分類精度にまで到達させた「5つのプロンプト術」 https://recruit-wp-prod.shiftinc.biz/career/library/id1552/ Wed, 19 Aug 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57295 JaSST’26 Tokyo 登壇レポート

ソフトウェアの品質を可視化し改善につなげる、ODC分析

この手法は「分類」と「分析」の2つの工程からなりますが、特に前段階の分類は膨大な手作業により全体の8割もの工数を占めるほどの重労働で、現場の大きな負担となっていました。 

2026年3月20日に開催され、SHIFTがプレミアムスポンサーを務めたJaSST’26 Tokyo」。

本イベントに登壇したCATエヴァンジェリスト 石井 優、エグゼクティブ・テストスペシャリスト 山腰 直樹、テストエンジニア 吉澤 麻由の3名は、この欠陥分類にAIを適用し、作業にかかる工数を約2週間からわずか1時間へと劇的に短縮を実現した取り組みを紹介。 

AIは自信満々に間違える――。取り組みのなかで直面したこの厄介な壁を突破する鍵となったのは、「あいまいさを可視化する」「逃げ道を用意する」という発想でした。

本記事では、現場の最前線で立ちはだかった「5つのつまずき」と、それらを解消しただけではなく、人間による分類精度にまで到達させた「5つのプロンプト術」を紐解きます。 

  • CATエヴァンジェリスト 石井 優

    倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入および大規模基幹システム移行への参画を経験し、2015年にSHIFT入社。CAT開発チーム内でユーザーサポートとして、ユーザーと開発メンバーのブリッジを行いユーザーの課題分析や新機能提案などを日々実施している。 

  • エグゼクティブ・テストスペシャリスト 山腰 直樹

    大手ITベンダーにて、約38年にわたりソフトウェアエンジニアとして製品開発に従事。その後、ITシステム開発におけるソフトウェアテスト事業の経験を経て、2022年2月にSHIFTへ参画。現在は海外事業推進部にて顧客支援を行う傍ら、ソフトウェアテスト事業拡大の一環である「欠陥分析サービス」を立ち上げる。SHIFTのテストオファリングを組織全体に浸透させ、顧客ニーズに最適化した支援を提供できるよう精力的に活動中。

  • テストエンジニア 吉澤 麻由

    国際的な標準規格(IEEE 29119)などをベースに、自社のナレッジを融合して体系化したSHIFT独自の品質保証標準「SQF(SHIFT Quality Framework)」を構築し、現場への適用を推進。書籍『駄目パターンに学ぶ 失敗しないソフトウエアテスト実践ノウハウ』で全体監修を、その改訂版であるSHIFT流 AI時代のソフトウエアテスト』においても執筆の中心的役割を担った

目次

全体工数の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メンテナンスから解放!6つの実務シナリオで検証する、AWS DevOps Agentの現在地 https://recruit-wp-prod.shiftinc.biz/career/library/id1597/ Thu, 06 Aug 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=58566 AWS CDK Conference Japan 2026 登壇レポート

2026年7月18日、JAWS-UG CDK支部が主催するAWS CDK(Cloud Development Kit)やCDKTF(CDK for Terraform) / cdk8s(+) の最新動向やベストプラクティスを共有する年次カンファレンス「AWS CDK Conference Japan 2026」が開催されました。 

SHIFTからは、AIアジャイル開発部 DevOpsエンジニアの奥田が「AWS DevOps AgentでCDKメンテナンスは楽になるのか?〜検証から見えた最適解〜」というタイトルで登壇しました。 

インフラストラクチャをコードとして管理するIaC(Infrastructure as Code)の分野において、AWS CDKは非常に強力なツールです。

再利用性や抽象化の高さから多くの開発現場で重宝されている反面、導入時の学習コストや日々の保守工数が大きな課題となっています。 

「この便利で強力なツールを、もっと誰もが簡単に使いこなせるようにならないものか」 

そんな開発現場の悩みを解決する有望な選択肢として期待されているのが「AWS DevOps Agent」です。

本記事では、奥田が、実務への適用を想定して行った徹底検証のストーリーを通じて、AWS DevOps Agentの活用術とその検証結果をご紹介します。 

  • AIアジャイル開発部 DevOpsエンジニア 奥田 雅基

    2016年、システム運用保守としてIT業界でキャリアをスタート。通信会社の新規ネットワークサービス立ち上げPJのPMO・ネットワークエンジニア、人事(社員教育担当)、社内プロダクト開発PJのシステムエンジニアを経て、2025年8月、株式会社SHIFTに入社。DevOpsエンジニアとして案件に取り組みつつ、社内外への技術発信活動にも挑戦している。 

目次

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と連携させたシナリオ(パターン1・2)では今回設定した検証項目をすべて検知しました。 

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

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

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

]]>
技術を極めたかったのに、PMになった人へ。SHIFTで拓くストラテジックアーキテクトとしての新境地 https://recruit-wp-prod.shiftinc.biz/career/library/id1567/ Thu, 16 Jul 2026 23:50:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57195

PMとして一度は感じるであろう、孤独感。 

そのつらさの正体は、ブラックボックス化したシステムの構造と、「技術を極めたくても、出世魚のように勝手にPMになっていく」一本道しか用意されていないキャリアパスにあるのではないか。  

そんな問いに対するSHIFTなりの解決方法を、2026年5月14日に開催されたイベント「PMはなぜつらいのか?AIとともにブラックボックスに挑むSHIFTのリアーキテクチャ」の内容からレポート。 

AIモダナイゼーションの力で、しがらみや限界を根本から壊しにいこうとするSHIFTのいまをお届けします。AI時代にPMがえらべる未来とは――。 

  • AIモダナイゼーション技術開発グループ テックリード 白木 翔也

    ソフトウェアエンジニアとしてソーシャルゲーム開発からキャリアをスタート。スタートアップ企業でCTO経験を経てSHIFTへジョイン。SHIFTでは「売れるサービスづくり」を実現するためテックリードとしてDX推進支援や開発標準の策定を行う。現在はAIモダナイゼーション技術開発グループにてSHIFT DQS for リバースエンジニアリングを開発。 

  • AIストラテジーグループ アーキテクト 竹村

    外資系IT企業、大手消費財メーカーを経て、2026年SHIFTへジョイン。30年以上にわたり大規模システム統合やクラウド基盤構築を主導。クラウドネイティブやAPI設計に加えAI活用も見据えたアーキテクチャ設計に強みをもつ。現在はAIモダナイゼーションサービス部のAI駆動開発アーキテクトとして、事業の技術戦略の高度化を牽引。 

孤独とキャリアの壁。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には、そうした構造的なしがらみを壊し、自身の志向にあったキャリアパスを歩める環境があると考えています。 

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

]]>
なぜ改善活動は自然消滅するのか?事例からみる、組織に定着させる3つの打ち手 https://recruit-wp-prod.shiftinc.biz/career/library/id1559/ Thu, 16 Jul 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57046 Scrum Fest Niigata 2026 登壇レポート

「いい取り組みだったはずなのに、なぜか活動がつづいていない……」 

勉強会やアジャイル導入、1on1など、現場発の改善活動がいつの間にかなくなってしまったという経験はないでしょうか。 

熱意をもってはじめたにもかかわらず、周囲は動いてくれず、推進者だけが疲弊していく。実は、そこには個人の熱量や努力では解決できない構造的な問題が潜んでいます。 

本記事では、ふりかえり&アジャイルエバンジェリストの森 一樹(びば)が2026年5月9日に登壇した「Scrum Fest Niigata 2026」の講演内容をもとに、改善活動が消滅してしまう5つのパターンを紐解きます。 

そのうえで、個人の熱量に頼らず、改善を組織に定着させるための3つの打ち手と5つのステップを事例とともにお届けします。

  • ふりかえり&アジャイルエバンジェリスト 森 一樹(びば) 

    黄色いふりかえりの人。みんなに強化魔法をかける人。野村総合研究所にてプロジェクトマネジメントや組織変革を推進し、プロダクトマネージャとしての経験を経て、2025年にSHIFTに入社。社内外へのアジャイル教育や、ふりかえりの啓蒙から、社内各部署や他社との連動など、支援の幅を広げ活動中。著書に「アジャイルなチームをつくるふりかえりガイドブック」など。   

目次

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

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

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

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

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

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

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

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

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

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

あるスクラムマスターがマネージャーにこう問題提起をしました。 

「チームの心理的安全性が低く、属人化が進んでいる。プロセスにも改善の余地があり、複数のチームでワークショップをやらせてほしい」。 

しかし、マネージャーからは「いろんなプロジェクトが佳境なのに、追加で1人月以上の工数を割く判断はできない」と却下されてしまいました。

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

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

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

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

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

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

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

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

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

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

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

ある若手のスクラムマスター自チーム成果のでた「ふりかえり」をほかのチームへ横展開したいと考えていました。

そこで、タスクやステップを体系的に整理したアクションリスト部長にほかのチームへの声掛けを依頼。

部長はよさそうな活動だ」と理解を示し掛けてくれましたが後日声がけしたチームからいい反応が得られなかったの一言で終わってしまいました。 

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

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

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

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

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

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

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

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

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

CoEメンバーが、組織横断の勉強会を立ち上げました。最初はCoEメンバーが毎回テーマを決め、丁寧に資料を準備し、進行まで担当。参加者の満足度が高い状態がつづいていました。 

5回ほど開催したところで、「チームだけでも自走できそうだ」と判断し、運営を別の人に引き継ぎました。しかし数ヶ月後、勉強会は自然消滅してしまいました。 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

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

]]>
「自分が何者かわからなかった」 40代エンジニアが挑んだアウトプットの軌跡。 https://recruit-wp-prod.shiftinc.biz/career/library/id1558/ Tue, 14 Jul 2026 23:50:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57133 ワンストップ アウトプット!アウトプットの背中を押すカンファレンス 登壇レポート

「エンジニアとして長く経験を積んできたのに、自分が何者かわからない」—— 

そんな悩みを抱える方もいらっしゃるのではないでしょうか。 

今回の記事の主人公、髙橋 直規。彼もまた自信をもてずにいました。20代はSESでさまざまな案件に参画し、30代で一次請け企業へ転職して、長く深い案件を担うも終わるごとにリセットされるような感覚… 

しかし、彼はあるプロジェクトで自分の限界を知ったことをきっかけに、“外の世界”へと飛び出します。そこからアウトプットをはじめたことで、彼はエンジニアとしてのオーナーシップを取り戻した、と語ります。 

本記事では、2026年4月4日に開催され、SHIFTが会場スポンサーを務めた「ワンストップ アウトプット!アウトプットの背中を押すカンファレンス」より、髙橋の講演をレポート。 

髙橋がブログ、技術同人誌、登壇、コミュニティ立ち上げといったアウトプットを通じて自身の経験に価値を見出すまでの等身大の軌跡を追います。 

  • 製造ソリューションサービス部 髙橋 直規

    エンジニアやPM、サービスマネージャー※として、さまざまなシステム開発案件などに携わった後、アジャイルを専門的に扱うために、3社目として2023年3月SHIFTに入社。現在は、SHIFTの「アジャイル」にまつわるさまざまな案件に入り、プロジェクトマネジメントから実務となるエンジニアリングまで、幅広い領域でアジャイルサービスの浸透/普及に従事している。 

    ※複数案件を管理し、滞りなくサービス提供ができるよう責任を担う立場。

目次

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

]]>
「AI疲れ」に効く。判断を最速化し、組織の学習率を最大化する、4つの柱×技術基盤の仕組み https://recruit-wp-prod.shiftinc.biz/career/library/id1554/ Tue, 14 Jul 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57100 SHIFT×CNIA×DASA Japan 共催イベント 登壇レポート

AIによって実装やテストの負荷が大幅に削減され、開発生産性が飛躍的に高まる一方で、次なる課題が浮上しています。 

それは、AIの圧倒的な生成スピードに対して、「本当に価値あるものは何か」「このアウトプットはビジネスとして正しいのか」を人間が判断するスピードが追いつかないという現象です。 

絶え間なく提示される選択肢に人間が追われる「AI疲れ」を感じる声が増え、開発プロセスにおける最大のボトルネックは、実装よりも意思決定に移りつつあります。 

本記事では、2026年4月24日にSHIFT、一般社団法人クラウドネイティブイノベーターズ協会(CNIA)DASA Japanの三社が共催したイベント「Agentic AI × Platform Engineering で変わる開発現場」に登壇したSHIFTのAIアジャイル開発部 アジャイルコーチ 船橋 篤史の発表内容をレポート。 

人が正しい価値判断に集中するための4つの柱と、個人の限界を超えて組織全体の意思決定をデータと技術で強力に支えるエンジニアリング基盤について解説します。

その先に目指すべきは、組織における学習率の最大化と語る点にもご注目ください。

  • AIアジャイル開発部 アジャイルコーチ 船橋 篤史

    SES企業やソフトウェアベンダーでの保守開発や自社サービスの開発、スクラムマスター、SREなどの経験を経て、2020年8月にSHIFT入社。入社直後からアジャイルコーチやQAリードエンジニアなどのロールで各種プロジェクトに参画。2021年9月からはグループ長としてグループ管理を担いつつ、お客様のアジャイルチーム化を総合的に支援・マネジメントしている。 

目次

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

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

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

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

]]>
AIモダナイゼーション事業 採用情報 https://recruit-wp-prod.shiftinc.biz/lp/career/ai-modernization Tue, 07 Jul 2026 06:41:49 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=lp&p=57102

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

AI MODERNIZATION

設計書がない。誰も全容を把握できない。 そんなシステムが、日本中にある。

改修しようにも、手をつけた途端に別の何かが壊れてしまう。
そんな悩みをかかえる企業が、業界を問わず、後を絶ちません。

AIを使い倒しながら、
専門チームが現行システムの可視化・分析から実装までを推進する。
SHIFTはこの仕組みで、日本企業のシステムの問題を根本から解決します。

AIモダナイゼーション事業のイメージ

AIモダナイゼーションとは

AIを使って、複雑化した基幹システムを
根本から解きなおす。

日本企業の多くが抱える「設計書のない・誰も全容を把握できないシステム」。SHIFTはAIでソースコードを解析し、設計情報を再構築。その結果をもとに、何を残し・捨て・つくらないかを人が判断し、AIと協業で実装まで担います。構想から品質保証まで、ひとつのチームで完結させる体制が私たちの強みです。

基本戦略

SHIFT独自のフレームワークAIによって、
足踏み状態だった仕様可視化・システムリビルドを現実に。

SHIFT独自のフレームワークとAIによって、足踏み状態だった仕様可視化・システムリビルドを現実に。

この事業に興味をおもちいただいた方へまずはカジュアルにお話ししませんか?

事業の面白さ

いまSHIFTが強化しているのは、「AIを使う人」ではなく「AI時代の仕組みをつくる人」

「AIを使う側」ではなく、
「AI時代の仕組みをつくる側」にいる。

システムそのものを再設計し、これまでの延長線上にはない価値をつくる。「AIを使いました」で終わらない仕事がここにあります。

構想から実装・運用まで、
一気通貫で責任を持てる。

構想を描いて終わり、PoCをやって終わり——ではありません。自分がかかわったプロジェクトの結果に、最後まで責任を持ちつづけられる環境です。

単発の導入ではなく、
システムそのものを再設計する仕事。

既存の仕組みの一部を置き換えるのではなく、システム全体をどう再構築するかがテーマ。本丸に上流から入り、本質的な変革を前に進められます。

誰も答えを持っていない問いに、
最前線で向き合える

AIに何をやらせ、人間が何を判断するか。その問いに、市場のほぼ最初の段階から関われるタイミングにいます。

この事業に興味をおもちいただいた方へまずはカジュアルにお話ししませんか?

技術環境

その時々のベストを選ぶ。
AIツールを自由に使い倒せる環境

AIツールは日々進化し、半年前の常識がすぐに変わります。SHIFTのAIモダナイゼーション統括部では、特定のツールに縛られることなく、案件・目的・フェーズに応じて使うAIを選ぶことができます。「このツールしか使えない」ではなく、「どのツールがいまの仕事に合うか」を自分たちで判断できる環境です。

Devin

実装・テストを任せ、人は設計と判断に集中する

Cursor

コードベースを理解した上での実装支援・リファクタリング

Claude Code

要件整理・ドキュメント生成・コードレビューに活用

Cline

ターミナル操作を含むエージェント的な作業を自動化

Codex

コード生成・変換・レガシーコードの読み解きに対応

掲載しているツールは一例です。技術の進化に合わせて、SHIFTが使うAIも変わりつづけます。

研究機関との連携

株式会社松尾研究所との共同開発

ソースコードをAIで解析しシステムの仕様を可視化する「SHIFT DQS for リバースエンジニアリング」のコア技術について、株式会社松尾研究所と共同開発を進めています。COBOL・Java・PHP・C#など多言語に対応。学術知見とSHIFTの現場経験を掛け合わせた、精度の高いシステム可視化を実現しています。

メンバーの声

SHIFTで働いてよかったと思ったこと。

カードをクリックすると詳細をみることができます

正解のない領域を自分たちで切りひらいていける。固定概念にとらわれず、アイデアをどんどん形にできる環境がここにはあります。

テックリード

T.R.

独自基盤と各領域のエキスパートが掛け合わさった点。インフラからアプリまで対応できる他社にない体制で日々多くを教わっています。

AI駆動開発PM

前川

社長自らAI活用を推進しているため、全社的に安心して挑戦できます。現場が自ら考えて動き、価値を生み出せる点が魅力です。

ストラテジックアーキテクト

加治

会社としてAI活用を全力で推進している点です。ソースコードからのドキュメント自動生成など、自社サービスを進化させています。

ストラテジックアーキテクト

江口

新しい可能性が見えたらまず試す、SHIFTらしいスピード感が体現されています。うまくいけば即取り込み、組織全体で次につなげます。

サービス部副部長

S.H.

この事業に興味をおもちいただいた方へまずはカジュアルにお話ししませんか?

募集ポジション

AIモダナイゼーション事業 募集職種一覧

可視化・分析
ストラテジー策定
AI駆動開発(要件定義〜設計〜開発)
可視化・分析
全量可視化お客様ヒアリングシステム化計画
プロジェクト計画各種設計AI駆動開発
①ストラテジックアーキテクト
②ソリューションアーキテクト
③AI駆動開発PM
④テックリード
AI駆動開発エンジニア

この事業に興味をおもちいただいた方へまずはカジュアルにお話ししませんか?

メッセージ

この事業に、本気で取り組んでいる理由。

代表取締役社長 丹下 大

代表取締役社長 丹下 大

理想の開発を、現実にする

これまでのシステム開発は、人のスキルや経験に依存し、品質・コスト・スピードのトレードオフから逃れられない構造にありました。優秀な個に成果が左右され、再現性や持続性に課題を抱えてきたのが実態です。
私たちはAIを、単なるツールではなく「圧倒的な処理能力をもつパートナー」と捉えています。正しい設計の考え方とガイドラインを与えることで、その力は発揮され、誰もが迷わず高品質な開発を進められるプロセスが生まれます。
AIを活用したシステムの刷新は、この構造そのものを変革し、品質・コスト・スピードのトレードオフを過去のものにします。そして、手を動かし価値を生み出す「つくる人」が正当に評価される世界へ。私たちは、その新しい開発の当たり前をつくりつづけます。

AIモダナイゼーション統括部 事業部長 佐藤 章太朗

AIモダナイゼーション統括部 事業部長 佐藤 章太朗

前提から問い直す、AI時代の開発へ

これまでの開発は、RFPを起点に進めることが当たり前でした。しかし、その前提が不完全なままプロジェクトが進み、本質的な課題にたどりつけないケースも少なくありません。
私たちは、提案ではなくソースコードという“事実”からすべてを読み解きます。システムの構造・業務・ロジックを可視化することで、見えていなかった課題やズレを明らかにし、真に意味のあるモダナイゼーションを実現します。
AIの活用により、その可視化と開発は圧倒的なスピードと精度で進化しました。構想から開発・テストまで、一気通貫でやり切ることが可能になっています。
これから求められるのは、役割にとらわれず価値創出に向き合い、AIを使いこなしながらプロジェクトを前に進める力です。私たちは、「つくる人」が正当に評価される新しい開発のあり方を、ともに実現する仲間を求めています。

AIモダナイゼーション統括部 開発責任者 加藤 勝也

AIモダナイゼーション統括部 開発責任者 加藤 勝也

品質から再定義する、開発の未来へ

日本にはいまだ多くのレガシーシステムが残り、ブラックボックス化によって誰も全体を把握できない状況がつづいています。私たちは、この構造そのものを変えるためにこの取り組みをはじめました。
これまで数多くのプロジェクトに向きあう中で、開発の成否をわける本質は「品質」にあると考えています。だからこそ私たちは、AIを単に活用するのではなく、「品質を担保したうえで使いこなす」ことに徹底的に向きあってきました。
ソースコードを起点に設計情報を再構築し、AIと独自技術を組み合わせて可視化する。さらに、開発標準やガイドラインによってAIの出力を制御し、再現性のある開発プロセスを実現しています。
AIが実装を担い、人は設計と判断に集中する。その結果、少数でも高品質な開発をやり切れる世界が現実になりつつあります。私たちは、技術で価値を生み出す人がより輝く開発の未来を、ともにつくる仲間を求めています。

カジュアルにお話しませんか。

具体的な仕事内容から、いまのフェーズだからこその面白さまで、お気軽にご質問ください。

ご希望のポジションのメンバーとの面談をお約束するものではありません。状況によってはご期待に沿えない場合がございますことをあらかじめご了承ください。
第1希望
第2希望
第3希望
]]>
プロセス信奉ではなく、価値を生む「テーラリング」を。PMBOKの変遷から読み解く今後のプロジェクトマネジメント https://recruit-wp-prod.shiftinc.biz/career/library/id1547/ Tue, 16 Jun 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=56171

2026年3月4日、SHIFTが手がける技術イベント「SHIFT EVOLVE」において「チームプロジェクトマネジメントとPMBOK第8版(Agile in Motion vol.6)」と題したセッションを開催しました。  

品質にこだわってきたSHIFTならではの目線で、アジャイルに長年携わってきたゲストを招き、アジャイルの神髄に迫るという本シリーズ。 

今回は、株式会社レッドジャーニー システムリデザイナー 森實 繁樹(samuraiRed) 氏とAIアジャイル開発部 アジャイルエバンジェリスト 渡会 健による対談です。 

AIなどの技術進化が加速する一方、日本のITマネジメントはオールドスタイルのままであると警鐘を鳴らす二人が語る、PMBOKの変遷(第6〜8版)と今後のプロジェクトマネジメントとは? 

本記事では当日の内容のうち印象的な部分をピックアップし、一部再構成してお届けします。 

同日に行われた森實氏単独のセッション、渡会単独セッションのイベントレポートも、ぜひご一読ください。  

関連コンテンツ

  • 株式会社レッドジャーニー システムリデザイナー 森實 繁樹 (samuraiRed) 氏

    大手SIerでの開発運用、大規模プロジェクトマネジメントを経験した後、ミドルベンチャーでCTO、通信系事業会社でエンジニアリングマネージャー、国立大学で非常勤講師などを歴任。プロダクト開発や組織づくりに造詣が深い。2003年からアジャイルを実践しており、社内外問わずいくつものチーム、組織の支援を行ってきた。現在は、認定スクラムプロフェッショナルとして組織変革支援に邁進している。

  • AIアジャイル開発部 アジャイルエバンジェリスト 渡会 健

    2025年、株式会社SHIFTに入社し、Customer Quality Agileを掲げて日々活動中。キャリア前半をPM畑で過ごした後、2008年に40代でアジャイルに出会ってからは、10年程受託開発で20件近くの実践を積み、その後コーチやコンサルとして50件以上の支援を行うなど、17年で70案件以上の多種多様な実践経験をもつ。マネジメント(≠PM)の力を信じ、その経験を活かしながら、一般社団法人PMI日本支部アジャイル研究会代表、独立行政法人情報処理推進機構(IPA)アジャイルWG構成員等を歴任し、マネジメント視点と現場視点の両軸からアジャイル領域に貢献。 PMI日本フォーラム2025 優秀講演第6位(52講演中)。  

目次

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

]]>