JSTQB FL取得を通じて得た知識をチーム運営に還元した話

こんにちは！イタンジでエンジニアリングマネージャーをしている、兼田（かねだ）と申します。子ども2人を育てながら、4プロダクト・8名のメンバーを持つユニットのマネージャーとして毎日全力投球しております。

はじめに

先日、JSTQB FL（JSTQB Foundation Level / Certified Tester Foundation Level）を取得しました。

JSTQB FLとは

JSTQB FLは、国際的なソフトウェアテスト資格団体であるISTQB（International Software Testing Qualifications Board）が認定する「Certified Tester Foundation Level（CTFL）」の日本語版認定資格です。JSTQBはISTQBの日本における窓口であり、国内でのシラバス翻訳・試験実施を担っています。

ISTQBのCTFLは世界100ヶ国以上で実施されており、ソフトウェアテスト分野で最も広く普及した国際資格のひとつです。

試験形式

試験は40問の選択式で、制限時間は60分です。CBT（Computer Based Testing）方式とPBT（Paper Based Testing）方式の2形式が用意されており、2023年10月以降はいつでも受験できる体制が整っています。

シラバスの内容（V4.0）

現行の最新シラバスはVersion 4.0（JSTQB公式サイトよりダウンロード可能）で、以下の6章で構成されています。

章	タイトル
第1章	テストの基礎
第2章	ソフトウェア開発ライフサイクル全体を通じたテスト
第3章	静的テスト
第4章	テスト分析とテスト設計
第5章	テスト活動のマネジメント
第6章	テストツール

第1章では「テストの7原則」など思想的な基盤が、第2章ではシフトレフトやアジャイル開発との接続が、第4章では同値分割・境界値分析・経験ベースのテスト手法といったテスト技法が体系的に扱われています。

JSTQB FLを取得した目的

なぜ私がこのタイミングでFLの取得を目指したのか、続けてご紹介します。

きっかけ①：年始の目標と12年分の知識の棚卸し

2026年の正月に「今年中に資格を3つ取る」という目標を立てました。

エンジニアになって12年ほど経ちますが、振り返ってみるとこれといった資格を取得してきませんでした。日々の業務の中でスキルを積み上げてきた自信はあるものの、体系立てて整理できているかという問いに対しては自信を持って答えられない部分があり、このタイミングで一度自分の知識を棚卸ししたいと思っていました。

資格取得という形でアウトプットすることは、散らかった知識を整理する良いきっかけになりますし、自分が何を知っていて何を知らないかを可視化するうえでも意義があると感じました。

きっかけ②：AI時代の開発における「品質の担保」

もうひとつ、これがメインの理由ですが、2025年から急激に成長するAIの力を最大限に生かした開発・エンジニアリングを行っていくためです。

AIによる実装速度の変革

2025年以降、AIの成長によって初期実装のスピードは格段に上がり、人間がコードを書く機会も劇的に減ってきました。かつては「プロンプトエンジニアリング」という言葉が注目されましたが、今はそれさえもすっかり古いフェーズに入りつつあります。

最近では「ループエンジニアリング」という考え方が登場し、設計・開発業務フローをどのようにAI前提で自動化するかということが、エンジニアの中心的な関心事になってきています。ちなみに私が年始に目標を立てた時点では「ループエンジニアリング」という言葉自体はまだなく、「ハーネスエンジニアリング」という言葉が使われていました。

AIが実装を担うようになってくると、浮かび上がってくる問いがあります。

リリース時の製品品質をどう担保するか。そしてそのために、どのようにループ（開発プロセス）を設計するか。

コードを書きレビューすることが人間の主な役割だった時代から、業務プロセス自体をAI前提で（再）設計することに重心が移りつつある今、品質を担保する責任は以前にも増してエンジニア自身に問われるようになっています。AIが書いたコードの正しさを判断し、何をどのようにテストするかのループを設計するのは、依然として人間です。なお、ここでいう「AIが書いたコードの正しさを判断」というのはユーザーが求めているものを満たすシステムを作っているか？といった観点のことを指しています。

人間がループをコントロールするために

このような状況の中で、人間がループを確実にコントロールし続けるためには、開発プロセスのあらゆるフェーズにおける体系化された知識が必要だと感じていました。

私自身、12年間の業務の中でテストや品質に関わる実践的な知識は身につけてきましたが、それを体系的に整理・言語化できているかというと、心許ない部分もありました。JSTQB FLの学習は、自分自身の業務フロー、そしてチーム・組織の開発プロセスを見直すための絶好の機会になると確信し、取得を決めました。

次のパートでは、実際にJSTQB FLの学習・試験を通じて得た知識を、チーム運営にどのように還元してきたかをご紹介します。

チーム運営への還元

シフトレフトとステークホルダーの早期巻き込み

SDLCの早い段階でテストを始める

