スキル差があるペア_モブプロで効果的な_ドライバーナビゲータ以外のロールの分け方.pdf

by Yatakeke

Slide 1

Slide 1 text

スキル差があるペア・モブプロで効果的な、ドライバーナビゲーター以外のロールの分け方クリエーションライン　矢田進之介 1

Slide 2

Slide 2 text

このセッションのゴール ● プレゼンのターゲット ○ ペアプロやモブプロをやったことがある人 ○ スキル差があるなかでのペアプロやモブプロの進め方に悩んでいる人 ● アウトカム ○ チームやプロダクトの状況に合わせて、ペアプロやモブプロでの進め方を柔軟に扱える、もしくはそのきっかけがもらえる ○ 教育と開発スピードのバランスがうまく取りながら進められるようになることでメンバー間のスキル差が緩和されていく 2

Slide 3

Slide 3 text

今日話すこと ● 自己紹介と自分自身のモットー ● ペア・モブプロがスキル差で辛くなる時もある ● スキル差があるペアモブのなかで起こった過去の自分の失敗談 ● そこから気づいたペア・モブプロの難しさとそれを改善する仮説 ● 先人たちの知恵から推測できる成し遂げたかった意図とは？ ● 実践の中で見つけた役割の分け方に関する新しいパターンの紹介 ● さいごに 3

Slide 4

Slide 4 text

自己紹介 ● クリエーションライン株式会社 ● アプリケーションエンジニア ● 劇団CL団長 ● 矢田進之介（やたしんのすけ） ● 愛知県安城市出身 ● ソロでの登壇は初めて ● 人生初登壇もスクフェス三河 4 

Slide 5

Slide 5 text

自分がこれまでやってきたこと ● 社内の開発者へのユニットテストの導入支援 ● 新卒PBLのメンター役 ● 社外の開発者へのリスキリング支援など 5

Slide 6

Slide 6 text

モットーは目の前の１人を変化に巻き込むこと ● 不特定多数の人にメッセージを発信したり、マネジメント側に回って変化を起こしていくのは自分にはまだ難しい ● 現場で背中を見せたり、一緒に試行錯誤しながら目の前で一緒に仕事をしている１人から変えていきたい ● そのための変化の創発の場として、ペアプロ・モブプロがあると思っている 6

Slide 7

Slide 7 text

ペアプロ・モブプロとは ● ソフトウェア開発の手法の一つで、2人以上のプログラマーが１台のマシンを操作してプログラミングを行う手法のことを言う ● ドライバー・ナビゲーター（モブプロの場合はモブ）に別れる。10-15分程度で役割を交代しながら進める ● コーディング速度が15%低下するが、バグの数も15%少なくなると言われている（フロー効率がよくなる）ペアプロを知らない人用に 7

Slide 8

Slide 8 text

ここでペアプロを知っているみなさんに質問 8

Slide 9

Slide 9 text

あなたの周りにはペアプロ・モブプロに嫌悪感を感じる開発者はいませんか？ 9

Slide 10

Slide 10 text

ペアプログラミングは、誰もが気に入る方法ではない 10 『モブプログラミング・ベストプラクティス』マーク・パール, pp. 24 1.2.3章

Slide 11

Slide 11 text

その開発者はスキル差があるなかで教育とスピードのバランスを考えながらモブするのに悩んでいるかもしれません 11 ただ、場合によっては

Slide 12

Slide 12 text

ペアプロを効率的にするための注意事項=スキルの不均衡スキルの不均衡には、胃が痛くなります。チームメンバーが未熟なメンバーのスキルを向上させることが、チーム全体のメリットとなると認識することが理想です。しかし、全ての人がこのように忍耐強く、人に愛される性格ではありません。 12  『ペアプログラミングエンジニアとしての指南書』ローリーウィリアムズロバートケスラー, pp. 68 ※ 太字は発表者独自の視点

Slide 13

Slide 13 text

これは僕自身のお話 13

Slide 14

Slide 14 text

2年くらい前の当時のチームの状況メンバー間でスキル差が生じているチームメンバーで教育が課題だった良いコードに関する基準がバラバラ、ユニットテストもあまり書いていない 14 え、まだユニットテストをできてない現場があるんですか？, pp. 10-11

