実践モブプログラミング/ mob programming practice

#JTF2020 #JTF2020A July Tect Festa 2020 A6 2020.07.25
実践モブプログラミング
@erukiti / 株式会社マツリカ佐々木俊介

View Slide

自己紹介

View Slide

@erukiti （えるきちです。Ｌチキではありません）

View Slide

QiitaやNoteなどでブログ書いています

View Slide

技術同人誌を書いてます

View Slide

技術書典9に向けて執筆開始
• Next.js
- React を楽に使う世界標準の薄型フレームワーク
• Hasura
- PostgreSQL とフルに連動して勝手に GraphQL スキーマを生成してく
れる凄く便利なフレームワーク。ただしまだマイナー
• 素早いプロトタイピングのコツ

View Slide

同人仲間とWebサービスをモブプロで開発中

View Slide

株式会社マツリカ

View Slide

Senses（センシーズ）

View Slide

僕とモブプログラミング
• モブプロという文化がなかった弊社に、モブプロの導入はできた
• とはいえ、全てをモブプロでとか、毎日モブプロとかってレベルまではいけて
ない
• カジュアルにモブで相談するか、モブプロでチケットやってみるか、くらいまで
は認識して貰えた
• 別件で、さっきも触れた同人仲間とのモブプロ

View Slide

セッション概要

View Slide

対象
チーム開発を改善したい人
• 開発者もそうでない人も！
• 属人性の高いコード・レガシーコードに苦しんでる人
• 個人vsタスクを、問題vsチームに変えたい人
• モブプロはプログラミング専用の考えではありません。モブワーキングという
もっと広いやり方があります
- そもそも始まりはモブトラブルシューティングだった

View Slide

リモートでモブプロをする
• このセッションはリモートでモブプロをすることが前提
• リモートでのノウハウ満載なため、オフラインでモブプロをする場合とは勝手が
違うかも
• 大半のノウハウはどちらにも共通します

View Slide

前半の概要
• モブプロとは何か
• 実際のモブプロのやり方
• モブプロの効能について

View Slide

後半の概要
• コツ
• 落とし穴の回避方法
• モブセッションが終わったあとにやるべきこと
• まとめ

View Slide


View Slide

なぜ開発をするのか？

View Slide


View Slide

問題を解決して会社の事業への貢献を最大化する
• 人件費という少なくない予算を投じて開発するからには、問題を解決して会社
の事業への貢献を最大化しなければいけない
• スーパースターのソロ開発で最大の貢献ができるならそれもありだけど、現実
問題としてそんなスーパースターはレアキャラだし、その人が辞めたら詰む
• そういう例外を除けば、チームの開発効率を最大化するしかない

View Slide

開発効率の話リソース効率 vs フロー効率
• 効率をどっちの視座で捉えるか？
• 個人の時間を軸に評価するリソース効率
• チーム全体の効率を評価するフロー効率
モブプロは後者！

View Slide

弊社の事例
• ほぼ同じような条件だったので比較可能なものがあった
• パターンA）ソロプロで、10日
• パターンB）モブプロで、合計9人日
• とくに、パターンBでは、品質、レビュー省力化、気持ちよさ、知見などプライス
レス！なものをいっぱい得ることができました

View Slide


View Slide

モブプログラミング
（モブプロ）

View Slide


View Slide

ソフトウェア開発は、コミュニケーションの塊

View Slide

ソースコード考古学はつらみとの戦い
開発の障害となるもの
• 複数人数が関わった古いコードのもつ一貫性のなさ
• 属人化してしまった知識を、ソースコードから追いかけるのは、エスパーやるの
と変わらない
• 開発効率を落とす最たる物でありつつも、色々な組織に根強く残されている
「動くからいいじゃん」

View Slide

#JTF2020 July Tect Festa 2020 A6 2020.07.25
断片でも知ってるひとや
知ってそうなひとに
聞けば手っ取り早いやん！

View Slide

知ってる人がないなら
「どう解釈し扱うべきか」を
相談して、後生に残すべき

View Slide

コミュニケーションで問題と戦おう
• チームメンバー集めて、要求・要件・仕様・設計・実装・レビューを一括でやるこ
とで、コミュニケーション効率を上げる
• ソースコード考古学のつらみを1人に押しつけない。暗黙知をそのままにしない
• あと、リモート時代だからこそ、みんな喋りたい欲求溜まってるでしょ？

View Slide

注意点
• モブプロに向いてない人、やりたくない人もいるので、押しつけは悪手
• コツコツ場を作り上げる、チーム戦にもっていく、根回しそういったものが重要
• 誰がやっても同じになる作業はモブプロには向いてない
• スーパースターの効率はまず出せない

View Slide

身も蓋もないこと言うと
コミュニケーションによる開発なので
メンバー次第

View Slide

応用: モブワーキング
• トラブルシューティング（そもそもモブの歴史は、これから始まった）
• デザイン
• チュートリアル
• カスタマーサポート
• インフラ構築・運用
• 営業ピアレビュー