JSTQB FLの学習を通じて「シフトレフト」という概念を改めて体系的に理解しました。シフトレフトとは、テスト活動をソフトウェア開発ライフサイクル（SDLC）のできるだけ早い段階で行うという考え方です。

従来の開発では、実装が完了してからテストを行うフローが一般的でしたが、これでは欠陥を後工程で発見することになり、手戻りコストが非常に大きくなります。

私のチームでは以下のプラクティスを取り入れています。

スプリントレビューよりも前にフィードバックを得る

弊社ではスクラムを取り入れているチームが多いですが、一般的なスクラムの流れとしてはスプリントの最終日にスプリントレビューを行うものと思います。ただ、シフトレフトの観点からすると必ずしもスプリントの最終日に初めてステークホルダーに機能を見せるのではタイミングとして少し遅かったり、スプリント期中にまとめてフィードバックをもらいたくなることが私のチームでは度々ありました。そこで、開発途中の段階で開発者のローカル環境での挙動をそのまま社内のCS(カスタマーサクセス)などのステークホルダーに見せてフィードバックをもらうステップを設けています。全てのプロダクトバックログに関して行なっているわけではなく、特に手戻りが発生しやすそうだとチームとして判断した場合のみ行うようにしています。(可能な場合はステージング環境などステークホルダーでもアクセス可能な環境に機能をデプロイをした上でデモをすることもあります)。ビジネスエキスパートや実業を担っている方々が社内にいる弊社のような環境では、この手法が非常に有効です。「動くものを見てから意見が出てくる」ことは多く、早い段階で認識のズレを潰せることで、大幅な手戻りを防げています。

PRDで受け入れ基準を言語化するフロー

機能開発の起点となるPRD（製品要求仕様書）の段階で、受け入れ基準を明確に言語化するフローを整備しています。受け入れ基準を事前に関係者間で合意・読み合わせしておくことで、「実装は完了したが期待していたものと違う」という事態を防ぎます。この受け入れ基準はそのまま受け入れテストケースの素材にもなるため、テスト設計の出発点としても機能します。 JSTQB FLのシラバスでは、ATDD（受け入れテスト駆動開発）のアプローチが紹介されているのですが私のチームではATDDに類似した「リリースノート駆動開発」のアプローチを最近取り入れました。概要と導入決定に至った背景は下記のとおりです。

- 概要
要求共有してrefineした内容を元にリリースノートを書き、それを成功の定義とする（受け入れ条件であり、顧客への提供価値とイコールになる）。
仕様が変わったらリリースノートもrefineされる。
つまり、リリースノートが提供価値のソース。

- 背景
• 「認識のズレ」の解消（ドキュメント形骸化の防止）
従来のプロセスでは開発過程で仕様書などのドキュメントが適切に更新されず、チーム内で認識の齟齬が発生していました。「リリースノート」を開発の指針（成功の定義）として先行して執筆することで、常にチーム全員がゴールを正しく共有できる状態を作るためです。

• 「顧客価値」の早期定義
開発が単なる「機能実装（タスク消化）」に終始しないよう、リファインメント（要件の詰め）の段階からリリースノートを書くことで、「誰に、どんな価値を届けるのか」を明確に定義し直す必要がありました。これにより、開発のブレを排除し、目的意識を持った開発へのシフトを目指しています。

• 開発プロセス全体の効率化
仕様のアップデートがリリースノートに反映される仕組みを作ることで、二重管理などの無駄を減らし、効率的な開発フローを構築するためです。また、これを活用することで、形骸化していた承認プロセスの見直しなど、より本質的なプロセス改善につなげる狙いがあります。
まとめると、**「ドキュメントの鮮度を保ちながら、常に顧客価値を軸足に置いた開発を行うことで、認識合わせのコストを下げ、最短で価値を届ける体制を作る」**ことが、今回の導入の決定的な理由です。

まだ試験的な取り組みではあり改善の余地はありますが、所感として

CSなど顧客に近い社内メンバーにも未来のリリースノートという形で早期に確認を依頼できるので、今作っているものがまず間違いなく顧客に価値を提供できる機能であるという安心感を感じながら開発ができる
仕様説明用の別のドキュメントを書く必要がない
先述した早期にステークホルダーからフィードバックをもらう場面でも先に書いたリリースノートを説明した上で機能デモにスムーズに入ることができる

などのメリットは強く感じています。

テストのチーム全体アプローチ

JSTQB FLでは「チーム全体アプローチ」をとることによってチームダイナミクスを向上させ、チーム内の情報伝達とコラボレーションを強化し、チーム内のスキルセットをプロジェクトの利益のために活用できるような相乗効果を生み出す、とされています。

マインドセットが最重要

ここで改めて認識したのは、テストはツールや手法よりもマインドセットが先行するということです。

