はじめに

本記事を書こうと思ったきっかけは、Twitter に普段使っている講演・アジャイル支援で使っているスライドの一部を公開した反応がよかったからです。

ソロとペア/モブの作業の違いのスライドから抜粋

解説

まずはじめに、ペアやモブでの作業は、ナレッジを共有でき、作業の均一化と、スキルや経験といった集合知を醸成するとても有効な手段になります。よいとわかっていてもそれを阻むものとして、「効率」がよく挙げられます。

ペアプログラミングやモブプログラミングは、「協力的プログラミング」と総称されたりします。また、ペアリングやモビング、スウォーミングなどの作業を「アンサンブルワーク」と総称したりもします。

「効率=生産性」の罠

そこでまず考えてほしいのが、「効率=生産性」なのかということで、「生産性下がるから」とよくやらない理由になるわけですが、生産性とは効率だけを指すのでしょうか?より効率よくよい成果をあげるから生産性が高いのであって、効率よく成果にならないものを量産することは生産性が高いとは言い切れません。逆によい成果をあげるのに常識の範囲を超えた時間をかけてしまっても生産性が高いとは言い難いです。

すなわち、生産性とは、効率性だけではなく、効果性も合わせて見なければならないわけです。

そして、フィードバックループの観点からは、「反応性」も大事になってきます。後述するコストについてもぜひご一読ください。

「局所的な効率」の罠

作業効率を考えるときには、局所的な効率化に取り組むことが大半です。例えば、成果がでるまでに、[分析]▶[作業]▶︎[レビュー]▶︎[統合]▶︎[品質チェック]をフローがあったとしたら、[分析]、[作業]、[レビュー]、[統合]、[品質チェック]のそれぞれのステップの効率化を図る傾向があるということです。各ステップのスループットが上がることで、全体的なスループットも上がるのは言うまでもありません。しかしながら、これはそれぞれのステップの効果性が高い前提です。言うなれば、全てのステップが明白で、誰がやっても同じ成果があげられるという前提に立っていれば、効率を探求することに集中してもよいということです。この前提に立てるのであれば、分業とソロでの作業が有効そうだとなるでしょう。そうです、ソロ作業は有効なのです。条件つきで。

世の中は複雑に

しかしながら、世の中は複雑になってきています。それによって、問題も複雑になります。クネビンフレームワークでいうところの【複雑】な問題領域では、「明白で誰がやっても同じ成果があげられる」という前提に立つことはそもそもとても難しいのです。この前提に目をつぶって局所的な効率を求めたり、それを前提に考えてしまって、本当によい成果に結びつくのでしょうか?

クネビンフレームワーク

1:10:100

作業コストが「1」だとすると、次のステップ、そのまた次のステップと進んだあとに問題が発覚し、それに対処した場合は、コストが10倍、100倍とかかってきてしまいます。「誰がやっても同じ成果があがる」前提に立てるならば、手戻り率がとても低いため、そこまでこれらを問題視しなくてもよいかもしれませんが、複雑な問題における作業では、失敗や間違いがつきものです。すると手戻り率は高くなってしまいます。手戻り率が高いと分かっているならば、できるだけ早期に問題を発見し、芽を摘めばよいわけです。コントロールできる失敗や間違いは、早く回すことができれば、小さな成功体験に昇華することができます。ちなみに、頻繁にコントロールできない失敗や間違いは単なるミスです。長時間失敗や間違いに気がつないのは事故の元です。

手戻りは、価値に直結しない作業を増やす

ペアやモブ作業によるマイクロフィードバックサイクル

ソロでは、作業完了後に、レビューなど第三者の支援を受けることになります。ペア/モブでは、作業とレビューが同時に進行します。それだけではなく、問題を検討・分析する思考と、問題を解決・実装する思考をうまく分けることもできるため、相互建設的な作用と協業が促進されます。

ソロ作業の利点

ソロ作業の利点は、やはり、メンバー人数分の作業を並行して実施できるところです。それぞれが別の作業に着手することができるので効率がよく、それが生産性が高いと言われる構図でしょう。

先述のとおり、「誰がやっても同じ成果があがる」という前提であればとてもよい戦略だといえます。逆にその前提が崩れると、手戻りリスクがコストに跳ね返る可能性があり、それが効率と生産性にも影響を与えないわけがないのです。しかし、これらを局所的な計測の仕方をしてしまうため、[作業]、[レビュー]などのそれぞれのステップでだけ効率をみているとこの問題に気がつかないということがよくあります。

ペアやモブ作業の利点

ペアやモブ作業の利点は、一つの作業にペアやチームで集中できることです。そこでは先述のような利点を活かせるのが特徴です。しかしながら、これはリソースの効率化という観点で燃費が悪く思われがちです。実際に「誰がやっても同じ成果があがる」作業をペアやモブでおこなってしまっては、効率がとても悪い結果になるでしょう。並行して実施できる作業が半減する(ペア作業)もしくは、並行して作業ができない(モブ作業)と捉えてしまうと、単純に「生産性が落ちる」という恐怖心から実践できないこともありえます。それくらい「作業が明白である」という強迫観念は根強いものがあるのです。

それぞれの特徴をまとめる

画一的である必要はない。チームで判断できることが大切

ソロ作業、ペア作業、モブ作業は、マネジメントやプロセスの管理者が明示して指示する手段ではないといえます。手段ではなく、チームが判断して取り組む「戦術」です。複雑な問題であったり、チームのメンバーの知見にバラツキがあるときはモブ作業やペア作業という「戦術」をとり、明白な問題に対してはソロ作業を行うなど、状況に応じた「戦術」として取り組めればよいわけです。

本記事の執筆者:

長沢智治

長沢 智治 - アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

PSPO II - Professional Scrum Product Owner II
PSPO I - Professional Scrum Product Owner I
PSM II - Professional Scrum Master II
PSM I - Professional Scrum Master I
PSD I - Professional Scrum Developer I
PAL-EBM - Professional Agile Leadership - Evidence-Based Management
PAL I - Professional Agile Leadership I
SPS- Scaled Professional Scrum
PSU I - Professional Scrum with User Experience
PSK I - Professional Scrum with Kanban I
PSF - Professional Scrum Facilitation Skills
PSPBM - Professional Scrum Product Backlog Management Skills
認定スクラムマスター
DASA Accredited DevOps Trainer

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール

お気軽にご連絡ください
お問い合せ
1営業日以内にメールにてお返事いたします