なぜモブプログラミングなのか
ソフトウェアで考えないといけないことはたくさんある。
- 正しい問題を解こうとしているか
- チーム内の技術スキルの組み合わせは適切か
- チームは十分早いペースでコードを作っているか
- 品質レベルは十分か
- 全員が効率的に共同作業できているか
- 誰かが抜けてもチームは問題なくやっていけるか
モブプログラミングを導入すれば、あなたとあなたのチームは、特定の個人に頼らずに、品質の高いソフトウェアを堅実なペースで生み出せるようになる
モブプログラミングとは何か
3人以上の人々が1台のコンピュータの前に座って協力しながら問題を解決していくことで、分散知識の考え方をプログラミングに生かしたものである
なぜ3人以上でひとつの仕事をするのか
モブプログラミングが最もコストのかからないソフトウェア開発手法でないことは間違いないが、それでもコストパフォーマンスは悪くない。何人かの人々にひとつの仕事をさせることには様々なメリットがあり、なかでもフロー効率が高い
リソース効率とフロー効率
モブプログラミングの考え方は、本質的にフロー重視であり、機能を安く作るのではなく、早く完成させることを目標にしている。リソース効率を重視すると、特定のタスクのスキルが特に高い人が生まれる。→できるひとが担当したほうが安くできる
これと対照的なのが、フロー効率を上げる方法
フロー効率とは、機能全体を早く市場に送り出すことを重視する考え方である。フロー効率を上げようとするチームは、一丸となって新機能に取り組む。誰かが1日とか1週間仕事から離れなければならなくなっても、チームは仕事を続けられる。
キーパーソンに頼らない方法
フロー効率だけではなく、キーパーソンへの依存度が下がるメリットもある。モビングで仕事を進めると、チームに「ため」を作ることができる。複数の人々が仕事のしかたを覚えさせれば、その中の誰かが辞めても組織が受けるダメージは小さくなる。
スキルアップ
チーム内の経験の浅い人々のスキルを引き上げる効果もある。
また単独で仕事をさせていると、それぞれが独自の方法で仕事をするようになるが、モビングで仕事を進めると、チームメンバーは互いにそれぞれのアイデアを共有できる。こういう共有が蓄積されていけば、チーム全体の知識が広がり、全員がもっと有能になる。
クライアントに影響を及ぼすような欠陥が減る
数人で協力してひとつの仕事をさせると、仕事の品質が上がる。コードがかかれると同時に複数の人々がレビューするので、本番コードに欠陥が入り込みにくくなる
成功をどのようにして計測するのか
マージコンフリクトの解決にかかる時間の短縮
マージコンフリクトの解決は困難で時間のかかる場合があるが、そのための時間が短縮される
本番システムに入り込む欠陥数の減少
チームのエラー率が高く、本番コードにたびたびバグが入るようなら、モブプログラミングはエラー率を下げるために役立つ
チーム内の経験の浅いメンバーの学習度の上昇
チームメンバー間で知識や経験に大きな差がある場合には、チーム内の経験の浅いメンバーに自分の学習、成長の度合いが上がったかどうかを尋ねるのも成果を示すのには役立つ
チームがモブプログラミングの導入を改善と感じているかどうか
何度かモビングセッションを行ったあとで、全員でどういう効果があったかを報告しあえば、成果がもっと実感できる
モビングの始め方
最初のモビングセッションを始めるときには、あらかじしておかなければならない準備がある
-
モビングを実験として位置づけること
実験として位置づけることで、期待が高くになりすぎず、参加者も心理的なセーフティを張ることができる。
導入は一時的なもので、セッションを数回行う。セッションが終わるたびに、うまくいったのはどういうことで、軌道修正が必要なのはどういうことかをグループ全体で評価する。数回のセッションを重ねたら、これからも続けるだけのメリットがあるかをグループとして判断する。セッションは少なくとも5回以上を目指すのが理想である -
最初のモビングに参加する人を決めること
実験として行っている間はモブを小規模にする(3-4人)
参加したい人が多い場合は複数のモブに分ける
初めてモビングをするときは、あちこちのチームの人々が興味を持ち、参加したがることが多い。しかし、最初の数回のモビングセッションは、同じチームの人々だけに限定することが大切。同じチームのメンバーならよく似たツールを使って同じコードベースを相手しているので、共同作業のやり方もわかっているぶん混乱を抑えられる
最初の数回のモビングセッションでは、コードを書ける人だけを参加させ、全員にキーボードの前に座る機会を与える。
-
モビングできる場所を見つけること
参加者がリラックスでき、互いにつながっていることを実感できるような場所を選ぶ
会議室を利用する場合は参加者からの距離のことをかならず考える。仕事場から近いほうがいい -
解きたい問題を見つけること
最初の数回のモビングセッションでは、納期が迫っておらず、全員が同じ立場で向き合える問題を選ぶようにする
書籍では「カタ」を解くことを進めている (AtCoderを解くなどでも良さそう)
-
モビング用にマシンの準備をすること
セッションが始まる前にマシンの設定を済ませる。
外付けのキーボードを用意し、モブの全員が使い方を知っているコードエディターを入れておく
モブのメンバーが少し離れた位置からでもコードがはっきり読めるようにエディターのフォントサイズを調節し、全員が快適に使えるようにショートカットを設定し、行番号の表示をオンにする -
モブタイマーを用意すること
モビングセッション中にメンバー全員がしっかりとみられるものを用意する。音だけに頼らなくても時間が過ぎたことがわかるようになる
初めてのモビングセッションは2時間程度にすべきだ。最初のモビングセッションは、準備、本体、しめくくりに分けるようにする
お膳立て
モブが初めて顔をそろえたときには、最初にモブプログラミングのコンセプトを説明する。
準備: お膳立て (30分前後)
- モブという形でひとつの私語をに取り組むことの意義を説明する (10分)
- モビングでの役割分担を説明する (8分)
- モブが解決する問題の概要を説明する (10分)
- タイピストの順番を決める (2分)
本体: モビングインターバル (1時間30分前後)
- 最初のタイピストにキーボードを渡す
- タイマーを10分にセットして開始する
- モブ全員が協力して問題の解決のために努力する
- 10分が経過したら、タイピストは作業を中止して次の人に交代する
- セッション終了20分前まで、タイマーをセットしなおして、インターバルを繰り返す
しめくくり: 経験からの学習 (20分前後)
- それまでのセッションを繰り返し、うまくいったこと、うまくいかなかったことを挙げ、次回の改善方法を議論する
モブという形でひとつの仕事に取り組むことの意義
- モブプログラミングとは、協力してひとつの問題を解決するために、1台のコンピューターの前に数人が集まって共同作業することである
- モビングを効率的なものにするためには、モブの一人ひとりのメンバーがフロー効率重視の考え方を確立していく必要がある。それは課題の完成に向かって歩みが滞らないように、チームの一員として協力し合っていくという考え方である
- フロー重視の考え方を確立するために必要なスキルを身に着けるためには練習が必要だが、決して不可能なことではない。世界中のチームがこれを成功させている
タイピストの仕事
タイピストとは、キーボードの前に座る人のこと。ひとつのモブで同時にタイピストになるのはひとりだけである。タイピストは、プログラマーではない。むしろ、その他のモブがしてくれと言ったことを取り入れ実装するスマートアシスタントと考えたほうが良い。
タイピストが効率的な仕事をするためには、次のことが求められる
- その他のモブがしてくれと頼んだことを理解する
- 要請の意味がはっきりしないときには、はっきりさせるための質問をすること
- してくれと頼まれたことをコードの形に実装すること
- その他のモブを信頼し、自分では通常試さないようなアプローチを躊躇せずに試すこと
- ショートカットキーや他の人のツールの活用方法などの新しいことを学ぶこと
タイピストが回ってきたときには、その他のモブがしてくれと頼んでくれることとを理解するのが難しい場合がある。何を求められたのか理解できない場合もある。そういう時には、声を上げて、モブが求めるようなコードを書く方法がわかるまで質問しなければならない。
有能なタイピストになるにはは信頼が必要。自分が普段とるのとは異なるアプローチをその他のモブが選ぶことがあるのを認識し、そのアプローチの可能性を探りつくすことをいわないものである。生半可に抵抗するのではなく、要請されたことを実装してから、それを評価するようにする
タイピストをやっているときに、実装する価値があると思うアイデアが浮かんだときはどうすればよいだろうか
その他のモブにアイデアを説明して実装に賛成してもらうか、他の人にタイピストを変わってもらって自分はその他のモブに戻らせてもらうかのどちらかになる。その他のモブに戻るときには、モビングインターバルはそこでリセットする。
タイピストを務めているときは、自分のツールの異なる使い方を他のメンバーから学ぶ素晴らしいチャンスだ。他のメンバーが自分とは違うやり方や作業ペースが上がる新しいショートカットを教えてくれた時には、受け入れるようにする。こういった小さな改善によって自分の仕事がいかに早くなり、能力がいかに上がっていくかは驚くほどだろう
その他のモブの仕事
- 問題解決につながる次の理論的ステップをみつけるために力になること
- 理解できるまで質問をすること
- モブ全体の理解の水準をあげるために貢献すること
- 目の前の問題に集中すること
- 他のメンバーの意見を聞くこと
- 必要な情報を予測すること
- システムの中の改善すべき部分を探すこと
モブはときどき脇道にそれて迷走することがある。そうなっていないかどうかに注意して、迷走が起きている場合は注意喚起し本筋に戻る努力をする。目の前の問題に直接関係のないアイデアはしばしおいておく
作業やコードの中の改良できる部分を探す。繰り返されるタスク、プロセスは自動化すべきである。他のメンバーが知らないショートカットやエディターの操作テクニックがあれば教える。あやしげなコードや不必要に複雑なところを見つけたり、ものごとを単純化したりする方法を探したりするのも、その他のモブとしての仕事の一部である
モビングで解決しようとしている問題の概要を紹介する
モブたちにふたつの役割がはたすべきことを理解してもらったら、解決しようとしている問題を紹介する。モブとして、問題にどう取り組んでいくかについてのおおよそのプランは一致していなければならない。ホワイトボードに問題解決のための様々なアプローチを書いて全員でブレインストーミングする。せいぜい15分程度で終わらせるべきである。意見が一致したら、おおよその実装手順を書き出して、細かい問題はモビングインターバルで考える
モビングインターバル
10分間のタイマーをセットしてはじめるが、どこから始めたらよいのかという問題が起こる。経験の浅いモブは、最初のインターバルでは、あまりコードを書けないことが多い。まずいことではないが、できる限りコーディングに進むと、会話の内容が理論的なものから実践的なものに変わっていく。問題へのアプローチのしかたがまちまちなら、最初はもっとも単純なものを選ぶ。
最初のインターバルでは、タイマーに注意する。タイマーが切れたらインターバルを終わらせ、タイピストを次の人に後退させなければならない。タイピストは、その時点でしていることを「終わらせたい」と思うものだが、その気持ちはぐっと抑える。新しいタイピストとの交代は素早く終わらせたい。交代したらタイマーを再び10分にセットしなおして、カウントダウンを開始する。この機会を利用してバージョン管理システムに作業内容をコミットしておくとよい
10分間のインターバルを初めて経験して感じるのは、10分はコードを書くためには本当に短い時間ということと、それでも少しは仕事を前進させられるということだ。短時間のインターバルを守っていくと、全員の集中を保つために役立つ。
その後のインターバル
アイデアを説明しなければならない時期が含まれる。そのときは次のタイピストのインターバルをそのタイピストに回す
インターバルごとに、モブの中でのそのときの自分の役割を意識しよう。タイピストの順番でなければ、キーボードに触れてはならないことにイライラするかもしれないが、時間とともに説明することと他人の話を聞くことがうまくなってくるとこういった不満は減っていく。
モビングセッションの冒頭でホワイトボードに書いたおおよその手順に絶えず立ち返るようにする。それにあわせておおよその手順も更新しなければならない。ボードの一部はToDoリストにして、検討すべき大切なアイデアやタスクを書き留めるようにする。
経験からの学習
セッションの最後の20分は、モビングを締めくくるためのレトロスペクティブ(反省会)にあてる。ここでは、モビングに参加したメンバーが感じたことを述べあい、次回に軌道修正することを提案する。
モビングの軌道修正
エキスパートがいるモビング
エキスパートがいるモビングとは、モブの中にひとりがエキスパートとみなされ、その他もすべてのメンバーが初心者と思われているモビングのことである。
モブの中にエキスパートが一人いると、その他の初心者メンバーたちはタイピストとしてそのエキスパートを選ぶという誤りを犯してしまう。実際、エキスパートをタイピストにすると問題は解決され、他のメンバーはただそれおｗみてうなずくだけになる。
なぜ問題なのか
エキスパートがキーボードの前に座ると仕事は快適なペースで進むが、その他のモブはついていけない。また、その他のモブには知識の隙間が生まれるため、なぜそうことが行われているのかわからなくなる危険がある
学習が浅いものにとどまる主な理由は、タイピストについていけないという事だが、他にもわかりにくい理由がある。もっと深くかかわっているときほど経験が得られないという事だ。キーボード操作は知識を内面化するために役立つが、エキスパートだけがキーボードをたたいているときには、その他のモブはキーボード操作によって得られる効果を得られない
どうすべきか
エキスパートをタイピストにしない。自分以外のモブに集中してもらう。エキスパートをモブのコーチにして、メンバーの知識の穴を探して埋めてもらう
手探りで進めていくような仕事のモビング
ときどきモブには次のステップが明確にわからないようんあ状況に陥るときがある。新しいテクノロジーを導入するときや全員が良く知らない技術スタックでつくられたシステムを引き継いだときに起きる
モビングの経験が浅い人たちがこういう状況では沈黙が流れる。誰かが次のステップを提案するのをまってしまっている。モブがつぎにするべきことについてはっきりとした方向性がないときは収拾がつかなくなることが多い。モブのメンバーたちはまちまちなアイデアを試したガリ、特に矢継ぎ早に矛盾するリクエストがタイピストにあつまると混乱、不満を感じる
どうすべきか
まずはモブがまちまちなアイデアをいくつも出しているという現状を認める。まずどのアイデアを最初に試すかについてモブの中で意見を一致させる必要がある、意見の一致のためには、タイムボックス付きの探求と強いモビングのふたつのテクニックがある
タイムボックス付きの探求
目の前の課題に対する理解を深めるために、モブの個々のメンバーにそれぞれの考えを掘り下げていく時間を与えるという方法。読まなければいけないオンラインマニュアルや、試してみなければならないチュートリアルがあるときには、いい効果を生むことが多い。こういった作業は一人のほうがうまく進む
流れは次のようになる
効果的に前進するために、先に理解しなければならないことをモブ全体で明確化する、これがタイムボックスの目的になる。
次に、モブ全体でタイムボックスの長さを決める。これは目標を達成するために必要だとそれぞれが思う時間を持ち寄り、提案がそろったところでもっとも短いものを選ぶとうまくいく。30分以上なら30分できることにする。
そして、タイムボックスに入る、一人一人が目的となっている知識を得るためにそれぞれの方法を追求する。誰かが必要な知識を突き止めたらモブを集めてわかったことを共有する
タイムボックスが過ぎたのに誰も必要な知識が得られなかった場合でも一度グループに戻り、それまでに学んだことについて簡単に報告する。そして、モビングを続けられるだけの手がかりが得られたか、新たにタイムボックスを設けて個人で調査を続けるかをモブ全体で判断する
タイムボックス中はそれぞれのデスクには戻らないほうがよい。デスクには集中を妨げられるものが多い。タイムボックスは休み時間ではないし、不必要なコンテキストスイッチを許す機会ではない。
強いモビング
タイムボックス付き探求に変わるアプローチでモブのなかの意見がバラバラに分かれたときに効果的な方法
矛盾するアイデアがいうつも提案され、それらのアイデアを統計的に試してひとつのソリューションにまとめなければならないときである
まずモブ全体の進行役を決める。
タイピストはコマンドモードに移り、進行役がしてくれといったことしかしない。他のメンバーが言うことを無視する。そのｔのモブが試してみたいアイデアを持っているときには、進行役にそのアイデアを委ねなければならない。
次に、進行役はホワイトボードにアイデアを書き出してモブにさまざまな提案の突合せ、明確化を促す。このとき進行役はアイデアに対して自分がどう感じているかに左右されてはならない。どのアイデアを試してみるかを決めるのはモブであり、進行役ではない。
全てのアイデアを列挙したら、進行役は個々の提案についてどういう前提条件を設けているか、確かなこととしてわかっているのは何か、確認が必要なことは何かをモブに答えさせる
そしてモブは作業をどう進めていくかを決める。その過程で次の問いについては答えていかなければならない
- まず試す価値があるアイデアはどれか
- どのアイデアがもっとも評価しやすいか
- すぐにふるい落とせるアイデアはどれか
モブの考え方が一つにまとまり始め、先の見通しがはっきりしたら通常のモブを再開する
些細な仕事のモビング
モビングを進めていくうちに、些細な作業を終わらせないといけないという状況がでてくる、些細な仕事は決して重要性が低いわけではなく、単純な反復作業である
このときも同じ場所に集まってその間に進む方向について議論したり、ここまでの軌道について簡単に振り返ったり、戦略を立てたりする。
モビング定着後の長期的な展望
チームの新メンバー
どこかの時点でチームの中の誰かが辞め、入れ替わりに他の人が入ってくるのは避けがたい
新メンバーの経験レベル次第では、モブは混乱だけでなく、別の課題にも直面する場合がある。新メンバーを迎え入れたときのことを思い浮かべると、チームの経験レベルのバランスを保つのは難しいと考える。しかし、モブプログラミングを導入してからは技術的スキルよりはどういう価値を提供できるか、他のメンバーとやっていけるかを考えた新メンバーを重視するようになる。
経験の浅い新メンバー
経験の浅いメンバーを迎えるときには、その人がモブの中でどう感じるかを考える必要がある、多くの場合、経験の浅い人が初めてモブで仕事をするときにもっとも気にするのは、チームの足を引っ張って仕事が遅れることである。
恐怖を緩和するためにできることは以下である
-
怖がっていることをオープンにする
-
安心感を与えることを心がける
無知にみられるのを恐れて質問するのを怖がることが多い。これは不安を感じている兆候である。この気持ちを乗り越えられるように働きかける。質問することはむしろ推奨されていることを明確化する。注意は、質問の中にはすぐに答えられるものとモビングセッションが終わってから答えたほうが良いものがある、セッション終了後に答えたほうが良い質問を受けたときには、はっきり言って安心させよう。 -
新人の学習を最大限後押しする
-
時間的制約を明確にする
現在の仕事をいつまでに完成させなければならないか、モビングをどうのくらいのスピードで進めていかなければいけないのかを明確にする。モブの経験の浅いメンバーが入ってきたときには、納期が迫っていない仕事をしていて、説明のための時間的都合を作るほうがよい。ただ、納期がある場合はメンターと一緒にペアプロをしてコードベースに慣れてもらうほうが良い。参加を遅らせすぎないように注意しないと孤立感がでてしまうので注意が必要である。
モビングの遅さ
そのうち、チームの中の誰かがモビングによる作業は遅く感じると言い出す。そういう感じを受ける本当の理由をはっきりさせることが大切である。全般的、抽象的にそう感じるか、モブの中の誰かが作業を遅らせているのかどうかということだ
遅いという漠然とした感じ
なんとなく仕事が遅いという感じがするなら、それは誤解であることが多い。実際はそんなことはないのに、モビングをすると仕事のペースが落ちるような気がする。よく考えれば、従来仕事を遅らせる原因だったいくつかのものをモビングによってなくなっていることに気付く。例えば、考えを一致させながら仕事を進めていくため、コードレビューは廃止されてるし、話さなければならないことが減っているため、スタンドアップも時間短縮されている。本番システムの欠陥も減っているのでリワークも少ない。
合意形成のためにコード作成時間自体は少し長くなっているかもしれないが、ソフトウェア開発のエンドツーエンドの作業時間は一人あるいはペアプログラミングと比べてモブプログラミングのほうが短いことが多い。
作業ペースが遅いと感じるのは、作業全体のうちコード作成の部分だけをみているからであり、全体としては遅くなっていない
誰かが作業を遅らせている
モブの作業ペースは、モブの中でももっとも経験の浅いメンバーの作業ペースに一致してしまうことがある。仕事の過程で知識をシェアし、学んでいくことはモビングですべきことだが、ペースが落ちてしまうことがある
意識的なスピードアップを行うときは例外として周知して進めていくことが大事。その中で作業ペースが速くてわからないことは質問リストをつくらせて後で答えさせるようにする
モビングを始めたばかりで、モブ内の誰かが作業ペースに遅いと感じる場合がある。大事なのはその不満に気付くことである。不満に気付いたら次にチームメンバーの仕事が遅い理由がどこにあると彼らが考えているかを知ることができる。
そして、明らかにしたことを共通認識に高め状況の改善に役立てる。
直接意見する文化の構成
チーム内に改善のために何をすべきかについてメンバー間ではっきりと意見を言い合える文化を育てると、改善点を意識できるようになる。
定期的に一対一での意見交換をするとよい
その他メモ
モビング疲れ
モビングをする際には30分ごとに休憩を入れる
モビングを始める前に、全員でコーヒーを淹れに行くなど儀式を作るとよい
急な対応
突発な飛び込み仕事はフローを阻害するので、(モブを導入すれば多くはなくなるが)バッドマンに守ってもらう。バットマンはモブの外部の人がものを尋ねたいときの最初の窓口になる。大規模なチームでは、バッドマンはモブには参加せずに単独で市と語をする。こうすると外部から誰かを見分けやすくなり近づきやすい。小規模のチームでは、モブ以外の誰かにバッドマンの役割を頼む。タイピスト以外のメンバーで順番を回す。バッドマンを定期的に交代すると外部の人々からの質問やリクエストへの対処方法について知識をチーム全体にいきわたらせることができ、特定のキーパーソンに頼らなくても済むようになる。最初は1週間でバットマンを後退させるようにする。しばらくしたらチームがうまく回る周期を決める。
バットマンのコツは外部から誰がバットマン化をわかるようにすることで、目印を持たせることやバットマンが使う汎用メールアドレスを用意することが便利である
モビングを出入りするときの中断
あなたが今話題の中心で話題を唯一知っている人間なら、とどまるようにすべき
特に重要な役割がなければ、どのくらいで戻れそうかを知らせて抜ける。戻ってきたときには「いないあいだのことを教えてくれない？」などは訪ねてはいけない。モビングのフローを断ち切ってはいけない。
モビングに入っているがモビングに集中していないのもフローの阻害になる。(メールチェック、スマホチェックなど)
モブにいる間は通知をオフにして、休憩中におこなうようにする
Q&A
モビングに幻滅してしまった人との接し方
大切なのは、彼らに参加を強制しないこと。何が嫌なのかを言ってもらう。モブへの参加は自由だという事を伝える。
モブプログラミングが成功するかどうかは、多くの要因によって決まる。誰が参加しているか、共同作業にどれだけ時間をかけているか、あなたが周囲にどのうう時間を与えているか、あなたとモブの他のメンバーがどういうコミュニケーションをとっているか、どういう場所でモビングをしているかといったことがすべてモビングの需要度に大きな影響を及ぼす
チームのメンバー間にモチベーションの温度差があるとき
仕事を納期までに仕上げることやコードを完璧なものに仕上げることに対して、他のメンバーが自分ほど熱心でないとイライラがたまってしまう。モビングは水面下に沈んでいて目に見えなかった問題を表面化させただけである。この課題を意識して、積極的に克服することが大切である。まじめなメンバーと協力してそうでないメンバーを良い方向に導いていけば、チーム全体として大きな業績を上げられる