Slide 15

Slide 15 text

そのときのペア・モブプロの進め方 ● 新卒の子１人 + ジュニアレベル１人 + 自分のペアプロ・モブプロ ● ドライバー ○ キーボードを持ってコードを書いていく人、自分だけの考えで実装を進めない ● ナビゲーター・モブ ○ ドライバーが書いたコードをレビューしながらドライバーに対して適切な指示をする人 ○ 自ずと自分がなることが多かった ● １セッションが25分タイマーで交代する 15

Slide 16

Slide 16 text

なんとなくこのやり方に落ち着いてしまった 16

Slide 17

Slide 17 text

前述の進め方がうまくいく必要条件 ● リファクタリングやオブジェクト指向、ユニットテストなどの基本的な素養や論理的思考力がチーム全体に担保されている ● コードを実装するうえでそのときに自分が考えていることの思考プロセスがある程度言語化できるや相手の意図を察する能力が高い ● それぞれがお互いの知識の共有についてモチベーションが高い 17 当時のチームでは上２つは確実に満たしていない

Slide 18

Slide 18 text

そのとき起こった失敗談①：教育のつもりが迷惑 ● ジュニアレベルの人にドライバーをやってもらった時のこと ● 自分として属人化はなくしたいし、チームとして強くなりたいという思いがあった ● 壁打ちとしていろいろ問いを投げかけてみよう ○ できたコードに対して、実はこれが間違っています！どこでしょう？ ○ 発生したエラーに対してこれはなぜ起こっているのでしょう？ ● ドライバー側に問いを投げかけすぎてキレられる ○ 「お前のチームの一員なんだから実装とかわかってるんだったら言えよ！」 18

Slide 19

Slide 19 text

そのとき起こった失敗談②：スピード優先の伝言ゲーム ● 新卒1年目の子にドライバーをやってもらった時のこと ○ 実装を論理的に考えて構文まで落とし込むのに少し苦労する人 ● 曖昧な指示を出すと、構文を調べたりするのに時間がかかってしまう ● 開発が遅れすぎるのもよくないし、できるだけ具体的な指示をしよう！ ● whyをいいながら進めようと試行錯誤をしながら結局whatを指示する日々 ● 結果として、あまり考えることなく言われたことをただコードにうつすドライバーになる ○ 知識差が緩和されることもなく、ただただナビゲータの自分が疲れてしまう 19

Slide 20

Slide 20 text

ソフトウェア開発においてスピードは教育とのトレードオフ 20 知っている人が多いとは思いますが質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き, pp.68

Slide 21

Slide 21 text

開発者が開発者を教育するのが難しい 21 相手のキャリアプランそもそも自分だって知らないことが多い相手との関係性構築変化の早い技術スタックマインドセット教えるのむずい他人に教えることのモチベ作り結局最後は自分の問題わかりやすい説明むずかしい

Slide 22

Slide 22 text

コラボレーションは習得に時間と忍耐が必要なスキルである 22 『クリーンクラフトマンシップ』 Robert C. Martin, pp. 225 (第７章協力的プログラミング)

Slide 23

Slide 23 text

チームとしての教育とスピードだけでも難しいのに 23 教育とスピードのバランス

Slide 24

Slide 24 text

スキル差が大きくあると教育自体の難易度も増す 24 教育自体の難しさ教育とスピードのバランス

Slide 25

Slide 25 text

人との協働作業をし始めると 25 教育自体の難しさ教育とスピードのバランスコラボレーションの難しさ

Slide 26

Slide 26 text

スキル差のあるペアプロ・モブプロはかなり難しい 26 教育自体の難しさ教育とスピードのバランスコラボレーションの難しさ

Slide 27

Slide 27 text

それでも向き合っていく 27

Slide 28

Slide 28 text

大きく3つの問題があった気がする ● 自分の問題 ○ 自分の説明スキルは高い方ではない ● チームの問題 ○ 教育とスピードのバランスについて合意が取れていなかった ○ 実装スキルに差がありすぎて、コードに対する意識があっていなかった ● プロセスの問題 ○ ドライバー・ナビゲーターがあっていない ○ 25分交代が逆にリズムを作れなかった 28 失敗した状況を振り返ってみると・・・

