スキル差があるペア_モブプロで効果的な_ドライバーナビゲータ以外のロールの分け方.pdf

スクラムフェス三河2023の発表資料

Transcript

1. スキル差があるペア・モブプロで効果的な、 ドライバーナビゲーター以外のロールの分け方 クリエーションライン　矢田進之介 1
2. このセッションのゴール • プレゼンのターゲット ◦ ペアプロやモブプロをやったことがある人 ◦ スキル差があるなかでのペアプロやモブプロの進め方に悩んでいる人 • アウトカム ◦ チームやプロダクトの状況に合わせて、ペアプロやモブプロでの進め方を柔軟に扱える、も しくはそのきっかけがもらえる ◦ 教育と開発スピードのバランスがうまく取りながら進められるようになることでメンバー間 のスキル差が緩和されていく 2
3. 今日話すこと • 自己紹介と自分自身のモットー • ペア・モブプロがスキル差で辛くなる時もある • スキル差があるペアモブのなかで起こった過去の自分の失敗談 • そこから気づいたペア・モブプロの難しさとそれを改善する仮説 • 先人たちの知恵から推測できる成し遂げたかった意図とは？ • 実践の中で見つけた役割の分け方に関する新しいパターンの紹介 • さいごに 3
4. 自己紹介 • クリエーションライン株式会社 • アプリケーションエンジニア • 劇団CL団長 • 矢田進之介（やたしんのすけ） • 愛知県安城市出身 • ソロでの登壇は初めて • 人生初登壇もスクフェス三河 4

5. 自分がこれまでやってきたこと • 社内の開発者へのユニットテストの導入支援 • 新卒PBLのメンター役 • 社外の開発者へのリスキリング支援など 5
6. モットーは目の前の１人を変化に巻き込むこと • 不特定多数の人にメッセージを発信したり、マネジメント側に回って変化を 起こしていくのは自分にはまだ難しい • 現場で背中を見せたり、一緒に試行錯誤しながら目の前で一緒に仕事をして いる１人から変えていきたい • そのための変化の創発の場として、ペアプロ・モブプロがあると思っている 6
7. ペアプロ・モブプロとは • ソフトウェア開発の手法の一つで、2人以上のプログラマーが１台のマシン を操作してプログラミングを行う手法のことを言う • ドライバー・ナビゲーター（モブプロの場合はモブ）に別れる。10-15分程 度で役割を交代しながら進める • コーディング速度が15%低下するが、バグの数も15%少なくなると言われて いる（フロー効率がよくなる） ペアプロを知らない人用に 7
8. ここでペアプロを知っているみなさんに質問 8
9. あなたの周りにはペアプロ・モブプロに 嫌悪感を感じる開発者はいませんか？ 9
10. ペアプログラミングは、誰もが気に入る方法ではない 10 『モブプログラミング・ベストプラクティス』マーク・パール, pp. 24 1.2.3章
11. その開発者はスキル差があるなかで 教育とスピードのバランスを考えながら モブするのに悩んでいるかもしれません 11 ただ、場合によっては
12. ペアプロを効率的にするための注意事項=スキルの不均衡 スキルの不均衡には、胃が痛くなります。チームメ ンバーが未熟なメンバーのスキルを向上させること が、チーム全体のメリットとなると認識することが 理想です。しかし、全ての人がこのように忍耐強 く、人に愛される性格ではありません。 12
 『ペアプログラミング エンジニアとしての指南書』 ローリーウィリアムズ ロバートケスラー, pp. 68 ※ 太字は発表者独自の視点
