失敗前提のオンラインDDDモブプロ
去年の12月にオフラインでモデリング会を開きました(詳細は上記記事から)
そのモデルが、それなりに出来た感触があったので、オフで集まったメンバーたちで、オンライン上で実装をしてみよう、というのを1月から今も継続をしています。
一応最初の目標であった、モデル図にあったユースケースの実装をとりあえずは出来たので、先週ふりかえりの場を設けてみました。
それが以下のHackMDです。
実際にどんなことがあって、どんな良かったことや良くなかったところ、カイゼンすべきところ、次回試してみたいこと、などについて、興味があればHackMDをざっと眺めて頂けたらと思います。
DDDモブプロ会の立て付け
1月のモブプロ会を始めるにあたって、以下の検証目的と、懸念点がありました。
【検証したいこと】
・ ユースケースやルールを明示的に絞った状態から、実装してみようっていう会が成立するのか?(勉強になるのか、ならないのか)
【懸念していること】
・技術レベルのハードルがあるのでは? あるなら、何なのか?
・モブワークの良さとかではなく、純粋に「実装がメインの学びになるかどうか」
・どうやってオンラインで、うまくモブしてコミュニケーションを取り、コードに落とし込むか
・コミュニケーションをどう上手く取るかが課題
オンラインモブプロのツールやルールなど
オンラインでモブプロするときには以下のツールとルールでやってみました。
・GoogleHangout (画面&音声通話)← メイン
・Discord(チャット)← ふらっと来た人が茶々入れする枠
・ドライバー交代方式はGitHubでのPush-Pull
・日本語でプログラミングする(言語はC#)
日本語でプログラミングをする、というところはだいぶ特殊だと思われると思います。
理由としては、モデリング自体は日本語だし、それをそのままクラス名やメソッド名として落とし込んでいくには、そちらのほうがわかりやすそうだ、と思ったためです(その場にいたメンバーにも同意は取った)
まずは負けてみる、失敗をしてみる
最初はオフで集まったメンバー6人で、隔週に2〜3時間ほど集まりモブプロをしていきました。
最初は各自別の現場で、いろんな経験をしているメンバーたちなので、実装の方針や、命名規則、ロジックの置き場所などで議論をしたり(時には揉めたり)。
最初の2、3回は議論ばかりでコードを書かずに、コミットが全然出来てないことがありました。
そうなってくると、実装を通してDDDを学びたいという当初の目的が薄れてきてしまうため、途中でチームの掟を導入してみました。
ワーキング・アグリーメントに近いものだと思っています(たぶん)
掟、という少し仰々しい感じが、個人的には好きです。
また、実プロジェクトでも無いし、勉強会なので「率先して間違おう」と掲げたのも良かったと思っています。
議論が白熱しそうだったら、自分の信じるものをいったん捨てて負けてみる。
間違えてもいいくらいなので、自分の中では選ばなそうな選択肢に行ってみてどうなるか、実験をしてみる。
自分の中では、これが結構効果てきめんだと思っており、
メンバーみんながそんな気概になって取り組めてからは、コードを書いて試す。意見が割れるときは、いろんなパターンのコードを並べて品評する。
その結果として、コミット量は増えていきました。
自然に人が集まり、PRやワイガヤする環境が生まれた
DDD-Comunity-jpのDiscord上でやっていた為、そのうち気になった人たちがモブプロの内容を見に来たりして、音声参加をしないにしても、チャットで意見を言ったり、質問をされたりするようになってきました。
それに対してもラジオのパーソナリティよろしく、コメントの読み上げを行ったり、回答をするなどをメンバーたちが行っていきました。
この読み上げがポイントだと思っており、
ただ気になって、なんとなくコメントをする人たちも、参加をできるようになっていて、モブとして巻き込めていけたのだと思います。
これを現実でのモブプロで例えると、こんなイメージ。
赤点線で囲っているのが、1つのチーム。(ハングアウトで実際にコード書いたり、ナビゲーターする人たち)
それを少し離れて見ていて、ナビゲーターに対して意見を言うモバー。それをナビゲーターが拾うも拾わないも自由、といった形。
そうやって巻き込んでいけたからか、隔週のモブプロ会以外にも、メンバー以外からPRが飛んでくるようになりました。
なにげにこれが、すごい。
あらためて、当初の目的をふりかえってみて
【検証したいこと】
・ ユースケースやルールを明示的に絞った状態から、実装してみようっていう会が成立するのか?(勉強になるのか、ならないのか)
HackMDにあるふりかえり量から判断して、多くの学びがあったと考えられます。
一人は、実際にプロダクトコードの一部に日本語プログラミングを取り入れてみて、わかりやすくなったという意見。
私自身は議論を交わす時とかに、まず負けてみる考え方は、最近取り入れるようにしました。
実装に関して言えば、選択可能な時間帯をenumで表現したり、スマートなリポジトリを作ってみた良し悪しなど、まず自分では考えつかないような実験をして、良い方に傾いたり、やっぱり悪かったけど、その悪さを実体験と共に説明ができるようになる、というのは非常に大きかったと思います。
【懸念していること】
・技術レベルのハードルがあるのでは? あるなら、何なのか?
・モブワークの良さとかではなく、純粋に「実装がメインの学びになるかどうか」
・どうやってオンラインで、うまくモブしてコミュニケーションを取り、コードに落とし込むか
・コミュニケーションをどう上手く取るかが課題
使用している技術の違いはあるので、この辺りは仕方ないな、という感覚です。
ただ、やはり実験の場ではあるし、教え合うことも出来たので、技術習得という点では良いと思いました。
実装がメインの学びになったか、という点では個人的には少し違った気はしました。
実装ももちろん学びがありましたが、どうやって意見をすり合わせるか、オンラインモブプロをどう上手くやるかの学びの方が大きかったです。
コミュニケーションを上手くやる、という意味では今回はすごく成功したと思っています。
この記事が気に入ったらサポートをしてみませんか?