リモートモブプロの社内普及のために人柱になってみた。

　あ～～モブプロやってみたい！！まともにやってみたい！！と思って、社内のコミュニティのイベントに無理やりこじつけてやってみたら、想像以上に楽しくて、ホント、ぜひみんなやってみて！！と思ったので使った環境とかデモのアジェンダとか、共有します。
　かなり突発で荒削りだったんで、もっといい方法があるよ、という方がいらしたら、教えて下さい！！

【経緯とか参加者】
　社内のアジャイルコミュニティに呼びかけたら、乗ってくれた方がいらしたので、2週間後くらいにやってみよう、くらいの簡単なノリで決定。結果的にコミュニティ全体に公開され、自分たちの醜態をさらす結果になりました！！
　参加者は、6人（当日機材の不調で結果的に5人）。ほとんどが初対面のかたでプログラミング経験も言語もバラバラ、地域も北海道から関東までバラバラ。（ホント、悪ノリに付き合っていただいて感謝）

【リモートモブプロ環境】
repl.it：リモートモブプログラミングに利用
（プログラミング参加者は事前にアカウントを作ってもらうように依頼、飛び入りの方はその場でアカウントを作ってもらう）
　※repl.itになった経緯は”【補足】リモートモブプロ環境調査”を参照

mural：当日の進行の説明とかふりかえりとかに利用
（事前にボードを作成、anonymousで編集権限をつえておいて、事前の情報共有から利用）

teams：事前の告知、モブ中の視聴者からのリアクション受け取り、モブ中の画面共有
（当日は負荷軽減のためモブ中の画面共有はなし、映像・音声のみを共有）

【アジェンダ・当日の進め方】
１．進め方共有・モブプロの説明（20分）
　※モブプロの説明は、日本で一番読まれている及部さんの資料を活用させていただきました
https://speakerdeck.com/takaking22/mob-programming-startup-manual-number-mobprogramming-number-mobupuro
２．テーマ決め、概要設計わいわい（20分）
３．モブ1回転目（25分=5人*5分）
４．中間ふりかえり（15分）
５．モブ2回転目（25分=5人*5分）
６．最終ふりかえり（15分）

【やってみての所感・気づき】
・中間と最後に視聴者含めたふりかえりを実施したが、実施のたびに学びのレベルが上がっている感じ
中間振り返りは四角のふせん、最終振り返りは丸のふせん。最終振り返りの方が、fun/done/learnの円が重なっているところのふせんが多い。振り返るたびに学びのレベルが上がっている感じ。

・初心者でも、初対面でも意外にやりきれる
私含めてモブプロに参加した5人は、python初心者でほとんどが初対面。
でも、最終的には自分たちで切った仕様のプログラムを完成させられた。

・参加者のスキルレベルの差については各種意見がでたが、レベル差よりもコミュニケーションがあれば埋められる
”熟練者＋初心者だと学びが大きいのでは”とか”みんな初心者だからうまくいったのでは”という両意見があったが、個人的には、”大丈夫？困ってない？”と声をかける雰囲気が作れれば、ググることでスキルの差は無効化できる印象。ただ、メソッドやクラスの切り方や処理順の様な暗黙知を共有するような目的がある場合には、”熟練者＋初心者”の方が面白いかも、と思った

・コスパはいい、と思った
作ったプログラムはfizzbuzz、言語はpythonで、初心者のみが集まった会だったが、途中pythonの言語仕様を調べ始めたりする場面もあり、部分的にかなり深いところまで学べた。モブの総工数は250分（25分*2回*5人）だったが、仮に一人でプログラム作れたとしても、あれだけの知識は得られないと思うので、かなりコスパ良い、と思った

・わからないことに気づく
仕様を切っているときも、例外処理で自分が気づかなかった様な仕様の漏れを発見したり、自分の発言がみんなの気づきを促して、プログラムがどんどん良くなっていくことを実感できた。あとは、自分のコーディングでの悪い癖やもっと良い書き方についても、どんどんフィードバックが得られるので、逐次改善されていく、のが楽しい

・モブは楽しい、を再確認
参加者はもちろん、視聴者は約20人、ほとんど退席することなく2時間見続けてくれた。視聴者からも参加したふりかえりでは、楽しそう、とか、自然と役割分担ができている、とか好意的なコメントをもらうことができた。
みんな楽しさを求めている、と感じた！！終わった後は飲み会やったくらいみんなフランクになった。飲みながらでも良いくらい。

【補足】リモートモブプロ環境調査結果

①vscode Live Share (GitHubのアカウントならいけるらしいよ報告アリ) 使う
　メリット：各自のキーバインドとか、補完機能とか、vscodeの設定をそのまま使える。後動作早い。ターミナルもシェアできるので、開発環境の差異も吸収できる
　デメリット：環境構築面倒なので、モブへの飛び入りハードル上がる
　（全員がvscodeインストール済、プロキシ設定完了済み、Githubのアカウント所持している必要あり。見るだけならブラウザのみでOK）

②画面共有：操作は１人がやる。別の人に切り替える際にはリポジトリ経由で（一旦pushして）後を続ける
　メリット：直感的、飛び入り参加が楽。
　デメリット：ただただ、通信速度が不安。あと人によって開発環境の差異が出る懸念あり
　→　モブに参加したい人、全員がgithub等のアカウントを所持していて、帯域が安定して100Mbps程度であれば、これもOK
　（ドライバ交代時にpush/pullするので、gitの環境が必要。社内サーバーに作ってもいいがそれも大変かなぁ。。）

③AWS workspaces：リモート環境を用意して、ドライバー変更時には、リモートデスクトップ環境ごと切り替える (及部さんち方式)
　メリット：参加者間で環境の差異がなくなる、高スペックマシンを使える
　デメリット：モブに参加したい人全員がクライアントツールを事前にインストールする必要があるので、飛び入り参加のハードル上がる。誰が契約して環境作るかの問題あり

④AWS Cloud9
　メリット：リンクをたどるだけで、開発環境にアクセス可能なので、飛び入りが楽。あとワンクリックで差異のない開発環境が構築できるので楽
　デメリット：誰が契約して環境作るのか、の問題あり
　過去に指摘あったIAM等の問題は、下記を参照すれば、解決しそう
　http://blog.serverworks.co.jp/tech/2020/02/26/cloud9-remote-development/

⑤repl.it：リモートモブ用のアプリを利用する
　メリット：環境出来てる、リンクから誰でも参加できる、動作早い
　デメリット：強いて言うのであれば、普段の開発環境からかけ離れているので、開発環境構築周りのノウハウの蓄積にはなりにくいかも