ハイブリッド開催でのユーザーストーリーマッピングワークショップ(JaSST'23 Tohokuワークショップ作成/運営話)
はじめに
2023/5/26(金)にJaSST'23 Tohokuがオンサイト(仙台市戦災復興記念館)/オンラインのハイブリッド開催されました。
この会のワーク担当として活動していたので、ワークショップの作成/運用話をまとめます。
同じようなワークショップをやりたい人の参考になれば幸いです。
ワークショップ概要
テーマ
JaSST'23 Tohokuのテーマは「アジャイルとテストと私たち ~明日『アジャイル』と言われたときに困らないためのヒント~」であり、アジャイル開発の普及により重要性が高まっているアジャイルテストを扱いました。
川口さんによる「アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発」の基調講演*1からはじまり、長田さん、大平さん、半谷さん中村さんのそれぞれの実践的なアジャイルテスティングの事例紹介、スポンサー各社のLTなどボリュームのある構成となりました。
また、参加者に手を動かしてもらうために、実行委員コンテンツとして「ユーザーストーリーマッピング」を扱ったワークショップを実施しました。
テストを直接扱うワークではありませんでしたが、アジリティ(機敏性)の高いテストを行う上でテスト重要性の判断基準となる「ユーザー視点」を学ぶことは役に立つ、と考えてユーザーストーリーマッピングを選定しています。
この記事は、そのワークショップを主題として扱います。
ワーク内容
ワークは以下の2段構成になっています。3-5人程度のチームを組んで実施いただきました。
- 「朝起きてから家をでるまで」を考えよう
- 「乗換案内システム」で顧客への価値を考えよう
「朝起きてから家をでるまで」を考えよう
参加者が朝起きてから家をでるまで*2を付箋に書き出していただき、チームで共有いただきます。その後、「寝坊して5分で家を出なければならない場合に何をやるか」を検討いただきました。アジャイル開発を行う上で重要なMVP*3の考えを実感していただくことが目的となります。
「乗換案内システム」で顧客への価値を考えよう
「乗換案内システム」を開発するために、ストーリーカード*4をもとにリリースに必要な機能を選定してもらいました。ストーリーカードや機能カードはあらかじめ用意されたものを使い、2回分リリースを疑似体験してもらうワークを実施いただきました。ユーザー視点を意識してMVPを考える感覚を体験いただくことが目的となります。
工夫したこと
JaSST'23 Tohokuはハイブリッド開催のため、ユーザーを以下の3属性に分けてワークショップを作成しました。それぞれの属性についての工夫をまとめます。
- オンサイト参加者
- オンラインワーク参加者
- オンラインワーク非参加者(視聴者)
オンサイト参加者
オンサイト参加者には一般参加者全員にご参加いただきました。ワークショップが本会の後半であり疲れていたと思いますが、みなさん積極的に取り組んでいただき有難い限りです。
一般的なペンと付箋のほか、時系列を表す線を引くためのロールタイプの付箋、機能カードやストーリーカードを印刷したもの*5を用意しています。
会場には多くの実行委員がいて参加者とのコミュニケーションも取りやすいため、今回の中では一番トラブルには対処しやすい運営スタイルでした。
オンラインワーク参加者
オンライン参加者にはMiroとDiscordボイスチャットでワークを実施いただきました。ワークへの参加は昼休み明けまでに参加者を募り、実行委員で3-5人のチーム分けを行いました。チーム用のワークスペースはあらかじめMiro+Discordに作成しており、割り振ったチーム番号のワークスペースに移動してもらうようにしています。
Miroでは以下の画像のようなワークスペースをチーム分用意しました。また、参加者はチームごとにDiscordのボイスチャンネルに入っていただき、チーム同士の会話を実施いただきました。ZoomのWebinarではブレイクアウトルームが使えないため、Discordのボイスチャンネルで個別ワークを実施いただくように対応しています。
また、オンラインでは人数がかなり多くなることが想定されていました*6。そのため、ワーク初めの説明では、オンライン参加者向けの説明を厚めに実施しています。説明を含む資料はワーク実施前に参加者に展開して、資料を見ながらワークができるようにしました。また、ワーク実施中はZoomから抜けてワーク実施後にZoomに戻ってもらうことがあるため、できる限りワークタスクのまとまりを大きくして切り替えが少なくなるようにしています。
オンラインワーク非参加者(視聴者)
オンライン参加者の中には、ワーク時間をすべて参加できない方*7がどうしても出てきます。特にJaSST東北のワークショップは1日のうちの一部でしかないので、ワークショップに参加できない方にも学べる内容を用意する必要がありました。
そのため、JaSST'23 Tohokuでは、オンラインのワーク実施風景を、実施者の音声込みでWebinarに配信させていただきました。対象となるチームは、あらかじめオンライン参加者の数名にお声がけして許可を頂いています。
運営配信側では、大きく以下の2つを実施しています。視聴者でもワーク参加者と同じ状況を共有できるので、ワークを疑似体験して学びが深くなることを期待しています。
- Miroの画面を配信に共有する。Miroの機能で、ワーク参加者の1名のマウスカーソルの動きを追従することができます。ワーク参加者の実際の動きを視聴者が追体験することができます。
- Discordのボイスチャンネルに入り、音声を配信に共有する。Zoomの画面共有時に「サウンドの共有」にチェックを入れることで、Discordボイスチャンネルでのワーク参加者同士の会話をZoomに共有することができます。運営PC上で鳴った音声は全て配信に載ってしまうため、Zoomの通知などを事前に切っておくなどの準備が必要です。
JaSST'21 Tohokuでも、今回のようにワーク参加者の実施状況を配信しました。その経験を活かした工夫です。
もっと工夫すべきだったこと
「オンラインワーク非参加者(視聴者)」向けにZoom Webinar上でワーク実施風景を共有しています。そのため、「オンラインワーク参加者」からワーク実施中にWebinarを切断しなければならず、ワーク実施後のWebinar再接続大変である旨の指摘をいただきました。
Zoom(Webinar)には現時点でスピーカーミュート*8機能が存在しません。そのため、オンラインワーク参加者はWebinarの音声を遮断するために、Zoomを切断する必要がありました。
例えば、Windows10にある「音声ミキサー」機能を使えば、アプリケーションレベルで音声操作を行うことができます。しかし、環境依存性があり、すべてのオンラインワーク参加者に実施いただくのは難しいため、Webinarの切断、再接続で対応いただくようお願いしています。
今後はツールの選定、調査などでオンラインワーク参加者の負担が減るように検討したいと思います。
おわりに
JaSST'23 Tohokuでは、いろいろな参加者の学びが深まるにはどうすれば良いかを考えて、準備をしてきました。
JaSST'23 Tohokuの参加者が「学んだ内容を活かしたい」と少しでも思っていただければ幸いです。
バグの少ないプログラミングの考え方の例
わたしがプログラミングをするときに、バグが少なくなるように意識していることを整理して書き出します。内容の正確さを保障できませんので予めご了承ください。
形式手法
形式手法とは数学や論理学に基づいたソフトウェア開発・検証手法を指します。プログラムと証明には対応関係があること*1が知られています。そのため、仕様を数学的に記述できれば*2、プログラムがその仕様を満たすかを検証できます。
ただし、以下の理由から数学的に仕様を記述することが最適でないケースが多いと考えれます。
- 仕様を数学的に記述することが難しい。
- 多くの分野では最適な仕様が定まらない。フィードバックにより仕様を変更していくことが主流。
大きなシステムで仕様を数学的に記述することは容易ではありませんが、数学や論理学の考え方をプログラミングに活かすことでバグを出にくい開発が可能です。
関数型プログラミング
CやJavaはプログラミングパラダイム*3としては命令型プログラミングに属します。また、数理論理学的な性質を表現するプログラムパラダイムとして、宣言的プログラミングがあります。宣言的プログラミングの中でも実用的なものとして、数学上の関数を主軸にプログラミングを記述する関数型プログラミングがあります。
関数型プログラミングの特徴として参照等価性が挙げられます。参照等価性は「式をその式の値に置き換えてもプログラムの振る舞いが変わらないこと」を指します。これは関数に副作用*4がないことを意味します。
関数型プログラミングの利点
以下が挙げられます。
- プログラムが理解しやすくなる
- 余分な状態が現れにくくなる
- タイミングの問題が起きにくくなる
プログラムが理解しやすくなる
副作用のない関数を多く書こうとすると、副作用が必要な/不要な箇所が明瞭になります。そのため、プログラムの構造がシンプルになりやすいです。
余分な状態が現れにくくなる
副作用のない関数が多くなると、関数の入出力以外の状態を操作する状況が少なくなります。そのため、状態を保持しなくても表現できる箇所が増える傾向にあります。
タイミングの問題が起きにくくなる
数学的な関数は、その関数が評価されるタイミングに依らず成り立つ性質を表します。タイミングの制御は複雑であり、命令型プログラミングではあるタイミングでうまく行っても違うタイミングでは意図しない挙動になることが多くあります。関数型プログラミングでは状態に依存しない(副作用のない)関数を扱うため、タイミングで挙動が変わるプログラムが書きにくくなります。
関数型と命令型の使いどころ
関数型プログラミングの利点は多くありますが、現実的に多く使われているプログラミングパラダイムは命令型プログラミングです。これは私たちが扱うコンピュータが命令的に(状態を変化させながら)動作しているからです。関数型プログラミング言語で書かれたプログラムも、コンパイラによって(命令的な)機械語に変換してコンピュータを制御します。
個人的所感として、関数型(宣言型)プログラミングは「人間が理解しやすい」、命令型プログラミングは「コンピュータが理解しやすい」ことが挙げられます。命令型プログラミング言語でも(言語のサポートはありませんが)副作用のない関数でプログラムを構築できます。そのため、わたしは命令型プログラミング言語を扱う場合でも関数型プログラミングをできる限り行います。可能な限り関数型プログラミングを行い、命令的に書かなければならないところだけを命令的に書くように意識しています。
命令型プログラミングが適している状況
命令型プログラミングの方が関数型プログラミングよりも適している状況を以下に挙げます。
- 状態を管理する必要がある
- 最適化の必要がある
状態を管理する必要がある
サーバーアプリケーションやGUIアプリケーションのように、動作を続けて外部との通信を行うプログラムは状態を管理する必要があります。
最適化の必要がある
実行速度やメモリ効率の性能向上は状態制御を最適化することで実現できることが多いです。
関数型プログラミングの設計
プログラミングの設計表現としてUML*5が最も使われています。しかし、UMLは状態制御やタイミングの設計が主であり、命令型プログラミングに沿った設計表現だとわたしは考えています。
関数型プログラミングの設計表現の提案
関数型プログラミングに適した設計表現としてわたしの理解では以下の2つが挙げられます。
- 型システムを用いた設計
- データフロー設計
型システムを用いた設計
例えば、純粋関数型プログラミング言語のHaskellでは、実装をundefinedとすることで、型検査のみを実行することができます。強力な型システムのサポートが得られる状態で型の設計ができます。
そのため、他の言語でもHaskellを持ちいて型の設計を行うことは有用に思います。しかし、図的表現ができないため、直観的理解が得られにくいと考えられます。
func_a :: Int -> Int func_a = undefined func_b :: Int -> Int func_b = undefined func_c :: Int -> Int -> Int func_c = undefined func :: Int -> Int -> Int func x y = let a = func_a x in let b = func_b y in func_c a b
データフロー設計
データと副作用のない関数を矢印で結んだデータフロー図を設計表現としてわたしは用いています。例えば図のような表現ができ、func_aとfunc_bは並列に処理できることが分かります。直観的理解を得やすい利点がありますが、以下のような課題があります。
- 関数を引数に取る関数を表現できない
- mapのような複数のデータ群に対して関数を適用することをうまく表現できない
プログラミング技術
プログラミングの設計技術をいくつか紹介します。
アクターモデル
並行/分散計算の数学的モデルのひとつです。メッセージパッシングの基本となる考え方といえます。他アクターの情報を把握する手段をメッセージを介してのみにすることで、データ競合の発生を防ぐことができます。
リアクティブプログラミング
データの変化に反応して、処理を実行する技術です。オブザーバーパターンを使って実装することが多いです。命令型プログラミングと関数型(宣言型)プログラミングとの切り替え点として利用するのが有用です。オブザーバーをデータストリームとみなすことができます。
契約プログラミング
処理の前処理/後処理に対する考え方です。処理を実装するときに毎回バリデーションを実装する防御的プログラミングの課題として、過剰な実装が必要になることが挙げられます。契約プログラミングでは処理に事前条件と事後条件、不変条件を定めて呼び出す側で条件に見合うようにすることで、処理の保証範囲を明瞭にします。契約プログラミング(契約による設計)はカジュアルなホーア論理とも呼ばれています。
ホーア論理は命令型プログラミングにおける形式論理の言語であるため、関数型(宣言型)プログラミングでは契約プログラミングとは異なるアプローチを取る方が適切だと考えています。例えば、副作用のない関数であれば、関数側ではなくデータ側に制約を持たせる方が自然に思えます。*6
おわりに
キーワード程度の提示しかできませんでしたが、使用するプログラミング言語が命令型だったとしても、宣言的な考えを用いることがバグを抑えることに繋がると考えています。
軽量ハイブリッド(オンサイト&オンライン)ワークショップの配信事情(2022/9/10 アジャイル札幌「チーム全体でテストの知を積み上げる-やってみようVSTeP-」)
はじめに
JaSST東北のメンバーとして、アジャイル札幌の「チーム全体でテストの知を積み上げる-やってみようVSTeP-」というイベントでVSTePのワークショップを行いました。ハッシュタグは #agilesapporo です。
VSTePは「Viewpoint-based Test Engineering Process」の略称であり、直訳すると「テスト観点に基づくテスト開発プロセス」になります。VSTePについて詳しく知りたい場合はこちらをご覧ください。
http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf
今回のイベントはハイブリッド(オンサイト&オンライン)開催でのワークショップでした。オンサイト会場にいながら、オンライン参加の方々にも可能な限り良い体験をしてもらうために用意しました。課題はあれど、それなりの形にはなったのでまとめておきます。
オンラインでのVSTePワークショップ
JaSST'16 Tohokuは「テスト開発しちゃいなよ!~テスト設計との違い~」というテーマで、VSTePのワークショップを行いました。オンサイト開催であり、4-5名で1グループを作り机を囲んで付箋にテスト観点を書き出していました。
今回はオンライン開催もあったため、同様の講義配信やワークショップをオンラインでも実現できる必要がありました。
ハイブリッド開催でのワークショップのためのアプリ
以下のアプリを使って実現しました。
- Zoom
Webビデオ会議ツール。複数の部屋を作って参加者を振り分けて会議をする機能*1があるので、グループごとに部屋を分けてワーク中の会話をしてもらいました。
- Mural https://www.mural.co/
Webホワイトボードツールであり、主に付箋の書き出し機能を使います。普段はMiro*2を使いますが、やんごとなき理由*3によりMuralを使ったところ、思ったより使い勝手が良かったです。
- Discord
参加者間コミュニケーションに利用しました*4。聴講中などは疑問点なども多く上げていただきました。
参加者への資料共有に使いました。
ハイブリッド開催での運営モード
ハイブリッド開催するにあたり、いくつかの運営モードを切り替えて実施しています。
- 講義モード
講師の講演をオンサイト&オンラインに伝えるモード。オンサイトには会場のディスプレイに講義に資料を出力します。オンラインには講義資料をZoomの画面共有で流したり、発表中の講師の様子をビデオで流します。
- ワークのぞき見モード
オンサイトにいるスタッフがオンラインのワークグループの支援をするモード。オンサイトの方々の注意を逸らさないようにするために、ヘッドセットをつけてノートPCでオンラインのワークグループの部屋に参加します。
- ディスカッションモード
講師と参加者が議論をするスタイル。ワークの成果物に対して実施したため、Mural画面をZoomで画面共有して実施しました。オンサイトではマイクとスピーカーでオンライン上の方々と議論できる用意をしました。
ハイブリッド開催での配信機材
今回の配信で使用した機材を紹介します。
- ノートPC
Zoom配信&Mural作業用。
Discord&Twitter(ハッシュタグ追跡)用。2画面分割表示機能を初めて有効に使った気がします。
- 大型ディスプレイ(会場備品)
映像出力用はもちろん、オンラインの会話をオンサイト会場に流すためのスピーカーとしても使用しました。
オンサイトの講演者や会場の様子をオンラインに流すために使用。少しでもライブ感を共有してもらう目的です。
- ワイヤレスマイク
新調品。講義モードやディスカッションモードで活躍しました。大きい会場だと音響設備が揃っていますが、会議室でオンラインへも配信する場合はこういったワイヤレスマイクでそれっぽく配信できました。
- レーザーポインタ
新調品。講義モードにおけるスライドのページ送りに使用しました。会議室で使われている大型ディスプレイに対しては、レーザーポイントは機能しなかった*5。単なるレーザーポイントだとオンラインには指し先が伝わらないので、別案を用意したい。
- ワイヤレスイヤホン(or ヘッドセット)
ワークのぞき見モードで使用。オンラインのワークグループ部屋に参加した際に、オンサイトへの影響少なく会話に参加するために使っています。他のスタッフはヘッドセットを用意していましたが、わたしはワイヤレスマイク&ワイヤレスイヤホンで対応*6。
おわりに
ハイブリッド開催のワークショップ開催の知見はまだまだ課題が多いので、いろいろ試してみたいです。
参加してくださった皆さん、スタッフ&講師の方もありがとうございました。
*3:定期大規模メンテナンスがワーク時間に直撃しました。https://twitter.com/aslead_miro/status/1565258864211423232
*5:レーザーポイントの光がディスプレイに吸収されるため
*6:荷物を減らすため
軽量ハイブリッド(オンサイト&オンライン)ワークショップの配信事情(2022/9/10 アジャイル札幌「チーム全体でテストの知を積み上げる-やってみようVSTeP-」)
はじめに
JaSST東北のメンバーとして、アジャイル札幌の「チーム全体でテストの知を積み上げる-やってみようVSTeP-」というイベントでVSTePのワークショップを行いました。ハッシュタグは #agilesapporo です。
VSTePは「Viewpoint-based Test Engineering Process」の略称であり、直訳すると「テスト観点に基づくテスト開発プロセス」になります。VSTePについて詳しく知りたい場合はこちらをご覧ください。
http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf
今回のイベントはハイブリッド(オンサイト&オンライン)開催でのワークショップでした。オンサイト会場にいながら、オンライン参加の方々にも可能な限り良い体験をしてもらうために用意しました。課題はあれど、それなりの形にはなったのでまとめておきます。
オンラインでのVSTePワークショップ
JaSST'16 Tohokuは「テスト開発しちゃいなよ!~テスト設計との違い~」というテーマで、VSTePのワークショップを行いました。オンサイト開催であり、4-5名で1グループを作り机を囲んで付箋にテスト観点を書き出していました。
今回はオンライン開催もあったため、同様の講義配信やワークショップをオンラインでも実現できる必要がありました。
ハイブリッド開催でのワークショップのためのアプリ
以下のアプリを使って実現しました。
- Zoom
Webビデオ会議ツール。複数の部屋を作って参加者を振り分けて会議をする機能*1があるので、グループごとに部屋を分けてワーク中の会話をしてもらいました。
- Mural https://www.mural.co/
Webホワイトボードツールであり、主に付箋の書き出し機能を使います。普段はMiro*2を使いますが、やんごとなき理由*3によりMuralを使ったところ、思ったより使い勝手が良かったです。
- Discord
参加者間コミュニケーションに利用しました*4。聴講中などは疑問点なども多く上げていただきました。
参加者への資料共有に使いました。
ハイブリッド開催での運営モード
ハイブリッド開催するにあたり、いくつかの運営モードを切り替えて実施しています。
- 講義モード
講師の講演をオンサイト&オンラインに伝えるモード。オンサイトには会場のディスプレイに講義に資料を出力します。オンラインには講義資料をZoomの画面共有で流したり、発表中の講師の様子をビデオで流します。
- ワークのぞき見モード
オンサイトにいるスタッフがオンラインのワークグループの支援をするモード。オンサイトの方々の注意を逸らさないようにするために、ヘッドセットをつけてノートPCでオンラインのワークグループの部屋に参加します。
- ディスカッションモード
講師と参加者が議論をするスタイル。ワークの成果物に対して実施したため、Mural画面をZoomで画面共有して実施しました。オンサイトではマイクとスピーカーでオンライン上の方々と議論できる用意をしました。
ハイブリッド開催での配信機材
今回の配信で使用した機材を紹介します。
- ノートPC
Zoom配信&Mural作業用。
Discord&Twitter(ハッシュタグ追跡)用。2画面分割表示機能を初めて有効に使った気がします。
- 大型ディスプレイ(会場備品)
映像出力用はもちろん、オンラインの会話をオンサイト会場に流すためのスピーカーとしても使用しました。
オンサイトの講演者や会場の様子をオンラインに流すために使用。少しでもライブ感を共有してもらう目的です。
- ワイヤレスマイク
新調品。講義モードやディスカッションモードで活躍しました。大きい会場だと音響設備が揃っていますが、会議室でオンラインへも配信する場合はこういったワイヤレスマイクでそれっぽく配信できました。
- レーザーポインタ
新調品。講義モードにおけるスライドのページ送りに使用しました。会議室で使われている大型ディスプレイに対しては、レーザーポイントは機能しなかった*5。単なるレーザーポイントだとオンラインには指し先が伝わらないので、別案を用意したい。
- ワイヤレスイヤホン(or ヘッドセット)
ワークのぞき見モードで使用。オンラインのワークグループ部屋に参加した際に、オンサイトへの影響少なく会話に参加するために使っています。他のスタッフはヘッドセットを用意していましたが、わたしはワイヤレスマイク&ワイヤレスイヤホンで対応*6。
おわりに
ハイブリッド開催のワークショップ開催の知見はまだまだ課題が多いので、いろいろ試してみたいです。
参加してくださった皆さん、スタッフ&講師の方もありがとうございました。
*3:定期大規模メンテナンスがワーク時間に直撃しました。https://twitter.com/aslead_miro/status/1565258864211423232
*5:レーザーポイントの光がディスプレイに吸収されるため
*6:荷物を減らすため
テスト自動化導入をゲームブック形式で学べるワークショップ~JaSST'22 Tohokuワークショップ作成/運営話 後編~
はじめに
2022/5/27(金)にJaSST'22 Tohokuがオンサイト(いわて県民情報交流センター)/オンラインのハイブリッド開催されました。
この会のワーク担当として活動していたので、ワークショップの作成/運用話をまとめます。こちらは後編になります。
前編はこちら。
toshimana.hatenablog.com
内容は以下となります。
【前編】ワークショップ概要
【前編】何でゲームブック形式のワークショップを作ることになったのか
【前編】ワークショップ設計プロセス
【後編】ワークショップで使用したツール
【後編】ワークショップ運営の工夫
【後編】ワークショップ後日談
【後編】おわりに
【後編】おまけ
ワークショップで使用したツール
今回のワークショップで主に使用したツールは以下になります。
- PowerPoint:プレゼン資料作成(ページリンク)
- Discord&Quick Poll:投票機能
- voicepeak:音声作成
PowerPoint
みんな大好き、Windows OSでのプレゼンテーション資料作成のデファクトスタンダード。
ゲームブックだと「○○ページへ移動する」という形式が多いですが、ワークショップで同じように実施するには操作が煩雑になります。そのため、今回はPowerPointのリンク機能を使用して、リンクをクリックすることでページが遷移できるようにしています。ワークショップ中には解説で問題といったりきたりしたり操作ミスが発生したりするので、ジャンプ元とジャンプ先は相互移動できるようなリンク実装を意識していました。
Discord&Quick Poll
オンサイトとオンラインのハイブリッド開催であるJaSST'22 Tohokuでは実行委員や発表者、参加者間のコミュニケーションツールとしてDiscordを使用しています。いろいろな使い方をしていますが、ここではワークショップの利用に絞って説明します。
ワークショップの要として参加者による選択肢の投票があります。Discordに投票機能を持つbotアプリを導入することで実現しています。いくつかある筈ですが、今回は高機能アンケートbotであるQuick Pollを使用しています。
Quick Pollを利用することで、Discordのリアクションを使って投票を行うことができます。Discordの場合は既存のリアクションがある場合、他の人がそのリアクションアイコンをクリックするだけでリアクションを行うことができます。Quick Pollは選択肢のリアクションアイコンを用意してくれるので、参加者は自分が選んだ選択肢に対応したリアクションアイコンをクリックするだけで投票できるようになります。また、Quick Pollは排他投票(最大どれか1つにしか投票できない)の機能があるため、すべての選択肢を選ぶことを抑制できます。
また、Quick Pollでは投票をある時点で集計することができます。ワークショップでは進行のタイミングで投票数を確定させたいため、集計機能によって投票数を確定させました。投票数や割合も表示することができます。
余談ですが、Quick Pollは選択肢番号がデフォルトでA, B, C, ... だったため、プレゼン資料上での選択肢番号もA, B, C, ... に合わせています。
voicepeak
商用利用も可能な入力文字読み上げソフト*1です。シナリオを読み上げるために使用しています。今回の切り札。
本ソフトは「最新のAI音声合成技術を搭載し手軽に読み上げさせることが可能な」ことを特徴として挙げており、テキストをそのまま渡すだけで自然な音声で読み上げてくれます*2。ワークショップ中で実行委員がシナリオを読み上げる負担の軽減に役に立ちました。また、ナレーターとして6種類の音声*3が使えるため、シナリオのキャラクターごとに音声の使い分けも行うことができました。音声出力形式は.wav or .flacになり、出力した音声ファイルをPowerPointでプレゼン資料に埋め込んでいます。
本ソフトのライセンスは1つしか購入していないので、音声ファイルの作成担当者が一人に限定されるのは事前想定が甘かったところです。また、音声ファイルのデバッグは聞かないと分からないため、大変でした。
ワークショップを開始した直後はソフトによる音声に驚きがありましたが、終わるころには特に音声についての苦情などはありませんでした。それだけ自然な読み上げができていたんだと思います。
ワークショップ運営の工夫
ワークショップ運営の工夫として準備したことを挙げます。
問題の選択は知識の正否ではなく、行動の決定とする
「【前編】ワークショップ設計プロセス」にも記載をしていますが、選択肢は「どういう行動をとるか」ものとしています。
今回は折角のシナリオ形式になるため、参加者は主人公の体験を疑似的になぞる形になります。その利点を活かして、選択肢は「どういう行動をとるか」を意識して設計しています。知識は学んで身につけることはできますが、知識は行動に移さなければ発揮されないものだと思います。そのため、本ワークショップでは「正しい知識に沿って正解を選ぶ」ではなく「知識を使って行動を選ぶ」形式にした、という狙いがあります。
今回は上手くいったかは分かりませんが、ゲームブック形式のワークショップが「行動選択を疑似体験できるもの」として成立しているのであれば、真剣に掘り下げる価値のあるワークショップスタイルだと言えそうです。
正解の選択肢に技術的な根拠を用意する
こちらも「【前編】ワークショップ設計プロセス」にも記載をしていますが、テスト自動化に関する技術があれば正解の選択肢を選べるようにしています。
ゲームブックという形式をとっていますが、あくまでテスト自動化導入を学ぶためのワークショップとして作成しています。正しい知識を身につければ正解が選べるし、誤った選択肢を選んだ場合は知識を身につける機会になればいいなぁ、という期待を持って設計しています。そのため、簡単ですが各問題に正しい選択肢を選ぶための解説を用意しています。
ゲームとしてみた場合には、技術的に正しい選択肢を取ったのに、理不尽にBAD ENDに向かうようなケースもあるかとは思います*4。しかし、「状況を良くするためには正しい知識が必要である」ようにあってほしいと思っているので、今回は知識があれば正解の選択肢を選べるようにしています。本ワークショップで「正しい知識があっても無くても失敗するなら、正しい知識は不要である」とは思ってほしくなかった、というところもありました。
読み上げソフトによる音声や投票機能をワークショップでいきなり実施しない
本ワークショップでは読み上げソフトによる音声や投票機能など、参加者が普段使い慣れないものを使用しています。そのため、ワークショップ開始時点でそれらに初めて触れると、新しいことに気が散ってしまって問題に集中できない懸念がありました。
そのため、JaSST'22 Tohokuでは実行委員長による会のオープニング(アイスブレイク)で、読み上げソフトによる音声や投票機能を使用してもらいました。参加者にはワークショップより前に使い慣れない要素に触れてもらうことで、本番であるワークショップに集中してもらいやすくなるように設計しています。
ワークショップ後日談
ワークショップが終わった後の後日談的内容です。
雑談チャンネルが凄く盛り上がった
Discordにはチャンネルをいくつも作ることができて、JaSST'22 Tohokuでは「雑談」「ワークショップ」「質問」「アンケート」など用途に合わせてチャンネルを用意していました。ワークショップでは投票を行う「ワークショップ」チャンネルを中心に扱っていましたが、投票外の時間で参加者のみなさんが「雑談」チャンネルで活発な意見を述べてくれたのがとても嬉しかったです。「これはあるあるだよね」「こんな選択肢もあるんじゃない」みたいな技術的な内容に切り込んだものから「バッドエンドに持っていきたい」「背景の立ち絵は誰なんだ」みたいなゲームブックとしての楽しみに関するものまで入り乱れて様々な書き込みをしていただきました。嬉しい誤算です*5。
ワークショップ中は前で発表していて「雑談」チャンネルを見る余裕がなかったので、終わってから「雑談」チャンネルを見て一安心しました*6。
シナリオ消化率
JaSST'22 Tohokuのワークショップでは用意した4シナリオ中2シナリオを実施しました。2シナリオはいずれもすべて正解選択肢を選ばれたため、ストレートにシナリオを消化しました。終わった後に、1つの分岐の失敗選択肢(BAD END)も試してみるようなこともやっています。
スライド消化率/シナリオ消化率は25.5%でした。50ページ/196ページになります。資料は公開予定なので、公開されたら是非残りのシナリオも見てみてください。
おわりに
ゲームブック形式がどのように受け入れられるか分からない状況で進めていましたが多くの人に受け入れられたので、改めてやって良かったと感じています。実行委員として多くの人に学びがあるように準備してきたものが、遊べるに足る形で披露できたので個人的にも満足度が高いワークショップになりました。
テスト自動化導入をゲームブック形式で学べるワークショップ~JaSST'22 Tohokuワークショップ作成/運営話 前編~
はじめに
2022/5/27(金)にJaSST'22 Tohokuがオンサイト(いわて県民情報交流センター)/オンラインのハイブリッド開催されました。
この会のワーク担当として活動していたので、ワークショップの作成/運用話をまとめます。
同じようなワークショップをやりたい人の参考になれば幸いです。
www.jasst.jp
ツイートのまとめ記事もあります。
togetter.com
今回は前後編の前編です。内容は以下となります。
- 【前編】ワークショップ概要
- 【前編】何でゲームブック形式のワークショップを作ることになったのか
- 【前編】ワークショップ設計プロセス
- 【後編】ワークショップで使用したツール
- 【後編】ワークショップ運営の工夫
- 【後編】ワークショップ後日談
ワークショップ概要
JaSST'22 Tohokuのワークショップは「あなたの1票が未来を決める、参加者投票式マルチエンディングストーリーなワークを行います。テスト自動化にまつわるストーリーを体験する、ゲームブック形式のセッション*1」です。
「なんだそれは?」となりますが、「ストーリー形式で話が進み」「途中で選択肢が用意され」「選んだ選択によってその後のストーリーが変わる」形式のワークショップになります。同様の形式として、ゲームブック*2があることから、ゲームブック形式と呼んでいます。実際は有名ノベルゲームを模した作りとなっていますが…
ストーリーや選択肢はテスト自動化導入に沿ったものを用意しました。参加者の選択肢への回答はDiscordと投票botアプリを用いた投票によって行いました。
みんなで楽しむ「かまいたちの夜風」テスト自動化ワークショップ#jassttohoku pic.twitter.com/FlHjx5ye98
— ネモトノリユキ@ソフトウェアテスト技法練習帳 発売中!! (@nemorine) 2022年5月27日
何でゲームブック形式のワークショップを作ることになったのか
ざっくり、以下のような流れで決まりました。
前提
- JaSST東北では毎回、実行委員企画による参加者が手を動かす/頭を使うワークショップの時間を用意している。
- JaSST'22 Tohokuはオンサイト/オンライン開催を想定している。
決まるまでの流れ
- オンサイトだと全員参加のワークショップができるけど、オンライン参加だと途中で抜けなければならない人がいるはず。グループワークのような参加し続ける必要のあるものは参加しにくくなる。
- Discordでアンケートを取ることができる。アンケート投票機能を使って問題の回答を投票してもらえるようにすれば、参加しやすいし、聞いている人も負担にならなそう。
- ストーリー形式にして、投票で選んだ選択肢によってストーリーが変わると面白いかも!
- 実行委員長「選んだ選択肢でストーリーが変わるって、どんなイメージ?」
- 実行委員「『かまい〇ちの夜』みたいな感じ」
- 知らない実行委員長にWebで「〇まいたちの夜」の情報を見せる
- 実行委員長「じゃあ、今年のワークは『か〇いたちの夜』で!」
…だいたい合っているはずです。
さすがに『かま〇たちの夜』の名称をそのまま出すわけには行かないので、近い形式である「ゲームブック」形式として呼称することになりました。*3
ゲームブック形式でのテスト技術者育成の先駆者
JaSST'19 Hokkaidoにて、探索的テストの技術向上にゲームブック形式の演習を取り入れていた事例紹介があることを教えていただきました。ありがとうございます!
ゲームブックは、ここで取り入れた人がいたりします。 #jassttohokuhttps://t.co/7mGx0e4AmI
— 町田欣史 (@machidays) 2022年5月27日
ワークショップ設計プロセス
ワークショップをどのような流れで作成したかを説明します。ワークショップが90分は初期から決まっていましたが、どのくらいのボリュームがあれば90分になるのかの見通しがありませんでした。そのため、5分岐×5シナリオを目安に作成を開始しました。最終的には5分岐×4シナリオになっています。*4
初期に想定していたこと
- ワークの問題は正解/誤りの判断根拠を明確にする。根拠が無いと参加者が理解を深めることができない。
- ワークの分岐文章は行動を決めるものにする。知識の正否を問うものではない。身につけて欲しいのは知識の先にある行動の決断。
- ワークのストーリー文章は主観(一人称)で書く。自動テスト導入の流れを疑似体験できるように。
プロセス
- 対象領域(ターゲット)を決める
- 問題の元となる技術文書とその項目を集める
- 分岐選択肢をつくる
- 正解概要シナリオをつくる
- 失敗分岐概要シナリオをつくる
- シナリオを元に資料に起こす
- 資料にリンクを貼る
- 資料に音声を付ける
1. 対象領域(ターゲット)を決める
シナリオがどのような属性をターゲットにするのかの候補を洗い出しました。この属性だと、こんな技術要素が出てきそうだ、というの洗い出しています。
2. 問題の元となる技術文書とその項目を集める
いくつか参考となる技術文書をワーク担当者で読み、問題として使えそうな項目の洗い出しを行いました。どんな形で使うかはこの時点では分からなかったので「問題として使えそう」なものを広く集めています。
3. 分岐選択肢をつくる
対象領域に対して5分岐分の問題を作りました。この時点ではシナリオまでは考えていないので「使うならこんな感じかな」という感覚で出しています。
4. 正解概要シナリオをつくる
分岐選択肢がすべて正解した場合を想定した概要シナリオを作成します。実際にシナリオを付けてみると、用意した問題が使いにくいことが分かったりして、この段階で問題の再検討が良く起きました。
5. 失敗分岐概要シナリオをつくる
用意した正解概要シナリオを元に、失敗分岐用の概要シナリオを用意します。失敗分岐の管理を複雑にすると作業難易度が大きく上がることから、基本的に1つ失敗したら終了にする方針としています。そのため、マインドマップなどの木構造でシナリオが管理できています。
6. シナリオを元に資料に起こす
作成した概要シナリオを元にプレゼン用の資料を作りました。この段階になるとページ割を意識しながらシナリオを作成することになります。シナリオはここで本番と同様のものが出来上がります。また、この段階で問題ごとに1ページの解説を作っています。
7. 資料にリンクを貼る
資料の分岐に対して、選択による遷移先の資料内リンクを貼ります。資料はPowerPointで作成しているので、その機能を使っています。
8. 資料に音声を付ける
資料の文章に合わせて、音声を用意します。ページごとの文章に音声.wavファイルを用意して資料に貼り付けています。
*1:JaSSTソフトウェアテストシンポジウム-JaSST'22 Tohoku-タイムテーブル
*2:≒ノベルゲーム
*3:実行委員内では最後まで「かまいた〇」って呼んでましたが…
*4:本番で使用したのは2シナリオです
適切な謝罪は信用獲得に繋がる
はじめに
「謝罪は好きか?」という問いに対して肯定できる人はほとんどいないと思います。謝罪は難しく、多くの人は謝罪しなくて済むのであれば良いと考えるでしょう。
「避けるべきもの」である印象が強いため、謝罪は焦点が当たりにくいテーマです。今回はそんな謝罪に焦点を当てて、謝罪がコミュニケーションにおいて重要な役割を示すツールであることを提示したいと思います。
本記事では主に仕事におけるコミュニケーションとしての謝罪を扱います。また、本記事は謝罪の考え方に焦点を当てていて、具体的な謝罪の例は扱いません。謝罪について深く学びたい場合は以下の本をオススメします*1。以下、本記事では参考書籍という記載はこの書籍を指すものとします。
謝罪に対する私見
私は謝罪は「後手必敗」だと考えています。後手必敗は"先手必勝"を元にした造語です。
後手必敗
謝罪が後手必敗だと考えているのは「(謝罪が必要な)問題を相手に先に指摘されることによって、関係悪化に繋がりやすい」からです。具体的には以下のようなことが挙げられます。
- こちらが問題を隠している、と相手にみなされる
- こちらが問題を軽視している、と相手にみなされる
- こちらに「相手に指摘されるような問題」を起こしている、という落ち度がある
謝罪が後手に回ることで関係は悪化しやすくなり、悪化した関係を正常に戻すことは困難です。そのことから、謝罪が後手に回ることは、物事を進める難易度を必敗といえるほど難しくするものだと考えています。
先手必勝?
では、謝罪は「先手必勝」なのか、というと必ずしもそうではないと考えます。謝罪を受け入れるかを決めるのは相手であり、こちらでは制御困難だからです。
ただし、先手を取って謝罪する利点は多くあります。具体的には以下のようなことが挙げられます。
- 問題を早めに共有できることにより、対処が容易になる
- 相手の成果に対する期待値が過度に高まりすぎることを抑え、現実に近づけやすくなる
- 問題を隠すことに労力を割かないため、こちらが本来考えるべきことに注力できる
先手の利点と後手の欠点とを並べて見ると、物事を円滑に進めるには(リスクを最小限に抑えるために)謝罪は先手を取る必要がある、と私は考えています。
謝罪とは何か
デジタル大辞泉では「謝罪」は「罪や過ちをわびること」とありますが、参考書籍ではより具体的に以下のように定義しています。この定義は具体的な謝罪の方法に繋がるのですが、本記事ではその方法には言及しません。
謝罪とは、加害行為や抗議内容に対する責任を認め、直接的かつ主体的な態度で曖昧を残さずに悔悟の念を表明し、挽回の方法を提示して、繰り返さないと約束することである。
参考書籍では謝罪の効果として「傷ついた人間関係の治療」を挙げています。それに伴って、私にとって印象的だったのは以下の一文でした。
加害者のせいで傾いた関係のバランスを取り戻すという意味で、謝罪は取引だ。
謝罪は「謝罪と許しを交換する」取引だとしています。
謝罪は取引
「取引」は言葉として淡泊な印象があるかもしれませんが、私たちは日常的に多くの取引を行っています。また、取引したことで新しいことができるようになるなど、取引には転換力があります。参考書籍でも適切な謝罪には転換力があり、壊れた関係を変化させて新しい可能性が広がることが述べられています。
信用力
謝罪の取引としての性質に対して、私は金融の「信用力」との類似性を感じています。
「信用力」とは(お金を貸す側から見た時の)借金をきちんと返してくれそうかという信頼度合いを指します*2。
関係性を壊すことが「借金」、相手から許しを得ることが「返済」に相当すると思います。やりとりするものは「お金」ではなく「信頼」が該当するでしょうか。デジタル大辞泉では信頼と信用は以下のように定義されています。
- 信頼 … 信じて頼りにすること。頼りになると信じること。また、その気持ち。
- 信用 ... それまでの行為・業績などから、信頼できると判断すること。また、世間が与える、そのような評価。
信頼と信用の違いを「主観的なもの」か「実績に基づくもの」か、で表すこと*3もあります。
謝罪によって信用を得る
謝罪と信用力の類似性が見えると、望ましい謝罪の在り方も見えたような気がします。
金融における信用力を示す手段として「お金を借りて、返す」ことが挙げられます。お金を貸す側にとって、初めてお金を借りる人はちゃんと返せるかが分からないので大金を貸すのはリスクが大きいと考えます。対して、何度もお金を借りて返却している人には大きな金額を貸しても大丈夫だと考えるでしょう。
謝罪でも同様のことがいえると思います。人間関係においても「謝罪をしたことがない人」と「適切な謝罪ができる人」では後者の方が信用できる人物だと判断されやすいのではないか、と考えます。
謝罪をする機会はあるか
適切な謝罪には利点が多いといえますが、何も起きていない平時にいきなり謝罪をすることはまずありません。謝罪の定義に「加害行為や抗議内容に対する責任を認め、」とあるとおり、何かしら謝罪すべき問題が起こって初めて謝罪をする機会が生まれます。
謝罪の機会はそんなに頻繁に起こり得るでしょうか。私は起こり得ると考えています。なぜなら、人は失敗するからです。大なり小なり、人は活動をすると失敗しますし、そのなかには以下のように他者への不利益に繋がるものも含まれます。
- 会議に遅刻して、相手の時間を削った
- 情報を伝えるのが遅れて、相手の余裕を削った
- 表現が曖昧であり、相手に誤解を与えた
謝罪は必ずしも大がかりなものである必要はありません。日常的な失敗であれば、日常的な謝罪をすればいいでしょう。軽度な謝罪の機会を無視すれば相手の不満は蓄積しやすく、対して軽度な謝罪を繰り返すことは相手にとって信用を感じる機会になると思います。参考書籍で引用されていたキャロリン・ハックス*4の表現を以下に記載します。
本当に優れた人間の定義とは、完璧であることではなく、愚かなふるまいを自覚し、生んでしまった惨状の対処に最善を尽くせることなのです
おわりに
参考書籍での謝罪における特徴的な文を以下に記載します。
謝罪を最後の手段ではなく、最初の手段ととらえれば、リーダーや組織は確実に得をする。
謝罪に向き合うことで、適切な謝罪を実施できれば、これまで難しいと感じていた問題も突破口が見えてくるかもしれません。特に人間関係に悩んでいる人にこそ、謝罪について向き合ってみることをオススメします。
参考書籍には効果的な謝罪に必要な要素や謝罪の難しさに対しての言及があります。本記事では表現しきれませんでしたが、興味があれば読んでみてください。
*1:絶版本なのですが、他に謝罪を扱った本を知らないのでご存じの方がいたら教えていただけると嬉しいです。
*3:「信用」と「信頼」の意味の違いとは?使用例や類語・英語表現も | TRANS.Biz
*4:人生相談のコラムニスト