こんにちは。ノウンです。 以前の記事で、「Webサイトのテスト」をスマートフォン（以下スマホ）を使って行う方法を紹介しました。その際は、PCとスマホをケーブルで接続して、PCのブラウザの標準機能であるデベロッパーツール（開発者ツール）を使う方法でしたが、今回はWi-Fi（無線）でPCとスマホを接続して同じテストを実施する方法をメリット・デメリットを交えて紹介します。 Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう Wi-FiでPCとスマホを接続してデベロッパーツールを使用するには条件があります。条件を満たしていない場合、Wi-FiでPCとスマホを接続をすることは出来ませんが、ケーブルで接続することは可能なので以前の記事を参照していただければと思います。 条件 ①PCとスマホを、同じWi-Fi（無線ネットワーク）に接続する ②「Android」は、「Android Studio」が必要かつ「OSver.11」以上である ※OSver.11で対応された、端末の「開発者向けオプション：ワイヤレスデバッグ」が使えることが前提となるため 「iPhone」は、初回の設定時のみスマホとPCをケーブルで接続する必要がある。OSver.は問わない 次に、「Android & WindowsPC」と「iPhone & MacPC」を使用した具体的な手順や設定について紹介していきます。スマホとPCの組み合わせは、この組み合わせでないと設定できませんのでご注意ください。 Android & WindowsPC（Chromeを使用） 以下の端末を使用した場合で説明します。 Android端末（OSver.11以上）＆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」を押下してインストールを実行する これで、スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されます。 7. ADBコマンドを有効にする ADBとは、Android Debugging Bridge のことで、コマンドを有効にするとAndroid Studioを使ってPCでスマホの開発をしたり、コマンドプロンプトからスマホを操作したりと、スマホのみでは行えない操作をPCから行うことが可能となります。 今回はスマホでデベロッパーツールを使用する際、スマホのワイヤレスデバッグが正常に動作するように設定を行います。 設定する際、あらかじめ手順「5」の画像上部「Android SDK Location：」に表示されているフォルダパスを控えておくとスムーズに設定できます。 8. WindowsPCのタスクバーにある「スタート」ボタンを右クリック＞「システム」を選択 9. 「システムの詳細設定」を選択 10. 「詳細設定」タブ＞「環境変数」を選択 11. システム環境変数 の「Path」を選択＞「編集」ボタンを選択 12. 「新規」ボタンを選択＞Android Studioをインストールした時に一緒にインストールされた、フォルダ「platform-tools」のフォルダパスを入力 13. 開いている各ウィンドウを「OK」ボタンを押下して閉じる 【注意】手順13.で「キャンセル」ボタンを押下すると、ここまでの設定が反映されないため、必ず「OK」ボタンを押下して各ウィンドウを閉じてください。 14. PCを再起動する PCを再起動します。 15. ADBコマンドが有効になっているか確認する ここまでの設定が反映されているか、確認を行います。 WindowsPCの「コマンドプロンプト」を起動します。 （「スタート」アイコンをクリック＞「 cmd 」で検索＞コマンドプロンプトを選択。または、タスクバーの検索アイコン・検索ボックスから「 cmd 」で検索＞コマンドプロンプトを選択） 16. 「 adb 」と入力してEnterキーを押下する 画像のようにコマンドの引数（内部デバック[internal debugging：]）、USBの接続[usb：]などの情報）が一覧になって出てくれば、ADBコマンドが有効になっている。 ※ADBコマンドが有効になっていない場合、下記エラーメッセージが表示されます。ここまでの設定や入力した文字列に誤りが無いか確認してみてください。 17. Androidの「開発者向けオプション」を表示する Androidの「設定」＞「デバイス情報」＞「ビルド番号」の部分を連続で7回タップします。 ※Androidによって「ビルド番号」の表示箇所が異なる場合があります。 18. 「開発者向けオプション」を有効にする 「設定」＞「システム」＞「開発者向けオプション」を選択して「開発者向けオプションの使用」のトグルボタンを有効にします。 19. 「ワイヤレスデバッグ」を有効にする 「ワイヤレスデバッグ」のトグルボタンを有効にして表示されたウィンドウで「許可」を選択します。 ※「このネットワークで常に許可する」にチェックを入れてから「許可」を選択すると、2回目以降の接続時にこの手順が不要となります。 20. AndroidとWindowsPCを同じWi-Fiに接続する AndroidとWindowsPCを同じWi-Fiに接続します。 21. AndroidとWindowsPCのペア設定を行う WindowsPCのAndroid Studioを起動＞デバイス表示部分のプルダウン＞「Pair Devices Useing Wi-Fi」を選択して「QRコード」を表示します。 22. AndroidでQRコードを読み込む Androidで「設定」＞「システム」＞「開発者向けオプション」＞「ワイヤレスデバッグ」＞「QRコードによるデバイスのペア設定」＞「QRコードのスキャン」から、WindowsPCのQRコードを読み込みます。 読み込みに成功すれば、ペア設定は完了です。 23. AndroidのChromeでテスト対象ページを開く AndroidのChromeでテストの対象ページを開きます。 24. WindowsPCのChromeを開き、アドレスバーに「 chrome://inspect/devices 」と入力してアクセスする 25. 接続しているAndroidの端末名とブラウザ、テスト対象ページのURLがWindowsPCのChromeに表示されるので、URLの下にある「 inspect 」を選択する 26. デベロッパーツールが開く WindowsPCのChromeの左側にAndroidの画面、右側にデベロッパーツールが表示されます。 27. デベロッパーツール内の通信情報を確認 スマホでアクセスしたwebサイトを操作して、デベロッパーツールでwebサイトの通信情報を確認する。画像は「Network」タブに情報が表示されている状態。 以上で、AndroidとWindowsPCの設定は完了です。 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をライトニングケーブルで接続する iPhoneとMacPCをライトニングケーブルで接続します。 4. iPhoneとMacPCを同期する MacPCの「Finder」から接続したiPhoneを選択＞「一般」＞「このiPhoneが接続されているときに自動的に同期」のチェックを外す＞「同期」ボタンを選択します。 同期が完了したら、ケーブルを抜いてください。 5. iPhoneとMacPCを同じWi-Fiに接続する 6. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞「ネットワーク経由で接続」にチェックを入れる 7. iPhoneのSafariでテスト対象ページを開く iPhoneのSafariでテスト対象ページを開きます。 8. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択する MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択します。 9. Webインスペクタが開く Webインスペクタが開きます。 10. Webインスペクタ内の通信情報を確認 iPhoneでアクセスしたWebサイトを操作して、WebインスペクタでWebサイトの通信情報を確認する。画像は「ネットワーク」タブに情報が表示されている状態。 以上で、iPhoneとMacPCの設定は完了です。 設定時の失敗例 設定が上手くいかない例として以下があります。 スマホとPCが異なるWi-Fiに接続されている 接続するWi-Fiは同じである必要があります。普段使用するWi-Fiが1つの場合は特に問題ありませんが、複数のWi-Fiを使い分けている場合は注意してください。 今回紹介した手順は、各手順毎に設定が行えていることを確認しながら進めれば上記以外の要因で失敗することは無い手順となっています。 注意点 PCとスマホを接続した状態のままにしておくと、スマホとPCが勝手に接続されてしまい第三者に見られたくない情報を盗み見される可能性があります。（例：PCを複数人で使いまわして作業をしている場合） 作業をしない時は、PCとスマホの接続を解除しておくことをお勧めします。 接続を解除する方法としては、「PCとスマホを同じWi-Fiに接続しない様にする」が簡単です。 先の手順で記載した様に、「PCとスマホが同じWi-Fiに接続されている」状態だとペアリングが行われるためです。 また、Androidであれば「開発者オプションを無効にする」、iPhoneであれば「Webインスペクタを無効にする」ことでも接続が解除されます。 なお、以前紹介したケーブルでPCとスマホを接続する手順では、ケーブルを抜けば接続が解除されるためその様なことは発生しません。 おわりに 今回はPCのブラウザ機能であるデベロッパーツールを、Wi-FiでPCとスマートフォンを接続して使用する方法を紹介させていただきました。 ケーブルで接続していないため、ケーブル長に左右されずに作業が行えること、スマホやPCの接続端子を自由に使用できる利点があります。 今回の方法を実際に試してみると、スマホとPCがケーブルで接続されていない状態だと想像以上に端末の取り回しがし易く、快適に作業を行うことができました。スマホ＋デベロッパーツールでテストを行う場合にぜひ使用してみてください。 The post Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう(第二弾) first appeared on Sqripts .

こんにちは。インフラエンジニアのTYです。普段はAWS,GCPなどのクラウドを扱ったサービスの検証・開発を行っています。 実は以前「 Asterisk入門~SIPフォンで通話してみる~ 」というブログを書かせていただきました。今回はAsteriskの別の機能についてお話ししたいと思います。 Asterisk入門　～SIPフォンで通話してみる～ 1. 概要 AsteriskはオープンソースのPBXです。PBXとは”Private Branch Exchange”の略で日本では”電話交換機”と訳すのが一般的です。1つの親番号に着信した通話をコールセンターやオフィス内線の様に適切な端末に振り分けます。 そんなPBXであるAsteriskですが、PSTNやSIPでの通話もちろんWebRTCでの通話も可能です。 Asteriskの情報は思っているよりも少なく、自分で構築した際にはWebRTCで通話できるようにするだけでも少し苦労しました。本記事では、私自身の備忘録もかねてAsteriskでWebRTC通話ができるようにしてみたいと思います。 2. 構築 AWS EC2インスタンスにUbuntuをセットアップし、そこにAsterisk,WebRTC通話で利用するブラウザアプリをインストールして構築していきます。 2.1 EC2 EC2インスタンスにUbuntuをセットアップし起動します。インスタンスタイプは小さいもので問題ないです。 2.1.1 セキュリティグループ セキュリティグループは以下のようにします。 セキュリティグループ ※アクセスするIPが制限できる場合は制限しましょう。 2.2 Asterisk導入 2.2.1 Asteriskインストール EC2にsshでログインし、Asteriskを導入します。 まずはシステムが更新されているか確認してください。 shell-session $ sudo apt-get update Asteriskをインストールします。 shell-session $ cd ~ $ wget <http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz> $ tar -xvf asterisk-18[tab] $ cd asterisk-18.[tab] $ sudo su # contrib/scripts/install_prereq install # ./configure --with-pjproject-bundled # make menuselect # make && make install && make config # exit $ cd ~ 次にAsteriskの設定ファイルをインストールします。 shell-session $ git clone <https://github.com/InnovateAsterisk/S2E2.git> $ sudo cp ~/S2E2/config/* /etc/asterisk 2.2.2 Asterisk設定( http.conf ) AsteriskでWebRTC通話を行うにはAsteriskのhttpサーバー機能を有効化します。 /etc/asterisk/http.conf を以下の様に変更します。 shell-session $ sudo vim /etc/asterisk/http.conf [general] enabled=yes ; HTTP bindaddr=127.0.0.1 bindport=8080 tlsenable=no ; HTTPS enablestatic=no Asteriskを再起動します。 shell-session $ sudo service asterisk restart 2.3 apacheインストールと構成 WebRTC通話で利用するブラウザアプリを用意します。今回はブラウザアプリもAsteriskと同じサーバーに配置します。 まずはapacheをインストールし設定します。 shell-session $ cd ~ $ sudo su - # apt-get install apache2 # a2enmod ssl # a2enmod proxy # a2enmod proxy_http # a2enmod proxy_wstunnel 必要なポートを開放します。 shell-session # vim /etc/apache2/ports.conf Listen 0.0.0.0:80 Listen 0.0.0.0:443 Listen 0.0.0.0:4443 Webアプリで利用する設定を行います。この時にDNSサーバーにAsteriskサーバーのIPアドレス指すエントリファイルを作成する必要があります。DNSサーバーは何でもいいですが、AWSだとroute53を利用できます。 shell-session # vim /etc/apache2/sites-enabled/000-default.conf <VirtualHost 0.0.0.0:80> ServerName <Asteriskサーバーのドメイン> DocumentRoot /var/www/html </VirtualHost> apacheを再起動します。 shell-session # service apache2 restart snapとcertbotをインストールし、証明書を発行します。 shell-session # snap install --classic certbot # ln -s /snap/bin/certbot /usr/bin/certbot # certbot --apache certbotが完了すると、新しい設定ファイルが作成されるので、それを開いて ws/ ホストを追加します。 shell-session # vim /etc/apache2/sites-enabled/000-default-le-ssl.conf <VirtualHost 0.0.0.0:4443> ServerName __copy_from_above__ DocumentRoot /var/www/html SSLCertificateFile __copy_from_above__ SSLCertificateKeyFile __copy_from_above__ Include /etc/letsencrypt/options-ssl-apache.conf ProxyRequests off ProxyPreserveHost On ProxyPass /ws ws://127.0.0.1:8080/ws ProxyPassReverse /ws ws://127.0.0.1:8080/ws </VirtualHost> apacheの設定はこれでOKなのでapacheを再起動し、設定を反映します。 shell-session # service apache2 restart # exit $ cd ~ 2.4 ブラウザアプリインストール WebRTC通話で利用するブラウザアプリをインストールし、ドキュメントルートに配置します。 shell-session $ git clone <https://github.com/InnovateAsterisk/Browser-Phone.git> $ sudo cp -r Browser-Phone/Phone/* /var/www/html/ 2.5 Asteriskユーザー設定( pjsip.conf/extensions.conf ) ここまでで利用するWebRTCアプリの設定が完了しました。最後にAsteriskサーバーの設定を行います。 まずは pjsip.conf でWebRTCで利用するユーザーを作成します。 /etc/asterisk/pjsip.conf を編集します。githubから設定ファイルをインストールしているためそこに以下を追記します。 このconfファイルでAsteriskで使用するユーザーを定義します。 ※パスワードはお好きな文字列に変更してください。 shell-session $ sudo vim /etc/asterisk/pjsip.conf ; == Users [User1](basic_endpoint,webrtc_endpoint) type=endpoint callerid="One Hundred" <100> auth=User1 aors=User1 [User1](single_aor) type=aor mailboxes=User1@default [User1](userpass_auth) type=auth username=User1 password=1234 [User2](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Two Hundred" <200> auth=User2 aors=User2 [User2](single_aor) type=aor [User2](userpass_auth) type=auth username=User2 password=1234 [User3](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Three Hundred" <300> auth=User3 aors=User3 [User3](single_aor) type=aor [User3](userpass_auth) type=auth username=User3 password=1234 次に /etc/asterisk/extensions.conf を編集します。こちらもgithubからインストールしているため以下を追記してください。 このconfファイルでダイヤル番号とユーザー紐づけます。 shell-session $ sudo vim /etc/asterisk/extensions.conf [subscriptions] exten => 100,hint,PJSIP/User1 exten => 200,hint,PJSIP/User2 exten => 300,hint,PJSIP/User3 [from-extensions] exten => 100,1,Dial(PJSIP/User1,30) exten => 200,1,Dial(PJSIP/User2,30) exten => 300,1,Dial(PJSIP/User3,30) exten => _[*0-9].,1,NoOp(Music On Hold) exten => _[*0-9].,n,Ringing() exten => _[*0-9].,n,Wait(2) exten => _[*0-9].,n,Answer() exten => _[*0-9].,n,Wait(1) exten => _[*0-9].,n,MusicOnHold() exten => e,1,Hangup() ここまでで設定出来たらAsteriskを再起動します。 shell-session $ sudo service asterisk restart ここまででAsteriskサーバーおよびWebRTCアプリの構築は完了です。実際に動作を確認してみましょう。 3.動作確認 動作確認のためWebRTCアプリに接続します。Chromeで以下のURLにアクセスします。 shell-session https://<Asteriskサーバーのドメイン> アクセスすると以下のようなサイトが表示されます。 WebRTCアプリ アカウントをクリックし、Asteriskサーバーに登録します。赤枠内にはAsteriskサーバーのドメインを入力します。パスワードには pjsip.conf で設定した値を入力します。 Asterisk登録 Asterisk登録2 そのほかはデフォルトのままで保存します。 シークレットウィンドウや別ブラウザなどでもう一つWebRTCアプリを表示し、そちらは別のアカウントで登録します。本記事の内容だとUser2 or User3があるはずです。 アカウントが2つ登録出来たらどちらかのアカウントから発信してみましょう。右上の電話マークをクリックし発信先にダイヤルします。ダイヤル番号はUser1なら100、User2なら200といったようになっています。このダイヤル先の設定は extensions.conf で行っています。 WebRTCダイヤル うまく設定できていればブラウザ同士で通話ができるはずです！ 4.さいごに 今回はオープンソースのPBXであるAsteriskをWebRTCの通話ができるように構築しました。音声のみの通話だけでなくビデオ通話も可能になっています。また、AsteriskはPBXであるため、通話の転送や着信をキューに入れて待機させておくことも可能です。 本記事でインストールしたWebRTCアプリには”SIPJS”というライブラリが使用されています。これはjavascriptでAsteriskを利用できるようにするためのライブラリでこのライブラリを利用すれば自作のWebRTアプリでAsteriskを利用することも可能です。私はまだそこまでチャレンジできていませんがそのあたりにもチャレンジしていきたいと思います。 ありがとうございました。 The post Asterisk入門～WebRTC通話編～ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第8回となる今回のテーマは「コストマネジメント」です。 限られた財源を意識してプロジェクト内で追加コストが発生しないように管理し、プロジェクトの目的・目標を達成することはとても重要です。 しっかりとしたコスト計画方法を知り、コストをマネジメントを適用することで、プロジェクトにとってコストは「管理するだけではない、変化に対応する武器」になるはずです。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ コストマネジメントとは コストマネジメントとは、プロジェクト予算内で遂行するための必要コストの見積もりや予算策定、それらをコントロールする活動を指します。 プロジェクトを行うには、当然ですが人件費や開発費用といったコストが発生します。プロジェクトにおける「鉄の三角形」である QCD ※1 に「C：COST」があるように、コストをしっかりと管理していないと、プロジェクトを終えられたとしても赤字になるなどして、プロジェクトが失敗したという評価になる可能性があります。また、予算超過が原因でプロジェクトが停止してしまうこともあります。まれに小さなプロジェクトでは詳細なコスト管理まで求められないこともありますが、プロジェクト予算が設定されている場合にはしっかりとコスト計画とマネジメントを行っていきましょう。 コストマネジメントは以下4つのステップ（プロセス）で行います。 ※1 QCD 「QCD」とは、Quality（品質）、Cost（費用）、Delivery（納期）の頭文字を重要度の高いものから順に並べたものです。 コストマネジメントのはじめかた 1) WBSやGANTTチャートから「コスト管理表」を作成し見積もってみる アクティビティタスクのコスト合計＝要素成果物のコスト 要素成果物のコストの合計＝成果物のコスト 成果物のコストの合計＝プロジェクト全体のコスト 各活動のコストを見積もる際は、タスク実施に必要な期間やそのタスクで利用する人件費や原材料費など必要な経費も追加します。また成果物の作成や伴う活動を外注する場合には、別途見積書を入手してコストに付加していきます。 2) コスト計画や管理表記載時の注意点 コスト計画や管理表に記載する際は、管理する資源ごとの単位を規定しましょう（例：時間を測定する場合は、労働時間や日数、通貨など）。記載の精密さのレベルや正確さのレベル設定も併せて必要です（例：見積りの正確さの許容範囲を±10％とする、といったレベルを設定するなど）。 また計画したコストの値からどれぐらい変動があったら手当をしなければならない、といった「閾値」を設けておかないと、Aさんは「これくらいのコスト変動（予実差）は許容できるだろう」と思っていても、Bさんは「すぐに処置が必要だ」と感じるかもしれません。そのような感覚に左右されないコスト監視やコントロールができるよう事前に計画、準備記載しておきましょう。 コストの見積もり 1) 見積もり精度のブレは結構大きい（最初から正確を求めない） プロジェクトの見積もり精度はプロジェクト活動が進むにつれて向上します、つまりプロジェクト初期（立ち上げフェーズ）はどうしてもその精度は十分ではありません。 ※PMBOKによる指標 また「超概算」と呼ばれる見積もりは-50～＋100%、予算化するタイミングでの概算は-10%～＋25%とされています。 2) 見積もり方法 コストの見積もりは、人件費（単価）、材料費、インフレーション、リスク要因など数多くの変数の影響を受けます。専門家や社内外にある経験や知識を集積して見積もるようにしましょう。 過去の類似プロジェクトの見積もり 業界、領域、専門分野の情報　 成果物の内製化や外製化の検討 （代替案分析） など 3) マネジメント予備、コンティンジェンシー予備 マネジメント予備（予備費）、コンティンジェンシー予備（予備費）という言葉を聞いたことがあるでしょうか？どちらもプロジェクトのコストとして予備的に計画/準備されるコストです。 コンティンジェンシー予備とは、主にリスク発生を鑑みて適応されるコストです。 例えば「成果物のどこかに手直しの発生が想定されるがどこであるか（手直しが発生するかも）わからない、もし発生した場合にかかるコストを予め用意しておこう」というものがこのコンティンジェンシー予備の使い先になります。一般的にはPMの裁量で使用することができます。 マネジメント予備は上記に対して「予期せぬ作業や事象に備えて用意」しておくコストです。例えば「プロジェクトの途中でクライアントから突発の追加要求が上がってきた」という「いざ」という事態に使うかもしれません。使用にあたってはプロジェクトスポンサー（PO）の承認が必要です。組織やプロジェクトによって「（見積予算 + コンティンジェンシー予備）× ○%」と一律規定、準備する場合もあります。 4) 品質コストを盛り込もう 品質コスト（COQ：Cost Of Quality）の前提条件を盛り込む必要があります。品質コストとはその通り品質を確保するためのコストであり、予防コスト、評価コスト、不良コストなどが含まれます。 コストをマネジメントするために コストコントロールの大部分は、コストの消費と当該支出の作業結果の関係を把握し分析することです。その時に単に「支出だけ」を追跡するのではコストコントロールの意味はぼやけます。必要なのは、達成した作業の本当の「価値」であり、それらを数値的に捉え「コントロール」することです。 「遅れています」「進んでいます」「月末までには完了すると思います」 こういった主観的な報告（説明）に対して、マネジメント者として客観的に「ほんとうに？」という疑問や、「そうだよね」という納得を返せる助けになるのが、複数の指標をコストに換算して管理できるアーンド・バリュー・マネジメント(EVM：Earned Value Management)という手法です。 まずはEVMを解し、プロジェクトの進捗状況や将来の問題をコストコントロールをしながら察知できるようにしましょう。 1) EVMで実績と進捗を定量的に可視化 EVMを使用する最大のメリットは コスト目線でのプロジェクト状態を「客観的に」測定することができる 精度の高い将来予測（見積もり）ができるようになる ことにあります。実際に、1960年代の米国でその膨大な国家赤字を見直すために、国防省でプロジェクトのパフォーマンス測定方法が見直されたことにEVMの起源があります。その後は米国産業界のガイドラインとして、政府調達のプロジェクトの前提条件となっています。 2) EVMで使う指標 EVMとは現在の進捗状況や将来の問題を察知するプロジェクト管理の手法のひとつです。難しくはありません、4つの指標を覚えましょう。 これらのPV、AC、EVの指標を使い、コストを縦軸、経過期間を横軸とするグラフを作成します。このグラフを基にこれまでのプロジェクトに費やされた作業量から推定し、プロジェクト完了にはどうなるか、という見積もりができるというわけです。EVMやそれら使った実績推移グラフからスケジュールの遅延やコストの超過が読み取れるなど、計画と実績の乖離が起きていたら即座に手を打つなど、問題が改善できるうちに対処するなどの予防を行いましょう。 3) EVMを使わないプロジェクト規模 EVMの他にも複数のコスト分析方法がありますが、まずはEVMをコストマネジメントに取り入れられれば十分です。むしろ、誤解を恐れずに言えば多くのプロジェクトで十分にEVMが使われていません。小規模プロジェクトではコスト管理のためのコストをかけることで、プロジェクト自体がショートすることになりかねないからです。筆者の感覚では最低5000万円以下のプロジェクト規模であれば、EVM以外のコスト管理をおすすめします。 コストが溢れそうだ！その時は。 プロジェクトは段取り（準備）が肝であり、コストもいかに計画、計算、想定しておけるか（計画の上で実行できるか）が、その後のプロジェクト成功の鍵です。残念ながら、どれだけ計画しても「まったく計画通り」に進むことは少ないですが、少なくともそれらの「事態」に予備費を準備したりするなど備えをしてきましたね？ みなさんがコストに対して、最も注力して対処するタイミングは「計画時」です。 コスト計画時に プロジェクトオーナーから指示された予算よりオーバーしてしまいそうだ 明らかにプロジェクト憲章に記載した予算と乖離があるぞ とわかったらしめたものです。計画時には2つの方法で予算とコストをポジティブに調整していきましょう！ 1) 基本的なコスト修正対応（1） 成果物の機能を簡易的な内容に調整したり、予定していた活動やタスクを見直す＝（今回は）やめる/スコープから切り離すなどしてコスト調整する「ECRS（イクルス）」を試しましょう。 ECRS（イクルス）とはEliminate（排除：取り除く）、Combine（結合：つなげる）、Rearrange（交換：組み替える）、Simplify（簡素化：単純にする）の頭文字で、元々は製造現場における的確な課題抽出と効果的な業務改善の手法として考えられたものですが、現在ではさまざまな業務改善に用いられています。 排除（Eliminate）：その業務をなくすことができないか？ 結合（Combine）：その業務を他の業務などと一緒にまとめられないか？ 交換（Rearrange）：その業務の順序や場所などを入れ替えることで、効率化できないか？ 簡素化（Simplify）：その業務のやりかたをより簡単にできないか？ 一般的にE→C→R→Sの順に改善効果が大きいと言われています。 2) 基本的なコスト修正対応（2） 予算自体を変更する（してもらう）交渉を恐れずに行いましょう。プロジェクトオーナーやクライアントなど、決裁者との会議や検討を設定し、予算自体適切に変更するための承認活動を行います。つまりプロジェクト憲章自体の予算を変更する、ということになります。いわずもがなですが、安易に予算変更（予算オーバー）承認を得るという考え方ではありませんので注意してくださいね。 多くの場合は、修正対応 （1）と（2）を組み合わせた検討と交渉/承認がスタンダードです。無理な計画、無理のあるコストでプロジェクトを実行しても、後々苦しくなります。プロジェクトの目的/目標の達成に必要な修正対応は早めに行いましょう。 おわりに PMは「限りある予算と限りない要求という圧力」と常に共にあり、コストマネジメントは大変困難な仕事です。そしていかに計画・準備とマネジメント施しても、どうしてもオーバーランするものだと意識してください。ITプロジェクトでは規模が大きくなる程予算超過率も高く、超過しないプロジェクトの方が少ないでしょう。コストの適正さや課題を日頃からプロジェクトオーナーと共通認識をもっておくこと。最も情報が少ないプロジェクト初期がコストマネジメントの重要タイミングであることを忘れず、コストマネジメントを困難にする様々な要因に立ち向かっていきましょう！ 次回のテーマは「プロジェクトの品質マネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ The post 【第8回】コストをプロジェクトの武器にする！ first appeared on Sqripts .

