こんにちは。ヤフー株式会社の宮川です。8月初旬にヤフーの社内のハッカソンInternal Hack Dayが開催されました。私は昨年からこのハッカソンに参加しており、オンライン会議の自分の顔を新鮮で楽しく！という記事も書いています。（関連記事：Zホールディングスのシナジー創出をテーマに、社内ハッカソン「Internal Hack Day」を開催しました）
今回一緒にハッカソンに参加したチームメンバーは同期で、全員が入社当初から、オンライン上で日々の業務開発を行っています。オンラインでの開発には慣れているものの、入社してから2年と若く、個人のスキルセットの偏りが著しく、ほぼ全員がバックエンド開発が得意という状態でした。このまま開発を進めると、フロントエンド開発やデザインの部分で時間を取られたり、特定の誰かに負担が偏るというのは明らかだったので、開発の体制を見直す必要がありました。そこでチーム内で相談した結果、モブプログラミング（以下モブプロ）を取り入れて、苦手な部分には全員で取り組むという方法を取りました。
この記事ではハッカソンの開発にモブプロを導入し、24時間という短時間の中でモブプロをどのように取り入れたのか、またその効果について紹介します。
なぜハッカソンにモブプロを取り入れたのか？
私たちは、ほぼ毎日Zoomを通して業務で開発をしています。チームメンバー4人全員がエンジニアで、先ほども書いた通り、普段の業務ではバックエンド開発経験が多いメンバーで構成されていたため、フロントエンドの知識不足による手戻りや追加の知識共有が発生してしまうことを減らすために、情報共有がしやすいモブプロを取り入れました。
また、昨年の開発でユーザーイメージが明確ではないアウトプットを作ってしまうという課題がありました。ハッカソンなどの短時間の開発では作り上げることばかりに意識が向いてしまうので、ユーザー目線を意識した開発の意思決定速度向上が必要だと考えました。
このようにチームメンバーのスキルセットの偏りや開発期間の短さを考慮した開発手法が必要だと考え、今回オンラインハッカソンでモブプロを取り入れるチャレンジをしました。
モブプロとは？
モブプロとは、複数人でコミュニケーションを取りながら実装を進め、知識をチーム全体で共有しながらモブ（開発の議論や実装を考える人）とタイピスト（モブの指示でコードを書く人）に分かれて行う開発手法です。
まず、周囲のモブたちがタイピストへ議論で決まった方針と具体的な実装方法を指示します。モブプロは単なる分業ではなく、タイピスト以外のモブによる認識合わせを行いながら、議論とアウトプットを出します。またペアプログラミングと異なり、モブが中心となり、開発を進めていくことが特徴です。
Tech Blogの中でもいくつかモブプロを紹介した記事があるので、よろしければ参考にご覧ください。
今回取り入れたモブプロの実施方法
今回オンラインでの開発であり同じオフィスにいるわけではありません。そこでコミュニケーションツールとしてはZoomを使いました。タイピストは常にZoomの作業画面を共有し、モブ達が共有画面に対して、開発の指示をするという方法を取りました。オンラインということ以外は、従来の手法と同じやり方をしています。
ハッカソン中は、モブの立場で常にアイデアや実装に関する議論へ参加することで、情報が共有され、開発の意思決定がスムーズに進められました。そして、議論をし尽くした上で成果物を作り出すことができたと感じています。
モブプロを導入してよかったこと・改善したいこと
今回のモブプロで実感できた効果や次回改善したい点を紹介します。基本的には取り入れてよかったと感じることが多かったのですが、モブプロは中長期の開発手法なので、短期間の開発にそぐわない部分もありました。
よかったこと：コミュニケーションが容易になり、相談や議論が行いやすくなった
モブプロを導入したことで、チーム内でのコンテキスト一致や開発方針の合意が常に取れた状態で開発ができたため、非常に効率的だと思いました。メンバー全員がリアルタイムに知識を共有しているので、情報共有の時間が不要になり、開発に注力できました。
例えば、24時間という制約の中では、素早くプロダクトの方向性を決断しなければなりません。そんなときも、妥協する機能や集中して開発する機能が瞬時に決まるということがありました。また、システム構成を検討する際も、全員の頭の中に同じような利用イメージがある状態なので合意がすぐにとれました。
また私たちのチームでは、フロントエンド開発経験者が少なかったのですが、モブプロを実践することで、比較的フロントエンドが得意なメンバーがモブにいることで利用者目線のアイデアを取り込む機会が増え、開発速度と開発の安定感向上に加え、利用者目線に立ったプロダクト開発を行えました。
「この画面には反応ボタンがないと困ってしまう」「アシスタント機能を作るなら提案にリコメンドや学習機能がないと煩わしいだけで良さが伝わらない」といった意見が飛び交い、それをヒントに必要な機能の選定が迅速にできました。
改善したいこと：タイピスト交代タイミングは守る
私たちのチームは、スキルセットの偏りがあり、フロントエンド経験者が少ないため、モブプロをすることで苦手分野を1人に押しつけずに、全員で開発を着実に進めていくことができました。
一方、24時間開発ハッカソンという点を意識しすぎてしまい、できるだけモブプロの交代コストを減らそうとした結果、モブプロの効率が悪くなることがありました。
具体的には、本来はタイピストと呼ばれる人は1ポモドーロと呼ばれる約30分程度で次の人へ交代するルールとなっています。しかし少人数かつ短期間の開発ということもあり、時間を忘れて作業に熱中してしまい、気がつくと4時間もタイピストが変わらないということがありました。結果的に疲労による開発中のミスが増えてしまうということがあり、これはよくないと反省しました。次回は交代コストを減らす工夫を取り入れたいです。
モブプロ以外の工夫
モブプロを取り入れることで、「誰が何をしているか」を自発的に意識することなく、開発を進められました。
分業ではなく、モブプロでは常時質問や議論が行えるため、常に個々の懸念事項が共有されている状態となります。しかし、懸念事項が多いと把握するまでに、忘れてしまうということが起きました。そこで、モブプロだけを導入するだけでは不十分だと思い、タスク状況をわかりやすくするために、GitHubのカンバン方式によるタスク管理機能やZoomを開発画面の共有以外でも活用したモブプロをチーム開発に取り込みました。
GitHubで利用可能なProjectsという機能を用いてカンバン方式でタスクを管理し、チーム開発を行うことで、やるべきことが明確になり開発に集中できました。加えて、GitHub Projectsのタスク管理を軸として、開発時間の大半をモブプロで行い、1タスクごとにタイピストを交代するという形でチーム開発を進めました。
チーム開発の成果と振り返り
今回のモブプロでは、手を動かしながら「この実装でいこう」と素早い意思決定と開発を短期間で行い、非常に良い経験ができました。加えて、不足しがちなコミュニケーションの活性化によるチームビルディングの強化も行えました。また、業務以外の機会で同期との交流やお互いの得意分野を生かしながら開発できたのが良かったです。
このハッカソンでは、わたしたちは個々のライフスタイルに最適化できる家事アシスタントアプリ「kazzy」という作品を作りました。
結果的には、モブプロでハッカソンを行うことでチーム全体で開発に取り組みやすくなり、メンバー全員が納得した開発が行える状態を作り出せたと感じています。
来年は技術面と利用者へのメリットをより伝えられるようになるために、よりユーザー目線と開発者目線の両方を意識したチーム開発を行っていきたいと思っています。
おわりに
24時間というハッカソンにモブプロを導入してみましたが、改めて時間を区切ったペース配分や開発速度の安定化・高速化を感じることができました。普段の業務においても、モブプロの時間管理をより厳格に管理することで、ミスの少ない安定した開発を行っていけるのではないかと感じました。
一方、開発中のソースコードの差分を見て、進捗状況を確認することが必須となり、この部分は合わなかったと感じています。次回はソースコードの共同編集等の機能を活用して改善していきたいと思っています。そして、今後とも安定したチーム開発ができるようになっていきたいと考えています。
また、スクラム開発手法（関連記事：ヤフーとベトナム拠点の海を越えたスクラム開発の話）といった手法も併用することで、チーム開発を成熟させていきたいです。
最後まで読んでいただき、ありがとうございました！
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
- 宮川 慎也
- エンジニア
- サーバーやソフトウェアの修正・管理をしています。