Slide 29

Slide 29 text

自分や人を変えるのは大変なのでプロセスを変える 29 人を変えられない認識はズレやすいプロセスは変えられる ● 自分の問題 ○ 自分の説明スキルは高い方ではない ● チームの問題 ○ 教育とスピードのバランスについて合意が取れていなかった ○ 実装スキルに差がありすぎて、コードに対する意識があっていなかった ● プロセスの問題 ○ ドライバー・ナビゲーターがあっていない ○ 25分交代が逆にリズムを作れなかった

Slide 30

Slide 30 text

もっとうまい進め方はないか？ 30

Slide 31

Slide 31 text

ペア・モブプロのプロセスをカイゼンするためのヒント① cybozu社でのいいモブチームの動き方をモデル化したものチームにあった独自の役割が根付いているシン・モブプログラミング第三形態 by 永田敦, pp. 33, pp. 38 31

Slide 32

Slide 32 text

ペア・モブプロのプロセスをカイゼンするためのヒント② ● 指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの実施のコツを解説した記事 ● 理想のペアプロ形態の１つは、ダブルリードでペアのどちらもがリード役でサポート役です。 32 知識差-スキル差を埋めるためのペアプロ＋αのコツ(1) Eiji Ienaga ※ 太字は発表者独自の視点

Slide 33

Slide 33 text

それらから生まれた自分の中での仮説 ● 良いチームはドライバー・ナビゲーターに拘っているわけではなく、自分たちにあったやり方を見つけていそう ● ドライバー・ナビゲーターの１つの型（カタ）であり、メンバーそれぞれの特性やチームの状況にあったよりよい分け方がありそう 33

Slide 34

Slide 34 text

今こそ「離」の瞬間 34

Slide 35

Slide 35 text

守破離 from レガシーコードからの脱却 ● アジャイルを、やって良いこと、やって悪いことのルールとして学ぶ人は多い。（中略）ルールを学ぶのは学習の最初のステージにすぎない ● ソフトウェア開発のような複雑な活動はルールだけで捉えることは難しい。 ~（中略）~ ある状況では最良のアプローチが別の状況では最悪のアプローチになることもある ● 守から始める理由は、プラクティスの背後にある理論が簡単には理解しにくいからだ。~（中略）~ 成功するには、プラクティスを上手に使いこなせるように、プラクティスの背後にある原則を学ばなければならない。 35 『レガシーコードからの脱却』 David Scott Bernstein, pp. 50 (4.2 守破離)

Slide 36

Slide 36 text

今こそ「離」の瞬間自分の中で実践知は溜まっているはずなので先人たちの書物の助けを借りながら言語化する 36

Slide 37

Slide 37 text

書籍でペア・モブプロの意図を探す 37 自分が持っている5冊くらいの記述を紹介します

Slide 38

Slide 38 text

XP白本の記述 ● ペアプログラミングとは、2人でプログラミング（および、分析・設計・テスト）とプログラムの改良を同時に行うやりとりのこと ● 以下のようなことをする ○ お互いにタスクに集中する ○ システムの改良について意見を出し合う ○ アイデアを明確にする ○ パートナーがはまったら主導権をにぎり、相手の失望感を軽減させる ○ お互いにチームのプラクティスの説明責任をはたせるようにする 38 ※ 太字は発表者独自の視点『エクストリームプログラミング』Kent Beck, Cynthia Andres, pp. 40 (主要プラクティス)

Slide 39

Slide 39 text

ソフトウェアクラフトマンシップにおける記述 ● 協力的プログラミングとは、2人以上の人が、同じコードで、一緒に作業をする規律である。 ● コラボレーションのセッションの時間は10分程度の短い時もあれば、1-2時間の長い時もある。 ● キーボードを触っているのは1-2人かもしれないが、その席はセッション中に何度も入れ替わる。 39 『クリーンクラフトマンシップ』 Robert C. Martin, pp. 224 (第７章協力的プログラミング) ※ 太字発表者独自の視点

Slide 40

Slide 40 text

