にならないために
新しいシステムの開発方法や新技術に対する恐怖って必ずあると思うんですが、これがある程度の人数で開発したりすると人数的にフォローしきれなかったりするわけです。
このフォロー（メンタル的フォローと技術的フォローと人的フォロー）を、どうにかしてあげないと、新技術や新開発方法は机上の空論になったりするわけです。すばらしいことも、結果、実現できない。
で、その原因は新技術＆新開発方法のせいだとなって、言い出した人に跳ね返ってくる。つまり、机上の空論だと。
作業を実際にする人たちに、技術的なフォローや人的フォローをできないことには、メンタル的ストレスが溜まっていく。メンタル的なストレスが溜まることによって、プロジェクトのメンバーが疲弊してプロジェクトも失敗するという悪循環になる。
この悪循環（負のスパイラル）を断ち切るために、なにができるかということをここで考えます。
たとえば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での開発ですすめて、設計段階ぐらいで抜けてしまうのが、角もたたないのでいいのかもしれないですね。従来方法で開発するので、技術的フォローも不要ですし丸くおさまりますね。
クライアントの単体テスト
VB.net,C#.net,Delphi.netなんかで、サーバと通信して結果によって画面編集するようなものに対する、単体テストのフレームワーク（ソフトウェアではなくて方法）を考えています。AOPでサーバのサービスからデータを取ってくる命令を書いて、テストすれば単体に関してはOKなんでしょうね。実際にサーバとの通信をする必要もないし。
で、画面内結合試験とかで実際のサーバのサービスと結合するような形ですね。単体が済んでいれば、結合もさっさと終わるでしょう。で、DBを戻して画面間結合試験って感じですね。分業もできるし万々歳ですね。
ちゃんとした手順を来週にでも合間で考えてみようと思います。S2DAOを見ていて思いました。というわけでdosankoにも期待
■
基幹系システムを構築するに当たって、業務の基盤として会計システムを置くことは多いと思います。これは、企業活動は、会計取引であるということ、さらに、どの企業も必ずしなければならないということで、システムの中央におくわけですが、最近これに追加して、人と人のコミュニケーションを中央に置くという考え方もアリかなと思っているわけです。PRMって感じかもしれない。Person Relationship Managementのような考え方。CRMと似せて考えているんですが、人（契約関係のある組織とかも含みます）との対話の記録をとっていくような感じですね。ちょっと、まだ、具体的になってないのですが、お客さんに見積もりを出したりする際に、新規顧客の場合、顧客の情報を登録して、顧客に対して見積もり作成して、顧客に対して見積書を出します。その案件を受注したら、経理部門に対して売上伝票を出したり、物流部門に対して配送の手配をしたりします。なんかワークフローみたいな感じになってます。自分に対して自分でTODOを割り振る場合、自分が作業を割り振ったという実績と、自分に作業が割り振られたという実績が残るような感じになります。うーん。やっぱり、これってグループウエアか・・
