モブプログラミング/モブプロとは...

> "all the brilliant people working...
on the same thing,
at the same time,
in the same space,
and on the same computer"
-- Woody Zuill

モブプロの提唱者、Woody Zuill氏は
Agile2014 カンファレンスでモブプロを上記のように紹介しました。

私達はモブプロを「デフォルトの働き方」として採用して以来、一年半以上にわたりフルタイムでモブプロを実践し、
ほとんどすべてのタスクをモブプロで行ってきました。

...しかしながら、昨今の COVID-19 による情勢は、私達の働き方にも大きな変化をもたらしました。
三密を避け、働きなれたモブ部屋を離れ、モブセッションをフルリモート、オンラインで開催するようになります。

リモートでモブプロを実施するようになって２ヶ月。
はじめはぎこちなかったリモートモブも、軌道に乗り始めたように思われました。

そんな中、ふとこんな疑問が頭をよぎります。

「こんなにも大きく世の中の情勢が変わったにもかかわらず、なぜモブを続けたのだろう？」
「ともすると、これはただの怠慢ではなかったのか？」

この疑問に答えるため、自分たちのモブを観察しはじめました。

なぜモブプロなのか

私達のモブを注意深く観察し、また過去の行動をふりかえって分析してみると、
モブがうまく機能しているときにあらわれる特定の習慣があることに気が付きました。

また、国内外での事例調査や、実践者へのインタビューを実施するうち、
やはり多くの共通した習慣があり、名前がつけられているものも多くあるように思われました。

これらの習慣に自分たちでも名前をつけ、その関連をチームのコンテキストの中で整理してみると、
モブがうまく機能するための習慣は、オンサイトでもリモートでも大きな変化がなかったことがわかってきました。

また、これらの分析を通じて、私達の実践しているモブプロについて

「その価値はなにか」
「なぜこのやり方がうまくいくのか」

という本質的なことが浮き彫りになってきました。

このセッションでは、一年半のフルタイムモブの経験からたどり着いた、私達の考えるモブプログラミングの価値,原則,プラクティスについてお話します。

全国のモブプロ実践者の皆様、あなたのチームのモブプロの価値はなんでしょうか？
是非一緒に議論し、これからのモブプロについて語りましょう！

はじめに

本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
見積りをやめてから起こった問題やその対処についてもご紹介します。

また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

Introduction

本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
アジャイル開発における見積りについては「アジャイルな見積りと計画づくり（AEP）」という素晴らしい書籍でその有用性や有効な実践方法が示されており、私自身もその有用性について同意しています。

しかしながら、見積りには負の側面があることもまた事実であるように思われます。
RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

そもそも、なぜ見積りが必要なのでしょうか？

そして、本当に必要なものは見積りなのでしょうか。

この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか？」という仮説にたどり着きました。
それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

この私達のプロセスでは、モブプログラミングが鍵となっています。

本セッションでは、私達がどのように見積りをせず開発をしているのか、その方法論を紹介するとともに、
見積りをやめたチームの事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

見積りの負の側面と価値

見積りの負の側面について、私達の考えをまとめます。
私達が考える見積りの負の側面は、以下の「３M」に集約されます。

• 数値化による「コミット圧力」… 納期の「ムリ」
• 数値化による「仕事量の最大化」 … 仕事の「ムダ」
• 数値化による「正確であるという錯覚」 … 精度の「ムラ」

そしてこれらは、見積りを「数値化すること」により発生すると考えています。

もちろん、見積りは負の側面ばかりではありません。
見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
計画づくりとは価値の探求なのだ。
– アジャイルな見積りと計画づくり

見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

見積りの負の側面の根源である「数値化」を行わず、
見積りから取り出したい「価値」を抽出する手法

と定義づけています。

スクラムと見積り

私達はスクラムを実践しています。

見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
見積りをやめて以来、ずっと問い続けてきました。

スクラムガイドには「見積り」という言葉が９回登場します。
それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

• リリース計画づくり … PBIの優先順位付け
• スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
• 進捗管理 … 残作業を確認し、計画を更新する

見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
これが私達のたどり着いた答えです。

我々は、以下の方法でこの意思決定を行っています。

• 優先順位付け / バックログリファインメント
  • PBIのサイジング … 直近のPBIを １スプリント以下のサイズ に調整
  • C3D(Cost of Delay Divided by Duration)
• キャパシティ / スプリントプランニング
  • PBIのスループット
  • スプリントゴール
• 進捗管理 / デイリースクラム
  • SBIのスループット
  • モンテカルロ法 … 過去データからの ‘予測’
• スプリント（開発作業）
  • モブプロ
    • WIP制限 … 安定性・予測可能性の向上

