2023年9月26日に帝国ホテルで開催された「Stuart Reid博士来日イベント　特別セミナー／知識ゼロから学ぶAIテスト」に参加してきました。 完璧ではないAIを”どうテストするか？” “AIをどう使うか？”に注目が集まっていますが、完璧ではないAIを”どうテストするか？“についてはほとんど議論がされていません。 AIプロダクトのテストについて、AIテストの第一人者であるStuart Reid博士と西康晴先生をお招きして特別セミナーを開催します。 セミナー概要 今から1年ほど前、2022年の秋までは、生成AIなどで話題になるものはあっても、認知度もそれほど高くなく、現在ほど普及はしていませんでした。 ところが2022年11月、 OpenAI が ChatGPT を発表すると、またたく間に注目を集め、IT業界だけでなく、いわゆる世間一般、教育業界、子供たちにまで認知されるようになりました。 AIは今まさに、急速な拡大期を迎えているといえます。 このAIというもの、「すごい！」と感嘆の声を挙げたくなることも多いのですが、反面、「完璧でない」と感じることが多いのもまた事実です。 ChatGPTを使ったことのある方なら経験があるかもしれませんが、しれっと「間違った答えをさも真実のように」伝えることがあります。 ここが、” AIが完璧ではない “ところです。 完璧ではないAIですが、せっかくの便利なモノなので利用しない手はありません。しかし、利用してみたところでやっぱり完璧でないので「AIの品質」が課題になる。 どのように利用していくのか、はたして利用していけるのか…。 そんなことに頭を悩ませる品質界隈の方々にプレゼントされたのが、本日の特別セミナー「知識ゼロから学ぶAIテスト」です。 まさに「AIの品質」にスポットを当て、エキスパート3名の講演を聞くことができました。 Building Trust in AI through Risk: An Emerging Test Specialism｜Stuart Reid博士講演 まずはStuart Reid博士が登壇されました。 タイトルを直訳すると、 リスクを通じてAIの信頼を築く： 新たなテスト専門分野 となります。 AIテクノロジーの95％は機械学習システム（Machine Lerning System）とのことで、MLSを中心に講演が進みます。 冒頭から一気にひきつけられる内容でした。 （要約） 2022年には92％の企業がAIに投資をし、AIから大きな利益を得られるようになってきています。 市場に大きなインパクトを与え、AIの時代が到来したことを告げています。 しかし、AIには「信頼できない」という問題が依然としてあります。 世界で約半数の人は 「AIの利益はリスクを上回る」 と答えていますが、AIを「 信頼しない 」「 データをAIと共有したくない 」と考える人も38％もいます。（日本やイギリスは「信頼しない」の割合が高い） 一方でイギリスのほぼすべての人がSNSを使用しています。 しかし驚くべきことに、実に45％の人はSNSがAIを使用していることを知らないで使用しています。 AIのメリットを享受していることを知らずに「信頼しない」と答えているということです。 信頼がなければAIは発展していくことができません。 では、信頼を得るためにはどうすればよいのか。 テストをすることです。 テスト業界には大きなチャンスが訪れています。 ここからMLSのリスクと重要性に関するお話になるのですが、講演に先駆けて特別寄稿されている こちらの記事 にも詳しく解説されていますので、ぜひご参照ください。 【日本語】AIのリスクベーステスト/Risk-Based Testing for AI 中でも、「入力データのリスク」では、 「ineffective data governance（非効果的なデータガバナンス）」について、「39％がデータプライバシーは生成AIのリスクであると考えているにも関わらず、このリスクを軽減しようとしているのは20%のみ。 約半分はテストをしていない。テストをせずに公開して利益を得ることを選択している可能性がある」 「開発リスク」では、 「lack of explainability (e.g. selected algorithm is difficult to explain) （説明不足（例：選択したアルゴリズムの説明が難しい））」について、「39％が、生成AIには説明の欠如というリスクがあると考えているにも関わらず、このリスクを軽減しようとしているのはわずか18％」 「開発フレームワークのセキュリティテストについて、53％はリスクがあると考えているのに、軽減を図っているのはわずか38％」 など、MLSのテスト実施割合の低さ、品質の問題点について数値を用いて大変わかりやすく解説していただき、あらためて問題意識を持つことができました。 AI（MLS）独自のテストについてもReid博士の寄稿文に詳しく解説されております。 【日本語】AIのリスクベーステスト/Risk-Based Testing for AI (日本語翻訳版) コーヒーブレイク オフライン開催のセミナーならではのコーヒーブレイクでは、帝国ホテルのサンドイッチとコーヒーで一息。 参加者同士の名刺交換、登壇者と参加者の雑談風景が見られるのも、オフライン開催ならではです。 オンラインに慣れてしまっているこのごろですが、やはりこのような風景はいいですね。 会場を眺めていると、いろいろな雑談や笑い声が聞こえてきて、温かみを感じました。 AIのAIによるAIのためのテスト｜西康晴博士講演 続いては西康晴博士の講演「AIのAIによるAIのためのテスト」です。 時々会場を笑いに包みながら、様々な事例とともにAIテストの具体例を解説してくださいました。 シベリアンハスキーと狼を見分けるAIを作成した。 どのようにシベリアンハスキーと狼を見分けているかというと、顔や鼻、耳を見ているわけではなく、バックグラウンドに雪があるかどうかだけで判断している。 このようなAIを信頼できるか？というお話は大変興味深いものでした。 また、AIのテストにおいては、 ・これまでのテスト技術が使えない ・自動化が必須 ・性能や不具合の因果関係の説明や理解は極めて難しいため、XAI（Explainable AI）（AIの中身を説明できた気になる技術）が大事になる というお話もあり、あらためてAIをテストすることの難しさを感じました。 メタモルフィックテスト AIテストの代表的な一つが「メタモルフィックテスト」であるとし、詳しく解説くださいました。 ・メタモルフィックテストとはAIの間違いを探すことが主 ・判定ミスを起こさせることで、どこで判別しているかがわかる ・テストケース自体をAIで生成するという研究が盛んにおこなわれている ⇒「泳いでいるコアラの画像を入力するとモルモットと判別する」というテストケースを生成する、など 西博士もおっしゃっていましたが、このあたりのテストは発見も多く「面白い」とのこと。 スライドを見ながら講演を聞いているだけでも、大変興味深く面白かったです。 大規模言語モデル（LLM） 続いて大規模言語モデル（LLM：Large Language Models／ChatGPTなど）のバグを見つけるお話がありました。 LLMは人間のように会話しますが、一切知性を持っていない。 「次の単語予測マシーン」にすぎないから、 単語を崩すゲーム をやらせると間違える。 西博士のお話にあった例を、さっそく帰社後にChatGPT（GPT-3.5）で試してみました。 　1.　4桁×4桁の掛け算をやらせるとまず間違える 不正解 。 正解は、1958×5089=9,964,262　です。 続いて単語テスト。 2.　Sで始まりSで終わる単語を教えて 不正解 いい線いってましたが、5番を間違えていました。 もう一つ試してみます。 3.　Pで始まりPで終わる単語を教えて 不正解 これも惜しかったですね。 間違えているにもかかわらず、回答の後に注意事項まで述べてくれるChat-GPTに感謝して実験を終わりたいと思います。 さて、レポートに戻りますが、西博士の講演は、 AIを恐れる必要はありません。 AIを使いこなせる会社が勝ちます。 進む方向はもうわかっています。 どちらに進むかは、みなさんが決めることです。 と締めくくられました。 AIテスト及びシフトライト戦略｜高橋寿一博士講演 続いて高橋寿一博士の講演「AIテスト及びシフトライト戦略」です。 11/16刊行予定！こちらもよろしくお願いします。 AIというのは避けて通れなくなっているが、AIのテストというのは大変だと感じている。 テストの仕方も複雑になっている。 2～3年前まではShift-Leftを唱えてきたが、今はなぜShift-Rightなのか。 というお話しから始まりました。 参考　 いまさら「シフトレフト」について考えてみた Shift-Rightについては、 ・あまり定義はない ・Shift-Leftでやりたいが、できないため仕方なくShift-Right手法をとっている ソフトウェアの巨大化、複雑化に伴い、Shift-Rightを考えていく必要がある時期に来ている。 実際にビルドをして客先に出る直前、もしくは客先に出てからテストをしなければならないということが、今後増えてくるのではないか。 とのことで、品質に携わる方々の仕事は増えていく、Shift-Leftもやらなければならないし、Shift-Rightも増えていくのではないかと予測されていました。 AIのテストについては、 ・答えがないテストと言われている ・基本テストケースが無限大 ・といってもテストケース（データ）がちゃんと作れない そんな中で、まだ完璧なソリューションは持っていないが、なんとか品質を担保していきたいと研究しているところである、というお話しでした。 まとめ 今回のプレミアムセミナーは「知識ゼロから学ぶAIテスト」ということで、専門用語すら怪しかった私ですが、非常にわかりやすく、また興味をそそられる内容でした。 AIを利用した技術はまだまだこれから進歩・進化していきますが、興味を持ってAIと仲良くしていきたいと感じました。 3人の博士には熱く楽しい講演をお聞かせいただき、本当にありがとうございました。 The post 「知識ゼロから学ぶAIテスト」セミナー参加レポート first appeared on Sqripts .

どうもITインフラエンジニアのあっきーです。 普段の業務はお客様先に定期的にお伺いしサーバーやクライアント端末などのメンテナンスやコンサルをしています。 ここ最近は「Windows Server 2012/2012 R2」のマイクロソフトサポートが2023年10月に終了してしまう話題が多くあります。 「Windows Server 2003」から「Windows Server 2012/2012 R2」へリプレイスを行い、現在も稼働しているケースが多いようで、必然的にこのタイミングでのリプレイスが喫緊の課題になっています。 サポート終了後は、マイクロソフトからの新規のセキュリティパッチが提供されなくなります。その為、新たな脆弱性が見つかった場合、その脆弱性を狙った攻撃を防ぐことが難しくなります。また、トラブル時にマイクロソフトのサポートも受けられないため、ビジネスが止まるリスクが高まります。既に「Windows Server 2012/2012 R2」のリプレイスのお話は多く頂いておりますが、その中でも多い相談はActive Directory（アクティブ・ディレクトリ）の移行、ファイルサーバーの移行を含む案件です。 今回はActive Directoryの移行に関してお話させて頂きます。Active Directoryとは、Windows Server 2000から提供が開始された機能で、ネットワークにつないでいるクライアント端末やサーバー、プリンター、アプリケーションなどの情報を収集し、一元管理できるディレクトリサービスです。Active Directoryの歴史は長くなるので今回は割愛いたします（笑）。 では本題に戻ります。Active Directoryを移行する手順はいたるところで紹介されていますが、今回は、Active Directoryが稼働している「Windows Server 2012 R2」から「Windows Server 2019」若しくは「Windows Server 2022」へリプレイスする際に注意が必要な事を紹介します。Active Directoryの移行作業では、お客様へのヒアリング、旧サーバーの調査、初期設定、ネットワーク設定、Active Directory参加等々の作業後、ドメインコントローラー昇格作業に入りますが、稀に下図のようなエラーが発生する事があります。 ADサーバーリプレイス時に考慮して構成されている場合は出ないイレギュラーなエラーですが、「Windows Server 2022」ではSYSVOL共有のレプリケートにDFS-Rを利用しています。新規構築では発生しないのですが、Windows Server 2003頃からActive Directoryを利用していて、バージョンアップしたリプレイスをした際にFRSからDFS-Rに変換していない時に見かけます。ちなみに、FRSとは以前から使用されていたレプリケーションサービスで、「Windows Server 2016」まではサポートされており、Windows Server 2019以降ではサポートされておりません。 💡 Active Directory の SYSVOL レプリケーション方式として、従来ではファイルレプリケーションシステム（FRS：File Replication System）が使われていましたが、ドメイン機能レベル Windows Server 2008 から分散ファイルシステムレプリケーション（DFS-R：Distributed File System Replication）が利用できるようになりました。また、DFS-R へ切り替えることで「SYSVOL 変更情報の差分のみが同期される」、「SYSVOL に変更が発生した場合は即時に同期が行われる」などのメリットがあります。 とうことで、こういうケースの時はドメインコントローラー昇格作業前にActive Directory の SYSVOL レプリケーション方式をFRSからDFS-Rに変換する作業が必要となります。FSRからDFS-Rに変換するには下記変換コマンドを利用します。 【FRS⇒DFS-R変換コマンド】 　dfsrmig.exe /CreateGlobalObjects 　dfsrmig.exe /GetGlobalState 　dfsrmig.exe /GetMigrationState 　dfsrmig /SetGlobalState 1 　dfsrmig /GetMigrationState 　dfsrmig /SetGlobalState 2 　dfsrmig /GetMigrationState 　dfsrmig /SetGlobalState 3 　dfsrmig /GetMigrationState コマンド実行後、問題なくFRSからDFS-Rに変換されたことを確認できれば、ドメインコントローラーの昇格作業が実施できます。その後、ADのマイグレーションを行えばリプレイス完了となります。 今回はActive Directory移行時の注意点として「FRS」と「DFS-R」の話をさせて頂きました。 まだ1年間ぐらいはWindows Server 2012/2012R2のリプレイスは多くあると見ています。最近は全く想定しない手順が必要となるケースはあまりありませんが、同じようなケースのリプレイスや新規構築でも決まった手順通りに進まないイレギュラー手順は発生するものです。当社ではイレギュラーな手順が必要になった時は再現環境を作り、問題を特定して手順確立とナレッジ化を行って対応の品質向上に取り組んでいます。 The post Active Directory移行時の「FRS」と「DFS-R」 first appeared on Sqripts .

はじめに 前回は、自動販売機を題材にして、BDDを用いたプロセスの「定式化(Formulation)」の部分までを説明しました。 今回は、「自動化(Automation)」の部分を説明します。 5. 自動化 前回の記事の「4. レビュー」まで、自動化については一切考えていませんでした。（BDDは自動化が目的ではないと第4回でお伝えした通りです。） ここまできて初めて、自動化について考えます。 今回は、前回作成した以下のGherkin記法のシナリオをインプットにして自動化を行います。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる 自動化の手順0. BDDのフレームワークを導入する BDDで行うためのフレームワークを導入します。本記事では、 プログラミング言語…Java フレームワーク…Cucumber ビルドツール…Maven で臨みます。 また、IDEはIntelliJを使用しており、「Cucumber for Java」のプラグインがインストール済みです。記事中に載っている画像は全てIntelliJのスクリーンショットであることをご了承ください。 Cucumberの構造を理解する Cucumberは以下の構造を作成して動かします。 Gherkin記法のシナリオとテストコードが分かれているのが、CucumberをはじめとしたBDDフレームワークの特徴です。 これにより、ビジネス関係者はGherkin記法のシナリオを見るだけで、どのような振る舞いを定義しているのか理解することができます。その際に、プログラミング特有のスキルは必要ありません。 CucumberのプロジェクトをCloneする 今回は、 cucumber-java-skeleton のプロジェクトをCloneします。 Cloneの仕方とCucumberの実行の仕方についてはプロジェクトのReadmeをご覧ください。 テストが実行できることを確認する GradleもしくはMavenを用いて、プロジェクトのReadmeに書いてある通りにテストを実行します。 例えばMavenの場合、以下のようにテストが実行できればOKです。初期状態ではテストが失敗するようになっています。 IDE上でフィーチャーファイルのテスト実行できることを確認する GradleもしくはMavenでテスト実行すると、IDEのフィーチャーファイル上でCucumberの実行ができるようになっています。 今回はCloneしたプロジェクトにデフォルトで入っているmaven/src/test/resources/io/cucumber/skeleton/belly.featureのファイルを開いてみましょう。すると、以下の画像のようになっているはずです。 この中で、行番号の1行目もしくは3行目の右側についている三角形2つのアイコンをクリックします。すると、以下のようなウィンドウが出てくるはずです。この中の一番上にある「Run ‘〜〜’」をクリックすると、IDE上でCucumberのテストを実行できます。 実行後、以下の画像のような結果になればOKです。 不要なファイルおよび記述を削除する 実際のプロジェクトを記述する上で以下のファイルは不要なので、削除してください。 maven/src/test/resources/io/cucumber/skeleton/belly.feature maven/src/main/java/io/cucumber/skeleton/Belly.java maven/src/test/java/io/cucumber/skeleton/StepDefinitions.java 以上で、Cucumberを用いてBDDの自動化を行う準備ができました。 自動化の手順1. フィーチャーファイルに記載する 新たにフィーチャーファイルを作成し、前回作成した以下のGherkin記法のシナリオを記載します。今回はmaven/src/test/resources/io.cucumber.vendormachine/vendormachine.featureというファイルを作成しました。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる 自動化の手順2. フィーチャーファイルを実行し、失敗を確認する 「自動化の手順1」で作成したフィーチャーファイル上で、Cucumberの実行をします。 すると、以下のようにテスト失敗となるはずです。 この時点では失敗している状態が正解となります。なぜならばシナリオを記述しただけで、それぞれのステップに対する実装をしていないためです。 なお、上のテスト失敗時の画像では、以下のようなテスト実行ステータスになっています。 Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある //←テスト失敗 When 550 円を入れる //←実行スキップ And 120 円の "コーラ" を選択する //←実行スキップ Then "コーラ" が出てくる //←実行スキップ And 430 円が出てくる //←実行スキップ Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある //←テスト失敗 When 550 円を入れる //←実行スキップ And 120 円の "コーラ" を選択する //←実行スキップ Then "コーラ" が出てくる //←実行スキップ And 430 円が出てくる //←実行スキップ 自動化の手順3. ステップ定義ファイルを作成し、Givenステップの実装を行う 「自動化の手順1」で作成したフィーチャーファイルを開くと、以下のようになっています。 このうち、4行目から8行目の背景色がついている部分は、コンパイルエラーの状態を示しています。今回の場合、それぞれの行に対応するステップ定義がないためコンパイルエラーとなっています。 そこで、まずは4行目の「Given 自動販売機がある」に対するステップ定義を作成します。 「自動販売機がある」の文章上にカーソルを持っていくと、ヒントとなる豆電球のアイコンが出てきます。 豆電球のアイコンをクリックし、「Create step definition」をクリックします。 すると、ステップ定義ファイルの作成ウィンドウが出てきますので、適当なファイルを作成します。 今回は、ファイル名を「VendorMachineDefinitions」、ファイルパスを「maven/src/test/java/io/cucumber/skeleton」としました。 ウィンドウの「OK」ボタンを押すと、以下の画像のようなmaven/src/test/java/io/cucumber/skeleton/VendorMachineDefinitions.javaファイルが自動作成されるはずです。 ここまで行ったらもう一度、「自動化の手順1」で作成したフィーチャーファイル上で、Cucumberの実行をします。 すると、前回とテスト結果が少し異なっているのが分かるでしょうか。 ステップ定義ファイル作成前のテスト結果 ステップ定義ファイル作成後のテスト結果 ステップ定義ファイル作成前では「自動販売機がある」の部分でテスト失敗になっており「550円を入れる」は実行スキップとなっていました。 一方ステップ定義ファイル作成後では「自動販売機がある」の部分は表示されず、「550円を入れる」の部分でテスト失敗になっています。 これは、「自動販売機がある」の部分のテストが成功しており、次のステップである「550円を入れる」のステップ定義が見つからないためテスト失敗となっていることを示しています。 自動化の手順4. Givenの中身を実装する ステップ定義ファイルおよびメソッドを作成しただけでは、具体的に実装ができていません。そこで、次に中身の実装を行います。 今回の場合、以下の画像のように記述します。現時点ではVendorMachineクラスが無いにもかかわらず、まるで存在しているかのように書くのはTDDを書く時と似ていますね。 この時点ではコンパイルエラーが発生している状態になっていればOKです。 自動化の手順5. コンパイルエラーの解消を行う 「自動化の手順4」で発生していたコンパイルエラーの解消を行っていきます。 今回の場合、maven/src/main/java/io/cucumber/vendormachine/VendorMachine.javaを作成することでコンパイルエラーの解消を行いました。 自動化の手順6. Whenステップの実装を行う 先ほどまでと同様に、今度は「When 550 円を入れる」のステップの実装を行います。 豆電球のアイコンをクリックし、「Create step definition」をクリックします。 今回は先ほどの「Given 自動販売機がある」と同じファイル上にステップ定義の実装を行うため、「VendorMachineDefinitions(io.cucumber.skeleton)」を選択します。 すると、VendorMachineDefinitionsファイルは以下のようになります。（変数名はarg0からinsertedAmountに変更しました） Tips シナリオ記載時に「When 550 円を入れる」と、数値の前後に半角スペースを記載すると、Cucumberが自動的に数値の変数だと判断してくれます。 同様に「Then “コーラ” が出てくる」のように、用語を””で括ると、Cucumberが自動的に文字列の変数だと判断してくれます。 Whenの中身を実装する Givenの時と同様に、TDDのような感覚で実装していきます。今回の場合、以下のようになります。 なお、Givenの時に生成したVendorMachineクラスを活用したいため、Given内のローカル変数だったvendorMachineをフィールド変数に変更しています。 そして、VendorMachineクラス内は以下のように変更します。 以下同様に、ステップ定義と実装を作成していきます。 おわりに 今回は「自動化(Automation)」として、BDDのフレームワークであるCucumberを用いた実装方法を紹介しました。 今回は説明しませんでしたが、BDDとしてのステップ定義を完成させた後は、より細かいテストを書いたり、実装部分のリファクタリングを行っていったりします。 その過程で色々と実装内容を変更することになるとは思いますが、今回のステップ定義を完成させておくことにより、外側の振る舞いは動くことを確認できるという安心感を持って変更することができます。これが、BDDやATDDの良さでもあります。 本連載「TDDとBDD/ATDD」も今回で最終回となります。今回は「自動化(Automation)」というプログラミング部分について説明していきましたが、BDDにおいて何よりも重要なのは「発見(Discovery)」で行うビジネス関係者との協調作業です。自動化のみを行って、Seb Roseに「開発アプローチは少しも BDD にはなっていません。」と言われないようにしましょう。 また、本連載をきっかけにBDDに興味を持った方は、ぜひThe BDD Booksシリーズをお読みいただければと思います。 The BDD Booksシリーズの書籍紹介ページは以下の通りです。 『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』 『 The BDD Books – Formulation （邦訳：The BDD Books – Formulation Japanese Editionはもうすぐ出版予定）』 『The BDD Books – Automation』はもうすぐ出版予定 それでは、BDDを通じてビジネス関係者と協調しながら、日々の業務を行ってみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 The post TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 first appeared on Sqripts .