チームの誰もが「品質はQA担当者だけの責任ではない」という認識を持つことが、テスト活動の土台になります。エンジニアは自分の実装に責任を持つだけでなく、チーム全体として品質を作り込む意識が必要です。

バイアスとの戦い

以前の記事でも書きましたが、開発者は自分の作ったものを正しいと信じ込んでしまうバイアスにかかりやすいという性質があります。

実装者と同じ人間がそのままテストをすると、確証バイアスが働き「動くはずだ」という視点で確認してしまいます。これはスキルや経験の問題ではなく、人間の認知の仕組み上、自然に起きることです。

以前は「自分が書いたコードは正しい」という思い込みがバイアスとなっていましたが、特にAIを前提とした現在の開発業務においては「自分が出した指示は正しい」という思い込みにすり替わっていることが多いと思います。この状況だと「そもそも自分が書いたコードではない」「指示が正しいのだからそこから生成されるコードも正しいはずだ」という思考が働きやすくなりアウトプットされた成果物に対するセルフレビュー基準がさらに下がり確認漏れやミスが以前より発生しやすくなった、と日々の業務で感じることがよくあります。

この前提に立って、チームでは以下のような工夫をしています。

実装者以外がレビューするフローを必ず挟む

AIが作ったコードでも基本的に指示を出した人間はいるので「指示を出した人間=実装者」とみなしてコードレビューは他のメンバーに依頼することをMUSTのルールとしています。

実装者以外がテストするフローを必ず挟む

ステージング環境での動作検証においては、必ず実装者以外がテスト担当者としてアサインされテスターとしてのテスト観点を列挙した上で検証するステップを通らないとリリースできないフローにしています。デプロイした各成果物に対してどのような観点・テスト技法で検証したかを必ず記述し、開発メンバー、テスト担当者、およびプロダクトオーナー(弊社の場合PdM)がいつでも参照できるテスト進捗レポートとして記録するようにしています。

AIによるコードレビュー・テストケース生成を活用してバイアスを外から補正する

テスト実装・機能実装・レビューをそれぞれ独立したAgent Skillsとして分離することで、バイアスや依存関係が混入しにくい設計にしています。ここで重要なのは実装系のskillとレビュー用のskillを明確に分離していることです。分離させることで内容によっては重複した指示内容・観点も含まれているのですが、偽陽性や偽陰性を防ぐためにあえて独立させる方法を選択しました。また、テストケース生成用のAgent Skillsも何種類か用意してあり、ユーザーの操作・目的単位で記述したユーザーストーリー形式のテストケースをPRDから自動生成することもコードから自動生成することもできるようにしてあるので各開発案件によってどのようにテストを設計するかの選択肢にも幅を持たせて運用しています。

実装者とテスト担当者の関係性・コミュニケーション

弊社のエンジニアリング組織には2026年8月現在、QA専任エンジニアがいません。そのため現状のチーム運営ではテスト担当者は開発メンバーからアサインするかPdMに受け入れテストを依頼するかという形を取ることが多いです。この場合、コミュニケーション不足から欠陥が見落とされるリスクがあります。テスト担当者が実装の意図を理解した上でテストケースを設計できるよう、要求読み合わせやリファインメント・設計議論の段階からテスト担当者およびPdMに対して実装者はオープンに情報を共有する文化を大切にしています。

テスト技法の正しい選択

経験ベースのテスト手法

経験ベースのテスト手法として、JSTQB FLでは以下が体系化されています。

エラー推測：過去の経験や知識から起こりやすい欠陥を推測してテストする
フォールト攻撃：欠陥が入りやすい箇所を意図的に重点的にテストする
探索的テスト：テスト設計・実行・学習を同時に行い、動的に深掘りする
チェックリストベーステスト：過去の知見を蓄積したチェックリストに基づいてテストする

私のチームの開発フローでは「自分たちが経験ベースで何をテストしているか」を言語化し、チェックリストとして蓄積することで属人的なテストを脱却していく取り組みをしています。ただ、各開発案件の性質に応じた最適なテスト技法を選択できているか、選択されたテスト技法から構築されたテストケースの妥当性はどの程度なのかといった振り返りや議論がチームとしてできていないのが実情です。リリース直前のリリース品質ゲートとしてどのようなテストを行うべきかの合意ステップを定義していく必要があると考えており、今後の課題と捉えています。

モンキーテストも選択肢に

ランダムな操作を行うモンキーテストも、ユーザーの予期しない操作を模倣するという意味で有効なテスト手法の一つです。チーム全体が正しいテスト技法の選択肢を持つことで、状況に応じた使い分けができるようになります。

テストの4象限

Brian Marick が提唱したテストの4象限は、テスト活動の全体像を把握するための有用なフレームワークです。