「見積しない」 開発と現実

このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

• 「見積りしない」の始め方
  • どのように上司を、ビジネスを巻き込むのか？
• 「見積りしない」計画づくり
  • どのように先の見通しを立てるのか？
• 「見積りしない」開発の課題
  • 見積りをやめてから、チームに降りかかる課題と対応
• 「見積りしない」で納期を守る
  • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには？

まとめ

Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

AEPから１０年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

モブプログラミングとは...

「同じことを、同じ場所で、同じ時間に、同じコンピューターで」

私たちはモブプログラミング（以下モブプロ）を「デフォルトの働き方」として採用し、一年間ほとんどすべてのタスクをモブプロで実施してきました。
これら自分たちのチームのモブの実践と、様々なチーム、ときには海外でモブプロを経験し、その行動を観察するうち、モブプロを実践するときに共通して見られるいくつかの行動を発見しました。

なぜモブプロなのか

書籍「Effective DevOps」によると、DevOpsは４本の柱からなる文化であるとされます。
４本の柱とはすなわち、

- コミュニケーション
- アフィニティ
- ツール
- スケーリング

「同じことを、同じ場所で」全員で実施するモブプロは、開発チームのコミュニケーションを促進し、そして開発チームを超えてビジネスや運用チームとのアフィニティを高め、信頼を醸成する最良の手段の一つであると言えます。

実際に僕たちのチームでは、モブプロをきっかけにチームのコミュニケーションが改善され、いまでは自己組織化された機能横断的なチームを実現しています。

'効果的な' モブプログラミング

モブプログラミングは「全員で１つのことをやる」という性質から、
「効率的に働く」つまりリソース効率の最大化、単位時間あたりのアウトプット総量の最大化をめざすのではなく、
「効果的に働く」つまりフロー効率を最適化し、単位期間あたりの仕事の成果（Outcome）を最大化するための手段であると言えます。

自分たちのモブを観察するうち、成果を出せているときとそうでないときそれぞれに特定の共通した行動が見られることに気が付きました。

これらの行動のうち、良い影響を与えるものを増長し、悪い影響を与えるものを最小化するため、意図的にチーム内でのモブにおける役割を定義しました。
このロールの組み合わせによって、モブにおける「フォーメーション」あるいは「カタ」として名前をつけ、いくつかのカタログを作成しています。

本セッションでは僕たちのチームで発見したモブプロの「カタ」を紹介し、カタを通して効果的にモブプロを行う方法について議論します。

• 「ビジネスになったアジャイルをエンジニアに取り戻せ！」

師匠：David氏からDevOpsDays Tokyo 2019で強いメッセージを受け取った直後に臨んだ認定スクラムデベロッパー研修。エンジニアがオーナーシップを持ってプロダクトと向き合うこと、スクラムをやるためにはXPが必要であるなど、私たちは師匠から熱い想いやメッセージを受け取りました。

これを経て、改めて『エクストリームプログラミング』(2015/6/26 Kent Beck (原著), Cynthia Andres (原著), 角 征典 (翻訳))に目を通すと、

“XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ”

とあり、XPは単なるプラクティス集ではなく、エンジニアは自分たちが取り組んでいることに対してちゃんと価値を理解すべきであり、それを周りの人たちに責任を持って説明していく必要性があることを強く訴えている、非常に刺激的なものであることに気づきました。

「お客様に継続して最も高い価値を届けられるのは自分たちだ！」と自負をしながら、より高いスキルやデザインを追求出来る。

スクラムとXPを最高のチームで体現していく勇気を、今こそ分かち合いましょう！

• 「社内なのに請負開発みたいだ・・・」

”ビジネス側” から言われたものを言われた納期でつくる。私達は内製のプロダクトのはずなのに、まるで請負契約のような開発をしていました。

そこから、開発チームが少しずつ変化し、プラクティスを実践し、”ビジネス側” を巻き込み、プロダクトの価値をともに考えるチームに成長してきました。

その変化の中で、プロダクトが価値を届けることにフォーカスし、チームの中心に据えることができたのは、師匠から学んだ価値、原則、プラクティスと、その実践の影響が多分にありました。

もっとより良いチームになりたい。もっとより良いプロダクトを開発出来るようになりたい。そんな想いで立ち上がり、一歩ずつビジネスと向き合えるようになったチームの今をお話します。

はじめに

Celebration Grid

CyberAgent AdTech Studioでの事例紹介

What is モダンイクメン？

Modern Agile is a community for people interested in uncovering better ways of getting awesome results. It leverages wisdom from many industries, is principle driven and framework free.

- Joshua Kerievsky