こんにちは。QAコンサルタントのテストのひろさんです。 本記事では、テスト進捗自体は順調なものの、現場の役割にミスマッチが生じていたプロジェクトの改善事例を紹介します。当時テストPMだった私が、JSTQB AL-TM v3.0Jシラバスなどの知見を活用し、どのように体制再構築と再発防止に取り組んだのかをお伝えします。 現場の運用に課題を感じている方の気づきや、参考になれば幸いです。 対象プロジェクトの概要 当時のテストプロジェクトの基本情報は以下の通りです。 テストレベル: システムテスト 期間: 2か月 テスト環境: オンサイト プロジェクト計画: システムテストの後に、機能追加に対するシステムテストを計画 チーム構成: PM（私）1名、テストリーダー（TL）1名、ビジネスパートナー（BP）リーダー1名、BPテスター3名 役割分担: BPリーダー: 日々の進捗報告（TL宛）、QA・タスクリストの更新、ハンズオンでのテスト実施。進捗フォーマットやステータス管理手法はトレーニング済み。 BPテスター: テスト実行全般。 TL: 進捗管理、探索的テスト実施、機能追加のテスト設計、QA・タスクリストのチェックや回答。 PM: 複数テストプロジェクトの統括。 立ち上げ時、TLの業務負荷が潜在的なリスクとして見受けられました。しかし、以下の理由からそのような計画で進行することを決定しました。 システムテストの一次報告はBPリーダーが実施すること 機能追加に伴うテスト設計の規模が限定的であること 探索的テストの工数や時期を調整可能であること 具体的には、最初の2週間は進捗管理とQA対応に注力し、3週間目から機能追加のテスト設計および探索的テストを開始するスケジュールを設定しました。 進捗の裏側に生じていた問題 システムテスト開始後、BPリーダーからは予定を前倒しで進めていると報告を受けていました。しかし、詳細を確認していくと以下の状況でした。 テスト進捗は専用のツールで算出するのですが、私が改めて算出し直した進捗数と、実際に報告されている進捗数が異なっていました。また、課題管理表の内容とTLから報告されている内容が一致していなかったり、課題管理表そのものに記載が漏れている等の状況に気づきました。 起きていたことをまとめると以下の状況です。 実際の進捗数と報告された進捗数の不一致 タスク管理表と実際の作業状況のズレ、および記載漏れ TLはBPリーダーへ是正を何度か依頼しましたが改善されず、事実確認などの対応に追われることになります。結果としてTLの工数が圧迫され、予定していた機能追加のテスト設計や探索的テストに入れない状況が発生しました。 この時、現場では以下のような心理的・運用的課題が生じていたのです。 TLの心理: テスト設計も探索テストも進まず、進捗もまとまらないという状況から、自身の評価への懸念が生まれ、PMに相談できず一人で抱え込んでいた。 BPリーダーの心理: 上手く進捗報告ができていないという認識はあるものの、具体的な改善方法が見出せず困惑していた。 双方ともに悩んでいる状態でした。ここで少し私の考えを挟むと、悩むとは問題を認識して試行錯誤しているが出口が見えない状態であり、考えるとはゴールが見えていて、そこに向かっていく状態だと捉えています。当時の現場は、まさに前者の出口が見えない状態に陥っていました。 さらに、この是正がうまくいかない日々が続いたことで、テストリーダーとBPチームの間にも徐々に不穏な空気が流れ始め、コミュニケーションが膠着する二次災害も起き始めていました。 1. 捉え方の転換：個人の問題ではなく構造の問題 この状況に直面した際、私は起きている問題を個人の資質や特性に起因させないことが重要であると考えました。 一見すると報告が不正確なリーダー、抱え込んでしまうTLのスキル問題に見えますが、本質は違います。これは、現場の状況変化に対してプロジェクトの初期枠組みが適合しなくなったことによる構造的な問題であると捉えました。 ここでベースにしたのは、人を責めず、仕組みを改善するという方針です。書籍「スクラム」などにある「プレイヤーを憎むな、ゲームを憎め」という言葉の通り、個人を責めても本質的な解決にはならないと私は考えています。 JSTQB AL-TM v3.0J には、以下のような記述があります。 「テストチームは、プロジェクト開始時に、必要なスキルをすべて持っているとは限らない。完璧な人材がそろうとは限らないが、強力なチームであれば、個人の長所と短所のバランスを取ることができる。」 最初から完璧な人材がそろうチームは難しいことがあるため、個人のせいにせず、仕組みや役割によってバランスを取るという考え方から、システムテストの進行途中で以下のように役割と環境の再配置を行いました。 役割の再定義 BPリーダー: 進捗報告・管理業務から一旦離し、ハンズオンテストの割り当てを80%に増加。タスク管理の不備がスキルの問題なのか業務過多によるものなのかを切り分けるとともに、テスト実行の推進に集中するようにしました。残りの20%はPMやメンバーとのコミュニケーションに充てる割合に変更しました。 テストリーダー（TL）: テスト管理やBPチームとのコミュニケーションをタスクから切り離し、本来のミッションである探索的テストの実施と機能追加のテスト設計」に専念できる工数を確保しました。 PM（私）: このシステムテストの進捗管理を巻き取りました。BPリーダーとのコミュニケーションは、時間を固定して1日2回（各10分）の状況確認を実施する運用へ変更しました。 物理環境の変更（座席位置の調整） また、TLとBPチームの間で関係性の悪化（コミュニケーションの膠着）が見られたため、オフィスの座席配置を変更して物理的な距離を置きました。これにより、TLによるBPチームへの細かな確認や介入を構造的に抑制し、TLもBPチームも自分たちのタスクに集中できる環境を整備しました。 ガバナンスの再構築 正確な情報を把握するため、これまでチャットベースで済ませていた報告を「対面での同期」に切り替えました。これは指示命令を強化するためではなく、事実（ファクト）と報告の同期を目的としたものです。情報の透明性を確保することで、プロジェクトの正確な現状がステークホルダーやチーム全体に共有される仕組みへと変更しました。 2. 心理的安全性と規律の両立：1on1における対話 役割変更と並行して、TLとの1on1を実施しました。目的は、心理的安全性を確保した上で役割変更の背景を納得してもらい、機能追加テスト設計、探索的テストに集中してもらうことです。1on1では、特に以下の3つの軸を意識して対話を行いました。 評価の切り分け（安心感の醸成）: 今回の介入はあくまで、体制上の判断による役割の変更であり、TL個人の評価を下げるものではないことを明言しました。テスト期間中であり、最終的な品質やゴールに対する結果はまだ出ていないためです。 ティーチングの選択: 通常であれば自律的な成長を促すコーチングを採用しますが、今回は納期が迫る緊急時であったため、私のやり方を直接伝えるティーチングへと戦略的にシフトしました。山本五十六の「やってみせ、言って聞かせ、させてみせ、ほめてやらねば、人は育たず」の方針のもと、並走しながらサポートしました。 コミュニケーションの原則（アサーション）: 強い言葉で行動を縛るのではなく、仕組みで解決を図る姿勢（アサーションの原則）を大切にしたい旨をTLに伝え、目線を合わせました。 3. 再発防止：根本原因の特定と仕組みのアップデート プロジェクト完了後、次フェーズである機能追加テストに向けて、今回の問題の根本原因の特定と仕組みのアップデートを行いました。 根本原因：正しいデータが報告に繋がらない集計・出力構造 そもそも、なぜ進捗報告と実態の乖離が起きていたのか。仕組みとしてExcel上で予定と実績が10%以上乖離するとセルが赤字になるというアラートのルール自体は存在しており、Excel内の関数やシステム側の元データも正常でした。 しかし、最終的に算出されたデータを、報告用にアウトプットする（テキスト化する）段階で人為的なミスが発生していたことが根本原因でした。 当時の集計・報告フローは以下の通りです。 テスト管理システムから正しい実績データをCSVでダウンロードする 集計用のExcelへコピー＆ペーストする（Excel上の関数・アラート自体は正常に機能） Excelで算出された数値を、手作業で報告用のテキストに書き起こす（ここで転記ミスが発生） 最終的な報告テキストを作成するまでに手作業のプロセスが多く、結果としてExcel上ではアラート（赤字）が出ていても、報告段階でそれが消えてしまうという、人為的ミスを誘発しやすい構造になっていました。BPリーダー個人を責めるのではなく、ミスが起きる構造を変える必要がありました。 対策：集計・出力の自動化 手作業によるリスクを排除するため、CSVダウンロード後のデータ集約から、Excelでの集計、そして最終的な「報告用テキストの出力」までをワンクリックで行うVBAマクロを導入しました。 これにより、データの信頼性を担保した上で、PMやステークホルダーが日々のモニタリングで客観的な事実（定量データ）をそのまま受け取り、早期に異常（アラート）を検知できる仕組みへとアップデートしました。 4. 再発防止の効果：定量的・定性的アプローチ アップデートした仕組みの効果を現場の感覚で終わらせないために、JSTQB AL-TM v3.0Jのシラバスに記されている以下の格言を指針としました。 「マネジメントには『測定できるものは達成できる』という格言がある。同様に、測定されないものは、無視されやすいので、達成されることはないだろう。したがって、テストを含め、どのような取り組みに対しても、適切なメトリクスを確立することが重要である。」 この考えに基づき、定量的なメトリクス評価と定性的なアプローチ（心理的安全性の確保）の両面から効果を測定しました。 ① 定量的なアプローチ プロジェクトメトリクス: テスト実行数、実行率、ステータス（OK/NG/Block）の推移。自動集計化により、10%の乖離アラートが正しく機能するようになり、進捗の透明性が確保された。 プロダクトメトリクス: BPリーダーのテスト比率を上げたことによる進捗の加速、TLの探索的テストによる、欠陥検出数と修正数の推移。想定していた計画値と実績を比較することで、品質リスクの低減に繋がった。 プロセスメトリクス: 集計作業工数そのものが削減されたことによる相乗効果で、チーム全体の生産性が向上した。 ② 定性的なアプローチ（1on1による内面サポート） 一方で、数字には表すことが出来ないメンバーの悩みや心理的状況は、定性的にしか捉えることができません。ここでは1on1などの直接的な対話によるサポートが不可欠です。 ちなみに、JSTQB AL-TM v3.0Jのシラバスには「方法論的、社会的、個人の能力はテストに特化したものではないため、専門的能力の開発に重点を置く」といった旨も述べられています。つまり、1on1やアサーティブなコミュニケーションといったスキルもまた、マネジメント知識として意識的な習得やトレーニングが必要な領域です。トレーニングや考え方などについては「ヤフーの1on1」「成長マインドセット」などの書籍を参考にしています。 1on1を継続した結果、TLが問題を一人で抱え込まずに早めのアラートを出せる関係性が構築され、BPリーダーも何に困っているかを素直に共有してくれる環境へと変化しました。 おわりに 今回の取り組みを通じて、データの信頼性とアラートの定量化、心理的安全性の確保によって、仕事の側面と人の側面をマネジメントすることの重要さを実感しました。 人が間違えるのは、仕組みに問題があると捉えて、変化の激しいテストプロジェクトを計画したゴールへ導くことが、マネジメントの本質ではないでしょうか。 この記事が、現場の体制構築や運用に悩むエンジニア・マネージャーの皆さまにとって、少しでも新しい視点や気づきのきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。 （参考文献） JSTQB JSTQB-Syllabus.Advanced_TM_VersionV3.0.J02 スクラム 仕事が4倍速くなる世界標準のチーム戦術（ジェフサザーランド 著、石垣 賀子 訳） ヤフーの1on1 部下を成長させるコミュニケーションの技法（本間 浩輔 著） 成長マインドセット 心のブレーキの外し方（吉田 行宏 著） The post 心理的安全性とガバナンスを両立させるテストチームの改善事例 first appeared on Sqripts .

