チームをつくるモブプログラミング / Mob Programming to build teams

デブサミ2020[13-E-8]でのセッションスライドです。

Transcript

1. νʔϜΛͭ͘ΔϞϒϓϩάϥϛϯά ΍ͬͱΉɹ5",",*/( 
   ಺ଆͱ֎ଆ͔ΒޠΔ
   
2. 2001年ごろアジャイルと出会い、開発者、チームリーダー、ト レーナー、導入支援と多様な立場で関わってきた。(株)永和シス テムマネジメントにて2010年頃からアジャイルコーチを主軸とし て活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)
3. https://tddrinking.connpass.com/event/164790/ PR
4. ✤ ٴ෦
   ܟ༤
   
   !5",",*/(
   ✤ גࣜձࣾσϯιʔ
   ΤϯδχΞ
   ✤ ΞδϟΠϧνʔϜΛࢧ͑Δձ
   ཧࣄ
5. ΞδϟΠϧ ίʔν ϖΞεΫϥϜ Ϛελʔ ߨԋɾݚम
   ࣥච ͦͷଞ૬ஊ ͓ؾܰʹ͝૬ஊ͍ͩ͘͞
   㱺
   IUUQTBHJMFNPOTUFSDPN
6. ✤ νʔϜ໊ɿ4*-7&3
   #6--&5
   $-6#
   ✤ ਓνʔϜ
   ✤ Ϟϒϓϩάϥϛϯά
   BT
   ಇ͖ํ
   ✤ ೥݄ʹνʔϜస৬ 5",",*/( 4BUP@SZV ͝ʔͨ
7. ۜͷ஄ؙϥδΦ ݱ৔ͷΞδϟΠϧνʔϜʹΑΔ νʔϜ:PVUVCFνϟϯωϧɺ1PEDBTU࢝Ί·ͨ͠ʂ IUUQTUBLBLJOHDPNTJMWFSCVMMFUDMVCTUBSU
8. νʔϜͷ಺ଆͱ֎ଆ νʔϜ
9. Ϟϒϓϩάϥϛϯάߨ࠲։ઃ༧ఆ IUUQTFWFOUTIPFJTIBKQD[B $PEF;JOF
   "DBEFNZʹͯ
10. Ϟϒϓϩάϥϛϯάͱ͸ ✤ ಉ͡࢓ࣄΛ
    ✤ ಉ࣌ؒ͡ʹ
    ✤ ಉ͡৔ॴͰ
    ✤ ಉ͡ίϯϐϡʔλʔͰ νʔϜશһͰ ͢Δ͜ͱ
12. ✤ ݴ༿͸೥ࠒʹ91ίϛϡχςΟͰੜ·Εͨ
    ✤ )VOUFS
    *OEVTUSJFTൃ঵ͷϞϒϓϩάϥϛϯά
    ✤ ΤϯδχΞϓϥΫςΟεͰ͸ͳ͘࢓ࣄͷελΠϧ
    ✤ ೔ຊͰ΋೥Ҏ͔߱Β੝Γ্͕͍ͬͯΔ Ϟϒϓϩάϥϛϯά
13. ✤ ࢓ࣄΛ෼୲͢Δ͜ͱΑΓ΋ੜ࢈ੑ͕௿͍ʁ
    ✤ Ϟϒϓϩ͸ମݧͯ͠͸͡ΊͯޮՌΛ࣮ײͰ͖Δ
    ✤ ϞϒϓϩΛ͏·͘׆༻Ͱ͖ΔνʔϜ͸ݶΒΕΔ
    ✤ ڭҭతޮՌ͕ߴ͍
    ✤ ୯ൃ͸͍͍͚Ͳ೔ৗతʹ͢Δͷ͸೉͍͠ Α͘࿩ʹग़ͯ͘Δ͜ͱ
15. νʔϜΛϒʔετ͢ΔϞϒϓϩάϥϛϯά ࢓ࣄΛυϥΠϒ͢ΔϞϒϓϩάϥϛϯά
16. ͸͡ΊΔ νʔϜΛϒʔετ͢Δ
    Ϟϒϓϩάϥϛϯά ࢓ࣄΛυϥΠϒ͢Δ
    Ϟϒϓϩάϥϛϯά
17. ✤ ڵຯ͕͋Δͱ͜Ζʹूத͍ͯͩ͘͠͞
    ✤ γϣʔττʔΫʴΫϩετʔΫ
    ✤ ࣭໰͸ର໘΍4/4ͳͲ͔Β͓ؾܰʹ ͜ͷߨԋͷฉ͖ํ
18. ͬ͘͡Γ͓࿩͍ͨ͠ํ͸ͪ͜Β΋Ͳ͏ͧ IUUQTXXXTFTIPQDPNQSPEVDUEFUBJM IUUQTEFWTVNJOPSBQBSUZDPOOQBTTDPNFWFOU  
19. ͸͡ΊΔ
21. ベストプラクティスの例 • モビングを実験として位置づける • 行番号ON • モビングインターバル…１０分ごとに ドライバーを交代する • 経験からの学習…セッション後には毎回、ふりかえりをする • 最初は共感から • 協調的なマインドセットの獲得 • スペースは重要だ
22. 始めるとき気をつけるとよいこと •目的とゴールを定める •進み方を表明する •議論と実験のバランスを取る •その場でフィードバックを得る •ふりかえりをする •個々人のペースとやり方で復習する
23. 目的とゴールを定める • 目的: なにを目指すか、現在の優先事項、方向性 • 例: X機能の開発を全力で進める Yライブラリの使い方を共有する AさんがZモジュールの現状を把握する • ゴール: セッション終了時に到達したい点 • 例： X機能の正常系2パターンを実装してテストする Yライブラリを納得するまで動かして結果を残す AさんがZモジュールのシーケンスを図に描ける 目的や 方向性 ゴールと 進み方
24. 「目的はこれ。いいですか？」ではダメ 「目的はこれこれです。いいですか？」 A) 「いいです(よくない)」 B) 「いいです(と思ったけど違った)」 C) 「いいです(聞いてない)」 • 少し議論や質問をして認識違いや 理解の差異を埋める • 進めながら揃う部分もあるので 深入りしすぎない • セッション途中でも確認する https://www.oreilly.com/library/view/user-story-mapping/9781491904893/
25. 進み方を表明する • モブプロ中、現在地がわからなくなったり、迷子になったりする • いまどこにいるのか、次は何をするのか、ゴールに近づいているかを 常に共有する • ゴールに向かう手順は？ • いまなにしてる？ 次の作業はどれ？ • やろうとしていることの全体像は？ どのくらい終わった？
26. 進み方を表明するツール TODOリスト 作業の区切り ここまでできたね 快調！ このTODOは☑ね 次はどれだっけ こっちのTODO？ あれ先にしない？ それがいいかも！ ドライバーがしゃべる さてABCメソッド 書くぞ あれ、DEFだっけ 正常系はこうで 変数名 どうしよっかな FOOBARは？ FOOBAR…と 戻り値の型int？ intでよかった
27. 進み方を表明するツール TODOリスト 作業の区切り ここまでできたね 快調！ このTODOは☑ね 次はどれだっけ こっちのTODO？ あれ先にしない？ それがいいかも！ さてABCメソッド 書くぞ あれ、DEFだっけ 正常系はこうで 変数名 どうしよっかな FOOBARは？ FOOBAR…と 戻り値の型int？ intでよかった intだとダメじゃね そう？ いい気がする 結果ゼロどうする？ 例外かと思った 例外でいいね なにしてたっけ コメント忘れてた 条件書き換えて テストしたい テストあるよ テスト変更し いやケース追加 このケースある テスト足らんじ あとにしよう えー…はーい できた気がする 処理がこうで、 チェックがあっ 引数のバリデー ンは…しなくて ので、ループの もいいし、フェ ポストエラーは ドライバーがしゃべる 注意: ナビゲーターがもうちょっと仕事したほうがよい あーうー…あー あーーー！おけ これでよさげ わからん…
28. 議論と実験のバランスを取る • モブでの議論は大事 • 知見を出しあってお互いから学べる • 創造的な騒々しい議論ができる • 知識が組み合わさって新しいアイデアが得られる • 話すだけではなく、試してみる • いいアイデアが出たら、書いてみる • 複数のアイデアは、書いて見比べる • 議論が平行線になったら、実際に動かしてみて比べる • 最初は議論 ＜＜ 実験くらいの気持ちで • 結論が出るまで話す ＜ 試してから結論を出す • 書く時間がもったいない ＜ 書けば判明する・共有できる情報がもったいない
29. その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト)
30. その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E)
31. その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E) 仕様漏れ がない (品 質テスト) よい設計 (リファクタ リング) モブ外の 人の評価 外部 システムと つながる
32. その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) 仕様漏れ がない (品 質テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E) よい設計 (リファクタ リング) モブ外の 人の評価 外部 システムと つながる 楽しい！ 学びが多い！ 品質向上！
33. その場でフィードバックを得る • 作業が“ちゃんと”進んでいるかどうか、モブの中でわかるように • 後で問題がわかっても、モブに伝わらない • 全員が正しい理解や学びを、できるだけたくさん得る • 動いたほうが楽しい！
34. ふりかえりをする • モブ作業を終えるとき • 全員で一緒に • やりかたはいろいろ • モブの延長として、みんな声を出すスタイルがおすすめ https://www.ogis-ri.co.jp/otc/hiroba/others/ActivityPocket/FunDoneLearn.html マインドマップでふりかえり して共有(リモート) ファンダンラーン 参考書籍
35. ふりかえりのねらいは2つ • よりよいプロダクトを目指す • よりよいモブプログラミングを目指す
36. 学びを積み上げる • ふりかえりの結果を再利用できる形で残していく
37. 個々人のペースとやり方で復習する • 復習 ― モブの中で得た新しい知識を定着させる • セッション後に一定の時間を確保する • スタイルは個々人の自由 • ひとりで復習してもよい • モブ体制を維持しながら、個人作業としてもよい • モブとして復習するのもよい ※復習に限らず、モブへの参加・離脱は各自の判断でゆるくてもよい
38. ϞϒϓϩΛ࢝ΊΔͱ͖ʹͲ͏࢝ΊΕ͹͍͍͔ʁ
    ಛʹωΨςΟϒͳ൓ԠΛ͞Εͨͱ͖ʹ͸ʁ ໰͍
