当社のシステムは、PHPで書かれています。
PHPは、バージョン５以降、革新的な進化を遂げ、オブジェクト指向やテンプレートシステムに始まり、フレームワークによる開発が始まりました。
この時期に多くのシステムが、革新についていけず、また、いったりいかなかったりで合いの子のようなシステムができたりと混乱があったのだと予想します。
当社も、設計者の私が、ついていけずに、また、技術責任者のリーダーシップがなく、また、アジャイル開発の全盛期でとにかく書くという時期だったため、とても滑稽なシステムになってしまったような気がします。
設計が一番大事、つまり設計者の人事が一番大事ということは、前回も散々話しましたが、現場を仕切る設計者やディレクターが、オブジェクト指向を知らない、フレームワークを知らないということが多々あったかと思います。それにより、フレームワークの開発環境により開発を進められているにも関わらず、違うディレクトリには、ベタベタと一から書かれたソースがあったりとディレクトリ構成がとても複雑なシステムになっていることが多々あったに違いないと思われます。
そうです、システムは、できればOK、お客様は中身なんか知りませんということで、多くのシステムがつぎはぎだらけのものになっていたのではないだろうかと予想されます。
私も、当初は、フレームワークやオフジェクト指向を知らず、ベタベタな開発しか経験をしておらず多くのPGをベタベタなコーディングを放置していたり、フレームワークを強制し、フレームワークで開発したシステムを破壊させてしまったりと、ハチャメチャなディレクションをしてしまった記憶が後悔先に立たずといった気持ちと共に蘇ってきます。
オープン系の進化は、めまぐるしく、著しく、日進月歩です。
流行りものがよいということではなく、開発者たちが、しっかり打ち合わせをし、吟味したうえでどのような開発を進めるかということの重要さを今一度再確認をしたほしいと思います。それぞれがバラバラに自由に開発をすすめることは、スピードにとっては、また、一朝一夕につくって使わなくなるシステムに関しては、それでよいかもしれませんが、業務用システムのように、末永く使用するようなものに関しては、メンテナンスということ、セキュリティということを検討しなければいけません。
誰が引き継いでもメンテナンスができる
オペレーションレベルで設定や修正ができる
監視ツール・報告ツールが２４時間稼働し、報告をしてくれる
ような素人でも、何がどう動いているか、正常か？問題か？を把握できるようなシステムでなければ、システムが２次被害を生むようなことになり、設備投資の意味がマイナスになり本末転倒になりかねない。それは、できればよい、金をすぐにもらいたいというPGたちの怠慢であり、設計者たちの勉強不足による産物であることは間違いない。
それからのメンテナンスは、さんざんだということは言うまでもない。つづく。
