技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。 しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。 人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。 その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。 今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 「教える」から「引き出す」への転換 QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。 しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。 テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。 そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。 もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。 しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。 そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。 そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。 私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。 図：銀座コーチングスクールのコーチングピラミッドを参考に作図 https://www.ginza-coach.com/overview/feature/curriculum.html （参照日:2026/3/21、最終更新日2026/1/20） 自己基盤 まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。 これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。 これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。 安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。 泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。 コーチングマインド コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。 コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。 今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。 相手の中にある視点や気づきをどのように発見し、どう繋げていくか。 この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。 その「答え」は、実は相手が自覚していない場合があります。 むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。 そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。 コーチングの技術を品質保証に活かす コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。 上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。 一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。 ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。 専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。 第３回 でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。 QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。 「どういう状態になれば、自信を持ってリリースできますか？」 「あなたがステークホルダーであればこの製品に対してどう感じますか？」 「あなたが知っているステークホルダーはどのような人ですか？」 このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。 自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。 専門性の組み合わせ：テスト実行との組み合わせ テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。 テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。 「今、テストを実行していて何に気づきましたか？」 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」 「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。 これが、テスト実行における個人のスキルアップや深い洞察に繋がります。 おわりに QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。 それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。 QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。 例えば、バグが放置されがちな現場があったとします。 ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。 コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。 プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。 そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。 コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。 しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。 この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts .

こんにちは、セーフィーの金原（@masakane55）です。 これまではサイバーセキュリティの担当としてブログを書いていましたが、最近はマネジメントとしての比重も増えてきました。 改めてマネジメントの視点で、サイバーセキュリティの世界でどのようにキャリアを作っていくか、私なりの考え方を整理してみたので、ブログでお伝えしたいと思います。 はじめに 早速ですが、読者のみなさんは、自分のキャリアを「戦略的」に考えたことはありますか？ サイバーセキュリティの世界は技術の進歩が速く、覚えるべきことも膨大です。場当たり的に学習を進めるだけでは、変化の波に飲み込まれてしまうかもしれません。 そもそ

