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

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

「CAT」「TD」と開発体制の基本構造

従来、QAチームの役割は開発された機能が仕様通りに動くかを確認し、不具合を報告することだとイメージされることもあると思います。

しかしSHIFTの自社プロダクト「CAT」「TD」のQAチームは、その枠にとらわれず、さまざまな役割をもって活動しています。

「CAT」「TD」のサポートを担当する立場の私から見ても、このQAチームの業務範囲はとても広いと考えています。

通常のテスト設計や実行はもちろんのこと、不具合修正の仕様策定、本番環境へのデプロイ作業まで手掛けています。

このQAチームがどのような成果を出しているのか、リーダーの田山に聞きました。

ご紹介する内容をより深く理解いただくために、「CAT」と「TD」、およびプロジェクト体制について簡単に説明します。

まず「TD」とはTest Designerの略称で、テスト設計を支援するツールです。SHIFTのもつ豊富なナレッジを基に、効率的かつ網羅性の高いテストケース作成を可能にします。

次に、テスト管理ツール「CAT」は、テスト実行フェーズを支援するツールです。テストの進捗状況をリアルタイムで可視化し、品質とプロジェクト管理の効率を飛躍的に向上させます。 

開発は4つのチーム体制で進められています。日本側の開発チームが主に要件定義や設計を担当し、詳細な実装はベトナムに拠点をおくグループ会社「SHIFT ASIA」が担っています。

そして、今回フォーカスする田山のQAチームは日本にいて、オフショアを含む開発チーム全体と密に連携しながら品質保証活動を進めています。

スプリント全体を使い切る高密度タスク管理

「TD」と「CAT」は、6週間（1スプリント2週間×3スプリント）を1つのリリースサイクルとしています。

一般的な開発プロセスでは、サイクルの序盤（設計フェーズ）でQAチームの手が空いてしまうことが少なくありません。しかし、彼らはその「空き時間」を価値に変える仕組みを構築しています。 

新しい機能のテストにすぐ着手できないスプリント1（設計フェーズ）では、チームは前のスプリントの残作業を片付けます。

具体的には、例えばCATのオンプレミス体系であるダウンロード版リリースや不具合の分析報告などがあります。

それらが終了したら、当スプリントで改修した機能のテスト（リリーステスト①）を設計します。 

次は、スプリント2（実装・テストフェーズ）です。リリーステスト①で発見された不具合の修正確認と、リリーステスト②の設計を行います。 

最後に、スプリント3（修正・最終テストフェーズ）ではリリーステスト②と、製品全体を通した最終的なE2E（End-to-End）テストを実施します。 

このサイクルに加え、新規OSへの対応検証やユーザーからの問い合わせ調査、オフショアチームへの修正依頼といった突発的なタスクも発生します。

田山はこれらのタスクをメンバーへ割り振り、チーム全体としてつねに稼働率を最大化しているのです。 

このQAチームのもう1つの特徴は、QAメンバーからUI／UXに関する改善提案が積極的にあがってくることです。

彼らは、毎朝行われるQAチームの朝会にて、進捗報告だけでなく、「ここのボタンは直感的でない」「この操作は使いづらい」といった、製品に対する違和感や気づきを積極的に共有しています。 

リーダーである田山自らが、フラットに意見をいいあえる雰囲気をつくり出すことで、メンバーは、臆することなく改善提案ができるのです。 

開発・QA・オフショアが一体になると、プロダクトは大きく進化する

QAチームでは、テスト以外にもリリース作業や、デプロイマニュアルの作成などに携わっています。

「QAがデプロイまで担当する」と聞くと、驚く方も多いでしょう。

田山は、QAがリリース作業を自ら行うことのメリットについて、「リリース作業を体感することで、インフラに近い挙動、例えば『バッチ処理が毎時0分に起動する』といったシステムの裏側の動きを肌で理解できます」と説明します。

通常、QAのテストはアプリケーションの要件が満たされているかという「要件適合性テスト」に偏りがちです。

しかし、デプロイを通じてインフラの知識を得ることで、サーバー負荷やネットワーク、データベースといった、より広い視点でのテスト観点が養われます。

とはいえ、専門性の高いデプロイ作業をQAチームが単独でこなせるわけではありません。この取り組みが成功している背景には、開発チームとの協力関係がありました。

デプロイに必要なコマンドの作成や技術的な基盤の整備は、専門知識をもつ開発チームが担当します。そして、その手順をドキュメントとして整理し、実行可能な形でQAチームに作業を移譲するのです。

これは「丸投げ」ではありません。それぞれの専門性を尊重し、もっとも効果的な作業分担を模索した結果たどり着いた、パートナーシップの形です。

このチームは、ベトナムのオフショア開発チームとも密接に連携しています。言語や文化の壁を越えてスムーズなコミュニケーションを実現している鍵は、「ブリッジメンバー」の存在です。

ブリッジメンバーが、開発チケット（作業指示書）の内容の翻訳や意図の伝達、スケジュール管理、リソース調整などをきめ細かく担うことで、QAチームは品質保証活動に集中できます。

また、QAチーム自身も、開発メンバーに対して積極的に質問し、仕様への理解を深める努力を怠りません。

適切なメンバー配置と、能動的なコミュニケーションが、チーム全体の生産性を支える生命線となっています。 

品質保証が開発を牽引する時代へ。SHIFT QAの挑戦

最後に、同チームが見据える未来は、QAが単なる「不具合を流出させない最後の砦」で終わることではありません。不具合の分析を通じて開発プロセス全体を改善していく存在になることです。 

QAチームがテストという専門領域から一歩踏み出し業務範囲を広げることは、QA活動そのものに大きなメリットをもたらします。

開発に携わるメンバーや、ユーザーとも密に連携していきたいと考えています。 

周囲のメンバーと連携しプロセスを俯瞰して、品質とデリバリー活動にとってよりよい形を考えていくことで、ユーザーにとって安全・安心かつ、有効なシステムを届けていきます。

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

知識やノウハウを体系的に学べる勉強会

お客様に真の価値貢献をするためのナレッジをシェアしあう。通称「ヨコッチシェア」

お客様に価値貢献をするためのナレッジを集約・共有・提供するために設立された勉強会です。

現場での各種シチュエーション（進捗報告やヒアリング、終了報告・提案など）についてお題が出され、参加者が自身のナレッジを事前にアンケート形式で回答します。

数百ほどあつまった回答のなかから部長陣がこれはぜひ他の方にも知ってほしいというものをピックアップし、リアルとオンラインのハイブリッド形式の勉強会で共有。今後の業務に活かせるようにしています。

キャリアアップへの理解を深め、学習のコツを知る。「トップガンナイト」

トップガン検定※への理解を深め、受検を促すために、トップガン作問者や合格者が試験の概要や学習のコツ、合格の秘訣を語る勉強会です。

正社員登用後のキャリアマップも紹介するなど、マイスター（アルバイト従業員）や契約社員のキャリア理解を深め、モチベーションを高める役割も担っています。

※トップガン検定…SHIFTグループ従業員を対象とする独自の社内キャリアUP制度

