This is a translated article. You can access the original here:
Mob Programming – A Whole Team Approach by Woody Zuill

モブプログラミング-チーム全体のアプローチ by Woody Zuill

Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto

1. はじめに

モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコードを書きながら、チームの全員にコラボレーションの範囲を広げています。

ソフトウェアのコーディングに加えて、ストーリーの定義、設計、テスト、ソフトウェアのデプロイ、顧客との作業など、一般的なソフトウェア開発チームが取り組むほぼすべての作業をチームで行います（私たちの環境では、プロダクトオーナーと似たような役割の社内の顧客のことを「パートナー」と呼んでいます）。ほとんどすべての作業は「ワーキングミーティング」や「ワークショップ」として行われ、パートナーを含めソフトウェアの作成に関わるすべての人がチームメンバーと考えられています。多かれ少なかれ、一日中毎日このように仕事をしています。

言い換えれば、ペアプログラミングというエクストリームプログラミング[EXT]の概念を超えた進化の一歩です。私たちは、いくつかの例を挙げれば、同席かつ対面のコミュニケーション、チームの連携、コラボレーション、チーム全体の関与、継続的なコードレビュー、「自己組織化チーム」などの概念を強調し、増幅させるように努めています。

この体験レポートでは、なぜこのような働き方をしているのか、基本的なセットアップ、モブプログラミングから得られたメリット、そして「ドライバー/ナビゲーター」チームワークモデルなどの、「チーム全体」として一日中働くために重要ないくつかのプラクティスを説明します。

2. どのようにして始めたか

私たちは、新しい働き方を発明しようとしたわけでも、ペアプログラミングのアイデアを拡張しようとしたわけでもありません。私たちは単に、私たちにとってうまく機能していることに気付き、それを拡張しただけです。

モブプログラミングを発見し、一般的なワークスタイルとして採用する前は、頻繁にふりかえりを行い、より良いものを作るために継続的に取り組むことを実践していました。ペアプログラミングやテスト駆動開発[TDD]を学んだり、コーディング道場[DOJO]を使った練習会(全員が1台のパソコンとプロジェクターを使い、キーボードを回して練習する)を行ったりしていました。チームメンバーの何人かは、TDDとペアプログラミングをはじめ、他の新しいスキルも含めて、日々の仕事の中である程度使い始めていました。

ある時、以前開発中だったものの、他のクリティカルな作業のため数ヶ月間「保留」にされていたプロジェクトを再開する準備をする必要がありました。私たちはよくある会議室に集まり、このプロジェクトを見て、どのように仕事を引き受けるかを決めました。チームメンバーの数名と契約社員はこのプロジェクトに携わったことがありましたが、それ以外のメンバーはありませんでした。

最初のミーティングでは、プロジェクトに慣れようとしました。私たちは、いくつかのコード、データベースのテーブル、ドキュメント、プロジェクトの他のいくつかの詳細を見ることから始めました。このレビュー/リフレッシュミーティングでは、いくつかのアイデアを試してみたり、テストを書いてみたり、コードを変更してみたり、今後の進め方について話し合ったりしました。ここ数ヶ月間、ペアプログラミングを学び、練習してきたので、キーボードを渡しながら作業をするのはとても自然なことでした。

数時間後、別のグループが私たちが使用していた会議室を使用することになったので、私たちは急いで荷物をまとめ、空いている会議室を探しに向かいました。その日の最後に「ミニ・レトロスペクティブ」[RETR]を行いましたが、全員がとても充実した経験になったと感じていました。そこで、翌日も同じように集まって活動できるように、会議室を手配することにしました。

それから２週間、私たちは、会議室から会議室へと移動しながら一緒に仕事をするという基本的なパターンを踏襲しました。毎日、その日の様子を振り返り、「チームとして」仕事を続けたい、ということを決めました。私たちは、上手にコミュニケーションをとり、知識を増やし、より良い解決策を見つける能力が急速に向上していると感じました。私たちは、プロジェクトとそれに関わる技術について、深く、共通の理解を得ることができました。この頃、私たちは自分たちがやっていることを "モブプログラミング "と呼ぶことに決めました。

私たちの最大の問題は、部屋から部屋への移動に伴う中断、一部の会議室でのネットワーク接続の問題、コンピュータやプロジェクターの品質や使い勝手の違いなどの、運営や設備の問題でした。また、姿勢の悪さから腰や首が痛くなったり、テーブルや椅子の向きがテーブルの端に投影されたスクリーンとの関係が悪かったりと、人間工学的な問題を抱えていることもわかりました。また、低解像度や質の悪いプロジェクタでコンピュータの画面を目を細めて見ると、頭痛がすることもありました。

3～4週目には、数ヶ月間毎日使える「常設」の作業場を見つけることができ、仕事のやり方もある程度固まり始めていました。人間工学的な問題にも対処する方法を発見していましたが、それは次のセクションで紹介します。

