シン・モブプログラミング 第三形態

サイボウズでは2018年に、kintoneの開発部隊からモブが部分的に始まり、それが、チームの拡大とともにkintoneの開発チーム全体に広がった。そのモブは、高い心理的安全性をベースに、チームにおける認知活動が行われていた。チームメンバー同士の多様性による創発と、高いレビュー効果があいまって、モブ・プログラミングの効果を出していた。
とそこで、最近、モブに対する反発の行動が一部にでてきた。以前もあった一過性のものと思っていたが、今回は思いのほか深く、あるチームの運用にも影響を与えることがあった。HunterのChrisにも意見を聞き、我々はそれに今向き合い、新たな形を模索しながら、今でもモブの活動は行われている。

Transcript

3. アジェンダ 第一形態 起 第二形態 承 第三形態 転 第四形態‥ 探
5. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 Devの全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote 2018/8 １個流し開始、３チーム体制 2018/10 モバイルチーム 2018/11 ４チーム体制 2019/1 Chris Lucian RSGT2019 keynote サイボウズ Kintoneのモブ・プログラミング
6. 2016/11 スクラム導入 １チーム体制 サイボウズ Kintoneのモブ・プログラミング
7. 2016/11 スクラム導入 １チーム体制 2017/7 モブ・プログラミングの導入 サイボウズ Kintoneのモブ・プログラミング
8. 比較的早い時期からモブ・プロは入っていた そして、今でも使われている
9. ２０１７年６月には、リアルでのモブ・プロを試していた ”他人のやり方が勉強になった“ ”コードを書いてて見落としていた点を素早く指摘できた“ ”楽しいだけでなく有用な手法であると実感できてよかった“ ”今後ももうちょっとモブプロを探求してみたい“ ”普段の業務でもペアっぽいことができたらいいのかなと思いました“
10. 前提条件 もうこのころからリモートでの多拠点での開発が行われていた つまり、モブ・プログラミングはこのころからリモートで行われていた
11. 2016/11 スクラム導入 １チーム体制 2017/7 モブ・プログラミングの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 サイボウズ Kintoneのモブ・プログラミング
12. 2017/9 モブ・プログラミングの改善 P: ペアプロやモブプロの良いやり方をあまり知らずに、やっているところがある。 ペアやモブに向いているタスク、そうでないタスクがある気がする ペアやモブの良いところと課題の認識 どういう時にペア（モブ）を組むべきか • 複雑な問題を解決したい時 • 教育・スキル伝達が目的のとき • 一人でやるのは不安な時 交代の時間はどうするか コードに集中しづらい時どうするか 集中しづらい時は一人で作業したり確認の時間をとってOK ペア（モブ）を組むべきでない時 • 集まっても問題が解決しない時 • 教育or効率アップに繋がらない作業 ＋集まってやるほどの複雑な作業じゃない場合 レビューの必要性 コードに集中しづらい
13. 2016/11 スクラム導入 １チーム体制 2017/7 モブ・プログラミングの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 Devの全作業ペア・モブ化 サイボウズ Kintoneのモブ・プログラミング
15. 2016/11 スクラム導入 １チーム体制 2017/7 モブ・プログラミングの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 Devの全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 サイボウズ Kintoneのモブ・プログラミング
16. スプリント PBI Done Sprint Planning 2 仕様書作成 プロダクトバックログアイテム 設計・実装・テスト Sprint Review Sprint Planning 1 バックログ 説明 割り当て タスク実行 モブ・アクティビティ Kintone 開発プロセス Sprint Planning 2 受入テスト 設計 仕様書変更 プロダクトバックログアイテム 設計・実装・テスト
17. バックログ QA 設計 レ ビ ュ ー 仕 様 作 成 PM デザイン QAをプランニングに呼ぶ レ ビ ュ ー 受 け 入 れ テ ス ト 設 計 システムテスト 設計・実装 受入テスト 実装実施 設計・実装 システムテスト 実施 スプリントプランニング２
18. 2016/11 スクラム導入 １チーム体制 2017/7 モブ・プログラミングの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 Devの全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 サイボウズ Kintoneのモブ・プログラミング
19. タスク設計 モブ テスト仕様 タスク実行 実装モブ 懸 念 点 出 し ・ モ ブ QA 設計 テ ス ト 設 計 ・ モ ブ 仕 様 作 成 ・ モ ブ PO UIデザイン リスクリスト 仕様書 受入テスト 試験設計書 ゴールの共有 共有の 形式化 品質の 埋込み ビルド・CI 品質の 確認 リリース テスト実装 テスト 仕様書 テスト実行 品質の 確認 スプリントプランニング２ バックログ
20. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 Devの全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote サイボウズ Kintoneのモブ・プログラミング
21. Agile Japan ２０１８/7 モブプログラミングと “フロー”の力 Woody Zuill 氏
22. Team Flow：チームフロー
23. リーン・フロー ”モブプログラミングでは 何を最適化するかというと、 個人のアウトプットではなく、 仕事のフローを最適化していきます”
24. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote 2018/8 １個流し開始、３チーム体制 サイボウズ Kintoneのモブ・プログラミング
25. １個流し 結果として、 チームで１個のバックログを モブ・プログラミングで行うパターンとなる
26. • • • • • • • • • • • • • • • • ▪ • • • • • • • • • • • • • ▪ ▪ • • ▪ • ▪ ▪ ▪ • • • ▪ ▪ • • • ▪ • ▪ • • • ▪ ▪ • • ▪ • • • • ▪ • ▪ • • ▪ • • ▪ • • • • • ▪ • • ▪ • • • • • ▪ • • • • • • • • • • • • • • • • • • • • ▪ ▪ • • • • • • • • • • • • • • • • ▪ • • • • • • • • • • • • • • • • • • • • • • • • • • ▪ • • • ▪ • ▪ • • ▪ ▪ • • • ▪ • ▪ • • • • • • • • ▪ • • • • ▪ • • • • • ▪ ▪ • • ▪ • • • • • • • • • • • • • • • スプリント バ ッ ク ロ グ フローグラフ
27. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/1 ２チーム体制 2018/2 全作業ペア・モブ化 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote 2018/8 １個流し開始、３チーム体制 2018/10 モバイルチーム 2018/11 ４チーム体制 2018/12 品質保証部がなくなる サイボウズ Kintoneのモブ・プログラミング
28. モブ・プログラミングの拡散 他のプロダクトの開発に広がる ◆ Galoon ◆ Clara ◆ Yakumo
29. モブ・プログラミングから、モブ・アクティビティへ プログラミングだけじゃない プランニング ドキュメント作成・修正・保守 テスト計画、設計、実装、実行 バックログ開発、リファインメント 開発以外の部署にも広がる
30. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote 2018/11 ４チーム体制 2019/1 Chris Lucian RSGT2019 keynote 2019/5 モブ・メトリクスの測定 サイボウズ Kintoneのモブ・プログラミング
31. 0 5 10 15 20 25 30 35 40 45 50 つぶやき あいづち 質問 説明 コメント 依頼 回答 提案 気づき 学び 言い換え 合意 改善変更 確認 感謝 モブメトリクス やり取りの分布 Driver Nav1 Nav2 Nav3 モブ・プログラミング分析 専用キーボート
32. モブ・メトリクス：自系列分析
33. モブ・チーム認知モデル 次のステップ 対象 次のステップ ドライバ つぶ やき 自信 質問 相槌 改善 学び 提案 議論 返答 ナビゲータ ナビゲータ 説明 促進ループ 改善ループ
34. 2016/11 スクラム導入 １チーム体制 2017/7 モブの導入 2017/9 モブ・プログラミングの改善、毎月リリース開始 2018/4 Sprint ２のプロセスの改善 2018/5 １週間スプリント、 Sprint ２にQAがモブで参加 2018/7 Woody Zuill ; Agile Japan Keynote 2018/11 ４チーム体制 2019/1 Chris Lucian RSGT2019 keynote 2019/5 モブ・メトリクスの測定 2019/8 Agile 2019, Mob Mentality Showに出演 2019/9 Ｈｕｎｔｅｒ Industry社訪問 サイボウズ Kintoneのモブ・プログラミング
35. Mob Mentality Show @mob__mentality Mob Programming in Japan! @martin_lover_se @kawaguti @kohzas @nagworld on the Mob Mentality Show https://youtu.be/Pu_zpVQrv70 #モブプロ @ChristophLucian
36. Hunter Industry 訪問 2019年9月30日
37. Hunterでのモブメトリクス
38. タイピング ドライバ ＝ タイピスト お頼み ファシリテーション タイピング ナビゲータ Restricted ナビゲータ お頼み お頼み ファシリテーション Hunter（モブ本）のモブ・認知モデル サイボウズのモブは“変異”していますが、問題はありません 私は、サイボウズのモデルが好きです
39. Code with the Wisdom of the Crowd: Get Better Together with Mob Programming 2018/7/24 モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める 2019/2/23
40. モブ・チーム認知モデル 次のステップ 対象 次のステップ ドライバ つぶ やき 自信 質問 相槌 改善 学び 提案 議論 返答 ナビゲータ ナビゲータ 説明 促進ループ 改善ループ
41. モブ・プログラミングは なぜ、このように導入され 使い続けられているのか やっていて楽しい しかも、結構いい結果が得られる
42. なぜモブは楽しいのか
43. Agile Japan ２０１８/7 モブプログラミングと “フロー”の力 Woody Zuill 氏
44. ３つのフロー 個人のフロー チーム・フロー リーン・フロー
45. Flow：フロー https://www.ted.com/talks/mihaly_csikszentmihalyi_flow_the_secret_to_happiness?language=ja 個人のフロー
46. 自分の最高の状態のときにどのように感じていたか “流れている（floating)ような感じだった” “私は、流れ（flow)に運ばれたのです” 時も忘れて、夢中になる状態、その達成感 ウェルビーイング、楽しい、面白い
47. チャレンジ スキル 退屈 無関心 心配 不安 覚醒 フロー コントロール リラックス 高い 低い 低い 高い 体験の質は、チャレンジとスキルの関係によって決まる 最適な体験、 つまりフローは、 両方の変数が高いときに 起こる Sources: Adaptive from Massimini & Carili 1988, Cshikzentmihalyi 1990. Finding flow, Chsikszentmihalyi, 1997
48. Team Flow：チームフロー
49. チームでの最高の状態、フローもあるのでは チームで、集中し、時も忘れて、夢中になる状態、その達成感 Team Flow：チームフロー 一人では解決できない複雑なことをやり遂げる 楽しさ、やりがい、ウェルビーイング
50. ７つの必要条件と４つの性質 Team Flow：チームフロー
51. Team Flowの７つの必要条件 • Collective Ambition: チームの志、強い思い • Common Goal: チームの皆が認める共通のゴール • Aligned Personal Goals: 共通のゴールにも貢献する個人のゴール • High Skill Integration: 個々の長所を総合的な力にアレンジする • Open Communication: オープンなコミュニケーション • Safety: 心理的安全性 • Mutual commitment: 相互に行動とその効果を認識している 組織文化やメンタリティに強く関係している
52. Safety • 心理的安全性 • 失敗を学習と成長の機会として受け入れる • 失敗を心配することなく受け入れられサポートされる • 互いに信頼しあう 信頼 : 弱い立場になることをいとわないこと • 偏見のないフィードバック オープンなコミュニケーション、情報共有 対立を解消するための行動
53. Team Flowの７つの必要条件 • Collective Ambition: チームの志、強い思い • Common Goal: チームの皆が認める共通のゴール • Aligned Personal Goals: 共通のゴールにも貢献する個人のゴール • High Skill Integration: 個々の長所を総合的な力にアレンジする • Open Communication: オープンなコミュニケーション • Safety: 心理的安全性 • Mutual commitment: 相互に行動とその効果を認識している PO 組織文化 メンタリティ
54. モブ・プログラミングは なぜ、このように導入され 使い続けられているのか この、チームフローの必要条件が満たされている この、チームフローが体験できているから
55. Team Flowの４つの特長 ＝ モブ・プログラミングで体感していること • Sense of Unity: 一体感 • Sense of joint progress: 一緒に進んでいるという感覚 • Mutual trust: 相互の信頼関係 • High Skill Integration: 全体的な集中状態を共有する ”チームフローは、個人が、自分のタスクや裁量で行う自律性と能力の体験を通じて 自己決定を行い、チームでの交流を通じて個人的なつながりを持つという形で幸福 を体験することができる” Team Flow: The psychology of optimal collaboration, 2019, Jeff J.J. vam dem Hout, Orin C. Davis
57. いや、モブ・プログラミングはすごい！！ 最強の開発形態だ！！！ いいよ、モブ・プログラミングは！！
59. モブ・プログラミングへの感想 ： ある振り返りにて • モブプロはチームに入ってすぐの右も左もわからない時はすごく助かる • ある程度時間が経つと成長が感じられなくなる • できる人やわかる人に頼ってしまう • 自分ひとりではいつまでもできないと感じる • わからないところは深く理解できないままになる • スキルや経験の豊富な人との差がどんどん広がるように感じる • その人たちが難しいことを解決してしまう • 自分が貢献したという感覚が得られない • 休み明けの時のキャッチアップで質問しづらい • ソロだと、どうにかしないといけない分、できることが増えている・成長している・貢献 していると実感できる この人のモブ・プログラミングを観察し分析することはあったが、このように感じて いるようには思えなかった。
60. 共感する人は結構いた • ソロだと「この機能は自分が作った」という感覚が強くなるが、モブだとそういう感覚が薄くなる • 達成感が弱い • 経験に差があると、経験豊富な人が全部進めてくれちゃって自分が成長できていないと感じるのは すごく共感する • 成長できない • 設計や命名の議論にはモブは効果的だが、成長していく上ではソロでやるほうが良さそう
61. ソロ・コーディングと モブ・プログラミング Solo Coding vs Mob Programming Chris Lucian, Hunter Industry https://www.chrislucian.com/2018/09/mob-programming-and-personal.html
62. Chrisも、モブプログラミングを始めたとき、 同じようなことを感じてた コードの問題を一人で逆境を超えて解決したときの勝利感がない 「簡単」に問題が解けると感じ、それにより退屈を覚える 一人でプログラミングしていたときの楽しさは、 一人だからこそ味わえたものなのか、 もはや、モブではもう味わえないのか。
63. チャレンジ スキル 退屈 無関心 心配 不安 覚醒 フロー コントロール リラックス 高い 低い 低い 高い 体験の質は、チャレンジとスキルの関係によって決まる 最適な体験、 つまりフローは、 両方の変数が高いときに 起こる Sources: Adaptive from Massimini & Carili 1988, Cshikzentmihalyi 1990. Finding flow, Chsikszentmihalyi, 1997
64. 今、私たちのモブチームでも同じような問題に直面しています。 チームに貢献できていない」「達成感がない」という理由で自信を失い、「ソロでや りたい」という話がありました。このことを振り返りの場で話題にしたところ、同じ 問題を感じている人が他にもいることがわかりました。 あるチームでは、バックログをモブ・プログラミングでやるのは割に合わないと判断 し、ソロでやろうとしたメンバーもいました。 みんなモブプログラミングの良さを理解し、感じてはいるのですが、同じように悩 んでいます。 Chrisへの質問
65. アツシさん、コメントありがとうございます。また、簡単な作 業があまりにも「簡単」に思える場合は、自動化することも有 効です。ちょうどいいバランスを見つけられるといいですね。 すべての人を幸せにすることはできませんが、レトロスペク ティブや、個人ではなくチームを改善することにフォーカスす ることで、環境を良くすることはできます。 Chris Lucian
67. わたしは、このような微妙な心理の内側に気づかず、品質面からしか見ていなかった orz Try いくつかのサブチームで試行錯誤して、良さそうな方法に少しずつ乗り換えていくと良さそう モブはフロー効率とか品質の観点からやっているけど、 やりがいとかメンタルの部分も重視していきたい
68. 多様性 モブ・プログラミングは、多様性により、効果を上げている 違う気づき・シナジー・化学変化 多様性：人それぞれ、モブを行うに際して感じ方が違う モブという認知活動がポジティブにもネガティブにも人間の精神の営みに直接影響する 幸福感、達成感を生む つらい感情、退屈、達成感がない
69. とりあえずのトライ ソロとモブ いつ、どのような開発をするか、選択できる 個人でフローを楽しむ チームでフローを楽しむ ハイブリッドでフローを楽しむ
70. 最高のチームでは、メンバーはお互いに耳を傾け、感情やニーズに敏感である プロジェクト・アリストテレス What Google Learned From Its Quest to Build the Perfect Team The New Yoke Times Magazine, 2026
71. 募集 多様性 求む！ サイボウズ ブースにも遊びに来てください！