キャリアップ検定合格への近道。「スター社員講座（トップガン）」

トップガン受検予定者のスキルアップをサポートする勉強会です。現場で活躍するスター社員が受検科目を解説する回、正解率の低い問題の解説を行う回、採点を講評する回など、さまざまな講座があります。 

現場で役立つ品質向上のノウハウを伝授。「スター社員講座（品質道場）」

プロジェクトの現場で活動しているエンジニアに向けて、スター社員が現場で役立つ知識やノウハウを紹介する勉強会です。

プロジェクトマネジメント全般や、テスト計画・設計・実行・報告といった一連のテスト業務などについて、毎回異なるテーマを取り上げます。

テスト設計ツールを実際に使って活用方法を知る。「TDハンズオンセミナー」 

SHIFT標準のテスト設計ツール「TD」（Test Designer）の機能を把握したり、案件適用時の使い方をイメージしたりするためのセミナー形式の勉強会です。

TDにまつわる勉強会としては、活用ノウハウをする「MEET UP」や、TDのAI機能「TD AI Assistant」を実際に使ってみる「TD AIドッグフーディング会」があります。

ちなみに、こんな教育プログラムも。

特定のポジションを担うメンバーを支援する勉強会

特定のポジションに必要なナレッジをシェア。通称「サビ勉」「キャプ勉」

SHIFTでは、特定のポジションのメンバーを対象にする勉強会も実施しています。 

サービスマネージャー※向けに開催される勉強会を「サビ勉」、キャプテン※向けに実施されるものを「キャプ勉」と呼びます。

※サービスマネージャー…複数案件を管理し、滞りなくサービス提供ができるよう責任を担うポジション。

※キャプテン…営業が拾いきれないお客様の現場の課題をヒアリングし、プロジェクトを成功に導くポジション。

いずれのポジションにおいても必要な、お客様との向き合い方や他社との協業関係を構築する方法を学んだり、SHIFTのプロダクトやサービス理解を深めたりします。

一人ひとりのスキルと横の繋がりを高める勉強会コミュニティ

SHIFTには、多様な技術領域のエンジニアが在籍し、領域ごとにさまざまな規模の技術勉強会が開催されています。ここでは、その一部を紹介します。

スクラムマスターへの道を支援。「シン・スクラムマスター虎の穴」

スクラムマスターとしてアサインされることを目指し、スクラムマスターに必要なスキル・考え方を学ぶ勉強会です。知識を実務に役立てられるよう、ケースワークや動画視聴会などトピックに合わせた形式で開催しています。

Teamsでの開催時は技術サービス組織の勉強会チャネルなどで告知されます。

多様なテーマで交流する場。「SHIFT QA Night ONLINE」

品質分析、セキュリティ、UI/UX、心理学、ライフプランなど、QAを軸にしつつも、それだけにとどまらない多岐にわたるテーマを扱う勉強会です。

プレゼンやディスカッションを通して、知識を共有したり、悩みごとの相談をしあったりすることで、SHIFT内の横の繋がりを強化します。

コミュニケーションスキルを磨く。「ブートキャンプ」

PMやリーダー、プロジェクトメンバーがプロジェクト推進に求められるコミュニケーションスキルを身につけるための勉強会です。

オンラインまたはリアルで参加者同士がコミュニケーションをとったり、コミュニケーションスキルに関する教育コンテンツを視聴したりします。

お客様から信頼されて課題をスムーズに把握することができ、案件をスムーズに進められる人材を目指すコミュニティを形成し、相談しあう環境も提供されます。

ここにあげたもの以外に、グループ会社を含めた提供サービスや導入事例について理解を深めるための勉強会もあります。

これからも、SHIFTメンバーの「スキルアップしたい」という思いを大切に、勉強会を企画していきます。

読者のみなさんも、入社後には社内勉強会にぜひ参加してくださいね！

※本記事の内容は、公開当時のものです

※SHIFT EVOLVEとは？

SHIFTグループが主催する技術イベントグループ。 エンジニアコミュニティから技術をEVOLVEしていこう、という想いで運営し、メンバー登録者数は3,200人を超える（2024年9月時点）。開催予定のイベントは以下よりチェック。 https://shiftevolve.connpass.com/

さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 by.石井 優（SHIFT）

石井が所属するSHIFTのサービスプラットフォームグループでは、統合型ソフトウェアテスト管理ツール「CAT（COMPUTER AIDED TEST）」や、テスト設計支援ツール「TD （TEST DESIGNER）」の自社開発や、それらを活用したAI技術の活用推進、社内の基盤開発などを進めています。

特にTDでは、現在「TD AI Assistant」の開発を進めており、これまでSHIFTが溜めてきたテストケースや標準テスト観点などのナレッジにAIの力を組みあわせることで、よりはやく精度の高いテストケースの設計を可能にするための取り組みを進めています。 

AI導入による具体的な提供価値とターゲット、解決されるペインは、上の投影資料にある通りです。 

そもそもTDは、以下のスライドにある通りテスト設計の段階を分割し、レビューと設計の効率を両立することを目指して構築されています。 

ここに対してTD AI Assistantでは、分解された各ステップに対してAIが支援する仕組みになっています。

ポイントは、AIに丸投げするのではなく、AIが品質保証エンジニアの業務を支援するような形での業務フローが想定されている点にあります。

「AIに渡すためには『ここの行間をうまく読んでよ』ではダメで、細かく指示をセットする必要があります。生成AI時代ではインプットとなる仕様を最初に整えておくことが大事であり、そこが我々が現在感じているハードルの一つです」（石井） 

テストケースの自動生成に生成AIの導入を試みた話 by.坂下 聡氏（NEC）

日本電気株式会社（以下、NEC）でテストソリューション、テスト自動化の推進を担当している坂下氏からは、既存の設計書（Excel形式）からテスト仕様書を作成し、テストスクリプトを出力するテストケースの自動生成ツールの一部に、生成AIが活用できないかを検討した2023年12月時点での取り組みが紹介されました。

NECでは以前から、上のスライドに描かれているようなテストケース自動生成ツールが使われていたのですが、主に日本語の処理において課題がある状況でした。

今回の取り組みは、この日本語処理に対して生成AIが活用できないか、という話。

実際に既存の設計書（Excel形式）を読み込ませてChatGPT-4でテストケースを作成したところ、以下の特徴／可能性などがわかってきたといいます。

これらに加えて、例えばログイン有無の条件分岐が解釈できないので書き方を考えたり、入力チェックのチェック項目は全部バラバラに記載したりといった試行錯誤を経てChatGPT活用に再チャレンジしたところ、決まったキーワードなどによるフォーマットで指示をするだけで、ある程度のものがアウトプットされるようになったといいます。 

以上の経験から、「AI-Readyなデータ」の準備こそが、生成AI活用促進の鍵だと坂下氏は説明します。

そのうえで現時点の生成AIが向いているのは、ドメイン知識を必要としない一般的なシステムのテストケースの設計・作成や、知識を特定のフォーマットに整理したうえで実施するようなテストシナリオ。

一方で論理的思考や人間の直感が必要になるようなアドホックテストや探索的テストなどのケースには不向きであることを示しました。

