1人目QAとしての立ち回り、第3回となる今回は、QAエンジニアや品質保証のことを開発組織に知ってもらうための取り組みについてご紹介します。 前回の記事 では、1人目のQAは開発組織に対して品質文化を浸透させる役割を求められる、と書きました。しかし、「文化の浸透」という大きなことを、一足飛びに実現するのは困難です。 「品質のことを考えよう」「改善活動を行おう」と組織全体に訴えかける前に、まずは品質やQAエンジニアについて、知ってもらうところから始めることが大切です。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ QAエンジニアという“異分子” 1人目QAとして開発組織に加わった場合、周りの開発者からみると、QAエンジニアは「謎の存在」あるいは「異分子」と表現してもいいかもしれません。 いったい何をする存在なのか、居ることによって自分たちにどのようなメリットがあるのか、などが不明確な状態です。 もし中途として採用されたのであれば、組織のトップや一部のマネージャーなどは、QAエンジニアの存在意義や行動についてなんらかの期待をもっているでしょう。あるいは、社内でのジョブチェンジとしてQAエンジニアになった場合も、なんらかのミッションを負っているはずです。つまり、1人目QA本人は、すくなくともぼんやりとは「何をする人なのか」をわかっているはずです。 しかし、周囲はそうではありません。もしかしたら「前職でQAエンジニアにあまり良い印象がなかったんだよね」とか、「テストしてくれる人でしょ？」なんてイメージを持っている可能性すらあります。 「相手はわかってくれているはずだ」という思い込みがキケンなのは、QAエンジニアに限らずお仕事の基本です。そのため、1人目QAは自分自身が「謎の存在である」という気持ちで、周りに認知されるよう動くことが必要です。 開発組織に認知してもらうには 周囲に認知してもらうために1人目QAができることはいろいろとあります。ここでは、私自身が1人目QAとして行ったことや、周囲のQAと情報交換をする中で複数人が実践していた方法について説明します。 なお、以下の方法はいずれか1つを行えばよいというものではありません。複数のチャネルで多方面から発信することで、より効果を発揮します。 ミーティングへの参加など、直接会話する もっとも強力な方法は、直接話をすることです。これは皆さんの実感とも合っているのではないでしょうか。 会ったことがある、話をしたことがある、というのは相手との関係性を良くするうえでとても重要です。とくに1人目のQAとしてさまざまな品質向上活動をしていく場合、開発者に工数を割いてもらったり、いままでのやり方を変えてもらったりと、拒否反応を示される可能性のあるタイミングが多々あります。そうしたときに快く協力してもらえるか、しぶしぶ協力してもらえるか、あるいは協力してもらえないのか・・・この結果は会話の量に大きく左右されます。 会話の機会を持つ方法として私が実践したのが、Joinしてすぐに行った「全開発部ヒアリング」です。これはその名前の通り、すべての開発部に対して「今どのような流れで開発していますか？」「どのようなテストをしていますか？」「品質について困っていたりしますか？」など、いろいろな内容を直接会議をして聞くというものです。また会議の冒頭10分程度では自己紹介やQAエンジニアの位置づけ、今後どう貢献したいかなどを説明し、ヒアリングとあわせて相互理解の機会として活用しました。 私は横断部門の1人目QAとして仕事をしているため、上記の方法を取りました。もし個別の開発部における1人目QAとしてJoinした場合や、会社規模がそれほど大きくなく開発組織が1つという場合は、「全員と1on1ミーティングをする」という手段も検討できるでしょう。部単位での代表者からのヒアリングと比べて、より深い話ができ、つながりも強化できるでしょう。 その他、上司や同僚のスケジュールを常にチェックしておき、呼ばれていない会議でも自分から突撃する、という強者QAも居ます。その方はオープンスペースから「テストが～」等関係ありそうな単語が漏れ聞こえてきたときにも話に入っていったそうです。 勉強会や輪読会の開催 ミーティングへの参加に近いものとして、QAエンジニアとして勉強会や輪読会を開催する、という方法もあります。 一般で行われているのは、JSTQBのシラバスを輪読したり、とくに若手の開発者に対して「品質とは？」や「テストとは？」といった内容を伝える勉強会などです。私自身も入社直後から継続的に勉強会を開いています。 勉強会や輪読会というと、知識を伝えるというイメージを持たれるかもしれません。確かに、ソフトウェアテストやQAに関しては開発者よりもQAエンジニアのほうが詳しいことが多いでしょうし、QAとしての視点で伝えられることはたくさんあります。しかし、私は勉強会や輪読会はただの勉強の場ではなく、むしろ生の情報や思いを直接やりとりするコミュニケーションの場だと捉えています。 生の情報、というのはつまり、現場で実際に開発業務を行っている方の視点での情報です。「今こんなことで困っていて」や「本にはこう書いてあるけど、実際にはそううまくもいかなくて・・・」など、先に挙げたヒアリングよりもカジュアルな形で本音が聞ける可能性があります。勉強会で伝えている内容や輪読会で読んでいる本の内容はあくまでもトリガーであり、より価値があるのはそこから出てくる開発者の本音や声、だと考えています。 また、開催している側から参加者に対しては、思いや熱量を伝える機会でもあります。1人目のQAとして、組織をこう変えていきたい。こんなことをやっていきたい。そのような思いというのは、1回や2回全体周知をしたところで伝わりません。むしろ個別に、頻繁に、何度も伝えてやっと浸透していくものです。そのため、品質文化を浸透させるという大目標には、こうした勉強会や輪読会の場を活用することも有効です。 少し大きな話になりましたが、純粋に接触機会が増えるため、QAエンジニアや品質に関する認知、という点でももちろん有効です。 ちなみに私は勉強会・輪読会の他に「ライブテスティング会」も開催しています。これは、開発チームに提供してもらった実際のアプリケーションを、ビデオ会議で画面共有しながら探索的テストをするというものです。テストする側も、される側も、かなり緊張するイベントなのですが、QAエンジニアやテストエンジニアが何を考えてどうテストしているのかを生で見てもらう良い機会になっています。こちらも認知という意味ではとてもオススメです。 品質やテストに関するナレッジベースをつくり、育てる 上記の2つは、同期的に何かを伝えて認知してもらう、いわばアクティブな方法でした。しかし、アクティブな方法だけでは限界があります。ほぼ自分が会議や勉強会をしている間しか、認知の向上につながらない、という点です。 そこで私がオススメしたいのは、社内Wikiなどに品質やテストに関するナレッジベースをつくり、育てていくことです。このナレッジベースはいわば1人目QAの分身のようなものです。 テストに関する用語や考え方、社外の動向やツールのノウハウなど、知り得るいろいろな情報を残しておきます。こうすることで、組織の誰もが好きなタイミングで情報にアクセスでき、そこから「＊＊＊について相談したい」「＊＊＊について教えて」といった声がけを得られる可能性が出てきます。 また、このナレッジベースは基本的に年中無休です。1人目QA本人が何か別の仕事をしている間にも、誰かがそれを見て問題を解決できるかもしれませんし、知りたかった情報を得られるかもしれません。これによって、知らない間に誰かの役にたち、認知向上につながることもあります。 複数のチャネルで接触機会を増やしつつ、QAを知ってもらおう 今回は品質やテスト、それからQAエンジニアについて、開発組織内で認知してもらう際に有効な取り組みについてご紹介しました。 本記事で挙げた他にも、できることはあると思います。方法やチャネルは複数持つことが有効です。直接対話する機会を持ちつつも、ナレッジ等はできる限り多く、かつ見える形で公開しておいて接触機会を増やすようにしましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ The post 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み first appeared on Sqripts .

はじめまして、QAエンジニアのK.Kです。 今回は10年ぶりに改訂された「知識ゼロから学ぶソフトウェアテスト」を読んだ感想をお伝えします。 www.shoeisha.co.jp この本を読むきっかけ 私にとって、この本はこれからソフトウェアテストを学ぶ人におすすめの入門書であり、10年ぶりに改訂されたとのことで気になっていました。また、改定内容もソフトウェア業界で流行りのアジャイル開発・AIを取り上げたもので、日々の業務で役に立つのではと考え、この本を読もうと思いました。 ※1 ※1 私自身、業務の中でアジャイル開発に触れる機会が増えているように感じています。また、AIに関してもいろいろなサービスが出てきており流行りを感じています。実際、既にAIのサービスを使っており、わからないことがあればすぐChatGPTに聞いたりしています。 改定内容 全体的な章の構成は大きく変わっておらず、これからソフトウェアテストを学ぶ人にとって必要な知識が書かれているため、各章について紹介していきたいところですが、以前、別の方が改定前の書籍をブログで紹介していましたので、今回は改定箇所の内容に絞って書いていきます。 改定箇所以外の内容について興味がある方は下記の記事を読んでみてください。 知らなきゃモグリ!?テストのプロはみんな読んでいるバイブルを紹介 10年ぶりに改訂された理由 10年ぶりに改訂された理由が冒頭に書かれています。 ※以下引用は第3版「知識ゼロから学ぶソフトウェアテスト」より 10年以上改訂しなかったことに、ある日突然気づいた。結構世の中は変わっているぞ！ 10年前に書いたときはベストだと思った記述の多くは、現代のアジャイルやAIソフトウェア全盛にそぐわなくなってきている。 開発サイクルが短くなるだけでこんなに世界が変わるものかとも驚いている。 10年でソフトウェアテストが大きく変化しているため、現在のソフトウェアテストに合わせた記述にする必要があるとのことです。 また、現在のソフトウェアテストについて以下のように書かれています。 アジャイル時代になり多くのテスト活動が開発者テストにシフトしているが、ソフトウェアのサイズは増え続けているので、テスト担当者の仕事は減ることなく多岐にわたっている アジャイルにシフトしたために多くの古くからのテスト手法がおざなりにされているが、当書で記した既存のテスト手法はアジャイル時代でも有効である AIのテストやカオスエンジニアリングは、10年前はほとんど話題にされなかったトピックだが、新規にテスト担当者が学習しなければならない必須トピックである 改定内容について 今回の改定では、各章の内容が現在のソフトウェアテストの状況に即したものにアップデートされており、新たに追加または削除されたテスト技法やカバレッジについての考え方の変化だけでなく、アジャイル開発についての記述も追記されています。どのようにテストをすればよいのか、なぜそのテストが必要なのかから入り、ウォーターフォール開発とアジャイル開発でのテストの違いや筆者の考えなどが書かれています。特に第8章と第9章では、テスト計画や品質管理に焦点を当てており、ウォーターフォール開発とアジャイル開発におけるテスト計画書の書き方や品質管理に使用するメトリクスの違いが大きく書かれています。 また、新たに第10章の「新しいテスト技術」が追記されており、この章では、AIに対するテストとしてメタモルフィックテストや経験ベースのテスト、ニューロンカバレッジについて書かれていたり、現代の複雑なシステム ※2 に対するテストとしてカオスエンジニアリングやランダムテストについて書かれています。 ※2 現代のシステムはオープンソースを利用したり、クラウド環境にシステムを構築したりすることにより複雑化しているため、すべてをテストすることが不可能です。そのため、無限大にあるテストを有限に落とし込むのもテスト担当者の仕事であり、カオスエンジニアリングやランダムテストはそのための手法として当書に記述されています。 本を読んだ感想 この本を読んで最初に感じたのは、アジャイル開発とAIのテストの難しさでした。なぜなら、これらのテストは発展途上であり、今後、アジャイル開発やAIの利用が拡大する中で成長していく技術だからです。 アジャイル開発について アジャイル開発は柔軟な対応が可能で市場リリースを早くできるというメリットがありますが、柔軟な対応と品質の向上の両立は難しい課題です。アジャイル開発だからといって、テストすべき項目やテスト手法がウォーターフォール開発と変わることはありませんが、私の経験上、今までのホワイトボックステストやブラックボックステストでは、逐次変化する状況に対してテストケースを随時更新しながらテストを行うことが困難です。 当書では第4章の探索的テストで以下のように書かれています。 ウォーターフォールでの探索的テストと、アジャイルやAIソフトウェアでの探索的テストでは少しずつ役割が変わっていくのかもしれません。 もちろん、それはもっと探索的テストが活用する方向にです。 また、 短いイテレーションでGUIが変更するようなソフトウェアでは、探索的テストが向いていると筆者は考えています。 このように、探索テストがアジャイル開発に向いていると書かれており、私も探索的テストはアジャイル開発において有用だと感じました。しかし、探索的テストはテスト担当者のスキルに依存する部分があるため、それを主としてしまうとテスト自体が属人化してしまうのではないかとも感じました。 また、アジャイル開発ではこれらのテストの難しさに加え、テスト計画や品質管理の部分でも、ウォーターフォール開発とは異なるため、アジャイル開発のテストは発展途上であり、これからも学び続ける必要があると感じました。 ※3 ※3 私自身はこの本を読むまで、アジャイル開発とウォーターフォール開発でのテスト計画や品質管理の違いについて、あまり意識したことはありませんでした。アジャイル開発では設計からリリースまでが短くなるため、テスト計画をどうすれば良いかと考えたことはありましたが、品質管理において、アジャイル開発に最適化したメトリクスを探そうなどは考えたこともありませんでした。 AIについて AIのテストについては、AI以外の機能テストと明確に異なる部分があります。それは、入力に対する明確な出力が存在しないということです。AIのテストも基本的には既存のソフトウェアテストと同じく、指定した入力に対する出力が返ってくるかをテストしていきますが、その出力が定まっていないためテスト自体が難しいです。当書では、これらの期待値の定義が難しい状況に対するテスト手法の代表としてメタモルフィックテストがあげられています。この手法は、ベースとなる入力と出力が存在する状態で、入力に少しずつ変化を加えていき、出力がどのように変化するのかを確認する手法です。入力に変化を加えたことで出力が大きく変わってしまう場合、AIシステムに問題があるのではないかと考えることができます。 しかし、このテスト手法の最後に以下のように書かれていました。 メタモルフィックテストも完璧ではありませんし、定量的な品質指標を提供しにくいテスト手法です。 特にミッションクリティカルなソフトウェアでは、このテスト手法は慎重に適応したほうがよいと考えます。 ただAIのテスト手法の一番代表的なものなので、これを使うしかないのですが。 このように、まだ効果的なAIのテスト手法は存在しないというのが現状であり、これからも学び続ける必要があると感じました。 どのような人におすすめか 10年ぶりに改訂されましたが、全体的な構成は大きく変わっておらず、読みやすい文章や図により、なぜテストをするのか、どのようにテストをすればよいのかがわかりやすく書かれているので、これからソフトウェアテストを学ぶ人にとっての入門書としておすすめであることに変わりはありませんでした。 また、改定前の当書を読んだことがある人にとっても、この10年間でどのようにテストが変わっているのか、特にアジャイル開発やAIのテスト手法や現状、また、それらに対する筆者の考えがわかりやすく書かれているので、アジャイル開発やAIに触れる機会が多いのであれば、手に取って読んでみても良いのではないかと感じました。 The post AI・アジャイルなど最新技法を網羅！改訂版「知識ゼロから学ぶソフトウェアテスト」を読んでみた。 first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第3回となる今回は、ステークホルダーとの関わり、ステークホルダーマネジメントの重要性についてお伝えします。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ ステークホルダーマネジメントの重要性とその高まり PMBOKでは2012年の第5版でから「コミュニケーションマネージメント」から「ステークホルダーマネジメント」という項目が独立し、その影響と管理の重要性が改めてフォーカスされました。PMBOKでは1996年以降マネジメント領域の新設は一度もなかったため、世界的にステークホルダーマネジメントに注目が高まっていることがわかります。 ステークホルダーとは ステークホルダとは一般的に「利害関係者」と訳します。もともと「株主」を示す経営用語から、今では企業経営やプロジェクトを取り巻いて影響を与えあう意味での利害関係者（従業員から、取引先、PJ結果の影響を受ける個人など）を広域に指すようになりました。PMBOKでは 「プロジェクト、プログラム、またはポートフォリオの意思決定、活動、もしくは成果に影響したり、影響されたり、あるいは自ら影響されると感じる個人、グループ、または組織」 と定義しています。 プロジェクト活動においてさらにステークホルダの存在やマネジメントの必要性が増している理由として プロジェクトが高速化している 多様化するプロジェクトで利害関係が複雑化している こと等があげられます。プロジェクト憲章が承認されPMに任命されチームが形成される「立ち上げ段階」で、いかに早くステークホルダーを特定して、後述するエンゲージメントのプロセスを準備/開始できるかがプロジェクト成功の鍵といえるでしょう。 「エンゲージメント」とは絆づくり ステークホルダマネジメントでは「エンゲージメント」という言葉が使われます。 エンゲージメントは「約束、婚約、社員の愛着心、ブランドと消費者の絆」など業界ごとに対訳が異なりますが、筆者は人事労務分野用語に近い「絆、望んで協力する愛着」といったイメージが近いと考えています。ステークホルダと絆を育んで、プロジェクトに愛着を持ってその成功に力を貸して貰えるよう、PMは活動を続けます。 ステークホルダーマネジメントの進め方 ステップ①：プロジェクトのステークホルダーを特定する ステップ②：どのようにステークホルダーとエンゲージメントするか計画を立てる ステップ③：エンゲージメントを実施する（マネジメント） ステップ④：エンゲージメントの実施状態を確認し、必要なテーラリングを行う プロジェクトのステークホルダー対象者は多岐に渡り、各ステークホルダーの関心ごとは異なるため闇雲に管理すること、当然エンゲージするなどはできません。まずは「プロジェクトのステークホルダーは誰（何）だろう？」と考え、ステークホルダーの関心、関与、相互依存、影響やプロジェクト成功への潜在的影響に関する情報を収集して整理します。次に整理した情報を元に「ステークホルダーにどう関わればプロジェクトが成功するか」計画を立てます。 ステップ３ではエンゲージメント活動として、ステークホルダーとコミュニケーションを取り協業していきます。プロジェクトが進むにつれ、ステークホルダーの状態も変化すると考え、定期的にプロジェクトとステークホルダーとの状態を見直すことも忘れません。 具体的にステークホルダーの特定やエンゲージメント計画にどのような対応があるか、見ていきましょう。 ステップ①：テークホルダーを特定する 漏れなく行いたいステークホルダーの特定 ステークホルダーをマネジメントするためには、その前にそのプロジェクトにおける、ステークホルダーを特定しなければなりません。その際は、社内と社外の利害関係者両方を考慮するようにしましょう。慣れない内は特定作業を難しく感じるかもしれません、そんな時は「事業構造、プロジェクト体制、顧客（ユーザー）中心」など検討の起点や枠組みを決めてから考え始めると良いでしょう。 プロジェクトに影響を与える（持つ）人は誰だろう？ プロジェクトが影響を与える人は誰だろう？ プロジェクトを承認（拒否）できる権力者は誰だろう？ コスト（等）を出してくれる人は誰だろう？ プロジェクトに必要な知識（ナレッジ）を授けてくれるのは誰だろう？ ステークホルダーの特定は近視眼的にならないこと、つまり自分と直接関わる人や物事だけにフォーカスしないことが大切です。例えばプロジェクトが進んでリソースが枯渇した場合やシステムリリースが他のプロジェクトとコンフリクトしたしてしまった、という場合は主要なPMやPMOとの連携/協力が欠かせず、ステークホルダーとして意識すべき対象ですが漏れがちです。見落としがあって「後からステークホルダーが見つかる」場合、その影響によってはプロジェクトにマイナス（リスク）として作用する可能性がありますので注意しましょう。 ステークホルダーを分析する ステップ①ではもう一つ大事なプロセスがあります、それは特定したステークホルダーを「分析」することです。分析といっても難しいことはなく、ステークホルダーマネジメントを計画、実施するために「傾向」を立てる整理だと考えましょう。 ステークホルダー分析にはステークホルダーをマップ化した 「分類マトリックス」 をお勧めします。 エンゲージメントを高めるために、まずは各ステークホルダーの影響力や関心度を明確にすることが必要です。この分析では「権力と影響度」と「関心度」という軸、「高」と「低」というレベルを設けて2×2のマトリックスに ステークホルダーを分類し視覚化 します。 ※この軸は影響×関心の２軸にしていますが、組織によってパターンや内容を変えてもいいと思います。何かしらの軸を持つことで個人の判断で恣意（しい）的に決めたのではないという合理性を持たせることが大切です。 例えば、、、 プロジェクトスポンサーの田中さんはプロジェクトへの権限を持っていて影響がある、そしてプロジェクトへの興味関心も高いので影響度高×関心度高に配置してみよう。経理部門はプロジェクトに対する権限こそないが、あまりコストをかけて欲しくないことからプロジェクトへの興味はありそうだ、もしかすると後半になって何かコスト的な指摘がはいりそうだ。と分析し影響度低×関心度高に配置しよう。と、このように分析/可視化することで、今後各ステークホルダーに対して優先順位や対応方針を明確にしていくことができますね。 マトリックスに対する標準的な対応方針 マトリックス上で可視化されたステークホルダー分析に対して、標準的に以下のような対応をとります。また、全てのステークホルダーに対して満遍なく対応することは難しく、PMは①→②→③→④の「逆ゼット（Z）」順（枠）で見るのがよいと言われます。 ステークホルダと分析結果を記録する ステークホルダーの特定とマトリックスで整理された分析結果を一覧化したものが「ステークホルダー登録簿」です。ステークホルダー登録簿へ明文化することで今後の「計画」やエンゲージメントによる変化をモニターすることを可能にします。 名前など基本情報を明確にした上で「マトリックス」で検討した情報を記載します。また対応内容には分析で得られた方針を元に「どのような態度・対応を講じていくか、その必要があるか」といったステークホルダーへの対策を記載します。 ここで注意したいのがステークホルダー登録簿の管理です。ステークホルダーマネジメントに伴う分析や整理はプロジェクトに必須の営みですが、ステークホルダー分析結果や登録簿に記載された内容はデリケートな部分を含む為その取り扱いには注意が必要です。分析結果や対応戦略等は基本的にはPMのみが管理することをお勧めします。 ステップ②：計画する ステップ①で行ったステークホルダーの特定、分析、整理記載をベースに、ステークホルダーへの対応を計画します。ステークホルダーとの効果的な対話と関与を促す方法を考えます。 例えば経理部の斉藤さんは、、、 現在関心度は高いが経理部としての関心であり、プロジェクトの後半で費用の締め付けや指摘などがあるかもしれない 経理部としては開発予算がXXに収まることがわかれば安心してもらえそうだ 次フェーズ開発コストの獲得を行う際、斉藤さんの発言力は高いが今フェーズの予算消化が物をいいそうだ →なんとか斉藤さんとの関係性を高め、関心度をより高めてプロジェクト支援者になってもらえないだろうか？ →斉藤さんではなくXX役員に後ろ盾になってもらうことで解決できないだろうか？ といったように、ステークホルダーとの関係性を変化させることでよい影響がもたらすことができないか「仮説」をシュミレーションすることからはじめます。分析からステークホルダーのニーズと視点、考え方を理解し、プロジェクトの成功に近づけるためにどんなアクションが取れるかを計画することはPMの役割です。ステークホルダーの立場に立って考えてみましょう。 ステップ③④：ステークホルダーエンゲージメントの実行と定期的な見直し 各ステークホルダーをプロジェクトに巻き込み、プロジェクトの成功に向けて継続的に関わって貰うには、交渉やコミュニケーションを通じて期待をマネジメントすることが必要です。 ステークホルダーと常に情報共有すること、プロジェクト中に発生する変更や進捗情報を知らせるようにしましょう。また適切なれポーティングは可視性が高まるだけではなく、誤解が発生するリスクも減らせます。すべてのステークホルダーに満遍なくは対応できず、またその必要がないことはステップ①でもお伝えしました。完璧なコミュニケーション補完とソリューションはありませんので、例えばの力のかけ具合や頻度を事前に決めておくことが大切です。またプロジェクトが進むにつれ、プロジェクトと同様にステークホルダーの状況（対象者、興味関心、影響度など）は変わります。定期的な棚卸しを忘れずに。 さいごに ステークホルダーを意識し、マネジメントすることはプロジェクトハンドリングするPMの非常に重要な活動ですが、実態として時間的制限から行われない（おざなりになる）、苦手意識があるといった課題を耳にしますPMBOKの知識体系の「最後」に書かれているからか、どうしても主役の対応になりにくいステークホルダーマネジメントをぜひみなさんには理解し実施していただきたく、本連載ではあえてQCDマネジメントやリスクマネジメントといったパートより先にお話ししてみました。 次回は、プロジェクトを始動させる際に必要なプロジェクト憲章やマネジメント計画書の作成とその方法についてお話ししていきます。 The post 【第3回】ステークホルダーマネジメントの重要性と進め方 first appeared on Sqripts .

