日経コンピュータ主催の「超高速開発ソリューションフォーラム2013」に参加しました。400名定員の会場に対して倍近い申込があり、開催一週間前に申込を締め切ったということで、会場は開始前から満席。期待感に包まれていました。*1 *2
私は「超高速開発コミュニティは何を目指すのか。」というタイトルで、会社ではなくコミュニティの幹事として発表させていただきました。アンケートの結果が良かったので、「ユーザー企業とSIer、ツールベンダーという関係者がそれぞれの立場で超高速開発の在り方を議論する場にしたい」という主旨がうまく伝わったと感じています。
ここでは他のご講演の概要をメモするとともに、私の感想を書きます。
超高速開発はどう使うのか、事例から方向性が見えてきた
「NTTドコモの情報システム戦略」では、大規模基幹系（12億レコード/日のデータ量）の開発・運用に関する知見が披露されました。システムのアーキテクチャやミドルウェアなど参考になる話が満載でしたが、特に注目したのはシステム全体で800万行にも及ぶ if 文をどう整理すべきか、という話題です。これだけの規模になると人間によるチェックや改修は困難を極めます。富士通さんをパートナーとして、ここにSolver型Rule Engineを適用することで90%近くを削減することに成功し、結果として機能拡張に対する開発期間の短縮やコスト削減につなげることができたということです。まさに BRMS の真骨頂を発揮された事例でした。
生活協同組合連合会コープネット事業連合様のご発表は、Sapiensの事例です。画面、DB定義、プロセス、ルールすべてをオールインワンで定義できるという製品が、同組織のシステム内製化に有効であるということが示されました。
レッドハット様のご発表では「プロセス（業務フロー）はBPMS」「ルールはBRMS」「データはDBMS」という3つの軸について、それぞれアプリケーションによる作り込みから分離させることで開発生産性と保守性が上がるというアーキテクチャの説明がありました。楽天生命保険様のご発表もBRMSの活用によってシステム開発が新サービス開始のネックにならなくなったというお話でした。
各ご発表で登場する製品は異なりますが、プロセスやルールをアプリケーションと分離するという手法により開発工数も削減でき、かつ少人数での超高速開発ができることが、具体的な数字で語られるようになってきました。
次の基幹系刷新のタイミングで、内製化が進む可能性
ここでいう内製化とは、すべて自社の情報システム部門が開発するという意味ではありません。SIerと一緒になった開発も含みます。中核となる思想は「業務仕様を自らの手元で管理することを重視した開発」とでも表現すればいいでしょうか。そのためには「モデリング」が必須であり、かつモデリングの情報 = リポジトリが最重要資産で、この保守に情報システム部門が積極的に関わっていくというものです。
これは（私を含め、多くの業界関係者が嘆いていた）一括請負丸投げ契約との決別です。いよいよ、その流れが本格化する予兆を感じました。ユーザー主導のシステム開発が目指す姿は、ブラックボックス化を廃し、設計情報とアプリケーションの整合性が保たれており、システムの改修（外的要因の変化）について最小限の修正で対応できる開発・運用基盤を持つことです。これは労働集約的な "マン・パワー" による開発から、ツールを活用した少人数による開発への移行を意味します。
このような思想はしかし、適切なツールがなければ画餅でした。使えるツール（環境）が整ってきたのならばチャレンジしてみたい、そういう思いがあるからこそ、このセミナーにこれだけの集客があるのだといえます。
"オープンシステム"、"ERP+カスタマイズ"から"設計情報の活用"へ
1990年代初頭の"オープンシステム"では、Visual Basic や 4GL を駆使したアプリケーション開発が流行しました。フレームワークが存在せず、開発者はAPIを直接、駆使することで多くのプログラムを書きました。これは自由度が高い反面、保守がしづらいという問題が表面化しました。
その反動から二つの潮流が生まれます。"ERP+カスタマイズ"と、"アプリケーションサーバ"です。前者はできるだけカスタマイズをせずに標準ERPとして使った方がいいと喧伝されましたが、実際にはカスタマイズの嵐となって、やはり保守がしづらいという課題が浮き彫りになります。ERPライセンス費よりカスタマイズ費の方が高い、というのも常識となってしまいました。後者はJava EEに代表されるようなフレームワークを前提とした「パターン化されたコード」を書くことで保守性を高める方式です。今のところはデータベースアクセス層と画面層の標準化が主であり、冒頭のNTTドコモ様の例にあるように、大量のif文をアプリケーションに埋め込むことの問題そのものを解決するには至っていません。
超高速開発コミュニティが目指すのは、この次です。業務のモデル化により、設計情報（リポジトリ）を整理します。ここに徹底的に時間をかけます。そして設計情報からアプリケーションの生成はツールにより（半）自動化します。この発想そのものは新しいものではありませんが、設計情報に何が必要で、どこまで自動生成可能なのかというノウハウが着実に蓄積されてきたため、研究レベルではなく実用レベルで使えるようになってきた、ということがポイントです。そして、このような環境にユーザー企業は大変な興味を抱いています。実現できれば、エンタープライズアプリケーション開発分野に大きな影響をおよぼすことでしょう。
まとめ
セミナー終了後、超高速開発コミュニティ主催として初の懇親会を開催しました。40名の参加を見込んでいましたが、60名近い参加となり、こちらも大いに盛り上がりました。懇親会でも技術論や過去のプロジェクトの事例が飛び交い、飲食する暇もないほどでした。コミュニティを立ち上げて良かったと思うのは、国内の第一人者が集まる「場」になりはじめたということです。人が集えばアイデアが飛び交い、ここから新しいチャンスも生じます。もちろん競争もありますが、それぞれのやり方でユーザー企業のためになること、を実践することです。
懇親会の場で、USP研究所の當仲所長の挨拶に感じ入りました。
"超高速開発というと、そんなにあくせくしてどうするんだ？という意見も出てきます。しかし超高速に開発できるなら、時間にゆとりがうまれます。その時間を歓談*3に使うなどできれば、それはいいことです。"
超高速開発は決して開発者に対してスピードを強要するという意図ではありません。コンピュータはもともと自動化というテーマに向いているのです。設計はデザインですから人間がじっくり時間をかけてやるべきところです。そのあとが自動化されれば、ゆとりが生まれます。そういう環境になればすべての関係者にとってメリットがあるでしょう。超高速開発の目指す未来像に期待しています。
2013.11.26 追記
@yusuke さんの指摘より、SlideShare 公開資料の p.24 「メーリングリスト」を「メールマガジン」に訂正しました。