はじめまして、QAエンジニアの桜 満開です。 最近よく生成AIという言葉を聞いたり目にしたりすることはありませんか？ 生成AIが実用化されてきている要因としましては、「コンピュータ性能の向上」「コロナ禍による労働環境の変化」「少子化による労働人口の減少」など、様々な要因はあるかとは思いますが、人間の稼働削減の必要に迫られ、この数年で飛躍的に進化を遂げてきている技術です。 ソフトウェアテストにおいても、AI活用によるテストの自動化は試みられており、「生成AIによるテストスクリプトの自動生成」といった活用も行われてきています。 ここまで便利に思える生成AIですが、急速に発展する技術にはそれを正しく利用するために留意しておかないといけないことがあります。 そう、タイトルにもある「著作権」です。 去る令和5年6月19日に文化庁による著作権セミナー「AIと著作権」が開催され、文化庁からの生成AIの利用時における著作権の考え方について、一定の指針が発表されました。 生成AIを利用してコンテンツを生成する場合も、状況によっては著作権の対象となりえる場合があります。 ここでは、セミナーでのポイントを抑えながら、生成AIや著作権について一緒に考えていきたいと思います。 ※本ブログ内容は令和5年8月時点の内容となります。 セミナー概要 セミナー名：令和5年度 著作権セミナー「AIと著作権」 主催者　　：文化庁著作権課 開催日　　：令和5年6月19日 著作権法の正しい理解に基づいて生成AIの利活用がされるよう、現行の著作権法の考え方やAIと著作権の関係についての説明が行われました。 第１部では著作権制度の概要についての解説。 第２部ではAIと著作権について、生成AIと著作権の関係についての解説。 という、２部構成で約１時間のセミナーとなっていました。 アーカイブ映像や講義資料は 文化庁のWebサイト から確認することができます。 そもそも著作権とは？ まずはセミナーの第１部「著作権制度の概要についての解説」と同じく、著作権について 文化庁の著作権テキスト の内容を引用しつつ確認・整理していきます。 著作権保護の目的 著作権テキスト 4ページ に以下のように記載されています。 適切な権利保護によって「創作の促進」を図り、権利の制限によって「公正な利用」を確保し、もって「文化の発展に寄与」することを目的としています。 文化庁著作権テキスト ※ 文化庁の著作権テキスト 4ページ より掲載 要は 「文化の発展に寄与」 するためには、新たな創造 「創作の促進」 が不可欠で、「創作の促進」を促すには、権利の保護・権利の制限で著作物の 「公正な利用」 を確保し、著作者に不利益にならないように利用できるようにすることで、創作の循環が生まれるようにする。ということのようです。 セミナーでも、 「著作者等の権利・利益を保護すること」と、「著作物を円滑に利用できること」のバランスを取ることが重要と考えられている。 と話されていました。 著作物について 次に著作物についての定義を確認しましょう。 著作権テキスト 5ページ の記載内容に、 著作権法では、著作物は、 「(a)思想又は感情を (b)創作的に (c)表現したものであつて、(d)文芸、学術、美術又は音楽の範囲に属するもの」 文化庁著作権テキスト と定義されています。 つまり、 思想や感情などの含まれないデータや事実といったもの 創作ではなく模倣であったり、ありふれたもの 表現していないアイデアのまま 工業製品 というように、定義から外れるものは著作物と認められない可能性が高いです。 業務に身近な著作物について それでは、ソフトウェアテストにおける身近な著作物についてはどのようなものがあるでしょうか？ ソフトウェアテストにおける作成物では、 要件定義書 詳細設計書 テストスイート テストシナリオ テストスクリプト テストサマリーレポート など、様々な作成物が存在するかと思います。 これらについて、著作物の定義や種類にあてはめてみると、 思想を創作的に表現した言語やプログラムの著作物としてなり得るもの は、 テストシナリオ テストスクリプト テストサマリーレポート 辺りでしょうか。 ただ、テストの目的としては「誰が操作しても正しい結果が得られること」を目的としているので、そこに対して創作性を見出すことは難しいかもしれません。 そもそも生成AIとは？ 続いて、今回のセミナーでは説明として触れられていませんでしたが、「生成AIとは何なのか？」「AIと何が違うのか？」を確認しておきます。 AIと生成AIの定義について AIについて 厚生労働省から公開されている「 AIの定義と開発経緯 」には、 人工知能（AI：artificial intelligence）については、明確な定義は存在しないが、「大量の知識データに対して、高度な推論を的確に行うことを目指したもの」（一般社団法人 人工知能学会設立趣意書からの抜粋）とされている。 AIの定義と開発経緯 と記載されています。 その他に総務省から公開されている「 人工知能(AI：エーアイ)のしくみ 」でも、 「AI」に関する確立した定義はありませんが、人間の思考プロセスと同じような形で動作するプログラム、あるいは人間が知的と感じる情報（じょうほう）処理（しょり）・技術（ぎじゅつ）といった広い概念で理解されされています。 人工知能(AI：エーアイ)のしくみ という記載があります。 AIは明確に確立された定義は無い。 という少し曖昧な技術ですが、大量のデータに対して 人間が思考・処理を行うことと同じように、コンピュータが動作を行うことを目的とした技術。 ということで、主に人間の代わりに処理を行うコンピュータを指すことが多い印象です。 生成AIについて NIKKEI COMPASSの生成AIの解説 には、 生成AI(英:Generative AI)は、画像、文章、音声、プログラムコード、構造化データなどさまざまなコンテンツを生成することのできる人工知能のこと。 NIKKEI COMPASSの生成AIの解説 大量のデータを学習した学習モデルが人間が作成するような絵や文章を生成することができる。 NIKKEI COMPASSの生成AIの解説 とあります。 つまり、AIが処理や技術を指していることに対して、 生成AIはそのAI技術を使って新たなコンテンツを生成することを目的 としています。 生成AIの学習段階と生成段階 生成AIを利用して新たなコンテンツを生成するためには、まずAIにデータを蓄積して情報を学習させる「学習段階」というものがあります。 この学習段階で蓄積するデータによって、AIの特徴づけが行われたりします。 次に、学習済みのAIに対して新たなコンテンツを生成させるために、利用者がどのようなコンテンツを 生み出したいかといった要求をAIに指示を出してコンテンツを生成する「生成段階」というものがあります。 この指示の出し方でも最終的な生成物の仕上がりが左右されます。 主な生成AIサービス 昨今話題に上がっている主な生成AIの種類では、「画像生成AI」「テキスト生成AI」「動画生成AI」「音声生成AI」など様々なものが展開されています。 例えばテキスト生成AIについては、サポートセンターなどへチャットで問い合わせた際に、質問に応じた生成メッセージが返答される。 という機会が身近に増えているかと思います。 ソフトウェアテストにおいても、テキスト生成AIにてテストケースの自動生成やテストスクリプトの自動生成、テストデータの自動生成など、生成AI活用の場面も増えてきています。 生成AIを利用する上での著作権に関するポイント では、実際に生成AIを利用する上で著作権に注意するポイントはどこになるのか、著作権セミナーの２部で解説されていた内容を元に確認していきます。 冒頭で触れていた、「生成AIを利用していても、状況によっては著作権の対象となりえる場合」について、また「対象とならない場合」についても具体的に見ていきましょう。 １．学習段階における学習のもととなった著作物 まず１つ目に、AIの開発・学習段階における、AI学習の元となったデータについての著作権に関する問題が説明されています。 結論としては、令和5年6月時点の著作権法第３０条の４の解釈では、 AI開発のための情報解析は既存の著作物に表現された思想や感情の享受を目的とした利用ではない。 （権利制限規定） と考えられることが多く、原則として著作権者の許諾なくAI学習を行うことができるようです。 セミナーでは、一般的な深層学習におけるAI学習段階の一例を元に説明されていました。 ※ 文化庁の著作権セミナーテキスト 30ページ～ より掲載 こちらに書かれているように、AI学習段階においてはWeb上のデータを収集して学習していくことが多く、さらに数十億点というような大量データの著作権の有無の判別や、著作者からの許諾を得る。 ということが困難で非現実的という状況から、下記の取り組みが行われてきたようです。 平成21年改正：インターネット情報検索サービスのための複製、電子計算機による情報解析のための複製等について、権利制限規定を整備 平成24年改正：いわゆる「写り込み」、技術の開発又は実用化のための試験の用に供するための利用等について、権利制限規定を整備 次世代知財システム検討委員会〔知的財産戦略本部・H27～28〕 新たな情報財検討委員会〔知的財産戦略本部・ H28～29〕 これらの取り組みの結果、著作権法第３０条の４が導入され、 ＡＩ開発のための情報解析のように、著作物に表現された思想又は感情の享受を目的としない利用行為は、原則として著作権者の許諾なく行うことが可能です（権利制限規定）。 と法改正になっているようです。 ※ 文化庁の著作権テキスト 65ページ より掲載 ただし、あくまで 著作権者への経済的利益を害するものではない。 ということが前提の思想としてはある為、 「著作権者の利益を不当に害することとなる場合※」は、本条の規定の対象とはなりません。 ※例えば、情報解析用に販売されているデータベースの著作物をＡＩ学習目的で複製する場合など。 という但し書きの条件や、 著作権者の著作物の利用市場と衝突するか、あるいは将来における著作物の潜在的販路を阻害するかという観点から、最終的には司法の場で個別具体的に判断されます。 とも説明されていました。 ソフトウェアテストにおいてもAI開発・学習が行われていますが、多くの企業では自社の過去のナレッジからAI学習を行っていることが多いようです。 私の所属会社（AGEST）につきましても、先日7月11日にAI技術の研究開発を行う「AGEST AI Lab.」の設立を発表いたしております。 こちらの ホームページ に情報公開しておりますので、ご参照いただければと思います。 ２．生成段階における入力情報の著作物 ２つ目に、生成AIを利用してデータを生成する段階における、入力情報となるものの著作権に関する問題が説明されています。 結論としては、 生成AI利用の有無に関わらず、既存の著作権同様の考え方が適用される。 ということのようです。 セミナーで説明されていた内容としましては、 ＡＩを利用して画像等を生成した場合でも、著作権侵害となるか否かは、人がＡＩを利用せず絵を描いた場合などの、通常の場合と同様に判断されます。 AI生成物に、既存の著作物との「類似性」又は「依拠性」が認められない場合、既存の著作物の著作権侵害とはならず、著作権法上は著作権者の許諾なく利用することが可能です。 これに対して、既存の著作物との「類似性」及び「依拠性」が認められる場合、そのようなAI生成物を利用する行為は、 ① 権利者から利用許諾を得ている ② 許諾が不要な権利制限規定が適用される ……のいずれかに該当しない限り、著作権侵害となります。 ということでした。 ※ 文化庁の著作権セミナーテキスト 44ページ より掲載 上記内容のとおり、特にAIだからということではなく、既存の著作権同様の考え方が適用されている。 ということでした。 ただ、生成AI利用という点でいうと、特に 生成物を作成するためのテキストの入力情報についても、「類似性」「依拠性」を問われる。 という点は気をつける必要がありそうです。 ３．生成AIの生成物自体の著作権の有無 ３つ目に、生成AIで生成した生成物自体に「著作権は認められるのか？」「著作者は誰になるのか？」という問題が説明されています。 結論としては、 AIが独自で創出したものは著作物にならず、利用者の創作意図が介入している場合は著作物になる。 ということのようです。 セミナーで説明されていた内容としましては、 AIが自律的に生成したものは、 「思想又は感情を創作的に表現したもの」ではなく、著作物に該当しないと考えられます。 （例）人が何ら指示※を与えず（又は簡単な指示を与えるにとどまり） 「生成」のボタンを押すだけでAIが生成したもの　※プロンプト等 これに対して、人が思想感情を創作的に表現するための「道具」としてAIを使用したものと認められれば、著作物に該当し、AI利用者が著作者となると考えられます。 というように、あくまで 著作物は人の「思想や感情などを創作的に表現したもの」である ので、それに当てはまらない利用方法をしている場合は著作物には該当せず、当てはまる場合は利用者の著作物として考えられるようです。 この考え方は中々に興味深く、人の思想や感情が入っていなければAIが生み出す生成物について、たとえ創造性が高いものであったとしても著作物になり得ず、著作者もいない。というケースが出てくる可能性があります。 たとえ同じような生成物だとしても、 「AI独自で創り出したもの」と「人の創作意図が介入して創り出したもの」とでは著作物の有無が異なる。 ということになります。 何と言いますか、新しい時代に入っているのだ。と改めて認識する感覚ですね。 さいごに 生成AIを業務利用する際にはどのようなことに注意すべきか ここまで著作権セミナーの解説内容を振り返りながら、著作権や生成AIについて確認してきましたが、結局のところ生成AIを活用して業務利用を行っていくに当たって、注意しておくポイントをまとめておきましょう。 ・ ポイント１つ目：著作物となり得るのかどうか 生成AIの開発・学習段階、生成段階、生成物について、著作物の定義 「(a)思想又は感情を (b)創作的に (c)表現したものであつて、(d)文芸、学術、美術又は音楽の範囲に属するもの」 と照らし合わせて著作物と見なされるかを確認しておくことが重要です。 ・ ポイント２つ目：著作者の権利を侵害していないか １つ目の確認で著作物であった場合、生成AIを利用してコンテンツを生成する上で、著作権の侵害に該当しないかどうかの確認が必要となります。 基本的に「権利制限規定」以外での利用は著作者に許諾が必要となります。生成AIの利用で著作者の利益を不当に侵害していないことが考え方の基本となります。 今後の著作権法の改正についてもチェックが大切 生成AIに限らず、技術の進歩に応じて著作権法も日々時代に合わせて改正されています。 先日に文化庁で行われた著作権セミナーのように、技術の進歩に応じて考え方を整理・検討して提示したり、法改正や施行が行われています。 文化庁で公開されている著作権テキストも現在は令和5年度版が公開されていて、前年度から記載内容の変更箇所もあります。 先端技術については法改正の整備頻度も早いので、文化庁などの発信情報を注視していくことが大切だと改めて感じました。 The post 生成AIと著作権について考える first appeared on Sqripts .

みなさん、こんにちは！　QAエンジニアのゆーすけです。 9/22にJaSST新潟が開催されました。（ JaSST ） 新潟でのハイブリット開催（オフライン＋オンライン）のため、当初は業務の傍らオンライン視聴ができればと思ってましたが、掲げたテーマに強い興味を抱いたため、業務を調整して新潟現地参加をしてきました。 「QAスキルアセスメントを活用したQA標準化とQA人材育成」 今回の新潟のテーマがこちらになります。 アセスメントとはざっくりいうと評価、分析といった類の意味合いとなります。 ひと昔前のAGESTでは、各役割（職務ないし職能）に対しての定義が 「求められる役割を満たすこと」 というような記載もあり、役割に対しての解釈が個人で異なる、また会社として標準スキルの定義が曖昧な部分もあったため、目指すべきキャリアに対しての研鑽すべきスキル提示ができてないものもありました。 順次job description（以下JD）を整理しているものの、役割に対して求められるスキルや、スキルに対する待遇というものはそれぞれの組織で大きく異なっていて、ここに明確な解はありません。 現在、役割に応じたジョブ定義、持っていてほしいスキル、資格などを鋭意設計中ですが、なかなか自分の所属組織外の情報を聞けるという機会も中々に稀だと思い、せっかく聞くのであれば現地で生の声を聞こうと思い、新潟に足を運ばせるきっかけとなりました！ 基調講演として、Sqriptsスクリプターである 湯本氏 によるfreee社での取り組みを語っていただいております。 講演内容レポートに関して、情報の誤認識、拡大解釈、認識のバイアスなどがあるとfreee社にご迷惑をおかけしてしまうことになりそうなので、印象に残った箇所の抜粋とそれに対する自分の考えやAGESTの方向性を取り上げていきたいと思います。 分化の違いを理解したうえで、自己の分化を確立する QAの経験があるといっても、組織が違えば根本的な部分での分化の違いはある 採用とあわせて、自社としてのQAを確立する必要性があった こちらはまさにその通りすぎる、と思いました。 自分も採用面接に携わることがありますが、これはクライアント様とMTGする時も思うことがあります。 分化が違えば同じ用語を使っていても中身の意味が全く違う、というようなことは多々あるので、 「コミュニケーションを重ねる」 「異文化である、ということを大前提で考える」 「自分の中の指標・ものさしをしっかりと固める必要がある」 といったようなことが大事である、と改めて感じるお言葉でした。 教えるもの、教えないものを切り分ける QA人材の育成で必要なことは、何を教えるのか、どこまで教えればいいのかを明らかにすること ～ オンボーディングで行う内容と、OJTで行う内容を明確に分かる これはなるほどな、と。 AGESTでも入社後のオンボーディングを1～1.5ヵ月で行っていますが、オンボーディングを実際に受けていないメンバーは実際のオンボーディングで明確に何をどの粒度まで教えているか、ということまでは切り分けられてないな、と。 基本的には現場で必要そうな内容をオンボーディングに入れ込んでいますが、あえてオンボーディングでは扱わずOJTに任せる（その代わり必ずOJTで扱うようメンバー理解が必要）ということは効果的になるものもあるな、と強く感じた内容でした。 スキルラダーのロール定義 スキルラダーのロール定義 スキルラダーに関しては自分も初聞きの単語でした。 ラダーは梯子を意味しておりスキルラダーとするとスキルの専門性をあげていくための指標。 キャリアマップ/パス、JDとは異なり昇進、報酬とは関連しない純粋なスキルマップのようなものとなり、今の自分のスキル位置を計れるようなもの、という理解をしています。 ジュニア層の定義は各分野の初歩は全てできるべき、ミドル層からは役割に特化して専門的にスキルアップできるように この内容に関しては、AGESTでも同じような考えをしています。 なぜならAGEST QA部門で考えているJDでも、ジュニア層は全ての初級を理解し、その上で専門性のあるテストエンジニア、テストマネージャー、テクニカルテストエンジニアなどに分かれるように設計しているので、新たな観点を得られたということはありませんが、それ以上に大きな安心感を得られた、という思いになりました。 スキルラダーの評価軸：自立性 freee社の自立性評価として、「サポートありき」「サポートが必要だから基本はできる」「サポート不要」「人のサポートができる」としている、とのことでした。 ここもある似ている考えをしており安心感を覚えた内容ですが、個人的には test.sff や守破離の考え方にもある「改善、改良、新規プロセスを生み出すことができる」といったものも上位評価として置きたいと考えています。 アウトプットを標準化すると人の流動化が容易になる これは自社プロダクトが複数ある前提特有かな、という思いが強い内容でした。 自社内に複数プロダクトがあり、QAのアウトプットをプロダクト横断で標準化することでプロダクト移動をしても覚えなおしがなく一定上の効果が見込まれる、という内容という理解をしていますが、第三者会社ではアウトプットの内容は顧客側に依存することがあります。（そもそもテストに対するインプットデータが絶対的に標準化されない） 第三者検証会社でも自社フォーマットで運用して構わないものは標準化を行っていますが、顧客に向き合い、顧客ごとの体制/要望に寄り添い臨機応援に対応、カスタマイズしてて成果を出す、というのが第三者検証会社ならではの面白味なのかもしれない、とあらためて感じました。 評価とカルチャー ほか心に残った内容としては 人事評価はスキルラダーでは行わず、アウトカムで行う スキルラダーは採用には活用しない。採用はカルチャーフィットが重要 というのが評価、採用にも携わる立場としては今後も意識して考えるべき内容だな、と思っています。 今回一部お見せいただいたスキルラダーは提示することで、スキルの客観的向上の可視化＝評価、待遇直結といったようなことも起こりやすいのかな、と思いますが、 成果により会社貢献 ↑ 成果を出すためのプロセス、ジョブ定義 　　↑ プロセスを達成するためのスキル 　　　　↑ スキルを習熟するための研修、オンボーディング、および各種資格奨励 のようなことが基本である、と。 また、採用においてもスキルや経験の確認を重要視していた時代（十数年前）も確かに自分にもありましたので、この2つは自分の襟を正すきっかけになったのではないかな、と思っております。 まとめ 今回スキルラダーや、freee社で使用されているテストチャータ等、具体的なものも見せていただきましたが、実際に何を考え何を構築するかは所属組織次第だと思っています。 freee社の事例はあくまでfreee社にあった内容であり、湯本氏も講演資料冒頭で 「組織作りの参考にしてね！」 と記載しているので、大事なのは事例を100%受け止めるのではなく、 スキルアセスメントや標準化などを考えることがカルチャー形成になり、 カルチャーが定まることによって方針、方向性がより強固なものになり、 それが自社ブランドになっていく、 ということが、今回のカンファレンス参加で持ち帰った内容になります。 この自分の考えもあくまで自社カルチャーにあわせた考え方も多いと思いますので、 皆様も組織作りや組織の中での動き方の参考にしていただければと思います。 またもしAGESTのカルチャーに興味を湧くようなことがありましたら、気軽にお問い合わせをしていただければと！！ The post 今こそQAスキルアセスメントについて考えてみた（JaSST新潟レポートにかえて） first appeared on Sqripts .