はじめまして！ QA業界23年のテストエンジニア『つよぽん』です。 今回、ブログ初挑戦となります。最後までお付き合いください。 さて、今回は2023年にCBT化された『JSTQB Advanced Level Test Analyst』（以下、ALTA）の合格体験記です。ALTAの受験～合格に至るまでの体験をまとめました。 これからAdvanced Level（以下、AL)を受験する方のお役に少しでも立てることができましたら幸いです。 Test Analyst 受験までの道のり 2000年からテストエンジニアとして働き始め、2011年に Foundation Level（以下、FL）を取得しました。 2013年の第2回　Advanced Level Test Manager（以下、ALTM）を受験。結果は『不合格』でした。また第2回試験の合格率が6.86％と低かったことや、以下の悩みどころもあり、その後試験を受けることに慎重になってしまいました。 私にとってのJSTQB試験の悩みどころ ・受験料が少々高い(22,000円) ・試験の回答が公表されないのでどこを間違えたかわかりにくい ・過去試験問題がほぼ非公開、問題集が少ない そこから9年　私が、AL試験を再度受けようと思ったのは、2022年8月に現在の会社へ転籍したことが大きなきっかけです。 再受験に向けた問題点、それは以下3つのでした。 学習    　　→　どうやって勉強すればいいだろう？ 資金    　　→　22,000円の試験料が少々高い メンタル    　 →　AL資格取得は本当に必要か？ 解決したのは以下によるものでした。 『学習』　e-learningの提供 　ALを受験するための学習コンテンツ( e-learning )が弊社にありました 　 ⇒　これで学習しよう！！ 『資金』　会社からのバウチャーチケットの提供 　会社から1回分のバウチャーチケットが提供される 　 ⇒　バウチャーを1回分貰えるならタダで受験できる！！ 『メンタル』　組織目標によるモチベーションアップ 　ALの取得目標が組織として設定される（おじさんには結構良い効果） 　 ⇒　会社からのPUSHでキャリア的にもAL持ってないといけないと奮起！ ！ 以降は、AL取得に向けた再受験のお話となります。 JSTQBの受験経歴 私のJSTQB受験履歴を並べてみます。 Ⅰ．FL受験（2011年8月／合格） Ⅱ．ALTM受験（2013年2月／不合格） Ⅲ．ALTA受験（2023年5月／不合格） Ⅳ．ALTA受験（2023年8月／合格） 今回のAL受験では、この10年で業務として関わりの深かった分野である『Test Analyst』を受験することにしました。 Test Analyst 受験（1回目）の失敗談 1回目のALTA受験は2023年5月にCBT化されたものでした。テストの感触としては悪くない。それなりにできた印象でしたが結果は不合格でした。 受験に向けて準備したことは以下の通り。 試験概要の把握 　問題数：40問 　総試験時間：135分　(NDA 5分 + 試験 120分 + アンケート 10分) シラバス の読み込み 　問題はシラバスに沿って出題されるため、シラバスを熟読（3回） 弊社 e-learning による学習 　シラバス読み込み後に講義形式、問題形式による学習の実施 CBT試験のデモ 　ペーパー試験世代のためCBT試験が苦手、事前に操作の把握 また反省点を考えて、次回に備えました。 【反省点】 試験概要の把握しか出来ていなかった 全体をまんべんなく学習してしまった CBT試験の経験不足（ペース配分、操作など苦手感が拭えなかった。） “失敗した経験も次に生かすための大事な財産として心に留めます！” Test Analyst 受験（2回目）の成功談 一番初めに、どうしたら合格できるかを「考えること」から始めました。 そこで導き出した結論が以下となります。 其の壱： 戦略を決めよう 資格試験もテストと同じ！戦略を決めてからスタートすることとしました。 今回の戦略は資格試験の定番　↓↓↓↓↓↓↓↓↓で決定 『敵を知り、己を知れば、百戦して殆うからず』（孫子） 其の弐： 具体策を練ろう 戦略も決まったので次は戦略に沿った具体策を考えました。 『敵（ALTA）を知る』 まずは敵を知らなくては戦えない。徹底的に敵を把握して、分析しよう！！！ 出題傾向の分析 どこが何問出るの？ ISTQB公式サイトの Exam Structure Tables v1.6 をチェックすべし！ 試験ごとの出題配分がChapter単位で公開されています。 ※詳しくは ISTQB公式サイト を参照 上記の『Exam Structure Tables v1.6』のALTAの問題数をまとめた結果は下表となります。 Chapter 問題数 Chapter1 6問 Chapter2 1問 Chapter3 17問 Chapter4 11問 Chapter5 3問 Chapter6 2問 合計 40問 配点傾向の分析 問題の配点はどうなっているの？ ここでもISTQB公式サイトの Exam Structure Tables v1.6 をチェックすべし！ 　試験ごとの問題配点もChapter単位で公開されています。 『Exam Structure Tables v1.6』のALTAの問題配点をまとめた結果は下表となります。 Chapter 配点 Chapter1 10点 Chapter2 2点 Chapter3 44点 Chapter4 15点 Chapter5 6点 Chapter6 3点 合計 80点 合格ラインの分析 何点取れば合格できるの？ 問題数40問、総点数は80点！合格点はISTQBに準拠することより65%なので・・・ 80点×65%＝　52点 　すなわち 52点で合格 です。 合格点に到達するための分析 合格点に到達するためにどの問題を何問正解すれば合格できるの？ そのためにはChapterごとの配点とK Level（配点の高い問題）の出題数を分析！！ Chapter 問題数 K2 K3 K4 Chapter1 6問 4 0 2 Chapter2 1問 0 1 0 Chapter3 17問 3 1 13 Chapter4 11問 9 0 2 Chapter5 3問 0 3 0 Chapter6 2問 1 1 0 K2 = 2点 / K3 = 3点 /K4 ＝ 4点 点数が高いChapterは以下２つです。 Chapter3（テスト技法）＝44点 Chapter4（ソフトウェア品質特性のテスト）＝15点 この二つをマスターすれば 44 + 15 ＝ 59点 となり、これだけで合格ラインに達します。 さらにK Levelも含めて分析するとChapter3（テスト技法）のK4 Level(配点3点)は13問出題されるので 39点 になります。これだけでも合格点の3/4がとれます。 K3 = 3問(9点)のChapter5（レビュー） も配点が高いのでおススメです。 なんかこの分析だけで合格できそうな気になりませんか？ 『己（自分）を知る』 敵を知ったその上で、己(自分)を知らなくても勝つための戦いはできません。 自分の得手・不得手を徹底的に分析しましょう！！！ 得手、不得手の分析 何を得意としているか？（自問する） 私の場合・・・ テスト技法など考えて解くものはモチベーションアップするし、理解しやすい 品質特性など業務で関わった部分は把握しやすい 何を不得意としているか？（自問する） 私の場合・・・ シラバスの理解が苦手（特に業務で関わってこなかった分野） ケアレスミスが多い(正しいものと、間違っているものどちらを選ぶかのミス) 得手、不得手の分析結果より導いた対応策 私の場合・・・ テスト技法は問題集の捜索・確認する 品質特性などは過去業務に照らし合わせて学習する シラバスは読むだけでなく自分で書き出しまとめてみる ケアレスミス対策として、問題の読み方を改善（何を回答するかを先に見る） “得手・不得手は人によって違う。自分を理解して、自分に合った対策を実行することが大事！” 『百戦して殆うからず』 何度、受験しても合格できるようにするべし。そのための対処法を考えましょう！！！ 目標を合格ラインのギリギリに設定しない 合格点(52点)に対して、確実に合格するよう学習しましょう。 「多分取れるだろう」を含めての目標では不合格リスクが高い！！ 学習のピークを試験日に持っていく 学習計画を立て、学習のピーク（一番まとまって学習できる）日程で試験を受けるべき。 其の参： モチベーションアップ対策を考えよう 合格をより確実なものにするために、モチベーションアップする案を検討！！ みなさんはどんな場合にモチベーションがあがりますか？ 私の場合は以下設定をしました。 合格時の成功報酬の設定 合格時に自分へのご褒美を設定。これだけでモチベーションは爆上がりです。 合格した場合のメリットの分析 合格した場合に自分にどんなメリットがあるかを考える。 『新たな学習チャンス』：次のスキルアップに向けた時間を確保できる 『業務的なアピール』　：資格保持を業務的なアピールとして使える 其の四・計画に沿った学習 今回の戦略・計画に沿って、5月中旬～8月下旬(2か月半)で以下の追加学習を行いました。 配点の高いテスト技法についても、問題集をこなし、取りこぼしのないように準備をして試験に臨みました。 No 追加学習 サイト 1 シラバス （前回テストで出題された内容） https://jstqb.jp/syllabus.html#syllabus_advanced_altta 2 JSTQB公式サイトのAL試験過去問題の解説 セミナー(TA)視聴 https://www.youtube.com/watch?v=IWUkunUZNoA 3 ソフトウェアテスト技法練習帳 https://gihyo.jp/book/2020/978-4-297-11061-1 4 JSTQB（非認定）ソフトウェアテスト問題集 (Advanced Level Test Analyst） https://learner-jstqb-al.booth.pm/items/3105863 5 JSTQB e-learning （再確認) https://agest.co.jp/academy/ 試験当日～結果判定 試験当日は、『やるべきことはやった。いい状態』で迎えられました。 手ごたえは以下です。 時間配分:試験時間を30分残して見直し開始、見直し含めて3分前に完了しました 試験内容：戦略・計画がハマった。一度受験した経験も追い風になりました 合格予想率：80%　⇒　試験結果は約2週間後。申し込みサイトのボタン一つで結果がわかる 今回は予想率通りの結果『合格』でFINISHできました。 まとめ JSTQB認定テスト技術者資格は、知識やスキルを体系的に学ぶことができます。 今回受験したALTAはFLで学んだ知識をより拡張したものとなります。より深く、広い知識を得ることで、業務に対しての理解度や共通認識での会話力が高まり、テストエンジニアとして、良い成果に導いてくれるものと思います。 また知識を有していれば資格は不要という方が多々見受けられますが、仕事の初見では、知識の有無は詳細に計れないところがあります。そのために資格という目に見えるものは知識の有無を示すのに有効であると考えます。 ソフトウェアテスト業界でFL取得が当たり前となる昨今、AL取得が次のステップとして必要になってきています。皆さんも、自分に合った戦略・計画を整えて学習することにより、JSTQB AL資格を取得しましょう。 最後まで読んでいただき、ありがとうございました！ The post 10年ぶりのJSTQB AL受験～TestAnalyst合格体験記～ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第13回目のテーマは、「かんばん」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 かんばんの誕生 かんばんは、イギリス人のデイヴィッドさんが考え出した開発手法です。 かんばんはその名の通り日本語が元になった開発手法です。もともとはトヨタ生産方式で使われているかんばんがベースなのですが、トヨタのかんばんとこのかんばんは、思想は似ていてもまったく異なる手段です。 かんばんは、開発手法としてのかんばんと、ツールとしてのかんばんがあります。開発手法のかんばんは、XPやスクラムのようなもので、原則が手順書のようになっているのではじめやすく、誰にでも理解しやすくなっています。 ツールとしてのかんばんは、タスクをふせんではりつけたタスクボードをさしています。厳密に言うとタスクボードとかんばんはちょっと違うのですが、このあたりも後ほど解説します。 かんばんに関しては、自分が翻訳した書籍『 リーン開発の現場 』をベースに解説します。また、翻訳の際に、 かんばんの英語版Wikipediaページ も日本語に翻訳しました。こちらもかんばんの理解にとても役立つ内容なので、おりまぜて解説します。 かんばんの基本原則 まず、かんばんの基本原則を解説します。 解説と言っても、原則自体が文章になっているので、これまでの開発手法とちがってとてもわかりやすい内容になっています。 原則： 現在、何をしているかを理解することから始める ひとつめは「現在、何をしているかを理解することから始める」です。 まずは、現状、どういう流れで開発が行われているかを考えます。リーン思考で登場したバリューストリーム（価値の流れ）を意識します。かんばんではこれをワークフローと呼んだりします。 塹壕より、かんばんとリーン より たとえば、大抵の開発現場では、要件を聞く ＞ 設計する ＞ 開発する ＞ テストする ＞ リリースする・・・といったワークフローになっているはずです。こういったバリューストリームを構成する要素をホワイトボードなどに書き出していくとよいでしょう。 そして、洗い出したワークフローをかんばんに反映していきます。 かんばん Wikipedia より この写真は、実際に私が使っていたかんばんです。マスキングテープによって、タテのレーンにわかれていますが、それぞれのレーンが、要件をきく ＞ 設計する・・・といった構成要素をあらわしています。そこに仕事を表す付箋を貼ることで、仕事がどういう状態なのか、かんばんだとひとめでわかるようになります。 原則： インクリメンタルに進化させ、変化を追求していく 2つ目は「インクリメンタルに進化させ変化を追求していく」です。 シンプルなかんばん。タスクボードと呼ばれたりもする。 さきほど登場したかんばんは、様々な進化を遂げて写真のような形になりました。もともとのかんばんは、上記のようなシンプルなかんばんでした。このかんばんは、TODO、DOING、DONEといったタスクの状態を可視化したものです。おそらく、さまざまな現場でも使われているフォーマットだと思います。 しかし、開発を進めていく上で、この方法ではわかりにくい部分が出てきたので、インクリメンタルに進化させ、変化を追求していきました。 たとえば、Doingひとつをとっても、開発がDoingもあれば、テストがDoingもあります。開発をすすめる上で、この違いがわかりにくくなったのであれば、開発DoingやテストDoingを追加するとよいでしょう。 このように進化を続けた結果、たくさんのレーンのあるかんばんになりました。 これをはじめて見たひとはよく「複雑でわかりにくそう」と感じるみたいですが、開発チームにとって見れば、自分たちの仕事の流れと状況がひと目で分かる仕組みになっています。Wikiにすらまとめる必要はありません。よって、新しいメンバーがはいったときでも、このかんばんを使い、ひととおりタスクを流してもらうだけで、開発の流れの全体像を理解できるようになります。 原則： 現状のプロセス、役割、責務、職位を尊重する 3つ目は「現状のプロセス、役割、責務、職位を尊重する」です。 現状、さまざまなプロセス、役割や責務があるはずです。とくに役割を見てみると、現状の役割分担では、アジャイル開発がうまく進まないケースもありえます。よくあるのが「これは誰が担当するのか？」の議論です。縦割りの工程に慣れているひとにとっては、職能横断型のやりかたは急にはなじめないものです。 かんばんでは、まずは現状を尊重し、そこから少しずつ変化をうながしていきます。 原則： すべての地位でのリーダーシップを求める 最後は「すべての地位でのリーダーシップを求める」です。 いうまでもなく、リーダーシップは重要です。これはチームだけでなく、マネジメント層や経営層まで、はばひろく求められる要素です。 チーム開発ですから「誰かがやってくれる」ではなく、「自分たちがやる」という気持ちを持つのが重要です。 コアプラクティス： 可視化する 最後にかんばんのコアプラクティスを紹介します。コアプラクティスも、やることが順番になっているので、わかりやすいのがかんばんのいいところです。ひとつずつ見ていきましょう。 ひとつめは「可視化する」です。原則にもありましたが、ワークフローを中心に可視化し、改善していきます。かんばんのいいところは、見える化に特化したツールなのでわかりやすい点です。 コアプラクティス： WIPを制限する 2つ目は「WIPを制限する」です。 これは、かんばんの特徴的なプラクティスです。WIPは（ウィップ： Work in progress）という意味です。日本語に訳すとすれば、進行中、処理中という意味になります。かんばんでは、同時進行の仕事の個数を制限します。これがWIP制限です。 たとえば、開発中というステータスのWIPを5に設定した場合、チームメンバーは5つの仕事だけを開発中にできます。これがWIP5の意味です。5つが開発中であれば、どれかが次に進まない限り、次の仕事を開発中にはもってこれません。 5人のチームだった場合、WIP5だとすると「ひとりひとつの仕事を担当する」という意味になります。もし、だれかが仕事を終えた場合、開発中の数がひとつへります。そうすると、新しくもうひと仕事を開発中に移動できます。 せっかく同時進行で進められるのに、やれる仕事の数に制限するのは不思議に思うかもしれません。ただ、ひとりで作業することが、効率が良いとは限らない場合もあります。たとえば、誰かに相談したくても、まわりもひとり一つの仕事に集中しています。もし話しかけるならば、誰かの仕事を止めることになります。 かんばんでは、WIP制限によって、流れる仕事の数を調整し、全体最適を考えていきます。このあたりはリーン思考に近い考え方です。 コアプラクティス： 流れを管理する 3つ目は「流れを管理する」です。 WIPで仕事の量をコントロールできたら、その状況を見極めます。たとえば、リリース待ちのエリアにたくさんの仕事が貼り付けてある場合、リリースがボトルネックになっている可能性があります。開発中のWIPを減らすなどして、リリースに仕事がたまらないようにするのもいいかもしれません。 かんばんを活用すれば、どこがどういう状況か？ 開発の流れがよくわかるようになります。 コアプラクティス： 明確なポリシーを作る 4つ目は「明確なポリシーを作る」です。 アジャイル開発でよく言われる「完了の定義」を決めます。たとえば、開発完了という状態がある場合、その状態になるためには何をクリアしなければならないのかを決めます。これを決めることで、チームメンバーはまよいなく仕事の状態を選択できるようになりますし、どうすれば終わるのかが明確になります。 たとえば、開発完了にテストも含めるのであれば、開発は終わったけどテストが終わっていない・・・といった状態に気がつけます。気がつけると、終わらせるための対策も打てます。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 The post 第13回 ソフトウェア開発における「かんばん」 first appeared on Sqripts .