クリーンアジャイルにおける記述 ● 二人が一緒に同じプログラミング課題に取り組む ● ペアになるプログラマーは異なる役割を担当する。一人がドライバーで、もうひとりがナビゲーターだ。（中略）ひとりがテストを書き、もうひとりがそのテストをパスさせ、それを交互に行うという役割分担もある。ほとんどの場合、明確な役割分担はない。 40 『クリーンアジャイル』 Robert C. Martin, pp. 124 (5章テクニカルプラクティス) ※ 太字発表者独自の視点

Slide 41

Slide 41 text

モブプロベストプラクティスにおける記述 ● 3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくことだ。分散知識の考え方をプログラミングに活かしたものである ● キーボードの前に座っている人をタイピスト、それ以外をその他のモブとしている 41 『モブプログラミング・ベストプラクティス』マーク・パール, pp. 24 1.2.3章

Slide 42

Slide 42 text

ペア・プログラミングの記述 ● 表面的にはペアプログラミングはシンプルな概念です。 ● 二人のプログラマーが同じタスクに対して1台のコンピューターで一緒に作業する ● 目的に合わせたさまざまな種類のペアが存在する ○ 専門家-専門家 ○ 内向型-外向型 ○ など 42 『ペアプログラミングエンジニアとしての指南書』ローリーウィリアムズロバートケスラー, pp. 68

Slide 43

Slide 43 text

まとめ意図交流の仕方 XP白本 2人でプログラミングとプログラムの改良を同時に行うやりとりのこと改良のアイデアを出し合って、パートナーがはまったら主導権を握るクラフトマンシップ 2人以上の人が、同じコードで、一緒に作業をする規律キーボードを触っているのは 1-2人クリーンアジャイル二人が一緒に同じプログラミング課題に取り組む明確な役割分担はないモブプロ１台のコンピューターの前に座って協力しながら問題を解決していくキーボードの前に座っているタイピスト、それ以外ペア・プログラミング同じタスクに対して1台のコンピューターで一緒に作業する目的に合わせたさまざまな種類のペアが存在する 43

Slide 44

Slide 44 text

意図は交流から生まれる相互作用にある意図交流の仕方 XP白本 2人でプログラミングとプログラムの改良を同時に行うやりとりのこと改良のアイデアを出し合って、パートナーがはまったら主導権を握るクラフトマンシップ 2人以上の人が、同じコードで、一緒に作業をする規律キーボードを触っているのは 1-2人クリーンアジャイル二人が一緒に同じプログラミング課題に取り組む明確な役割分担はないモブプロ１台のコンピューターの前に座って協力しながら問題を解決していくキーボードの前に座っているタイピスト、それ以外ペア・プログラミング同じタスクに対して1台のコンピューターで一緒に作業する目的に合わせたさまざまな種類のペアが存在する 44

Slide 45

Slide 45 text

交流のやりかたについては原則はない意図交流の仕方 XP白本 2人でプログラミングとプログラムの改良を同時に行うやりとりのこと改良のアイデアを出し合って、パートナーがはまったら主導権を握るクラフトマンシップ 2人以上の人が、同じコードで、一緒に作業をする規律キーボードを触っているのは 1-2人クリーンアジャイル二人が一緒に同じプログラミング課題に取り組む明確な役割分担はないモブプロ１台のコンピューターの前に座って協力しながら問題を解決していくキーボードの前に座っているタイピスト、それ以外ペア・プログラミング同じタスクに対して1台のコンピューターで一緒に作業する目的に合わせたさまざまな種類のペアが存在する 45

Slide 46

Slide 46 text

それらを踏まえて自分の認識共通している意図 ● 全員で同じコードをみながら交流することによって相互作用を生むこと状況に合わせて自由にできること ● 役割の分け方と交流の仕方（指示する人と書く人だけではない） ● 役割交代のタイミングここで言う、状況を決める変数 ● それぞれの実装スキル ● 実装の難易度 ● 考えていることの言語化能力 ● 個々人の性格（外向的か内向的） 46

Slide 47

Slide 47 text

Slide 48

Slide 48 text