39. • まずは試してみましょうというアプローチ。実験としてやってみると よい。実験したうえで、このチームではどう進めるといいのか話し合 う。 • モブプロを教えてくれる外部の人を呼んできて、やり方を教えても らったり、ガイドしてもらう。外部のお墨付きとして利用する。 • 外部の勉強会などでモブプロを体験したメンバーが、これは良 かったからやってみようと持ち帰ってくるのもよい。
40. ʮݸਓͰ࡞ۀʢֶशʣ͍ͨ͠ʯ
    ͱݴΘΕͯ͠·ͬͨΒͲ͏͢Ε͹͍͍ʁ ໰͍
41. • 個人でやりたいというのは、それでよい。モブだから全員拘束する という必要はない。 • とはいえまずは試してみる方がよい。実感してから、どういう仕事を モブでやるか、どういうモブを組むと良いか考える。 • 最初は抵抗感がある人でも、やってみたら思ったよりよかったと感 じる人は、けっこう多い。 • Hunter Industriesの動画では、複数のモブの中を個人がけっこう 自由に移動している様子が見られる。 https://youtu.be/dVqUcNKVbYg • 大事なのは仕事を進めること。スタイルにこだわるべきではない。
42. νʔϜΛϒʔετ͢Δ
    Ϟϒϓϩάϥϛϯά