13. これは僕自身のお話 13
14. 2年くらい前の当時のチームの状況 メンバー間でスキル差が生じているチームメンバーで教育が課題だった 良いコードに関する基準がバラバラ、ユニットテストもあまり書いていない 14 え、まだユニットテストをできてない現場があるんですか？, pp. 10-11
15. そのときのペア・モブプロの進め方 • 新卒の子１人 + ジュニアレベル１人 + 自分のペアプロ・モブプロ • ドライバー ◦ キーボードを持ってコードを書いていく人、自分だけの考えで実装を進めない • ナビゲーター・モブ ◦ ドライバーが書いたコードをレビューしながらドライバーに対して適切な指示をする人 ◦ 自ずと自分がなることが多かった • １セッションが25分タイマーで交代する 15
16. なんとなくこのやり方に 落ち着いてしまった 16
17. 前述の進め方がうまくいく必要条件 • リファクタリングやオブジェクト指向、ユニットテストなどの基本的な素養 や論理的思考力がチーム全体に担保されている • コードを実装するうえでそのときに自分が考えていることの思考プロセスが ある程度言語化できるや相手の意図を察する能力が高い • それぞれがお互いの知識の共有についてモチベーションが高い 17 当時のチームでは上２つは確実に満たしていない
18. そのとき起こった失敗談①：教育のつもりが迷惑 • ジュニアレベルの人にドライバーをやってもらった時のこと • 自分として属人化はなくしたいし、チームとして強くなりたいという思いがあった • 壁打ちとしていろいろ問いを投げかけてみよう ◦ できたコードに対して、実はこれが間違っています！どこでしょう？ ◦ 発生したエラーに対してこれはなぜ起こっているのでしょう？ • ドライバー側に問いを投げかけすぎてキレられる ◦ 「お前のチームの一員なんだから実装とかわかってるんだったら言えよ！」 18
19. そのとき起こった失敗談②：スピード優先の伝言ゲーム • 新卒1年目の子にドライバーをやってもらった時のこと ◦ 実装を論理的に考えて構文まで落とし込むのに少し苦労する人 • 曖昧な指示を出すと、構文を調べたりするのに時間がかかってしまう • 開発が遅れすぎるのもよくないし、できるだけ具体的な指示をしよう！ • whyをいいながら進めようと試行錯誤をしながら結局whatを指示する日々 • 結果として、あまり考えることなく言われたことをただコードにうつすドラ イバーになる ◦ 知識差が緩和されることもなく、ただただナビゲータの自分が疲れてしまう 19
20. ソフトウェア開発においてスピードは教育とのトレードオフ 20 知っている人が多いとは思いますが 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き, pp.68
21. 開発者が開発者を教育するのが難しい 21 相手のキャリアプラン そもそも自分だって 知らないことが多い 相手との関係性構築 変化の早い 技術スタック マインドセット教える のむずい 他人に教えることの モチベ作り 結局最後は自分の問題 わかりやすい説明 むずかしい
22. コラボレーションは習得に時間と忍耐が 必要なスキルである 22 『クリーンクラフトマンシップ』 Robert C. Martin, pp. 225 (第７章 協力的プログラミング)
23. チームとしての教育とスピードだけでも難しいのに 23 教育とスピードの バランス
24. スキル差が大きくあると教育自体の難易度も増す 24 教育自体の難しさ 教育とスピードの バランス
25. 人との協働作業をし始めると 25 教育自体の難しさ 教育とスピードの バランス コラボレーション の難しさ
26. スキル差のあるペアプロ・モブプロはかなり難しい 26 教育自体の難しさ 教育とスピードの バランス コラボレーション の難しさ
27. それでも向き合っていく 27
28. 大きく3つの問題があった気がする • 自分の問題 ◦ 自分の説明スキルは高い方ではない • チームの問題 ◦ 教育とスピードのバランスについて合意が取れていなかった ◦ 実装スキルに差がありすぎて、コードに対する意識があっていなかった • プロセスの問題 ◦ ドライバー・ナビゲーターがあっていない ◦ 25分交代が逆にリズムを作れなかった 28 失敗した状況を振り返ってみると・・・
29. 自分や人を変えるのは大変なのでプロセスを変える 29 人を変えられない 認識はズレやすい プロセスは変えられる • 自分の問題 ◦ 自分の説明スキルは高い方ではない • チームの問題 ◦ 教育とスピードのバランスについて合意が取れていなかった ◦ 実装スキルに差がありすぎて、コードに対する意識があっていなかった • プロセスの問題 ◦ ドライバー・ナビゲーターがあっていない ◦ 25分交代が逆にリズムを作れなかった
30. もっとうまい進め方はないか？ 30
31. ペア・モブプロのプロセスをカイゼンするためのヒント① cybozu社でのいいモブチームの動き方をモデル化したもの チームにあった独自の役割が根付いている シン・モブプログラミング第三形態 by 永田敦, pp. 33, pp. 38 31
32. ペア・モブプロのプロセスをカイゼンするためのヒント② • 指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの 実施のコツを解説した記事 • 理想のペアプロ形態の１つは、ダブルリードでペアのどちらもがリード役でサポート役で す。 32 知識差-スキル差を埋めるためのペアプロ＋αのコツ(1) Eiji Ienaga ※ 太字は発表者独自の視点
33. それらから生まれた自分の中での仮説 • 良いチームはドライバー・ナビゲーターに拘っているわけではなく、 自分たちにあったやり方を見つけていそう • ドライバー・ナビゲーターの１つの型（カタ）であり、メンバーそれぞれの 特性やチームの状況にあったよりよい分け方がありそう 33
34. 今こそ「離」の瞬間 34
35. 守破離 from レガシーコードからの脱却 • アジャイルを、やって良いこと、やって悪いことのルールとして学ぶ人は多 い。（中略）ルールを学ぶのは学習の最初のステージにすぎない • ソフトウェア開発のような複雑な活動はルールだけで捉えることは難しい。 ~（中略）~ ある状況では最良のアプローチが別の状況では最悪のアプロー チになることもある • 守から始める理由は、プラクティスの背後にある理論が簡単には理解しにく いからだ。~（中略）~ 成功するには、プラクティスを上手に使いこなせる ように、プラクティスの背後にある原則を学ばなければならない。 35 『レガシーコードからの脱却』 David Scott Bernstein, pp. 50 (4.2 守破離)
36. 今こそ「離」の瞬間 自分の中で実践知は溜まっているはずなので 先人たちの書物の助けを借りながら言語化する 36
37. 書籍でペア・モブプロの意図を探す 37 自分が持っている5冊くらいの記述を紹介します
38. XP白本の記述 • ペアプログラミングとは、2人でプログラミング（および、分析・設計・テ スト）とプログラムの改良を同時に行うやりとりのこと • 以下のようなことをする ◦ お互いにタスクに集中する ◦ システムの改良について意見を出し合う ◦ アイデアを明確にする ◦ パートナーがはまったら主導権をにぎり、相手の失望感を軽減させる ◦ お互いにチームのプラクティスの説明責任をはたせるようにする 38 ※ 太字は発表者独自の視点 『エクストリームプログラミング』Kent Beck, Cynthia Andres, pp. 40 (主要プラクティス)
39. ソフトウェアクラフトマンシップにおける記述 • 協力的プログラミングとは、2人以上の人が、同じコー ドで、一緒に作業をする規律である。 • コラボレーションのセッションの時間は10分程度の短い 時もあれば、1-2時間の長い時もある。 • キーボードを触っているのは1-2人かもしれないが、そ の席はセッション中に何度も入れ替わる。 39 『クリーンクラフトマンシップ』 Robert C. Martin, pp. 224 (第７章 協力的プログラミング) ※ 太字発表者独自の視点
40. クリーンアジャイルにおける記述 • 二人が一緒に同じプログラミング課題に取り組む • ペアになるプログラマーは異なる役割を担当する。一人 がドライバーで、もうひとりがナビゲーターだ。（中 略）ひとりがテストを書き、もうひとりがそのテストを パスさせ、それを交互に行うという役割分担もある。ほ とんどの場合、明確な役割分担はない。 40 『クリーンアジャイル』 Robert C. Martin, pp. 124 (5章 テクニカルプラクティス) ※ 太字発表者独自の視点
41. モブプロベストプラクティスにおける記述 • 3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決 していくことだ。分散知識の考え方をプログラミングに活かしたものである • キーボードの前に座っている人をタイピスト、それ以外をその他のモブとし ている 41 『モブプログラミング・ベストプラクティス』マーク・パール, pp. 24 1.2.3章
42. ペア・プログラミングの記述 • 表面的にはペアプログラミングはシンプルな概念です。 • 二人のプログラマーが同じタスクに対して1台のコン ピューターで一緒に作業する • 目的に合わせたさまざまな種類のペアが存在する ◦ 専門家-専門家 ◦ 内向型-外向型 ◦ など 42 『ペアプログラミング エンジニアとしての指南書』 ローリーウィリアムズ ロバートケスラー, pp. 68
43. まとめ 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒 に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ １台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 43
44. 意図は交流から生まれる相互作用にある 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒 に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ １台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 44
45. 交流のやりかたについては原則はない 意図 交流の仕方 XP白本 2人でプログラミングとプログラムの 改良を同時に行うやりとりのこと 改良のアイデアを出し合って、パート ナーがはまったら主導権を握る クラフトマンシップ 2人以上の人が、同じコードで、一緒 に作業をする規律 キーボードを触っているのは 1-2人 クリーンアジャイル 二人が一緒に同じプログラミング課題 に取り組む 明確な役割分担はない モブプロ １台のコンピューターの前に座って協 力しながら問題を解決していく キーボードの前に座っているタイピス ト、それ以外 ペア・プログラミング 同じタスクに対して1台のコンピュー ターで一緒に作業する 目的に合わせたさまざまな種類のペア が存在する 45
46. それらを踏まえて自分の認識 共通している意図 • 全員で同じコードをみながら交流することによって相互作用を生むこと 状況に合わせて自由にできること • 役割の分け方と交流の仕方（指示する人と書く人だけではない） • 役割交代のタイミング ここで言う、状況を決める変数 • それぞれの実装スキル • 実装の難易度 • 考えていることの言語化能力 • 個々人の性格（外向的か内向的） 46
47. それらを踏まえて自分の認識 共通している意図 • 全員で同じコードをみながら交流することによって相互作用を生むこと 状況に合わせて自由にできること • 役割の分け方と交流の仕方（指示する人と書く人だけではない） • 役割交代のタイミング ここで言う、状況を決める変数 • それぞれの実装スキル • 実装の難易度 • 考えていることの言語化能力 • 個々人の性格（外向的か内向的） 47 自分の場合はここが苦手
48. 自分の特性と意図を踏まえてやり方を変えてみた • 8月-12月のなかで新しいチームにジョインした時の話 ◦ 10月-12月の間にペアプロをやるようになった • 一緒にやっていた相手 ◦ いわゆるジュニアレベルのエンジニア ◦ ユニットテストを書いたことがない ◦ クラス設計は肥大化しがち • ドライバー・ナビゲーターは意識せずに自分にあう方法を試す 48
49. そのチームのBefore PoCをやっていたとはありつつもリポジトリにはたった1件しかなかったテスト 49
50. そのチームのAfter • そのリポジトリは100件のテストケースが生まれた • GoFのデザインパターンのいくつかやデータオブジェクトを書くのが当たり 前になった • 自分が抜けた後も品質改善が続いていった ◦ 自分が触っていなかったリポジトリに追加要望が入った時の話 ◦ お客さん向けに品質改善の交渉を申し出る ◦ 既存のリポジトリを書き直すと1ヶ月かかるけど新しく書き直せば2,3週間で保守性が高いも のができます 50
51. ふりかえってみると、どう役割を分けていたか？ • 3つの役割のパターン • コンポーネント単位、もしくはつまったタイミングでパターンを変える • それぞれのパターンで動く前に合意をとる 51
52. 実践の中で見つけた、役割の分け方に 関する新しいパターンの紹介 52
53. パターンの書き方（Alexander + fearless change + α） • パターン名 • このパターンが使える状況：問題が発生する状況の定義 • このパターンが解決できる問題 • 役割の分け方：解決策としてのそれぞれの役割での動き方や関わり方 • 実施方法：解決策としての役割の分け方を踏まえた実施方法 • 例：自分が実際にこのパターンを見出した場合の例 • 気をつけることや注意すること 53 初めてパターンを言語化してみたので優しく見守ってください
54. パターン：五十六先生 54
55. パターン：五十六先生 • このパターンの要約 ◦ 自分の実装風景を相手に観察してもらうことでその実装概念に対しての価値を実業務を通し て実感してもらい、イメージをつける。 • このパターンが使える状況 ◦ あなた自身は暗黙的に使いこなしている実装技術ではあるが、相手にとっては新しい概念と なるものがたくさんある • このパターンが解決できる問題 ◦ 初学者に対して教育の時間が充分に取れないなかで実際の開発タスクが山積みである ◦ 初学者にとっては、さまざまな実装技術のアイデアを活性化してくれる存在が必要である 55
56. • 役割の分け方 ◦ 師匠（主体的に実装）= インストラクター ▪ 通常通りに実装を行い、言語化できる部分は説明をする ◦ 弟子 = オブザーバー ▪ 「師匠」を観察しながら暗黙的に概念を記憶する • 実施方法 ◦ 「師匠」は言葉のみの説明に注力せずに背中を見せながら実装を進めていく ◦ 「弟子」は「師匠」の実装を共体験することで、暗黙知を獲得する パターン：五十六先生 56
57. 例：新人にテストファーストな実装を教える • テストとは？の説明はせずに実装から見せるところから始める ◦ こういう感じでテストってのを書いていくんだよ • テストメソッドで日本語で入力と出力を書いてみせる ◦ 書いた後に以下のメリットだけ伝える ▪ 日本語で書くとコードが読めない人でもわかる ▪ 具体的に書いて、グルーピングすると仕様の理解が深まる • テストコードが失敗するところを見せる • テストがパスするように変更する • リファクタリングする • 最後に追加で説明する ◦ テストの実行は何回でもしていい ◦ テストを通したまま変更すればよりよいコードになる 57 TDDとまでは言わないが
58. 例：新人にテストファーストな実装を教える • テストとは？の説明はせずに実装から見せるところから始める ◦ こういう感じでテストってのを書いていくんだよ • テストメソッドで日本語で入力と出力を書いてみせる ◦ 書いた後に以下のメリットだけ伝える ▪ 日本語で書くとコードが読めない人でもわかる ▪ 具体的に書いて、グルーピングすると仕様の理解が深まる • テストコードが失敗するところを見せる • テストがパスするように変更する • リファクタリングする • 最後に追加で説明する ◦ テストの実行は何回でもしていい ◦ テストを通したまま変更すればよりよいコードになる 58 TDDとまでは言わないが それ以上のことは、説明すると自分の説明がうまくできないのとスピードが変わるのであとに回す
59. 師匠側が気をつけていることや注意していること • 説明に躓きそうだと思ったら、一連の処理まで実装し終わった後に書き終 わったコードベースで説明すること ◦ 説明しながら実装を意識しすぎると脳内メモリを使いすぎるので疲れる • 相手にわかってもらうことを意識しないこと ◦ 完全に理解させようとするよりも、まずは見てもらうことを目的とする ◦ 聞いてわかったことはすぐ忘れる ◦ その後に自分で書いてみるフェーズで腑に落ちるときもある • わからなくても写経させるくらいなら観察させる • 説明できないのは、言語化できないだけなのでやって見せる 59
60. パターン：赤ペン先生 60
61. パターン：赤ペン先生 • このパターンの要約 ◦ 経験値の浅い開発者は自分のコードを修正してもらうことでよりよいコードへの差分を理解 する • このパターンが使える状況 ◦ 経験値の浅い開発者は、あなたの持ち合わせている実装概念について浅い理解はしているの でその知識を定着させたい • このパターンが解決する課題 ◦ 経験値の浅い開発者は実装概念についての知識を十分に理解するための練習時間が取れない 61
62. パターン：赤ペン先生 • 役割 ◦ 弟子（主体的に実装） ▪ 実験に近い形で実装をする ◦ 師匠 ▪ 実装されたものに対してブラッシュアップ（orリファクタリング）する • 実施方法 ◦ 「弟子」は「師匠」からリアルタイムでレビューを受けながら実装を行うことでよりよい コードへの差分や勘所を頻繁に知ることができる ◦ 「師匠」は「弟子」の書いたコードをもとに直接書き直すことで新しい概念を伝える 62
63. 例：可読性の高い実装 by モブプロ（新卒+2年目+自分） • とあるコンポーネントに関して新卒が書いてみる ◦ 新卒の子はとりあえずできるところまでをやってみる ◦ 実装ができたらそれでよし ◦ 詰まるなら２年目に渡す • 2年目が実装/リファクタリングしてそのコードをよりよくしていく ◦ ２年目は新卒の子が書いたコードをその場で引き継いでよりよいコードを実装していく ◦ 新卒の子は自分のコードが変更されていく様を見ることで実装パターンのイメージが活性化 されていく • 自分が最後にリファクタリングをしてよりよい実装を作る ◦ ふたりとも実装がほとんど終わらなかった場合は五十六先生パターンになる 63
64. 師匠側が気をつけていることや注意していること • 師匠側はより良い実装への修正と不要な実装の削除を主な作業とする • 弟子側がつまづいた時点で、師匠が手を動かすようにスイッチをする ◦ コードを引き継いで自分であればこう書く！という議論につなげながら理解を深めさせる • 直すことで理解を促し、直す観点から新しい概念を教えていくこと 64
65. パターン：ライオン先生 65
66. パターン：ライオン先生 • このパターンの要約 ◦ 単独練習を通して、それぞれの実装概念の背後にある原則を深く理解する ◦ ライオンが谷底に落として育てるようなイメージ • このパターンが使える状況 ◦ 経験の浅い開発者は熟練者とのペア・モブプロであれば実装ができるとき • このパターンが解決できる問題 ◦ 開発者がペア・モブプロのフィードバックループに過剰最適されている ◦ 開発者はペア・モブプロでないときに実装への自信がなくなる 66
67. パターン：ライオン先生 • 役割 ◦ 弟子（主体的に実装）= ソロプログラマー ▪ 覚えたことや実践してみることで実践知を増やし、自分の中で知識を昇華させていく ◦ 師匠 = レビュワー ▪ タイポなどの明らかに間違っているところだけ指摘する（エディターの機能に近い） • 実施方法 ◦ 画面は一緒に見ているがプログラマーができるだけ単独で実装を行う ◦ ただし、バグは防ぎたいので、レビュワーは監視をしながらバグを発見したら報告する 67
68. 例：通常の実装でより強くなる • ２人で同じ画面を見ているが、相手は一人で実装を行う • 自分はタイポのみ指摘する • 自分は、手が止まったタイミングで考えの言語化だけ質問する • 実装が終わった後に感想戦を行う • できるだけ相手の実装した状態を残し、相手だけで実装した風味を残す 68
69. ３つのパターンの共通点 • 作業はわけずに交流の仕方を決める役割であること ◦ 書く人（ドライバー）・指示する人（ナビゲーター）のような作業ごとの分け方をしない • つまずきを減らすことにフォーカスすること ◦ 五十六先生は、交流によって生まれるつまづきを減らすためのもの ◦ 赤ペン先生とライオン先生はつまづいたらコードを書く人が変わる • 書いていないものでの会話を減らすこと ◦ whyの言語化が苦手な人でもコードベースで話がしやすい 69
70. ３つのパターンの差分は相手の習熟度 五十六先生から始まって、赤ペン先生で理解を深めてライオン先生で個人の技術 を高めるのが必勝パターン 70 まだ早かった まだ早かった やってみようかな？ やってみようかな？
71. 推しパターンは赤ペン先生 71
72. パターン：赤ペン先生のいいところ • 師匠側はリファクタリングなので楽しい • コードが書かれていく様子を見ているのでハイコンテキストな状態で他人の コードをリファクタリングできる • よいリファクタリングをしたときに、へええって言われるのが嬉しい • 初学者にとっては、どこが変えるべきなのか見当がつかないので学びがある • 初学者にとっては、自分のコードだから実感が湧く • いろいろ試行錯誤の議論ができて楽しい 72
73. 意外と重要なのはライオン先生 73
74. ライオン先生がなぜ重要なのか？ システムを設計するための判断力をつける一番の方法は、自分で設計したシステ ムを長い間メンテすること 74 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き, pp.94
75. ペアプロの問題点=依存性 • 一人でプログラミングすることが不安になります • Ken Auerはパートナーがトイレに行っている間 に、コストの大きいエラーが発生するというシナ リオを記述している 75 『ペアプログラミング エンジニアとしての指南書』 ローリーウィリアムズ ロバートケスラー, pp. 63
76. ペア・モブプロのプロセスをカイゼンするためのヒント② • 指導役となる熟練者側向け中心に知識差-スキル差を埋めることを主目的としたペアプロの 実施のコツを解説した記事 • 理想のペアプロ形態の１つは、ダブルリードでペアのどちらもがリード役でサポート役で す。 76 知識差-スキル差を埋めるためのペアプロ＋αのコツ(1) Eiji Ienaga ※ 太字は発表者独自の視点
77. 一人でもできるけどペア・モブだから もっとうまくできるが理想 77 ライオン先生はペアの利点を生かしつつ、このゴールに近づける
78. 改めてまとめると 78
79. 自分というコンテキスト：口よりも手が動く • 説明するのは苦手、言語化は苦手で言いたいことがまとまらない ◦ 人と話すのが苦手なわけではない • 滑舌はよくないのでよく何言っているかわからなくなる • 脳内メモリは全然多くないので空中戦が苦手 79
80. そういう人におすすめの3つのパターン • 五十六先生パターン ◦ やってみせるで相手に新しい概念を植え付ける • 赤ペン先生 ◦ ブラッシュアップで相手により概念を理解させていく • ライオン先生 ◦ 相手に実装概念を定着させる 80
81. そういう人におすすめの3つのパターン • 五十六先生パターン ◦ やってみせるで相手に新しい概念を植え付ける • 赤ペン先生 ◦ ブラッシュアップで相手により概念を理解させていく • ライオン先生 ◦ 相手に実装概念を定着させる 81 全ては指示や説明を減らして、 実装ベースで議論するもの
82. 最後のまとめ 82
83. ペアプロ・モブプロは簡単なようで奥が深い 83
84. 最後に伝えたいこと • 今回紹介した3パターンは説明下手な開発者にとって、かなり有効なパター ンであると考えています • ただ、今回の3つだけではなくて、状況やコンテキストに合わせていろいろ なパターンが発見できると思います • 重要なことはプラクティスの背後にある意図を理解して、自分たちにあった やり方を見つけることで、みんなでパターンが増やしていきたい！！ 84