開発マッチポンプ

隣で開発作業を行っているチームの様子を見ていると、自ら問題の種を蒔いて仕事しているような気がしてならない。「不具合が見つかって初めて仕様が分かる」というお粗末な後付けの開発姿勢なのだ。

• △□という仕様が不足していると分かったので追加対応します。
• ▽◇という仕様にミスが合ったので対応します。
• ○×という障害が見つかったので対処します。

問題が発生した後で対処するのは確かに大切な事かも知れないけれど、開発者なのだからそもそも問題が発生しないように考えるのが仕事なのではないだろうか？仕様を決める時点で、不足やミスを全て発見しておくには何をすべきか？障害の発生件数を予測範囲内に抑え込むには何をすべきか？そんな考え方を念頭において開発業務を進めるのであれば、やるべき仕事は明らかなような気がする。

もちろん、新規開発や新技術導入などリスクが高い開発案件は有るけれど、発生し得るリスクをどう抑え込むかが技術者の腕の見せ所だろう。あらゆる可能性を考慮し、様々な角度から事前分析を行っておけば、実際に発生する障害なんてたかが知れているし、開発プロセス全体を制御して、納期通りにソフトウェアをリリースすることは全然難しいことではない。予定に従って期待通りの品質で出来上がるからこそ、エンジニアリングと言えるのだろう。

実際に火事が発生してから防火対策を考えても手遅れだ。火災の発生を防ぐためには何が必要なのか、火災を初期の段階で消し止めるにはどうしたら良いのか、事前に考えて対策しておくからこそ意味があるのだ。ソフトウェア開発も同様だと思う。