Slide 1

Slide 1 text

ハッシュタグ:#rakutensapporo Tech Meetup with MobProgramming 山川広人 (@gishi_yama)
 公立千歳科学技術大学 情報システム工学科 1

Slide 2

Slide 2 text

ハッシュタグ:#rakutensapporo Chitose Inst. Sci. Tech., 
 Department of Information Systems Engineering, Senior Assistant Professor
 R&D: Experimental Development of ICT (ex: City-Bus Tacking System) 
 Computer in Education, Programming and Programmer's Learning 
 
 Community: Hiroto Yamakawa, @gishi_yama 2

Slide 3

Slide 3 text

ハッシュタグ:#rakutensapporo モブプログラミングとの出会い 3

Slide 4

Slide 4 text

ハッシュタグ:#rakutensapporo 4 https://youtu.be/p_pvslS4gEI https://youtu.be/dVqUcNKVbYg

Slide 5

Slide 5 text

ハッシュタグ:#rakutensapporo 〈感じた効果〉 エキスパートが集まった発展的開発
 ビギナーとエキスパートが集まった完全習得 開発者とステークホルダーが集まった高精度共有 5 ☜ 今回はここの話

Slide 6

Slide 6 text

ハッシュタグ:#rakutensapporo 初期導入と失敗 6 〈成功を感じる現象〉 • 個々が悩む(ホールドしてしまう)時間の短縮 • 要件や仕様の議論・方針決定での気づき • メンバーのスキルレベルや改善点の確認 〈失敗を感じる現象〉 • テクニックや知識の未定着の繰り返し • エキスパートがいないとモブが進まない • メンバーがモブの時しか作業をしない 大学の教員(エキスパート)と、
 学部4年生(システム開発は素人)の
 プロジェクトに導入 うまく行っている部分も
 あるが、メンバーが巣立つ
 気があまりしない...

Slide 7

Slide 7 text

ハッシュタグ:#rakutensapporo 原因と対策 7 モブプログラミングは「集まって作業する」だけではない、うまく進めるための作法やノウハウが必要 自分たちの経験もふまえ、
 特にモブプログラミングに慣れていないメンバーにむけた
 ルール集(案)を用意して、できるだけ徹底 1. 〈全員〉内職禁止! 2. 〈全員〉 分からないこと・確認しておきたいことを残さない 3. 〈タイピスト〉 モブ全体の合意がない操作やコード化をしない 4. 〈タイピスト〉 自分の想像や知識だけでコードを書かない 5. 〈モブ〉 攻撃や差別、ハラスメントをしない 6. 〈全員〉 時間や順番を守らずに進めてはいけない
       (特に、休憩・振り返りをおざなりにしない) ※ルール集は今も育ててる最中 を参考に、

Slide 8

Slide 8 text

例)実際に勉強会などで提示する内容 1. 〈全員〉内職禁止!
 ノートPCやデバイスが手元にあっても良いが、メモや簡易の検索に限る (なんなら閉じておく)
 割り込み仕事、時間がかかる調査はルールを定めて別に行う
 (例:短い感覚でこまめに休憩を取る or 席を外す、サイクルを一旦止めて調査専用の時間を作る) 2. 〈全員〉 分からないこと・確認しておきたいことを残さない
 分からない事や不安・不明な点が出てくるのは当然であり、そのままにしておくことを恥じる
 どんな質問・確認であっても、容認し、受け止め、全員の不明点を解消する
 質問・確認を言い出しやすい雰囲気や工夫をする(心理的安全を作り出す) 3. 〈タイピスト〉 モブ全体の合意がない操作やコード化をしない
 特定の誰かの意見や指示だけに従ってPCの操作やコード化をしてはいけない
 モブ全体が合意していることだけに沿って、PCの操作やコード化をする(合意がとれているか確認する) モビングをうまく進めるためのすべからず6箇条(案) 8

Slide 9

Slide 9 text