はじめまして。テストエンジニアのサバコ、りんご、ぴょんです。 私たち2名は、昨年よりQA事業に携わる部署の所属となり、現在はテスト実施業務に従事しています。まずはテスト実施で経験を積みつつ、将来的にはテスト設計者へステップアップしたい・・・！という目標を掲げ、日々業務に取り組んでいます。 そんな私たちは昨年、社内で1ヵ月間の「テスト設計者研修」を受講する機会がありました。今回のブログでは、テスト設計未経験の私たちが1ヵ月間の設計研修で何を学び、どんなことを感じたかをお話ししたいと思います。 テスト設計者研修の概要 1．座学（約１週間） はじめに、約1週間の座学を行いました。座学ではテストに関する基礎的な内容を中心に学習しました。 ソフトウェアテストの基礎とテスト工程の概要を学ぶ ブラックボックステスト技法の学習および演習 理解度テスト（1日）：主に各テスト技法の習得度を確認するテスト 2．テスト設計演習×2回（各1週間） 座学の次は、テスト設計演習を２回にわけてそれぞれ１週間ずつ行い、より実践的な学習を行いました。 演習用のシステム仕様書を基に「テスト設計仕様書」を一通り作成し、適切なテスト技法を用いてテストケースを作成するまでの演習 2回目の演習では、顧客への説明を想定したプレゼンテーションも行う テスト設計者研修で学んだこと、感じたこと 1．テストに関する知識・考え方の変化 座学の研修は基礎知識に関する講義が中心でしたが、その中でも重要なポイントについては実例を交えた丁寧な解説があり、テスト業務の全体像が理解しやすい講義でした。特に、テスト設計の一連の流れを学ぶことができたのはとても有意義でした。 受講前は、テスト実施業務で使用している「テスト項目書」は、開発仕様書などから直接起こすもので、イメージとしては「Verification（検証）」の視点に基づくものと考えていました。 しかし、実際には機能の洗い出し、テスト観点の抽出、洗い出した機能へのテスト観点の割り当て・・・など、様々な分析を行いながら「テスト設計仕様書」を作成し、開発仕様書には記載のない部分、ユーザーの要求・ユーザーの使い勝手なども意識した「Validation（妥当性確認）」の視点も含めて、ひとつひとつのテストケースが作られていることを学びました。 普段目にしている「テスト項目書」がどのようなプロセスを経て作成されているかを学び、また設計演習でそのプロセスを実際に順を追って体験できたことで、現在のテスト実施業務においても、 なぜこの観点が用いられているのか この項目にかかる工数は適切なのか などを考えながらテストに取り組むようになりました。 また、 挙動は仕様通りだが、システムの応答時間が若干遅いのでは （とあるシステムで）メッセージの送信時間に、時間だけでなく「日付」も付与した方がユーザーにはわかりやすいのでは など、ユーザビリティの観点を考慮して報告・要望も挙げられるようになってきたり、テストを行う際の「意識」にも少しずつですが変化が出てきたように思います。項目書の文字を追うだけのテストではなく、設計者の意図やテストを行う意味をしっかり理解した上で実施することで様々な気付きが生まれ、より質の高いテスト実施が可能となることをあらためて実感しています。 他にも、テスト設計演習の際、「ローレベルなテスト項目書の作成」を心掛けるよう指導がありましたので、実業務で触れるテストケースについても、 経験の浅いテスターでも、正しいテストが実行できる前提条件・実施手順となっているか 明確な期待値の記載がされているか など、ローレベルな項目書になっているかを常に考えながら見るようになりました。 「テスト設計には正解がなく、テスト設計者によってテスト項目にも違いが出る」とのことでしたので、この先もテスト実施を数多く経験していく中で様々なテスト項目書・テストケースに触れながら、実施しやすいテスト項目書のノウハウを身につけていきたいです。 2．難しかったこと、苦労したこと ブラックボックステスト技法の理解・習得 「同値分割法」「境界値分析」は比較的理解しやすく、実業務でも「テスト項目に具体的な入力値の記載がされていなくても、同値クラスや境界値を入力してテストする」など、ある程度自分で考えて活用できるようになりました。 が、「デシジョンテーブル」「組み合わせテスト」は、どういったケースに用いると有効なのかの見極めと、正しい条件が設定できているのか・・・などの判断がしづらく、演習でもうまく活用することが難しかったです。 とはいえ、膨大・複雑な仕様、入力条件を整理するためにはテスト技法の活用は必要不可欠とのことなので、それぞれの技法に慣れるために「テスト技法の問題集」などを活用し、自学に励みたいと考えています。 顧客への説明を想定したプレゼンテーション 緊張感が高まる中、「テスト設計仕様書」と「テストケース」をどのように作成したかの説明に終始する・・・という反省点の多いプレゼンとなってしまい、少々ハードルの高い演習でした。後に過去の研修の模範的なプレゼンテーションの動画が共有され、プレゼンのあるべき姿が把握できました。 正しいテストを行うためには、ステークホルダとの綿密なやり取り・テストに関する意識の擦り合わせが特に重要であることを学びました。 3．全体的な感想 ・主に「Meet」を利用したオンライン研修でしたが、並行してコミュニケーションツール「Metalife」も活用しました。「Metalife」は、研修メンバー全員での会議はもちろんのこと、受講者同士個別でも気軽にやり取りができるツールで、アバターを作成できるゲームのような機能が搭載されていたこともあり、気軽に利用できました。対面でないと一方通行になりがちですが、こうしたツールを上手に活用したコミュニケーションの取りやすい研修だったと思います。 ・テスト設計の知識が乏しかったため、理解のスピードや演習の進みが遅く、講師の方には苦労をお掛けしたことと思います。そんな中でも、都度Slack・ハドルミーティング等で最大限のアドバイス・フォローをいただくことができたので、設計演習・プレゼンテーションとも反省点は多々あるものの、ある程度の形に仕上げることができました。 ・研修全体を通して、学ぶべき情報量が多く、1ヵ月ではとても頭に入りきらない・・・と焦る気持ちが大きかったですが、研修で使用した資料や演習教材は研修終了後も参照できるよう共有されているため、今後も折に触れ参考にし、引き続き設計に関する知識を深める努力をしたいと考えています。 まとめ 1ヵ月という短い期間で、理論だけでなくテスト設計演習・プレゼン演習なども含めた実践的なスキル研修まで学ぶことはなかなか大変でしたが、得られたものは大きかったと思います。 社内で充実した研修を受講できたことで、テストに関する学びを深められ、日々のテスト実施にも自信を持って取り組むことができるようになりました。 今後も日々の業務を行う中で、研修の内容を反芻しながら知識を増やし、直近の目標として、まずはJSTQB FLの合格を目指したいと思います。 そして将来的には、テスト設計業務にも挑戦しスキルを更に高めていけるよう、前向きに進んでいきたいです。 おわりに 講師の方による研修ブログに、さらに詳しい研修内容の解説があります。ご興味のある方は是非ご覧ください！ テスト未経験者向けに研修を行って、気付かされたこと(前編) テスト未経験者向けに研修を行って、気付かされたこと(後編) The post テスト設計未経験者がテスト設計研修を受けて感じたこと first appeared on Sqripts .