43. ✤ νʔϜͷ಺ଆΛڧ͘͢ΔϞϒϓϩ
    ✤ ϞϒϓϩͷڧΈΛ׆͔͢
     ڭҭతޮՌ͕ߴ͍
    ‣ ஌ࣝҠస
    ‣ ϨϏϡʔ νʔϜΛϒʔετ͢ΔϞϒϓϩͱ͸ʁ
44. Ϟϒϓϩάϥϛϯά
    º
    ஌ࣝҠస
45. ✤ ܦݧ஋͕௿͍ਓΛυϥΠόʔʹ͢ΔͱΑ͍
    ✤ ࢓ࣄΛࢭΊΔ͜ͱ͕Ͱ͖ΔݖརΛ౉͢
    ✤ ஌ࣝͷδϟετΠϯλΠϜ
    ✤ ฉ͖ͳ͕ΒखΛಈֶ͔ͯ͠Ϳ͜ͱ͕Ͱ͖Δ
    ✤ ࢀՃ͍ͯ͠Δશһʹಉ࣌ʹ఻͑Δ͜ͱ͕Ͱ͖Δ Ϟϒϓϩάϥϛϯάͱ஌ࣝҠస
46. 4&$*Ϟσϧ
47. ✤ ҉໧஌ʹܗࣜ஌ʹͳΒͳ͍΋ͷ
     ίʔυͷ૊Έཱͯํ
     πʔϧ΍*%&ͷ࢖͍ํͷίπ
     ͳʹΛɺͲͷΑ͏ʹɺͳͥͭͬͨ͘ͷ͔
     ͲΜͳ໰୊ղܾ͕͋ͬͨͷ͔ɺۤ࿑ͨ͠৔ॴ
    ✤ ҉໧஌΋ܗࣜ஌΋·ͱΊͯڞ௨ମݧͰ఻͑Δ ҉໧஌΋·ͱΊͯ఻͑Δ