最後に、今後のテストプロセスにおける生成AIの期待について、以下のスライドを投影しながらコメントしました。 

「特にテスト計画のところは、品質計画やテスト戦略などの部分も含めて立てていくことを考えていくと、まだまだこれからの世界かなという印象があります」（坂下氏）

E2Eテスト自動化プラットフォームにおけるAIの活用 by.伊藤 望氏（MagicPod） 

自動テストツール歴15年の伊藤氏が提供しているのが、Web＆モバイルアプリのE2Eテスト自動化SaaS「MagicPod」です。こちらのプロダクトでは、以下3つの機能でAIを活用しているといいます。

• 人間に読みやすい画面要素名
• 自動修復（アプリケーションの画面構成が変わってテストが失敗した場合に、AIがテスト側を適切に修正してテストを継続する機能）
• 生成AI

今回のテーマである3つ目の生成AI機能では、「テストケースの要約」、「変更コメントの生成」、そして「ランダムIDの検出」の3点について生成AIの活用が検討され、前者2つについてはMagicPodへの機能実装が進められました。

例えば変更コメントの生成機能をみてみると、変更前と変更後のスクリプトをそれぞれMagicPodのAPIを使って人間が読めるテキストへと変換し、それらを使って以下のプロントをChatGPTに渡すことで、割と実用的に活用できるアウトプットになったといいます。

一方で最後の「ランダムIDの検出」は、最終的にボツになった事例です。

検証の流れとしては、HTMLからすべてのidとclassをひたすら抜き出し、そのなかのどれがランダムIDかどうかを生成AIに渡して判断してもらうという、シンプルなものになります。

渡したプロンプトは以下の通りです。

こちらの検証の結果、生成AIは多くのランダムIDを検出でき、検出されたものはほぼ正しくランダムIDだったものの、一方で検出漏れが頻繁に発生し、さらに30個のIDを検出するのに6秒もかかるという状況だったとのことで、MagicPodに組み込むのはいまのところむずかしそうだと判断しました。

「ただし、最近のChatGPTはかなりレスポンスがはやいので、また結果は違ってくるかと思います。

また、リアルタイムではなく自動修復のときにやれればいいといったアプローチもあると思うので、今後またチャレンジしたいと思っています」（伊藤氏）

パネルディスカッション「生成AIはどうテストを変えるのか」

最後に、登壇者3名を交えたパネルディスカッションが展開されました。ここでは、各ディスカッショントピックにおいて特に印象深かった発言をピックアップしてお伝えします。 

質問：AIがテストを設計する未来についてどう思われますか？

伊藤：AIが本当に全部を変えてくれるみたいな日もくるのでしょうが、テスト設計って裏側にあるモデリングの話や、それこそ人がもつ常識など、いろんなことを知っていないとダメだと思っています。 

プログラムを書くのと同じぐらい本質的に人間じゃないとできないことだと思うので、テスト仕様書が本当に自動でつくれるようになったときは、たぶん仕様書もプログラムも全部つくれるようになっていて、エンジニアも概ね失業というかロールが変わっているみたいな状況かなと思います。

テストだけ先に全部自動化みたいなことにはならないのではと思っています。 

質問：AIでE2Eテストのコストは限りなくゼロに近づくのでしょうか？ 

伊藤：本当にゼロになっているときというのは、ほかのいろんなITコストもゼロになっているときだと思います。

その前提にはなりますが、MagicPodを開発していて思うのは、製品の仕様書から全部つくって、テストも全部やってくれるみたいな世界は少し大変だなと思いますが、人間が手動テストで普段使っているテストケースだけを読み、あとはそこの自然言語で書いているやつを使ってE2Eテストができたらいいなとは、けっこう思ったりしています。

もう少しChatGPTなどが賢くなればできる側面もあるのかなと思っているので、当然ゼロにはなりませんが、減ってはいくと思います。

坂下：ユニットテストを書くのがめんどくさい、っていうSEの方ってけっこう多いんですよね。大変なので。

その部分にAIを使うことで、いわゆる品質を担保しながらタイプミスなども減らせると思うので、レビューにも注力できると。

それに連携する形で開発コードも自動的に生成できてくるような形になって行くことを踏まえると、まずはユニットテストのところが一番効率的に進められるのかなと感じます。

質問：AIがつくったテストの信憑性についてはどうお考えでしょうか？ 

石井：実際にTD AI Assistantを再評価したときに、テストの信憑性を評価するのってむずかしいね、っていう声が出ていました。

というのも、実際に検証するとなると、そのロジックを頭のなかで考えて、それがこの状態であっているのか否かを、仕様とつきあわせながら考えないといけません。

それがけっこうつらいなっていうのが、TD AI Assistantの課題であり、そこを乗り越えていくのはけっこう大変だなと思っています。

もうちょっと上位の、例えばテスト観点を出してもらうとか、テスト戦略をいっしょに考えてもらうとかっていう方が自然なのかなと思っています。

伊藤：AIが書いたものを人間がチェックする未来ではなく、人間が書いたものをAIがチェックする未来であってほしいですけどね、個人的には。むずかしいところですが…。

質問：AIの普及によってテストは増えますか？それとも減りますか？ 

伊藤：つくるコストが低いので、どうやっても増えることは増えると思います。増えるところまで増えきって、これではいけないとなって間引く、という話がやってくるんじゃないですかね。 

石井：パーキンソンの法則で考えると、どこまでやるのっていうのをちゃんと定義しないと、いつまでたっても増えつづける一方だなって思いました。

坂下：例えば増えるのをよしとして、増えたおかげでいままでリグレッションとかでテストの範囲が届かなかったところを自動でやるっていうところで品質を均一に担保していくっていう考え方をすれば、増えたら増えたなりの効果が出るという話になるかなと思います。 

パネルディスカッションの他パートや、動画全編をご覧になりたい方はこちら 

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。「AI Test Lab」と銘打ったシリーズは今回がはじめてでした。Vol.2以降もぜひお楽しみに。 

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

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

人と向き合い、人を巻き込む仕事

Q1. 流通・物流領域における「リーダー」の役割とは？ 

櫻井：私たちのチームは、コンビニチェーンからアパレルまで、流通・小売業界に特化してソフトウェアテストとPMOサービスを提供しています。 

それぞれの現場に、メンバーが入り、お客様のシステムのテストの実行・設計・計画、あるいはお客様の会社の社員代行としてプロジェクトの推進を手がけています。

そのなかで「リーダー」の役割は、現場メンバーを２～15人ほど束ねて、文字通り、リードしていくことです。 

Q2.具体的にはどのような案件に、どのように関わっているのでしょう？ 

櫻井：流通業界のお客様は、無人レジの導入やECサイトの充実、倉庫の自動化など激しい競争を勝ち抜くためのDXに積極的です。 

リーダーは、フロントエンドからバックエンドにいたるまで、こうしたDXを支援するためにメンバーを牽引。

チームの進捗管理はもちろんのこと、テスト実行や設計を担うメンバーの業務をレビュワーとしてチェックをしたりなど、チームのアウトプットの質とスピードをコントロールします。 

