ある nakagami の日記

自分の一番最初の仕事は、プログラマー一人、お客さんが企画＆要件定義＆営業合わせて二人の小規模プロジェクトだった。
最初の発注が３ヶ月くらいの予定の CAD の図面から穴図形の座標を取得して、順番にドリルで穴を開ける Gコードを出力するものだった。
それが終わったら僕の仕事は終わりかと思っていたのだが、機能追加・変更と、その間の不具合修正で結局３年間そのプロジェクトをやることになった。

世の中には、新規開発と運用と追加開発のフェーズを分けて、全く別の部署の別の人間がやる体制になっているところも多いと思う。

機能追加されそうだからと準備しておいた拡張性は大体は必要になることなく邪魔になるし、思わぬところが機能追加になって、既存の処理を整理する必要にかられたり（それによって以前作った機能に不具合が生じたり）いろいろ大変だった。
不具合を適当に誤魔化そうとしても、結局それは自分が将来尻拭いをしなくてはいけなくなるということも経験した。
そのプロジェクトで、できるだけその時点でシンプルになるように実装して、必要があったら書き直すのが一番いいなって学習した。

あの時、自分が作ったものの面倒を長く見ることになったことは、僕の後のキャリアを考えると非常にラッキーだったと思う。
大変だったけど、今にも通じる良い経験だった。
考えてみると、あれ以降も新規に書き起こした後で運用時点での機能拡張しながらの不具合修正って仕事をすることが多かった。
まあ、それは大きな組織で働いてないという裏返しでもあるんだけど。

もし、仕事では新規開発から不具合修正、機能追加を一貫して行える環境にない人は、 OSS を書いて、広く一般からフィードバックを受けて、「これは直す不具合」「これは新規機能開発」って長くプロジェクトを継続してみるといいと思う。