こんにちは!
システム統括本部の長谷部/渋谷/佐藤/榎本です。
前者の3人はヤフーの通知機能を担当するチームで開発をしています。
詳しくはこちら
新型コロナウイルスの影響で多くの方がリモートワークで仕事をされていると思います。
今まで同じ場所でチームとして仕事をしていたのにリモートワークになったら、個別作業になり、協力しての仕事がしづらくなったという話をよく聞きます。
僕らのチームも皆さんと同じように、突然全員のリモートワークが開始されました。
ただ、僕らはこのような状況下になる前からモブプログラミング(以下モブプロ)を導入していたため、生産性を落とさず、チームとしての協力体制を変えずに開発を続けることができています。
僕らがこの状態にいたるまでの経緯をお伝えすることでリモートでの働き方のヒントとなれば幸いです。
*ちなみにこの記事もモブプロで執筆しています。
モブプログラミングとは |
---|
ソフトウェア開発のやり方の1つで、チーム全体で1つの仕事のみを一緒行い、キーボードも1つで、画面やコンピューターも共有してチーム全体で1つの作業のみを行います。 モブプログラミングで感じたメリットについてはこの記事で細かくシェアしますが、コミュニケーション、知識共有、技術品質、スループットなどの課題に対して有効だと期待され、採用されている事が多そうです。 モブプログラミングを最初に始めたHunter Industries社のチームのモブプログラミングの1日の様子は下記の動画で見る事ができます。 A day of Mob Programming |
なぜモブプロを採用したのか
チームでは以前からスクラムを導入しており、アウトプットの低下に課題を持っていました。
特定の技術やプロダクトに対する知識が業務歴が長い人(エキスパート)に偏り、突然の休暇や離席で属人化している課題がチームに新しく参加した人(初心者)だけでは解決できない状態でした。
具体的には以下のような問題が発生していました。
- 似たような質問が何度も発生することにより、エキスパートの作業が止まる
- エキスパート同士で議論が進み、初心者がついていけない
これらの点がチームの生産性向上の阻害要因となっていました。
そこで解決案として、他チームが採用していると聞いたメンバーからモブプロ導入の提案がありました。
フルリモートでモブプロするまでの道のり
ここではモブプロを採用してから、アウトプットの改善までの課題や解決策をタックマンモデルに照らし合わせて示しています。
コラム:タックマンモデルとは |
---|
チームは機能するまでに形成期、混乱期、統一期、機能期という4つの段階を経るとする理論で、1965年にBruceTuckmanが初めて提案した。 私たちの仕事の進め方はみな少しずつ異なっており、それらの違いが意見の対立やメンバーの不満を引き起こすことがある。メンバーたちがそういった違いを見つけ、対立を解決し、うまく折り合いをつける方法を見つけていく時期を混乱期と呼ぶ。 モブプログラミングでは、混乱期は人々が作業スタイルの違いに気付く比較的早い時期に始まる。メンバーがそれぞれの仕事をするチームと比べれば混乱期の始まりはかなり早い。 (中略) [引用]マーク・パール. モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める (Japanese Edition) (Kindle の位置No.554-559). Kindle 版. |
どのように始めたのか(形成期)
アウトプットの低下の対策の振り返りから導入が決まり、次に挙げるルールで実践しました。
チームの状態
この時点で効果が現れたのが以下の2点です。
情報共有の速さ
同じ画面で作業をし、同じ問題に詰まり、質問への回答をメンバー全員が聞いているため、情報共有の速さは想像以上でした。
進捗の共有
全員でタスクに取り組むため、進捗の可視化が必要なくなりました。
モブプロに対する不満を解消していく(混乱期)
前述のようなメリットありましたが、混乱期は成熟していないことによる成長痛の伴う時期でした。
中止したい気持ちとメリットのせめぎ合いの中で、日々モブプロに対するネガティブ要素を打ち消していました。それぞれの課題の不満な点と追加したルールを書いていきます。
コラム:モブプログラミング・ベストプラクティスとの出会い |
---|
形成期にモブプロを体系的に学ぶためチームでモブプログラミング・ベストプラクティスを読み、教科書通りのモブプロを実施しようとしていました。 この本からチームに採用できそうなルールをまねしたりアレンジしたりしました。 これからモブプロを始める方にとてもおすすめできる本なのでぜひ読んでみてください。 |
開発環境
不満な点
朝一番に席についたメンバーのPCでコーディングして、PCの所有者はメールやチャットが確認できない状況でした。
他のメンバーも慣れないキーバインドで普段通りの操作ができず、ストレスがたまっていました。
追加したルール
モブプロ専用のPCを用意して、以下のように使用しています。
- 各自好きなキーボードを接続
- ブラウザーのユーザー機能でブックマークを切替
- 必要なソフトを全部入れておく
- キーバインドは同意の取れた最低限のカスタマイズにする
これにより切替が瞬時にでき、個人が占有されることがなくなりました。
リモートワークについて
不満な点
リモートで勤務しているメンバーは、リモートデスクトップでオフィスにあるPCを操作していましたが、遅延が大きく作業効率を落とす要因となっていました。
追加したルール
以下の機能を1コマンドで実現するオリジナルのモブコマンドを導入しました。
- commit & pushが1コマンドで実現
- 引数にアカウント名を記述するとcommitの共同編集者に追加
次の人はgit pullするだけで作業を開始できます。詳しくはこちらの記事をご覧ください。
交代のタイミング
不満な点
10分間隔で交代をするルールがありましたが、ドライバー(操作役)は「キリが良いところまで!」「時間測り忘れた!」とキーボードを手放さないことがありました。
ナビゲーター(誘導役)は「早く交代して欲しい」と思っていますし、ドライバー自身も気づかないうちに疲労がたまっていきます。ロスが積み重なり、1時間に1回はあるはずの休憩がどんどん後回しに・・・ときには2時間休憩なしなんてこともありました。これではチームが疲れ切ってしまいます。
追加したルール
交代と休憩を管理してくれるモブプロ用タイマーmobsterを導入しました。
mobsterは規定の時間を経過すると画面が暗転して、操作不可な状態になり交代を促されます。休憩のタイミングでも強制的に作業が中断されるため、長時間の作業でも適度な休息がとれるようになりました。
エキスパートの振る舞いについて
不満な点
エキスパートがドライバーをしている時に無言で進行することが多々ありました。
初心者が要因で進行が遅れていると、エキスパートには「自分の手番で遅れを取り戻したい」と焦る気持ちがうまれるようです。しかし理解の追いついていない人を放置すると、チームの成長につながりません。
追加したルール
エキスパートはナビゲーター役に固定しました。これは知識の共有に専念してもらうこと、初心者になるべく多くの経験をさせることを意図しています。エキスパートは初心者からの質問に集中できるため、さらに知識の共有が進みました。
形のないものに議論をしない
不満な点
実装方針やアルゴリズムについて議論を始め、何もアウトプットのないまま次の人に交代して実装が進みませんでした。
追加したルール
まずは概要をコードや図を書いて、それから議論するという方針にしました。たとえば
if(配列にAを含む){
ここに処理を書く
}
のような感じでやりたいことを記述してから議論をします。
実装の際に議論が頻発するのは設計が不十分だと気付いたため、計画時に入念に実装のイメージを全員で共有することにしました。
チームの状態
モブプロを始めた頃と比べ、メンバーが実力を発揮できるようになりました。
具体的には形成期と比較して、以下のような変化がありました。
- 基礎的な知識が初心者に浸透したため、質問でエキスパートの作業が中断されづらくなった
- エキスパートとの議論にも初心者が積極的に参加できるようになった
コラム:改善続けた理由 |
---|
ここまで読んだ方からするとでデメリットの方が多く見えるかと思いますが、それでも僕らのチームは1つ1つの課題について、取り組みました。 それは情報共有の速さというメリットもありましたが、モブプロを開始した時点でチーム内で3カ月頑張ることを合意していたことが大きかったと思います。 振り返ってみるとすぐに効果が出るものではなかったので、ある程度腹を決めて続けることがよかったです。 |
一体感が生まれ成果が出せるようになってきた(統一期・機能期)
3カ月ほど経過するとチーム全体のアウトプットがモブプロ開始以前と同程度かそれ以上になりました。
また、OJTで配属されたメンバーをモブプロに組み込んでもアウトプットに影響はありませんでした。それらの積み重ねにより、モブプロで進めることに確かな自信を持つことができるようになりました。
追加したルール・改善した点
この時期を振り返ると不満の改善ではなく、開発やコミュニケーションの効率を向上させる工夫の追加が多くありました。
具体的には以下のルールが整備されました。
テスト駆動開発(TDD)、ドメイン駆動設計(DDD)の導入
設計と実装の品質を担保するために、TDD・DDDを導入しました。
体系的な手法を取り入れることで認識を合わせやすくなりました。
トレードオフスライダーの導入
プロダクトを良いものにしたい気持ちから、納期と品質の優先順位についての議論に熱が入り、平行線になることがありました。
納期や品質は対立関係にあるため、トレードオフスライダーを作成し、素早い意思決定を行うようにしました。
一週間の動きをシミュレートする「これでほんとに終わるの?」
次週行うタスクがリモート勤務・有給取得・朝礼などを考慮し忘れていたことで、計画通りに終わらないことがありました。
そこで、曜日ごとに取り組む課題を書き出してシミュレートし続けることで、無理なく完了できるアウトプットが正確に予測できるようになりました。シミュレート通りにタスクが進んでいると、「今日ここまで終わっていればいい」という安心感と達成感が得られます。
任意の時間に20分休憩
1日1回まで20分間好きな時間に休憩を取れるルールを作成しました。
モブプロでは人の出入りが自由にできるため、好きな時間に休憩をとっても生産性を落とさずに開発が進められます。また、夕方には疲れてしまうので20分休憩を活用することで高い生産性を保つ狙いもあります。
ミーティングもモブプロで
あらかじめ共有されたフォーマットを確認しながら進めることで、誰が司会になってもミーティングの目的からずれないようにすることが狙いです。進行に徹する司会を交代で行うため、全員がアイデアを出せる活発なミーティングになります。
【フォーマット】
○ゴール・アウトプットは何か
○なぜこのミーティングが必要か
○アジェンダ・論点・課題点
○時間
○作業場所(付箋ミーティングツールのURL)
チームの状態
モブプロをしていると、成果が個人ではなくチーム全体でシェアされるようになります。
ヤフーでは個人を評価する仕組みがあるため、その際に「モブプロをしていました」だけでは評価されづらいというのが正直なところです。そのため、私たちのチームでは自発的に課題を見つけることが大事だととらえて動くメンバーが多いように思います。
おわりに(執筆者からそれぞれ)
モブプロによって突然の自宅待機命令を含め多くの課題を乗り越えてきましたが、「新しいメンバーが参入した場合に雰囲気になじめるか」「モブプロを実施しているメンバーの評価が難しい」「ビデオ会議ツールで複数の会話が混線する」「表情が見えないので会話がすれ違ってしまう」など課題は山積しています。
しかし、私たちはモブプロの価値を感じているので今後も課題を解消していきたいと考えています。
最後にこの記事を執筆したモブプロのメンバーからのあいさつとして締めとさせていただきます。
長谷部(@persimmon071)より
非常に不安な中始まったモブプロでしたが、今では当たり前の光景になっています。
今回の施策は働き方を現場に一任してくれるヤフーだからこそ実現できた部分もあり、このような形で発信できたことにとても感謝しています。僕たちのチームではこのような取り組みもしているので、ぜひご覧いただけると嬉しいです!
渋谷より
初めは効率が悪い手法なのではと思っていましたが、今ではモブプロなしでは自分の仕事を語れない状態になっています。
この記事を読んでモブプロを導入するチームの参考に少しでもなれば幸いです。
佐藤より
ハッピー佐藤(@pimsato)です。
このチームに入ってからずっとモブプロ導入を叫んでいました。
そして今文化として根付き、記事にするまで至ったのが感慨深いです。
手法に縛られずに、みんなが幸せな働き方を模索できていて最高なチームだと思います!
榎本より
コロナウイルスにより、リモートワークとなり、チームで仕事をする事の難しさを感じている方々に働き方の1つの選択肢としてリモートモブプロの事例をリアルな体験として共有頂けた事をうれしく思います。
この記事がリモートでチームワークの改善をしていく助けとなれば幸いです。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
- 渋谷 峻
- バックエンドエンジニア
- 通知系のプラットフォームを担当しています。家庭菜園やポケモンGoが好きです。
- 榎本
- アジャイル開発支援
- 社内でのスクラムの導入支援をしています。