48. Ϟϒϓϩάϥϛϯά
    º
    ϨϏϡʔ
49. 1IPUP
    CZ
    ϑϦʔࣸਅૉࡐͺͨͦ͘
    IUUQTXXXQBLVUBTPDPN ϨϏϡʔ͓͡͞Μ໰୊ ΤϯδχΞͱͯ͠εΩϧΞοϓ͍ͯ͘͠ͱɺ
    ΤϯδχΞϦʔμʔ΍ςοΫϦʔυΛ೚͞ΕͨΓ͢Δɻ ͦ͏ͳΔͱɺϝϯόʔڭҭ΍඼࣭୲อ΍γεςϜ҆ఆՔಇͷ੹೚͕ͷ͖ͬͯͯɺ
    ྫ͑͹ϨϏϡʔΛ͢Δ͕࣌ؒͲΜͲΜ૿͍͑ͯ͘ɻ ΋ͱ΋ͱΤϯδχΞϦϯά͕޷͖ͰΤϯδχΞΛ΍͖ͬͯͨΜ͚ͩͲɺ
    εΩϧΞοϓ͍ͯ͘͠ͱͲΜͲΜίʔυΛॻ͕࣌ؒ͘ݮ͍ͬͯ͘ͷͬͯͳΜ͔ͩͳ͋ɻ
50. ϨϏϡʔͷ໨తͷ෼ྨ $IFDL -FBSOJOH &OIBODF ݕࠪ ֶश ڧԽ w ඼࣭Λ୲อ͢Δ
    w όάΛݟ͚ͭΔ
    w ςετͱͯ͠
    w ʢ࠷௿ݶͷʣ
 ϦϑΝΫλϦϯά w φϨοδͷڞ༗
    w εΩϧτϥϯεϑΝʔ
    w ৽ਓڭҭ
    w จԽͷৢ੒ w ϦϑΝΫλϦϯά
    w ΋ͬͱΑ͘
    w ΋ͬͱΩϨΠʹ
    w ઌߦ౤ࢿ
51. ϞϒϓϩάϥϛϯάͷΧόʔൣғ $IFDL -FBSOJOH &OIBODF ݕࠪ ֶश ڧԽ
52. ✤ ϦΞϧλΠϜϨϏϡʔ
    ✤ λΠϙ͢Δͱ਌ͷٲͷΑ͏ʹࢦఠ͞ΕΔ
    ✤ νʔϜશһͷ߹ҙͷ΋ͱͰίʔυ͕૊·Ε͍ͯ͘
    ✤ ዁౓ͤͣʹνʔϜͷϕετΛ໨ࢦ͢͜ͱ͕Ͱ͖Δ ϞϒϓϩάϥϛϯάͱϨϏϡʔ
