mvcConf @:Japan パネル・ディスカッション 人気のASP.NET MVCエキスパートが語るMVCの魅力と実践 デジタルアドバンテージ　一色 政彦 2011/06/29

Page1 Page2 Page3

　2011年6月11日（土）、＠IT .NET 開発者中心とMicrosoft Tech Fieldersのコラボレーションによるオフライン・セミナー「mvcConf @:Japan 〜 ASP.NET MVC ブートキャンプ 〜」が、品川グランドセントラルタワーで開催された。そもそもmvcConfとは、（主に英語圏の）ASP.NET MVC開発者で人気のオンライン・カンファレンスの名称であり、今回開催されたオフライン・セミナーはこのmvcConfの日本版（@:Japan）という位置付けである。

　当日は、雨だったにもかかわらず、会場は午前中から満席で、大いに盛り上がった。

mvcConf @:Japan会場の様子

　mvcConf @:Japanでは、ASP.NET MVCに詳しいMicrosoft MVP（Most Valuable Professional） for ASP.NET／Windows Azureの5名が順にセッションのスピーカーを務め、その全員が最終セッションであるパネル・ディスカッションに参加した。その5名は、下記のとおりだ。

【パネリスト】

• 長田 直樹 氏（株式会社シーエスアイ）
• 芝村 達郎 氏
• 竹原 貴司 氏
• 小野 修司 氏（あおい情報システム株式会社）
• 勇 大地 氏（株式会社野村総合研究所）

【モデレーター】

• 一色 政彦（＠IT Insider.NET編集長）

　本稿では、下記の3テーマで議論された、このパネル・ディスカッションのほぼ全内容をお伝えする。以降、ASP.NET Webフォームは単に「Webフォーム」と、ASP.NET MVCは「MVC」と略す。以下、敬称略。

1. Webフォームではなく、ASP.NET MVCを採用する理由
2. ASP.NET MVCと組み合わせる周辺技術の選択指針
3. ASP.NET MVCへのスキル移行

■

■1. Webフォームではなく、ASP.NET MVCを採用する理由

――ASP.NET MVC開発に取り組み始めたきっかけは何でしょうか？

小野　わたしの場合は、最初のMVCバージョン1のころから、セミナー・セッションのテーマとして話したりしています。技術的な興味から調査を始めて、いまは仕事でも実用しており、顧客に提供するWebシステムを開発しています。特に、Webフォームよりもチーム開発しやすいと感じたのが、MVC採用の決め手でした。「チーム開発のしやすさ」というのは、プログラムの書き方のパターンを決めておくことで、メンバーが同じ形式でプログラムを記述できる、という点にあります。

　また、弊社にはWebデザイナーがいまして、開発に先行してWebデザインを作成してもらいました。プログラマーはデータベースまわりのモデルなどを設計・開発して、Webデザインの完成に合わせて後から動的な部分を作り込んでいく、という手法を取ることができました。MVCの良いところは、このようにWebデザイナーの制作物やお客様の要望に合わせてビューを柔軟に作成するという開発スタイルが採用できることです。

長田　わたしも技術的な興味から入りました。スコット・ガスリー（通称：ScottGu）氏のブログを（MVC登場前の）Ajax＋Webフォームの時代から購読していて、そこでMVCのCTP（コミュニティ技術プレビュー）が紹介されたのがきっかけです。とはいっても最初は、MVCの開発がWebフォームのそれとあまりに異なるので、敬遠していました。しかしURLルーティングやテスト面の便利さを知ると興味が湧いてきました。そんなときに、竹原さんがMVCの情報を積極的に発信しているのを見て、「これは面白い」と完全にMVC派になりました。

――竹原さんは、なぜASP.NET MVCを採用したいと思ったのでしょうか？

竹原　MVCを採用したかったのではなく、Webフォームの開発スタイルに絶望していたからです。あとは、わたしもスコット・ガスリー氏のブログの影響が大きいです。

――Webフォームに絶望したのは、なぜでしょうか？

竹原　出力されるコードに対する主導権がマイクロソフトにあり、デベロッパーにはないからです。悪いというわけではないですが、Webフォームに対しては「サーバ・コントロールがビューに関与する」ことを好ましく感じていませんでした。

――業務系Webシステムであれば、サーバ・コントロールの方が手軽に作れるのではないでしょうか？

竹原　はい。そのとおりです。

　ですがわたしは、そういった「業務システム開発に最適な手軽さ」ではない選択肢を求めていました。それがたまたまマイクロソフトから出てきた「MVC」であった、というだけです。出なかったら、当時、勉強していたRuby on Railsを使っていたと思います。

――WebフォームからMVCへ移行した経験のあるパネリストの方にお聞きしたいのですが、WebフォームとMVCを比べて、開発生産性や開発コスト、作りやすさなどで、実際に違いがあるのでしょうか？

小野 修司 氏 （あおい情報システム株式会社）

小野　わたしの経験では、それほど変わらない気がしています。

　Webフォームを使っている方やわたしのブログを読んでいる方は分かると思いますが、Webフォームでもバリデーションを入れようとすると、「どのイベントに対して検証用のプログラム・コードを挿入するのが最も効率がよいのか？」などを考慮する必要があり、かなり大変です。サーバ・コントロールを熟知した開発者がサーバ・コントロールに合わせて仕様を作成し、開発を行っていくのであれば効率はよいのですが、常にそういうわけではありません。結果的に、Webフォームが手軽そうに見えても、効率はあまりよくない場合もあります。