こんにちは。小学２年生と年中の子を持つワーママ、ちーちゃんです。 育児の一番大変な時期は多分越えた？とは思いますが、まだまだ自分の時間は持てない中で最低限の勉強をしてAWS認定 クラウドプラクティショナーを受験＆合格しましたのでAWSについて、受験のことや試験について報告します！ AWSの概要 AWSとは AWSとは何か？公式Webサイトには以下のように説明されています。 Amazon Web Services (AWS) とは、世界で最も包括的で、幅広く採用されているクラウドコンピューティングサービスです。クラウドサービスを利用すると、インターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした、さまざまな IT リソースをオンデマンドで利用することができます。AWSでは、そういった 200 を超えるフル機能のサービスを世界中のデータセンターから提供しています。 AWS公式Webサイト「AWSとは？」 AWSが人気の理由 クラウドインフラ市場シェアは以下です。 1位：AWS　32% 2位：Azure　23% 3位：GCP　9% Canalys「Worldwide cloud infrastructure services expenditure grew 23% in 2023」 AWSはCIPS市場において、どのプロバイダーよりも幅広く高度な能力を発揮し続けている。AWSは、競合クラウドプロバイダーがそのまま模倣することも少なくない標準の設定、技術の開発、および手法の確立を通じて、市場全体の指導的な役割を担ってきた。 さらに、AWSは、合理的に見てクラウドに該当すると考えられるものの範囲から大きく逸脱したサービスの販売を基に顧客に対して業績を誇張することのない、この市場における数少ないベンダーの1つである。 gartnerのクラウド・インフラストラクチャ／プラットフォーム・サービスのマジック・クアドラント の分析ページより AWSは長らくシェア1位をキープしています。 AWSはクラウドサービスの先駆者であることだけではありません。上記のように指導的役割を果たしたり、技術を上げノウハウを蓄積したこと、また歴史も長いことから、ネットに情報が多いことも利用しやすい理由だと思います。 それだけでなく、AWSはよくユーザーファーストといわれます。クラウドから逸脱したサービスを行ったり、利益を得た分を還元するシステムで何十回も値下げをしています。先頭に立って他にはないサービスを提供しながらコスト面でもユーザーの期待に応えていたことがAWSが人気になった理由だと思います。（参考： 「AWSのクラウドが選ばれる10の理由」 ） 3大クラウドサービスの特徴 今度は先ほどのシェア率の図を見てみましょう。1位のAWS、2位のAzure、3位のGCPだけでシェアの60%以上を占めています。 これらは以下の特徴があります。 AWS セキュリティ AWSでは、セキュリティが最優先事項です。 AWSは、アプリケーションとワークロードを構築、移行、管理するための最も安全なグローバルクラウドインフラストラクチャとして設計されています。これは、300種類以上のクラウドセキュリティツールの豊富なセットと、政府、医療、金融サービスなどのセキュリティに最も敏感な組織を含む数百万のお客様からの信頼によって裏付けられています。（ 「AWSクラウドセキュリティ」 より） サービス数 （ 「AWSのクラウドが選ばれる10の理由」 より） 200以上のサービスを提供 リージョン、国と地域 (「 AWSグロ－バルインフラストラクチャ 」より) リージョン数： 32 利用できる国と地域：245 AWS グローバルインフラストラクチャマップ より Azure セキュリティ クラウドの保護に役立つサイバーセキュリティ関連のインテリジェンスが全世界からリアルタイムで供給されるので、新しい脅威を検出し、迅速に対応することができます。このような実用的な分析情報は、180 億件の Bing Web ページ、4,000 億件のメール、10 億件の Windows デバイスの更新、毎月 4,500 億件の認証など、幅広いソースを分析することによって得られます。Microsoft のデータ サイエンティストは機械学習、行動分析、アプリケーションベースのインテリジェンスを駆使して、Microsoft インテリジェント セキュリティ グラフにある大量のデータを分析しています。このようにして得られた分析情報が Azure のサービスに供給され、脅威の迅速な発見に役立てられているのです。（ 「Azureでセキュリティ体制を強化」 より） サービス数 200以上のサービスを提供 リージョン、国と地域 （「 Azure の施設、建物、および物理上のセキュリティ 」より） リージョン数： 60 以上 利用できる国と地域：140 GCP セキュリティ Google と同じ安全性を重視した設計のインフラストラクチャ、組み込みの保護機能、グローバル ネットワークを使用して、お客様の情報、ID、アプリケーション、デバイスを保護します。 Google の施設間で転送中または保存中のデータを暗号化し、暗号鍵への監査済みアクセス権が承認されているロールとサービスのみがアクセスできるようにしています。（「 Google Cloudトラストセンター 」より引用） サービス数 ※サービス数の具体的な数値は見つけられなかったがGCPがAWS,Azureとのサービスの比較表を提示しています。それを見るとサービス量に大きな差はないのではないかと思いました。（参考：「 AWS や Azure サービスと Google Cloud を比較する 」） リージョン、国と地域 （「 Cloudのロケーション 」より） リージョン数：39 利用できる国と地域：200以上 3大クラウドサービスすべてに言えること セキュリティについては公式の文面で優劣は私だとつけられないですが、自分たちが持てる最大のセキュリティで情報を守っているのだと分かりました。 リージョンや利用できる国、地域については数で多少差はありますが、日本は当然のことながら世界中で利用できることが分かりました。 サービス数においても、どのクラウドサービスも、利用する企業の希望に応えることのできる量のサービスを提供していると感じました。 AWS認定 クラウドプラクティショナー試験 2023/08にAWS認定クラウドプラクティショナー試験を受験しました！ 資格取得しようとした理由 AWS認定 クラウドプラクティショナーの資格取得しようと思ったきっかけは、以前お客様先でAWSを使用していたことを思い出して、AWSは様々な業種で使用しているので、この知識を多く知っておくことは有意義だと思ったからです。 この資格は広く浅くAWSやクラウドのサービスを知ることができる資格なので直接〇〇に役立つよ！！というものは多くはないです。しかし、AWSやクラウドのサービスを知ることでお客様先で利用しているときなどに役に立ったり、どの業界でもクラウドサービスを利用しているので自分自身を一段成長させたいと思った時、このシステムを把握すること自体意味があることだと感じました。 ここから次のレベル以降は直接的なAWS構築の業務に携わったり、さらには世界に通用する国際資格なので高みを目指すためのベースとなる資格です。そのため資格取得を目指して勉強することは意味があることだと思い資格を取得しました。 試験の概要 4択問題か、5択で2個選ぶ形式で出題 試験時間：90分 問題数：65問 （ 「AWS Certified Cloud Practitioner」 より引用） 合格ライン：非公開（7割正解で合格？難易度で前後するらしいとの噂も・・・） ピアソンVUEでの受験 受験の申し込みとamazonの公式勉強「Amazon Skill Builder」のアカウント取得までが英語だらけで、英語が苦手な私にはちょっと大変でした。。。 必要なアカウント 受験申込：Amazonアカウント 無料の勉強システム：Amazon Skill Builderアカウント Amazonアカウントは持っているものでも良いらしいですが私は試験用に新規作成しました。 またサブスクで追加の勉強もあるみたいでしたが今回は無料の範囲で挑戦することにしました。（勉強のサブスクがあることに驚きました！サブスクで収益を得る時代なのかなと思いました。） 申し込みの際に英語の難関さえ越えれば、受験勉強用に公式の無料勉強教材「Amazon Skill Builder」があることや、受験結果がすぐ出るなど受験しやすいと感じる試験でした。 試験の特徴 資格の有効期限がある →AWSの試験全てにおいて３年の有効期限がある。最初は驚きましたが、世の中の変化に合わせて知っておくべきサービスが変わるので個人的には納得しました。 ピアソンVUE試験会場（沢山ある）、または自宅で受験できる →自宅だとネットワークなどのトラブルが怖いので会場受験を選択しました。 ピアソンVUEの受験をしたことがある人はご存じの通り試験会場はカンニングできないような対策がばっちり。 →免許証等２枚身分証明書必要 →当日も受験者の写真を撮られる →ヘアピン禁止（ヘアゴムはOK） →もちろんカバンやスマホ、ポケットの中のものはロッカーへ →メモしたい時などペンさえも会場が用意したものを使用する 最初ちょっとドキドキしますが、会場には他の試験を受けている人も沢山いるのですぐ慣れます。 私の勉強方法 勉強に利用したサイト 「 Amazon Skill Builder 」 動画で勉強のほかに、無料の模擬テストもあり何度か利用。 「 AWS認定資格 無料WEB問題集＆徹底解説 」 　直前は（最後の１日くらい）は「AWS認定資格 無料WEB問題集＆徹底解説」のサイトも利用 受験勉強方法 「AWS Skill Builder」では覚えてほしいことを動画や文章でまとめてくれているのでそれを中心に２週間前から勉強。当然、日本語バージョンを使って勉強しました。 主にコーヒーショップを例にした動画を見ながらキーワードや、説明をメモして動画を一通り見ました。その後、時間もなかったのでメモを見返して特徴を覚えました。 直前は「AWS Skill Builder」の無料の試験の想定問題や、「AWS認定資格 無料WEB問題集＆徹底解説」のサイトを利用して問題に慣れるようにしました。 公式の想定問題だけでは問題慣れが不十分と感じ、「AWS認定資格 無料WEB問題集＆徹底解説」は前日から利用しました。しかし、このサイトに用意されている400問という問題数は前日からではとてもできないと思い網羅しやすいとことに絞って利用しました。 試験の出題範囲と出題率が以下です（C01ドメイン） クラウドのコンセプト： 26% セキュリティとコンプライアンス： 25% テクノロジー： 33% 請求と料金設定： 16% ( 2023/9/18 まで。 9/19 から変更あり) AWS Certified Cloud Practitioner(CLF-C02)試験ガイド より それに対して「AWS認定資格 無料WEB問題集＆徹底解説」の問題数が以下でした。 クラウドの概念： 45 問 セキュリティ： 57 問 テクノロジー： 254 問 請求と料金設定： 51 問 そのため約100問で51%のカバーができる「クラウドの概念」「セキュリティ」だけをこのサイトでは学習しました。 こちらの学習で用語の定着の確認や覚えていないところの覚えなおしができました。 この勉強方法でよかったことは、「動画でイメージが分かってから用語を覚える」そして「他サイトも含めて定着を確認する」という流れだったので最短で受験合格ができたことだと思います。 受験 受験中 試験では私は見直しを含めて時間は最後まで使いました。 （昔からギリギリまで粘るタイプ） 難しい！とは思わなかったですが、学習中に聞いたことない用語が消去法で消せなかったり、残り２つから絞れない問題や、まったく分からない問題もありました。 一方で、ITの常識の範囲で選択肢を消去できるような問題もあり（例：自社サーバーからクラウド移行するメリットを答える問題で、選択肢で「パッチの適用が不要になる」は明らかに不正解など）落ち着いて考えればある程度絞れる問題もいくつもありました。 今回の勉強に踏まえ、このような問題で確実に点を取っていたのかなと思います。 試験結果 試験結果が早く分かります。 試験が終わってアンケートを答えた後 ---------------- この画面を保存しないでください。 ----------------- と表示されて（そもそもスマホはロッカーだし、ピアソンVUEのPCだからスクショしても意味ないけど。と思いながら）読み進めると ----------------- 「合格」 ----------------- の二文字が！！ ここまで即時に合格が分かった試験は初めてです。笑 （2023/03に受験したJSTQB_FLを受験したときでさえメールで２日後に連絡がきました） 合格証 上長とも「時代？！」と話していたのですが、合格証は送られてくるものではなく自分でダウンロードして取得するものでした。笑 AWS認定 クラウドプラクティショナーを取得して AWSは効率的なサービスがたくさんあって、世界中どこでも利用することができてホント便利！と感じました。 例えば東京と、大阪という異なるリージョンにミラーを配置することができます。複数のリージョンを利用すれば、地震など一方に大きな災害があった時、もう一方が問題なくお客様の情報を守ったり、仕事が円滑にできるなど、クラウドの必要性を知ることができました。 ※ただし東京にあるが、大阪にはないサービスがあるなどリージョン毎に提供されるサービスが異なっていたり（「 AWSサービス（リージョン別） 」で、それぞれのリージョンで提供されるサービスの確認が可能です）、料金もリージョン毎に異なるので、利用の際は確認が必要です。 また、近年日本で普及した理由の一つは新型コロナウイルス感染拡大予防のため、テレワークが急速に進められたからです。オフィス以外の場所で仕事ができる環境を整えるためクラウドサービスを利用する企業が増えたことにも納得しました。 今回の勉強で、データ保管の方法や、世界各国に配信することができることや、料金システムなどクラウドコンピューティングができることや仕組みが分かるようになりました。AWSクラウドについて知識がふえることでイマドキの世の中のクラウドのことが少しは理解することができたと思えたので受験してよかったです。 ここまで読んでいただきましてありがとうございます。 参考資料 AWS(アマゾン ウェブ 【AWS公式】 クラウド コンピューティング サービス | Microsoft Azure 無料トライアルと無料枠  |  Google Cloud The post AWSをもっと知りたくなった！AWSクラウドプラクティショナー受験体験記 first appeared on Sqripts .

2023年11月15日、 VMware （現 Broadcom ）社主催のVMware Explore 2023 Tokyo内で脅威ハンティングのコンテスト「VMware Carbon Black Threat Hunter Challenge」が開催されました。 今回は、同コンテストで並みいる強豪を抑えて個人スコア１位を獲得した、株式会社AGESTのプリンシパルアナリスト（以降Aさん）にインタビューを行いました。 ■ 脅威ハンティングのコンテスト「CTF（Capture The Flag）」とは 情報セキュリティの腕を競い合うコンテストです。CTF（Capture The Flag -旗をつかめ-）とも呼ばれ、今や世界中で開催されています。 セキュリティ関連の課題がクイズ形式で提示され、制限時間内に解いたクイズによって獲得した得点が多い方が勝利です。個人でも団体でも参加でき、勝利を目指すためのWebサイトや書籍なども存在します。 関連記事 CTFとは。情報セキュリティの腕を競うコンテスト－Capture The Flag－ 　</Sqripts> 【注釈】この記事は一部2023年11月15日時点での製品名等の表記があります。 コンテスト概要 開催概要 開催日：2023年11月15日（水）14:00～17:30　（VMware Explore 2023 Tokyo Day2） 場所：ザ・プリンスパークタワー東京「きんもくせい」ルーム 公式サイト： VMware Carbon Black Threat Hunter Challenge 競技の概要 VMware Carbon Blackを用いた脅威ハンティングを3時間で体験するコンテスト。これまで海外で多数開催されており、日本では今回が初の開催となった。 サイバーセキュリティの知識を問う問題や、VMware Carbon Black Cloudを用いた脅威ハンティングに挑戦し、時間内での獲得点数を競い合う。 参加対象は、サイバーセキュリティに興味がある・脅威ハンティングを体験してみたいといった人から、業務でVMware Carbon Blackの運用に携わる人、VMware Carbon Blackの導入を検討している人など幅広い。団体での参加が可能だが、得点は個人単位となる。 サイバーセキュリティの知識を問う問題や、VMware Carbon Black Cloudを用いた脅威ハンティングに挑戦する問題をL100-L300（初級～中級）の複数のレベルで出題している。 優勝者インタビュー。職業はセキュリティアナリスト。 編集部 ：今回は優勝おめでとうございます。まずはAさんのプロフィールをお願いします。 Aさん ：現在は株式会社AGESTでセキュリティオペレーションセンター「DH-SOC」に所属し、セキュリティアナリストをしています。 これまでの職歴としては、セキュリティアナリストを3年、その前はデータセンターのオペレーターを6年ほどしていました。 編集部 ：今回参加された「VMware Carbon Black Threat Hunter Challenge」は、どのようなコンテストだったのでしょうか。 Aさん ：VMWareのCarbon Black EDRで検知されたインシデントの調査・分析を題材にしたCapture the Flag形式の競技大会です。海外での開催実績はあるそうですが、日本で開催するのは今回が初めてと聞いています。 当社からは私と同僚の2名で参加しました。 編集部 ：参加したきっかけはどのようなものでしたか？ Aさん ：今回のCTFはVMwareさんからお誘いいただき参加しました。 過去には2回ほど別のCTFに参加していますが、いずれもあまりいい成績ではなかったので、今回もそこそこの順位までいければいいな、というぐらいの見通しでした。 コンテスト開始から途中経過発表まで 当日のタイムテーブル 編集部 ：コンテストで優勝に至る経緯をうかがいます。当日のタイムテーブルを拝見しました。日本では初めての開催とのことで、会場の雰囲気などどのように感じられましたか？ Aさん ：実は私は当日遅刻をしてしまい、オープニングやゲームの説明には参加できませんでした。ですので、開会時の雰囲気などはわからず、初めて参加する大会なのに残念な思いをしました。 遅刻した私に対しても、VMwareの担当の方が丁寧に対応してくださったので、とても助かりました。 会場についた時にはもう競技が始まっており、みなさん真剣に取り組んでいたので、途中から入るのはかなり気まずかったです。 競技中に漏れ聞こえてきた周囲の話から、参加者はアナリストだけではなさそうだと感じましたので、あまり構えずに挑みました。 表彰時に他のSOCアナリストも多く参加していることを知り、むしろ驚いたぐらいです。 SOCアナリストとは 各種ネットワーク機器やセキュリティ機器などから取得したログを監視し、サイバー攻撃やインシデントの発生を把握する役割を担っています。監視は24時間365日行われます。 インシデントの対策の立案や、実際に発生したインシデントの対処を行うこともあります。 競技の様子 （VMware社提供。※モザイク加工をしています／Sqripts編集部） 編集部 ：競技の内容について教えてください。 Aさん ：一般的な知識を問うパートが1/3、Carbon Black上で模擬的なインシデントのシナリオに基づいてアラートや検知ログからフラッグを探すパートが2/3ほどの割合でした。 一般的にSOCだと、端末と端末上の挙動だけについて詳しくなりがちですが、今回はネットワークだけではなく、ログの外部連携やAPIなどについての質問もあり、かなり広範囲について質問されている印象を受けました。 編集部 ：競技開始から1時間ほどで途中経過発表がありました。ここまでの前半での手ごたえはどのようなものでしたか？ Aさん ：スタート時点ですでに出遅れていましたので、なるべく焦らず、着実に回答可能な問題を選んで解いていきました。今回のCTFは2回のミスで不正解の扱いになるルールでしたので、とにかく失点をしないことを一番に心掛けました。 私が従事しているようなSOCの現場では、短時間で確実に分析・判断することがいつも求められていますので、普段の業務のつもりで取り組みました。 とにかく遅れを挽回することに集中していたので、ここまでは順位などもあまり気にしていませんでした。途中経過の段階では5位に届かないぐらいでしたが、これぐらいのペースで解いていけばいいかなという感触でした。 途中経過を発表した司会の方から「追い上げが凄い」とコメントをいただいたのですが、私としては実感はなかったです。 優勝インタビューではありきたりなコメントをするのが精一杯でした 編集部 ：遅れてのスタートでしたが、順調に順位を上げていたのですね。競技後半での手ごたえはいかがでしたか？ Aさん ：前半のペースを落とさず、同じような調子で問題を解いていきました。インシデントのシナリオに沿って解いていくタイプの問題が前半と比べて増えたので、前半よりも比較的容易に解けたかなと思います。 出題ではAPIや外部ログ出力に関する問題もありました。私が現在所属しているDH-SOCでは、運用を担当するチームと連携して顧客対応をすることがあります。その際に運用チームから教えてもらった知識を活用することができ、とても嬉しかったです。 夢中で問題を解いていたところ、途中で同僚から1位になっていることを教えられて、自分としてはむしろ驚きました。景品も出るという話をチラッと聞いていたので、それならもうちょっと頑張ってみようかなと。 終了の30分前ぐらいに2位の人に500点（1～2問分）程度の点差に迫られていたので、正直焦りもありました。どうにか突き放そうとして頑張って点差を稼いだのですが、最後はそのまま逃げ切り、終了することができました。 当日のスコアボード。青い線がAさん （※名前を隠す加工をしています／Sqripts編集部） 編集部 ：最終の結果では、個人スコア1位を獲得されました。おめでとうございます！ 発表時のお気持ちはどのようなものだったでしょうか。 Aさん ：そこそこの順位のつもりで参加していたので、1位が取れるとは思っておらず、正直びっくりしました。 今ここに至っても1位を取ったという実感はないです。自分のことではないみたいで…… 優勝時のインタビューでも泡食ってありきたりなコメントをするので精一杯でした。 編集部 ：競技では冷静でしたが、優勝インタビューはテンパってしまったというところでしょうか。 本当におめでとうございます。 CTFで勝つために必要なこと 編集部 ：このようなコンテストや大会は普段の業務経験が活きるのだとは思いますが、大会に向けて、普段から準備やトレーニングしていることなどはありますか？ Aさん ：特にはありません。 しいて言うなら、業務を通して幅広く知識を得ようと心掛けているぐらいです。また、普段から、端末の挙動ではなくその背後にあるユーザーや攻撃者の意図を意識するようにしています。 編集部 ：今後もこのような大会があれば出場されますか？（他社CTF含む） Aさん ：ぜひ参加したいと思っています。 自身のセキュリティ知識やアナリストの腕試しという意味もありますが、純粋に自分の知識を使って問題を解いていくのは楽しいです。 編集部 ：これから出場を目指す方に、普段から取り組むとよい勉強・トレーニングなどがあればアドバイスをお願いします。 Aさん ：自分の業務外の知識も知ろうとすることが重要だと思います。 SOCだけだとついつい端末側の知識に偏りがちですが、CTFだとフォレンジックやネットワーク、製品でも運用構築に近い部分の知識が問われることも珍しくありません。 それから、実際に分析に必要な作業を行って操作に慣れておくことも重要だと思います。競技中も調べものをすることは可能ですが、「一度経験があることを思い出すために調べる」のと、「初めての作業を調べながら、その情報を元に作業する」のでは、速度も作業精度も各段に差が出ます。 普段から、自分の担当する部分だけではなく、周辺の知識を習得したり実際に作業を行ってみることで、予想外の問題が出ても解いていく力がつくと思います。 （了） The post CTF優勝者インタビュー｜VMWare社主催「VMware Carbon Black Threat Hunter Challenge」 first appeared on Sqripts .

こんにちは。QAエンジニアのTHです。 普段からGoogle Chromeをウェブブラウザとして使用されている方は多いと思います。 このGoogle Chromeにはデベロッパーツールと呼ばれる機能があります。 一般ユーザーとしてウェブサイトを閲覧するだけの人は使うことのない機能ですが、ウェブ開発や検証においてはとても便利なツールです。ウェブ開発や検証に携わったことのある方は一度は見聞きしたことがあるのではないでしょうか？ 本記事が下記のような方にとって Chromeデベロッパーツール 使い始めの第一歩として参考になればと思っています。 - Chromeデベロッパーツールはなんとなく知っているけど何ができるのか分からない - Chromeデベロッパーツールの使い方が分からないので敬遠している - ウェブデザイン・コーディング初心者 - 意図しないブラウザ表示の原因特定や微調整に苦労している 沢山あるChromeデベロッパーツールの機能の中でも、特に基本となる「要素(Elements)パネル」の機能について紹介していきます。要素(Elements)パネルは、Chromeデベロッパーツールの中でも特に重要な機能の一つで、ウェブページの要素やDOMツリーの視覚的な表示、スタイルの編集などに使用されます。 要素(Elements)パネルを活用すると、HTML構造や、CSSでどのようなスタイル指定がされているのかを確認しながら、ブラウザ上の表示や動作のシミュレーションを即時反映で確認することができます。要素の微妙な表示位置やサイズ、色合い調整のために、HTMLやCSSをエディター画面で少しいじっては、ブラウザ画面の表示を確認する、といった作業を繰り返しているような方は作業効率がぐんと上がるはずです。 その他、本記事を読んでいただくことで以下のようなことができるようになります。少しでも皆様のお役に立てばと思いますので、ぜひ最後までお付き合いください。 - HTMLやCSS編集によるブラウザ表示の変化を即時反映で確認しながらコードを決定 - 決定したコード（シミュレーションした内容）を手軽に実ファイルへ反映 - マウスオーバー時など、特別な状態の要素を即時反映でシミュレーション確認 - 様々なデバイス端末のブラウザ表示状態をシミュレーション確認 ※本記事の執筆時のGoogle Chromeのバージョンは 117.0.5938.92 です。 ※本記事内の画像はWindowsで起動したChromeデベロッパーツールのものになります。 まずは使ってみよう 起動 まずは以下手順でChromeデベロッパーツールを起動してみましょう。 Chromeブラウザを開きます。 ブラウザウィンドウの右上隅にあるメニューアイコン（3つの垂直な点）をクリックします。 メニューが表示されたら、「その他のツール」を選択します。 「デベロッパーツール」をクリックします。※または、以下のショートカットキーでも起動することができます。　Windows/Linux：F12　Windows：Ctrl + Shift + I　Mac：Option + Command + I デベロッパーツールが表示されます。 日本語化 Chromeデベロッパーツールはデフォルトでは英語表示となります。 英語がどうにも苦手という方もいらっしゃるかと思いますが、それで利用を敬遠してしまっては非常に勿体ないので以下手順で日本語化しましょう。 ・Chromeデベロッパーツールを起動します。 ・デベロッパーツール右上に表示されているSettingsアイコン（歯車のアイコン）をクリックして、Settingsメニューを表示します。 ・Settingsメニューの「Preferences」を選択して、「Language:」の項目で「Japanese – 日本語」を選択後、右上の×ボタンで閉じます。 ・設定変更を反映するためのリロードが必要である旨のメッセージが表示されますので、「Reload DevTools」をクリックします。 ・リロード後、デベロッパーツールが日本語表示になります。 画面配置の変更 Chromeデベロッパーツールは画面配置を変更することができます。 以下手順で検証対象のウェブページや自分の好みに合わせてデベロッパーツールの画面配置を変更して使ってください。 ・デベロッパーツールの右上にあるメニューアイコン（3つの垂直な点）をクリックします。 ・メニューが表示されたら、「固定サイド」のいずれかのアイコンを選択します。選択肢には次のものがあります： 固定を解除して別ウィンドウに表示：デベロッパーツールを独立したウィンドウとして表示します。 左に固定：デベロッパーツールをブラウザウィンドウの左側に固定表示します。 下部に固定：デベロッパーツールをブラウザウィンドウの下部に固定表示します。 右に固定：デベロッパーツールをブラウザウィンドウの右側に固定表示します。 要素(Elements)パネルの基本的な使い方 ここからは、本題の「要素(Elements)パネル」でできることについて記載していきます。 HTMLやCSSの表示を確認したり、加えた変更をシミュレーションしながら最終的なファイル更新を行う、といった活用の仕方の例を紹介していきます。 DOMツリー表示と要素選択 要素パネルでは、ウェブページのDOMツリーが表示されます。DOMツリーは、ウェブページの要素の階層構造を示しており、子要素と親要素の関係を視覚的に確認することができます。DOMツリーは展開/収納することもできます。 また、要素パネルの上部にあるポインターのアイコンをクリックすることで、ウェブページ上の要素を直接選択することもできます。 ［1］デベロッパーツール左上の「ページ内の要素を選択して検査」アイコンをクリックします。アイコンが青色になっている時は要素の選択モードになっている状態です。 ［2］そのままウェブページの表示画面のほうにカーソルを移動して要素上にかざすと、その要素がハイライト表示され、ポップアップ表示でタグの種類やクラス名、要素のサイズが確認できるようになっています。 ［3］さらに検証ツール画面のほうでも連動して該当要素のコードをハイライト表示してくれます。 ［4］DOMツリー上のハイライト表示箇所をクリックして選択すると検証ツールの画面でそのままその要素の詳細（CSSでどのようなスタイルが適用されているか等）を詳しく確認できます。 スタイルの編集 要素パネルの最も多い使い方としては、実際のブラウザ上での表示の変化を見てシミュレーションしながらCSSの指定の仕方を決めたり、CSSの記述が効いていない場合に何が原因で上手くいかないのかを検証ツールで確認したりするケースかと思います。 ［1］スタイルタブでは、選択中の要素に対して効いているCSSのスタイル指定が一覧で確認できます。プロパティ指定の一つ一つに対してチェックを付けたり外したりできるようになっており、この指定がなかった場合、または、あった場合、というようなシミュレーションができます。 ［2］プロパティに書いてないものを追加することもできます。プロパティ欄をクリックすることで新しいプロパティ指定を増やせるようなモードになります。この状態で何かプロパティを追加した場合どう変わるかといったシミュレーションをしながらコードを決めることができます。 例として「Google」表示の要素に対して「BACKGROUND-COLOR」のプロパティ指定を追加すると、実際の画面にその背景色が反映され、どのような表示になるかをシミュレーションすることができます。 ［3］また、element.style欄にプロパティ指定を追加することで、タグ名やクラス名等のセレクタ指定があるCSSでのスタイル指定ではなく、選択中の要素一つ一つに対して直接プロパティ指定をすることもできます。element.style欄で記載した内容は、個別にHTMLの要素の中に直接インライン指定でスタイル属性が追記されます。ある特定の個別要素に対して表示の検証がしたいような場合にはこちらが便利です。 ここで注意点です。 検証ツール上での変更は、あくまでシミュレーションなので実際のファイル内容が書き換わることはありません。ブラウザでのページ再読み込みやクローズで検証ツール上でのシミュレーション内容は全て消えてしまいます。 反映する場合には同じ内容を実際のファイルに書き写して更新する作業が必要になりますので忘れないようにしましょう。 inspector-stylesheet を利用したスタイル編集 上記の通り、実際にシミュレーションした内容を反映させるためには記載内容の実ファイルへの書き写しが必要となりますが、この作業を少し楽にしてくれる方法として、inspector-stylesheetを利用したプロパティ指定の方法があります。ここではその方法を紹介していきます。 この inspector-stylesheet とは、簡単に言うと検証用に一時的に読み込むためのCSSファイルになります。 ［1］スタイルタブ右上にある「新しいスタイルルール」アイコン（プラスマークアイコン）をクリックすると、選択中要素のタグ名やクラス名などのセレクタ指定で自動で inspector-stylesheet のブロックが生成されます。自動で生成されたセレクタの内容が意図したものではない場合には編集して修正も可能です。 ［2］この inspector-stylesheet のブロックにプロパティ指定を追記できます。この場合は、先程のelement.style欄でのプロパティ指定とは違い、HTMLの要素には直接インライン指定でのスタイル属性は追記されません。 ［3］続けて他の要素を選択して、同様にスタイルタブ右上にある「新しいスタイルルール」アイコン（プラスマークアイコン）をクリックして、inspector-stylesheet のブロックでプロパティ指定を追記します。 ［4］ここで、inspector-stylesheet のブロック右上にある「inspector-stylesheet：数字」の表示をクリックしてみます。各ブロック右上のこの欄には、そのブロックに表示されているスタイル指定が実際に記載されているCSSファイルの名前が表示されています。またファイル名の後のコロン記号に続く数字はCSSファイルの何行目にそのスタイル指定の記載があるかが表示されています。 ［5］表示が要素パネルからソースパネルへと変わり、inspector-stylesheet(検証用に一時的に読み込むためのCSSファイル)に記載されている内容を全て確認することができます。 今回は、上記の手順2と手順3で、inspector-stylesheet に追記した内容をまとめて確認することができ、その内容をまとめて選択してコピーすることが可能です。つまり、inspector-stylesheet を利用してシミュレーションをした場合には、全ての表示確認を終えてから実際のファイルに反映させる時にも、こちらのソースパネルから纏めてコピペができることになります。 hover要素のスタイル編集 ウェブサイトにはマウスオーバー時（hover時）に表示スタイルが変わる仕様のボタン等が数多く存在します。 例えば、Googleトップページでは下記キャプチャのように「Googleアプリ」アイコン（9つの点でできたブロックアイコン）は、hover時とそれ以外で表示が切り替わります。 ・通常時（9つの点でできたブロックアイコンのみ表示） ・hover時（円形のグレー背景が追加表示される） 当たり前ですが、ブラウザ上の表示はマウスオーバー時にはhover時表示に変わりますが、マウスを動かしてしまうと通常表示に戻ってしまいます。なので、このhover時のスタイル指定編集を実際のウェブページ上でシミュレーション確認しながら実施するには特別に表示設定を固定する必要があります。 この方法が少し分かりづらいのでここで説明しておきます。 ［1］確認したい要素を選択した状態で、スタイルタブの「:hov」をクリックして「要素の状態を強制」メニューを表示します。 ［2］「要素の状態を強制」メニューで「:hover」のチェックをオンにします。 チェックをオンにするとブラウザ上の表示がマウスオーバーしているいないに関わらずhover時の表示で固定されます。 また、該当要素のコードの左上にはhover表示固定であることを示すオレンジ丸のマークが表示されます。 そして、スタイルタブには、該当要素のhover時のプロパティ指定が表示されて編集が可能になります。 ［3］この状態であれば、hover時のスタイル指定を編集してブラウザ上での表示をシミュレーションすることができます。 また、「要素の状態を強制」メニューには、hover以外にも機能がありますので、ここでhoverも含めて簡単に説明しておきます。 それぞれ、hoverと同様の手順で各状態のスタイル編集をシミュレーションできます。 active：クリックされた状態 hover：マウスオーバー時の状態 focus：テキストエリアやテキストフィールドが選択された状態 visited：過去に訪問したことのあるリンク色の状態 focus-within：テキストエリアやテキストフィールドが選択された状態（focusとの違いは一つの入力欄だけでなくフォーム全体の状態であること） focus-visible：タブキー操作などのキー操作で選択している状態 target：アンカーリンクなどのリンク先に適用される状態 デバイスモードでの表示確認 デバイスモードはウェブぺージをさまざまなデバイスや画面サイズで表示するための機能になります。これにより、モバイルデバイスでの表示やレスポンシブデザインのシミュレーションが容易になります。また、実際のデバイスでの操作同様に画面のスクロールやタッチイベントのシミュレーションも可能です。 デバイスモードを使用する手順は以下の通りです。 ［1］デベロッパーツール左上の「デバイスのツールバーを切り替え」アイコンをクリックします。ウェブページ表示画面がデバイスモードの表示に切り替わり、上部にはデバイスツールバーが表示されます。 ［2］デバイスツールバーの中央にあるサイズ欄をクリックすると、利用可能なデバイスやプリセットが表示されます。確認したいデバイスを選択すると、ウェブページが自動的にリロードされ、選択したデバイスでの表示に切り替わります。その状態でデバイス固有の表示問題の特定などを行うことができます。 ［3］表示されたデバイスリスト一番上の「レスポンシブ」を選択した場合には、特定機種のサイズではなく自由に横幅と縦幅を設定して表示を確認することができます。 表示されたデバイスリストで「編集」を選択した場合には、エミュレート対象のデバイスリストが表示され、リストに表示または非表示にするデバイスを選択することができます。 さらに「カスタムデバイスを追加」ボタンをクリックすると、任意に画面サイズを設定したデバイスを追加することも可能です。 ただ、非常に便利なデバイスモード機能ではりますが、あくまでもシミュレーション用になります。この機能を使って確認をしながらデザイン実装を進めた後に、最後は必ず実機での検証確認をお勧めします。 おわりに 今回ご紹介した要素(Elements)パネルの機能は基本的なものばかりですが、ウェブページの表示や、各要素のスタイルを確認したり変更したりする際にとても役立ちます。 意図しないブラウザ表示の原因特定や微調整など、HTMLやCSSエディターでの編集作業とブラウザの表示確認で、繰り返しの画面切り替えが発生して時間をロスしているような方は、Chromeデベロッパーツールを使うことで画面表示を予めシミュレーションして作業を効率的に実施することができるようになりますので、ぜひご活用ください。 また、Chromeデベロッパーツールには、他にも多くの機能があります。この記事がデベロッパーツール利用の機会となれば嬉しいです。機会があれば今回ご紹介できなかった他パネルについてもご紹介していければと思います。 こちらの記事もおすすめ Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう The post Chromeデベロッパーツールを使ってみよう｜要素（Elements）パネル編 first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 最終回となる今回は、過去の連載記事で紹介しきれなかったDune（分析ツール）のTips的な有用機能や、分析のための高度なSQL構文についてご紹介します。 Dune Tips DuneのようなSQLベースの分析ツールは、SQLで記述されたクエリを再利用するためのさまざまな有用機能が実装されていることが多くあります。その中でも、多くの分析ツールで頻繁に使用されるパラメタ化機能やビュー作成機能についてご紹介します。 Parameters SQLクエリ中の絞り込み条件に含まれる、時刻や特定の文字列などの値を、パラメタ化して実行時に指定できるようにしたり、パラメタだけを変えて同じクエリを何度も実行したりしたいことがよくあります。Duneの場合、パラメタ化したい箇所に名前をつけて {{ }} で囲うことで、簡単にパラメタの外部化を実現できます。コード1に、uniswapという分散取引場の取引履歴から、トークンペアの種類をパラメタで指定して集計を実行するクエリ例を示します。 コード1 . token_pairをパラメタ化したクエリ例 SELECT token_pair, COUNT(1) AS cnt, SUM(amount_usd) AS total_amount_usd FROM uniswap_v3_ethereum.trades WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' AND token_pair = '{{token_pair}}' GROUP BY token_pair LIMIT 100 パラメタ化した箇所のデータは、図1に示すような設定画面で、データ型を指定したり、選択肢を設定したり、他のクエリの出力結果をパラメタとして設定したり、といったカスタマイズが可能です。パラメタ化機能をうまく活用することで、ひとつの汎用的なクエリを用いて、さまざまな切り口からのデータ分析をおこなうこともできます。 図1. パラメタの詳細設定画面 Query Views 過去の記事でも解説した通り、関係演算の閉包性により、SQLクエリの出力結果は別のSQLクエリの入力（FROM句に指定するテーブル）になることができます。それは、WITH句を用いてひとつのクエリ内で名前付けしたテーブルを再利用するだけでなく、異なるクエリ間でも再利用が可能です。 SQL自体の機能にも、「CREATE VIEW」などの構文を用いて、クエリ結果をテーブルとして扱うことができるビューを定義する機能があります。Duneの場合は、クエリエディタで作成し保存したクエリには自動的にIDが振られるため、そのIDを用いてさらに簡単にクエリ結果の参照ができます。 例えば、 https://dune.com/queries/3238025 というURLでアクセスできるクエリの結果をSQLで利用するには、URLに含まれる queries/ 以下のクエリIDを用いて、「query_3238025」といったテーブル名で参照するだけです。 図2. ビューとして参照したいクエリ（ https://dune.com/queries/3238025 ）の実行例 コード2 . クエリID: 3238025のビューを参照するクエリ例 SELECT * FROM query_3238025 図3. コード2の実行結果（図2と同様の出力結果になる） 自身が作成したクエリだけでなく、他のユーザーが作成し公開しているクエリも簡単に参照できるので、オンラインコミュニティ全体で共創的なダッシュボード開発が実現できることも、Duneのサービスの魅力です。 分析のための高度なSQL 最後に、Window関数やCASEほど頻出ではないものの、SQLの表現力を拡大させる高度な構文として、ROLLUP（超集合）やWITH RECURSIVE（再帰クエリ）の使い方をご紹介します。 ROLLUP ダッシュボードやレポートを作成する際、カテゴリごとの集計と、それらを合算した小計、全体の合計などを一度に表示したい場合があります。SQLの場合、同じカラムを持ったテーブル同士をUNIONまたはUNION ALL句で連結することで、一つのテーブルにまとめることができるため、UNION句を用いて小計・合計を含むレポートを作成することができます。 コード3 . UNION ALL句を用いて、Ethereum Traceデータの種類ごとの件数と合計を同時に取得するクエリ WITH target_traces AS ( SELECT * FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' ) SELECT 'ALL' AS type, count(1) AS cnt FROM target_traces UNION ALL SELECT type, count(1) as cnt FROM target_traces GROUP BY type 図4. コード3の出力結果 しかし、同じテーブルに対して複数のSELECT文を実行し、UNIONで連結するのは、実行コストが高く、記述も冗長になりがちです。そこで、GROUP BY句にROLLUP句を指定することで、全体の合計と小計を同時に計算することができます。 コード4 . コード3と同様の内容をROLLUP句で実現したクエリ SELECT type, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY ROLLUP(type) 図5. コード4の出力結果 また、ROLLUP句には複数のカラムを指定することもできます。ROLLUP句に複数のカラムを指定した場合、指定した順に応じて小計のグループが細分化されます。例えば、コード5に示すとおり、ROLLUPにtypeとsuccessという2つのカラムを指定した場合、まず冒頭に指定したtypeをもとに小計と合計が計算され、さらにsuccessの中身に応じて細分化された小計が計算されます。2つ目に指定したsuccessのみに応じて細分化された小計（この場合はsuccess=trueのレコード全体とsuccess=falseのレコード全体の小計）は計算されないことに注意してください。 コード5 . ROLLUPに複数カラムを指定するクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY ROLLUP(type, success) 図6. コード5の出力結果 もし、指定したカラムのすべての組み合わせに対する小計を計算したい場合は、ROLLUPではなくCUBE句が利用できます。コード6に示したCUBE句によるクエリ例では、図7に示すとおり、2番目に指定したsuccessカラムだけに基づく小計も計算されています。 コード6 . コード5のROLLUPをCUBEに書き換えたクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY CUBE(type, success) 図7. コード6の出力結果 よりカスタマイズされた条件に基づく小計を計算したい場合、GROUPING SETS句を用いることもできます。GROUPING SETS句には、GROUP BYの対象としたいカラムの組み合わせを列挙して指定することができます。「ROLLUP(c1, c2)」という記述は「GROUPING SETS( (c1, c2), (c1), () )」に等しく、「CUBE(c1, c2)」という記述は「GROUPING SETS( (c1, c2), (c1), (c2), () )」に等しくなります。 コード7 . コード5のROLLUPをGROUPING SETSで書き換えたクエリ例 SELECT type, success, count(1) AS cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' GROUP BY GROUPING SETS( (type, success), (type), () ) 図8. コード7の出力結果 WITH RECURSIVE SQLには、手続き型プログラミング言語のfor文のような繰り返し処理のための構文がないため、逐次処理が苦手と思われがちです。しかし、WITH句のなかで自分自身のテーブルを参照できるWITH RECURSIVE（再帰クエリ）を用いると、無限ループを含む繰り返し処理をSQLで実行することも可能です。 コード8に、WITH RECURSIVEを用いてフィボナッチ数列を計算するクエリ例を示します。WITH RECURSIVEの基本構文は、UNION ALL句を用いて2つのSELECT文を結合し、1つ目のSELECT文では繰り返しの起点となるレコードを指定し、2つ目のSELECT文で繰り返し中の計算処理と終了条件を指定します。 コード8 . WITH RECURSIVEを用いてフィボナッチ数列を計算するクエリ例 WITH RECURSIVE fib (x, a, b) AS ( SELECT 0, 0, 1 UNION ALL SELECT x + 1, b, a + b FROM fib WHERE x < 10 ) SELECT x, a FROM fib; 図9. コード8の出力結果 WITH RECURSIVEを用いた実用的なクエリ例として、暗号資産の取得価額を移動平均法によって計算するクエリをコード9に示します。暗号資産の取得価額の計算方法については、国税庁による「 暗号資産に関する税務上の取扱いについて（ＦＡＱ） 」（pp.15-16）の事例を参照します。 コード9 . WITH RECURSIVEを用いて、移動平均法による暗号資産の取得価額を計算するクエリ WITH RECURSIVE t (id, btc_balance, trade_time, trade_type, trade_amount, btc_amount, jpy_amount) AS ( SELECT ROW_NUMBER() OVER(ORDER BY trade_time) AS id , SUM(btc_amount) OVER(ORDER BY trade_time) AS btc_balance , * FROM query_3238025 ) , moving (id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, btc_moving_avg_price) AS ( (SELECT id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, 1.0 * abs(jpy_amount) / btc_amount AS btc_moving_avg_price FROM t WHERE id = 1) UNION ALL (SELECT t.id, t.trade_time, t.trade_type, t.btc_amount, t.jpy_amount, t.btc_balance, CASE WHEN t.trade_type = 'Sell' THEN moving.btc_moving_avg_price ここでのサンプルデータは、下記のような内訳でビットコインの購入と売却をおこなった場合を想定します。このサンプルデータは、図2に示したクエリ（ https://dune.com/queries/3238025 ）から参照できます。 3月1日 4 BTCを 1,845,000円で購入 保有数量 4 BTC 6月20日 2 BTCを 1,650,000円で購入 保有数量 6 BTC 7月10日 2 BTCを 2,400,000円で売却 保有数量 4 BTC 9月15日 0.5 BTCを 542,800円で購入 保有数量 4.5 BTC 11月30日 3 BTCを 2,895,000円で売却 保有数量 1.5 BTC コード9のクエリを細分化して解説します。まず、サンプルデータには取引時点での保有BTCの残高を示すカラムがないので、Window関数を用いて累計のBTC残高を計算します。また、取扱を簡単にするため、取引履歴順に連番のIDを付与します（コード10）。 コード10 . BTC取引履歴の前処理部分 SELECT ROW_NUMBER() OVER(ORDER BY trade_time) AS id , SUM(btc_amount) OVER(ORDER BY trade_time) AS btc_balance , * FROM query_3238025 移動平均法を用いた暗号資産の平均単価は、「取引時点で保有する暗号資産の簿価の総額 / 取引時点で保有する暗号資産の数量」で計算されます。 例えば、3月1日時点でのビットコインの平均単価は、ビットコインの簿価の総額が1,845,000円であり、保有するビットコインの数量が 4 BTCなので、1 BTCあたりの平均単価は 1,845,000 / 4 = 461,250円となります。コード11に示す再帰クエリのなかでは、UNION ALL句の前側のSELECT文で、この計算をおこなっています。 続いて、6月20日時点の場合を計算します。この時点でのビットコインの簿価の総額は、過去に保有しているビットコインの簿価＋新規購入額となります。すなわち、上記で計算した平均単価461,250円 × 保有ビットコイン 4 BTC + 新規購入額 1,650,000円 ＝ 3,495,000円です。また、この時点で保有するビットコインの数量は 6 BTCなので、1 BTCあたりの平均単価は 3,495,000 / 6 = 582,500円となります。この計算は、コード11においては「WHEN t.trade_type = ‘Buy’ THEN～」に続く箇所で計算しています。 7月10日の取引は、保有しているビットコインの売却なので、平均単価には影響せず、1 BTCあたりの平均単価は6月20日時点と同じ582,500円となります。コード11においては「WHEN t.trade_type = ‘Sell’ THEN」に続く箇所が、該当する計算箇所です。 9月15日の取引では、新たに 542,800円分のビットコインを購入し、合計4.5 BTCを保有していることになるので、平均単価は （582,500円 × 4 BTC + 542,580円）/ 4.5 BTC = 638,400円となります。 11月30日の取引では、ビットコインの売却のため平均単価には影響せず、同じく638,400円が1 BTCあたりの平均単価です。 コード11 . 移動平均法を計算する再帰クエリの中核部分 (SELECT id, trade_time, trade_type, btc_amount, jpy_amount, btc_balance, 1.0 * abs(jpy_amount) / btc_amount AS btc_moving_avg_price FROM t WHERE id = 1) UNION ALL (SELECT t.id, t.trade_time, t.trade_type, t.btc_amount, t.jpy_amount, t.btc_balance, CASE WHEN t.trade_type = 'Sell' THEN moving.btc_moving_avg_price WHEN t.trade_type = 'Buy' THEN (moving.btc_balance * moving.btc_moving_avg_price + abs(t.jpy_amount)) / t.btc_balance END AS btc_moving_avg_price FROM moving JOIN t ON moving.id = (t.id - 1) ) このように、前の計算結果を引き継いで次の計算をおこなう必要がある場合、WITH RECURSIVEによる再帰クエリが力を発揮します。上記の説明文で計算したビットコインの平均単価と、図10に示す計算結果が一致していることを確認してみてください。 図10. コード9の出力結果 まとめ 全8回の連載を通じて、ブロックチェーンの基本的な仕組みの解説と、代表的なブロックチェーンであるビットコインとイーサリアムのデータ構造の解説、および、SQLを用いたオンチェーンデータ分析の演習をおこないました。これからSQLを用いてデータ分析の技術を磨きたい人にとって、ブロックチェーンのオンチェーンデータは手軽にアクセスできるリアルなデータソースとしておすすめです。また、ブロックチェーンに関する知識を深めたい人にとっても、自分でSQLを記述しながら実データを分析するプロセスは非常に有益です。本連載を通じて、読者の皆様がSQLやブロックチェーン技術の魅力を発見する一助となれば幸いです。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習1 【第6回】Ethereumデータ分析演習2 【第7回】Ethereumデータ分析演習3 The post 【第8回】Ethereumデータ分析演習4 first appeared on Sqripts .

