疲弊する開発者

前回([id:rabbit2go:20080601:1212326562)に続き、ソフトウェア品質改善委員会に参加。隣の事業部がやっているから、という安直な理由で設置された委員会だが、経験者が揃っているのであーだこーだと議論は盛り上がる。しかし、自分がコードを書いていて時代の技術しか知らず、今の現場で起こっている問題を正しく把握できていなかったりするので、ひたすら空虚な主張が続く。曰く、

• 設計書のレビューはきちんと行うべきである。
• ソースコードのレビューはきちんと行うべきである。
• 割り込み作業が入って場合、工程の見直しを行うべきである。
• 仕様変更は関係者の事前合意を得るべきである。
• 進捗確認はきちんと行うべきである。

そんなことを実践できるのなら、もうやっている。組織の開発体制として、そのような作業が出来ない（許されない）やり方を続けているから、問題が山積み状態になってしまうのだ。そもそも、この人たちが自分の組織を戻ると、ろくなレビューも行わずに開発を進め、割り込み作業が発生しても残業時間を延長し、連絡が不十分なまま勝手に仕様を変えたりするから始末に負えない。ある程度の経験を積んだベテランこそ自らの意識改革を行うべきだが、会議で偉そうなことを言うリーダーに限って自分では何もやらなかったりする。

改善すべき点が多いのは事実だが、それならまずは自分の作業から実践すべきなのだ。業務命令の名の下、あれやれ、これやれと言われ続けて、開発の現場は疲弊状態にある。このような開発者に、さらに課題を与えても対応できるわけがない。開発プロセスの改善を計るという委員会の名目は結構だが、疲れ切った開発者ばかりという現実を直視すべきだろう。現場の開発者たちは、改善委員会を冷ややかな視線で見ているのだ。

「ソフトウエア開発者はみな，プロセスの話題が嫌いなはずだ。重いプロセスでは，開発者が押しつぶされてしまうことがある。もうプロセスの話題はたくさんだ」

「もうプロセスの話題はたくさんだ」，UMLの父，Ivar Jacobson氏が語る - 組み込み開発 - Tech-On!