.NETは危険な香り
「今度の開発は.NETでやることになりそうだ」
「しかも、C#.NETらしいぞ」
こんな会話がちらほらと、ようやく私の周りでも聞けるようになりました。
おぉ、ようやくオブジェクト指向を採用する気になったか！と、私には
嬉しい限りなのですが、本当に導入してしまって大丈夫なのでしょうか。
オブジェクト指向での開発はそれまでの開発プロセスとは明らかに異なる
わけですし、分析、設計、開発、テスト方法の全てが異なるのですから、導入には
慎重に検討をし、参加メンバー全員に教育もある程度行わなくてはなりません。
それなのに、検討もせず、教育のスケジュールも全く取られていないのに、
なぜ.NETを使用することだけが先に決まっていたりするのでしょう。
アーキテクチャ（言語を含む）が先にある程度決定されていることは
ままあることとはいえ、全く検討もせずにオブジェクト指向経験ゼロの
メンバーだけでその決定を下すのは危険です。
しかし、そのプロジェクトは.NETで開発する、ということだけを先決し、
走り出してしまいました。
管理者「どう？あれの調子は。」
プログラマー「いやぁ・・・難しいですね」
管理者「難しいの？UMLが難しいの？」
プログラマー「UMLもですけど・・・。色々と。」
管理者「UMLってそんなに難しいの？難しいかもしれないけど、頑張っていこうよ！」
プログラマー「はぁ・・・。」
どうやら管理者はUMLを知らないようです。先にプログラマーにUMLを勉強させて、
ドキュメントを作らせ、それをプログラマーに説明させることで自分は
UMLを習得していくつもりなのでしょう。
そんな方法でUMLは習得できません。管理者はUMLがどういうものなのかを
全く理解していないようです。理解していないのに、なぜUMLでドキュメントを
作らせるのでしょうか。
おや、オブジェクト指向設計は誰がやっているのでしょう？
誰もやっていないようでした。
プログラマーに話を聞いてみると、ユースケースを作っているとのこと。
UMLも勉強しはじめたばかりで、なんのためにユースケースを作っているのかは
わかっていないようでした。
正しく記述できているか誰も判断ができないので、
怪しいユースケースだけができあがるのは目に見えていますね。
そんなユースケースで一体何をしようというのでしょうか。
それにしてもOOA、OODをしないで（できる人がいないから）どうやって
クラス図を作るつもりなのでしょう。
話を聞いてみると、既に見積もりまで出ています。C#.NETという新しい
言語を使うので、見積もりは今までの1.3倍だとか。
・・・。
この人たちはオブジェクト指向で開発するつもりはこれっぽっちも
無いようです。今までのやり方で（ユースケースは作りますが）
ただ、新しい言語で開発するだけのようです。
せっかくクラスベースで開発できる言語を使うのに、ただ新しい言語を
使うだけの意識しかないとは！一体どういうことなんでしょう。
ここでイヤな記憶が甦りませんか？同じような事が過去ありましたよね。
それはCOBOLからVBへの移行です。
COBOL技術者がVBへの移行をした時、SQLもろくに勉強せず、
COBOL時代の設計方法をそのまま使用し、VBの方が開発スピードは
断然速いからなんとかなるはず、というおかしな見積もりのために
結果デスマーチになってしまったプロジェクトに巻き込まれた人も
少なくないと思います。
そうなんです、今回のこの管理者とプログラマーの会社はまさに
COBOLからVBへの移行を行った会社でした。
そして今度はVBからC#.NETへ同じやり方で移行しようとしているのです。
管理者が、今までVBをやってきているのだから、.NETなんてちょっと勉強
すればなんとかなるだろう、最初時間が少しかかるかもしれないが、
慣れたら.NETの方が開発は速いらしいし・・・という甘い認識で
.NETを採用するなんて言語道断です。いや、オブジェクト指向を一切取り入れないので
あればその甘い認識はある程度正しいでしょう。
しかし、どうなんでしょう？オブジェクト指向をまったく取り入れないで.NETを
使用して開発しても、プログラマーレベルではオブジェクト指向を全く知らないで
済むわけではありません。
それでも、必要な技術だけその都度調べ、オブジェクト指向についてはあまり
わからないままなんとかリリースまでたどり着くことは可能でしょう。
私はJavaで仕事をしたことはないのですが、「オブジェクト脳の作り方」
によると、Javaの開発ですら、ちゃんとオブジェクト指向設計をした上での
開発はほとんど見られないとか。
という不幸にも間違ってしまった認識を、今度は
「.NETで開発すればオブジェクト指向なのさ！」
と、同じことになりつつあるということなのですね。
