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

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

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

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

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

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

なぜモブプロなのか

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

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

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

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

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

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

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

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

イノベーションを生み出し、生産性の高いチームを目指すのなら、マネージャーやスクラムマスターはどのように振る舞うかが鍵となります。そこで推薦したいのは「サーバント・リーダーシップ」です。

サーバント・リーダーシップを活かしている人は一方的に命令するのではなく、チームメンバーをどうやってサポートしてあげられるかに重点を置きます。チームメンバーをコントロールするのではなく、チームメンバーに仕えるという態度で接します。

このワークショップでは、サーバント・リーダーシップを効果的に実践するために必要な要素を紹介し、またそれを応用する方法もお教えしていきます。自分のリーダーシップを再考する絶好のチャンスになります。

2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか？と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。あの時の彼の決断は正しかった、と今の私なら言えます。

このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

12年前、最初のアジャイルスクラム案件に取り組みました。

この新しい世界を受け入れるには、最初からすべてを学び直す必要がありました。しかし、いくつかのプロジェクトを経験し、いくつかの困難に直面したため、アジャイル、プロジェクト管理、およびメトリクスが共存できることに気付きました。

無駄ゼロを目指したリーン思考により、非常に簡潔なプロセスを達成できました。

CI&Tリーン・アジャイルプロセスを適用してプロジェクトを管理している間に、私はいくつかのことを学び、リーダーシップに対する考え方を完全に変えるに至りました。

そして「Process ＆ People」は私の情熱であることに気付きました。

3年前、私はブラジルから東京に移り、このCI&Tリーン・アジャイルプロセスとCI&Tの企業文化を日本での事業に導入しました。

日本文化について学び、日本でも受け入れられるようにプロセスを調整することは、大きな挑戦でした。

私はこの困難に立ち向かいながら、数々のプロジェクトを経験しました。再び、私は多くのことを学び、そしてそれは自分自身をも変革してくれました。

この登壇では、アジャイル、プロジェクト管理、メトリクスに関する「学びの旅」と、これらが日本という地で如何に適用されているか皆さんに共有します。そして、これが再度自分を完全に変化させたことを。

私はとあるコミュニティの運営に数年携わっています。正直なところ運営の苦労なんてなるべく避け、楽しくやっていきたいものです。しかし、実際のところはいろいろありました。そこでみんなであれこれ実験してみたりカイゼンしたりと試行錯誤を重ねた結果、今現在ではなかなかいい感じなプロセスができあがった気がしてます。

そんなことを思い返していると、ふと気づいたことが。「これってチームの活動と似ているな」と。

そこで、コミュニティ運営というチームが直面した課題とそれに対しどのような取り組みを行ったか、そしてどのような成果を得られたか（あるいは得られなかったか）、これを続けた結果どのようにチームが成長していったかを整理しつつ、みなさんのチームや組織、コミュニティなどに活かせるヒントが得られるようなセッションをしたいと思っています。

※コミュニティについて、話の都合上簡単な紹介はすると思いますが宣伝するつもりはありません

こんにちは！
私達はLED-Camp(※) で毎年スクラムを初心者向けに教えています。

ここでふりかえりを重点的に教えたのですが...LED-Camp が終わった後のアンケートに「ふりかえりは重要ではないと考えている」と答えた人がいました。
何故なのか？そもそもふりかえりは何故必要なのか、どういったときに必要なのか？
必要ってことは分かっている。分かっているんだけども...本当に必要なの！？

この疑問をなんとかして自分の納得する形にしたい！と思い、実践やイベントで様々な意見を交わしていきました。
その際に得た情報や、自分なりに出したふりかえりについてお話します。

この話を通じて、「ふりかえり」について、ふりかえるきっかけになってもらえたらと思います。

※ LED-Campは、組込みシステム開発の初学者や未経験者、また、興味のある方を対象とした合宿形式の勉強会です。若手の社会人や学生が一堂に会し、組込みソフトウェア開発の基礎を学びます。実習を通して、モデル駆動開発とスクラムを学び、チームで解決することを体験します。
詳しくはリンクを見てください！

あなたの組織はアジャイルな開発を志ざし、スクラム開発を取り入れ、素晴らしい結果を得ることができました！ おめでとうございます！

全社共通の人事制度では3ヶ月ごとに個人目標を設定し、メンバーから360度フィードバックを集め、成果を評価します。半年ごとに成果に応じた賞与があり、昇進の機会もあります。上司からアジャイル開発の推進者として信頼されているあなたは「スクラム開発での目標設定・フィードバック・評価はどうしたら良いのか」と相談を受けました。プロダクトの成功にばかり集中していてそのことをすっかり失念していたのです。

スクラム開発では全員が一丸となり同じ目標を追います。・・・でも個人ごとの目標を決めるルールです。メンバーのキャリア・成長はどう導いていきましょう? 誰が何の貢献をしたのかどう評価しますか?

アジャイルな開発を長く続けるために、たまにはマネージャーの悩みを一緒に考えてみませんか?

※Scrum Fest Osaka採択後、福岡セッション枠の45分で話すことになったため情報を更新しています。

伝えたいこと

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

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

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

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

スクラムと私

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

会社の文化（カルチャー）変革の7年間の軌跡。

