中国当局、ＩＢＭサーバー撤去を国内銀行に迫る－関係者
http://headlines.yahoo.co.jp/hl?a=20140527-00000030-bloom_st-bus_all
あ～、日本とアメリカは大丈夫だけど、
日本と中国もやばいよね！
中国と日本の関係が悪くなれば、中国当局が日本のサーバー撤去を求めるのみならず、日本から、中国企業も撤退・・・となると、中国製ＰＣ，サーバー、クラウドを使っていると、サービス停止とか・・
アメリカ製、国産のほうが、戦争リスクを考えると安全か？
中国当局、ＩＢＭサーバー撤去を国内銀行に迫る－関係者
http://headlines.yahoo.co.jp/hl?a=20140527-00000030-bloom_st-bus_all
あ～、日本とアメリカは大丈夫だけど、
日本と中国もやばいよね！
中国と日本の関係が悪くなれば、中国当局が日本のサーバー撤去を求めるのみならず、日本から、中国企業も撤退・・・となると、中国製ＰＣ，サーバー、クラウドを使っていると、サービス停止とか・・
アメリカ製、国産のほうが、戦争リスクを考えると安全か？
昨日、
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き
つぎは
情報システム刷新の主流となる手法
システム・リフォーム
なんだけど・・・（以下内容のメモのあと、一番最後に感想）
１．会社紹介
・リフォームの報道
・急速に広がっているリフォーム
・日本に来た経緯
２．巨大開発の問題
・既存システムの状況
初期開発
ブラックボックス→莫大のロジック
開発になると
ユーザー要望を押さえ込む
業務カイゼンを考える余地がない
開発の失敗は日常茶飯事
・企業ＩＴの新の需要は
業務カイゼン→世界標準でやってください
２つ機能＋技術
３．システムリフォームのプロセス概要
現行システム
１．スリム化
２．移行
３．仕様書再生
４．新案件取り込み
刷新システム
移行のプロセス
・変わるところを気にする
ソースを仕様書／ソースに変える
・パイロット移行検証で、品質と納期を確実に
フェーズ１：パイロット移行検証
フェーズ２：本移動
・多用な変換パターン
ツールとミックス
人は２ヶ月あれば読める
既存システムをベースに改善（新要件取り込み）
・業務プロセス分析
・データ分析
・業務ヒアリング
既存ＡＰ資産のスリム化・移行前の見える化
・ログ分析：ツールにかける
ユーザー：この機能は使っていない
→実はバッチで使っていた！
・ＰＧＭ→ＰＧＭ連携分析（画面／バッチフロー）
リフォームの品質
・納品後バグ密度
（ＪＵＡＳ換算欠陥数） ＪＵＡＳ標準目標：０．２５
・コスト
ＪＵＡＳ新規開発平均８６．８
・オフショア保守
システム更新
ＣＯＢＯＬ→ＪＡＶＡ
事例
・パッケージは意外とたかい：１０年使ったりすると
・業務を理解しているわけではない
で、システムリフォームって、なに？
超高速開発リノベーションフォーラム２０１４
に行って来た！話の続き
つぎは
情報システム刷新の主流となる手法
システム・リフォーム
なんだけど・・・（以下内容のメモのあと、一番最後に感想）
１．会社紹介
・リフォームの報道
・急速に広がっているリフォーム
・日本に来た経緯
２．巨大開発の問題
・既存システムの状況
初期開発
ブラックボックス→莫大のロジック
開発になると
ユーザー要望を押さえ込む
業務カイゼンを考える余地がない
開発の失敗は日常茶飯事
・企業ＩＴの新の需要は
業務カイゼン→世界標準でやってください
２つ機能＋技術
３．システムリフォームのプロセス概要
現行システム
１．スリム化
２．移行
３．仕様書再生
４．新案件取り込み
刷新システム
移行のプロセス
・変わるところを気にする
ソースを仕様書／ソースに変える
・パイロット移行検証で、品質と納期を確実に
フェーズ１：パイロット移行検証
フェーズ２：本移動
・多用な変換パターン
ツールとミックス
人は２ヶ月あれば読める
既存システムをベースに改善（新要件取り込み）
・業務プロセス分析
・データ分析
・業務ヒアリング
既存ＡＰ資産のスリム化・移行前の見える化
・ログ分析：ツールにかける
ユーザー：この機能は使っていない
→実はバッチで使っていた！
・ＰＧＭ→ＰＧＭ連携分析（画面／バッチフロー）
リフォームの品質
・納品後バグ密度
（ＪＵＡＳ換算欠陥数） ＪＵＡＳ標準目標：０．２５
・コスト
ＪＵＡＳ新規開発平均８６．８
・オフショア保守
システム更新
ＣＯＢＯＬ→ＪＡＶＡ
事例
・パッケージは意外とたかい：１０年使ったりすると
・業務を理解しているわけではない
で、システムリフォームって、なに？
超高速開発の話をきいてきて（これからいろいろ披露しますが）、
どうも、超高速開発は４つに分かれる話をひとつにまとめてしまうから、
まゆつばに聞こえるように思えた。
１つ１つの話は、以下のように全うな話。
１．MVCにおいて、モデルを３つ、ルール・データ・プロセス？にわけ、
ルール部分を、可視化し、ノンプログラミングにする→BRMSの分野
２．MVCにおいて、MCを自動化し、てきとうな（適切ではない）Vをつける
→いわゆるRails、マジック、GeneXusなど
３．１．２が動作する環境の提供、自動化など
→DevOpsやクラウドなど、RedHatのOpenShiftなど
４．その他（開発方法論など）
→産総研包括フレームワーク？
それぞれをみると、既にあるもので、実績を挙げているものなので、
そんなに不思議な話ではなく、うん、そういくだろうな・・・
と思うんだけど、これらをごちゃ混ぜにして、日経BPが
「超高速開発」というと、あやしくなる。
で、これらは、アジャイルそのものではなくて、
アジャイルを行ううえで便利なツールになるということですね
（アジャイルでなくても使える）
ただ、これで進化が終わりではない。
結局Vの部分がいいかげんなものをつけてしまうので、
すべてに応用できない。
今後は
・MCをRESTで提供し、Vの部分は、一応作るけど、いろんなツール
を使い、AJAXで連携することができる
・その上、ルール部分はBRMSと連携可能
というツールができれば、完璧
どうも、超高速開発は４つに分かれる話をひとつにまとめてしまうから、
まゆつばに聞こえるように思えた。
１つ１つの話は、以下のように全うな話。
１．MVCにおいて、モデルを３つ、ルール・データ・プロセス？にわけ、
ルール部分を、可視化し、ノンプログラミングにする→BRMSの分野
２．MVCにおいて、MCを自動化し、てきとうな（適切ではない）Vをつける
→いわゆるRails、マジック、GeneXusなど
３．１．２が動作する環境の提供、自動化など
→DevOpsやクラウドなど、RedHatのOpenShiftなど
４．その他（開発方法論など）
→産総研包括フレームワーク？
それぞれをみると、既にあるもので、実績を挙げているものなので、
そんなに不思議な話ではなく、うん、そういくだろうな・・・
と思うんだけど、これらをごちゃ混ぜにして、日経BPが
「超高速開発」というと、あやしくなる。
で、これらは、アジャイルそのものではなくて、
アジャイルを行ううえで便利なツールになるということですね
（アジャイルでなくても使える）
ただ、これで進化が終わりではない。
結局Vの部分がいいかげんなものをつけてしまうので、
すべてに応用できない。
今後は
・MCをRESTで提供し、Vの部分は、一応作るけど、いろんなツール
を使い、AJAXで連携することができる
・その上、ルール部分はBRMSと連携可能
というツールができれば、完璧
昨日、
超高速開発リノベーションフォーラム２０１４
に行って来た！
その内容をメモメモ。まずは、はじめのお話
双方向判断機能で乗り越えるＢＲＭＳの落とし穴
～なぜ独自ＢＲＭＳを開発したのか～
から。
ＢＲＭＳの苦手なところ→独自開発
ライセンス提供可能
１．会社紹介
ＩＴプロデュース部
ＳＯＡ，仮想化、ＷｅｂＳｏｃｋｅｔ，ＢＲＭＳなど
２．ＢＲＭＳとは
アプリケーションからビジネスルールを切り出して、
実行・設計・管理
目的
・守りの目的：システム開発、メンテナンスコスト
・攻めの目的：インテリジェンス
ＢＩＷＡＲＤ
ＢＩ：双方向
ＷＡＲＤ：forward,backward
ＢＲＭＳ：保険業界多い
→一部のインプット固定
銀行：対面型事務→双方向
前進判断：条件→結果
後進判断：結果→条件
ほとんどのアルゴリズム
Ｔｒｅｅ構造で判断分岐→逆方向：実現が難しい
→Ｎｅｔｗｏｒｋ構造アルゴリズム
前も後ろも関係ない
ルール：独自のルールエディタ
ディシジョンテーブル
条件をいれると→なにをしてくれとでてくる
ＸＭＬでできている
ルール作る
ルール直す
エラーになる→想定するところがエラーになるか？
エラー部分の修正
ＸＭＬ→Ｓｃａｌａ（すから）→ＪＡＲ
対面業務のＢＲＭＳ活用には注意が必要
ＮｏＷＤＳＢ：双方向
ＢＲＭＳは保守性向上に大きなメリット
→新規開発時に楽になったわけでない
→保守：ルール側かアプリ側かがわかる
提案型ＢＲＭＳへの挑戦
超高速開発リノベーションフォーラム２０１４
に行って来た！
その内容をメモメモ。まずは、はじめのお話
双方向判断機能で乗り越えるＢＲＭＳの落とし穴
～なぜ独自ＢＲＭＳを開発したのか～
から。
ＢＲＭＳの苦手なところ→独自開発
ライセンス提供可能
１．会社紹介
ＩＴプロデュース部
ＳＯＡ，仮想化、ＷｅｂＳｏｃｋｅｔ，ＢＲＭＳなど
２．ＢＲＭＳとは
アプリケーションからビジネスルールを切り出して、
実行・設計・管理
目的
・守りの目的：システム開発、メンテナンスコスト
・攻めの目的：インテリジェンス
ＢＩＷＡＲＤ
ＢＩ：双方向
ＷＡＲＤ：forward,backward
ＢＲＭＳ：保険業界多い
→一部のインプット固定
銀行：対面型事務→双方向
前進判断：条件→結果
後進判断：結果→条件
ほとんどのアルゴリズム
Ｔｒｅｅ構造で判断分岐→逆方向：実現が難しい
→Ｎｅｔｗｏｒｋ構造アルゴリズム
前も後ろも関係ない
ルール：独自のルールエディタ
ディシジョンテーブル
条件をいれると→なにをしてくれとでてくる
ＸＭＬでできている
ルール作る
ルール直す
エラーになる→想定するところがエラーになるか？
エラー部分の修正
ＸＭＬ→Ｓｃａｌａ（すから）→ＪＡＲ
対面業務のＢＲＭＳ活用には注意が必要
ＮｏＷＤＳＢ：双方向
ＢＲＭＳは保守性向上に大きなメリット
→新規開発時に楽になったわけでない
→保守：ルール側かアプリ側かがわかる
提案型ＢＲＭＳへの挑戦
アクセス
トータル
ランキング