こんにちは、見習いフロントエンジニアのぱやぴです。 今回はframer-motionを使用して、React＋Typescriptでカレンダーコンポーネントに月の変更時のアニメーションを追加する方法を紹介します。 はじめに まず、完成したものをご紹介します。 （フレーム数の問題でカクカクしていますが、実際はスムーズに動作します！） 実装 それではアニメーションの実装をしていきます。。 使用技術 TypeScript: “^4.8.4” React: “^18.2.0” framer-motion: “^9.0.0” date-fns: “^2.29.3” アニメーション作成前の準備 まず、date-fnsを使用して以下のようなコンポーネントを作成しました。 import { addMonths, subMonths } from "date-fns"; import { useState } from "react"; import { Month } from "./Month"; import { CalendarHeader } from "./CalendarHeader"; export interface CalendarProps { date?: string; } export const Calendar = ({date}: CalendarProps) => { const currentDate = date ? new Date(date) : new Date(); const [month, setMonth] = useState(currentDate); const onNext = () => { setMonth(addMonths(month, 1)); }; const onPrev = () => { setMonth(subMonths(month, 1)); }; return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <Month month={month} /> </div> ); }; アニメーションの作成 まず、アニメーションの定義を行います。 月が進む場合と月が戻る場合の2つのパターンのアニメーションと最終的な位置を決めます。 月が進む場合は右から、月が戻る場合は左から移動してくるように設定し、最終的に0になるようにしました。 const variants = { enter: (isNext: boolean) => { return { x: isNext ? 100 : -100, opacity: 0, }; }, center: { x: 0, opacity: 1, }, }; 状態の作成 月が進んでいるか戻っているかの状態を管理し、月を変更するタイミングで状態を更新します。 const [isNext, setIsNext] = useState<boolean>(); const onNext = () => { setMonth(addMonths(month, 1)); setIsNext(true); }; const onPrev = () => { setMonth(subMonths(month, 1)); setIsNext(false); }; アニメーションの適用 アニメーションを適用したいコンポーネント（今回はMonthコンポーネント）を motion.div コンポーネントで囲み、アニメーションの設定を行います。 import { motion } from "framer-motion"; ~~~ return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <motion.div key={month.toString()} custom={isNext} variants={variants} initial="enter" animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> </div> ); custom プロパティに渡した変数は、 variants プロパティで渡した関数の引数として使用されます。 initial プロパティには描画時のアニメーション、 animate プロパティには描画後のアニメーションを設定します。 transition プロパティを使用することで、opacityの速度やx軸の移動方法など、さまざまな設定を行うことができます。 詳細な設定については、以下のリンクで確認できます： https://www.framer.com/motion/transition/ 今回はxの動きに "spring" を使用して、少し反発するようなアニメーションに設定しています。 初回描画時のアニメーション 上記のままでは初回のカレンダー描画時に月が左からスライドインするようなアニメーションが発生します。 初回のみアニメーションを行わないようにするため、 initial プロパティに条件分岐を追加しました。 ~~~ <motion.div key={month.toString()} custom={isNext} variants={variants} initial={isNext === undefined ? "center" : "enter"} animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> ~~~ 完成図 import { addMonths, subMonths } from "date-fns"; import { motion } from "framer-motion"; import { useState } from "react"; import { Month } from "./Month"; import { CalendarHeader } from "./CalendarHeader"; const variants = { enter: (isNext: boolean) => { return { x: isNext ? 100 : -100, opacity: 0, }; }, center: { x: 0, opacity: 1, }, }; export interface CalendarProps { date?: string; } export const Calendar = ({ date }: CalendarProps) => { const currentDate = date ? new Date(date) : new Date(); const [month, setMonth] = useState(currentDate); const [isNext, setIsNext] = useState<boolean | undefined>(undefined); const onNext = () => { setMonth(addMonths(month, 1)); setIsNext(true); }; const onPrev = () => { setMonth(subMonths(month, 1)); setIsNext(false); }; return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <motion.div key={month.toString()} custom={isNext} variants={variants} initial={isNext === undefined ? "center" : "enter"} animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> </div> ); }; 最後に framer-motionを使用することで、簡単にアニメーションを追加することができました。 アニメーションを追加するだけで、より洗練されたコンポーネントになりました！ framer-motionを使えば、比較的簡単に複雑なアニメーションを作成できますので、さらに学習を進めて、プロダクト内で活用できるリッチなコンポーネントを作成していきたいと思います。 読んでいただき、ありがとうございました。何か参考になれば幸いです。 The post framer-motionでReactのカレンダーコンポーネントを少しリッチに first appeared on Sqripts .

お客様とサービスの間には有形、無形の連続する接点が存在します。この接点の一つ一つを「ユーザーインタフェース（UI）」といい、連続する接点がお客様やお客様に関わる方々にもたらす記憶や感情、想いといったものを「ユーザーエクスペリエンス（UX）」あるいは「顧客体験」と呼びます。 ここ近年、IT技術の発展によってUIは高度に進化し、お客様のUXも大変リッチになってきました。 一度、素晴らしい体験をしたお客様の満足度レベルが上がると、これまで不満なく使ってきたシステムやサービスに満足できなくなります。特にWebサービスなどは、お客様が同じデバイスから各種のサービスを既にご体験なさっていることも多く、ご提供したいサービスそのものではなく入口のメンバー登録など多くのサービスと共通のUI部分で競合以外のサービスと比較されてしまいサイトを離れてしまうといった残念なことが起こってしまいます。 また反対に慣れ親しんだサービスのUIが急に、或いは一方的に変更されてしまったことに不満が募りそのサービスから離れてしまうといったことも起きてしまいます。 本記事では、お客様に不満を抱かせない、更には満足いただけるシステムやサービスを提供し続けるために私たちは何をすればよいのかということをご一緒に考えたいと思います。 ユーザビリティ改善で品質改善スキルが上がる 3 つの理由 　皆さんがシステムやサービスを提供する側でいらっしゃる場合、ユーザビリティを具体的に意識するのはいつごろでしょうか？ サイトの直帰率や平均滞在時間の指標が思わしくない時？ UAT ※1 でユーザビリティに関する問題が山のように指摘された時？　 いえ、このコラムを読んでくださっている読者の方ならば「いつも意識している」とおっしゃる方が大半に違いありません。 では具体的に改善を図るのはいつごろでしょうか？ 実は、ユーザビリティの改善は企画や要件定義工程から始めると手戻りも少なく、組織としての品質改善スキルもどんどん向上していく優れものの取り組みなのです。 「えっ？ユーザビリティとか可用性って非機能要件の一つだから、ユーザビリティ向上って品質改善そのものでは？」 鋭い読者の方はそのようにご指摘くださるかもしれません。ですが、わざわざユーザビリティ改善を取り上げるのは次の3つの理由があるからです。 理由①　改善された、良くなったことが分かりやすい 理由②　組織全体で取り組むことが出来る 理由③　1/0(イチゼロ)ではなく段階的に改善していける ※1　参照　 JUAS「非機能要求仕様ガイドライン」 工夫や努力を分かってもらえると一層やる気が出ませんか 一つずつ説明していきましょう。 まず、「理由①　良くなったことが分かりやすい」ですが、この理由だけでユーザビリティ改善に取り組むべき価値がある理由です。品質の中には改善しても効果が分かりづらい、どこがどのように良くなったのか説明しづらいものもあります。 例えば「保守性－構成管理効率 ※2 が0.5から0.6にあがりました」と言われたら上がったのが良いか悪いかさえ門外漢には判断しづらいですが、「エンドユーザー5人中3名が当惑して先に進めなかった箇所が5人全員先に進めるようになりました」と聞くと良くなったことが分かりやすいですよね。 改善をアピールしやすいと言い換えても良いでしょう。人間、褒められるとやる気が出るのは自然なこと。改善をさりげなくアピールして組織内で認められたり、何よりもエンドユーザーに喜ばれたりと改善のモチベーションが向上します。そして更に良くしようという原動力となり好循環が働くようになれば自主的に改善に励むようになります。 ※2　保守性－構成管理効率：保守作業における各種資源（プログラムやドキュメント、使用データ（DBを含む））のバージョン管理における機械管理の実現割合： JUAS「非機能要求仕様ガイドライン」 より 組織のみんながお客様の方を見ることで連帯感が強まります 次に「理由②　組織全体で取り組むことが出来る」ですがこれはユーザビリティの定義をお伝えすると分かりやすいかもしれません。 ユーザビリティ ※3 とはJIS Z 8520によりますと「特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い。」と定義されています。 つまり改善を図る前に「どういったユーザー」が「どういった状況で」「何を目標・目的に」使った場合使いやすいのかを明確に定義する必要があります。そして一般的に組織の中でターゲットユーザーやメインユーザーの情報を多く持っているのは企画や営業、ユーザー対応部門といった方々です。 となれば、ユーザビリティの効果的な改善には、通常開発と品証部門のしかも機能によっては限られたチームのみが人知れず頑張っているところ、多くの部門を巻き込んで取り組むことが出来ます。 あなたが提供しようとしているシステムやサービスが基幹システムの場合、経理や総務といった部門の方がユーザーの代わりに問題点を見つけてくださるかもしれません。 特許関係でしかやり取りの無かった法務部門の方が、ターゲットユーザーのペルソナにピッタリかもしれません。 すると、関わった方たちも改善項目の進捗を気にかけてくださるようになります。自分からも色々と直接伺うことが増えたり各部署へ情報発信をしたりすることが自然と行われていきます。 多様な方が関わってくださればくださるほど気づきの機会も増えますし、カバーできる範囲も広くなっていくと思いませんか？ その他の品質項目も改善には色々な部門からの協力を仰ぐ必要がありますが、そういった協力を仰ぐ前に、大きな負担を相手に掛けず気軽なお願いでネットワークを築いていけるチャンスを作ってくれる点はユーザビリティ改善活動の得難い利点です。 ※3　参照　JIS Z 8521：2020　人間工学−人とシステムとのインタラクション− ユーザビリティの定義及び概念 スモールサクセスが品質改善活動への肯定感をどんどん高めます 最後の理由は「段階的に改善していける」点です。 個人的な挑戦において「初めから大きな成功を目標に掲げず、小さな目標を掲げて成功体験を積み重ねていった方が、目標達成率が高い」と聞いたことはありませんか？これは組織での改善でも言える事です。 そしてユーザビリティは「効果，効率及び満足を伴って特定の目標を達成する度合い」なので「達成した、できなかった」の1/0(イチゼロ)ではなく、改善のステップを段階的に設定することが可能です。 短い期間で小さな改善を示すことによってあなたやあなたのチーム、システムやサービスが確実に「変わっていく」「良くなっていく」という印象と信頼を周りに感じていただくことが出来ます。 すると信じられないかもしれませんが、その他の改善活動を行う際も「あの人は、あのチームは、有言実行の実績があれもある、これもある」と思って快く協力してくれることが増えてくるのです。 お客様に不満を抱かせない、更には満足いただけるシステムやサービスを提供し続けるにはお客様への深い理解と不断の品質向上が必要です。これらを充実感と共に実施できるのが「ユーザビリティ改善」という取り組みです。 是非皆さんも「ユーザビリティ改善」から品質改善を始めてみませんか？ The post 「ユーザビリティ」後回しになっていませんか？― 品質改善スキル向上にも役立つ「ユーザビリティテスト」をご紹介 first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第9回目のテーマは、「エクストリーム・プログラミング（XP）」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 価値・原則・プラクティス XPの話をする前に、価値・原則・プラクティスを解説します。スクラムやXPのように、世の中にはさまざまな開発手法がありますが、それぞれの手法には価値・原則・プラクティスが定義されてるケースが多いです。これらがどういった意味を持つのかを見ていきましょう。 まず、価値とは、「何を考え、何を行うのかを判断するのに使用する基準」です。開発手法が持つ価値観なので、開発手法が大切にしていることが価値としてまとめられています。この価値があることで、開発手法を利用する人は、「自分たちは、この開発手法の価値を満たしているだろうか？」と判断ができます。 価値はふんわりした言葉になるので、じゃ、どうやったらその価値を実現できるのか？がわかりにくいと思います。たとえば、アジャイルマニフェストの一例をあげると、「個人と対話を」という価値がありますが、これをどう実現すればいいか？ これだけではそこまでわかりません。 また、価値だけだと間違った判断になってしまう可能性があります。たとえば、アジャイルマニフェストだとコミュニケーションに価値を置いてますが、「コミュニケーションを重視したいから1000ページのドキュメントを書こう！」となると、ドキュメント作成に時間がかかりすぎて、アジャイルな開発とは言えません。そこで登場するのが原則です。 原則は、価値とプラクティスを支える橋のような存在です。原則は、「具体的な指針」なので、具体的に何をすればいいかわかりやすいものになっています。 アジャイルマニフェストの原則を見てみると「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というのもあります。この原則を守って、価値を実現していこうというものです。 先程の例にでてきた「1000ページのドキュメントを書こう！」の場合、「フェイス・トゥ・フェイスで話をする」や「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」という原則にマッチしません。マッチしないので、価値を満たさない可能性のあるアクションだと気がつけます。 プラクティスは、価値へと向かう原則をより具体的にしたものです。アジャイルプラクティスとも呼ばれます。プラクティスには「実行」、「練習」、「習慣」という意味があり、アジャイル開発だと「アジャイルになるための習慣」という表現がふさわしいかもしれません。アジャイルプラクティスをやればアジャイル開発になる！とはかぎりませんが、少なくとも価値へと続く橋のような存在になります エクストリーム・プログラミング XPの考案者のケント・ベックさんは、Javaエンジニアであれば誰もが知っているであろうテストフレームワーク「JUnit」を開発したひとりです。 XPは、価値・原則・プラクティスに分かれて解説されています。XPは、コミュニケーションやチーム運営だけでなく、具体的なエンジニアリングプラクティスが揃っているので、開発者の方であれば共感しやすい内容にもなっています。ただ、エクストリームとあるだけあり、極端なプラクティスも多く、ペアプログラミングなど、賛否両論を呼ぶプラクティスも多数あります。 XPを解説した書籍は、第1版が出た5年後に第2版が登場しました。第2版は内容も修正・追記されています。副題も変わっており、第1版では「ソフトウェア開発の究極の手法」だったのが「変化を受け入れる」になっています。ここでは、手元にあるエクストリーム・プログラミング第2版『 XPエクストリーム・プログラミング入門―変化を受け入れる 』を使って説明しています。 まずは、XPの価値を順に見ていきましょう。XPの価値は5つあります。 XPの価値 XPの価値： コミュニケーション ひとつ目の価値は「コミュニケーション」です。書籍では「もっとも重要」とされています。 XPの生みの親であるケント・ベックさんが、実際の仕事において、顧客とのやりとりがうまくいかず失敗するプロジェクトを多く見てきたため、コミュニケーションをもっとも重要視するようになったという逸話もあります。 XPに限らず、アジャイル開発全般において、チームの意識を高め、効率的な協力関係を生み出すためには、コミュニケーションは必須の価値とも言えます。 XPの価値：シンプルさ 2つ目は「シンプルさ」です。 シンプルさは、開発するシステムであったり、問題や課題の解決策であったり、さまざまなものに適用できる価値観です。私自身も、若手エンジニアを育成するときは、「140文字以内で報告をしてみよう」とか「これがもっともシンプルな方法だろうか？」といった話を意識してしています。 もちろん、複雑なシステムも必要でしょうが、開発活動も開発するシステムも、コミュニケーション方法も、できるだけシンプルな方が、よいシステムに近づけるように思います。 XPの価値： フィードバック 3つ目は「フィードバック」です。 完璧なシステムを開発するのはとても難しいことです。たとえ、完璧になったとしても、時間の流れや世の中の変化によって、それもすぐ不完全になってしまいます。 ただ、完璧を目指していく姿勢はとても大切です。自分の力だけで完璧になれればよいですが、フィードバックがあればよりはやく完璧に近づけるでしょう。十分な改善を行うためには、さまざまなところからやってくるフィードバックが重要になります。 また、アジャイル開発に取り組むのであれば、フィードバックに慣れておくのも必要だと思います。たとえば、コミュニケーションを重視するアジャイル開発では、フィードバックをもらうだけでなく、あなたからもフィードバックを与えるケースが多くなるはずです。よいフィードバックをする習慣を身に着けておくと良いでしょう。 そして、フィードバックにはポジティブなものもあれば、ネガティブなものもあります。ネガティブな場合でも、どうすればよくなるのか？ ポジティブに相手とコミュニケーションを取っていく必要があります。 ネガティブなフィードバックは、誰もがすぐに受け入れられるものではないでしょう。相手を気遣って本当のフィードバックを避けてしまう気持ちもわかります。 しかし、将来の宝になるかもしれないフィードバックが与えられない、受け取れない環境は健康的な環境とは言えません。ネガティブな内容であっても、チームで話せる、話し合える、そういうチームを目指してみてはどうかと思います。 XPの価値： 勇気 4つ目は「勇気」です。 フィードバックでも書きましたが、真実を伝える勇気、新しい解決策を探す勇気など、開発のなかで様々な勇気が求められます。ふりかえりでも勇気を持ったチャレンジを考えていきます。 アジャイル開発では、どんどん変化を受け入れていくため、勇気を持った対応がとても重要です。そうでなければ、新しいチャレンジができなかったり、できることだけやってしまったりして、その結果、改善が進まなくなり、「なんだかうまくいかない」となってしまうでしょう。 個人的には、やりなおせるものであればどんどんチャレンジしてほしいと思いますが、どれだけ心配であっても、作業全体の20％ぐらいはチャレンジを入れていかないと、現場が良くなっていく体感が得られにくいのではないかと思います。 XPの価値： 尊重 最後は「尊重」です。 書籍には、「これまでの4つの価値の背後にあるのが尊重」とあります。続けると「ソフトウェア開発で人間性と生産性を同時に改善するには、チームにおける個人の貢献が尊重されるべき」と書かれています。 アジャイル開発では、コミュニケーションを重視します。コミュニケーションはひとりではできないものです。相手に対する尊重であったり、敬意であったり、よいコミュニケーションに必要な価値は、アジャイル開発でなくとも持っておきたいものだと思います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 The post 第9回 エクストリーム・プログラミングとその価値 first appeared on Sqripts .

