レガシーコードからの脱却

9.8.2 保守しやすいコードを書く７つの戦略 内容 コードの共同所有を取り入れるコードの共同所有とは誰でもどのコードでも変更してよいことを意味する。チーム全員が同じコーディング規約を持つことで、誰が書いてもスタイルは保たれ扱いやすくなる。同じドメインモデル、開発プラクティス、用語を揃えることで更に良くなる。 リファクタリングを熱心に行うすでに動いているものであっても、状況に応じてリファクタリングはしていくと良い。リファクタリングは保守性につながる。 常時ペアで進めるペアプログラミングは知識共有の一番はやい方法。設計、開発、リファクタリング、デバッグ、テストでは常時ペアを組み、共有された知識で、コードの一貫性を保つ。 頻繁にコードレビューするペアを組んでいたとしても、ペアを組んでいない人がコードを見てフィードバックする機会になる。 ほかの開発者のやり方を学ぶ自分の外側にある知識を学びつつ自分も成長させる。 ソフトウェア開発を学ぶプロの専門家は継続的な学習が必要。ソフトウェア開発者もしかり。 コードを読み書きして、コーディングの練習をする作家スティーブン・キングは「作家になるために必ずしなければならないことが２つある。たくさん読み、たくさん書くことだ」と言った。ソフトウェア開発者も同じで、たくさん読み、たくさん書くこと。 学び 保守性を高める戦略 学びを活かすアイディア・行動 ペアプロ、コーディング規約作り

8.7 コードレビューとレトロスペクティブのスケジュールを立てる 8.8 学習を増やし、知識を広げる 8.9 常にメンター、メンティーであれ 8.10.2 レトロスペクティブの７つの戦略 内容 ペアプロの本質の１つはリアルタイムなコードレビューが含まれているということ。しかし、チーム全体に共有する時間を持つと、尚良い。 また、ペアプロで上手くいったことや上手くいかなかったことの共有としてレトロスペクティブを行い、チームで共有することも良い。 今は、個がスペシャリストになればそれで良いという時代ではない。横断的に情報を展開し、さまざまなことができるチームになることに価値が置かれている。外部の人とも積極的に混ざり合い（機密情報はもちろん伏せる必要があるが）、楽しく知識を増やそう。 ときには孤立するかもしれない。しかし、目的にフォーカスする姿勢、教えることは教わることがという謙虚な姿勢と、新しいことを受け入れる勇気を持ち、協働して作る世界に入ることは自分にとって多くのメリットがあるはずだ。 レトロスペクティブの７つの戦略 小さな改善を探す組織（人）は変化を嫌う。特に、同時に多数な変化があることを嫌う。小さな改善を積み重ね、徐々に改善する。 プロセスを責めよ。人を責めるな誰かが原因で問題が発生した場合でも、その人の問題にフォーカスするのではなく、その人がそうなってしまった開発プロセス全体をフォーカスする。 なぜなぜ５回をやってみる問題がなぜ起こったかを自分たち自身で問う。４回目あたりから想像もしなかった真因が見える。 根本原因に取り組むそのまんま 全員の意見を聴く問題に対して全員の目線が揃っているかは重要。出揃っていない場合、偏った解決策になる可能性がある。 人に権限を改善行動に取り組む際には、必要なものを与える。特に、権限と責任を与え、勇気を持って取り組ませる。 進捗を測る改善は明確なゴール、指標で計測できる状態にすることで効果が図りやすく、さらなる改善につながる。 学び 学びを共有することにさらなる学びがある 学びを活かすアイディア・行動 まずペアプロの実践

8.5 スパイク、スウォーム、モブ 8.5.1 スパイク 8.5.2 スウォーム 8.5.3 モブ 8.6 タイムボックスの中で未知を研究する 内容 ペアプロ、バディプロの他に有効なプラクティスを紹介。 スパイク未知の課題解決のために１つのタスクに複数の開発者が取り組む。使う時間は限定し、課題が解決すればその会は解散する。 スウォーミングチーム全体（または複数のメンバー）で課題解決に取り組む。 モブ単一のストーリーを複数の開発者で進める。ペアプロの複数人版で、キーボードを打つのは常に１人、周りはディスカッションしながら指示をする。物によっては非常に有効。 また、これらの方法は、ソフトウェア開発だけでなく、通常の科学の研究者でも使えるプラクティスだということがわかった。そもそも未知なものを解決することに有効な手段ということだ。 学び 未知の問題は複数人で協力することで効果的なことが多い。 スパイクなんかは実際やってるね。 学びを活かすアイディア・行動 まずはペアプロをして徐々に取り入れていきたい。

