はじめに
今回は、私たちのチームのモブワークについてのエピソードをお話していきたいと思います。
私たちのチームは、スプリント中に行うタスクをほぼチーム全員でモブで行うようにしています。私の過去の経験上ではありますが、そんなチーム・組織はこれまで出会ったことがありませんでした。
そもそもアジャイル開発自体お目にかかったことがありませんでした。
大体がマネージャーがいて、担当業務を行うエンジニアがいて、マネージャーの指示によりエンジニアが作業する、いわゆる縦割り組織が多かったです。
そんなところも、私がこのチームに入ってきたときの驚きの１つでした。
そんなチーム状況・環境に身を置けることは、本当にありがたく、とても恵まれているなぁと日々感じています。
初めてのモブ体験記
ちょっとだけ脱線して、私の初めてのモブ体験記もお話していこうと思います。
私が初めてモブを体験したのは、スクラムマスターの研修でした。
研修でもモブについてのレクチャーがあり、「すべての作業をモブで行いましょう」と聞いていて、「へぇ〜」と驚いたことを今でも覚えています。
実際にモブを実践してみるワークもありました。そのときのモブは、全員がエンジニア経験者ではない可能性もあるので、プログラムを書くワークではなく、お題を出されてその対する回答をメールする体でメール本文をモブで作成してみようというものでした。
メール本文を作るというワークだったので、どちらかというと内容を書いていくことより、書きながら本文全体の体裁を整えることが難しかったです。
特に自分がナビゲーターになったときに追加する文章は指示しやすいけど、出来上がった文章に直しを入れるのは、まだまだメンバー間の遠慮もあって指示しづらかったことを思い出しました。
そんな私の、はじめてのモブ体験記でした。
参考までに、下記は研修で見た映像で、実際にモブワークをやっている様子を観ることができます。
モブ（モブプロ）とは
ここで、一般的にモブ（モブプロ）ってなに？を確認してみましょう。
ここでは「モブ」と言っていますが、正確には「モブプロ」なのかな？
というわけで、ChatGPTに質問してみました。
以下がChatGPTからの回答です。
モブプログラミング（Mob Programming）は、ソフトウェア開発のアプローチの一つで、複数のプログラマーが同じコンピューターで協力してコーディングを行う手法です。モブプログラミングは、プログラミングチームが一つの課題に取り組む際に、集団的な知識共有と効率的なコラボレーションを促進することを目的としています。以下は、モブプログラミングの特徴と利点のいくつかです：
- チームの協力: チーム全体が同じタスクに従事し、一緒に問題を解決するため、知識やスキルを共有しやすくなります。
- リアルタイムの共同作業: チームメンバーはリアルタイムでコードを書き、アイデアやアプローチを共有しながら進行します。
- 知識共有: チーム内での知識共有が促進されるため、特定のメンバーが不在の際でも問題が解決しやすくなります。
- バグの早期発見: チーム全体がコードを共同でレビューし、バグを早期に発見しやすくなります。
- プログラム品質向上: 複数の視点からのアプローチやアイデアの組み合わせにより、プログラムの品質が向上することがあります。
- 集中力の向上: チームが一つのタスクに集中するため、生産性が向上しやすくなります。
モブプログラミングの実施方法は、チームやプロジェクトによって異なることがありますが、一般的には1つのコンピューターを共有し、1人がキーボードを制御し、他のメンバーがコードの設計、レビュー、デバッグなどの作業をサポートします。また、モブプログラミングはアジャイル開発やXP（eXtreme Programming）などのソフトウェア開発手法と結びついて用いられることが多いです。
モブプログラミングは、特に大規模なプロジェクトやチームでの協力を強化するために有用であり、コミュニケーションと協力が鍵となるソフトウェア開発プロセスに適しています。
私たちのモブプロの実践方法
私たちのモブ実践方法もご紹介したいと思います。
使っているツールたちは下記の通りです。
- MobTime
主には、下記のMobTimeを使って、メンバーの一覧を登録し、タイマー機能がついてくれるので、時間が来たら役割を交代して進めるようにしています。
私たちのチームでは、モブの役割はドライバーと、モバーしか設けません。これは過去に３役（ドライバー、ナビゲーター、モバー）でやってみたところうまくいかなかったことから、現在は２つの役割でやることになったそうです。
- gather
普段の作業はgatherというバーチャルデスクトップから行っています。
バーチャルなオフィス空間のミーティングスペースにチームが集まり、そこで画面共有と会話をしながら作業を進めています。デジタルなのにアナログで集まったりもする、不思議なツールですね^^
Gather Town（ギャザータウン）日本公式パートナー | 株式会社ローカルスクエア
- VSCode・Live Share
実装の環境面での主なものは、コードエディタは「VSCode」を使用しています。VSCodeのプラグインにある、「Live Share」を使って、ソースコードをメンバー間で共有することで、全員で編集することも可能になります。
Live Share とは何ですか? – Live Share
気がかりだったこと
最近、チームを観察していて１つ気がかりなことがありました。
それは、いつの間にかリードエンジニアがドライバーもナビゲーターもこなしている傾向が強かったことでした。
リードエンジニアが画面共有とソースコード共有をした状態で他のメンバーはリードエンジニアが作業しているのをずっと見ているということが多いなぁというふうに観察していました。これでも全員のスキルは向上するかもしれませんが、実際に手を動かすことも必要なのではないかと考えていました。
コーチにそのことを相談してみると、「聞いてみたらいいんじゃないですか？」というアドバイスをいただきました。いや〜確かに。そうなんですよね。聞けばいいだけの話なんですよね実のところ。
よし、頃合いを見計らって聞いてみようと思ってチャンスを伺っていたのですが、自分の中でなんとなくこのことを聞くのをためらっていました。ちょっとした怖さがあったのです。自分がこれを聞くことによって、チーム間の雰囲気が悪くなる、もしくはスクラムマスター（私）と開発メンバーとがギクシャクしてしまうのではないかという怖さがありました。自分の中ではこれを切り出す勇気を出せない。なぜ切り出すのが怖いのでしょうか？これはまだ私の中で答えが出せていないところでもあります。
躊躇しているところ、チームが会話している中でこれは！というタイミングがありました。
自分でもここはいいタイミングだというのは認識しつつも、言おうとしても言葉が出てこない。。コーチもこの機を逃してはいけないと、コーチの方からそっと救いの手を差し伸べてくださりました。
「ちょっとここまで○○がやってきちゃったので、他の人に交代してもいいんじゃないですかね？」
自然に、そしてエレガントにそんな問いかけをしていただきました。
するとどうでしょう、メンバー間で「確かにそうだね、じゃあ時間決めて交代しながらやっていきましょうか」という雰囲気に変わっていきました。
その後の雰囲気を観察していると、タイマーを測ってドライバーを交代し、周りから「こうしましょう」とか、「こうした方がいいんじゃない？」と言ったような声も見られるようになり、私の目から見てもいい雰囲気でモブが実施されているんじゃないかと感じることができたのでした。
さいごに
というわけで、今回はコーチに助けていただいて、スクラムマスターとしての私の未熟さを露呈してしまった回でした。
結果をふりかえってみると、なんとなく勇気が出せなかっただけで、今回コーチが言ってくれたみたいに、疑問や課題感があったら聞いてもいいし、聞いたところでメンバーの皆さんも耳を傾けてくれるということ。いったい何を怖がっているんだろう。。自分の勝手な思い込みがそうさせたのでしょうか・・
自分の中にある「恐怖心」のようなものの源泉は、いまだ解消されてはいないものの、いつまでもコーチに頼っているわけにはいきません。
スクラムマスターとして、「チームがより成長するには」ということを誰よりも考え、チームの成長のために必要な問いかけを続けていこうと、そう心に誓うのでした。