今回から新連載「テスト会社に勤めるって実際どうなの？～事業会社QA・ツールベンダー”も”経験して見えたこと～」をスタートします。 私はこれまで、いわゆる「テスト会社」と「事業会社」、そして現在の「テスト自動化ツールの会社」という、大きく3種類の会社に勤めてきました。その間はずっと、テストエンジニアやQAエンジニアとして、ソフトウェアテストや品質に関わる業務に従事しています。 本連載では、この中でもとくに「テスト会社」で働くことについて、3つの業態を経験してきた私自身の視点から語ってみたいと思います。 テスト会社に勤めていたころも含め、「テスト会社ってこうだよね」という話を、いろいろなところでよく耳にしました。しかしその中には、合っている部分と、そうではない部分の両方があります。テスト会社に勤めたからこそわかることもあれば、逆にテスト会社に勤めている方（特に若手）が陥りやすい思考もあるな、と今振り返ってみるとわかることもあります。 本連載の話が唯一の正解、というわけではありませんが、いろいろな業態を経験したQAエンジニアの視点として実際に感じたことを共有できればと思います。 これまでのキャリア これからの話の前提として、まずは私自身の経歴を改めてご紹介しておきます。 2012年から10年ほど、テスト会社に勤めていました。この間はいくつか客先常駐のプロジェクトと社内での勤務も経験し、 テストの実行や設計 テスト自動化 現場リーダーとしてのメンバーやパートナーの管理・マネジメント 新規提案や営業同行 中途採用の募集・面接、エンジニア評価 組織立ち上げ など、「テスト会社らしい」業務を含めていろいろな経験をさせてもらいました。 2023年からは3年弱、事業会社でQAエンジニアとして働いていました。部署では1人目のQA（社内の別プロダクトにはすでにQAがいました）として、QA組織の立ち上げを目指していました。会社の事情もあり、結果的に大きな体制を作るところまでは至りませんでしたが、QAチームを立ち上げて始動するところまでを行いました。この間は、E2Eテスト自動化の推進や、開発者に向けたQA・テストのイネイブリングなど、特定のチームやプロダクトに入り込んで実務を担うのではなく、組織横断的な活動が中心でした。 そして2025年から本記事執筆時点までの1年強は、テスト自動化ツールを提供している会社に勤めています。ここでは自分自身がプロダクトの品質保証を行うのではなく、テスト自動化に関連する技術検証や、普及推進活動が中心となっています。 それぞれの業態で同じくらいの期間在籍していればほんとうに公平な意見が言えるかもしれませんが、期間としてはテスト会社が特に長いです。この前提で読んでいただければと思います。 また、私がテスト会社から事業会社に移った直後のタイミングで生成AIが急速に普及・拡大したため、その後のテスト会社内部の変化については直接経験をしたわけではない、という点もご了承ください。 テスト会社の中で言われること ここからは、本連載全体を通じて考えていく「テスト会社の内外で言われていること」をいくつかみてみましょう。具体的な話や「実際どうなの？」は次回以降の記事で主に語るとして、本記事では「こんなこと言われているよね」という共通認識をまずは持っていきたいと思います。 「やりたいことができない」という声 新卒でテスト会社に入ってしばらくすると、「テスト会社ではやりたいことができない」「事業会社のQAのほうがいいのでは」といった声を耳にするようになりました。実は私自身も、若い頃は同じように感じていました。上司、しかも直属よりも上の上司に飲みに連れて行ってもらって愚痴を聞いてもらっていたこともあります。 この不満の要因のひとつとして、個人と会社の間にある利害のズレがあるように思います。個人、特にやる気があってキャリアを考えている若手には、市場で求められるスキルが身につく業務に関わりたいという気持ちがあります。一方で会社としては、単価の高い案件や、待機期間なしで入れる案件にエンジニアをアサインしたいという事情があります。当然ながら、所属するエンジニア全員の希望を全て叶えるわけにもいきません。この、希望する案件に関われる・関われないという点で、個人の側に「やりたいことができない」という不満がつのっていく場合があります。 たとえば、かつて「テスト自動化はこれから必須スキルになる」と言われていた時期がありました。現場で自動化を提案しても、顧客に求められていなかったり、契約のスコープ外だったりすると、機会そのものが得られません。また自社の都合で自動化に関わる案件そのものにアサインしてもらえないなど、不満を抱えてしまうパターンもあります。 「テストの仕事しかできなくなる」という不安 もうひとつ、テスト会社に勤めていたころによく耳にしたのが、「このままではテストの仕事しかできなくなるのでは」という不安です。特に新卒でテスト会社に入ると、開発の経験が無い状態です。2、3年のうちはよいかもしれませんが、5年10年と勤めた先で「やっぱり開発者になろう！」というのは難しそうだ、将来の選択肢が狭まってしまう、と考えるわけです。 このあたりは、ここ10年くらいでずいぶん状況が変化してきた部分でもあります。たとえば待遇面。かつてはテストの仕事よりも開発の仕事のほうが給料が良いと思われていたので、「いつまでもテストをしていたくない」とキャリアチェンジを狙う方もいました。しかし昨今の採用市場ではエンジニア全体として待遇がよくなっており、QAエンジニアの募集を見ても、その待遇は開発者と同等のものがたくさん見られるようになりました。 また、生成AIの登場も大きなポイントです。職種間の隔たりが少なくなり、軽微なバグであればQAエンジニアが自分たちで直してしまう、という組織もあるようです。そのため、「テストの仕事しかできなくなる」という不安は、以前に比べれば軽減されているのではないでしょうか。 一方で、開発者の中での品質意識やテストの技術も高まってきており、テストだけに特化したスキルセットでは今後の市場価値を保ちにくくなるかもしれない、という声も聞かれるようになってきました。 「事業会社に行きたい」という声 これらの不安や不満によって、テスト会社の若手が事業会社に行きたがる傾向が 当時 はあったように思います。テスト会社から事業会社に移ることへの”憧れ”のようなものの存在を感じることもありました。ところが今では、事業会社で活躍していたQAが、むしろテスト会社に移ってくるという動きも出てきています。 不安の種類は変わってきているものの、何らかの形でモヤモヤが残り続けている、という点は当時とあまり変わっていないのかもしれません。今回の連載で思い浮かべている読者層、つまり今の環境にモヤモヤを抱えている若手のテスト・QAエンジニアの感覚そのものは、当時とさほど変わっていないのではないか、というのが私の仮説です。 テスト会社の外から言われること 「主体性がない」という決めつけ 逆に、テスト会社の外からもステレオタイプを感じることがあります。代表的なのが、「テスト会社のエンジニアは主体性がない」といった声です。 先ほどの「やりたいことができない」という内部の声と、一見矛盾しているように見えるかもしれません。しかし、これには構造的な背景があるように思います。 それは、「テスト会社のテストエンジニア＝作業員」というイメージです。おそらく、昔の実態に由来する部分もあるのでしょう。上位のテストエンジニアが設計したテストケースを、手順書に沿って実行するだけの存在だと見なされると、それは受動的な存在、つまり主体性がない存在、という印象につながりやすくなります。 加えて、ビジネス構造上の事情もあります。テスト会社のエンジニアは客先の社員ではないため、どうしても「社外の人間」として扱われる場面が出てきます。これはテスト会社に限った話ではなく、派遣社員や業務委託など、外部人材全般に共通する構造的な問題ではないかと感じています。 私個人が経験してきた範囲では、客先の正社員の方は「あの人は他社から来ている人だから」といった線引をせずに接してくれる人がほとんどで、その点で疎外感を感じることはありませんでした。 しかし、例えば情報ガバナンスの観点からアクセスできる情報に制限があったり、業務内容に一部制限があったりと、どうしても正社員に依頼をしたり、指示を仰ぐ必要がある場面もあります。実際、テスト会社から事業会社への転職を考えている方に話を聞くと、「ユーザーに価値を届けるために何をすべきかを考えるにあたって、必要な材料が集めにくい、アクションを起こしにくい」という意見も聞きます。 加えて、当然ながら企業にとっては自社の社員のほうが大事なので、育成や業務の機会という点では正社員が優先されます。それでいて、テスト会社の社員が常駐先の若手の教育を手伝う場面を見ることもあり、優先度の置き方と、実際に頼られる場面とが必ずしも一致しないこともあるようです。 つまり、発注する側にとって都合のよい、相反する考え方が共存してしまっているのではないでしょうか。一方では、内部の人間と同じような主体性や積極的なコミットメントを求めます。もう一方では、外部の人間だからという理由で、情報や権限は渡さず、正社員の活躍を優先して、派遣や業務委託のメンバーは後回しにする。この2つが、同時に成り立ってしまっているように思います。 契約等の都合でどうしても制限がかかる部分のせいで、個々のエンジニアは行動を起こしたいにもかかわらず「主体性がない」と見えてしまう 場合もある のではないか、という説です。 まとめと、今後の連載について ここまで、テスト会社の内外でよく言われていることを振り返ってきました。「やりたいことができない」「テストの仕事しかできなくなるのでは」という内部の声は、いずれも個人と会社の間にあるアサインの利害のズレに起因するものでした。もっとも後者については、待遇の変化や生成AIの影響で、以前より和らいできている面もあります。こうした不安から、当時は事業会社への”憧れ”が生まれていましたが、今はむしろ逆方向の動きも見られます。 一方、「主体性がない」という外部からの決めつけは、ビジネス構造そのものに根ざした、一見矛盾するような要求の共存から生まれているように見えます。 いずれも、単純な決めつけで片付けられるものではなく、その背景にある構造まで見ていく必要があるのではないかと思います。 そこでこの先の連載では、今回触れたテーマをより掘り下げていきます。 次回は、「事業会社のQAに”自由”はあるのか。テスト会社は”不自由”なのか」について考えます。結論を少し先に言うと、自由の対象が違うだけで、どちらを選ぶかという話なのではないか、と考えています。 その後は、テスト会社に勤めることで得られるもの、たとえば教育機会や経験の幅、コミュニティとの関わりなどについて取り上げます。公平性も意識して、事業会社QAならではの良さについても1回を使って書く予定です。そして最終回では、自分の志向性やキャリアの段階によってどちらがよりマッチするのか、について私見を述べて終わりたいと思います。 連載全体を通じて、十数年前の若い頃の、狭い視野しか見えておらず不安やモヤモヤを抱えている自分に対して、視野を広げてあげられるような、そんな話をするつもりです。結果としてそれがどなたかの役に立てば嬉しいです。 The post 【第1回】”テスト会社”の内外で言われていること first appeared on Sqripts .

