ＲｅｄＨａｔのＩＯＴ，ＡＩや、富士通、CISCOのOpenStackリファレンスモデル等

今日（11月４日）Redhat Forum 2015に午後から行ってきて、
ＲｅｄＨａｔのＩＯＴ，人工知脳や、
富士通、CISCOのOpenStackのリファレンスモデル等の話を聞いてきた！
ので、聞いてきた講演内容をメモメモ

---

■ＩｏＴ研究所～JBossとDockerを使ったIoTのベストプラクティス
・ＩｏＴ４つ：HBRでマイケルポーターが
　モニタリング：データ収集
　制御：クラウド上のアルゴリズム等で制御
　最適化：過去、外部データまぜる
　自律性：結びつき自律

自律性　｜　　　　　　　　｜Industry4.0
最適化　｜　スマート○○　｜　トランザクション大＋ＡＩ
　　　　｜－－－－－－－－－－－－－－－－－
制御　　｜　対人　　　　　｜対機器（あまりない）
モニタ　｜　最近のサービス｜コネクテッドカー等
　　　　＊－－－－－－－－－－－－－－－－－
　　　 小　　　トランザクション量　　　　大

・対人だと、トランザクション量少なくなる
　ＩＴＣ企業が狙うべきは、一番下以外
　ＩｏＴもりあがっているけど、案件ない
　　→左下のところ：あまり関係ない

ＩｏＴを実現するためのテクノロジーアーキテクチャ
・レッドハットのＩｏＴソリューションと戦略

　　　　　　→知的アクション→　
　　　　　｜　　　　　↑　　　｜
　　情報処理　　　←ーー　ナレッジ
　　　　　↑
　　　　　　－－データ収集

・ＩｏＴテクノロジースタック
　フロント：ＭＱＴＴ，ＨＴＴＰメッセージブローカー
　バックエンド：リアルタイム処理、分散、アプリ、ルールエンジン

　マイケルポーター：ルールエンジン重要

　JBOSS A-MQ
　Redhat Mobile プラットフォーム：MBaaS
　JBoss DataGrid リアルタイム処理
　JBOSS BRMS

・レッドハットＩｏＴスタックの特徴
　（１）ポータビリティ　クラウドからオンプレへ案件：Docker,OpenShift
　（２）リアルタイム処理ＣＥＰ
　（３）フレキシビリティ
　　　オープンイノベーションの実現：どこか１社で作る→組んで作る
　　　ビジネスの変化についていける柔軟な仕組み
　　　　　サービスのベストプラクティスできていない
　　　　　ＪＢＯＳＳ　ＢＲＭＳ

（１）ポータビリティ
　　情報量が増えると止まるのは、ネットワーク
　　　→クラウドのサービスを工場内に：ポータビリティ
　　Docker：ＩｏＴ案件では使われている
　　OpenShift Enterprise3→Docker管理基盤にも(kubernates)

（２）リアルタイム処理
　分析　　　　：Hadoopにためる　人が分析
　制御、最適化：別のＩＴ基盤　　直近データを機械学習

　JBOSS BRMS
　　ルールエンジン　日本ＮＯ１
　　Ｊａｖａのバイトコードで動く
　JBOSS データグリッド
　　分散インメモリ処理。可能な企業向けKVS/NoSQL製品
　　事例：松井証券

