「言語化」を言語化する

はじめに

システム開発の現場では、自身の意見を伝えたり、出会った現象を伝えるために「言語化」が求められます。とくにソフトウェアテストにおいて、違和感に出会ったときの感覚を他者に伝えるために「言語化」が必要だと考えています。

ただし、「言語化」はよく使われる言葉ではありますが、その使われ方は多岐にわたるため、同じ「言語化」という言葉が、異なる範囲を指して使われることで、認識ずれが発生する場合があります。

本記事では、「言語化」の区分について考察することで、多様な言語化についてより意識的に扱えるようにしたいと考えています。

「言語化」の定義とフェーズ

辞書では、言語化は次のように説明されています。

言葉で表現すること。特に、思想や知識などを他者に説明したり共有したりするために、言葉を用いて説明すること。——『デジタル大辞泉』*1

言語化という言葉の意味は汎用的で、字面以上の意味はありません。

ソフトウェア開発の文脈では、思想や知識だけでなく、気づきを言葉で表現することも含まれる場合があります。本記事では、「感覚×論理」軸と「内部×外部」軸で以下の4象限を作成して、自身が行う言語化に対する整理を行います。この中で、「感覚×外部」は他者へ踏み込んだ行為になるため、本記事では対象外とします。ただし、この象限へ間接的に働きかける経路はあります。これは後半で扱います。

言語化の4象限

  • フェーズ1:感覚×内部:気づきの言語化:状況の整理
  • フェーズ2:論理×内部:構造の言語化:気づきの深化
  • フェーズ3:論理×外部:論理の言語化:他者への伝達
  • フェーズ4:感覚×外部(対象外)

対象とする3つの象限は、順に進むフェーズとして捉えられます。言葉にする対象はフェーズごとに異なります。フェーズ1では気づきそのものを、フェーズ2では気づきの周囲にある構造を言葉にします。フェーズ3で言葉にするのは、理解を支える筋道——論理です。内部で得た理解そのものは他者に渡せないため、論理を言葉にして渡し、受け手はそれをもとに自分の理解を組み立てます。3つのフェーズは、それぞれ着目する問いと、言語化の対象と、やり方が異なります。「言語化が大事」と言うとき、人によって指しているのは、このうちの異なるフェーズかもしれません。また、言語化する前の気づきは「何かある」という漠然とした感覚にすぎず、放っておけばそのまま消えてしまいます。消える前につかまえて言葉にすることが、すべてのフェーズの出発点です。以下、フェーズごとに順に見ていきます。

フェーズ1:状況の整理

状況の整理は、感覚×内部に位置する、気づきの言語化です。「何を感じ、そのとき何が起こっていたか」という問いに着目します。入り口は自分の感覚です。まず「気になった」という感覚そのものを言葉にし、そこから、そのとき何が起こっていたのかという状況の記述へ広げていきます。

気づきを言葉にしようとすると、「何が」「どうなっているから」気になるのかを特定する必要に迫られます。言葉は曖昧なままでは並べられないので、言語化の過程で自然と状況が整理されていきます。

逆にいえば、言葉にできないということは、まだ状況を把握しきれていないというシグナルでもあります。うまく言語化できない箇所こそ、理解が足りていない箇所です。言語化は、自分の理解度を測る物差しとしても機能します。

フェーズ1のやり方は、「自覚すること」です。何か違和感があったとき、「結果の値が少しずれている」「出力のタイミングが若干遅い」のように、できるだけ言葉で表現するよう努めます。この時点で、正しい必要はありません。「自分は何があって引っかかりを感じたのか」を自覚することが、言語化の第一歩です。

フェーズ2:気づきの深化

気づきの深化は、論理×内部に位置する、構造の言語化です。「なぜそう感じたのか」という問いに着目します。自分の感覚が何の影響を受けて生じたのかを表現するところから始まり、探索は事象の側へ広がっていきます。感覚の原因をたどることは、その感覚を生んだ事象の構造——挙動の条件、仕様のつながり、変更の履歴——をたどることでもあるからです。

言葉にした気づきは、検討の対象になります。「この表現で合っているか」「本当にそうか」「他のケースではどうか」と、言葉を足がかりに考えを進められるようになります。

漠然とした感覚のままでは、深めようにも取っかかりがありません。言語化によって気づきが固定されるからこそ、そこを起点に問いを重ねられます。最初は的外れな言葉であっても構いません。言葉にしてみて「違うな」と感じたら、その「違うな」がまた次の言語化の材料になります。言語化と検討を往復するうちに、気づきは最初の漠然とした感覚よりもずっと具体的で深いものになっていきます。

フェーズ2のやり方は、「要因に対して仮説を立てること」です。「値がずれているのは、このパラメータが現状と合っていないからではないか」「出力のタイミングが遅いのは、負荷の高い処理が並列で走っているからではないか」——論理のつながりがある仮説を置いてみます。重要なのは、事実と仮説を分けて扱うことです。仮説が誤っていたり、論理がつながらなかったりしたときは、訂正して別の要因を考えます。この訂正の繰り返しが、先ほど述べた「言語化と検討の往復」にあたります。

フェーズ3:他者への伝達

他者への伝達は、論理×外部に位置する、論理の言語化です。「どう伝わるか」という問いに着目します。フェーズ1・2が自分の中で完結するのに対し、こちらは受け手の存在を前提とします。ここで言葉にするのは、内部で得た理解そのものではなく、理解を支える筋道——論理です。

言葉になった気づきは、他の人に渡せます。当たり前のようですが、これは大きな働きです。

自分ひとりの観察には限界があります。気づきを言葉にして共有すれば、同僚の知識や経験と突き合わせることができます。「それ、こっちでも見たことがある」「その動き、この修正と関係あるかも」といった反応が返ってくれば、ひとりでは到達できなかった結論にたどり着けます。

また、伝達には副次的な働きもあります。自分の理解は、受け手に伝わる表現を探す過程で磨かれます。人に説明しようとすると、整理と深化がさらに進むのです。説明する相手がいることで、言語化の質そのものが上がります。

