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

> "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 による情勢は、私達の働き方にも大きな変化をもたらしました。
三密を避け、働きなれたモブ部屋を離れ、モブセッションをフルリモート、オンラインで開催するようになります。

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

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

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

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

なぜモブプロなのか

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

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

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

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

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

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

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

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

伝えたいこと

スクラムの原理原則に背くとだいたい失敗するとよく言われます。「事情があってちょっとだけ自分たちのやり方に変えてみたいのですが、、」ともなれば、いずこかのスクラム有識者が「スクラムちゃうがな」と投げかけてくるかもしれません。しかし、それでもやってみてはどうでしょうか？

スクラムは3つの役割、3つの作成物、5つのイベントで構成される軽量で理解が容易なフレームワークです。ところがそれだけシンプルな仕組みであっても、実際に始めるとなるとそれほど容易ではありません。原則通りに始めようとすると、色々と疑問点がわいてきませんか？プロダクトオーナーやスクラムマスターは誰がやるのが良いでしょうか？プロダクトバックログはどうやって作るのでしょうか？スプリント計画はどうしますか？スプリントレビューは必要ですか？スクラムはいつ始められますか？

全ての条件を揃えてからスクラムを始めるのは容易ではありません。しかし、それでもやるしかないのです。なぜなら、正しいやり方を実践するだけの知識や実力や環境が私たちには無いからです。とりあえずやって、失敗して、少しでも原則どおりできるように変えていくのが現在の私たちのやり方です。

2019年4月に私がJOINしたチームはコテコテのウォーターフォールで開発していました。体制変更で突然大きく変化したチーム状態と過去に経験したことがない高難易度な開発テーマで課題が山積みの中、行き詰まりを感じてスクラムの原則を取り入れ始めました。とはいえ私たちはスクラムの経験が無いチームなので、プロダクトバックログも十分に作れない状態からとりあえずスプリントの開発サイクルに移行するなど、経験者から「それやったらアカンよ、たいてい失敗するから。」と言われるようなこともあえてやって、たいてい失敗しながら、従来の開発スタイルを少しずつ変えています。私たちの取り組みはまだスクラムをやっているとは言えないかもしれませんが、少しずつでもスクラムに近づこうと試行錯誤している方々にとっての1つの事例として、「こんなやり方でもできるよ」というストーリーをお話したいと思います。

スクラムと私

株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

Regional Scrum Gathering Tokyo 2020 で「田舎で14年スクラム - チームを導く現場の「ゲームモデル」づくり」というプロポーザルを出したら落ちたのと、当該カンファレンスで2つもゲームモデルの話があったので、田舎の未開度合いと、そこで発見した奇跡について話したいです。

鳥取に比べたら、世界中スクラムパラダイスやで！

前回「田舎で11年スクラム」との違い

• 1年経過しました
• 計算間違ってません
• 田舎のスクラムチームを取り巻く状況はさらに深刻に
• 田舎では、会社の中でスクラムチーム運営してますわーいだけでは先がありません
• Long-Stable-Teamを求めて、ちんもは自分が働いている土地とそこに住む人々について改めて考えることになりました

巨大ウォーターフォールプロジェクトの一員であった業務SEは、8か月後、重要なアジャイルプロジェクト（※）を任されるエンジニアになっていました。

「なぜ？」「どうやって？」。このセッションでは、チャレンジした本人（橋本）とそれを支える組織（岡島）それぞれの目線から、次の切り口で明らかにしていきます。

1. 価値：変化を抱擁する世界へのチャレンジと、それを支援するアジャイル組織の在り方
2. 原則：本気で取り組むための「ビジネスと学びの両立」「段階的動機付け」「組織能力化」
3. プラクティス：プログラミング未経験の業務SEが成長するために日々考え実行したこと

※ https://jbpress.ismedia.jp/articles/-/57937

　私はスクラムチームのProduct Ownerとしての仕事に加え、2019年夏から人事、総務、経理、情シスなどを統べる「管理本部」を兼務しています。

そのミッションは"1300人に対し、働き方改革を推進すること"この抽象的かつ大きなテーマに立ち向かうことです。

　ミッションを受けてから数ヶ月、小さなチームで小さく始めることでリモートワークやコミュニケーション改革などたくさんのアウトプットと社内のメンバーへのアウトカムを追求してきました。

　そんな実践録をお話しします。

我々は誰に"価値"を届けるのでしょうか？

エンドユーザー？自動車メーカー？事業部長？？

大企業はPOからエンドユーザーまでが遠すぎます。

そして、POと開発チームの間にも距離感を感じている方もいるのではないでしょうか？

では、"価値"とはなんでしょうか？

ユーザーの求める価値＝ステークホルダーの求める価値でしょうか？

ステークホルダーの求める価値＝POの考える価値でしょうか？

そして、POの考える価値＝開発チームの考える価値でしょうか？？

また、"価値"とはどうやったら生まれるのでしょうか？？

失敗に成功した！

私のチームはとあるWebアプリ開発をスクラムで取り組みました。

結論を言うと、プロジェクトは予定通りリリースできました。が、その道のりは失敗の連続でした。

このセッションでは、とあるプロジェクトを通して私たちが経験した失敗談をお届けします。

しかし、結果的にこの失敗のおかげで私たちはアジャイルの原則に立ち返ることができ、開発チーム、PO、ステークホルダー、プロジェクトに関わった全員が大きく成長できました。そう、私たちは失敗に成功したのです！

皆さまには、プロジェクトの中で価値を生み出し続けるための明日から使える具体的な提案と、愛という"価値"をお届けするセッションになればと思います。

Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。

駒場
「最近、うちのおかんがシステム開発に興味を持っててなぁ。名前は忘れたんやけど、その開発手法には "プロダクトオーナー" ってゆー役割があるってゆーてたんやわぁ。」

内海
「そんなもん、スクラムやないのぉ〜。 プロダクトオーナーゆーたら、スクラムの三つのロールの一つやないのぉ〜。スクラムに決まりやがなぁ〜。」

駒場
「オレも最初スクラムやと思っててんけどな、話しを聞いてみるとなんかちょっと違うねんなぁ〜。」

内海
「違うことあれへんがなぁ〜。何が違うねんなぁ〜。」

続きは会場で。

なんやて！このセッションおもろそうやな〜。

だから大阪好っきゃねん。

アジャイルやスクラムなどについて悩んでいる時、みなさんはどうしますか？
インターネットなどで似たような悩みを解決した話がないか調べてみたり、SNSでつぶやいてみたり、同僚に相談したりする人もいます。

みなさんの現場にアジャイルコーチがいるなら話してみるのもいいかもしれません。多くのアジャイルコーチはアジャイルなマインドセットや幅広い知見を持っています。しかしそんなアジャイルコーチがすべての現場にいるわけではありません。

先日のRegional Scrum Gathering Tokyo 2020では Coaches Clinic という、アジャイルコーチに(基本)1対1で相談できる場がありました。

この時間では、その Coaches Clinic の紹介をし、実際にどのような感じで行われるのかを見ていただこうと思います。このセッションを終わった後には、ScrumFestOsakaでも Coaches Clinic の場ができるといいと考えています。

※Workshop(90分)を選択していますが、30〜45分の想定です。

なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。