こんにちは、エンジニアのしているタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自分たちのプロダクト開発チームで行なっているNotionとGitHubを使ったリリースバージョンの管理について紹介したいと思います。 リリースバージョンとは プロダクトの開発において、開発の区切りや本番リリースを行う段階で、プロダクトに バージョン という一意の番号を付与することがあります。 これはプロダクト（ソフトウェア、インフラ等）のとある段階を指し示すための番号であり、この番号とリリース日などを併せて管理することで、プロダクトの実装済み機能や改修の状態が、チーム内外から分かりやすく判別できるようになります。 例. A機能はバージョン1.0.0で実装した。Bの改修はバージョン1.1.2で行っており、このタイミングでデグレードが起きたなど このうち、本番環境にリリースしたものをリリースバージョンと呼びます。 リリースバージョンを定義することで 「◯月◯日」にリリースした機能 ではなく、 バージョン1.0.0でリリースした機能 といった呼称にでき、機能やリリース時期の関係が分かりやすくなります。 リリースバージョンと管理内容 自分たちのプロダクト開発チームでは4つのリリースバージョンを定義しています。赤字の数字が対象のバージョンに対応する部分です。 これらのリリースバージョンは、リリース日と後述の情報を併せてNotionのDBで管理しています。 リリースバージョンのDB. リリース日はグレーアウトしています ページの内容 リリースバージョンと紐づけて管理している内容は以下の4つになります。 Product Back Log（PBI） リリースノートのページURL コンテナのリビジョン リポジトリのmainブランチのタグ 1.のPBIは、Notionで別管理しているPBIのDBとの関連付けを行っています。また、2. のリリースノートのページURLは、公開したリリース情報に関するページなどのURLを載せています。 3.と4.については以降で個別に解説します。 コンテナのリビジョンを取得する 自分たちのプロダクトの環境は、Google CloudのCloud Run（コンテナ）を使用しています。 デプロイをするかサービスの構成を変更すると、コンテナごとにリビジョンと呼ばれる設定やコードバージョンのキャプチャ情報が生成されます。 このリビジョンにはコンテナのURLや環境変数などの設定に加えてデプロイしたソースコードも含まれ、GUI上から選択することでコンテナ単位で過去のリビジョンに戻すことも可能です。 Cloud runのリビジョンは、事前にインストールした gcloud CLIにプロダクト環境のプロジェクトを設定したうえで、以下のコマンドで取得できます。 $ gcloud run revisions list | grep yes このコマンドを実行するとリージョン選択を促されます。 リージョンを選択すると存在するコンテナの現リビジョンが表示されるので、先ほどのNotionのページにコピー & ペーストしています。 リポジトリのmainブランチのタグ管理 次はGitリポジトリでmainブランチのタグ管理を行います。 通常、タグはリポジトリをcloneしてきたうえで、ローカルリポジトリのmainブランチに切り替えて打つ方法が一般的です。 $ git checkout main $ git tag -a 1.0.2 -m '1.0.2リリース' $ git push origin 1.0.2 （又は git push origin --tags） ただし、ソース管理をGitHubで行なっている場合、 GitHubのRelease機能 を使うことでより簡単に管理が可能です。 機能で管理するメリットはいくつかありますが、タグ打ちとRelease関連情報の記録を同時に行うことが最大のメリットかと思います。 リリース機能の特徴 * GUIでタグを打てる * リリース情報を（commit情報を引っ張ることで）半自動生成で書けてファイル添付も出来る * リポジトリの利用者がRelease機能のページからソースや配布ファイルを簡単にダウンロードできる Release機能の使い方 1. リポジトリトップページの Tags をクリックします。 2. Releasesタブで、 Draft a new Release ボタン をクリックします。 3. Releaseの画面で、 Choose a tag プルダウン からタグを新規作成し、Targetブランチを指定します。今回は本番リリースのバージョンを管理するのでmainを指定します。 入力欄 4. タイトルと説明を入力していきます。本文はGenerate Release Notesボタンでcommit内容が自動で入力されますので、これを使用します。 5. 併せて、Notionのリリースバージョンページへのリンクも掲載して関連付けを行います。 6. 作成ボタン を押して画面が作成されたらOKです。 作成後のページ。内部情報が含まれているのでグレーアウトしています おわりに 今回の内容は以上となります。 現状、本日紹介した内容はリリース作業の一部として組み込んでおり、担当者が手動で実施しています。 現時点ではまだ発展途上であり、今後管理すべき情報がもっと増えた場合はそれに応じて追加していく予定です。 なお、コンテナリビジョン取得やNotion APIを用いてのページ作成等は比較的簡単に自動化できる思うので、リリース時の負荷はまだまだ減らせると思います。 リリース内容の管理に困っている方はぜひ一度試してみてください。 The post GitHubとNotionで実現するアジャイル開発のリリースバージョン管理 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 はじめに どちらが「論理的」だと感じますか？ 図1-1、PさんとQさん、どちらが「より論理的」だと感じますか？　その理由は何ですか。 図1-1 食堂で注文を話し合うPさんとQさん 「論理の言葉」を覚えたら “実践編”のテーマ 論理スキル”実践編”では、”入門編”で出てきた「基本的な論理の言葉」を基にして、文や文章の論理構造を読み取ったり、筋道立った文を作ったりするための 「推論」の形 を見ていきます。 不具合/故障のチケットやテストサマリレポートを書きあぐねた経験はありますか。テストベース（要件定義書、機能仕様書、ユーザーストーリー、etc.）や返ってきたチケットを読んで、「どんな場合にどうなるのかわからないな？」「何故この対応でよいと言えるんだろう？」などと感じたことはありますか。 ソフトウェアの世界でも、(長めの)文/文章を読み書きする機会は多くあります。こうした困りごとをなくすためにも、 論理の言葉の使い方、使われ方 の感度を研ぎ澄ませましょう。 ●入門編：テストエンジニアのための論理スキル[再]入門 記事一覧はこちら ｜Sqripts 推論：　話の筋道をつくる、読み取る 推論とは 何か言いたいことがある時、最終的に言いたいこと(結論)と、その結論の前提があります。結論も前提も何かしらの主張や判断ですが、ここではざっくり「文」と呼びます（本連載では、文脈によって「主張」「判断」「文」を使い分けます）。 前提となる文(主張/判断)をつなげて組み立て、結論となる文(主張/判断)を導くことを 推論(inference) と言います。(図1-2) 1-2 “推論”とは 推論では、前提(根拠)から結論までのつながり、話の筋道が重要です。(図1-3) 前提が、結論(言いたいこと)の根拠になっている 前提から結論までのつながりに無理や飛躍がない 図1-3 推論で大事なこと その話の筋道を組み立てたり、話の筋道をチェックしたりするのが、 推論の形 。 そこで活躍するのが、“入門編”で見てきた 論理の言葉 です。 形が整っていれば自動的に「正しい筋道、正しい推論」となるわけではありませんが、形がよくない立論は言っていることが正しくてもよい主張とは言えません。（「「真」と「妥当」」の節参照） 推論の種類と、”実践編”で扱う推論 推論には種類がいくつかあります。(図1-4) 図1-4 演繹と帰納とアブダクション 演繹 （えんえき） 演繹（deduction） とは、ひとつ以上の前提から結論を導き出す推論の形です（図1-4は「前提から結論」をいくつか組み合わせた複合的な形になっています）。 何かを根拠とともに主張する時、正しいと広く受け入れられた事柄に基づいて個別の事例を論じる時、などに使われます。 前提がすべて正しいなら、結論が正しいかどうかは形から判定できます。 帰納 （きのう） 帰納（induction） とは、個別の事例から一般的/普遍的な前提(各事例に共通する規則・法則、性質・特徴など)を導き出す推論の形です。 ソフトウェアのテストで、「画面AでPという操作をしたら故障Xが起こった」「画面Bで操作Pをしたら故障Xが起こった」……「どの画面でも、操作Pをしたら故障Xが起こる（のでは？）」と仮説を立ててテストを広げていくのは帰納的な推論の働きです。 有限個の事例に基づいているため、この推論から導かれる「事例に共通すること」は必ずしも正しいとは限りません（“当てはまらない例外”があり得る）。 アブダクション、レトロダクション アブダクション(abduction)、またはレトロダクション(retroduction) とは、個別の事例から、その事例(結論)に至る前提や理由を導き出す推論の形です。 アブダクション的な推論として、 デバッグ があります（故障から、その故障を引き起こす原因である欠陥を推定する）。また、欠陥の 原因分析 でもこの種の推論が働きます。 この推論から導かれる「前提と当てはまる推論」も、必ずしも正しいとは限りません（デバッグでも、原因を特定したと思ったら違っていた、やり直し。ということは多々ありますね）。 “実践編”で取り扱う推論の種類 “実践編”では、前述のうち演繹的な推論/思考を形成する推論の形を取り扱います。 帰納やアブダクションでも必要になる、思考の基盤です。 演繹的な推論にもいくつか種類がありますが、本連載では「ふたつ以上の前提(主張/判断)から、結論となる主張/判断を導く」形式を主に取り扱います。 「真」と「妥当」　～正しさの留意点 正しい推論であるためには、ふたつのことに留意する必要があります。(図1-5) 図1-5 真と妥当 「真」であること　……内容の正しさ(真偽) 前提が間違っていたり、結論が間違っていたりしていては、正しい主張とは言えません（当然ですね）。正しい前提に基づいて、正しい結論を導出するものである必要があります（図1-5の上の文が真です）。 「妥当」であること　……話の筋道の正しさ(妥当性) 前提や結論が真でも、適当に(自分に都合よく)理屈をつけるのでなく、 話の筋道が「よい形」をしている 必要があります （図1-5の上の文が妥当です） 。 「よい形」とは： 論理の言葉を適切に（意味と働きに即して）使っていること 文(主張)と文(主張)とのつながりの中で矛盾や飛躍を生じていないこと 真偽も大事だが、話の筋道も大事 前提や結論が正しくても、非妥当な(よい形でない)推論は間違った推論です。 次のa, bどちらも、①②③それぞれは正しいとしても、①②から③を主張することは妥当ではありません。 (a) ①イヌはイヌ科の動物である。②イヌは哺乳類である。∴③イヌ科の動物は哺乳類である。 (b) ①ネコにはしっぽがあるか、またはにゃあと鳴く。②うちのネコはにゃあと鳴く。∴③うちのネコにはしっぽがない。 一方、前提や結論は間違っていても、妥当な(よい形をしている)推論は作れてしまいます。 (c) ①哺乳類は空を飛ぶ。②イヌは哺乳類である。∴③イヌは空を飛ぶ。 (d) ①ネコには縞模様があるか、または単色である。②うちのネコには縞模様がない。∴③うちのネコは単色である。 両方揃って、初めて正しい推論と言えることになります。 内容の真偽はその内容を吟味しないと判断できませんが、筋道の正しさは形から判断できます。本連載で取り上げる「推論の形」はその筋道の正しさを確保する役に立ちます。 なお、「よい形」を作れていない推論や、内容に誤りがある推論の特徴を「誤謬(ごびゅう)」と言います。これらについてはシリーズ後半の記事「気をつけたい落とし穴」で取り上げる予定です。 冒頭の“問題” 「食堂で注文を話し合うPさんQさん」は「「論理的」ってどういう感じのこと？」を感じてもらいたくて考えたもので、考え方の正誤や優劣を論じるものではありません。 Pさんの主張を整理・補足すると、①初めての店では外れのなさを優先して注文する。②唐揚げは大体どの店でもおいしい（から、外れがない/少ない）。③唐揚げ定食を注文する。 となっていて、①と②から③が無理なく出てきます。 Qさんの方はどうでしょうか。 ①初めての店では（その店の「推し」として）「本日のおすすめ」を頼む。②さらに煮魚定食はこの店で一番安い（から、懐に優しい）。③煮魚定食を注文する。 Qさんの主張には、 それが嫌いな食べ物でも頼むの？ とか、 「本日のおすすめ」がメニューの中で一番高かったらどうするの？ という疑問が生じます。前提①②と結論③の間に飛躍がある感じがします。 （本“問題”は、『論理的思考の技法Ⅰ』を参考にしました） （注：「食事の注文は論理的に考えてなされなければならない」と言っているわけではありません！） （注：どちらの「注文の論理」も、ありだと思います） （注：何にせよ心地よく選んで心地よく食事を楽しみましょう！） クイズ 次の主張は「よい形」をしていると思いますか。 （『例解・論理学入門』を参考にしました） （解答は次回に） 問1 Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。 しかし、②Aさんはギャンブルには手を出さない。 従って、③Aさんは破産しない。 問2 その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。 ②彼の家柄はよかった。 しかし、③結婚できなかった。 従って、④彼は裕福ではなかった。 参考文献 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009 図版に使用した画像の出典 TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016 人物画(シルエット)をお借りしています。 Loose Drawing  人物画をお借りしています。 The post 論理のかたち。推論とは｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自身が所属する開発チームで起きたコミュニケーションの課題を解決した バーチャルオフィスツール Gatherについて、導入前後でどのようにチームに変化があったのかを紹介したいと思います。 チームのコミュニケーションの課題 開発チームが2023年夏頃に行った振り返りで、特に新しくチームに入ったチームメンバーからコミュニケーションの敷居が高いという意見が上がりました。 チームメンバーはオフィスや遠隔地の自宅などそれぞれ異なる場所で働いており、会話を伴うコミュニケーションツールはSlack（ハドル） とGoogle Meetを使用していました。 これらのツールでは、話す前に「通話いいですか？」などを一度Slackチャンネルに投稿してから行なっており、会話へのアクションが段階を踏むことで気軽に行えないという意見が上がりました。 そこで、解決策の一つとして上がったのがバーチャルオフィスツール ※1 でした。 もちろん、出社時にコミュニケーションを取ることで解決する部分はありますが、遠隔地で勤務しているチームメンバーも含めて常に全員が揃う機会は少なく、今回試すことにしました。 ※1：仮想のオフィス空間 = ワークスペースにチームメンバーがアバターとして表示され会話やチャットを行う。まるでオフィスに居るように人（アバター）の動きが可視化されるのが特徴 Gatherとは バーチャルオフィスツールは数多くありますが、無料プラン ※2 をチームで使って比較検討を行い、最終的に以下のような理由から Gather を使うことに決めました。 操作性 アバター移動の操作性とレスポンスがよく、使っていてストレスが無かった 親しみやすさ ワークスペースが上から見下ろすタイプのドット絵で描かれた2Dで、キャラクターもドット絵で馴染みやすい 筆者を含む2Dゲーム世代(?)のメンバーのウケがとても良かった ※2：この記事を書いている段階ではGatherは最大10名まで無料 Gatherを触ってみての感想 以下、Gatherの導入にあたり設けたチームルールと、主な機能を使ってみての感想になります。 導入したチームルール 定例MTGを含む、全てのチームコミュニケーションはGather内で行う 機密に関わる話、チーム外のメンバーを交えたMTGなどは除く ステータス状態を逐次変更する ステータスはコマンドで変更でき、誰が不在かが分かりやすいため 主な機能の使用感 1. アバターでのコミュニケーション Gatherを選んだ理由の一つでしたが、アバターの操作性、レスポンスがよいです。 またチームメンバーの今の状態が一覧で見れることで「あの人は今誰かと話している」「話しかけて大丈夫そう」など現実のオフィスに近い感覚で状況把握ができるようになりました。 誰かと話して別の人を呼びたい時も、手を振るという機能を使ってすぐに通知が飛ぶので、ストレスなくコミュニケーションを行うことができました。 2. ビデオ通話（多人数、少人数） ビデオ通話の品質は、meetと比較しても特に遜色はありませんでした。MTGルームや各自席周辺などのフォーカスが当たる部分に入ることで、その部分に居るメンバーはシームレスに通話に移行するので使いやすいです。 ただし、人数が増えると、PCスペックや回線によっては、ビデオをONにしたときにややPCが重くなるケースがあったため、その場合はビデオを切ってMTGしてもらうなど対策を行なうことでこの問題は解消されました。 なお、フォーカスの無い場所ではアバター同士を近づけると話せますが、基本的に各自の席周辺や大きなフォーカスエリア（MTGルーム）で話すことが多くなったため、立ち話のように何も無い場所で会話することは少なくなりました。 3. デスクトップアプリ 個人的に、Gatehrはデスクトップアプリがとても使いやすいと感じました。 アプリはミニモードという表示が行え、Gatherからフォーカスを外した時はデスクトップ上に自分のステータスが最小表示されます。このときに誰かが自分の居るフォーカス部分に来ると、ミニモードのままで通話ができます。 常に画面を出しっぱなしにしても良いのですが、集中したいときは気になるので、このモードのおかげでリモートワークのメリットと、オフィスワークのメリットの両方が満たされると思いました。 なお、この状態でキャラクターを動かすことはできないので、MTGルームに行くなどの際は、Gatherアプリを選択してキャラクターを動かします。 4. その他機能 GoogleカレンダーやSlackとの連携、Gatherへの外部アクセス制限、ゲスト招待機能、オフィステンプレートの編集機能などを使用しています。 この中のGoogleカレンダー連携は、予定の数分前にデスクトップに通知を出せるようになるので、MTG参加忘れに役立ちます。 コミュニケーションに起きた変化 Gahterを使い始めてすぐにコミュニケーションの変化を実感しました。そのうち、特に実感したことをいくつかピックアップします。 良い方向に変わったこと 1. コミュニケーションコストの低下 振り返りで課題として上がっていたコミュニケーションの敷居の高さは無事解消されました。 Slackで一言投稿するよりも、話しかけてOKのステータスの人に近寄って呼び出すことは心理的ハードルが低いという意見がありました。 また、アバターだからか誰と誰が話しているかも分かりやすくなり「朝会で報告した問題点について有識者と話していそう」など状況が掴めるようになりました。 2. MTGへのシームレスな移行 MTGをGatherで行うことにより、MeetなどのMTG用ツールの起動が不要になりました。 全員でMTGを行う際は、オフィスのように全員が集まれるエリアに移動するだけでMTGが行えるので、特にストレスなく開始できます。 議事録やチャットもGather上のホワイトボードに記録でき、全体向けに共有が必要な場合はその場ですぐに共有ができるので、プロジェクトで必要なコミュニケーションは、基本的にGather上で動作が完結できます。 気になった点 1. コミュニケーションコスト低下により、作業時間が減るメンバーが出てきた メリットと表裏一体ではありますが、気軽に会話をしやすい環境になったため、特にコアメンバーへは相談や質問でのコミュニケーションコストが生じ、作業時間が減少するという問題が起きました。 設計やレビューなどの必要なコミュニケーションが増えることは良いことですが、本来は自分で解決できるような簡単な質問も増えてしまう傾向が見られました。 リモート、オフィス関係なく基本的なことではありますが、質問する場合のルールを決めたり、優先作業に集中したい場合は応答不可にして貰うルールを設けることを検討しています。 2. リモートメンバーとオフィスメンバーが混在する場合の取り決め オフィスに出社しているメンバー同士ですと、わざわざGather上で話すよりも直接話すことが多いため、リモートメンバーからは状況がつかめなくなります。 弊社はフリーアドレス席のため、固まって仕事をすることはほぼ無いのですが、出社中の場合はステータスを記入してもらうことで状況をリモートメンバーにも明示することを検討しています。 おわりに 今回の内容は以上となります。 バーチャルオフィスツールは初めて使いましたが、結果的にコミュニケーションに対する敷居が格段に下がり、リモートワークにおけるメンバーの満足度が向上しました。 主にリモートワークでコミュニケーションに課題があるチームは一度使ってみる価値はあると感じたので、気になった方はぜひ一度試してみてください。 The post リモートワークのコミュニケーションコストがバーチャルオフィスGatherでグッと下がった話 first appeared on Sqripts .

はじめまして。テストエンジニアのchikaです。 最近はリモートワークも増えチャットツールを導入した企業が多いと思いますが、 チャットツールを使っていて情報を取りこぼしたこと 仕事はこなせているけどもうちょっと効率良く作業できないかな～と思ったこと はありませんか？ そんな２つの課題を解決に導いたTeamsの便利機能を実体験を元にご紹介したいと思います。 Microsoft Teamsとは？ マイクロソフト社が提供するコミュニケーションツールで、チャットや通話、ビデオ会議といった複数の機能が実装されています。また、Officeアプリと連携してファイルを共有したり編集ができるとても便利なツールです。 便利機能の紹介 チャットの見落とし防止 Teamsを使い始めた当初、いつの間にか色んなグループにメンバー追加されどんどんチャットがきて必要な情報を見落としてしまう始末…とても困っていました。そんな中で見つけたTeams初心者にオススメの機能です。 メッセージの保存機能 重要なチャットや後から読み返したいチャットなど、どのグループチャットからも自分専用の場所に保存することができる機能です。 保存したいメッセージの右上［‥］＞「このメッセージを保存する」をクリックすればOKです。 保存したメッセージは、右上の自分アイコンの「保存済み」をクリックすると保存済み一覧が表示され、必要なメッセージのチェック時間を削減することができます。 【補足】チェックし終わったメッセージは「保存」を外しておくと、必要な情報が整理できて 未読の確認機能 検索欄に”/unread”と入力すると、左側のフィードに未読メッセージの一覧が表示されます。　　休み明けやリアルタイムにチャットを確認できなかった場合に重宝します。 ※［アクティビティ］＞未読のみ のトグルをONにしても同様です。 自分専用チャットによる 作業効率アップ 今まで必要な情報はメモ帳やExcelにまとめていましたが「自分専用のチャット」があることに　気付き、使ってみたらファイルを開いて知りたい情報に行きつくまでのちょっとした手間が省け、　以前より情報収集のスピードがアップしていました。 日常的に使えば使うほど「タイパ （Time Performance）」を実感できる機能です。 自分しか閲覧できないチャットで、自分宛てにメッセージを送信して使用します。 画面左にある「①チャット」をクリックし、固定表示の「②自分の名前（あなた）」をクリック 又は、画面上の検索欄①に自分の名前を入力し「②自分の名前（あなた）」をクリック あとは、通常のチャットと同じようにメッセージを書いて送信すればOKです。 今回はほんの一例をご紹介しますが使い方次第で時短の可能性は広がりますので、是非ご自身で　活用法を探してみて下さい。 リンク先やフォルダの場所一覧 リンク先のURLやフォルダの場所を記載しておくと、探す手間だけでなくチャット毎に整理ができ編集もラクなので便利です。 ※但し、デスクトップのショートカットやブラウザのお気に入りの方が便利な場合もあります 操作/手順の簡易マニュアル化 テストツールの操作やテスト手順は、頻繁に使うものは覚えているものの時々使うものは忘れがちです。そんな手順の一部を抜粋したりポイントを記載（簡易マニュアル化）しておくと、テスト実施時や依頼を受けた際の対応スピードがアップします。また、ExcelやWordの手順書は機能毎にファイルが分かれているケースが多いですが、必要な手順だけチャットに送信しておけばTeamsの検索機能でピンポイントで手順を見つけることもできます。 ※但し、複雑な手順は不向き（ExcelやWordの方が見やすい） メッセージの下書き 誰かにメッセージを送る前に内容を整理したり後で送信したい時など、下書き代わりに使用すると便利です。ファイルとは違い記載するだけで内容が維持されるのも良い点です。 端末間の情報共有 Microsoftアカウントは５つのデバイスまで登録可能なので、自分のアカウントでログインした　テスト用端末／事務用端末 のチャットを使って結果（スクリーンショット）を共有できます。今までは不具合チケット起票用のスクリーンショットをテスト用端末から社内メールを使って事務用端末に送付していたので、工程も時間も短縮されました。 注意事項 業務で使用する場合は、セキュリティ上の問題がないかご確認のうえ行って下さい。 上記で紹介したTeamsの便利機能は、他のコミュニケーションツールにも同等の機能があります。 　　例えば「Slack」でいうと以下になります。 - メッセージの保存機能 ⇒　メッセージのブックマーク機能 - 未読の確認機能 ⇒　［アクティビティ］＞未読メッセージ のトグルをON - 自分専用のチャット機能 ⇒　［ダイレクトメッセージ］＞自分の名前 (自分) チャット おわりに 今回紹介した機能は簡単に情報の見落とし防止や時短による効率アップが図れると思うので、 皆さんに活用してもらえたら嬉しいです。 以上、最後まで読んでいただきありがとうございました。 The post Teamsで業務効率UP！便利機能の紹介 first appeared on Sqripts .