（３）フレキシビリティ
　　より製品側の最適化、自律性
　　出荷時と異なる動作、パーソナル化
　　ルールエンジンを製品に組み込む
　　　　ＳＰＳＳ、ＳＡＳ、Ｒ　ＰＭＭＬ→ＤＲＬ(ルールエンジン）に変換

レッドハットＩｏＴ研究所

---

■Cisco OpenStackとサービスへの取り組み

現在のトレンド
・企業における課題：常に変化が必要とされる
　Tecnology Transitions
　ＩＴの役割変化
・クラウドの位置づけと価値
　スケーラビリティ
　スピード
　オープン
　柔軟性
・企業へのOpenStack導入
　Redhatとのアライアンス

Cisco & Redhatの価値提案
・共同のエンジニアリングと製品開発
　クラウドプラットフォーム UCS+OpenStack→リファレンスモデル
　ネットワーク仮想化
　クラウドセキュリティ

・OpenStack実装時の課題
　測定可能な結果
　リスクの管理
　柔軟性の維持

・OpenStackクラウドの容易な導入
　Cisco ばりでーでっと　でざいん

・OpenStacj向けＵＣＳ統合インフラストラクチャ
　エディション３つ
　　スターターエディション
　　アドバンスドエディション
　　アドバンスドＡＣＩエディション

・一般的なユースケース
　プライベートクラウドとハイブリッドクラウド

・Cisco Validated Design(CISCO検証済みデザイン）

・Cisco UCSラインナップの継続的な拡充
　　エッジスケール
　　データセンターワークロード
　　クラウドスケール

・インフラに対する自動制御と管理
　Cisco UCS Director

・データセンターネットワークの進化
　現行の階層型ネットワークモデル
　今日のＳＤＮ：ＡＣＩ
　Ciscoの考える将来像

・ＡＣＩ Application Centric Infrastructure(ACI)
　　SpineとLeaf

・アプリケーションネットワークプロファイル
　　パターンを用意しておく

・アプリケーションとインフラ管理者の適切な分離
　移動、拡張の基盤を提供

・Cloud Security：ハイブリッドクラウド利用環境の実現
　　自由なクラウド選択
　　セキュアコネクト
　　コントロール
　　ガバナンス

・最適なハイブリッド環境を実現する　Cisco Intercloud Fablic

・シスコのソリューションサポートサービス（SSPT)
　統合サポートの新モデル

・シスコアドバンスドサービスのご紹介
　ライフサイクルサポート
　サービスの特徴
　サービス提供能力・体制

・シスコアドバンスドサービスメニュー

・シスコの提供するクラウド関連サービス

まとめ
・Cisco OpenStackソリューションの価値

---

■人工知能
　５年前くらいから話したかった
　幅が広い

・人工知能に期待すること
　人の至らぬところをサポートしてくれる何か
　人と同じレベルで会話・行動をしてくれるロボット
　人の能力を超越し、意思をもって行動する”ロボット”

・政府の来年度ＩＴ予算
　マイナンバー：国税・総務・内閣官房（厚生：医療マイナンバー）
　人工知能：経済産業省（産業総合研究所）もんかしょう（理化学研究所）
　
・なぜ注目されているのか
　現時点でのＩＴの頂点となりうる技術（究極）
　ビッグデータ処理が可能な基盤がそろった（現実）
　利権を確保して価値に変える（欲望）
　みんなが幸せになれる（貢献）

・人工知能：いっぱい（人工知能学会ホームページより）
　感性処理
　ロボット
　　：
　エキスパートシステム
　探索
　推論
　プランニング
　　：
　情報検索
　ニューラルネット
　データマイニング
　マルチエージェント

・ＡＩとＢＩの違い
　ひいらぎ：たいやきやさん
　冬の寒い日にはタイ焼きがよく売れる　統計情報から確認された事実（ＢＩ)

　タイ焼きは温かい＋冬の寒い日に温かいモノが売れる＝冬はタイ焼き
　事実　　　　　　　　経験則　　　　　　　　　　　　推論結果
　タイ焼きは温かい＋夏の暑い日は冷たいモノが売れる＝夏は冷やしタイ焼き
　（ＡＩ）

・人工知能に求めるもの
　人が気がつかないことを気づかせてくれる知識とそれに基づく行動
　機械学習やディープラーニング
　　「人の能力を超えるスピードで、モノとモノの関係性を見つける：
　プランニング：
　　膨大な組み合わせの中から、人が気づいていなかった、よりよい組み合わせを見つけて行動を促す
　
・人工知能のサイクル
　データ収集
　　大量のデータ　Internet of Things
　　ゴミデータの掃除
　　似たようなデータをまとめる
　　後で使えるように保管
　分析・学習
　　機械学習
　　ディープラーニング
　　　　事象の場合分け
　　　　相関関係を抽出
　推論・行動
　　事実をルールに従い処理
　　脳のシナプスのようにルールを連続発火させて推論結果を得る

