開発者のリセット症候群

ソフトウェア開発の現場でよく聞く言葉の一つに、今の問題を一旦棚上げして、最初からやり直そうというものがある。ややこしいソースコードや問題を相手にしていると、その解決方法の一つとしてやり直しを考えるらしい。例えば、こんなものだ。

  • 度重なる修正で見通しの悪くなったソースコードを捨てて、一から作り直す。
  • 問題山積みのプロセス改善に嫌気が差して、一旦全ての問題をリセットする。
  • 行き詰まった議論を解決するために、決定事項を白紙に戻して再検討する。

リセットしたくなる気持ちはよく分かるけれど、仮にリセットしたところで抱えている問題は変わらないし、同じ人間が同じような思考で取り組む限り、いずれまた同じ状況に陥ることは明らかだろう。問題の根本が変わらないのだから、取り組み方を変えようがリセットしようが、本質的な問題は何一つ解決していないのだ。

組織の中で仕事を進めていると、例えば、組織が変わるとか、その管理体制が変わるとか、問題を取り巻く周辺はいろいろ変化するものの、本質的に存在する問題そのものは変わることがない。だから担当者が変わろうが、人が入れ替わろうが、部門の方針が少しくらい変化しようが、継続的で地道な取り組みが不可欠となる。目の前の問題を直視せず、そこから逃げようとする限り、問題は一向に解決できないだろう。

最初から取り組み直せば、新しい体制で取り組めば、年度が変わって心機一転頑張れば、次回こそ上手く出来るはず、という思い込みは、銀の弾丸を追い続ける姿勢にどこか似ているような気がしている。

クラッチから始めるときに覚えておかなければならない重要な点は、あなたが最初にやったときよりもいい仕事ができるだろうと信ずべき理由は全くないということだ。第一に、あなたはバージョン1.0のときに作業したのと同じプログラミングチームを持っているわけではなく、「より経験を積んでいる」わけではないということ。あなたのチームは昔やった間違いの多くを再び繰り返し、最初のバージョンにはなかった新しい問題を持ち込むことだろう。

Joel on Software

Joel on Software



関連