小さな修正を頼むときの、ちょうどよい粒度

• 1回で頼むのは、1つの変更まで
• 確認できる単位で区切る
• 戻せる大きさに保つ

修正を頼む範囲を、どれくらいにするか迷っていた。いまの基準を書く。

大きく頼んで困った点

まとめて頼むと、後で困った。

• 複数の箇所が同時に変わる
• どこが原因で壊れたか分からない
• 戻すと、直った部分も戻る

3つ目が面倒だ。直った部分と壊れた部分が混ざる。

小さすぎても困る

逆に、細かく分けすぎても進まない。

• やりとりの回数が増える
• 前の文脈を毎回渡すことになる
• 全体の流れが見えなくなる

2つ目が手間だ。文脈を渡し直す時間のほうが長くなる。

いまの基準

いまは、この基準で区切っている。

• 動作を確認できる単位
• 戻すときに、1手で戻せる範囲
• 説明が2〜3行で済む変更

1つ目が中心だ。確認できなければ、合っているか分からない。

確認できる単位とは

具体的には、こういう区切りになる。

• 画面の表示が変わる
• 処理の結果が変わる
• 目で見て、前後の違いが分かる

3つ目が条件だ。見て分からない変更は、確認できない。

分けた例

実際に分けた例を挙げる。

• 一覧の表示を変える — 1回目
• 並び順を変える — 2回目
• 件数の上限を付ける — 3回目

以前はこれを1回で頼んでいた。分けると、どこで壊れたか分かる。

まとめてよい場合

逆に、まとめてよい場合もある。

• 機械的な置き換え
• 名前の変更
• 書式を整えるだけの変更

どれも判断が入らず、間違っていればすぐ分かる。

範囲を指定する

頼むときに、触る範囲も書いている。

• どのファイルを触るか
• どの関数を触るか
• 触らない箇所を明示する

3つ目が効く。変える場所より、変えない場所を書くほうが守られる。

確認の手順を決める

1回ごとの確認も、手順を決めてある。

• 変わった箇所を見る
• 関係しそうな箇所も見る
• 問題なければ、記録して次に進む

2つ目を忘れやすい。変えた箇所の外に影響が出ることがある。

記録を残す

1回ごとに、何をしたか書いている。

• 変更の内容を1行
• 確認した結果
• 次にやること

3つ目を書くと、中断しても再開できる。

進まないと感じたとき

細かく進めると、遅く感じることがある。

• 1回あたりは小さい
• ただし、戻る回数が減る
• 結果として、全体では速い

3つ目が実感だ。まとめて頼んで戻した回数を思い出すと、分けたほうが速い。

粒度を間違えたとき

途中で大きすぎると気づくこともある。

• 説明が長くなってきたら、分ける合図
• 確認する箇所が増えたら、大きすぎる
• その場で止めて、分け直す

1つ目が目安になる。指示が長くなるのは、複数のことを頼んでいる証拠。

頼む順番も考える

複数の修正があるとき、順番も決めている。

• 土台になる部分から直す
• 見た目の調整は、最後にする
• 後ろの修正が、前の修正を壊さない順にする

2つ目が効率的だ。先に見た目を整えても、土台を変えると作り直しになる。

やりとりを短く保つ

1つの話題でのやりとりも、長くしないようにした。

• 5往復を超えたら、いったん区切る
• いまの状態を書き出して、新しく始める
• 長いやりとりは、前提がずれていく

3つ目が理由だ。途中の変更が積み重なると、何が有効か分からなくなる。

前後を記録する

修正の前後も残している。

• 変更前のファイルを複製する
• どこを変えたか、差分を見る
• 意図していない変更が無いか確認する

3つ目を必ずやる。頼んでいない箇所が変わっていることがある。

粒度を決めてからの変化

基準を決めてから、作業の感覚が変わった。

• どこまで頼むか、迷わなくなった
• 壊れたときに、原因を探す時間が減った
• 全体として、やり直しが減った

2つ目が大きい。直前の1つを戻せば元に戻るので、原因を探す必要がない。

まとめ

• 1回で頼むのは、動作を確認できる単位まで
• 細かすぎると、文脈を渡す手間が増える
• 機械的な置き換えは、まとめてよい
• 変えない場所を明示すると守られる
• 指示が長くなったら、分ける合図