53. ✤ ޻ఔͱͯ͠ͷϨϏϡʔ͸ϞϒϓϩͰ୅ସͰ͖Δ
    ✤ ݕࠪ΋ֶश΋ϦΞϧλΠϜͷํ͕ޮՌతͳ͜ͱ͕ଟ͍
    ✤ ׬શʹϨϏϡʔ͕ඞཁͳ͘ͳΔΘ͚Ͱ͸ͳ͍ ϞϒϓϩάϥϛϯάͱϨϏϡʔ
54. ϞϒϓϩάϥϛϯάͷΧόʔൣғ $IFDL -FBSOJOH &OIBODF ݕࠪ ֶश ڧԽ
55. 3FWJFX ࠶ͼ ݟΔ
56. ڧΈ ऑΈ ϦΞϧλΠϜ
 Ϟϒϓϩάϥϛϯά ϨϏϡʔ
    3FWJFX ✤ ৗʹνʔϜͷϕετΛ
 ໨ࢦ͢͜ͱ͕Ͱ͖Δ
    ✤ ݁Ռ͚ͩͰͳ͘ϓϩηεΛ
 ධՁ͢Δ͜ͱ͕Ͱ͖Δ ✤ ྫྷ੩ʹݟΔ͜ͱ͕Ͱ͖Δ
    ✤ શମ࠷దΛߟ͑ͯϑΟʔυ
 όοΫ͠΍͍͢ ✤ ͦͷ৔ͷ೤ʹΑͬͯޡͬͨ
 ൑அΛͯ͠͠·͏Մೳੑ
    ✤ ہॴ࠷దʹؕΔՄೳੑ ✤ ዁౓͕ੜ·Ε΍͍͢
 FY
    ΠϚΠν͚ͩͲ͕࣌ؒͳ͍͔Βʜ
    ✤ ݁ՌͷΈͰಡΈऔΕͳ͍
 ෦෼Λ஌ΔͨΊʹ͸ɺ
 ίϛϡχέʔγϣϯ͕ඞཁ
57. ڧΈ ऑΈ ϦΞϧλΠϜ
 Ϟϒϓϩάϥϛϯά ϨϏϡʔ
    3FWJFX ✤ ৗʹνʔϜͷϕετΛ
 ໨ࢦ͢͜ͱ͕Ͱ͖Δ
    ✤ ݁Ռ͚ͩͰͳ͘ϓϩηεΛ
 ධՁ͢Δ͜ͱ͕Ͱ͖Δ ✤ ྫྷ੩ʹݟΔ͜ͱ͕Ͱ͖Δ
    ✤ શମ࠷దΛߟ͑ͯϑΟʔυ
 όοΫ͠΍͍͢ ✤ ͦͷ৔ͷ೤ʹΑͬͯޡͬͨ
 ൑அΛͯ͠͠·͏Մೳੑ
    ✤ ہॴ࠷దʹؕΔՄೳੑ ✤ ዁౓͕ੜ·Ε΍͍͢
 FY
    ΠϚΠν͚ͩͲ͕࣌ؒͳ͍͔Βʜ
    ✤ ݁ՌͷΈͰಡΈऔΕͳ͍
 ෦෼Λ஌ΔͨΊʹ͸ɺ
 ίϛϡχέʔγϣϯ͕ඞཁ ิ׬ؔ܎
58. ϞϒϓϩάϥϛϯάͱϨϏϡʔͷ૊Έ߹Θͤ $IFDL -FBSOJOH &OIBODF ݕࠪ ֶश ڧԽ ϨϏϡʔ w ;Γ͔͑Γ
    w ࣗ෼ୡͷ࢓ࣄͷධՁ
    w ΋ͬͱΑ͘͢Δʹ͸
59. த௕ظతͳࢹ఺ͰϞϒϓϩάϥϛϯάΛ׆༻͢Δ
60. ϞϒϓϩΛத৺ʹਐΊͯ
    ஌ࣝҠసΛ͠ͳ͕Β
    νʔϜͷจԽΛৢ੒͢Δ ιϩɺϖΞΛ૊Έ߹Θͤͯ
    εϐʔυΛ্͛Δ ϞϒϓϩʹΑͬͯ
    ଐਓԽΛ๷͗
    νʔϜͷจԽΛอͭ ॳظ ͏·͘·ΘΓ࢝ΊͨΒ
