モブプロMeetupLT 僕らのモブプロ<br>仮説検証記録 === --- ### 自己紹介 * 松岡 幸一郎(@little_hand_s) * サーバーサイドエンジニア * 普段はDDDのこと発信してます --- ### 経緯 * 2018年8月 スクラム導入と同時にモブプロ開始 * 「モブ(ペア)プロのメリット」を調査 * 半年やってみた * 途中で[ブログ](https://tech.bizreach.co.jp/posts/312/pair-programming-benefit/)も書いた --- ### モブプロの狙いを言語化 * 英語の記事を調査 * 日本語より情報が豊富 * 「期待できそうなこと」を事前に言語化 --- ### 狙っていたこと 1. 効率化 2. 品質向上 3. チームコミュニケーション 4. 属人化排除 --- ### 狙っていたこと - 1.効率化 * レビュー＆指摘工数の削減 * 分業設計＆同期コストの削減 * フロー状態の時間増加 ---  --- ### 狙っていたこと - 2.品質向上 * 品質向上 * 複数人の知見反映 * バグ削減 * 設計品質向上 --- ### 狙っていたこと - 3.チームコミュニケーション * 議論する文化作り * 個人間の知見シェア * クロスファンクショナルトレーニング * 新人教育 * メンバーのリレーション構築 * 難しい問題に取り組みやすくなる --- ### 狙っていたこと - 4.属人化排除 * 短期：休暇を取りやすい * 長期：離任してもプロジェクトから知識がなくならない --- ### 進め方と経緯 * 基本ペアである、というWAで進めた * フラストレーションが溜まる * 作業を柔軟に * 結果、SPが倍増 * さらに、個人タスク＆レビュー体制に戻して見た * 新しい技術の腹落ち感がました * 結構手戻りが増えて、プランニング時の設計必要性を見直して揺り戻した --- ## 検証結果 --- ### 狙っていたこと - 1.効率化 * レビュー＆指摘工数の削減 * 分業設計＆同期コストの削減 → ◎複雑な開発ほど効果あり。ただし代替案あり * フロー状態の時間増加 → △傾向としてはあるが、進め方や好みによりそう。 --- #### 効率化の代替案 * スプリントプランニングにおける設計 * こまめに相談する * 設計上の大きな手戻りをなくすにはこれでも良さそう --- ### 狙っていたこと - 2.品質向上 * 品質向上 * 複数人の知見反映 * バグ削減 * 設計品質向上 * → ◎先輩後輩という立場ではなくても、同レベルの人が複数いるだけで単純にミスを見つけられる確率が上がる * ×議論は増えるので単体でみたときの時間はかかる、精神的疲労感も上がる --- ### 狙っていたこと - 3.チームコミュニケーション (1/3) * 議論する文化作り → ◎効果大。最後までやってPR、という形式に比べて圧倒的に会話しやすくなる * 個人間の知見シェア * クロスファンクショナルトレーニング → ◎詳しくない人に作業しながら伝達には良い。ただし個人で手に馴染ませる時間は必要だと痛感 --- ### 狙っていたこと - 3.チームコミュニケーション (2/3) * 個人間の知見シェア * 新人教育 → △バランス必要で、納得いくまで自分で仕上げてレビューしてもらった方が学びが深いように思う。 ただし、ログの追い方やIDEの操作などPRレビューではできない学びあり --- ### 狙っていたこと - 3.チームコミュニケーション (3/3) * メンバーのリレーション構築 → △設計や進め方の好みは把握しやすくなるが、他の要素も大きいのでなんとも言えない * 難しい問題に取り組みやすくなる → ◎難しいことに取り組む精神的負荷はすごく下がる --- ### 狙っていたこと - 4.属人化排除 * 短期：休暇を取りやすい * 長期：離任してもプロジェクトから知識がなくならない → ◎両方とも、間違いない 「自分が抜けたら止まる・・」とならないのは安心感大きい。」 --- ### ペア/モブプロが向いてるケース * 難易度が高い、不確実性が高いもの * 初期に設計し切るのが難しい * 個人に任せ切った時の手戻りリスクが高い * メンバー間のスキル交換を促進したいとき * 特定の技術 * 一般的な効率化のための知見 * TDD、IDEの効率的なショートカットなど * チーム立ち上げ初期 * 一緒に議論して進めるクセ付け --- ### ペア/モブプロが向いていないケース * 個人ワークや分業が向いているもの * 手を動かす学習が必要なもの(特に学習初期) * 複雑度が低い作業 * 分業した方が期日達成確率が上がるとき --- ### まとめ * 課題ドリブンが重要 * メリデメのトレードオフが大きい * 具体的な課題感を元に始めないと、目的を見失う * 課題に刺されば、効果は大きい * 再掲： 目的の分類 1. 効率化 2. 品質向上 3. チームコミュニケーション 4. 属人化排除 --- ### まとめ * 継続的な改善が必要 * 開発作業のチームワーク色が高まる * 「思っていても言いにくい」「やり始めたらやめにくい」が出る * 継続的に課題感を吸い上げて改善しないとストレスたまりがち --- Thank you for listening! --- ###### tags: `LT`