この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第14回目のテーマは、リーンスタートアップとDevOpsを解説します。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 ＜あらためて学びたいアジャイル開発　連載一覧＞ ※クリックで開きます 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 第14回：さまざまな方法論 − リーンスタートアップ・DevOps リーンスタートアップ リーンスタートアップは、2011年にエリック・リースさんが考えた、主にスタートアップのための起業の開発手法です。アジャイル開発から派生した開発手法ですが、これまでの開発手法が開発寄りだったのに対し、事業やプロダクトよりの内容なので、ビジネス側の人間や起業家など、開発外の人たちに影響を与え、もう10年以上前になりますが、日本語訳がでたときは、とても話題になりました。 とくに、当時MITメディアラボの所長だった伊藤穰一氏がリーンスタートアップを、「 地図を捨ててコンパスを頼りに進め 」と例えているのも有名です。この言葉は、まさにアジャイル開発を表した言葉と言えます。 その名のとおり、リーン思考の影響をうけており、起業して開発したプロダクトに対して、成功に導く確率を高めるための方法がまとめられています。起業家だけでなく、ソフトウェアを使った新規事業を立ち上げるときにも参考になる内容です。 リーンスタートアップのサイクル リーンスタートアップのフィードバックサイクルは上の図のようになっています。アイデアができ、コードが作られ、データを集め、さらにアイデアにつなげていく流れになっています。このあたりはXPやスクラム、アジャイル開発全般の流れにとても似ていますが、データを重要視している点が、今風なスタートアップが好むところでしょう。 リーンスタートアップが広まったあとに、リーンUX、リーンキャンバスなど、たくさんのリーン系アイデアも登場するようになってきました。当時のシリコンバレーでは、リーン思考がブームになっていたのだと思います。 一方で、10年経った今、リーンスタートアップを見てみると、あまり話題になることはなくなりました。時代遅れという言葉もちらほら見かけます。リーンスタートアップの実績が国内でどれだけ出てくるのかが楽しみです。 DevOps 切り離してはならないものを切り離してしまうと、問題が起きがちです。たとえば、開発とテスト。たとえば、開発と運用です。開発と運用が別れてしまった場合、問題の多いソフトウェアをデリバリーしてしまい、運用が疲弊するといった問題が起きたりします。こういった弊害を解決する方法はずっと議論されてきましたが、そこから「DevOps」という言葉が生まれてきたのだと思います。 DevOpsについては、ここでは開発手法として列挙していますが、 Wikipedia やさまざまなイベントの発表資料を調べてみると、開発手法としてのDevOpsもあるみたいです。一昔前だと、開発と運用が分離している組織において「サーバのAdmin権限を与えるのがDevOpsだ」という意見もありました。ちょうどそういう現場で働いていたので、「権限を与える ＝ 信頼する ということなのだな」と妙に納得した記憶があります。 図は [翻訳] DevOpsにおける継続的テストとは何か？ より DevOpsは、上記の画像のように、無限大の形で表現されることが多いです。見てのとおり、左側に開発をさす「Dev」があり、右側には運用をさす「Ops」があります。それぞれのループでPlan、Branch・・・といったアクティビティが並んでおり、2つのループがつながって無限大のような形になっています。このサイクルを高速にまわすことで、改善を続けていきます。 DevOpsに関しては、画像共有サイトのフリッカーのエンジニアが発表した「 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr （意訳： 一日に10回以上デプロイする： フリッカーにおける開発と運用の協力体制）というスライドが有名です。 DevOpsが誕生する2009年の発表ですが、今見てもヒントがたくさんある内容です。当時のフリッカーはブロガーに大人気のサイトでしたが、トップクラスの企業は、日に10回もリリースするのか！と私は当時衝撃を受けました。この日に何回もデプロイ・・・というのは、現在でも継続的デリバリなどの文脈で話題になるプラクティスと言えます。そして、Flickerの発表から10年がすぎ、今では日に何回もリリースするのは当たり前になりました。 DevOpsを実現するツール DevOpsのそれぞれのカテゴリ・アクティビティは、ツールで実現できます。 コード： GitHubやGitLabなど ビルド： JenkinsなどのCIツール テスト： 自動テスト、  パッケージ ： コンテナ技術、ライブラリ管理 リリース： リリース自動化 コンフィギュレーション： インフラの自動構築、オーケストレーションツール モニター： パフォーマンスモニタリングツール これまで紹介したプラクティスとは違い、ツールで実現しようとしているのは興味深い点です。ツールを活用するのが得意な日本人であれば、DevOpsの導入障壁は比較的低いかもしれません。 DevOpsのメトリクス： デプロイ頻度 DevOpsの目標はとても具体的なメトリクス（指標）として示されています。 ひとつめの指標は、デプロイの頻度です フリッカーの事例にもありましたが、リリースの頻度をカウントします。リリース回数を数えることで、継続的な改善が行われているかどうかの目安になります。 DevOpsのメトリクス： 変更のリードタイム 2つ目は「変更のリードタイム」です。 ソースコードに変更のコミットが行われ、それが本番環境にリリースされるまでの時間をリードタイムとして計測します。これは短ければ短いほど、ユーザに価値が素早く提供されていると考えることができます。 DevOpsのメトリクス： 変更障害率 3つ目は「変更障害率」です。 いくらリリース回数が増え、リードタイムがはやくなっても、変更したときの障害が多くなってしまったらもともこもありません。回数を増やし、時間を短くするのと同時に、障害が発生する割合をかぎりなくゼロにしていく必要があります。 DevOpsのメトリクス： サービス復元時間 最後は「サービス復元時間」です。MTTR (平均復旧時間または平均修復時間)とも呼ばれます。 障害が起きてしまった場合にどれぐらいの時間で回復できるかを計測します。短ければ短いほど、ユーザーへの影響は小さくなります。 これらの目標は、4 Key Metrics と呼ばれています。 4 Key Metricsは、2022年にリリースされた最新のテクノロジー動向がまとめられた「 テクノロジーレーダー 」というレポートでも、積極的に採用すべきものとして取り上げられています。よって今後、 この4 Key Metricsが、世界中に広がっていく可能性を秘めています。 DevOpsについては、さまざまな書籍が出ていますが、今回紹介した4 Key Metricsという目標を中心に調べるとわかりやすいです。このあたりの情報がよくまとまっているのは、書籍『 LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する 』です。継続的デリバリーのJezz Hanbleさんも著者に名を連ねています。 Googleからも 4 Key Metricsのレポートが公開されています 。ご興味があれば、あわせてご確認ください。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 第14回：さまざまな方法論 − リーンスタートアップ・DevOps The post 第14回 さまざまな方法論 − リーンスタートアップ・DevOps first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 私は中国やベトナムの企業を活用したオフショア開発プロジェクトのPMOとして活動してきました。 昨今のオフショア開発は日本企業内にノウハウが蓄積されて開発プロセスも成熟してきましたし、オフショア企業も日本企業の商習慣や品質基準の理解が進んできたことで成果物の品質も安定してきた印象があります。 いまやオフショア開発なしのソフトウェア開発に出会う方が少ないのではないでしょうか。 しかし数年前のオフショア開発では、これまでのソフトウェア開発ではあまり出会うことのなかった問題が出てくるため、日々新しい課題と向き合いながらプロジェクトを進めていました。 そんなオフショア開発でよく目にしていた事例と、その改善策の一例をご紹介いたします。 問題：動くことを優先する傾向がある オフショア開発の魅力の１つにコーディングのスピードがありますが、仕事の進め方を聞いてみるとトライ＆エラーを繰り返して作り込んでいくメンバーが多かったです。 オフショアメンバーが不慣れなプログラム言語であっても、習得速度は早くどんどん作り込んでいきます。 しかし、正しく実装しているかは受入側が慎重に確認する必要があります。色々試したけど上手く動かなかったという理由で、基本設計の方針（例えばアーキテクチャ設計）とは違った独自の設計で対応することがあるからです。 コードレビューで検出できるものもありますが、コード量が多いと見落としてしまうケースがあります。他にも動作確認すると動いているように見えてしまうためレビューが甘くなることもあります。そのためプロジェクトが進んでいくと従来の設計と独自の設計で整合が取れなくなる処理が出てくることがあります。 修正するにも工程を遡らないと修正できない重篤なバグに繋がることがあり、品質を安定させるために多くの工数が必要になってしまいます。 対策 詳細設計書を日本側で作成する、作業指示書内容を充実する、リリースされたソースコードを細部までレビューする、など対応できることは多くありますが、現実的にはその工数に耐えられないことが多いです。 このような場合はすべてを一気に解決しようとしても無理があるため、優先度をつけて段階的に解決するように進めるのが良いと思います。 一例として軽微なバグには目をつむり、重篤なバグ検出を減らすために基本設計に沿っているかという観点のみ集中してレビューする、という対策が考えられます。 効果 基本設計以外のコードレビューは優先度を下げることになるため、バグの検出数が大きく減ることはないと思いますが、重篤なバグを減らすことでバグの再指摘の件数やデグレの発生が減り、バグの消化件数が伸びていきます。 また、レビューを通じて設計の理解も深まっていき、最終的にはオフショア側の内部レビューだけで基本設計からの逸脱を予防できるようになり、品質が安定していきます。 時間の経過とともに品質が向上していくため、その後の計画も立てやすくなるのではないでしょうか。 問題：影響範囲に対する認識の違い オフショア開発をしていると商習慣や文化の違いに戸惑うことがあります。 例えば私がプログラマーとして活動していたときは、ある関数を変更する場合、その関数が使用されている処理すべてで問題ないことを確認していました。 それは誰かに指示されたりドキュメントに明記がなくてもすることと教育されていたため、プログラマーだったら当たり前の行為だと思い込んでいました。 そのため影響範囲が記載されていないドキュメントを見ても、影響範囲は調べればわかることなので気にすることはありませんでした。 オフショア開発は設計書と作業指示書をベースに作業を進めてもらうことが多いですが、影響範囲について言及しないと対応漏れに繋がり、修正を繰り返すことになってしまいます。 対策 「影響範囲を理解している日本側ですべての影響範囲を記載する」という対策も取れますが、オフショア開発を長い目で見ると問題を先送りしているだけで、次のオフショア開発でも同じ問題に直面することになるでしょう。 「影響範囲も確認するように指示する」といった意見が出ることもあります。しかし、日本人相手なら通用するかもしれませんが、オフショア開発だと指示が抽象的で上手く伝わらないケースが多いです。 「影響範囲を確認する」という依頼をする場合は、日本側が考えている影響範囲とは何か、どのようなプロセスを踏んだ結果なのか、こちらの想定や考えを含めて伝えるようにしましょう。 例えば、「この処理は他の機能でも共通で使用される」「他の機能の処理が変わらないことを確認する」「この処理の使用箇所を検索して、使用箇所すべて処理が変わっていないことを確認する」などです。 また、それらをチェックリスト形式で記載することにして、適切に実施されたのかをレビュー時に確認することを徹底すると、より良いと思います。 効果 検索の仕方まで明記するのは冗長かと思いましたが、こちらが何をしてほしいのか明確に理解できるとオフショアメンバーからは好評だったりします。 レビューを繰り返すなかで作業が定着していくものは、徐々に記載を省略できるようになりますが、チェックリストに沿って影響範囲を確認した上でリリースしてくれるようになり、品質が安定していきます。 このように作業プロセスを浸透させたり、育てていくことで品質の向上に繋がります。 さいごに ITのプロジェクトはオフショアに限らず品質に関する問題が発生するものですが、オフショアではさらに「時差」「言葉」「商習慣」「文化」の違いがあるため、より多くの問題が発生します。 特に「情報が正確に伝わらない」ことに起因する問題に頭を悩ますことが多く、今回ご紹介した事例も情報の伝達や意思疎通がきちんとできていれば回避できたのではないかと考えています。 日本人は行間を読み解いて作業を進める傾向があるので、日本側で作成したドキュメントは情報が不足している、曖昧な表現が多い、主語／述語／目的語を省略している、など誤りや勘違いを生む内容になりやすいです。 私が設計書や作業指示書を作成するときに、2つ実践していたことがあります。 1つ目は「文章で表現せずに箇条書きにする」です。 これだけで主語／述語／目的語を省略し辛いのと、表現も簡潔なものになるため翻訳も容易になりました。 2つ目はレビューです。 このような表現の問題は作成している本人では気づきにくい事が多いため、第三者にレビューして貰うことを徹底していました。 繰り返しになりますが、ITのプロジェクトは品質に関する問題が必ず発生します。 品質の問題といっても多種多様で、改善策も一括りにこれというものはなく、日々頭を悩ませていますが、今後もプロダクト品質やプロセス品質、いずれの品質問題も適切なアプローチで解決できるクオリティマネージャーになれるように精進して参りたいと思います。 【サービス紹介】 ドキュメントインスペクション ドキュメント品質にお困りのみなさまへ、第三者視点によるドキュメントレビューをサービスとして提供しています。 ■ ドキュメントインスペクションのサービス紹介はこちら ｜株式会社AGEST 「インスペクション」とは― 組織全体の品質改善スキル向上に導入効果の高い「インスペクションレビュー」を紹介 The post オフショア開発で品質向上に取り組んだこと first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はアジャイル開発におけるスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、プロダクト開発で起きたシステム課題に対して、導入の敷居が低いスプレッドシートを中心に解決を行った体験談を書きたいと思います。 エラーメッセージに関する課題 現在関わっているシステムにおいて、ある日、エラー制御に関する問題点が開発チームから上がりました。 1. 画面で表示されるメッセージの統一性が欠けている 2. システム共通のエラーコードが存在しない 詳細を解説します。 1.メッセージの統一性 例えば、データを一覧表示する画面でデータ登録件数が0件だった場合、通常は「データが登録されていません」という趣旨のメッセージが画面に表示されます。 データの種別が異なる場合でも、同じ事象のメッセージには統一性を持たせたいところですが、現在関わっているシステムでは、フロントエンドで一部メッセージをハードコーディングしており微妙に表記揺れが存在していました。 これだけだと共通処理を作って解決すればよいとはじめは思いましたが、このメッセージは運用を続ける中で、内部/外部からの指摘で変わる可能性があり、また複数言語向けにメッセージも管理したいなど、単に共通処理を作って解決は難しい状況になっていました。 2.システムのエラーコード Webシステムで使うエラーコードの代表例はHTTPステータスコードです。 例えば400エラーは BadRequest という意味ですが、複数の画面でそれぞれ起こり得る可能性があり、どの画面で400エラーが発生したかをログ等から特定したいとのことでした。 もちろん、ログの設定なり組み合わせで特定は可能ですが、パッと見て分かりにくいですし、運用メンバーがメッセージからどの画面の事象かを特定できれば運用コストの削減になります。 問題の解決方法と要件 これらの問題の解決方法として、システム全体で使うエラーコードとフロントエンドで表示するメッセージを紐づけて管理することにしました。 運用を加味して要件をまとめたところ、下記の通りとなりました。 1. 定義するデータの保存場所は、DB、テキストなど形式は問わない。 ただし、システムとして、フロントエンドとバックエンドでそれぞれ参照したい。 2. エラーコードに紐づくメッセージは、POをはじめ関係者が閲覧でき、場合によっては編集したい。 3. 今後、新機能が実装されるたびにデータを追加したい。 3.に関しては、運用次第でメッセージを変える可能性があること、運用や評価を行う上で開発者以外のメンバーも閲覧できることが必要なためとなります。 システム構成 シンプルな構成になりますが、後でマニュアルとして残すために、 GoogleCloud Developer cheat sheet を用いてシステム構成図を作成しました。 データの保存場所は、手軽に使えるスプレッドシート採用しました。 スプレッドシートは使用する敷居がとても低く、アクセス権を設定することで、直接開発に関わらないメンバーも閲覧/編集することが可能ですし、Jsonなどのテキストファイルと比べるとリポジトリへのアクセス権も不要で視認性も良いです。 ただし、スプレッドシートをシステムから直接参照するのはAPIを介した通信により様々なコストがかかるため、GAS （Google Apps Script）でJsonを生成してリポジトリにcommitする形式を採用しました。 GASのサンプルコードと注意点 GASの処理はシンプルで、フロントエンド用とバックエンド用に関数を2つ作り、後の処理は共通化して別関数に切り出しました。 一部、エラー制御は省いた主要処理のサンプルコードを掲載します。 // Slackにメッセージを送信 function notifySlack(message, filePath, type) { // SlackのWebhook URL、チャンネル名を指定 const slackWebhookPath = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_PATH'); const requestUrl = "<https://hooks.slack.com/services>" + slackWebhookPath; // Google Driveの特定のフォルダにファイルを作成 const folderId = PropertiesService.getScriptProperties().getProperty('DRIVE_FILE_PATH'); const folder = DriveApp.getFolderById(folderId); const file = folder.createFile('error_code.json', JSON.stringify(message), MimeType.PLAIN_TEXT); // 共有リンクを作成してSlackに送信 const url = file.getUrl(); const payload = { text: type + 'JSONを生成しました。共有リンクです：' + url + '\\n' + filePath + 'に貼り付けてください' }; const options = { method: 'post', contentType: 'application/json', payload: JSON.stringify(payload) }; UrlFetchApp.fetch(requestUrl, options); } // JSON生成処理 function generateJson(getErrorCodeAndInfo, filePath) { // スプレッドシートのデータを取得する const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('data'); const data = sheet.getDataRange().getValues(); // JSONを格納するオブジェクトを作成する const json = {}; // シートの各行を処理する for (let i = 2; i < data.length; i++) { const row = data[i]; const { errorCode, errorInfo } = getErrorCodeAndInfo(row); // エラーコードをオブジェクトに追加する json['data'][errorCode] = errorInfo; } return json } // バックエンド用の共通エラーコード取得処理 function backendStatus(row) { // エラーコードを取得する const errorCode = row[2]; // エラー情報を取得する const errorInfo = { 'number': row[3], 'httpStatusCode': row[4], 'httpStatus': row[5], 'message': row[6] }; return { errorCode, errorInfo }; } // フロントエンド用の処理 function frontendMessage(row) { // エラーコードを取得する const errorCode = row[2]; // フロントエンドメッセージの取得 let message = ''; if (row[7]) { message = JSON.parse(row[7]).ja } // エラー情報を取得する const errorInfo = { 'message': message }; return { errorCode, errorInfo }; } // バックエンド用の関数 function generateErrorCodeJson() { const filePath = ''; // JSONのパスを書く const type = 'システムエラーコード' const message = generateJson(backendStatus, filePath); notifySlack(message, filePath, type); } // フロントエンド用の関数 function generateFrontMessageJson() { const filePath = ''; // JSONのパスを書く const type = 'フロントエンドエラーメッセージ' const message = generateJson(frontendMessage, filePath); notifySlack(message, filePath, type); } 初期段階ではGASで生成したJSONをSlackにテキスト送信していましたが、ある程度の長さに達したら省略されてしまったため、途中でDriveに切り替えました。 また、JSONは手動でソースに反映しcommitが必要ですが、将来的にこの運用が長く組み込まれるようになった際は、CI/CDで自動で生成し配置なども検討します。 メリットとデメリット この構成のメリットは、利用の敷居が低くシンプルな構成であること、運用における変更や拡張の要望にとても柔軟に対応できることが挙げられるます。 GASなら、例えばチーム内でエンジニアメンバー以外が管理を引き継ぐ際にも、ブラウザがあればデバッグやデプロイまで出来るため、ChatGPT等でのサポートによりメンテナンスがし易いと考えています。 clasp + TypeScriptで書くのが理想ではありますが、先述の理由に加え、運用途中でシートの形式が変わることが想定され、加えてLambdaやCloudFunctionsなどに移行する未来も有り得ることから、一旦はGASのまま管理することにしました。 デメリットとして、手軽すぎる構成なので壊れやすいという点が上げられます。 例えばスプレッドシートを想定外の形式で編集された場合、GASの作りによりますが、実行が失敗してしまいます。 この場合、バリデーションを行う処理を別で準備したり、入力規則や編集不可な箇所を設定することで対策を行えます。 おわりに 今回の内容は以上となります。 既存の困っていることを解決したいという声が開発チーム内で上がったことがきっかけでしたが、運用を含めて最初はカッチリとした仕組みにせず、スピード感を持って導入し、本格運用したら徐々に見直す形をとりたいと考えています。 今回の内容がプロダクト運用において何かの参考になれば幸いです。 The post スプレッドシート × Google Apps Scriptでシステム仕様をシンプルに管理！ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第4回となる今回のテーマは「統合マネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 統合マネジメント 統合マネジメントという言葉は、あまり聞き慣れないかもしれませんね。 私も時折「統合マネジメントってなんですか？」「具体的に何を行えばいいのか？」といった質問を受けます。 統合マネジメントは簡潔に言うと「プロジェクトのすべての要素を調整」する活動です。 PMBOKでは「プロジェクトマネジメント・プロセス群内の各種プロセスとプロジェクトマネジメント活動の特定、定義、結合、統一、調整等を行うために必要なプロセスおよび活動」と定義されています。 プロジェクトは有期的で独自性のある活動＝ひとつとして同じプロジェクトはありません。リソース、コスト、納期、関わる人々、目的などのすべての要素を総合的に管理・調整することではじめて、プロジェクトマネジメントが実現します。 プロジェクトは固有であり、複数の利害か関与するダイナミックで複雑なものです。プロジェクトの目的を達成する為に、今どのような状態にあって何をすべきかを考える際、プロジェクト統合マネジメントが不可欠です。そして統合マネジメントはプロジェクトマネージャー固有の領域として、PM自身がその活動を担当・指揮していきます。 統合マネジメント７つのプロセス 統合マネジメントではプロジェクト活動に関する総合的なアプローチがなされます。そこではプロジェクト活動を効果的に調整するための「7つのプロセス」を定義しています。 (1) プロジェクト憲章の作成 (2) プロジェクトマネジメント計画書の作成 (3) プロジェクトへの指揮とマネジメント (4) プロジェクトに関する知識のマネジメント (5) プロジェクト実行の監視とコントロール (6) 統合変更管理の実行 (7) プロジェクトクローズ 次から各プロセスを詳しく見ていきましょう。 (1) プロジェクト憲章の作成 プロジェクトの羅針盤とも言える「プロジェクト憲章」、みなさんの組織やプロジェクトでは書いていますか？ プロジェクト憲章はプロジェクトと組織の戦略目標とを結びつけて、プロジェクトへの組織のコミットメントを示すものとされ、通常はプロジェクト初期に1度だけ作成される、プロジェクトの基礎となるドキュメントです。 1）プロジェクト憲章を作り前に行うこと（準備） プロジェクト憲章を作成するもととなる情報が必要です、それはなんでしょうか？主には前段階で作成された（されているであろう）プロジェクト作業範囲記述書（SOW：Statement of Work）やビジネスケース、外部発注の場合には契約書やSLAなどをもとに作成します。 プロジェクト憲章より前に作成された、適当なプロジェクト関連文書類を入手する 文書間の整合性や実現可能性が低い内容がないか確認する 必要に応じて、不明点等を関係者に確認したり交渉を行う 必要になる文書・情報は業種業態、企業文化、そもそもプロジェクトが発注側か受注側か、組織内プロジェクトなのかといったものによっても変わります。自身のプロジェクト憲章作成に対してどのような情報が必要かというイメージやリストを事前に持っておきましょう。 2）プロジェクト憲章に何を記載するか プロジェクト憲章に何を記載するかは、「何を明確にしておかなければならないか」と考えましょう。プロジェクト憲章に明確なフォーマットはなく、プロジェクトの規模や複雑さ、組織内のルールなどによってその記載ボリュームは増減します。プロジェクト憲章はハイレベルな記述によりプロジェクトないの共通理解とその視座をあわせます。 ここでは最適限記載して欲しい項目をご紹介します。 ビジネスニーズ プロジェクトの概要・目的/目標、終了基準 ビジネスケース（メリット） 成果物 納期とマイルストーン 条件（前提条件・制約条件） 予算（承認された財源） 主要なリスク プロジェクト組織体制 役割や権限 変更管理方法 承認者 3）プロジェクト憲章は誰が作るか問題 ドキュメントの性質からプロジェクトのイニシエーターやスポンサーが発行（作成）します。しかし組織によってはプロジェクトマネージャーが作成し、その確認/承認をスポンサーから得るという手続きが多いようです。著者の感覚としても後者の割合が高いと感じます。プロジェクト憲章の存在は前述したようにプロジェクトとPMの活動を助けるものですから、組織内の慣習を理解しながら早めはやめの作成を心がけたいものです。 (2) プロジェクトマネジメント計画書の作成 ハイレベルなプロジェクトアウトラインがプロジェクト憲章で整理されたら、次のステップとしてプロジェクトマネジメント計画書を作成し、詳細な計画作成に入ります。主にプロジェクトの実行、監視コントロール、終結についての方法を規定しますが、要約レベルでも詳細レベルでも大丈夫で、憲章と同じようにプロジェクトの特性に応じた詳細さで記述しましょう。 計画書作成の基本的なステップ (3) プロジェクトへの指揮とマネジメント 前のステップまでに整理された計画を実行に移し、その活動を指揮（リード）して成果物を作成、必要に応じて修正を加えるプロセスです。PMはプロジェクトチームへ指示を与え、会議開催や日々その進捗状況をウォッチして、プロジェクトの計画に沿って効果的に活動がなされているかを確認します。このフェーズで得られる（＝プロジェクトとして残さなければならない）以下のアウトプットを意識して進めましょう。 成果物 成果物は「固有で検証可能なプロダクト、所産、またはワービスを提供する能力で、プロセス、フェーズ、またはプロジェクトを完了するために生成したもの」と定義されます。要するにプロジェクトの成果です。 作業パフォーマンス・データ プロジェクトマネージャーは、プロジェクト実行時に得られた観測値や測定値を管理、収集し、これらはプロジェクトの資産としてこれからのプロジェクトに生かされます。 例えば） ・アクティビティの予実　→ XXタスクはX日で実施できると思っていたが、実際はその倍を要した。 ・変更要求の数　　　　→ 当該A_PJ規模での変更要求数から鑑みて、類似プロジェクトBも同等の予測ができるだろう。 課題ログ プロジェクトで挙がった課題は対応経過が追跡されると同時に、記録として残しましょう。 変更要求ログ プロジェクト実行中に挙がった変更要求もその対応経過と共に記録します。 (4) プロジェクトに関する知識のマネジメント プロジェクトに関する知識のマネジメントとは、過去に得られた情報やツールを利用したり、プロジェクトの目標達成に必要な知識を得て活用するプロセスを指します。またプロジェクト活動で新たに得られたナレッジは、その後のプロジェクトや組織に再活用され、これらを繰り返していくことが大切です。 1）プロジェクトは一から作らない 筆者の経験からも、プロジェクトを１から建てつけることはほとんどありません。プロジェクトに必要な知識や情報は社内（外）に豊富に存在します。例えばBプロジェクトの前身であるAプロジェクトに関わったXXさんであれば、Aプロジェクトのドキュメント一式にアクセスでき、教訓登録簿等などを現在のプロジェクトに活かすことができるでしょう。プロジェクトを任されたら「よし作ろう」ではなく「よし、情報収集しよう」という意識で社内の情報を集めることから始めましょう。 残念ながらそのような情報がない、蓄積されていない、という場合は自組織のプロジェクト高度化のために、知識の蓄積や管理を自組織に対して提案してみましょう。 2）暗黙知を形式知化する 暗黙知とは経験やノウハウといった、明確に表現することが難しい知識を指します。この知識を共有するには会話や相互作用が必要です。いかに暗黙知を形式知（文書化できる知識）にして生かしていくか、を意識しましょう。 3）ナレッジの源泉を引き出す プロジェクト中に起こった問題や課題、或いはこれは上手くいった、というプラスの情報も、その時期が過ぎると忘れてしまうものです。また特に不満や要求などネガティブな部分は表立って声にならないことも少なくありませんが、会社全体の成長・高度化、知識体系に貢献し、将来のプロジェクトをより良くするためにはそれらの「声」を収集することが必要です。そのためにPMはプロジェクト内で信頼関係を築くこと、つまり「発言しやすい、発言できる」雰囲気を作って、「さあ、どうぞあなたが感じたことを教えてください、もっと良くしていきましょう、よくなるはず！」という態度を示すことが重要です。例えばプロジェクト終了後のアンケートでそのような意見を収集する際などに「どのような意見であっても人事評価に影響しない、上長に記名で共有しない」などと付け加えるなども有効です。 (5) プロジェクト実行の監視とコントロール プロジェクトにおける監視とは、プロジェクトは順調か？計画通りに進んでいるか？を見る活動です。そのために活動進捗や途中結果の収集を行い、必要に応じて改善活動（予防・是正・欠陥修正）を適用していきます。 1）どのようにプロジェクトの状態を測定するか 一般的な手法として以下のような分析を行いますが、特に利用されるのが「アーンド・バリュー分析」です。今はさまざまなプロジェクト管理ツールで自動的に測定されることが多いですね。 データ分析方法例） アーンド・バリュー分析（EVM） 費用便益分析 根本原因分析 傾向分析、差異分析 プロジェクトは常に動いていますが、その動きをモニタリングし、目に見える形（データ）にすることで今の自分たちの状況と打つべき対策が明確になります。 EVM ：1960年代にアメリカで生まれたプロジェクト管理技法で、プロジェクトの計画予算と実際に発生した費用、およびそれまでに完了した作業量を対比し、コストとスケジュール実績が計画とどの程度の乖離があるのかを明確化。最終的な推定コスト・完了時期を予測する。現状から将来プロジェクトを予測する際に活用される手法です。 (！) ここではEVM作成方法や分析結果の見方（パターン）などは割愛しますが、馴染みのない方はぜひ調べてみてください。 (6) 統合変更管理の実行 変更が起こらないプロジェクトはありませんが、変更に伴う活動が適切でないとストレスや予期しない負担となります。知らないうちに追加要求をチームが受け取ってしまった、追加要求が捩じ込まれたが納期が遅れてしまう、どうしよう…といった苦い経験は想像に易いでしょう。統合変更管理の管理主眼は、それら必ず起こる変更の「ルールを決めて適切に管理すること」です。 1）その変更要求は受けるべきか、受けざるべきか？ 「XXをこう変えたい」と変更要求がなされたのには理由があるはずです。しかし、例えばその変更要求がプロジェクトスコープの範囲内か、そのプロジェクトフェーズ内で行うべきか（後続対応でよいのではないか）など評価することも同じように重要です。ある要求を受けつけるためには、別のタスクや物事に影響する場合がありますし、その影響によっては適切に「変更しない」という判断になる場合があることも忘れないでください。 また統合変更管理の活動ではそれらの変更ログを必ず文書化して、どのようにして変更要求が承認されたか、その全体的な影響、影響先を把握し、プロジェクト活動にスムーズに統合＝適応させていきましょう。 2）変更管理委員会とは？ 要求された変更（希望）内容によってはPMの権限で判断するものもあれば、プロジェクトスポンサー（オーナー）が判断するものなど様々です。事前に「XXの変更はPM承認、それ以外はPO、XXXレベルは変更管理委員会で決裁する」など事前に定義しておくとよいでしょう。変更管理委員会（CCB：Change Control Board）のメンバも事前にアサインしておきましょう。必要時に招集（MTG）し、プロジェクトからでた変更要求をレビュー、評価し、承認または却下します。 (7) プロジェクトクローズ 全てのプロジェクト作業が終了し、その活動を終えるために必要なマネジメントを指します。プロジェクトは成果物ができたら終わり、ではありません。最終的に必ずプロジェクト憲章に沿って「プロジェクトオーナーらからクローズ承認」を受けることができて初めてプロジェクトをクローズ（終結）することができます。 1）具体的なステップ プロジェクトオーナー等への活動報告 プロジェクトクローズMTG（振り返り会など） プロジェクト活動報告と終了報告書等の提出 プロジェクトナレッジの整理と保管 2）実施するクローズ活動と終結基準 プロジェクトクローズ活動をしっかりできるプロジェクトでありたいですね。形式的な活動も含まれますが、以下の活動を終結基準のチェック項目として意識しておきましょう。 全ての文書と成果物が最新状態であることを確認する 全ての課題が解決されていることを確認する（または適切に申し送り事項として管理されていることを確認する） 成果物の検修完了を確認する プロジェクトの会計を終えている（未払い等がない状態を指す） 人的資源（人員）を返却する（プロジェクトから定常業務へ配置転換する） プロジェクトで利用した各種資源の返却や再分配を行う プロジェクト報告など必要なドキュメントを作成し報告を完了する プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する ステークホルダーの満足度特定（アンケートやヒアリングの実施） さいごに プロジェクト統合マネジメントは、プロジェクトの土台となる整理（プロジェクト憲章）と計画（プロジェクトマネジメント計画書）、それらの実行（実行・知識の活用、監視コントロール）と変更調整（統合変更管理）を行いながら、その目的目標を達成してプロジェクトの役割を終える（プロジェクトクローズ）に至る、一連の大きな活動サイクルです。ボリュームがありますが、一連の流れと共にプロジェクトではこういう活動が必要なんだ、というポイントを先ずは掴んでいきましょう。 次回のテーマは「スコープマネジメント」です。明確な目標設定と共有方法のコツを学んでいきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？（連載初回全文公開中） 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス The post 【第4回】プロジェクトの統合マネジメント、7つのプロセス first appeared on Sqripts .