フェーズ3のやり方は、「受け手の知識ギャップを順番に埋めていくこと」です。説明というと、自分が体験した順——時系列——で話したくなりますが、受け手に必要なのは体験の再現ではなく、理解に足りない知識が順に埋まっていくことです。まず全体像を渡し、そこから段階的に詳細化していくようにすると、受け手が理解しやすくなります。受け手の中の「わからない」が順に解消されていく順序で話すことが、伝わる説明の骨格になります。品質保証の文脈でいえば、不具合報告がまさにこれです。「何が起きるか」という結論を最初に渡し、影響範囲、再現条件、調査の詳細へと段階的に詳細化する。自分が調べた順には書かない、が肝になります。

言語化は感覚と論理の橋渡し

ここまでの3つのフェーズを眺めると、言語化のもうひとつの働きが見えてきます。

感覚と論理は、性質の異なる能力です。感覚は速く、違和感のようなかすかな兆候を捉えられますが、そのままでは漠然としています。論理は明晰で、検討や伝達に向いていますが、言葉になったものしか扱えません。性質が異なるため、感覚が捉えたものは、そのままでは論理に接続しません。

この2つをつなげるのが言葉です。言葉は、感覚に触れる面(「ん?」、オノマトペ、比喩)と、論理に接続する面(定義、条件、命題)を併せ持っています。両方に触れられるものが仲立ちすることで、性質が異なるためにそのままでは混ざらない2つがつながります*2

感覚と論理は、どちらか一方を選ぶ能力ではなく、働きが異なる、共存すべき能力です。言語化が両者をつなぐことで、感覚が捉えたものを論理で検討し、他者に届けられるようになります。感覚と論理の接続のかたちも、言葉にする対象によって異なると考えています。定義の節で示した4象限の上に、想定する接続を表現します。

言語化の4象限

3つのフェーズは、この4象限を進む流れとして描けます。状況の整理は、感覚×内部を起点とする言語化です。「何を感じたか」を言葉にすることで、気づきは論理×内部へ運ばれます。気づきの深化は、論理×内部での言語化です。言葉を足がかりに「なぜそう感じたのか」を問い、構造をたどります。他者への伝達は、論理×外部へ向けた言語化です。受け手に伝わる表現へ磨くことで、理解が自分の外へ渡ります。

残るひとつが、定義の節で対象外としたフェーズ4——感覚×外部、他者の感覚です。他者の感覚そのものを直接作り出すことはできません。感覚は本人の中でしか生じないからです。それでも、そこへ働きかけることはできます。その経路は2つあります。

ひとつは、感覚的な表現による直接の経路です。感嘆の声、表情、勢いのある言葉——論理を介さずに感覚を伝えることは可能で、日常的な表現としてはむしろこちらが頻繁に起こります。ただしこの経路は、何がどう伝わるかを制御しにくく、受け手の解釈に大きく依存します。また、その場のコンテキストや、ボディランゲージのような言語以外の要素に支えられているため、表現はその場限りになりやすく、届く範囲は場を共有する少人数にとどまります。

もうひとつが、整理→深化→伝達と論理を経由する経路です。こちらは手間がかかるかわりに、意図した内容を保ったまま届けられます。コンテキストへの依存を言語化の過程で削ぎ落としていくため、言語のみの表現でも伝わりやすくなり、伝わりやすさが時間や状況に左右されにくくなります。その結果、少人数のコミュニケーションで機能するのはもちろん、場や時間を共有しない不特定多数——マスコミュニケーション——にまで届きます。ブログ記事はその実例です。書かれた場に居合わせていない読み手に、時間を置いて届くことを前提とした表現だからです。言葉になった気づきが受け手に渡ると、受け手の中で新たな気づきや違和感が生まれる可能性が上がります。これが、フェーズ3からフェーズ4への遷移です。自分では実行できない最後のフェーズは、受け手の中で起こります。言語化の流れは、他者の感覚へ、狙いを持って、より遠くまで働きかけるための経路なのです。

なお、この4象限は、野中郁次郎らのSECIモデル*3を想起させるかもしれません。場の共有を前提に暗黙知を直接伝える共同化は直接経路に、暗黙知を形式知へ変換する表出化は言語化そのものに、形式知が文書などを通じて広く伝わる連結化は論理経由の到達範囲に、形式知が受け手の中で暗黙知として身につく内面化は「受け手の感覚が動く」ことに、それぞれ重なります。違いは視点です。SECIモデルが組織の知識創造プロセスを説明する理論であるのに対し、本記事は個人の言語化という行為を、感覚×論理・内部×外部の状態空間の上の流れとして描いています。

言語化を鍛える

これらの言語化を鍛える機会は、業務に限りません。日常にも、言語化の機会は多く訪れます。例えば、映画やコミックをはじめとした娯楽コンテンツに触れたとき、受けた感情を言語化することでも鍛えることができます。感情も、本記事でいう「感覚」の一種です。内側で生じ、言葉になる前は「面白かった」「なんか好き」といった漠然とした状態にとどまります。

言語化を鍛える利点は、3つ挙げられます。

1つめは、気づきの感度が上がることです。「何を感じたか」を言葉にする訓練を重ねると、気づきを自覚しやすくなり、具体化しやすくなります。これはフェーズ1(感覚×内部に位置する、気づきの言語化)の訓練にあたります。

2つめは、良し悪しの判断基準が磨かれることです。これには内向きと外向きの両輪があります。内向きには、「なぜそう感じたのか」を言葉にするうちに、自分の判断基準が精緻になっていきます(フェーズ2、論理×内部)。外向きには、言葉になった基準は他者と突き合わせられるため、他者が共感できる判断基準として構築しやすくなります。

3つめは、共感してもらいやすくなることです。自分が受けた感覚や感情を表現することで、他者がそれを理解し、共感しやすくなります(フェーズ3)。共感とは、言葉が相手の感覚を動かすことにほかなりません。つまりこれは、言語化の流れを経た働きかけが、フェーズ4——感覚×外部に届いた状態です。先ほどの4象限図に共感を書き込むと、この位置づけがはっきりします。

言語化の4象限(共感を例として追記)

言語化の制限

