--- # モブプログラミングを導入するときに考えていること URL: https://agile-monster.com/blog/mobprogramming-advent/ Published: 2019-12-01 --- この記事は、モブプログラミングAdvent Calendar 2019 の1日目の記事です。 https://qiita.com/advent-calendar/2019/mobprogramming モブプログラミングに関するAdevent Calendarを、[昨年](https://qiita.com/advent-calendar/2018/mobprogramming)に引き続き今年も立ててみました。まだ空いている日があるのでぜひ飛び込んでみてください。アウトプットの年末調整です。 ## なぜモブプログラミングの導入についてなのか 今年もモブプログラミングについての講演、ワークショップ、現場相談会などをさせていただく機会がたくさんありました。そうした際に、 - 「どうやってモブプログラミングを導入すればよいですか？」 - 「モブプログラミングのファシリテートについて教えてほしい。」 など導入する側としてのアドバイスを求められることがありました。 モブプログラミング自体はかなり広まってきているものの、いざ自分の現場でやってみようと考えると、自分以外はモブプログラミングを知らない／やったことがないメンバーばかりなのでどうやって導入すればよいのかわからない、という状況が多いようです。 自分のチームでは導入してから（チーム転職も挟んで）2年半くらいモブプログラミングを続けています。それらの経験知を活かして、全員初対面のチームや普段一緒に働いているがモブプロは初体験のチームに対して導入ワークショップを何度もやらせていただきました。 というわけで、今回は **自分自身がモブプログラミングを導入するときに考えていること** をまとめてみます。 ## 想定する読者 - モブプログラミングをやったことがある／やったことはないがある程度知っている - モブプログラミングがなんとなくよさそうなことはわかっている - 実際に勉強会や現場でモブプログラミングをやってみようと考えている ## モブプログラミングを導入するときに考えていること 自分がモブプログラミングを導入するときに考えていることは、主に、 - ファシリテートしない - カオスを受け入れる の2つです。それぞれ項目ごとに見ていきます。 ### ファシリテートしない あくまで自分の考えですが、モブプログラミングを導入する際に外部からファシリテートをする必要はないと思います。むしろしない方がいいです。少なくとも自分がやるときはファシリテートしないようにしています。 現場でチームで働いているときに、常に近くに外部のファシリテーターがいることはありません。困ったときに正しいやり方を教えてくれる先生もいません。仮にいたとしても、その人がいないとうまく仕事ができない状態はチームとして不健全でしょう。だからモブプログラミングを導入するときも同じです。 モブプログラミングは、チームで考えて、チームで行動して、チームで学んで、チームで仕事をするアプローチです。むしろ、その「困ったときにどうするか」こそがモブプログラミングです。その学びの機会を奪うようなことはしたくありません。 もちろん、モブプログラミングに参加する場合は一人のメンバーとしてチームに貢献します。メンバーという立場で、チームの仕事を進めるファシリテートは必要です。必要ないのは、あくまでモブプログラミング自体のファシリテートのことです。 もし、モブプログラミングの外からワークショップを運営している場合は、モブプログラミングの最中は基本的には外部から口を出さないようにしています。何かを聞かれる場合がありますが、ほとんどの質問に対して「チームで考えてみてください」「仕事をしているときと同じですよ」と答えることが多いです。 モブプログラミング自体のやり方について学びを深めたい場合は、モブプログラミングが終わった後にふりかえりなどを行います。そのときであれば、見ているときに気づいたモブプログラミングの進め方についてのアドバイスを行ってもよいでしょう。大切なことは、モブプログラミングの特徴を理解した上でそれを学ぶことができる場を用意することです。 ### カオスを受け入れる 導入する立場だと、どうしても「うまくいかせたい」という想いが強くなってしまいがちです。ましてや先に成功体験をもっていたり、本などを読んでよい事例を知っている場合はなおさらです。 しかし、「うまくいかせたい」のは何なのかを考えてみましょう。ほとんどの場合、うまくいかせたいのはその場一回きりのモブプログラミングではなく、チームにモブプログラミングを活かせるかどうかを知ることでしょう。 モブプログラミングをしているときに、 - 全然コードにたどりつかない - 議論が紛糾して手が止まる - 声が大きい人がずっと話している - 特定の人がずっと教えている などいろんなカオスに出会うことがあります。ですが、モブプログラミングは仕事をしているだけなので当たり前のことです。カオスを受け入れましょう。 そもそもモブプログラミングをしているときに発生する問題のほとんどは、モブプログラミング＝進め方とは関係ないことばかりです。たいていはそのチームが現在抱えている問題が顕在化しただけです。モブプログラミングによってコミュニケーション密度が濃くなるので、問題が顕在化しやすくなりますし、ときには潜在的に眠っていた問題が見つかることもあるでしょう。問題が見つかったのであれば、それをどう対処するかを考えるだけなので焦る必要はありません。 ここで考えるべきなのは、問題が見つかったタイミング、見つかり方、そのときのチームの対応の仕方をどう捉えるかです。「いつもより早く見つかったね」「見つかってよかったね」と前向きに問題解決に向かえるチームであれば、モブプログラミングをうまくチームに取り入れることでよりよいチームになれるかもしれません。一方でもし問題を受け入れられないチームであれば、モブプログラミングをすることでかえって関係が悪化してしまうかもしれません。 うまくいかない状況に陥ると、人は安易に手段に原因を紐付けがちです。導入する側は冷静に、「それは本当にモブプログラミングの問題なのか？」「問題が見つかったことは悪いことなのか？」などの質問をチームに投げ入れてあげるとよいでしょう。 ## モブプログラミング導入に関するQ&A 最後によく聞かれることをQ&A形式でいくつか補足しておきます。この記事を読んで載っていない質問がある場合は、 SNSなどでぜひお気軽にご連絡ください。 ### いつ、どれくらいやるのがよいのか（初回） できれば半日〜1日くらいやれるとよいです。参考までに自分が実施するワークショップ（半日Ver.）のアジェンダを置いておきます。 - イントロダクション、準備（30min） - モブプログラミング 1（60min） - 中間ふりかえり（15min） - モブプログラミング 2（60min） - 成果共有＆ふりかえり（30min） - 講義：現場でのモブプログラミング、質疑応答（30min） 半日以上時間をとれると、中間ふりかえりをはさむことで自分たちのやり方を改善する機会をつくることができます。メンバーをシャッフルしてみることも出来ます。学びが多い実験ができるでしょう。 ただし、どれくらい時間をとれるかは職場環境やチームの雰囲気などの制約によると思います。たとえば1時間あれば試してみることはできます。1時間であれば、チームMTGの時間を使ったり、会議として時間をとって実験しやすいでしょう。 ### いつ、どれくらいやるのがよいのか（導入） モブプログラミングを現場に導入しているチームは、 - 常にモブプログラミングをする - 週に○日、○時間など決まった時間枠でモブプログラミングをする - 必要になったタイミングでモブプログラミングをする のどれかです。 いずれにしても必要だと思えば機会を増やせばいいし、必要ないと思えば減らせばよいです。モブプログラミング or NOTを選ばなければいけないわけではないので、適切な選択をできるようになるのがいちばんよいでしょう。 特に重点的にモブプログラミングをするとよいのは、 - プロジェクトの初期、切り替わり期 - メンバーの入れ替わり直後 - チームワークが乱れ始めて同期が必要な時期 などです。 ### お題はなにを選ぶのがよいのか 現場のメンバーでやる場合は、実際の仕事の中からピックアップして行うのもよいでしょう。 - 時間内にある程度区切りがつきそうなサイズのもの - 全員が体験しておくとよさそうなもの - 特定の人に依存しているもの を意識して選ぶとよいと思います。具体的には、環境構築、初期のコーディング、人依存の運用作業などをモブプログラミングすると効果を感じやすいです。 本当にお試しでやるのであれば、TDDのお題を検索したり、 [Cyber Dojo](https://cyber-dojo.org/) にお題がたくさんあるのでそのあたりから選ぶのもよいでしょう。 ### 上長をどうやって説得すればよいか そもそもモブプログラミングはチームで仕事をするだけなので、少なくとも実験をする段階においては説得は必要ないと思います。仕事をもっとうまくできるようになろうとやっていることなので、堂々と気軽に実験しましょう。こっそりやりたい場合でも、チーム内会議やチーム内レビューとほとんど変わらない構図や時間で試してみることができます。実験がうまくいって、仕事のスタイルを変えたり、必要な備品を購入してほしい場合は、そのときにうまくいった結果を持って上司に話をすればよいでしょう。 どうしても結果が出る前に真正面から説得したい場合は、以下あたりが参考になるかもしれません。 https://agile-monster.com/blog/mob-advent/ https://agile-monster.com/blog/mobpro-bestpractice/ ## まとめ モブプログラミングの導入について、自分が考えていることについてまとめてみました。もちろんあくまで個人の考えなので唯一解ではないですが、参考にしていただければと思います。 複業で個人事業主をはじめました。実際に現場でモブプログラミングの支援をしてほしい、講演をしにきてほしいなどのご相談があればお気軽にお声がけください。 https://agile-monster.com/services/ どんなチームどんな状況においてもモブプログラミングが適しているとは思いませんが、業界や職種を超えてモブプログラミングがチームワークの選択肢としてもっと気軽に選べるようになるとよいな、心の底から思っています。