まずは箇条書きより始めよ

昔、ソフトウェア開発のベテランの方に質問したことがある。

「どうしたら優れた開発者になれるのでしょうか？」

予想していた回答は「この本を読め」とか「あれを学べ」と言ったものだったのだけど、実際の回答は全然違っていた。

「自分の作業を箇条書きで表現出来るようになることだ」

これだけでは腑に落ちないので、その理由を聞いてみたところ、こんな説明が返ってきた。自分がやるべき範囲がどこまでなのか、何が必須項目の作業であり、何が見送り可能な項目なのか、作業に必要なものは何なのか等々を全て考えば、簡潔に箇条書きで表現できるはずだ。箇条書きで表現できないのなら、それは自分がやるべき事を自分自身で分かっていないことの証拠に他ならない。開発者は実際の作業の中でアレコレと疑問を持つはずなのに、それを確認しないまま勝手に作業を進めてしまい、後で予期せぬ問題を引き起こすことが多い。本当の開発者なら、その確認、検証、合意を得ることを厭わないし、その確認が済んでいるのなら芋づる式に追加作業が発生することもあり得ない。

なるほど、そんなものなのかと思いつつ、それ以来、仕事の項目は箇条書きで表現するように心がけている。確かに周囲の開発者に対して「あなたのやるべき作業は何なのか？」と聞いてみても、「あれと、これと、えーと、これも必要なのかな？」と心許ない返事が返ってくることが珍しくなく、自分の抱えている作業を「これだけです」とリストで明確に示せる人は実はあまり多く無い。こんな事例を何度も見ていると「箇条書きで表現出来ること」という尺度はそれなりに正しいと思えてくる。

WBSやチケット駆動開発のチケットも本質は似たようなものであって、箇条書きで表現した項目の単なる動的管理に過ぎず、もし作業項目をチケットの形で表現できないのなら、それはそもそもやるべき事が分かっていない証拠なのだろうと思う。だから、チケット駆動開発にスムーズに取り組める人は、自分自身の仕事の管理を以前から上手く出来ているようだ。

なお、単に箇条書きと言ってもその具体的な方法論は色々だけど、今のところ下記の基本ルールを守るようにしている。こんな整理方法を意識して仕事の項目を管理するようにすれば、少なくとも大きな漏れが生じるとか、やるべき事を忘れていたと言ったつまらないミスは防げるように思っている。

やるべき項目を全てもれなくピックアップすること。
納期やリソース配分に応じて、作業の優先順位を付けること。
作業項目の確認や優先順位付けは、頻繁に見直すこと。
追加作業が必要になった場合、その原因は誰（何）に有るのか理由を明確にして、優先順位付けの参考にすること。（自分の側に落ち度があるのなら、それなりに頑張る必要はある）