私たちは、「モブプログラミング」を始めてから3年間、多くのプロジェクトや機能拡張を成功させてきました。今では常設の作業スペースを確保し、仕事の進め方を少しずつ改善してきましたが、チーム全体で1台のコンピュータで作業をするという基本的なパターンを守り続けてきました。

3. なぜこのような働き方をするのか

チームがこの方法で仕事をしようと決めたからこそ、私たちはこの方法で仕事をしているのです。これは私たちにとって重要な概念です。仕事をしているチームは、その仕事をどのように行うかを最もうまく決めることができます。私たちは、このように働けと言われたわけではありません。私たちには、どのように仕事をしたいかを決める自由と責任があるのです。毎日、一日中一緒に仕事をし、協力し合うことがうまくいっていることがわかったので、それを続けることは自然なことでした。私たちは何がうまくいっているかに注意を払い続け、必要に応じて頻繁に「調整とチューニング」を行っています。私たちの合言葉は、「常に、よりよく」です[TURN]。

4. 基本的なセットアップ

基本的なセットアップは複雑ではありませんが、一般的な作業スペース(キュービクル)の配置とは大きく異なります。別々の作業スペースで一人で作業する場合は、身体的な快適さや個人的な好みを考慮するのは簡単ですが、仕事のほとんどをグループワークエリアで一緒に長時間座って行う場合は、ちょっとした課題になります。お互いに比較的近くで作業し、共有のモニター、キーボード、コンピュータのセットアップ、プログラミングツールを使用している場合は、身体的に快適であることが非常に重要であることがわかりました。キーボード、コーディングスタイル、ワークスタイル、ツールなどの個人的な好みを考慮する必要があります。

基本的な間取り図は、図1を参照してください。私たちのメインの作業エリアは、標準的なキュービクルのパーティションを使用して構成されており、約16ft x 18ft(4.9m x 5.5m)の大きさです。チームメンバー全員がコードを書く際に使用するコンピュータが1台あります。2台のプロジェクターで「デュアルモニター」を壁に投影し、2台のキーボードでチームメンバーの好みに合わせて選択できるようにしています。壁の周りには、数台のローリングホワイトボードとフリップチャート用のエリアがあります。コーディングをしていない時やチームのメインコンピュータを使用していない時には、個別の机や他のコンピュータを使用することができます。

図1 - 恒久的な作業エリアができた後の初期のホワイトボード図面

4.1 コンピュータ

プログラミングに使用されているコンピュータは1台だけです。コードベースに入るコードはすべてこの1台のコンピュータを介して入力されます。このコンピュータは、チームメールや設計、テストなどチーム全体を巻き込んだ活動にも使われています。

他にも、デスクトップパソコンやノートパソコンを利用して、調査をしたり、独自にデータベースを見たり、何かを試してみたり、個人的なメールを書いたり、プログラミングと並行して他のことを行っています。何らかの問題や新しい技術についての情報を探している人が複数人いることもよくあります。私たちは皆で一緒にいて、私たちが学んでいることについて継続的にコミュニケーションをとります。

4.2 プロジェクター

図2 - デュアルプロジェクションモニター

プロジェクターは2台あり、デュアルモニターとして使用しています。私たちは、この目的のためにうまく機能する特別なプロジェクター用のスクリーンペイントでペイントした壁に投影します。高さ、距離、明るさ、周囲の部屋の照明、壁の塗料、および他の設定を実験し、チームのみんなにとってうまく動作するように調整しました。一般的な会議室のプロジェクターよりも壁の高さを低くして投影することで、首が痛くならないようにしています。2台のプロジェクターは同じモデルで高品質です。私たちの目標は、スクリーンの大きさ、位置、解像度、明るさをほぼ同じにして、一日中快適に作業できるようにすることです。

4.3 キーボード/マウス

キーボードとマウスが2つあるので、誰もが自分に合ったものを選ぶことができます。4、5種類のキーボードを試してみた結果、「普通の」キーボードと「人間工学に基づいた自然な」キーボードの2種類に落ち着きました。後述するように、一度に「キーボードを使う」開発者は一人しかいません。開発者が Qwerty と Dvorak のような全く異なるキーボードレイアウトを好む場合、私たちは設定を素早く切り替える方法を見つけます。左利きと右利きのプログラマー、トラックボールと伝統的なマウスなど、個人的な好みはたくさんあります。チームメンバーの一人が別の人とは異なる作業をする必要があるセットアップの問題は、各人がキーボードを使う際に素早くスムーズに切り替える方法を見つける限り、問題ではありません。

4.4 椅子とテーブル

各チームのメンバーはそれぞれ自分の椅子を持っていて、それぞれの役割（ドライバーやナビゲーター）に応じて移動します。このようにして、常に椅子を再調整する必要がなく、各人が可能な限り快適に過ごせるようになっています。私たちの椅子は高品質で快適なものを使用しており、人間工学的な評価を受けた上でチームメンバーのために個別に選択されます。私たちの作業台は、２組の座り心地の良いテーブルです。コンピュータ、キーボード/マウス、プロジェクター、電話、スピーカー、手指消毒剤、その他の身近に置いておきたいものがテーブルの上に置かれています。