本連載では、ここまで主に「1人目のQAがやるべきこと」について、経験ベースでお伝えしてきました。 今回は少し視点を変えて、1人目のQAがやるべきではないこと、アンチパターンについてご紹介したいと思います。 やるべきことは組織の状況などによって変化することもありますが、アンチパターンは状況によらずある程度共通する部分がある、と考えているためです。 本記事では、代表的なアンチパターンを4つ説明します。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 目の前のタスクに集中しすぎる 一つは、目の前のタスク、「すぐに実施できて達成感が得られそうなタスク」に集中しすぎてしまうことです。 とくに組織にJoinした直後のQAは、できる仕事がたくさんある状態だと思います。 そこで 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqripts でご紹介したように組織の現状把握をしつつタスクの取捨選択を行うわけですが、このときに個々のタスク、とくに達成感・「仕事をした感」が得やすいタスクを選び取りがちです。 たとえばリリース後に見つかる不具合が多い開発チームに入っていき、テスト設計・実行やリリース前の探索的テストに注力したとします。もちろんこれ自体は良いことです。しかし、そこでバグを見つけたり開発チームに感謝されたりしながら、1か月2か月と過ごしていったとして、それは1人目QAとしてのミッションに沿っているのでしょうか？ 会社として、問題のあるチームに入って立て直してほしいという狙いがあれば、動き方としては良さそうです。しかし、広く会社全体の品質保証のやり方を考えてほしい、といった狙いがある場合はどうでしょうか。 目の前のタスクを行って一定の成果が出ることは良いのですが、ついそこにハマってしまう危険もあります。1人目QAとして期待される動きや成果を考慮したうえで、場合によっては広く組織全体にアプローチするようなやり方が必要かもしれません。 得意なやり方、実績あるやり方に頼りすぎる なんらかの課題に対して、自分の得意なやり方や実績あるやり方を当てはめてしまうというのもよく目にするアンチパターンです。 テスト技術に自信がある、テストプロセスの整備の経験が豊富など、QAエンジニアそれぞれにはなんらかの得意なジャンルや手法があるかと思います。 そして、とくに入社直後のQAの場合は目に見える成果が欲しくなるため、つい自分の得意技で攻めようとしてしまいがちです。しかし、たとえばシステムテストの自動化が得意だからといって、なんでもかんでも自動化によって解決できるわけではありません。 必ずしも得意ではなかったとしても、今自分のいる組織にとって何が必要なのかを見定めるところからスタートするのが良いでしょう。結果として、やるべきことに対して自分のスキルが不足している場合には、社外の有識者を頼ることも一つの選択肢ですし、エンジニア部門のマネージャー等と協力しながら「経験はないけれどもチャレンジしてみる」こともできるかもしれません。 周囲のスムーズな理解を期待してしまう 1人目のQAと周囲の開発者やマネージャーとの間には、物事の見方・捉え方や知識の幅などに多くの違いがあります。とくに1人目として入社した直後のQAと、長く勤めているメンバーとではこの違いが顕著になるでしょう。 QAに限らず、そのロールの1人目として働く場合は「自分がどのような役割なのか」を周囲に理解してもらう必要があります。たとえば、1人目QAの方から「QA＝テストしてくれる人、という認識を持たれがち」といった話も伺います。これが誤解である場合、組織におけるQAの位置づけをもっと違ったものとして考えている場合は、適切に伝えていかなければなりません。 ところが、周囲の理解は簡単に得られるものではありません。QAとしての活動をわざわざ邪魔してくる人はいないかもしれませんが、誤解や無知（にQA側からは見える状態）などは必ず発生します。 そのため、開発者やマネージャーはQAのことを知っているはず、一度説明すれば理解してもらえるはず、といった「周囲のスムーズな理解」を期待するのは危険です。 QAの役割や関わり方など、なんらかの情報を組織の中に広めていくということは、思った以上に時間がかかることです。「簡単にはわかってもらえない」「伝わったと思っても伝わっていないことが多い」という前提を持ちつつ、しつこいくらいに伝え続ける動き方が1人目QAには求められます。 独力でなんとかしようとしてしまう QAかどうか、1人目かどうかに関わらず仕事全般に通じるアンチパターンですが、とくに1人目QAの方はハマりがちな傾向にあるように思います。 組織1人目のロールの場合、相談できる相手が居ないか、限られることが多いです。 かつ、1人目QA自身も「プロとして呼ばれてきたわけだから、相談しづらいな・・・」と感じてしまうのかもしれません。 いろいろな組織課題を独力で解決しようと考えても、多くの場合解決できないか、時間がかかりすぎてしまいます。それでは組織にとってもメリットがありません。 私自身1人目QAとして働いて感じたことは、品質への興味を持った方は少なくない、という点です。開発者の中にもテストをうまく・効率的に行いたいと考えている方はいますし、マネージャーの中にも品質向上のために試行錯誤した経験のある方が必ずいます。 そうした方々の取り組みや課題を拾い上げて一緒に解決していくことも、1人目のQAとしての価値です。「自分がなんとかする」という責任感もすばらしいですが、いったん脇に置いて「積極的に周りを巻き込んで一緒になんとかする」という考え方に変えてみるのもよいでしょう。 また、社内に相談相手がいない場合は社外を頼るという方法もあります。 昨今は（私も含めて）カジュアル面談プラットフォームなどを用いて「他社QAと情報交換しましょう！」という場を設けている方もたくさんいます。もちろん社内の情報の扱いには注意が必要ですが、純粋な技術課題・組織運営課題として抽象化したうえで社外の方と話をしてみる、経験談を聞いてみるのも有効です。 1対1の会話でなくとも、社外の勉強会やイベント等に参加して他社事例を聞くことも有効です。勉強会などで「今の自分が抱えている問題にピッタリはまるヒントは得られなかった」という方もいますが、私はそのような都合のよい機会はほぼないと考えています。 そうではなく、普段から勉強会やイベント等に参加をして情報を集めておき、いざ自分がなんらかの課題に直面したときに過去見聞きした情報からヒントを得るものです。 書籍や、Web上に公開されている資料なども含めた意味での「他人の知恵を借りる」ことは常に意識しておきたいですね。 1人だからとタスクや情報を抱え込まないのがポイント 今回は代表的な4つのアンチパターンをご紹介しました。 共通する点としては、1人だからといってタスクや情報を抱え込まないようにすべき、という点です。 1人目のQAは周囲から謎の存在になったり、あるいは「テストしてくれる人」のような固定イメージで見られたりすることがあります。そうならないためにも、自分がどのような役割を担いたいのかや何ができるのか、いま何をしているのかなどを常に発信していきましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 The post 【第5回】1人目QAアンチパターン first appeared on Sqripts .

金融、公共交通、電力、通信等の社会インフラを支える業界では、その業務に使用されるコンピュータシステムの信頼性を担保するために様々な法規制があります。   人の生命に直接関係するお薬や医療機器を製造する製薬・医療機器業界もその一つです。   本記事では初めて製薬・医療機器業界のコンピュータシステム導入・運用に携わる方々向けに、同業界に適用される法規制の一つである CSV（Computerized System Validation）の基本的な事柄をご紹介します。 製薬業界のコンピュータシステムの特徴 製薬業界でもコンピュータの利用が急速に普及し、従来は人手と紙記録で行われていた多くの作業がコンピュータ化されています。   一方、コンピュータの欠陥による重大事故も発生しており、コンピュータシステムの信頼性と安全性への要求がますます高まっています。   医薬品は生命に直接関係するため、基本的に「不良品ゼロ」が要求されます。このため、医薬品製造者が業務に使用するコンピュータシステムについては「バリデーション」の実施により、管理するデータと出力結果の信頼性確保が要求されています。 「バリデーション」と「CSV」 お薬を作る工場では製造工程、作業手順、製造管理、品質管理等の方法が、製品品質に対して「期待される結果」を与えることを検証し、文書化することが求められています。これは「GMP省令（医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令）」という法令に基づくもので、この検証と文書化のプロセスを「バリデーション」と呼びます。   同様の考え方をコンピュータ化システムについても適用し、各種業務に使用するコンピュータ化システムをバリデーションすることを「コンピュータ化システムバリデーション（CSV）」と呼びます。   ここで「コンピュータ化システム」という言葉は、「コンピュータシステムで統合された工程又は作業、及びコンピュータシステムにより実現される機能を利用する業務プロセス」を指す広い概念です。 CSV と規制対象 CSV はお薬の製品開発、臨床試験、製造、品質保証、流通、販売後安全管理に亘る、製品ライフサイクル全般で使用されるコンピュータ化システムを対象としています。   前章で「GMP省令」という法令を紹介しましたが、製品ライフサイクルの各段階に対応して下記に示す基準が定められており、「GxP」と総称されています。 GLP（Good Laboratory Practice）：医薬品の安全性試験の実施に関する基準   GCP（Good Clinical Practice）：医薬品の臨床試験に関する基準   GMP（Good Manufacturing Practice）：医薬品の製造管理及び品質管理に関する基準   GQP（Good Quality Practice）：医薬品の製造販売品質保証に関する基準   GDP（Good Distribution Practice）：医薬品の適正流通に関する基準   GVP（Good Vigilance Practice）：医薬品の製造販売後安全管理に関する基準   また、これらの基準による規制は日本国内に留まらず、海外でも各国で同等の法令が制定されており、お薬の輸出入を行う場合はそれに従うことが求められています。 CSV の概要と特徴 CSV の基本的な考え方は一般的なコンピュータシステムの検証と同じですが、開発・検証プロセスとその文書化についてガイドラインが制定されている点が特徴です。 CSV の全体像 （図1）に CSV が前提とする開発・検証プロセス全体像と主要作成文書を示します。   ウォーターフォールの V字モデルに沿った開発・検証を行う点では一般的なシステム導入と同じです。   一方で可監査性を目的とした開発・検証文書の整備が重要視されており、システムアセスメントや供給者監査等、第三者的な視点での評価がプロセスに組み込まれています。   （図1）開発・検証プロセスと主要作成文書 開発業務に於ける主要作成文書 （表1）に開発業務に於ける主要作成文書を示します。   要件定義の前提として「システムアセスメント」の実施が規定されています。システムアセスメントの結果はバリデーション計画にも反映されます。 （表1）開発業務の主な作成文書 検証業務に於ける主要作成文書 （表2）に検証業務に於ける主要作成文書を示します。   「供給者監査」の実施が規定されており、システム開発ベンダーが CSV に関する充分な知識と経験を保有し、定められた品質管理システムを実践していることを、発注側が監査します。 （表2）検証業務の主な作成文書 プロジェクト管理上の考慮点（ケーススタディ） CSV 対象プロジェクトでは、開発・検証段階での文書作成・管理に要するリードタイムと工数が、プロジェクトの計画・管理に大きな影響を及ぼします。   本章では 文書作成・管理視点から見た課題と対応事例を、筆者の経験からケーススタディ的にご紹介します。   CSV 対象システム構築プロジェクトで筆者が特に重要と考える ①：文書作成・管理目的の理解、②：文書体系整備、③：文書管理、④：変更管理の事例です。   尚、これらの事例は筆者が製薬企業側の PM として参画した、複数の導入プロジェクトに基づくものです。 ①：文書作成・管理目的の理解 筆者が最初の CSV 対象プロジェクトを経験するまでは、開発・検証文書は、開発者⇔システムユーザ間の仕様合意・品質記録と、本番運用開始後の保守を目的として作成・管理するという理解でした。   CSV 対象システムでは上記に加え、お薬の製品品質に関する適切なリスク管理が行われていることを、ユーザ企業の品質保証部門や外部査察・監査に対して説明できる文書であることが要求されます。   このため、説明責任視点でも納得性のある文書体系・文書管理プロセスの整備・運用に多くの時間を割いてきました。   一例として、システム構築プロジェクトと並行して CSV 文書体系・文書管理プロセス整備をゼロから行った、Aプロジェクトの事例をご紹介します。   CSV 文書は、製薬企業の品質保証部門が承認した基準書や手順書に従って作成・管理される必要があります。   国内では 2012 年度から CSV 規制が適用になったこともあり、その企業では CSV に関する基準書や手順書が無い状態でしたので、先ずはこれを整備する必要がありました。   しかし、Aプロジェクトの計画時点ではこれらのタスクは想定していなかったため、途中で品質保証部門を始めとする関係各部門を巻き込んで、サブプロジェクトとして対応しました。   社内にはノウハウが無かったので、早期から CSV を実施している外資系製薬企業に見学に行ったり、CSV 経験・ノウハウを持つ開発ベンダーからコンサルティングを受けたりして、何とか形だけは整備して本番運用を開始しましたが、今振り返ると突っ込みどころ満載の突貫工事だったと思います。   ②：文書体系整備   （図1）に示した各文書は内容の整合性が担保されていることが CSV の大前提となります。 Bプロジェクトの設計仕様書（DS）レビューで、に品質保証部門のレビュアーから「要求仕様書（URS）の要求項目が漏れなく DS に反映されていることは確認できていますか？」という指摘がありました。   Bプロジェクトでは、それまでの文書レビューは個別文書毎の内容レビューが中心でした。異なる開発工程の文書間で整合性を網羅的に確認する、という発想自体が無かったので早速対応に追われました。   対策として、要求仕様（URS） ⇔ 機能仕様（FS） ⇔ 設計書（DS）間相互の記述内容に過不足や不整合が無いことを確認する「トレーサビリティマトリクス」を作成しました。  幸い URS ⇔ FS ⇔ DS の各文書と項目には体系的な ID が採番されていたので、ID を紐付けることで文書間のトレーサビリティを可視化することができました。   もしこれらの文書が整合性確認を意識せずに作成されていたとしたら、最悪の場合は URS や FS の体裁修正まで手戻りが発生することも考えると、初期段階での文書体系整備の重要性を認識した一コマでした。   これ以降、開発文書の成果物にトレーサビリティマトリクスを入れたプロジェクト計画を作るように留意しました。 ③：文書管理  CSV 関連文書は文書間の整合性維持や、規定通りの承認経路によるタイムリーな承認が必要となります。    加えて本番運用開始後も査察対応等のために、監査証跡の記録や目的文書への迅速なアクセスが必要となります。   このため、文書管理に要する工数とリードタイムが、プロジェクトリソースとスケジュールに大きな影響を与える場合があります。   Cプロジェクトでは設計・開発工程のスケジュールが遅延して、受入テスト・CSV のスケジュールが圧迫されている状態でした。   対策の一つとして、検証文書の承認リードタイムを短縮することで CSV 全体のリードタイムを短縮する取組を進めました。   具体的には、GxP 文書の管理目的で運用していた文書管理システムと承認プロセスをそのまま流用して、Cプロジェクトの CSV 文書管理を行うことにしました。   文書管理システムを活用し、承認者が出張等で不在の際にも社外での承認を可能にしたり、承認プロセスを可視化して遅滞している承認を督促したりすることにより、スケジュールを遵守することができました。   又、副次的な効果として、文書の変更管理や発行管理にも同システムを活用して、外部監査や査察対応の際にもアカウンタビリティの高い管理ができるようになったと思います。    一方、紙と印鑑で承認していた時のようなバックデート対応等は難しくなるため、例外的な処理を含めた業務ルール設計とそれを遵守する教育や文化の醸成にも配慮しました。    これ以外にも 品質保証部門が承認した手順書に従って各文書が作成されていること   必要な職責のレビューと承認が全て完了していること   ウォーターフォール開発の場合は各文書承認日付の前後関係に矛盾がないこと   等々、一般のプロジェクトでは後回しになりがちなことが、CSV 対象プロジェクトでは大きな問題になることがあるので、計画段階で管理タスクを可視化して確実に実施することが必要です。 ④：変更管理  Dプロジェクトはその企業で初めての MES（工場の製造実行システム）導入であったため、機能設計書（FS）の確定が遅れていました。加えて開発・単体テスト段階になっても仕様変更や追加が多発したため、変更管理手続きの煩雑さと手間が課題になっていました。    当初、Dプロジェクトでは品質保証部門が制定・運用する、GxP の変更管理プロセスを準用していました。    このプロセスはお薬の製造工程変更や標準作業手順変更のような、製品品質に直接影響する変更を主として想定しており、変更理由と必要性評価、影響内容と範囲、品質リスク評価、変更許可理由 等を全て規定の様式で文書化して残すことが求められるものでした。    しかしシステム開発の場面では、明らかに製品品質には影響しない仕様変更や機能追加も多く、煩雑な変更管理プロセスが形骸化したり、遵守されない状況が発生していました。加えて、変更管理文書の査閲・承認がボトルネックとなり、開発工程のスケジュールにも影響が出ていました。    対策として、変更申請時に製品品質への影響リスクを Dプロジェクト内で事前評価する手順を設けました。  低リスクのものについては一般的なシステム開発の変更管理プロセスを適用し、中・高リスクの案件についてのみ、GxP の変更管理プロセスを適用するようにしたのです。    又、GxP の変更管理プロセスの中でも、リスクが低い変更案件は手続きや承認レベルを簡素化するルールを適用することで、手続きの簡素化・迅速化とリスク低減を両立しました。 まとめ  製薬業界でコンピュータ化システムを導入する場合に必要となる CSV について、概要をご紹介しました。    CSV は法令による規制ですので正しく実施して、査察や監査にも耐えられるシステム構築や運用が必須です。    このためにはプロジェクト計画段階で、一般的なシステム構築プロジェクトに比べて追加で必要となる文書作成・管理のリードタイムと工数を織り込んでおくことがポイントです。    プロジェクト体制面では品質保証部門（QＡ部門）の参画が必須なので、早い段階から巻き込んで良い関係を築き、二人三脚で進めることが成功要因の一つです。    開発ベンダーについては、CSV 経験の無いベンダーでは要求される各種事項への適切な対応が難しいと思います。逆に経験豊富な開発ベンダーからは、効率的な CSV 実施のアドバイスや他社事例等の有益な情報提供が期待できるため、ベンダー選定はプロジェクトの成否を分ける大きなポイントとなります。    最後までお読み頂き、ありがとうございました。    本記事が製薬・医療機器業界の GxP システム構築に携わる皆様のお役に立てますと嬉しく思います。 Appendix 参考となるサイト など 厚生労働省／コンピュータ化システム適正管理ガイドライン 国内での CSV 実施要領の基準となるガイドライン文書です。 GMP Platform CSV に留まらず、医薬品の製造や品質管理を総合的にカバーする情報発信サイトです。   （株）イーコンプライアンス 医薬品、医療機器業界を中心に、当局規制内容の解説や対応方法の情報が充実しています。 用語説明 GMP 省令： 医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令   URS（User Requirement Specification）： 指定されたコンピュータ化システムに関する機能上の要求仕様が記載された文書   FS（Functional Specification）： 要求仕様書に記載された要求仕様に対応する、より具体的な機能が記載された文書   DS（Design Specification）： 機能仕様に記載された具体的な機能を実現するコンピュータ化システムを作成するための詳細仕様が記載された文書。   DQ（Design Qualification）： 設計時適格性評価。要求仕様書に記載された要求事項が、機能仕様書、設計仕様書等に正しく反映されていることを確認し文書化すること。   IQ（Installation Qualification）： 据付時適格性評価。コンピュータ化システムが、設計仕様等に記載されたとおりに据え付けられ、プログラムがインストールされたことを確認し、文書化すること。   OQ（Operational Qualification）： 運転時適格性評価。コンピュータ化システムが、運転時において、機能仕様等に示された機能及び性能を発揮することを確認し文書化すること。 PQ（Performance Qualification）： 性能適格性評価。コンピュータ化システムが稼働時において、要求仕様等に記載されたとおりに機能し、性能を発揮して運転できることを確認し、文書化すること。 The post 製薬・医療機器業界のCSV入門｜Computerized System Validation first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第7回となる今回のテーマは前回に続き「スケジュールマネジメント」です。 後編となる今回は、スケジュールの作成と作成したスケジュールをどのように使ってマネジメントしていくかにフォーカスします。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 前回のおさらい 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ １）スケジュールマネジメントとは ２）スケジュール作成に必要な準備・検討 　　・アクティビティを定義する：WBSで要素分解する 　　・作業の依存関係を確認して順序を決める：アクティビティの順序設定をする 　　・アクティビティ所要期間（工数と時間）を見積もる スケジュールの作成 1) クリティカルパスを使ってスケジュールを考える スケジュールを作成する技法は幾つもありますが、クリティカルパスメソッドを押さえておきましょう。 クリティカルパスメソッド（ CPM：Critical Path Method ）は、プロジェクトを完了させるために実行しなければならないタスクを特定する技法です。クリティカルパスとは、プロジェクトの全工程を最短時間で完了するための作業経路で、重要な作業を特定することでスケジュールとその柔軟性も判断することができます。プロジェクトは細かなタスクの集合体であり、その一連のタスクを連ねた時に「最も時間のかかる経路」をクリティカルパスと言います。 クリティカルパス＝最長の重要タスクですから、ここに遅れがでると後続に影響がでてプロセス全体も遅延する為、スケジュールの作成においてクリティカルパスを特定しておくことはとても重要です。 プロジェクトマネジメントの資格試験などではクリティカルパスの求め方などが出題されますが、今はプロジェクト管理ツールなどで比較的簡単に求めることができるでしょう。みなさんにはスケジュール作成への活かし方やその必要性について感じていただければまずはOKです。 Wiki： クリティカルパス法 2) スケジュール作成のアウトプット 計画したスケジュールは整理記載して、その後のマネジメントとプロジェクト活動に使用しましょう。スケジュールを表現する形式は様々ありますが、以下のようなアウトプットは最低限作成しましょう。 ・ガントチャート　　　　　：アクティビティの開始日、終了日を横軸で記した工程表 ・マイルストーン　　　　　：主要な成果物に関わる予定や終了日、外部との重要なインターフェイスなどを記載管理する ・プロジェクトカレンダー　：稼働日、非稼働日、納品日、シフト、特別なイベントなどを記載したプロジェクト専用カレンダー 3) ガントチャート ガントチャート（ GANTT ）はみなさんに馴染みあるツールではないでしょうか（PMBOKではバーチャートと呼びます）。プロジェクト活動の中でその進捗を管理するためにガントチャートは高い頻度で活用されます。 スケジュールを作成するためにアクティビティを整理する時にWBSを作成しましたが、このWBSはガントチャートに進化させることができます。WBSを横90度に回転させてみましょう。 するとWBSの各階層がガントチャートの「成果物、要素成果物、活動タスク（アクティビティ）」になりますね。必要な情報、特にタスクの開始日と終了日を設定して時間の概念と担当者を加えれば、最もシンプルなガントチャートができあがります。 4) スケジュール作成時にできる「転ばぬ先の杖」 スケジュールが作成できた時点で「思ったような期間にスケジュールが収まらない」、「要求されているリリース日ぎりぎりになりそうで不安が残る」という現実を見て重い気持ちになるはずです。不安を抱えた計画を実行しても良いことはありません、この時点でできることはなんでしょうか？ ①減らせる作業はないだろうか？ 例えばAという機能は実装しなくても、すでに存在するBという運用を使えばすむのでないか？というように、改めて計画を見直してみましょう。また役割分担を変更することで、例えば「CさんはAという機能実装するために事前に仕様書の読み込み時間が必要。一方、Dさんはすでにその仕様書を読んでいると聞いている。作業を交代すればその分の時間が削減できそうだ」ということもあるでしょう。当たり前を見直して、少しでも作業を減らせるポイントを見つけましょう。 ②人を増やせないだろうか？ 追加人員を投入して期間を圧縮する方法を「クラッシング」といいます。追加分のコストとトレードオフ（コスト増加）になるのですが「お金がかかってもスケジュールが短縮されれば」と考えて実施されるケースも少なくありません。基本的には人を増やせば所要時間の短縮につながりますが、事前の引き継ぎや作業にあたる為の知識を得る必要がある場合、すぐに期待するパフォーマンスや短縮効果が得られないことも理解しておきましょう。 ③手がつけられるところからはじめる？ 前後関係（FS）の作業を並行して実施することで期間を圧縮する方法を「ファストトラッキング」といいます。例えばAチームの作業と後続開始のBチームの作業には数日の待機期間があるが、待機せず同じ時期に作業を行えば待機期間が削減できます。ただし、無理な前倒しには注意してください。例えば「要件定義前に開発を始めて、要件が変わったので開発が無駄になった」というように手戻りリスクがあるからです。 ④メンバ変更はできるだろうか？ 「チームにはAさんがアサインされているが、Bさんの方が経験豊富で同じタスクを数倍早く完了できると考えられる。交渉してAさんとBさんを交代してもらうことはできないだろうか？」というように、スキルと生産性が高い要員を引き入れたり交代したりすることも一つの方法です。日頃からメンバのスキルセットへ関心を持っておくことも重要です。 ⑤プロジェクトスコープの削減はできないだろうか？ どうしても要求スケジュール内に収まらない時の手段として、スコープ自体を調整することも選択肢に入れましょう。その際は必ず承認が必要です。 スケジュールをコントロールする スケジュールは作成してからがスタートであり本番です。プロジェクトは絶えず変化するので、常に見守りながら変化に即してスケジュール見直したり修正していくものです。計画時点からの変化、要求変更やシステム問題、体調不良での要員離脱など、必ずスケジュールを修正しなければならない問題は起こります。「なんでスケジュール通りに行かないんだ！」ではなくスケジュール通りに行かないもの、さあどうしようか、と思える心構えと備えをしておきましょう。 1) スケジュールをコントロールするために とはいっても、できれば計画通りにコトが運んで欲しい…と思うのも当然です。 まずは常にプロジェクトスケジュールと「現在の状態」の確認を行うこと スケジュールに変更を来しそうな要因へ事前に働きかけ、その芽を摘むこと スケジュール変更が必要か常に確認する 変更発生時（変更発生が必要と思われた時）にはその影響をを測定して、速やかに変更を適用すること 2) PMは常に自分の「予備（バッファ）」を持っておく 前述の通り、どれだけ準備計画しても、必ずスケジュールを変更しなくてはならないことは起こります。起こるとわかっていることですから、備えを計画しておくこともできますね。 計画通りにいかないというのはスケジュールが伸びる（増加する）ことです。この増加に対して「予備として備えておいた期間を充て」ることで余裕を持たせることができます。ではどれぐらいの予備を想定しておけばいいかというと、これは概ね10％程度が適当だと言われています。もちろんみなさんの経験から10％を前後する場合もあると思いますが、大規模プロジェクトや難易度の高いプロジェクトでは10％より多めに設定するとよいでしょう。 3) 打ち手は「クリティカルバス上」でなければならない クリティカルパス＝最長の重要タスクであり、ここに遅れがでると後続に影響がでてプロセス全体も遅延しますね？スケジュールにおける準備や打ち手は常にクリティカルパス上に意識を向けて、クリティカルパス上に施さなければなりません。例えば、リーダーや責任者は「クリティカルパス上の作業を担当しない」のが原則です。なぜならリーダーはチームメンバのマネジメントや監督も必要であり、十分にクリティカルパス上の「タスク」にリソースを投入できないリスクが考えられます。またパス上に「優秀なエンジニアや担当者を配置する（※経験不足の人員をアサインしない）」といった工夫（打ち手）もあるでしょう。当たり前ですが他の経路（クリティカルパス以外）に人員やコストを投入しても、意味がないとは言えませんがスケジュール短縮はできませんね。 また注意として「クリティカルパスに打ち手を施し期間短縮すると、新しいクリティカルが生まれる（生まれる可能性）」ことになります。「今の」クリティカルパスがどこにあるのか、常に追いかけてコントロールするようにしましょう！ 予備（バッファ）の注意ポイント ①「個別のアクティビティに対してバッファを持たない」ということです。なぜならアクティビティの正確な対応期間がわからなくなり管理不能に陥るからです。あくまでプロジェクト全体又は設計・開発・テストなど工程の最後に対して予備期間を設けて、必要に応じて適応いくようにしてください。 ②学生症候群やパーキンソンの法則という言葉を聞いたことはありますか？簡単に言えば、人は「時間」や「資源」の余裕がある（余裕があるとわかる）とその余裕を残さず使ってしまう、というものです。（①）にあるように、タスクにバッファを置くと計画上は目に見えて（バレて）しまい、メンバに使われてしまう可能性が高くなります。そうすると折角捻出した予備も水の泡です。ですのでメンバに見えないようにPMだけがバッファを持つこと（バレないように後まで隠しておくこと）がコツです。 さいごに 2回に分けてスケジュールを作成する為の準備となるWBSでの要素分解、アクティビティの順序や見積もり方法、スケジュール作成、そのマネジメント方法を学びました。納得できるようなケジュールを作成することがプロジェクトの成功に直結します。 次回のテーマは「コストマネジメント」です、予算オーバーを防ぐ計画策定と管理方法を整理していきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ The post 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているタカです。 普段はプロジェクトのマネジメントや開発者としてプロダクトの開発に関わっています。 以前投稿した Notionでプロダクトバックログを管理するビューを作成する の記事の最後に触れた NotionのGitHubインテグレーション機能 と、その機能を活用した自分たちのチームのブランチとプルリクエストの運用フローを紹介します。 Notionでプロダクトバックログを管理するビューを作成する NotionのGitHubインテグレーション機能とは Integrate GitHub – Notion Help Center NotionのGitHubインテグレーションは、NotionとGitHubを接続し、GitHubのプルリクエスト (PR)とNotionのページに紐づける機能です。 機能としてはシンプルで、連携したGitHubのリポジトリにあるプルリクエストを自動または手動でNotionのページのプロパティとして表示するものになります。 ただ単に表示するだけではなく、プルリクエストのステータス（Open、Merged）が自動で反映されるので、Notionからプルリクエストの状態を即座に確認できるというメリットもあります。 なお、GitHubとNotionの連携設定は 公式のヘルプ を参照してください。両サービスの権限があれば設定は簡単に行えます。 プルリクエストの紐付け方法 紐付け（リンク）方法は下記のステップで行えます。 1. NotionのページにIDプロパティを追加する 2. 外部接続 GitHubプルリクエストプロパティを追加する。 1. ステータスプロパティがある場合、そちらとプルリクエストステータスの連携設定も可能 3. プルリクエストを紐づける 1. 手動の場合、プルリクエストのURLをプロパティに貼り付ける 2. 自動の場合、プルリクエストのタイトルにID名称（キャプチャの場合SBI-976）を追加する。 ステップ1 ステップ1 ステップ1 ステップ2 ステップ2 ステップ2 ステップ3 手動 ステップ3 手動 ステップ3 手動 チームで導入した運用ルール この機能をベースに直近の開発ではブランチとプルリクエストの運用方法を見直しました。 ブランチ 自分たちのチームのブランチ運用は git-flow を採用しています。 このフローにおいて機能改修を行うブランチ feature/ ︎ ︎の名称を feature/PBI-⚪︎⚪︎ としました。 意図としては、プロダクトバックログ（PBI）ごとになるべく1つのブランチで作業することにして、どのような改修作業を行うかを明確にしたいためとなります。 なお、hotfixによる急ぎの対応では、このルールの限りではありません。 プルリクエスト こちらのルールでは、ブランチ名称を踏まえ、 developのブランチに出すプルリクエストのタイトルには、必ず PBI のIDプロパティを含める というルールにしました。 PBIをタイトルに含めることで、連携機能により、自動でNotion側のPBIにプルリクエストが反映されます。これにより、コードの修正が必要なPBIを受け入れ完了にする際に、自動反映されたプルリクエストがMergedの状態であるかを確認することも出来るようになりました。 なお、ブランチのルールには沿わないですが、細かい修正を行う際に、複数のPBIを1つのプルリクエストに紐付ける場合は、そのタイトルに全ての関連PBIのIDを含めることで、それぞれに自動的に紐付けが行われます。 導入してみて感じたメリット 本ルールを導入して分かったメリットは作業をした内容が可視化されることでした。 開発担当者にしてみれば、自分の作業内容を プロダクトオーナーやQA担当者をはじめ、チーム内に共有できますし、要件に対してどのような修正を行ったかも一目でわかるようになりました。 また、レビュアーから見ても、GitHubのプルリクエストをすぐ見れる導線が増え、ブランチやプルリクエストにPBIのIDをつけることで、1ブランチで複数のPBIの作業をすることが少なくなり、1回のレビューの量が減るメリットにもなりました。 おわりに 今回の内容は以上となります。 運用負荷がほぼゼロとうこともあり、今回設けたルールは自然とチームに受け入れられました。 GitHubとNotionの連携機能を使うことで無理なくバックログとプルリクエストを紐付けて可視化ができるので、プルリクエスト名を統一したい、バックログからプルリクエストを辿りたいなどで困っているチームのは、ぜひ一度試してみてください。 関連記事 Notionでプロダクトバックログを管理するビューを作成する The post GitHubプルリクエストをNotionで管理：効率的なブランチとプルリクエスト運用のガイド first appeared on Sqripts .