自分の特性と意図を踏まえてやり方を変えてみた ● 8月-12月のなかで新しいチームにジョインした時の話 ○ 10月-12月の間にペアプロをやるようになった ● 一緒にやっていた相手 ○ いわゆるジュニアレベルのエンジニア ○ ユニットテストを書いたことがない ○ クラス設計は肥大化しがち ● ドライバー・ナビゲーターは意識せずに自分にあう方法を試す 48

Slide 49

Slide 49 text

そのチームのBefore PoCをやっていたとはありつつもリポジトリにはたった1件しかなかったテスト 49

Slide 50

Slide 50 text

そのチームのAfter ● そのリポジトリは100件のテストケースが生まれた ● GoFのデザインパターンのいくつかやデータオブジェクトを書くのが当たり前になった ● 自分が抜けた後も品質改善が続いていった ○ 自分が触っていなかったリポジトリに追加要望が入った時の話 ○ お客さん向けに品質改善の交渉を申し出る ○ 既存のリポジトリを書き直すと1ヶ月かかるけど新しく書き直せば2,3週間で保守性が高いものができます 50

Slide 51

Slide 51 text

ふりかえってみると、どう役割を分けていたか？ ● 3つの役割のパターン ● コンポーネント単位、もしくはつまったタイミングでパターンを変える ● それぞれのパターンで動く前に合意をとる 51

Slide 52

Slide 52 text

実践の中で見つけた、役割の分け方に関する新しいパターンの紹介 52

Slide 53

Slide 53 text

パターンの書き方（Alexander + fearless change + α） ● パターン名 ● このパターンが使える状況：問題が発生する状況の定義 ● このパターンが解決できる問題 ● 役割の分け方：解決策としてのそれぞれの役割での動き方や関わり方 ● 実施方法：解決策としての役割の分け方を踏まえた実施方法 ● 例：自分が実際にこのパターンを見出した場合の例 ● 気をつけることや注意すること 53 初めてパターンを言語化してみたので優しく見守ってください

Slide 54

Slide 54 text

パターン：五十六先生 54

Slide 55

Slide 55 text

パターン：五十六先生 ● このパターンの要約 ○ 自分の実装風景を相手に観察してもらうことでその実装概念に対しての価値を実業務を通して実感してもらい、イメージをつける。 ● このパターンが使える状況 ○ あなた自身は暗黙的に使いこなしている実装技術ではあるが、相手にとっては新しい概念となるものがたくさんある ● このパターンが解決できる問題 ○ 初学者に対して教育の時間が充分に取れないなかで実際の開発タスクが山積みである ○ 初学者にとっては、さまざまな実装技術のアイデアを活性化してくれる存在が必要である 55

Slide 56

Slide 56 text

● 役割の分け方 ○ 師匠（主体的に実装）= インストラクター ■ 通常通りに実装を行い、言語化できる部分は説明をする ○ 弟子 = オブザーバー ■ 「師匠」を観察しながら暗黙的に概念を記憶する ● 実施方法 ○ 「師匠」は言葉のみの説明に注力せずに背中を見せながら実装を進めていく ○ 「弟子」は「師匠」の実装を共体験することで、暗黙知を獲得するパターン：五十六先生 56

Slide 57

Slide 57 text

例：新人にテストファーストな実装を教える ● テストとは？の説明はせずに実装から見せるところから始める ○ こういう感じでテストってのを書いていくんだよ ● テストメソッドで日本語で入力と出力を書いてみせる ○ 書いた後に以下のメリットだけ伝える ■ 日本語で書くとコードが読めない人でもわかる ■ 具体的に書いて、グルーピングすると仕様の理解が深まる ● テストコードが失敗するところを見せる ● テストがパスするように変更する ● リファクタリングする ● 最後に追加で説明する ○ テストの実行は何回でもしていい ○ テストを通したまま変更すればよりよいコードになる 57 TDDとまでは言わないが

Slide 58

Slide 58 text

Slide 59

Slide 59 text

師匠側が気をつけていることや注意していること ● 説明に躓きそうだと思ったら、一連の処理まで実装し終わった後に書き終わったコードベースで説明すること ○ 説明しながら実装を意識しすぎると脳内メモリを使いすぎるので疲れる ● 相手にわかってもらうことを意識しないこと ○ 完全に理解させようとするよりも、まずは見てもらうことを目的とする ○ 聞いてわかったことはすぐ忘れる ○ その後に自分で書いてみるフェーズで腑に落ちるときもある ● わからなくても写経させるくらいなら観察させる ● 説明できないのは、言語化できないだけなのでやって見せる 59

