TDDBCオンライン#01 1人でふりかえり やってよかったこと編

TDDBCオンライン#01 よかったですね！

関わっていただいたみなさんありがとうございました。

運営のコアメンバーの1人として、とてもうれしく思います。

TDDBC初のオンライン開催としては成功と呼んで良いのではないでしょうか。

運営としての残りのお仕事

さて、運営のお仕事はまだ残っています。それは今回開催のふりかえりです。うーむ、どうしたものか。

いきなり集まって「ふりかえりしようぜ！」と宣言するのはカンタンなのですが、話題が散らかってしまったり、共感が集まるだけで、結局モノゴトが前に進まない予感がすごいです(それはそれで楽しいのだけど)。

じゃあ、何をふりかえりましょうか？

そこで考えたのは「次のTDDBCオンライン開催に役立つ情報を残すこと」です。 これは、運営のコアメンバーがやるべきことの1つだと思います。コアメンバーは運営に関する意思決定を行ったり、意思決定の場に同席する回数が圧倒的に多いわけです。意思決定の結果は残りやすいですが、過程の情報は失われがちですからね。

次につながることを書こう

というわけで、運営のコアメンバー1名の視点で、役立つ情報を書き記していきましょう。

記述内容は次の観点で絞りました。

1. 「狙いがあってやったこと」を書く
   • 狙いがあるということは、そこに1つの仮説があるわけです。仮説があるから、結果の考察により価値が生まれます。
2. 「やってよかったこと」を書く
   • 多少の改善余地はあるけど、そのまま継続したら良いと思うことを書く。
   • 次回やるときに、「この記事にあることはやっておこう」というカタチで使いまわししやすそう。

他の話も書くつもりでしたが、書ききる前に心が負けそうになったのでやめました。 また、改善すべきところは記憶にも残りやすいので、あとからは考えやすいかなと。

というわけで、つらつらと書いていきます。

1. 環境構築会のための準備会を導入した(TDDBC Online は 2日構成 にした)

結論から言うと、絶対にやるべきです。間違いない。

狙いは「本編当日によーいどん！ で TDDペアプロができるようする」ためです。

TDDBCはTDDをペアプロで進めていくスタイルです。ペアプロする以上、環境を揃えたりとか、交代方法を決めたりする必要があります。何より、初対面の人とペアを組むことになるので自己紹介のレベルから始めないといけません。

オフラインの場合は何かトラブルがあったとしても、その場でなんとかできることが多いです。例えば、参加者のPCが壊れてしまっても、運営からPCまるごと貸し出すこともできます。

しかし、リモートペアプロはそうはいきません。マイクが設定とか画面共有の方法みたいなところから丁寧にやらないといけません。特にトラブルシューティングが鬼門です。相手の状況は相手にしかわからないので、時間がかかるし、何よりとてつもない不安感やストレスが襲ってきます。これはとてもつらいです。

「環境構築してたら時間がなくなってしまった。。。」というのはTDDBCの体験として最悪の部類です。それだけはなんとしても避けなくてはなりません。

そこで「環境構築をするだけの会」を設けたわけです。これはオンライン開催の移動コストや参加ハードルの低さのおかげでもありますね。

スライドを見ていただくと何をする会かイメージがつくと思います。 TDDBC準備会 - Speaker Deck

準備会では チェックシート(Googleスプレッドシート) を使って、ペアごとに環境を揃えてもらいました。 項目を見ていただくとわかりますが、「ペアの名前を知っている(発音もセットで)」や「Discordでライブへの参加方法を理解している(他の人の画面共有を見れる)」といったものも抑えています(本当につまづきが多いのです！)

2. 準備会でペアプロのデモをやった

これもやってよかったです。ぜひ続けましょう。

ペアプロのデモをタイムテーブルに追加した経緯はこんな感じです。

準備会でペアプロ環境を構築することに決めた！

↓

ペアプロ環境が構築できたかどうかは、ペアプロしてみれば明らかになる。(チェックシートだけだと検証として弱い可能性がある)