・データの収集
　　ＲｅｄＨａｔ　ＪＢおｓｓＲｕｓｅ

　　ＲｅｄＨａｔ　ＪＢＯＳＳ　Ｄａｔａ　Ｇｒｉｄ
　　　ＫＶＳ　ぐりっどＤＢ
　　ＲＤＢ／分散ストレージ　ＲｅｄＨａｔ　Ｓｔｏｒａｇｅ
　　　　データの形式や重要度に応じた適切な格納

・機械学習
　本誌うは分ける
　　分けた者の間の関係性を作って、現実世界にフィードバックする

　　ＹＥＳ／Ｎｏ
　　クラスタリング
　　ベイズ推定
　　決定木
　　ニューラルネット等

・機械学習：クラスタリングの例
　ルールエンジンでもできる　ＢＲＭＳ

・ディープラーニング
　ニューラルネットワーク：生物の神経細胞間の仕組み
　　ひいらぎ
　　　　タイ焼き
　　　　クリスマスツリー
　→特徴量

・ルールの実行（推論・行動）
　パターンマッチング→探索

・探索とは

・組み合わせ爆発

・解法がある→公式に会えはめる
　解法がない→試行錯誤→ヒューリスティック・メタヒューリスティック
　JBoss BRMS Business Resource Planner

・生物が持つ本能・欲望・無意識は絶対に人工化できない

---

■エンタープライズクラウド実現に向けた富士通のOpenStackへの取り組み
ＯＳＳをエンタープライズ適用する富士通の取り組み
・業務システムを支える４つの取り組み
　ハードウェア：ＰＣさーばーぷらいまじー　基幹サーバーぷらいむくえすと
　ＬｉｎｕｘＯＳ：開発コミュニティ、ものづくり
　ミドルウェア：開発コミュニティ参加、Apache2.0ライセンスで公開
　サービスサポート：力入れてる

・Linux開発への富士通の取り組み
　オープンソースコミュニティ開発を通じてMission Critical適用推進
　富士通：横串を通して
　OpenStack：スイッチ、サーバー、ストレージ
　　→認証重要

・ＭＣ実現への技術的な取り組み
　機能強化
　プログラム品質強化：テストセット使ってもらう
　サポート品質強化：一番苦労。日本的運用スタイル

・Ｌｉｎｕｘ機能強化への取り組み
　コミュニティ積極参加・開発リード
　　ミッションクリティカル
　　近年はDockerに取り組んでいる

・Ｌｉｎｕｘ品質強化への取り組み
　Ｅｎｔｅｒｐｒｉｓｅ　Ｌｉｎｕｘ開発エコシステムを活用
　富士通の取り組み　ＭＣ適用を目指した品質強化に着目
　　開発上流工程
　　ＲＨＥＬ開発工程
　　ＲＨＥＬ出荷前評価工程

・Ｌｉｎｕｘサポート品質強化
　富士通がフロントに立って、責任を持ってお客様をサポート
　９９．５％を富士通内で解決

・Advanced Mission Critical Program(AMC)
　ミッションクリティカル領域でLinuxを使用するお客様のご要望
　　→システムを安定にかつコストも意識して長期間利用したい
　　システムに必須な修正をより安全に運用したい
　マイナーリリースアップデートなしに安定的な修正適用を実現

・RHEL7 Advanced Mission Critical
　日本的な運用スタイルに合わせたサポート商品仕様を実現

・Ｌｉｎｕｘは機能・品質・サポートすべてミッションクリティカルシステムに

・パブリッククラウドのLinuxゲストサポート
　Trusted Public S5上において、世界６拠点で
　Redhat Enterprise Linusを提供中