61. ϨϏϡʔͷதͰͲΜͳձ࿩͕ग़Δͷ͔ʁ
    έϯΧʹͳͬͨΓ͢Δ͜ͱ͸ͳ͍ͷ͔ʁ ໰͍
62. • 特に始めのうちは、変数の命名、関数の書き方、これモデルに書い ていいんだっけ？などの議論が盛り上がる。そうした話を全員です るのが大事で、全員の認識がそろえば、ソロで書いてもちゃんとそ ろったコードが書けるようになる • ケンカになるという話は聞いたことがある。もともと仲が良くない チームがモブプロのような密なコミュニケーションをしようとしたら 爆発するのは当たり前で、モブプロのせいとは言えない。 • ケンカや議論自体は悪いことではない。ケンカのようなやり取りを 通じて相互理解が進んだり、隠れたフラストレーションがないか チェックする機構になる。 • 無用に感情を傷つけるような言葉は避け、伝えるべきことを伝える 丁寧なコミュニケーションをする。
63. ʮΘ͔Βͳ͍Ͱ͢ʯͬͯݴ͑ͳ͍ਓ͕
    ग़ͯ͠·͍·ͤΜ͔ʁ ໰͍
64. • 言えない人は出る。仕事が進んでいるところを止めるのは心苦し いもの。ドライバーは止められるが、ドライバー以外の人はどうす るか。たとえば1時間おきに一時停止して、理解の度合いを確認し たり、復習したりする時間を取る。 • チーム内でスキルや知識のある人にとっては、周囲に伝えるよい チャンス。周りの人ができるようになれば、本来やりたいことに集中 しやすくなる。この考え方を、スキルのある人に理解してもらう。
65. ࢓ࣄΛυϥΠϒ͢Δ
    Ϟϒϓϩάϥϛϯά