目次 はじめに 注意事項 対象者 検証環境 ポイント1 : なぜESRallyではなくJMeterなのか？（Kibana経由の負荷計測の必要性） ポイント2 : ハマりポイント最大要素！ kbn-xsrf: true ヘッダーの必須設定 設定すべき主要ヘッダー一覧 ポイント3 : キャッシュの罠を回避せよ！クエリ日時の動的置換（JMeter関数） ユーザーパラメータの設定例（過去15分間のデータ取得例） .jmx ファイル内のテキスト置換処理 ポイント4 : 安全かつ確実な認証設計（API KeyとCSV Data Set Configの活用） API Keyの発行と管理の注意点 CSV Data Set Config による値の注入 ポイント5 : 本番さながらの負荷をかけるための実行手順 5.1. リスナーの追加とGUIでの事前確認（ドライラン） 5.2. 本番試験はCLIモード（非GUIモード）で実行 5.3. システム側のリソースモニタリングとチューニング 5.4. 【補足】ロードバランサー（ALB等）配下での注意点 まとめ はじめに 大規模なログ分析基盤や可視化プラットフォームの運用において、「ダッシュボードへのアクセスが集中した際、十分なパフォーマンスを維持できるか」という課題は非常に重要です。 Elasticsearch 単体への負荷テストであれば ESRally 1 などの専用ツールが適していますが、実際のユーザーがWebブラウザを介して体験する「Kibanaダッシュボードの表示・検索処理」のパフォーマンスをこれだけで測定することは困難です。 Kibana は Node.js 上で動作するWebアプリケーションです。複数ユーザーによる同時アクセスやダッシュボード表示の集中に伴うボトルネックを特定するためには、Apache JMeter などのツールを用いて、HTTP(S)経由で実際の利用状況を模倣した負荷試験を行うことが不可欠となります。 しかし、Kibana に対して JMeter で作成したシナリオをそのまま実行しようとすると、Kibana 特有のセキュリティ仕様やキャッシュメカニズムによってテストが正常に動作しないケースが多発します。 本記事では、Kibana の負荷試験でハマりがちなポイントを回避し、正確で効果的なテストを実施するための5つの実践ノウハウを解説します。 注意事項 Apache JMeter は使い方によっては外部システムに過度な負荷を与える可能性があるため、本記事では JMeter の基本操作の説明は割愛し、Kibana 特有のポイント・ハマりどころの解説に絞って記述しています。 対象者 Apache JMeter の基本的な使用方法を理解している技術者 Kibana の基本的な操作方法を理解している技術者 検証環境 Apache JMeter v5.6.3 Kibana v9.5.5 ポイント1 : なぜESRallyではなくJMeterなのか？（Kibana経由の負荷計測の必要性） Elasticsearch 単体の性能を評価する目的であれば、専用ツールである ESRally を使用して直接接続テストを行うのが最適です。一方で、ESRally では「ユーザーが Kibana 画面を開き、ダッシュボードを表示する」といったフロントエンド経由の多重アクセスを再現することは困難です。 Kibanaを含めたシステム全体を評価するためには、以下のアーキテクチャの流れに沿った負荷テストを行う必要があります。 [ JMeter ] -(HTTP/HTTPS)-> [ Kibana (Node.js) ] -(REST)-> [ Elasticsearch Cluster ] Kibana はユーザー操作を受けると、Node.js アプリケーションとしてリクエストを処理し、バックエンドのElasticsearch へ REST API を発行します。フロントエンドである Kibana 層を含めて HTTP(S) 経由でテストを実施することで、Node.js 層での処理滞留や Webアプリケーション特有のレスポンス遅延を含めた、真のユーザー体験に近いパフォーマンス計測が可能となります。 ポイント2 : ハマりポイント最大要素！ kbn-xsrf: true ヘッダーの必須設定 JMeter のプロキシ機能（HTTP(S) Test Script Recorder）を使ってブラウザ操作を録画し、そのままシナリオを実行しても、Kibana へのリクエストはすべて拒否されてしまいます。これは、Kibana が持つ CSRF （クロスサイトリクエストフォージェリ）対策のセキュリティチェックに引っかかるためです。 この問題を回避するには、スレッドグループに 「HTTP ヘッダーマネージャ」 （追加 > 設定エレメント > HTTP ヘッダーマネージャ）を追加し、リクエストに必須のヘッダーを明示的に付与する必要があります。 設定すべき主要ヘッダー一覧 ヘッダー名 設定値 説明 Content-Type application/json リクエストボディの形式 kbn-xsrf true 【必須】 CSRF対策チェックの回避（※1） Authorization ApiKey ${API_KEY} API Keyによるヘッダー認証（変数は外部ファイルから読み込み） ※1 注意点: kbn-xsrf: true ヘッダーの付与を忘れると、KibanaはすべてのAPIリクエストに対して 400 Bad Request や 403 Forbidden を返し、テストは即座に失敗します。 また、セッション維持やCookie管理を自動化するために 「HTTP クッキーマネージャ」 （追加 > 設定エレメント > HTTP クッキーマネージャ）も併せてスレッドグループに追加しておきます。 ポイント3 : キャッシュの罠を回避せよ！クエリ日時の動的置換（JMeter関数） 録画によって生成されたシナリオ（ .jmx ファイル）内には、検索条件としての「開始日時（ gte / start ）」や「終了日時（ lte / end ）」が固定の文字列やタイムスタンプとして記録されています。 この固定値のまま負荷テストを繰り返し実行すると、Kibana や Elasticsearch 側でキャッシュが効いてしまい、常に速いレスポンスが返される「偽の高速化現象」が発生します。リアルな負荷を再現するためには、 「ユーザーパラメータ」 前処理エレメント（追加 > 前処理 > ユーザーパラメータ）とJMeter関数を活用し、リクエストを投げるタイミングに応じた動的なタイムレンジを設定する必要があります。 ユーザーパラメータの設定例（過去15分間のデータ取得例） スレッドグループにユーザーパラメータを追加し、以下の4つの変数を定義します。（過去15分間を指定する場合、ミリ秒計算は -1000ミリ秒 * 60秒 * 15分 = -900000 となります） 変数名 変数の値（JMeter関数） START_TIME_LONG ${__longSum(${__time(,)},-900000,)} END_TIME_LONG ${__time(,)} START_TIME ${__dateTimeConvert(${__longSum(${__time(,)},-900000,)},,yyyy-MM-dd'T'HH:mm:ss.SSS,)}+09:00 END_TIME ${__time(yyyy-MM-dd'T'HH:mm:ss.SSS,)}+09:00 Kibana のリクエスト内では、ミリ秒単位のエポックタイム数値表記とフォーマットされた ISO日時文字列の両方が使用されるため、上記のように両パターンの変数を用意しておきます。 .jmx ファイル内のテキスト置換処理 保存した .jmx ファイルをテキストエディタで開き、リクエストボディ内の固定日時を変数へ置換します。 ここで注意が必要なのは、JMeterの .jmx ファイルはXML形式で保存されるため、内部のJSONリクエストボディに含まれるダブルクォーテーション（ " ）が " にXMLエスケープされている点です。エディタでの検索・置換時は以下のようにエスケープ文字を含めた形で置換を行います。 置換前（録画された固定値の例）: "gte":"2026-10-27T06:01:02.345Z" "start":1792743725126, "lte":"2026-10-27T06:16:02.345Z" "end":1792743727052, 置換後（動的変数への置換）: "gte":"${START_TIME}" "start":${START_TIME_LONG}, "lte":"${END_TIME}" "end":${END_TIME_LONG}, リクエストごとに検索タイムレンジを現在時刻ベースへ動的にシフトさせることで、キャッシュの有効化を防ぎ、バックエンドの検索エンジンへ正しく負荷をかけることが可能になります。 ポイント4 : 安全かつ確実な認証設計（API KeyとCSV Data Set Configの活用） 負荷試験で認証を通す際は、画面上のログイン操作をシナリオに含めるのではなく、 API Keyを用いたヘッダー認証 に統一するのが安全かつ効率的です。録画シナリオ内にログイン画面へのアクセスリクエストが含まれている場合は、無効化または削除しておきます。 API Keyの発行と管理の注意点 Kibana上でテスト用の API Key を発行する際は、以下のセキュリティ運用を徹底します。 有効期限の制限: API Key の有効期限は無期限にせず、負荷テストが終了するまでの必要最小限の期間に設定します。 権限の最小化: テスト対象インデックスへの参照権限など、必要最低限のロールのみを付与します。 CSV Data Set Config による値の注入 発行したAPI Key（Base64文字列）を記述した api_key.csv ファイルを作成します。 API_KEY 0123456789abcdef...== JMeter のスレッドグループに「CSV Data Set Config」（追加 > 設定エレメント > CSV Data Set Config）を追加し、以下のように設定して各スレッドに安全に ${API_KEY} 変数を渡します。 項目名 設定値 Filename api_key.csv Variable Names API_KEY Ignore first line True Recycle on EOF ? True Stop thread on EOF ? False Sharing mode All threads ポイント5 : 本番さながらの負荷をかけるための実行手順 シナリオ構築完了後、本番テストを実施する際の手順と運用の注意点は以下の通りです。 5.1. リスナーの追加とGUIでの事前確認（ドライラン） 本番実行前に、まずはGUIモードでテスト結果を確認するためのリスナーをスレッドグループに追加します。 結果をツリーで表示: 追加 > リスナー > 結果をツリーで表示（出力例: results.csv ） 統計レポート: 追加 > リスナー > 統計レポート（出力例: summary.csv ） リスナー追加後、スレッド数を1に設定してテストを1回実行（ドライラン）し、以下を確認します。 リクエストボディの検証: 「結果をツリーで表示」の Request タブを開き、 gte や lte が現在時刻ベースの動的な日時に正しく置換されているか確認します。 エラー率の確認: 「統計レポート」の Error % が 0.00% であることを確認します。 5.2. 本番試験はCLIモード（非GUIモード）で実行 事前確認が取れたら、スレッド数（同時接続数）や Ramp-Up 期間を目的の負荷レベルに設定して .jmx ファイルを保存します。 本番負荷試験はJMeter本体のリソース消費を最小化するため、 必ずCLIモードで実行し、HTMLレポートを出力 します。 jmeter -n -t sample.jmx -l result_jtl.csv -e -o ./result_output -j jmeter_batch.log 実行完了後、 ./result_output/index.html をブラウザで開き、レスポンスタイムのパーセンタイル推移やスループット（TPS）を分析します。 5.3. システム側のリソースモニタリングとチューニング テスト実行中は、Kibana および Elasticsearch ノードの CPU 使用率、メモリ使用量、Node.js / JVM のヒープステータスを継続的に計測します。要求水準を満たさない場合は、Kibana の Node.js ヒープサイズ調整やElasticsearch のインデックスクエリ最適化などのチューニングを実施します。 5.4. 【補足】ロードバランサー（ALB等）配下での注意点 AWS ALB などのロードバランサー配下に置かれた Kibana に対して高負荷をかける場合、JMeter（Java）側でDNS解決結果がキャッシュされ、特定の Kibana ノードにアクセスが偏る現象が発生することがあります。 マルチノード環境で均等に負荷を分散させたい場合は、JMeter のスレッドグループに 「DNS Cache Manager」 を追加し、 Clear cache each iteration を有効化するなどの対策を検討してください（ただし、この記事では未検証です）。 まとめ Kibana の適切な負荷試験を実施するための要点は以下の5点に集約されます。 Apache JMeter の利用: ESRally ではなく、Apache JMeter を利用する。 kbn-xsrf: true ヘッダーを付与: CSRF対策チェックを回避し、 400 / 403 エラーを防ぐ。 API Key認証の活用: CSV Data Set Config を用いて、不要なログイン処理を排除し最小権限のヘッダー認証に統一する。 タイムレンジの動的化: JMeter 関数で gte / lte 等をリクエストごとに動的置換（ .jmx 内の " エスケープに注意）し、キャッシュによる偽の高速化を排除する。 CLIモードでの実行とモニタリング: GUIを避けてCLIで実行し、HTMLレポート解析とインフラ側のリソースモニタリングを並行して行う。 事前準備と特有の仕様への対策をしっかりと設計しておくことで、本番稼働前に Kibana を含めたシステム全体のボトルネックを正確に洗い出し、適切なチューニングを施すことが可能になります。 Elasticsearch Rally ベンチマーク入門: バージョン 8.x と 9.x の性能比較 ↩︎ The post Apache JMeter による Kibana への負荷試験を行うためのポイント first appeared on Elastic Portal .