ＢＲＭＳの次に期待されるレッドハットが提供する次世代ＰａａＳ実行環境

５月２６日、
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き

つぎは

ＢＲＭＳの次に期待される
超高速開発環境「ＤｅｖＯｐｓ」に迫る
～レッドハットが提供する次世代ＰａａＳ実行環境
　ＪBoss　ｘＰａａＳとその価値を紹介～

をメモメモ

---

ＲｅｄＨａｔ　ＪBoss Ｍｉｄｄｌｅｗａｒｅ
→ＢＲＭＳ：２０１３年度　シェアＮｏ１を獲得
・ルールエンジン
　　後ろ向き推論　NowDSBのみでなく、後ろ向き推論できる
　　プランニング
→ＢＰＭをよりシンプルに

ベストプラクティス　その１
・「ビジネスルールは常に変化する」を前提とする
　　ルールとプロセスをわける
　　変更はルールで吸収
　アプリケーション
　　　プロセス→データ→ルール

ベストプラクティス　その２
　ルールの抽出、デザインは専門家に任せる
　保守工数が上がる

ＤｅｖＯｐｓ
　　小さな変更を頻繁にリリース→超高速開発

レッドハットが提供するPaaS－OpenShiftの戦略
　　ＯＳＳコミュニティ
　　パブリッククラウド
　　プライベートクラウド
JBoss xPaaSで高度なアプリケーションに対応
OpenStack RHEL7,Dockerに最適化
→OpenShift Dockerで
　Jenkinsが組み込まれている
一歩先行くPaaS基盤
　　OpenShift+JBoss=JBoss xPaaS
　　　BPM ＰａａＳ
　　　Real Gear プッシュ
　　JBoss Fuse

JBoss XPaaSで実現できること

ＢＲＭＳ
・変化を受け入れる
・専門家による支援

PaaS
・OpenShift

エンタープライズモバイルアプリは超高速開発に向かう

５月２６日、
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き

つぎは

エンタープライズモバイルアプリは超高速開発に向かう
～モバイル事例で見る開発ツールの進化と真価～

をメモメモ

---

イスラエル
マジックソフトウェアエンタープライズ
サピエンスと兄弟外車（親会社一緒）

８００社のパートナー

・Ｍａｇｉｃ　xpa：きょうこっち
・Ｍａｇｉｃ　xpi＜－ＥＡＩツール

モバイルアプリ開発
・ＢＹＯＤ
・Ｗｅｂアプリは遅い、使いにくい
・ＯＳが変わるたび
・要求仕様がまとまらない
・ユーザーからいろいろ要求
・サーバー側にリソース

利益　＜　コスト

業務アプリのための開発環境の条件
・ワンソースマルチデバイス
・早く作れて、即座に変更
・基幹システムに耐えうる機能性、信頼性
・デバイス側のアプリ開発では不十分

モバイルアプリ開発は氷山の一角
　　・ＵＩクライアント側ロジック
　　　通信→xpa
　　　データ管理→xpa
　　　サーバー側ロジック→xpa
　　　データ連携→xpi

業務処理の定義
Ｍａｇｉｃ　Ｅｎｇｉｎｅ

開発環境
　　ＤＢ設定
　　画面
　　ロジック：１０種のコマンド
→ＸＭＬのアプリケーションメタデータ
　コンパイル不要、即実行

３種類のアプリケーションを構築可能

リポジトリを定義する
　　モデルリポジトリ　　：カラムの定義
　　データリポジトリ　　：テーブル設計
　　プログラムリポジトリ：
　クロスリファレンス
　　コールしているプログラムリスト
　　　　→影響範囲がわかる

保守、メンテナンス

開発プロセスの違い

アプリケーション更新プロセス

優れた拡張性・可用性
・容易にスケールアウトできるサーバーアーキテクチャ
　　→標準で入っている

