モブプログラミングの観点

F-Secureのテスタで“Mob Programming Guidebook”の著者のひとりであるMaaret Pyhäjärvi氏は先日、自身のモブテスト体験と、氏のチームが懐疑主義を克服し、クロスファンクショナルなスキルセット全般に渡って、個人およびチームの能力を向上させた経験に関する記事を執筆した。#NoEstimatesの生みの親であり、モブプログラミングプラクティスを発案したひとりでもあるWoody Zuill氏によれば、モブプログラミングで得られるのはチームメンバのリアルタイムなスキルアップに限らない。リリース可能な小ステップの連続としてソフトウェアを提供する場合の、効果的なコラボレーションモデルもそのひとつだ。

2月のAgile Uprisingポッドキャストで語った2部構成のエピソードの中で、Zuill氏はこのプラクティスについて、次のように説明した。

チームの全員が協力して、“我々が開発しているのは何なのか？”、“これを提供可能なものにするために、我々は何をすればよいのか？”といったことを見出すのです。同じものを同じ時に、同じ空間で、同じコンピュータ上で開発するというのは、素晴らしい発想です。

GOTO Copenhagenでの講演で氏は、“アイデアの継続的統合”こそがモブプログラミングの神髄であると述べ、重要な視点の存在によって、フィードバックループがおのずと左シフトする(より早い段階から始まるようになる)点を指摘した。ポッドキャストではこの点をより詳細に説明して、モブで必要とされるのが、動作するソフトウェアのインクリメンタルに提供するための幅広いスキルであることを指摘した。

コーダのみならず、テスタやデータベース専門家、プロダクトオーナ、あるいは何をしたいのかを理解しているプロダクトの専門家、その他の、アイデアに過ぎないこのソフトウェアを、誰かが実際に使えるものにする上で必要なすべての人々。

Zuill氏はさらに、効果的なコラボレーションのためには、リリース可能な小さなステップで開発を実施して、短期間でのデリバリとフィードバック獲得を可能にする必要があると説明した。

何らかの開発に着手する場合、私たちはまず、小さな達成単位を作ります。最初から最後まで、小さな単位で作業したいと思っています。これには結合性が必要です。すべてがひとつで、分離できないものでなければなりません。これは、私たちがするべき作業を見つけるための作業です。いかに情報や知識があったとしても、いかに最終的な目標が明確であったとしても、段階的に事を進めることは必要です。有用性を持った部分に分割することができれば、その部分部分を最初から最後まで、可能な限り直接的に利用して、誰かに使用してもらうことが可能になります。そうすることで、自分たちが正しい方向に進んでいるかどうか、フィードバックを得ることができるのです。

自身の話としてPyhäjärvi氏は、自らがテスタとしての熟練に焦点を当てていたこと、そしてなぜ“プログラマになろうと思わなかった”のか、について記している。“適正がなかったのではなく、興味と時間がなかったのです。” 始めてモブプログラミングに触れたとき、氏はそれが“プログラマとテスタのコミュニケーション”においてのみ価値のあるものだと信じ込んでいたが、“それまで熱意を持ってきたこと、すなわちテストから離れる機会だとも確信した”と、当時を振り返って書いている。

“当時の私にはほとんど知識がなかったので、プログラムを習得してプログラマになるということが１年後に現実になるとは、誰も考えていませんでした。”

Pyhäjärvi氏は自身のチームによるコラボレーティブなアプローチについて、次のように説明している。

モビング(モブプログラムとモブテスト)は、ひとつのコンピュータを使っていて、単一のフローを実施せざるを得なかった人々のアイデアに端を発しています。グループの各メンバは、順番が来るとコンピュータの前に座って、数分間のタイマを回して、それが終了するまで同じタスクの作業を続けます。誰かが仕事をしている間は他の人は見ている、というようなラウンドロビン的な仕組みではなく、モビングでは、強力なナビゲーションを通じて全員が同時に作業するのです。

さらに氏は、自身のモブが、ペアプログラミングと同じような方法で、ドライバ-ナビゲータのパラダイムを適用している状況について説明する。

キーボードにいる人(ドライバ)は、キーボードで何を行うかを決めることはできません。グループ(ナビゲータ)からの指示があって、それが可能な限り高い抽象化レベルで作業をガイドします。考え方としては、個人の能力を最大限に引き出すことではなく、チームが行っている作業に対して最善のアイデアを提供する、ということです。全員のアイデアをタイムリに利用可能にすることで、手戻りや再実施を回避する意図があります。