66. 仕事をドライブするモブプロとは？ • ソロワークより優れた成果を出せるモブプロ • 「優れた成果」とは何か？ • モブプロの真価 • 全員の知識を生かせる • 個々人の総和以上の成果が出る • エンゲージメントが引き出される • オーバーヘッドが最小になる
67. モブプロが生きる仕事 仕事に生かす モブプロの強み 仕事に生かせない 高度な知識を 組み合わせる 全員の知識を生かせる 形式的に定義された知識 均一な知識 解くべき問題が複雑 個々人の総和以上の 成果が出る 容易な問題の積み重ね 創造性が求められる エンゲージメントが 引き出される 単純作業 密な連携が必要 オーバーヘッドが 最小になる 明確に切り分け、 定義された作業 ルーチンワーク
68. モブプロが生きる仕事 最近の経験だと… ✓スクラッチ開発2ヶ月弱 ✓メンバーはいるけどパートタイム ✓知らんサービスいろいろ試す ✓どレガシーな既存システムと結合 ✓もやっとしたイメージだけで 何を実現したらいいかわからない ✓でも本番でユーザーに見せる (マジで？) • 新しいことを試す • 未知のものを使う • 全体的な設計 • 問題が複雑 • 正解がわからない • いろいろ起きて、どんどん対処する • 曳光弾開発 (『達人プログラマー』) • 顧客も一緒 • メンバーのスキルが高い • みんな乗り気 • 一部屋占拠して部室化
69. 必死にデプロイ中 なんかあったら すぐ参加できる 全体がモブ
70. なぜモブプロを導入するのか？ A) 仕事の成果を向上するため(品質、生産性) B) 教育や、知識の伝達のため •プロダクトのため •チームのため
71. 仕事に生かすかチームに生かすか？ 仕事に生かす モブプロの強み チームに生かす 高度な知識を 組み合わせる 全員の知識を生かせる メンバーどうしで学びあう 解くべき問題が複雑 個々人の総和以上の 成果が出る 自分の力の出し方を学ぶ 協力が上手になる 創造性が求められる エンゲージメントが 引き出される モチベーションが上がる 障害物が見つかる 密な連携が必要 オーバーヘッドが 最小になる 文化を醸成、維持する
72. モブの目的: 仕事かチームか 仕事をドライブ • 詳しい人がドライバー • 今やるべき箇所をやる • 議論する • 幅広いメンバーでやる チームをブースト • 詳しい人がナビゲーター • 難しい箇所をやる • 質問する • 必要なメンバーでやる
73. 高 パ フ ォ ー マ ン ス 低 チームブースト重視 仕事ドライブ重視 アプローチ 仕事面 チーム面 合計 こうかな？
74. 高 パ フ ォ ー マ ン ス 低 チームブースト重視 仕事ドライブ重視 アプローチ 仕事面 チーム面 合計 こうじゃない？
75. 高 パ フ ォ ー マ ン ス 低 チームブースト重視 仕事ドライブ重視 アプローチ 仕事面 合計 むしろこうしたい チーム面
76. モブの目的: 仕事もチームも 教育軽視 教育重視 仕事軽視 簡単な仕事 仕事重視 難しい仕事 研修 タスク丸投げ 優秀な人がレビューする できなかったら 教える さしみタンポポ OJT 常時レビュー その場で理解する 全員の知識を使う 品質の高い成果を 完成する ベストの仕事をする できる人に任せる 使い捨て人材 議論と実験 優秀な人がタスクアサイン
77. 仕事面 高 パ フ ォ ー マ ン ス 低 チームブースト重視 仕事ドライブ重視 アプローチ 合計 チームが成長し 学びが高度化していく チーム面 チームが学び成長する モブプロが上手になる
78. 責 任 大 ← → 小 能力 →高 低← 学習 パニック 快適
79. 責 任 大 ← → 小 能力 →高 低← 学習 パニック 快適
80. 「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」
81. 図3. グルー プレベルで 研究した心 理的安全性 の関係
82. 仕事をドライブするモブ • モブの「成果」として何を求めるか考える • モブに向いた仕事を選ぶ、モブに向くよう仕事を作る • 成果が出るようチームをブーストする
84. ΍ͬͺΓ࢓ࣄΛ෼୲ͯ͠ਐΊΔΑΓ΋
    ੜ࢈ੑ͸མͪͯ͠·͏ͷͰ͸ͳ͍͔ʁ ໰͍
85. • 単純作業ならモブのメリットはない。仕事の成果に対する評価を見 直したうえで、モブプロすべき仕事を選ぶ。 • そのうえで生産性を考えてみると、適切な人数は意識するべき。い まチームに10人いるから10人のモブにすると、短絡的に決めない 方がよい。 • モブをやる中で個人が学んで成長することから、中期的に全体の パフォーマンスがよくなるという側面もある。 • 短期的に見ては難しいので中長期的に見る。チーム全体の成長を 見る。モブに求める成果を見直す。
86. ΄ͲΑֶ͍शঢ়ଶʢ৺ཧత҆શʣʹ
 ਎Λ͓ͨ͘Ίʹ޻෉͍ͯ͠Δ͜ͱ͸͋Δͷ͔ʁ ໰͍
87. • チームが安定した状態というのは、よく見るとめったにない。周囲で はいろいろなことが起きているのだが、ベテランだったりリーダ だったりの個人が見つけて対策して、チーム全体に影響しないよう にしていることが多い。それをあえて、モブとして取り組むように切 り替えるとよい。 • 人工的に外部から新しい知識を取り込むラーニングセッションを、 定期的におこなう。学んだことを自分たちで積極的に試してみる。 す。
88. ίʔν໨ઢͰϞϒϓϩΛ͏·͘࢖͑ͯΔͳʔ
    ͍ͬͯ͏νʔϜͷಛ௃͸͋Γ·͔͢ʁ ໰͍