加えて、チームだけではなくお客様の要望を直接聞き入れ、プロジェクトのプランニングに反映。現場によっては多く参画する他社ベンダーとの調整の窓口役も担っています。 

現場でテスト実行や設計を手がけるメンバーからリーダーにロールアップして大きく変わるのは、「人とコミュニケーションをとる仕事」が倍増することです。 

プロジェクトを予定どおり進捗させるのはリーダーの大きな目的ですが、そのために日々、人と向き合うことが大切な仕事になります。 

Q3.リーダーに求められる資質は、何でしょうか？ 

櫻井：IT人材に不可欠な「論理的思考力」や、スピード感あふれるビジネスを手がける流通業界にフィットする「柔軟性」、凝り固まらずに新しいことに臨機応変に挑める「鈍感力」――。 

これらメンバーに必要な資質は、リーダーでも変わらず必要な資質でしょう。 加えて、リーダーになると「巻き込み力」をもっていてほしい。 

人ひとりができる仕事は限られています。大きな成果をあげるために、必要な人たちを必要なタイミングで巻き込む力は、リーダー以上のポジションでは大事になってきます。 

さらにSHIFTのリーダーには、本当の意味でのリーダーシップがなければ務まらないと思います。

スコープをコントロールし、一段上の視点をもつ

Q4.「本当の意味でのリーダーシップ」とは？ 

櫻井：プロジェクトメンバーだけではなく、プロジェクトそのものやお客様もリードしていく、強い意思のことです。 

駆け出しのリーダーは、特に内向きに目が向きすぎる傾向があります。メンバーを気を遣ったり、どんなアラートにも迅速に反応するなどはできる。しかし、それはリーダーがすべき仕事の一部でしかありません。 

とくに、SHIFTは伝統的なSIerなどとは違い、成果完成形ではなく「準委任契約」でのプロジェクトが多くを占めます。ひとつのシステムをつくりあげる成果物に対して契約するのではなく、「業務の遂行そのもの」が報酬の対象です。 

いい方を変えると、お客様にしてみると明確な成果が見えにくいことがありえるということ。だからこそ、こちら側がしっかりとスコープコントロール（お客様からSHIFTへの期待値を明確にすること）をしてお客様に適切に提示し、共有する必要があるのです。 

こうした役割をリーダーに担ってほしい。そのためには、単にメンバーケアといった内向きな視点ではなく、プロジェクトそのものを引っ張ってほしい思いが強いです。

Q5.リーダーが昇級する際のポイントとは？ 

櫻井：先にあげたような本当の意味でのリーダーシップをいかなるときでも発揮できるか、ですね。 

たとえば、Bさんは、あるプロジェクトでトラブルが発生して、部長である私が直接、現場で指揮をとったときにリーダーとして現場とのつなぎ役をしてくれました。 

このときに、私はあえて細かい指示を彼に伝えることはしませんでした。しかし彼は、実に的確に補って現場のメンバーへの指示の言葉に変えてくれました。

「一を聞いて十を知る」を地で行き、スピード感をもって、具体の指示に変えておろしていった。 

彼はリーダーながらその上のマネージャーの視点をもって考え、動いていたように感じました。こういった姿勢は一朝一夕に身につくものではありません。

きっとメンバーのころからリーダー、マネージャーの視点をもって思考していたのでしょう。 

こうしたいまいるロールのひとつ上、ふたつ上の高い視座で考え、動ける。そうした人材はスピーディに昇級する傾向があります。 

Q6.どんな人にリーダーとしてジョインしてほしいか？ 

櫻井：リーダーになると求められる難易度はあがると思います。ただし、そのうえの責任はマネージャーがとるので、思う存分、自分の力を発揮して、リーダーシップを振るってほしい。 

「もっと”自分ごと”として、案件に関わりたい」「大きな成果をあげたい」と考えている方には、ぜひリーダー職として活躍していただきたいですね。 

（※本記事の内容は、取材当時のものです）

流通業界の川上から川下まで。第一線でソフトウェアテストを実行・計画する

Q1. 流通・物流領域における「メンバー」の役割とは？ 

櫻井：流通・小売業界に特化して、ソフトウェアテストとPMOサービスをメインにお客様のDXを支援するのが、私たち流通・物流領域のミッションです。 

メンバーは、コンビニチェーンやアパレル、百貨店やドラッグストアといったお客様の案件に入り、第一線で活動します。

数多のシステムのテスト実行・設計・計画、あるいはお客様の社員代行としてプロジェクトの推進を日々、手がけています。 

Q2.具体的にはどのような案件に、どのように関わっているのでしょう？ 

櫻井：例えば某大手アパレルチェーンの店舗で使われているセルフレジやECサイトの品質管理・テスト。コンビニチェーンのアプリケーションのシステム管理などのPMO。

スーパーマーケットの無人レジのシステムのテストと品質管理……。 

ユーザーとして極めて身近なアプリやサービスに直接触れられ、品質の向上に貢献できる。それは流通・物流領域のメンバーならではの醍醐味のひとつです。 

もちろんエンドユーザーの目に触れない販売管理などの基幹システムなどもあり、これらの品質保証やテストサービス、あるいはPMOサービスも私たちのチームの得意分野。多くのメンバーがお客様を支援し、力になっています。 

加えて、オンラインショッピングの利用増加や人手不足などを背景に、倉庫の省人化や膨大なデータ管理といった物流関係のDXニーズが極めて高くなっています。

これらバックエンドの領域で品質保証エンジニア、またはPMOとしても多くのメンバーが現場に入り、活躍してくれています。 

いずれにしても、メンバーになることは、流通物流業界の川上から川下まで、幅広な現場に入り込んで業務を遂行すること。

結果として、流通物流業界のビジネスフローすべてに関われて、この業界のどこでも戦えるスキルと経験を身につけられるのは、キャリアにおいての大きなメリットでしょう。 

大事なのは「鈍感力」？鈍感さが強みになる理由

Q3.メンバーに求められる資質は、何でしょうか？ 

櫻井：IT系人材全般に通じますが、「論理的思考力」は不可欠です。 

どんなシステムもビジネスも、ロジックが明確でなければ、うまくまわりません。ソフトウェアテストでも同様で、論理的にものごとを捉え、分解してクリアに思考できるに越したことはない。 

加えて、論理的に思考して構築したものを凝り固まり過ぎず変えたり、捨てたりできる「柔軟性」もあわせもっていてほしいです。 

流通業界では、スピードが非常に大事。競争激しく、ビジネス環境が目まぐるしく変わりますからね。

品質保証エンジニアでもPMOでも、お客様の側で仕事するメンバーは同様のスピード感を求められます。 

その意味で、論理的思考に固執して「これが正しい」「こうすべきだ」と“べき論”を振りかざすだけの人は向いていない。 むしろスピーディに変わる状況やお客様の判断にも、臨機応変に対応できるマインド。

納期日必達のために完璧を求めるよりもとにかく物事を前に進めるような、いい意味での「鈍感力」がある人が向いているかもしれません。 

もちろん、最初からロジカルで柔軟性があり、鈍感力をもっている必要はありません。

