こんにちは。ノウンです。 私が普段対応しているテスト業務の中にWebサイトのテストがあります。テストはPC以外にスマートフォン（以下スマホ）を使って行うこともあります。 今回は、スマホでWebサイトのテストを行う場合に、PCのブラウザの標準機能であるデベロッパーツール（開発者ツール）を使ってテストする方法を紹介したいと思います。 スマホのみでもWebサイトのテストを実施することはできるのですが、デベロッパーツールも使用してテストするメリットがあります。 はじめに スマホを使ってWebサイトのテストを行う場合は、主に表示やサイト内の機能（ボタンなど）のテストを行うことになります。その他にも例えば、Webサイトの要素に記述されているタグがブラウザ上で動作して通信が行われているか？（この動作のことを「タグが発火する」と言います）をスマホのブラウザでデベロッパーツールを開いて確認することも可能なのですが、確認するにはスマホ1台ごとにアプリのインストールが必要で、スマホはそもそも画面サイズが小さいためデベロッパーツールが見辛く操作しにくいです。 PCで設定を行っておけば、スマホ1台ごとにアプリをインストールすることなく、スマホのブラウザのデベロッパーツールをPC上で確認・操作できるようになります。 なお、PCでデベロッパーツールのエミュレート機能（UserAgent偽装）を使えば、PCで「スマホを使用してサイトを閲覧している」という状態を疑似的につくり出してテストをすることもできます。「じゃあ、全部PCでエミュレート機能を使ってテストすれば問題ないのでは？」となりますが、その場合「スマホでサイトを閲覧した時だけ表示が崩れる」等の、スマホ端末のみで発生する不具合を発見できない可能性があります。 私が過去に遭遇した事例もあります。（後に紹介します） スマホで見ているサイトに対してPCのデベロッパーツールを使用することで、PCでWebサイトのテストを行っている時と同じ情報をスマホで確認できることから、タグの発火をリアルタイムで確認できたり、HTML/CSSの確認やJavaScriptエラーの有無等も併せて確認できる様になります。 なお、デベロッパーツールを使用したタグの発火テストについては、以前に下記の記事を投稿していますのでそちらも参考にしていただければと思います。 ■ GoogleAnalytics利用時に組み込むタグのテストについて スマホでPCのデベロッパーツールを使用する手順 今回紹介する方法は、使用するスマホ端末によってUIの違いはありますが、どのスマホ端末でも実行できる内容となっています。 まず「Android & WindowsPC」、次に「iPhone & MacPC」を使う手順を説明します。 Android & WindowsPC（Chromeを使用） 以下の端末を使用した場合で説明します。 Android端末＆Windows10 Pro 1. PCにAndroid Studioをインストールする 以下のURLにアクセスして、Android Studioをダウンロード→インストールします。 Android Developers インストールは、表示される画面に沿って進行すれば大丈夫です。迷う要素は特に無いと思いますが、公式のヘルプがありますので必要に応じてご参照ください。 Android Studio をインストールする 2. Android SDKの設定を行う スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されるようにします 3. 「Tools」メニュー＞「SDK Manager」を選択 4. 「SDK Platforms」タブで、使用するAndroidのOSにチェックを入れる 5. 「SDK Tools」タブで、「Android SDK Platform-Tools」が「Installed」になっていることを確認（「Not Installed」になっていたらチェックを入れる） 6. 「OK」または「Apply」を押下してインストールを実行する（インストールが不要な場合は「Cancel」ボタンでウィンドウを閉じる） これで、スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されます。 7. ADBコマンドを有効にする ADBとは、Android Debugging Bridge のことで、コマンドを有効にするとAndroid Studioを使ってPCでスマホの開発をしたり、コマンドプロンプトからスマホを操作したりと、スマホのみでは行えない操作をPCから行うことが可能となります。 今回はスマホでデベロッパーツールを使用する際、スマホのUSBデバッグが正常に動作するように設定を行います。 設定する際、あらかじめ手順「5」の画像上部「Android SDK Location:」に表示されているフォルダパスを控えておくとスムーズに設定できます。 8. WindowsPCのタスクバーにある「スタート」ボタンを右クリック＞「システム」を選択 9. 「システムの詳細設定」を選択 10. 「詳細設定」タブ＞「環境変数」を選択 11. システム環境変数 の「Path」を選択＞「編集」ボタンを選択 12. 「新規」ボタンを選択＞Android Studioをインストールした時に一緒にインストールされた、フォルダ「platform-tools」のフォルダパスを入力 13. 開いている各ウィンドウを「OK」ボタンを押下して閉じる 【注意】手順13.で「キャンセル」ボタンを押下すると、ここまでの設定が反映されないため、必ず「OK」を押下して各ウィンドウを閉じてください。 14. PCを再起動する 15. ADBコマンドが有効になっているか確認する ここまでの設定が反映されているか確認を行う。WindowsPCの「コマンドプロンプト」を起動する （「スタート」アイコンをクリック＞「 cmd 」で検索＞コマンドプロンプトを選択。または、タスクバーの検索アイコン・検索ボックスから「 cmd 」で検索＞コマンドプロンプトを選択） 16. 「 adb 」と入力してEnterキーを押下する 17.画像の様にコマンドの引数（内部デバッグ[internal debugging:]、USBの接続[usb:] などの情報）が一覧になって出てくれば、ADBコマンドが有効になっている ※ADBコマンドが有効になっていない場合、下記エラーメッセージが表示されます。ここまでの設定や入力した文字列に誤りが無いか確認してみてください。 18. Androidの「開発者向けオプション」を表示する Androidの「設定」＞「デバイス情報」＞「ビルド番号」の部分を連続で7回タップする ※Androidによって「ビルド番号」の表示箇所が異なる場合があります 19. 「開発者向けオプション」を有効にする 「設定」＞「システム」＞「開発者向けオプション」を選択して「開発者向けオプションの使用」のトグルボタンを有効にする 20. 「USBデバッグ」を有効にする 「USBデバッグ」のトグルボタンを有効にして表示されたウィンドウで「OK」を選択する 21. AndroidとWinPCを接続する Android端末のUSB端子形状（Type C）に合ったケーブルでAndroidとPCを接続して、Androidの画面に表示されるウィンドウで「許可」を選択する 22. AndroidのChromeでテスト対象ページを開く 23. WinPCのChromeを開き、アドレスバーに「 chrome://inspect/#devices 」と入力してアクセスする 24. 接続しているAndroidの端末名とブラウザ、テスト対象ページのURLがWinPCのChromeに表示されるので、URLの下にある「 inspect 」を選択する 25. デベロッパーツールが開く WinPCのChromeの左側にAndroid端末の画面、右側にデベロッパーツールが表示される 26. デベロッパーツール内の通信情報を確認 スマホでアクセスしたWebサイトを操作して、デベロッパーツールでWebサイトの通信情報を確認する。画像は「Network」タブに情報が表示されている状態 iPhone & MacPC（Safariを使用） 以下の端末を使用した場合で説明します。 iPhone端末＆iMac 1. iPhoneでWebインスペクタを有効にする MacPCでiPhoneのデベロッパーツール（Webインスペクタ）を表示させるには、iPhoneの設定を行う必要があります。 iPhoneの「設定」＞「Safari」＞「詳細」＞「Webインスペクタ」のトグルボタンを有効にする 2. MacPCのSafariで開発メニューを表示する MacPCのSafariは、デフォルトの設定ではiPhoneのWebインスペクタを開くためのメニューが表示されていないため、設定を行う必要があります。 Safariを起動＞「Safari」メニュー＞「環境設定」＞「詳細」の「メニューバーに開発メニューを表示」にチェックを入れる 3. iPhoneとMacPCをライトニングケーブルで接続する 4. iPhoneのSafariでテスト対象ページを開く 5. MacPCで、接続したiPhoneを選択する Safariの「開発」メニュー＞接続したiPhone＞テスト対象ページのURLを選択する 6. Webインスペクタが開く 7. Webインスペクタ内の通信情報を確認 iPhoneでアクセスしたWebサイトを操作して、WebインスペクタでWebサイトの通信情報を確認する。画像は「ネットワーク」タブに情報が表示されている状態 過去の不具合事例紹介 スマホまたはPC（UserAgent偽装）いずれかのみのテストでは発見できない、または発見が遅れる不具合の事例について、私が過去に遭遇したことがある2つの例を紹介します。 事例1　テキストの改行位置が不自然 PCのデベロッパーツールでUserAgent偽装を使用して確認した場合は問題なかったのですが、同じ文章をスマホで確認したところ、テキストが不自然に改行された状態で表示されていました。 文末の「す。」が不自然に改行された状態になっています。 これは、画面サイズにより改行される位置が変わってしまうこと、フォントの指定を行っておらずWebサイトを閲覧する端末のOS毎のテキストの微妙なサイズ違いによりスマホで閲覧した時とPCで閲覧した時でデザインが異なることが原因でした。 文字欠けがある訳では無く不要な文字が表示されている訳でもありませんが、見た目が良くないため後に修正対応されました。 事例2　スマホのみで発火するタグが発火しない スマホで見ているサイトに対してデベロッパーツールを使用してタグの発火を確認したところ、タグが発火していませんでした。 しかし、PCのデベロッパーツールでUserAgent偽装を使用して確認した場合は、タグが発火していました。 スマホでタグが発火していないのにPCでは発火している、ということは、タグが動いてはいることは間違いないのでタグ設定内容に問題があるのでは？…という推測から調査したところ、その通りでタグ設定に誤りがあったことが原因でした。 （具体的には、タグの記述でUserAgentを指定しており、スマホのUserAgentが指定されていませんでした） スマホとPCを接続してテストを行ったことで、PCでUserAgent偽装でテストをしていただけでは検出できなかったかもしれない不具合を検出することができました。 なお、今回のケースでは「タグの発火確認」がテスト観点として存在したためPCとスマホを接続してデベロッパーツールを適用したテストを実施しましたが、例えばテキストの誤字脱字の確認や、タグの記述にUserAgentの指定が無いことが明確な場合など、UserAgent偽装を使用した方が効率よくテストを行えるケースは少なくないため、常にスマホとPCでデベロッパーツールを使用することが必要ということではありません。 テスト内容によって使い分けることで、テストを効率化できたり質を向上させることが出来ます。 スマホのサイトでデベロッパーツールを使う場合の追加メリット Androidの場合、スマホのWebサイトでPCのデベロッパーツールを使う場合の追加メリットとして、デベロッパーツールにスマホの画面が常時映し出されていて、PCでスマホの画面を操作できるため、マウス・キーボードを使ってスマホサイトの操作が可能になります。タップ操作だけではなくスワイプ、文字入力も可能です。 これにより、入力フォームの項目が多いページや、細かい部分をタップ・スワイプした時の挙動の確認など、スマホでは手間だったり操作しにくかったりする部分が確認しやすくなります。 なお、iPhoneの場合はデベロッパーツールにスマホの画面が映し出されないため、残念ながらPCでのスマホの画面操作は不可能です。 おわりに 今回はPCのブラウザ機能であるデベロッパーツールをスマートフォンで使用する方法を紹介させていただきました。 Webサイトのテストを行う環境の例として、PC・スマホ・デベロッパーツールのエミュレート機能・スマホ＋デベロッパーツールがありますが、どの環境でテストを行うべきかはテストの内容により異なります。 「スマホ＋デベロッパーツール」は他の環境と違い、使用するには準備に手間が必要です。 ただ事前に設定をしておくと、その後はPCと接続するだけでいつでもデベロッパーツールを使用することができますので、スマホ＋デベロッパーツールでテストを行う必要がある場合はぜひ使ってみてください。 The post Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 第1回の今回は、論理スキルが重要である理由、身につけておくべき理由を解説します。 論理(ロジック)の話をする理由 “論理的”とは ビジネスの場でしばしば重要とされることのひとつに、“論理的であること”があります。 「論理的に考える/話す」「論理的な文章」など、耳に(目に)することも多いと思います。 ここでいう“論理的”とは、「矛盾や不整合、飛躍や欠落が見られない」「首尾一貫している（筋道が立っている）」……といった特徴を指していると言えるでしょう。 ソフトウェアは論理の塊 ソフトウェアはその殆どの工程/作業を通して“論理的”に構築されます。とりわけ、以下のような…… AとBで○○を計算する。その結果がCなら、その結果を用いてDを計算する。そうでなかったら、Eを用いてFを計算する αの状況で、利用者がβという操作をしたら、画面をγに切り替えてδという動作をする 処理ができない状況になったら、処理を続行せずに停止する etc. どんな場合に何をするのか(してはいけないのか)といった“条件/場合”に応じた処理/動作は 矛盾や欠落がないように しなければなりません。 また、どの工程の成果物(文書類)でも、その記述内容に 食い違いや不明瞭な箇所があると 、構築したソフトウェアが適切な動作をしなかったり、暴走やフリーズに至ることもあります。こうした意味で、論理(ロジック)はソフトウェア開発の“生命線”とでも言えるでしょう。 テストにとっても論理は大切 テストをする立場にとっても論理(ロジック)は重要です。 テスト対象の振舞いを、自分の解釈を加えたり想像で補ったりせずに、テストベースの記述の 筋道を辿って 理解する （テスト対象を操作しながら理解することもありますが、その場合は「どんな場合にどうなるのか」などを自分の頭の中で整然と組み立てていくことになります） テストすべきことを 当てずっぽうや思いつきではなく 根拠を持って、 筋道を立てて 考える 本記事では、“論理的”に考えるための「基本的な道具」である「 論理(ロジック)の言葉 」をいくつか見ていきます。 以下のような人に読んでもらうことを想定しています。 テストエンジニアとして、読解力、設計力を強化したいと考えている人 論理演算などを復習したい人 （これからテストエンジニアを目指す人にもお勧めです！） （ただし、テスト対象を理解したりテストすべきことを考えたりするのに、「論理の言葉」をひねり回すだけで十分というわけではありません。頭の中で考えるだけでなく、 考えたことを図に表すなど視覚化 してみて理解を確かめたりチェックしたりすることも大切です） 「筋道を辿る/筋道を立てて考える」とは 「筋道を辿って理解する」「筋道を立てて考える」ってどんな感じのことなの？　と思う人もいると思います。かんたんな“例題”で体感してみてください。 “論理パズル” この国のどこかに、正直者と嘘つきが住む村があります。 正直者は常に正しいことを言い、嘘つきは常に正しくないことを言います。村にはこの2種類の人間しかいません。 この村を歩いていたら、二人の住人AとBに出逢いました。Aは言いました。「私たちは二人とも嘘つきだ」 （【出典】『記号論理学　一般化と記号化』(スマリヤン / 丸善出版　問題1.3) A, Bは、それぞれ正直者でしょうか、嘘つきでしょうか。 （ぱっと解答に辿り着けなくても気にすることはありません。ソフトウェア業界人なら誰でもこうした“論理パズル”がすらすら解ける、というわけではありません（筆者も論理パズルが苦手です(´・ω・｀)）） ※この論理パズルの考え方を文末に掲載しています。 どう考える？① ある遊園地のあるアトラクションに、次のような注意書きが掲げられていました。 本アトラクションは以下の方のみ利用できます。 ・身長130センチ以上190センチ以下 ・体重90キログラム以下 ・年齢満15歳以上 このアトラクションを利用できる人/できない人はどんな人でしょうか。 どう考える？② とあるシステムのユーザーアカウント名の仕様です。登録できるユーザーアカウント名には以下の条件があります。 (a) アカウント名に使える文字は以下のいずれかに限ること 半角英大文字(A～Z), 半角英小文字(a～z), 半角数字(0～9) (b) アカウント名は16文字以下であること (c) 既に登録済みのアカウント名は登録できない 新規ユーザーとして登録できないアカウント名文字列はどのようなものでしょうか。 論理的に考えることは、“スキル” 誰でも身につけることができるスキル “論理的”に考えることは、持って生まれた何か特殊な才能やセンスによるものではなく、「論理の言葉」の意味や働きの理解・習得を通して身につけるスキルです。 言葉と言葉、文と文のつながりを把握し、条件や場合とその結果とのつながりを丁寧に結びつけて、文章の筋道を把握する 主張と根拠のつながりを明確にする 才能/センスということでいえば、 誰しも物心ついた時から論理の才能/センスを育んでいる と言えます。誰しも、日々の生活や勉強、仕事などを通して（無意識的にでも）「論理的に考える」ということをいくらかは学んでいるからです（100%徹頭徹尾非論理的に考え、生きる人間は、たぶん一人もいません）。 意識を向ければ、その分(早く)上達する 、というわけです。 誰しも身につけておきたいスキル ソフトウェアやソフトウェアテストを離れてみても、論理のスキルは身につけておきたいスキルです。 “論理的”に考えることは、文章を読んだり話を聞いたりする上でも大切ですし、「報告・連絡・相談」をはじめとするコミュニケーション全般の質を左右するのは、 「話が一貫しているか、整合が取れているか」「言うべきこと、言いたいことを適切に表せているか」 ということだからです。 “裏づけ”を知っておこう ここまで読んで、次のように感じた人も相当数いると思います。 「何を当たり前のことを言っているんだ？」 「特に勉強をした憶えはないけど、全然困ってないぞ！？」 そう感じた人は、自信を持ってよいと思います。意識せずに論理のスキルを身につけているのは素晴らしいことです。 そういう人も、「当たり前のようにできていること」にも基礎や裏づけがあると知っておくのは悪いことではありません。基礎や裏づけは「なぜそう考えるのか」を説明する助けになってくれるからです。 むすび これから何回かに分けて「論理(ロジック)の言葉」をいくつか取り上げ、その意味や働き、注意点などを紹介していきます。 プログラムレベルのロジック……基本の論理演算 文レベルのロジック　……文や文章の筋道を把握するための論理の言葉 （これだけですべて、というわけではないので、タイトルに「入門」とついています） なお、本記事は 「ロジカル・シンキング」を解説するものではありません 。ロジカル・シンキングは主にビジネスコミュニケーションにおける体系的な思考・発想の技術です（本記事で取り上げる“論理のスキル”は、その中の一部として関係はしますが、イコールではありません）。 “論理パズル”の考え方 Aが正直者だとすると、「私たちは二人とも嘘つきだ」はA自身も嘘つきと言っていることになってしまい、矛盾します。 従って Aは嘘つき で、「二人ともに嘘つきだ」は正しくありません。ということは、二人のうちどちらかが正直者ということになります。 （「二人とも正直者」という可能性もありますが、2でAは嘘つきと判明しているので、これはあり得ません） Aが嘘つきなので、 Bは正直者 です。 ※なんでそうなるの！？　と思った人は、「 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算」をご覧ください！ 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) The post [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか first appeared on Sqripts .