・Core Infrastructure Initiative(CII)
　インターネットインフラを担うＯＳＳプロジェクト買う同を支援
　富士通は日本から唯一設立当初から参加
　　・ＯｐｅｎＳＳＬ
　　・Ｂａｓｈ

ＯｐｅｎＳｔａｃｋエンタープライズ適用
・プラットフォーム利用形態の変化（昨年講演）
　２じく　ＤｅＤｉｃａｔｅ⇔Share,Private⇔Public
　　ベアメタル　Dedicate／Privateから、Share,publicげ

・クラウドビジネスの取り組み
　２０１５年より弊社ナレッジを搭載したクラウドＫ５の提供開始
　　（いままでＴｒｕｓｔｅｄ　Ｓ５）
　２０１４年よりエンタープライズ適用に向けＯｐｅnStack本格強化

・OpenStack品質強化への取り組み
　RedHatEnterprise OpenStack Platform
　　エンタープライズ適用への機能品質向上
　　プログラム品質強化
　　社内実践による品質強化への取り組み
　エンタープライズ適用に向け、ＲｅｄHatと協働で品質強化

・RHEL-OSPの課題と取り組み
　より導入しやすい小規模厚生で社内実践し、課題抽出
　　環境構築
　　機能
　　品質
　　運用・保守
　リファレンスモデル開発とRHEL OSP構築サービスにより４つの課題を解決

・リファレンスモデル Primeflex for RHEL OSP
　今年８月から欧米で先行発売
　約８０％のユースケースをカバー
　ＳＰＯＦ排除による高可用性
　導入期間　４０％短縮

・リファレンスモデル厚生
　主要コンポーネント多重化によるＳＰＯＦ削減

・RHEL-OSP導入におけるサービス・サポートをフェーズ毎に提供

・リファレンスモデル
　　さーばー
　　　ぷりまじー　いろいろ
　　すとれーじ
　　　えたーなす
　　ソフト
　　　Systemwalker Service Catalog Manager→ＯＳＳ化
　　　　１０月２７日より無償公開

・オープンソースを活用したエコシステム強化
　Systemwalker Service Catalog Manager→ＯＳＳ化
　　　　１０月２７日より無償公開
　Open Conteinar Initiative創設メンバー
　Containerのポータビリティ確保

・ＳＤＮ
　みどねっと
　おーぷんでいらいと

ＯｐｅｎＳｔａｃｋ関連製品
・クラウドサービスマネジメント
・サービスカタログマネージャー
・えんたーぷらいずみどねっと
・ストレージえたーなす
　ＣＤ１０Ｋ　せふでつくってる
・ＮＦＶプラットフォーム
　ばーちゅーらＯＭ

富士通ブース紹介
　実機でも
　たぶれっとあたる　しむふりー

---

■レッドハットによる予測分析と分析データ連携ソリューションのご紹介

・分析系も入ってきている
・事例も出てきた

レッドハットと分析
・データ分析と分析データ
　　データ収集
　　データ蓄積
　　データ分析
　　分析データ蓄積
　　分析レポート
　　分析データシステム利用

→きょうは真ん中の部分「データ分析」

データ分析と予測
・分析ツールの傾向
　Top Analytic Tools and Trends
　Ｒ、ＳＱＬ、Ｅｘｃｅｌが上位に来ている

　Ｒ：統計計算とグラフィックのための言語・環境

　データ分析
　　傾向分析
　　原因分析
　　予測分析→今回ここ
　分析手法
　　回帰（重回帰）
　　クラスター
　　決定木
　　相関分析
　　アソシエーション分析

・予測分析とは
　過去データ分析、将来予測
　属性と実績の組み合わせによる関連性判断
　必要な業務
　　　小売・サービス
　　　コールセンター
　　　製造業
　　　作業予測

・予測できていないことによる問題
　　想定以上の客（注文）がきた
　　想定以下の客（注文）であった
　経験である程度カバーできるが、今後も同様のことが起こりえる