少なくとも「そうした資質をもつほうがフィットするな」と理解して、自分をそこに寄せていけるメンバーは、どんどんキャリアアップしている印象があります。 

Q4.メンバーからリーダーに昇級するポイントとは？ 

櫻井：自主性をもって、自分を磨く意欲とフットワークをもっている。そういうタイプは、すぐさま頭角を現して伸びていきます。短期に大幅な昇給があることもあります。 

直近では、2022年卒でとても印象的なメンバーがいました。 

SHIFTには社内検定制度（トップガン検定※SHIFTグループ従業員を対象としたキャリアUP制度）があり、数多ある検定に合格するとそれに対応する職務を任され、自分自身の単価、そして給料もあげられる仕組みを採用しています。 

テスト設計者としての検定に受かると、テスト設計を任される。さらに上位の検定に受かるとPMやPMO…といった具合にロールアップします。 

ロールアップするごとにお客様からいただくフィーがあがるので、自動的に昇給にもつながるわけです。 

先に触れた22年卒のAさんは、10％以下である合格率の検定を見事クリア。いちはやくテスト計画の仕事を任されるようになってからも、次の検定にも次から次へと受検しました。 

そして1年もたたずに、テスト設計リーダーといったような重要な役割を担うようになり、大幅な昇給がありました。 

彼の「次から次へと検定を受ける」積極性が、検定受検への姿勢だけではなかったことが功を奏したのだと思います。

テスト実行でも、テスト設計でも、上司や先輩のやり方をうまく模倣し、疑問点は素直に質問して、ぐいぐいと前進するタイプでした。

もちろん、Q3であげた論理的思考力や柔軟性ももち得ていたと思いますが、そうした地頭のよさに加えて、自律的に前進していくマインドのある方は、スムーズに昇級を重ねていますね。 

裏返すと、そうしたポテンシャルの高いメンバーをきちんと評価する仕組みが、SHIFTにはあるともいえるでしょう。 

Q5.どんな人にメンバーとしてジョインしてほしいですか？ 

櫻井：いろいろいってきましたが、先にあげた資質や特徴が合致しなくても「おもしろそうだ」「自分にあいそうだ」と感じられた方がいたら、ぜひ応募していただきたいです。 

前向きさと鈍感力こそが、私たちSHIFTの流通物流サービス部が期待していることですからね。 

（※本記事の内容は、取材当時のものです） 

尖った流通業界の、先端に立てる醍醐味

Q1. 流通物流サービス部が手がけている領域と特徴を教えてください。 

櫻井：小売・流通や物流、食品や農林・水産などの商社といった、広範な産業向けにお客様のDXを支援しています。 

なかでもコンビニやスーパー、アパレルといった流通領域は、DXの機運が高く、競争も激しい業界。セルフレジやモバイルオーダーといった店舗の省人化に積極的で、「運営コストを削減したうえでサービスの質をあげたい」と考えていらっしゃいます。 

そうしたニーズにスピーディにお答えできるよう、「テスト」と「PMO」という品質保証に関するサービスを提供しているのです。

しかもSHIFTのPMOサービスは業界でいわれる「事務局的なPMO」としてルーティンワークを行うのではなく、お客様側と‟同じ人格”をもってプロジェクトを管理運営するものです。 

かつては「SHIFTはテストばかりやっているのですか？」と聞かれることも多かったのですが、いまは、PMOとテストでほぼ半々。

特に我々、流通領域のビジネスポートフォリオをみると、売上は6：4でPMOの方が多いほどです。 なお現在、流通物流サービス部には500人ほどのメンバーがいます。 

Q2. 流通物流サービス部にジョインした場合、個人の能力はどんな成長が見込まれますか？ 

櫻井：幅の広い「エンジニアリングの知識」と、深いレベルの「業界全体の知見」を積めることです。 

少し前までは、流通領域のお客様のニーズは、圧倒的に「フロントエンドのシステム」でした。店舗であればPOSレジや、ECサイトのシステムなど、BtoCの直接消費者の目に触れるシステムです。 

しかし、この1年半ほどでバックエンド側、いわゆる倉庫や物流にかかわる業務システムの領域の案件が急増しました。

フロントエンドのDXは成熟しはじめた一方、物流コストを下げるための「倉庫の無人化・自動化」といったバックエンドのDXは、まだこれからの面が強いためです。 

そうしたお客様の利益に直結するビジネスの最前線で、テストやPMOを携われるのはとても刺激的です。幅広な知識と知見が磨け、流通業界全体の潮流も広く深く理解できるはずです。

仮に品質保証エンジニアとして仕事に携わりはじめても、コンサル的な高い視座の知見を自ずと磨けるでしょう。 

もとより、消費者としてイメージしやすい大手アパレル、コンビニ、スーパーといった、toCの有名企業がお客様です。あらゆる領域のなかでも特に社会に役立っている実感と醍醐味が存分に味わえます。 

Q3. 流通物流サービス部にジョインした場合、具体的なキャリアパスは？ 

櫻井：キャリア階層は、プロジェクトマネジメントのスキル別に大きく3つ。「メンバー」「リーダー」「マネージャー」にわかれます。 

「メンバー」の最初のステージはテストの実行を担う役割。その後、設計を手がけるようになってもらい、さらにテスト計画まで手がけてもらいます。 

計画までできるようになったら、「リーダー」の階層にあがってもらいます。2～15人を束ねて、彼らの仕事のフィードバックをしながらフォローしてもらう仕事です。 

その次が「マネージャー」職になります。2つにわかれていて、最初は5～40人を従えてひとつのプロジェクト担当となる「プロジェクトマネージャー」に。

その後、一般的なIT業界ではシニアマネージャーの職位にあたる「サービスマネージャー（※）」にあがります。 

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

サービスマネージャーになると、最低でも1社のお客様と向き合って日々サービスのデリバリーを担当。複数プロジェクトをみると同時に、案件拡大のためにサービスの提案も手がけてもらいます。 

その先はラインマネジメントで、最初は「グループ長」に、そしていま私が就いている「部長」になって、そのうえの「本部長」に……とあがっていきます。 

このように現場からラインマネジメントへとあがるのがスタンダードですが、一方でスペシャリストとしてずっと現場の仕事をつづけていくキャリアパスもあります。 

たとえば、50代後半や60代で、大企業の要職につかれていた方が役職定年や60歳定年を迎えた後、SHIFTに転職。「いままでは管理職だったけれど、現場をやりたかった」と活躍されている方もたくさんいます。 

Q4.評価制度の特徴を教えて下さい。 

櫻井：年功序列なしの、「完全成果主義」であることです。 

SHIFTグループは約13,000人の従業員がいますが（2024年2月時点）、成果主義であり「絶対評価」で「ガラス張り」であることも大きな特徴です。 

「S評価は上位10％、A評価は20％、B評価は30％…」などとあらかじめ順位ごとに定員が決められていて、そこにあてはめる相対評価ではありません。 

成果を出したら出しただけ、ダイレクトに自分の評価と報酬に反映される「絶対評価」。従業員が不公平を感じることはまずない設計にしてあります。 