こんにちは。Q4Aと申します。 私はテストエンジニアとして、長らくお客様常駐で業務した後、ここ数年は現場を離れて部門管理を担当しています。現場時代でも担当案件の状況説明やリリース判定時に、品質の良し悪しについて説明したり考えたりするシチュエーションは多々ありましたが、今も商談の場でお客様と話をしていると、やはり品質の良し悪しについては凄く気にされています。 言葉としてはポピュラーですが、ひとくちに品質と言ってもいろいろな視点があります。今回はそんな話をしたいと思います。 品質が良いってどういうこと？ 「皆さん品質が良いってどういうことだとお考えですか？」 私は部門内の新人研修でよくこの質問をするのですが、一般的なECサイトを例に考えてみましょう。 面白いことに回答は多岐にわたります。 「機能が充実している」 「レスポンスが早い」 「使い勝手がよい」 いろいろな意見が挙がりますが、 はい、全部正解です。 所謂ひとつのワインバーグ的な有名な決め言葉ですが、 「品質とは誰かにとっての価値である」 ワインバーグ と言われるように、品質にはいろいろな視点があるのです。 そのため我々テストエンジニアは、様々な視点でお客様やユーザーの求める品質を考えてテストする必要があります。機能テストや性能テスト、セキュリティ診断等、お客様から直接指定のご依頼がある場合はよいですが、大規模プロジェクトや社会性の高い製品の場合は、あらゆる視点の品質を考慮しなくてはいけません。規模の小さい製品でも、機能テスト要求の中にユーザーの操作性や他ソフトとの共存動作など見えないニーズも隠れていたりします。 ただ、このように様々な視点を一から全部考えるのは大変ですよね。そんなあなたのために先人の知恵があります。それらは品質モデルというもので体系的にまとめられているのです。 ISO/IEC 25000 シリーズ（SQuaREシリーズ） 品質モデルとは、ソフトウェアの品質を確保するのに必要な特性をモデルとして定義したものです。国際規格であるISO/IEC 9126が長らく重用されてきましたので、9126の数字を聞いたことがある人は多いと思います。その後、ソフトウェア技術の進化や利用形態の多様化など様々な要因を経て再編され、現在はISO/IEC 25000 シリーズとして整備されています。 ISO/IEC 25000 シリーズは、システムおよびソフトウェア製品の品質要求と評価に関して規定している国際規格「Systems and Software Engineering – Systems and Software Quality Requirements and Evaluation」の頭文字を取って、SQuaREシリーズとも呼ばれています。SQuaREシリーズでは「製品品質モデル」「利用時の品質モデル」「データ品質モデル」と3つのモデルを定義しています。私たちに馴染み深い製品品質モデルで説明すると（図1参照）、8つの品質特性と31の品質副特性で構成されています。 図1）出典： IPA「つながる世界のソフトウェア品質ガイド」 これらの特性が、冒頭で述べたいろいろな視点で品質を考える時の着眼であり観点となるのです。 例えば「機能適合性」の副特性「機能正確性」では、機能が期待どおりの処理をしているかやデータ出力しているかが確認の観点になります。そのため機能テストを実施して動作を確認します。 「性能効率性」の副特性「資源効率性」では、システムが利用する資源の量が要求を満たしているかが確認の観点になります。そのため性能テストを実施してメモリ使用量やCPU使用率などを確認します。 このようにSQuaREシリーズを利用すれば、品質を考えるときの視点が品質特性や品質副特性として網羅されているので、様々な視点/切り口で漏れなく品質やテストを考えていくことが出来ます。この点が品質モデルを利用する一番のメリットだと私は考えています。 もう1つのメリットとしては、SQuaREシリーズは国際規格なのでステークホルダーと共通の認識のもと話をすることができる点にあります。文化や立場の違い、異なる基準で品質を評価しようとすると混乱が生じるので、合意形成するにも便利だと思います。 いともたやすく使える？品質モデル・品質特性の利用方法 ここからは私の経験事例も交えて、品質モデル・品質特性の利用方法をご紹介します。 品質モデル・品質特性は、対象システムやサービスに対して、各品質特性・品質副特性ごとに品質目標や評価基準を定めて、要求を満たしているかリリース前までに評価するといった使われ方が最もポピュラーかと思います。特に非機能要件はおざなりにされがちなので、きちんと定めておくことが重要です。 品質特性ごとにテスト観点を定義 私が以前参画していたあるプロジェクトでは、そこからさらに一歩踏み込んで、各品質特性・品質副特性ごとにテスト観点を定義して共有していました。かなり大規模なプロジェクトで、多人数でテストしていたのですが、担当者や担当チームによるテスト品質のバラつきが課題になっていました。品質特性ごとにテスト観点を定義することで、一定水準で網羅的なテスト品質を確保することが出来ました。 ただ注意点としては、共有したテスト観点はあくまで基準であり、きっかけであり、製品や機能によってはそこからさらにテスト観点を追加する必要があることです。「定義した観点だけテストしていればいい訳ではない」と考え続けることが重要だと思います。 探索的テストのチャーター検討に利用 もう1つ身近な事例を挙げますと、探索的テストのテストチャーターを考える際に、品質特性をベースに考えたことがありました。 例えば「性能効率性」の副特性「容量満足性」の観点で、各機能のデータ保存時における出力先容量不足時のエラー挙動を確認したり・・・ 「使用性」の副特性「ユーザーエラー防止性」の観点で、各入力フォームに誤った入力のまま登録エラーになった際に、入力済の正しいデータを保持しているか各登録画面で確認したり・・・ このように品質特性は、ちょっとしたテスト観点の検討のきっかけとしても利用することが出来ます。 そうはいっても、JSTQBの試験などで言葉は知ってるけど、品質モデルや品質特性の中身を詳しくはよく知らない。文献見ても小難しいことが書いてあるし、という方も多くいらっしゃるのではないでしょうか。 そんなあなたに「つながる世界のソフトウェア品質ガイド」ー！ SQuaREシリーズについては、 IPA （独立行政法人　情報処理推進機構）が発行している 「つながる世界のソフトウェア品質ガイド」 を参照することをお勧めします。 1つ1つの品質特性、品質副特性に対し、比較的分かりやすく説明してあります。例えば「使用性」の副特性「適切度認識性」と言われてもよく分かりませんが「製品又はシステムが利用者のニーズに適切であるかどうかを利用者が認識できる度合い。」と説明があると理解できます（図2参照）。 図2）出典： IPA「つながる世界のソフトウェア品質ガイド」 ただしこの要求を満たしているか確認するためにどのようにテストするかはまた別問題で難しいです。同ガイドには、各品質副特性の品質測定量も記載されていますので、興味のある方は参考にしてください。 最後に同ガイドの特徴をお伝えしておくと、PDF216ページで読み応え十分というところです。もう京極夏彦先生の小説くらい長いです。ですので私は必要な時に必要な箇所だけ確認する使い方をしています。 また、冒頭の「第1章　あらためて品質を考える背景」などは、読み物としても非常に面白いです。発行は2015年と古いものの、IoT時代におけるテストの重要性を改めて再確認させられ、テストエンジニアとしてのモチベーションを高めるのにも最適です。 まとめ さて、ここまで品質モデル・品質特性について経験事例も交えてお話してきました。品質にはいろいろな視点が求められるため、ソフトウェアの品質モデル・品質特性を下敷きに考えるとよいと思います。 いろいろな視点の品質を網羅的に確認することができる 国際規格なのでステークホルダーと共通の認識のもと話をすることができる 学ぶにも使うにもよい体系的にまとめられたガイドもあるので、ぜひ使ってみてはいかがでしょうか。 最後までお読みいただきありがとうございました。 ＞「ありがとう」それしか言う言葉がみつからない・・・ The post いともたやすく使える品質特性ッ！ first appeared on Sqripts .