・予測が正しくできることで
　事前の対処や回避のための施策が可能

コールセンター事例
　コールセンターでよくある課題
　　ＣＳ向上
　　人員不足・余剰
　　スキルの向上
　　離職率
→呼量予測で多くが解決
　柔軟な配置

・要員計画と要員配置の問題
　長期的な問題：たくさんの人確保、経験は人に依存
　当日の追加は難しいは予測は重要

　要員計画と要員配置の施策案

　今回の分析要件の概要
　　→予測分析のゴール：呼量の予測式算出

　分析予測作業
　１．データ整理
　２．データ分析：Ｒで
　３．予測モデル

・１．データ整理
　各地域
　共通部分

・２．分析
　天候影響がないもの
　総着信数＝ベースロード＋ウェザースパイク
　　ベースロード＝生活係数＊（経年変動＋季節変動）
　日種

　　ウェザースパイク＝ピーク値＊経時係数

　気象情報：気象台

　モデル補正
　　１．ピークシフト補正
　　２．トレンドフォロー
　　３．オーバーコール

　気象タイプと着信数との関連判断

・３．分析モデル

　回帰分析注意点
　　関連度が高い要因


　心得１・論理モデルを仮定して要員を選定
　心得２・論理モデルから結果を評価
　心得３・定期的に評価を実施して重回帰分析が可能であることを確認する


・今後の分析作業
　問い合わせの内容分析

JBossMiddleware
・仮想データベース
・データグリッド
・ＢＲＭＳ．ＥＡＰ

まとめ

---

■カルテを患者に返すシステムの中核を担うSoftware Defined Storage
メディカルデータビジョンのひと

カルテ３千円から２万円、２週間くらいかかる

インフォームドコンセント
・診療の流れの中で
・５つの要素
　　開示
　　理解
　　提案
　　選択
　　同意

・アメリカから入ってきた
　→システム開発ではあたりまえ／医療ではかんじらない

・会社紹介
　医療や健康分野での活動を通じ、生活者のメリット創出に貢献します
　→患者のために活動している

　個人だとカルテが見れるサービス

　ＤＰＣ：包括請求
　　→ＤＰＣ分析

　どこでもマイ病院構想

　これまでは制度→システム
　今回はシステムがさき

・デジタル健康ソリューション「エースビジョン」とは
　病院基幹系→かるてこ
　　診療記録モジュール
　　カルテコ
　　ＣＡＤＡ

・ＣＡＤＡ：医療情報統合ＩＤカード
　ＣＡＤＡ提携医療機関なら、診察券になる
　診療記録一元管理
　情報を見るカギ

・カルテコ
　　診療記録
　　お医者様とのコミュニケーション
　　診療明細書＋お薬手帳＋生体検査＋コミュニケーション

・システム概要
　データセンターに入ってる
　患者に開示していいか、医師が判断できる：診療情報開示システム
　→RedHat Gluster Storage
　患者さんはカルテコでみる：ＣＡＤＡで認証

・ＤＢＭＳでなくストレージである理由
　すべての情報を一元管理
　災害発生時でもデータ閲覧が容易
　　画像ＤＩＣＯＭ、他はテキストデータ
　医療制度改定の影響を受けない（＝フォーマット変更の影響を受けない）

・要件定義からカットオーバーまで３か月

・担当者をアプリケーションエンジニアにしてみた

・複数のアクセス方法がある・オープンソースである
　病院ごとにアクセス権→ＳＡＭBAと組み合わせる：医療情報はパフォーマンスより質
　スモールスタートし、順次容量を追加できる

　サーバーはＤＥＬＬ

　クライアント増加時にパフォーマンス低下しないように
　　→病院ＩＤをいれハッシュ化

　りプレースの影響が小さくなること

　今後の展望に合致すること
　永続的に利用できること

2ちゃんねるの「みずほ銀行次期システム開発を見守るスレ」にマジレスしてみる

今,ＳＥＳ（っぽい請負、委任、派遣）市場を調べています。
その手の話といえばＪＩＥＴ，大型案件は「みずほ次期勘定系」ですよね！

