クラウドのトレンドが世界をどう変えるか？

Oracle CloudWorld Tokyo 2015のビデオが
http://www.oracle.com/jp/corporate/events/oracle-cloudworld-tokyo/index.html
に、公開されている。その内容をメモメモの続き

Cloud Leadership Summit
クラウドのトレンドが世界をどう変えるか？

をメモメモ

---

一言で言うと　人は石垣人は城

クラウドのトレンド、ビジネス戦略
　合計すると１０兆円、４５万人

日本オラクルの状況
　情報量　５０倍
　いやな思い→つぶやく→取引停止

日本企業が直面する課題　少子化・グローバル
　海外投資１３兆円を超える

ラリーさんに：DBのキングをつくったことについて
　最初日本に来たのは富士通で仕事する為
　　　IBMコンパチ：
　JRで通勤、日立市にも

　Oracle作ったら→日本を考えていた

　新幹線：ローマ字で書いてあるので楽
　漢字だと大変

G5

NTTデータさん：どういうふうにクラウド戦略？
　　バチカン図書館のデジタルアーカイブ
　　　８万２千→保存、デジタル化したい
　　　世界中で研究してほしい
　　いま、どういう時代か
　　　→第三の波
　指数関数的に伸びている
　　CPU,ストレージ、ネットワーク
　デジタルワールド：IoT
　指数関数：あっという間に変化

　NTTテクノロジーフォーサイト
　　　技術の将来が未来
　　情報源
　　外部環境分析
　　社会トレンド
　　　１ぱわーおぶいんでぃびじゅある
　　　２．こらぼれーしょんばりゅー
　　　３．
　　　４．
　　技術トレンド：８つ
　　　人体、３D

　相手にしてるのは、個人、企業、国家？

むすびつける

NECさん：
　２０５０年の地球
　　　人口１．３倍／都市人口１．８倍
　　　でも日本１億２千→８０００万（２／３）
　　　食料１．７倍、水１．６倍エネルギー１．８倍
　　　　→どういうネットワークを作る？
　　ICTカンパニーが貢献
　　社会ソリューション：価値提供
　　社会価値創造：７つのテーマ
　NEC
　　ITそりゅーしょん・そふとうぇあ：ダイナミック→ビッグデータ、画像処理
　　こんぴゅーてぃんぐ：りあるたいむ→クラウド・スーパーコンピューター
　　ねっとわーきんぐ：リモート→SDN

　IOT
　　クラウドの価値とセキュリティから

　NECのアセット

CTCさん：
　エンタープライズクラス・ハイブリッドクラウド
　毎日あるきまわる
　人口の話
　　１つの県ぐらいの人口が４年で減る
　　いまから３５年間で、大きな県がなくなるくらい
　　新入社員ラッキー：ITの会社、高齢化先進国→輸出できる

　日本：クラウド化→電気は自家発電していない
　　　　なっとくできるストラクチャー

富士通さん：
　どのようなジャンルで使うと面白いか
　社会のイノベーションを通じて豊かな未来を実現する

　ビジネスイノベーション
　ソーシャルイノベーション