一方の「ガラス張り」の意味は、一つひとつのサービスのデリバリーで得られた売上と利益の大枠を社内でオープンに提示しているからです。 

「この役割に対しお客様からいただく単価はこれだから、あなたが目指せる年収の上限はこれだけありますよ」とある程度、開示しています。

そのうえで半期ごとに上長と目標管理制度に基づいて「今期の活動成果は80％ほどだったから上限の85％の給料額で。まだ上が目指せますね」とフィードバックのうえ、すりあわせます。 

一言でいえば、フェアネスをもっとも大事にしている。これは代表の丹下が大切にしている想いでもあります。 

もっとも、この評価制度を運営するため、信じられないほど「人に向き合う時間」をつくっているのもSHIFTの特徴です。 

上長との目標設定から評価のフィードバックまで、面談を半期内に計4回は行います。そのうえで日々、1on1が繰り返しおこなわれています。

時間をとって、その人の仕事とキャラクターを理解したうえで、生真面目に評価するカルチャーが根づいているのです。 

Q5流通物流サービス部において、特に重視される特徴的な評価基準は？ 

櫻井：目標達成率や、それに至るまでのプロセスなどを丁寧に評価するのは、どの部署も変わりません。 

ただし、流通領域のチームは「スピード感」を重視する面は強いかもしれません。 

お客様である流通業界は、QCD（Quality＝品質・Cost＝コスト・Delivery＝納期）でいうと「D」を最優先する傾向が極めて高いためです。

そのために私たちはスピードを重視する。品質やコストももちろん大事ですが、何よりプロジェクトを前進させる気概がマストです。 

立ち止まらずに前進するマインドを見せてくれることは、評価ポイントにつながる面が少なからずあります。 

Q6.意思はあっても、成果を出せないメンバーがいた場合、何かしらのフォロー体制がありますか？ 

櫻井：はい。グループ内外を含めて「ここではちょっとあわなかったね」とフランクに配置転換をおこないます。 

SHIFTにジョインしていただいた以上、ポテンシャルは間違いない。そこで成果が出せないのは、適材適所ではなかった、というだけのことだと考えているからです。 

むしろ評価する上長にこそ厳しい。「アサインされたプロジェクトで成果が出せないメンバーがいた」場合、あるいは「明確な理由がなく昇給していないメンバーがいた」場合なども、上長が「なぜそうした結果なのか」「昇給できるにはどんな対応が必要なのか」と厳しく説明責任を求められます。 

これも代表の丹下の考え方に基づきます。「成果があがらない従業員がいること」「くすぶっている従業員がいること」は、上長の責任である、という考えが社内には根づいています。 

とにかくメンバーには、もつポテンシャルを存分に発揮できる場所で輝いてほしい、という願いがあるのです。 

Q7.どんな人材が、流通物流サービス部で輝けるでしょうか？ 

櫻井：流通業界での経験をもっているに越したことはないですが、実のところ間口は広いと考えています。 

根幹にポジティブさをもっていて、変化を楽しめるタイプ。少しでもそのマインドがあるならば、誰しも輝けると思います。 

いま流通領域は、本当におもしろいタイミングなので、ぜひ多くの方に手をあげていただきたいですね。 

（※本記事の内容は、取材当時のものです）

トップガン検定：アジャイルQAエンジニアの概要

―――アジャイルQAエンジニアのトップガン検定について、まずは概要を教えてください。 

平岡：「アジャイルQAエンジニア」は、2024年にリリースされた最新の検定で、「テストエンジニア」と「スクラムマスター」の間のキャリアラインです。 

アジャイルQAのなかでもエントリーレベルとなっており、上位ロールとしてQAリード、QAコーチが控えています。 

本検定に合格するためには、IT未経験で入社する方にとっての登竜門となる「トップガン（テスト設計者）」の検定科目も合格が必要です。 

それに加えて、専門科目である「アジャイルQA 知識」「アジャイルQA スクラム実践」をクリアすると「アジャイルQAエンジニア」合格となります。 

合格することで、「アジャイルソフトウェア開発に関する基本的な知識があり、QAエンジニアとしてスプリント内のQA活動を滞りなく行える人であること」を証明することができます。 

なお、「トップガン（テスト設計者）」に合格しないと「アジャイルQAエンジニア」が受検できないなどの制限はなく、同時合格を狙うことも可能です！ 

アジャイルQAエンジニアを通じて身につくこと

―――今回、どうしてアジャイルのトップガンをつくろうと思ったのでしょうか？ 

平岡：もともとSHIFT全体でアジャイル開発に力をいれており、お客様からのニーズも高まっていたので、アジャイル人材を増やしていこうという動きがありました。 

新規採用だけではなく、同時に既存従業員の育成も行う必要がありましたが、有志によるアジャイル系の勉強会以外に、育成の仕組みを構築しなくてはと…。

そこで部内で話しあい、「アジャイルのトップガンをつくってみよう！」となったのがはじまりです。 

―――検定受検者にとってのメリットはなんでしょう？ 

平岡：これからの時代、お客様に価値貢献をしていくにはアジャイル開発の知識は必須になると思うので、それを学べるというのは大きいと感じます。 

これまでの日本は世界的に見てもアジャイル開発が浸透していなかったのですが、近年は増加傾向。

「アジャイルの手法がまったくわからない」というエンジニアは市場から取り残されてしまうかもしれません。 

―――検定に合格することで身につくスキルも詳しく教えていただけますか。 

平岡：そうですね、アジャイル開発のベースとなっている「スクラムガイド」と「アジャイルソフトウェア開発宣言」の考え方を正しく理解できるようになる、という点でしょうか。 

世の中にはこれらのベースとなる考えが正しく理解されていない、手法だけアジャイルっぽい“なんちゃってアジャイル”がわりとあって。 

アジャイル開発では「自分の領域はここまでだから」と線引きをせず、短いスプリントのなかで「どうやったら目的を達成できるのか」をチーム全員でつねに考え、コミュニケーションをとっていきます。

必要な情報は自らとりに行き、変化していく要件や目的に対して柔軟に対応していく。これはSHIFTのクレドに通じるところでもありますよね。 

このようにアジャイル開発ではチームで物事を進めていくので、テスト実行者やテスト設計者として優秀というだけではダメで、しっかりとチームで目標達成するためのベースの考え方が身についているかどうかが大事なんです。 

そこの考え方が身についているかを測るためのものが今回の検定という感じですね。 

実際の試験問題では、知識を問うものと「こういう事態がおこったとき、あなたはどう動きますか？」という実践的な問題があります。 

いま時点で自分は何をすべきか、そしてチームにはどんな内容を報告するのか、もっというといますぐ報告するのか翌日のデイリースクラムで間にあうのかなど…、ベースの考え方がないと正解できないようになっています。 

―――前向きなマインドはお客様にも求められるところですよね。合格後の想定キャリアとしてはどのようなものがありますか？ 

平岡：テストのエキスパートになる道ももちろん残っていますが、アジャイルの手法や考え方に共感する方は、QAだけでなくアジャイルコーチやスクラムマスターなど、アジャイル開発のスペシャリストを目指すことが可能です。 