↓

でも、ペアプロ初めての人もいるから、やり方は伝えないといけないのでは？

↓

じゃあ、ペアプロのデモもやっちゃいますか！

↓

せっかくだから、基調講演でカバーしにくいところをやっていこう (※基調講演は主にTDDの話であり、「ペアプロ」の成分は少ないのです。というか、一人でペアプロはできないですからね。)

とても納得できる話だと思っていたし、「アイデアで終わらせてはならない」と思ったので、その場にいたとーます(@grimrose)さんとTakehiro Inoue (@i_takehiro)さんに依頼しました。おふたりとも歴戦の猛者です。TDDBCに関しても詳しく、情熱もあります(結果的に、この人選は大成功！)。

時間のない中、練習を重ねて、とてもクオリティの高いペアプロデモに仕上げていました。すごすぎる。 また、Discordでの意見や質問への回答も凄まじかったですね。とてもよかった。

デモをやる理由と、お題のリポジトリを貼っておきます。

grimrose/tddbc_online_demo_java_junit5: TDD Boot Camp 2020 Online #1 ペアプロデモ

## このデモをやる理由
​TDDBCではペアプロで演習を行うことが多い。
ペアプロをやったことがない人が多いので、まずはどんな感じなのかみてもらう。
あくまでもデモなのでこんな感じに出来るといいよというのを伝える
当日はTAもいるのでそこまで不安に感じなくても大丈夫だと伝える
​
## ペアプロの役割の説明
​ドライバーとナビゲーターがいます。
​
### ドライバーがやること
​コードを書いていく。
書いているときに考えていることを口に出してナビゲーターに意図を伝える。
​
### ナビゲーターがやること
​ドライバーがコードを書くのに必要な情報などを伝える
調べ物をしたり、気づいたことを伝える
ドライバーからの意図を汲み取って、どのようにコードを書いていくと良いか考えてその意図をドライバーに伝える。
​
### ２人でやること
​お互いが考えていることを口に出して意図を伝え合い、合意をとりながらすすめていく。
役割を切り替えるタイミングを予め決めておく。

ペアプロデモはとても素晴らしく、それだけで価値があるものでしたが、ここで私は最大のミスを犯します。

それは、アーカイブ(録画)しなかったことです。これは私が犯した最大のミスの1つです。非常に悔やまれます。 特に、準備会については、私が中心となって進めていただけに、悔しさはより大きいです。

アーカイブしなかった理由は1つ。それは、恐れです。

「困ったら安全側に倒そう」という意識があったのです。

ペアプロデモのライブ配信のアイデアが無いわけではありませんでした。 しかし、録画や配信の体制を追加することで、肝心のペアプロデモが破綻してしまったらどうするんだ？ という思考になり、アーカイブ案は私の中で切り捨てました。

このあたりは次回は改善できそうです。単純に練習を重ねるか、知見のある人の力を借りれば解決します。

3. リモートペアプロ環境は2つ準備してもらった

これもやってよかったです。ツールは変わるかもしれませんが、2つの手段を用意しておくべきです。 とにかく「ペアプロできなくなった！」という状況を避けるためです。

リモートペアプロの環境として主に3つのやり方があります。

1. Push/Pullパターン
2. LiveShareパターン
3. ブラウザIDEパターン

詳しくは p.36 リモートペアプロの3パターン TDDBC準備会 - Speaker Deck をご覧ください。

また、VSCodeLiveShare で ペアプロする方法(Mac編) - YouTubeで、LiveShareパターンの実演をしているので見てもらうと良いと思います。

このうち、「1. Push/Pullパターン」と「2. LiveShareパターン」の両方を準備してもらいました(準備会で終わらなかったペアは本編までにやってもらいました)。

実際、これは正解でした。

当日に、あるペアのAさんの環境が壊れる事象が発生したのです。

現象をざっくり書くと、