View Slide


View Slide

実際のモブプロのやり方

View Slide

モブとタイピストパターン
• モブプロには幾つかのスタイルがあるが、ここでは1つのパターンを紹介する
• 時間ごとに持ち回りで交代するタイピストという役割と、それ以外の全員モブ
の役割に分かれる
• モブ全員で成果物を作るために必要な相談をして、具体的にタイピストに指示
を出して、一定時間で交代するだけ！

View Slide

• モブに、何を操作すればいいか？
を聞く
• モブを全面的に信頼して、モブが
決めて指示した内容をタイプする
• 指示が不明瞭なときは必ず質問
をする
タイピスト

View Slide

• 成果物を作り上げるために、紳士
的（淑女的）かつ積極的にコミュニ
ケーションをする
• タイピストに打ち込んでもらうコ
ードを相談して、具体的な指示を
出す
• みんなで全力で楽しむ！
モブ
※Wikipediaより引用

View Slide

タイピストはモブに
混ざっちゃいけないのか？

View Slide


View Slide

実際にやってみて分かること
• 慣れないうちは2時間くらいでも本気で疲れる
• ガチのプロダクションコードをモブプロで成果を上げることと、お試しでやるモ
ブプロは、体験として全く違う
• モブプロに懐疑的な人も、やってみると感想が変わることが多い

View Slide

うまくいったモブプロはめっちゃ楽しい
• 役割（フロントエンド、バックエンド、インフラなど）を超えて知見や達成感を得ら
れる。自分の知らないことでも達成感を得られる。
• 相互理解が深まる
• プロダクト考古学をあまり苦しまずに、少しでも究明できる
• 少しずつ確実な一歩を踏み込んで、プロジェクトが前進する快感
• 成長の喜び

View Slide

View Slide

コツ

View Slide

リモートでモブプロをする準備
• ZoomやSlack通話などを開いて、音声通話 + 画面共有をする
• VSCode の LiveShare で誰か1人のホスト環境を共有するとやりやすい
• 【参加者全員】がVSCode / LiveShare / 必要な拡張をインストールしてお
く
• ただし、LiveShare は罠と癖が多いので設定は苦戦する可能性もある
• LiveShareでモブプロを進めるための練習を済ませておく

View Slide

linter や formatter を導入しよう
• linter や formatter を活用する。インデントやコーディングルール議論、手
動でのフォーマットほど無意味な時間の浪費はない。リポジトリレベルで設定し
ておき、VSCode拡張もインストールしておきましょう。
• linter や formatter の設定は一般的なものを使う。細かい議論は自転車置
き場議論にしかならないので限りなく不毛

View Slide

タスク選定をする
初めてのモブ体験が楽しさになるか最悪になるかはこれ次第
• やろうとしている作業について、情報をチケットなりに記載しておく
• 初めてのモブをやるときは、ある程度道筋をつけて、接待プレイを心がける方
が良い
• 題材選びは重要。簡単すぎても、ハマりすぎてもだめ

View Slide

モブセッション開始時にすること
• モブ啓蒙や教育を目的とするか、効率を目的とするか？を決めておく。初回は
おそらく「実際の案件にモブプロが有効であることを確認してもらう」というこ
とになるはずで、前者ということになる
• モブプロのこと、モブとタイピストの役割について説明
• やってはいけないことの説明
• やるべきことの説明

View Slide

ファシリテーションが重要
• コミュニケーションの場を作り上げること。できれば協力者を確保して、場を作
る手助けをしてもらう
• 歩調を合わせることと、質問出来る空気を作ること、ハマり防止
• 議論が紛糾して空中戦にならないこと
• みんなが積極的に楽しく喋ること

View Slide

密なコミュニケーション
• コミュニケーションの空白をなく
す。独演会になったり、置いてけ
ぼりの人を作らない
• 少しでも何か出来たら、大げさな
くらい喜ぶ、拍手する、褒める
• お互いを尊重し合う。HRT重要。
絶対に言論封殺をしない
場を作る

View Slide

伝える努力、傾聴力
どちらも必須

View Slide

伝えるときに工夫すること
モブプロ体験を大きく左右する
• 具体的な指示であればあるほどスムーズになる
• ファイル名や行番号を常に口に出すことで、今どこを見ているのか、どこに対して言
ってるのかを全員が気にかける
• 「スペース」なんかも口に読み上げる方がいい。
• 変数名・関数名は特殊な場合「キャメルケースで」「先頭大文字で」とかを明示する
• 慣れてくれば、コミュニケーションを少しずつショートカットできるようになってくる
ので、根気強く、分かりやすい指示を心がけましょう

View Slide

議論をする
• 議論が起こることは喜ばしい。それは心理的安全性を満たせている証明
• 絶対に議論封殺をしない。「それはさっき検討したから」で終わらせると心理的
安全性は無くなっていく。「どこが気になりますか？」「それを後回しにできない
理由はどういうところですか？」傾聴力がとても大切
• でも議論ばかりでも先には進まないので、場合によっては議論に5分や10分く
らいの時間制限を設けよう
• 後ほど説明する空中戦は議論に見せかけた時間の浪費なので注意