先ほどいった通りアジャイルをやりたい企業は増えていますが、日本のアジャイル人材はまだ少なく希少性が高いので、市場価値も高いですよ。 

―――合格に向けて、勉強のコツがあったらぜひ教えてください。 

平岡：受検する方のレベル感にもよるので一概にはいえないのですが、未経験の方におすすめしているのは、まずは大枠をとらえることです。 

いったんいろいろな情報に触れ、そこからわからないところを具体的につぶしていき、最後は応用できるように頭になじませていく。この繰り返しですね。 

―――どこまでいっても考え方が大事なんですね。それでは、最後に受検者へのメッセージをお願いします！ 

平岡：アジャイル開発のベースの考え方がしっかり根づいている環境であれば、前向きにチームで対話をしながら一丸となってモノづくりができるはずです。 

そういったやりがいを感じられる環境で働けることが個人的には非常に魅力的だと考えています。 

「楽しくチームで成果をあげたい」「楽しくモノづくりをしたい」という方はぜひこの検定を受けていただいて、自分自身が前向きに業務に取り組める人材として、チームに貢献してもらえたらうれしいです！ 

受検者を支える万全のサポート体制

最後に、トップガン合格を目指す人に向けて、運営や過去の合格者による施策についてご紹介します。 

1.トップガンナイト
毎月1回、オンラインでトップガンに関する最新情報や、合格者の声をお届けしています。実際に受検をするかどうか悩んでいる人は参加してみるといいかもしれません。 

2.トップガンサポート
検定の制作や採点をしているトレーナーからサポートが受けられるプログラムです。GPTの活用に関するアドバイスや科目別のサポートなど、いくつかのコースに分かれています。 

トップガンサポート参加者の合格率は、参加してない人と比較すると1.5倍！検定別では最大で3倍ほど。おすすめのサポートプログラムです。 

3. スター社員講座
トップガンシリーズ、品質道場の2種類があります。トップガンシリーズではある科目に集中して学習アドバイスが受けられ、品質道場では実際の業務で必要な情報を提供する場になっています。毎回100名以上参加する人気講座です。 

まとめ

考え方、マインドが非常に重要なアジャイル開発。その考え方は開発現場以外でも役立ちそうですね。少しでも気になった方は、ぜひ入社後にチャレンジしてみてください！ 

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

SHIFTのテスト設計について 

私たちはこれまでの多種多様なテスト業務の知見から確立した独自の方法論とナレッジを有しています。それらをもとに、不具合が発生しやすいポイントを狙い撃ち。 

加えて自社開発した、総合型ソフトウェアテスト管理ツール「CAT」による効率的なテスト管理を武器に、開発とテストの分業化を推進することで開発会社がテストを内製化することによる様々なデメリットを解消しています。 

2024年８月期　第4四半期及び通期決算説明資料P.47より引用

※以下、所属部署は2024年1月時点

金融領域：金融や法律の知識まで身につけ、社会の根幹を守っています

間違った数字を表示してしまうと致命的。特に私が関わる証券業界の場合、それを見てユーザーが瞬間的に株の売買を行うことがあるので責任重大です。

証券業界に限らず、金融領域ではシステム上で数値計算することが多いため、テスト設計では数字まわりに気をつかいます。またテスト設計のスキルとは別に、専門知識が必要。

専門知識がないと、業界特有のフローや計算などが理解できず、付加価値の高い提案ができないばかりか、テストに抜け漏れが出てしまいます。

そのため、私の場合、2022年に証券外務員の資格を取得しました。また、金融領域のテスト設計者は、法律に敏感でなくてはなりません。たとえば、法律が変わることで、システムにいくつもの変更が生まれます。

だからこそ、法律までアンテナを張る必要があるんです。金融システムで事故が発生するとニュースになりかねません。それぐらい社会の根幹となるシステムを、私たちのテストで守っている義務感がありますね。

流通領域：複雑化するPOSシステムに挑み、世界中の買い物を支えています

調べて、勉強して、テスト設計をする。グローバルに展開する衣料系のお客様のPOSシステムを担当するうえで、とても大切にしていることです。店舗がある国にあわせたテストをする必要があり、各国で税率も異なります。

記載ミスもある要件定義書をうのみにするのではなく、まずは自分でたしかめる。そうやってテスト設計をする「前提」を大切にしてきました。

POSレジの進化はめざましく、その用途も扱える金種も増え、テストは複雑化する一方です。不具合を出さない設計書を作成するためにやっているのは、運用の妄想（笑）。

スタッフが店舗でレジを使用する流れなど、めちゃくちゃ想像してパターンを組んだり、因子水準をつくったりしています。 もともと細かな間違いを見つけるのが好きという性格が役立っているのかもしれません。

私たちが不具合を取り除いたPOSシステムが、訪れたことのない国でつかわれていたり、買い物を支えていたりすると思うと不思議な気分ですね。

ネットサービス領域：テスト設計を通して、お客様の想いが見えることにワクワクします

「便利になったね」という笑顔を生むサービスに関わりたい。そんな想いで入社した私が向きあうのは、不動産情報サービスを行うお客様。生活に直結する分野の品質を守ることに、大きなやりがいを感じています。

テストを行うのは、部屋探しサービスに加え、不動産会社など、お客様の取引先に向けたいくつものWebサービスです。

膨大な量の情報を、密に連携させてユーザーに提供するので、仕様は複雑。確実に品質を担保するには、抜け漏れなく、誰にでもわかりやすいテスト設計が欠かせません。

一筋縄ではいきませんが、もともと、何かを読み解く過程が大好き。

テスト設計をするうちに、お客様がサービスに込める想いが見えてきて、ワクワクするんです。お客様にとっても、いまの案件は一大プロジェクトなので、絶対にやり切りたい！

最近では、新たな設計者の育成にも注力しています。テスト設計をSHIFTの強みとして、さらに伸ばす一助になれたらうれしいです。

ERP領域：当たり前のことを当たり前に、そして丁寧にやることが大事

システムをつかうユーザーは当然バグがあるとは思っていません。だから絶対に迷惑をかけちゃいけない。そのような気持ちでテスト設計をしています。ERPのテストは、大きくわけて2つ。

ERPパッケージの開発に対するテストと、企業が既存のERPパッケージを導入する際のカスタマイズに対するテストです。

業務内での画面のつかわれ方、データの流れまで強く意識してテスト設計をしていますが、どんなテスト設計でも、その先には必ずテスト実行があります。

こだわっているのは、テストが正しく実行できるかどうか。特に手順をキッチリ書くことを大事にしています。

手順がわかりやすければ無駄な時間を省け、テスト1件あたりのスピードが上がって、1日により多くのテストを行えます。

いわれれば当たり前のことかもしれません。しかし、当たり前のことを当たり前に、そして丁寧にやることがテスト設計をするうえで何よりも大事なことだと思っています。

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

※アカウントマネージャー：お客様単位での案件管理や、すでにお取引のあるお客様の課題に対する提案活動・折衝を行うポジション 

たとえ現場でつまずいても。自ら考える姿勢を貫く

