1つの作業は小さくする

1つの操作、1回の作業は小さな単位で行い、素早く確認することで、大きな問題に発展させないようにする。

• キーをタイプし始める時、1文字だけ打って IME の状態を確認する
  • ひたすら入力してしまってから「IME がオフだった」みたいなミスをなくす
• 実装していく時は、ライブリロード機能などを利用して、保存するごとに対象コードの実行結果が確認できるようにする
  • 全体を書き上げるまで動作検証しないでいると、問題があった時に原因の箇所を探しづらくなる
  • 書いている最中に、中間成果物 (ワーク変数の値など) が想定どおりになっていないことが分かれば、その場で修正できる
• コードをリファクタリングする時は、1行ずつ修正し、修正する度に元と同じ結果が得られているか確認する
  • 一気に書き換えてしまってからバグに遭遇すると、どこのコードのせいでバグっているか検証しづらい
• 定型作業を自動化するシェルスクリプト・バッチファイルを作ったが、数百行に及ぶ大掛かりなコードになってしまった
  • 1つの処理ごとにスクリプトファイルを分けておき、順番に手動実行するか、順に実行する大本のスクリプトファイルを別で用意しておく
  • このようにして中間成果物を検証できるようにしておくと、問題があった時に原因箇所を特定しやすい

もう少し大きな単位で「1つの作業」を捉えても良い。

• 上長からある作業を任されたが、内容に不明瞭な点が多い場合
• × : 「分からないところは後でまとめて聞こう」と考えて、自分なりに全て作り上げてから上長に提出する
  • もし認識が大きく違った場合は、全ての作業時間が無駄になる
• ○ : 全体の1割分程度が作成できたところで、資料を見せて方針を確認する
  • もし認識が大きく違って、全て作り直しになったとしても、手戻りは「1割分の作業時間」で済む
  • 大きなズレはないものの、実際の成果物を見たことで上長の気付きが得られ、今後の方針に関するアドバイスがもらえる

タスクのブレイクダウンも、「漠然と大きなタスク」としてではなく、できるだけ小さな単位に分割しておくと、一つひとつは機械的にこなせるタスクと捉えられるようになる。「仕事」を「(単純) 作業」と見なせるぐらいに分割すると、余計なことを考えず作業に集中できる。

• 「○○システムの開発プロジェクト」として捉えると大きくても、「○○画面の設計」「○○バッチ処理の実装」と分割していけば、必要な前情報も、やるべき作業もすんなり見えてくる

確認するタイミングを早めに設け、問題を小さな段階で見つけるために、一つひとつの作業は小さくしておく。