Slide 60

Slide 60 text

パターン：赤ペン先生 60

Slide 61

Slide 61 text

パターン：赤ペン先生 ● このパターンの要約 ○ 経験値の浅い開発者は自分のコードを修正してもらうことでよりよいコードへの差分を理解する ● このパターンが使える状況 ○ 経験値の浅い開発者は、あなたの持ち合わせている実装概念について浅い理解はしているのでその知識を定着させたい ● このパターンが解決する課題 ○ 経験値の浅い開発者は実装概念についての知識を十分に理解するための練習時間が取れない 61

Slide 62

Slide 62 text

パターン：赤ペン先生 ● 役割 ○ 弟子（主体的に実装） ■ 実験に近い形で実装をする ○ 師匠 ■ 実装されたものに対してブラッシュアップ（orリファクタリング）する ● 実施方法 ○ 「弟子」は「師匠」からリアルタイムでレビューを受けながら実装を行うことでよりよいコードへの差分や勘所を頻繁に知ることができる ○ 「師匠」は「弟子」の書いたコードをもとに直接書き直すことで新しい概念を伝える 62

Slide 63

Slide 63 text

例：可読性の高い実装 by モブプロ（新卒+2年目+自分） ● とあるコンポーネントに関して新卒が書いてみる ○ 新卒の子はとりあえずできるところまでをやってみる ○ 実装ができたらそれでよし ○ 詰まるなら２年目に渡す ● 2年目が実装/リファクタリングしてそのコードをよりよくしていく ○ ２年目は新卒の子が書いたコードをその場で引き継いでよりよいコードを実装していく ○ 新卒の子は自分のコードが変更されていく様を見ることで実装パターンのイメージが活性化されていく ● 自分が最後にリファクタリングをしてよりよい実装を作る ○ ふたりとも実装がほとんど終わらなかった場合は五十六先生パターンになる 63

Slide 64

Slide 64 text

師匠側が気をつけていることや注意していること ● 師匠側はより良い実装への修正と不要な実装の削除を主な作業とする ● 弟子側がつまづいた時点で、師匠が手を動かすようにスイッチをする ○ コードを引き継いで自分であればこう書く！という議論につなげながら理解を深めさせる ● 直すことで理解を促し、直す観点から新しい概念を教えていくこと 64

Slide 65

Slide 65 text

パターン：ライオン先生 65

Slide 66

Slide 66 text

パターン：ライオン先生 ● このパターンの要約 ○ 単独練習を通して、それぞれの実装概念の背後にある原則を深く理解する ○ ライオンが谷底に落として育てるようなイメージ ● このパターンが使える状況 ○ 経験の浅い開発者は熟練者とのペア・モブプロであれば実装ができるとき ● このパターンが解決できる問題 ○ 開発者がペア・モブプロのフィードバックループに過剰最適されている ○ 開発者はペア・モブプロでないときに実装への自信がなくなる 66

Slide 67

Slide 67 text

パターン：ライオン先生 ● 役割 ○ 弟子（主体的に実装）= ソロプログラマー ■ 覚えたことや実践してみることで実践知を増やし、自分の中で知識を昇華させていく ○ 師匠 = レビュワー ■ タイポなどの明らかに間違っているところだけ指摘する（エディターの機能に近い） ● 実施方法 ○ 画面は一緒に見ているがプログラマーができるだけ単独で実装を行う ○ ただし、バグは防ぎたいので、レビュワーは監視をしながらバグを発見したら報告する 67

Slide 68

Slide 68 text

例：通常の実装でより強くなる ● ２人で同じ画面を見ているが、相手は一人で実装を行う ● 自分はタイポのみ指摘する ● 自分は、手が止まったタイミングで考えの言語化だけ質問する ● 実装が終わった後に感想戦を行う ● できるだけ相手の実装した状態を残し、相手だけで実装した風味を残す 68

Slide 69

Slide 69 text