ご無沙汰しています。Yoです。 JSTQB FLの学習は順調でしょうか。 前回 に引き続き、今回もJSTQB FL対策として、私が学習中に躓いた箇所を解説しようと思います。今回は「レビュー」に関してとなります。私が個人的に最も苦手だった箇所ですので、同じく苦手意識を持っている方の手助けができれば幸いです。 前回の記事はこちら JSTQB FL対策 弱点強化解説　～1回目～ レビューとは？ まずは「レビューとは一体何か？」という所から説明していきます。とはいえ、レビューとは何であるかについては、 詳細な解説記事 がSqripts内にあるため、そちらに解説を任せるとして、ここでは簡潔に説明をします。 「レビュー」って何をするの― さまざまなソフトウェアレビューの種類・特徴を紹介 レビューは一般的に「批評」という意味であり、成果物の確認やチェックをするといった活動です。 JSTQBシラバスにおいては、主に3章「静的テスト」にて扱われています。 テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ここではレビューも一つのテストとして紹介されています。レビューがテストであるというのはいまいちピンと来ないかもしれませんが、静的テストというものに答えがありそうです。 静的テストに関しては以下のような記載があります。 静的テスト技法では、動的テスト技法（テスト対象のソフトウェアの実行が必要）と異なり、作業成果物を人手で調査（すなわち、レビュー）したり、コードや他の作業成果物をツール主導で評価（すなわち、静的解析）したりする。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 静的テストとはプログラムを動かさずにドキュメントやコードを確認するテストのこと、とのことです。確かにこう聞くとレビューも静的テストの特性と一致しています。 静的テストもテストの1つの技法であるので、その目的は欠陥を発見することにあります。つまりレビューをおおまかにまとめると、「成果物を確認し、欠陥を見つける」活動ということになります。 レビュー種類について レビューについて簡単な解説が済んだところで、この章では、レビューの種類について解説したいと思います。レビューには参加者や目的などで主に4種類に分けることができます。JITQBシラバスに記載の順序でそれぞれ説明します。こちらも詳細は過去の記事がありますので、簡潔に進めます。 非形式的レビュー 欠陥の検出を目的とし、形式的な方法に則らない方法です。他の呼び方として「バディチェック」、「ペアリング」、「ピアレビュー（ピア＝同僚）」と呼ばれるように、「知見のある同僚など」に「サッと見てもらう」という場合が非形式レビューになり、手順や成果物が厳密に決まっていないため、柔軟性があります。 例えば、隣の席の同僚などにサッと見てもらい、明らかな誤りなどがないかを確認してもらう。といったものも非形式的レビューになります。個人の印象ですが、簡単な修正のチェックや、もっと形式的なレビューの準備として行う事が多いです。 ウォークスルー 主に作成者が主導するレビューになります。レビュアーはチーム内のメンバーであることが主で、作成者が主体となり、他のメンバーがコメントや意見を述べる形式です。先に非形式という単語が出ましたが、これは手順や成果物が厳密に決まっていないという意味で、ウォークスルーは非形式なものもあれば形式的なものまで様々です。 開発やQAなどのチーム内で行うレビューというとウォークスルーの場合が多いかと思います。成果物の作成者が説明をしながら主導するため、チーム内の認識合わせといった側面もあります。また、非形式的レビューと同様に、より形式的なレビューの前段階として行われることもあります。 テクニカルレビュー 主に作成者以外が主導する形式的なレビューになります。レビュアーにも技術の専門家が参加する場合があるなど、非形式レビューやウォークスルーに比較してより専門的な視点から評価が行われるものとなります。 専門家が参加し、別の解決方法はないかなど、技術的な議論を行うことが目的となります。 ウォークスルーと比較し、専門家の関与といった点で、一般的に公式度合いがやや高いものになります。 インスペクション 形式的、という尺度で見ると最も形式的なレビューになります。スケジュール、開始と終了基準、参加者の役割といったものが決められており、作成者が他の役割を担わないなど、役割が役割やフローが厳密に定められています。更にレビューの成果をプロセス全体の改善に活用するなど、目的も成果物を精査する以上のものがあります。 指摘事項を修正し再度レビューをしたりすることもあります。イメージとしてはこれまでの3種よりもオフィシャルな場（チームの統括への報告、取引先とのレビューなど）で用いられることが主かと思います。 なぜ苦手なのか ここで少し脱線です。本シリーズは弱点強化と銘打っており、私が苦手だった箇所の解説を行っています。そこで、単に解説するだけでなくどうして苦手だったかを探ってみたいと思います。弱点を克服するヒントがあれば幸いです。 共通している内容が多い 基本的に技法の解説や、ブラックボックスかホワイトボックスかといった問題はそもそも被る内容があまりないため「それは何の説明か」という1対1の理解で事足りることが多いです。が、各レビュー手法の特徴に関しては共通する内容が非常に多く、1対1の理解では対応できないことが多いです。 例えば、レビューの目的「異なる実装方法の検討」はウォークスルーとテクニカルレビュー両方に共通する目的となるため、問題を解くにあたって「共通しているのでこの目的だけでは判断できない」ということも覚えていなければいけません。 これらの問題を解消するために、各レビューの特徴を素早く覚えられるようにまとめることが重要だと考えています。そのために以降の解説では、各レビューの特長を整理することに重点を置いて解説していきます。 問題を解く上でのポイント 上記のような分かりにくさを解消するために、いくつかポイントを絞って解説したいと思います。 目的の違いを覚える 共通の内容があるということは既に説明した通りですが、それを全て覚えるのではなく、そのレビューで固有のものを1つを覚えておくことで各レビューがどういったものか判別がつきやすくなります。 シラバスの各レビューの目的の内、固有のものは以下になります。 非形式的レビュー：影響度の小さい問題の迅速な解決 ウォークスルー：標準や仕様への準拠の評価 テクニカルレビュー：新しいアイデアの創出 インスペクション：ソフトウェア開発プロセスの改善 先ほど説明した各レビューの説明と絡めて考えると理解がしやすいかと思います。非形式レビューは「サッと見てもらう」レビューになるため、目的にもスピード感を意識したものが含まれるのが特徴です。 ここで厄介なことは、主にテクニカルレビューの「新しいアイデアの創出」についてです。ウォークスルーの目的で「さまざまな技法やスタイルに関するアイデアの交換」というものがあります。JSTQBの文言そのままであれば問題ないですが、選択肢の文章が独自のものになっていると上記二つの判別はほぼできなくなるため、目的だけでテクニカルレビューだと判断することはできなくなります。 参加者の違いを覚える 次に各レビューで特徴的なものは参加者の役割です。役割についてはシラバスでは作成者、マネージャー、ファシリテーター、レビューリーダー、レビューア、書記の6つが定義されています。それぞれのレビュー種類によってどのようになっているのか見てみましょう 非形式的レビュー：作成者と同僚によって実施 ウォークスルー：作成者が主導 テクニカルレビュー：経験を積んだファシリテーター（作成者ではない）が主導するのが理想 インスペクション：役割が明確に決まっている　※個々の詳細は割愛 それぞれ最も特徴的な部分を抜粋しています。上記のように大きく異なる点は、誰が主導するのかという点にあります。ウォークスルーとテクニカルレビューで主導する人物が変わっているという点が1つのポイントになります。 テクニカルレビューとインスペクションでは主導する人物は同じなため、その他の役割が明確かどうかという点で差が生まれます。 レビューの特徴のまとめ ここまででレビューの特徴の解説ですが、文字では把握がしにくい部分もあると思うので、以下にテーブルとしてまとめました。こうしてみると、形式度合いが上がるにつれて厳密になっているのが分かります。 レビューに参加するメリット いかがでしたでしょうか。レビュータイプの特徴について整理できたでしょうか。ここからは解説ではなく、レビューへの取り組みといった内容を解説したいと思います。 要件定義などのレビューにQAが参加することのメリットをいくつか紹介します。 第三者目線、ユーザー目線の提供 QAはユーザー目線でのテストを行うことも多いため、開発者とは異なる視点から成果物を評価することが多いです。そのため、レビューの傾向が開発者目線のリスクやアプローチに偏らないようにすることが可能です。 テストに対するリスクを早い段階で検知 更に、成果物に対してどのようにテストをするかという事を早い段階で考えることができるようになるため、テストデータの必要性であったり、ブラックボックステストでは確認が困難であるなどといったテストを行う上でのリスクを早い段階で検知できます。結果としてテストの成功にも貢献することができます。 レビューの成功要因 最後にレビューの成功要因について軽く説明させてください。シラバスにはレビューの成功要件として個別にまとめられています。それだけ重要な概念となります。ここで全てを紹介すると長くなってしまうため、最も重要と考えるものを紹介します。 シラバスには成功要因の一つとして以下のような記載があります。 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。 スキルや知識といった内容ではなく態度や心がけに近いものですが、そもそもどのような指摘やアドバイスであっても受け手が納得しなければ意味がありません。受け手が発言を受け入れられるように態度や説明には気を配る必要があります。 最後に これで今回のレビュータイプの解説を終了します。レビューが苦手と感じている方の助けになれたでしょうか。 ではまた次の記事でお会いしましょう。 The post JSTQB FL対策 弱点強化解説　～2回目～ first appeared on Sqripts .