重要な要素の1つは、1日を通して投影されたスクリーンに対してどのように向き合っているかということです。一般的な会議室では、プロジェクターのスクリーンはテーブルの端にあるため、ほとんどの人がスクリーンを見るために頭を回転させなければなりません。短時間の会議であれば問題ありませんが、数時間、1日中このように作業していると、非常に不快な気分になります。私たちのレイアウトでは、テーブルとスクリーンが平行に配置されているので、一日中快適でストレスのない方法でスクリーンと向き合うことができます。

一般的なタスクボードに似た仕事の記録に使用している回転式のマグネットホワイトボード、他にもいくつかのホワイトボードやイーゼル、ファイルキャビネットや小さなデスクもあります。

4.5 個人用の作業エリア

一人で仕事をしたい人がいつでも利用できるように、個人用の作業エリアもあります。私たちは、メインのチームエリアとは別の場所に、小さなデスクエリアを持っています。各人の好みに応じて、座るか立つかのどちらかのワークステーションとして構成されており、各チームメンバーはそれぞれのコンピュータ、デュアルモニター、引き出し、電話などを持っています。プライベートエリアにいても、メインの「モビング」エリアの音を聞いたり、注意を払ったりすることもできるし、ヘッドフォンをして他の人達がやっていることを「締め出す」こともできます。

5. 作業に関するいくつかの重要なプラクティス

モブプログラミングでは、誰もが他の誰とでも常にコミュニケーションをとりつづけます。これは多くの価値をもたらしますが、ソフトウェア開発をしている多くの人にとっては比較的異質な働き方でもあります。私たちは、一日を通して集中し、うまく協調するために、いくつかのシンプルな原則とプラクティスが必要であることに気付きました。私たちの目標は、誰もがチームと自分自身の両方にとって最も有用であると感じるレベルで貢献したり、学習したりすることができるようになることです。私たちは、学習はチームへの貢献の一種であると考えています。

免責事項: 私たちが発見し、使用している原則やプラクティスは、私たちにとってはうまく機能していますが、私たちは常に改善を求めています。私たちはまた、他のグループやチームが、私たちのアプローチが自分たちの状況では通用しないことに気づくかもしれないことも理解しています。私たちは実験と革新を歓迎し、自分たちの環境でうまく機能する新しい方法や異なる方法を発見した他の人の意見を聞きたいと思っています。

5.1 優しさ、思いやり、尊敬をもってお互いに接するという原則

私たちの仕事では、人と人との間には何十、何百もの相互作用が毎日発生します。2人だけの会話ではなく、5～6人、時にはそれ以上の人との会話になると、その数は急速に増えていきます。私たちは一日中、アイデアを表現し、問題を議論し、可能な解決策を探り、考えを共有します。貢献できることがある人全員から話を聞く機会を得て、理解を深めるために堂々巡りな議論をするまでは、ほとんどのことがらにおいて意見が一致することはめったにありません。

このような高いレベルのコミュニケーションを一日を通して行うために、私たちは、常に親切、思いやり、尊敬の念を持ってお互いに接することを原則としています。これは簡単なことのように思えますが、この原則の重要性を明確に認めることは、私たちの日々の交流の基盤になると感じています。私のように親切、思いやり、尊敬の心を持って接することが苦手な人は、誰もがこの原則で生活することに専念すると、すぐに上手になります。

5.2 プログラミングのドライバー/ナビゲーターパターン

私たちは、Llewellyn Falco 氏の「強い」ペア・プログラミング・スタイルから発展したドライバー/ナビゲーター [DRVR]パターンを使用しています。基本的なルールはこうです：「アイデアが頭からコンピュータに入力されるためには、他の誰かの手を通さなければならない」。

これには2つの役割があります：ドライバーとナビゲーターです。ドライバーはキーボードの前に座り、コードを入力します。ナビゲーターは、これからコードになるアイデアを議論し、ドライバーをガイドしてコードを作成します。これは、ドライバーがソロでコーディングする場合よりもはるかに機械的な仕事をしていることを意味します。ドライバーはナビゲーターの話に耳を傾け、ナビゲーターを信頼しなければなりません。ドライバーはタイピング/コーディングに集中しています。ナビゲーターは、ゆっくりとしたペースでドライバーに自分たちのアイデアを伝えているので、ドライバーはいつでも次のタイピングに集中することができます。

これらのことをドライバーに声に出して表現すると同時に、チームの他の人にも表現しています。口頭やホワイトボードで可能性を議論し、考えることで、全員がアイデアを完全に理解することができます。これにより、ナビゲーターとチーム全体の集合知が生まれます。

私たちは時間制のローテーションを採用しており、各チームメンバーが短時間(通常10分から15分)ドライバーとしてキーボードの前で作業します。タイマーを使用して、現在のドライバーが自分の番が終わると次のドライバーにキーボードを渡します(5.3項で説明します)。

