「1年間続いたオンライン勉強会」秘伝のタレを公開します

本記事は、 DDD-Community-Jp Advent Calendar 202020日目です。

■ はじめに

この記事について

この記事では、1年続いたオンラインモブ開発のフォーマットを紹介します。

このフォーマットを紹介しようとした経緯ですが、2020年最後のモデリング会で 1年間を振り返っている中で、『せっかくDDDCJというコミュニティ内でやっているのだから、もっと実践したいという人を受け入れられる形にしたい』といった意見が出てきたのが発端です。

それに対して、「もうちょっとこの会として何をやっているのか、という透明性を高めるために、会としてのアウトプットを増やした方が良さそう」だと判断しました。

たとえば、今後モデリング会に参加したいもしくは、モデリング会のように自分が得た知識を実践する会を開くときに、いま私たちのやり方をフォーマットにしておくことで、何らかのヒントになるのではないかと考えました。 そこで1年続いた(もしくは辞めなかった)モチベーションを書いておくことにしました。

ちなみに、1年間の試行錯誤のお話は以下をご参照ください。

  ※ なおこの記事もタイトルもモブで書きました!


この記事の構成

本記事は、

  • なんで勉強会をするのか
  • モデリング会でやっているオンラインモブ開発のやり方の一例
  • 勉強会を継続するにあたって大事にしたこと

という構成で書いていきます。

自分たちが伝えたい「なぜ勉強会をするのか?」

本を読んだり勉強会に参加して、ある程度知識が付いてきたように思える。 しかし、いざ実践や素振りをしてみようとしてもその場はあまりなかった。 そんな悩みを感じていました。

そこで勉強会を開いて実践する場を作ったところ、あらゆる種類の失敗にハマり、その失敗を経験したことから次々と学べるというサイクルが生まれていきました。

これは実務の中ではそうそうできないことであり、勉強会だからこそできることでしょう。こうした、成果主体ではないからこそ大きな学びの機会になるということや、躊躇することなく新しいことにチャレンジできるという楽しみが、勉強会を続ける動機になっているように思います。


■ 進め方の一例

いまどんなふうにやっている?

ほぼ隔週日曜日に、20:00からDiscord上で開催して、次のようなことをやっています。

  • 集合
  • カンバンを確認する
    • 前回何をやっていたかをふりかえる
  • モデル図見る
  • やる範囲決める
  • 頑張って実装する
  • ふりかえり
  • モデル図を見る
  • 次回のToDo整理

この順番が基本になっていますが、コードを書いていて不審な点があればモデル図に立ち返ったり、モデル図を見ているときにどういう実装になってたっけ? とコードを見に行ったり、ちょくちょく切りのいいところでやっていることを整理したりもしています。

オンラインでの進め方

進め方の中で大事なこと

  • モブワークに参加する人はボイスチャット必須。
  • コミュニケーションを多重構造にする。
    • ボイスチャットとテキストチャットを混合する。
    • テキストチャット勢は、好き放題わいわいする。
      • ボイスチャット勢に何かを伝えてもよし。
      • テキストチャット勢同士で会話してもよし。
    • チャット勢の言葉を『読み上げる』のが大事。
      • 読み上げることで「視点を同期する」
        • コードやモデルを目の前にしていると、参加者それぞれの視点がばらばらになりやすい。
        • 特にオンラインでは身振り手振りが使えないので顕著。
        • なので、チャットを読み上げることで「今何について話しているのか」を同期する。
        • ※ チャット以外(コーディングやモデリング) でも非常に有効。
      • 読み上げることで「場を整える」
    • ボイスチャット勢を3人集めたい。
      • 1:1 の会話だと休憩出来ず辛い。
      • ヒートアップしているときなど、3人目が仲介したり疑問を投げかけたりできる。
  • 次回のToDo整理をしてから終わり、ToDo確認から始める。
    • たとえ毎週実施したとしても、前回の内容は忘れてしまいます。
    • 次回なにをやるかを決めておき、いざやる前にもう一度何をするべきか確認してから始めることで、たとえ1回欠席してしまったとしてもスムーズに参加できるようになりました。
  • 開催タイミングを基本的に固定する
    • 例えば「隔週日曜」と決まっていればリズムが生まれます。
    • その日が近づくと自然と「もうすぐ勉強会だな」という気持ちが生まれやすく、習慣化につながっていきます。
  • 分からないを言葉にする。
    • 分からないことを素直に言葉にすることで、モデルの整理や振り返りにつながります。

■ 勉強会を継続するにあたって大事にしたこと

日程を決めて開催すること

勉強会初期から意識していたことですが、勉強会を終了する前に、「次回はこの日!」と決めておくのは大事です。

仮に都合が悪くなっても、延期日を決めておきます。

勉強会でありがちなのが、「日程は後で決めましょう」で解散してしまい、その後なにも決めずに時が過ぎて、結局やらないパターンがあります。

そういったことを防ぐためにも、参加者全員が揃っているその場で、次の日程を決めておくのは重要です。

3ツイ・ルール