2013年ごろ、色々な問題が噴出し、会社としても個人（経営者）としてもどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化（カルチャー）が形成されるようになりました。

その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

今回は、Developer Summit 2020 での講演（45分）のロングバージョンとしてもう少し詳しく、それぞれの取組みについてお話したいと思っています。（Developer Summit 2020ではベストスピーカー賞を受賞しました。https://codezine.jp/article/detail/12140 ）

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

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

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

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

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

予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be

数度目のアジャイル開発戦争が勃発。
内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。

Scrumの加護をうけし組織となるために工作を展開する企業。
それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。

終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・

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

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

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

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

実験場はどうして必要か？

企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。

でも、それ大丈夫ですか？
安全ですか？失敗しても大丈夫ですか？失敗しないようにがんばりますか？
でも、失敗ってしたほうがいいんですよね。

会社組織は良い実験場か？

そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね？
失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。

そうならないように、安全に実験できる場所を探しましょう！
そのためのサバイバルテクニックを考えましょう。

サバイバルテクニック

#1 趣味を増やそう！

単に趣味を増やすことに意味はありません。
社会性が得られる趣味であれば、それは立派に実験場として機能します。

#2 地域コミュニティに参加しよう！

PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。

#3 家族を実験に

家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。

このワークショップは一言でエレベーターピッチの強力版です。

次のような悩みに効果的です。
・「良い商品なのに売れない、自社(自分)に強みがあるのにお客様に喜んでもらえない。」
・「日々、頑張っているものの報われないことも多く、意気消沈してしまう」

私は20代前半から新規事業に取り組み、自費でも数百万の借金をするなどして挑戦してきました。良い商品なんだけど売れない、強みがあるのに買ってもらえないとずっと悩み続け、どうしたらお客さんの喜びにつながるのだろうと考え続け、試行錯誤してきました。

そのうち徐々にうまくいくにつれて、お客さんから「弊社のこと、なんでそんなに知っているんですか? もしかして勤めていたことがあるんですか?」と驚かれたり、喜んで値引き無しに買ってもらえるようになりました。

その中で学んだ重要なポイントは開発だけでなく、顧客との付き合い方や売り方もアジャイルに適応してくことです。

今回は「顧客との付き合い方や、売り方もアジャイルに適応してく」ためのワークを行います。顧客と良い関係を結ぶためのヒントがえられるセッションにしたいと思います。

・商品/サービス/強みについて考える
・顧客を考える
・競合を考える
・セールス/プレゼンテーションを考える
・ロールプレイしてみよう/セールスマップでユーザーにも決裁者にも響くアプローチを整理してみよう

「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
「このエピソードは、どこでも起きうる話なのだろうか？」
「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか？」

事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか？

レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。

今、現場で起きている課題の先に光があるのだろうか？そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。

※本セッションは、「アジャイルチーム成長の過程ってどんな感じ？(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を１つにまとめて再構成するものになります。

さぁ、スクラムマスターやるぞ！で、まず何をすれば良いんだっけ…？
CSMの資格とったよ！とはいえ、実際現場でどうふるまえば良いのかちょっと不安…

教科書的な知識はいろいろなところで学べますが、実際の現場に立つのはいつも不安とワクワクで溢れてますよね。
私も同じです！

一方、ベテランスクラムマスターのみなさん！
「何から取り組めば良いですかね？」と新米スクラムマスター相談されました。
さぁ、なんと答えますか？

ということで、そんな新米スクラムマスターの不安を少しでも取り除いて、ワクワクを大きくしたい！
自分が相談されたときにきちんと答えられるようにしておきたい！
そんな気持ちから、
こんな取り組みしたな。こんな失敗したな。これは良かったな！
といったような、自身の経験を振り返ってみました。

振り返る中で、

• やっぱりこういったことは大事にしたいな。
• まずはこういったことを意識してやってみると良いかも。

といったようなものも整理してみたので、その超個人的な見解をみなさんに共有したいと思います。

お話しするキーワードはこんなものを想定しています（変わる可能性は高いです）
エピソードも含めて共有させていただきます。

• まずはチームから信頼を得よう
• チームに集中できる環境にしよう
• 焦らずじっくりやっていこう
• 必要は最高のモチベーション
• チームのカラーはそれぞれだよね
• 仲間をつくろう

などなど

現場によって状況は様々でしょうが、
「聞いてくれた人にとって、少しでも勇気を与えられ、励みになれば」
と思っています。

講演後に、ぜひいろいろお話ししましょう！！！

モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、具体的にどういうことがいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりのログを徹底的に取っていきました。

そうすると、うまくいっているモブの状態や行動に、あるパターンが見えてきました。しかもそのパターンは、チームで不確実な問題を解決していくうえでのメンタリティーを援けているばかりでなく、高い品質をはじめから埋め込んでいく仕組みを裏付けていました。これを言語として表現して、その言葉で議論していけば、さらなるモブの改善や、モブ文化の伝達に寄与することが期待されます。

これはあくまでも、サイボウズのケースですが、モブの推進の参考になればと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

失敗に成功した！

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

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

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

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

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

スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskが、いかにして海外を中心に4ヶ国・6都市で1500名体制を構築してきたのか。また、ベトナムをはじめとする、海外で培ってきた人材育成や教育の手法をご紹介します。