こんにちは、QAコンサルタントのツマミです。 唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。 お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当たるのは本当にすごいことだと思います。そんなJISのいずれかの制定に絡んでいればもっと学術的な話や裏話の一つもできたかもしれませんが、そこはあくまで利用者側のツマミ、JISの一つひとつを道に例えて、こんなことが(書いて)あったよ、こんなことを見つけたよといったことをお気楽な道行のごとく書き連ねて参りたいと思います。 さて、初めてのさんぽは JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 。ゆるゆると楽しんでまいりたいと思います。 どうぞ皆さま、ちょっとした気分転換としてこのJISさんぽにお気楽にお付き合いの程、よしなに願い奉ります。 今回のJIS JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 とは この規格はツマミがAGESTで担当している「UI/UX向上支援サービス」と深いかかわりがあります。表題にあるように、人とシステム（サービスであったり、プロダクトであったり）との間でのやりとり(インタラクション)がどうあればよいかについて、原則が具体的かつ豊富な事例を添えてまとめられています。 インタラクション(Interaction)：相互作用，相互の影響 Weblio英和辞典 なぜ、このJISを選んだのか 「新しくて」「例が豊富で」「カテゴリ分類が手ごろ」と三拍子揃っているので、ユーザビリティを評価する際に使いやすい点が「UIやUXを検討しよう」という方にとって役立つと思ったからです。 「新しい」本JISは改訂が2022年です。一つ前の版でも2008年改訂なので新しい見解が盛り込まれていることが期待できます。 「例が豊富」後で詳しく述べたいと思いますがなんと141もの例が示されています。 「カテゴリ分類が手ごろ」レーダーチャートにした時に形の違いが分かりやすい7カテゴリという所が買いだと思っています。 道行 まえがき、序文 まえがきは8行。前半で「一般社団法人人間工学会」と「一般財団法人日本規格協会」が原案を出したと記載されています。それとJIS Z 8520:2008からの改訂であること。後半4行で示されている「この規格が著作権法で保護対象になっている云々」は重要なことですがどのJISでも記載されているはずなので、実質前半の4行がこの規格の前書きといってよいですよね。 あっさりしたまえがきと本文における豊富な例との対比にちょっとグッと来てしまいます。 1章　適用範囲 「安全を重視するシステム、共同作業、人工知能などの一部の応用技術には適用しない」ものの、それ以外の全てのインタラクティブシステムに適用可能と書いてあることからも分かるとおり、かなり適用範囲の広い規格です。 また、対象（利用者）も要求仕様に関係するエンジニアやUI関係の設計者、評価者だけでなく使いやすい製品を調達しようとする購入担当者も使えるということが書いてあります。 確かに、インタラクティブシステムを使いやすくしようと思う方や、使いやすさを何らかの形で評価する方に使っていただきたい規格です。 2章　引用規格 「この規格には、引用規格は無い」と記載されています。つまりこの規格単独で利用することが出来るわけで、本文の豊富な例も相まってUI/UX教育に使いやすいのではないでしょうか。 3章　用語及び定義 ここでは11の用語が定義されています。ツマミが特に着目したのは3.8項で定義されている「ユーザ」についてUI/UX評価での解釈を明確にするために、3.8A「ユーザエンゲージメント」を追加し、より詳細に定義されている点（この定義を含めると12個の用語が定義されていることになります）。 「エンゲージメント」は英語では一般用語だそうですが、日本語だと「婚約」の意味がまだ強く、ここで定義されている「インタラクティブシステムがユーザとシステムとのインタラクションの継続を促し、動機付けるような機能及び情報を提供すること」という意味はしっくりこないような気がします。 ただ、この「ユーザエンゲージメント」の考え方が盛り込まれていることによって、この規格がUX(ユーザエクスペリエンス)の設計や評価にも使えるようになっているので、わざわざ用語として定義されているのはこの規格の良い点の一つだと思っています。 その他、「アクセシビリティ」「利用状況」「ユーザビリティ」「ユーザエクスペリエンス」「ユーザインタフェース」などUI/UX教育で押さえておきたい用語が定義されています。 4章　インタラクションの原則 概要に7つの原則が記載されているのですが、ここに”7”という数字を持ってくることに「規定自体を分かりやすくしよう」という心意気を感じてしまうのはツマミだけでしょうか。 ここには7つの原則について概要が記載されており、また原則に含まれる主な推奨事項が表になっていますが、やはり概要だけで理解するのは少々厳しい。是非、5章の「原則及び推奨事項」を読んでいただきたいところです。 この4章の一番の読みどころは「推奨事項を一つしか適用しない場合，原則を完全に満たしたことにはならない」と「設計推奨事項を分類することよりも，それらの意味を理解して利用することの方が重要」のどちらかなのではと思います。学ぶ立場で読むと後者の「理解して利用することの方が重要」に目が行きがちですし、もちろん大切な考え方です。しかしながら前者が意味するところの「一つ適用できたからと言って改善できた！とはならない」というUI/UX改善時の注意点は、肝に銘じておきたいところです。 また、4章には、JIS Z 8530 で示される「人間中心設計」との関係が記載されていますが、ツマミには規定していることが違うということだけ伝わってきて、もう少しかみ砕いて記述されていると嬉しかったなぁと思ってしまいます。要は使いやすいインタラクティブな製品やサービスとはどういったものか、どのような特徴を備えているのかを示しているのがこのJIS8520、他方JIS8530は使いやすいインタラクティブな製品やサービスを作る際の作り方やプロセスがどうあればよいのかを示しているのだと理解しました。 5章　原則及び推奨事項 この章では7つの原則についての説明が記されています。 パッと見ると文章量に圧倒されそうになりますが、7つの原則それぞれが「原則(節題)－原則の説明ー注記－補則/細則ー補則/細則の説明－事例」という構成になっていることを予め知っておくと、とても理解しやすく記載されていることが分かります。 そのまま引用すると著作権に触れてしまいますから、例えば5.1節をツマミが理解した範囲でかみ砕きますと、まず節題として「5.1 ユーザーが行うタスクへの適合性」が記載されています。 続いて、この原則の説明が述べられます。5.1節の場合、「手段と目的を取り違えないように、手段が凄くなくてもユーザーが目的を達成できることが重要です」といったようなことが書かれているわけです。 そして、この説明に対して注記が記載されています。「達成する目的自体もユーザーニーズに沿ったものでないと駄目ですよ」「手段も奇をてらったものではなく、何がしたいかの本質に沿った手段を選びましょう」といった原則の説明をきちんと理解するためのアドバイスが注記として記載されている訳です。文章が延々と続くとつい本文だけ拾い読みしてしまいたくなりますが、是非、注記も読み込んで欲しいですし、その価値があります。 更に、原則をもう少し具体的にした補則、細則的な項目が述べられ、続く各項でこれらの補則、細則について詳しい説明と例が示されます。例えば5.1節の場合、3項目が挙げられていますが、3つ目の項目では「ユーザーが入力したり決定したりしやすいように予め適切な設定をしておきましょう」というようなことが書かれている訳です。そしてこの項目を実現するための推奨事項が複数点挙げられ、更に推奨事項を理解しやすくするために実施例がほぼ全項目2点以上挙げられています。 このように7つの原則が複数の項目に詳細化され、各々に例が複数示されるため、全部で141点もの例が掲載されるに至るわけです。 しかも、この例が工夫されていて、異なったインタラクティブシステムや別手段による対応策について述べられているので異なる観点から原則について考えることができます。推奨事項を「～は実現できているか？」といった形でチェック項目にし、例のいずれかを自分たちのサービスや製品に当てはめた書き方にするだけでかなり使えるチェックリストが出来ると思われます。 附属書A(参考)　この規格の推奨事項を適用するためのチェックリスト 前項で「かなり使えるチェックリストが出来ると思われます」と書かせていただきましたが、なんと本JISにはすでに付録としてこのチェックリストがついています。それが「この規格の推奨事項を適用するためのチェックリスト」です。 このページをコピーするだけでチェックリストとして使えます。ただし、例は掲載されていません。ツマミとしては、例を是非ご自身のサービスや製品に適した事例に書き換えていただいてチェック項目に追加することをお勧めします。事例を考えることが自身の勉強にもなりますし、チェックリストを利用する方に対して適切な利用に関するハードルを下げる事にもつながります。 参考文献 本JISを策定するための参考文献となった33点の資料が並んでいます。もし、本JISに触れて更に色々と知りたいとなったならこれらの資料にも是非あたってみてください。 JIS Z 8530「人間工学－人とシステムとのインタラクション－インタラクティブシステムの人間中心設計」はいつかこのJISさんぽでも取り上げたいと考えております。 附属書JA(参考)　JISと対応国際規格との対比表 本JISとISO9241-110:2020との対比が一覧表となっています。大きく2点が追加となっていて、1点目は「ユーザーエンゲージメント」、定義が追加されています。 2点目は「自己記述性」、分かりづらいから「インタラクティブシステムの自己記述性」としたと書いてあるのですが、まだわかりづらいかもしれません。 インタラクティブシステム＝自己なんですよね。インタラクティブシステムが今どうなっているのか、期待する結果を得るためにはどうすればよいのか、といったことをインタラクティブシステム自身がユーザーに分かりやすく情報提供しているかといったことなのですが、「記述性」という言葉が案外難しい。自己記述性に関する問題に気づきやすいよう、指摘しやすいよう例を読み込んで言葉の意味を説明できるようにしておかないと今後手こずりそうな気がします。 以上がJIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」となります。 今日見つけた宝物： 「代替テキスト 」 このJISの4章に図が示されている ※1 のですが、この図について「代替テキスト ※2 」が記載されていました。 音読アプリを使えばどんな図が記載されているか分かるようになっている点はアクセシビリティに関する規定として「あらまほしきことなり（望ましい、理想的である）」と感じました。 JISは登録すれば無料で閲覧できるPDFファイルが提供されていますが、同様に音声ファイルも提供されています。代替テキストがあれば音声ファイル利用者も使い勝手が良いですよね。 ※1：参照文献の図1：ユーザーシステムインストラクションのための指針に関する主要な情報源の関係 ※2：代替テキスト　画像をテキストによって説明したもの 最後までお付き合いくださりありがとうございます。本日の道行きはいかがでしたでしょうか。次のさんぽはJIS Z 8522「人間工学－人とシステムとのインタラクション－情報提示の原則」を予定しております。次回またご一緒できることを楽しみにしております。 参照： JIS Z 8520 インタラクションの原則 The post JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 first appeared on Sqripts .

こんにちは。チュンです。 オンラインで開催されたソフトウェア品質シンポジウム2023の本会議に参加してきました。 複数の講演や発表を聴講しましたが、基調講演と当社社員が登壇した発表についてご紹介します。 参考までに、 昨年の参加レポート です。※参加レポート内のソフトウェア品質シンポジウム2022の公式サイトは、 こちら に変更されています ソフトウェア品質シンポジウムとは ソフトウェア品質シンポジウム とは、1981年から開催されている日本科学技術連盟主催の歴史あるシンポジウムです。 今年で42回目を迎え、本会議前日の9/6に（今回は9/2(土)も）併設チュートリアルが開催され、本会議が9/7〜9/8の2日間で行われました。本会議1日目の終了後には、本会議Special Talk Session (STS)も行われました。 本会議レポート 基調講演について 今回の基調講演は 狩野 紀昭先生の「Kano Modelから品質について学ぶ！」でした。 狩野先生の講演を直接聴講できる貴重な機会です。 品質の概念として学習したことはありましたが、聴講前におさらいをと思い、ChatGPTで「狩野モデル」で確認してみたところ、ほしい回答が得られず…。 「Kano Model」で確認してみると難なく回答が得られました。まさに世界的な「Kano Model」であることを実感した次第です。 「Kano Model」の誕生 「Kano Model」の誕生について、狩野先生のこどもの頃の品質の思い出から始まり、「魅力的品質と当り前品質」の論文が学会誌に掲載されたところまでを語ってくださいました。 研究のきっかけとなったのは、 こども時代からの期待である「すぐに壊れる玩具を作らない」（よい品質とは壊れにくいものという期待をもって育った） 「品質不良の低減」 これらが、学生時代に学んだ「消費者を満足させるという品質」と同じであるということにギャップがあった、というところからだそうです。 「消費者を満足させるという品質」は、品質不良を低減するなどというだけでは十分ではなく、『「不満をもたらす品質」と「満足を与える品質」は異なる』という漠然とした考えから始まったとのことでした。 その後、ハーズバーグの動機付け・衛生理論に出会い、疑問を解明できるかもしれない、ということから研究を進めて論文を提出したそうです。 …が、品質管理分野以外の文献調査が不足しているとの理由で却下されたことがあるとのこと。 他の分野には明るくなかったようですが、研究室でアルバイトをしていた方から哲学者のアリストテレスにたどりつき、最終的に論文が認められるに至ったとのことでした。 そのアリストテレスが「形而上学」で主張していた質についての内容から、「品質とは、ある事物に関して２つの品種が存在する時、それらの種差を指す」ということを、アリストテレスの品質論として説明してくださいました。 魅力品質のライフサイクル Kano Modelの特徴として、品質要素を二次元で図式化していることがあげられます。 各品質要素を図解すると以下のようになります。 一元品質：ないと不満、あれば満足なもの 当り前品質：ないと不満、あっても満足とならないもの 魅力品質：なくても不満にはならないが、あると満足なもの 無関心品質：あってもなくても不満にも満足にもならない。関心がないもの 魅力品質理論図解 この魅力品質理論ですが、多くは「無関心品質」として生まれてそのまま終わってしまうことが多いようです。 ただ、その「無関心品質」の一部は「魅力品質」となり、さらにその「魅力品質」が「一元品質」に、いずれはそれが「当り前品質」になる、というようなライフサイクルがあります。 この魅力品質のライフサイクルについて、狩野先生が大学で講義していた時代に、他の品質関連に関する内容と比較すると学生の理解力に問題があったそうです。 狩野先生は学生が理解できないのは教える側が悪い、として、どうやったら理解が深まるのかについて、「MaryとJohnの恋の物語」として二人の恋の変化に例えて解説するようにしたところ、学生の理解力が大幅に上がったとのことでした。 それまでとは異なる雰囲気の資料で驚きましたが、確かにこれならわかりやすい、と感じました。 余談ですが、自分も教える側になることがあります。 なかなか理解してもらえない、と思うこともありますが、教える側が悪い！と断言された狩野先生のことばにグサッときました。 教える側として改善しなければいけないですね。 競合優位としての品質の歴史的変化 競合優位としての品質は歴史的に変化しているという、品質の3レベルについてのお話もありました。 第1レベル：品質統制（顧客苦情解消、製品の基本的要件への適合） 第2レベル：品質管理（顧客満足、顧客の明示要求の実現） 第3レベル：魅力品質創造（顧客歓喜、顧客の潜在要求の実現） 第2レベルが出てくると第1レベルは当たり前になる、というように、品質競争は変化するというお話でした。 品質は第1レベルから第2レベルへ発展し、さらには第3レベルとなるように発展してきたとのことです。 これらの話の中で、突如「BFの3レベル論」という資料が提示されたのですが、BFって？と思っていたら、「BoyFriend」のことでした。 品質3レベル論をいろいろな3レベルに例えるようにレポートを書かせた際、学生が考えた場合の例として提示されていたものです。 このようにくすっと笑ってしまうような内容が講演中のところどころに含まれており、狩野先生の人柄が垣間見えたようでした。 まとめ（業務における「品質」を考えてみた） ご紹介しきれていない内容もありますが、基調講演では全体的にハードウェアを前提としてお話しされていました。 基調講演後には「ソフトウェア、サービスにおける魅力的品質とは？」というパネルディスカッションもあったのですが（こちらはSNS禁止のため割愛）、ソフトウェアやサービスにも大きく関連する内容です。 別の一般発表や講演で、狩野先生のお話を引き合いに出されている方も複数いらっしゃいました。 論文発表当初から時間は経過していますが、現時点でも色褪せずマーケティングの場でも活用されていることなどを考えると、狩野先生から直接お話を聴けたことは本当に貴重でした。 自分自身は、テスト業務を担当しています。 お客様が開発した製品に対するテストの依頼を受け、テストを担当することが多いです。 品質管理として「品質不良の低減」のための業務であり、「不満をもたらす品質」にあたるものだと考えます。 そのため、今回のお話のメインである「魅力品質」を意識して業務することはほとんどありませんでした。 今回のお話を聴いて、少し視点を変えてみました。 そもそも、お客様から依頼されている「ソフトウェアテスト業務」そのものの品質を考えてみると、お客様からの期待や要望という意味では、この「魅力品質」に関連するのではないかと。 お客様から依頼されたテスト業務そのものに対して、最低限の成果を出すということは「当り前品質」であり、期待に対して成果を出すことが「一元品質」にあたるのかなと思いました。 お客様との会話の中から潜在的な要求を読み解くことができ、それらに対応することができれば、それは「魅力品質」になるのではないのかと。 長期間担当する場合には、ライフサイクルとして変化することもありそうです。 業務に対する姿勢として、「当り前品質」をこなすことはもちろんですが、一元品質や魅力品質にも対応できるようになるため、日々精進していく必要があると感じました。 ※注：本文内の表記について、論文名やパネルディスカッションの名称は「魅力的品質」、その他は講演中の資料に提示されていた「魅力品質」としています。 林 尚平さんの発表について 本会議2日目には、当社社員の林 尚平さんによる経験発表がありました。 発表のテーマは、 IoT技術を用いた組込み系製品のラズベリーパイを使用した自動化の問題点と解決方法 です。 林さんは本Sqriptsにおいてスクリプターとしても 記事 を執筆しており、テスト自動化エンジニアとして活躍しています。 こちらの特集もおすすめ！ ■ 【連載】自動テストはなぜ失敗するのか。失敗事例からひも解く成功への道筋 Sqripter：林 尚平 問題点 IoT組込み系製品のテストを自動化するためには、自動化ツールを製品やサーバ、シミュレータといった機器と連携させる必要がありますが、ラズベリーパイを用いて自動テスト環境を構築したとのことでした。 テスト自動化の導入にあたって選定した自動化ツールでは、前提条件の設定やテスト実行結果の確認ができないことが判明したようですが、他の自動化ツールでは代用できないことを自動化できるといったメリットがあったことから、その自動化ツールを用いた環境構築ができないかを検討し、「AutoIt」と連携させることで不足する機能追加の対策をしたそうです。 これにより、自動テストの導入としては成功できたようなのですが、その後の運用フェーズでエラーが多発してしまったとのこと。 エラーの要因としては、テスト対象が数十機種にもおよんでいたこと、ツールを２つ連携させたことにより環境構築が複雑になってしまい、ヒューマンエラーが発生してしまったことなどが挙げられていました。 解決方法 解決のために着目したこととして、できるだけシンプルなテスト自動化環境を構築することが望ましいとのことで、自動化ツールの選定について検討し、AGESTのプロダクトである TestArchitect を利用する方法を紹介しています。 TestArchitectであれば、ハーネス機能によりラズベリーパイを制御する機能を取り込んで使用することができるため、環境構築をシンプルにすることが可能となります。 まとめ 自動化ツールの選定については、プロジェクトの状況などにもよると思いますが、導入だけではなく、運用まで見据えることも重要な要素であると改めて感じました。 TestArchitectは、デスクトップやWebアプリケーションをはじめ、モバイルにも対応しており、幅広いシステムの自動化が可能なツールです。 現在はこれらのシステムに利用されているケースが大半ですが、林さんの発表のとおり、ハーネス機能を用いることで組込み系製品の制御が技術的に可能であることが判明しました。 TestArchitectが組込み系製品の自動化ツールとして利用できることは、まだまだ知られておりません。 本記事をご覧いただいた方で気になった方がいらっしゃいましたら、ぜひお問い合わせください。 お問い合わせ先 さいごに ご紹介した内容以外にもたくさんの講演や発表がありました。 基調講演や特別講演はもちろんですが、一般発表として多くの品質に対する考え方などを聴講することで、「基本の本質を学び、 見つめなおす場をご提供します」という開催概要にもあるように、日々の業務を見つめなおす学びの場となりました。 同時間帯に聴講したい内容が重なっていたこともあり、悩ましくもありましたが、アンケートに回答してアーカイブ視聴特典をいただいたので、アーカイブでさらに学びたいと思います。 The post 狩野モデル（Kano Model）から考えるテストエンジニアの”品質”　～ソフトウェア品質シンポジウム2023参加レポート～ first appeared on Sqripts .