例)実際に勉強会などで提示する内容 4. 〈タイピスト〉 自分の想像や知識だけでコードを書かない
 モブの指示を勝手に解釈し、自らの知識だけで操作やコードを書かない
 どのようなPCの操作やコードが必要か、モブにつぶさに確認をして、PC操作やコードに反映する
 指示に納得できない点がある場合は、タイピストを交代し、モブとして自分の考えを合意に反映する 5. 〈モブ〉 攻撃や差別、ハラスメントをしない
 いうまでもないことですが...どんな場合も相手を傾聴し、チームの力になることが大事
 意見の衝突や感情的になりそうな時は、誰かが休憩を促す 6. 〈全員〉 時間や順番を守らずに進めてはいけない
 役割の交代や全体の時間の厳守、やらなくてはいけない事柄を厳守する
 役割は操作の途中でも交代。全体の時間オーバーの場合は潔く中断し、「ふりかえり」を犠牲にせず行う モビングをうまく進めるためのすべからず6箇条(案) 9 べからず集は堅く見えますが、最初はしっかりと守り、アレンジをした方がモビングの効果が高まります

Slide 10

Slide 10 text

ハッシュタグ:#rakutensapporo モビングの効果をよりひきだせるようになってきた 10 • テクニックや知識の未定着の繰り返し
 ⇒ コード化や操作の前に、逐一確認
 ⇒ 当たり前になると、自然と質問がはじまる • エキスパートがいないとモブが進まない
  ⇒ 分かるところだけでも...と参加メンバーで
     進めるようになってきた(次第に範囲が増える)
  ⇒ 前半はメンバーだけで、
     後半はエキスパートを入れて(レビュー的に)
     とゴールを定めたモビングが進めやすくなる • メンバーがモブの時しか作業をしない
  ⇒ 時間を区切って、あるモビングで終わらなかった
     部分は次回のモビングまでの作業に
     (ふりかえり大事)
  ⇒ メンバーが「ここで困っているのでモビングしたい」
     と気軽に提案をするようになった

Slide 11

Slide 11 text

ハッシュタグ:#rakutensapporo 〈本題〉
 IT勉強会でもモビングは効果を発揮する のでは? 11

Slide 12

Slide 12 text

ハッシュタグ:#rakutensapporo IT勉強会にもどんどんモビングを取り入れてみる 12

Slide 13

Slide 13 text

ハッシュタグ:#rakutensapporo

Slide 14

Slide 14 text

ハッシュタグ:#rakutensapporo

Slide 15

Slide 15 text

ハッシュタグ:#rakutensapporo • テーマとなった技術を使って、経験者も初心者も同じ土俵で進める
 ⇒ 技術以外の部分での気づきや学習、得意分野の発揮
    モビングで陥りやすい問題点への解決手法の創出 • 参加者にとってリアルな課題設定や、プログラミングコンテストの課題でワイワイ進む
  ⇒ 日頃、なかなか言い出せなかった疑問や知識不足の解消、実践的な課題での練習
  ⇒ モブプログラミングから、自然とモブワークの体験へ • 新入社員の研修でやりたい! という感想が、中堅層からかなりある
 ⇒ モビングをやりたいと思ったときに、できるメンバーが沢山増えると素敵だと思います ハンズオンをやっていたときよりも好評(に感じてます) 15 IT勉強会での導入では、ルールよりも、環境の用意が大変 • 普通の会議室ではなかなかモビングはやりづらい
  ⇒ 複数の別系統プロジェクタ、ホワイトボード、動かしやすい椅子・机 • 参加者のPCに十分な環境が揃っている場合と、そうでない場合がある
  ⇒ タイピスト用PCをどうやって用意するか?(バージョンやライセンス等含む) 図引用: マーク・パール (著)、長尾高弘(訳)、 及部敬雄(解説):モブプログラミング・ベストプラクティス

Slide 16

Slide 16 text

ハッシュタグ:#rakutensapporo IT勉強会でモビングで学ぶ 現場で気軽にモビングを取り入れられる のサイクルが回るといいな 16