モブプログラミングを導入したいと思っていても1人で出来るものでもないですし、良さそうだなと思ってもやったことないと自信を持ってお勧めできないというところはあると思います。

弊社では、継続的にモブプログラミングをしているチームはまだあまりないのですが、興味のある人はいそうです。また、ジュニアの育成に悩むマネジメント層からの興味もあり、モブプロ 体験会を実施することになりました。

すでに5回実施して参加者からは好評を受けているその中身を紹介したいと思います。

職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。

• プランナー（プロダクトデザイン、企画、グロースを担う役割）
• デザイナー
• フロントエンドエンジニア
• サーバーサイドエンジニア
• QA(Quality Assurance)

また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
プランナー側には以下のような不満があり、

• エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか？)
• エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか？)
• エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか？, オーバーエンジニアリングしてないだろうか？)
• 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)

エンジニア側には以下のような不満がありました。

• 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
• 開発する機能に関して背景や目的があまり納得できない
• 開発する機能の優先順位がわからない
• プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする

​
そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない？とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。

• プランナー組織構造の都合上、1人のPOは選出しにくい
• QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
• 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)
  ​

私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。
​
この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。