こんにちは！　テストエンジニアのマツキョーです。 第三者検証会社のテストエンジニアは、様々なプロジェクトに途中から参画することが多くあります。プロジェクトに参画したテストエンジニアは、まず仕様把握という作業から着手していきます。 仕様把握では、テスト対象となるシステムの要件や仕様が記述されたテストベースが必要になります。すでに開発が進んでいるプロジェクトでは、当然ながらテストベースの量も膨大になっています。そのためテストエンジニアは、膨大なテストベースを確認・理解してテスト設計をする必要があります。 ですが、純粋にテストベースの確認と理解だけに使える時間は限られています。 プロジェクトの体制にもよりますが、多くの場合はキャッチアップ期間として1日～数日、それ以降はテスト分析・設計作業と並行して仕様把握を進めていきます。何も知らないところから、膨大なテストベースを短期間で読み解いて仕様を理解し、品質を担保するために最適なテスト設計を行うのです。 やりがいのある仕事ではありますが、テストエンジニアも人間なので当然プレッシャーが掛かります。むしろ、品質のプロだからこそ感じる不安がプレッシャーの原因と言えるかもしれませんね。 品質保証の業務に従事して10年以上経つ私でも、プロジェクトに参画して仕様把握を始める時は不安を感じます。 この記事では、仕様把握という作業について再認識するところから始め、テストエンジニアの正直な内心にフォーカスしたのち、それを克服して効果的な仕様把握を行うためのコツを紹介したいと思います。 日々品質の守護者として戦うテストエンジニアたちが、不安やプレッシャーに打ち勝ち、より良い品質のために行動する助けになれば幸いです。 仕様把握とは？ 仕様把握とは、言葉のとおり仕様を把握していく作業です。 テストプロセスにおける テスト分析 の作業の1つで、テスト設計の情報源であるテストベースを読み解いて理解していきます。 文字に起こすと簡単そうですが、重要なのは 「理解する」 の部分にあります。この 「理解する」 という作業は、ドキュメントに書かれた内容を覚えるだけの作業ではありません。 仕様として明記されていない情報がないか？ ユーザーの利用シーンはどのような状況か？ 他の機能や外部システムとの連携はあるか？ このような問いを自分の中に持ち、想像力を膨らませながらテストベースを読み解いていく必要があります。なぜなら、 テストベースに書かれていない部分に多くの欠陥が潜んでいる と考えられるからです。 そうして読み解いた内容からテスト設計に必要な情報を選別していき、テスト分析という工程を通じて「何をテストするか？」であるテスト条件を定義していきます。 品質を担保するために必要な情報を得るため、 適切な広さ・深さで仕様を熟知していく作業 がテストエンジニアにとっての仕様把握です。 テストエンジニアの内心 プロジェクトに参画したテストエンジニアが、最初に取り掛かる作業が仕様把握です。仕様把握は、膨大なテストベースを読み解いてテスト対象への理解を深めていく作業です。 私たちはプロなので、お客様のご都合に合わせた期間で必要な情報を集め、理解し、テスト設計に活用して品質に貢献します。だからこそ、テストエンジニアは仕様把握を行うときに以下のような不安を感じます。 効率の良い順番でテストベースに手をつけられるだろうか？ テストベースの内容をスムーズに理解できるだろうか？ テスト設計に必要な情報を期日までに収集できるだろうか？ この不安の裏には、品質のプロとして 「テスト対象を深く理解してテストを設計し、高品質の実現に貢献したい」 という想いがあります。その想いが自身にプレッシャーという形で降りかかってくるのです。 プレッシャーというとデメリットのように捉えがちですが、テストエンジニアにとってはデメリットだけではありません。このプレッシャーに打ち勝つために、知識を身につけ、技術を磨き、創意工夫することで、私たちは成長していくからです。 仕様把握のコツ５選 仕様把握のコツを紹介する前に、まず 仕様把握 という作業を分解してみます。 仕様把握は、 インプット、アウトプット、コミュニケーション という3つの要素に分けられると考えています。 インプット　　　　 …　テストベースから情報を集めること アウトプット　　　 …　インプットした情報を理解して整理し可視化すること コミュニケーション …　会話により情報への理解を深めたり共通認識を作ること この3つの要素を繰り返し行うことで、テスト対象の仕様理解が進み、テスト設計に必要な情報が明らかになっていきます。 これら3つの要素を前提に、私が仕様把握をするときに大事にしているコツを紹介します。 1. ステークホルダーと密にコミュニケーションをとる ステークホルダーとは「プロジェクトに関わる利害関係者」のことです。開発エンジニア、プロジェクトマネージャー、デザイナーなど、そのシステムの開発プロジェクトに関わる人たちを指します。私たちテストエンジニアもステークホルダーの1人です。 仕様把握を効果的に行うには、テストの目的、品質の目標、QA方針といったプロジェクト毎に存在する 決まり事 を知っておく必要があります。また、仕様把握やテスト設計を進める中で、疑問や不明点は必ず出てきます。 これらの 決まり事 を確認したり、疑問や不明点を解消するための、唯一の方法が 他のステークホルダーとのコミュニケーション です。私たちはコミュニケーションを通じて、情報の共有・質問・相談を重ねることで、仕様に対する理解を深め、曖昧さや抜け漏れを解消し、共通認識を作っていくことができます。 この後も仕様把握のコツを紹介していきますが、仕様把握において コミュニケーションを密にとる ということが最も重要なコツであることを、まずお伝えしておきます。 2. 主軸とするテストベースを決める 仕様把握はテストベースを読み解く作業ですが、手当たり次第にドキュメントを読み漁ればいいわけではありません。限られた時間の中で必要な情報を効率よく集めるためには、木の幹となるテストベースを決めておくことが重要です。 V字モデルを例に考えた場合、受入テストは「システムが要求を満たしているかを確認するテスト」なので 要求分析の結果 、システムテストは「システムが要件を満たしているかを確認するテスト」なので 要件定義 を主軸のテストベースとするのが一般的です。 このように、テストの目的に合わせて最適なテストベースを主軸に据えることで、確認するテストベースの優先順位を決めたり、どの程度の理解度が必要かの判断ができるようになります。 注意点として、受入テストやシステムテストといった用語は、組織やプロジェクトによって意味合いが異なる場合があります。なので、ここでもステークホルダーとのコミュニケーションで共通認識を作っておくことが重要になります。 3. 全体を俯瞰できるテストベースから着手する 主軸のテストベースが決まったら、早速そのテストベースから仕様把握を進めたくなりますよね。でも、焦ってはいけません。仕様を効率的に理解するには、どのようなテストベースから確認していくかも重要になります。 では何から着手するのが良いかというと、オススメは画面遷移図やDFD（データフローダイアグラム）といった システム全体を俯瞰して見ることができるテストベース です。 システムの全体像が見えていると、上から下、大から小といった流れでシステムの理解を進められます。このような流れで仕様把握することには、その画面や機能がシステム全体の中でどのような役割を持っているか、ユーザーがどのようにして利用するかといった部分の理解がしやすくなるというメリットがあります。 テストエンジニアは、テストベースに明記された仕様だけでなく 暗黙の仕様 にも配慮します。 暗黙の仕様 とは、ドキュメントに明記されていない隠れた仕様のことです。 システム全体を理解することは、その画面や機能が果たす役割やユーザー視点での理解を助け、要件や仕様の抜け漏れ、隠れたユースケースといった 暗黙の仕様 の発見に繋がります。 システム全体を頭の中でイメージして、テスト対象の振る舞いをシミュレーションできるようになれば仕様把握の上級者です。 4. ドキュメントを読むだけでなく、アウトプットして整理する 仕様把握は、概ねがドキュメントを読む作業です。しかしドキュメントを読むだけで仕様を理解したとするのは、私の経験上おすすめできません。 私たちは、品質保証を目的としたテスト設計をするために仕様把握をしています。前項でも書いたように、ドキュメントに明記された仕様だけでなく暗黙の仕様にも配慮する必要があります。暗黙の仕様を見つけるためには、システム全体を理解しながら仕様把握を行うことが重要ですが、システム全体を頭の中だけで理解していくのは無謀な行いです。 効果的に仕様把握を進めるためには、 理解したことをアウトプットして情報を整理していく ことが重要になります。アウトプットと言っても闇雲にメモすればいいわけではありません。ロジカルにアウトプットすることが仕様の理解を深める助けになります。 ロジカルシンキングという言葉を耳にしたことのある方は多いでしょう。ビジネススキルの定番とも言える思考法で、物事を論理的な繋がりで考えるスキルです。テストエンジニアにとっても優先的に身に着けたいスキルですね。 このロジカルシンキングには、基本的な概念とは別に、様々な思考を補助するツールや技術があります。詳しく書くと長くなってしまうので、ここでは概要と仕様把握におけるメリットに絞って、私がよく利用しているモノを紹介します。より詳しく知りたい方は、書籍やネットで調べてみてください。 ロジックツリー ロジックツリーは、情報を特定のロジックでツリー状に分類して整理するツールです。仕様把握におけるメリットは、画面や機能をツリー構造で整理できることです。画面や機能の関係性が視覚化されてわかりやすくなります。 ですが、ロジックツリーだけでは暗黙の仕様を見つけるには少し足りません。暗黙の仕様を見つけるためには、暗黙の仕様を見つけるための 問い が必要だからです。この 問い を考える時に活用できるのが、次に紹介する2つのスキルです。 フレームワーク思考 フレームワーク思考は、情報をフレームにあてはめて分解・深堀りするためのスキルです。仕様把握におけるメリットは、仕様の抜け漏れを発見しやすくなることです。特定の基準で作った枠組み（フレーム）に仕様をあてはめながら整理するので、仕様に抜け漏れがあると枠が埋まらないため、すぐに気づけます。 例えば、時間に関する機能があれば「過去」「現在」「未来」というフレームを作り、テストベースの情報をそのフレームにあてはめて情報を整理します。最後まで空欄の枠があれば、仕様の考慮漏れや記述漏れの可能性がありますので、ステークホルダーに確認してみましょう。 仮説思考 仮説思考は、現時点の情報から可能性の高い仮説を立てて検証していくスキルです。仕様把握におけるメリットは、隠れた要件やユースケースを発見しやすくなることです。現時点の仕様から導き出した仮説から、明記されていない仕様について検討することで、隠れた要件やユースケースに気づくことができます。 例えば、ユーザーを管理する機能があるとしましょう。管理者が管理するユーザー数をシステム上の最大ユーザー数であると仮定した場合、性能要件がどうなっているか、検索機能や一括処理機能などのユーザビリティに配慮しているかといった疑問が浮かびます。テストベースからその疑問の答えが見つからない時は、隠れた要件やユースケースである可能性がありますので、ステークホルダーに確認してみましょう。 このようにツールやスキルを利用してアウトプットしながら仕様把握を進めることで、テストベースに書かれたことを理解するだけでなく、システムが実現したい本来の姿を明らかにできます。 今回紹介した以外にも、思考を整理したり、情報を分析するためのスキルやツールはたくさんありますので、ぜひ色々試して自分にあった武器を身に着けてください。 5. 自分ひとりで考えない 最後のコツは、 誰かと一緒に考える ということです。 技術職の方には、自分ひとりで黙々と作業するのが好きな方が多いのではないでしょうか。集中して作業することはとても良いことですが、ひとりで考えていると壁に当たった時になかなか抜け出せないこともあります。 システム開発には多くの人が関わっていますので、チームの同僚やステークホルダーと積極的に話してください。 自分の考えたことや気づいたことを、誰かに伝えることで共通認識ができたり、別の角度からの意見が貰えることもあります。また考えがまとまらないときには、誰かに話すことでスルっと思考が整理されたり、新たな気づきを得られる場合もあります。 人と話すことは、最も手軽で効果的なアウトプット です。チームメンバーやステークホルダーに自ら話しかけ、協力関係を育んで、より良いプロダクト品質のために行動しましょう。 さいごに 仕様把握が効果的に行えると、それに比例してテスト設計の品質も高まります。 テスト設計の品質は、高度な仕様把握に基づいたテスト分析によって作りこまれるからです。 今日もどこかのテストエンジニアが、未知のシステムを前に勇気を出して仕様把握の一歩を踏み出していることでしょう。私のこれまでの些細な経験から得られたコツが、少しでも彼らの一歩の助けになり、世の中のプロダクト品質に貢献できれば幸いです。 The post 良い仕様把握は良い品質に繋がる ～仕様把握をする時のコツ ５選を紹介～ first appeared on Sqripts .