ナビゲーターは、ドライバー（および他のチームのメンバー）がその時点で理解できる最高レベルの抽象度で話すことが重要です。ドライバーがコード化すべきコンセプトを理解していて、詳細な指示がなくても進めることができる場合には、非常に高いレベルであることもあります。また、必要に応じてキー操作の指示が必要な場合には、非常に細かいレベルになることもあります。これは人によっても変わってきますし、同じ人でも取り組んでいるアイデアによって、またドライバーの指示を理解する能力によっても変わってきます。

私は、ドライバー/ナビゲーターのアプローチが非常に強力であることを発見しました。このアプローチに従うためには、コードベースの一部になる前に、それぞれのアイデアを別の人とコミュニケーションを取り、議論することが得意にならなければなりません。問題や、解決策の設計、またコード自体についての継続的な議論とレビューが自動的に行われます。誰もが参加し、情報を得ることができます。

5.3 タイマによるドライバーのローテーション

私たちは15分ごとにドライバーを交代するので、誰も長時間キーボードにかじりついていません。その日の作業者のランダムなリストを使って、「ローテーション」します。15分ごとに現在のドライバーがキーボードから離れてナビゲーターと合流し、リストの次の人がキーボードに移動してタイピングを開始します。時間が経つにつれ、リストの一番下に到達したら、一番上から再開します。私たちは、これを代行してくれる小さなタイマーアプリケーションを作りました。ドライバーの時間が終わると、画面をブランクにします。私たちは通常15分ローテーションを使っており、時々この時間を短くしたりしますが、モブプログラミングを初めたばかりの人はもう少し短く設定したほうが良いかもしれません。私たちが最初に始めたときは4~5分間のタイマーを使っていましたが、私たちのスキルとこのプラクティスの快適さのレベルが成熟していくにつれて、時間を増やしていきました。

5.4 電話とEメール

チーム関連の電話やメールでのやりとりはすべてチームで行います。メールには「開発チーム」と署名し、グループのメールアドレスを使用します。チームで電話をかけたり、電話に出たりするときは、スピーカーフォンで通話中であることを相手に伝えます。「やあ、メアリー、ウッディです。スピーカーフォンで他のチームメンバーと一緒に聞いています。」

私たちがこのプラクティスを使う理由の一つは、チーム内の全員が、チーム外の人との(チーム関連の)やりとりについて、すべて把握できるようにするためです。これにより、一般的にサイロで起こる問題の一つ、単一の連絡先問題が解決できます。担当が不在の間、当人が戻るまでコミュニケーションが切れてしまう問題です。しかも、勘違いも少なくなります。他の人が見落としていたことをチームメンバーがキャッチするからです。

6. レトロスペクティブ[RETR]の重要性と、行動を起こすこと

これはアジャイル原則の一つです。「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」[APRN] 私たちはこれを心に留めており、私たちに多くの価値をもたらしてくれることがわかりました。私たちは頻繁に、何がうまくいっているのか、私たちが抱えているかもしれない問題は何か、どのように物事を改善することができるかを評価します。この原則の重要な部分は、「調整とチューニング」することです。シンプルに注意を払い、「調整とチューニング」することによって、私たちは途方もない改善と私たちのモブプログラミングのスタイル自体の発見につながった行動を選択することができました。

私たちが開催するレトロスペクティブのほとんどは、典型的なレトロスペクティブのパターンに従っています。30分から1時間ほどの時間を設けて、ここ1、2週間の振り返りをします。このセッションでは、付箋紙に情報を集め、類似のものをまとめたり、ドット投票をしたり、観察したことや試してみたいことについて会話をしたりします[RETR]。いくつかのテクニックを使いましたが、最も一般的なのは、「何がうまくいっているか」「何が助けを必要としているか」「何が足りないか」のパターンのいくつかのバージョンを行い、それぞれの見出しについてのアイデアを集め、チームにとって最も意味のあることを探ります。

私たちは「アクションアイテム」を常に探しています。アクションアイテムは自分たちのプロセスを「調整とチューニング」するものですが、私たちは行うアクションアイテムを１つか２つだけに絞っています。私たちは、１つまたは２つを超えるアクションアイテムを持つと、ほとんど常に逆効果になることに気が付きました。私たちは「ベイビーステップ」を採用しています。つまり、私たちが有用であると思う変更を試してみて、その後反映し、調整し、チューニングしていることを確認しながら進めます。

6.1 ジャストインタイムのアドホックなレトロスペクティブも頻繁に行う

定期的なふりかえり以外にも、私たちはいつでもふりかえりを行い、それが役に立つと感じたらいつでもふりかえりを行います。チームの誰もが、私たちが反省すべきだと思う何かに気付いたら、経験がフレッシュなうちに素直に振り返ります。たいていは一つの事柄に焦点をあてた、短いものになります。重要なのは、常に「修正する」ことではありません。

問題点に気づくだけでなく、誰かが何か良いことに気づいたり、私たちが面白いと思ったことに気づく可能性もあります。何か行動を起こすべきだと思う項目があれば、ノートカードを作り、他のアクションアイテムと一緒にボードに貼っています。