Zuill氏の説明によると、氏のチームが最初にモブプログラミングを発見したのは、“リファクタによるコード読み(read by refactor)”を実施している時であった。

リファクタリングを行うことで、作業の対象とするコードを学ぶのです。そうすることで、ずっと完全な方法でコードを読むことができます。リファクタリングを開始してナビゲータがナビゲートをした時、すぐに誰かがそこに加わりました。別のアイデアを試し始めて、リアルタイムでそれを共有しました。１時間後、私たちの作業には大きな進歩がありました。そして、この共通理解がチーム全体のものになったのです。

Pyhäjärvi氏は、自身のチームがドライバを効果的にナビゲートするために、3レベルの抽象化を意識してコミュニケーションを行っていることを説明した。

• 意図: “最初のステップで、何を望んでいるのかを説明する”
• 場所: “意図だけでは希望した通りの行動を起こす上で不十分な場合に使用する、例) メニューではなくキーボードショートカットで検索を使用する”
• 詳細: “意図した方向への行動に失敗した場合、実行すべきことの低レベルな説明として使用する、例) control + Fをタイプする”

さらに氏は、モブシナリオが行動に対するバイアスとコミュニケーションの必要性をいかに促進するか、という点について説明した。

一般的にグループは、明確なタスクを持って始まります。プログラミングアクティビティとしてのコードのシンプルなリファクタリングは、モブで行う素晴らしいことのひとつです。プログラミングの型(Kata)やプラクティスも自由に試すことができます。テスティングアクティビティとしては、自動化スクリプトや探索的テストのための集中的なチャータなどが含まれます。どちらを選択するにせよ、最初に課題となるのはコミュニケーションです。

そして氏は、チームが効率的に共同作業する上で生じる、コミュニケーション上の課題について詳説した。

モビングセッションが始まると、言葉を見つけるのが難しくなります。使用しているIDEの行番号の次にあるもの(ガター)が何をするものなのか、知らない人もいるでしょう。何をしたいのかを明確に述べるための言葉を探さなくてはなりません。同じように、注意深く聞いたり、他者の意図に従うように努めることに慣れていない人もいます。モビングでは、ドライバが発言してよりよい方法を提案することはできますが、次に何をするのかを決める権利はナビゲータ側にあります。

コミュニケーションに関する最初の課題はあるものの、Zuill氏は、シリアライズされた作業ストリームにおける効果的なモブのメリットについて、最終的な結合に向けてチームメンバ個々が独立的に作業することのコミュニケーションオーバーヘッドを含めた論議を展開した。

私たちの知能、スキル、能力をひとつのものに集中させると、面白いことが起こります。利用可能なものが直接的に、非常に短期間で完成するのです。作業を分割した場合には、コミュニケーションやコーディネーションのコスト、個々が違う仕事をしている、などの理由から、同じ目標を達成するまでに1～2週間は必要でしょう。1週間の作業を2ないし3時間にできれば、迅速なフィードバックループは大成功です。

Pyhäjärvi氏はさらに、意見の不一致に直面した場合、行動に向かってバイアスされたアプローチを採用することで、モブがどのように自分自身のブロックを解放したか、という点について論議した。氏が提示したのは、このような状況で適用した２つのルールである。

1. “Yes, and”ルール — “グループは心をひとつにして作業している。始まりはあれば終わりがあるが、追加することは可能だ。”
2. “Do Both”ルール — “何かを行う上で2つの方法がある場合、列挙して、両方を実施する。うまく行かなそうな方から、あるいはランダムに開始する。どちらを採用したか、すべての人が知ることが目標だ。”

Pyhäjärvi氏は、“チームとして行う場合、れまでにない方法で作業が展開されることになる”ことから、これらのルールが責任を持って実行されなければならない、と強調した。

Pyhäjärvi氏はテスタとして、適切な考え方と品質レベルをソリューションに確実に適用する上で、モブの力も氏を支援してくれることを理解している。さらに氏は、テストを中心とした質問に対する解決策の検証方法が成熟していることを実証することによって、モブのスキルアップが図れることも確認している。

モブのサイズに関するコメントとして、Zuill氏は、次のような質問に答えることで解決できると指摘している。

グループのメンバが持つ知識で最初から最後まで実施できなければ、チームにメンバが欠けているということです。

Zuill氏は今年4月、マサチューセッツ州バーリントンで開催されるMob Programming Conferenceのハンズオンを支援する予定である。