言語化がどれほどうまくいったとしても、すべての感覚を過不足なく表現することはできません。言葉にできた部分の外側には、言葉にならなかった感覚が必ず残ります。

ただし、すべてを言語化できないことは言語化の価値を損なうものではありません。むしろ、やり方の指針になります。すべてを表現できない以上、言語化は必ず取捨選択を伴います。ならば、無自覚に零れ落ちるに任せるのではなく、自覚的に選ぶほうが自身の納得につながります。感覚の正体が掴めてきたら、言語化したい感覚、伝えたい感覚を選択して、そこに集中して整理する。全部を言葉にしようとするより、選んだものを丁寧に言葉にするほうが、期待通りの言語化は実現しやすくなります。

おわりに

「言語化」を4つのフェーズに区分してみました。システム開発の仕事では、明確な不具合になる前の、かすかな違和感に出会う場面が数多くあります。その違和感を言葉にできれば、検討できるようになり、チームに渡せるようになります。言語化を深めることは、不具合への感度を自分とチームの両方で高めることにつながると考えています。

言葉にならない「ん?」を感じたら、まず言葉にしてみる。そこから始めてみてはいかがでしょうか。

*1:「言語化」『デジタル大辞泉』(小学館)。 https://kotobank.jp/word/%E8%A8%80%E8%AA%9E%E5%8C%96-3241569

*2:マヨネーズにおける酢と油に対する卵黄(乳化剤)と同じ構造です。卵黄は、酢(水分)になじむ面と油になじむ面を併せ持つため、そのままでは混ざらない両者の仲立ちができます。

*3:野中郁次郎・竹内弘高『知識創造企業』(東洋経済新報社)。SECIモデルの概説は https://ja.wikipedia.org/wiki/SECI%E3%83%A2%E3%83%87%E3%83%AB など。

2024/6/26(水)、「人生が整うマウンティング大全」読書会に参加しました。

はじめに

「南町通りイカ研究所 デベロッパー部」の活動として開催された「人生が整うマウンティング大全」読書会に参加しました。

minamimachi.connpass.com

正直なところ、「ネタ本」だと思いワイガヤできればいいや、くらいに思っての会でしたが、やってみると事前の想定以上に役に立つ考えがあって面白かったです。マウンティング、という日常で避けて通れないネタであり参加者の体験談も豊富に出てきて、とても面白い会でした。想定よりも、人が集まって読書会するのに向いている本だと思いました。

ABD(Active Book Dialog)

読書会では、読書法としてABDを採用しました。初見だと結構驚く読書法なので、「そういう読書法もあるのか」を知ってもらうだけでも良いかと思ってABDを採用しています。ABDの詳細は割愛しますが要点は以下になります。

  • 複数人で書籍を読み、短時間で書籍の要所や各人の知見を共有する読書法
  • 紙の本を区切りごとに分けて書籍を裁断して、担当を決めて読み進める
  • 読んだ部分を要約して、参加者にプレゼンする

www.abd-abd.com

今回は、ABDを採用して、良い読書会になったと思います。

  • 1章のマウンティング図鑑だけだと、「くだらない」という感想を抱いてしまう場合がある。全体像を短時間で把握できることで、後半部分のマウンティング活用を理解して、本の評価を改めることができる
  • 読んだ内容をプレゼンするために、担当範囲の内容をまとめようと集中して読み込むことができる。
  • マウンティングというSNS時代において、誰もが触れたことがあるテーマであって、体験談や考察が捗る。
  • ABDを初めて体験した参加者から「短時間で本の理解度を深められる手法に驚いた」旨があった。

マウンティング大全

事前の書籍の想定は「マウンティングをまとめた、いわゆる"ネタ本"」と思っていたのですが、人間が持ちうる性質に向き合った学びのある書籍だと思います。書籍の後半はマウンティングがビジネスにも貢献する旨の記載があり、その内容を真面目に議論できる会になったと思います。書籍の内容が「あまり明言しないけど、日常にあるあるで存在すること」を扱っているので、普段の議論では目を背けがちな内容を改めて議論する機会になりました。

マウンティングマウンテン

副教材(?)としてマウントを扱った2分程度の動画が紹介されました。「登っても登っても、そこにあるのは孤独だけ」。

youtu.be

おわりに

内容も難しくなく、あるあるで議論しやすい、ビジネスにおける示唆が得られる、など有意義な読書会でした。

「読書会をしたいけど、真面目な本で扱える自信がない」方は、緩衝材として「マウンティング大全」で読書会を実施することを選択肢として入れるといかがでしょうか。