6.2 リーンコーヒー (Lean Coffee ™) [LCOF]

私たちは、ふりかえりでリーンコーヒー(Lean Coffee™)の手法をよく使います。リーンコーヒーは、議論のポイントを維持し、迅速に進めるための簡単な方法です。大前提として、会議の開始時に出席者が議題を決定し、議論される各トピックは5分程度の時間枠に収まるようにします。これにより、私たちは集中力を維持し、会話が延々と続くことを防ぐことができます。限られた時間の中で多くのトピックをカバーするには、これが非常に効果的なアプローチであることがわかりました。Lean Coffee™のセッションでは、通常45分を費やし、さらに行動を起こす必要があると感じた話題については、アクションアイテムを見つけるように努めています。親切、思いやり、敬意を持ってお互いに接するという原則を適用することで、リーンコーヒーのセッションは私たちにとって常に有意義なものとなっています。

6.3 「常に、よりよく」(Turn Up the Good) [TURN]

私たちは、うまくいっていることを認識すること、またさらに良くする方法を探すことによって、多くの価値を得ることができると発見しました。私たちはこれを「いいこと探し(Turn Up the Good)」と呼んでいます。問題を特定し、それを解決しようとすることは有用ですが、うまくいっていることを増やす方法を見つけることで、さらに多くの価値を得ることができることがわかりました。

6.4 行動を起こす

ふりかえりやレトロスペクティブから真の価値を得るためには、行動を起こす必要があります。私たちは常に可能性のあるアクションアイテムを話し合い、いくつかを選択して、進めるようにしています。アクションアイテムの中には、良い結果が得られるものもあれば、そうでないものもあります。私たちは、これらの結果に注意を払い、反省し、時間をかけて調整し、適応していきます。

7. 問題のフェードアウト [FADE]

しばらくモブプログラミングをやっていると、以前に直面していた問題の多くが、もはや自分たちに影響を与えていないことに気がつきました。これらの問題を直接解決しようとしたわけではありませんでしたが、私たちはそれらの問題が消えていくことに気がつきました。

これらの「自然消滅した問題」を一つ一つ挙げていくと、私たちが以前に抱えていた具体的な問題の長いリストになりましたが、それらはもはや私たちに影響を与えなくなったか、あるいは小さな問題になっていました。具体的な問題は会社によって異なるでしょうが、これらの問題はいくつかのカテゴリーに分類できることがわかりました。主なカテゴリーのいくつかは、逆効果なコミュニケーション、意思決定の機能不全、「かろうじて足りる」こと以上を行うことのムダ、技術的負債による衰弱、そして重厚なマネジメントテクニック（見積もり、優先順位付け、スケジューリング、キューイング、パフォーマンスレビューなど）の負担とそれに関連するムダです。他の問題のカテゴリーには、不必要なタスクの切り替えや中断によるプログラマーのバタつきによって引き起こされる集中力と有効性の喪失、社内政治の有害な側面、意思決定と知識創造を本質的に分離する「ミーティングによるマネジメント」の弊害などがあります。問題のカテゴリーは他にもあると思いますが、私たちが気づいたこの類のもののイメージをお伝えました。

アジャイルソフトウェア開発はこうしたよくある問題のすべてに対応し、モブプログラミングは、より高度なアジャイルワークスタイルを奨励し強化します。私たちは、アジャイルマニフェスト[AM]の哲学（価値と原則）とリーンシンキング[LEAN]の概念の両方を使って、自分たちが使っている、あるいは試してみたいプラクティスやテクニックを評価しています。これは、チーム全体で協力して仕事をすることの「いいこと探し」だけで、ほぼ自動的に起こります。例えば、顔を合わせて（そしてサイド・バイ・サイドで）コミュニケーションや意思決定をすることは、一日中一緒に座っていると自然に起こります。さらに、効果的な意思決定を妨げる恐怖や「分析麻痺(Analysis paralysis　/　分析ばかりして行動できないこと)」は、すべてが透明で、迅速なフィードバックがある環境で意思決定を行うことで、軽減されたり、排除されたりします。

私たちが見てきた改善点は、私たちのワークスタイルの継続的なコラボレーションとコミュニケーション、「限定的なWIP」と一個流しのワークスタイルの自動適用、ソフトウェアを頻繁に届けて使ってもらうこと、それがもたらす迅速なフィードバック、そして意味のあるレトロスペクティブを頻繁に開催していったことに起因していると私たちは考えています。これらの自然消滅した問題の詳細については、最近のブログ記事[FADE]に詳しく書いています。

8. 生産性

モブプログラミングについて最初に聞かれる質問の一つに、こんなものがあります。"5、6人の開発者がこのような作業をしながら、どうやって生産性を上げることができるのか？違うことに取り組んでもらったほうが、より生産的ではないのか？”

