KDOC 177: 『モブプログラミング・ベストプラクティス』

• 作成
  • 2024-05-24 貴島
• レビュー
  • 2024-05-27 貴島

モブプログラミング・ベストプラクティスは、モブプロの解説本である。方法論だけでなく、上司を説得させる方法やチームに根付かせる方法までカバーしている。

• 上司から支持を取り付けることも難問である。彼らに対しては、管理的な問題を解決するということを伝えればよい、という(p27)
• リソース効率は、特定のタスクのスキルが特に高い人が生まれる。できる人に集中し、ボトルネックになっていく。フロー効率は、機能全体を早く市場に出すことを重視する(p28)
• モブで行うと、キーパーソンへの依存度を下げる。チーム内の経験の浅い人々のスキルを引き上げ、チームメンバーがそれぞれのアイデアを共有する(p30)
• 成功をいかにして計測するかは、管理職が知りたいことだという。最初に期待値を設定しておく(p31)
  • 例: マージコンフリクトの解決にかかる時間の短縮。数値として出る
  • 例: 本番システムに入り込む欠陥の数の減少。数値として出る
  • 例: チーム内の経験の浅いメンバーの学習度の上昇。アンケートする
  • 例: チームがモブプログラミングの導入を改善と感じているかどうか。アンケートする
• 導入当初は、モビングによって得られた成功を文書化して記録しておくと役に立つ、という。成功を実感した日の出来事を書く。知識共有の機会が生まれたことや品質上の問題が見つかったことなどを記録しておく。上司に説明するときに読み返すと役立つ(p32)
• チーム内に実験の文化を根付かせることは単にモブプロを実験する以上の価値がある、という(p33)
• モブに参加するかは自由で、それぞれの意思で決めてよい。参加の強制は、確実に失敗を招く(p34)
• 初めてモブプログラミングをしてみるときには、実験として位置づけることが大切である、という。そういう位置付けだと、期待が高くなりすぎず、参加者も心理的なセーフティネットを張れる。モブプロのメリットを聞いたので、役に立つか試してみたいと考えていることが伝わるようにする、という(p37)
• セッションが終わるたびに、うまくいったのはどういうことで、軌道修正が必要なのはどういうことかをグループ全体で評価する。数回したら、続けるだけのメリットがあるかどうかをグループとして判断する。少なくとも5回以上を目指すべき、という(p39)
• 実験としてモビングを行っている間は、モブは小規模におさえる。最初のうちは3、4人がちょうどよい、という。参加人数によっては、大規模なモブをひとつ作るのではなく、複数のモブに分ける。はじめのうちは混乱しやすくなるため(p39)
• Agility - Mob Programming Timer。モビング専用のタイマー(p48)

• タイピストが効果的な仕事をするために求められること(p53)
  • その他のモブがしてくれと頼んだことを理解すること
  • 要請の意味がはっきりしないときは、はっきりするための質問をすること
  • してくれと頼まれたことをコードの形に実装すること
  • その他のモブを信頼し、自分では通常試さないようなアプローチを躊躇せずに試すこと。抵抗するのではなく、要請されたことを実装してからそれを評価する。コードで表現されていないものに反対すると長い論争になり仕事が進まないことがある。表現してからだと議論が進む
  • ショートカットキーやほかの人のツールの活用方法などの新しい方法を学ぶこと
• タイピストは頻繁に交代するので、コードを理解していることが大切である(p54)
• タイピストをやっているときにアイデアが思い浮かんだ場合は、その他のモブにアイデアを説明して実装に賛成してもらうか、ほかの人にタイピストを替わってもらって自分はモブに戻らせてもらうかのどちらかにする、という(p54)
• タイピストになっているときは、自分のコードをこっそり書くようなことをしてはならない。モブの決定に委ねてコラボレーションを心がけなければならない(p55)
• ホワイトボードに問題解決のさまざまなアプローチを書いてブレインストーミングする。議論は15分程度で終わらせるべき。意見が一致したらホワイトボードに手順を書き出し実装の細かい問題はモビングインターバルで考えるようにする(p59)
• エキスパートではない人にとって、タイピストは最良のポジションである、という(p59)
• コーディングに進むと、会話の内容が理論的なものから実践的なものに変わっていく(p62)
• タイピストの順番でなければ、キーボードには触れてはならない(p64)
• セッションの最後の20分は、モビングを締めくくるためのレトロスペクティブに充てる。考える対象を明確に切り分け、議論がまとまりのつかないものにならないようにする(シンキングハット法)。4種類の帽子をかぶってモビングセッションを評価するつもりだということを説明する。全員が同じ色の帽子を同時にかぶったつもりになって、それぞれの帽子が表す観点からモビングセッションについて議論する。間違った色の帽子をかぶったときはその人の話をさえぎり議論を今の帽子の内容に戻すことが許される(p65)

• 軌道修正すべきことの決定、合意形成。建設的な問題解決の欄に集められた提案の中で、最初に試したいものを尋ねる。ここで決める修正は次のモビングセッションで行う実験に過ぎないことを伝える。うまくいかなければ、いつでも戻していい。全員の賛同が得られないなら、何も変更しない。変更点を試してみるためには全員の同意が必要である(p71)
• 人ではなくコードを批判せよ、という(p77)
• エキスパートがタイピストになると、うわべだけは健全そうな薄っぺらいモビングセッションになる、という。エキスパートにはタイピストの役割を回さない(p101)
• タイムボックス付きで探求する。目の前の課題に対する理解を深めるために、モブの個々のメンバーにそれぞれの考えを掘り下げていく時間を与える方法。理解しなければならないことをモブ全体で明確にし、タイムボックスに入る。それぞれの方法を追求する。誰かが必要な知識を突き止めたら、わかったことを共有する。誰も得られなかった場合でも、一度グループに戻り、それまでに学んだことについて報告する(p105)
• 新しいプログラミング言語を勉強するときには、モビングは役に立たない。じゅうぶんに理解しているおなじみの領域の仕事では、モビングはきわめて効果的である、という(p106)
• アイデアがさまざまで収拾がつかない場合のテクニック、強いモビング。進行役を決めて、進行役がしてくれと言ったことしかしない。その他のモブが試してみたいアイデアを持っているときには、進行役にアイデアを委ねなければならない。進行役はアイデアをホワイトボードに書き出してモブにさまざまな提案を突き合わせ、明確化を促す。進行役はアイデアに対して自分がどうかんじているかに左右されてはならない。どのアイデアを試してみるのかはモブである。次に確かなこと、確認が必要なことをモブに答えさせる。モブはどう作業を進めていくか決める
• 全員が正面に画面を見ているように、机、ディスプレイ、椅子を配置するとよい、という(p119)
• モブプログラミングによって満たされるチームメンバー個人のニーズの例(p128)
  • 解こうとしている問題を理解する
  • 問題点の調査にかかる時間を短縮する
  • チームメンバーの作業の進捗状況を揃えるための会議を減らす
  • 作業が中断される回数を減らす
  • 従来よりも品質の高いコードを書く
  • 必要なときにチームを離脱できるようにすること
  • チームのほかのメンバーとつながっていることを実感できるようにすること
• チームに固有なニーズをはっきりさせる

なし。

• KDOC 204: 知らない分野の学びかた