こんにちは、QAエンジニアの リキオ です。 ご存知の方も多いとは思いますが、QA業務ではしばしば、テスト設計時における仕様などの質問を「QA管理表」、またはテスト実施時における不具合を「不具合管理表」として、スプレッドシートやExcelなどに一覧化して運用する場面があります。このとき、一覧表に対してテストリーダー等の管理者のみが運用したとき、下記のような問題が生じる可能性があります。 情報の偏在： 記載者及び管理者にのみ情報が偏在するため、他のステークホルダーにまで共有されず、QA業務に影響を及ぼす場合がある。また、重複起票などの副作用も併発してしまう可能性もある。 テストプロセスの遅延： 管理者の記載内容の見落としといったヒューマンエラーが発生する場合がある。例えば、一覧表の不具合をBTSに転記するような運用であれば、見落とした分だけ不具合の修正期間が遅延してしまう。また、不具合の影響度や修正コストによっては、プロジェクト規模で影響を及ぼす可能性もある。 本記事では、スプレッドシートに記載された内容をGoogleAppsScripts（以下、GAS）を使用してチャットツール（テスト関係者のチャットグループ）に通知することで、上記のような問題を解決する試みをご紹介したいと思います。業務の最適化や効率化などに少しでもご活用いただけると幸いです！ ※ </Sqripts> では、以下のようにGASに関する記事もいくつかあるので、ご興味のある方は是非ご覧ください！ 業務改善にはコレ！＼Google Apps Script／ Google Apps Scriptを使ってGoogleスプレッドシートとCloud SQLを連携 GoogleAppsScriptを使ってテスト項目書の体裁を一発で整える 事前準備 1. スプレッドシートを用意する それでは早速解説していきます。まずはじめに、前提条件としてチャットツールへの連携元が必要となるため、スプレッドシートにて下図のような表を作成しました。こちらに記載された情報をピックアップして通知させていきたいと思います。 2. チャットツールにアプリを追加する 次にスプレッドシートの連携先となるチャットツールにアプリを追加しましょう。今回はSlackを例に、付属アプリである「Incoming Webhook」をご紹介したいと思います。 ※GoogleChatでも同様に、「Webhook」というアプリを追加することで連携可能です。 Incoming Webhookの追加方法 1.　対象のグループのチャンネル詳細設定の「インテグレーション」タブからアプリを追加します。 2. 「Incoming Webhook」を追加し、インテグレーションの設定を行います。設定した内容は保存しておきましょう。 各設定の概要は、以下の通りです。 チャンネルへの投稿 ：通知先対象のチャンネルを指定します。（上図では「通知先のチャンネル」というグループを指定しています。） Webhook URL ：アプリのユニークなURLです。GASで連携する際は宛先としてこのURLを指定します。 説明ラベル ：用途などを自由に記載することができます。 名前をカスタマイズ ：投稿時の名前を設定することができます。 アイコンをカスタマイズする ：投稿時のアイコン画像を設定することができます。（今回は「</Sqripts>」のアイコンを設定してみました。） 以上で事前準備は終わりです。 コーディング＜基本編＞ 続いて、スプレッドシートからGASを起動し、コーディング作業に入りましょう。GASは、スプレッドシートの拡張機能タブ ＞ Apps Script から起動することができます。 1. 対象のスプレッドシート・シートを取得する はじめに、実行対象となるスプレッドシートを取得しましょう。関数名は「chatNotice」としています。 function chatNotice() { //対象のスプレッドシートの取得 const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const sheet = activeSheet.getSheetByName(activeSheetName); 「getActiveSpreadsheet」メソッドと「getActiveSheet」メソッドを活用し、アクティブ状態のシート（スプレッドシート上で現在開かれているシート）を実行対象となるようにコーディングしているので、シート名に依存せずに実行することができます（間接参照）。言い換えれば、実行対象以外のシートがアクティブだった場合にも処理が走るので、少し注意が必要です。 2. 記載された内容を取得する 次に、事前準備で用意したスプレッドシートのNo.2（芥川 龍之介）の情報を直値で取得してみましょう。 //記載内容の取得 const info = sheet.getRange(4, 3, 1, 3).getValues().flat(); 「info」という一次元の配列変数を定義し、記載内容を格納させます。（スプレッドシートに対する「4」行目の「3」列目から「1」行単位で「3」セル分取得する　⇒　info[0] = 1915, info[1] = 芥川 龍之介, info[2] = 羅生門　となるイメージです。） 3. 送信内容を設定する 続いて、2で取得した情報を活用し、送信する内容を設定します。 //送信内容の設定 const msg = ( "スプレッドシートに記載された内容を送信してみよう！" + "\\n" + "\\n" + "▼記載情報" + "\\n" + "・発表年　 ： " + info[0] + "\\n" + "・著者　　 ： " + info[1] + "\\n" + "・タイトル ： " + info[2]); このあたりはお好みで加工することができます。今回は下記のような内容になるように設定してみました。 4. 設定した通知内容を送信する 最後に、設定した通知内容をPOSTするメソッドをUrlFetchAppと呼ばれるクラスを用いて記述していきます。 //取得した情報の送信 const message = { 'text': msg } const options = { "method": "POST", "contentType" : "application/json", "payload": JSON.stringify(message) }; const result = UrlFetchApp.fetch('事前準備のインテグレーション設定で生成したURL' , options); } 以上でコーディングは完了です。 実行結果 GASの実行結果がこちらです。 無事に送信されました！インテグレーションの各設定や記載情報も想定通りになっています◎ 以上が基本的な連携方法となります。 コーディング＜応用編＞ 最後に、QA業務での活用事例をご紹介します。QA業務ではしばしば、テスト設計時における仕様などの質問を「QA管理表」、またはテスト実施時における不具合を「不具合管理表」として、スプレッドシートに一覧化して記載する場合があります。 応用編ではこういった場面を想定し、不具合管理表を例に、不具合情報を抜粋して通知する方法をご紹介したいと思います。 対象の不具合管理表 対象の不具合管理表として、下図のような内容を用意しました。 今回は概要レベルで通知する用途を想定しているので、「起票日」「起票者」「タイトル」の3点をピックアップし、チャットグループに送信したいと思います。（「ステータス」や「詳細」は、通知内容としては冗長になりかねないので省略しています。） 送信エリア 上記を実現させるために、B2～C3セルに「 送信エリア 」を設けました。 B2、B3セルの「 No. 」に、スプレッドシートの「データの入力規則」を使って、一覧表で該当するNo.を プルダウンリスト形式で出力する処理を入れています。 また、A列のNo.には「=IF(ステータス=””,””,ROW()-ROW($A$5))」といった関数を記述しているため、未記載の不具合といった不要なNo.を出力しないように制御しています。 C2、C3セルの「 送信ボタン 」ではボタンの図形を描画し、そこにGASを割り当てています。 したがって、不具合が記載されたとき、不具合の起票者が自ら記載した不具合のNo.をB2セルの「No.」で選択し、C2セルの「送信」ボタンで関係者のチャンネルに投稿するような運用を想定した内容となっています。 コーディング内容 基本的には「コーディング」章で紹介したコードとあまり変わりませんが、応用編として少しだけ手を加えています。詳細は下記で解説します。 /** - 新規に記載した不具合をSlackに送信する。 - 送信する情報は以下3点。 - ・起票日[data] - ・起票者[tester] - ・タイトル[title] - / function bugNotice() { //対象のスプレッドシートの取得 const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const sheet = activeSheet.getSheetByName(activeSheetName); //不具合情報の取得 const bugNo = sheet.getRange(3, 2).getValue(); const bugInfo = sheet.getRange(bugNo + 5, 4, 1, 3).getValues().flat(); //通知内容の定義 const data = Utilities.formatDate(bugInfo[0], 'JST', 'yyyy/MM/dd'); const tester = bugInfo[1]; const title = bugInfo[2]; //通知内容の設定 const msg = ( "不具合が起票されました。" + "\\n" + "\\n" + "▼記載情報" + "\\n" + "・起票日　 ： " + data + "\\n" + "・起票者　 ： " + tester + "\\n" + "・タイトル ： " + title); //確認ダイアログの表示 const confirmdlg = Browser. msgBox("送信確認", "Slackに以下の内容を送信しますか？" + "\\\\n" + "\\\\n" + "▼記載情報" + "\\\\n" + "・起票日　 ： " + data + "\\\\n" + "・起票者　 ： " + tester + "\\\\n" + "・タイトル ： " + title, Browser.Buttons.YES_NO); if (confirmdlg == "yes") { ; } else { return false; }; //取得した情報の送信 const message = { 'text': msg } const options = { "method": "POST", "contentType": "application/json", "payload": JSON.stringify(message) }; const result = UrlFetchApp.fetch('事前準備のインテグレーション設定で生成したURL', options); } 不具合情報の取得 //不具合情報の取得 const bugNo = sheet.getRange(3, 2).getValue(); const bugInfo = sheet.getRange(bugNo + 5, 4, 1, 3).getValues().flat(); 対象の情報を取得するために、はじめに「bugNo」という変数を定義し、getRangeメソッドを使って3行目かつ2列目である「送信エリア」の「No.」の値を取得しています。 続いて、「bugInfo」という一次元の配列変数を定義し、記載内容を格納させます。（スプレッドシートに対する「プルダウンリストで選択した値＋5」行目の「4」列目から「1」行単位で「3」セル分取得する　⇒　「送信エリア」の「No.」で「1」が選択されていた場合は、bugInfo[0] = 2023/10/01, bugInfo[1] = テスト 太郎, info[3] = ○○画面で△△したとき✕✕になる　となるようなイメージです。） 通知内容の定義 //通知内容の定義 const data = Utilities.formatDate(bugInfo[0], 'JST', 'yyyy/MM/dd'); const tester = bugInfo[1]; const title = bugInfo[2]; 「bugInfo」の内容を分かりやすくするために、配列の値をそれぞれ別の変数に置換して定義しました。また、取得した値が年月日の場合は、GASの特性上、文字列に変換する必要があるため、「Utilities」メソッドで日付形式（yyyy/MM/dd）に変換しています。 確認ダイアログの表示 //確認ダイアログの表示 const confirmdlg = Browser. msgBox("送信確認", "Slackに以下の内容を送信しますか？" + "\\\\n" + "\\\\n" + "▼記載情報" + "\\\\n" + "・起票日　 ： " + data + "\\\\n" + "・起票者　 ： " + tester + "\\\\n" + "・タイトル ： " + title, Browser.Buttons.YES_NO); if (confirmdlg == "yes") { ; } else { return false; }; 送信時の誤爆を防ぐために、確認ダイアログも実装してみました。ダイアログで「はい」を選択すると送信され、「いいえ」または「✕」ボタンを選択すると送信されない処理を記述しています。 インテグレーションの設定 インテグレーションの設定も併せて少しだけ変えました。 実行結果 実際に「不具合 No.3」を対象にして送信してみましょう！ 「送信エリア」の「No.」のプルダウンリストから「3」を選択し、 「送信」ボタンを押下すると、、、 スプレッドシート上に確認ダイアログが表示されました！ 確認ダイアログで「はい」を押すと、、、 無事、Slackに不具合内容が投稿されました！スタンプ等も活用するとより効果的に活用できそうです。 以上、より実践的にQA業務を意識した使い方のご紹介でした！ おわりに 「コーディング＜応用編＞」でご紹介した方法であれば、チャットグループ内に所属しているプロジェクトリーダー、テスト設計者やテスト実施者、あるいは開発者などの各プロジェクト関係者に対して、一律で仕様質問や不具合などを概要レベルで通知することができるため、「はじめに」でご紹介した例のような情報の偏在や属人化などが解消できたり、スピード感を持って課題を解消できたりする場合があります。その反面、質問や不具合が頻出するプロジェクトでは、通知が煩わしく感じることもあるので、使用する場合は適切な場面や使い道を見極めることを心掛けましょう。 ※もちろん、使用前にはステークホルダーに事前に確認を取るなどプロジェクト関係者への許可や配慮も必要です！ また、こうしたスプレッドシート × GAS などの機能を上手く組み合わせて、業務の最適化や効率化を図り、よりよいQA業務を実現させていきましょう！ The post スプレッドシートとチャットを連携してQA業務を効率化しよう first appeared on Sqripts .

私は仕事柄、所謂炎上プロジェクトの火消しや、前任PMが胃潰瘍で離脱して…といった「修羅場」をなんとか制御してクローズまで持っていくといった役割を担うことが多くあります。 ここで質問です、プロジェクトを成功させるには 炎上プロジェクトを鎮火する技術 プロジェクトを炎上させないようにする技術 どちらが大切だと思いますか？ １は火消しの技術が求められ、燃えている事や人を助けて、どうにかこうにかプロジェクトを纏めあげるテクニック。対して２はそもそもプロジェクトが炎上しないように先手を打ってコントロールするテクニックです。 炎上案件には社内の関心が集まり、立て直しがフォーカスされ、エース級やカネも投入、うまく鎮火されたなら盛り上がりもする「目立つ」プロジェクトです。他方、比較的スムーズに進むプロジェクトは目立たない存在です。要求事項を整理し、QCDを守って予算通りに納品しても「はい、OK」となって、大きな事象を発生させなかった、という功績はクローズアップされません。ですが、 本当に現場に求められ、プロジェクトが成功したと言えるのは２ です。 火消しは派手で目立ちますし、高難度で重要なテクニックです。同じように、 火を起こさないように見守っては火種を消してゴールすることは、往々にして目立たず疎かにされがちですが、その実践には多様なテクニックと理論・工夫が散りばめられ ています。 本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜参考と準拠＞ 本連載はプロジェクトマネジメントの国際規格であるISO21500:2012及びプロジェクトマネジメントの業界標準資格であるPMP ® （Project Management Professional）に準拠しながら、筆者の整理を加えた内容で記載しています。加えて、プロジェクトマネジメント講師としての経験や、プロジェクト現場で実行支援を行う中で得られた「実践的」なノウハウを盛り込んでいきたいと考えています。 プロジェクトとは、プロジェクトマネジメントとは プロジェクトの語源 「プロジェクト」の語源はラテン語で、PRO＝前方に（未来）、JECT＝投じる、投げるという意味があります。仕事でいえば、まさに前にある未来の目標に向かってアクションを投じていく姿そのものがPROJECTという単語のありようになります。 プロジェクトとは プロジェクトは「独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務」と定義され、特に 有期性・独自性 という点がプロジェクトの特徴と言えます。 独自性とは「新しい要素（過去に経験したことがない要素）が含まれる目的や目標」を指しますが、なにもまったく初めて！という大層なものである必要はありません。有期性とは「開始日と終了日が明確になっていること」であり、その期間において成果物を生み出す活動を行います。この２つの要素が入っていれば、たとえ「XXプロジェクト」と銘打たれていなくてもプロジェクトの性質を持ち、当然プロジェクトマネジメントの知識や技術を適用させることができます。プロジェクトと聞くと大規模インフラ事業やIT業界を想像することが多いですが、日々の業務或いはプライベートの活動の中にもプロジェクトは存在しています。例えば旅行の計画や引越し、就職活動なども独自の目的と期限を持つプロジェクトと言えるでしょう。また近年、企業や組織はその厳しい環境変化から絶えず独自性が求められるようになっており、 規模や業界に関わらず様々な業務がプロジェクト化してい ます。 プロジェクトマネジメントとは だれもが日常的にプロジェクトの参加者であるならば「改めてプロジェクトマネジメントを知る必要なんてあるのか？」「なんとなくできるから（できそうだから）大丈夫」というとそうではありません。プロジェクトを「マネジメント」することは、プロジェクトを 「その技術や経験を適用しながら、適切にヤリクリ（マネジメント）」 する必要があるからです。 プロジェクトマネジメントとは「プロジェクトの要求事項を満足させるために方法、知識、スキル、ツールと技法をプロジェクト活動へ適用すること」と定義されます。つまり、プロジェクトをどのように遂行するか計画を立て、プロジェクトの目的を達成できるようにコントロールしていくことです。またプロジェクト目標は未来にあるため、常に 「不確実性」 が存在します。その不確実性の中でいかに「目的・目標の達成角度を高める」か、その準備をしておきましょう。何のマネジメントもしなければ、プロジェクトは100％失敗します。 またプロジェクト実行時に適切な手法や方法を用いず実現可能性の低い目標設定を行う、適切な計画ができないということも起こりえるでしょう。 適切なプロジェクト実行に関する技術や技法は、プロジェクトの円滑な活動の必須要素 です。 プロジェクトやマネジメントの実務経験がある方でも、さらにその活動精度を高めるために、引き続き意識してそのプロジェクトマネジメントスキルを高めていっていただきたいと願っています。 プロジェクトマネジメントと定常業務マネジメント プロジェクトは「期限」を持つ有期的な活動です。その対の関係にあるのは定常的な業務、つまり無期的な活動です。 企業はこの有期的な活動と無期的な活動、２つの活動の組み合わせにより価値を生み出しながら事業運営を行なっています。 プロジェクト完了後はその活動から生み出したものを「定常業務化」つまり安定的に運用できるように受け渡します。「プロジェクトが終了したけれど、ずるずるタスクが残っている」「定常業務化したはずがうまく回らない」といことをよく耳にしますが、これらの受け渡しがが上手くいっていないケースです。 プロジェクト→定常業務という流れと定着化を意識 して各活動を進めましょう。 プロジェクトにおける制約と不確実性 プロジェクトは独自であるが故に情報や経験が十分でないにも関わらず、期限までに約束した成果物等を完成させなければなりません。プロジェクトが向き合う「敵」とも言えるのはこの不確実性であり、プロジェクトマネジメントの本質は「不確実性の中で活動をヤリクリすること」と言えます。 プロジェクトには多くの制約条件がありますが、中でもQCDが三大制約条件と言えます。この制約条件をマネジメントすることがプロジェクト成功の鍵です。また不確実性も確率論的な不確実性、曖昧さによる不確実性、複雑さによるものなど様々です。残念なことにこの不確実性の検討（洗い出し）や対処が後回しや、行われないことが少なくありません。不確実性の検討は容易な作業ではありませんが、それ以上に「もしこんなことが起きたら大変だ」と想像力を働かせ 「正しいマイナス思考」 を受け入れる体制が必要です。 プロジェクトでは制約や不確実性に対応する「完全な正解やマニュアル」は持っていません。プロジェクトの開始前から制約条件に優先度を付けたり準備することや、時には「実現不可能なプロジェクトを開始しない」という判断も必要になることを覚えておいてください。また、不確実性への対処は「リスクマネジメント」の回で触れていきます。 プロジェクトマネジメントのライフサイクル プロジェクトマネジメントの手法として代表的なのものが予測型ライフサイクルと呼ばれるウォーターフォール型（WF）適応型ライフサイクルと呼ばれるアジャイル型の２つです。そのほかに反復型・斬新型・ハイブリット型などがあります。 ウォーターフォール型は、プロセスやタスクを初期に計画した順番で完了させ、成果物を生み出す手法です。比較的長期のプロジェクトや明確な成果物がある場合に使われます。 アジャイル型は、優先的な機能や成果物を選択しながら２-４週間の短い期間で完成、その繰り返しで成果物を生み出す手法です。日本全体ではまだウォーターフォール型開発がマジョリティとして使われており、「これから」プロジェクトマネジメントを学ぶという方はこれらウォーターフォール型から習得するとよいでしょう。 プロジェクトの環境（組織のプロジェクトマネジメント） 複数のプロジェクトを運営して様々な経営課題の対処や戦略実現を目指す際に、それらを効率的にマネジメントする体制として「プログラム」や「ポートフォリオ」があります。 出典：OPM3を基に筆者が作成 プログラムとは複数の関連するプロジェクトや活動のグループです。ポートフォリオとは一般的に複数のプログラムやプロジェクト、活動のグループを指します。これらのグルーブにおけるマネジメントをそれぞれ「プログラムマネジメント」「ポートフォリオマネジメント」と呼びます。それぞれの効率的なマネジメントとなるように、プロジェクトやプログラム、その他の活動は組織戦略と整合が取れているか、プロジェクトやプロジェクトの成果は戦略目標達成に貢献しているか、作業状態の確認、限られたリソースの状況下でプロジェクトの優先順位を明確にし、整合のとれたリソース配分などを行います。 プログラムの性質 プロジェクトマネジメントが普及する中で、さらに複雑な概念であるプログラムが注目されています。プログラムとは複数の関連するプロジェクトや活動のグループとお伝えしたように、プロジェクトとプログラムは共通点がありますが異なる特徴も持っています。例えば 反復型の活動が含まれる場合があり定常業務に近い性質を持つ プロジェクトは目的の成果物を生み出したらその使命を終え解散するのが原則だが、プログラムはかならずしもそうではない などです。プログラムが解散するのはいつかとういうと、持っている戦略的な部分、目標自体が新しい目標に上書きされてプログラム自体の使命を終えた場合か、目標を達成する仕組みが完全に社会や市場、システムに定着して、これ以上の監視が必要なくなったような場合です。このように 成果の実現だけでなく、その維持・管理にも使命を負うというのがプログラムの特徴 の一つといえます。またそもそもプログラムには有期性が怪しいものがあります。プログラムでも通常は目標達成時期が決められていますが、プロジェクトと比較すると大変緩やかで「期限」と呼べるほど強い制約事項ではないケースが殆どです。 担当するプロジェクトの環境を確認した時、どのプログラムやポートフォリオに属しているか、あるいは属していないか、属している場合はプログラムマネージャーやポートフォリオマネージャーとの連携を図りながらプロジェクト活動を推進することが必要です。 さいごに 今後はリモート環境でのプロジェクトがスタンダードとなりグローバルプロジェクトの割合も増えていく中で、プロジェクトマネジメントという「共通言語としてのフレームワークや方法論」の重要性はより高まります。当然市場や社会情勢の変化の激しさに合わせて、プロジェクトマネジメントの方法論もアップデートが続いていくでしょう。まずは基本を押さえて、日々のプロジェクト、プロジェクトマネジメント活動へ適用しましょう。 今回は初回として、プロジェクトマネジメントとは何か？という大枠をみなさんと共有しました。 次回は、「PMの役割や必要な準備」についてお話しします。 The post 【第1回】プロジェクトマネジメントとは何か？ first appeared on Sqripts .

はじめまして、QAコンサルタントのしろです。 システムのステークホルダーやプロダクトオーナーから「品質ってどうなの？」って聞かれたとしたら、定量的なデータを示した説明をするのが良いですよね。「定量的」とはよく聞きますが、改めてソフトウェアの品質を説明するための定量的な指標をおさらいする意味で、色々なところで使われているソフトウェア品質の指標を一部ではありますが、ご紹介します！ 品質を表すために使われる定量的指標たち ソフトウェア開発の見積などで必要な指標など コスト これは様々な活動に対する必要な金銭、時間などの事です。こちらは品質自身を表す指標として使う事はないですが、コスト対効果など様々な形で登場します。特にシステム開発コストは品質を作るうえでも必要になりますのでしっかりと把握・確認しておくことは必要です。コストに該当するものは金銭、時間以外に心理コスト、認知コスト、肉体コストもありますが、定量指標としては使用することは難しいと思います。 工期 こちらは時間(期間)ですね。これも品質自身を表わす指標として使う事は余りないかと思います。しかしプロジェクトの期間は品質に影響を与える非常に重要な要素ですので明確にしておきたいです。 特に工期の遅れや、延長した。などの場合、品質にも影響を与えている可能性が高いため、その理由を確認しシステムへの影響を把握しておくことは、後の振り返りなどで必要になります。 工数 人時、人日、人月: 実際に作成に関わった時間のことですね。期間、リソースなどの要素をかけ合わせて算出します。1人が1時間稼働すれば＝1人時ですね。後は掛け算です。 勿論、これだけで品質の良し悪しが分かる訳ではありませんが、当初計画時の工数を大きく超えるような場合は、品質に何かしらの課題を抱えていると考えられます。 規模 LOC (Line of Code): お馴染みのコードの行数です。KLOC(キロ:1000行)やMLOC(メガ:100万行)もありますね。これらは測定方法、使用言語、作成者の書き方でかなり行数が異なるので信頼性に欠ける事がありますので、継続的に測定し品質指標として使う場合コーディング規約や測定ツールを整備してこの指標の数値の信頼度を向上させる必要があります。 LOC取得環境が整備されていれば最も使いやすい指標だと思います。是非とも活用することを検討してみてください。 FP (Function Point): 実装する機能に基づいてシステム規模を数値化する、言わずと知れたFP法による規模の測定です。ISO/IEC 20926:2009で規格化されています。FP計測手法として、IFPUG法、COSMIC法、フルファンクションポイント法、フィーチャーポイント法、MarkⅡ法、NESMA概算法、SPR法などがあります。 一番使われているIFPUB法によるFP計測の精度を向上させるには、設計仕様書が明確である必要があります。また更にFP計測を行うには工数もかかる。などもあり利用は簡単ではありません。しかしプログラムに実装される機能を一定の方法で数値化する事は、品質を測る上ではかなり有用な指標となります。 参考までにIFPUG法を使ったFPの計算手順は以下の通りです 扱うデータを外部入力(EI）、外部出力(EO)、外部照会(EQ)、内部論理ファイル(ILF)、外部インタフェースファイル(EIF)の５つのタイプに分類する 扱うデータごとに、「データ項目数」とそのデータに関連する「レコード種類数」を求め、それに従ってそのデータのファンクションの複雑さを３段階(低、中、高)に分ける 各データに、ファンクションの複雑さに応じた重み係数を掛けて合計し、システム全体の未調整FPを求める これまでの計算とは別に、対象とするシステムの特性を14の観点から０～５の６段階評価し、合計する(この合計値をXとする) システム特性係数＝ 0.65 ＋X × 0.01 を計算する FP ＝システム特性係数×未調整FP UCP (Use Case Point): 実装するユースケースから求めるポイントでシステム規模を計測する方法で、UML(Unified Modeling Language)で表されたシステムの機能的要求を利用します。 既にUMLで開発するプロジェクトでは導入は比較的容易だと思います。過去の実績情報などが揃っている場合にUCPと他の指標と比較するなどで色々な角度から表すことができると面白いですね。 作業の主体となるアクターとユースケースを洗い出し、アクターを利用してユースケースとアクターのインターフェースの複雑度を３段階(単純、普通、複雑)で評価します インターフェースとユースケースのポイントを合計して「UUCP (Unadjusted Use Case Point): 未補正ユースケース・ポイント」とします システムの技術的要因係数複雑度と，プロジェクトを取り巻く環境要因に関する複雑度(環境的な複雑度)を評価し、それをUUCPに反映しUCPを決定する 画面数、帳票数、ファイル数、バッチ数 このまま画面の枚数などの数値ですが、画面や帳票に含まれる仕様の複雑度は表せていません。（ゆえにFP法などの利用が必要となる。）単なる表示だけの画面と、他画面/機能と連携したり、入力項目の多い画面や、データチェックが必要な項目の他にデザイン上の複雑さなどは、画面数だけでは表現できていません。指標の一つの参考には使用できるかもしれませんが、品質を説明するための指標としての使用は難しいと思います。しかし実際の見積の段階などで、画面数や帳票数から全体工数やFPの概算試算ができたりします[JUASレポート ※1 ]。実績値との差異などの比較対象や見積参考の利用など使えるシーンも多いので収集する事をお勧めします。 全体工数（人月）＝ 112.97 ＋ 0.81 × 画面数 + 0.42 × 帳票数 FP ＝ 91.54 ＋ 13.41 × 画面数 ＋ 40.33 × 帳票数 JFS (JUAS Function Scale): システムの規模を推定するために JUAS が独自に作成した指標。「画面数＋帳票数×2/3」で算出され、既存の見積もり方法に比べ簡易に規模を推計することができます。 過去、私はこの指標を使った経験はありませんが指標となるものが何もない場合には参考としてみても良いかと思います。 ストーリーポイント: 書籍『アジャイルな見積りと計画づくり ー 価値あるソフトウェアを育てる概念と技法』 ※2 では、「ストーリーポイントとは、ユーザーストーリーやフィーチャー、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような、ひとまとまりの作業に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイントを付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる。 ストーリーポイントの数値は、ストーリー全体の規模をあらわす。ストーリーの規模を定義するための数式は存在しない。 ストーリーポイントによる見積りが示す値は、フィーチャーを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである」と定義されています。 アジャイル開発にてバックログにストーリーポイントを設定し、スプリントの中で作成できるストーリーポイントの合計をベロシティとして利用をしており、チームのスプリント工数＝ベロシティと理解することもできます。 ソフトウェア開発の作業に関わる指標など レビューに関わる指標 レビューは、どの工程で何をレビューするのか。また何をもってレビューを完了とするのかを決めて実施する必要があります。ただ工程に組み込まれているからといって形式だけ実施しても意味はないでしょう。レビューによって得られる情報を説明します。 レビュー回数、時間: レビューの実施回数、のべ時間です。ウォークスルーレビューなどは参加者の数だけレビュー時間(=工数)は増加します。例えば3人で3時間かけてレビューをすると、9人時のコストを消費します。「レビュー指摘のエラー修正コスト」と、「テストでバグとして修正されたコスト」が比較対象となり、「9人時」より大きなコストが削減されていれば良い訳です。レビューに時間をかけたから良いという事ではなく、「早期に問題を発見することでコスト削減に寄与する」ことが目的となります。 レビュー対象規模: レビュー対象となるドキュメントをページ数で表すことが多かったですが、ここ最近はレビューの対象となるドキュメントもwikiだったり、NotionやMiroなどのSaaSで作成されることも増えておりページ数で表せない事も多くなりました。アジャイル開発では、機能単位でストーリーポイントを使うこともあります。 「設計書」というドキュメントに囚われず、レビューの対象物の規模が適切に指標として利用できればよいと思います。指標を取得することが目的ではないのです。 レビュー品質メトリクス: レビュー実施にて検出した指摘件数を利用して精度を測る指標です。 レビュー工数密度 =  レビュー時間 ÷ レビュー対象規模 (または規模) で算出します。 短いとレビューの不足、長いとレビュー実施方法に課題があると推測されます。 レビュー指摘密度 = レビュー指摘数 ÷ レビュー対象規模 (または規模) で算出します。 例えば、規模が大きいのにレビュー指摘数が少ない場合に、ドキュメントの品質が高いためなのか、レビュー実施で指摘ができていないのかを確認することで、再レビュー判断や後工程での品質予測に利用することができます。 レビュー指摘効率 ＝ レビュー指摘件数 ÷ レビュー時間 で算出します。 レビュー工数に対してどれだけの指摘数の割合があるのかを示しています。レビュー指摘密度と合わせて判断することで、ドキュメント品質やレビュー実施方法の判定をすることができます。 テストに関わる指標 テストにより検出した不具合数は品質を測る上でQAエンジニアにとって非常に重要な要素・指標となります。ただ、いわゆるバグ情報だけではなくそれに属性や検出工程などが不可される事で深く分析することが可能になりますので、ここであらためて説明をします。 テストケース数: 件数で表します。ケース数は内容の粒度によって件数のブレが生じる要因となります。ケースに記載するテスト観点(確認内容)の粒度で合わせることでブレはなくなるでしょう。 開発プロセスで工程が明確に分けられている場合、テスト工程ごとに実行するテストケースが分かれていると思いますので、工程ごとにテストケース数を測定しましょう。それぞれ対象となる開発工程での品質を確認することにつながり、工程ごとに細かく対策を検討できるようになります。 不具合数、不具合起票数: いわゆるバグ数です。テスト実施中に検出したバグの数はプロジェクト内で管理されています。もし管理されていないならバグ起票の登録項目を含めたプロセスを作るチャンスです。後々の分析も考慮して作りましょう。 こちらもテストケース数と同様に工程ごとに検出されたバグ数を計測しましょう。これでそれぞれの工程の分析はより完全なものに近づくでしょう。また起票数＝バグ数ではありません、またテストケース外で検出されるものもあります。これらの理由に品質改善の種が埋まっています。これを上手に使い改善に利用しましょう。 密度 テストケース密度 = テストケース数 ÷ 規模 で算出します。 不具合密度 = 不具合数 ÷ 規模 で算出します。 上記の2つの指標により、開発システムの品質とテスト自体の品質も表すことができます。テスト密度が低く、不具合密度が高い場合に想定されるのは開発システムの品質に疑義がある状態になります。その逆はテスト密度が高く、不具合密度が高い場合はテスト自体の方法に問題がないかを確認する必要があると思います。 まとめ プロジェクトに関わったQAエンジニアやプロダクトオーナー、プロジェクトマネージャーはこれらの定量的指標を上手く使って品質を説明できる様に、どれを使うのかを明確にして、指標の集計や収集を可能にしなければいけません。「品質が良くない」など漠然とした説明ではどこがどの様に良くないのか分かりません。何を改善するべきか分からないですね。定量的指標を知り、どう使うのかを考えてみてはいかがでしょうか。よりよいプロダクト開発のための一助となればと思います。 APPENDIX:参考資料 ※1　一般社団法人 日本情報システム・ユーザー協会 ソフトウェアメトリックス ※2 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29） The post 品質を説明するには(定量的指標編) first appeared on Sqripts .

​「1人目QA」というワードを、2020年ごろからよく聞くようになりました。 ​もちろんそれ以前から、組織の中で1人目のQAとして活動をされてきた方はたくさんいました。 しかし、QAエンジニアという職種の認知が広まったことで「いままでQA専門の人は居なかったけど、ウチにも要るよね」と思いはじめた会社が多くなり、採用募集や実際に1人目QAとしてお仕事をする方も増えたように思います。​ 私自身も、現在は1人目のQAとして試行錯誤をしている身です。 ​そこで、本記事からは“1人目QAとしての立ち回り”シリーズとして、1人目のQAに求められていること、実際にやってみて大事だと思ったことなどをお伝えしていきます。​ なお、本記事では「QAエンジニア」を指して「QA」と表現します。 1人目QA、とはなにか ​まずはタイトルにもある「1人目QA」がそもそも何なのか、から考えてみましょう。 ​会社の1人目なのか、部署の1人目なのか、などは組織によってバラバラですが、共通するのは「前任者や同僚のQAが居ない状態」に新たに入ってきたQAエンジニアという点です。 前任者や同僚が居ないということは、 テストや品質保証を開発者が試行錯誤しながら行っている、テストや品質保証の体制が整っていない QAの具体的な役割やロール設定がない ということです。つまり、1人目QAはプロダクトのテストや品質保証業務と並行して、これらを決める・つくることも担う存在、といえます。 需要が増えている1人目QA ​冒頭にも触れたように、2020年ごろからX（旧Twitter）上でも1人目QAに関する言及が増えてきており、求人サイトでも「QA立ち上げメンバー」や「1人目QA」などを募集する企業を目にするようになりました。 ​要因はさまざま考えられますが、そもそもの「QAエンジニア」というロールの認知・必要性の理解が進んできているため、募集する企業が増えた、と考えられます。それに伴って、「今はQAエンジニアやQA専任の組織はないけれども、新たに立ち上げをしたい」という企業も増えてきました。 ​QAチームをつくるうえで、1人目のQAはとても重要です。 ​そのチームや組織のカルチャーを創る存在でもありますし、組織におけるQAや品質への期待を把握しつつゴールとタスクを具体化しながら進めていく、という高難度の仕事を担うことになります。 開発組織へのアプローチの仕方 ​そんな難度の高い仕事を担う1人目QAについて、本記事と今後の連載を通じていくつかの切り口で分類を試みます。 ​今回は、1人目QAによる、開発組織へのアプローチの仕方について考えます。 ​1人目QAが新たにJoinして開発組織と一緒に業務を行う場合、考えられるパターンは大きく2つあります。 ​パターン1:特定のチームに入り込む ​​ひとつは、特定のチームに入り込んで、そのチームの専任QAとして実務を行うパターンです。 ​開発しているプロダクトが一つだけのところに1人目のQAとして入る場合や、専任QAが居ない状態で複数プロダクトを開発していたうちの1プロダクトに専任QAとして入る場合などがあります。 ​特定のチームに1人目のQAとして入る場合、それまでのテストのやり方や品質に対する考え方などを把握しつつ、そのチーム・プロダクトにとって最適な品質向上のプロセスや仕組みづくりを担っていきます。 同時に、そのプロダクトのリリースに向けた普段のテストや改善活動なども行います。 ​チームや組織によって求められることはさまざまですが、例として ​テスト計画・分析・設計・実装・実行・報告までの、テストプロセスに沿ったテスト活動全般 テストプロセスの整備 探索的テストによる “バグ出し” チーム内の不具合管理や分析 要件や設計、単体テスト等のレビュー 開発者に対するテスト技法や品質についての考え方のレクチャー テスト自動化 ​などがあります。 ​実際に1人目QAとしてJoinする方にとってのパターン1のメリットは、開発チームと密に連携できる、プロダクトの仕様や過去の経緯などをキャッチアップする範囲が狭めという点が挙げられるでしょう。 ​範囲や対象がある程度絞りつつ、1人目QAとしての取り組みをタスクレベルに分解・取り組みがしやすい一方で、ある程度短期的な成果が求められることもあります。 パターン2:複数チームに広く浅く関わる もうひとつは、複数のチームやプロダクトに横断的に関わり、兼務のような形で外から品質向上の手助けをするパターンです。 ​専任QAが居なかった会社において、組織全体として品質向上の取り組みを始めるために1人目QAとして入る場合や、社内のQA業務を外部の会社に依頼しているところに1人目の正社員QAとして入る場合などがあります。 ​こちらはパターン1とは異なり、より組織にフォーカスした働きを求められる傾向にあります。 ​たとえば ​組織全体でのテスト・QA活動状況の把握 「QAエンジニアとは」の認知向上 2人目3人目のQAエンジニアの採用関連業務 「品質基準」や「テスト標準」など、組織全体に関連するルールや基準の制定および普及 チームをまたいだテストプロセスや不具合の管理・分析方法の設定 ​などがあります。 ​こちらのパターン2の1人目QAとしてJoinするメリットは、パターン1と比べてより広い範囲に携われること、中長期的な視点で品質向上施策やチームをまたいだ土台づくりに着手できることなどがあります。 ​一方、横断的に関わるQA側が積極的に開発チームに対して働きかけをしていかないと、品質向上施策がなかなか進まないなど、成果が出づらくなってしまう面もあるでしょう。 ​2つのパターンを行き来する場合も ​実際に私自身も「1人目QA」として仕事をしており、パターン2に近い形で動いています。 ​便宜上パターン1と2、という区別をしましたが、これらは完全に別物であったり、一方を選択したらもう一方は選べない、というものでもありません。状況によっては、それぞれを切り替えたり、ある程度両立させようとすることも考えられます。 ​たとえば私が所属する部門では、複数の開発部が存在しており、私が入社するまで専任のQAは居ませんでした。 そこに1人目のQAとしてJoinしたわけですが、最初に考えたのが「特定のチームに入り込んで動く（パターン1）のと、広く浅く全体をみる（パターン2）のと、どちらがいいだろう？」という点です。 ​最初はパターン2を選択して、各開発チームに対して少しずつ関わっていました。しかし、しばらく行ってみたところなかなか品質向上活動が前に進んでいない実感があり、これは特定のチームで成功事例を作らないと難しそうだと考え、パターン1に近い形に変更をしました。 ​その後、ひとつのチームに入り込んで活動をしつつ、そこで行った内容を他のチームにも共有することで「それならウチも」と声をかけてもらえるようになりました。結果として、再度パターン2の形に近づいています。 ​これはあくまでも私の例であり、これが正解ということはありません。組織規模や開発チームの文化などに応じて、つど考えていくことが大切です。 「1人目QA」が活躍するために、2つのパターンをもとに考えましょう ​今回は、1人目QAについての概要と、1人目としてJoinしたQAが開発チームに関わって活動していく際の2パターンについてご説明しました。 ​特定の開発チームに入り込む場合と、複数の開発チームに対して外から関わる場合。組織の状況や募集時の要件などによってどちらかのパターンに定まることもあれば、どちらかを選択したり行き来しながらQA活動を進めることもあります。 ​もし選択できる場合には、開発組織のマネージャーなどと「どちらのパターンでいくか」を一緒に考え、合意することが大切です。1人目QAとしてJoinした場合、もしくは1人目QAを迎え入れる場合は、いずれのパターンが適切かを考えてみてください。 The post 1人目QAの位置づけと、開発組織へのアプローチの仕方 first appeared on Sqripts .

はじめまして！ ヒロッシュです。 現在の業務はアジャイルQAとして、お客様先に常駐して業務を行なっています。 9/22に JaSST’23 Niigata が開催されました。今回、「QA組織に仲間を増やしていくときに大事なこと」「QAスキルアセスメントとオンボーディングで乗り越えた壁とこれから乗り越える壁」等、自身の常駐先に新規メンバーが配属された時にOJTとして役立つことがあるのではないかと思い、オンラインで参加してきました。 その中でも自身の現場で役立つと感じた、 「事例発表」 をピックアップさせていただき、学びの部分を共有させていただきたいと思います。 事例発表 事例発表は、 〚QAスキルアセスメントとオンボーディングで乗り越えた 壁とこれから乗り越える壁〛と題して、ミッツこと川満 勇哉さん （freee）とkenseiこと 本多 顕成さん （freee）が登壇されました。講演内容から得た「２つの学び」を以下にまとめます。 学び その１：OP(オンボーディングパートナー)と一緒に課題と目標を持って取り組んでいく 講演は、今年の4月に中途入社された川満さんが体験したfreee のスキルアセスメントとオンボーディングについての話から始まりました。 オンボーディングとは オンボーディングとは、新入社員をはじめ、中途採用社員など新しく組織に加わった社員の早期離職を防ぎながら、企業にとって有用な人材に育成する施策のことです。 オンボーディングとは？事例5選｜実施のポイントやメリットも解説 過去に川満さんご自分が体験してきたこととの比較を中心に以下の3点についてお話いただきました。 これまでの現場と比較してよかった所 オンボーディングに対してのQA組織の雰囲気 オンボーディングを受けた中で困った所 オンボーディングの雰囲気も話しやすくて良かったとのお話もされていました。グループチャットを活用して受講者仲間や先輩社員への質問がし易い環境が用意されていたのが良かったそうです。 また、困ったときにありがたかったこととして、OP(オンボーディングパートナー)の存在があるとのことでした。OPとは、オンボーディングを実施する側が受講者ひとりひとりの担当になる制度です。川満さんが受講者として「何から手を付けたらよいか」悩んでいるときに、OPに課題や目標を相談・共有できる環境があったことが良かったとのことでした。 私の現場では専任のOJTの担当を設けておらず、詳しい人に聞くといったことになりがちになっています。OPのような存在を現場で設定することで、以下の改善が図れると考えているので、今後取り組んで行ければと思います。 窓口が一元化されるので新規メンバーが質問しやすくなり、心理的安全性が担保された状態で教育を受けることができること 専任担当者にとっても後輩を指導する経験の場を与えられること 教える側と教わる側でしっかりコミュニケーションを取りながら不明点や心配事を乗り越えて、お互いに成長しながら学んでいける環境を作りたいと思います。 学び その２：オンボーディングを全て受けたから一人前というわけではない。 講演の後半は川満さんのOPでもある本多さんの担当となり、ご自身が入社したオンボーディングの体制が整っていなかったころと現在との比較、それとオンボーディングを実施する側の視点について以下の3点を中心にお話をしていただきました。 スキルアセスメント・オンボーディング導入以前のQA組織 オンボーディングの課題 スキルアセスメントの課題 今回は詳しく触れませんが、 ・オンボーディング導入以前の組織は開発チームにQAが⼊って密にコミュニケーションを取りながらテストをできるメリットがあったものの、各チームでのテストのやり方がバラバラだという課題があったそうです。 ・スキルアセスメントでは、自己評価で個人毎のブレが発生してしまうなどの課題があったそうです。 川満さんの3つのお話の中で一番大事だと感じたことは、オンボーディング受講者の課題としてあげられた、【オンボーディングを全て受けたから一人前というわけではない。】という部分です。これは、学んだことをハンズオンで実施しなければなかなかスキルとして身に付かないということです。 私の現場ではOJT期間以降は専任の担当者を付けることがありませんでした。が、OJT期間後も引き続き新規メンバーの業務にサブ担当を付けるなどのフォローを継続することで、成果と教育を効率よく実践できるようになるのではと考えています。 もちろん、一番大事なことは本人の学習意欲と積極性になると思います。 まとめ 以上、事例発表から得た学びをご紹介させていただきました。 今回オンボーディングの話を中心に取り上げさせていただきましたが、スキルアセスメントについても 湯本 剛さん（freee/ytte Lab）の基調講演で取り上げられています。 【QA組織に仲間を増やしていくときに大事なこと】と題して、QA組織の拡大を図る中で人員増加に適した組織作りの設計についてお話いただいています。 詳しくは以下をご参照ください。 JaSST’23 Niigata レポート 基調講演 セッション 1 「QA組織に仲間を増やしていくときに大事なこと」 オンボーディングについては色々な会社が試行錯誤して取り組んでいると思います。弊社でも取り組みを行なっておりますが、新規メンバーにより良い成果を出してもらうためにも、配属後のサポートもしっかりと行なっていきたいと改めて思いました。 継続的なサポートを手厚く行うにはサポート側のコスト面も意識しなければなりませんが、新規メンバーとより良い成果を出すために努力していきたいと思います！ 最後まで読んでいただきありがとうございました。 The post オンボーディングの現場活用のヒント見つけた！～JaSST’23 Niigata 参加レポート～ first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 今回は、私がReact開発で普段利用しているアクセシビリティのチェックツールについてご紹介したいと思います。 アクセシビリティとは アクセシビリティとは、情報へのアクセスを全ての人が平等に行うことができる状態を意味します。ウェブアクセシビリティは具体的には、視覚・聴覚などの障害を持つ人々や、高齢者などがウェブサイトやアプリケーションを利用する際に遭遇する可能性のある困難を解消することを目指します。 React開発においても、アクセシビリティの確保は重要な観点となります。この記事では、その実現をサポートする一部のツールを紹介します。 アクセシビリティのチェックツール esl int-plugin-jsx-a11y React開発においては、コーディングの初期段階からアクセシビリティの問題を特定することが重要です。その一助となるのがESLintのプラグインである eslint-plugin-jsx-a11y です。 このプラグインは、Reactアプリケーションで使用されるJSXにおけるアクセシビリティルールを検証します。Reactコンポーネント内のJSX要素に関連するアクセシビリティルールをチェックし、開発者に潜在的なアクセシビリティの問題を警告またはエラーとして表示します。 例えば、img要素にalt属性が存在しない場合や、フォーム要素がラベル付けられていない場合など、アクセシビリティに関する問題を検出してくれます。このツールを使用することで、コードの品質を向上させつつアクセシビリティの問題を早期に発見できます。 axe-core axe-core は、Deque Systemsが開発したオープンソースのアクセシビリティの問題を診断するためのライブラリです。ブラウザのデベロッパーツールのコンソールにアクセシビリティ違反の警告を表示することで、開発中にリアルタイムのフィードバックを得られます。 導入方法は非常にシンプルで、アプリケーションのメインのエントリーファイルに以下のようにコードを追加するだけです。 Next.jsの_app.jsの例： import React from 'react'; if (typeof window !== 'undefined' && process.env.NODE_ENV !== 'production') { const ReactDOM = require('react-dom'); const axe = require('@axe-core/react'); axe(React, ReactDOM, 1000); } function MyApp({ Component, pageProps }) { return <Component {...pageProps} />; } export default MyApp; 開発環境でのみaxe-coreを有効化します。そのため、本番環境ではパフォーマンスに影響を与えません。 axe Accessibility Linter axe Accessibility Linter は、アクセシビリティをチェックするためのVSCode拡張機能です。この拡張機能は、上記で紹介したaxe-coreをベースにしています。eslint-plugin-jsx-a11yと同様、アクセシビリティの問題を自動的に検出し、エディタ内で直接フィードバックを提供することができます。 Accessibility Insights for Web Accessibility Insights for Web は、Microsoftが提供しているChromeとEdgeの拡張機能です。このツールは、アクセシビリティの問題を自動的に検出し、修正ポイントやガイダンスなど豊富なレポート機能を通じて、開発者がアクセシビリティの向上に取り組むことができます。 終わりに 以上、私が日々のReact開発において活用しているアクセシビリティチェックのツールをいくつか紹介しました。これらのツールを利用することで、アプリケーションのアクセシビリティ問題を早期に検出し、可能な限り多くのユーザーにとって使いやすいアプリケーションを開発することが可能になります。 しかしながら、ツールだけで完全なアクセシビリティを保証することは困難です。ツールの活用は重要ですが、それと同時に、アクセシビリティについての知識を深めることも大切です。全てのユーザーが快適にアプリケーションを利用できるよう、我々は引き続き学びを深めていきましょう！ The post React開発におけるアクセシビリティのチェックツールの紹介 first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第10回目のテーマは、「エクストリーム・プログラミング（XP）」です。前回は価値の解説をしたので、今回は原則やプラクティスを解説します。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 XPの原則 XPの原則 一般的に語られているXPの原則は、第1版第2版で内容が進化したりした影響で、いくつか種類があります。よって、どれが本物かとてもわかりにくいので、今回はWikipedia（ Extreme programming – Wikipedia ）にまとまっているものをベースに解説していきます。 XPの原則： フィードバック まず「フィードバック」です。顧客からのフィードバックだけでなく、テストによるフィードバックも含みます。迅速なフィードバックを得るために、短いサイクルでどんどんリリースを繰り返したり、テストを自動化してくりかえし自動でテスト実行したりします。XPは迅速なフィードバックがもっとも重要だと考えています。 XPの原則： シンプルさを前提とする 次に「シンプルさを前提とする」です。シンプルさはXPの価値にも登場しました。 シンプルなものを複雑にしてはなりません。複雑なものをシンプルに解決していくのが重要です。短い期間で小さく開発するのもシンプルさにつながります。小さくコツコツリリースを繰り返していきます。 XPの原則： 変化を包容する 最後に「変化を包容する」です。英語だと「Embracing change」。XPを知る人にとっては有名な言葉です。「embrace」は抱きしめる、包囲する、取り巻く、包容する、受け入れるといった「積極的に取り入れる」意味になります。 これまでのプロセスでは変化をコントロールしようとする方法が取られてきましたが、そうではなく変化を積極的に受け入れるのがアジャイル開発の大きな特徴です。変化を包容することで、より柔軟に開発を進めていけるようになるのがアジャイル開発の目指す方向性です。 XPのプラクティス 最後にXPのプラクティスを見ていきましょう。 プラクティスは状況に応じて実施していきます。また、プラクティス同士、関係し合う部分があるので、うまくつながると大きな効果を満たせます。たとえば、10分でビルドと常時結合を一緒にやることで、プログラム同士の結合がより確実に安全に行われます。 XPのプラクティスはたくさんあるのですが、現在でも使える色褪せない技術プラクティスが多いです。筆者自身も、顧客の支援でXPのプラクティスを中心に導入するケースは多くあります。 現在だと、コミュニケーションやチーム運営が中心のスクラムが主流となり、技術プラクティスがおろそかになってしまう現場も多いです。その結果、アジャイル開発が失敗するケースもあるので、ここでは、ちょっとだけ詳しく解説しておきます。 XPのプラクティスは基礎と応用に分かれています。 XPの基礎プラクティス： 全員同席 ひとつめは「全員同席」です。 最近のオフィスだとあまりないかもしれませんが、昔のオフィスだとパーティションに区切られたりしていました。それはそれで個室のように使えるので「集中できる」といった便利な点もありますが、ソフトウェア開発は共同作業なので、パーティションが文字通り壁になってしまう場合もあります。 また、チームメンバーがそれぞれ別の場所で働いている場合、コミュニケーションが取りにくくなります。同じビルでフロアが別でも似たような問題がおきます。 繰り返しますが、開発は人間による共同作業ですので、全員同席というプラクティスはできるかぎり取り組んでいくと良いと思います。難しい場合でも、開発チームの島にひとつだけビジネスの席を作っておく・・・とかして、時間があるときにそこにきてもらって作業できるようにしてあげる・・・などの対応も有効です。 チームの座席配置は、チーム立ち上げ時によく考えてみるとよいでしょう。 XPの基礎プラクティス： チーム全体 2つ目は「チーム全体」です。 いわゆる職能横断型チームをつくるということです。職能横断型チームとは、プロジェクトを成功に導くためのすべてのスキルや知識や経験をもつ人達が集まったチームです。 職能横断型チームを作るのが難しい組織の場合は、アジャイル開発がなかなかうまくいかないケースも多いです。いいすぎかもしれませんが、職能横断的チームを立ち上げ、ふりかえりというプラクティスをくりかえし行えば、たいていの現場はアジャイル開発をうまく機能させられる気がしています。 まずは、職能横断型チームをできるだけ作り、難しい場合は、外部の協力を得て、その摩擦をできるだけなくす・・・といった対策を考えていくと良いでしょう。 XPの基礎プラクティス： 情報豊富な作業空間 3つ目は「情報豊富な作業空間」です。 たとえば、アジャイルチームは、壁にふせんを貼り付けて議論したり、ホワイトボードに新しいアーキテクチャのドラフト図を書いたりして、情報豊富な作業空間を作っていきます。 さらにいうと、フロアにコーヒーメーカーをおいてもらって雑談空間を作ったり、そこにおやつをおいて集まりやすくしたりする工夫もしたりします。 私自身も、開発チームの座席の近くに、おやつ置き場をおいたりします。これはおやつ神社などと呼ばれるプラクティスで、メンバーはすきな額のお金をお賽銭箱に入れて、お菓子をたべます。賽銭箱のお金を使ってお菓子を補充するのが僕の役目でした。 XPの基礎プラクティス： 活気のある仕事 4つ目は「活気のある仕事」です。第1版だと「週40時間労働」という名前のプラクティスでした。 アジャイルマニフェストにもありますが、持続可能な開発が重要です。よって、XPでは週40時間勤務をベースとして、しっかり休息を取るようにしていました。 あたりまえのことのように思うかもしれませんが、昔は残業でカバーが横行していたので、明示的に「ノー残業デー」を作るのも手です。 ただ、残業がだめというわけではありません。場合によっては、必要なときもあるはずなので、するとしても無理のない方法をとる。メンバーも納得の上で働ける環境を作るのが重要だと思います。 XPの基礎プラクティス： ペアプログラミング 5つ目は「ペアプログラミング」です。通称ペアプロは、有名なプラクティスであり、賛否が分かれるプラクティスでもあります。 ペアでプログラミングをするので、開発量は2分の1になります。ただ、随時議論を行いながらコーディングするので、レビューのコストが減るため、結局こちらのほうが効率が良かったりします。また、ペアで作業することで、知識や経験は倍のスピードで得られるようになります。 ペアプロの生産性については、過去多くの議論が行われていますが、少なくとも、ずっとペアプロができなくても、新しいメンバーがはいってきたときや、難しい実装をするときなどにしぼって、ペアプロを部分的に活用できます。 XPの基礎プラクティス： ストーリー 6つ目は「ストーリー」です。ユーザーストーリーと呼ばれたりします。 ストーリーの特徴のひとつは、見積もりをすばやくシンプルに行えることです。よって、必然的にストーリーは、できるだけ小さく作らなければならなくなります。1000ページの要件定義書よりも、1枚のカードに書ききれる量のストーリーをXPはあつかいます。 XPの基礎プラクティス： 1週間サイクル 7つ目は「1週間サイクル」です。第1版では計画ゲームというプラクティスでした。 アジャイル開発ではイテレーション（スクラムだとスプリント）と呼ばれる短いサイクルで開発を行います。書籍は当初2〜3週間を推奨されていましたが、第2版では1週間になっているのが興味深い点です。より短い期間でリリースを繰り返していくことをすすめているのかもしれません。 XPの基礎プラクティス： 四半期サイクル 8つ目は「四半期サイクル」です。 短いサイクルで開発を行いますが、中長期的な計画も大切です。四半期、つまり三ヶ月ぐらいの期間で大きな目標の調整を行っていきます。 長期的な計画については、現場に合わせて長さを調整すると良いと思います。ただし、長く見積もっても、1年から2年ぐらいが限界だと思います。意味のある範囲で計画を立てていきましょう。 XPの基礎プラクティス： ゆとり 9つ目は「ゆとり」です。ゆとりで有名なものとしてはGoogleの20％ルールがあります。 やることを詰め込んでも、大抵はうまく終わりません。どうせうまくいかないことを、毎回のイテレーションで行うとどんどん辛くなってきます。よって、ある程度のゆとりを設け、この問題を解決していきます。 XPの基礎プラクティス： 10分ビルド 10番目は「10分ビルド」です。 システムの規模によって変わってくるかもしれませんが、ここでは10分という目安を設定しています。10分以内という制限があることで、実行回数を維持しやすくなりますし、時間が長くなってしまったときに気がつけます。 ビルド時間は短いに越したことがありません。時間については、自分たちが待てる時間を設定してもいいと思います。 XPの基礎プラクティス： 常時結合 11番目は「常時結合」です。 これは継続的インテグレーション（CI）です。書籍では2〜3時間ごとに結合とテストを行うとありますが、最近だとソースがコミットされたら自動でCIが動く方法をとっている所も多いと思います。 大抵の場合、問題は結合部分におきます。よって、常時結合していけば、その問題にすぐきがつけるようになります。これがCIを利用するメリットです。 XPの基礎プラクティス： テストファーストプログラミング 12番目は「テストファーストプログラミング」です。テストファーストとテスト駆動開発は、賛否両論が起きやすいプラクティスです。 失敗するテストをまず書き、テストが失敗しないようにコードを修正していくプラクティスです。はじめからテストファーストで行うのが難しいなら、コードとテストを同時コミットするルールから始めてもいいと思います。なんにせよ、自動テストはアジャイル開発に必須の技術プラクティスです。 XPの基礎プラクティス： インクリメンタル設計 13番目は「インクリメンタル設計」です。第1版ではシンプルな設計というプラクティスでした。 これは説明が難しいプラクティスですが、ざっくりいうと、ちょっとずつ設計しましょうです。その理由は、全部をまとめて設計するのはコストがかかるからです。ちょっとずつ設計すれば、いま決めなくても良いことを、ぎりぎりまで先延ばしして、それまでに得た情報を使ってあとで決められます。先延ばしをうまく使う方法です。これはあとで解説を予定しているリーンソフトウェア開発にも「最終責任時点」という似たような言葉がでてきます。 ここまで基礎プラクティスを解説してきました。次回は応用プラクティスの解説を行います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 The post 第10回 エクストリーム・プログラミングの原則と基礎プラクティス first appeared on Sqripts .

こんにちは。自動テストエンジニアのおすしです。 2023年8月にLogiGear社の自動テストツール「TestArchitect」がモバイルアプリのテストに対応しました。今回はこの機能の概要を紹介します。 TestArchitectとは 「 TestArchitect 」はAGESTのグループ会社であるLogiGear社が開発した自動テストツールです。10年以上の運用実績があります。当初は特定の顧客の要望に沿って開発されたオンデマンドツールでしたが、機能追加と改善を繰り返して汎用性の高い製品に進化しました。現在も積極的に開発が進められています。 2023年8月にモバイルネイティブアプリのテスト機能が追加( v9.3 )されたことで、数ある自動テストツールの中でも対応できるテスト範囲が広いツールとなりました。レコード機能を利用した簡単な自動テストから、ほかツールとの連携やスクリプトを利用した複雑な自動テストまで作成できる適用範囲の広いツールです。 TestArchitectの特徴 TestArchitectのメリット キーワード駆動と豊富な組み込みアクションで実装とメンテナンスにかかるコストが少なく、テストコードの可読性が高いためレビューのコストも減らせるというメリットがあります。テスト対象がWindowsネイティブアプリ、ブラウザの他、モバイルネイティブアプリ（Androidアプリ/iOSアプリ）にも対応しているため、他の自動テストツールと比べても幅広い開発チームで利用可能です。 動作環境 TestArchitectはWindows PCで動作します。 Windows 10,11 ※その他動作環境は自動化対象や連携するツールによって異なります。詳しくは公式ドキュメント「 Supported platforms 」をご参照下さい。 テスト対象 Webブラウザ（Chrome、Edge、Firefox、IE） Windowsネイティブアプリ Androidネイティブアプリ iOSネイティブアプリ 主な機能 キーワード駆動型テスト TestArchitectはキーワード駆動型テストを採用しています。操作内容がシンプルなキーワードで記述できるため可読性が高いテストを作成できます。また、テストの修正も容易になるという利点があります。 レコード機能 操作した内容を記録してテストコードとして利用できるため、誰でも簡単にテストが作成できます。記録したテストは簡潔なUIで表示され編集も容易です。 ※v9.3では、Webブラウザ、Windowsアプリテストがレコード機能に対応しています。モバイルアプリテストについても開発中です。 あらゆる操作に対応するアクション TestArchitectは 膨大なアクション が定義されています。テストで必要な操作はこれらのアクションを組み合わせることで実現可能です。ユーザーが自分で開発する必要はありません。 プログラミング言語が利用可能 テストはプログラミング言語でカスタマイズすることも可能です。既にプログラミング言語で実装したテストがある場合、それをTestArchitectのテストに組み込むこともできます。 利用可能言語 Java Python C# その他、画像認識機能、他社ツールとの連携機能、自社端末を利用可能、DBと連携したデータ駆動型テストができるなど、様々なオーダーに対応できる機能を備えています。 モバイルアプリテスト機能 テスト環境の構成図 TestArchitectのモバイルアプリテスト機能はAppiumサーバーを利用して動作します。手持ちの端末のほか、Remote TestKitなどの端末クラウドサービスも利用可能です。 Appiumサーバーを介して操作するため、iOS端末をテストする場合はXcodeをインストールしたMacが必要です。 作成できるテストの例 TestArchitectはAndroidとiOSを交互に操作したり、複数の端末を切り替えながら操作することができます。AndroidとiOSで音声通話を行うテストや、3端末以上でメッセージのやり取りをするテストなどを実装することができます。このような複雑な操作でも組み込みアクションが用意されているためコーディングの必要はありません。 また、モバイルアプリ、Windowsブラウザ、Windowsアプリなどを切り替えて操作するクロスプラットフォームテストも作成できます。モバイルアプリで登録した情報をWindowsのデータベースアプリで確認する、といったテストも作成可能です。 テスト作成の手順 iOS端末で写真を撮影するテストを作成する手順を紹介します。 端末への接続 TestArchitectの「インタフェースビューワー」機能に接続する端末の情報を入力して「接続」ボタンをクリックします。 要素の取得 ミラー画面上で取得したい対象をクリックすると要素のプロパティが表示されます。要素の検出に利用したいプロパティにチェックをいれて保存するだけで取得が可能です。 保存ボタンを押すと、TestArchitectのインターフェースに取得した要素が表示されます。 テストコードの作成 組み込みアクションと取得した要素を利用してテストを作成します。ExcelライクなUIであるため、スクリプト言語で作成したテストケースよりも分かりやすいテストコードを作成できます。要素の名前には英数字以外に日本語が利用可能です。 テストの実行と結果レポート 「インタフェースビューワー」を利用した時と同様に接続先の端末情報を入力するだけで実行できます。 テスト結果レポートはhtml形式で出力されます。失敗時だけではなく、操作毎にスクリーンショットを自動的に撮影するように設定することができます。それらのスクリーンショットは操作箇所が赤い丸で囲まれ、確認箇所は赤い枠で囲まれています。テストの内容が分かりやすく、結果の確認をスムーズに行うことが可能です。 ・カメラアプリをtapする前後でスクリーンショットを撮影した場合のレポート ・操作や確認箇所は赤い〇などで明示されます。 使用感 私はAppiumとプログラミング言語のPythonを利用してフルスクラッチの自動テストを作成した経験があります。それと比較すると、TestArchitectを利用した自動テストには多くのメリットがあると思います。 テストコードが速く作成できる フルスクラッチで実装したときはAppium Inspectorで要素を取得してコピペでコードに張り付ける作業を何回も繰り返す必要がありましたが、TestArchitectはインターフェースビューワーでスマホのミラー画面をクリックするだけでインターフェース定義に出力できます。テストコードについても既にほとんどのアクションが準備されているため、それを呼び出すだけで終わります。アクションの使い方はF1キーを押すだけでTestArchitectから該当のアクションを解説した公式ドキュメントに遷移できます。探す必要はありません。フルスクラッチのコーディングよりもかなり速くテストコードが作成できます。 ただ、アクションが膨大にあるため、慣れるまでは使いたいアクションを探すのに時間がかかります。 テストコードが読みやすい 私はコードの羅列とインデントによる区別に慣れていたので、TestArchitectのExcelみたいな見た目はちょっと…と思っていましたが実際に使ってみるとかなり読みやすい印象です。さらにアクションやインターフェースに日本語名を使うと内容が一目で分かります。自動テストの実装担当者やレビュアーにはエンジニアではないメンバーが含まれる場合があるため、コードが読みやすい点はメリットがあると思います。 テスト実行が簡単 実行するテストケース、実行対象の環境（端末などの接続先）を指定したテスト実行用のバッチファイルをワンクリックで作成できる機能がとても便利です。テストスイートやテスト端末毎に作成しておくと必要なテストをすぐに実行することができます。Jenkinsなどの外部ツールで定期実行するといったCI/CDに組み込むことも簡単です。 プログラミング言語が利用可能 TestArchitectはJavaやPythonといったライブラリが充実しているプログラミング言語で拡張できるため、公式のサポートがないツールを連携させたり、かなり特殊な処理でも自動テストに組み込むことができます。他のテスト自動化ツールの多くは対応している言語がJavaScriptのみであったり、限定された範囲でしか利用できないといった制約があります。いざとなったらコードを書ける点は自動テストエンジニアとして安心できる機能だと思います。 おわりに TestArchitectのモバイルテスト機能は、Appiumとプログラミング言語を利用したテストと比較すると簡単にかつ速く作成ができ、修正にかかる工数も少なく済みます。操作が容易である一方で、自動テストツールの中でも多機能かつ拡張性が高いという特徴があります。 TestArchitectはFreeライセンスを提供しています。自動テストツールを探している方はぜひお試しください。 https://www.testarchitect.com/ AGESTではTestArchitectの導入を考えている方、少しでも興味がある方に向けて説明会を実施しています。お気軽にお問い合わせ下さい。 The post TestArchitectモバイルテスト機能の紹介 first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまるです。 この記事では、Protocol BuffersのLinterの一つである Buf を使ったLintついて、実践例とともにご紹介します。 Protocol Buffersとは Protocol Buffersは、Googleが開発したバイナリデータのシリアライズ形式です。データ記述形式の一種なのでJSONやXMLと比較されることもありますが、ProtocolBufferはバイナリ形式で保存されるため、JSONやXML形式などのテキストベースの形式よりもデータサイズが小さく、より高速にデータ転送ができます。 Protocol Buffersは、Googleが開発したRPCフレームワークである gRPC に使われています。Protocol BuffersとgRPCの関係は、JSONとHTTP通信の関係によく似ています。HTTP通信がデータ記述形式としてJSONを使用するように、gRPCはProtocolBufferを使用して通信を行います。 Bufとその他のLinterの比較 我々のプロジェクトでは、初めはProtocol BufferのLinterとして Google API Linter を採用していました。Protocol BuffersがGoogle製なので、LinterもGoogle製のものを使えば安心だろうと考えていたためです。 しかし、Google API Linterのルールはいささか厳しすぎたため、プロジェクトのシステム構成の見直しのタイミングでLinterの選定を見直すことになりました。再選定の際に決めた要件は以下の3つです。 最近まで更新がある（開発が止まっていない） 個人開発でない（今後も更新が続けられる可能性が高い） Lintのルールが厳しすぎない 検討したLinterは以下の通りです。 prototool 直近の更新が2020年と古く、公式の発言を見ても今後アップデートされる可能性が低い。 protolint 個人開発である点が不安。 Buf prototoolの後継にあたる。更新頻度は高く、ルールも問題ない。 これらのLinterを使って軽くPoCを行い、最終的にはすべての要件を満たしていたBufを採用しました。 .protoファイルの準備 ここから、実際にBufを使ったlintの例をご紹介します。 Bufをインストールする前に、まずはLint対象の.protoファイルを用意しましょう。今回は、以下のような簡単な.protoファイル（book.proto）を使います。 書籍データを作成するCreateBookと、書籍データを取得するGetBookという2つのメソッドがあります。この2つのメソッドのResponseは共通のメッセージ型（Book）を使用しています。 syntax = "proto3"; package book.v1; service BookService { rpc CreateBook(CreateBookRequest) returns (Book); rpc GetBook(GetBookRequest) returns (Book); } message Book { string id = 1; string title = 2; string author = 3; int32 pages = 4; } message CreateBookRequest { string title = 1; string author = 2; int32 pages = 3; } message GetBookRequest { string id = 1; } 以下のようなディレクトリ構成にして、v1の下にbook.protoを置きましょう。 sample-project └── pb-proto └── book └── v1 └── book.proto これで準備完了です。 Bufのインストールとセットアップ 次に、Buf CLIをインストールします。 $ brew install bufbuild/buf/buf Homebrew以外のインストール方法については、公式の インストールガイド を参照してください。 buf CLIのインストールが終わったら、Lintのためのセットアップをします。プロジェクト直下に以下のような内容の buf.work.yaml を作成しましょう。 directories にはpb-protoを指定します。 version: v1 directories: - pb-proto 最後に以下のコマンドを実行します。これにより、  buf.yaml  がpb-protoディレクトリに生成されます。 cd pb-proto buf mod init 最終的なディレクトリ構成が以下のようになっていたら成功です。 sample-project ├── buf.work.yaml └── pb-proto ├── buf.yaml └── book └── v1 └── book.proto BufをつかったLint さっそくBufを使ってbook.protoをLintしてみましょう。 $ buf lint ./book/v1/book.proto 出力を見てみると、いくつかLintエラーが出ていることが分かります。 pb-proto/book/v1/book.proto:5:3:"book.v1.Book" is used as the request or response type for multiple RPCs. pb-proto/book/v1/book.proto:5:46:RPC response type "Book" should be named "CreateBookResponse" or "BookServiceCreateBookResponse". pb-proto/book/v1/book.proto:6:3:"book.v1.Book" is used as the request or response type for multiple RPCs. pb-proto/book/v1/book.proto:6:40:RPC response type "Book" should be named "GetBookResponse" or "BookServiceGetBookResponse". 1つ目と3つ目は、「 Book というメッセ―ジ型が複数のRPCで使われている」ために生じたエラーです。 Bufの公式の Configuration and options ページには、以下のような記述があります。 最新の Protobuf 開発において最も重要なルールの 1 つは、すべての RPC に対して一意のリクエストメッセージとレスポンスメッセージを持つことです。複数のRPC間でProtobufメッセージを共有すると、このProtobufメッセージのフィールドが変更されたときに複数のRPCが影響を受けることになります。（筆者翻訳） Configuration and options 要は「メッセージ型を使いまわすな」ということを言っていますね。どのような名称に変更するべきかは2行目と4行目を参考にすればよいです。 修正後のbook.protoは以下のようになります。 syntax = "proto3"; package book.v1; service BookService { rpc CreateBook(CreateBookRequest) returns (CreateBookResponse); rpc GetBook(GetBookRequest) returns (GetBookResponse); } message CreateBookRequest { string title = 1; string author = 2; int32 pages = 3; } message CreateBookResponse { string id = 1; string title = 2; string author = 3; int32 pages = 4; } message GetBookRequest { string book_id = 1; } message GetBookResponse { string id = 1; string title = 2; string author = 3; int32 pages = 4; } もう一度Lintをかけてみると、エラーが出なくなったことが分かると思います。 開発の都合で無効化したいルールがある場合は、buf.yamlに except の段落を作って無効化したいルール名を指定するとよいです。 以下が RPC_RESPONSE_STANDARD_NAME と RPC_REQUEST_RESPONSE_UNIQUE を無効化したbuf.yamlの例です。 version: v1 breaking: use: - FILE lint: use: - DEFAULT except: - RPC_RESPONSE_STANDARD_NAME - RPC_REQUEST_RESPONSE_UNIQUE こうすると、修正前のbook.protoでもLintが通ります。他のルールの名称については公式ページの Rules and categories を参照してください。 終わりに Bufを使ってProtocol BufferをLintする方法をご紹介しました。BufはLint機能を使うだけなら非常にシンプルで、学習コストがかからないと思います。 この記事がみなさんのお役に立てば幸いです。 The post Protocol BuffersのLintチェック入門: Bufを使った実践ガイド first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第6回の今回は、引き続きオンチェーンデータのオンライン分析サービスのDune（ https://dune.com/ ）を用いて、Ethereumを対象としたデータ分析の演習を始めていきます。 Raw Blockchain Dataの確認 Duneの提供するデータテーブルには、第5回の記事でもご紹介した通り、Decoded projectsやSpellsなどの分析のために加工された便利なデータテーブルが揃っています。しかし今回は、ブロックチェーンの基本的なデータ構造を理解するためにも、ブロックチェーンの生のデータに近いRaw Blockchain Dataを中心に取り扱ってみましょう。 EVM Raw Table Data Duneでは、BitcoinやEthereumをはじめ、Polygon、Optimism、BNB Chainなど、さまざまなブロックチェーンのデータを提供しています。このうち、BitcoinやSolanaなどの少数の例外を除き、ほとんどのブロックチェーンはEthereum Virtual Machine(EVM)と呼ばれる仮想マシンを利用しています。 Ethereumのクライアントプログラムにはいくつかの実装が存在しますが、すべてのクライアントが同じEVMの仕様に準拠することで、実装の違いを気にすることなく同じスマートコントラクトを実行して同じ結果を得ることができます。また、Ethereum以外のブロックチェーンであっても、EVMの仕様に準拠しているチェーンであれば、Ethereum用に実装されたスマートコントラクトを動かすことができます。 スマートコントラクトを実行可能なブロックチェーンは数多く存在しますが、その中でもEVMと互換性のあるチェーンがデファクトスタンダードとなっているため、まずはEthereum(EVM)のデータ構造に慣れておくと汎用性が高まります。 BlocksとTransactions 第3回の記事 でもご紹介したとおり、多くのブロックチェーンはブロックとトランザクションというデータ構造を持っています。 Ethereumにおけるブロックとトランザクションの生データは、Dune上ではそれぞれ「ethereum.blocks」「ethereum.transactions」というテーブル名で参照できます。 下記のコード1.をDuneのクエリエディタに記載し、RunをクリックしてEthereumのブロックデータを10件取得してみましょう。FROM句に欲しいデータのテーブル名を指定し、SELECT句に欲しいカラム名を列挙します。すべてのカラムを取得したい場合は「＊」を利用できます。また、すべてのデータを取得するのは非常に時間がかかる可能性があるため、LIMIT句で取得するデータの件数を指定する癖をつけておくと安心です。 コード1 . Ethereumのブロックデータを10件取得するクエリ SELECT *FROM ethereum.blocksLIMIT 10 無事に実行が終了すると、図1のようなクエリ結果画面が表示されます。なお、SQLにおけるテーブルは、表計算ソフトにおけるテーブルとは異なり、順序を持たないデータの集合ですので、取得される10件のデータは実行ごとに異なるものが取得される可能性があります。今回の実行結果では、2015年9月12日のタイムスタンプが付与された、ブロック番号「224095」のデータが1件目に取得されています。 図1. ethereum.blocksテーブルのサンプルデータ Duneで取得したデータが正しいかどうか、Etherscan（ https://etherscan.io/ ）のサイトでも確認してみましょう。Etherscanの検索窓にブロック番号を入力して検索すると、該当ブロックの詳細情報を記載したページが閲覧できます。 図2 . ブロック番号「224095」の詳細情報（ https://etherscan.io/block/224095 ） 図1と図2を比較してみて、TimestampやDifficultyなど、基本的な情報が一致していることを確認してみてください。 データ加工のためのSQL 上記のブロックデータを対象として、SQLを用いた簡単なデータ加工の演習をしてみましょう。 SQLにおけるデータ加工のための演算は、大きく分けて数値や文字列などのスカラ値を対象とした演算と、データの集合であるテーブル（リレーション）を対象とした演算が存在します。両者について具体例を確認してみましょう。 値を対象とした演算 図1で示したクエリの出力結果のうち、タイムスタンプを表す「2015-09-12 17:04」といったデータや、ブロック番号を表す「224095」といったデータに対して、SQLを用いて好きな加工を施すことができます。特に、ブロックチェーンのデータの多くはタイムスタンプを付与された時系列データですので、タイムスタンプを分析しやすい形に加工する機会が多くあります。 コード2に、タイムスタンプを取り扱う典型的な関数の記載例を示します。yearやmonthといった関数は、タイムスタンプから特定の要素を抽出する関数です。date_trunc関数は、タイムスタンプを指定した桁で切り捨てた値を取得する関数で、日次や週次でのデータ集計を実施したい場合によく用いられます。format_datetime関数はJavaの時刻関数ですが、Dune SQLではこのようなSQL標準には存在しないものの有用な関数も多く対応が行われています。 Dune SQLでどのような関数が実装されているかは、公式のドキュメント（ https://dune.com/docs/query/DuneSQL-reference/Functions-and-operators/ ）を参照してください。 コード2 . タイムスタンプを加工する関数例 SELECT time, year(time), month(time), day(time), date_trunc('day', time), date_trunc('week', time), format_datetime(time, 'MMM-dd-yyyy KK:mm:ss a +z'), number FROM ethereum.blocks WHERE number = 224095 LIMIT 10 図3. 「コード2」の実行結果例 SQLにおける値を対象とした演算の注意点として、対象テーブルに含まれるすべてのレコードのカラムに対して、同じ演算が適用される点に注意してください。例えば、100件のデータが存在した場合に、一般的な手続き型のプログラミング言語では、for文などのループ構文を用いて、1件ずつ演算を適用していくことが多いと思います。一方、SQLは集合演算を基本としているため、ループ構文などは存在せず、100件のデータすべてに必ず同じ演算が適用されることになります。 また、値を対象とした演算では、入力したテーブルに含まれるレコード数と、出力されるレコード数は必ず一致することにも注意してください。100件のレコードを含むテーブルに対して値を変更する演算を実行した場合、出力結果のレコード数も必ず100件となっています。 もし、期待している分析結果がレコード数の増減を伴うようなものであれば、次のテーブルを対象とした演算が必要です。 テーブルを対象とした演算 集合演算としてのSQLを使いこなすためには、テーブルに対して演算をおこなって別のテーブルを作成する、というイメージを持つことが重要です。 集合演算としてのSQLを体験する前準備として、さきほど示したdate_trunc関数を用いて、タイムスタンプを日付で切り落としした一時データを作成してみます。コード3では、date_truncの計算結果カラムに対して、AS句を用いて「day」という名前を付けています。コード2のような書き方では、出力結果のカラムが「_col1」「_col2」といったデフォルトの連番名となっていましたが、これらに分かりやすい名前をつけることで、分析の見通しやクエリの再利用性が向上します。 また、取得するレコードの条件をWHERE句で指定し、レコードの絞り込みをおこなっています。WHERE句の次に指定した式がTRUEとなるレコードだけが出力結果に表示されます。「timestamp ‘2023-01-01 00:00:00’ <= time」という条件式は、’2023-01-01 00:00:00’という文字列をtimestamp型に変換し、timeカラムの値と比較している式です。 コード3 . date_trunc関数を用いた前処理 SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time 図4 . 「コード3」の実行結果例 図4に示したとおり、タイムスタンプから時刻情報が切り落とされ、日付情報を示すdayカラムを持ったサンプルレコードを取得することができました。 このサンプルレコードを対象として、日付ごとにどれくらいのブロックが生成されているかを集計するクエリを記述してみましょう。 まず、テーブルに対して演算を適用することをイメージするために、コード4のような書き換えをおこなってみてください。コード3に限らず、すべてのSELECT文の出力結果はテーブル（リレーション）の形式をしているので、その出力結果をFROM句に指定して、さらに別のSELECT文を記述することが可能です。コード4の実行結果は、図4で示したコード3の実行結果と同じです。 コード4 . 「コード3」のSELECT文をFROM句に指定したクエリ SELECT * FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) 集約関数 テーブルを対象とした演算として代表的なものに、集約関数と呼ばれる関数群があります。コード5は、コード3の出力結果のテーブルに対して、集約関数であるcount, max, min関数を適用したクエリです。 コード5 . 「コード3」の出力結果に集約関数を適用したクエリ SELECT count(1), max(day), min(day) FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) 図5 . 「コード5」の実行結果例 コード5の計算結果は、FROM句で指定したテーブルに含まれるレコード数、dayカラムの最大値と最小値を示しています。ここで、出力結果のテーブルのレコード数が1件となっていることに注意してください。テーブルを対象とした演算は、値を対象とした演算と異なり、入力テーブルのレコード数と出力テーブルのレコード数は必ずしも一致しません。 GROUP BY句 集約関数をGROUP BY句と組み合わせて使うことで、集約をおこなう粒度を指定することができます。GROUP BY dayと指定することで、dayが同じ値を持つレコード群を単位として集約関数を適用し、dayをキーとした新たなテーブルが生成されています。なお、計算結果の表示順はデフォルトでは不定のため、ORDER BY句を用いることでソートして表示することができます。 コード6 . 日付ごとにブロック数をカウントするクエリ SELECT day, count(1) FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) GROUP BY day ORDER BY day 図6 . 「コード6」の実行結果例 WITH句（共通テーブル式） 任意のSELECT文の結果はFROM句に指定して新たなSELECT文への入力として指定できますが、多くのSELECT文がネストしたクエリは可読性が下がる可能性があります。 WITH句を用いた共通テーブル式という構文を用いると、SELECT文の結果に一時的なテーブル名を付与することができ、一連のクエリのなかで再利用ができるようになります。 コード7は、コード3のSELECT文の結果にtmpという名前を付け、WITH句を用いて共通テーブル式化したクエリです。出力結果はコード6と同様になります。 コード7 . WITH句を用いた「コード6」の書き換え WITH tmp AS ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) SELECT day, count(1) FROM tmp GROUP BY day ORDER BY day JOIN句 テーブルを対象とした演算には、レコードをフィルタしたり集約したりするWHERE句や集約関数とは逆に、複数のテーブルを組み合わせてレコード数やカラムを増加させる演算も存在します。 上記のblocksテーブルに含まれる情報だけでは、ブロックに含まれるトランザクション数などを把握することができませんでした。ブロックごとのトランザクション数の集計は、transactionsテーブルを用いて計算できます。transactionsテーブルの計算結果と、blocksテーブルのカラム情報を組み合わせて結果に表示させたい場合は、複数のテーブルを指定したキーで結合するJOIN句が利用できます。 コード8は、WITH句による共通テーブル式で、トランザクション数を集計したtx_countテーブルを作成し、blocksテーブルのnumberカラムと、tx_countテーブルのblock_numberカラムとをキーにして結合したクエリです。 コード8 . ブロックに含まれるトランザクション数の集計クエリ WITH tx_count AS ( SELECT block_number, COUNT(1) AS tx_count FROM ethereum.transactions GROUP BY block_number ) SELECT number, time, miner, difficulty, tx_count FROM ethereum.blocks AS b JOIN tx_count AS t ON b.number = t.block_number ORDER BY b.number DESC LIMIT 10 図7. 「コード8」の実行結果例 次回予告 今回の記事では、ブロックチェーンの基本的なデータ構造であるブロックやトランザクションのテーブルをサンプルとして、データ分析で役立つSQLの基本的な構文や、SQL特有の思考方法について紹介しました。次回記事では、EVMのデータ構造の深掘りや、発展的なSQLの構文について解説しながら、オンチェーンデータ分析の演習を進める予定です。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習 1 The post 【第6回】Ethereumデータ分析演習2 first appeared on Sqripts .

こんにちは。 エンジニアの nobushi です。 RDBを扱うWebアプリケーションを構築しているとRDBのレプリケーション環境を必要とすることもあると思います。 アプリケーション側で対応が必要なのでできれば開発を行うローカル環境の段階で導入したいところです。 そこで今回は手軽にローカルのdocker-composeでRDBのレプリケーション環境を構築してみたいと思います。 使用するRDBは PostgreSQL です。 ついでに検証用に pgAdmin も導入してみます。 導入 docker-compose が使える環境で、任意のディレクトリに以下のファイルを配置して / db_primary/ init.sh pg_hba.conf db_read_replica/ entrypoint.sh docker-compose.yml 配置したディレクトリで起動してください。 docker compose up -d docker-compose.yml services: db_primary: image: postgres:14.8 command: -c "hba_file=/etc/postgresql/pg_hba.conf" environment: - POSTGRES_PASSWORD=hoge - POSTGRES_DB=main volumes: - db_primary_data:/var/lib/postgresql/data - ./db_primary/pg_hba.conf:/etc/postgresql/pg_hba.conf - ./db_primary/init.sh:/docker-entrypoint-initdb.d/init.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] db_read_replica: image: postgres:14.8 entrypoint: /etc/postgresql/entrypoint.sh volumes: - db_read_replica_data:/var/lib/postgresql/data - ./db_read_replica/entrypoint.sh:/etc/postgresql/entrypoint.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] depends_on: db_primary: condition: service_healthy pgadmin: image: dpage/pgadmin4:7.3 volumes: - pgadmin_data:/var/lib/pgadmin environment: - PGADMIN_DEFAULT_EMAIL=johndoe@example.com - PGADMIN_DEFAULT_PASSWORD=johndoe ports: - 50080:80 volumes: db_primary_data: driver: local db_read_replica_data: driver: local pgadmin_data: driver: local 構成はPostgreSQLのインスタンスがプライマリ、レプリカでそれぞれ一つ、 pgAdminが一つです。 またそれらのデータ保持用のボリュームを定義しています。 db_primary/init.sh #!/bin/sh -xeu psql -v ON_ERROR_STOP=1 <<- _EOT_ CREATE USER replicator WITH REPLICATION; SELECT pg_create_physical_replication_slot('my_replication_slot'); _EOT_ db_primary/pg_hba.conf local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust local replication all trust host replication all 127.0.0.1/32 trust host replication all ::1/128 trust host replication replicator 0.0.0.0/0 trust host all all all scram-sha-256 db_read_replica/entrypoint.sh #!/bin/sh -xeu pg_basebackup \\ -h db_primary \\ -D ${PGDATA} \\ -S my_replication_slot \\ -X stream \\ -U replicator \\ -R || true /usr/local/bin/docker-entrypoint.sh postgres プライマリDB プライマリDBで必要なことは以下の3点です。 レプリケーションスロットの作成 レプリケーションユーザーの作成 レプリケーションユーザーの認証設定 レプリケーションスロットの作成 レプリケーション接続を行うためのレプリケーションスロットを作成します。 init.sh で行っています。 SELECT pg_create_physical_replication_slot('my_replication_slot'); レプリケーションユーザーの作成 レプリカ側からの接続用にユーザーを作成します。 init.sh で行っています。 CREATE USER replicator WITH REPLICATION; このサンプルではセキュリティは気にしないのでパスワードは設定しません。 レプリケーションユーザーの認証設定 pg_hba.conf は認証設定ファイルです。 デフォルトの pg_hba.conf は /var/lib/postgresql/data/pg_hba.conf にありますので、それをベースにして以下の設定を追加しています。 host replication replicator 0.0.0.0/0 trust この設定により replicator ユーザーのレプリケーション接続は接続元に関係なくパスワード不要となります。 本サンプルはローカルの環境用ですので簡易的に設定します。 db_primaryの設定 使用する pg_hba.conf を変更するためにコマンドを設定しています。 command: -c "hba_file=/etc/postgresql/pg_hba.conf" また、ファイルを差し替えるためにvolumeを設定しています。 - ./db_primary/pg_hba.conf:/etc/postgresql/pg_hba.conf - ./db_primary/init.sh:/docker-entrypoint-initdb.d/init.sh レプリカDB レプリカDBでは pg_basebackup を使用してレプリケーションを作成します。 pg_basebackup はPostgreSQLの起動前に実行し、 PostgreSQLの起動時にはレプリケーションDBが既に生成されているように制御する必要があります。 そのためにENTRYPOINTを差し替えて、 従来のENTRYPOINTの前に pg_basebackup を実行するようにしたのが entrypoint.sh です。 pg_basebackup の引数はプライマリDBの設定内容に合わせたものです。 また、2回目以降の起動時にはすでにデータがあるため pg_basebackup がエラー終了します。 その場合はエラーを無視するように || true をつけています。 pg_basebackup \\ -h db_primary \\ -D ${PGDATA} \\ -S my_replication_slot \\ -X stream \\ -U replicator \\ -R || true また、プライマリDB側が起動した状態でないと起動に失敗するため、 composeでプライマリDBのステータスがHealthyになってから起動するように制御しています depends_on: db_primary: condition: service_healthy pgAdminで検証 ではpgAdminで動作確認してみます。 pgAdminへのアクセスは docker-compose の通りであれば http://127.0.0.1:50080 でアクセス可能なはずです。 login ログイン画面が表示されるので docker-compose の環境変数で設定した以下のメールアドレス、パスワードでログインします。 johndoe@example.com / johndoe 接続 ログインしたら各サーバーへの接続を追加します。 General / Name Connection / Host name Connection / Username Connection / Password db_primary db_primary postgres hoge db_read_replica db_read_replica postgres hoge 検証 この段階でレプリカDB側にも main データベースがある等 プライマリDBと同期していることが分かります。 ではプライマリDBにテーブルを追加してみます。 レプリカDB側にも同期されました。 またレプリカDB側にテーブルを追加しようとするとエラーが発生します。 ERROR: cannot execute CREATE TABLE in a read-only transaction 所感 ローカルでRDBのレプリケーション環境ができればアプリケーションのテスト等やりやすくなると思います。 compose一発で構築可能なのでぜひお試しください。 The post PostgreSQLのレプリケーション環境をDockerで手軽に立ち上げてみる first appeared on Sqripts .

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 .