第1象限（チームを支援する・技術面向け）：単体テスト、コンポーネント統合テストなど
第2象限（チームを支援する・ビジネス面向け）：機能テスト、ユーザーストーリーテストなど
第3象限（プロダクトを批評する・ビジネス面向け）：受け入れテスト、ユーザビリティテストなど
第4象限（プロダクトを批評する・技術面向け）：パフォーマンステスト、セキュリティテストなど

AIの活用が進み実装フェーズが自動化されてきた今、エンジニアのリソースは第3・第4象限、つまりユーザビリティやUXの検証、パフォーマンス・セキュリティといった非機能面に重点を移していく必要があります。

特に、AIを搭載した機能が増加する中での「顧客に価値を提供できる状態になっているか」「操作が明示的か（操作によって何が起こるかをユーザーが想像でき、その通りになるか）」というUX・価値提供視点のテストは、今後ますます重要になってくると考えています。

テストの4象限をバランスよく意識することの重要性

先日私のチームが担当しているプロダクトにおいて、WebKit系ブラウザ（PC Safari・iOS Safari・iOS Chrome）でだけ画面がクラッシュし意図しない画面遷移をしてしまうという事象がありました(PC Chromeでは再現しない)。弊社のサービスはPCのChromeでお使いいただいているお客様が多いため、開発メンバーによる検証で、ローカル環境においてもステージング環境においてもPCのChromeでのみ検証をしていた、ということがポストモーテムを経てわかりました。ただ、実際は一部の画面ではむしろタブレットやスマートフォンでの利用の方が多いものがあり、開発フローの中でその前提に立った検証がされておらず検証プロセスを見直すことになりました。

その時に、この事象は第4象限に分類されるテスト観点が不足していることに気づき今後は一部の画面のステージング環境での検証にはスマートフォンの実機を使ったテストを行うフローに変更しました。

システムや作った機能全体をバランスよくテストすることの難しさや重要性を特に感じた一件でした。

リグレッションテストについて

弊社では、E2Eテストの自動化やVRT(Visual Regression Testing)によってリグレッションテストを行っているプロダクトが多いです。

E2E追加基準の整備

E2Eテストは自動化しても実行コストやメンテナンスコストが高いため、追加基準を明確にしておくことが重要だと考えています。基本的にはビジネス的に重要な業務フロー、あるいは過去に重大な障害が発生した箇所を優先的にカバーする方針を取っていますがチーム横断で活用できるE2E用のテストケースの追加基準は整備されていない状況です。 E2Eテストは基本的には第2象限にあたるテストを実行するものが多いと思いますので実行の自動化は推進していきたい一方で TypeScript向けの単体テストフレームワークであるvitestを活用して第1象限にあたるコンポーネントテストの拡充をする取り組みなどと組み合わせて全ての観点をE2Eテストに搭載しないなどの工夫が必要と捉え日々改善を行なっています。

UXリグレッションの観点

機能的なリグレッションテストは整備されやすい一方、UXのリグレッションは見落とされやすいです。機能は動いているが操作感が悪化した、導線がわかりにくくなったといった変化は、ユーザー満足度に直結します。第3・第4象限を意識したチェックリストを作り、UXのリグレッションもカバーできるよう組織全体で施策を講じていく必要があると考えています。

品質とは何か

最後に「品質とは何か」を考えてみたいと思います。

テストの7原則から考える

JSTQB FLでは「テストの7原則」が定義されています。その中でも特に実感が強いのは以下の2点です。

欠陥の偏在

欠陥は特定のモジュールや機能に偏在する傾向があるという原則です。パレートの法則(80:20の法則)と同じですね。この原則をもとに取れる品質改善アクションとしては、過去の障害履歴やポストモーテムから「欠陥が集まりやすい箇所」を把握し、そこへ重点的にテスト投資をするのが有効だと考えています。「テスト投資」にはテスト行為そのものだけではなくコードリファクタリングやプロセスの改善も含めるべきと捉えています。

テストは欠陥がないことを証明できない

「すべてのテストを通過した」は「欠陥がない」の証明にはならない、という原則です。この原則はチームの過信を防ぐために重要で、この意識がチーム・組織に浸透していると、特に新機能リリース後も継続的なモニタリングと探索的テストが必要だという意識につながっていくと考えています。

UXと価値提供は別軸で考える

機能が正しく動くことと、UXが良いこと、ユーザーに価値を提供できることは、それぞれ別の軸で評価する必要があります。これらすべてが品質の構成要素です。

「バグがない = 品質が高い」という誤解を解き、チームがより広い品質観を持てるよう、日頃から対話を重ねることがこのAI時代には特に必要性が高いと考えています。資格取得をきっかけに、私も最近チームメンバーに「UX(体験)をデザインできるエンジニアになろうね」とか「テストの4象限を意識しないと品質向上にはつながらないよ」といったフィードバックをよくするようになったと思います。これも今回の資格取得が良い面に働いた1エピソードかなと思っています。