8.3 ペアプログラミング 8.3.1 ペアプログラミングのメリット 8.3.2 どうやってペアを組むか 8.3.3 誰とペアを組むか 8.4 バディプログラミング 8.10.1 ペアプログラミングの７つの戦略 内容 ペアプログラミングへの誤解 まず、ペアプログラミングは非常にネガティブなイメージが、開発者でもマネージャーでも先行している。しかし、それはただ単にやり方が間違っているため。 うまくやれば、１人でやるより、はるかに早く、高品質に高いレベルでタスクを完了することができる。 ペアプログラミングのメリット メンバー間の高速な知識の共有。メンバー全員がある程度コードに親しんでいる状態は、ボトルネックになりにくいためチームにとっとかなり価値が高い。 ネーミングに有効。プログラミングでは至るところでネーミングするが、名が体をなしているネーミングが超重要で、しかも他の人とも共通で読めるものでなければならない。 コーディング標準がいらなくなる。コードに一貫性が生まれ、コード自体が標準化され、コーディング標準がいらなくなる。「コードはこうあるべき」というものを定義せずとも、チーム内で運用しやすいものが生まれやすい。 新規参画メンバーの成長にも良い。経験者メンバーと１〜２週間ペアプロ（最初のうちはシャドーイング）することで、新規参画メンバーのスピードがつく。 １人でやるよりも見られている緊張感のために変なコードを書かなくなるし、お互いが監視することでしっかりとした一日を過ごす。 割り込み作業がほぼなくなる。２人で作業しているところに割って入りづらくなるため。 時間の観点でも、生産性が半分になるわけではない。約１５％増えるとされているが、高品質なコードとチーム全体がが総合的な運用コストをカバーする。 ペアプログラミングの注意点 ナビゲーター（指示する側）とドライバー（タイプする側）で分かれるが、両者の合意のもと進むことができるということをお互いが意識して、お互いが積極的に「そうやったのはなんで？こうやらないのはなぜ？」というような質問をして、それに対してしっかりと回答して、回答に対して耳を傾ける必要がある。 お互いが正直に意見を言えることが重要。 良いものは積極的に褒める。 休憩も両者のタイミングで取る。 片方が退屈しているようであれば、退屈している方は機能していないため、役割を交代してみたりする。 おすすめの方法は、テストファースト開発で、片方がテストを書き、片方がテストを通すコードを書きCleanにする。 役割の交換のタイミングは遅くて３０分。忘れそうならタイマーを使うと良い。 ペアリングの方法 ペアプログラミングが本質的に期待するところとして「それぞれ違ったものが合わさり、新しいものが生まれる」「お互いに無いところを補いあう」というような考え方がある。同じような人とペアをしても学びは少ない。その考えに乗っ取り、 性格が違う人同士（強い性格、社交的な性格の人と、内向的な静かな人など）をペアにする。 経験の豊富な人と浅い人をペアにする。教える側と教わる側という関係になることが多いが、結果的に教える側は教えながら自分も多くを学ぶことになる。 ランダムにペアする。知らなかった自分の一面が引き出され、新たな可能性が広がる。すべてのパターンでペアリングしてみよう。 その他の有効な手法 自分の考えは他人の手でコンピュータに伝えなければならないという原則に則る。これによって当人たちの頭の中の問題解決空間が共有され始め、ペアフロー状態という桁違いに生産性の高い状態に入れる。 バディプログラミング ペアリングが苦手なチームや、１人で作業したほうが効率が良いタスクの場合に有効な方法。１日の最後に、やったことのレビューをお互いで行い、質問、回答、議論を行う。ペアプロよりもエクストリームではないが、ペアプロの導入としては取り入れやすい。 進捗を追跡する ペアリングが上手くいき始めたら、その効果、生産性を計測し、マネージャーに提示することで、さらにペアリングの運用が確固たるものになる。 学び ペアプロを新人の教育の場合のみに使われることを見てきたが、ペアプロの目的はチーム全体のフロー効率を上げるためにあり、知識の共有はその１つの効果でしかない。その認識をまず持つことが重要。 ユダヤ学習方式でもペアで教え合うこと・議論しあうことをしているが、この人に教えるという行為は記憶の定着率が一番高い。（読書、プレゼン、体験、人に教える、の中で）ペアプログラミングにはそのエッセンスが入っている。 ペアプログラミングをトレーニングしたくなった。 学びを活かすアイディア・行動 現場でペアプロの実践、バディプログラミングの実践。特にバディはやりやすい。