View Slide

歩調を合わせる
• できる限り、一番遅い人、理解度が低い人に合わせる
• 繰り返しになるけど、ファイル名や行番号を読み上げるのは効果的。遅い人は
「今どこを見ているか分かってない」ことが多い
• 定期的に問いかける、気にかける、喋ってないひとを慮る

View Slide

モブプロでは「流れを止めてしまうと悪い
気がして質問できなかった」が発生しやすい

View Slide

「ちょっと駆け足だったかも知れません。
ここで、他の皆さんに共有してあげたい
疑問はありませんか？」

View Slide

改善していく
ボーイスカウトルールなど、一歩ずつ前進できるマインドセット
• JSDoc/JavaDoc/YARDなどのコードドキュメントを追加
• 不完全な型定義を改善
• 足りないユニットテストの追加
• 暗黙知をドキュメント化

View Slide


View Slide

落とし穴を回避しよう

View Slide

アンチパターンは全員に苦い記憶を残してしまう
• 世の中のモブプロ関連の情報を見たとき高頻出
• モブプロのコンセプト崩壊
• モブプロ体験を著しく落とす
• その結果、モブプロ懐疑派や反対派が誕生してしまう

View Slide

「ペアプロの延長線」
「タイピストが暴走」
「誰かが勝手に書き換える」

View Slide

モブプロのコンセプト崩壊を防ぐ
• ペアプロとモブプロは全く違うことを説明しておく
• モブとタイピストの役割を説明しておく
• 口で説明するのが苦手な人には、なんとか頑張ってもらう。手伝う。傾聴力を
最大限駆使して、暴走を防ぐ
• とにかくファシリテーションが命
• 協力者を少しずつ増やしていく

View Slide

「空中戦」

View Slide

空中戦を防ぐ
必ず可視化しよう
• ソースコードなら、でたらめに思えるものでも、必ず入力してから議論をする
• ソース以外のものなら、テキストに書き出すか、長引くならプログラミングから
いったん離れて、MURALのような専用のツールを使って、整理すること
• ファシリテーターは常に空中戦にならないことを意識する

View Slide

ハマり防止
• ハマりの気配を感じたら「いったんこれは置いておいて、先にこちらをやってみ
ませんか？もちろん後でちゃんとやるようにメモしておくので」
• 識者を呼べるなら呼んでしまう「CTO教えて！！」
• 何かどうしても調査が必要なら、必ずタイムボックスを設定する。10分くらい

View Slide


View Slide

モブプロが終わったら

View Slide

ふりかえり
• 参加者のモブプロに対する感触を掴んでおく
• 強制することなく気持ちを引き出す
• 楽しさを可視化することで、楽しさを演出
• MURALを使いましょう。もちろん類似の別のサービスでも構いません。とりあ
えずMURALと同程度の機能性・操作性を持つサービスは絶対に必須です

View Slide

学習効果
• もし可能なら、業務時間、特にモブプロ終了後に、学習時間制度を設けるべき
• モブプロをすると、業務知識、暗黙知、技術的知見など、得られるものがとても
多いのだけど、それらは時間が経てば経つほど揮発する
• ブログを書く、資料を残す、公式サイトを読みに行く、実験コードを書く、Slack
で発言する、過程を残すなど
• 詳細のレポートを残すべきかは、コストがかかりすぎるため意見が分かれると
ころ。音声通話の文字起こしが低コスト・高精度で可能ならやってもいいかも

View Slide


View Slide

まとめ

View Slide

まとめ
• モブプロは、コミュニケーションによる開発手法
• 実際の体験に勝るものは存在しえない
• 良いモブプロ体験は、ファシリテーションが重要な鍵
• 傾聴力を駆使しよう
• 可視化必須、MURALか類似サービスを試してみてください
• 協力者を得よう。増やしていこう

View Slide

参考資料
• 成功する実践的モブプログラミング - Qiita
• モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary
• モブプロの聖地 Hunter Industriees で学んだこと〜複数モブ編 - kawaguti’s diary
• モブプロにやりづらさを感じて改善した話 - Sansan Builders Box
• 「モブプログラミング・ベストプラクティス」読んだのでモブプロの魅力と始め方をまとめる
• Hunter Industriesの方のモブプロ体験会で教わった、本場のモブプロプラクティス - little hands' lab
• Mob Programming Startup Manual #MobProgramming #モブプロ
• モブプログラミング・ベストプラクティスソフトウェアの品質と生産性をチームで高める | マーク・パール, 長尾高弘,
及部敬雄 | 工学 | Kindleストア | Amazon

View Slide

モブプロは楽しいので
是非とも体験してみてください

View Slide

実践モブプログラミング/ mob programming practice

実践モブプログラミング/ mob programming practice

erukiti

More Decks by erukiti

Other Decks in Programming

Featured

Transcript