このやり方で仕事をしていると生産性が格段に上がったと感じていますが、それがモブプログラミングだけのおかげだとは簡単に証明できません。アジャイル宣言の原則である「動くソフトウェアこそが進捗の最も重要な尺度です」ということを肝に銘じるならば、モブプログラミングを発見する前の1年間と、モブプログラミングを導入した後の1年間のプロジェクトの納品数を比較することで、生産性を判断できるかもしれません。納入プロジェクト数は約10倍に増えています。この測定には、プロジェクトの規模や機能の数など、考慮していない要素がたくさんあります。この一般的な比較は、社内ではこれらのプロジェクトの作業内容を知っているので意味のあるものになりますが、他の方々にとっては意味のないものかもしません。

生産性の向上を強く感じたとしても、これが他の環境でも再現性があるとは断言できません。様々な要因が絡んでいました。例えば、モブプログラミング以前のこのグループの開発手法は、従来の段階的なウォーターフォールモデルでした。開発者は個別に別々のプロジェクトに取り組んでいました。その既存の開発手法からアジャイルベースのアプローチに移行するだけでも、大きな改善につながる可能性がありました。

生産性は重要ですが、正しいことに取り組むこと以上に重要なことはありません。アイデアと結果を検証し、価値を見出し、取り組んでいることについてしっかりとコミュニケーションをとることで、価値ある結果が得られる可能性が高まります。シンプルさにフォーカスし、「かろうじて足りる」ソリューションを見つけ、やらない仕事の量を最大化することで、無駄を省くことができます。行った仕事の質が悪くてメンテナンスができなかったり、使用目的に合わなかったり、使用目的自体がエンドユーザーにとって価値がないのであれば、単に多くの仕事をこなしたとしても価値はありません。

9. ハピネス・ファクター

私たちのワークスタイルのもう一つの特徴は、毎日元気に出勤し、一緒に仕事をしていることにわくわくしていることです。「仕事をするために生きている」という人は少ないでしょうが、チームとして一緒に仕事をすることで人生が大きく豊かになることを実感しています。私たちはこれを「幸福度」と呼んでいます。私たちは、仕事に興味を持ち続けるために、非常に持続可能なアプローチをとっています。私たちは、心身の健康に注意を払い、誰もが仕事に秀で、自分の人生に秀でられる環境を提供するように努めています。このことは、私たちが最高の思考をし、私たちが創造することのできる最高のソリューションを作り出すのに役立ちます。私たちは皆、自分のスキルと能力を学び、拡大することでキャリアを常に前進させています。私たちは普通に幸福感と充実感をもって仕事をしています。

10. 継続的な学習、意図的な学習/実践、経験

モブプログラミングでは、継続的な学習が行われる環境が整っています。典型的なプログラミングスキルは、お互いのコーディングを見ているうちに簡単に明らかになり、学ぶことができます。キーボードショートカットやプログラミング言語の機能から、デザインパターンやビジネスコンセプトまで、すべてのことがチーム内で公開され、共有されます。興味深い副作用として、私たちは皆、質問をしたり答えたりするのが上手になり、より良い生徒や教師になるための学習をしています。一人一人の経験のレベルに関係なく、私たち一人一人が自分自身の向上のために意味のあることを発見し、学ぶ機会は無限にあります。

協調性の高い仕事をすることで自然と学習が増幅されるだけでなく、1日の最初の1時間をグループ学習に費やすことで、毎日「ノコギリを研ぎ直す」[S&R]時間を取っています。さらに、毎週金曜日には延長勉強会を行い、2～3時間の集中的な勉強を行っています。毎日の学習では、自分が苦手だと思うプログラミングの分野を選び、1時間かけて勉強しています。私たちは普段、ワークショップとして勉強をしていますが、それを私たちのMobプログラミングスタイルに似たコーディング道場として運営しています。例えば、コードの型を使ったり、オンラインのビデオトレーニングを見たり、本を勉強したり、面白いアルゴリズムや新しい技術に取り組んだりするなど、役に立つテクニックは何でも使います。

私たちは1日か2日という短い期間で仕事をしているので、何かをする色々な方法を簡単に試すことができます。私たちは、仕事のあらゆる側面から自動化や簡略化できそうなものを探し出し、うまくいきそうなアプローチを試しています。これには、プログラミングとプロセスに関連するアイデアの両方が含まれます。例えば、ある問題を解決するためのアイデアはいくつかあるものの、チーム全体で明確にこれというものがない場合、それぞれの解決策の最小バージョンを試してみて、どれがより良いかを確認します。実験を行うためのコストは比較的低く、私たちにとっての見返りは多くの場合、投資した時間の何倍にもなります。

面白いことに、新しいメンバーをチームに加えると、新しいアイデアやコーディングスキルをチームにもたらして、すぐに貢献者になってくれることがあります。逆に言えば、彼らは私たちが取り組んでいるプロジェクトの性質をすぐに学びます。「稼いだ分だけ学ぶ」ということです。新しい開発者は、私たちが開発しているビジネスロジックの入出力を学びながら価値を提供しています。これは、訪問者を一日チームに参加させた場合にも表れています。チームに参加してから10分も経たないうちにコーディングや技術的なアイデアを提供してくれるようになったというケースも多々あります。