──多田さんは、新人研修では自らリーダー役を買って出るなど、はやい時期から目立つ存在だったと聞いています。入社当初はどのような気持ちで仕事にのぞんでいたのでしょうか。 

多田：1年目は「何かの分野で1番になる」ことを目標にしていました。国内トップクラスの国立大学や情報系学部出身の同期たちと比べると、自分には強みになるような要素が見当たらなかったんです。 

ただ、巻き込み力やコミュニケーション能力はあると思って、新人研修をとりまとめたんです。自ら動いて何でも吸収していきたいと、社内イベントの幹事や全社総会の実行委員なども率先して引き受けていましたね。 

出鼻をくじかれたのは、2ヶ月間の研修を終えたあと。現場に入りましたが、当初は理解が追いつかず立ちすくんでしまう瞬間もありました。

ひと通りの知識は学んだものの、いざ実践に入るとテスト設計にどう手をつけたらいいのかわからなくなってしまったんです。 

でもだからといって、ただ焦って五月雨式に聞くのは先輩たちに失礼。わからないなりにも自分の頭で考えて仮説を立て、テスト設計の方向性を見出してから、質問することを徹底しました。 

仮説の根拠を示すために相当の時間を費やしましたが、苦労した分、先輩たちからの信頼を得ることができ、現場に馴染むスピードがはやまったと感じています。 

結果、FY2019のSHIFT AWARDで新人賞を受賞することができました。頑張りや成果を見てくれているようでうれしかったですね。 

──「1番になりたい」という気持ちのほかに、ご自身を支えていたものはありましたか？  

多田： 各企業が内製でやっていた品質保証を、SHIFTが第三者として担うというのはそれまでの業界の常識を変えるものです。

そうした点に惹かれて入社した経緯もあり、「品質保証のプロとして技術を身につけたい」という意欲は人一倍強かったと思います。 

テスト設計者だったころ、特に意識していたのは、SHIFTの品質保証ナレッジであるSQF（SHIFT Quality Framework）の活用です。実践のなかで、この会社がもつ“武器”がどんなものなのかを一つひとつ理解していきました。 

相手と対等に渡りあうために。欠かさない綿密な準備   

──翌年からはPM、PMO職に就きました。ポジションが変わったことで、どんな変化がありましたか。 

多田：テスト設計者時代は主に社内に対する視点をもって仕事していましたが、PMやPMOになると、お客様と同じ視点に立つ必要があると感じました。それがもっとも大きな変化でしたね。 

「ナレッジをフル活用してほしい」「社内の品質保証チームを強化したい」など、お客様がSHIFTに抱く期待はさまざまです。

ニーズを正確に把握し、きっちりサービスへと落とし込む。一つひとつのプロセスを丁寧に踏んでいく大切さを知りました。 

──プロジェクトを進めていくうえで、もっとも苦労したことは何ですか。 

多田：PMOになりたてのときは「どうしたらお客様や協力会社、チームメンバーに自分の意見を聞き入れてもらえるか」が最大の悩みでした。当時は新卒2年目でしたし、年齢や経験の壁がとても厚く感じられました。 

悩み抜いて出した結論は、とにかく準備を怠らないこと。一瞬でも「若手だから、思いつきで話している」と思われたらその先はありません。何を質問されても困らないくらいの材料を揃えて、提案や説明にのぞみました。 

──その後、アカウントマネージャーに抜擢。アカウントマネージャーといえば、個別プロジェクトの枠を超え、お客様の課題をヒアリングしながら解決に向けご提案を行うポジションです。1年が経ちましたが、いまどのように仕事に取り組んでいますか。 

多田：それまでは、契約関係にあるお客様に対して、いかに期待以上のサービスを届けるかに注力していましたが、アカウントマネージャーに求められるのは課題を見出す力と、提案力。 

SHIFTがもつソリューションをどう売っていくのか。そして「結果としてお客様に何を提供できるのか」を考え、拡大戦略を練る……熟考すればするほど、自分の視座が上がっていくのを実感します。 

一方で、担当領域は入社以来ずっと金融業界なので、ポジションは変わりつつも経験の積み重ねを実感できる瞬間もあって。業界の常識やトレンドはもちろん、小さなところでは例えば、お客様向けの資料作成。 

成果物は関係部署や上層部、関係省庁にも展開される可能性が高いため、正確性や完全性を重視した資料づくりを心がけるようになり、それがそのままいまのポジションでの活動にも活きています。 

「支援できていないことが、相手に失礼」逆境にも果敢に立ち向かう 

──なかなか契約をとれなかったお客様とも成約できたそうですね。 

多田：実は……あいさつに伺って、SHIFTの強みをお話ししたら「もっと聞きたい」といってもらえたんです。

詳しい話をするのはむずかしいかと思っていたのですが、ふたを開けてみたら“いま”のSHIFTのことを知ってもらえていなかっただけ。 過去に一度契約したことはあったものの、距離が遠のいてしまっていたようでした。 

有利だったのは、先方の他の課とはすでに取引があり、近しい事例が山ほどあったこと。そのときの提案先である部署の課題感と照らし合わせながら、解決策を提示していき、そのまま成約に至りました。 

──マイナスからのアプローチは大抵腰が引けてしまうと思うのですが、なぜ果敢に挑戦できたのでしょうか。 

多田：率直に、SHIFTのサービスを提供できていないことが失礼だと感じて。先方はSHIFTの成長を支えていただいた大切なお客様。なぜその部署のご支援ができないのか、原因を突き止めて解決したかったんです。 

私がどんな状況下でも物怖じせずに提案や説明の場をつくれるのは、間違いなく2年目というはやい時期から、お客様に伴走しプロジェクト管理を進めてきた礎があるからだと思います。 

若手というハンデはありましたが、だからこそ準備を万全にしながら、どんな立場の人とでも対峙できる自分になれたんだと思います。 

 “若手の”という枕詞をとるために。経営メンバーとしても成果をあげたい 

──さまざまな経験を経て2023年10月からはグループ会社であるヒューマンシステムの社外取締役にも就任しました。いま、あらためてSHIFTの強みは何だと思いますか。 

多田：経営理念が仕組みを通じて現場まで浸透していることですね。 

例えば、会社が掲げる目標のひとつに「IT業界の多重下請け構造の改善」がありますが、その施策が現場できちんと実施されています。

SHIFTがプライムベンダーとなって、直接開発会社へ発注し、中間階層を排除しているからです。 

さらに、独自のポジショニングを築いていることにより、給与も業界高水準をキープしています。明確なビジョンを掲げ実践していることが、私を含む従業員の満足度につながっているんじゃないでしょうか。 

──最後に、今後の抱負について聞かせてください。 

多田：社外取締役の辞令を受けて、驚いたと同時に「SHIFTを選んだことは間違っていなかったんだ」と心から思えました。 

いまは周囲からの期待に全力で応えていきたいという思いだけです。上司や同僚たちもこの昇進をものすごく喜んでくれたんですよね。 

若手でも経営層として活躍できる会社であることを示しながら、後につづく道をつくりたい。そして中長期的には「若手の」という枕詞がとれるくらいの成果を残していきたいです。 

──多田さん、本日はありがとうございました！ 

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