モブプロ体験談とデータサイエンスへのモブプロ適用の可能性について

はじめに

こんにちは。
某SIerでSEをしている@daisuke19891023です。

今年の頭くらいから@TAKAKING22さんの記事とか、Pod Castのお話を聞いて、
モブプロ楽しそうだなー、とかモブプロやってみたいなーとずっと思っていました。
幸いなことに夏くらいからモブプロを実践する機会に恵まれ、色々経験させてもらったので、恐れ多くもアドカレに書き込みたいと思います！

本記事の目的

• モブプロをやってみたい方向けに、とにかくやってみるとどうなったかということをお伝えします
• あまりモブプロとセットで語られることのない、データサイエンス領域とモブプロの親和性をお伝えします（こっちはこれから実践していきたいという決意表明）

※モブプロの効果や素晴らしさは随所で語られているので、この記事では割愛致します！

モブプロ体験 PoCアプリ開発

概要

詳細は伏せますが、今年の夏頃に、アジャイルでとあるPoCアプリを開発しました。
その際は自分がプロマネであり、開発規模も小さかったため、強権発動してモブプロで開発することにしました！

• 環境や作るもの
  • 某クラウド上に某SPAでサーバレスなアプリを作るというもの
• 期間
  • 2-3ヶ月
• 人数
  • 6人（途中でメンバーが2人out＆2人inという感じだったので、MAX人数は4人）
• モブプロを選択した理由（押し通すための方便ともいう）
  • 部署の性質上、参加メンバーが兼務を抱えていたため、誰かがタスクを抱えるという状況を避けたかった
  • 自分も含め、選択した技術要素に詳しいメンバーが居なかったため、全員でレベルアップを図りたかった
• 場所 　- 会議室（途中からは事務所にあるリーンな雰囲気のスペース）。自分のデスクから離れるの大事！
• 時間
  • 9:30-18:00（集中力の続く定時内）でほぼ毎日実施

やり方

陣形

よく見るモブプロの画像とは違いますが、
自分たちは4人掛けのデスクの両端にモニタを置きました。
モニタを2つ用意した理由としては、開発中調べることが多く、その結果を共有するためです。
調べたりすることが多いので、各自がPCをもちながら作業しました。

あとは、必ずホワイトボードのある会議室を選びました。
後述しますが、ホワイトボードの威力がやっぱり高かった気がします。

進め方

モブの進め方は以下の感じで進めました。

朝会

朝会はやっぱり必要でしたね。
その日実施するIssueを確認し、かつそのIssueをこなすかをホワイトボードにイメージを描きながら、メンバーの認識を合わせていく作業を行いました。

開発

交代の契機は以下の2パターンで進めました

• Issueをやり終える（きちんとプルリクエストまでやる）⇒そのためにIssueは細かく分割（これも朝会中にみんなと話しながら分割しちゃいます）
• ドライバーの時間が1時間経過する⇒本当はポモドーロテクニックっぽくやりたかったですが、どうしても開発中は夢中になって時間が過ぎてしまうので、だいたい1時間を交代の目安としました

あと、交代する際は必ず休憩を挟みます。プログラミング作業は集中力が必要な知的作業なので、細かい休憩は取った方がいいと思います。

夕会

認識は常に同期されているので、改めて話すことはなかったです。ただし、残業するかどうかはメンバーと話して決めていました。
無理に帰るよりも、キリがいいところまでやった方が良い場合もあるので。
そこは皆の認識がある程度揃っていたので毎回揉めずに決められていた気がしています。

生々しい所感

↑の内容をある程度構造的に書いていたので、ある程度うまくやってたんじゃないの？という印象を受ける方もいたかもしれませんが、これ以降は清濁併せた感じの所感を書いていきたいと思います

前半（チーム結成＆スプリント開始時）

いきなりアンチパターンを踏んでしまった感があったんですが、メンバーが誰も精通していない技術を選んでしまったので、何か引っかかる要素があると開発は全然進みませんでした。

上手くいくときのパターン