っていうことで、「みずほ次期勘定系」を調べたいんだけど、
２ちゃんねるしか出てこない・・・

たとえば

みずほ銀行次期システム開発を見守るスレ16◆ [転載禁止]
http://hello.2ch.net/test/read.cgi/infosys/1440260984/

とか。

でも、そこに書かれていることが、本当だとすれば
（たぶん、わかっていない人が、テキトーに書いている部分も多い
　と思うけど、もし、かりに本当だとしたら）
日経ＢＰさん、ＮＨＫさん、取材に行ったほうがいいですよ！
スクープです。はい。これ、やばいです・・・

どれくらいやばいか、上記２ちゃんに書かれている内容に答えながら
説明する

---

■なぜ、JavaとCOBOLが採用されることが多いのか？

　このシステムに限らず、金融系はJavaとCOBOLが採用されることが多い。
　なぜか？これは、金融系のシステムで求められる要求からきている。

【COBOLが採用されるわけ】

金融系では、

・金額を間違えては困る。そしてものすごく大きな数字を扱ったり、
　ものすごく細かい数字を乗じたりする
　（例：１兆円２３４５億６７８９万０１２３円に
　　金利0.023％を乗じ、円未満を切り捨てる）
　そして、「有効桁数を絶対保証してほしい」という要請がある

・法律では、乗じたり、割ったりする順序が決まっている。
　例：１ヶ月分の給与を出し、百円以下を切り捨て、１２倍したものを１年の収入とする
　→３か月で１００万円もらっている人
　順番を変えられては困る：最適化しないでほしい。
　できれば、計算順序が明確にわかるように記述できてほしい

・夜間バッチの突き抜けは許されない！！！
　したがって、処理を起動したときに、必要な容量は確保し、
　処理スピードが予測可能であってほしい。

この要請、とくに最後の要請を満たすには、ダイナミックにメモリを
取る言語は使えない
（ダイナミックにメモリをとってしまうと、処理中にメモリ不足になったり、
　処理スピードが（スラッシング、ガベージコレクションなどで）落ちるので
　処理スピードが予測不能となり、最悪夜間バッチ突き抜けになる）

ＣＯＢＯＬは、メモリを動的にとらない。
そこで、とくにＪＣＬを使って動かす場合、はじめに資源をとり、それが
確保できれば、（ガベージコレクションが起こらないので）ある程度
いつも同じスピードで処理できる。
その上、有効桁数は、コンパイラの手引書に明示してあるし、
掛け算、割り算を明示して書きたければ、ＣＯＭPUTE命令をつかわず、
１つ１つ足し算なら　Ａｄｄ　なんとか　Ｔｏ　なんとか　とか
いちいち記述すれば、計算順番を明示して記述できる。
ということで、すべての要請にCOBOLはあっている。なので、ＣＯＢＯＬを
とくに夜間バッチでは使いたいと思う。

---

【Javaが採用されるわけ】

では、COBOLだけを使えばよいかというと、そうはいかない。
画面がある場合、COBOLでは柔軟な処理ができない。

たとえば、セッションの中に入るものは、
半構造化された非定形なデータであり、自分の処理に
関係ないものもある。
このようなものを、Data Divisionで定義するのは、難しい。

ＣＯＢＯＬは、構造化されたデータを、定形的に処理するのに向いている
（金融業はＧＵＩ以外、こういう業務が多い）

そこで、画面周り、通信回りの半構造化された非定形なデータを
扱いやすい言語が必要になる。これにはＪａｖａが向いている。

他のＷｅｂで使われる言語、たとえばＰＨＰ，Ｒｕｂｙ、Javascript
などは、型推論を行ってしまう。
１＋１＝１１なんていうのは論外としても、加減乗除の有効桁数、
優先順位などがはっきりしない言語は扱いにくい。
そういう点で、Ｊａｖaは、型があるし、最適化もコンパイルオプション
とかでカバーできそう？だし・・・という点でＪａｖa