こんにちは。プロダクトチームで品質改善に取り組んでいる、QA Maestro K.O.と申します。 自社製品やサービスの売上げを伸ばす方法について悩み、日々奮闘している企業は多いのではないでしょうか。 競争が激化するビジネス環境において、ユーザーの期待を上回る品質は市場を制する鍵になり得ます。 自社が提供するサービスを自らが使用し、その品質を常に向上させることは、顧客満足度向上に繋がり、競争優位性を築く秘訣となるでしょう。 この記事では、サービスの品質向上のための有効な施策の一つである「ドッグフーディング」について詳しくご紹介します。 また、QAエンジニアが行うドッグフーディングについても記載しました。 売上にお悩みの方や、製品の価値を高めたいQAエンジニアの方のご参考になれば嬉しく思います。 ドッグフーディングとは ドッグフーディングとは、製品やサービスの開発者や内部関係者が、自らが開発した製品を実際に使用し、評価するプロセスです。つまり、開発者や関係者が、自分たち自身で一般のユーザーと同じように製品を利用し、その品質や性能を評価し、改善に役立てることを指します。 「ドッグフーディング」という名前の由来 由来は諸説あるようですが、ドッグフードの販売を手がける企業の社員が、自分が飼っていた犬にドッグフードを食べさせていたというエピソードが語源と言われています。 その後、Microsoftの従業員の一人が、自社の製品を自分たちで使うアイデアを説明する際に「Eating our own Dogfood」という比喩的な表現を用いたことから、「ドッグフーディング」という用語が社内で広まり、「ドッグフーディング」は内部での製品使用と評価を指す言葉として広く受け入れられるようになりました。 では、自社製品やサービスを自ら利用することにどのような意義があるのでしょうか。 ドッグフーディングのメリット ここでは、ドッグフーディングを実施するメリットとして広く知られているものをいくつかご紹介していきます。 製品品質と顧客満足度の向上 開発者や企業内のステークホルダーが日常的または正式リリース前に自社の製品を利用することで、ユーザーエクスペリエンスにおいて発生する潜在的な問題や改善点を直感的に把握できます。 これにより、不具合や改善点を事前に発見し、顧客がより満足するであろう製品品質に近づけることができます。 高い品質を備えた製品はユーザーに信頼感を与え、顧客満足度の向上も期待できるでしょう。 また、製品の品質や顧客満足度の向上は、競争の激しい市場で競合他社との差別化を図るための重要な要素となります。 競争優位性の確立 自社の製品を積極的に利用することで、他社製品との差別化ポイントや自社製品の優れたユーザーエクスペリエンスを見つけ出しやすくなります。 たとえば、競合他社の製品よりも高速で信頼性が高く、使いやすい新しいスマートフォンを開発した場合、この製品は競争優位性を持つこととなります。 また、競争力のある製品を提供することで、市場での価格競争を回避し、付加価値を提供することも可能となるのです。 このように、ドッグフーディングによる自社製品の品質や顧客満足度の向上は、製品の信頼性や競争力が向上するなど、ビジネスの長期的な成功へ大きく影響し、市場での成功を支える要因となります。 品質向上以外のドッグフーディングのメリット 品質向上以外にも、ドッグフーディングにはさまざまな利点が存在します。 従業員やステークホルダーが製品を自身で使用することにより、製品に関する理解が深まり、マーケティングやカスタマーサポートなどの役割においても、より効果的にユーザーに対応できるようになります。 また、実際に使い込むことで自社製品に対する愛着やコミットメントが高まり、各部門が一体となって製品の成功に貢献することも期待できるのではないでしょうか。 このように、ドッグフーディングは製品やサービスに多くのメリットをもたらす重要な取り組みであるといえます。 QAエンジニアが行うドッグフーディングについて考えてみた 品質管理の専門職であるQAエンジニアは、製品品質やユーザーエクスペリエンスの最適化を目指すドッグフーディングとの相性が良いと考えられます。 QAエンジニアがドッグフーディングを行う利点 テストや品質管理などを得意とするQAエンジニアがドッグフーディングを行うと、以下のような効果が期待できるでしょう。 バグと改善点の早期発見 QAエンジニアが製品を実際に使用することで、一般ユーザーが遭遇する可能性のあるバグや課題の早期発見がしやすくなるでしょう。 これにより、開発段階での修正が行いやすくなり、リリース後のトラブル減少に貢献することができます。 ユーザーエクスペリエンスの最適化 QAエンジニアはユーザーエクスペリエンスを向上させるための提案や改善点の提供を得意としています。 質の高いフィードバックにより、製品の使いやすさや顧客満足度の向上に寄与することが可能です。 テストケースの充実 QAエンジニアが実際に製品を探索的に使用することで、予め用意することが困難なテストケースやテストシナリオを作成し、テストカバレッジを増やすことができます。 このことは品質保証の精度向上につながり、製品の信頼性を高めることに貢献します。 将来のQAエンジニアリングとドッグフーディングの可能性 将来においてQAエンジニアとドッグフーディングの関係にはどのような可能性が考えられるでしょうか。 QAエンジニアリングの業界でも、今後、AIや自動化技術を活用したQAテストツールの進化が期待されていますが、これらのツールでユーザーエクスペリエンスを担保することは難しいのが現状です。 したがって、QAエンジニアがユーザー視点からソフトウェアを評価し、フィードバックを提供する役割は重要であり、QAエンジニアが新しいテクノロジーを活用した品質保証を行う未来においても、ドッグフーディングは不可欠な要素となることが予想されます。 また、ユーザーの多様なニーズに対応するために、QAエンジニアがソフトウェアやサービスを多角的に評価し、改善を推進する役割としての需要も将来的に増していくでしょう。 では、ドッグフーディングを効果的に実施するためにはどのような点に注意するとよいのでしょうか。 ドッグフーディングの実践に向けて これまでも紹介してきた通りですが、実際に製品を利用し、その使用体験からフィードバックを得ることはドッグフーディングの中核的な要素です。 ここでは、効果的なドッグフーディングを実施するための要素をいくつかご紹介します。 ユースケースシナリオの検討 ドッグフーディングを行う際には、製品やサービスの様々なユースケースやシナリオを検討することも重要な要素となります。 異なる利用状況での振る舞いや問題点を特定し、幅広いユーザー層の要求に適合するように改善を行うことが可能になるためです。 ユースケースの多様性を考慮することで、製品の汎用性を向上させることができます。 レアケースのテスト こちらは優先度は低くなることが多いですが、通常のユースケースシナリオだけでなく、稀なケースや特殊な状況に対するテストを意識的に行うのもよいと思います。 一般的でない問題やエッジケースでのバグを特定することは、製品の信頼性と安定性を高めるために必要なステップとなります。 たとえば、モバイルアプリケーションのドッグフーディングでは、通信状況が不安定な地域での利用などがこれにあたります。 チームへのドッグフーディングの普及 ドッグフーディングを個人で行うのもよいのですが、チーム全体で実施するとより大きな効果が期待できます。 チームでの実施により、より多くの視点と洞察を得ることができ、多角的な評価と改善を行いやすくなるためです。 ドッグフーディングの重要性をチームメンバーに伝え、定期的なドッグフーディングセッションの企画・ユーザーフィードバックの収集を行うなど、積極的な参加を促す工夫をすることが成功の鍵となります。 ドッグフーディングの継続と改善 ドッグフーディングは一度だけの実施ではなく、継続的に取り組むことが重要です。 フィードバックと改善のサイクルを確立することで、製品やサービスを継続的に進化させていくことが可能となるためです。 このサイクルを継続することで、ユーザーの期待に応じつつ、製品品質と競争力の継続的な維持に寄与できます。 これらの要素から自分のチームの状況に合ったものを取り入れ、実践的なドッグフーディングプロセスを構築することで、成功へ一歩近づくことができるはずです。 ドッグフーディングの課題点 ドッグフーディングを行うことで多くのメリットが得られる一方、注意すべき点も存在します。 製品やサービスの開発チームでドッグフーディングを行う場合、仕様を理解していたり、現在の仕様になるまでの経緯を知っていることで先入観が生まれ、初見のユーザー視点での改善点が挙げづらくなることがあります。 また、ステークホルダーなどの従業員から集まったフィードバックが、一般のユーザーや顧客の期待とは異なる可能性もあります。 このように、ドッグフーディングにはバイアスの問題が存在することには注意が必要です。 バイアスを軽減するためには、多様な従業員の選定や外部ユーザーのフィードバックを取り入れることが重要です。 開発チーム内で実施する際には、開発完了してから少し時間をおいたり、類似プロダクトを触るなどした後、改めて自社製品を触るとバイアスが軽減され、改善点を挙げやすくなるかもしれません。 ドッグフーディングの小ネタ 最後に個人的に効果があった、テスト業界の知識がなくても誰でも簡単にできるドッグフーディングの小ネタを紹介して、今回の記事を終わりにしたいと思います。 それは「 サービスを使った作業をタイムアタックで行う 」というものです。 たとえば、Webアプリケーションのドッグフーディングを行う場合を考えてみましょう。 Webアプリケーションは、基本的には業務などを効率的に行うために作られるサービスです。 ということは、手早く作業ができるWebアプリケーションは使い勝手がよいと評価されやすく、つまり、短時間で作業を完了させようとした際に、操作に迷ったり面倒な操作があれば、それは改善ポイントとなる可能性が高いというわけです。 対象のシステムにも依りますが、 ショートカット的な機能が欲しい ボタンの配置がこうなっていれば、もっと早く操作できるのに この機能は頻繁に使うから、もっとレスポンスを…！ というような改善点を挙げやすくなります。 とても簡単なことですが、意識するのとしないのでは改善点の気付き方も大きく変わってくると思います。気になる方は是非試してみてください。 おわりに ドッグフーディングは、自社製品やサービスの品質を改善する強力な手段の１つです。 競争が激化するビジネス環境において、ユーザーの期待を上回る品質は市場を制する鍵になり得ます。自社が提供するサービスを自らが使用し、その品質や顧客満足度向上に繋げるドッグフーディングは、このような状況下で非常に効果的なアプローチとなります。 ドッグフーディングは、製品やサービスの改善だけでなく、従業員が製品に関する理解を深め、各部門が協力して製品の成功に貢献する効果も期待できるでしょう。 この記事がドッグフーディング導入のきっかけとなったり、自社製品やサービスの開発に携わる方々の参考になれば幸いです。 The post 品質を制する者は市場を制す？サービス改善のためのドッグフーディング戦略 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 第2回から第4回は、「論理の言葉」の基本でもあり、プログラムのレベルで働く論理の基本でもある 論理演算 を見ていきます。 連載第1回はこちら [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 論理演算はソフトウェアエンジニアの必修科目、だが…… プログラミング言語には実行の流れを制御するための条件分岐を司る仕組みが具わっています（簡単に言うとif文です）。 条件分岐の判定箇所にはひとつ以上の 条件式 を置く（「条件式」は本記事独自の呼称です） 典型的な条件式は、値の大小の比較や、等式/不等式。x > 10、y == 0、など 条件式は「 真 ( true 。成り立つ、満たす、当てはまる)」か「 偽 ( false 。成り立たない、満たさない、当てはまらない)」かどちらかの値を取る 条件式の取る値は 真か偽かいずれかのみ 。 また、「真であり、同時に偽でもある」ことはない（ 真でなければ偽。偽でなければ真 ）  この「真」と「偽」を 真理値(真偽値) と呼ぶ 判定の真偽で分岐先が決まる 判定箇所で複数の条件式の組合せを扱う場合や、真偽を反転して考えたい場合が(かなり頻繁に)あります。そこで活躍するのが 論理演算 です。 論理演算 とは、真理値を入力として、結果の真理値を出力する仕組みのこと（図2-1） 基本となる論理演算は 否定(NOT)、論理積(AND)、論理和(OR) の三つ（第3回で解説します） プログラミングには必須の要素なので、言語の学習には必ず含まれるほか、情報処理技術者試験のシラバスにも含まれています。 が、論理演算は憶えればそれで十分というものではありません(-ω-;)。 その後ずっと秘かにソフトウェアエンジニアについて回り、苦しめる存在です。というのは、論理演算はやりたいことに正しく合わせなければいけませんが、そこで起こるのが“ロジックミス”などと呼ばれるエラー(誤り)です。 （“ロジックミス”のすべてが論理演算の使い方によるものではありませんが、論理演算を誤ると“ロジックミス”に直結します） 論理演算がらみのエラーは、“修行”を積めば犯さなくなる……ということはなく、ベテランでもエラーを犯します(以下、いずれも当社比)。 仕様の記述を「条件を否定したif文にするとロジックをすっきり書ける」と思って、間違える 仕様の記述を“勘違い”したまま設計～実装に落とすこともある コードをデザイン/実装する時は「正しく解釈した」と思っていても、後でレビューで指摘、あるいはテストで故障が見つかって、愕然とすることもある まずいことに自分が考えたロジックに自信を持ってしまうと、自分のミスに自分で気づきにくくなる このエラーを根本的になくす方策はありません（と、筆者は思っていますが）。すなわち、 バグの種は尽きない ということになります(´・ω・｀) そのようなバグをできるだけ見つけるためにも論理演算の働きは理解しておきたいところです。 論理演算の言葉が重要である理由 ソフトウェアにとって“ロジックミス”が生じやすい、ということを除いても、 否定、論理積、論理和に相当する言葉は、ソフトウェアの仕様記述のレベルでもよく使われ、仕様を理解する場合やテストを考える際の手がかりになります。 一般的な文章や日常生活で使われる言葉にもあり、人の話や文章の筋道を辿ったり、自分の話や思考の筋道を組み立てたりする際に重要な役割を果たします。 具体例 論理演算が絡む「ロジックのミス」や、テストを考える際に論理演算の知識がどう関係するか、具体例で見てみましょう。 忍び寄る“ロジックミス”のごく単純な例 「利用者の年齢(入力値)が18以上の場合のみ、利用可能。18未満の場合、利用を拒否する(先には進まない)」といった仕様があるとします。 これをプログラム(疑似言語)で書くとこんな感じになりますが： if age >= 18 then 　　.... (利用可能な場合のコード) else 　　... (利用拒否) end if “>=”と書くところを”>”と書いてしまう、ということが起こります(以降、いずれも当社比)。タイプミスもあり得ますし、「仕様を勘違い」することもあります（もっとも、これは論理演算とは関係ありませんね）。 「利用拒否される場合(18歳以上でない)はそこで打ち切りにすればコードがすっきりする」と考えれば、「>=(等しいか大きい)」を否定してこう書くこともできるでしょう（第3回参照）： if age < 18 then 　　... (利用拒否。処理打ち切りで先に進まない) end if ... (利用可能な場合のコード) ここで、<と書くつもりでいて実際には>=のまま、ということが起こりますが、これを論理演算の誤りと呼ぶのも違うかも知れません。しかし、 「>=の否定」を間違えて<=とするということも起こります。 「利用可能でないなら」という表現を“活かそう”と”NOT(age >= 18)”と書くつもりでいて、”NOT”を書き忘れて”if (age >= 18) then …”としてしまう、ということも起こります。 もっと複雑な条件になると、よりいっそうエラーが紛れ込みやすくなります。 ISTQB Foundation Levelシラバス 4.0 の境界値分析(4.2.2)で「開発者はこれらの境界値に関してエラーを犯す可能性が高い」としている通り、ここに挙げた“エラー(誤り)”とその結果としてのバグ(欠陥)は、いずれも「利用可能な年齢」の境界に絡みます。境界値分析はこうしたバグを見つけるのに適したテスト技法です。 テストを考える時に働く論理演算 入力ファイルから1文字ずつ読み出して、出力ファイルに書き出すプログラム(ファイルのコピー)があるとします。 入力ファイルが開けない場合（ファイルが存在しないか、存在するが読み出しが許可されていない）は、何も書き出さずに終了する（空の出力ファイルを作らない）。 入力ファイルが空の場合は、何も書き出さずに終了する（空の出力ファイルを作らない）。 このプログラムをテストするには、どんな場合をテストするとよいでしょうか。 ………… 出力ファイルが作られるのは以下の場合です（太字部分が論理演算の言葉で、論理積(AND)や論理和(OR)というものになります。第3回参照）。 入力ファイルを開くことができ、 かつ 、ファイルの内容が空でない場合 出力ファイルが作られない場合には、次の2通りがあります。 入力ファイルが開けない（開けない場合には次の2通りがあります） ファイルが存在しないか、 または 、存在するが読み出しが許可されていない 入力ファイルを開くことができ、 かつ 、ファイルの内容が空である それぞれをテストすることになるでしょう。 （ 具体的にどんなファイル を用意するとよいか、考えてみてください！） むすび 論理演算の概要と、論理演算の言葉を知っておく意義をお話ししました。 次回第3回では否定(NOT)、論理積(AND)、論理和(OR)の意味と働き、続く第4回では、論理演算の組合せという話題を取り上げます。 参考文献 情報処理技術者試験　IT パスポート試験シラバス　Ver.6.2 （PDF） 情報処理技術者試験　基本情報技術者試験（レベル２）シラバス （PDF） 情報処理技術者試験　応用情報技術者試験（レベル３）シラバス （PDF） 『プログラミング言語C　第2版』(カーニハン, リッチー / 共立出版) 『プログラミング言語AWK』(エイホ, ワインバーガー, カーニハン / USP研究所) JavaScript リファレンス (Webページ) Python 言語リファレンス (Webページ) 『ソフトウェアの信頼性』(マイヤーズ / 近代科学社) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 The post [第2回] プログラムレベルのロジック (1)概要編 first appeared on Sqripts .

こんにちは。性能テストグループのけんです。この記事では私が主に担当している性能テストについて、引き続き共有していきます。 前回の投稿 ではテストパターン（ロードプロファイル）の構成要素について説明しました。 今回は、構成要素の中で重要となる負荷量ついて説明していきたいと思います。 ＜ 性能テストのススメ 記事一覧 ＞ ※クリックで開きます #1 性能テストの目的と種類 #2 テスト計画 #3 対象シナリオ（運用プロファイル） #4 テストパターン（ロードプロファイル）第一章_構成要素 #5 テストパターン（ロードプロファイル）第二章_負荷量（入門編） スレッド数とスループット 性能テストにおいて適切な負荷量を設定するためには、スレッド数とスループットについて理解する必要があります。 ISTQBのシラバスでは、コンカレンシー（スレッド）とスループットについて以下の説明があります。 ワークロードの異なる側面であるスループットとコンカレンシーを理解することは重要である。 運用プロファイルとロードプロファイルを適切にモデル化するには、両方の側面を考慮すべきである。 参考文献： 「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 Version 2018.J01」 要約すると以下になります。 ・スレッドとスループットは別物なのできちんと理解しないといけないよ ・対象シナリオとテストパターンを決定するためには両方を考慮するべきだよ スレッドとスループットについては 前回の投稿 で説明しましたが、実際にはイメージしづらい部分もあるかと思いますので、今回は詳しく説明していきたいと思います。 握手会から学ぶスレッド数とスループットの関係 突然ですが、問題です。 【問題】 架空のアイドルグループAGT48 ※1 の握手会があります。 握手会には最大で300人の客が参加します。握手会の制限時間は60分です。 時間内に参加者全員が入退場するためには入場のための受付レーンを何列設置すればよいでしょうか。 【前提条件】 1. 入場から退場までにかかる想定時間は（受付を含め）1人あたり3分 2. 受付レーンから会場に入場できるのは1列あたり1人までで、1人が退場した直後に次の人が入場 ※1 AGT48は架空のアイドルグループですが、AGEST（当社）のアイドル「こころちゃん」（画像右上）はデジタルコンシェルジュとして社内で活躍しています。 こころちゃんについては「 Cloud FunctionsとSlack APIに踊らされたSlack Bot作成 」をご確認ください。 解けましたでしょうか？ここでヒントです。 【ヒント】 (1) 受付レーン1列で60分間あたり何人が入退場できるのか (2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか ※注意※ 下の画像の後がすぐ答えになります。もう少しお考えになりたい方はスクロールしないようにしてください。 答えは以下の通りです。 （1）受付レーン1列で60分間あたり入退場できる人数は.. 　　　　↓ 　　60[分]（制限時間）/ 3[分]（1人あたりの入退場時間）＝ 20[人] （2）受付レーン1列で20人が入退場できるとして、300人を入退場させるためには.. 　　　　↓ 　　300[人]（客総数）/ 20[人]（1受付レーン60分あたりの入退場数）= 15[列] 正解は15列でした。 性能テストに置き換えると… 先ほどの例題は性能テストで負荷量を検討する際の基本となります。それでは例題の内容を性能テストに置き換えて解答していきたいと思います。 握手会場を対象システムに置き換え、握手会場に客が入場してから退場するまでにかかる時間を計測対象範囲とした場合、以下の様になります。 問題例 性能テストに置き換えると 握手会場 対象システム 握手会場に入場してから退場するまでの動線 トランザクション 握手会場に入場してから退場するまでの時間 トランザクションのレスポンスタイム 受付レーンの数 スレッド数 時間あたりの入退場者数 スループット これらを置き換えて図にすると以下の通りです。 例題の解き方も置き換えてみます。 (1) 1つの受付レーンで60分間あたり何人が入退場できるのか 　　　　↓ 　　1スレッドで60分間あたり何トランザクション実行できるか 　　　　↓ 　　60[分]（時間範囲）/ 3[分]（1トランザクションの処理時間）＝ 20[トランザクション] (2) 60分で300人を捌くためには、(1)を踏まえた上で受付レーンを何列用意すべきか 　　　　↓ 　　60分で300トランザクションを実行するためには、(1)を踏まえた上で何スレッド用意すべきか 　　　　↓ 　　300[トランザクション/60分] / 20[トランザクション/60分] = 15[スレッド] スレッドを算出するために、目標となるスループット（300[トランザクション/60分]）を確認した上で、1スレッドの時間あたりの実行可能な回数（時間範囲/ 1トランザクションの処理時間）を算出してから必要なスレッド数を算出する、という流れになります。 60分あたりのスループットで計算していますが、実際のスループット要件は分間、できれば秒間と、短い単位で算出することが好ましいです。なぜなら、例題では範囲時間が60分と決まっていましたが、範囲時間は今回の様に必ずしも定まっていないことが多いからです。1スレッドで1分あたりのスループットが算出できていれば、範囲時間（負荷継続時間）が変わったとしてもスレッド数の算出が容易となります。 以上を踏まえ、1分あたりのスループットを元に計算してみます。 目標スループット（300[トランザクション/60分]）を分間にすると... 　　　　↓ 300[トランザクション] / 60[分] = 5[トランザクション/分] 1スレッドで1分間あたりのトランザクション実行回数は... 　　　　↓ 1[分] / 3[分]（1トランザクションの処理時間）＝ 0.3333...[トランザクション/分] 目標トランザクションを達成するために必要なスレッド数は... 1分あたりの目標スループット / 1スレッドで1分あたりのスループット = 必要スレッド数 　　　　↓ 5[トランザクション/分] / 0.333...[トランザクション/分] = 15[スレッド] これが汎用的なスレッド数の計算方法となります。 もし上記から条件が変わり、範囲時間（負荷継続時間）が60分→100分に変更となった場合でも、1スレッドあたりの分間スループットが算出済みであれば以下の様に適用できます。 目標スループット（300[トランザクション/100分]）を分間にすると... 　　　　↓ 300[トランザクション] / 100[分] ＝ 3[トランザクション/分] 目標トランザクションに達するために必要なスレッド数は... 　　　　↓ 3[トランザクション/分] / 0.333...[トランザクション/分] = 9[スレッド] ポイント 今回は時間あたりの目標となるスループットを元にスレッドを算出するための方法をお伝えしました。 ※2 この方法では以下の３つが必要となります。 スループット（時間あたりのトランザクション処理数）の予測値 対象シナリオ1回あたりの所要時間予測（上記の例では「対象シナリオ1回 = 1トランザクション」として置き換えていました） 対象シナリオに含まれるトランザクション数（上記の例では1トランザクションのみでしたが、実際には複数のトランザクションが存在するのが一般的です） 注意点として、1と2は予測値であるということです。これらはリクエストの応答速度によって変動します。 変動要因としては、負荷をかけた影響によってシステム側のいずれかの処理で遅延が発生することです。 そのため正確な数値は計測するまでわかりません。どこまでの誤差が許容されるかで大きく違いはありますが、1回のテストで想定通りのスループットを出すことは難しいことをご理解いただけると幸いです。 ※2 負荷生成ツールによってはスループットを指定して実行する機能もあるので、それを利用することも選択肢の一つです。（考慮する観点が変わるため説明は割愛します） スレッド数の算出方法は今回紹介した方法以外にも存在します。以下は一例です。 ・同時アクセスユーザー数とスループットの両面で算出する場合（ユーザー数＝スレッド数とし、シナリオ内でスループットを調整） ・同時アクセスユーザー数のみで定義する場合（ユーザー数＝スレッド数とするが、実運用想定となる負荷量との乖離は大きい） ・システムが保持する同時セッション数で定義する場合（時間あたりのセッション数＝時間あたりのシナリオ実行回数） 性能テストで適切な負荷量を設定するためには、必要な情報をできる限り収集することが重要です。 さいごに 今回は負荷量について説明しましたが、まだまだ基礎的なお話となっているので引き続き連載していきたいと考えています。 次回記事もどうぞよろしくお願いいたします。 連載一覧 性能テストのススメ #1　性能テストの目的と種類 性能テストのススメ #2　テスト計画 性能テストのススメ #3　対象シナリオ（運用プロファイル） 性能テストのススメ #4　テストパターン（ロードプロファイル）第一章_構成要素 性能テストのススメ #5　テストパターン（ロードプロファイル）第二章 負荷量（入門編） The post 性能テストのススメ #5 テストパターン（ロードプロファイル）第二章 負荷量（入門編） first appeared on Sqripts .

AI が急速な進化を続ける中、各企業や私たちはその流れに遅れないようにする必要が出てきました。最先端の機械学習アルゴリズムから自然言語処理の進歩に至るまで、これらのトレンドは産業や私たちの日常生活を再構築する可能性を秘めています。 2023年以降も成熟する AI 市場に対して、私たちはAIをテストするという視点からAIに対してアプローチをしていきます。 AIテスティング(CT-AI)コースの紹介 今回紹介するのは、 ISTQB(テスト技術者資格制度) の　Foundation Level シラバス-AI テスティング (CT-AI)のトレーニングコースについてです。 一言で纏めてしまうとISTQBの資格取得用のトレーニングコースになるのですが、ソフトウェアテストの分野では世界的な権威でもある スチュアート・リード博士 がトレーナーを担当しており、博士の深い見識からもたらされるAIシステムにおけるテストの考え方を深く学ぶことができ、貴重な体験を得られます。 参考記事 【特集】AIのリスクベーステスト／スチュアート・リード博士 コース時間は12時間に及ぶコンテンツになっております。AI全般の技術や深い理解を醸成し、その実用化に向けて重要な洞察を提供してくれます。 内容は直接、ご覧いただきたいと思いますので、ここでは簡単な概要を紹介いたします。 セッション1：AIへの紹介 AIの基礎と導入に関する内容 AIの中核技術をお伝えし、GDPRのような法規制や特化型AI、従来の非AIとの違いなどを紹介。 キーワード ： 適応性、アルゴリズムバイアス、自律性、バイアス、進化、説明可能性、説明可能な AI（XAI）、柔軟性、不適切なバイアス、解釈可能性、ML システム、機械学習、報酬ハッキング、堅牢性、サンプリングバイアス、自己学習型システム、副作用、透明性 セッション2：AIベースのシステムの品質特性 AIシステムの特に重要な品質特性について学び、ユーザーがAIシステムをどのように信頼するかを紹介。 キーワード ： 適応性、アルゴリズムバイアス、自律性、バイアス、進化、説明可能性、説明可能な AI（XAI）、柔軟性、不適切なバイアス、解釈可能性、ML システム、機械学習、報酬ハッキング、堅牢性、サンプリングバイアス、自己学習型システム、副作用、透明性 セッション3：機械学習（ML） – 概要 機械学習の概要、モデルの評価やチューニングなどのワークフロー、機械学習モデルを利用した演習を通じて理解を深める。 キーワード ： アソシエーション分析、分類、クラスタリング、データ準備、ML アルゴリズム、ML フレームワーク、ML 機能性能基準、ML モデル、ML 訓練データ、ML ワークフロー、モデル評価、モデルチューニング、外れ値、オーバーフィッティング、回帰、強化学習、教師あり学習、アンダーフィッティング、教師なし学習 セッション4：ML – データ MLにおけるデータの取得、準備、前処理の重要なステップ。 キーワード ： アノテーション、データ拡張、分類モデル、データラベリング、データ準備、ML 訓練データ、教師あり学習、テストデータセット、検証データセット セッション5：ML機能パフォーマンスメトリクス 機械学習の評価指標に関する詳細な情報や算出方法の説明。 キーワード ： 正解率、AUC、混同行列、F1 スコア、クラスター間メトリクス、クラスター内メトリクス、平均二乗誤差（MSE）、ML ベンチマークスイート、ML 機能パフォーマンスメトリクス、適合率、再現率、ROC(受信者動作特性)曲線、回帰モデル、R2 乗、シルエット係数 セッション6：ML – ニューラルネットワークとテスト ディープニューラルネットワーク（DNN）などの基本的なキーワードを取り上げ、多層パーセプトロンやニューロンカバレッジのような高度なテクニックを紹介。 キーワード ： 活性値、ディープニューラルネットワーク（DNN）、ML の訓練データ、多層パーセプトロン、ニューラルネットワーク、ニューロンカバレッジ、パーセプトロン、符号変化カバレッジ、符号-符号カバレッジ、教師あり学習、閾値カバレッジ、訓練データ、値変化カバレッジ セッション7：AIベースのシステムのテスト概要 AIベースのシステムのテストに関する概要と課題について触れ、またコンセプトドリフトやデータパイプラインといったテストの際に考慮すべき事項について紹介。 キーワード ： AI コンポーネント、自動化バイアス、ビッグデータ、コンセプトドリフト、データパイプライン、ML 機能パフォーマンスメトリクス、訓練データ セッション8：AIに特化した品質特性のテスト AIの品質を評価するための特定のテスト技術と考え方を探求し、バイアスの検出、自律的なシステムの挙動、さらには解釈可能性や透明性を評価する方法など、AIの品質を確保するための多岐にわたるトピックを網羅。 キーワード ： アルゴリズムバイアス、自律型システム、自律性、エキスパートシステム、説明可能性、不適切なバイアス、解釈可能性、LIME 法、ML 学習データ、非決定論的システム、確率論的システム、サンプリングバイアス、自己学習型システム、透明性 セッション9：AIベースシステムのテストのための方法と技法 AIベースのシステムのテストに関するさまざまな方法と技術の紹介 AIで利用されるケースが多い、A/Bテストや敵対的テスト、メタモルフィックテストなども取り扱う。 キーワード ： A/B テスト、敵対的テスト、バックツーバックテスト、エラー推測、経験ベースのテスト、探索的テスト、メタモルフィック関係（MR）、メタモルフィックテスト（MT）、ペアワイズテスト、疑似オラクル、テストオラクル問題、ツアー,敵対的攻撃、敵対的サンプル、データポイズニング、ML システム、学習済みモデル セッション10：AIベースのシステムのテスト環境 テスト環境に関する詳細なガイド ここでは自動運転車を例に取り上げ、仮想テスト環境のメリットやデメリットについての紹介。 キーワード ： 仮想テスト環境、AI 専用プロセッサ、自律型システム、ビッグデータ、説明可能性、マルチエージェントシステム、自己学習型システム セッション11：テストにAIを使う テストプロセスにAIをどのように組み込むか、および実際の演習を通じての学び。 キーワード ： ビジュアルテスト、ベイジアン手法、分類、クラスタリングアルゴリズム、欠陥予測、グラフィカルユーザーインターフェース（GUI） 1. AI業界のこれから AIは現代のエンジニアリング分野において重要な役割を果たしており、その市場規模は急速に拡大しています。 特に生成AIの経済的ポテンシャルに関するマッキンゼーのレポートを要約すると生成AIの導入は、世界経済に年間約2.6兆ドルから4.4兆ドルの価値をもたらす可能性があり、現在使用されているソフトウェアに組み込まれることで、その価値はさらに2倍になる可能性があります。 生成AIはすべての産業構造に著しい影響を与えると予測されており、顧客サービス、マーケティング、販売、ソフトウェアエンジニアリング、研究開発などの分野で特に大きなビジネス価値を提供することが予想されています。 いくつかのユースケース分析を通じて、AIが様々なビジネス課題に対処し、測定可能な成果を出すことが示されています。 生成AIは労働市場にも影響を及ぼし、現在従業員が行う作業の60～70%を自動化する可能性があることから、仕事の構造を変化させることが予測されています。 この技術の自動化の可能性は、特に自然言語理解の能力が向上することにより加速しています。 この移行は労働者に新しいスキルの習得や職業の変更を要求し、それをサポートするための投資が必要と示しています。 このようにテクノロジーの絶え間ない進歩により、将来的にはさらに大きな進歩が期待でき、未来を形作る上でテクノロジーがますます重要な役割を果たすことは間違いありません。 参考： 2023年 国内AIシステム市場予測を発表 参考： The economic potential of generative AI: The next productivity frontier 生成型 AI の経済的可能性: 次の生産性フロンティア(マッキンゼーの見解) では将来に向けてどのように備えればよいでしょうか? 私たちは更に認識を広め、自分自身を教育していくことを継続していく必要があると思います。 AIは反復的なタスクを自動化し、人間の時間を節約するという驚異的な能力を備えてくれています。 これは私たちがより複雑で創造的な取り組みに集中するのに役立つツールだということです。 AI はさまざまな業界の多くのデータ分析に役立ち、あらゆるタスクを最適化し、効率とコスト効率を高めてくれると思います。 AIの未来は明るく、適切なアプローチをとれば、私たちは AI テクノロジーの進歩の恩恵を受けながら、その課題にも取り組むことができます。 AIテスティング(CT-AI)コースは、この急成長している分野でのキャリアを志向するエンジニアにとって、必要な知識と技術を習得する絶好の機会を提供します。 このコースでは、AIの基本原理から最先端の応用に至るまで幅広いトピックが網羅されており、特にAIベースのシステムの品質特性やテスト方法に重点を置いています。 参加者はAI技術の進歩に対応するための実践的なスキルと理解を深めることができます。 2. AIシステムのテストや評価の難しさについて コースにおいてもAIシステムのテストや評価の難しさを取り上げています。 これらの要因は、AIの複雑性、不透明さ、そして動的な性質から生じるものです。 以下に、これらの要素をいくつか紹介し、機械学習システムの失敗例とテストの重要性を示します。 【AIの複雑性とブラックボックス問題】 問題 説明 複雑性とブラックボックス問題 AIシステムは通常「ブラックボックス」と見なされ、システムがどのようにして特定の出力や決定に至ったかを外部から理解することは困難です。 ニューラルネットワークなどのモデルは数百万のパラメータを持ち、これらが最終出力にどう影響するかの理解は難しいです。 データ依存性 AIモデルは訓練データに大きく依存しており、データセットに偏りがある場合、不正確な結果を出す可能性があります。 訓練データと異なる新しいデータに対する反応を予測するのは難しいです。 動的な学習プロセス 多くのAIシステムは新しいデータから学習を続け、システムの振る舞いが時間と共に変化する可能性があります。 この動的な学習プロセスはテストや評価を継続的に行う必要があり、大量の資源を消費する可能性があります。 解釈可能性と透明性 AIシステムの決定を人間が理解し信頼するためには、その決定過程を説明できる必要があります。 解釈可能性と透明性の欠如はテストと評価を複雑にします。 エラーの特定と修正 AIシステムが誤った決定をした場合、その原因の特定と修正は難しく、AIモデルの規模が大きく複雑であればあるほど困難です。 不確実性とリスクの管理 AIシステムには確率的要素が含まれ、予測や決定に不確実性が伴います。 この不確実性を適切に管理し、リスクを最小限に抑えることはAIテストと評価の重要な課題です。 【機械学習(ML)システムの失敗例】 問題 説明 偏ったデータセット ある人種や性別に偏ったデータセットで訓練された顔認識システムは、特定のグループに対して誤った識別を行うことがあります。 これは偏見を持った意思決定につながり、社会的な不公平を生じる可能性があります。 オーバーフィッティング 訓練データに過度に適合したモデルは、新しいデータに対してうまく機能しない可能性があります。 これは、モデルがトレーニングデータのノイズやランダムな変動を学習してしまうためです。 リアルタイムデータへの適応の欠如 市場予測のモデルが過去のデータに基づいて構築され、市場の新たな動きに迅速に適応できない場合、不正確な予測を行うことがあります。 不十分なテストと検証 医療診断をサポートするために設計されたMLシステムが、十分な検証を経ずに臨床環境で使用されると、誤診や治療の遅れを引き起こす可能性があります。 【テストの重要性】 テストの重要性 説明 バイアスの低減 テストは、モデルの決定に偏りがないことを確認するために不可欠です。 これにより、公平で倫理的なAIシステムの構築が可能になります。 汎化能力の評価 モデルが新しい、未知のデータにうまく対応できるかどうかをテストすることで、その汎化能力を評価します。 パフォーマンスの検証 正確性、再現率、適合率などのメトリクスを用いて、モデルのパフォーマンスを検証します。 これにより、特定の用途に対してモデルが適切かどうかを判断できます。 安全性と信頼性の保証 特に医療、金融、自動運転車などの分野では、モデルの安全性と信頼性の確保が必要です。 継続的な改善 テストは、モデルの弱点を特定し、継続的な改善を行うための基盤を提供します。 機械学習システムのテストと評価は、これらのシステムが現実世界で効果的かつ倫理的に機能するために不可欠です。 これらの要因により、AIのテストや評価は伝統的なソフトウェアテストよりもはるかに複雑で挑戦的な作業である事が判ります。 ※参考までに機械学習の失敗事例を載せておきます。 キヤノンITS -なぜ上手くいかなかったのか 機械学習 WebBigData – 機械学習のトレーニングに失敗したしくじり事例 tjo.hatenablog.com – 機械学習プロジェクトが失敗する9つの理由 スタビジ -AIプロジェクトの失敗する原因3 ソフトバンク – なぜAI導入は失敗する？ 失敗事例から学ぶ傾向と対策 Aidemy Business – AI導入の失敗あるある、「PoC死」の罠とは？ 3. トレーニングコースで学べる事 各セッションの内容は多岐にわたり、AIベースのシステムの品質特性や機械学習の基本、訓練データの取り扱い、MLモデルの評価指標などに焦点を当てています。 さらに、AIベースのシステムのテスト方法、AI固有の品質特性とテスト問題、テスト環境の構築、そしてAIをテストプロセスに組み込む方法など、実践的なテスト技術に関する詳細な情報も提供しています。 このようにコンテンツ量が多く専門的な用語も豊富なため、全てをお伝えするのは難しいですが、いくつかの主要なトピックを紹介したいと思います。 機械学習(ML) コース概要からも判る通り、本講義では機械学習(ML)という用語が頻出します。 本コースでは、AIにおける最も人気のあるアプローチとして機械学習に重点が置かれています。 機械学習には、回帰/分類/クラスタリングがあり、講義でも取り扱っている内容です。 ●回帰 (Regression) 【用途】: 連続する値や量の予測 　・株価予測 　・不動産の価格予測 　・気温の予測など 【主なアルゴリズム】 　・線形回帰 (Linear Regression): 　連続値の予測に使用される 　・多項式回帰 (Polynomial Regression): 　非線形関係をモデル化する際に使用 ●分類 (Classification) 【用途】 データをクラス/カテゴリに分類 　・顔識別 　・スパム判定 　・病診断など 【主なアルゴリズム】 ・ロジスティック回帰: 2クラス分類用 ・決定木: 階層分割で分類 ・ランダムフォレスト: 　決定木のアンサンブル学習 ・SVM: 分類境界を最適化 ●クラスタリング (Clustering) 【用途】ラベルのないデータ(教師なし学習)を類似性に基づいてグループ化 ・顧客のセグメンテーション ・遺伝子クラスタリング ・SNS上のトレンドの識別など 【主なアルゴリズム】 ・K-平均法: データをK個のクラスタに分類 ・階層的クラスタリング: データをツリー構造のクラスタに分類 機械学習と一口に言っても、様々な手法があり、実際の使われ方にも多様な種類があります。ニューラルネットワークの仕組みを利用したディープラーニングは今のAIにおいて多大な貢献をもたらした技術です。 いくつか代表的な例を紹介しておきます。 使用技術: 畳み込みニューラルネットワーク（CNN） 顔認証 ロック解除、防犯、など… 画像の分類 写真の分類、 医療画像解析、など… 使用技術: 敵対的生成ネットワー ク（GAN） 画像・動画の生成 線画の着色、テキストから画像生成、ロゴデザイン、動画コンテンツの生成 など… ゲームの再現 名作ゲーム「パックマン」の完全再現、など… 使用技術: 再帰型ニューラルネットワーク（RNN） 文章の理解 商品レビューの分析、 音声アシスタント、 問題文の読解、スパムフィルタ、 など… 文章の生成 文章の要約、 チャットボット 、機械翻訳、 など… 一例ではありますが、ディープラーニングの種類は実に豊富で、多くの事業に活用できるテクノロジーであることが証明されています。 本コースでもニューラルネットワークについて取り上げており、シンプルなパーセプトロンを実装する演習などが用意されています。 機械学習モデルの評価指標 これら代表的なタスクのほかに、機械学習では、データの前処理やモデルの構築、モデルの評価と、さまざまな技術や手法が紹介されています。 特にテストや評価に密接に関わるであろう、モデルの評価指標について、いくつかの重要な概念とそれらの基本的な説明を紹介しておきます。 以下の表と図で混合行列のマトリクスを用いて紹介します。 混同行列（Confusion Matrix）は、主に機械学習において、分類モデルの性能を評価するために使用されるツールです。この行列は、分類問題の実際の結果と予測された結果を比較するために使われ、以下の四つの要素で構成されます 左上： True Positive (真陽性:TP): 正しい陽性の予測。 実際に陽性であり、モデルが陽性と正しく予測したケースの数。 左下： False Positive (偽陽性:FP): 誤った陽性の予測。 実際には陰性であり、モデルが誤って陽性と予測したケースの数。 右上： False Negative (偽陰性:FN): 誤った陰性の予測。 実際には陽性であり、モデルが誤って陰性と予測したケースの数。 右下： True Negative (真陰性:TN): 正しい陰性の予測。 実際に陰性であり、モデルが陰性と正しく予測したケースの数。 【この図は正解ラベル(横軸)に対してモデルが正解/不正解の予測(縦軸)を示す指標です】 これら4つの要素を使って、正解率、適合率、再現率、F1スコアなどを算出できます。 これらはモデルの特性やデータが不均衡な場合は誤解を招く可能性がありますので、1つの指標だけでなく複数の指標を用いて多面的に評価をしていく必要があります。 ここでは分類モデルの評価指標の一例を紹介しました。 さて、コースにおけるいくつかのコンテンツを紹介させて頂きましたが、ここですべてを説明することは割愛させて頂きます。今までの内容からAIテスティングに興味が湧いた方は、是非、お手に取って頂ければと思います。 今回紹介した内容以外にも AIに特化した品質特性 アルゴリズムやサンプルのバイアス、独自に進化する自己学習システムや自らを制御する自律型システムなどどのように予測精度や意思決定の品質を評価していくかを課題として取り扱っています。 AIのテスト環境 現実的に環境構築が難しいケースを構築できるメリットを上げており、危険なシナリオ、異常なシナリオ、極端なシナリオ、時間のかかるシナリオなどに対して、観測や制御が容易であるメリットを説明しています。 テストにAIを使うケース 欠陥の分析や予測、テストケースの生成やユーザーインターフェースのテストなどが取り上げられています。一例ではありますが、例えば今回紹介したような、SVMやk近傍法などを用いる事で、適切な欠陥カテゴリを特定し、類似した欠陥や重複した欠陥を分類したり、ファジー理論やベイズ理論等の応用で、事前確率と新たなデータを組み合わせて、事象の発生確率を更新し予測を行うなどに用いる事例が紹介されています。 多様にあるAIベースのシステムに対して、ソフトウェアの品質をどのように達成するか、そのヒントを提供してくれると思います。 4.最後に ChatGPTの動向 今回AIの題材を扱わせて頂きましたが、2022年にChatGPTとMidjourneyの登場により、生成AIの波が到来しました。特に、ChatGPTを中核とする大規模言語モデル（LLM）に関するニュースは日々飛び交い、その急速な進化には驚嘆させられます。 多くの企業がLLMをビジネスに導入し、新規サービスの開発、既存事業の拡張、効率化のために活用しています。そして2023年11月7日、OpenAIはChatGPTを大幅にアップデートし、その波はさらに加速しています。 このコースでは大規模言語モデル（LLM）の直接的な扱いはありませんが、LLMの使用を通して、その評価の複雑さを理解することができます。 現代のテクノロジーの中心にあるChatGPTのようなLLMが作り出すテキストの精度を測ることは、非常に困難な課題です。 この根幹にあるのは、特定の期待される出力に対して明確な基準を設定することの難しさと、同じ入力に対しても一貫性のある結果を得られるとは限らない、という特性にあります。これらの要素はLLMのテストと評価を複雑にしており、我々がこの分野で直面する主要な問題の一つとなっています。 LLMの評価指標は新しい研究分野ですので標準的な指標セットや、評価ツールも発展途上という状態です。 その中でいくつか参考となる内容を紹介しておきますので、興味がある方はご覧ください。 例えば、ChatGPTのAPIであるLangChainの評価機能の中で特に埋め込み距離（embedding distance）を扱う部分に焦点を当てています。 LangChainを使って自然言語処理タスクを実行し、その結果を評価するための機能やメソッドの説明がされています。 langchain.evaluation.embedding_distance.base.EmbeddingDistanceEvalChain — LangChain 0.0.336 またGitHubページに、OpenAIによる「 HumanEval 」という問題解決データセットの評価ハーネスに関するものがあります。 このデータセットは、コード上で訓練された大規模言語モデルの評価を目的としており、「Evaluating Large Language Models Trained on Code」という論文で詳細が述べられています。 https://github.com/openai/human-eval AI の時代はまだ始まったばかりです。しかし、この技術の利点を完全に実現するには時間がかかり、ビジネスや社会は依然として対処すべき大きな課題を抱えています。 これには、生成 AI に内在するリスクの管理、従業員に必要な新しいスキルや能力の決定 新しいスキルの再トレーニングや開発などの中核となるビジネスプロセスの再考などが含まれます。今後のAI時代に向けて、AIをテストするというアプローチから、AIに関する基本的な知識や理解を深め、今後の発展に役立ててくれると嬉しく思います。 Udemyクーポン配布 Udemyの割引クーポンの発行 (29%OFF) クーポンコード: 57749211103205F5B818 有効期限: 2023/11/24 0:00～2023/12/25 0:00 ぜひご活用ください。 The post 「ゼロから始めるAIテスティングトレーニングコース」を解説～AIベースシステムを「どうテストするのか？」～ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は前回の Notionでプロダクトバックログを管理するビューを作成する の記事の続きで、Notionプロジェクトについて書きたいと思います。 関連記事 Notionでプロダクトバックログを管理するビューを作成する Notionプロジェクトについて Notionプロジェクトは、2023年6月に発表されたNotionの新機能で、主に開発におけるプロジェクト管理に役立つ機能群のことを指します。 今回紹介するのは、これらの機能を活用したテンプレートです。 テンプレートは、ページの新規作成時に テンプレート を使用し プロジェクト、タスク、スプリント のテンプレートを選択することで使用できます。 テンプレートを選択すると以下の4つのDBが作成されるので、それぞれのDBを更新し、プロジェクト管理を行っていきます。 なお、本テンプレートの注意点について先に記述します。 * 今回試すのはあくまでテンプレートのデフォルトの設定です。 実際の開発プロジェクトでは適宜プロパティなどを削除/追加してください。 * 記事執筆時点で本テンプレートはベータ版の表記がありました。 今後、テンプレート内容が変更される可能性があります。 Notionプロジェクトのテンプレート タスクDB 1つめはタスクのDBです。初期のビューとして、 プロジェクト別ビュー 、 タイムラインビュー などが存在します。 DBのページのプロパティは、一般的なBTSやタスク管理システムにあるような、連番のID、担当者、期限、ステータスなどが存在します。 この中で特殊なプロパティは以下です。 プロパティ名 説明 要約 Notion AIによる概要。プロパティ編集時に更新を押せば自動でテキストが生成される 親タスク 同一DBにある親となるタスクを指定。指定することで親タスクのサブアイテムとなります。 プロジェクト プロジェクトDBの値 スプリント スプリントDBの値 GitHubプルリクエスト 後述のGitHub連携機能を用いたプロパティ 個人的には、このDBを プロダクトバックログ として使うのが良いかと思いました。 完了のステータスでPOやステークホルダーに見せられる 成果物 が出てくるイメージで、その成果物をスプリントレビュー等でレビューしていくイメージです。 なお、GitHub連携についてはNotionの新機能のため次で解説します。 GitHub連携機能 GitHub連携機能は、NotionのpageとGitHubのプルリクエスト（PR）を紐付け、Notionのpage上にプルリクエストのリンクを表示する機能です。 この機能を使うことにより、タスクとPRを紐付け、Notion上では見えにくい改修の進捗を追うことができます。 連携は、NotionとGitHubのコネクトを行ったうえで、ページのIndexをGitHub側のPRのタイトルに追加するか、PRのURLをNotionのページのプロパティにコピー・ペーストするかのいずれかで行なえます。 プロパティの設定画面 使ってみた感触としては、PRのタイトルにindexを入れるチームルールを設けることで、PRを出す時にもプロダクトバックログを意識できるので、前者のIndexのタイトルへの追加が良いのではと思いました。 プロジェクトDB タスクのカテゴリ的なイメージで、ステータス、オーナー、期日、優先度などのプロパティを設定しページを作成します。 完了率のプロパティもあり、これはタスクのステータスと連動して自動計算されます。 初期のビューとしては、 アクティブビュー 、 タイムラインビュー などが存在します。 タスクDBも同様ですが、次のプロジェクトを指定することで、タイムラインビューにて依存関係が表示され、担当者のアサインや進捗状況のチェックに役立てることができます。 スプリントDB 1スプリントを 1ページとして扱うDBで、ステータスや日付を指定できます。タスクDB側にスプリントを指定することで、完了したタスク数などが反映されます。 自分たちはこのDBと同様のものを既にバックログの管理に組み込んでいましたが、 スプリントのステータス のプロパティは設定していませんでした。 今回のテンプレートではこのステータスが後述のスプリントボードDBの機能と連動して更新されていきます。 スプリントボード スプリント – Notion (ノーション)ヘルプセンター スプリントボードは、これまでの3つのDBを使ってスプリントを運用するボードです。 デフォルトで次の3つのビューが存在します。 現在ビュー スプリントのステータスプロパティが 現在 のタスクおよびプロジェクトを表示します。 特徴的な新機能として スプリントの完了 があります。 完了すると、未完了のタスクを次のスプリントに移動したり、スプリントのステータスプロパティが自動更新されるなど、これまでスプリントの完了時に手動で行っていた操作を自動で行ってくれます。 スプリントを完了ボタンを押下時のモーダル スプリントプランニング ビュー スプリントのステータスプロパティが 次 以降のスプリントごとにタスクが表示されます。タスクを追加したり、スプリントを移動したりできます。 また、 バックログ（スプリント未設定） のスプリントが自動で作られるので、こちらに一旦タスクを移動することができます。 バックログ（スプリント未設定）のスプリント バックログ ビュー 先ほどのバックログ（スプリント未設定）に存在するすべてのタスクを表示します。ここで担当者のアサインなどプロパティの設定も行えます。 おわりに テンプレートの紹介は以上となります。 今回のNotionプロジェクトのテンプレートを使うことで、 GitHubと連携してのタスク(バックログ)管理 や、 スプリント終了時の操作 が半自動になるので、スクラム開発の運営において、手動で管理していた部分が楽になった印象でした。 アジャイル開発・スクラム開発で既にNotionを活用している方も、今回のテンプレートを取り入れる価値はあるのではと考えています。 Notionは定期的に新機能がリリースされており、例えば Notion2.33では、データベース周りの新機能であるワークフローの自動化や、Excelのような列の固定化機能などがリリースされています。 様々な機能を用いることで自分達のチームに合う運用方法が見つかるはずなので、ぜひ一度試してみてください。 The post Notionプロジェクトのテンプレートでスクラム開発をよりスムーズに！ first appeared on Sqripts .

前回の記事 では、1人目QAとは何かや1人目QAに求められているもの、そして1人目QAとしてJoinした後の立ち回りなどについて説明しました。 連載｜1人目QAとしての立ち回り 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 今回は1人目QAが実際に組織の中で「品質保証」を浸透させる際のアプローチについて説明します。 1人目QAの役割である「品質文化の浸透」 一般に「QAエンジニア」と言った場合、求められるスキルや現場での役割などは組織によってさまざまです。この点を整理し、QA関連の各種スペシャリティをわかりやすくするために、ソフトウェア技術者協会の分科会の一つ、ソフトウェア品質保証分科会（SigSQA）が考案したのがQMファンネルです。 参考： 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） | PPT QMファンネルでは、3つのスペシャリティ – TE:テストエンジニア – PE:パイプラインエンジニア – QA:QAエンジニア が表現されているほか、それぞれのスペシャリティについて5つのロール – スプリット – インプロセス – コーチ – コンサルタント – プロモーター が定義されています。 今回、このQMファンネルの中で注目していただきたいのは、QAのスペシャリティにおける各ロールの説明にある「品質文化の浸透」です。 私は、1人目QAに求められる役割の多くは、この「品質文化の浸透」であると考えています。 なお、”品質文化とは何か”についても議論の対象になる点です。本記事においては「品質保証の重要性や手法等について、開発組織で考える習慣があり、品質保証のやり方を仕組み化できている状態」を指して「品質文化が浸透している」と考えることにします。その一部分である、品質保証の重要性や手法およびその仕組みをどうやって開発組織に浸透させるのかが本記事のテーマです。 品質文化について考えたい、という方は西康晴氏のプレゼン資料 What is quality culture? Is it something tasty? | PPT および講演動画 JaSST nano vol.12 #5「品質文化って何なの?」 – YouTube も参考にしてみてください。 本題に戻ります。1人目QAを募集している各社の求人や、1人目QAの方の業務内容を見ると – QA組織づくり（採用、QA組織のMVV策定など） – 開発者へのナレッジ共有 – 品質目標・標準やテストプロセスの整備 などが業務内容に含まれていることが多くあります。つまり、1人目QAは特定プロダクトのテストやQA業務だけを求められているのではありません。QA組織を作り、開発組織での品質保証のやり方や方向性を定める役割を期待されていることになります。 この役割が、まさに「品質保証を開発組織に浸透させること」を表している、と考えます。 品質保証を浸透させるための2つのアプローチ では、1人目QAが品質保証を開発組織に浸透させるために、どのような方法があるでしょうか。 ここでは2つのアプローチについて考えてみましょう。 1. トップダウン型のアプローチ 1つ目はトップダウン型のアプローチです。 こちらは、品質保証のやり方やプロセス、品質標準などをQAエンジニアや開発組織のトップがともに策定し、それを現場で実践してもらうやり方です。 このやり方のメリットとして、 – 決まった方法を取り入れてもらうので、実践までが早い – 複数の開発チームに対して共通のやり方や仕組みを導入できる – QAエンジニアが少人数でもある程度進められる などがあります。 一方デメリットとしては、 – 現場の納得を得づらくなる可能性がある – 現場の実態に合わないことがある などが考えられます。 2. ボトムアップ型のアプローチ 2つ目はボトムアップ型のアプローチです。 こちらは、個々の開発チームや部門において、その現場での課題を解決しながら改善を重ねていく方法です。複数の現場で同じような課題が出てきた場合に、共有の仕組み化やルール化を進めていきます。 このやり方のメリットとしては、 – 取り組みの意義や期待するメリットを現場が理解しやすく、納得を得やすい – 個々の開発チームに合った施策を行える などがあります。 一方デメリットとしては、 – 開発チームや部門ごとに取り組みの進度に差がでる – 局所最適な改善に陥りやすい – 組織全体で見たときに、品質保証のやり方の浸透が遅くなりやすい などが考えられます。 どちらのアプローチで行くのかを検討して取り組みましょう 上記2つのアプローチのうち、開発組織に品質保証を浸透させるにはどちらが適しているのでしょうか。 私個人の経験からは、上記2つのアプローチは「並行して両方やる」が正解だと考えています。 私も現在1人目QAとして、開発組織への品質保証の浸透をまさに行っているところです。その過程では、トップダウン型とボトムアップ型、どちらもやりながら試行錯誤をしています。いろいろと試した結果、ボトムアップとトップダウンの両輪を回すことで、双方のデメリットを補いつつ着実に進んでいる実感があります。 ただ、あえて順番を設定するのであれば、1人目QAとしてはボトムアップ型→トップダウン型→両方が良いでしょう。 理由は、1人目として開発組織にJoinしたQAエンジニアは、その時点では周囲からの信頼が貯まっていないからです。 よほどの業界の有名人でもなければ、外からやってきた1人目QAは謎の多い存在です。 そのような状態でいきなり「これからの品質保証はこのやり方でいきます」とか「標準を決めたのでこれを守ってください！」と言ったとしても、周りには響きません。 それよりは、まずは1つでも良いので開発チームの困りごとを解決し、信頼を得つつ他のチームへも横展開を行いましょう。そして、開発組織全体から少しずつ信頼してもらえたところで、いよいよトップダウンのアプローチに移る、という順番がスムーズです。 1人目QAとして活動する方や、1人目QAをこれから採用して品質向上に取り組んでいこうという組織の方は、これら2つのアプローチをぜひ意識してみてください。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 The post 【第2回】組織に品質保証を浸透させるアプローチ first appeared on Sqripts .

みなさんはじめまして、QAコンサルタントのぐっちです。 私はこれまで制御系エンジニアとして様々な案件に携わってきました。今回のブログでは、制御系開発とはどのような開発かというお話から自身が経験して学んだ開発での課題や対策を紹介したいと思います。 制御系開発とはどんなものか 制御系開発と組込み開発は、よく混合されますが、違う開発の種類になります。 制御系開発は具体的なモノを作るのではなく、モノを制御するという考え方がわかりやすいと思います。 車を自動的に目的地に運ぶための仕組みを作り出すシステム開発を制御系開発と考えることがイメージしやすいと考えます。運転手がいない自動車や、ロボットが物を掴む動作をする場合など、人が操作することなく、動作を制御するシステムを作るのがシステム開発の概要になります。 例えば、自動車に乗って高速道路を走っているとします。制御系開発では、自動車が速度を一定に保つように制御するシステムを作成します。もしその速度が目標値よりも速くなったら、ブレーキを軽くかけて速度を下げるよう指示し、目標値よりも遅くなったらアクセルを踏んで速度を上げるよう指示します。これにより、自動車は目標の速度をキープできるのです。 制御系開発は、自動車の他にも、洗濯機の水量調整、エアコンの温度調整、電車の自動運転など、さまざまな場面で活用されています。システムが一定の目標を達成するように「指示」を出す仕組みなので、効率的かつ安全な動作を実現することが可能です。 制御系開発は、私たちの生活の中で自動化や効率化を実現するために欠かせない技術なのです。 開発現場で苦労したこと 次に、実際の開発にて苦労したことを記載していきます。Web開発やアプリ開発とも重複する内容もありますが、主に苦労したことをピックアップして記載します。 ソフトウェアだけでなく、ハードウェアの知識も必要 制御系開発ではソフトウェアの知識だけでなく、ハードウェアの知識も必要になります。もちろん専門家ほどの知見は不要ですが、開発では、デバックボードを使用して、プログラムを流し込んでプログラムの動作確認を行います。 検証では、オシロスコープ ※1 やPLC ※2 などハードウェアを使用してプログラムを制御するテストを行ったりします。普段使い慣れていないものなので、最初使うときには慣れるまで時間がかかりました。 想定する仕様の複雑さ 制御系開発では、様々な条件で起動したり停止したりするため、複雑な仕様になりやすいです。細かな制御が必要であるため、数学的な計算式を使って制御を行う場合もあります。 そういった場合、なぜこの処理になっているのか、どの仕様でこのプログラムが動作しているか等を調べるのが困難な場合も多いです。 また、動作する環境は、自動車やセンサーのようなモノであるため、実際の動作を見ることは中々できません。エミュレータ等を使用し、仮想環境でプログラムを作成したりテストを行ったりします。そのため、使用するツール等の理解や習得も必要になります。 納期の厳しさ 納期についてはWeb開発やアプリ開発も同様になりますが、制御系開発ではモノ（ハードウェア）も含めて完成になります。今ではPCやスマートフォンは容易に準備できるものになるため、準備にそこまで時間が必要にはなりません。 しかし、自動車やセンサーなど動作環境を含めてリリースするとなると様々な準備が必要になります。よって、ソフトウェアの開発だけでなく、ハードウェアの準備や進捗にも気を配る必要があります。 課題に対する対策 上述した課題に対しての対策について以下に記載します。 ハードウェアの知識もしっかりつける 先述でも記載した通り、制御系開発では色々なハードウェアを使用して開発を行うことが多いのでソフトウェアの勉強だけを行っていれば解決できるものではありません。よって、各開発に使用するハードウェアの理解を深める必要があります。 そうすることにより、ハードウェアを含めた動作を意識することができるようになり、ソフトウェアだけでなくモノとして全体を含めた視点で開発に着手できるようになります。 そうすることによってソフトウェアの動作という観点だけでなく、システム全体を俯瞰して意識していなかったことに気付くようになります。 複雑なロジックを理解できる訓練をする 制御系開発だけでなくその他の開発でも同じことが言えますが、複雑な仕組みや仕様を理解するのは容易ではありません。私も最初は苦労をしましたが、なぜそのような計算式を使うのか、なぜそのタイミングで制御を行うのかという視点で物事を考えるとだんだんと理解できるようになり、仕様書に書かれている内容に対しても、問題があるところに指摘できるようになっていきました。その際に役に立ったのはロジカルシンキングという考え方です。ロジカルシンキングとは、物事を結論と根拠に分け、その論理的なつながりを捉えながら物事を理解する思考法になります。今では書籍や研修など様々な訓練方法がありますので、興味がある方はぜひ勉強いただくことをお勧めします。 全体を見据えたスケジュール管理を意識する 先述も述べたように制御系開発ではソフトウェアだけなく、ハードウェアも含めた開発になります。よって、従来であればソフトウェアのリリーススケジュールを考慮しておけば問題ないですが、制御系開発ではハードウェアのリリースも含めたスケジュール管理が必要になります。その分、課題管理やリスク管理もハードウェアを含めた管理が必要になりますので意識してスケジュール管理を行うようにしてください。 まとめ 今回は制御系開発で気を付けるべき内容や対策について記載させていただきました。ここに書いてある内容については、他の様々な開発にも流用できる考え方だと思います。 現在はQAコンサルタントとして業務に携わっておりますが、制御系開発によって得た全体を俯瞰して開発を進めていく経験やロジカルシンキング思考を用いてプロジェクトの課題の解決することで、最終的な成果物の品質の向上に繋がっていることを身をもって実感しております。 今後もプロジェクトを成功に導けるように日々スキルアップを目指して業務を遂行していきたいと考えております。 APPENDIX:用語の説明 ※1： オシロスコープ（Wikipedia） オシロスコープ (英: oscilloscope) は、入力した信号の電圧の変化を時間の関数として視覚的に表示する電気計器。表示される波形から、振幅・周波数・立ち上がり時間（英語版）・時間間隔などの値を得ることができる。昔のオシロスコープでは、これらの値を得るには画面に組み込まれた目盛りを使って波形を手動で読み取って計算する必要があったが、現在のオシロスコープはこれらの値を自動で計算して表示する。 ※2： PLC（Wikipedia） プログラマブルロジックコントローラ（英: programmable logic controller、PLC）は、リレー回路の代替装置として開発された制御装置である。プログラマブルコントローラとも呼ばれ、一般的にシーケンサ（三菱電機の商品名であるが登録商標ではない）とも呼ばれる。 The post プロジェクトを成功させる制御系開発の進め方：学んだ教訓と対策 first appeared on Sqripts .

こんにちは。みぞぐちです。 アジャイル開発のQAとして日々業務を行っています。 11/2に開催された JaSST’23 Kyushu にオンライン参加してきました。今回は「E2Eテストの自動化導入」や「継続的テスト」をテーマにした 『 テスト自動化から、 開発を支える継続的テストへ 』 というセッションについて、要点と感じたことをレポートしたいと思います。 セミナー概要 『 テスト自動化から、 開発を支える継続的テストへ 』 今回のセッションは、ある開発チームがテスト自動化の導入を皮切りに、ソフトウェア開発サイクル全体に段階的にテストを導入していき「 継続的テスト 」を実現するまでの進化の道のりについてお話しされていました。 【登壇者】 末村 拓也（すえむら たくや）さん オーティファイ株式会社 シニアテクニカルサポートエンジニア／テスト自動化スペシャリスト ちなみに「笑わせないと生きていけないタイプの人間なんですよ」とご自身でおっしゃっていた通り、70分の講演は面白くてあっという間でした。 資料は公開されていますので、興味のある方は覗いてみてください。 継続的テストに進化するまでの道のり これは末村さんが6年前にQAやソフトウェア開発に携わったときの話だそうです。 明日リリースするというリリース日程が差し迫っている状況のときに… 開発者 ：「QAテストしてください！」 QA ：「はい！」 QA ：「バグ見つかりました！」 開発者 ：「バグ直りました！」←リリース当日3時間前 QA ：「（え？こっからテストするの～？）」 みたいなことがとてもストレスだったということで、開発者の実装とQAのテストの間に何か見えない壁があってウォーターフォールに近いものが残っていたそうです。この苦しみの源泉は何なのかいろいろ勉強していくうちにDevOpsというのを知りました。 DevOpsとは DevOpsとは、Development（開発）とOperation（運用）を分けて仕事していたのを一緒にしよう、というシステム開発の流れを良くする意味で使われる造語で、それを下支えする技術や概念として継続的インテグレーションや継続的デリバリーという考え方が出てきたそうです。 出典： テスト自動化から開発を支える継続的テストへ （P.9） では、今回の主役とも言える「継続的テスト」とは何なのか。 出典： テスト自動化から開発を支える継続的テストへ （P.10） 上記図のように、継続的テストはすべての場所でテストできると言われています。 開発とQAの間にあった壁が苦しみの源泉でしたが、確かにこの八の字なら壁を取っ払えそうです。ということで、「ある開発チームのテストが継続的テストに進化するまでの道のり」がスタートしました。 クライマックステスト 出典： テスト自動化から開発を支える継続的テストへ （P.15） ある開発チームのお話です。1スプリント2週間で開発／テスト／リリースという流れで仕事をしていて「 一度にリリースする量が多い 」、「 駆け込みマージが多い 」、「 手戻りが多い 」という課題があり、QAの手動テストがボトルネックになっていました。手動テストを自動化したらリリース頻度を増やせるのではないか！ということで、まずはクライマックステストのソリューションとして E2Eテストの自動化 を導入しました。 （ちなみに「クライマックステスト」の名前はChatGPTに考えてもらったそうです。最後の方にどっかーーんとテストするの、何かいい名前ない？と聞いたら「クライマックスはどうでしょう」ということで名付け親になってもらったそうです。いい仕事しますね！） テスト自動化 出典： テスト自動化から開発を支える継続的テストへ （P.22） テスト自動化したらテスト実行速度は1/4～1/2まで短縮し、4時間だったテストは1～2時間になりました。 しかしここにも課題があり… 出典： テスト自動化から開発を支える継続的テストへ （P.25） E2Eテストの自動テストコードが古かったり、新機能追加に対応できていなかったりと、実際に動かしてみて初めて問題に気が付きました。 問題に気付くのが遅かった のです。テスト時間はテストコードのメンテナンス作業が追加発生してむしろ増えてしまいました。 実装の後にテスト工程が集中しているのが悪くて、これを開発中にE2Eテストを回したら、そのサイクルの中で問題にすぐに気付けるのではないか。 出典： テスト自動化から開発を支える継続的テストへ （P.32） ということで次のチャレンジです！ シフトレフト 出典： テスト自動化から開発を支える継続的テストへ （P.35） 今まで開発の後に集中していたテストを開発の途中にもっていこう、という シフトレフト を取り入れました。 開発中に開発者によってテストコードの実装／メンテナンスがされるので、 問題に気付くタイミングが早く なり、CIサイクルの中にE2Eテストを組み込めば自動的に実行されてリリース直前のQAの負荷軽減、コードフリーズ期間の短縮、リリースサイクルの短縮が可能となり、結果、「2週間スプリントを1週間に」、「2週に1回リリースを1週に1回に」改善していきました。 ただし、ここにも課題があり… 開発者たちにフラストレーション がありました。 「CIの実行時間が長くなった」 「UNITテストで充分なのにE2Eテストを書かないとダメなの？」 これは どのようなバグをどのように見つけるか、ということをチーム内で充分共有されていないのが原因 ということがわかり、課題がわかったので次のチャレンジです。 テストリアーキテクティング リアーキテクティングはリファクタリングと類義語で使われますが、リアーキテクティングは直訳すると再設計。テストリアーキテクティングは、今までE2Eテストに寄りすぎていたテストをもっといろんなテストレベルに寄せていこうというものになります。 出典： テスト自動化から開発を支える継続的テストへ （P.41） 左の図のアイスクリームコーンというアンチパターンから、右の図の実行時間が短く実行コストが少ない順に充実させたテストピラミッドのバランスにもっていこう、というのを 開発チーム内で共有しまずは合意 を取りました。 次にテストのバランスを考えてE2Eテストを減らし、同時にテストを削ってもカバレッジは保っていることを裏付けるためのカバレッジ計測を1週間に1回やって、このチームにとって一番最適なテストピラミッドのバランスを確立しました。 これによって、リリース頻度が週1回だったのをテストリアーキテクティングで週4回に増やすことができました。 ただここでも課題が… 品質について議論できていない のではないか…。 次のチャレンジです！ 継続的テスト 「 継続的テスト 」は作る前からリリースの後までずっとテストし続けるということです。 出典： テスト自動化から開発を支える継続的テストへ （P.56） 「 開発前 」 仕様を理解し、仕様の抜け漏れを減らす。つまりは開発～デプロイまでの必要なテストをリファインメントで計画を立てて合意（QA承認済）するため、自動テストが通ったらQAの判断を待たずに（QAは開発者をブロックせずに）デプロイできるようになります。 「 リリース前 」 未知の不具合を探るために、探索的テストをします。 「 リリース時（段階的ロールアウト） 」 ユーザーの反応を見るために一度にリリースしないでちょっとずつリリースしていく、段階的ロールアウトをします。 「 リリース後（GA（General Availability）） 」 全ユーザーに使ってもらい、GA（General Availability）＝ 監視を一つのテスト手段として使い、ユーザーがどんなふうに使っているかというのをテストします。 作る前からリリースの後までずっとテストし続ける「継続的テスト」をしたことにより、デプロイ頻度は週4回から毎日数回になりました！ さらにはチームの課題感も変わり、最初は開発プロセスの中の話ばかりしていたのが、どんなテストが必要か、自分たちがどういう価値をユーザーに提供できるかなど、気付けばチーム全体で 品質について議論できるように なっていました。 最後に末村さんは、「この通りにやれというわけではありません。この話をたたき台にして自分たちのチームでも話してみてください。チームの状況に応じたアプローチが必要です。」とおっしゃっていました。 確かにおっしゃる通り、この「継続的テスト」の取り組みは一つの事例で、全ての開発チームにそのまま適応できるものではなく、開発チームごとの課題やそれぞれの議論の結果があって、解決していくためのプロセスやヒントについてをこの講演から学ぶととらえるのが良さそうだと思いました。 感想 今回のセッションを聴いて、『品質を伴う「継続的テスト」を続けること』が重要だと思いました。ただただ「継続的テスト」をするのではなく、PO／開発者／QAそれぞれが「品質」マインドを持ち続けることでその先のユーザーへの価値提供につなげられると解釈しました。さらに時代と共にユーザーの求める価値が変化し続ける今だからこそ『品質を伴う「継続的テスト」を続けること』がマッチしているのだと思います。（ちなみに、今携わっている自身の開発チームはまさにこれを体現しているので講演を聴いた後、にんまりと幸せを噛みしめていました。） また、セッション内容とは別の観点で着目していたのは、今回一貫して段階的に体系立てて検証する進め方でした。末村さんがやっている「〇〇したことでXXが起こって、そこから出た課題、次のチャレンジ、成果をその都度丁寧に明らかにしていくサイクル」は本当に圧巻でした。これは日々の業務で意識している部分ではあるものの輪郭がぼやけてしまいがちなところでもあったので、自身の課題を見つめなおす講演にもなりました。さっそく明日からの仕事にこの学びを役立てていきたいと思います。 最後まで読んでいただき、ありがとうございました。 The post テスト自動化から、開発を支える継続的テストへ JaSST’23 Kyushu 参加レポート first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第12回目のテーマは、「リーンソフトウェア開発」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 リーンという思想 リーンソフトウェア開発は、リーン開発とも呼ばれています。 日本で生まれたトヨタ生産方式は、アメリカやヨーロッパのソフトウェア開発で活用・適用され、体系化されて日本に逆輸入された開発手法です。リーンの考えが、日本のソフトウェア産業に直結していかなかったのは、日本人として残念に思います。 リーンという言葉は、リーンスタートアップなど、現在、様々な書籍でも使われていますが、リーン開発自体はあまり話題にならないように感じています。どちらかというと不人気です。 その理由を考えてみると、リーン開発には、具体的なプラクティスが少なく、「22の思考ツール」と呼ばれるリーンの考え方（スクラムでも出てきたリーン思考）が、多く語られているからかもしれません。 リーン関係の書籍を読み解いていくと、リーン開発にはプラクティスがないのではなく、リーン思考をベースに現場に即したプラクティスを考えていきなさいというメッセージということが見えてきます。このあたりもスクラムととても似ています。 しかし、自分たちで考えるのは大切なことですが、読者を突き放したような言い方にも感じます。せっかくいい思想であっても、使われなければ意味がありません。せっかく、リーン思考、リーンの原則には、現在の開発でも通用するものがたくさんあるのに、このあたりはもったいないと思わざるを得ません。 リーン開発の本はこれまで3冊が日本語訳されています。もし、これからリーン開発を学ぶのであれば、廃盤になってしまいますが、『 リーン開発の本質 』がおすすめです。 この記事でも『リーン開発の本質』をベースに解説します。 リーンソフトウェアの7つの原則 リーンソフトウェアの7つの原則をみていきましょう。書籍『リーン開発の本質』を見ると、価値より原則が先に登場しています。 原則1： ムダをなくす ひとつめは「ムダをなくす」です。「ムダ」がカタカナなのは、リーンが海外からやってきた考え方だからでしょう。英語だと「Waste（無駄、浪費）」という言葉がありますが、トヨタの考えが尊重された結果、「無駄」が「ムダ」になり、その言葉自体が海外でも通じるようになりました。 トヨタ生産方式を源流とするリーン開発なので、ムダ取りは大切な原則でしょう。ムダを見つけ、ムダをなくすことで、顧客への価値提供を最短距離で行っていきます。また、ムダをなくすのは、さまざまなアジャイル開発手法でも取り入れられている考え方です。そう考えると、トヨタ生産方式はさまざまな開発手法に影響を与えたのだと言えます。 原則2： 品質を作り込む 2つ目は「品質を作り込む」です。 事後に欠陥を見つけるのではなく、最初から欠陥が入り込まないようにしていくこと。これを「作り込む」と表現しています。 ソフトウェアだと、作ったあとでも修正ができてしまうので、「作り込む」という意識を持ちにくい部分があるのかもしれません。しかし、トヨタ生産方式だと、生産物が車なので、欠陥を後で取り除けません。製品に欠陥が入り込むと、命の危険にもなります。 日本だと、ソフトウェアのテストは、作ったものをテストするのが主流です。しかもバグを出すと大騒ぎする文化なので、大量のテストを、手動で実行する現場も多いでしょう。トヨタ出身の人が言っていたこんな言葉があります。 すでにバグが埋め込まれているものをテストしてバグを取り除いても、品質がいいとは言えない。 バグを取り除くことに必死になるのではなく、バグそのものが埋め込まれない仕組みや方法を考える必要があります。そうしなければ、開発がバグを作り、テストで発見するという、非効率なもぐらたたきがずっと続いてしまいます。 「品質を作り込む」も、開発手法全般で大切にされている原則です。 原則3： 知識を作り出す 3つ目は「知識を作り出す」です。 ソフトウェア開発は知識創造のプロセスです。プロセスを運営しながら知識を生み出し、成果物だけでなくプロセス本体も改善していきます。 原則4： 決定を遅らせる 4つ目は「決定を遅らせる」です。 ソフトウェア開発において、最初にすべてを決めるのは不可能と言えます。なぜなら、未来を見通すのが難しいからです。 書籍には「ソフトウェアの詳細な設計は、コーディングの最中に行われるものである」とも書かれています。設計を詳細に書きすぎるとコードに近づいてしまいます。だから、あえて決定を遅らせて、コーディング中に設計していく・・・のもひとつの手かもしれません。 意思決定は素早く行うことも大切ですが、「決定を遅らせる」では、大切な意思決定を「あえて」先延ばしし、ぎりぎりまで情報やフィードバックを集めて、決定を行います。 原則5： 速く提供する 5つ目の原則は「速く提供する」です。ひとつめの「ムダをなくす」でもでてきた「速い価値提供」です。 スピードを強みとすることで、競合他社との競争に打ち勝ちます。これはリーンに限らず、アジャイル開発の本質とも言える内容です。 原則6： 人を尊重する 6つ目の原則は「人を尊重する」です。 書籍には「トヨタの製品開発システムの4つの基本理念のうち、3つまでが、製品開発プロセスに携わる人に関係している」とあります。ソフトウェア開発は人間中心の活動です。 さらに、トヨタ生産方式では、自動化を、ニンベンの付いた「自働化」という表現にします。人間を大切にしたトヨタ生産方式らしい表現だと思います。 原則7： 全体を最適化する 最後の原則は「全体を最適化する」です。 リーンではアイデアが生まれてリリースするまでの流れを「バリューストリーム」と捉えて改善していきます。バリューストリームは、日本語にすると価値の流れです。リーン開発ではバリューストリームの一部分ではなく、全体を最適化します。 全体を見ず、部分最適をしても、問題がどこかに移動してまた別の問題が生まれてしまいます。だから、全体を見ながら改善を行っていきます。これは制約理論という有名な理論でも語られています。 リーンソフトウェア開発の22の思考ツール 最後に、リーンソフトウェア開発の22の思考ツールを解説します。この思考ツールは、XPでいうプラクティスに似た立ち位置のものです。これらのツールは7つの原則に分類できます。 1. ムダをなくす ムダを認識する バリューストリームマッピング 価値の流れを図解し、流れる時間を計測して流れを短縮していく 2. 品質を作り込む 認知統一性 統一性を作り込む コンセプト統一性 統一性を作り込む リファクタリング テスティング 3. 知識を作り出す フィードバック イテレーション 同期 集合ベース開発 チーム開発 4. 決定を遅らせる オプション思考 最終責任時点 意思決定 5. 速く提供する プルシステム かんばんの考え方 待ち行列理論 リーンとは別の理論 遅れのコスト 6. 人を尊重する 自発的決定 モチベーション リーダーシップ 専門知識 7. 全体を最適化する 計測 契約 より詳細を知りたい場合は、書籍『 リーンソフトウエア開発 アジャイル開発を実践する22の方法 』をご確認ください。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 The post 第12回 リーンソフトウェア開発 first appeared on Sqripts .

はじめまして！テストエンジニアの「大の字」です。 私はゲーム業界でテスターを経て、エンタープライズ業界のテストエンジニアになりました。 今回は、エンタープライズ業界に転身したことで気付くことが出来た「デバッグ」と「テスト」の違いについてご紹介したいと思います。 気付き 前職のゲーム業界では、「デバッグ」や「デバッガー」という言葉が「テスト」「テスター」と同じ意味で扱われていることが多く、私自身も「デバッグ」と「テスト」は同じ言葉の意味だと思っていました。 しかし、エンタープライズ業界でテストの知識を学ぶうちに2つの言葉はまったく異なる言葉の意味だと知りました。 今回はJSTQB認定テスト技術者資格のシラバスを通して、「デバッグ」「テスト」の意味や他にもよく誤解されやすい言葉「エラー」「故障」「欠陥」の意味を再確認してみることにしました。 デバッグとは？ 私は以前まで「デバッグ」は開発者がプログラムのバグを見つける行為だと、ざっくりとしたイメージで認識していました。 では、実際にはどのような意味かをJSTQBのシラバスで確認してみましょう。 デバッグは、故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動である。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ ふむふむ、なるほど！つまり、プログラム内に潜んでいる欠陥を見つけて、原因のプログラムコードをチェックして欠陥を取り除く行為自体が「デバッグ」という意味なんですね。 では、故障の原因である欠陥を取り除いた後、本当にその故障が無くなったかは確認しないのでしょうか？その答えは、これから紹介する「テスト」にありそうです。 テストとは？ 私は「テスト」といえば、テスト手順通りに実行して期待する結果と一致しているかどうかを確認する行為だと思っていました。では、正しい意味はどうでしょうか？JSTQBのシラバスを確認してみましょう。 テストは、実行することでソフトウェアに存在する欠陥に起因する故障を示すことができる JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ 「テスト」とは、欠陥が原因の故障が発生するかどうかを示すことができるんですね。また、故障の発生は確認できますが、その欠陥の原因が特定できないことも特徴と言えます。 では、その欠陥を「デバッグ」で取り除いた後、発生していた故障が修正されたことの確認は行わないのでしょうか？その問いには、再度シラバスの記載を見てみましょう。 テスト担当者が確認テストを実施し、修正により欠陥が解決したことを確認する。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ なるほど。「デバッグ」を行って修正後に「テスト」を行い、検出した欠陥が無くなったこともきちんと確認するんですね。 エラーとは？ 私は「エラー」といえば、プログラム内で誤った動作が発生することだと思っていました。 では、またまたJSTQBのシラバスで意味を確認してみましょう。 人間はエラー（誤り）を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥（フォールトまたはバグ）となる。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 1 つの作業成果物で欠陥を発生させるエラーは、他の関連する作業成果物でも欠陥を発生させる可能性がある。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 テスト業界での「エラー」の意味は、プログラム内だけではなく、ヒューマンエラーを含んだ意味なんですね。ソフトウェアのエラーに留まらず、テストを行う上で発生する人為的なミステイクを含む意味であることが分かりましたね。 次は「デバッグ」「テスト」「エラー」をより深く理解してもらうため、上記3つの中で使われている「故障」と「欠陥」という言葉の意味についてご紹介します！ 故障とは？ JSTQBのシラバスでは下記のような定義がされています。 コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること 「故障」とは、システムが期待する結果と異なる結果になることを意味するのですね。私の経験則上では1つの欠陥で複数の故障が発生することがある印象があります。「故障」を検出するための活動としてテストを行うので、イメージがしやすいですね。 欠陥とは？ JSTQBのシラバスでは下記のような定義がされています。 システムの要件や機能が実現できない原因になる不備や欠点 「欠陥」とは、要件や機能が満たせない「故障」の原因のことなんですね。また、テストによって「欠陥」が存在していることは示せますが、「欠陥」が存在しないことは証明できません。つまり、ソフトウェアに残存する未検出の欠陥数は減らせますが、「欠陥」が見つからないとしても残存する「欠陥」は無いとは言い切れないのが特徴です。 テストをもっと詳しく では、言葉の意味が分かったところで少しテストについて深掘りしていきたいと思います。 テストといえば、以前の私のようにソフトウェアの動作を確認して期待する結果が得られるかを確認するだけと認識されている方もいると思います。しかし、実はテストには下記のような様々な活動のプロセスが存在します。 「テスト計画」「テストのモニタリングとコントロール」「テスト分析」 「テスト設計」「テスト実装」「テスト実行」「テスト完了」 また、テストプロセスにはいくつかのメリットがあります。 プロセスを分けることで、各担当の作業範囲齟齬などのヒューマンエラーが予防できる プロセス毎にエキスパートな人員をアサインすることにより、作業の効率化を実現できる テストプロセスの中で問題点があった場合、どのプロセスに問題があったかを分析し、改善を続けることができる テストプロセスを段階的に行うことで、人為的なミスの防止や作業の効率化、各プロセスの改善等が可能になり、リスクの軽減にも繋がります。 まとめ 「デバッグ」と「テスト」の役割について、理解が深められたでしょうか。欠陥を取り除く「デバッグ」も大切ですが、「テスト」によって故障を検出することで欠陥があることが分かるため、「テスト」は必要不可欠な存在であり、ソフトウェア品質を保つための最後の砦であることがお分かりいただけたと思います。 また、エンタープライズ業界ではシステムの大規模化や複雑化、短納期化が日々進んできています。これらを実現するためにテストプロセスを上手く活用して、ヒューマンエラーの予防や作業の効率化、テストを改善していく仕組み作りが出来ることを今回学べました。 みなさんも今回を機会に各テストプロセスにどのような役割があるかを調べてみるのもいいかもしれませんね。 「/Sqripts」では、テストプロセスについても紹介しています。是非チェックしてみてください。 ・基本的なテストプロセス 基本的なテストプロセス ・テスト分析の重要性～テストを支える縁の下の力持ち～ テスト分析の重要性～テストを支える縁の下の力持ち～ ・テスト設計技法 テスト設計技法 The post テストとは何か？デバッグとは違うの？ first appeared on Sqripts .