こんにちは、電通総研 XI本部 サイバーセキュリティテクノロジーセンターの櫻井です。 本記事ではISC2 CISSP認定を少し変わった観点から紹介します。 なお、本記事でご紹介する資格の情報は2025年12月時点のものとなります。 ISC2 CISSP認定とは？ セキュリティ資格（認定）の中での立ち位置 筆者の受験体験 CISSP認定の特色 なぜ難しいのか？その１（出題範囲） CISSP認定で必要とされる知識 どこまで知識を深めるべきか？ なぜ難しいのか？その２（認定者の立場） 優先事項はなにか？ 誰目線の判断か？ なぜ難しいのか？その３（試験形式） 筆者の利用したコンテンツ 書籍 Webコンテンツ Udemyコンテンツ 最後に ISC2 CISSP認定とは？ CISSPは正式名称 Certified Information Systems Security Professionalであり、ISC2（アイエスシーツー）が認定しているセキュリティ関係のプロフェッショナル認定です。（※1） 技術的な分野だけでなく、セキュリティ戦略を考案するマネジメント・経営者的な視点も含まれる広範囲の知識を必要とされる認定試験です。 ※1 CISSP®とは セキュリティ資格（認定）の中での立ち位置 CISSP認定の難易度はほぼすべてのサイトにおいて最高レベルの資格群にランクされます。 セキュリティ資格の中でも傾向が異なり、主にマネジメント層向けの認定とされています。（IPA 情報処理安全確保支援士は比較的近しいものだと思います） 問題の傾向としても現れていますが、技術的に完結した正解を問う問題に加えて、現状の組織の立ち位置を踏まえどういった判断が最適かを問う問題が多いです。 筆者の受験体験 筆者は昨年2025年12月にCISSP認定試験を受験し、無事合格することができました。 CISSPは CAT方式 で実施されますが、実際の試験については100問で問題が終了し、延長されることもありませんでした。 学習期間は1か月程度で、確かに難しいが一般的に認知されている難易度レベルまで難しいか？と感じたため本記事の執筆に至っています。 CISSP認定の特色 筆者の考えるCISSP認定はなぜ難しいのか？の特色は以下の3点に分けられると思います。 出題範囲 認定者の立場 試験形式 先に簡潔に述べるとテックブログをご覧の皆さんは、クラウドの設計ややアプリ開発の業務に従事されている方が多いかと思いますが、そういった方々から見るとちょっと変わった試験であるということです。 以降で、3点について紹介したいと思います。 なぜ難しいのか？その１（出題範囲） CISSP認定の出題範囲はプラットフォームや技術領域カットでは表現が難しいです。 この点は他の多くのベンダー資格試験（AWS、Microsoft Azure）やIPAの高度情報処理技術者試験と異なります。 CISSP認定で必要とされる知識 広く認識いただいている代表的な試験で具体例を挙げるとAWS認定の代表 AWS Certified Solutions Architect – Professional (SAP)であればAWS全般の知識がほぼすべて出題範囲ですし、 IPAデータベーススペシャリスト試験 であればデータベースに関わるインフラ、アプリの理解、設計、運用（クエリオペレーション含む）までが出題範囲です。 逆に言うと、SAPであればソフトウェア開発やオンプレミスインフラに関わる範囲はほぼ含まれませんし、IPAデータベーススペシャリスト試験であればソフトウェア開発やネットワークに関わる範囲はほぼ含まれないということです。 では、CISSP認定はどうでしょうか？ 出題範囲とされる CISSP CBKドメイン概要 の8項目を見てみましょう。 １．セキュリティとリスクマネジメント ２．資産のセキュリティ ３．セキュリティアーキテクチャとエンジニアリング ４．通信とネットワークのセキュリティ ５．アイデンティティとアクセスの管理(IAM) ６．セキュリティの評価とテスト ７．セキュリティの運用 ８．ソフトウェア開発セキュリティ ざっと一覧を眺めてみて、どこまでが出題範囲か理解できたでしょうか。（なんとなくセキュリティ全般？でしょうか） 解としては、セキュリティの課題を解決するために必要となる領域はクラウド、オンプレ、インフラ、ソフトウェア問わずすべて出題範囲ということであり、ほぼ同じことが CISSP8ドメインガイドブック（日本語版） の一文として含まれています。 CISSP CBK を理解しようとした時に、最初に驚かれるのはその範囲の広さです。 リスクマネジメントや暗号、ネットワークセキュリティだけではなく、ソフトウェア開発やコンピュータシステムのアーキテクチャなどもその範囲に入っているためです。また、これらは独立した知識として身につければ良いわけではなく、関連性をもって体系的に理解する必要があるということです。 この点に高難易度たる理由があります。範囲が広すぎるためベース知識の学習に時間がかかるため主に未経験者が受験するにはハードルが高いということです。 逆にセキュリティ領域の知見が薄い方でもクラウド、オンプレ、インフラ、ソフトウェアのバックボーンを持ち、かつ実務経験がある方であれば、セキュリティ領域のキャッチアップをするだけで比較的容易に認定を突破することが可能だと思います。（筆者もその類です。） どこまで知識を深めるべきか？ 技術的な正解を問う問題も出題されますので、プロトコルや設計、実装といった細かい内容を理解するのもよいですが、まずは大枠から理解するのが望ましいです。 その為にはCISSP認定のガイドブックを学習するだけでは難しく、自分がなじみがない技術領域の学習を進めることが良いと思います。 例えばクラウド環境から学習される方も多いと思うのでオンプレに関する知識は必須になると思います。IPAネットワークスペシャリスト試験くらいのレベルを満たしてあればこのあたりは基本的に十分です。CISSP対策の問題集を解いている最中に出てきた突飛な用語や技術は個別に調べましょう。 100点を取らないと合格できない試験ではありませんので、俗にいう捨て分野を作るのも選択肢に入りますが、ご自身の財布と相談の上で検討いただくのが良いかと思います。（CISSPの受験費用は1回あたり749＄） なぜ難しいのか？その２（認定者の立場） CISSPの出題形式は一般的な4択ですが、技術的な正解（○○を満たすプロトコルは何？）を問う問題だけでなく、選択肢を絞り切れず完全にマッチした回答が存在しない問題があります。 「優先事項はなにか？」、「誰目線の判断か？」の要素を元に条件に合うような回答から絞るにはどうすればよいかに関して、筆者の考えを紹介します。 優先事項はなにか？ CISSP認定で問われる点の多くはシステムに求められるセキュリティをどのレベルまで高める必要があるかです。 筆者は4要素で分類し、以下のような優先度で考えながら問題を解いていました。 実害、ダメージへの対応（具体例：社会的影響、自組織以外への影響、人命の損失） ＞　規制・制度への対応（具体例：GDPRやCCPAへの対応） ＞　コスト問題への対応（具体例：必要以上の対応コストを避ける、経営コストの最適化） ＞　技術的付加価値の提供（具体例：最新のテクノロジーの適用、過度な利便性の向上） 例を挙げると次のようなものです。 最新のテクノロジーやセキュリティソリューションを追加コストを払って実装することは、既に要件を満たしているのであれば不要である。 システムを提供する地域がGDPRの忘れられる権利への対応が必要の場合、コスト度外視でも対応しなければならない。（この場合はリスク回避という選択も検討） 実装すべきセキュリティレベルは「下限は規制・制度を満たす」、「上限は組織（企業）の経済合理性を考えたうえでマネジメント層、経営者層が判断」というロジックに集約されると思います。（人命や社会的影響への対応は言わずもがな） ITエンジニアリング界隈のコンサルタントや技術者だとより「良い付加価値を提供」という視点になってしまいますが、売る側の視点ではなく買う側の視点に切り替えましょう。この場合は「ヒト、モノ、カネ」ではなく「ヒト、（セイド）、カネ、モノ」なんですね。 誰目線の判断か？ 組織としてどうするかを考えるかの目線、つまり管理者、経営者目線での判断を優先するということです。 CISSP CBKドメイン概要 の記載を引用しますが、統制すべきはシステムであり、そのシステムを運営管理する組織です。 8ドメインの共通的な考え方は組織のガバナンスにあります。ガバナンスとは、組織全体の把握をし、適宜修正を行いながら、組織の目的や目標を効率に達成するためのプロセスです。ベストプラクティスを理解し、それを実践するだけではなく、そのベストプラクティスが自らの組織に合ったものであるかどうかを判断し、もしも適切なものでないとした時に組織に合わせた形に修正(テーラリング)できるようにしなければなりません。 回答の中にも技術的な解決と組織的な解決が入り混じってくることがありますが、この場合は組織的にどのように対応するかを考慮した選択肢が正解となる可能性が高いです。 ここまでの総論としては、 CISSP8ドメインガイドブック（日本語版） や CISSP CBKドメイン概要 をとにかく隅々まで読みましょうとなります。試験に関わる様々なエッセンスが含まれていますので必ず目を通すようにしてください。 なぜ難しいのか？その３（試験形式） ISC2のCAT方式については受験者にかなりのプレッシャーがかかると思います。（筆者体験） 筆者は既にCCSPの認定を取得していますが、CCSP認定受験時はCAT方式ではなかったので、今回初めてのCAT方式受験でした。 既に紹介していますが、CAT方式の要点を挙げると以下2点です。 問題数は最小100問、それ以降は回答状況に応じて最大150問まで問題数が変動する。 一度回答した問題に関して戻って回答、見直しは行うことができない。 筆者は100問解いた段階で開始後90分経過のペースでしたが、150問出題される想定だとどのようなペースで解けばよいのか全くイメージがわきませんでした。 大前提は基本的な考え方や出題範囲の基本的な知識をきちんと理解し、余裕をもって回答するという点に尽きると思います。 筆者の利用したコンテンツ CISSP認定に関する筆者の考えは以上ですが、参考までに筆者が利用したコンテンツ（書籍、Web、Udemy）について簡単に紹介します。 書籍 CISSP認定に関する書籍はガイドブックと問題集がそれぞれ出版されています。 新版 CISSP CBK公式ガイドブック The Official (ISC)2 Guide to the CISSP CBK Reference 日本語版と英語版です。発行日が違うので最新は英語版になります。ガイド及びガイドブックについては、辞書代わりの様な使い方になるのかなと思います。 全部読むのに膨大な時間が必要となりますし、一人で黙々と読んでいるだけでは頭に入るイメージがないです。（日本語Kindle版で1700ページのようです。） CISSP 公式問題集 筆者は公式問題集は利用しました。ただし、事前情報とCCSP認定試験を受験したときの経験で同じ問題は出ないという認識でしたので、参考問題レベルの感覚でなぞった程度です。今保有している知識、観点が正しいかを確認しました。 Webコンテンツ CISSPは企業のWebサイト、学習用Webコンテンツ、個人のブログのそれぞれでかなりの種類が存在します。 筆者が利用したものは主に二つです。 piedpin.com CISSPをターゲットに様々な情報を整理しているサイトです。有料のものと無料のものが存在しますが、ここでは無料のものを対象としています。 ※有料のものは後述するUdemyのものと同様かもしれません。（筆者は未利用） CISSPの出題範囲を対象に図やリンクを用いて整理されています。○○という技術について調べたいとなったら非常に有用だと思います。 晴耕雨読さん CISSP 勉強ノート 筆者がCISSPの存在を知ったWebサイトです。（特定のセキュリティ用語を調べようと思ったら検索に引っ掛かりました） CISSPで出題される技術領域を把握するのにわかりやすく整理されていると思います。 ※要約（まとめノート）であって特定の用語に関してすべての内容を網羅することは難しいと思います。 Udemyコンテンツ 所属している企業でUdemy Bussinessをサブスクライブしている場合、以下のコンテンツが利用できると思います。 【日本語】初心者から学べるCISSP講座 先ほどの「piedpin.com」の作者が公開しているUdemyコンテンツだと思われます。 CISSPのCBKごと、8つのコンテンツに分かれています。 技術的な内容に関してもそれなりの分量がありますが、CISSPにおける回答の考え方について注意して学ぶと最も効率が良いです。 日本語音声付きですので、コンテンツ名の通り、初心者でも抵抗なく利用できると思います。 最後に 読了いただきありがとうございました。 CISSPは今後も注目が集まる認定であり、クラウドだけでなく物理のレイヤを含めた統合的な情報セキュリティの認定として普及していってほしいと思います。 また、新しい取り組みとしてISC2 JapanのWG（ワーキンググループ）で AIセキュリティWG も発足しました。 ISC2としてどのようなポリシー策定や研究結果をアウトプットしていくのか、とりわけ経営判断としてどのようにセキュリティリスクや導入を判断していくかについて筆者も注目していきたいと思います。 (※ My credly ) 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakurai.ryo レビュー： @azeta.takuya （ Shodo で執筆されました ）