みなさんこんにちは、マッシュです。 今回、eKYCのテストを行う際に使用可能なテストデータの作成方法について紹介していきたいと思います。 はじめに eKYCとは electronic Know Your Customer の略で、免許証やマイナンバーカード、本人のセルフィー撮影など、本人確認が必要な手続きを オンライン上 で行う仕組みのことです。 ※オフラインで行う本人確認はKYC(Know Your Customer) ※ eKYCとは（Wikipedia） eKYCは口座開設やクレジットカードの発行等で使用されているため、みなさんの中にも実際に使ったことのある方は多いのではないでしょうか。では、eKYCを利用した時のロケーションは同じだったでしょうか。部屋の明るさ、照明との距離等、様々な違いがあったはずです。 エンドユーザがシステムを利用するロケーションが異なるなら、その点も考慮したテストデータを使用してテストを行うべきです。そこで、私がこれまでに行ったeKYCのテストで使用したテストデータの一部を紹介していきたいと思います。 テストデータの事例 それではさっそく、eKYCのテストで活用できるテストデータの紹介をしていきます。 光量、光源のテストデータ 光量を調整可能な光源を使用して、本人確認書類の明るさを調整し、上限と下限の光の許容値を超えた場合の動作を確認します。券面に直接光を当てないように注意し、本人確認書類の周囲の明るさを調整できるように環境を構築します。 強い光や弱い光を照射し、本人確認書類の表示物の読み取りやすさを変化させます。これにより、「読み取れない」または「読み取り時にエラーが発生する」といった結果を得ることができます。 また、光量を数値化して調整可能な光源を用意するか、光量を計測する照度計を用いることで、テスト条件を定量的に示すことが可能となります。 上記と同様の方法で、色温度の異なる光源(電球色、白色、昼光色など)を使用することで、本人確認書類を読み取れない色温度がないかを探ることができます。 背景のテストデータ 本人確認書類を読み取る際の背景を変化させます。本人確認書類の券面と同色または類似色、デザインイラスト系、布、木目、光を吸収することを想定した黒一色の背景など、ユーザがeKYCを利用する際のロケーションをイメージしながら様々な背景を準備します。 用意した背景の上に本人確認書類を配置し、本人確認書類と背景の境目を不明瞭にすることで、「読み取れない」、「読み取りづらい」といった結果が出ないかを探ります。光源や照度など、背景以外の要素は一定のものとして、背景の影響を明確に区別するために注意します。 白とびのテストデータ 高輝度のライトなどを使用して、光を本人確認書類の一部にピンポイントで照射し、白飛びを起こした状態で撮影を行います。 住所や名前などの文字部分や顔写真など、白飛びを発生させる箇所や面積を変化させながら、本人確認書類の撮影を行います。eKYCでの読み取りが成功した場合には、本人確認書類の情報が人の目でも読み取れる状態で取得できているかの確認も必要です。 手ブレ(ピンぼけ)のテストデータ 次は手ブレのテストデータを用意したいと思います。 ここまでに紹介したテストデータについては、光源や光の角度、背景を同じにすることで再現が可能な内容でした。手ブレを起こすだけであればスマホを振りながら本人確認書類の撮影を行うことで可能ですが、毎回、同じ角度、度合いで手ブレを起こすのは困難です。そのため、テスト条件を定量的に示せず、テスト結果も曖昧になってしまいます。 そこで手ブレのデータについては、ツールを使用して作成していきたいと思います。まずは元となる手ブレが起きていない画像と ガウシアンフィルタ を使用可能な任意の画像処理ソフトウェアを用意します。ガウシアンフィルタは、撮影した画像のノイズ(荒れ)を軽減する効果を生む技法ですが、デメリットとして、処理をした画像のエッジ(輪郭)がぼやけてしまう欠点があります。 この特徴を利用し、元となる手ブレが起きていない画像をガウシアンフィルタを通して標準偏差の値を調整することで、意図的にエッジのブレを起こした画像を作成します。この画像をテストデータとして使用することで、手ブレの方向、度合いを定量的に示すことが可能となります。 まとめ 今回ご紹介したのは、テストデータのごく一部に過ぎません。実際の本人確認書類には擦れや傷、汚れなどがあり得ますし、また、本人のセルフィー撮影においても髪の色、化粧の程度、カラーコンタクトの有無など、さまざまな要素を考慮する必要があります。 今後もテストデータを検討する際には、システムを利用するユーザのペルソナやロケーションを十分に考慮したいと思います。 The post eKYC（電子顔認証）のテストデータの紹介 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。このシリーズでは、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 初回のテーマは「優れたスクラムマスターが絶対に言わないこと」です。 アジャイルになれない現場のコミュニケーション 私はアジャイルコーチとして、アジャイル開発の現場を支援する仕事を、はや14年以上続けています。よって、様々な現場を見てきたつもりですが、アジャイルになりきれていない現場でのコミュニケーションには、共通する点が多くあります。そのなかでも比較的よく聞く言葉を選ぶとすると、以下のようなものが浮かびます。 「〜さんがこう言っていた」 「すごく困っている」 「なんでこういう事を聞いたかというと・・・」 1 については、現場にいない人の話をしています。誰かの言った（であろう）言葉の意図を、正確に理解するのは至難の業です。 2 については、困り具合が曖昧です。この人の「すごく困っている」はどれぐらいの度合いなのでしょう？ 1時間困るぐらい？ 1日困り続けるぐらい？ もしかして一生？ 3 については、この言葉の前に質問や確認があったことが想定できます。なぜこの人は、理由や意図をもったいぶって先に説明せずに、質問や確認を行ったのでしょうか？ 優秀なアジャイルコーチやスクラムマスターは、上記のような言葉は使いません。 なぜなら、どれも非効率なコミュニケーションの言葉だからです。 アジャイル開発において、コミュニケーションはとても重要な要素のひとつです。それなのにわざわざ非効率な方法を選ぶ必要はないでしょう。ましてやエンジニアも非効率から効率を作り出すのが職務と言えます。こちらもわざわざ遠回りする方法を選ぶ必要はないでしょう。 細かい点かもしれませんが、こういった小さな言葉の使い方の違いが、大きな認識の違いを生み出します。 アジャイルなふるまい スクラムマスター、スクラムチーム、アジャイルチーム、アジャイルコーチ・・・。アジャイル開発に関わる人達には共通する「ふるまい」があります。 アジャイル実践者は「個人やチームの自律」を目指そうとするので、「〜しなさい」といった命令をしたり、「進捗どうですか？」のような管理的な言葉をあまり使いません。必要な場合だとしても最低限にするでしょうし、将来的になくしていく努力を進めているはずです。 これと同じく、スクラムを推進するスクラムマスターや、アジャイル開発全般を支援するアジャイルコーチにも似たような「ふるまい」があります。 これが「スクラムマスターのためのコミュニケーション講座」で学んでいくテーマです。 ふるまいは身のこなし方であったり、言葉であったりします。これらを学びながら、よりよいコミュニケーション・コラボレーションスキルを身に着け、スクラムイベントなどでのファシリテーションスキルを身に着けていきます。 この講座の内容 この講座では、以下の内容を中心に解説を行っていきます。 ファシリテーション技術 コーチング技術 1on1技術 「ファシリテーション技術」 はその名の通り、この講座のメインとなるスキルです。なんとなく「こういうもんだろう」とファシリテーションを行っている人は多いでしょうが、ファシリテーションについてはさまざまな書籍や解説書、トレーニングがあるように、体系立てて学べる部分も多くあります。ここでは「なんとなく」を「ロジカル」に変えるための解説を行っていきます。 「コーチング技術」 はファシリテーション技術と同じく、この講座のメインとなるスキルです。ファシリテーションといえばMTGなどの司会者のイメージがあるでしょうが、コーチングの主要技術もファシリテーションに有効活用できるものばかりです。純粋なコーチング技術の中から、スクラムマスターやアジャイルコーチに役立つ部分を解説していきます。 「1on1技術」 は、スクラムマスターやチームメンバーの育成に利用できる技術です。今では多くの現場で取り入れられている手法ですが、実際にやってみるととてもむずかしい方法であることがわかります。この難しさを分解し、もっと効率的な1on1の方法を考えていきます。 これ以外にも、「様々なコミュニケーション方法とその使い分け」や将来的にスキルを高めていく「コミュニケーションを鍛えるトレーニング」についても解説する予定です。 「様々なコミュニケーション方法とその使い分け」 では、我々が何気なく使っているコミュニケーションの種類を整理し、それぞれの特徴を解説します。コミュニケーションの方法は、その特徴に合わせて、さらに相手に合わせて使い分ける必要があります。どのように使いこなすのが効果的かを解説していきます。 「コミュニケーションを鍛えるトレーニング」 では、ここまで学んできた技術をより高めるための方法を考えていきます。この講座ではさまざまなテクニックや経験談を語る予定ですが、その場で理解できても、どう使っていけばいいか迷うこともあるでしょう。実際の現場でも活用できるように、筆者が経験したトレーニングや、自分のチームでも明日からできるスキルアップ方法を説明していきます。 この講座の対象読者 この講座の対象読者は以下になります。 スクラムチームを支えるスクラムマスターや、スクラムマスターを目指す方 アジャイル開発支援全般ができるアジャイルコーチや、アジャイルコーチを目指す方 私はプログラマからキャリアを積んできましたが、新卒研修やOJTでプログラミング言語は学んだことはあっても、仕事の現場で使えるコミュニケーション方法を学ぶことはありませんでした。多くのエンジニアも私と同じなのではないでしょうか？ 我々は仕事に限らず、人生の多くの時間をコミュニケーションに使います。よって、ソフトウェア開発に関わるすべての人たちが、この講座の対象読者とも言えます。 ＊ アジャイルコーチの仕事はさまざまです。単純にアジャイル開発やスクラムを教えるだけでなく、アジャイルプラクティスを教えるだけでもなく、アジャイルなふるまいができる人を育てなければなりません。そうしなければ、アジャイルコーチに依存する現場が生まれてしまうからです。 私が支援する現場では、それぞれの状況に合わせて勉強会という名のトレーニングを行ったりもします。トレーニングは、アジャイル開発をやるうえで、つまづきやすい部分にスポットライトを当てるケースが多く、人気のものだと「見積もりと計画づくり」、「効果的なインセプションデッキの作成」「アジャイルQAのための品質改善」などがあります（一部は Udemyでも公開している のでご興味があればどうぞ）。 https://www.udemy.com/user/dai-fujihara/ 今回のこの講座の土台になっている「チームが自走するためのコミュニケーション入門」は、一番人気のトレーニングです。このトレーニングは支援先で行っているオンライントレーニングなのですが、エンジニアだけでなく、ビジネス側にも人気で、アジャイルチームとのコミュニケーションの取り方だけでなく、そこからアジャイルな考え方を学んでくださっています。 この講座を進めながら「なんとなく」だったコミュニケーションを、「よりよい」コミュニケーションにするために、一緒に学んでいきましょう！ 次回はスクラムイベントで一番使うであろう「ファシリテーション」の解説です。 The post 優れたスクラムマスターが絶対に言わないこと first appeared on Sqripts .

こんにちは、みなさん！QAエンジニアのゆかわです。 ふりかえりの場が暗い雰囲気になりがちで、改善が上手くいかなかったり、形骸化してしまったりした経験はありませんか？そんな課題を解決する手法として、kudo cardsを導入した事例をご紹介します。 うちのふりかえり、なんか暗い？ 私たちのチームの従来のふりかえりでは、KPTなどの手法が用いられてきました。しかし、プロジェクトを良くしたいという想いから、「Problemの分析（なぜ上手くいかなかったのか？）ばかりに焦点が当たる。」、「なんとかTryを見つけても難易度が高くなってしまう。」という課題があり、暗い雰囲気が漂っていました。別のチーム（いつも楽しそうにしている）で実施していたkudo cardsという手法を紹介してもらい、私たちのチームでも活気のあるふりかえりを実現するために取り入れてみることにしました。 kudo cardsとは？ kudo cardsは、チームメンバー同士がお互いに感謝や称賛の気持ちを伝えるために使用するカードです。この手法は感謝カード、サンクスカードなどとも呼ばれています。 オフィスにボードや箱などを設置して、感謝を伝えたいときに記入し、共有します。リモートワーク主体のチームではドローツール（例えばMiro）を使う場合もあり、いくつかのテンプレートも用意されています。 カードには、Thanks、GreatJob、Congratulationsなど、複数のバリエーションのカードがあり、感謝や賞賛をしたい内容によって使い分けることができます。 実施方法や準備などは ふりかえりカタログ を参考にさせていただきました。 出典:「 ふりかえりカタログ / Retrospective Catalog P.79 Kudo Cards 」より このふりかえりカタログには、kudo cards以外にも様々な手法が紹介されているので、ふりかえりに課題を感じたら参考にさせていただいています。 ふりかえりでの活用事例 私たちのチームでは、隔週でふりかえりを行っており、その最初の約10分間でkudo cardsを行っています。その後は通常通りKPTを用いたふりかえりを行います。kudo cardsの具体的な手順は以下の通りです。 1. カードの記入 私たちはリモートワークでの業務を行っているため、物理的にカードの受け渡しをすることができません。そのため、Miroなどのドローツールを利用してカードの共有をしています。 ふりかえりの中で5分間程度時間をとり、参加者各自がカードに記入をします。行動に気づいたときに伝えられるのが一番よいのですが、日々の業務に追われている中で記載するのは大変です。そのため、ふりかえりの時間の中でしっかり時間を取ることを重視しています。 2. カードの共有 書いたカードを記入した方自身が共有します。 共有している中で他の参加者から「私もそう思う！」といった声があがることがあります。その意思表示として記載されたカードに★印をつけるようにしています。そうすることで同じ内容でも複数人が同様に感謝しているということがわかり、行動の自信につながります。 kudo cards導入後に見られた変化 kudo cards導入後、感謝を伝えられた人からは「単純に嬉しい」、「自身が行っている行動に自信が持てた」といった声があがりました。一方で、伝える人からも「場があることでしっかりと伝えることができる」というポジティブな意見を得ることができました。 導入前の課題であった、「Problemの分析（なぜ上手くいかなかったのか？）ばかりに焦点が当たる。」という点についても、kudo cardsであがってきた内容を、続けて行っているKPTのKeepとして流用することで軽減できています。ふりかえりの最初に実施することで、アイスブレイクとしての効果もあり、発言者の偏り軽減や発言の頻度増加にもつながっています。 回数をかさねていくにつれてカードの内容自体にも変化が見えてきました。最初は「いつもありがとう」といった抽象的な内容が主だったのですが、具体的な行動「この意見貰えて助かった」や成果を称賛するメッセージが増える傾向が見られました。kudo cardsの導入によりメンバーの行動に気づけるようになってきたのだと思います。 まとめ kudo cardsは、事前準備もボードやカードを用意するだけで簡単に取り入れることができる手法です。私たちのチームでも、コミュニケーションが活性化したり、自信を持って行動ができるなどの効果を実感しています。 ふりかえりが形骸化してしまったり、活気がないと感じている方はぜひ一度試してみて下さい。感謝と称賛の気持ちを伝えることができ、チームの結束を高めることができるでしょう。 最後まで読んでいただき、ありがとうございました。 The post ふりかえりに活気を！〜kudo cards導入事例の紹介〜 first appeared on Sqripts .