　逆に、「MVCで作り方のパターンを決めていれば、チームのメンバーが協働して、それなりに効率的に開発できる」というのが、いまのわたしの考えです。

　以上の点を考えると、WebフォームでもMVCでも開発効率はそれほど変わらないと思います。

――MVCの楽しさはどこにあるのでしょうか？ わたし自身は、HTMLタグを自分で入力して、完全に自分好みの構造とデザインにするのは楽しいと思っています。Webフォームだと、簡単にビューを作成できるがゆえに、カスタマイズしにくいというところがあると思います。その点、MVCは自分の意思を反映しやすく、開発者のクリエイティビティを発揮しやすく、楽しいのかなと思います。

竹原　わたしとしては、Webフォームの「ページ・コントローラ」というアーキテクチャ・スタイルが気持ち悪いです。「MVC」というアーキテクチャ・スタイルは、それに比べると気持ちよく感じます。もちろん、「それがベストなのか？」と問われると、それよりも良いアーキテクチャ・スタイルも存在するのかもしれません。

――少し質問が変わりますが、WebフォームとMVCの両方を開発されている方は、両技術の選択指針はあるのでしょうか？

竹原　わたしのプロジェクトでいえば、MVCで作っているのは「コンシューマ向けの機能」です。「社内向けの機能」は、Webフォームで作っています。なぜかというと、コンシューマ向けの機能のビューは、雰囲気や外観も重要なので、Webデザイナーに制作してもらいます。一方の社内向けの機能のビューは、見た目よりも使いやすさと生産性が重視されます。

　MVCのビューについて例えば、.cshtmlファイルそのものをデータベースに格納しておき、表示が必要になったらそのファイルからビューを動的にレンダリングする仕組みを作れば、管理者が.cshtmlファイルの内容をWebシステムの管理画面から投入できるようになります。こうしておけば、見た目の部分は非常に管理しやすいです。MVCであれば、コンシューマ向けのWebシステムで役立つ、このような仕組みが作成できます。

――確かに、コンシューマ向けで作るのであれば、わざわざWebフォームで作らず、Webデザイナーの制作内容がそのまま生かせるMVCで作る方がよさそうですね。このほかに、MVCが向く場面／向かいない場面はあるでしょうか？

勇　わたしはMVCとWebフォームを実際に使ってみて、「MVCの方が覚えやすそうだし、楽そうだ」という結論で、MVC開発を採用しました。というのも、わたしの経歴では.NETよりもJavaの経験の方が長く、そのほかにPHPも触っていました。Webフォームの開発経験がない、非マイクロソフト系のWeb開発者にとっては、やはりWebフォームよりもMVCの方が学びやすいです。特にPHPのZend Frameworkを使っていれば、その基本的な開発手法はほぼ同じだといえます。ほかにもRuby on RailsやPython向けのDjango（ジャンゴ）などでも、考え方は同じなので、基本的な開発手法はほとんど同じです。

　Webフォームは使い始めたころは、その仕組みや開発方法がなかなか分かりませんでした。気が付いたら、さまざまなHTMLタグがたくさん生成されて、巨大な<input type="hidden">タグが埋め込まれていて、気分的に何か嫌な感じがしました。実際に、Webブラウザ「Firefox」用のJavaScriptデバッガのFirebugを触っていると、「不正なリクエスト・エラーです」のようなエラーが表示され、理由も分からず困惑したことがあります。ほかの技術の知識があるほど、何が起こっているのか分からずに混乱すると思います。それに比べてMVCの方は、何が起こっているのかが分かりやすい。

　他プラットフォームからのスキル移行を考えると、MVCの方が良いと思います。片や昔から.NET開発やWindowsアプリケーション開発をしてきた人にとっては、Webフォームの方が向いている可能性は残されていると思います。

小野　昔からの.NET開発者というよりも、「VB6開発者をWebアプリケーションの開発へ、スキル移行してもらうために作られたのが、Webフォームである」という認識です。だから、Webフォームの開発では、フォーム上にコントロールをペタペタと貼り付けて、コントロールの中でHTMLコードを生成して、さらに昔はCSSコードもインラインで生成したりしようとしていたのが、サーバ・コントロールです。その裏側では、HTTPなどのWebの仕組みに沿わない、見方によっては無理やりな仕組みで動かしています。そういった点が、HTMLやHTTPから入った開発者にとっては、「なんで、こんなおかしなことを行っているの？」という疑心を生む結果になってしまうのです。

　ちなみにわたしは、レガシーASP開発を経験しているのですが、Webフォームに触れ始めた当初は、勇さんと同じようにその仕組みに混乱しました。仕組みが分かって納得するまでには、それなりの時間を要しました。

　最近では、.NET開発へのさまざまな移行が考えられるようになり、そういったニーズに応えるためにMVCが登場したのだと考えています。

INDEX
	mvcConf @:Japan パネル・ディスカッション
	人気のASP.NET MVCエキスパートが語るMVCの魅力と実践
	1．Webフォームではなく、ASP.NET MVCを採用する理由
	2．ASP.NET MVCと組み合わせる周辺技術の選択指針
	3．ASP.NET MVCへのスキル移行

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）