仕様をホワイトボードで話して決める→プログラミングを始める→実装がわからない→調べる→それっぽい解決策が見つかる→プログラム書く→実装が上手くいく→みんな喜ぶ

上手くいかないときのパターン

仕様をホワイトボードで話して決める→プログラミングを始める→実装がわからない→調べる→それっぽい解決策が見つかる→プログラム書く→が、ダメ・・・→また調べる（以下繰り返し）→段々みんな無言になっていく
この時の雰囲気は、ちょっと辛かったです

対処方法

銀の弾丸的な解決策はなく、基本的には上手くいかないパターンの繰り返しばかりでしたが、
それで試行錯誤していくというのが基本スタイルでした。
日々の振り返りで出た意見を取り入れ、以下のような改善をして少しはましになっていきました

• 調べた内容や試したことをホワイトボードに書き出す（口頭だとだんだん分からなくなっていくので、皆の見えるところに書きだすのが大事）
• もう割り切って、その部分をスキップする。大まかな調査は誰かに割り当てる（モブで全員が時間を消費することはない）

兼務は厳しい

色んな所で言われていますが、やっぱり兼務は厳しかったです。
抜けるも戻るも自由がモブプロの長所でもありますが、やはり数時間抜けた後からキャッチアップするのはかなり厳しいです。それが続くとキャッチアップするばかりになってしまうし、抜けているメンバーも、段々貢献出来ていないことに申し訳なさを感じてるように見受けられました。

それでも楽しい

色々厳しかった旨を書いていますが、それでもモブプロは楽しく感じました。
上手くいっているときもそうじゃないときも、その感情をメンバーと共有できているため、すごく一体感を持って仕事に取り組むことができました。

メンバー（自分も含む）が日に日に成長していくのも、実感できました。
昨日分からなかったことが今日わかるように、明日の業務に活きるようになる。その感覚がとても充実感がありました。

後半

メンバーの交代

上に書いた兼務メンバーの、兼務側業務の比重が段々と大きくなっていったため、結果的にメンバーが入れ替えになってしまいました。

• 兼務メンバーが2人out（実際はすっぱり切れたわけではないため、たまにモブに参加しに来てくれていました）
• 新メンバーが2人in

交代を言い渡された当初、いきなりモブに入ってもキャッチアップは厳しいと感じました。
通常のウォーターフォール開発でもメンバー参入時はキャッチアップには相当時間もかかるし、炎上プロジェクトのヘルプなどもやることの範囲がテストやbug fix限定されているのに対し、途中参加のモブは短期間で全容を理解しなければいけないので。

交代はスムーズにできた

ただ、上記の書いたことは杞憂に終わりました。
まず、抜けたメンバーからの引継ぎはありませんでした（不要でした）。
ずっとモブプロを、やっていたので、離脱したメンバーだけがもつノウハウがない状態を担保することが出来ていました。

追加メンバーが幸いにもかかわらずSPA開発に精通していたこともあり、アプリや、プロジェクトの概要を伝えるだけで開始することが出来ました。
（この概要を伝える際もホワイトボードは大活躍でした）

効果が出始める

メンバーの交代はありましたが、後半になって、段々とモブプログラミングの効果が出始めました。

• 開発の速度が上昇 　- 開発におけるリズム（ブランチ作成～修正～マージ）に慣れてきました 　- メンバーの技術力があがり、問題解決の速度が見違えるほど早くなりました
• 仕様に対する意見、議論が活発になる
  • 開発の前半は私が仕様を伝え、それをどう実装するかが議論の焦点でした（Howを議論）
  • 後半はメンバー全員が仕様のあるべきや、もっとこうした方がいい、など仕様・要件よりの議論が活発になりました（Whyを議論）
  • それらの議論を経て取り組んだ仕様がアプリのUXや品質の向上に寄与しました

やはりモブプロはすぐに効果が出るような代物ではなく、
やはり１か月程度は効果が出るまでかかるものだと思いました。
ただし、今回はチーミングから始めたため、慣れ親しんだチームに導入するということであれば、効果が出始めるまではもっと早いかもしれません。

結果