Aさんの環境で、テストが回せない → ドライバー交代できない → もしかして、LiveShareならいけんるんちゃう？ → LiveShareで何か詰まった → どうしよう？ 困ったぞ！

その場での結論は次のようになりました(たぶん、5分くらいで決まったと思います)

• Bさんの環境だけを使う
• Bさんが、ドライバーオンリー
• Aさんが、ナビゲーターオンリー

判断基準は

• 環境構築に時間をかけるよりも、今ペアプロやれることを大事にする
• 役割は、後日入れ替えて楽しんじゃえばええやん！ → 実際に、現在予定しているようです！ すばらしい！ → 日程も決まって、みんなでやることになりました！ すごい！

4. 「2TA -> 3ペア」フォーメーションを採用した

これも良かったと思います。次回もそのまま採用して良いと思います。

オフラインとの最大の違いは、「なんとなく様子を見る」ってのができないことです。

オフラインであれば、画面を覗き込まなくったって色んな情報が手に入ります。例えば、

• 明らかに詰まっているっぽいワードがなんとなく聞こえてくる
• TAがつきっきりなペアがなんとなく視界に入る
• 全然コミュニケーションできてないのがなんとなく感じられる
• たのしそうに進んでいる感じがなんとなく感じられる

リモートの場合は、1度に手に入るのは僅かな情報であり、しかも積極的に情報をとりにいかないと分からないのです。

• 1TA -> 1ペア
  • これは安定のパターン
  • でも、もうちょっとTAを活用したくなる
• 1TA -> 2ペア
  • 一応回せそうではあるが、リモートペアプロ練度に大きく依存する
  • また、一方のペアでトラブルってしまうと、、、／(^o^)＼
• 2TA -> 3ペア
  • ちょうどよさそう(未検証でしたが、実際やってみた感じでは機能していたと思う)

5. 参加人数はTAのキャパシティから決めた

これも継続採用で良いと思います。

今回の運営判断で重要視したのは、参加人数の最大化は目指していないという点です。

また、迷ったら安全側に倒すという意思決定基準も作用しています。

「もしかしたらもっと多くの人を参加しても成り立つようにできるかもしれないが、それよりも確実にカバーできる範囲でやっていきましょう！」と、なりました。

初のオンライン開催の負担は大きいものでしたが、続けていけばコストはきっと下がります。であれば、確実な開催を何度も何度もやるほうが良いと思ったというわけです。 (この記事もコストを下げるために書いています！)

6. 申込時段階で使用するプログラミング言語を固定した

これも継続で良いと思っています。

この決定をしたのは「ペア決めの煩雑さを避けるため」です。

この狙いは成功したと思います。 実際には、ペアの片方が欠席してしまい、別言語でのペアに組み換えということもありました。

却下となったアイデアもあります。 「第N希望まで書いてもらって、その後調整する」という方式です。これはオフラインでやっていた方式です。

オフラインはなんとかできるのですが、リモートは何とかならないのです

7. 申込みは申込日時を公開した上で、先着順での当選にした

ここも継続してよいと思います。

不採用にしましたが「抽選方式」というアイデアもありました。

抽選方式にすると、ペアが成立しなくなるか、ペア決めが煩雑になります。

ランダム抽選にした場合は、言語の偏りがでたり、TAでフォローできないパターンになる可能性があります。

ある程度介入した上での抽選みたいなこともできますが、これは結局、運営負担が増えるだけです。

こういった理由もあり、「申込日時公開+先着順」としました。

8. 参加費を有料(1000円)にした

1000円が高いか安いかの議論はさておき、次回も有料にすべきだと思います。

実は、今回の開催は0円です(当然、人件費を除きます)。

詳しい収支報告は松岡さんがきっと書いてくれます → tddbc/tddbc-online-earnings-call: TDDBC Onlineの収支報告を記録します

じゃあ、無料でもいいのでは？ という人もいるかも知れませんが、無料にすべきではないと思います。

理由は2つです。

