昔は.NETが好きではありませんでした -私の技術変遷-
●はじめに
私が言語を学び始めたのは大学で、そのとき学んだのはBASICやCや機械語でした。
Javaが出てきたときに興味があったので勉強しましたが、どこでも動く言語でポインターがなく、動作が遅いというくらいで、オブジェクト指向についてはわかりませんでした。
C#があるということは知っていましたが、Javaに似ているというくらいの知識でした。
会社に入って仕事ではまずC++やJavaを使いました。オブジェクト指向についてはJavaで学び、経験を積みましたが、C#でも良かったと思います。そのころC#は食わず嫌いでした。
●IDEの優位性
Javaを学び始めたときには開発環境が貧しく、テキストエディターで編集し、コマンドラインでコンパイルして実行していました。Eclipseが出てきて、ものすごい進歩だと思いました。
実はVisualStudioは前から便利だったんですね。以前は、ただで手に入る開発環境があるのに、VisualStudioという開発環境にお金をかけるのはもったいないと思っていました。
業務用にアプリケーションを作るとき、GUIでボタンなどの部品をペタペタはりつけてWYSIWYG（What You See Is What You Get：見た目のまま編集できる）で開発できるのは楽だし、完成形のイメージがしやすいし、自動生成できるような余計なコードを書かなくていいので便利だということがわかりました。
●自動生成コードの隠蔽
自動生成されたコードは普段は見たくありません。C#は言語を拡張してクラスの定義を複数ファイルに分けて書ける（Partialクラスの開発）ようにし、自動生成コードを分離・隠ぺいしました。これはめちゃくちゃ便利です（ジェネレーションギャップパターンも必要なし）。
●作業の自動化と省力化
VisualStudioを使ってみると、開発者が面倒に思っていたことを、バージョンアップのたびにどんどんサポートしてくれるようになっています。プロパティ設定やWYSISYG編集、Winフォームと同様の考えでWebアプリができるASP.NETの開発、自動生成コードの隠ぺいや機能追加を別ファイルに記載するPartialクラス、LINQやEntityフレームワーク、マスターメンテナンスアプリならあっという間にできるASP.NET Dynamic Data……。
これならお金をかける価値はあります。ただ、学生のころにはアプリケーションの完成形をイメージしながら開発する必要がなかったし、GUIアプリを作る必要がなかった（コマンドラインで良かった）ので、開発環境が無料というのが大事でした。
●ライセンス料金
大学時代から10年以上経過した今でも、教育の場ではCやJavaしか教えないそうです（教育をやっている講師に聞きました）。
言語的にはJavaでもC#でもいいと思います。開発環境は、VisualStudioの無料版が出ている今では、VisualStudioがいいでしょう。特に画面が大事なアプリの場合は。
さらに学生向けにはProfessionalEditionが無料になっています。これは.NETの裾野を広げようという戦略でしょうが、数年後には狙い通りになると思います。遅すぎたくらいだと思います。
●現状の環境を変えるメリット
今VisualStudioを使っていない人は、「今うまくいってるのに、無料だからといってVisualStudioを使う必要はない」と思うでしょう。ですが、無料の開発環境でこんなにすごいアプリが簡単にできちゃう！ とか、WPFアプリ作成やASP.NETアプリ作成で得たスキルがSilverlightアプリ作成でもかなり利用できる！ とかいうことがわかりやすくカタログ化されてくれば、かなり利用者が増えてくると思います。
ロジックだけを書くのはどんな言語を使っても同じです。仕様通りに決められたロジックを実装するのは単価の安い仕事になっています。あとは開発環境やミドルウェア、フレームワーク、ライブラリーの充実、GUI開発環境のしやすさ、それらすべての連携です。
実際にJavaでも.NETでも設計・開発しましたし、開発環境も特にJavaではいろいろと利用し、フレームワークも山ほど使いましたが、選択肢がありすぎると相性を考えたり、相互接続性を確認したりとかなり面倒でコストがかかります。これはTVとハードディスクレコーダーを同じメーカーでそろえると、何も考えずに連携できることと似ている気がします。Javaのアプリケーションサーバはいろいろな会社が扱っていますが、.NETのアプリケーションサーバはMicrosoftしか扱っていないため、本来の目的と関係ない余計なことを考えなくていいのが楽です（選択肢がないことを嫌う人もいます）。
●再利用可能なスキルと再利用可能なシステム
すでに企業のシステムの多くがJavaをベースにできているため、Javaのスキルは必要でしょうが、フレームワークはまちまちで、今のスキルが他のJavaを扱う会社で通用するという保証はまったくありません。逆に.NETスキルはどこでも通用しますが、企業の根幹にJavaのシステムがある限り、Javaとの相互接続性を保証しないと単なるリッチクライアントの枠組みを出られません。
そこへ、言語によらない相互接続の規格として、昔はCORBAから今はSOA（WSなにがし）が出てきています。私はCORBAでの開発経験もありますが、サポートする製品が少ないのが弱みでした。今のSOAにも同じにおいがします。Javaのアプリケーションサーバがあまり対応していません（特にトランザクションのあたり）。逆に.NETフレームワークはWCFやWFなどで積極的に対応しています。やはり相互接続性を重視しているところが伺えます。Java系のアプリサーバがWS-Transactionに対応してくるまでは、.NETとはBizTalkのアダプタで接続するのがよさそうです。
ちょうど仕事でWCFやWFを利用したために、これらのフレームワークがかなり考えられていてJava系より数歩先を行っているのがわかりました (Javaは次の次のバージョンにもWSなにがしの対応がされるか決まっていません）。WCFは昔の.NET資産はそのまま接続できるように考えつつ、 WSなにがしの規格にも対応するようになっていて、新規システムに導入する際のハードルを下げています。
●システム同士の接続
システム開発案件では、既存のシステムに引っ張られて様々な制約がかかります（理想的にはやりたいことが、現実的にはできない……）。これはシステムの結びつきが強すぎるせいですので、せめてこれから作るものくらいは（現在事実上の）標準規格のWSなにがしなどに合わせておくのが望ましいと思います。
（プロマネ支援などもやりながら）システムやフレームワークの設計・開発をしていく中で、規模が大きくなるほど本来のシステムの目的と別な、ミドルウェアの選定やら相性やら開発環境の選定やら開発者の確保やら、もろもろに取られるコストが増えていきます。「なにも制約がなければ、面倒なことは考えず、VisualStudioで楽に作ってしまった方がいいな！」と考えるようになりました。
●今では……
今では.NETが結構好きです。特に気に入っているのはASP.NET Dynamic DataとSilverlightです。両方仕事で使っています。SOAを考えるとWCFも必須です。