11. いくつか気をつけること

モブとして働くということは、自分たちの弱点がすべて露呈しているということです。自分たちの行動はすべてチームのみんなの目に触れることになります。これを不快に思う人もいるかもしれません。しかし、そこにたどり着くまでに時間はかかりましたが、現在のチームの全員が、この絶え間ない精査と露出に適応することができました。私たちは皆、お互いに優しさ、思いやり、敬意を持って接することを約束していると理解しているので、当初思えたほど脆弱ではありません。他の人よりもスキルや能力が高い人もいますが、私たちは皆完璧ではなく、他人にさらけ出すことに自信が持てない何かを持ってもいます。

これが誰にとっても楽に行えるようにするために、相手が快適に感じられない場合、私たちが参加を強要することはありません。誰もが自分ができる最善の方法で貢献することを期待されていますが、座ってチームで作業することを誰も強制されません。それは個人の選択です。すべての人が参加するように招待されていますが、もしそうしたければ、一人で自由に仕事をすることもできます。

12. 健康と人間工学

私たちは、他の人と密接に仕事をすることで、細菌を共有したり、病気にかかったりする可能性が高くなることを認識しています。全員が同時に病気になる可能性を減らすために、全員がお互いにくしゃみや咳をしないように、十分に離れた場所に座るために十分なスペースを確保しています。また、キーボードでドライバーを交換するときに使えるように、テーブルの上に手指消毒液を置いておきます。私たちの誰かが病気の時は、その人が家にいるように勧めます。彼らが仕事をしたい場合は、チームに細菌を広げるよりも、自宅で仕事をしてもらうさせるようにしています。

人間工学的な要素に注意を払うことが大切です。私たちは、ストレスのない快適な職場環境を実現するために、その妨げとなる問題点を特定し、対処することに努めています。例えば、反復運動過多損傷(RSI)に対処したり、それぞれの方の好みに合わせるため、キーボードは様々なものを用意しています。反復性ストレスや頭痛、眼精疲労などが起きないように配慮し、必要に応じて調整しています。ローテーションはキーボードやマウスを使用する時間を制限するのに役立っています。私たちは、立って仕事ができるように整っており設定されており、頻繁に立つ位置体勢を変えています。前にも述べたように、私たちはそれぞれが自分に合わせた椅子を持っています。自分がドライバーの番になると、キーボードに向かって椅子を転がしていく回していくので、再調整することなく快適な姿勢を保てるようになっています。

13. チームの理想的なサイズは？

これはよくある質問ですが、回答するためには情報が不足しています。私たちは現在、6人のチームで活動しています。これまでに3人から12人までが「モブ」として一緒に仕事をしたことがありますが、生産的になれることがわかりました。しかし、「どのくらいの人数では多すぎるのか」という問いに関しては、ヒューリスティックな手法を用いています。それぞれの人が、貢献していない、学べていないと感じた場合は、サインと捉えます。少しの間一人で作業をしたり、ペアや数人に分かれて、新しいモブを開始するとよいタイミングかもしれません。

14. あなたはモブプログラミングを勧めますか？

モブプログラミングを勧めますかとよく聞かれます。私たちはそれが私たちにはうまく機能することを発見しましたし、あなたにも使えるかもしれません。しかし、私たちはそれを推奨しているのではなく、単に私たちの経験を共有しているに過ぎません。モブプログラミングのコンセプトを調査し、自分にとってうまくいく部分があるかどうか確認していきます。そのやり方に価値があると私たちは信じています。あなたのチームで最終的にうまくいくと、誰が分かるのでしょうか？

世界中でモブプログラミングを試しているチームがいくつもかありますが、こうした私たちが聞いたチームの中には、日常的に、あるいは週に数回このスタイルで仕事をしているチームもあると聞きます。緊急だったり、特に難しい問題が発生したときにモブスタイルで仕事をするという人たちの話もよく聞きます。他の方の経験が書かれた記事へのリンクを添付しておきます。[LINKS]

私が重要だと感じているコンセプトの一つは、それが自分たちにとって適切かどうかをチームが判断しなければならないということです。誰もがこのように働かなければならないということを強制するのは、おそらく適切ではないでしょう。

モブプログラミングに挑戦したい人には、ペアプログラミング、一個流し、テスト駆動開発、継続的デリバリー/デプロイメント、レトロスペクティブ、コーディング道場、クリーンコード、その他のアジャイルやリーンの概念についての知識と経験があると役に立つと思います。しかし、親切、思いやり、敬意を持ってお互いに接することに専念していれば、必要なことは何でも途中で学ぶことができます。

私たちは誰もが有意義なレトロスペクティブを開催することを奨励しています。自分にとってうまく行っているのために機能しているものに注意を払い、「良さを高める」方法を試してみてください。 "良いものを上げる "方法を試してみてくださいもしあなたがモブプログラミングをやってみようと思うなら、やってみた経験をお伝えいただけると嬉しいです。聞かせていただけたら嬉しいです。もしあなたがモブプログラミングをやってみようと思ったら、あなたの経験をぜひ聞いてみたいと思います。また、もし何か助けが必要であれば、私に知らせてください。何かできることがあれば嬉しいです。