結果としてアプリ開発は成功に終わりました。
納期前には十分にリファクタリングする時間が取れましたし、ユーザからの評価も概ね好評でした。

最後の方は、このチームなら何でもできるという謎の万能感を獲得するまでに至っていました。そのくらいチーム状態は良いものになったので、もっと長期間のプロジェクトであればさらに価値を出していけたんじゃないかなぁと思いました。

私が感じたモブプロの良さ

上記のモブプロ体験を通して私が感じたモブプロの良さを簡単にまとめたいと思います。

学習効果の高さ

やはり学習効果の高さは驚きでした。一人で開発したり、勉強したりするよりも効果が高いように感じました。

一人でやるときは何を調べればいいか、どう調べればいいか、Googleで検索するキーワードは何かが最初は分かりません。
しかし、モブプロを通じて、他の人のやり方や意見を聞いて、わからないことの調べ方は習得できたと思います。
一人で悶々と悩んで苦労して、やっとの思いで解決するという経験も貴重だとは
思いますが、楽しみながら学んでいくという観点ではモブプロの学習効果も
かなりいいものだと痛感しました。

管理作業からの解放

SIerだと管理作業にすごく追われます。理由は、やはり認識同期を行うためです。
通常だと個々人に作業を割り振り、同期するために打ち合わせを設定するところ、
モブプロだと常に認識が同期された状態となるため、その分のオーバーヘッドが減ります。

この恩恵をもろに受けるのはPMであったりPLだと思います。
実際に私が体験しただけでも、以下のような管理作業が不要になりました。
- レビュー（完全になくならないにしても、時短効果あり）
- 朝会
- タスク分解（人のスキルや空き状況、クリティカルパスの考慮は結構大変）
- 情報共有のためだけの定例会

なので、人を管理する仕事についている人こそ、モブプロを実践してみる価値があると感じました。

データサイエンスへのモブプロ適用の可能性

ここまですごく開発者寄りな内容をまとめてきましたが、一応私の業務の本分はデータサイエンス領域です。
私はまだまだこの領域に入ったばかりで未熟者ではありますが、データ分析作業とモブプロは親和性が高いんじゃないかと考えています

親和性が高い理由

属人性の高い作業

データ分析におけるコーディング作業（pythonにせよ、Rにせよ）はきれいに行う必要はありません。1,2回動いて結果が見れればいいし、とにかく試行錯誤しなければならないので、例外処理なんかも不要であることが多いです。
そのため、分析した当人しか分析スクリプトの詳細がわからないという状況が発生しがちです。

ここに対し、モブで分析作業を行うことで、1人だけしかわからないコードの生成を防ぐことができます。
また、分析に必要な知見は広く獲得しておく必要があるので、それを熟練者から学び取るという意味でもモブプロは効果が高いと感じています。

レビュー・説明が必須

仮に一人でデータ分析を行っても、最終的には結果報告が必要となります。
データの統計情報や探索的データ分析の結果、AIであれば学習モデルの精度の説明など、
報告内容は多岐に渡り、レビューは必須です。
作りながらレビューする形のモブプロとの相性は良いと感じています。

Jupyter Notebookは共同利用しやすい

データサイエンス（少なくともPythonを使う人）はJupyter Notebookを使うことが多いと思います。
Jupyter Notebookは対話型でPython(RやJuliaも）を実行できるツールで、
実行したいコードのすぐ下に結果が出力される形式になるため、
少しずつ、結果を確認しながら分析を進めていくことができます。
癖の弱いツールですし、サーバに建ててしまえばブラウザ経由でアクセス可能であるため、
コードと結果を確認しつつ進めるスタイルは、モブと近しいものを感じます。

まだ可能性なので試す必要がある

上記で可能性について書きましたが、実際やるとなると課題山積みです。
学習に時間がかかる、JupyterNoteBookはGit管理に向かない、要件（試行すべきこと）は後から出てくるなどの課題がまだまだありますが、来年のモブプロアドベントカレンダーまでには色々試してみて、その結果や考察を書きたいと思います！

それでは、良いモブライフを！