1. 無料にすると、キャンセル率が高くなりがちだから(申し込みコストが0になるので、とにかく申し込んだほうが得になってしまう)
2. 今後、利用するツールを有料化する可能性があるときや、招待講演などをする場合にプールされている資金があると便利だから

9. 行動規範(CoC; Code of Conduct)を導入した

こちらも継続で良いでしょう。内容に関しては随時Updateしておけば良いと思います。 tddbc/tddbc-online-coc: オンライン開催におけるCOC(ConfcodeOfConduct: 行動規範)

参考とした資料もいくつかあったと思います。例えば、さいきょうのCode of Conductを求めて - ものがたりです。 (@nakasho_devさんに聞かなくては。)

CoCを担当していただいた @nakasho_dev さんの振り返りブログはこちら。

nakasho-dev.hatenablog.jp

10. 自己紹介スライドを導入したこと

これもぜひやりましょう。

TDDBC online 1st自己紹介スライド - Google スライド

どこまで役立ったか測定が難しいところもありますが、やっておいて損はないところだと思います。 アイコンを1つのスライドにまとめたり、移動の指示がとても楽になります。

アイコン収集は @shibatea365さん と @消しゴムうまこ さんのおかげです。 (お二人には影で相当な協力をいただきました。これもいずれちゃんと書かねば)

11. YouTubeLiveでモデレーターを導入した

基調講演のかたちがどうなるかはわかりませんが、Live配信をするならやるべきアイデアだと思います。

基調講演のYoutubeLiveでは「モデレーター」という役割を @yattomさん と @PoohSunnyさん のお二人に当日お願いしました。 (より正確には、お二人の立候補です)

依頼内容は2つです。

1. コメントでの質問で対応可能なものがあれば、コメントで回答してもらう
2. 補足などがあればコメントしてもらう

(「モデレーター」と命名しましたが、「副音声」という表現がより良い感じがしています)

モデレーターの背景はちょっとややこしいので説明します。

まず、基調講演の配信構成は次のとおりでした。 (より詳しいフォーメーションは、別の記事で書きます。きっと。)

• TDDBC参加者は Zoomでの視聴 + Discordのチャットでワイワイ
• それ以外の人は、YoutubeLiveの視聴 + YoutubeLiveのコメント欄でワイワイ

また、事前の取り決めとして次を定めていました。

• 質問はコメントのみで行う(Voice参加はなし)
• 質問はベストエフォートで拾う(全ての質問への回答を保証しない)
• 拾い上げる質問は TDDBC参加者の質問(Discordでの質問) を優先する

カンタンに言うと、TDDBC参加者を優先したわけです。

しかし、YoutubeLiveでの視聴者も相当な数(500名以上)が見込まれていたし、YoutubeLiveでの体験をより良くできるならすべきだろうという判断でした。 (モデレーターのアイデアは、おそらく@t_wadaさんのアイデアだったと思います。忘れてしまった。)

これが経緯です。

結果、大成功。

一度動画を見た方も、コメントに着目してもう一度見てもらうと発見があると思います。 (TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング - YouTube)

#tddbc 当日はライブコーディングで手一杯で YouTube Live コメント欄の質問に対する回答は @yattom さんと @PoohSunny さんに全面的にお任せしていたのですが、動画アーカイブに残ったコメント欄のやりとりを見ているとお二人の回答が素晴らしすぎて目から汗が出てきます……

— Takuto Wada (@t_wada) 2020年8月3日

アーカイブされることを考えると、YoutubeLiveのコメント欄を盛り上げたり、より意義のある情報を残すのは良いと思いました(これは、あとになって気づいたことです)。

もちろん、Discordでのやり取りも大盛況でした。純粋なワイワイだけでなく、具体的な質問やその回答が行われていました。すばらしい。

まとめ

「次のTDDBCオンライン開催に役立つ情報を残す」ために「狙いがあってやったこと」のうち「やってよかったこと」を「11個」書き出しました。

狙ってやったけどイマイチだったことや積極的に改善したいこと、次回は止めたいことはまた別の記事で書きましょう。