年末から4回に分けて、来栖川電算内でモブプロ会を実施しました。 参加者の声や様子をお伝えします。

「モブプロ」とは？

• ● 3人以上の人々 が
• ● 1台のコンピューター の前に座って
• ● 協力しながら 問題を解決していく

基本的には、参加者を以下のように分けて実施します。

1. タイピスト： 1人
2. モブ： その他

タイピストがコードを書いていき、コードを書くためのアイデアはモブが出します 。 モブは基本的にコードは書かず、問題解決のためのアイデアをタイピストを含むその場の全員に説明する役割です。

モブプロは、IT系企業で取り入れているところも多いのではないでしょうか。

来栖川電算で、モブプロを通じたスキル習得について声が上がったことを受け、現在までに計4回実施されました。

来栖川電算のモブプロの特色

リモート開催→ 面着開催へ

当初はリモートでVS Code Live Shareを使った実施でしたが、接続のトラブルシューティングに時間を取られることが多かったため思い切って「面着で」実施しました。

顧客役の「アドバイザー」を置く

また、来栖川電算のモブプロには「アドバイザー」として、 顧客役＆全体を見渡して意見をする役割の人 が参加しました。 モブプロのお題として出されたものについて要件がわからない所は、アドバイザーに意見を求めるやり方を取りました。

実際、やってみてどうでした？

コーディングスタイルの違いに気づいた

• ● 自分のスタイルは→ 処理をベタ書きで書いて後で関数化
• ● タイピストのスタイルは→ 関数名・引数・戻り値の型で全体像を定義してから中身を作っていく

異なるスタイルで実装が進むさまを目の当たりにして「これは取り入れたい」と強く思いました。

**関数の ** docstring や、型の説明や仕様をしっかり書いておけば よかった

「ここに入ってくる引数はこういうものだという仮定があります」と説明することが結構あったが、それを 明文化 しておけば混乱は少なかったと思いました。

また、アドバイザーから出た意見も掲載します。

「仕様を満たしているか」を常に意識したい

実装に邁進しすぎることで、要求仕様への意識が薄れることはなかったでしょうか？

breakpoint ではなくテストを実装する発想もほしい

「ここまで作ったやつはちゃんと動くかな？」を見るときに、焦ってbreakpointを設置して動かすよりも「仕様を満たすにはこのテストがいる」という発想で、いったん「テストを実装する」という発想があると良いですね。

おわりに

全体としてのまとめで、モブプロ会の振り返りをしました。 その際に出たコメントには以下のような物がありました。

• ● チームコミュニケーションの活性化には良い
• ● リアルで集まってワイワイやれたのも良い
• ● お題に沿って取り組むのは、現実問題として工数が純増である

今後も、モブプロかあるいは形を変えて「スキルを習得する機会」の提供や開催を続けていく予定です。

---

来栖川電算では、一緒に働くメンバーを募集しています。 来栖川電算にご興味を持たれた方は、ぜひ採用ページをご覧ください。