３つのパターンの共通点 ● 作業はわけずに交流の仕方を決める役割であること ○ 書く人（ドライバー）・指示する人（ナビゲーター）のような作業ごとの分け方をしない ● つまずきを減らすことにフォーカスすること ○ 五十六先生は、交流によって生まれるつまづきを減らすためのもの ○ 赤ペン先生とライオン先生はつまづいたらコードを書く人が変わる ● 書いていないものでの会話を減らすこと ○ whyの言語化が苦手な人でもコードベースで話がしやすい 69

Slide 70

Slide 70 text

３つのパターンの差分は相手の習熟度五十六先生から始まって、赤ペン先生で理解を深めてライオン先生で個人の技術を高めるのが必勝パターン 70 まだ早かったまだ早かったやってみようかな？やってみようかな？

Slide 71

Slide 71 text

推しパターンは赤ペン先生 71

Slide 72

Slide 72 text

パターン：赤ペン先生のいいところ ● 師匠側はリファクタリングなので楽しい ● コードが書かれていく様子を見ているのでハイコンテキストな状態で他人のコードをリファクタリングできる ● よいリファクタリングをしたときに、へええって言われるのが嬉しい ● 初学者にとっては、どこが変えるべきなのか見当がつかないので学びがある ● 初学者にとっては、自分のコードだから実感が湧く ● いろいろ試行錯誤の議論ができて楽しい 72

Slide 73

Slide 73 text

意外と重要なのはライオン先生 73

Slide 74

Slide 74 text

ライオン先生がなぜ重要なのか？システムを設計するための判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすること 74 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き, pp.94

Slide 75

Slide 75 text

ペアプロの問題点=依存性 ● 一人でプログラミングすることが不安になります ● Ken Auerはパートナーがトイレに行っている間に、コストの大きいエラーが発生するというシナリオを記述している 75 『ペアプログラミングエンジニアとしての指南書』ローリーウィリアムズロバートケスラー, pp. 63

Slide 76

Slide 76 text

ペア・モブプロのプロセスをカイゼンするためのヒント② ● 指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの実施のコツを解説した記事 ● 理想のペアプロ形態の１つは、ダブルリードでペアのどちらもがリード役でサポート役です。 76 知識差-スキル差を埋めるためのペアプロ＋αのコツ(1) Eiji Ienaga ※ 太字は発表者独自の視点

Slide 77

Slide 77 text

一人でもできるけどペア・モブだからもっとうまくできるが理想 77 ライオン先生はペアの利点を生かしつつ、このゴールに近づける

Slide 78

Slide 78 text

改めてまとめると 78

Slide 79

Slide 79 text

自分というコンテキスト：口よりも手が動く ● 説明するのは苦手、言語化は苦手で言いたいことがまとまらない ○ 人と話すのが苦手なわけではない ● 滑舌はよくないのでよく何言っているかわからなくなる ● 脳内メモリは全然多くないので空中戦が苦手 79

Slide 80

Slide 80 text

そういう人におすすめの3つのパターン ● 五十六先生パターン ○ やってみせるで相手に新しい概念を植え付ける ● 赤ペン先生 ○ ブラッシュアップで相手により概念を理解させていく ● ライオン先生 ○ 相手に実装概念を定着させる 80

Slide 81

Slide 81 text

そういう人におすすめの3つのパターン ● 五十六先生パターン ○ やってみせるで相手に新しい概念を植え付ける ● 赤ペン先生 ○ ブラッシュアップで相手により概念を理解させていく ● ライオン先生 ○ 相手に実装概念を定着させる 81 全ては指示や説明を減らして、実装ベースで議論するもの

Slide 82

Slide 82 text

最後のまとめ 82

Slide 83

Slide 83 text

ペアプロ・モブプロは簡単なようで奥が深い 83

Slide 84

Slide 84 text

最後に伝えたいこと ● 今回紹介した3パターンは説明下手な開発者にとって、かなり有効なパターンであると考えています ● ただ、今回の3つだけではなくて、状況やコンテキストに合わせていろいろなパターンが発見できると思います ● 重要なことはプラクティスの背後にある意図を理解して、自分たちにあったやり方を見つけることで、みんなでパターンが増やしていきたい！！ 84