はじめに 前回は、自動販売機を題材にして、BDDを用いたプロセスの「発見(Discovery)」の部分（2.要件ワークショップ）までを説明しました。 今回は、「3. 定式化(Formulation)」の部分を、BRIEFの原則を交えつつ説明します。 3. 定式化 定式化では、システムの振る舞いの例（実例マッピングでいう具体例の部分）をシナリオの形で文書化します。 例えば、以下のような実例マッピングができた時に、書かれてある具体例「550円を入れて120円のコーラを選ぶとコーラと430円のお釣りが出る」をシナリオの形で文書化します。 例えば、Gherkin記法を用いて以下のように書けます。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる And コンボボックスから 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる Gherkin記法 Gherkin記法とはGiven/When/Thenなどのいくつかのキーワードを用いて、実行可能な形式で記述する構文方法です。 今回は、以下の6つのキーワードが登場します。 Feature…ソフトウェアのフィーチャーの概要を記述するためのキーワードです。 Scenario…ビジネスルールを表す具体例を記述するためのキーワードです。 Given…システムの初期段階やシナリオの前提を記述するためのキーワードです。 When…実際に行うアクションや操作を記述するためのキーワードです。 Then…期待される結果を記述するためのキーワードです。 And…複数のGiven/When/Thenに値する内容が出てきた時には、この「And」のキーワードで繋げます。 例えば今回書いた内容の場合、以下のような内容を説明していることになります。 自動販売機についてのフィーチャーです。 「飲み物を買うとお釣りが出る」という具体例について記述します。 「自動販売機がある」という前提があります。 以下の操作を行います。 「500 円硬貨を入れます」 「50 円硬貨を入れます」 「コンボボックスから120 円のコーラを選びます」 すると、以下の結果が期待されます。 「コーラが出てきます」 「100 円硬貨が 4 枚出てきます」 「10 円硬貨が 3 枚出てきます」 シナリオを改善する さて、今回Gherkin記法で書いたような以下のシナリオがあれば全て大丈夫なのでしょうか。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる     And コンボボックスから 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる このままでも実行可能なテストを作成していくことが可能ですが、もう少しシナリオの改善を考えることができます。 自分一人で考えても良いですが、他の人からフィードバックを得ながら進めるとなお良いでしょう。BDDを用いたプロセスの「#4. レビュー」の部分に該当します。 シナリオを改善する時の参考になるのが、BRIEFの原則です。 BRIEFの原則 BRIEFの原則とは、シナリオをより良くするために考えられた経験則です。それぞれの頭文字5つとBriefという言葉自体の計6つからなります。以下の説明は、「 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 （原文は Keep your scenarios BRIEF ）」から引用。 Business language（ビジネス言語）…ビジネスチームのメンバーが明確に理解できる用語を使用すべきです。 Real data（実際のデータ）…具体的な実際のデータを使用すべきです。 Intention revealing（意図を明らかにする）…シナリオのアクターが達成しようとしている意図を明らかにすべきです。達成する方法のメカニズムを説明するのではありません。 Essential（必須）…シナリオの目的は、ルールがどのように振る舞うかを説明することです。 この目的に直接関与しない部分は偶発的なものであり、削除すべきです。 Focused（焦点を絞る）…ほとんどのシナリオは、1つのルールの説明に焦点を絞るべきです。 Brief（簡潔である）…ほとんどのシナリオを5行以下に制限することをお勧めします。 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 今回のシナリオにBRIEFの原則を適用して改善する それではBRIEFの原則に当てはめて今回のシナリオを改善していきましょう。 ビジネス言語を用いる(Business language) 今回のシナリオの中で「コンボボックス」という単語は、実際の画面を想定して表現しており、ビジネス言語ではありません。また、コンボボックスでなくチェックボックスなどであっても今回行いたい内容を満たすことができます。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる      And コンボボックスから 120 円の "コーラ" を選択する      And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる 意図を明らかにして(Intention revealing)、必須(Essential)の目的のみに焦点を絞って(Focused)記述する 今回のシナリオで示したい目的は、「飲み物を買うと飲み物の値段を引いた金額だけお釣りが出る」ということです。重要なのは金額であり、どんな硬貨が出てくるかは今回のシナリオの意図ではありません。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる When 550 円を入れる And 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる And 430 円が出てくる なお、どんな硬貨が出てくるかを示したい場合は、別のシナリオとして記述を検討すべきでしょう。おそらく、「発見(Discovery)」に立ち戻って、実例マッピングでいう具体例（緑色の付箋）やルール（青色の付箋）を追加することになると思います。 結果として簡潔(Brief)なシナリオになっている 改善した結果、以下のようなシナリオになりました。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる これを見ると、シナリオ自体は5行に収まっており、簡潔になっています。 「BRIEFの原則は必ず全て守るべき」ではない BRIEFの原則は必ずしも全て適用すべきではありません。 例えば今回の場合、シナリオで示したい目的は「飲み物を買う」ということなので、必須(Essential)の原則に従うと「コーラ」を指定する必要がありません。一方で、実際のデータ(Real data)の原則に従うと、「コーラ」という具体的なデータを用いた方が良いと思われます。 このように、原則の一部は排反する可能性があるので、その場に適した内容を適宜考えてください。 おわりに　〜BDD以外でもBRIEFの原則を活用する〜 今回は「3. 定式化(Formulation)」のプラクティスとして、Gherkin記法のシナリオをBRIEFの原則に従って改善していきました。 なお、BRIEFの原則はBDDの場面以外での活用も考えると良いでしょう。例えば、TDDやUnitテストの作成時には、色々なことが気になりすぎた結果、テストの意図(Intention revealing)が明らかになっていないことが多々あります。 ぜひ、そのような場面でもBRIEFの原則を活用してみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 The post TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 first appeared on Sqripts .