クラシフィケーションツリー技法ワークショップの工夫点(JaSST'24 Tohokuワークショップ作成話)

はじめに

2024/5/31(金)に仙台市戦災復興記念館がJaSST'24 Tohokuが開催されました。

jasst.jp

JaSST東北実行委員会は「同値分割法と境界値分析」と「クラシフィケーションツリー技法」のワークショップを実施しました。

わたしは「クラシフィケーションツリー技法」のワークチームに属して活動しました。ここでは、ワークショップで工夫した点をまとめたいと思います。

当日の資料はレポートページから参照してください。
jasst.jp

おやつコーナー

クラシフィケーションツリー技法の情報元

今回は国際規格「ISO/IEC/IEEE 29119-4:2021 システム及びソフトウェア工学-ソフトウェア試験-第4部:試験技法*1」でクラシフィケーションツリー技法の引用元として挙げられている論文「Classification Trees for Partition Testing*2」に基づいてワークを作成しています。

クラシフィケーションツリー技法は技法説明の資料が少なく、用語や作成手順の定義が分かりませんでした。そのため、できる限り信頼できる情報元を見つけて、それを頼りに資料を作りました。クラシフィケーションツリー技法はISO29119以外の定義(使われ方)も多いです。技法の定義にこだわるよりも、適切にテスト設計できることを優先する方が望ましいと考えます。JaSST'24 Tohokuで説明した内容とは異なるクラシフィケーションツリー技法があったとしても、柔軟に対応いただければ幸いです。

構成の工夫

クラシフィケーションツリー技法のワークショップは以下の4項目で構成しました。参加者の方々には3-4人でグループになり、ワークを実施してもらいました。普段のワークショップではあまり実施しない「作り方の説明(チュートリアル)」「練習問題2(仕様変更問題)」について詳しく説明します。

  1. 技法の説明
  2. 作り方の説明(チュートリアル
  3. 練習問題1(新規開発問題)
  4. 練習問題2(仕様変更問題)
タイムテーブル
チュートリアル

今回はクラシフィケーション技法の使い方の説明を、簡単なワークとともに実施しました。クラシフィケーションツリー技法は理解することが多く、説明を聞いただけではクラシフィケーション技法を扱えずに練習問題をうまく解けないことが予見されました。

多くの参加者にとってクラシフィケーションツリー技法は初めて学ぶ・扱う技法です。そのため、ワークショップの練習問題を解くときに以下を行う必要があります。

  • ワーク道具の使い方の把握
  • 技法ルールの理解
  • 技法を用いた情報の整理

これらを同時に考えるため、頭が処理しきれず混乱したり、うまくいかなかったときに何が問題なのかを理解できないことが起こります。これは練習問題の時間配分を増やしても解決しない問題だと捉えました。

学んだものを実務で使ってもらうために、ワークショップの練習問題では実務に近い思考をしてもらいたいです。そのため、練習問題の時間では「技法を用いた情報の整理」に参加者の思考を割いてほしいと考えています。

その解決策として、今回は練習問題の前にチュートリアルを行い、参加者が「ワーク道具の使い方の把握」や「技法ルールの理解」に注力できる時間を作りました。事前にチュートリアルを行うことで、練習問題では参加者は「技法を用いた情報の整理」に集中できるようにしました。

ステップと参加者に期待する思考の割合を以下の表に示します。

◎:特に注力してほしい 〇:注力してほしい △:できれば注力してほしくない

チュートリアル 練習問題
ワーク道具の使い方の把握
技法ルールの理解
技法を用いた情報の整理
仕様変更問題

練習問題を2種類用意していますが、1問目は出された仕様に基づいてクラシフィケーションツリー技法でテストケースを検討するもので、2問目は1問目の仕様に変更が入った場合のテストケースを検討するものとしています。

仕様変更問題1
仕様変更問題2

ワークショップで学んだ内容を参加者が自身の現場で活かすために、練習問題は現場に近い派生開発のネタを入れたい、という意見が実行委員の中*3で出ていました。多くの現場では新規開発よりも派生開発の方が多いため、練習問題も派生開発を想定したものを用意しました。

参加者の感想では、仕様変更問題のときに自分たちの経験に基づく意見交換を行った、という話*4*5もいただいています。実務に近い感覚で練習問題に取り組んでいただけたのかな、と受け取っています。

ワーク説明の工夫

クラシフィケーションツリー技法は複雑なため、限られた時間で理解してもらうための工夫をいくつか用意しました。

用語の書き方

クラシフィケーションツリー技法の重要な用語として、クラシフィケーションとクラスがあります。ワークショップではクラシフィケーションをCLN、クラスはそのままクラスという書き方で使用しました。

用語

書き方を決めるにあたり、いくつか紆余曲折がありました。クラシフィケーションは頻繁に出てくる割に文字数が多いため、スライドの文字数が増えて見る負担が大きくなります。また、クラシフィケーションをCLN、クラスをCLSのようにアルファベット3文字の略称に置き換える案もありました。しかし、CLNとCLSはCLが共通のため、スライドに出てきたときにパッと見で区別がつきませんでした。最終的に、クラシフィケーションをCLN、クラスはそのまま使用して、文字数を減らして区別がつきやすい折衷案に落ち着きました。

クラシフィケーションの書き方 クラスの書き方 説明
クラシフィケーション クラス クラシフィケーションの文字数が多すぎる
CLN CLS アルファベット3文字の略称。文字数は少ないが、パッと見の区別がつきにくい
CLN クラス 【採用】文字数が少なく、区別がつけやすい

また、CLNとクラスは強調のため着色しています。ワークで用いる付箋の色と合わせています。*6

テストしたいこと

クラシフィケーションツリー技法によるテストケースの作成手順は大きく以下の3ステップになります。

  1. クラシフィケーションツリーを作る
  2. 組合せテーブルを作る
  3. テストデータと期待結果を定める

今回のワークショップでは、作成の前準備として「テストしたいことを決める」ステップを追加しています。

クラシフィケーションツリー技法によるテストケースの作り方
テストしたいこと

実務でクラシフィケーションツリー技法を使うにあたり、いつ、どうやって技法を適用できるかを判断するにも経験が必要になります。技法を適用する前にどのような整理をすると良いか、というのはそれだけでワークショップが組めるほど大きなテーマです。クラシフィケーションツリー技法のワークショップでは、テストで確認したいことをいくつか挙げて、「テストで確認したいことを挙げるステップが必要」であることを参加者に察してもらうようにしています。

ステップバイステップ(スライドごと)

クラシフィケーションツリー技法の作り方をスライドに記載しましたが、定義が書かれていても実際の作り方に結びつかないことが想定されました。そのため、説明の定義と例のクラシフィケーションツリーや組合せテーブルがどのように対応づいているかを、1手ずつ説明しました。定義の文章だけではイメージが湧きにくいことが軽減されることを期待しています。*7

クラシフィケーションツリーの作り方1
クラシフィケーションツリーの作り方2
ステップバイステップ(手順ごと)

ワークショップではクラシフィケーションツリー技法の作成手順を4ステップで説明しています。チュートリアルでは、それぞれのステップごとにワークを挟んでステップの内容を理解できるようにしました。クラシフィケーションツリー技法で用いるクラシフィケーションツリーや組合せテーブルは、初めて学ぶには複雑な作成手順になります。技法の説明はチュートリアル前に実施済みなので、チュートリアルではステップをひとつひとつ着実に学んでもらうようにしています。

ワーク

今回のワークショップでは、ワーク時間で作成手順を振り返れない構成にもかかわらず、私の知る限り手順に関する確認は特に受けませんでした。グループワークの参加者内でクラシフィケーションツリー技法の手順を補完できる状態にあったのだと思います。

NGケース

作成手順の説明において、NGケースは図を付けて少し詳しく説明しました。技法の説明は汎用性を持たせるため、抽象度が高く説明されることが多いです。そのため、説明を聞いてもうまくイメージできないことがあります。対して、NGケースは具体的に示しやすいため、明瞭にイメージしやすいです。「しなければならない」はうまくいっているかの判断が難しいですが、「してはいけない」は判断しやすいです。

NGケース

今回のワークショップでは、説明したNGケースを実施した人は見られませんでした。適度な量のNGケースを説明することは、技法をうまく扱うことを促進できるのだろう、と思いました。

例のトレース

チュートリアル内のワークは、事前に例を用いて説明した内容を、例を見ずになぞってもらうようにしました。これは、参加者に「ワーク道具の使い方の把握」や「技法ルールの理解」に注力してもらうことが狙いです。

クラシフィケーションツリーの説明
例のトレース

チュートリアルのやり方として「完成形の写経」もしくは「あたらしい問題を解く」ことが挙がります。「完成形の写経」は正解を容易に確認できるため、書き写すだけ意識が向いてしまいます。「ワーク道具の使い方の把握」は達成できますが、「技法ルールの理解」を達成しなくても完成形が作れることが想定されます。また、「あたらしい問題を解く」は「ワーク道具の使い方の把握」や「技法ルールの理解」だけでなく「技法を用いた情報の整理」にも意識を割く必要があります。そのため、考えることが複雑になっていずれもうまく達成できないことが予見されました。

チュートリアル後の練習問題では参加者に「技法を用いた情報の整理」に十分意識を割いてもらいたいです。チュートリアルでは「技法を用いた情報の整理」はできるだけ抑えめにして「ワーク道具の使い方の把握」や「技法ルールの理解」に意識を割いてもらいたいと考えました。

ワークショップのチュートリアルでは「例のトレース」を採用しました。説明で使った例と同じ内容を、例を隠した状態で作ってもらいます。仕様は印刷した仕様書で見ることができますが、そこからクラシフィケーションツリーや組合せテーブルはグループで考えて作る必要があります。ワーク時間では完成形は見れませんが、事前の説明で完成形は見ているので、完成形のイメージを持ちつつクラシフィケーションツリーや組合せテーブルを作ってもらいました。「ワーク道具の使い方の把握」や「技法ルールの理解」を達成しつつ、「技法を用いた情報の整理」に意識が向きにくいワークにできた、と思っています。

チュートリアルのやり方と参加者が習得できる期待値を以下の表に示します。

〇:習得できる、△:すこし習得できる、×:習得が難しい

完成形の写経 あたらしい問題を解く 例のトレース
ワーク道具の使い方の把握
技法ルールの理解 ×
技法を用いた情報の整理 ×

練習問題で、参加者が「ワーク道具の使い方の把握」や「技法ルールの理解」に躓くことがほとんどなく、「技法を用いた情報の整理」の議論が盛り上がっていました。チュートリアルを工夫したことが報われたのだと自分の中ではとらえています。

ワーク道具の工夫

ワークショップで使用する道具も試行錯誤しています。

マス目模造紙

格子状に薄い線が引かれている模造紙です。

組合せテーブルのワークでは格子状に線を引く機会がたくさんあります。線がまっすぐ引けなかったり線同士の間隔が合わなかったりと、ワークの内容でないところに集中力が割かれることを避けるため、ペンで直線を引く補助としてマス目模造紙を採用しました。

あるワークグループがワーク時間ギリギリのため、組合せテーブルの格子線を引かずに、マス目模造紙のマス目に合わせて組み合わせを検討していました。ワークでは組み合わせの検討に時間を割いてほしかったので、運営としてとてもありがたかったです。

ロール付箋

ロール状の紙付箋です。組合せテーブルで格子の交点に印を置くために使用しました。

格子の交点に印を置く道具の候補として、丸シールが挙げられます。しかし、丸シールは粘着力が強いため、ワークのように貼って剝がしてを繰り返す使用方法には向いていませんでした。付箋は粘着力が弱いため、ワーク用に貼って剥がしてもらう目的に適していました。今回はロール付箋を適切なサイズに手で切って使ってもらいました。紙なので、道具を使わなくても簡単に切れるのもお手軽です。

ロール付箋の使われ方としては馴染みがない方法ですが、参加者はかなり早く順応してくださったと思います。

おわりに

クラシフィケーションツリー技法は思った以上に難しく、テーマとして決めてからワークを作るまでいろいろな試行錯誤を行いました。当日のワークショップでは運営の至らぬ点もありましたが、参加者のモチベーションがとても高くて活発な意見交換も行われており、とても良い時間だったと思います。

当日はX(旧Twitter)でハッシュタグ #jassttohoku のついた投稿を表示しており、togetterにまとめています。感想ブログはまとめに追加しますので、公開いただけるとJaSST東北実行委員は大変喜びます。

togetter.com

謝辞

ワーク内容にご意見をいただいた 井芹久美子さん(@mejiro8000)、井芹洋輝さん(@goyoki)や、ワーク資料をレビューしてくださった秋山さん(@akiyama924)をはじめ、ワークショップのプレ会にも多くの方にご協力いただきました。ご協力いただき、大変ありがとうございます。

*1:ISO/IEC/IEEE 29119-4:2021 システム及びソフトウェア工学-ソフトウェア試験-第4部:試験技法 | 日本規格協会 JSA Group Webdesk

*2:https://onlinelibrary.wiley.com/doi/abs/10.1002/stvr.4370030203

*3:主にume2さんが強く推していました

*4:

*5:JaSST東北名物ワークショップを体験して思ったこと #jassttohoku - CAT GETTING OUT OF A BAG

*6:と思って緑付箋を発注したはずなのに、届いたのは青付箋だった。なんで…

*7:スライド数が多くなり、図の修正が必要になると時間がかかって大変でした

ハイブリッド開催でのユーザーストーリーマッピングワークショップ(JaSST'23 Tohokuワークショップ作成/運営話)

はじめに

2023/5/26(金)にJaSST'23 Tohokuがオンサイト(仙台市戦災復興記念館)/オンラインのハイブリッド開催されました。

www.jasst.jp

この会のワーク担当として活動していたので、ワークショップの作成/運用話をまとめます。
同じようなワークショップをやりたい人の参考になれば幸いです。

ワークショップ概要

テーマ

JaSST'23 Tohokuのテーマは「アジャイルとテストと私たち ~明日『アジャイル』と言われたときに困らないためのヒント~」であり、アジャイル開発の普及により重要性が高まっているアジャイルテストを扱いました。

川口さんによる「アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発」の基調講演*1からはじまり、長田さん、大平さん、半谷さん中村さんのそれぞれの実践的なアジャイルテスティングの事例紹介、スポンサー各社のLTなどボリュームのある構成となりました。

また、参加者に手を動かしてもらうために、実行委員コンテンツとして「ユーザーストーリーマッピング」を扱ったワークショップを実施しました。
テストを直接扱うワークではありませんでしたが、アジリティ(機敏性)の高いテストを行う上でテスト重要性の判断基準となる「ユーザー視点」を学ぶことは役に立つ、と考えてユーザーストーリーマッピングを選定しています。

この記事は、そのワークショップを主題として扱います。

ワーク内容

ワークは以下の2段構成になっています。3-5人程度のチームを組んで実施いただきました。

  1. 「朝起きてから家をでるまで」を考えよう
  2. 「乗換案内システム」で顧客への価値を考えよう
「朝起きてから家をでるまで」を考えよう

参加者が朝起きてから家をでるまで*2を付箋に書き出していただき、チームで共有いただきます。その後、「寝坊して5分で家を出なければならない場合に何をやるか」を検討いただきました。アジャイル開発を行う上で重要なMVP*3の考えを実感していただくことが目的となります。

ワーク1「朝起きてから家を出るまで」を考えよう
「乗換案内システム」で顧客への価値を考えよう

「乗換案内システム」を開発するために、ストーリーカード*4をもとにリリースに必要な機能を選定してもらいました。ストーリーカードや機能カードはあらかじめ用意されたものを使い、2回分リリースを疑似体験してもらうワークを実施いただきました。ユーザー視点を意識してMVPを考える感覚を体験いただくことが目的となります。

ワーク2「乗換案内システム」で顧客への価値を考えよう

工夫したこと

JaSST'23 Tohokuはハイブリッド開催のため、ユーザーを以下の3属性に分けてワークショップを作成しました。それぞれの属性についての工夫をまとめます。

  1. オンサイト参加者
  2. オンラインワーク参加者
  3. オンラインワーク非参加者(視聴者)

オンサイト参加者

オンサイト参加者には一般参加者全員にご参加いただきました。ワークショップが本会の後半であり疲れていたと思いますが、みなさん積極的に取り組んでいただき有難い限りです。

オンサイトワーク風景(モザイク)

一般的なペンと付箋のほか、時系列を表す線を引くためのロールタイプの付箋、機能カードやストーリーカードを印刷したもの*5を用意しています。

会場には多くの実行委員がいて参加者とのコミュニケーションも取りやすいため、今回の中では一番トラブルには対処しやすい運営スタイルでした。

オンラインワーク参加者

オンライン参加者にはMiroとDiscordボイスチャットでワークを実施いただきました。ワークへの参加は昼休み明けまでに参加者を募り、実行委員で3-5人のチーム分けを行いました。チーム用のワークスペースはあらかじめMiro+Discordに作成しており、割り振ったチーム番号のワークスペースに移動してもらうようにしています。

チーム分け(参加者名はモザイク)

Miroでは以下の画像のようなワークスペースをチーム分用意しました。また、参加者はチームごとにDiscordのボイスチャンネルに入っていただき、チーム同士の会話を実施いただきました。ZoomのWebinarではブレイクアウトルームが使えないため、Discordのボイスチャンネルで個別ワークを実施いただくように対応しています。

ワーク1のMiroワークスペース
ワーク2のMiroワークスペース

また、オンラインでは人数がかなり多くなることが想定されていました*6。そのため、ワーク初めの説明では、オンライン参加者向けの説明を厚めに実施しています。説明を含む資料はワーク実施前に参加者に展開して、資料を見ながらワークができるようにしました。また、ワーク実施中はZoomから抜けてワーク実施後にZoomに戻ってもらうことがあるため、できる限りワークタスクのまとまりを大きくして切り替えが少なくなるようにしています。

オンライン参加者向けの説明スライド1
オンライン参加者向けの説明スライド2

オンラインワーク非参加者(視聴者)

オンライン参加者の中には、ワーク時間をすべて参加できない方*7がどうしても出てきます。特にJaSST東北のワークショップは1日のうちの一部でしかないので、ワークショップに参加できない方にも学べる内容を用意する必要がありました。

そのため、JaSST'23 Tohokuでは、オンラインのワーク実施風景を、実施者の音声込みでWebinarに配信させていただきました。対象となるチームは、あらかじめオンライン参加者の数名にお声がけして許可を頂いています。

運営配信側では、大きく以下の2つを実施しています。視聴者でもワーク参加者と同じ状況を共有できるので、ワークを疑似体験して学びが深くなることを期待しています。

  1. Miroの画面を配信に共有する。Miroの機能で、ワーク参加者の1名のマウスカーソルの動きを追従することができます。ワーク参加者の実際の動きを視聴者が追体験することができます。
  2. Discordのボイスチャンネルに入り、音声を配信に共有する。Zoomの画面共有時に「サウンドの共有」にチェックを入れることで、Discordボイスチャンネルでのワーク参加者同士の会話をZoomに共有することができます。運営PC上で鳴った音声は全て配信に載ってしまうため、Zoomの通知などを事前に切っておくなどの準備が必要です。
ワークショップ実施風景の公開

JaSST'21 Tohokuでも、今回のようにワーク参加者の実施状況を配信しました。その経験を活かした工夫です。

www.jasst.jp

もっと工夫すべきだったこと

「オンラインワーク非参加者(視聴者)」向けにZoom Webinar上でワーク実施風景を共有しています。そのため、「オンラインワーク参加者」からワーク実施中にWebinarを切断しなければならず、ワーク実施後のWebinar再接続大変である旨の指摘をいただきました。
Zoom(Webinar)には現時点でスピーカーミュート*8機能が存在しません。そのため、オンラインワーク参加者はWebinarの音声を遮断するために、Zoomを切断する必要がありました。

例えば、Windows10にある「音声ミキサー」機能を使えば、アプリケーションレベルで音声操作を行うことができます。しかし、環境依存性があり、すべてのオンラインワーク参加者に実施いただくのは難しいため、Webinarの切断、再接続で対応いただくようお願いしています。

Windows10の音量ミキサー

今後はツールの選定、調査などでオンラインワーク参加者の負担が減るように検討したいと思います。

おわりに

JaSST'23 Tohokuでは、いろいろな参加者の学びが深まるにはどうすれば良いかを考えて、準備をしてきました。
JaSST'23 Tohokuの参加者が「学んだ内容を活かしたい」と少しでも思っていただければ幸いです。

*1:川口さんの講演は豊富な知識に基づく話が多く、ユーモアある会話ながらも刺さる観点が多く、衝撃を受けました

*2:オンライン参加者で家を出ていない場合は、JaSST'23 Tohokuのwebinarに接続するまで

*3:Mininum Viable Product, 価値を提供できる最小限のプロダクト

*4:「who」として「why」のために「what」したい、が書かれたカード

*5:家庭用プリンタで印刷できる名刺シートを利用

*6:念のため30チーム分用意していました。実際は7チーム

*7:他に予定があるなど

*8:運営側が流している音に対して参加者側が音量を調整する

バグの少ないプログラミングの考え方の例

わたしがプログラミングをするときに、バグが少なくなるように意識していることを整理して書き出します。内容の正確さを保障できませんので予めご了承ください。

形式手法

形式手法とは数学や論理学に基づいたソフトウェア開発・検証手法を指します。プログラムと証明には対応関係があること*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

おわりに

キーワード程度の提示しかできませんでしたが、使用するプログラミング言語が命令型だったとしても、宣言的な考えを用いることがバグを抑えることに繋がると考えています。

*1:カリーハワード同型対応

*2:形式仕様記述

*3:プログラミング言語における模範

*4:入力以外でプログラムの動作に変化を与える

*5:統一モデリング言語、Unified Modeling Language

*6:カジュアルな依存型、と言いたいですが依存型に詳しくない…

軽量ハイブリッド(オンサイト&オンライン)ワークショップの配信事情(2022/9/10 アジャイル札幌「チーム全体でテストの知を積み上げる-やってみようVSTeP-」)

はじめに

JaSST東北のメンバーとして、アジャイル札幌の「チーム全体でテストの知を積み上げる-やってみようVSTeP-」というイベントでVSTePのワークショップを行いました。ハッシュタグは #agilesapporo です。

agilesapporo.doorkeeper.jp

VSTePは「Viewpoint-based Test Engineering Process」の略称であり、直訳すると「テスト観点に基づくテスト開発プロセス」になります。VSTePについて詳しく知りたい場合はこちらをご覧ください。

http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf

今回のイベントはハイブリッド(オンサイト&オンライン)開催でのワークショップでした。オンサイト会場にいながら、オンライン参加の方々にも可能な限り良い体験をしてもらうために用意しました。課題はあれど、それなりの形にはなったのでまとめておきます。

オンラインでのVSTePワークショップ

JaSST'16 Tohokuは「テスト開発しちゃいなよ!~テスト設計との違い~」というテーマで、VSTePのワークショップを行いました。オンサイト開催であり、4-5名で1グループを作り机を囲んで付箋にテスト観点を書き出していました。

www.jasst.jp

今回はオンライン開催もあったため、同様の講義配信やワークショップをオンラインでも実現できる必要がありました。

ハイブリッド開催でのワークショップのためのアプリ

以下のアプリを使って実現しました。

  • Zoom

Webビデオ会議ツール。複数の部屋を作って参加者を振り分けて会議をする機能*1があるので、グループごとに部屋を分けてワーク中の会話をしてもらいました。

Webホワイトボードツールであり、主に付箋の書き出し機能を使います。普段はMiro*2を使いますが、やんごとなき理由*3によりMuralを使ったところ、思ったより使い勝手が良かったです。

  • Discord

参加者間コミュニケーションに利用しました*4。聴講中などは疑問点なども多く上げていただきました。

参加者への資料共有に使いました。

ハイブリッド開催での運営モード

ハイブリッド開催するにあたり、いくつかの運営モードを切り替えて実施しています。

  • 講義モード

講師の講演をオンサイト&オンラインに伝えるモード。オンサイトには会場のディスプレイに講義に資料を出力します。オンラインには講義資料をZoomの画面共有で流したり、発表中の講師の様子をビデオで流します。

  • ワークのぞき見モード

オンサイトにいるスタッフがオンラインのワークグループの支援をするモード。オンサイトの方々の注意を逸らさないようにするために、ヘッドセットをつけてノートPCでオンラインのワークグループの部屋に参加します。

  • ディスカッションモード

講師と参加者が議論をするスタイル。ワークの成果物に対して実施したため、Mural画面をZoomで画面共有して実施しました。オンサイトではマイクとスピーカーでオンライン上の方々と議論できる用意をしました。

ハイブリッド開催での配信機材

配信機材

今回の配信で使用した機材を紹介します。

  • ノートPC

Zoom配信&Mural作業用。

Discord&Twitterハッシュタグ追跡)用。2画面分割表示機能を初めて有効に使った気がします。

  • 大型ディスプレイ(会場備品)

映像出力用はもちろん、オンラインの会話をオンサイト会場に流すためのスピーカーとしても使用しました。

オンサイトの講演者や会場の様子をオンラインに流すために使用。少しでもライブ感を共有してもらう目的です。

  • ワイヤレスマイク

新調品。講義モードやディスカッションモードで活躍しました。大きい会場だと音響設備が揃っていますが、会議室でオンラインへも配信する場合はこういったワイヤレスマイクでそれっぽく配信できました。

  • レーザーポインタ

新調品。講義モードにおけるスライドのページ送りに使用しました。会議室で使われている大型ディスプレイに対しては、レーザーポイントは機能しなかった*5。単なるレーザーポイントだとオンラインには指し先が伝わらないので、別案を用意したい。

  • ワイヤレスイヤホン(or ヘッドセット)

ワークのぞき見モードで使用。オンラインのワークグループ部屋に参加した際に、オンサイトへの影響少なく会話に参加するために使っています。他のスタッフはヘッドセットを用意していましたが、わたしはワイヤレスマイク&ワイヤレスイヤホンで対応*6

おわりに

ハイブリッド開催のワークショップ開催の知見はまだまだ課題が多いので、いろいろ試してみたいです。

参加してくださった皆さん、スタッフ&講師の方もありがとうございました。

昼ご飯のキングサーモン定食

*1:ブレイクアウトルーム

*2:https://miro.com/ja/

*3:定期大規模メンテナンスがワーク時間に直撃しました。https://twitter.com/aslead_miro/status/1565258864211423232

*4:運営のアジャイル札幌に用意いただきました

*5:レーザーポイントの光がディスプレイに吸収されるため

*6:荷物を減らすため

軽量ハイブリッド(オンサイト&オンライン)ワークショップの配信事情(2022/9/10 アジャイル札幌「チーム全体でテストの知を積み上げる-やってみようVSTeP-」)

はじめに

JaSST東北のメンバーとして、アジャイル札幌の「チーム全体でテストの知を積み上げる-やってみようVSTeP-」というイベントでVSTePのワークショップを行いました。ハッシュタグは #agilesapporo です。

agilesapporo.doorkeeper.jp

VSTePは「Viewpoint-based Test Engineering Process」の略称であり、直訳すると「テスト観点に基づくテスト開発プロセス」になります。VSTePについて詳しく知りたい場合はこちらをご覧ください。

http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf

今回のイベントはハイブリッド(オンサイト&オンライン)開催でのワークショップでした。オンサイト会場にいながら、オンライン参加の方々にも可能な限り良い体験をしてもらうために用意しました。課題はあれど、それなりの形にはなったのでまとめておきます。

オンラインでのVSTePワークショップ

JaSST'16 Tohokuは「テスト開発しちゃいなよ!~テスト設計との違い~」というテーマで、VSTePのワークショップを行いました。オンサイト開催であり、4-5名で1グループを作り机を囲んで付箋にテスト観点を書き出していました。

www.jasst.jp

今回はオンライン開催もあったため、同様の講義配信やワークショップをオンラインでも実現できる必要がありました。

ハイブリッド開催でのワークショップのためのアプリ

以下のアプリを使って実現しました。

  • Zoom

Webビデオ会議ツール。複数の部屋を作って参加者を振り分けて会議をする機能*1があるので、グループごとに部屋を分けてワーク中の会話をしてもらいました。

Webホワイトボードツールであり、主に付箋の書き出し機能を使います。普段はMiro*2を使いますが、やんごとなき理由*3によりMuralを使ったところ、思ったより使い勝手が良かったです。

  • Discord

参加者間コミュニケーションに利用しました*4。聴講中などは疑問点なども多く上げていただきました。

参加者への資料共有に使いました。

ハイブリッド開催での運営モード

ハイブリッド開催するにあたり、いくつかの運営モードを切り替えて実施しています。

  • 講義モード

講師の講演をオンサイト&オンラインに伝えるモード。オンサイトには会場のディスプレイに講義に資料を出力します。オンラインには講義資料をZoomの画面共有で流したり、発表中の講師の様子をビデオで流します。

  • ワークのぞき見モード

オンサイトにいるスタッフがオンラインのワークグループの支援をするモード。オンサイトの方々の注意を逸らさないようにするために、ヘッドセットをつけてノートPCでオンラインのワークグループの部屋に参加します。

  • ディスカッションモード

講師と参加者が議論をするスタイル。ワークの成果物に対して実施したため、Mural画面をZoomで画面共有して実施しました。オンサイトではマイクとスピーカーでオンライン上の方々と議論できる用意をしました。

ハイブリッド開催での配信機材

配信機材

今回の配信で使用した機材を紹介します。

  • ノートPC

Zoom配信&Mural作業用。

Discord&Twitterハッシュタグ追跡)用。2画面分割表示機能を初めて有効に使った気がします。

  • 大型ディスプレイ(会場備品)

映像出力用はもちろん、オンラインの会話をオンサイト会場に流すためのスピーカーとしても使用しました。

オンサイトの講演者や会場の様子をオンラインに流すために使用。少しでもライブ感を共有してもらう目的です。

  • ワイヤレスマイク

新調品。講義モードやディスカッションモードで活躍しました。大きい会場だと音響設備が揃っていますが、会議室でオンラインへも配信する場合はこういったワイヤレスマイクでそれっぽく配信できました。

  • レーザーポインタ

新調品。講義モードにおけるスライドのページ送りに使用しました。会議室で使われている大型ディスプレイに対しては、レーザーポイントは機能しなかった*5。単なるレーザーポイントだとオンラインには指し先が伝わらないので、別案を用意したい。

  • ワイヤレスイヤホン(or ヘッドセット)

ワークのぞき見モードで使用。オンラインのワークグループ部屋に参加した際に、オンサイトへの影響少なく会話に参加するために使っています。他のスタッフはヘッドセットを用意していましたが、わたしはワイヤレスマイク&ワイヤレスイヤホンで対応*6

おわりに

ハイブリッド開催のワークショップ開催の知見はまだまだ課題が多いので、いろいろ試してみたいです。

参加してくださった皆さん、スタッフ&講師の方もありがとうございました。

昼ご飯のキングサーモン定食

*1:ブレイクアウトルーム

*2:https://miro.com/ja/

*3:定期大規模メンテナンスがワーク時間に直撃しました。https://twitter.com/aslead_miro/status/1565258864211423232

*4:運営のアジャイル札幌に用意いただきました

*5:レーザーポイントの光がディスプレイに吸収されるため

*6:荷物を減らすため