「楽しかった」「面白かった」で終わらせないために、言語化や深堀りを促進する手段として、「最低、3つツイートしよう」というルールを設けました。 (1年かけて「学びがあった」を打破した - mob-mob-village)

これによって、自分だけではなく他の参加者たちも言語化をより深めることができる為、それを見て更に言語化をするという良いサイクルが生まれていきました。

これをやることにより、勉強会終わり際のふりかえりの中でも、自身の言語化や、他人の言葉から深堀りをする習慣が自然と生まれていきました。

3ツイ・ルールの話は、こちらの記事でも書いています。

勉強会を設計することについて考える - jnuank blog

チームの掟

勉強会はオンラインモブでやっているので、チームでの活動が主体となります。 活動中は、モデルやコードの書き方への議論が多くなっていきます。

議論ではどちらが絶対的に良い、悪いというのはあまり無くて、議論をしても決めきれないことが多いです。 そこで自分たちが打破したいのは「停滞」でした。

「喋って議論して、何も決まらずに終わってしまった」ということもあった為、勉強会(とチーム)の大事にするものとして、「チームの掟」というのを決めました。

いわゆる「ワーキング・アグリーメント」に近いものだと思います。

以下、チームの掟となります。

  • 論よりコード、論よりモデル
    • 口頭で議論するなら、コードや図を並べて議論すべし
  • 無責任デリゲーション (っ'-')╮ =͟͟͞(責任) ブォン
    • 迷ったら誰か1人に無責任に決断を委ねるべし
      • 多数決はスピードが出ないので、「◯◯さん、決めてください」と無責任に投げる(この委譲に関しては合意している)
  • ワールドメーカー【俺がルールだ】
    • 誰かが提案したら、いいぞー!と称えるべし
  • まずは負けてみる(ゴン・フリークス@天空闘技場)
    • 実験なので、率先して間違うくらいの気持ちでいくべし

これらの掟を決めたことにより、失敗を許容する文化を作ることに成功しました。

勉強会は時間が限られていることもあり、「う~んどうしよっか~~?」で30分使うのは本当に勿体ないです。 このため、間違っていても良いから決めようという姿勢が大事です。

『負けてもいいんだ』 と思う事さえできれば、 「自分は普段やらないやり方だけど、今回はこっちでやってみようかー」となれるのです。

それで成功したら学びになりますし、失敗したらその理由を振り返ることでまた豊かな学びになります。

擬似コード作戦

先述した「チームの掟」にて

  • 論よりコード、論よりモデル
    • 口頭で議論するなら、コードや図を並べて議論すべし

と挙げました。

これはオンラインでもオフラインでも変わらないことですが、「会話だけでの意見交換」には限界があります。 いわゆる「空中戦」というやつなのですが、喋りながら前提条件や経緯が抜けていってしまい、 結果的に何も得られなかった、という事が多発しました。

そこで掟を作った結果、困ったり煮詰まったら コード、モデル にして見比べてみる、という事が出来るようになりました。

その効果は大きく、ただ声の大きい人や見栄えの良い意見だけが採用されるのではなく、 具体的なものを目にして見比べながら客観的な判断を下すことが可能となりました。


■ なんでやめなかったのか

継続するためには「上のフォーマットをただやる」より、以下の感覚を促す会にできるのが重要だと思います。

これらが、続けたい、学びたいという気持ちにつながりました。

曜日固定することで習慣化を促す

日程を決めて開催することが大事です。

勉強会初期では、平日だったり土日の昼だったりと、結構まちまちでしたが、最終的には「隔週日曜日の20時に固定」と落ち着きました。

これによって、隔週の日曜日に勉強会をするという習慣が生まれ、継続することに繋がっていったと思います。

まず負けてみる、という発想

前述したチームの掟です。 失敗しても良い環境を、早期に確立できたのは大きかったです。

それぞれがこれまでやってきた「勝ちパターン」に拘らず、他の人から聞いた「勝てるかわからないやり方」を積極的に試していきます。

一回転んでみないと、痛いかどうかはわからないです。 次第に、新しいことを試してみて、結果を見るのがやめられなくなり、 さらには 新しい負けが楽しみ になってきて、結果的に継続していくことができました。

いろんな手法が学べる

チーム開発、設計の話を含めてできる場になったのは大きいです。 音声参加、チャット参加、それぞれの立場の人たちが、自分たちの経験と織り交ぜてアドバイスをしてくれるため、それを試すことができました。

また、コミュニティ内で開催していたことで得たメリットもあります。 いろいろ悩んでいると、外からのアドバイザーがふらっと見に来て、「こうしてみたら?」「この手法使ってみたら」というアドバイスをくれました。


■ まとめ

今回モデリング会のフォーマットや考え方をまとめたことで、 冒頭で挙げた『せっかくDDDCJというコミュニティ内でやっているのだから、もっと実践したいという人を受け入れられる形にしたい』という課題を解決していく準備が整いました。

今後も、モデリング会への参加のハードルとなっている、参加する際の心得や考え方などを文章にまとめ、楽しく豊かな学びを得られる会へどんどんと進化させていきたいと考えています。

その際はぜひ一緒に学びましょう!