こんにちは、QAエンジニアのカンパチロックです。 今回は、マイクロサービスアーキテクチャにおける通信の品質保証としてCDCテストと、その実行において規模や多機能性に応じて一般的に使用されるツールである Pact の使用についてのワークショップを紹介します。このワークショップを通じて、CDCテストとPactの基本的な使い方や有用性を紹介できればと思います。 マイクロサービスとCDCテスト マイクロサービスアーキテクチャは、開発の効率化、デプロイメントの簡易化、そしてスケーリングの容易さをうたった誘惑的な選択ですが、サービス間の適切な通信はシステム全体のスムーズな運用に不可欠です。その中心に位置するのが、Consumer Driven Contract (CDC) テストです。 CDCテストは、各サービスが他のサービスとの通信契約を順守しているかを確認し、システム全体の信頼性と安定性を向上させる有効な手段です。そして、CDCテストを容易に実施できるツールとして、Pactが広く活用されています。 この記事では、Pact Workshop JSを用いてCDCテストを行うための知識と具体的な事例についてご案内します。深く理解や体験を通じて、マイクロサービスアーキテクチャを検討する開発者さんたちの視野を広げ、より豊かな選択肢を提供できればと考えています。 CDCテストの基本 Consumer Driven Contract (CDC)  テストは、マイクロサービス間の相互通信をテストするための方法論です。このテストでは、各サービス（ここでは”コンシューマー”）が他のサービス（”プロバイダー”）との間で期待する通信の動きや振る舞い、すなわち”契約”を定義します。この手法の目的は、サービス間の通信が予期された方法（つまり契約に従って）で行われることを保証することです。 CDCテストの一般的なフローは以下の通りです。 契約の定義 ：すべては、コンシューマーがプロバイダーに期待する振る舞いを正確に規定する契約の定義から始まります。この契約は、具体的には特定のリクエストに対する期待されるレスポンスを示す仕様となるべきです。この手間をかける理由は、明確な契約によりコンシューマーとプロバイダーの間の誤解や食い違いを最小化し、次の段階であるテストの成功率を高めるためです。 コンシューマーによるテスト ：次に、コンシューマーは上記の契約を基にしてテストケースを作成し、実行します。このステップでは、期待したレスポンスがプロバイダーから正確に返すことができるか、システムの限界をテストすることが目的です。この結果により、コンシューマーは契約が正しく機能することを確認でき、信頼性の高いコードをプロバイダーサイドに提供できます。 契約の共有 ：テストが無事合格した後、コンシューマーは契約をプロバイダーと共有します。このステップは、双方向のコミュニケーションと協調を促進し、広範で一貫性のある結果を生むために不可欠です。 プロバイダーによるテスト ：最後に、プロバイダーは受け取った契約に基づいて、自身のテストケースを作成し実行します。このステップでは、プロバイダーが契約仕様を適切に遵守していることを確認します。これにより、双方のマイクロサービス間の信頼性が高まり、安全なプロダクション環境への適用が可能となります。 Pactの特性 CDCテストの基本を理解したところで、次に紹介するのは、CDCテストを実施するための強力なツール、Pact( https://docs.pact.io/ )です。 Pactは、CDCテストを効果的に実施するためのオープンソースのフレームワークです。主に、コンシューマーとプロバイダー間の契約を定義し、その契約が適切に遵守されていることを確認するためのテストを作成、実行、検証する作業を容易にします。 出典： https://docs.pact.io/ Pactのもう1つの大きな利点は、言語に依存しないことです。これにより、異なる技術スタックを持つマイクロサービス間でも使用することができます。さらに、視覚的に理解できるテスト結果を提供し、契約違反が発生した場合にはその詳細を明示します。これにより、開発者は問題を素早く特定し、その修正に努めることができます。 しかしながら、この章ではPactの全機能について詳しく説明するのではなく、PactがCDCテストをどのようにサポートするか、そしてそれがなぜ重要なのかに焦点を当てたいと思います。Pactの詳細な機能や使用方法については、 公式ドキュメンテーション をご覧ください。 ワークショップ紹介 これまでに、CDCテストとPactについて説明してきましたが、まだ、これらの概念が抽象的に感じるかもしれません。そこで、このセクションからは具体的な実践体験を通して、Pactの使用方法とCDCテストのメリットをわかりやすく説明します。 Pact Workshop JSは、CDCテストの実践的な運用を体験できるワークショップです。ここでは、Pactを使用したマイクロサービス間の契約の定義方法とそのテスト方法を体験できます。このワークショップは、現場で直接応用することができる知識とスキルを得るためのネタ足しとなります。さらに、約60分で完了できるよう設計されています。 ワークショップのレポジトリは以下からアクセスできます。 https://github.com/pact-foundation/pact-workshop-js このハンズオンワークショップは、Pactを使ってCDCテストを体験する機会となります。 CDCテストを正確に理解し、適切に設定することでマイクロサービスの信頼性を向上させることができます。この機会をぜひ活用して、CDCテストの実践的な運用を体験してみてください。 準備手順 ワークショップの為の準備は、Pact Workshop JS公式ののgithubに記載されておりますが、以下のソフトウェアのインストールが必要となりますので、事前にインストールして下さい。 Docker Docker Compose Node + NPM ソフトウェアを全てインストールしたら、次に下記のコマンドを実行し、ワークショップのリポジトリをcloneしてください。 git clone <https://github.com/pact-foundation/pact-workshop-js.git> 以上がワークショップの準備手順になります。これで準備は完了です！ 学習内容 Pact Workshop JSは、Pactを使用したConsumer Driven Contract (CDC) テストの具体的な手順と例を学ぶためのワークショップです。このワークショップは11のステップで構成されていますが、それらは以下の4つの主要なフェーズに分かれています。 ステップ1 – 5: Pactの利用の基本 ：このフェーズでは、コンシューマとプロバイダの間で通信の契約を定義し、それに基づいてテストを作成、実行、検証します。これにより、Pactを利用したCDCテストの基本的な流れを理解します。また、コンシューマとプロバイダ間の通信契約がしっかりと担保されることを確認します。 ステップの実施内容としては、コンシューマ側のエンドポイント名の誤認識により結合テストが失敗する状態をスタートとして、PactによるCDCテストにより問題の検知・解消を行うところまでが含まれていますので、CDCテストの有益性を確認する上では十分な内容と思います。 ステップ6 – 7: データ状態(stateHandlers)を利用したテスト ：次のフェーズでは、プロバイダ側に格納されているデータの状態に応じたテストを行います。これにより、データ状態と応答データの関係性の検証をPactで行う方法を学びます。具体的には、対象のIDの商品が存在しないケースや、商品が全くない場合のケースについての実装を行います。 APIのエンドポイント、リクエスト、レスポンスの形式などは、IDL(Interface Definition Language)を利用することで静的な検証を行うことが可能ですが、データの状態に基づくレスポンス内容は動的な性質を持つため、テストでの検証が必要となります。PactではstateHandlersの機能を利用することで、これらの動的なレスポンスを効率的にテストすることが可能となります。 ステップ8 – 10: 動的なデータについてのテスト ：この段階では、動的なデータ（例えば、認証トークンなど）についてのテストを行います。この段階では、動的なデータを扱うテストケースでPactをどのように利用するかに焦点を当てます。具体的には、APIの認証機能としてタイムスタンプを含むトークンの組み込みをユースケースとして考えます。ここでは、このような問題を解決するためにPactをどのように活用するかを学びます。 ユニットテストで期待値を検証する際、日付情報や一時的な認証トークンのような動的なデータの取り扱いは常に課題となります。PactではRequestFilterという機能を使ってこれらの動的な要素に対応したテストを実装することが可能です。これにより、テストの信頼性と精度が大幅に向上し、問題解決の手間を削減できます。 ステップ11: Pact Brokerを利用した効率的なPactファイルの管理 ：最後のフェーズでは、Pact Brokerを導入し、Pactファイルの管理を効率化します。Pact Brokerは、Pactファイルのバージョン管理、共有、検証結果の追跡などを行うことができ、複数のサービスやチーム間での契約テストを容易にします。さらに、Pact BrokerはCDCテストの結果を一元的に管理し、それを基に自動的にデプロイを許可するか判断するなど、CI/CDパイプラインとの統合を強力にサポートします。これにより、CDCテストの結果を直接CI/CDプロセスに反映させることが可能となり、開発プロセス全体の効率化に寄与します。 ワークショップでは、Pactのテストが意図的に失敗する状況も設けています。それらを「なぜテストが失敗するのか？」を自己学習の一環として理解することが求められます。 このように、各ステップを順次進めながら、Pactの使用方法とその有益性を深く理解することが、このワークショップの主な目的です。 体験と洞察 ワークショップを終えてみて感じたのは、CDCテストの全体的なフローを理解し体験することができ、さらにはPactを使用して契約を定義し、テストを作成、実行、検証する方法を学ぶことが非常に有益だったということです。 このワークショップの最終段階でPact Brokerの組み込みを行ったことにより、「最後にいつCDCテストが行われたか？」や「どのバージョンのプロバイダと接続を確認したか？」といった情報をWeb上で簡単に確認できるようになったのも大きな収穫でした。 また、ワークショップで学んだことは基本的な例にすぎません。実環境のCDCテストは、さらに多くのシナリオをカバーできると思います。特に、マイクロサービス環境では、CDCテストによって実現されるサービス間のネットワークグラフは、各サービスの接続状況を一覧表示することに非常に役立ちます。 その為、このワークショップが期待以上に価値ある体験であったと感じています。 出典： https://github.com/pact-foundation/pact_broker#network-diagram 最後に 今回は、 Consumer Driven Contract (CDC) テスト と Pact に関するワークショップについてご紹介いたしました。これらの知識とツールが、あなたの開発プロセスを更に丁寧で、効率的なものに進化させ、より高品質なソフトウェア作りに貢献することを心から願っています。 このワークショップを通じて、新たなスキルを獲得し、自身の技術スタックを拡張するための第一歩となることを期待しています。どうぞ、この機会にワークショップを試してみてください。 The post CDCテストに触れてみよう。Pact JS workshopを利用したCDCテストの実体験 first appeared on Sqripts .

前回の記事（ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 ）では、テスト自動化のために既存のテストケースを整理・加工する際のポイントについて説明しました。 今回はテスト自動化を前提としてテスト設計（およびそれに伴うテスト計画やテスト分析の見直しなど）を行う際の方法について考えます。 これまでの連載記事とは異なり、「こうするとよい」「こうしましょう」といった、わたしの経験や一般の知見に基づくノウハウの共有という意味合いは少なくなっています。 むしろ、「わたしはこう考えて、こんなことをやっている。世の中ではこんなことが言われている。みなさんはどうですか？」といった、半分は読み手の皆さまへの問いかけとして本記事を書いています。 これをきっかけに、テスト自動化を前提としたテスト設計について情報の流量が増え、議論が活発になればうれしいです。 テスト自動化とテストプロセスとの関連についてあらためて整理 テストエンジニアやQAエンジニアの間でも、テスト自動化を業務で行っている方や経験がある方が増えているようです。 ソフトウェアテスト自動化カンファレンス2022アンケート結果サマリー より テスト自動化研究会が行ったアンケート結果の毎年の推移をみると、テスト自動化の経験がない方は少しずつですが下がっています。 しかし、テスト自動化が普及している一方で、テストエンジニアが普段の業務で扱っている「テストプロセス」と、「システムテストの自動化」とを完全に別のものとして考えてしまっている場合があるように思います。 上の図に近い形の方法が、 前回の記事 でご紹介したやり方です。 ただ、これも前回の記事で何度か触れたように、このやり方で進める場合はデメリットもいくつか考えられます。たとえば自動化をする際の手戻りが多くなるリスクがありますし、暗に「手動実行の効率化・工数削減」という視点で考えてしまいがちでもあります。 本記事でお伝えしたいことのひとつは、先の図における「手動テストの世界」と「自動テストの世界」は別々のものではなく、下図のように同じプロセスで検討されるべきものである、という点です。 テスト設計の先が2つに分岐していますが、実際には先の図で「手動テストの世界」として表現したテストプロセスと、そのアウトプットやフェーズには大きな違いがありません。 つまり、テストプロセスのアウトプットをあとから自動化向けに加工するのではなく、テスト自動化を考慮してテストプロセスに沿って進み、手動・自動それぞれのアウトプットを作成するほうが効果的ということです。 手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い 手動実行が前提のテスト設計、つまりテスト手順をあとから自動化するパターンの場合と、自動化を考慮したテスト設計とでは何が異なるのでしょうか？テスト分析やテスト設計の段階で自動化について考えておくと、どんなメリットがあるのでしょうか？ ひとつは、 前編 で触れた – 手順や期待結果の具体化 – 順序や依存関係の整理 などが後追いではなく最初から行えるという点です。 他にも、以下のような違いが考えられます。 テストの範囲が広がる・網羅度合いが高まる 手動実行を前提としてテスト設計を行うと、プロジェクトの現実的なリソースでできる範囲でテストケースを作成する場合があると思います。 自動実行によって効率的に実行できるのであれば、本来やりたかった範囲をすべてテストする、網羅度合いを高めるといった選択ができるかもしれません。手動実行時に比べてテストケースの量を増やすことができる、とも言えます。 もちろん、テストは多ければ多いほど良いわけではありません。しかし、手動実行ではリソース等の制約があってできなかった範囲・量のテストが実行できる可能性が生まれる点は、メリットと考えられます。 実行頻度・フィードバックサイクルを増やせる テストの範囲や網羅度合いに加えて、実行頻度やフィードバックサイクルを増やせる、というメリットがあります。 手動でシステムテストを実行する場合、たとえば「システムテストフェーズ」として一定の期間を設け、この期間内にシステムテストをすべて完了させるというやり方があります。その場合、テストケースもシステムテストフェーズで1回ずつ実行される前提で作成します。 しかし、自動実行を考慮してテスト設計を行うことで、「システムテストフェーズで行うテスト」というひとかたまりのテスト設計ではなく、より段階を分けて考えることができます。リグレッションテストに相当するテストをCIパイプラインに組み込んだり、もしくはステージング環境で毎晩実行したりと、テストの目的や内容に応じて実行タイミングや頻度を分け、増やすことができます。 自動化を考慮したテスト設計のポイント これらのメリットを得るために、テスト分析やテスト設計の段階から自動化を考慮しておくことが大切です。 自動化を考慮してテスト設計を行う際のポイントは前述の「手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い」がほぼそのまま該当します。 ただ、ここまでに出てきていない注意点としては – 自動化によって抜けがちな観点に注意しましょう ということをお伝えしておきます。 手動実行向けのテストを自動化する際にも同様の注意が必要になりますが、テストを自動実行することによる実行効率UPと引き換えに、手動実行時に人間が暗に確認しているさまざまな観点が抜け落ちることになります。 単純な例で考えると、たとえばテスト設計時に「ログイン処理は簡単に自動化できるから、自動実行するテストとして設計しよう」と考えたとします。そうするとログインに関するテストは自動実行でカバーできているからOK！と思いがちですが、ログイン処理における画面表示の問題などは単純な自動テストスクリプトでは見逃されてしまいます。 こうした、自動実行するテストでカバーできていない範囲・観点があるにもかかわらず、機能や画面としては自動テストで見ている、という場合は必要な観点が見逃されがちです。 まとめ 今回はテストプロセス、とくにテスト設計時にテスト自動化を考慮して行う際の考え方等について説明しました。 こうした、テストプロセス中のどのタイミングで、自動化に関するどんなことを考慮するかについてはまだまだ議論や改善の余地があると考えています。 わたしも普段の業務における自動化向けのテストケース設計のやり方はいろいろと模索中で、 過去のテスト設計コンテスト決勝進出チームの成果物 なども繰り返し参照しながらよりよい形を考えています。 本記事がなんらかのヒントになればもちろんうれしいですが、それ以上に「もっとこう考えるべきでは」などいろいろな意見をいただけると、よりありがたいです。 参考 – 自動テストを活躍させるための基礎作りとテスト設計の工夫 – Speaker Deck – テスト設計チュートリアル U-30版 資料 2019 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 The post テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 first appeared on Sqripts .

JSTQB FL の取得に向けて学習中のみなさん。初めまして、Yoです。 シラバスの読み込みは順調ですか？各項目をしっかり理解できていますか？ JSTQBの学習において、シラバスの熟読は避けて通れません。しかしながら、シラバスは言い回しが少々難解であったり、耳慣れない用語が多かったりとなかなかとっつきにくいものです。私もFL学習の初期には全然理解が追い付かずに苦労しました。 本記事では、シラバスを理解する上で私が個人的につまづいた箇所をかみ砕いて解説していこうと思います。 今回はプロダクトリスクとプロジェクトリスクについて解説します。 シラバスにおいて プロダクトリスクとプロジェクトリスクについて、JSTQB FLシラバスでは以下のように解説されています。 ※少々長いので、箇条書きにされている具体例は割愛します。 プロダクトリスクについて プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。プロダクトの特定の品質特性（例えば、機能適合性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連するプロダクトリスクは、品質リスクとも呼ばれる。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 プロジェクトリスクについて プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 英語の意味を考える シラバスの引用だけではまだ表現が固くて取っつきにくいので、英語の意味を考えていきましょう。 プロダクトは「製品」、プロジェクトは「事業、計画」といった意味の言葉です。つまり、プロダクトリスクは「製品に対するリスク」プロジェクトリスクは「計画に対するリスク」と言い換えることができます。 ※プロジェクトの和訳として、ここでは計画の方を採用しました。 もっと簡単に表現してみる 英語で意味を噛み砕いてみると、それぞれのリスクがどういったものか、多少はイメージしやすくなったのではと思います。更に、それぞれのリスクを「製品」「計画」というキーワードに着目して言い換えてみましょう。 プロダクトリスク = 製品の利用者に害があるリスク、製品の提供者に不都合があるリスク プロジェクトリスク = 計画通りに進まないリスク、計画そのものが抱えるリスク こうして両リスクを言い換えてみると、冒頭で引用したシラバスの記述が理解できるかと思います。 シラバスの例を具体的に考えてみる 言葉の意味の解説が済んだところで、ここでは両リスクが具体的にどういう物かを考えてみます。 先ほどのシラバス引用では割愛しましたが、シラバスには具体例が箇条書きで記載されているので、それらを見てみましょう。 プロダクトリスクの例 プロダクトリスクの例について、シラバスに以下のような記載があります。 特定の計算結果が状況によって正しくないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 これがプロダクトリスクである、と答えありきで言われると、確かにそうかもなと思うかもしれませんが。ヒントなしで何のリスクであるかと答えるためには、両リスクがどの様なものであるかをしっかり理解していることと、例からどの様な事象に発展してしまうのかを想像することが大切です。 この例では、計算の結果が正しくないということですので、以下のような事象に発展する可能性があります。 ショップの購入者への請求額の誤り 在庫数の表示と実態の不整合 これらのようなことが実際に起こってしまうと、利用者は金銭的な損害を被りますし、サービス提供者は機会の損失が発生する可能性があります。これらは「製品」の機能不備によって引き起こされたものであるため、プロダクトリスクになります。 プロジェクトリスクの例 プロジェクトリスクの例としては、以下のような記載があります。 テスト環境が予定した期限までに用意できないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 経験がある方もいらっしゃるのではないでしょうか。予定通りに環境が出来上がらない場合、どういった事態が考えられるでしょうか。すぐ思いつくのは、 テストが遅延する などでしょう。更に言うと、リリース判定、申請、リリース等が後ろにずれてゆき、当初計画していたスケジュール通りに開発が完了しないということが起こりえます。そうなると当然。 開発コストの高騰 等も発生しえます。これらは「計画」に影響を与えるリスクであるため、プロジェクトリスクだと判断できます。 上記の例のように、「どこで」「どの様に」悪影響があるのかを具体的に考えることで両リスクの判断が可能になります。 例題 ここまでで両リスクの説明と、具体例からの判別について一通りの解説ができたので、応用として簡単な例題を解いてみましょう。 以下のうち、プロダクトリスクはどれか A：ループ制御構造が正しくコーディングされていない B：人員のスキルやトレーニング不足 C：ツールによる支援が遅れる D：欠陥や他の技術的負債が累積する それぞれに対し、リスクが何に影響を与えるかと、どの様な問題が発生するかを想像して回答してください。 回答はAです。合っていたでしょうか。 解説になります。プロダクトリスクはどれか、という問いですので選択肢のうち「製品」が直に利用者か提供者に不都合をもたらすリスクであれば正解となります。Aはアプリなどで考えると離脱不可やフリーズなどを引き起こしかねないため「製品」のリスクとなります。故にプロダクトリスクとなります。 他3つのリスクに関して、個別の解説は省きますが、ザックリと言ってしまえば「うまく製造できない」という結果に繋がります。これは「計画」に対するリスクとなるためプロジェクトリスクです。 いかがでしたでしょうか。両リスクはシラバスで取り上げられる例も多いので一つ一つ覚えると大変ですが、内容を理解した上で想像することで問題の難易度がぐっと下げることが可能です。 リスクにどう対処するか JSTQB FL対策というテーマからは若干逸れますが、それぞれのリスクに対して、業務でどのようなアプローチをとると良いのか、リスクを判断できるとどういうメリットがあるのかという話をしたいと思います。 プロダクトリスクに対処する プロダクトリスクに対処するものとして、リスクベースドテストというものがあります。リスクベースドテスト自体もFLで軽く触れられているものになりますが、可能性や影響から優先度を決定していくアプローチになります。ただ、当然ながらリスクベースドテストでなくとも、テストの対象となる機能にはどういったプロダクトリスクがあるかを常に意識することは重要です。 可能性や影響を適切に判断することによって、テスト優先度やテストの詳細度合い等を決定することができるというメリットがあります。例としては、要件レビューに参加し、リスクの観点からレビューを行う、非機能テストの戦略をリスクに基づいて決定するなどです。 プロジェクトリスクに対処する プロジェクトリスクへの対処は、JSTQBでは主にTMで解説される内容のため簡潔に、かつ個人の見解も含むものになりますが、自身が担当する範囲で、何かしら作業が滞る要因は全てプロジェクトリスクです。 阻害となっている要因（たとえばテスト環境構築の遅れなど）を適切に判断することができれば、テスト実行スケジュールの再検討などができるようになり、影響を最小限に抑えることができます。 環境構築はあくまで一例ですが、プロジェクトリスクを判断できるということは、プロジェクトやチームが抱える問題を発見できるということでもあるため、テストコントロールの観点においてもプロジェクトリスクを適切に判断できることは重要となります。 このように、対処のアプローチ、対処することのメリットも異なるため、それぞれの対処法だけでなく、それぞれを正しく「判別」出来ることが重要になります。 まとめ 以上でJSTQB FL対策の第1回、プロダクトリスクとプロジェクトリスクの解説は終了します。あくまで私が受験時に苦戦した内容をまとめているものになるため、「そんなことは知っている」という方もいるでしょうが、私と同じ個所で苦戦している方がいらっしゃいましたら、この記事で理解のお手伝いが出来れば幸いです。 本記事はFL対策と銘打っていますが、テストに向けてというだけでなく、JSTQBの用語理解にも役立てていただければと考えています。JSTQBの用語を基準とすることで認識の共通化を図ることでステークホルダとのコミュニケーションにおいてエラーも発生しにくくなると思いますので、プロジェクト内のポジションに関わらず、用語を深く理解することは重要と考えます。 では、また別の記事でお会いしましょう。 The post JSTQB FL対策 弱点強化解説　～１回目～ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 チームではスクラム開発を導入しており、今回はNotionでのバックログ管理の話をしたいと思います。 当初のバックログ管理方法 自分が所属するチームでは、バックログは、当初Miroで原案を作ったのちGitHub + ZenHubにて作成し管理していました。 バックログに加えバグや要望も同様にGitHub + ZenHubで管理していましたが、ナレッジやドキュメントはNotionに作成しており、下記のような課題を持っていました。 バックログ、要望、バグが混ざって見にくい バックログとドキュメントを参照するのに複数のサービスを行き来するのは手間がかかる Sprint単位のバックログや状態が把握しにくい 現在のバックログ管理方法 これらの課題を解決するため、バックログ等をすべてNotionに移植し、ボードビューのグループとサブグループを用いて見やすいビューを作成し管理するようにしました。 実際に使用しているビューの形式はこちらです。 ※実データは載せられないため、形式は同じもので仮のデータを入れたものになります。 縦軸に担当者、横軸にSprint、プロパティにはバックログのステータスとindex（通し番号）を表示しています。 また、タイトルにも indexを付与することで、他pageからバックログをリレーションのプロパティとして関連づける際に検索しやすくしています。 ※今は手動で付与していますが、Notion APIを用いれば半自動などでの付与も可能だと思います。 いちいちバックログ名を検索するのは大変ですが、番号で検索することで、スムーズに目的のバックログを表示することができます。 プロパティはこちらです。（最低限のものを表示しています） 担当者は今回のブログ記事用のデータベースを作成して割り当てていますが、Notionのユーザー一覧でも問題ないかと思います。 Tasksは後述する開発者のタスクボードへのリレーションです。 こちらは自分達のチームでは関連付けを追加する機会が多いこともあり、セクションとして表示しています。 なお、今回はページ内容は空白ですが、ユーザーストーリーや受け入れ基準など開発に必要な内容を記述していきます。 要望、BUGの管理 これらはバックログとは異なるデータベースとし、主にテーブルビューで管理しています。 先ほどのプロパティからは省いていますが、バックログのページとリレーションを設けることで、互いに参照ができるようにしていきます。 なお、同じデータベースで管理するのも一つの方法なので、ここを分けるかどうかはチームで運用しやすい方法を選択するのが良いかと思います。 タスクボード 開発チームのタスクも別のデータベースを作成し、バックログと同じ形式のボードビューとして利用しています。 これらに互いにリレーションプロパティを作成することで、開発チーム プロダクトオーナーの情報共有に役立っています。 その他通知設定 Notionではビューの設定で簡単にSlack通知を行うことが出来るため、自分たちのチームではこれを活用しています。 例えばバックログボードやタスクボードのステータスが指定のものに変更されたときにSlackに通知を行なえます。 例として、自分たちのチームではステータスを横軸にした別ビューを作り、ステータスがQAメンバの評価待ちを表す 開発完了 というステータスになったら、QAメンバの居るチャンネルに通知するといった運用を行っています。 おわりに 今回の内容のまとめです。 バックログや要望一覧などをNotionに移植することで、各種課題を解消 データベースを分けた場合も、リレーションを活用することでリンクしやすくする バックログの管理方法にお困りの方は、ぜひ参考にしてみてください。 なお、Notionには継続的に新しい機能が追加されており、以下の2つの機能を今後は試す予定です。 スプリント機能 GitHub連携機能 The post Notionでプロダクトバックログを管理するビューを作成する first appeared on Sqripts .

こんにちは。ゆーてぃです。 2023年9月8日(金)に開催されたJaSST’23 Hokkaidoに参加してきましたので参加レポートを書いてみたいと思います。 テーマ「心動かさる”コト”の品質」 今回のテーマは、「心動かさる”コト”の品質」とし、利用時品質、UI/UX、DevOpsに焦点をあて、ソフトウェアテストと品質の今後のあり方を考えます。 JaSST’23 Hokkaido 北海道外の方がこのテーマを目にすると、「動か さる 」ん？誤字？と思うかもしれませんね。私は生まれも育ちも北海道なので何の違和感も覚えず、よいテーマだなと思いました。 JaSST’23 Hokkaidoの開催要項にも書かれていますが、「～さる」は北海道弁で「自分の意思以外の何かによってそうさせられてしまう」という意味となり、私はよく弁解のためにこの言葉を使ってきました。 おい！なんでそのボタン押したんだよ！→いや、押ささったんだよ！ 私は言い訳に使うことが多く(たぶん？)ネガティブな言葉として捉えてましたが、今年のテーマを見て、ポジティブな表現としても使える良い方言だな、と感じました。そしてソフトウェアを使用する人の心が動かさる仕事がしたいなと思いました。 基調講演「ユーザビリティとソフトウェア品質」 今回の基調講演では、国立研究開発法人理化学研究所革新知能統合研究センター 兼 東京都立大学客員教授／公立千歳科学技術大学客員教授の福住 伸一様が登壇され、様々なユーザビリティの考え方や捉え方、さらにソフトウェアの品質としての利用時品質、製品品質におけるユーザビリティの問題点についてお話をされてました。 DX(デジタルトランスフォーメーション)が注目されている中で、「デジタル化していけばいいんじゃなくて、人間中心に考えていかないとダメだろう」という観点から、どのように考えていけば良いかについて例を挙げながら語られていました。印象に残った内容をピックアップして記事にまとめたいと思います。 人間中心の考え方 1980年代後半から、ユーザビリティという概念が提唱され、当初は「何とかして使えるようにする」という目標から、「使いやすくする」という思想へと変化しました。さらに、視覚的なGUIにとどまらず、聴覚や触力覚などにも広がり、ユーザビリティの捉え方が多様化してきています。 この変遷の中で、顧客との要求明確化に課題があると指摘され、システムの利用に焦点を当て、ユーザビリティやユーザエクスペリエンスを満たすために人間中心設計とインタラクティブシステムの活用が重要だと強調されました。 人間中心設計とは 国際規格ISO9241-210で定められた、 システムの利用に焦点を当て、人間工学(ユーザビリティを含む。)の知識および技法を適用することによって、インタラクティブシステムをより使いやすくすることを目的とするシステムの設計および開発へのアプローチ。とのこと。 人間中心設計では実際に以下のことが重要とお話をされてました。 ・例 発表者(ユーザ)は、限られた発表時間(利用状況)の間に発表を完了させるために(利用目的)、どれだけの時間が残されているか(前提条件)を知る必要がある。ユーザ要求事項は、タイマーを使って、残り時間および経過時間を計測し、視覚的および聴覚的情報として提示する、などとなる。 このように、利用者が誰で、どのような操作や環境で行うかを考慮し、利用状況と関連付けながら要件を抽出し、ユーザ要求事項に合致する設計解を作成、および評価を行う流れを繰り返すことにより、ユーザ要求事項に適した設計につながると述べられました。 所感 利用状況を理解し、要求事項を明確にした上で設計し、評価することは、私たちが担当している機能テストでも同様に重要な要素です。非常に興味深い内容であり、多くの共感を覚えました。そして、何よりも重要なのは、このサイクルを繰り返し、より良いものにしていくことだと感じました。 新しい利用時品質 次に「新しい利用時品質」についてご紹介いただきました。以下の理由から新しい利用時品質の考え方が必要だと述べられています。 従来は製品やシステムが仕様を満たすことで品質が評価されていた(製品品質)。 デジタル化が進んでそれらを「使う」ことの影響が直接のユーザだけでなく、所属する組織や社会にも及ぶようになってきた。 これらの影響をできる限り制御できるようにすることが、組織の社会的責任として感じられる(利用時品質)。 デジタル化が進むことにより使う人の影響範囲が広くなったため、ユーザと製品・システムの1対1の影響ではなく、製品・システム・サービスを利用したことによって、多くの人々や社会など間接的な影響に目を向ける必要があるとお話をされてました。 また、製品品質モデルと利用時品質モデルの動向について、以下のように紹介されました。 品質モデルとして、製品品質モデルと利用時品質モデルの2つが存在する。 製品品質モデルにはusability(使用性)として品質特性が含まれている。 利用時品質モデルではusabilityが使用されていないという問題があった。 製品品質モデルとインタラクションの原則の品質特性であるusabilityに関連する品質副特性が、実質的に製品品質モデルの品質副特性として活用されている。 そのため、製品品質モデルの品質特性名を「usability」から「interaction capacity(インタラクション能力)」に変更することが適切ではないかという議論が国際規格の中で進行中であるようです。この変更については、直近の国際会議で合意がされており、現在最終審議中であるとのことです。 所感 常日頃、ユーザ目線でのテストを心がけていますが、今後は「ユーザ周辺目線」なるものが必要になるかもしれませんね。 製品を使うユーザだけでなく、さまざまな属性を持つユーザや所属する組織、会社、その他の関係者にも影響が及ぶことを考える必要があり、視野を広げて物事を検討することが、今後のテストにおいてより重要になると感じました。 最後に 福住様は最後に以下をまとめとしてお話をされています。 ユーザビリティ(を含めた人間工学)とソフトウェア工学はもっと仲良くすべき ユーザビリティはさまざまな観点からアプローチされており、これまで一緒に考えてこなかった部分があることが指摘されています。より密接に連携し、協力して取り組むべきだと述べられました。 人間中心設計で抽出されるユーザ要求事項を上流の段階で要件に組み込む 上流の段階でユーザ要求事項をうまく要件に組み込む方法を向上させる必要があり、要件定義は行われても、それを具体的な仕様に落とし込むことが難しいことが指摘されました。結果的に、ユーザビリティが把握しづらくなるという課題が示されました。 開発プロセスの中で段階的にユーザビリティを評価する方法 発表の最後で、福住様はこの問題に焦点を当て、テストの観点で確認してもらえると嬉しいと述べ、発表を終えられました。 所感 今回はユーザビリティと品質に関する内容をお話いただきました。こういった概念を理解した上でテストするとよりユーザエクスペリエンスが向上に繋がると感じました。 また、今回お話いただいた内容は開発、テストエンジニアも双方で考えることによって、より良い品質になるのではと考えさる内容でした。 ワークショップ 今回、オンサイトでワークショップに参加してきました。合同会社CGFMの金内 和子様、金内 透様が開催する「クライアントも開発メンバーも巻き込んで作るUIデザイン」をテーマにしたワークショップになります。 ワークショップの流れ ワークショップは以下の流れで即興演劇、ユーザシナリオ作成、ペーパープロトタイプ作成、簡易ユーザテストを行いました。 １）抽選により4人1組のチームを作成 ２）即興演劇 一人がユーザになり切って空想でアプリを使用します。 この時、ペルソナの心境、考えなどを言葉に出しながらアプリを触ります。 他のメンバーはペルソナの心境やアプリの情報など、ユーザ役の言葉を付箋にメモしていきます。 ３）ユーザシナリオ作成 ２で書いた付箋を時系列で整理し、ユーザシナリオを作成します。 ４）ペーパープロトタイプ作成 手書きで簡易的なUIを作成していきます。 これが思ったよりも難しく、ついペルソナの人物像、課題を忘れてしまう場面もありました。 ５）ユーザテスト 紙で作成したUIに対してどうやってテストしていくんだろう？と思っていましたが、一人がサーバ役をやるんです！ユーザが遷移ボタンなどを押すと、サーバ役が別画面の紙に差し替える方法でユーザシナリオを進行していきます。 道中に不具合などがあればユーザシナリオ、ペーパープロトタイプを修正し、再度ユーザテストします。 その後各チームで1名テスターを選出して、別のチームへ赴きそのチームのシナリオと簡易ユーザテストを実際に進められるか、といった流れで進めていきました。 所感 「早くつくって、早く試す」と金内様が強調されておりましたが、兎に角すごい早い速度で進行していきました。1つの工程は5分程度だったかと思います。 また、初めは自分のチーム内で話ながら進めていたため、完成したもので概ね問題ないだろうと思っていたものが、別チームの方が進めてみると思ったように進まない、というのが大体のチームで起きていたと思います。 これでよかろうと思って作成したものが、実はユーザからしたら分かりにくかったり、使いにくかったりするため、実際に使用するユーザの事を考えてUIを作成することの難しさを体験できました。 まとめ 「心動かさる”コト”の品質」をテーマに参加させていただきましたが、どの講演内容も考えさる内容でした。日頃、機能テストを担当しているため、機能性を中心に考えてしまいがちですが、様々なユーザ要求を達成するには使用性に目を向けることも重要であると再認識しました。 今まで機能テストでもユーザ目線でのテストは心掛けて実施してきましたが、今回の講演やワークショップで学んだ内容を活かして、よりユーザの事を考えたテストが行えるよう日々精進していきたいと思います。 The post JaSST’23 Hokkaido 参加レポート first appeared on Sqripts .

IoT機器とは IoT機器とは、インターネットに接続される機器のことです。 パソコンやスマートフォンは当たり前のようにインターネットに接続されている機器ですが、近年では一般家庭向けの機器だけみても、エアコンや冷蔵庫、洗濯機など、これまでインターネットに接続されていなかった家電製品がインターネットに接続されるようになっています。 外出先から家の鍵の状況を確認し、解錠や施錠が行えるスマートロック、外出先から家の中の様子を確認できるネットワークカメラなど、様々な機器が販売されており、今後ますます広がりをみせていく分野となっています。 IoT機器に潜在するセキュリティリスク 機器がインターネットに接続され、便利な暮らしを提供するようになった一方、インターネットに接続されていない機器とは異なり、新たにセキュリティ上のリスクに対応する必要がでてきました。 適切なセキュリティ対策が行われていないと、悪意をもった第三者に機器が乗っ取られたり、機器で扱う重要な情報を窃取されたりするなど、重大な問題が発生する可能性があります。 IoT機器は、機器自体に利用されている基板やチップ、連携するサーバ、ソフトウェアなど、セキュリティを考慮しなければならない要素が多数存在します。 機器の基板やチップなどのハードウェアに潜在するリスク IoT機器は、ソフトウェアだけでなく、ハードウェアそのものに対する攻撃にも対策が必要となります。 例えば、UARTなどのデバッグポートが利用可能なまま残されていると、攻撃者によって機器で利用しているシェルへの不正アクセスを許してしまい、重要なデータを窃取される恐れがあります。 その他にも、メモリ上からファームウェアを抜き取られ、解析される等のリスクがあります。 連携するサーバやWebアプリケーション / Web APIに潜在するリスク IoT機器を管理するために利用するWebアプリケーションや、そのWebアプリケーションが稼働するサーバなど、ネットワーク経由で攻撃を受けるリスクがあります。 サーバやWebアプリケーションの脆弱性により、IoT機器を利用するユーザーの情報の窃取、サーバやIoT機器への不正アクセスなどが考えられます。 また、一般家庭向きのIoT機器ではスマートフォンアプリ（モバイルアプリ）と連携し、離れた位置からインターネット経由で機器を操作できるものが増えており、アプリで利用するAPI、アプリの動作についても同様の危険性があります。 ローカルで動作するソフトウェアに潜在するリスク インターネットに接続されるIoT機器であっても、全ての動作がネットワーク経由で処理されているとは限りません。 例えば、液晶画面付きの機器を起動させた際に、機器へログインするための画面が表示されるとします。 機器へログインするためには、機器に登録されているユーザーである必要がありますが、何らかの方法によりログイン画面を迂回し、不正に内部機能の利用が可能であるかも知れません。 ネットワークを介さない部分の動作においてもセキュリティ上のリスクは存在します。 このようにIoT機器には、機器自体や関連する様々な要素に対してセキュリティのリスクが存在します。 起こり得る問題の具体的な例としては、脆弱なスマートロックを利用していた場合、モバイルアプリのローカル部分の動作不具合により、解錠権限のない第三者に家の鍵を開けられて侵入される、脆弱なAPIを利用するネットワークカメラによって、第三者に密かに家の中の様子を監視されていた、などが考えられます。 IoT機器のシステムに対する主な検証内容 IoT機器のシステムに対する検証内容の例をご紹介します。 IoT機器のシステムに対する検証では、IoT機器や関連するアプリケーションなど、様々な要素に対して検証が必要となります。 ハードウェア診断 IoT機器自体の基板やチップに対して、UARTやJ-TAGなどのデバッグ用のインターフェースが利用可能でないかを調査するハードウェア解析や、ファームウェアの解析、USB/Bluetooth/NFCなどの各種インターフェースの調査を行います。 プラットフォーム診断 IoT機器や、 IoT 機器が利用するサーバに潜在する脆弱性の有無を調査します。 Webアプリケーション / Web API診断 IoT機器との連携管理に利用されるWeb アプリケーションや、ルータ等の機器自体に内包されるWebアプリケーション、連携するモバイルアプリケーションの通信先となるWeb API に対する脆弱性を調査します。 探索型セキュリティテスト（総合的な動作確認） AGESTでは、IoT機器単体での動作確認や、連携するWeb アプリケーション、モバイルアプリケーションを含めた動作確認など、正規ユ ーザーと同等の環境を想定した、探索型のセキュリティテストを実施することをお薦めしております。 探索型セキュリティテストにより、セキュリティ上問題のある仕様の洗いだしや、イレギュラーな操作によって機器の動作に問題が生じ、結果としてセキュリティにかかわる問題に繋がるなど、未知の不具合/脆弱性が発見される場合があります。 探索型セキュリティテストの具体例 では、一般家庭向けのスマートロックに対して探索型セキュリティテストを実施すると仮定して、機器の動作やモバイルアプリを検証する際の具体例をご紹介します。 一般家庭向けのスマートロックでは、既存の鍵の上に重ねるようにして貼り付けるタイプが多く、機器を動かすことによって、同時に既存の鍵を動かす、という仕組みになっています。 解施錠の判定 モバイルアプリと連動しているスマートロックでは、現在鍵が施錠されているのか、解錠されているのかをモバイルアプリで確認することができます。 施錠状況をモバイルアプリで確認できる 機器側で施錠、解錠の判定が行われた後、機器からネットワーク経由（インターネット、またはBluetoothなど）で現在のステータスが送信され、モバイルアプリにも反映されます。 では機器側ではどのように判定を行うのでしょうか。 スマートロックでは、まず初回利用時に、施錠位置と解錠位置の設定を行います。 実際に家の鍵に取り付けた状態で施錠/解錠状態にし、モバイルアプリを利用して施錠/解錠位置として設定します。 このサムターン（鍵のつまみの部分）の位置によって機器が施錠位置と解錠位置を判定し、現在の状態がモバイルアプリに表示されることになります。 では以下の状態となったとき、モバイルアプリの表示はどのようになるべきでしょうか。 この状態では、実際に鍵は開いていない状況が高いと考えられるため、施錠されていると判定されるのか、それともサムターンが施錠状態の位置から解錠側へ動いているので、解錠されていると判定されるのか。 今回の場合、丁度施錠状態と解錠状態の中間に位置しているため、どちらを正解とするかは難しく、各種メーカーによって取扱いに違いがあるようです。 では次の例を見ていきましょう。 こちらの場合、大きく解錠側にサムターンが回っていますが、まだ完全に解錠位置に設定したところまでは回っていません。 モバイルアプリの表示も施錠状態のままであるとします。 実際に施錠されている状態なのであれば、モバイルアプリの表示は間違っていないことになりますが、取り付ける鍵の種類によっては、既にこの時点で解錠されてしまっているものが存在します。 つまり、実際には鍵が開いている状態であるにもかかわらず、機器側の判定、およびモバイルアプリの表示上は施錠されているということになります。 実際の状態を適切に反映できていないため、セキュリティ上問題があるといえます。 解施錠のログ スマートロックでは、解錠/施錠が行われた際の記録がログとして残るものが多いです。 複数人でそれぞれモバイルアプリを利用している場合、モバイルアプリにログインするアカウントに設定されているユーザー名が履歴に表示されます。 また、スマートロックを取り付けていても、手動で解施錠を行うことはできるため、手動で操作した場合には、手動で施錠/解錠したログが表示されるものが多いです。 このログの機能も、誰がいつ利用したかを把握できるために存在するものと考えられるため、常に正しいログが保存されている必要があります。 正しくログが保存されなかったり、ログが改ざんされたりするようなことがあれば、セキュリティ上問題といえます。 モバイルアプリでログを表示する際には、サーバ上に保存されたログを取得していることが多く、モバイルアプリで解施錠を行うと同時に、モバイルアプリからサーバに向けてログ情報が送信されている場合もあります。 モバイルアプリから送信されるログ情報を改ざんして、不正なログを送信できないか、送信時のリクエストをドロップし、サーバにログ情報を送信しないことでログを残さず操作できないか、などもチェックします。 他の例として、手動解施錠によるログの扱いを取り上げます。 モバイルアプリで解施錠した場合には、モバイルアプリからログ情報が送信されますが、手動で解施錠した場合には、どのようにログが送信されるのでしょうか。 あくまで一例となりますが、インターネットに接続可能なスマートロックであれば、手動で解施錠した後、機器からサーバに対してログデータが送信されます。 インターネットに接続できず、Bluetoothのみで利用するタイプのスマートロックの場合には、未送信のログ情報が機器内部に保存されており、モバイルアプリで解施錠を行った際に、モバイルアプリでの解施錠のログと同時に、手動解解施錠のログも送信されるようになっています。 手動による解施錠でも正しくログが保存される必要がありますが、ログが正しく保存されない状況はないか、という考えでチェックを行います。 施錠状態から、ゆっくりとサムターンを回して解錠した場合に、正しいログが残るのか、逆に高速でサムターンを回しても正しくログが残るのか。 ログが残ることが当たり前のように思いますが、実際に検証してみなければ、どのような挙動になっているかは分かりませんので、実際の動作をしっかりと確かめます。 まとめ IoT機器のシステムに潜在するセキュリティリスクと、検証方法の例についてご紹介しました。 IoTの分野は、今後も広がり続けていく分野と考えられており、より複雑なシステムが増えてくることが予想されます。 IoT機器では、サイバー空間からの攻撃によって機器が誤動作し、それを利用する人が怪我を負うなど、現実世界への影響も軽視できません。 このような問題を未然に防ぐためには、事前にしっかりとした検証を行うことが重要です。 AGESTでは、具体例として記載した探索型セキュリティテストを含めたIoT機器検証のサービスを展開しております。 セキュリティエンジニアとテストエンジニア双方の視点から、製品に含まれる問題を発見し、製品の品質向上に貢献いたします。 お困りごとがありましたら、お気軽に当社にご相談ください。 AGESTのIoT機器診断サービスの詳細はこちら から。 The post IoT機器に潜在するセキュリティリスクと検証方法とは？ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第5回となる今回から、オンチェーンデータのオンライン分析サービスのDuneを用いて、Ethereumを対象としたデータ分析の演習を始めていきます。 Hello Dune Dune は、ブロックチェーン上のデータ分析に特化したオンラインサービスで、類似サービスの中でも開始までのハードルが低く、コミュニティ機能やチュートリアルなども豊富なため、データ分析初学者の人にとってもおすすめなサービスです。 Duneのユーザは誰でも自分の分析クエリや可視化のためのダッシュボードを公開できるため、公開されているダッシュボードを見る用途だけでも有益なサービスです。今回は、実際に自分で新しいクエリを作成して実行してみることから試してみましょう。 なお、今回ご紹介するDuneの機能は2023年8月現在の仕様であり、今後のアップデートで変更が発生する場合もあるため、最新の情報は公式ページのドキュメントをご確認ください。ただし、ひとつのオンラインサービスであるDuneの仕様が変わったとしても、そこで使われているSQLの構文や知識は、他のサービスやデータベースでも通用する普遍的なものですので、Duneを入り口としつつも、ぜひ汎用的なSQLの知識を身につけていってください。 セットアップ 図1. Duneのダッシュボード一覧とアカウント登録画面（ https://dune.com/ ） Duneの公式ページにアクセスし、右上のSign upまたはSign inボタンから、アカウント登録またはログインをおこないます。アカウント登録には、ユーザネームとメールアドレス、パスワードの設定が必要です。ユーザネームは、クエリやダッシュボードを作成した際の作成者として表示されます。 アカウント登録後、 アカウント設定ページ でアイコンや各種SNSアカウントの連携、自己紹介文の追加が可能です。 また、MetaMaskなどのウォレットアプリをインストールしている方は、ウォレットアドレスとDuneアカウントを連携させることで、パスワードを使わずウォレット認証でDuneにログインできるようになります。 基本機能 Duneの基本機能として、他ユーザの作成したダッシュボードやクエリを検索できるDiscover機能があります。ダッシュボードやクエリにはタグ付けやお気に入り登録ができるため、ジャンル別のダッシュボードや人気のクエリなどを探すことができます。また、他ユーザの作成したクエリを自身のワークスペースにフォークしてきて、独自のクエリとして実行したり書き換えたりすることも簡単にできます。 クエリエディタ クエリエディタは、オンライン上でSQLクエリを記述し、実行するための機能です。公開されているクエリをForkしてくるか、画面上部のCreateボタンをクリックすることで、自身のクエリエディタを開くことができます。 図2. クエリエディタの表示例 エディタウィンドウでは、SQLの予約語やテーブル名などを補完してくれるオートコンプリート機能や、クエリの一部のみを選択して実行する選択実行機能などがあります。 また、クエリの一部をパラメタ化して実行時に決定できるようにしたり、特定の時刻やイベントに応じてクエリを再実行したりする機能もあります。 さらに、ChatGPTなどのLLM（大規模言語モデル）を応用した機能として、SQLクエリの内容を英語で説明してくれる機能や、英語の文章からSQLクエリを生成してくれる機能なども提供されています。 クエリの結果画面では、データを表形式で表示するだけでなく、棒グラフや円グラフなどで可視化する機能も備えています。 これらのクエリの結果を複数組み合わせて、ひとつのテーマで分かりやすくデータを表示させる機能がダッシュボードです。 図3. ダッシュボードの表示例 これらの機能は、アカウント登録さえすれば無料で使うことができますが、一部の機能はリソース制限があり、有料プランや有償のクレジットを購入することで追加のリソースを利用することができます。例えば、無料プランでは自分だけしかアクセスできないプライベートなクエリやダッシュボードの作成数に制限があったり、分析結果をCSV等でダウンロードできる数に制限があったりします。複雑なクエリを高速に実行するために実行エンジンのサイズをアップさせるためにもクレジットの消費が必要で、無料で手に入れられるクレジットを使い切った場合は、追加の購入が必要です。 また、独自のデータをアップロードして分析に活用したり、あるクエリの計算結果を永続化して再利用したりするには、有料プランの利用が必要です。 有料機能の詳しい内容については、 公式のPlansページ をご確認ください。 データテーブル クエリエディタの左側に、「Query Explorer」「Data Explorer」「Version History」といったアイコンが並んでいます。デフォルトではData Explorerが選択されており、Duneで提供されているデータセットとして、「Essentials」「Raw」「Decoded projects」「Spells」「Community」といったカテゴリが存在します。 図4.データテーブルのカテゴリ関係図 まず、「Raw」データは、本連載の第2回 ビットコインの仕組みや、第3回 イーサリアムの仕組みでご紹介したような、ブロックチェーンのデータ構造そのものに近いブロックやトランザクションのデータを示します。 しかし、Ethereumのような汎用的なスマートコントラクトの実行基盤では、トランザクションの中身はコンピュータが解釈しやすいバイナリ形式になっていることがあり、人間にとっては扱いにくいデータです。そのようなデータをプロジェクトごとにデコードして人間にも理解しやすい形にしたものが「Decoded projects」データです。例えば、OpenSeaやUniswapといったブロックチェーンサービスの仕様ごとに、オンチェーンデータがデコードされ格納されています。 さらに、それらのデータセットを組み合わせて、汎用的に使いやすいデータセットとして提供されているものが「Spells」です。例えば、NFTプロジェクト全般の取引情報を集約した「nft.trades」といったテーブルがあります。余談ですが、Duneではクエリを記述する分析者のことを「ウィザード（魔術師）」と呼び、記述されたクエリを「スペル（呪文）」、クエリのコレクションを「スペルブック（呪文書）」と呼んでいます。これらの「Spells」を生成するクエリは、Dune公式やコミュニティメンバーによって作成・管理されています。 また、公式のオンチェーンデータだけでなく、ブロックチェーン以外のオフチェーンデータを組み合わせてデータ分析をおこないたい場合もあります。例えば、ブロックチェーン上のアドレスに対するサービス名やユーザ名などのラベル付をおこなった「addresses」テーブルなどがあります。Duneやコミュニティによって提供されたオフチェーンデータを「Community」から利用できます。 上記のさまざまなデータセットから、特に頻繁に使用されるデータセットを集めたものが「Essentials」になります。 Hello Query それでは、クエリエディタから最初のクエリを作成し、実行してみましょう。サンプルとして、データテーブルのカテゴリから「Essentials」を選び、nft.tradesのテーブルを探します。テーブルの右横に並ぶプレビューのアイコンにフォーカスすると、このテーブルの中身のサンプルを表示してくれます。 図5. nft.tradesテーブルのサンプルデータ 今回は、サンプルとなるクエリをAIによって自動生成する体験をしてみましょう。テーブルのアイコンの中から「Wand（魔法の杖）」というボタンをクリックすると、クエリエディタの上部に「Using nft.trades, 」というフォームが追加されるでしょう。Duneの生成AIの場合、クエリ対象となるテーブル名は文章中で明示してあげる必要があり、このようなテンプレートが用意されています。 試しに、「Using nft.trades, what was the daily trade volume of opensea」という文章に変更し、OpenSeaの一日あたりの取引総額を計算するクエリを生成してみましょう。OpenSea ※1 とは、Ethereumブロックチェーンなどで発行されたNFTと呼ばれるデジタルデータをオンチェーン上で売買できるマーケットプレイスサービスです。「Generate SQL」ボタンを押してしばらく待つと、クエリエディタに自動生成されたSQLが入力されます。生成されるSQLは確定的ではありませんが、筆者の例では下記のようなクエリが生成されました。 コード1 . OpenSeaの一日あたりの取引総額を計算するクエリ（自動生成） SELECT   DATE(block_time) AS trade_date,   SUM(amount_usd) AS daily_trade_volume FROM nft.trades WHERE   project = 'opensea' GROUP BY   DATE(block_time) ORDER BY   trade_date DESC クエリエディタの「Run」ボタンを押してこのクエリを実行すると、図6のような実行結果が得られました。 図6. コード1.の実行結果 ※1 OpenSea ビジュアライズ この実行結果を、グラフでビジュアルに確認してみましょう。「New visualization」のタブを選択し、「Line chart」を選んで「Add visualization」ボタンをクリックすると、自動的に図7のような折れ線グラフが生成されると思います。 図7. 実行結果の折れ線グラフによる可視化例 図7のグラフを見ると、所々で急激な取引額の増加が見られます。これが、取引件数の増加によるものなのか、一取引あたりの取引額の増加によるものなのかを確認するため、取引件数を計算するカラムを追加してみましょう。 さきほどのWandの文章フォームを「add column of daily trade count」と書き換えて、「Generate SQL」から「Edit SQL」に切り替えて実行してみます。 コード2 . 取引件数のカラムを追加したクエリ（自動生成） SELECT   DATE(block_time) AS trade_date,   SUM(amount_usd) AS daily_trade_volume,   COUNT(*) AS daily_trade_count FROM nft.trades WHERE   project = 'opensea' GROUP BY   DATE(block_time) ORDER BY   trade_date DESC SELECTとFROMの間に、「COUNT(*) AS daily_trade_count」という記述が追加されました。この記述が、日別の取引件数を計算するコードのようです。 このクエリを実行し、さきほどの折れ線グラフのY軸に追加してみましょう。クエリを実行すると、「daily_trade_count」というカラムが結果に追加されます。これを、Line chartの「Y column 2」に指定します。これだけだと、Y軸のスケールが違いすぎて取引件数のグラフがほぼ見えないため、「Y-axis options」で「Enable right y-axis」を有効化し、2つのスケールを利用できるようにします。さらに、画面最下部の「Series」パネルで、「daily_trade_count」の「Y-axis」を「Right」としてあげると、図8のような折れ線グラフが表示されます。 図8.取引件数・取引額による折れ線グラフの表示例 このように、Duneの機能をフルに活用すれば、ブロックチェーン上のデータを好きな形で加工してビジュアライズする工程が簡単に実装できます。 ただし、AIの機能に依存しすぎては、生成されたSQLの正しさに確信が持てず、想定しない挙動となった場合の修正も困難です。また、どのようなデータテーブルを組み合わせる必要があるかは、いまのところ人間が明示的に指定してあげる必要があります。 Duneを使いこなしてオンチェーンデータ分析をおこなうためにも、本連載の後半で、SQLの基本構文に関する知識と、オンチェーンデータのデータ構造についての知識を身につけていきましょう。 基本的なSQL構文 コード1.～2.で示したSQLクエリをサンプルとして、基本的なSQL構文について解説します。 SQLの構成要素は、基本的に「文（statement）」「句（clause）」「式（expression）」の3要素があります。句は「節」とも表現されますが、ここでは句に統一します。式はさらに細かな構成要素に分けることができますが、SQLクエリの大まかな構造を理解する上では、まず「文・句・式」のレベルで理解することをおすすめします。 図9. サンプルクエリにおける文・句・式への分解 文 (Statement) SQLにおける文は、クエリを実行可能な最小単位です。複数の文が存在する場合は「；（セミコロン）」で文を区切りますが、Duneのクエリエディタのように基本的に1つの文しかないようなケースではしばしば省略されます。 文の例として、UPDATE文やDELETE文なども存在しますが、Dune上でデータ分析をおこなう上で登場するほとんどの文がSELECT文なので、まずはSELECT文を覚えておけば問題ありません。 句（Clause） SQLにおける句は、文を構成する要素であり、文における意味の最小単位として考えることができます。例として、SELECT句やFROM句、WHERE句などがありますが、SELECT句は「どんな情報を表示したいか」、FROM句は「どこからデータを取得したいか」、WHERE句は「どんな条件でデータを絞り込みたいか」といった意味を定義する役割を持ちます。 多くの句単独では文にはなれないので、例えばFROM句のみのクエリやWHERE句のみのクエリは、クエリエンジンで実行できません。SELECT句のみのクエリは、単独でSELECT文としても解釈できるので実行可能ですが、多くの場合は「SELECT ～ FROM ～ WHERE ～」の3つの句がセットで用いられます。 コード1.～2.で利用されているその他の句として、AS句は「カラムに別名を付与する」、GROUP BY句は「レコードをグルーピングして新しいテーブルを作る」、ORDER BY句は「レコードを並び替える」といった意味があります。 どのような順番で句を使用できるかは、文の構文として決められており、例えば「FROM ～ SELECT ～」といった順で書かれたクエリはエラーとなります。 式（Expression） SQLにおける式は、句を構成する要素であり、ある単一の値（スカラ値）やテーブル（リレーション）を返す表現です。 例えば、「1+1」という表現は2を返す式ですし、コード1.～2.の中の例では「DATE(block_time)」は日付を返す式、「SUM(amount_usd)」は引数の合計値を返す式、「nft.trades」はテーブルを返す式、「project」はprojectカラムの中身を返す式、「‘opensea’」は文字列のopenseaを返す式、「project = ‘opensea’」はTRUEやFALSEといった真偽値を返す式です。 特に、TRUEやFALSEを返す式を、特別に述語（predicate）と呼びます。クエリの構成要素を考える上では「文・句・式」の3要素でも十分なのですが、第4回 ビッグデータ分析のためのSQL基礎でも解説したとおり、SQLは関係代数と呼ばれる演算を実装した言語であり、この関係代数は集合論と述語論理をベースに設計されています。そのため、SQLを学ぶ上でも、この述語の概念を理解することが重要となります。 次回予告 今回の記事では、Duneのサービスの特徴や機能を紹介し、はじめてのクエリを実行する手順を示しました。また、文・句・式といったSQLの基本的な構成要素について解説しました。 次回の記事では、データ分析で役立つSQLの構文を紹介しつつ、引き続きオンチェーンデータ分析の演習をおこなう予定です。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習 1 The post 【第5回】Ethereumデータ分析演習 1 first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第4話です。 今回はまたまたまーくーの学び直し！、今や古典といっても良い？書籍「基本から学ぶソフトウェアテスト」を読んで、初版から20年以上たった今でも活かせる内容があるのか？ないのか？会話形式でお話させて頂ければと思います。 最後まで楽しんで読んで頂ければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 ソフトウェアテストの流れに、流れて、流れて・・・一日が街に恵む日差しで干からびそうになっている今日この頃です。 くまねこ QA業界経験1x年のエンジニア。 アスファルトのキラキラを追いかけていたところ、干からびかけているまーくーに話しかける。 イラストby くまねこ まーくー、どうしちゃったんでしょう…？今日も二人のやりとりをお楽しみください！ 学び直し！の道は長く険しい？？？ あっ、まーくーさん。お疲れ様です。だいぶカラカラになっているようですが…どうしたんですか？ もう、ほんと心がカラカラだよ テストって、覚えることが多くて大変だよなぁって思ってたんだけど、我らが神？の本（ 知識ゼロから学ぶソフトウェアテスト ）を読んでいたら、こんなことが書いてあって・・・ ソフトウェアというものは四つの仕事しかしない。なので君らはその四つのふるまいをテストすれば良いのだ。 知識ゼロから学ぶソフトウェアテスト とか、 （前略）おいらたちテストの技術の進化は非常に遅いし、学んだ技術が陳腐化しないというのは非常に楽なことなんだよ 知識ゼロから学ぶソフトウェアテスト とか、すごーく簡単なもの的にかいてあるんだけど、今でも全然簡単ではなくて・・・ なるほど…僕も「しっかりと理解してやれているかい？」って言われると自信が無いですね… でも、泣き言ばっかり言ってられないし、陳腐化しないのなら20年以上前に神の師匠が書いた本が、確か家の本棚にあった気がしてて・・・いっそのことそれを読んでやれって思ってるんだよねー 前々回 、アジャイルソフトウェア開発技術者検定試験に挑戦した時の気持ちを思い出していきましょう！背水の陣！バックウォーターフォーメーション！タフになれって風が吹いてますよ！ ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 基礎から学ぶソフトウェアテストとは 「 基本から学ぶソフトウェアテスト 」という本は、本の紹介ページによると「世界で最もたくさん読まれているソフトウェアテスト/品質保証の実践的な教科書です。」らしく、神の師匠Cem Kanerさん他が書いているんだよね。 すごいですね…まーくーさんが今持っているのがその本なんですね。どんな感じの内容になっているんですか？ 目次は ↓ みたいな感じで、テストの基本編、テスト技術編、テストのプロジェクトやテストチームの管理、付録としてよくあるソフトウェア不具合まで載っていて、460ページ以上ある辞書みたいな教科書なんだ(笑) 目次 第1部　基本編 　第1章　テストの進め方 　第2章　テストの目的と限界 　第3章　テストの種類と位置付け 　第4章　ソフトウェアエラー 　第5章　障害の報告と分析 第2部　テスト技術編 　第6章　障害管理システム 　第7章　テストケースの設計 　第8章　プリンタ（およびその他デバイス）のテスト 　第9章　ローカライゼーションテスト 　第10章　ユーザマニュアルのテスト 　第11章　テストのツール 　第12章　テストの計画とドキュメント 第3部　テストプロジェクトやテストチームの管理 　第13章　開発全体におけるテストの役割 　第14章　ソフトウェアの不具合に対する法的責任 　第15章　テストチームの管理 付録　よくあるソフトウェア不具合 知識ゼロから学ぶソフトウェアテスト おおお…まさにバイブル！すべてはここにあり、ですね。でも今回でこのボリュームを学び直すには、少し大変じゃないでしょうか。（少しづつ進めてほしい気持ち…ニヤついてみよう…ニヤニヤ） さすがにね、いっぺんに全部は・・・（私も無理）今回は古典と言ってよい基本から学ぶソフトウェアテストの第1部第1章、第2章を読んで、学んでいこうと思う！ Yeah～! \ /（訳：気持ちが通じた～！） 序文を読んで まずは序文からですね…ふむふむ。本書は、受入テストは別として、命に関わるようなソフトウェアについては対象外として記載がありますね。命に関わるようなソフトウェアだと、プロジェクトのプロセスとか厳格になってきますよね。本書の対象はそれ以外のソフトウェアテスト、という理解で読み進めた方が良さそうですね。 あ、そこ気付いた？そういう場合は他の本をお勧めしている(笑)。また面白いのが、 この本が対象にするのは、必ずしもみんながルールを守らない、または守るつもりがない、もしくは守る必要がないときのテストの進め方だ 知識ゼロから学ぶソフトウェアテスト って述べているんだよ。厳密にルール化して開発していて、それに則ってテストが出来るなんてそうそうないよね。どのプロジェクトでもルールはあるけど、より良くしようとか、まだルール化できていないとか、暗黙知とかがそれぞれにあって、把握するのに労力が必要だけど、それを前提としてくれているところがユニークだと思った。そういった状況下でも応用可能な視点で書かれてるんだろうな、と期待させてくれるよね。 確かに…「こうあるべき！」という内容だと、実際の現場にうまく当てはまらなかったりして逆にカオスになっちゃう話とか、聞いたことあるかもです…。そういう意味でも、今回の学び直しによって、現在の業務に活かせる学びがありそうでワクワクしてきました！Exciting！ さっそく、第1部の第1章から読み進めましょう！ OK！Come on！↷ 第1章　テストの進め方を読んで 第1章は「テストの進め方」について、簡単なプログラムに対する初期テストを題材に説明されているね。テストの段階という単位で説明がされているんだけど、書籍発行時の50年前の論文も参照して書かれていて歴史を感じると同時に、冒頭に書いた「学んだ技術は陳腐化しない」という神の言葉が思い返されるね…。 そうですね。実際にテスト業務を担当している立場からすると、テストの第一段階で「当たり前のテストから始めること」というところが基本にして真髄だな、と感じました。考え抜いた複雑なテストを早くやりたいところですが、まずはテスト対象のプログラムの「当たり前」のことがしっかりと動作しているかを確認し、徐々に複雑なテストを実施するっていうことは、私たちもやってましたが改めて大事なんだなぁって。 そうだねー。「当たり前」のところが動作してこそ、複雑なテストが意味を成すものね。複雑なテストとから実施して不具合が出てしまった場合、原因も掴みずらいし、手戻りが発生してしまうからね。 また、境界値テストの重要性についても書かれていて、JSTQBのFLで取り上げられている技法ですし、改めて学び直しておきたいです。 「境界値分析」をテスト設計に取り入れる 初期テストという条件だからかもしれないけど、即興的にその場で考えたテストを行う、というところも興味深かったね。本能を信じて「くさい」部分をテストするなんて、ちょうど 前回 くまねこさんが話していた探索的テストにも通じる考え方なんじゃないかな…。 確かに！なんだか、古来から伝わる伝説の技のようです。エンシェント！（ニヤニヤ） そうだね！（しまった、変な方向に誘導してしまった まぁ楽しそうだからほっとこう笑）第1段階はここまでにして、第2段階の話もしてみようか。 ここでは、不具合に関する記載がメインですね。報告した不具合に対する開発回答の捉え方の所は、現場でも参考になりそうです。例えば開発からの回答が「修正しない」だったとしても、ユーザーから見たら途轍もなく重要であることが伝わっていない可能性もあるから、そこは伝わるまで手を尽くす必要がある。開発とのコミュニケーションが大切ということを、ここでも改めて認識することができました。テストのメンテナンスや再テストなど、テストサイクルを繰り返していく上でのポイントも、参考になりました。 そうだね。現在はAIも登場してきて、色々とソフトウェアテストを取り巻く環境が変わっていく所だと思うけど、開発者やステークホルダーとの関係を良好にすることは、より良い品質の製品を作っていくためには大事だよね。（よし、第1章をきれいに仕上げた…！） Yeeeaaah～! \ /（訳：まーくーさん良いこと言ったぁ～！）この勢いで、今日は第2章までいけそうですか…？（今日はここまで…ここまで…祈！） オゥーライ！第2章までいくよ！ Yeeeeeeaaaaaah～! \ /（訳：うげぇえええ～！） 第2章　テストの目的と限界 第2章は「テストの目的と限界」ですか…ちょっとセンセーショナルなタイトルですね。。。 ここで述べられているのは、まず「完全なテストは出来ない」し、「プログラムの正当性の証明も出来ない」ということ。そのうえでテストの目的として、「不具合の検出」、「不良の修正」を挙げているね。詳しい戦略とかは、後段の章で述べるみたいだけど。 「完全なテスト」については、「全入力テスト」「全パステスト」「設計上の問題の全件検出」は不可能であると説明されていて、「完全なテスト」が不可能である時点で「プログラムの正当性の証明」も完全には出来ないと述べている。 ふむふむ。この辺りの考え方は、ソフトウェアテストのテスト7原則の「全数テストは不可能」「テストは欠陥があることは示せるが、欠陥がないことは示せない」「「バグゼロ」の落とし穴」に通じる考え方ですね！ 個人的にはテストに関するバイアスについての以下の説明が、ふむふむとなったよ。心理的なバイアスで、不具合に気付かなくなるってのはテスト管理の面でも気を付けなきゃだよね。 プログラムは正常に動くと期待すると、プログラムは正しく動くように見える。と言うより、バグを見逃してしまう。プログラムは動かないと考えると、不具合を見つける可能性は高くなる。バグを報告すると罰せられるなら、不具合を見逃してしまう。報告しなくなるのではなく、不具合に気付かないのだ。 知識ゼロから学ぶソフトウェアテスト ふむふむふむふむ。 あっ…（また始まった…？） ふむふｍ…これは確かにそうですね。「プログラムは動かない～」のところ、エラー推測テストはこの考え方に近いのかな、と感じました。テスト担当者の心理的な面も書かれていて、共感できました！（あれっ…まーくさん、なんでちょっと意外なリアクションなんでしょ？） オゥーケイ！第2章はこのぐらいにしようか！（良かった。今回はちゃんと考えてただけだった笑） はーい！（干からびていたまーくさんもテンション上がって潤っている～！） まとめ 基本編の最初の部分を読んだだけだけど、テストの進め方の「当たり前のテストから始める」や「完全テスト」は不可能といった、現在の考え方のベースになったであろう記述が多々あって、古典とは言え学び直しにとても有効そうだと感じたね。 そうですね。まだ序盤の序盤ですが、今までの我々の経験や知識は、なかなか陳腐化しないということが改めて理解できて良かったです。 とはいっても、時代を経るにつれ変わるところ変わらないところがあるはずだから、今後もしっかりと読み進めていこう！ちなみに・・・第2章「テストの目的-不良の修正」に出てくる、 テストの担当者はプログラムを破壊するつもりでテストするが、大局的には建設的な仕事である。鍛え上げるために、しごいているようなものだ。 知識ゼロから学ぶソフトウェアテスト って記述を読んで、テスト対象のプログラムに対して、厳しくも優しくテストして行く気持ちは大事なんだよなって、再認識できたよ。 まさにULTIMATE CRUSH！ですね。ララ Yeeeeeeeeeeaaaaaaaaaah～! \ / 次回予告 今回はここまでにして、次回の記事はどんな感じにしようか？ 次回のまーくー＆くまねこは、 まーくー、JSTQB ALTM試験、本当に受けるの？どうでしょ！（仮） くまねこ、JSTQB FL試験を通り過ぎる！（仮） の2本でーす。 最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ ﾉｼ ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ The post ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ first appeared on Sqripts .

はじめに 前回は、BDDを構成する3つのプラクティス「発見(Discovery)」「定式化(Formulation)」「自動化(Automation)」の概要を紹介しました。 今回以降は、 第1回 の記事でも用いた自動販売機を題材にして、前回の記事で紹介した、「BDDを用いたプロセス」を行ってみます。 本記事では、「発見(Discovery)」の部分までを、具体例を交えつつ説明します。 1. ユーザーストーリーを選ぶ ユーザーストーリーマッピングなどを用いて、予めユーザーストーリーを作成しておきます。 そして、次Sprint以降で開発する可能性が高いユーザーストーリーをピックアップします。 今回は、自動販売機に関する以下のユーザーストーリーをピックアップします。 タイトル ：顧客が自動販売機で飲み物を購入する As a ：顧客の立場で、 I want ：自動販売機から飲み物を購入したい so that ：店舗に行かなくても飲み物をすぐに得られるように 2. 要件ワークショップ 1で選んだユーザーストーリーに対して、要件ワークショップを行います。「要件ワークショップ」という言葉は、組織によっては「リファインメント」「スリーアミーゴス」などと呼ばれたりします。 「発見(Discovery)」のフェーズでもある要件ワークショップでは、ドメインを構造的に理解していく協調作業を行います。その際には、 明確な具体例を使用することが重要 です。 要件ワークショップでは色々なやり方があるのですが、今回は実例マッピングを用いてみます。 実例マッピング 発見(Discovery)を行う活動として「実例マッピング(Example mapping)」というものがあります。 詳しいやり方については、実例マッピングの考案者であるMatt Wynneが説明している「 Introducing Example Mapping （邦訳： 受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」 ）」や、私が解説している スライド や 記事 を参照ください。 ここからは、今回の題材である「顧客が自動販売機で飲み物を購入する」というユーザーストーリーに対して、実例マッピングを作成していきます。 手順0. 対象のユーザーストーリーを記載する 対象のユーザーストーリーを黄色の付箋で貼ります。 手順1. 具体例を1つ記載する 手順0で記載したユーザーストーリーを行うような具体的な例を考え、緑色の付箋で貼ります。例えば以下のような感じです。 例えば以下のような感じです。 手順2. 具体例が成立するためのルールは何か考える 手順1で緑の付箋に書いた具体例が成立するためにはどのようなルールがあるか考えます。 もしも思いつかない場合は、別の具体例（緑の付箋）を書いてみると良いかもしれません。 今回の場合、以下のようなルールが考えられそうです。 自動販売機に投入できる硬貨がありそう 選んだ飲み物は出てきてほしい 飲み物を買うとお釣りが出てきそう（連続購入はできなさそう） これらの考えを元に青色の付箋を記載していきます。 手順3. 文章のリファクタリングを行う 実例マッピングを書いていく中で、言葉が揃ってないことに気付くことがあります。その際はTDDでのリファクタリングと同様に、言葉のリファクタリングをしていきましょう。 例えば今回の場合、以下のようなことが気になりました。 ・「購入する」と「買う」という単語が存在している。どちらかで揃えられそう。 ・「買う」という言葉自体が、どのような振る舞いを表しているのか分かりづらい。何をもって「買う」という状態を表すのかはっきりさせた方が良い これらを元に、実例マッピング内に書いた文章をリファクタリングした結果が以下の通りです。（太字＋下線が変更した部分） 手順4. ルールを簡潔に表現している具体例を書く 手順3で作成したルール（青色の付箋）を簡潔に表現できる具体例（緑色の付箋）を記載します。 例えば、以下のような感じです。 手順5. 疑問点が出てきたら、赤い付箋で残しておく 実例マッピングを作っていく際に、その場では解決できないものが出てきたら、疑問点として赤い付箋に残しておきます。 例えば、以下のように置きます。 疑問点は疑問点として書き出しておき、要件ワークショップの時間や頭のリソースを疑問点の解消に費やさないことが大切です。 手順6. 手順1〜5を繰り返す ここまで説明した手順を繰り返します。 なお、手順通りの順番でなくても良いです。例えば、文章のリファクタリングは都度行っても良いですし、ルール（青色の付箋）を最初に書いて、ルールを表現する具体例（緑色の付箋）を書いても良いです。 実例マッピングを行うことのメリット 実例マッピングを行うことで色々なメリットがあります。 メリット1. 「Unknown unknowns（知らないことを分かっていない）」ものが明確になり、他の状態へシフトできる 前回の記事で紹介したラムズフェルド行列において、今まで、どんなことが「Unknown unknowns（知らないことを分かっていない）」状態（ラムズフェルド行列の右下）だったのか明確になります。 疑問点として赤い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known unknowns（知らないことを分かっている）」状態（ラムズフェルド行列の右上）へとシフトできています。 また、具体例として青い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known knowns（知っていることを分かっている）」状態（ラムズフェルド行列の左上）へとシフトできています。 メリット2. 開発開始までに解決しなければならない課題が明確になる 疑問点（赤い付箋）が解決しないまま開発開始しようとする行為は、要件が固まっていないまま開発開始を試みているのと同義です。 開発開始前にPOやビジネス関係者と話し合って、赤い付箋の解決に向かうべきという指針を立てることができます。 メリット3. ユーザーストーリーやルールの大きさが適切か把握することができる 今回の例では、青い付箋が3枚程度、緑の付箋も最大で3枚程度になりました。 しかし、これらの付箋の枚数がもっと多かったりすると、ルールやユーザーストーリーの内容を再考した方が良いということが分かります。 例えば以下のように、緑色の付箋が非常に多くなってしまった場合。 これは、いくつもの具体例を示すことで、やっと1つのルールを表現していることになります。つまり、それだけルールが複雑になってしまっていることが示唆できます。 このようになってしまった場合は、複雑になっているルールをいくつかのシンプルなルールに分けることを検討しましょう。 別の例として以下のように、青色の付箋が非常に多くなってしまった場合。 これは、いくつものルールを用いることで、やっと1つのユーザーストーリーを表現していることになります。 このままですと、ユーザーストーリーが複雑であるため、プランニングの際に考えるストーリーポイントも大きな数になる恐れがあります。 このようになってしまった場合は、ユーザーストーリーをいくつかの小さなユーザーストーリーに分けることを検討しましょう。 メリット4. ルール（青い付箋）は受け入れ基準として使うことができる ルール（青い付箋）は、Scrum等でよく使われる「受け入れ基準(Acceptance Criteria)」に転用が可能です。 例えば、今回の自動販売機の例の場合、青い付箋で書いた以下のものが受け入れ基準の候補となります。 自動販売機に投入できる硬貨が決まっている 選んだ飲み物が自動販売機から出てくる 飲み物を買うとお釣りが出てくる おわりに　〜協調作業を伴う「発見(Discovery)」はBDDで最も大切〜 今回は、要件ワークショップの中で行う「発見(Discovery)」のプラクティスとして実例マッピングを紹介しました。 前回の記事でも書いたように、協調作業が行われる「発見(Discovery)」がBDDの中で最も大切です。 またここまでの説明から分かるように、「発見(Discovery)」のフェーズにおいて、「自動テストを書くかどうか」は全く論点ではありません。 一旦、自動テストのことは頭の片隅に置いておいて、ビジネス関係者と協調することを大切にして「発見(Discovery)」のプラクティスを行ってみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング The post TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング first appeared on Sqripts .