15. 謝辞

何よりもまず第一に、私たちが最初にモブプログラミングを発見したときにチームで働いていたメンバーに感謝したいと思います。Dexter Baga、Gordon Pu、Chris Lucian、そして DanYeung Wong です。彼らの献身的な努力がなければ、何が機能しているかに注意を払い、常に「より良く」する活動なしに、この素晴らしい働き方を見つけることはできなかったでしょう。また、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」[APRN]というアジャイル原則の力を認識する知恵と先見性を持った上司の Marc Kase にも感謝したいと思います。私たちがモブプログラミングを始めてからチームに加わってくれた、偉大な貢献者でありチームメンバーである Aaron Griffith と Jason Kerney にも感謝します。

Llewellyn Falco には大変お世話になりました。彼の発見したすべての良いことの無欲な共有に、多くの良いものを発見する能力に、他人を助ける方法を常に探している飽くなき習慣に。私は彼からドライバー／ナビゲーターのモデルとなった「強い」スタイルのペアプロや、コーディング道場のコンセプトを学びました。また、ペアプログラミング、テスト駆動開発、レガシーコードの扱い方、受け入れテスト[APPR]、ソフトウェア開発全般についても、Llewellyn から多くのことを学びました。

この論文で私の査読者となってくれた Joseph Yoder [YODER] には大変感謝しています。彼の助けと指示がなければ、私のごちゃごちゃしたアイデアを実際の論文にすることはできなかったでしょう。誰もが Joe と一緒に仕事をする機会を持つべきですー彼は本物のプロです。

参考文献

[PAIR] Pair Programming: Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck

[EXT] Extreme Programming: Extreme Programming Explained: Embrace Change, 2nd Edition, Kent Beck

[TDD] test driven development: Test Driven Development: By Example, Kent Beck

[TURN] “Turn Up The Good” comes from the idea of “I would turn all the knobs up to 10 and see what happened” from Kent Beck: [EXT]

[DOJO] Coding Dojo – I was introduced to the Coding Dojo via Llewellyn Falco, who learned the concept from Laurent Bossavit, who introduce the idea with Emmanuel Gaillot. Emily Bache has written a book on the subject available from LeanPub: https://leanpub.com/codingdojohandbook

[RETR] Retrospectives: Agile Retrospectives: Making Good Teams Great, Authors: Esther Derby, Diana Larsen

[DRVR] Llewellyn Falco have written a bit on the subject here: http://llewellynfalco.blogspot.com/2014/06/llewellyns-‐strong-‐style-‐pairing.html

[AM] The Agile Manifesto: http://agilemanifesto.org/

[APRN] Agile Principles: The Principles Behind the Agile Manifesto, http://agilemanifesto.org/principles.html [LCOF] Lean Coffee: Jim Benson and Jeremy Lightsmith, http://leancoffee.org/

[FADE] Fading Problems, on the Mob Programming Blog: http://mobprogramming.org/fading-‐problems/ [LEAN] Lean Software Development, Authors Tom and Mary Poppendieck, http://www.poppendieck.com/

[S&R] Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement. Repenning, N. and J. Sterman (2001): http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf

[APPR] ApprovalTests are a library that extends unit test in many programming languages : http://blog.approvaltests.com/ [YODER] Joseph Yoder: http://www.joeyoder.com/

[LINKS] Here are some links to articles or video about experiences with Mob Programming Our team blog: http://mobprogramming.org/

Time lapse of a day of work: https://www.youtube.com/watch?v=p_pvslS4gEI

AppFolio Engineering Blog: http://engineering.appfolio.com/2014/03/17/my-‐experience-‐with-‐mob-‐programming/ Tagged: http://blog.tagged.com/2014/05/mobbing-‐tagged/#more-‐2520

Agical: https://www.youtube.com/watch?v=goAMu-‐XqJts

Per Jansson: http://pichdude.wordpress.com/category/agile/

Marcus Hammarberg: http://codebetter.com/marcushammarberg/2013/08/06/mob-‐programming/

Kevin Rutherford http://java.dzone.com/articles/reflections-‐day-‐mob

Amy Lightholder: http://www.light-‐holder.com/mob-‐programming-‐at-‐shesgeeky/

Mob refactoring: http://blog.codeclimate.com/blog/2014/01/30/mob-‐refactoring/

Agila Sverige, Tobias Anderberg and Ville Svärd: https://agilasverige.solidtango.com/video/2013-‐05-‐20-‐agila-‐sverige-‐torget-‐d2p02

Richard P. Gabriel at the ACM Conference on Object-‐Oriented Programming, Systems, Languages, and Applications on October 19, 2000, in Minneapolis, Minnesota, USA on a related concept: http://www.dreamsongs.com/MobSoftware.html