マジカとソフトウェアファクトリー
この間参加したTechEdで、Microsoftのコンサルタントの方とソフトウェアファクトリについてお話する機会があった。
だいたいの内容は、こんな感じ。
- SoftwareFactory構築の最初の一歩は、プロジェクトのベストプラクティスを収集すること
- その次に、収集したプラクティスをガイダンスとしてまとめる
- ガイダンスから、可変部とそうでない部分を抽出する
- 不変な部分は、フレームワークやライブラリとして提供
- アプリケーションの構造的な部分はDSLでモデリング後にコードを生成
- 可変な部分は、Wizard形式で開発者がパラメータを指定し、テンプレートエンジンでコード生成
で、実際にプロジェクトで適用した後に、またプラクティスを収集するところから繰り返すイテレーティブなプロセスであるということ。
また、このプロセスを洗練させていくことによって、アプリケーションのコードの80〜90%はFactoryから生成されるようになるということ。
上記のプロセスの最後の２つをサポートするために、DSL ToolkitやGAT(Guidance Automation Toolkit)を提供しているということ
自分の今のプロジェクトの状況は、「不変な部分は、フレームワークやライブラリとして提供」ここかな。
今のプロジェクトは基盤が.net1.1なので、DSL ToolkitやGATを使うことはできないけど、エッセンスを取り入れていくことは可能だと思うので、もっと努力していきたい。
Webを散策していたら、こんなエントリを見つけた。
http://d.hatena.ne.jp/yojik/20070826/1188137262
余談だけど、業務プログラマの本業は、基盤(フレームワークやプロセス)を作り上げることだと思う。アプリケーションロジックも重要だけど、そこは理想的な状況なら、本来ユーザが実装すべき箇所だと思う。もちろん現状ではありえないけど、近づけるように努力すべきかなと。手紙の代筆みたいな仕事はいつか消えるだろう。業務プログラマから、基盤に対する自由度を奪うとやる気が失せる。業務プログラマは、本質的なアプリケーションロジックのみだけ実装すべきみたいな考え方は無意味だ。SI企業の差別化要因は「基盤を作り出す能力」にあって、それは外から買ってきたりダウンロードできるものじゃないと思う
ここで言われている、「基盤」というのは、ソフトウェアファクトリに近いのではないかと思う。
そして、「本来ユーザが実装すべき箇所」をよりユーザに実装しやすくするための第一歩がDSLなのではないかと。
「それは外から買ってきたりダウンロードできるものじゃない」
これは、上記のコンサルタントのひとも言っていて、「ベストプラクティス」といっても、どんな問題にも対応できるようなものではなく、今まさに対面している問題に対応したものでなければ、ファクトリーの効果は薄い。
つまり、自分たちで見つけていかなければならないということでした。
でこれを書いている間に、ちょっと前にニュースになった「マジカ！」の話を思い出した。
http://www.atmarkit.co.jp/news/200707/19/starlogic.html
これもソフトウェアファクトリの一種ではないかと思った。
最初に見たときは、「カード1枚が8万円」なんて無理じゃないかと思ったが、そう考えていくと
「不可能」というわけでもないように思えてくる。