89. • 楽しそうなチーム。具体的には、発言が均等になっていて、しゃべ る人・しゃべらない人という区別がない。 • ドライバーが流動的で、この部分は誰がやるという固定化がない。 • モブ外の人、マネージャーとか部長とかがモブを放っておいてくれ ている。そういう仕組みができている。
90. ·ͱΊ 1IPUP
    CZ
    .JDIBFM
    $PVSZ
    PO
    6OTQMBTI
91. ʮϞϒϓϩʜ͍ͬͯ͏͔νʔϜͷ࿩ͳΜͩΑʯ
92. Ϟϒϓϩάϥϛϯά͸νʔϜશମͷ׆ಈͰ͋Δ IUUQTXXXTMJEFTIBSFOFUBOESFGBSJBNPCQSPHSBNNJOH
93. Ϟϒϓϩͷ
    lશମੑz
    ʹண໨͢Δ
94. νʔϜͷ಺ଆͱ֎ଆ νʔϜ νʔϜΛϒʔετ͢ΔϞϒϓϩ ࢓ࣄΛυϥΠϒ͢ΔϞϒϓϩ
95. 私(I) 主観的 私たち(We) 間-主観的 この図は『インテグラル理論 多様で複雑な世界を読み解く新次元の成長モデル』を参考にしながら独自に作ったもの https://www.amazon.co.jp/dp/B07TSD52MX それら(Its) 間-客観的 それ(It) 客観的 個人 美意識 文化 スキル 役割 チーム / モブ 美意識 価値観 ミッション 得意範囲 組織？ 全体性を維持しながら成長するには、内側のすべてのレベルと、 四象限すべての方面を包含しなくてはならない 美 善 真
96. νʔϜͷঢ়گʹΑͬͯൺॏ͕ҧ͏ νʔϜͷ֎ଆ νʔϜͷ಺ଆ νʔϜͷ੒ख़౓
97. λοΫϚϯϞσϧ 1FSGPSNBODF 5JNF 'PSNJOH 4UPSNJOH /PSNJOH 1FSGPSNJOH
98. Ϟϒϓϩ
    PS
    /05Ͱ͸ͳ͍
99. ϞϒϓϩʹνʔϜϫʔΫ ιϩϓϩ ϖΞϓϩ
100. ৔໘৔໘Ͱ࠷దͳબ୒Λ͢Δ͜ͱ
101. ڱٛͷϞϒϓϩɺ޿ٛͷϞϒϓϩ ܗࣜͱͯ͠ͷ
     Ϟϒϓϩ νʔϜϫʔΫͱͯ͠ͷ
     Ϟϒϓϩ
102. Ұॹʹߦಈ͢Δ͔Ͳ͏͔͕ॏཁͰ͸ͳ͍
103. ✤ ׂΕͨ૭Λͳ͘͢
     ✤ ֝ͷࣽ෺
     ✤ ఻ୡ͠Α͏
     ✤ %3:ݪଇ
     ✤ ௚ߦੑ
     ✤ ࣗಈԽ
     ✤ ֆըͷ੍࡞ͷ΍Ί࣌Λ஌Δ ୡਓνʔϜ IUUQTBN[OUP/J;F
104. ͦͷͨΊʹ࿹Λຏ͘
105. Ϟϒϓϩάϥϛϯάߨ࠲։ઃ༧ఆ IUUQTFWFOUTIPFJTIBKQD[B $PEF;JOF
     "DBEFNZʹͯ
106. ͬ͘͡Γ͓࿩͍ͨ͠ํ͸ͪ͜Β΋Ͳ͏ͧ IUUQTXXXTFTIPQDPNQSPEVDUEFUBJM IUUQTEFWTVNJOPSBQBSUZDPOOQBTTDPNFWFOU  
107. ૬ޓओ؍ IUUQTBN[OUP2**W/ ϝϯόʔҰਓͻͱΓ͕ࣗ෼ͷओ؍Λ
 อ࣋͢ΔҰํͰɺଞͷϝϯόʔͱڞಉͰ ங্͖͛ΔʮΘΕΘΕͷओ؍ʯͷ͜ͱ
108. IUUQTXXXTMJEFTIBSFOFUZNBFEBTT
109. *
     
     :PV
     ͔Β
     8F
     ΁ Ϟϒϓϩ͸νʔϜͩʂʂ