　デジタル対応とワークスタイル革新　Alma　Media(フィンランド）
　医療分野でのクラウド利用→社会保障制度おおきいのは医療
　　　　　地域連携、遠隔医療
　農業分野でのクラウド利用：農業変えていく→サプライチェーンも含め
　クラウド時代のエコシステムに向けて→より強固なパートナーシップへ

Q&A
富士通さん→ラリーさんへ
　IaaSは？そらりす？
　　コモディティ：決してマイナスでない。電気もコモディティ
　　コモディティ：低コストが鍵→コストアドバンテージがある
　　２１世紀への移行
　　　　Infini バンド使ってみる、コスト下げる
　　　　ストレージ周り
　　　　インフラ、CPUまだまだ発展
　　おもしろいのは、クラウドでどのプロセッサ使っているか聞かない
　　　→いろんなストレージ組み合わせて
　　　　データセンター：大掛かりなものが生き延びる

CTCさん→ラリーさん
　７つのデータセンター適切な場所に適切なサイズ
　日本において、データセンターをどういう風に作っていこうと思ってる？

　日本：パートナー　世界のほかの地域とは違う
　自社のデータセンターを作る／パートナーのDCでデータベースをサービスとしてうける
　　オラクル、パートナー、お客様

NECさん→ラリーさん
　IOT世界中に
　　国の中での重要データ、
　　世界中のクラウド連携で価値を作る
　どういう環境の作り方？

　そもそも、サンマイクロをなぜ、オラクルは買収したのか
　　技術、とくにJava
　　データ：コストを安く集める
　　　　土壌のモニタリング
　　　　数知れないデバイス
　　　　Java、微細化できる→データ回収
　　　　高い価値を生み出し、安いコストで→Javaをセンサーに

　IoTのセキュリティ
　　人も繋がっていく→脆弱性のリスク
　　いろんな事件
　　これまではコストパフォーマンス、これからはセキュリティ

NTTデータさん→ラリーさん
　　接続されるデバイス数
　　データ容量
　　データの多様性：非構造化データが指数形に

　１．非構造化データXBRLチャールズホフマン
　　　レポートに非構造→DBどう考える

　分散型コンピューティング
　　自動運転：発生源で処理→エッジコンピューティング
　２．これらに対してどう考える

　エッジコンピューティング
　　飛行機自動パイロット、航空管制
　　　→クラウド（航空管制）が間違っていたら？
　　飛行機で出来るのなら、自動車でも出来るだろう
　　　→自動走行車はでてくる
　　クラウドで経路を教えてくれる

　非構造化データ
　　Hadoopと密結合
　　SQLインターフェースをHadoopの上におくと混ぜられる
　　ただ、まざるのが問題
　　でもHadoopはリアルタイムでないので、航空管制には使えないけど
　　ビッグデータ：幻想をつくる

日本オラクル→ラリーさん
　日本企業向けに何か？
　　みきたに社長から招待うけて講演
　　４５年通ってる
　　スタートアップ企業大幅に増えた
　　大手にしか出来ないこともある：マイクロプロセッサ
　　アメリカ：大手企業と提携
　　日本：イノベーション起こそうとしている
　　　　エコシステム誕生しつつある

まとめ
　最高のクラウドを提供する相互協力する枠組み
　　WG

２０年前のアプリケーションをデータセンターに移行しても、それがクラウドではない－ラリー・エリソン

おおおお、モダナイゼーションの真っ向否定だ。
ま、そうなんだけどね・・・

Oracle CloudWorld Tokyo 2015のビデオが
http://www.oracle.com/jp/corporate/events/oracle-cloudworld-tokyo/index.html
に、公開されている。その内容をメモメモ。

まずは、ラリー・エリソンのキーノートスピーチより

---

Modern HCM is Social HCM

・人材管理アプリケーション紹介
　クラウドアプリケーション
　いままでと同じではない

・２０年前のアプリ→サーバーで提供
　それがクラウド？
　Ａｍａｚｏｎに移行、それがクラウド？そんなもん？
　そうでないと思う

・クラウド：既存のアプリをＡｍａｚｏｎに持っていく
　そうでないと思う：異なった見栄え

・世界中重要なアプリ
　　人材管理：　
　　　社員：重要→労働不足：ロボット
　　　お客様対応
　　従業員の効率性に話し集中

モダンなクラウドアプリ
　　人材を見つける　facebook,Twiter,LinkedIn
　　　→１０年前にfacebook,Twiter,LinkedInはない
　　　　古いアプリは的確に機能しない
　　それ自体がソーシャル
　　　すべての従業員が使う→ほかの従業員とやり取り
　　　→１０年前はソーシャルない
　　マニュアルない＝使いやすい、なじみのあるインターフェース
　　　Facebook,Twitterインターフェース、SAPとは違う
　　　今までトランザクションがあって処理
　　　　　　データウェアハウス、ＢＩは別々にあった
　　　　→いまは統合
　　　　　予算超えたらアラート
　　運用ははるかに、はるかに安い
　　　　なぜ、トレーニングコスト下がる？
　　　　→いまのコンシューマーになじみある
　→ビジネスに注目すればいい

自動車メーカー、電力会社→プロ
　ＩＴインフラも→プロ

従業員の口コミ
　ソーシャルネットワーク：人のネットワーク
　優秀な人材の獲得

ＨＲシステム→トレーニングシステム
　　人にお金をかける
　　オンライン大学→自社でやっていくべき

一人ひとりが発電するのは・・・
　→自社でデータセンター？井戸作ってる？
　　自社のデータセンターを自分で運用する理由はない
　→規模の経済、専門性、低コスト
　　中規模企業がＥＲＰできる

日本に大きなデータセンター解説
　　→今世界中に１９、２００国以上
　　　ＳａａＳ　Ｎｏ２（セールスフォーストップ）
　　　　→クラウドでＯｒａｃｌｅがセールスフォース上回る
　　　ＳａａＳの２０社中１９社がプラットフォームでＯｒａｃｌｅ
　コンピューティングサービス：ユーティリティ化

アプリケーション組みなおす
　　昔、ＳＡＰが１番、Ｏｒａｃｌｅ２位だった
　　→参入に８年間：世界変わったオンプレミスから新世代
　　今、ＳＡＰはクラウドで目に付かない→再開発しようとしていないから

　今はＡｍａｚｏｎと競合
　ＰａａＳ：Ｏｒａｃｌｅデータベース人気（セールスフォースも）
　　　　　　オンプレミスでもクラウドでもＤＢはＮＯ１
　ＩａａＳ：Ｓｕｍマイクロ買収、
　　　　　　オープンソース
　　　　　　ハードＩＢＭと競合、今Ａｍａｚｏｎ競合

ＨＣＭ：ゼロから急成長

今まで買えなかった会社→クラウドでより早く、よりやすく

ソーシャルモバイルＨＣＭスイートＩｎクラウド

　　ＳａａＳ：人事管理など・・・
　　ソーシャルネットワーク
　　拡張可能プラットフォーム：ＤＢ、Ｊａｖａ
　　インフラ　ＶＭ、Ｌｉｎｕｘ

ＨＲ→プロジェクトマネジメントも
ＵＩ→Ｔｗｉｔｔｅｒ
全てがモバイル対応、全てがソーシャル対応

クラウドを使い始めた
　　→データセンターの移行：ホスティングという
　　　　→真のクラウドではない

トレーニング最適化、適材適所、総合的に力をつけさせること可能
→アメリカ：深刻な課題
　日本：転職しない？変わってきた→やめる人材予測できる

アクショナブル・インサイト
　スウェーデン：従業員の性別をトラッキングできない
　　　→各国のプライバシールールに対応できる
　　　　でもＤＢは１つ

スマホの上で実行できる。
　　→AndroidでもiPhoneでもタブレットでも
トレーニングも
近代的なアプリ：プラットフォーム上に
　　Ｊａｖａ，ＳＱＬ
クラウドにフィーチャー追加

---

マトメがここにあるね

えせクラウドにだまされてはいけない、ラリー・エリソン
http://ascii.jp/elem/000/000/998/998722/

(以下太字は上記サイトより引用）

今回のことば

「これはクラウドだと自分を騙していないか。騙したままだと敗者になる」（米オラクル 取締役会経営執行役会長兼CTOのラリー・エリソン）

ビッグデータ時代にＣＲＵＤはキケン！

このまえ、ちょっと話していたら、
「生成があるなら、削除があって、当たり前」と言っていたけど、
その考え、最近キケンになってきたので、
ちょっとコメント

---

■昔ＣＲＵＤってのがあった。

たしかに昔
　Ｃ：生成
　Ｒ：読み込み
　Ｕ：更新／書き出し
　Ｄ：削除
ということで、データの生成から廃棄までのＣＲＵＤを明確にして
チェックしていた時代があった（ＣＲＵＤ図を作って）

でも、この考えは、ビッグデータ時代になって、危険ということに
なってきた。ＣＲＵＤに基づき、削除してしまうと、バグの温床に
なったり、重要なお宝データが消えてしまうのだ・・・

---

■過去は、消せない

この理由は、ＣとＵは、Ｄよりも過去に行われた行為だということ。
過去は消せない。消してはいけない。

例を挙げる。

Ａ社にＸ，Ｙ，Ｚという商品を販売し、
その後Ａ社が倒産、取引はなくなったとする。

ここでＡ社データを削除してしまうと、
Ｘ，Ｙ，Ｚの商品を売ったという販売データが
　ＩＮＮＥＲ　ＪＯＩＮなら、なくなってしまうし
　ＯＵＴＥＲ　ＪＯＩＮなら、仕入先が分からなくなってしまう

ということで、お宝ビッグデータが消えてしまうわけだ。
過去に売ったという事実は消せない。
だから、残しておかないといけない。

---

■論理削除にすればいいという問題じゃない！

ここで、「じゃ、論理削除にすればいいじゃない」というのは、
問題を分かっていない。

いまはＤの話をしたので、消えたという話をした。
過去は消せないという構図はＵでも同じ。

例えば、Ａ社は東京から大阪に移転したとしよう。
単純に得意先データの住所を東京から大阪に移してしまうと、

地域別の集計をしたときに、Ａ社の購入はすべて大阪として処理される
昔東京で買ったときも・・・

---

■対策は２つ。大福帳と追記

そこで、今ドキ、この手の問題を解決するのに２つの方法がある。

１つは、正規化せず、必要な情報はすべて載せてしまう、大福帳システムにするというやりかた
具体的には、上記の販売データの場合、販売データ内に、得意先コードだけでなく、
得意先の住所（地域につかう）、得意先名など、検索に必要なデータはすべてセットして
しまうという方法。RedShiftなどでは、こちらが向いているといわれる。

もう一つは、追記型。
主キーのほかに、タイムスタンプも使って一意にし、
更新があるときは、主キーは一緒、タイムスタンプが現在時刻としたデータを追加（追記）し、
削除は削除フラグを上げて、主キーは一緒、タイムスタンプが現在時刻としたデータを追加（追記）する。

そして、マテビューを１個つくる。
それは、主キーでＧＲＯＵＰ　ＢＹして、タイムスタンプがＭＡＸのレコードだけを集める。
こうすると、最新の(状態の）レコードがわかる。

販売データを検索するときは主キー＋タイムスタンプで
販売データを作成するときは、マテビューから主キーで検索、そのデータを保存する。

---

って方法をとる。だから、「削除があって、当たり前」っていう考えは、キケンなのだ。

その「大学院は簡単に入れる」といわれる東京大学大学院に落ちた人の立場は（＾＾；）

【エンタがビタミン♪】たかまつなな“東大大学院合格”のニュースに批判続出。「大学院は簡単に入れる」
http://japan.techinsight.jp/2015/04/takamatsunana_toudaidaigakuingoukaku1504291125.html


ごめん、その簡単に入れるという、東京大学大学院に落ちて、
ほかの某国立大学の大学院に行った私の立場は？

（ただし、「たかまつなな」さんの合格した東京大学大学院情報学環教育部ではなく、私が受験したのは、東京大学大学院工学系研究科　技術経営戦略学専攻だけど・・

　っていうか、情報学環は知ってたけど、そこに教育部なんていうのが
あるって、初めて知った（＠＿＠！）


ちなみに、もっと聞きたいのは・・・

その「簡単に入れる」という東京大学大学院に落ちた
私でも入れた某国立大学の大学院に、落ちた人の立場は・・・？
（ちなみに私が行っている某国立大学の大学院は受験生が毎年１００
人くらいいて、合格者は３０人くらいだから、落ちた人はいるはず・・・）

マイナンバーでやらなければいけないことを、まとめてみる

【企業側】

（１）マイナンバーを集める
　　社員のマイナンバーと、扶養家族のマイナンバーを集める
　　社員に利用目的を告げる→利用目的以外のマイナンバーは使えない

（２）本人確認する
　　マイナンバーがあっているかを確認しないといけないので、
　　運転免許だけではＸ
個人番号カード（番号確認と身元確認）
通知カード（番号確認）と運転免許証など（身元確認）
個人番号の記載された住民票の写しなど（番号確認）と運転免許証など（身元確認）
　　で確認する。

　　http://www.cas.go.jp/jp/seisaku/bangoseido/faq/faq4.html#q4-3top

（３）源泉徴収票など、法定調書の変更
　　パッケージソフトを購入している場合、バージョンアップすればいいようになると思うけど、

　　　その場合、バージョンアップは可能か？（ＸＰに対応してくれるとは、かぎらないよ）
　　　マイナンバーをどう入力するか
　　　費用は？
　　　これをきっかけに調書の大幅変更はないか＊

　　などの確認は必要。
　　なお、法定調書には、個人番号（マイナンバー）の他に、法人番号が入ることもある。
　　また、法人番号は、なんに使ってもかまわないし、調べることも出来る

　　＊例えば、源泉徴収票には、扶養家族のマイナンバーのほか、個人名も入る。
　　　ということは、その領域が増えるはずで、ということは、そこの入力の手間もかかるはずだ・・

（４）マイナンバーの管理
　特定の人にしか、アクセスできないように管理しないといけない

DBセキュリティ見直しにも影響するマイナンバー安全管理の“要件”と“盲点” (2/3)
http://www.atmarkit.co.jp/ait/articles/1501/19/news028_2.html

にあるように、スーパーユーザーでも、マイナンバーを見れてはいけない。
つまり、スーパーユーザーもＤＢのデータ項目にアクセスできないような特権を
かける必要がある→Oracle Data Vaultの利用？

（５）業種によっては、対応が必要

・たとえば、配当金には、マイナンバーがいる。
　　→銀行、証券
　　→未上場の企業が、株主に配当を払う場合

・生命保険の支払い調書にも
　　→保険業
・講演を頼んで、謝金を払う場合→支払調書にも
　　→いろんな業界

　　なお、謝金をする場合、本人確認も必要になることになる。
　　番号、間違えて書いたら、大変だもんね！


【個人・みんな】
・マイナンバーの連絡の紙をもらったら、なくさないようにする
　　→本人確認に必要
・できれば、個人番号カードを作ったほうが良いのか？

「お薬手帳」共通化へ－なにが便利になるのか？

電子版「お薬手帳」共通化へ　厚労省、利便性向上に向け標準仕様の構築検討
http://news.goo.ne.jp/article/sankei/life/sankei-lif1504260012.html

なんだけど、そもそもみんな、お薬手帳って、知ってるんだろうか？

こんなかんじ・・・

この中は、こうなっている

飲んでいる薬の一覧、出している医療機関などが分かる

最後のページには、かかった病院も！

お薬手帳のほかに、薬局では、こんな紙ももらう

飲んでいる薬の説明。この薬局では、
ジェネリックとの薬価の違いとかも出ている。

---

これが、電子化されると、どういいのか？

■まず、救急搬送された場合

現在、お医者さんは、今飲んでいる薬は、わからない。
何処の病院にかかっているかも、わからない・・・
お薬手帳を持ち歩いている人はいないので。

お薬手帳が電子化され、見えれば、
たとえ救急搬送で、その人がしゃべれなくても、
どの薬を飲んでいるかがわかるし、
どの病院にかかっているかもわかる。
　→カルテとかも回してもらえる？

もちろん、マイナンバーが医療で使えれば、
マイナンバーだけで分かるけど、
それは今のところ出来ないので（法案が通らないと）
それまでは、お薬手帳の電子化は、意味あるのだ！

---

■つぎに、勘違いが防げる。

同じ薬でも、グラム数が違って、数種類でているものもある。
ここで、２０ｍｇのものを２錠飲んでいたが、
違う病院にいったら、４０ｍｇしか、扱っていなかったとする。
当然、１錠になるわけだ・・・

でも、患者はそんなこと知らない。
いままで、２錠飲んでたのに、なんで１錠なの？
とか言われたら・・・
・・・お薬手帳みないと、説明つかない、確認できない。

そのへんが、一発で説明がつく。

---

それと、これは今回のお薬手帳共通化では、そこまで出来ないかもしれないが、
紙の今のお薬手帳の場合、

■アレルギー、副作用、既往歴なども記入できるので、
　いろいろな医療情報が引き出せる。

それも、本人が分からなくなっても（認知症はもとより、単に忘れた場合でも）

---

ということで、お薬手帳の電子化、どうでもよいように思えて、
結構奥深いのだ・・・

ＪＶＭの動きと、ＧＣについて

4月24日(金)にJJUG ナイトセミナ 「Javaのプログラムはどうやって動いているの?」に行って来た。
その内容をメモメモ

---

■Javaのプログラムはどうやって動いているの？ＪＶＭ編

アジェンダ
・ＪＶＭ
・Ｃｌａｓｓファイル
・mainを実行するまで
・バイトコードの実行

桜庭さん@skrbの自己紹介
・Javaチャンピオン
・Java in the BOX
・ITPro Java技術最前線
・ごちそうフォト

ＪＶＭ

Virtual Machine
　プログラミング言語を解釈し
　コンピューターで実行するソフトウェア
　　・JavaVM
　　・.net CLR
　　・Small t5alk
　　・Write Once,Run Anywhere

Java Virtual Machine
　バイトコードを解釈して実行
　基本はインタープリタ
　実行時コンパイル
　　　Just-in-Time Compile

Today's Sample

Classファイル
　.java→Javac→.classファイル

　クラス定義
　フィールド定義
　メソッド定義
　　　↓
　クラス定義
　フィールド定義
　バイトコード

　定数プール：文字列、リテラル
　属性：型パラメータとか

Javap：どういうバイトコードか？
　バイトコードの逆アセンブル
　javap -p -c クラス名
　　-p　プライベート
　　-c バイトコード
　javap -p -v クラス名
　　-v バイトコード＋定数プール

Java仮想マシン仕様

mainを実行するまで
　1.JVM起動
　2.クラスロード
　3.リンク
　4.初期化
　5.main実行

JVM起動
　JNI_CreateJavaVM()

クラスロード
　classファイルの読み込み
　使用するクラスを芋づる式にロード
　 java -verbose:class Test
　rt.jar Java9から必要ないのは読み込まないように

リンク
　classファイルが正しいかチェック
　staticフィールドの初期化
　　ただし、Javaコードの実行はしない
　　finalでもnullが入る
　クラス間の関係を解決

初期化
　staticフィールドの初期化
　　javaコードも実行 finalの値入る
　staticイニシャライザの実行

mainメソッドの実行

Java puzzle:Anniversary

バイトコードの実行
　１．キュー
　２．でっく(Deque：できゅーではない）
　３．スタック
　４．リングバッファ
　５．マップ（連想配列）
　６．リンクドリスト（リスト構造）

java.utilのstackは使ってはいけない
　古い
　ArrayDequeを使う

スタックがメイン

Stack
　LIFO
　途中の要素のアクセスはダメ

実行形態
　スタックマシン：中間状態をスタックに
　　　JavaVM,.net Framework CLR,PS
　レジスターマシン：Intel Core,ARM Cortex
　　　ダルビック

逆ポーランド記法

中間の状態をスタックで取る
　　ヒープ
　　メタスペース（パーマネント領域）
　　スレッドごとにスタックがある

Ｊａｖａ　Ｓｔａｃｋ
　　プログラムカウンタ（ＰＣ）
　　フレーム

　０番目 This
　そのあと引数が積まれる

ＪＶＭ編conclusion
・マカロンスタック
　　マカロンは積むもの

Java Javac Classファイル：バイトコード
　ＪＶＭ起動
　クラスロード
　リンク
　初期化
　main実行
JVM:Stackマシン

サーバー系はむちゃくちゃ読み込む
互換性：検証でチェック
　OracleのJavacとeclipseのJavacでバイトコードは違う
　Java SE7までは、互換性は取れている（実行結果は同じ）
　ただし、ＶＭの解釈は、実装依存

---

■Ｊａｖａのプログラムはどうやって動いているの？ＧＣ編

アジェンダ
　Why to Use GC
　Mark & Sweep GC
　Copy GC
　世代別GC

Why to Use GC

ＧＣ
　Garbage Collection
　　メモリの自動管理
　　不要になったメモリを自動的に回収

Ｂｅｆｏｒｅ　ＧＣ
　自前でメモリ管理
　　Ｃ
　　　malloc(),calloc(),realloc()
　　　free()

問題点
　　メモリの解放し忘れ
　　二重開放
　　無効な参照
　メモリ周りのバグは修正が難しい

１９５９：いちばんはじめのＧＣ
　　John McCarthy Mark&SweepGC Lisp向け
一般的に使用されだしたのは９０年代
　　ＣＰＵ、メモリ性能向上

ＧＣ
　アルゴリズム
　　ベーシック
　　　　Mark&Sweep
　　　　参照カウント
　　　　Copy
　　複合
　　　　世代別
　　　　Ｇ１
　運用
　　　　シリアル
　　　　インクリメンタル
　　　　コンカレント
　　　　パラレル

JavaVM：参照カウントだけない。他はある
　デフォルトＣＭＳ：コンカレントでMark&Sweep

ＧＣ本　中村さん

Mark&Sweep
　Mark：使用中のオブジェクトをマーク
　Sweep：マークのないオブジェクトを掃除

　Rootから芋づる式にマーク→深さ優先探索
　先頭から未使用ObjをFreeListへ

Compactionも一緒にやる
　→コンパクトにする

いい点
　実装がシンプル
　参照の書き換えがないので安全（コンパクションしない限り）
　　→保守的ＧＣ
欠点
　おそい
　Stop-the-worldの時間が長い
　ヒープの断片化がおきやすい（コンパクションしない限り）

CopyGC
　ヒープを２分割
　使用する領域は一方のみ
　片方からもう一方へObjをコピー
　使用する領域を反転
→コピーすることでコンパクションと同じことができる
利点
　stop-the-worldの時間が短い
　ヒープの断片化が起きない
　高速なアロケーション
欠点
　ヒープの仕様効率が悪い
　参照の書き換えがある

世代別ＧＣ
　仮説：若いObjほど早く死ぬ
　世代別にヒープ管理を行う
　　Young世代　高速なＧＣ→Copy
　　old世代　安定したＧＣ→M&S
　Objの年齢：ＧＣを生き延びた回数
世代別ＧＣ
　Young
　　　servivor1,servivor2,Eden
　old
　　　tenured
新しいＯｂｊはYoungへ配置→Eden
　　ＧＣ：edenからservivorへ
　tenuredがフラグメンテーション→コンパクション→FullGC
　領域サイズはチューニングが必要
　old世代のＧＣをなるべく減らす
　ＣＭＳ，Ｇ１ＧＣなどの派生ＧＣあり

Conclusion
　Ｍ＆Ｓ、Ｃｏｐｙ、世代別
　原理を知って、チューニングに活かす

「ジャパネットたかたがモダナイゼーションした理由」を聞いてきた

きのうの、ＩＴモダナイゼーションSummitを聞いてきた。その内容をメモメモの続き。
ＩＴモダナイゼーションSummitのメモは、これで終わり。

---

■ジャパネットたかたがモダナイゼーションした理由
ジャパネットホールディングス

Windows95　ＮＴ４．０
　モダナイゼーションした
　ダム端からＧＵＩにラッピング→２００９年まで

会社概要
・事業方針
　１．メディアミックス　紙４０％
　　　テレビで紹介→チラシ：結果的には
　２．自前主義

ビジネスニーズ＝スピード開発
１．全部門が自部門のカイゼン改革に取り組み
　　データ連携
２．各部が一斉に改善改革に取り組むとシステム部がボトルネック

開発スピードがボトルネック
１．システム構築をベンダーに依頼
　ＣＯＢＯＬと４ＧＬ
　汎用機とＶＢをキューでインターフェース

２．生データはデータベースにある

移行前システム構成

汎用機ホスト
　基幹系
　　ＣＯＢＯＬ８５万ステップ
　コールセンター
　　ＶＢ（２０万）
　物流
　　Ｃ言語


Ｕｎｉｘサーバー
　ＥＣサイト
　　ＪＡＶＡ

Windowsサーバー
　情報系
　　ＡＳＰ（９８万ステップ）

２００８年：レスポンス遅くなる
　端末（コールセンター）６００台
　　→キューに５０、１００たまる

安定稼動スピード開発の戦略
汎用機からダウンサイジングを通して自社開発体制を実現する

ソフトウェア資産として成長させる

両立；自社化
　安定したインフラを確保する　ＩＴ専門：社外

　業務の先読みで開発スピードを上げる　業務：社内

１．アーキテクチャ
　シンプル／理解できる／ボトルネック
２．プロジェクトマネージメント
　３点レビュー／規模／ＰＭ
３．規律
　資産／整理／最小ドキュメント

何を捨てたか：
・ドキュメント
・理解できるものに絞った

安定とスピードをどう維持するか
・どうなりたい
　　稼動に責任、開発に責任
・なぜか
　　障害をリカバリー
・どのようにする
・どう維持する

開発体制をどう構築したか
　ダウンサイジングを実現する要員の育成
１．中途採用で経験者を募集、不足分はベンダーから派遣し、
　　開発要員確保

２．自社内でダウンサイジングを完結させる

開発体制の経緯
　いたく開発
　システム主導開発
　現場手動

ＣＯＢＯＬのビジネスロジックをしっかり生かす
ＯＲＡＣＬＥ利用ＳＱＬ
　　早いハードとＤＢ
　　ＳＳＤ（半導体ディスク）
　　ＰＢＸ２倍
　　ＥＣサイト３倍
　　Ｆｌａｓｈ導入

何を経験したか
１．チューニングと生涯対応を経験
　　１０００台からの同時受注トランザクション処理
２．基幹のビジネスロジックの移行
　　ＣＯＢＯＬは使える
　　ＩＢＭ　ＭＱ→安定したインフラ
３．自社で理解できる技術を選択
４．動かせないデッドライン

言語にこだわらない理由
１．目的に応じ、特性に合致した開発言語を選択すればよい
　　　ＥＣサイト　Ｊａｖａ
　　　ビジネスロジックはＣＯＢＯＬ
　　　ジョブ制御ＪＰ１

ソフトウェア資産を維持継承する
１．採用言語として周知する
２．常にシステムを整理整頓し、ソフトウェア資産とする

システム開発のステージ
１．いたく開発
　　　　要望を抑え手作業
　　　　運用整合性
　　　　開発が遅い
２．システム主導開発
　　　　目に見えるものの自動化
　　　　運用整合性／開発生産性／開発生産量
　　　　優先すべきものが優先されない
３．現場主導開発
　　　　業務の精度を高める高度な自動化
　　　　運用整合性／開発生産性／開発生産量／改善効果
　　　　現場ＩＴ要員確保

・ビジネスロジックは手を付けない
・パフォーマンスは枯れた技術で

基幹系ＣＯＢＯＬのデータでビッグデータ解析する日立「データ連携統合基盤」って・・

きのうの、ＩＴモダナイゼーションSummitを聞いてきた。
その内容をメモメモ。

IBM AS/400移行と、
基幹系ＣＯＢＯＬのデータでビッグデータ解析する日立「データ連携統合基盤」の話

---

■なぜIBM i(AS/400)のモダナイズはコスト高になるのか
－自動解析＆再設計ツールがもたらすコスト削減について－
第一コンピュータリソース

会社案内

本日お話したいこと
　背景
　　見積もり
　　マイグレーション手法
　ＤＣＲの試み
　ご紹介したいこと

きっかけ
・ＩＢＭ　iのモダナイゼーション案件の急増

こんなことになっているらしいです・・・
・今後の維持する体制のリスク

問題発生
・リソースの規模
　　平均２０００～４０００プログラム
・機械的ストレートコンバージョン
　　→ハードの壁：全部はコンバートできない
・塩漬けのまま
・パッケージに適合できない
・見積もり→むずかしい

いままでの見積もり
・どんぶり勘定

見積もりのための見積もり
・事前調査→お金かかる

見積もり時点の解決策
・ソフトウェアメトリクス

ソフトウェアメトリクスで何が量れる
・機能量
・開発期間
・工数
・生産性
・信頼性

量ったらどう役に立つ
・平均と比べ、どれだけ逸脱
・過去と比べて変化しているか
・将来予測

例
・ソースコード
　　循環的複雑度
・要求や仕様
　　ＦＰ
　　ユースケースポイント
・プロセスのメトリクス

結構手間かかるよね
・静的解析に絞る
・自動解析で

ツールを探せ
　設計書リバースツール？？
　似て非なる設計情報解析ツールの存在
　X-Analysisとの出会い

X-Analysisとは／できること

カイゼンできたこと
・精度の高い見積もり

見積もり事例
・桁数変更→キーフィールド
再構築中

ソフトウェアメトリクスを用いたアセスメントサービス
（サービスの紹介）

再設計の効率化への試み
　　ＶＳＳＤに流す
再設計モデルからアプリケーションジェネレートへのこころみ
　　ＶＳＡＧ

---

■ＩＴの力でビジネス力をアップする基幹データ活用方法のご紹介
日立製作所

ＩＴモダナイゼーションとは
・リホスト　ＣＯＢＯＬ→ＣＯＢＯＬ
・リライト　ＣＯＢＯＬ→ＣＯＢＯＬ＋ＪＡＶＡ
・リビルド　ＣＯＢＯＬ→ＪＡＶＡ
・リドキュメント

個別最適のＩＴモダナイゼーションから全体最適へ

新しいＩＴモダナイゼーションを提案
・データ連携統合
　　収集：リアルタイム収集
　　蓄積・加工：標準化
　　活用：見たいときに見たいデータに

コンテンツ
　現在活用しているデータ
　　基幹システムのログデータ
　今後
　　個人データ

データ活用に求める目的
基幹システムこそ、価値あるデータの宝庫
→どのように取り出せばよいか
　どのように活用するか

活用例
・グローバルでの「生販在計画」の見える化
　→必要なデータをバッチプログラムで収集し、統合
　　　→時間かかる／新たな分析視点への対応が難しい
　→ほしいときにほしいデータが入る

・ＰＯＳデータを活用し、お客様に近づく
　　売り場のデータを活用したお客様の理解
　　お客様に近づくほど、ビッグデータ処理が必要
　→データマートレス化
　　時間帯別集計、バスケット分析の実現

データ利活用を実現する新しいＩＴモダナイゼーション
データ連携統合基盤
　　１．データベースの変更情報を自動収集
　　　　更新検知エージェント
　　２．形式の異なる大量データを加工・蓄積
　　３．必要なときに必要なビューで：論理ビュー

本日お話したかったこと
　データ連携基盤

ワークショップに参加しませんか

---

要するに、日立「データ連携統合基盤」って、
OracleのGoldenGate＋αってかんじ？

麻生さんより、中国人記者のほうが、無礼だろう！

中国人記者への対応に波紋＝麻生氏に批判相次ぐ

(以下太字は上記サイトより引用）


麻生太郎副総理兼財務相が今月３日の記者会見で、中国主導のアジアインフラ投資銀行（ＡＩＩＢ）への参加を見送った日本政府の対応を「野党が批判している」とただした中国人女性記者に対し、笑った上で「うちは共産主義じゃないから中国と違って（野党が）何でも言える。パクられることもない」


そのとおりだ・・・なんか、文句あるか？


李さんによると、ＡＩＩＢについて日本語で質問すると麻生氏は「ハハハ」と笑いだした。さらに李さんが質問を続けようとしたところ、挙手しなかったことから英語で「ここのルールを知らないのか」と述べた。

挙手しないほうが悪い。ルールは守れ！


中国のネットでも「記者に対して失礼。重大な差別だ」


は？麻生さんに失礼なのでは？
記者がなんぼのもんなんだ・・

この記者、日本の大臣バカにしてるだろう。
だから、中華思想はこまる
（中国人を尊べ、自分はルール違反してもかまわないが、
　日本人は、中国人に服従し、大臣でも、何でも答えるべきだという発想）

　そもそもＡＩＩＢは中華思想。
　なんで、外国も拠出するのに、中国が使途を多く決められるんだ？
　普通に考えたら、出資しないだろう・・・

Ｐ．Ｓ
このブログは、基本的にはコンピューターだが、
放送、マスコミも扱っているし、
麻生さんは、アキバ系なので、ここに載せてみました。

KNOPPIX日本語版が開発を中止！！

えええ（＠＿＠！）

KNOPPIX日本語版が開発を中止。公式サイトも終了し、イメージは削除される
http://internet.watch.impress.co.jp/docs/yajiuma/20150423_699132.html


ほんとうだあ・・・

http://www.risec.aist.go.jp/project/knoppix/

ＣＯＢＯＬモダナイゼーションの話とか聞いてきた

きょう、ＩＴモダナイゼーションSummitを聞いてきた。
その内容をメモメモ（まずは、第一弾。午後から行った）

---

■ご挨拶
ＣＯＢＯＬコンソーシアム
1960年　COBOL
2000年　COBOLコンソーシアム

COBOLが古いのではなく、古いシステムがCOBOLで書かれている

---

■りそなグループ様マイグレーション事例のご紹介
ＣＩＪの人

話すこと
　言語変換
　データ変換
　照合試験

環境
　ＯＳ　ＩＢＭ　Ｚ／ＯＳ
　ＰＬ／Ｉ、アセンブラ→ＣＯＢＯＬ
　ＪＣＬ→Ｂａｓｈ
　ＤＢ２→ＳＱＬＳｅｒｖｅｒ

マイグレーションのアプローチ
　手変換
　変換ツール型
　　　変換ツールを作る
　　　照合試験
　　　運用試験

言語変換
　構文解析
　　　↓
　構文ツリー
　　　↓
　言語生成←生成ルール／手修正情報
　　　↓
　整形前プログラム
　　　↓
　プログラム整形

ＰＬ／Ｉ言語変換　留意点は印刷物見てね

ＪＣＬ変換も同様
　ファイル処理、ログ出力機能などを作るのが重要

　成功要因
　・ＰＬ／Ｉ生成ツール
　・実行基盤

　運用変更に伴う追加機能

外部インターフェース
　・ジョブネットの変更
　・ジョブの変更

データ変換
　移行データ
　マルチレイアウト→レコードレイアウト→実データで検証

照合試験
　変換ツールによる変換
　運用の変更
　データ変換
　追加作成（ユーティリティ）
→照合試験→総合試験→並行稼動

照合試験
　・変換ルール網羅試験
　・プログラム網羅試験

---

■プロジェクト事例に学ぶ陥りやすいレガシーオープン化の
　落とし穴と対策

会社案内

１．レガシーモダナイズの全体像

レイヤ
　ユーザー層　プログラム／入出力／データ→等価性
　メカニズム層　ＡＰＩ／処理方式／外部連携／ユーティリティ
　コンテキスト層　非機能／固有要件

２．レガシーモダナイズの課題事例
ＣＯＢＯＬ→ＣＯＢＯＬの案件
企画：移行資産の確定
設計・変換：
　　ユーザー層：オープン化方針に依存して、難易度が変化
　　　　データ移行
　　メカニズム層：システムごとに発生傾向が異なる
　　コンテキスト層：現行実現手段にこだわると深刻化
試験：照合試験：どこまでカバレージするか
　　　　業務知識必要

ソリューション
　変換サービス
　リホスト製品
　マイグレーションサービス
　システム再構築

３．当社の提言
・データ重要：経験、実績が有効
・レガシーナレッジが必須
・トップダウンの大胆な割り切り

---

■マイグレーション時に考えなければならないこと・進め方

自己紹介

本説明の前提と内容
・リホスト手法
・はじめてマイグレーション
　　ＣＯＢＯＬさえあれば、オープン化できる
　　リホスト設計不要？
　　リスクは？
・Ｑ＆Ａ形式で

Ｑ１．マイグレーションを検討したいが、何からすべきか？
Ａ．現行ＣＯＢＯＬ資産の棚卸から始めてください
　資産棚卸の位置づけ

Ｑ２．効率のよいリホスト・プロジェクトの進め方は？
Ａ．資産の一部をパイロット変換し、課題を把握・確認してから
　本格変換作業に入ります
　　基本変換ツール→固有機能変換ツール
　パイロット移行を実施しない場合のリスク

Ｑ３．効率のよい評価方法は
Ａ．現システムとの並行評価をするのが効率的です
　テスト仕様、テストデータの準備→業務が分かっている人
　　　ＮＧが出た場合→業務に影響するか判断
　移行時に機能追加・変更はしない

Ｑ４.その他の懸案事項は
Ａ．十分な事前設計必要
　　お客様限定
　　ソース消失
　　大量印刷・オンライン印刷
　　外字
　　文字コード

---

■実績に基づくＣＯＢＯＬモダナイゼーションのススメ
富士通

システム移行を考える
・きっかけ
　　ハード保守が近づいた
　　見識者がいなくなった
　　メンテナンスに想定以上のコスト
・希望
　　手間はかけたくない
　　コストは抑えたい
　　仕様が不明確：現行は踏襲したい
・傾向
　　資産：どこから手をつけたら
　　知らない複雑な仕組み
　　理解できない業務ロジック→テストできない

ＣＯＢＯＬの特徴
・いつまでも変わらない文法（８５）
・生産性・品質が読みやすい
→継続しやすい
・将来性の不安
・ＣＯＢＯＬからオープン技術を使いにくい
・ベテラン中心→引継ぎ

見える化のススメ
・まずは、業務を把握して整理しましょう
・つぎに、資産を把握して整理しましょう
・そして、資産を整頓して管理しましょう
　　→ドキュメント、版数管理

業務見える化の期待

アプリケーション構造の見える化
　ソフトウェア地図

アプリケーション資産の見える化
　稼動資産分析
　類似分析
　資産特性分析→インパクトスケール(登録商標）
　システム相関分析

【事例】見える化（金融Ｂ社、製造業Ｃ社）
・類似資産を把握し、次期システムの開発規模を明確化

構成管理のススメ
　よくある話
　　・ソースがない
　　・実行モジュールと合っていないソース
　　・多数の管理外資産

　どうにもならない資産
　　諦めて　使い続けてください／作り直してください

なぜ、構成管理が必要なのか

ソフトウェア構成管理の構成
構成管理
　プロセス管理
案件管理
　インシデント管理
　障害管理

ドキュメント整備のススメ
・ドキュメントの鮮度はすぐ落ちる
　ソースからのリバースは夢のまた夢
　　　ドキュメントが現行ソースと乖離
　　　引継ぎできない資産
　　　ついていけない人材

事前に資産やドキュメント

生成可能なドキュメント

モダナイゼーションのススメ
・レガシー機能を今風に
　　オンライン→Ｗｅｂ化
　　バッチ→Ｓｈｅｌｌ
　　データベース→オープン系ＲＤＢ
　　帳票→電子帳票、ＰＤＦ
　　　　→ＣＯＢＯＬ資産

ＮＤＢ
　→ＤＢアクセス部分で部品化
　性能問題はある。チューニングは必要

品質保証のススメ
２５％のテストで８０％カバー
【事例】２２％で７１％
業務の見える化→シナリオ試験

モダナイ後／最新技術のススメ
オープンスタンダードな開発環境
　NetCOBOL Studio
　Hadoopと連携

最後に
・ＣＯＢＯＬのロジックは継続性に優れている
・長年使っているだけに、とにかく資産の管理は徹底的に
・新しい技術もしっかり対応
→ＡＬＬ富士通でお客様のＣＯＢＯＬ資産を全力でサポート

フォローアップセミナー参加のススメ

マイナンバー対応作業を実施している企業・組織は20%以下

マイナンバー対応作業を実施している企業・組織は20%以下
http://news.mynavi.jp/news/2015/04/22/084/

(以下太字は上記サイトより引用）

その割には、マイナンバーのセミナーは盛況で、
取れないんだけど・・・

ちなみに、

マイナンバーの実施・実施予定・実施想定層が、対応する必要があると考えている情報システム（複数回答）は、上から「人事・給与システムの改変」(71.4%)、「会計・経理システムの改変」(41.4%)、「マイナンバー保管システムの導入」(28.3%)だった。


実は、「マイナンバー保管システム」が曲者なんだよね。
特定の人しかアクセスできないようにしないと・・

NTTソフトウェア、クラウドでのマイナンバー管理向けセキュリティ製品
http://news.mynavi.jp/news/2015/01/28/068/

なかんじで・・

ビッグデータ解析は、統計的手法より、機械学習・人工知能に進んでいくと思う

ビッグデータを収集後、どのようにデータ解析を行うかという話。

現在の主流は、
　　・データを可視化して、テキトーに見ながら、仮説を立てていく（Tableauとか使って）
　　・ＲないしはＳＰＳＳを使って、統計的に解析する
が中心なんではないだろうか？

で、特に後者の場合、ある程度の統計知識が必要となる。
それはめんどくさいし、費用もかかるし、時間もかかる・・・


・・・となってくると、今後は、ビッグデータを

・目的変数だけ決めたら、あとは機械学習、人工知能に食わせて、
　結果だけを受け取る

っていう方向になってくるんじゃないかと思う。
企業はカネさえ儲かればいいのであって、細かい統計的説明はいらないのだから・・

最近、そういう文脈で、機械学習や人工知能を見ている。


【そこはかとなく、関連ありそうな話】

・ビッグデータが支える、25年ぶりの人工知能ブーム
http://business.nikkeibp.co.jp/article/opinion/20141125/274222/

・ビッグデータ時代の機械学習アルゴリズム：オンライン学習
http://www.nttdata.com/jp/ja/insights/trend_keyword/2014110601.html

ドローンって何？→無人飛行機のことなんですね！

最近、

国際ドローン展
http://www.jma.or.jp/tf/drone/


とかあるらしく、ドローンって何？と思っていたのですが、

官邸屋上に小型無人機落下＝発炎筒や小型カメラ装着―警視庁、危険物有無調べる
http://news.goo.ne.jp/article/jiji/nation/jiji-150422X626.html

のニュースを見て分かりました。小型無人飛行機のことですね！

そのうち、万引き防止の監視カメラなんかも、ドローンで定期的に
店内を飛び回って撮るようになるんでしょうね
（今の固定型だと、死角ができるので）