「テスト自動化の習慣を最速で定着させるためには」と題しているこの連載ですが、今回で最終回となります。 第1回 ではテスト自動化を失敗させないための「毎日テストを回す」習慣を中心に、自動化を始める際のステップについてお伝えしました。そして 第2回 では運用可能な自動テストを作成するにあたって非常に重要な「独立性」の考え方と具体的な実装方法をご説明しました。 今回は、第2回の続きとして自動テストの作成・運用をより効率的に進めるための工夫をご紹介します。今度のキーワードは「共通化」です。日々コーディングをしている開発者の皆様にとっては重複する処理の共通化はごく当然のことですが、ノーコードツールを使ってテストを自動化するときにも同じ考え方が有効です。以下、共通化にまつわる3つの工夫をご説明します。前回まで同様、テストケースの具体例にはノーコードテストサービスのMagicPod( https://magicpod.com )を使用していますが、紹介している概念自体は特にサービス独自のものではありません。 ◆連載｜ テスト自動化の習慣を最速で定着させるためには 第1回：E2Eテストの自動化を最速で成功させる秘訣 第2回：毎日の自動テストを無理なく続けるためのキーワード 第3回：共通処理を活用してさらに効率的に自動化を進めよう 工夫1：データ駆動テスト 第1回でも触れましたが、自動テストを運用する際にむやみにテストケースを増やさないことは重要です。とはいえ、せっかく仕組みがあるのですから色々なパターンのテストを導入したいと思うのも自然なことですね。そこで、おすすめなのは少ないテストケースで大きなメリットを得られる「データ駆動テスト」の利用です。 データ駆動テストとは、テストの「手順」と「データ」を分離することで効率的にテストケースを実装する手法のことです。テストケースの中にはいくつかの変数を含めておき、その変数に入れる値（データ）を表のような形式で指定します。すると、指定したデータのパターンの数だけテストを繰り返し実行することができます。この方法を使えば、データ部分の定義を増やすだけで様々な条件のテストができますので手間のかかるテストケース部分の実装コストは非常に少なくて済みます。 データ駆動テストは非常にポピュラーな手法ですのでほとんどの自動テストツールに機能として組み込まれており、CSV等を使ってデータを定義できるようになっています。実際にMagicPodを使って試してみましょう。まず、テストケースの定義とデータの定義は以下のようになります。データは手入力もできますし、CSVファイルをアップロードすることもできます。 なお、今回のテストケースではテスト対象としてテスト自動化の学習用の練習サイトである HOTEL PLANISPHERE を利用させていただきました。ログイン情報は、サイト上で公開されているものです。 図 1　テストケースの定義 図 2　データの定義 実行した結果は、パターンごとに切り替えて確認することができます。 図 3　テスト結果の切り替え 上では説明のためにほとんど意味のない「様々なユーザIDとパスワードでログインするだけ」というテストケースを示しましたが、実際には ユーザの権限によって表示されるメニューや可能な操作が変わることを確認するテスト ECサイトなどで、購入する商品ごとにパターンを用意して購入までの操作を確認するテスト のような用途が多いかと思います。筆者のチームでは、MagicPodの利用プランに応じて表示が変わる部分のテストをデータ駆動テストで実装しています。 非常に便利でつい多用したくなるデータ駆動テストですが、注意すべき点もいくつかあります。 分岐を多用しすぎない データごとに結果が変わることをテストしたいわけですからテストケース側にはある程度の条件分岐が発生することも多いですが、あまりに分岐が多すぎるとテストケースが複雑になり、かえって何をしているのか分からなくなることもあります。結果が変わる部分についてもなるべくデータ側で表現できるように工夫し、どうしても分岐が多くなるようならテストケースを分割することも検討しましょう。（その際、次に説明する「処理の共通化」が有効になります） パターンを増やしすぎない  最初の説明とやや矛盾してしまいますが、データ駆動テストが便利なあまりになんでもかんでもE2Eテストのパターンを増やして対応しようとするのはあまり良くないパターンです。本当にシステム全体の疎通が必要なテストであれば良いのですが、可能であればE2Eテストは最低限にしてユニットテストやAPIテストで多くのパターンを網羅した方が実行時間を短くできます。 工夫2：処理の共通化 うまくはまるケースがあれば非常に強力なデータ駆動テストですが、基本的に同じ操作の繰り返しにしか使えないので様々な機能のテストを行いたい場合にはもちろん使えません。次はもう少し汎用的な方法として、テストケースの全部ではなく一部の処理を共通化して部品のように使うことを考えてみます。 共通化される処理として代表的なのはやはりログインのように頻繁に使われる処理です。それ以外にも、テストの前処理として必要なデータ作成の処理などがあれば共通化しておくと便利です。処理を共通化しておくと、新しいテストケースを作るときに作っておいた部品を呼び出すだけで良いので当然ケース作成の工数が削減できます。それ以外にも、ユーザから見て分かりやすい単位にまとめることで処理の流れを明確にするというメリットもあります。実際に、前節で使ったホテルの予約サイトのテストを通じて共通化前後のテストケースを見てみましょう。 一通りの情報を入力して予約を行うテストケースを普通に作ると、以下のようになります。 図 4　全く共通化されていないテストケース ここではデモ用のサイトで最低限の情報しか入れていないので10ステップで済んでいますが、実際のサービスをテストする際にはもっと項目が多くなるはずです。クリックやテキスト入力といった細かい粒度のステップが並んでいると、パッと見て何をしているテストなのかが分かりにくくなりがちです。 この手順を「情報の入力」と「確認・確定」に分け、さらに予約処理全体も共通化したものが次の図です。いかがでしょうか。階層化されたものをすべて展開しているので、一見するとかえって難しく見えるかもしれません。 図 5　意味のある単位で階層化されたテストケース 今度はいちばん下の階層を閉じてみました。すると、細かい処理は抽象化されてこのテストケースの概要が一目で分かるようになります。ここまで来れば、初見のメンバーがテストケースをメンテナンスすることになってもどの部分を編集すれば良いのかが分かりやすくなります。また、共通化されたステップには「宿泊数」「人数」といったパラメータが付いていることにも注目してください。このように処理の内容を変数化しておくことによって、同じ部品でも様々な値を入れて使い回すことができます。このあたりの考え方はデータ駆動テストに似ていますね。 図 6　抽象的な階層だけを表示 工夫3：画面要素の共通化 最後は、もっと小さい単位で処理ではなく操作対象の画面要素（ボタン、テキストボックスなど）を共通化するという工夫です。自動テストで画面要素を操作するときは、ロケーターやセレクターと呼ばれる記述を使って対象の要素を指定します。Webアプリケーションの場合は、HTML要素のタグの名前・ID・文字列などがロケーターの構成要素になります。たとえば、「メニュー」という文字列を含むボタンであれば「 //button[text()=’メニュー’] 」のような表現で指定できます。ロケーターの記法は色々ありますが、この例の記法は「XPath」というものです。 ここで画面要素の共通化と言っているのは、こういった要素に名前を付けておいて要素とロケーターを紐づけておく考え方のことで、Object Mapなどと呼ばれることもあります。こうやって説明してしまうと「なんだ、そんなこと当たり前じゃないか」と思われるかもしれませんが、自動テストの実装方法によっては「ステップAとステップBでは同じメニューボタンを操作している」と認識されるとは限りません。「ステップAで //button[text()=’メニュー’] をクリックする」「ステップBで //button[text()=’メニュー’] をクリックする」と、全く別個に認識されている場合もあります。 こうなっていると、もし画面の構造が変わってメニューボタンのXPathが変わった場合、呼び出しているすべての箇所のXPathを変更しなければなりませんし、そもそも呼び出している場所をすべて探すだけでも大変な作業になります。「メニューボタン」という1つの要素として認識しておけば、メニューボタンに対応するXPathを変えるだけで済むので修正が圧倒的に楽になります。ちなみにMagicPodではテスト対象の画面全体を保存しておいて使い回すことができるので、ごく自然な形で画面要素の共通化を行えます。 図 7　MagicPodにおける画面要素の共通化 共通化の本当のメリット ここまで、「テストケース全体」「よく使う処理」「画面要素」という3つの粒度での共通化を紹介してきました。最初に「自動テストの作成・運用をより効率的に進めるための工夫」とお伝えしましたが、効率的に進めるというのはテストの作成スピードが速くなるというだけのことではありません。私たちは日々変化していくソフトウェアをテストしているので、変化に応じて素早くメンテナンスを行えることは作成スピード以上に重要です。様々なレベルで共通化を行うことによって必要な変更点を最小限に抑えることで、テストケースの可読性が上がり、エキスパートでなくても容易にメンテナンスを続けることができます。 おわりに 本連載では、テスト自動化に初めてチャレンジする方をメインの対象としてテスト自動化の進め方・効率的な実装・運用方法をお伝えしてきました。本来もっと短期間で終わらせるべきところ、筆者都合で非常に期間が長くなってしまったことをお詫びいたします。 ここでお伝えしてきたことは自動化をかじったことのある方にとっては当然と思われることばかりで、物足りないと感じられた方も多いかもしれません。自動テスト関連の技術は日々進化しています。筆者がE2Eテストの自動化を仕事として始めたのは10年ほど前ですが、その頃はSelenium 2 (WebDriver)が登場していよいよWebアプリケーションのE2EテストがOSSで手軽に実践できる！と盛り上がっている時代でした。その後モバイルアプリケーションの自動テストフレームワークも充実し、さらにAIを搭載した自動テストSaaSがいくつも出てきて自動化の敷居はどんどん下がってきました。 ただ、どんなツールやサービスを使っていても、コーディングをしてもノーコードでも、最初に理解しておくべき基本的なポイントや躓きやすい点はあまり変わっていません。筆者は以前にも初めて自動化に触れるお客様へレクチャーをする仕事に従事しており、最先端の技術を追いかけるよりも自動化の敷居を下げてたくさんの方に触れていただくことの方に喜びを感じています。本連載が皆様のテスト自動化のはじめの一歩に少しでもお役に立ちましたら幸いです。 連載一覧 第1回：E2Eテストの自動化を最速で成功させる秘訣 第2回：毎日の自動テストを無理なく続けるためのキーワード 第3回：共通処理を活用してさらに効率的に自動化を進めよう The post 第3回：共通処理を活用してさらに効率的に自動化を進めよう first appeared on Sqripts .

はじめまして、QAコンサルタントのアイネイドです。 私はソフトウェア開発と開発プロセスに関する仕事を何十年もしてきました。昨年ソフトウェア品質保証に興味を持ち転職したのですが、その過程で初めて「JSTQB」というソフトウェアテストの資格があることを知りました。 今回のブログでは「JSTQB Foundation Level」の問題を解かせてみる実験を行ってみました。ChatGPTがどれだけ正確に問題を解けるか、興味深い結果が待っていますので最後までお付き合いいただければ幸いです。 1. ChatGPTに試験を受けさせようと思った理由 近年、米Chicago-Kent College of Lawに所属する研究者らは「ChatGPT-3.5」で米国司法試験(選択式)の7科目を受けさせたところ、平均正答率50%(人間の平均正答率68%)となったとのことです。このニュースを見たクオリティマネージャーの私は、同じ選択式問題である「JSTQB Foundation Level」を解くことができるのかということに興味が沸きました。 仮に合格ラインに達する事になれば、資格保持者と同等の知識レベルということになり、より仕事に活かすことができるのではないかと期待したことがChatGPTに試験を受けさせようと思った理由になります。 2. JSTQBについて JSTQBとは何か？ JSTQBについてご存じない読者もいらっしゃると思いますので、簡単に説明をします。 JSTQBは日本におけるソフトウェアテスト技術者資格認定の運営組織として2005年4月に認定されました。各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織の加盟組織の一つになります。 「JSTQB Foundation Level」の問題について 認定試験にはいくつか種類がありますが、初回ということでまず一番基礎的な「JSTQB Foundation Level」の問題に焦点を当てています。 使用する問題は公式サイト( JSTQB認定テスト技術者資格 )で公開している サンプル問題 で、問題形式は選択肢4つの選択式問題です。 なお、サンプル問題の問題の正解は選択肢Aとなっていることを覚えておいてください。 3. ChatGPTにJSTQBの問題を解かせてみた ChatGPTに問題と選択肢を読み込ませ、正解・正解の理由・他選択肢の不正解の理由を出力するように設定し、出力された内容が以下になります。 問題1 テストや操作で見かけるインシデントの一覧がある。「故障」といえるのはどれか。次の選択肢の中から１つ選びなさい。 - A. ダイアログボックスのオプションを選択した時、製品が異常終了した。 - B. 間違ったバージョンのソースコードをビルドした。 - C. 間違った入力変数を使用した計算アルゴリズムを使用した。 - D. 開発者は計算に関する要件のアルゴリズムを誤った解釈をした。 正解：A 正解の理由 ：製品が異常終了することは、明らかな故障です。他の選択肢は欠陥やエラーを指摘していますが、故障とは異なります。 不正解の理由 ： – B、C、Dは欠陥やエラーを指摘していますが、故障とは異なります。 問題2 次の説明においてテストとデバッグの違いを最も適切に説明しているのはどれか。次の選択肢の中から１つ選びなさい。 - A. テストは欠陥から発生する故障を発見する。デバッグはソフトウェアの故障の原因を発見し、解析し、除去を行う。 - B. テストは欠陥を正確に指摘する。デバッグは欠陥を解析して、事前に除去できるように提案する。 - C. テストは欠陥を除去する。デバッグは故障の原因を特定する。 - D. 動的テストは故障の原因を防ぐ。デバッグは故障を除去する。 正解：A 正解の理由 ：テストはシステムやソフトウェアの欠陥やエラーを発見するプロセスであり、テストを通じて故障が明らかになります。一方、デバッグは発見された故障の原因を特定し、解析し、除去するプロセスです。 不正解の理由 ： – Bはテストが欠陥を正確に指摘することを説明していますが、デバッグの特徴ではありません。 – Cはテストが欠陥を除去することを説明していますが、デバッグの特徴ではありません。 – Dは動的テストとデバッグの関係について説明しており、問題文とは異なります。 問題3 ツールによる静的解析の主な利点の説明文として最も適切なものはどれか。次の選択肢の中から１つ選びなさい。 - A. ツールによる静的解析は、手動によるテスト実行の前に欠陥を検出することができる。 - B. ツールによる静的解析は、ビジネスアナリストや要求エンジニアが要件と一致しないソフトウェアのモデル（状態遷移図など）を構築することを防ぐ。 - C. ツールによる静的解析により、ユーザ受け入れテストのテストケースが少なくなり、テスト実行の期間が短くなる。 - D. ツールを使ってコードの静的解析を行うことで、開発者によるユニットテスト実施のニーズは減少する。 正解：A 正解の理由 ：ツールによる静的解析は、コードやドキュメントなどのテキストを自動的に解析し、欠陥や問題を発見することができます。これにより、手動テストの前に問題を早期に検出できます。 不正解の理由： – Bは静的解析が要件と一致しないモデルを防ぐと説明していますが、主な利点ではありません。 – Cはユーザ受け入れテストのテストケースに関する話であり、主な利点ではありません。 – Dは開発者によるユニットテストのニーズに関する話であり、主な利点ではありません。 問題4 客のクレジット信用枠を決定する銀行のアプリケーションがある。このアプリケーションのテストに最も適したブラックボックステスト設計技法を、次の選択肢の中から１つ選びなさい。 - A. デシジョンテーブルテスト - B. 状態遷移テスト - C. ユースケーステスト - D. 同値分割法 正解：A 正解の理由 ：クレジット信用枠を決定するアプリケーションは、異なる条件やルールに基づいて判断を行います。デシジョンテーブルテストは、異なる条件に対するテストケースを効果的に設計するための適切な方法です。 不正解の理由 ： – Bの状態遷移テストは、状態遷移が重要な場合に使用されますが、信用枠決定アプリケーションには必ずしも適しているわけではありません。 – Cのユースケーステストは、システムの機能やユーザの操作に基づいてテストケースを設計する方法であり、信用枠決定アプリケーションには特に適していません。 – Dの同値分割法は、入力値の範囲を区切り、各範囲の代表的な値をテストする方法ですが、信用枠決定アプリケーションにはデシジョンテーブルテストの方が適しています。 問題5 テスト実行ツールの特徴に関する以下の記述のうち、キーワード駆動テスト実行ツールの特徴にもっとも当てはまるものはどれか。次の選択肢の中から１つ選びなさい。 - A. テスト入力データ、アクションワードや期待結果を含む表が、テスト対象システムの実行を制御する。 - B. テスト担当者の動作が、何度も繰り返すことができるようにスクリプトに記録される。 - C. テスト担当者の動作が、様々なテスト入力データによって実行できる。 - D. テスト結果を記録し、期待結果と比較することができる。 正解：A 正解の理由：キーワード駆動テスト実行ツールは、テストスクリプト内にキーワードやアクションワードを使用してテストケースを設計し、テスト対象システムの実行を制御します。この方法により、テストの再利用性が向上し、テストケースのメンテナンスが容易になります。 不正解の理由： – Bはテストの録画再生ツールの特徴を説明しており、キーワード駆動テスト実行ツールの特徴ではありません。 – Cはテストデータのバリエーションに関する話であり、キーワード駆動テスト実行ツールの特徴ではありません。 – Dはテスト結果の記録と比較に関する話であり、キーワード駆動テスト実行ツールの特徴ではありません。 4. 問題の正答率とChatGPTの能力 驚くべきことに「JSTQB Foundation Level」の問題に対して、ChatGPTは5問すべての問題に対して正解しました。これにより正答率は100％となり、下手をするとChatGPTは「JSTQB Foundation Level」資格保持者より正確な回答ができたのかもしれません。 ※ChatGPTが出力した正解の理由・不正解の理由には一定の信頼性があるとは思いますが正確であるとは断言できないため、サンプル問題に記載された正解の理由・不正解の理由を参照してください。 この結果より、ChatGPTはソフトウェアテストに関わる簡単な文章であれば、推敲や校閲においても力を発揮できるのではとさえ思わせる能力を持っている可能性があるのではないでしょうか。 5. 考察 前章でChatGPTの能力をベタ褒めさせていただきましたが、実は解かせる問題を選択する際に手心を加えています。 例えば問題の一部として「フロー図」がある問題は意識して除いています。図をテキストで表すことができないのかといわれるとある程度可能ですが、人間がやることになるので今回の実験からでは不確定要素と判断しました。 データだけの表であれば、下記のようにカンマ区切りにすることでテキストとして入力できますが、文字の強調やセルの色合いにも意味がある場合はテキスト化が難しい場合があります。 商品名,値段,割引額,売り場 みかん,100円,10%,生鮮食品売り場 シャンプー,300円,5%,日用品売り場 サンダル,1000円,8%,服売り場 ちなみに今回省いたフロー図の問題は以下になりますが、テキスト部分だけを入力すると、毎回のように正解とする選択肢が変わってしまいます。 プロジェクトにおけるカバレッジ目標の一つに、100%デシジョンカバレッジがある。 次の制御フローグラフに示す３つのテストを実行する。  テストA：A,B,D,F,Gのパスをカバーする  テストB：A,C,F,Gのパスをカバーする  テストC：A,C,F,C,F,C,F,Gをカバーする 次のデシジョンカバレッジ目標に関する記述のうち、説明文として最も適切なものはどれか。 次の選択肢の中から１つ選びなさい。  A. 判定（デシジョン／以下、判定）Dは完全にテストされていない。  B. 100%デシジョンカバレッジを達成する。  C. 判定Eは完全にテストされていない。   D. 判定Fは完全にテストされていない。 なお、このテキスト化の方法が正しいかどうかは不明ですが「制御フローグラフ」の図を下記のようなテキストに置き換えると正答するようになります。 制御フローグラフ A→B,Cに分岐 B→Dに遷移 C→Fに遷移 D→E,Fに分岐 E→Gに遷移 F→C,Gに遷移 また、図や表を人間の手でテキスト化した場合以外にも、回答が違ってくることがあります。(不正解の頻度は数回に一度や数十回に一度の場合もあります) このような現象になる原因の一つに「日本語の曖昧さ」があります。 日本語は主語が省略されていたり、どの単語を修飾しているか判断しづらいことがあります。ただ、今回のJSTQBのサンプル問題には英語の物もあるので、それを使用することで正答率が上がる場合もあると思います。 実は今回の結果に驚いたのは日本語の問題であるのに関わらず正解率100%だったことも原因の一つでした。 まだまだChatGPT使う側の人間が気を使わないといけないことは多そうです。 6. まとめ ChatGPTのようなOpenAIは今この時も進化を続けており、今回省いた「フロー図」の認識についても、「フロー図」を画像のまま認識するようなプラグインがあれば、今回のような手心は必要なくなる可能性もあり回答の精度もまだまだ上がっていくことでしょう。 筆者としてはそんな(おそらく近い)未来が少し楽しみです。 機会があれば次は更に上のランクの試験に挑戦させてみたり、バージョンアップしたOpenAIにさせてみたりしてみようかと考えております。 本ブログを最後まで読んでいただいてありがとうございました。 The post ChatGPTにJSTQBの問題を解かせてみた first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 第3回は、基本の論理演算・否定(NOT)、論理積(AND)、論理和(OR)の意味と働きを見ていきます。 各論理演算は、名前だけ見るとものすごそうに見えるかも知れませんが、ひとつひとつはそう難しい演算ではありません。まず、それぞれが「どういうことを言っているのか」を把握しましょう。日常でも同じような考え方をしている時がある筈です。 文中で「条件や主張」という表現を使っていますが、それはこれらの論理演算が文や文章のレベルでも使われるからです（第5回に記載予定）。 ＜論理スキル［再］入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ [第2回] プログラムレベルのロジック (1)概要編 否定(NOT) 否定(NOT)とは 否定(NOT)は次のような演算です。 条件や主張の 真理値を反転 する 単項演算 (演算対象がひとつの演算)  否定の演算式を、本記事では NOT(A) と表す 条件や主張Aが真ならNOT(A)は偽になり、Aが偽ならNOT(A)は真になる 日本語では、「A ではない 」、「Aである ということはない 」という語句が相当する 否定の真理値表を図3-1に示します。 真理値表(真理表、真偽表とも) とは、演算対象の真理値と演算結果の真理値をまとめた表で、”T”は真(true)、”F”は偽(false)の意味です。以下の通りであることを確認してください。 Aが真の時、NOT(A)は偽になる Aが偽の時、NOT(A)は真になる 図3-1 論理否定の真理値表 二重否定 二重否定(否定の否定)は、もとの真理値と同じ値になります（もとの真理値に戻る）。（図3-2） Aが真の時、NOT(NOT(A))は真 Aが偽の時、NOT(NOT(A))は偽 図3-2 二重否定の真理値表 否定の留意点 否定そのものではありませんが、数値の範囲を表す表現の否定は、以下のようになります。（図3-3） 「以上」の否定は、“以上で(は)ない”＝“より小さい”＝「未満」 「xが10以上(x >= 10)」という条件式の否定は「x < 10」 「以下」の否定は、“以下で(は)ない”＝“より大きい”＝「超」  「yが50以下(y <= 50)」という条件式の否定は「y > 50」 上記の逆で、未満の否定は「以上」、超の否定は「以下」。   「超」という語はあまり日常会話的ではないが、ソフトウェアではよく使われる 日常で使う場合は、この辺りの大小・含む含まないの関係を“曖昧に”表し/解釈することがままあります。（第5回に記載予定） 日常で使う時の「否定」の、論理の言葉としての意味合いとの違いも、第5回で取り上げます 図3-3 以上/以下の否定は、未満/超 論理積(AND) 論理積(AND)とは 論理積(AND)は次のような演算です。 条件や主張A, Bがともに真である時に結果が真、そうでない場合には結果が偽になる 二項演算 (演算対象がふたつの演算) 論理積の演算式を、本記事では A AND B と表す 「ふたつの条件が同時に成り立つ(必要がある)場合」「ふたつの条件がともに必要である場合」などを表すのに用いる 日本語では、「 および 」「 かつ 」「 ならびに 」「 そして 」などの接続語が相当する  「そして」は時間的順序を表す意味もあるので注意が必要です 論理積の真理値表を図3-4に示します。 表の1行目が「A, Bがともに真の時」 2～4行目が「そうでない(A, Bがともに真、ではない)場合」 “A, Bどちらかが偽”である場合を含む 図3-4 論理積の真理値表 演算対象が三つ以上の場合 論理積は二項演算ですが、演算対象が三個以上になっても同じように考えることができます。（三条件の論理積の真理値表は図3-5参照） 演算対象が すべて真の時、結果が真 そうでない場合(＝どれかひとつ以上が偽の場合)、結果は偽 図3-5 論理積(三条件)の真理値表 論理和(OR) 論理和(OR)とは 論理和(OR)は次のような演算です。 条件や主張A, Bのどちらかが真である時に結果が真、そうでない場合には結果が偽になる 二項演算 論理和の演算式を、本記事では A OR B と表す 「ふたつの条件のどちらかが成り立つ(必要がある)場合」「ふたつの条件のうちどちらかが必要である場合」などを表すのに用いる（「どちらかが成り立てばよい」と理解しても差し支えないことも多い） 日本語では「 または 」「 あるいは 」「 ないし 」などの接続語が相当する 「ないし」は数量の範囲を表す意味もあるので注意が必要です（第5回に記載予定） 論理和の真理値表を図3-6に示します。 表の1～3行目が「A, Bのどちらかが真である時」 “A, Bがともに真”である場合を含む 4行目が「そうでない(A, Bのどちらかが真、ではない)場合」 図3-6 論理和の真理値表 演算対象が三つ以上の場合 論理和は二項演算ですが、演算対象が三個以上になっても同じように考えることができます。（三条件の論理和の真理値表は図3-7参照） 演算対象が どれがひとつ以上が真の時、結果が真 そうでない場合(＝すべてが偽の場合)、結果は偽 図3-7 論理和(三条件)の真理値表 論理演算で表す例 第1回で出てきた「登録できるユーザーアカウント名」の例を見てみましょう。 登録できるユーザーアカウント名には以下の条件があります。 (a) アカウント名に使える文字は以下のいずれかに限ること 半角英大文字(A～Z), 半角英小文字(a～z), 半角数字(0～9) (b) アカウント名は16文字以下であること (c) 既に登録済みのアカウント名は登録できない a, b, cの条件をすべて満たしているときに登録できる(3条件の論理積)、と解釈すると（条件aはいったん「使用可能な文字だけで構成されている」と置き換えます）、 使用可能な文字だけで構成されている AND 16文字以下である AND NOT(既に登録済み) といった形に表せます。 条件a「使用可能な文字だけで構成されている」を展開すると 半角英大文字である OR 半角英小文字である OR 半角数字である となります。 条件bを「16文字を越えていないこと」と読んで、否定を使って NOT(16文字を超えている) と表すこともできます。 むすび 例が既にそうなっていますが、これらの論理演算は組合せて使うことが多いです。 第4回では、この「論理演算の組み合わせ」の扱い方や、憶えておきたいことを見ていきます。 参考文献 『プログラミング言語C　第2版』(カーニハン, リッチー / 共立出版) 『プログラミング言語AWK』(エイホ, ワインバーガー, カーニハン / USP研究所) JavaScript リファレンス (Webページ) https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference 否定は「単項演算子」のカテゴリーで「論理否定」として、論理積と論理和は「バイナリー論理演算子」というカテゴリーで取り上げられている。（この「バイナリー」は二項演算の意か） Python 言語リファレンス (Webページ) https://docs.python.org/ja/3/reference/index.html 「6.11. ブール演算 (boolean operation)」で取り上げられている。 『スマリヤン先生のブール代数入門』(スマリヤン / 共立出版) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) 『入門！論理学』(野矢茂樹 / 中央公論新社) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 The post [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 first appeared on Sqripts .

はじめまして。四十路にしてブログデビューのおつばです。 よろしくお願いします。 日々のちょっとした作業。いつも通りに手作業で対応してもそこまで時間はかからない。だけどこのちょっとが面倒に感じていること。ちょっとだから後回しにして結局遅れたり忘れたりしてしまうこと。皆さんもありませんか？ありますよね？・・あるってことで進めていいですね？笑 そんなちょっとした作業を自動化することで煩わしさから解放されて、対応遅れや忘れのヒューマンエラー要因のミスも軽減する。そんなことを目的として取り組んでいるプチ効率化の中から、今回は「定型メールをGoogleForm上での選択操作から自動作成＆送信する方法」をご紹介します。 前提 業務で使用するPCには特別なツール類をインストールできない事が多いかと思います。そこで、Googleアカウントがあれば実現できるGAS（GoogleAppsScript）を使用した定型メール自動作成を、当日勤怠連絡メールをサンプルとしてご紹介していきます。 流れとしては以下のような順で進めていきます。 ・必要なものを準備 　　→Googleアカウントを用意 　　→入力用となるGoogleFormを作成 　　→GoogleFormの回答を出力するスプレッドシートを作成 　　→スプレッドシートにメール定型文のベースを追加 ・GASっていく 　　→ソースコードをコピペして編集 　　→処理実行のトリガーを設定 　　→実行してみよう 「GASって何？」の説明は本記事では割愛させてください。GASをテーマにした他の記事でもご紹介していますので、是非ご覧いただければと思います。 ■ GoogleAppsScriptを使ってテスト項目書の体裁を一発で整える </Sqripts> ■ 業務改善にはコレ！＼Google Apps Script／ </Sqripts> 必要なものを準備 GASのコードを書く前に、まずは必要なものを準備をしていきます。 ＜用意するもの＞ Googleアカウント （Google先生ありがとう） Chromeブラウザ （Google先生ありがとう） 少しのやる気 （何気に一番大事） ＜作成しておくもの＞ ① GoogleForm （メール自動作成＆送信の操作用） ② メール定型文 （自動作成する定型メールのベース） 作成しておくもの ①GoogleForm まずは操作用のGoogleFormの作成です。 勤怠連絡メールとなると、状況に応じて連絡内容や宛先が変わってきますので、以下の回答項目があるGoogleFormを作成します。 ＜回答項目＞ 連絡先　：連絡先メールアドレス　を追加 休暇区分：全休、午前半休、午後半休　の選択肢を追加 休暇事由：私用 / 体調不良 / 急用　の選択肢を追加 今回はGASをスプレッドシートに仕込みますので、Formの「回答の送信先を選択」の設定から、スプレッドシートに回答が記録される設定にしておきます。 作成しておくもの ②メール定型文 ①の最後に用意した回答記録用のスプレッドシートを開いて、ベースとなるメール定型文を記載したシートを追加します。「メール定型文」の名前でシートを追加し、A1セルにメール本文の文章を入力してください。 メール文面中の名前、日付、休暇区分、休暇事由が入る箇所は、GoogleFormで選択した項目をGASの処理で自動的に置換して本文に反映させるため、置換処理用キーワードを入れておきます。 ＜置換処理用キーワード＞ 名前：★NAME★ 本日：★DATE★ 休暇事由：★CAUSE★ 休暇区分：★CLASSIFICATION★ GASっていく いよいよGASっていきましょう。先ほど用意した回答記録用のスプレッドシートにて「拡張機能」-「Apps Script」を選択してスクリプトエディタを開き、次のソースコードをまずはコピペしてください。 ソースコード全体 function Send_AttendanceMail(){ //定数 const SUBJECT_HEAD = '【勤怠連絡】'; const NAME = 'おつば'; const MY_ADDRESS = 'o-tsuba@agest.co.jp'; const MAILBODY_SHEETNAME = 'メール定型文'; const MAILBODY_REPLACE_NAME = '★NAME★'; const MAILBODY_REPLACE_DATE = '★DATE★'; const MAILBODY_REPLACE_CAUSE = '★CAUSE★'; const MAILBODY_REPLACE_CLASSIFICATION = '★CLASSIFICATION★'; //対象シートを取得 let DataSheet = SpreadsheetApp.getActiveSheet(); //基準セルを取得（最終行、先頭列） let BaseCell = DataSheet.getRange(DataSheet.getLastRow(), 1); //連絡先 let MailTo = BaseCell.offset(0, 1).getValue(); //休暇区分 let Classification = BaseCell.offset(0, 2).getValue(); //休暇事由 let Cause = BaseCell.offset(0, 3).getValue(); //MailCc let MailCc = MY_ADDRESS; let mailArgs = {cc:MailCc}; //件名 let Today = Utilities.formatDate(new Date(), "JST", "MM/dd"); let MailSubject = SUBJECT_HEAD + ' ' + NAME + ' ' + Today + ' ' + Classification; //対象シート（メール定型文シート）設定 let MailBodySheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(MAILBODY_SHEETNAME); //本文 let MailBody = MailBodySheet.getRange(1, 1).getValue(); //メール本文内の文字列置換 if(MailBody.match(MAILBODY_REPLACE_NAME)){ MailBody = MailBody.replace(MAILBODY_REPLACE_NAME, NAME); } if(MailBody.match(MAILBODY_REPLACE_DATE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_DATE, Today); } if(MailBody.match(MAILBODY_REPLACE_CAUSE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CAUSE, Cause); } if(MailBody.match(MAILBODY_REPLACE_CLASSIFICATION)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CLASSIFICATION, Classification); } //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); } 部分的に解説 定数の宣言部分 //定数 const SUBJECT_HEAD = '【勤怠連絡】'; const NAME = 'おつば'; const MY_ADDRESS = 'o-tsuba@agest.co.jp'; const MAILBODY_SHEETNAME = 'メール定型文'; const MAILBODY_REPLACE_NAME = '★NAME★'; const MAILBODY_REPLACE_DATE = '★DATE★'; const MAILBODY_REPLACE_CAUSE = '★CAUSE★'; const MAILBODY_REPLACE_CLASSIFICATION = '★CLASSIFICATION★'; ソースコードの先頭で定数を宣言しています。この定数のうち、上から3つは値を変更してください。 ・SUBJECT_HEAD： メール件名の先頭に付ける文字列です。連絡ルールに合わせて変更してください。 ・NAME： メール件名や本文に入る名前です。ご自身の名前に変更してください。 ・MY_ADDRESS： メールアドレスです。ご自身のメールアドレスに変更してください。 （※サンプルですので、記載のアドレスは存在しません。） 上記以外の定数は、先ほどの「作成しておくもの②」で整えた内容に合わせていますので、特に変更する必要はありません。 以降のコードは変更せずともコピペのままで動作しますが、処理の内容を順番に説明していきます。 スプレッドシートからの取得部分 //対象シートを取得 let DataSheet = SpreadsheetApp.getActiveSheet(); //基準セルを取得（最終行、先頭列） let BaseCell = DataSheet.getRange(DataSheet.getLastRow(), 1); //連絡先 let MailTo = BaseCell.offset(0, 1).getValue(); //休暇区分 let Classification = BaseCell.offset(0, 2).getValue(); //休暇事由 let Cause = BaseCell.offset(0, 3).getValue(); //MailCc let MailCc = MY_ADDRESS; let mailArgs = {cc:MailCc}; Form回答が記入されたシートを対象として取得します。 そのシートから最終行、先頭列（つまり直近の回答が入っている列の先頭）を基準にするセルとして取得して変数に代入します。その基準セルから1列ずつ右にズレながら、連絡先，休暇区分，休暇事由，のForm回答内容をそれぞれ取得して変数に代入していきます。 最後に、自身のメールアドレスをCcの宛先として変数に代入します。 件名と本文 //件名 let Today = Utilities.formatDate(new Date(), "JST", "MM/dd"); let MailSubject = SUBJECT_HEAD + ' ' + NAME + ' ' + Today + ' ' + Classification; //対象シート（メール定型文シート）設定 let MailBodySheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(MAILBODY_SHEETNAME); //本文 let MailBody = MailBodySheet.getRange(1, 1).getValue(); 当日の月日を取得して変数に代入し、先頭に付ける文字（定数）＋名前（定数）＋日付（当日）＋休暇区分（シートから取得）の件名を作ります。それぞれの間にスペースを入れるため、定数や変数の間に「 + ‘ ‘ + 」を入れて繋いでいます。 本文は、「メール定型文」シートに用意したセルの値をまずはそのまま取得します。 本文内の対象文字を置換 //メール本文内の文字列置換 if(MailBody.match(MAILBODY_REPLACE_NAME)){ MailBody = MailBody.replace(MAILBODY_REPLACE_NAME, NAME); } if(MailBody.match(MAILBODY_REPLACE_DATE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_DATE, Today); } if(MailBody.match(MAILBODY_REPLACE_CAUSE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CAUSE, Cause); } if(MailBody.match(MAILBODY_REPLACE_CLASSIFICATION)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CLASSIFICATION, Classification); } 先ほど取得した定型文メール本文の中には「作成しておくもの②」で用意したように、まだ置換処理用のキーワードが入った状態ですので、対象の文字を置換します。この処理を行うことで、GoogleFormで選択した各項目の値、名前、日付がメール本文に反映されます。 メール送信 //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); ここまでで「Toの宛先」「件名」「本文」「Ccの宛先」が揃いましたので、あとはメールを送信するためのsendEmail関数にそれぞれの値を引数として指定します。 これでGASのソースコードが完成です！ トリガーを設定 ソースコードが整ったら、あとはこの処理を実行するタイミングを指定するために、スクリプトエディタにてトリガーを設定します。今回はGoogleFormを使用しているので、Formで送信を押したタイミングで動作させます。トリガーに以下を設定してください。 実行する関数を選択：先ほど書いたコードの関数「Send_AttendanceMail」を設定 イベントの種類を選択：「フォーム送信時」を設定 それ以外はデフォルトのままでOK 実行してみよう ソースコードと設定が整ったら、GoogleFormから送信をしてみましょう。Form上の選択通りの宛先と内容で定型メールが自動送信されることが確認できると思います。 スマホでGoogleForm回答用URLを開くショートカットを用意しておくと便利です。 ショートカットを選択→開いたGoogleFormで各項目を選択＆送信、の数回ポチポチっとするだけで勤怠連絡メールが送信できます。メールアプリを開いて手動で文章入力を行うよりも早いことが実感できるかと思います！ Slackにも投げてみる と、ここまで書き上げたところで、「Slackチャンネルにも投稿できると便利だと思うんだよなぁ。」そんな天のお告げを受けたので、参考情報として以下2つの方法を簡単にご紹介します。 Slackに投稿する方法 ＜方法Ａ＞ Slackにメール送信するための機能がいくつか用意されています。一部Slack有料プラン用の機能もありますが、こちらを活用することでメール送信からのSlack投稿を実現できます。 [Slackヘルプセンター] Slackにメール送信する ＜方法Ｂ＞ Slackのアプリケーションを追加して「IncomingWebhooks」を設定、HTTPリクエストを送るGASソースコードを書く、ことでメール送信と合わせてSlack投稿を実現できます。 ①Slack上の設定： 　Slackの対象ページを開いてアプリケーションを追加、設定する。 https://api.slack.com/appsを開く 「Create New Apps」からアプリ作成 作成したアプリのIncomingWebhooksを On に設定 投稿したいチャンネルを設定追加して専用のURLを生成 ②GASソースコード： 　「Post_Slack」関数を作成してメール用に用意した件名と本文をSlack投稿する。 メール送信の下にソースコードを追加する（件名と本文を引数で渡す） //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); //　★ ↓ コレ ↓ ★ Post_Slack(MailSubject + '\n' + MailBody); //「\n」で改行 } 「Post_Slack」関数を追加する 　　件名、本文のデータを処理用のパラメータに整える 　　SlackUrlFetchAppクラスのfetchメソッドを使ってHTTPリクエストを送る 　　「’★ココはSlack設定で生成したURL★’」の箇所は①で生成したURLに置き換える function Post_Slack(PostText) { //WebhookのURL let SlackWebhooksUrl = '★ココはSlack設定で生成したURL★'; //引数で受け取った投稿用メッセージを代入 let Payload = { 'text': PostText }; //Slack投稿のメソッドに渡すパラメータを作成 let Parameters = { 'method': 'post', 'payload': JSON.stringify(Payload) }; //Slack投稿 UrlFetchApp.fetch(SlackWebhooksUrl, Parameters); } おわりに いかがでしたでしょうか。 スクリプトのソースコードを書くとなると、あまり経験が無いとちょっとハードルが高く感じがちですが、今回見ていただいたサンプルはソースコード量としては多くはないですし、順を追って見ていくとそこまで複雑な処理も無かったのではないかなと思います。 今回は簡単な当日勤怠連絡メールとSlack投稿をサンプルとして紹介しましたが、自分の作業に当てはめると「もっとこうしたい」「この定型メールも対応できるようにしたい」など、やりたいことが思い浮かぶかと思います。想像したことを形にできてそれが成果として表れると、より一層のやる気にも繋がります。 この記事でGASに興味を持っていただけたら、作業効率化のネタとしてお役に立てれば、幸いです。 またGASネタ、効率化ネタをご紹介できればと思っています。 最後までご覧いただきありがとうございました。 The post それ、GASっちゃえば？　－定型メールはGoogleForm操作で送信－ first appeared on Sqripts .

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 .