にならないために - みぞやんの日記

新しいシステムの開発方法や新技術に対する恐怖って必ずあると思うんですが、これがある程度の人数で開発したりすると人数的にフォローしきれなかったりするわけです。
このフォロー（メンタル的フォローと技術的フォローと人的フォロー）を、どうにかしてあげないと、新技術や新開発方法は机上の空論になったりするわけです。すばらしいことも、結果、実現できない。
で、その原因は新技術＆新開発方法のせいだとなって、言い出した人に跳ね返ってくる。つまり、机上の空論だと。
作業を実際にする人たちに、技術的なフォローや人的フォローをできないことには、メンタル的ストレスが溜まっていく。メンタル的なストレスが溜まることによって、プロジェクトのメンバーが疲弊してプロジェクトも失敗するという悪循環になる。
この悪循環（負のスパイラル）を断ち切るために、なにができるかということをここで考えます。

たとえばCOBOLで作られた現行ホストシステムをJavaでレガシーマイグレーションをしてもらうとします。
この場合、ホスト環境からオープン環境という環境の変化（ユーザーインタフェースの変化、アンチRDB→RDBの使用）すなわち実現方式の変更（ほかにもあるかも）があります。
言語の変化（プロシージャ的な機能分割から関数的分割への変化／モジュール単位の概念）によるモジュールの分割方法の変更があります。
これだけでも、かなり大きな変更、メンタル的ストレスだったりします。
これに対して、無防備に従来と同じ開発方法をとるということで、プロジェクトメンバーへの技術的なフォローは少なくなります。人的フォローさえしていれば、現行システムとおなじシステム機能をもった新システムができることでしょう。
ただし、システムは完成して終わりではなくて、運用して次システムへの移行でライフサイクルを終えます。システムで元をとるには、効果のあるシステムで、システムの使用期間による効率のアップの累積が開発にかかる費用と運用の費用を比較して評価することになります。したがって、システムの評価を上げるためには、コストを下げるか、効果をあげるかしか対応方法はありません。現行システムの運用コストが、システムエントロピーで上がってきたのを下げるといった意味で新システムを組んだ場合、COBOLをJavaに単純に変えるといった事で得られる効果は、ざっと考えて、ソースのクリーンナップとドキュメントの最新化くらいしか考え付かないですね。それでも効果のある会社は絶対あると思うのですが、やりたい仕事ではないですね。運用コストも現行よりは下がる事でしょう。
SOAのようにサーブレットやWEBサービスでサーバサイド処理をしてクライアントに結果を返す処理形態は、ホストで開発していた人たちは向いていると思います。RBDに向いていなかったものをRDBで実現することに関しては、考え方を変えなければならないので、ここら辺については、過去のはぶさんの日記とかで見てください。
次にVBをやっていた人たちがVB.netに変更するケースを考えます。
VBをしていた人たちすべてではありませんが、ボタンクリックのイベントに処理内容を記述しているソースを見かけました。同じ機能を持ったボタンのイベントはフォームをまたぐとコピペです。このような人たちは、COBOLの人たちより、ある意味始末に悪いと思います。COBOLの人たちは、ある意味MVCを分割する考え方は持っています。本人たちは、意識していないかもしれませんが、モジュールの開発単位が明確に分かれています。一方でVBの人たちは、RDB文化でしょうから、正しい間違っているは別として、ある程度正規化されたデータモデルを好むかもしれません。いろいろな、M$系の雑誌ではデータ中心でって特集を年に何度かしています。
この人たちには、モジュールをわける方法を伝授することで技術的なストレスはだいぶ下がる事でしょう。
最後にCOBOLerの人たちです。ここで言うCOBOLerは、COBOL開発者を指していません。長期間開発プロジェクトをこなしてきた人たちで、徹夜でがんばったことが自慢だったりするような人たちです。量を上げるための措置は人的投入で、作業方法の変更ではないような人たちです。COBOLerの人たちは、作業方法の変更をしていると自分では思っていたりしますが、COBOLerの人たちがいっているのは、プロセスステップ内の原子的な作業の効率化だったりします。ミクロ的な最適化をしてマクロ的な最適化はできていないということです。こういう人たちは、頭ごなしに新しい開発方法や開発言語を否定しますので、さっさとプロジェクトを抜けましょう。官僚的な仕組みなど悪い点もありますが見習う点もありますので、それぐらいは勉強してもいいと思います。管理しなければならない人は、新しいことをするとそれは自分に返ってきますので、従来どおりのCOBOLでの開発ですすめて、設計段階ぐらいで抜けてしまうのが、角もたたないのでいいのかもしれないですね。従来方法で開発するので、技術的フォローも不要ですし丸くおさまりますね。