Magic xpaの真価
・機械的、低レベルのコーディングを排除
・カスタマイズ／保守コスト軽減
・アプリケーションの移行が簡単
　　Magicが吸収
・業務アプリケーションしか作れない
　　→作り方が決まっている
・アジャイル開発が得意

事例
・パッケージソフト.com
・富士通テン
・紙→タブレット
Ｍａｇｉｃで開発すると
・全部１人で開発できる
・お客様と一緒に前向きに取り組める
バックエンド連携：学研ＳＡＰ

ＩＴゼネコンの食い物にならないための、産総研包括フレームワークを利用したシステム構築－札幌市

５月２６日、
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き

つぎは

長期間にわたりメンテナンスしやすいシステムの実現を目指す
札幌市基幹系システム再構築におけるグラスボックス化のとりくみ

をメモメモ

---

長期間にわたりメンテナンスしやすいシステムの実現を目指す
札幌市基幹系システム再構築におけるグラスボックス化のとりくみ

・はじめに
・変化に強いシステム実現のポイント
・業務とシステムをつなげる利点、大変さと工夫

変化につよいシステム
・札幌市が考える「メンテナンスしやすいシステム」
・保守開発の高速化
　　重複して作らない
　　互いに影響させない
　　業務とシステムをつなげる
　　　＋α（新しく広く普及した技術）

再構築対象システム（現行）の概要
現行システムで起きていたこと
　　ＩＴがビジネスの変化を阻害する状況に
　　自治体がＩＴゼネコンの食い物に

規模間とスケジュール
　　Ｊａｖａによるフルスクラッチ、事業基幹は６年
　　発注：専任７２名

産総研包括ＦＷの採用とその構成要素
　　産総研包括フレームワーク
　　　→グラスボックス（要件と実装のつながりで中身が見える）
　　　　　共通のものさしに

・１．重複して作らない
　　似て非なるもの→共通化をどのタイミングで誰が判断

・２．互いに影響させない
　　データ連携基盤
　　インフラ、ミドルウェアの入れ替えやバージョンアップの影響
　　　　Ｏ／Ｒマッピング
・３．業務とシステムをつなげる

・業務とシステムをつなげる利点
　産総研包括ＦＷの成果物標準
　　　→ＢＰＮＭににたようなもの
　業務と論理的

・大変さ
　　品質
　　　切り出しかた
　　　濃さ
　　　洗い出し漏れ、関連性漏れ

・やり方しだいで品質、生産性は大きく変わる　

サピエンスによる開発生産性向上事例

５月２６日、
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き

つぎは

サピエンスによる開発生産性向上事例

(注意！サピエンスの人では「なく」
　　サピエンスを使ってシステム構築した会社の人が話した事例）

をメモメモ

---

サピエンスによる開発生産性向上事例
・会社概要
　　リクルートの総務部門から→コスモスライフ

・サピエンス導入の経緯
　　　日経コンピューターの記事
　　　センチョラ＝SQLWindow→サピエンス
　　　　クラス指向

・対象システム概要
　　スクラッチ再開発
　　パッケージなし
　　スピーディー
　　外部監査
　　開発変更体制
　規模
　　　テーブル１８０
　　　画面　　２０９
　　　帳票　　　２８　（ＳＶＦ）
　　　バッチ　　４０　（ＲＰＧ／ＣＬ）

・注目した特長
　　プロトタイピング＆スパイラル
　　自動ドキュメンテーション
　　プログラムレス（知識ベース）

・ＶＢ．ＮＥＴとサピエンス比較
　ＺｅｎＡｐｐ（メタフレーム）
　　・開発生産性
　　・ナレッジ：統合環境

・内製を考えたが、外製を選択
　　　人を抱えると→キャリアパス、抜けた穴
　　　簡単に開発→外製でよりスピードアップ
　　　ドキュメント：外部→監査会社
　　　作って提供するでなく、サービスを提供

・成果
　　正解：VB.Netでは難しい