---

【ただし、これは一般論で】

　みずほの今回の場合、Javaになったのは、人の集めやすさだと思う。
　人の集めやすさだと、ＰＨＰのほうが、安くていいけど、
　ＰＨＰにしなかった理由は、上記のように技術的に考えたんならいいけど、

　　　　中間搾取のしにくさ

（もともと単価安いことがわかっているＰＨＰは中間搾取しにくい）
　だとしたら、浮かばれないね・・・

まあ、技術的には上のような理由があるので、けがの功名ではある。

むしろ、Ｊａｖａ一択でなく、一部ＣＯＢＯＬになったことに
良心を感じる。

---

■ＪａｖａとＣＯＢＯＬの連携の難しさ

ということで、ＪａｖａとＣＯＢＯＬ両方使うとなると、
連携させないといけない。

連携させるには、
PIC 9（数字項目）とPIC X(英数字項目）のint,Stringへの
置き換え以上の問題がある。

【問題１】
Packed Decimalとか、数字を変わった持ち方をしたり、
同じ03句を書いて再定義（redefine　=CのUnion)することが、
ＣＯＢＯＬは、できる。

これを、Ｊａｖａでどう変換するか・・・は、いろいろ考えないといけない

【問題２】
COBOLの場合、なにもセットしないと、メモリー上にのこっているデータの値が
そのままだされる。つまり、それを印字してしまうとゴミが出力される。
(FILLERで、使わない項目でも）

そこで、これを防ぐために、集団項目にスペースを送る。
こうすると、数字項目でも（０でなく）スペースがおくれ、きれいに出力できる
（もしかすると、自分の使っていた（富士通）ＭＳＰ，ＦＳＰ，ＣＳＰだけの仕様かも？）

Ｊａｖａでこれを変換したら、もちろん、数字項目にスペースだから、
例外になってしまう。
しかし、集団項目にスペースを送るのは、動的な処理なので、
動かしてみないとわからない。

まあ、こんなことで「なんだあ　かんだあ　あり」、意外と変換は難しい。
基本的には、ＣＯＢＯＬ側で操作するのはたいへんなので、ＣＯＢＯＬ側は
単純に情報をセットし、Ｊａｖａ側で適宜変換してがんばるしかないのかなあ・・

---

■ノンプログラミングツール

　富士通のInterDevelopを使っているみたいだけど、ノンプログラミングツール
（超高速開発ツール）は、バズーカ砲みたいなもんで、目的地に正しく打てば
効果大だけど、まちがって、自分に向けて打っちゃったりすると、悲惨な結果になる。
ピストルで撃つよりも・・・

　現在のノンプログラミングツールは、設計書を必要とするが、要求段階、
設計段階で間違っている場合、ごみソースコードを急激に作ってしまう。
　そして、それに対応した単体テストを作られた場合、単体テストまで
一気に通るので、結合テストのときに、一気に問題が露呈し、収集つかなくなる。

　ただ、まったくの見当違いを設計することは少ない。
　（特殊ケースが抜けていたり、インターフェースミスが多い）
　なので、部分的にコメントにしたりすると、通ることがある。
　コメントにすること自体は、次のテストにすすめるために必要なこともあり
一概に問題とは言えない。しかし、いつかはコメントをはずし、テストしないと
いけないので、コメントにして通して、あとでやるということを忘れてしまうと
問題になる。

　さらに問題なのは、忘れたのでなく、進捗上、故意にコメント入れて通した
ことが報告されていないとすると、大問題で、あとで事件になる。

　なので、ノンプログラミングツールは生産性は高いかもしれないが、
「だから大丈夫」ということにはならない。なお、ノンプログラミングツール
自体のバージョン管理の問題とかあって、必ずしも生産性が高くなるとは限らないかも・・

---

■レビューしてもバグになる理由

上述のように結合テストでバグになる場合は、インターフェース等の問題が多く、
これは、特殊ケースのテスト項目を削ると、一見バグが減ってくるように見える。

この結合テストは設計書で発生しているはずなので（Ｖ字モデルでは）
設計書のレビューを徹底すればなくなるかというと・・・なくならない。

レビューには３種類の方法がある（一般に言われるのは後者の２つ）

・ただのレビュー
　文字の間違い、文章の間違い、コーディングルール間違いを指摘したり
　自分の価値観を他人に押しつけたりする。
　技術的に、あまり意味がない。

・ウォークスルー
　データまたはプロセスの流れに従って、間違いがないかを確認する
　機能仕様のチェックになり、結合テストのバグを減らせる

・インスペクション
　ある専門的な観点（データ処理方法、ネットワーク通信方法、セキュリティなど）
　からチェックをかける。
　主に非機能仕様のチェックになり、総合テストのバグを減らす・・・とうれしいが、
　主に、総合テストで問題が発生し、どうしようかというときに行う。

　インスペクションは品質管理部が行うので、現場では、可読性の高いプログラムを
書いておいてくださいと言われることがある（私は言われた）。
　なので、ウォークスルーをやるかやらないかが問題となるが、こういうことが必要
と知らない人が多いので、時間を取ってもらえない。結果、やらない。

そうすると、レビューしても、ただのレビューしかしていないと、結合でバグが
一気に出る。

---

■どこがやばいのか

前にＣＯＢＯＬを採用する理由は、処理時間が見えないからとか書いた。
で、Ｊａｖａを使っているとも書いた・・・
・・・ってことは、Ｊａｖａの処理時間は見えていない。

つまり、Ｊａｖａの部分は、ユーザーの処理能力要求（レスポンスタイム等）
をみたしているかどうかわからない。
これがわかるには、数理モデルを解くか、シミュレーションしないといけない。

しかし、シミュレーションなどを行うには、
通信を行う場合、インターフェース、つまりプロトコルと通信内容が
確定し、さらにその量が予測付かないといけない。

でも、これが完璧なら、結合テストは簡単に通るはず。
だけど、そうなっていない・・のなら、インターフェース部分に問題がある
可能性がある。ここがやばい！

つまり、やばい点は以下の２点（ただし、あくまでも２ちゃんねるからの推測で、
実際にはうまくいっていると・・・信じたい）

・プログラム間通信やインターフェースとなる引数の処理に関する
　チェックが甘く、バグやあいまいな箇所が存在する可能性がある
　→これを退治するウォークスルーのレビューも行われていない

・そのため、Ｊａｖａで、今の通信量、処理量で処理しきれるかどうか、
　問題がないかなどの検証が行えない／行っていない
　→総合テストでパフォーマンス不足を指定される危険性

---

■もし、この事態になっているとしたら、なぜ、そうなった。

　「インターフェースを管理する責任者がいないから」という可能性が高い
　　みずほＩＲは・・・実際の設計は、ベンダー各社の責任だよね
　　ベンダー各社・・・とはいえ、１社ではきめられないので・・・
　となると、責任者不在となる。この場合、ウォークスルーのレビューも行えない

　あらかじめ、インターフェースの確認をとるウォークスルーのレビューは
当然のこと、万全を期すため、ＶＤＭによる（形式）仕様化と、データによるテスト
を行えば問題はないが、さすがにそこまでやる気は、なかったのであろう。

　これを行わないと、とうぜん、Ｊａｖａでどうなるかというシミュレーションは
取れない。

---

■持ち直す方法

・現状を正しく把握する（本当にテストは消化できているのか？）
・インターフェースの部分のチェック
・シミュレーションなど

なお、これはあくまでも、２ちゃんねるの内容から妄想したものであり、
現実にこんなにひどい・・・ことはないよね（＾＾；）

今どきの数学科って、wordやexcelの使い方とかやるの？

ここ

http://www.keikotomanabu.net/college/manabu/CT0000043_CP0000031/


へ～、そうなの？
東京大学理学部数学科と、アビバと同じことやるのかしら？？？