こんにちは、まゆげです。 今回は「便利なツール「Pict Master」が使えない環境でもペアワイズテストのパターンを効率よく作りたい」をテーマに、その際に使用するツール「PICT（Pairwise Independent Combinatorial Testing tool）」を紹介していきたいと思います。 はじめに 以前の記事（ 「Pict Master」でペアワイズ法のテストケースを高速生成！ ）でペアワイズテストのパターンをPict Masterで作成する方法が紹介されていました。 「Pict Master」でペアワイズ法のテストケースを高速生成！ ただ、いざ使おうとしたら、作業環境でダウンロード許可が下りないなど様々な事情でPict Masterが使用できなかったというケースに遭遇したことはありませんか。 かくいう私も過去に諸事情でPict Masterを使用できず、PICTのみ使用できる環境で少しだけ苦戦したことがありました。 組み合わせのパターン抽出の際に条件付き制約を考慮するのはPict Masterの制約表に記載するのが視覚的でわかりやすいですよね。それをPICTで実行しようとした時には条件付き制約の構文をPICT実行時のモデルファイルに記載しないといけません。その場合、構文を書くことに慣れていないと導入の際の高い壁になってしまうこともあるのではないかと思います。 便利なPict Masterが使えない環境でもPICTを使用してパターンを作成したい、でもモデルファイルの書き方に自信がなくて一歩踏み出せないという方に向けて、単純な条件付き制約ならば割と簡単に書けてPICTを実行できる方法を紹介したいと思います。 ぺアワイズテストやPict Masterについては先ほど紹介した 以前の記事 を参照いただくとして、今回使用するPICTを簡単に紹介します。 PICT（ Pairwise Independent Combinatorial Testing tool ）とは PICTとはペアワイズテストのテストパターンを条件に合わせて効果的に生成できるコマンドラインツールです。様々な実行オプションと実行時に付けるプレーンテキストで作成したモデルファイルにはベースとして因子と水準を記載し、さらに条件付き制約の構文を記載する（しないケースもある）ことによって目的に合ったテストパターンを生成することができます。 詳しくは GithubのPICT紹介ページ を参照してみてください PICTはコマンドラインから以下のように実行しますが、特に実行オプションなしの場合はシンプルでとても簡単です。 >PICT.exe モデルファイル名.txt ただ実行するにあたってのポイントはモデルファイルの書き方になります。ということで条件付き制約を含めて記載方法を紹介していきます。 モデルファイル（条件付き制約を含む）の書き方 以前の記事 で使われていたスーツオーダーシステム（勝手に命名．．．(;^_^A　）の例を使ってPICTを実行できるようにしていきたいと思います 因子水準表は以下のようになっていました。 ではこの因子水準表を元にモデルファイルを書いていきます。 モデルファイルの書き方 その1　※因子と水準の書き方 ↓条件付き制約がなければいたって簡単、因子（パラメータ）、水準（値）の書き方 例のように因子（パラメータ）ごとに行を分け、それぞれの水準（値）をカンマで区切ります。また因子と水準はコロンで区切ります。 例）<因子> : <水準1>, <水準2>, <水準3>, … ○上記因子水準表を元に書くと以下のようになります ITEM: Jacket, Pants, TwoPieceSuit, ThreePieceSuit, Tuxedo FINISH: Single, Double, No SIZE: Small, Medium, Large, Order PATTERN: Plain, Stripe, Check, Order OPTION: No, Yes モデルファイルの書き方 その2　※条件付き制約がある場合 手順１ 　 仕様をもとに一文で条件付き制約を書いてみる ★下記例の様にシンプルな一文に起こしてみる （例）もし因子Aが〇〇であれば（〇〇でなければ）、因子Bは～になる(～にならない) 手順２ 　 記載した一文を構文に書き換えてみる ★条件文はIF～THENで記載 （例）IF [A] =(<>) ”〇〇” THEN [B] =(<>) “～” ; 「=」の場合は「〇〇が～ならば」 「<>」の場合は「〇〇が～でなければ」 因子は［］で囲うこと 水準が文字列の場合は””(ダブルコーテーション)で囲うこと、数値の場合は””は不要 構文の文末には；(セミコロン)を記述 ORやAND、INといった論理演算子も使用できます ではスーツオーダーシステムの例に記載のあった条件付き制約3つを文章化します。 ※本文中で「条件付き制約」と記載しているものは以前の記事では「制約条件」と記載されているため、以下制約1、2、3では原文の表現をそのまま引用しています。 制約1： <制約条件> 『購入アイテム（ITEM）』が「ジャケット（Jacket）」の場合 <制約対象> 『仕上げ（FINISH）』は「なし（No）」となる 制約1を一文にすると もし [ITEM] が "Jacket"であれば [FINISH] は "No"となる。 さらに構文化すると IF [ITEM] = "Jacket" THEN [FINISH] = "No"; となります 制約2： <制約条件> 『購入アイテム（ITEM）』が「ジャケット（Jacket）」以外の場合 <制約対象> 『仕上げ（FINISH）』は「シングル（Single）」もしくは「ダブル（Double）」となる 制約2を一文にすると もし [ITEM] が "Jacket"でなければ [FINISH] は "Single" か "Double"となる。 さらに構文化すると IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; となります 制約3： <制約条件> 『購入アイテム（ITEM)』が「○○スーツ(○○Suit」もしくは「タキシード（Tuxedo）」以外の場合 <制約対象> 『オプション（OPTION）』は「なし（No）」となる ※この制約3の場合、PictMasterの例のようにワイルドカードをつかって、さらに別条件も重なる場合、複雑になってしまい間違えやすくなります。 ですので、ここはシンプルに「〇〇スーツ」と「タキシード」以外というのを「ジャケット」か「パンツ」の場合としてしまった方が間違いは少なくなります。 したがって制約3は以下のように文章化します。 もし [ITEM] が "Jacket" か "Pants" であれば [OPTION] は "No"となる。 この場合、文章のまま以下のように記載しても良いですし、 IF [ITEM] = "Jacket" OR [ITEM] = "Pants" THEN [OPTION] = "No"; ORをひとまとめにしてINという演算子を使って、以下のようにも記載出来ます。 IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; ↓上記条件付き制約を構文化したものを下記にまとめます。 IF [ITEM] = "Jacket" THEN [FINISH] = "No"; IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; 前述の「モデルファイルの書き方 その1」で作成した 因子、水準のベース と「モデルファイルの書き方 その2」で作成した 条件付き制約 を記載したものをモデルファイルとして作成します。 ↓以下内容を記載してモデルファイル（ファイル名は任意）として保存する ITEM: Jacket,Pants,TwoPieceSuit,ThreePieceSuit,Tuxedo FINISH: Single,Double,No SIZE: Small,Medium,Large,Order PATTERN: Plain,Stripe,Check,Order OPTION: No,Yes IF [ITEM] = "Jacket" THEN [FINISH] = "No"; IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; 補足 　条件（条件付き制約になるもの）が複雑になりそうな場合、まずは一つずつ簡潔な箇条書きで整理してから文章化するのもオススメです 作成したモデルファイルでPICTを実行する コマンドラインから実行する方法は前述の通りですので以下に実行結果を記載します。 ITEM FINISH SIZE PATTERN OPTION TwoPieceSuit Single Order Plain No Tuxedo Single Medium Order Yes Jacket No Large Check No TwoPieceSuit Double Small Order Yes ThreePieceSuit Double Order Check Yes Pants Double Medium Order No ThreePieceSuit Single Large Stripe Yes Tuxedo Double Small Plain No Jacket No Medium Plain No Pants Single Small Stripe No Tuxedo Single Order Check Yes ThreePieceSuit Single Small Plain No Pants Double Large Plain No TwoPieceSuit 　　Double Large Stripe Yes Tuxedo Single Order Stripe Yes Pants Single Order Order No ThreePieceSuit Single Medium Order Yes Pants Single Small Check No Jacket No Small Stripe No TwoPieceSuit Double Medium Check Yes Jacket No Medium Stripe No Jacket No Order Order No Tuxedo Double Large Order No ThreePieceSuit Single Order Plain Yes いかがでしょうか、このように簡単に生成することが出来ます。 知っておくと 便利な実行オプションを活用しよう 便利に使えるオプションを紹介します。 /e: ファイル名 　重要な組み合わせを予め加えることができる スーツオーダーシステムの例だと最高金額になる以下の組み合わせを加えていましたので上記オプションを適用します。 ファイルへの記載方法はPICTの出力結果と同様にする ↓表の組み合わせを下記の様に記載して例えばケース指定.txt（任意）として保存 ITEM FINISH SIZE PATTERN OPTION Tuxedo Double Order Order Yes 以下のようにファイルを指定して実行します。 >pict.exe モデルファイル名.txt /e: ケース指定.txt 実行すると指定した組み合わせを含めてパターンが生成されます。 ITEM FINISH SIZE PATTERN OPTION Tuxedo Double Order Order Yes TwoPieceSuit Single Order Plain No Tuxedo Single Medium Order Yes Jacket No Large Check No TwoPieceSuit Double Small Order Yes ThreePieceSuit Double Order Check Yes Pants Double Medium Order No ThreePieceSuit Single Large Stripe Yes Tuxedo Double Small Plain No Jacket No Medium Plain No Pants Single Small Stripe No Tuxedo Single Order Check Yes ThreePieceSuit Single Small Plain No Pants Double Large Plain No TwoPieceSuit 　　Double Large Stripe Yes Tuxedo Single Order Stripe Yes Pants Single Order Order No ThreePieceSuit Single Medium Order Yes Pants Single Small Check No Jacket No Small Stripe No TwoPieceSuit Double Medium Check Yes Jacket No Medium Stripe No Jacket No Order Order No Tuxedo Double Large Order No ThreePieceSuit Single Order Plain Yes 赤字箇所 がオプションで追加した組み合わせです。 その他の便利なオプションをいくつか載せておきます。 /o:N 　組み合わせるパラメータの数 (N(初期値: 2)) ★PICTのオプションで3因子間以上（N因子間）でも生成可能★ /d 　モデルファイルに記載するパラメータに対する値の区切り文字を指定する （指定なしオプションのデフォルトはカンマ） /r 　生成結果をランダム化するので毎回同じ出力結果にはならない 紹介したPICTの実行オプションで3因子間網羅も出来るし、Excel等で見やすく表示できるようにすることも、生成結果をランダム化することで様々なパターンをテストすることも可能です。 PICTが使用できない！そんな時は！ （ Pairwise PICT ONLINE の紹介） ここではモデルファイルを同じように入力欄に直接記載して実行することで同じ結果が得られます。 （参考）Pairwise Pict Online ※ただし、インターネット上のサイトを利用することになりますので、セキュリティ上のリスクを考慮しないといけません。お客様に使用許諾を得るなどの対策が必要ですので使用する際には慎重を期すようにしましょう。 まとめ 条件付き制約をわかりやすい文章に出来れば構文化は簡単にできます 結果誰でも条件付き制約の構文を記述するというハードルが下がってPICTを気軽に使いやすくなります まずは簡単な条件付き制約の構文を書くところから始めて、慣れてきたら色々な演算子などを駆使してより複雑な条件付き制約の構文を書いてみましょう おまけ せっかくなので作成例をもう一つ、仕様から文章化して実行結果までを参考までに記載しておきます。 ホテルの予約システムの仕様例　※PICT適用のためのサンプル仕様（オリジナル）です 【仕様】 ・ 部屋のタイプは4種類（シングル、ツイン、ダブル、ダブル2台） ・ 一部屋の宿泊人数は1名～4名 ・ 宿泊プランには朝食付き、朝夕食付き、素泊まりがある ・ 一回の予約で可能な宿泊日数は1泊～5泊 ・ シングルは1名利用に限る ・ ツインとダブルの1名利用は可能 ・ ダブル2台の部屋は2名から4名の利用が可能 ・ 3泊以上の場合に限り、素泊まり利用が可能 ・ 連泊は5連泊までを上限とする 【因子水準の整理】 部屋タイプ：シングル、ツイン、ダブル、ダブル2台 宿泊人数：1、2、3、4 プラン：朝食付き、朝夕食付き、素泊まり 宿泊数： 1、2、3、4、5 【条件付き制約の文章化】 もし［部屋タイプ］が”シングル”だったら、［宿泊人数］は1名であること もし［部屋タイプ］が”ツイン”か”ダブル”だったら、［宿泊人数］は2名以下であること もし［部屋タイプ］が”ダブル2台”だったら、［宿泊人数］は2名～4名であること もし［宿泊数］が”素泊まり”だったら、［プラン］は”朝食付き”か”朝夕食付き”であること もし［プラン］が”素泊まり”だったら、［宿泊数］は3～5泊であること 【モデルファイル（因子水準、条件付き制約の構文化）】 type: Single, Twin, Double, Doublex2 Guests: 1, 2, 3, 4 Plan: breakfast, dinner, stay Stays: 1, 2, 3, 4, 5 IF [Type] = "Single" THEN [Guests] = 1; IF [Type] = "Twin" OR [Type] = "Double" THEN [Guests] <= 2; IF [Type] = "Doublex2" THEN [Guests] IN {2,3,4}; IF [Stays] <= 2 THEN [Plan] = "breakfast" OR [Plan] = "dinner"; IF [Plan] = "stay" THEN [Stays] IN {3,4,5}; 【実行コマンドと実行結果】 > PICT.exe モデルファイル.txt ↓　↓　↓ 以下は出力結果を表に転記してナンバリングしたものです。 一連の流れを載せてみました。水準が数値の場合だった際の条件付き制約の構文の例も併せて記載してあります、これらを参考に是非色々試してみてください。。 参考資料 GitHubのPICTの紹介ページ PICTについて詳細なことはこちらを読むとさらに理解が深まります。 PICTの最新版 （2023年12月現在の最新はVer.3.7.4）の在り処の紹介 以前はインストーラでインストールが必要でしたが、現在は.exe（実行ファイル）のみの配布となっています。 最後までお読みいただき、ありがとうございました。 The post PICTを活用してペアワイズテストのパターンを手軽に生成する方法 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 ＜テストエンジニアのための論理スキル[再]入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT 第6回のテーマは、「文レベルの論理の言葉」のうち条件や場合を示す言葉の意味と働きです。 「希望者が5人集まったら、イベントを開催します」といった、 “特定の条件/場合を前提とした主張” を言いたい時があります。このような表現はソフトウェアにとっても重要であることは 第1回 で述べました。実際、ここまでに出てきた例の殆どで使われています（読み返してみてください！）。 この、条件や場合を示す言葉に出逢った時は、どういうことに注意を向けるとよいでしょうか。 前回に引き続き、一般的な文章や日常会話などで用いられる語句や表現を 一般語 と呼びます。 条件・場合を表す言葉の基本形・“ならば” 文章の中で“条件や場合を示す”際に目印として使われる語句の代表格が、 “ならば” や “場合” です。 「論理の言葉」としての“ならば” 典型的な条件の表し方は、 「PならばQ」 という形を取ります。 「テストが全件合格したら、テストを終了する」 「当日雨天の場合、大会を中止とする」　etc. Pを 前提(仮定)または前件 、Qを 帰結または後件 といいます。 「テストが全件合格」「当日雨天」が 前提 「テストを終了する」「大会を中止とする」が 帰結 「PならばQ」は、 「Pという前提が成り立つなら、Qという帰結が成り立つ」 ということを表しています。 この“ならば”の働きを「 条件法 」といいます（「もし昨日晴れていたら、○○ランドに行ったのに」のような、事実に反することを述べる条件法とは異なります）。 PとQの関係に注意してください。 「PならばQ」は、「Pが成り立つ時はQが成り立つ」「Pが成り立つのにQが成り立たないことはない」とだけ言っており、「Pが成り立たない時」のことは何も言っていません。 従って、PでなくてもQであることがあり得ます。（集合のベン図的に表すと、「PならばQ」は図6-1の左を指しています）。 図6-1　「PならばQ」のベン図 「テストが全件合格」していなくても、テストが終了することはあり得る（他の条件があるかも知れない） 「当日雨天」の他にも大会を中止する条件はあり得る（強風の場合、参加者が揃わない場合、など） 等値(同値)の“ならば” 「PならばQ」もその逆「QならばP」もともに成り立つ、という場合もあり、これを「双条件法」といいます。（PとQが“同じ大きさ”でぴったり重なる。図6-2） 図6-2　双条件法(等値(同値)の“ならば“) 「稼働中にバッテリー残量が10%を切ったら、“充電して！”と音声で知らせます」  稼働中に“充電して！”と音声が流れる場合は、バッテリー残量が10%を切っている 「獲得ポイントが○○になったら、ランクAAになります」 ランクAAになる条件は○○ポイント獲得のみ 等値(同値)の“ならば”を明示する語句として、「……の場合、そしてその場合に限り、～である」という言い回しが用いられることもあります。 （英語の論文などでは”if and only if …”という表現が使われます(“iff”と略される)） ソフトウェアに出てくる“ならば” ソフトウェアでは、条件や場合を示す“ならば”は、成り立つ成り立たないというよりは、特定の条件/場合に対応する特定の処理/動作や、特定の処理/動作ができるための条件を記述する局面で使われることが多いでしょう。 「条件を満たさない時の動作」といった記述が添えられることも多いです。 ある箇所で次のような記述があったとして： 「利用者がログインしており、SP権限を持っている場合は、XYZ機能を使うことができる」 「数値のいずれかがゼロの場合、エラーメッセージE1を出力する」 別の箇所で、 「別の条件が満たされている場合、XYZ機能を使える」や 「別の条件に該当する場合、エラーメッセージE1を出力する」 という記述があることもあります。 逆・裏・対偶 「PならばQ」の“変形” 「PならばQ」のP(前提)とQ(帰結)との関係に着目して、次の三種類の変形が考えられます。（図6-3） 図6-3　逆・裏・対偶 逆 ：　PとQを入れ替える。 「QならばP」 裏 ：　PとQをそれぞれ否定する。 「NOT(P) ならば NOT(Q)」＝ 「PでないならばQでない」 対偶 ：PとQをそれぞれ否定し、さらに入れ替える 「NOT(Q) ならば NOT(P)」＝ 「QでないならばPでない」 もとの文の「 裏の逆(または逆の裏) 」に等しい 逆・裏・対偶は、同じ変形を二度繰り返すと、もとの形に戻ります。図で確認しましょう。 もとの文：「PならばQ」 逆「QならばP」の逆は、「PならばQ」 裏「PでないならばQでない」の裏は、「PならばQ」 対偶「QでないならばPでない」の対偶は、「PならばQ」 なお、逆と裏は互いに対偶の関係にあります。（図6-3） もとの文と逆・裏・対偶との関係 もとの文に対して、逆・裏・対偶について以下のことが言えます。 逆・・・「PならばQ」が成り立っていても、 逆「QならばP」が成り立つとは限らない 「テストを終了するなら、テストが全件合格している」？？ 「大会が中止になるなら、当日雨が降っている」？？ （「等値(同値)の“ならば”」なら、逆は成り立つ） 裏・・・「PならばQ」が成り立っていても、 裏「PでないならばQでない」が成り立つとは限らない 「テストが全件合格していないなら、テストを終了しない」？？ 「当日雨が降らないなら、大会は中止にならない」？？ （「等値(同値)の“ならば”」なら、裏は成り立つ） 対偶・・・「PならばQ」が成り立つなら、対偶「QでないならばPでない」は必ず成り立つ 「テストが終了していないなら、テストが全件合格しているのではない」 「大会が中止にならないなら、当日雨は降っていない」 条件・場合の表現をチェックする 文章の理解を確実にするために、条件・場合の表現の逆や裏を考えて、文章全体を調べてみたり考えてみたりする方法があります。 逆： 「Qが成り立つ場合には、Pという前提が成り立っていると考えてよいか」と考えてみる 裏： 「Pでないならば、Qにはならないか」と考えてみる 具体例① もとの文：「利用者がログインしており、SP権限を持っている場合は、XYZ機能を使うことができる」 逆： 「XYZ機能を使うことができる」なら、「ログインしており、SP権限を持っている」と言えるか。他の場合はないか 裏： 「ログインしており、SP権限を持っている」のでないならば、「XYZ機能を使う」ことはできないか 具体例② もとの文：「数値のいずれかがゼロの場合、エラーメッセージE1を出力する」 逆： 「エラーメッセージE1を出力する」ならば、「数値のいずれかがゼロ」であると言えるか。他の場合はないか 裏： 「数値のいずれかがゼロ」でないならば、「エラーメッセージE1を出力」しないか 「同じ処理をする他の場合はないか？」「ここに記されている“条件や場合”を満たしていない場合の動作はどうなる？」といったことを自然に気にかけている人も多いと思います。それは、 「PならばQ」の形の文に対して、PとQの関係が自然に気になるから なのかも知れません。 むすび 6回にわたって、“論理的”に考えるための「基本的な道具」である「 論理(ロジック)の言葉 」をいくつか見てきました。 取り上げたのはあくまでも「基本的な道具」です。これらを憶えたら、ぜひ次のステップに進んで論理のスキルを高めてください。 文章レベルの論理：文章の構造を理解するための論理の言葉 長い文章の筋道を追ったり、話を整理して論旨を把握するのに役立ちます 推論：考えの筋道を立てるためのルール 前提から結論を導き出したり、 複数の事象を一般化して考えたり、事象から原因の仮説を立てたりする方法 （故障の要因の推測や、故障の原因の推測などに役立ちます） 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『論理的思考の技法〈1〉第2版　「ならば」をめぐって』(鈴木美佐子 / 法学書院) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 『スマリヤン先生のブール代数入門』(スマリヤン / 共立出版) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT The post [第6回] 文レベルのロジック (2)条件・場合を表す言葉 first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第6話です。 前々回 、 前回 から引き続き、学び直し回です！ 書籍「基本から学ぶソフトウェアテスト」を読んで、現在でも活かせる内容があるのか？ないのか？会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 過去のミスに愕然とする事ってありますよね？えっ？ありませんか？私はあります。。。 くまねこ QA業界経験1x年のエンジニア。 ジムに行った後、「運動したし、食べまくるぞ！」ってなる日ありますよね？僕はいつもです。。。（元の体重に戻りつつあります） イラストby くまねこ 何やらまーくーが愕然としている模様…何があったのでしょうか？ 今日も二人のやりとりをお楽しみください！ 今日も仲良く学び直し！山あり谷ありの探求の旅？？？ ぐあああぁあああああ！（突然の叫び！） あらっ、まーくーさん、どうしたんですか？Knock knock Downしてますね…？（愕然として青ざめている…何があったんだろう…？） く、くまねこさん、、、書籍「 基本から学ぶソフトウェアテスト （第4版）」P.83の欄外を見てくれぇ・・・ は、はいっ！ふむふむふむふむ…（ふむむ…何があるんだ？？？） ここだよ…こ、ここぉ～！Woo～！ 訳注：原著は1993年に執筆されており、2000年問題はそのころまだ騒がれていなかった。 基本から学ぶソフトウェアテスト 今までの学び直し記事で、「20年前の書籍を紹介している」って書いてたけど、原著は30年前のものだったんだぁ。。。 30 years ago～！…そうみたいですね♪（もっと昔だったのかぁ…ますますエインシェント！でも、何を取り乱しているんだろう？） 全世界に公開されている記事で30年前のものを20年前のものと、虚偽の記載をしてしまった。もう取り返しがつかない・・・。原著に裁かれているような気がするぅ…ぐあああぁあああああ ちょっと落ち着いてくださいよ。まぁ日本では20年前に発売された書籍だから問題ないんじゃあないですか？This book was made in Japan！We live in Japan！さっ、今日は第5章、第6章から学び直していきましょう！ （えっ？あっさり？Why？取り乱した自分が恥ずかしい。。。そんな自分に負けないためにあれを使おう…）お、おぉ。そ、そうだね。ま、学び直して行こう！Bigbang ？ \ / → → ﾉｼ Hello World Yeah～！ \ /（訳：まーくーさん、BigBang使ってここまでの流れを再創生したのは良いけど…うっかり自分から「学び直ししよう」って言っちゃった～！ぐあああぁああああ～！((( )))） 第5章 障害の報告と分析を読んで まずは「本章のねらい」からですね。本章では「障害レポートをどう使えばプログラマとスムーズに意思疎通できるかを説明する。」とあります。 「バグチケット」「バグ票」「バグレポート」「障害票」など現場によっていろいろな呼び名がありますよね？ そうだね、本記事では書籍に記載のとおり「障害レポート」で進めましょう！ はーい。 障害レポート以外でもプログラマとのコミュニケーションは取る必要があるけど、テスト担当者としてプログラマと障害のやり取りをする一番重要なツールが障害レポートだ。これが上手く書けないといわゆる「バグピンポン」が発生してしまう。 ﾉ あ、プログラマとテスト担当者で障害レポートが行ったり来たりするやつですね。なかなかこちらの言いたいことがプログラマに伝わらず悲しくなってくるやつですね。 でもテスト担当者の書く障害レポートの内容が不十分だったり、書き方が悪かったりすることが原因で発生することが多いんだ。テストを実施する立場で言えば、この章はとても重要だね。 心して掛かります！ちなみに「本章で紹介するレポートは、紙での運用を想定している。」っていうのは、時代を感じますね。 いまはほとんど障害管理システムを使っていたり、表計算ソフトなんかで表にして運用することがほとんどだからね。でも第一報は紙って現場もまだあったりするよ。 えー。びっくり。そうなんですねー！障害管理システムでも紙でも基本的に内容はいっしょですよね？本章で記載されている以下をちゃんと理解して、良い「障害レポート」が書けるよう学び直します ・障害レポートの項目 ・質の高い障害レポートの書き方 ・再現性のある障害分析の方法とコツ ・障害を再現させる方法 基本から学ぶソフトウェアテスト おぉ、冒頭にとても良いことが書いてあるね！ 障害を見つけたら、その場でレポートを作成せよ！ 基本から学ぶソフトウェアテスト メモを取ってあとから書こうとしても、時間が掛かったり、曖昧な記述になってしまったり・・・すぐに書くって大事ですよね。 うん。すぐに書けないこともあるけど、極力早めに書いた方が良いのは間違いない！障害を早く開発側に報告できるしね。次にレポートの内容について記載すべき項目があげられているよ。 ふむふむ…ふむふむ…書籍に記載されている障害レポートのフォーマットを見てみると、現在の業務でも使っている項目は網羅されているようです。共感したのは、障害検出～報告までのところです。実際のテスト中に障害と思われる現象を検出した時、今までの手順や条件などを整理しながら、必要なことをなるべく簡潔に開発チームに伝えられるように心がけています。 GOOD！障害レポートの報告内容によって問題の重大さの認識や、開発側のデバッグ効率などに影響を与えるから、改めて理解して実践できるようになっておきたいところだね。 あと、スケジュールに余裕がないピリピリした状態でも開発チームと良い関係で進めていけるよう、障害レポートの表現にも気を付けています。ちょっとした気配りをするだけで、テスト担当者・開発者間の行き違いや感情的な衝突を防いだりできるので、言葉遣いも重要ですよね！ 誰が言ったか知らないが、「バグを憎んで人を憎まず」ってのが大事だよね ですね（心に刻みます！）。次は「再現性のある障害の分析のコツ」＆「障害を再現させる方法」！これは興味のある方も多いのではないでしょうか？ だよね。まず障害の分析として以下を挙げている。 ・最も致命的な現象を明らかにする ・最も簡単で制約の少ない条件を明確にする ・同じ障害を発生させる別の手順を見つける ・関連する障害を探す 基本から学ぶソフトウェアテスト ふむふむ。上記の情報がそろっている障害レポートなら、開発者もプログラムの修正がしやすそうですね！ 続いて「再現性のある障害の分析のコツ」＆「障害を再現させる方法」が詳しく記載されているよ。 ここは特に現在のテスト担当者にも活かせる内容ですね！障害を検出したときって、上記ポイントを明らかにするために、過去にさかのぼって操作や条件を思い出したり整理したり・・・考えること多いですよね。 この書籍の分析のコツや障害再現方法を参考にすれば、テスト経験が浅くても良い障害レポートが書けそうだね。 焦ってると頭の中だけで考えてながら進める事が多いですけど、色々やり過ぎて迷子にならないよう、上記ポイントを押さえつつメモを取りながら進めていくと良いかなって思いました。 オーゥケイ！そんな我々が報告した障害レポートがどこへ行こうとしているか、くまねこさんは知りたくないか～い？ Yeah～！ \ /（訳：突然エンジンがかかった？？？とりあえず乗っておく～！） このまま第2部、第6章も読んでいくぞー！カモォン！ Yeah～！ \ /（訳：ぎゃー！） 第6章 障害管理システム を読んで 6章は障害管理システムについて。私もくまねこさんも、障害管理システムとして独立して管理しているプロジェクトや、Redmineなどを使ってタスクと一緒に管理するプロジェクトを担当したことがあると思うけど、ここでは前者の意味合いで書かれているかな。 現代ではアジャイル開発のように短いスパンで設計～テスト～リリースするプロジェクトも多いですし、本書は30年前のものの書籍だからウォーターフォール開発前提の重厚な内容だとすると、導入が難しいところもあるかもしれませんね。 ただ本章のねらいでも「障害レポートを報告後どうするかを述べる。」と記載されていて、「障害を管理する」という点では共通して学べることもあると思うから、読み進めていこう。 まず、「障害管理」というところではテスト対象で報告された障害の可視化（重大度の大きな障害が何件あるか、修正された件数が何件あるか等）ができる点は当然良い点として挙げられると思います。 製品の品質状況やプロジェクトの状況を可視化することができるよね。 ただ可視化したことで、人や管理の問題（誰がどれぐらい件数を出しているのか、起こりえる問題など）についても言及があって、改めて障害管理システムの与える影響について考えさせられました。 そうだね。正しい運用をしないと、プラスの影響だけでなくマイナスの影響も出てしまうんだね。 やはり、テスト担当としてプロジェクトに参画すると、自分の実績って「どれぐらいのペースでテストを消化しているか？何件の障害を検出して報告できたか？」というのが大きいと思います。 報告した障害レポートの数を競ったり、人の障害レポートの数をみて「あ、自分の報告少ない！」って焦ったりね そうそうそれです！でも、障害管理システムで集計された数字が他のテストメンバーや開発メンバーに与えるマイナスな影響についても言及されていて、プロジェクトを運営する側は正しく障害管理システムを運用しなければならないとわかり、とても参考になりました。 そうだね。マネジメントする立場からすると、ある程度数字で判断しなければいけない場面ってあると思うけど、障害管理システムのいちばんの目的は下記にもあるように「障害の発生/修正状況を管理する」ということだから、そのことを意識して使っていくよう注意が必要だね。 障害管理システムは、修正すべきバグを修正するためにある。この目的に直接関係ない事は、二の次である。 基本から学ぶソフトウェアテスト はい。また、テスト初心者であっても本章を読むことで、プログラマやプロジェクトマネージャー等さまざまな役割のメンバーが、それぞれの視点で障害管理システムを利用する際に考えなくてはならないことが分かると思います。 障害管理システムが備えておくべき要件と各役割の全体像を理解するには良い記載かも知れないね。次に、障害管理システムで出力できるレポート関連について記載があるけど、どうかな？ 検出した障害の一覧というところで、基本的な項目や出力できるレポートの種類は現在とあまり大きな差異はないように思います。ちょっと結びつけるには強引かもしれませんが、 以前の記事 で話した「目的に対する最終的な成果」についての報告で、出力したレポートを使ってテスト担当として障害傾向や品質状況についての考えをコメントできるようになると、より説得力のある報告ができると思いました。 そうだね。ここで学んだことを活かして、障害管理システムを使いこなしていきたいね！ ゆるっと♪どうやってる？探索的テストの世界！ まとめ 今回は障害関連ということで見てきたわけだけど、どうだったかな？ 第5章の障害報告については大事なポイントが整理されていて、自身がやっていたこととの比較から良い学び直しになりました。障害報告フォーマットについては、今までの経験からすると新しい発見はあまりありませんでしたが、基本は陳腐化しないものであるということが実感できてよかったです。 学び直してるねぇ(笑) （茶化さないでくださいよー）また、現場によって障害報告フォーマットの項目が異なることもあるので、そういった場合には「改善提案」という形で今回学び直したフォーマット項目に留意しつつ、不足部分があれば提案して、導入するメリットまで説明できるようにしていきたいです。 良いね！紙で障害レポートを書くことを前提にしていたり、時代を感じる記載はあったけど、全体的に現在でも大事にすべきポイントが多々記載されていたね。私もテスト結果のレポートなどを提出する時には、第6章に書かれている「障害管理システム」の運用の考え方やフォーマットを参考にして、今後の活動に役立てていきたいと思う！ よーし、第2部もこの調子で学び続けていかなければ…バーイ！ ﾉｼ 三 Yeeeeeeeeeeaaaaaaaaaah！ \ / （アンコール！アンコール！） 次回予告 三 ﾉｼ（戻ってきた）さて、今回はここまでにしようか。 お互いJSTQBのALの学習は進んでないけど(笑)、次回はどんな感じかな？ 次回のまーくー＆くまねこは、 JSTQB ALTM試験、勉強する気ある？どうでしょ！（仮） JSTQB ALTM試験、受けるかも？受けないかも？どっちでしょ！（仮） の２本でーす。 最後まで読んで頂き、ありがとうございました！ よろしければ、過去のゆるっと♪シリーズもお楽しみください！ 次回もまた見てねー ﾉｼ 三 ﾉｼ 三 ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！②～あきらめてしまわないでね 難しさ感じても～ The post ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ first appeared on Sqripts .

新卒でフロントエンド開発者をしています、イソダです。 先輩が作成した社内情報お問合せSlackBot をLangChainというツールを使用して、ベクターデータベースとChatGPTに接続して、より賢く、より人間らしい回答ができるようにシステム改修しました。今回はそのシステムについて簡単に紹介したいと思います。 （今回作成したシステムはまだ運用をしておらず、今後の運用を調整中です。） Cloud FunctionsとSlack APIに踊らされたSlack Bot作成 LangChainとは Introduction | Langchain LangChainはChatGPTなどの言語モデルを活用したアプリケーションを開発するためのフレームワークです。利用方法としては、ChatBot、データベースやドキュメントなどの知識を元に質問に答えてくれるお問合せAI、ドキュメントの要約などいろいろあります。 今回はLangChainを使用して、社内制度へのお問合せSlackBotを作成していきます。 システム構成 作成したシステムの構成は次のようになっています。 社内情報お問合せAIシステムの構成図 まずSlackからの質問文をLangChainで受け取ります。 これをLangChainからベクターデータベースにクエリとして送信します。 すると質問文と関連があるドキュメントを抽出して返ってきます。 次にLangChainからChatGPTにドキュメントの内容を参考にして質問に答えるように指示を出します。 そしてChatGPTから回答が返ってきます。 返ってきた回答をそのままSlackに返します。 LangChainはGoogle Cloud Functions、ベクターデータベースはGoogle Cloud Storage上に構築しています。 以降は、ベクターデータベースの作り方とLangChain、ベクターデータベース、ChatGPTとのやり取りについて説明していきます。 ベクターデータベースの構築 ベクターDBは、様々な形式のデータをベクトルとして保存し、クエリに対して類似度検索をして該当したデータを返してくれるデータベースです。 今回は社内向けのWebサイトに掲載されている情報を取り入れてベクターDBを作成しました。Webサイトをクローリングで取得してtxtファイルとして保存したものを利用しています。本記事ではクローリングについては説明しません。 以下がPythonで実装したベクターDB作成のコードです。 from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import CharacterTextSplitter import dotenv # OPENAI_API_KEYの読み込み # (このコードがあるディレクトに.envファイルを作り、 # 中身に OPENAI_API_KEY=オープンAIのキー を書いておく) dotenv.load_dotenv() # データの読み込み loader = DirectoryLoader("Webサイトのtxtデータがあるディレクトリ", glob="**/*.txt") documents = loader.load() # テキストデータを小さく分割 all_splits = CharacterTextSplitter().split_documents(documents) # ベクターDBの作成 db = FAISS.from_documents(all_splits, OpenAIEmbeddings()) db.save_local("./faiss_index") まずローカルに保存してあるWebサイトのtxtデータを DirectoryLoader ＆ load() で読み込みます。引数の glob で拡張子がtxtであるファイルのみ読み込むよう指定しています。 次にベクターDBに格納するテキストデータをある程度の長さで分割していきます。この工程を行う理由としては、ベクターDBにクエリを出したときに帰ってくるドキュメントを短く、かつクエリと深く関連しているようにするためです。Webサイトなどのドキュメントは、１ページに複数個のトピックが書かれていることが多いです。これを短く分割することで、１つのドキュメントに含まれているトピックを絞り、クエリとは関連のないトピックが含まれることを防ぎます。 分割を行うインスタンスを CharacterTextSplitter() で呼び出し、分割を行う関数 split_documents() に先ほど読み込んできたWebサイトのデータ documents を渡しています。 最後にベクターDBを作成します。今回はFAISSというベクターDBを使用しています。またテキストデータをベクトルに変換する埋め込みモデルはOpenAIのものを利用してます。 FAISS.from_documents(ドキュメント, 埋め込みモデル) でベクターDBが生成されます。できたベクターDBは、 db.save_local("./faiss_index") でローカル上のfaiss_indexディレクトリに保存します。 faiss_index ディレクトリ内に index.faiss と index.pkl という２つのファイルが生成されます。 問合せシステムの構築 以下のコードがPythonで実装した問合せシステムです。モジュールはGoogle CloudとLangChainのものをインポートしています。以降の節で詳しく説明していきます。 import os import functions_framework from google.cloud import storage from langchain_community.vectorstores import FAISS from langchain_openai import ChatOpenAI from langchain_openai import OpenAIEmbeddings from langchain_core.messages import HumanMessage @functions_framework.http def ai_question_vectordb_api(request): try: query_dict = dict() question = request.get_data(as_text=True) # GCSからベクターDBをダウンロード storage_client = storage.Client() bucket = storage_client.bucket("test_vecdb_for_langchain") blob = bucket.blob("index.faiss") blob.download_to_filename("/tmp/index.faiss") blob = bucket.blob("index.pkl") blob.download_to_filename("/tmp/index.pkl") # ベクターDBにクエリ vectorstore = FAISS.load_local("/tmp/", embeddings=OpenAIEmbeddings()) docs = vectorstore.similarity_search(question, k=3) input_documents = str() for d in docs: input_documents += "input_documents: {}\n".format(d.page_content.replace('\n', '')) # 問合せに対する回答を生成 llm = ChatOpenAI(model_name="gpt-3.5-turbo-16k", temperature=0, request_timeout=60) query = input_documents query += "question: {} ".format(question).replace('\n', ' ') query += "questionに答えてください。" answer = llm([HumanMessage(content=query)]) return answer.content except Exception as e: print(e) return "ごめんなさい。。何か問題が起きたようです。。" 質問受付 @functions_framework.http def ai_question_vectordb_api(request): question = request.get_data(as_text=True) 一行目の @functions_framework.http はGoogle Cloud Functionsで実装するときのおまじないみたいなものです。Slackから送られてきた質問を request で受け取ります。 request はただの文字列の想定なので、テキストとして読み込んで question 変数に代入してます。 ベクターDBへのクエリ # GCSからベクターDBをダウンロード storage_client = storage.Client() bucket = storage_client.bucket("test_vecdb_for_langchain") blob = bucket.blob("index.faiss") blob.download_to_filename("/tmp/index.faiss") blob = bucket.blob("index.pkl") blob.download_to_filename("/tmp/index.pkl") # ベクターDBにクエリ vectorstore = FAISS.load_local("/tmp/", embeddings=OpenAIEmbeddings()) docs = vectorstore.similarity_search(question, k=3) input_documents = str() for d in docs: input_documents += "input_documents: {}\n".format(d.page_content.replace('\n', '')) まずベクターDBであるFAISSをGoogle Cloud Storageからダウンロードして、ローカル上に保存します。今回はGCFs上の一時ファイル置き場として使える /tmp ディレクトリ上に保存しています。ダウンロードするファイルは２つで、拡張子が .faiss であるものと .pkl であるものです。 次にローカル上に保存したベクターDBをメモリに読み込みます。 読み込みは FAISS.load_local(”FAISSがあるディレクトリ”, embeddings=OpenAIEmbeddings()) で行います。ここで埋め込みモデルとして、ベクターDB作成時と同じモデルを指定します。読み込んだベクターDBに対してのクエリは vectorstore.similarity_search(質問文) で行います。このクエリの返答としては、質問文と類似度が高い文書が複数個返ってきます。今回は k=3 で３つの文書を返すように指定しています。そして帰ってきた文書を input_documents に整形して格納します。 ChatGPTへのクエリ # 問合せに対する回答を生成 llm = ChatOpenAI(model_name="gpt-3.5-turbo-16k", temperature=0, request_timeout=60) query += input_documents query += "question: {} ".format(question).replace('\n', ' ') query += "questionに答えてください。" answer = llm([HumanMessage(content=query)]) return answer.content まずChatOpenAIをインスタンス化して変数 llm に代入しています。このインスタンスは、OpenAIのgpt-3.5-turbo-16kモデルを使用してます。引数の temperature は0~1の値を取り、1に近いほどChatGPTが生成する回答文がランダムになります。今回はテストがしやすいように、値を0にして、同じ質問文に対しては同じ回答を返すように設定してます。あとは変数 query にChatGPTに送りたい文章を入れていきます。ここでは、ベクターDBが返した文章と、Slackから送られた質問文を整形して入れています。 そして、 answer = llm([HumanMessage(content=query)]) で実際にChatGPTと会話を行います。ChatGPTの回答はanswer.contentに入っているので、これをSlackにそのまま返しています。 動作例 以下の画像が実際にSlack経由で実装した問合せシステムに質問した結果になります。試しに弊社の資格取得支援制度について質問したところ、社内情報に特化して、かつ自然な感じで回答してくれます。また「制度の申請方法を教えて」など質問する内容を詳細に絞ってあげると、それに対応して制度の細かい部分まで答えてくれます。 問合せシステムに社内制度について質問した結果 社内制度の詳細について質問した結果 まとめ LangChainを使うことで、ベクターDB+ChatGPTと連携してAIアプリが簡単に作成できました。今回は使用しなかったのですが、LangChainのChainという機能を使うことで、さらに簡潔に、かつデバッグがしやすくなるらしいです。以降はそのあたりも勉強しようかと思います。 The post LangChain+ChatGPT+VectorDBで問合せbotを賢くした話 first appeared on Sqripts .