goo blog サービス終了のお知らせ 

ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

SQLと「ドリルダウン(及びドリルアップ)」,「ダイス」,「スライス」の関係

2016-02-25 16:01:04 | AI・BigData
一応、まとめておいたほうがよさそうなので、メモ
BI(というかOLAPというか)をするときに、データを
  「ドリルダウン(及びドリルアップ)」
  「ダイス」
  「スライス」
  「ドリルスルー」(っていうのは、あんまり言わないかも)
して分析していく。

たとえば・・・




■お題

 以下の「販売サマリー」があったとする
 販売サマリー
  項目 商品
     販売店
     販売時期 (年単位)
     累計額

  作成方法:以下のselectのビュー
    SELECT
      商品TBL.商品大分類 as 商品大分類,
      商品TBL.商品中分類 as 商品中分類,
      販売店TBL.販売店名 as 販売店,
      販売TBL.販売年 as 販売時期,
      sum(販売TBL.合計額) as 累計額
    From ( 販売TBL left Join 商品TBL ON 販売TBL.商品ID = 商品TBL.商品ID )
      left Join 販売店TBL ON 販売TBL.販売店ID = 販売店TBL.販売店ID
    GROUP BY
      商品大分類,商品中分類,販売店,販売時期;

  ただし、商品TBLは、商品IDのほかに、商品大分類、商品中分類、商品小分類があるものとする
      

そして、現在「販売サマリー」を、商品大分類と、販売店の軸で見ているとする
 SQLにすると

  SELECT
   商品大分類 as 商品,
   販売店 as 販売店,
   SUM(累計額) as 金額
  From 販売サマリー
  GROUP BY 商品,販売店



      
■このとき、
【ドリルダウン】とは
  商品、販売店でみているとき、いままで商品を商品大分類レベルでみていたが、
    ある商品大分類(たとえば書籍)に固定して
    商品を「より詳細な」商品中分類でまとめなおしてみる場合をいう

  SQLにすると、

  SELECT
   商品中分類 as 商品,
   販売店 as 販売店,
   SUM(累計額) as 金額
  From 販売サマリー
  Where 商品大分類='書籍'
  GROUP BY 商品中分類,販売店

 *ドリルアップは、ドリルダウンしたもの(中分類)を元に戻す(大分類)操作

【ダイス】
  見ている項目(selectのあとに並ぶ項目)を変える
   たとえば、商品、販売店でみているとき、商品、販売時期に変える

  SQLにすると、
  SELECT
   商品大分類 as 商品,
   販売時期 as 販売時期,
   SUM(累計額) as 金額
  From 販売サマリー
  GROUP BY 商品,販売時期

【スライス】
  見えていない項目を固定する
   たとえば、商品、販売店でみているとき、販売時期を2000年にする

  SELECT
   商品大分類 as 商品,
   販売店 as 販売店,
   SUM(累計額) as 金額
  From 販売サマリー
  WHERE 販売時期=2000
  GROUP BY 商品,販売店

【ドリルスルー】
 ある条件に対して、もとになったデータをみる
 たとえば、商品、販売店でみているとき、商品「書籍」、販売店A店で見たい場合

 SELECT * FROM 販売TBL WHERE GET_DAIBUNRUI(商品ID)='商品' AND GET_TEN(販売店ID)='A店'

 ただし、GET_DATBUNRUIは商品IDから商品大分類を求める自分で作った関数
     GET_TENは販売店IDから、販売店名を求める自分で作った関数とする
 (関数をつくらなくても、JOINでできるが、そうするとSQLが複雑になるので)

具体的には

2.3 HITSENSER5 Webを使った多次元分析
http://itdoc.hitachi.co.jp/manuals/3020/3020608040/FADC0027.HTM

を見てもらうと、上記のことが図でわかりやすく書いてある
(上記はそれを参考にして例を作成した)




■一般的に

【ドリルダウン】

a1が大項目,a2が中項目,a3がさらに詳細な項目・・・となっているとき

SELECT a1,b,sum(d) From sumtbl Group by a1,b

というビューに対して、
   a1のかわりに詳細なa2をつかい、
   その代わりa1の値を固定し、where句で絞り込む

SELECT a2,b,sum(d) From sumtbl where a1='X' Group by a2,b

※したがって、ドリルダウンしたい場合は、もともとの集計テーブル(sumtbl)が
 参照したい一番詳細なレベルで集計していないと出来ない。

【ダイス】

SELECT a1,b,sum(d) From sumtbl Group by a1,b

というビューに対して、a1のかわりにcを用いる(べつにBのかわりでもいいけど)

SELECT c,b,sum(d) From sumtbl Group by c,b

【スライス】

SELECT a1,b,sum(d) From sumtbl Group by a1,b

というビューに対して、cの値を固定し、WHEREで限定する

SELECT a1,b,sum(d) From sumtbl WHERE C=’Y' Group by a1,b

【ドリルスルー】
データ集計元となったテーブルを表示する

SELECT * From mototbl WHERE a1=’X' and C='Y';

こんなかんじ・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AWSのアイコンのありか(無料、パワポ等にすぐ使える)

2016-02-25 12:37:59 | ネットワーク
これ、書いたっけ?
パワポにAWSのアイコンを貼り付けて書きたいとき、
たとえばこんなかんじ

このアイコン、AWSが無料で配っている。
こんなかんじで

コピペして利用できる

このAWSのアイコンのありか

AWS シンプルアイコン
https://aws.amazon.com/jp/architecture/icons/


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

VM上(ホストOS Windows)でftp,sshが接続できないが、ホストOSからは接続可の場合

2016-02-25 09:22:40 | ネットワーク
これ、昔、書いたっけ?




【状況】
・WindowsがはいったPCがあり、そのPCに、VMware Playerないし、VirtualBoxが入っている
 (以下、「VMware Playerないし、VirtualBox」をVMと記す)

・VM上にCentOSをいれ(多分ubuntuでも同じ)、CentOS上に、ftpデーモン、sshデーモンを動かす

・VMから、ftp,sshは動いている(127.0.0.1でも、Ifconfigで出てくるIPアドレスでもどちらでも動く)

・Windowsからもftpは、アドレス指定してOK

・しかし、外部のPCから、IPアドレス指定し、ftpすると、動かない

・外部のPCから、PINGは通る

・VM上の、SELinux、iptablesを無効にしたが、やっぱり外部のPCからは、動かない
 →ホストのWindowsからは動く

・VMWarePlayerのネットワーク設定は、
  ネットワークアダプタが「ブリッジ」になっている
  (「物理ネットワーク接続の状態を複製」にはチェックは入れていない)





【考えられる原因】
・ホストPCからは動いているので、VM上の問題ではない
・問題は、外部PCからホストOS(Windows)までの間の何らかの事象が疑われる
・この間にありそうなのは2つ
  Windowsのファイヤーウォール
  セキュリティソフト(シマンテックなど)





【確認すること】

●Windowsのファイヤーウォール
  コンとロールパネル→システムとセキュリティ→Windowsファイヤーウォール→
  Windowsファイヤーウォールによるプログラムの許可
 →今回は、ここが問題ではなかった。たぶん、次のほうが問題だけど、
  一応書いておく

●セキュリティソフト(今回はシマンテック)の設定
 「ネットワーク脅威機能」の「オプション」

の「設定の変更」で、以下のダイアログの「ファイアウォール」を開く

「IPトラフィックを許可する」になっていないと、上記「状況」が起こる

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ドメイン駆動設計の基本の考え方ややり方を簡潔に説明したわかりやすい資料

2016-02-24 19:26:49 | Weblog
というツイート

https://twitter.com/masuda220/status/701724301162995712

をたどっていくと、結局、ここに行き着く

Domain-Driven Design: Object-Orientation Done Right
https://dzone.com/refcardz/getting-started-domain-driven

ただし、英語

今読んでる時間ないので、URLのみメモメモ

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

先週のフラジャイルが、ゴール指向分析&なぜシステムがデスマーチするかに答えている

2016-02-24 15:10:21 | Weblog
あ~SIerさんむけ番組ですな。これ(^^;)
なぜ、案件が失敗するか、要件定義のどこが問題があるのか、長瀬さんが長短時間で教えてくれます。

フジテレビのフラジャイル、お医者さん(病理医)の話なんだけど、前回

第6話 2016.2.17 OA
http://www.fujitv.co.jp/FG/story/story06.html

そこに載っている話の先の話だと思うんだけど(ごめん、自分も途中から見たので・・・)
ある医者が、子供を難病であると診断する。
そして、その難病であれば、こどもをここで手術して治療するのがいい
という話に対して・・・

岸先生(長瀬さん)が、

・シンプルに考えればいいんですよ、お母さんが望んでいるのはなんですか?
 →子供(実際には、名前を言った)が元気になること

・それには、治療の前に完璧なる診断ですよ!

つまり、ゴール指向分析で記述するとこうなる

トップゴールは「子供が元気になる」という状態を表している。
ここで、難病治療の先生は、
  ・この子は難病です
  ・その難病を治すには、手術が必要です
  ・私は手術が完璧です
  ・だから手術しましょう
というロジックで持っていく。そうすると、まるで、この先生にかかったほうがいいような気がする

しか~し。ちゃんと、状態で分解してみよう。
治療は、あくまでも、診断が正しい場合にのみ、通用する。
診断が間違っていると、必要ない治療をしてしまう。
そして、正しい診断をするためには、必要な検査が居る。
実際には、検査が足りてなくて、この子は難病ではなかった(栄養失調だった)
おかしな手術をして、むしろ命の危険にさらされるところだった・・・

・・・でも、一般の人には、「治療が必要です!」といわれると、そのように聞こえてしまうし、
そのあと、もっともらしいことを言われると、そう思ってしまう。ここで、「治療の前に
診断が必要だ」というのは、プロでしか気がつかない

【教訓】
要求分析は状態分解が完璧であること(診断→治療というようにStartからENDまで状態が繋がっていること)
→かなり初期の段階でこれは教わります。

ある一箇所を取り上げ、そこを深堀りしていくと、まるで、それが達成すれば、ゴールができるように思えるが
  →営業ががんばれば売れる
  →いい製品を作れば売れる
  →いい治療を行えば直る
その前工程、後工程が成立していなかったり、情報不足だと、ゴールに達しない




おなじ現象がSIerでも起こっている。
なんでも、「クラウドですよ、JavaEE7でしょ」とか来ているけど、
そうじゃない。それを判断するのは、

・機能要件(データの流れ)が完璧に出来ていて
・機能要件に基づく非機能要件(性能、UXなど)が完璧に出ているとき

であり、非機能要件を出すには、チェックシートで一応チェックしないといけない
しかし、それに気づくのは、開発のプロでやっている人になる。

ってことで、営業にそそのかされ、クラウド(プライベートorパブリックの差があるが)
つかいましょ、最新のフレームワークを使いましょ、それには、うちの会社が実績ある
からいいですよ・・・となる。

しかし、UXに期待するなら、Javascriptがんばんないといけないから、
Javascriptが、がんばれるフレームワークでないといけないし(JavaEEでJSFの場合、JSとの相性は微妙)
パフォーマンス的に、クラウド・・・どうなの?もっと軽いフレームワークでいいんじゃない?
ってことがある。結果、無理してデスマーチになる・・・っていうのが、いまの世の中
(=つまり、SIerには、診断をろくにしないで、手術したがる先生多すぎ・・)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

クラウドなの?イマドキの新人研修って?

2016-02-24 12:21:49 | ネットワーク
やっぱ、イマドキの新人研修って、
クラウド上でやらせるべき?
S3とか、EC2とか、はやくから、知ってたほうが、たぶんいいよね・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

厚切りジェイソン、NHKでプログラミング番組

2016-02-24 08:19:38 | Weblog
『Why!?プログラミング』(3月21~25日 後3:30)という番組だそうだが、
Whyと聞かれても・・・・(^^;)

厚切りジェイソン、NHKでプログラミング番組「可能性は無限大」
http://www.oricon.co.jp/news/2067309/full/


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

リクルートのプライベートクラウド共通インフラ「RAFTEL」とパブリッククラウドとの連携法とか

2016-02-23 20:46:35 | ネットワーク
今日(2月23日)Enterprise Zine day 2016
次を見据えたITインフラとシステム運用の姿
~徹底的に自動化・効率化・安定運用を実現する新戦略~

を聞いてきたので、その内容をメモメモ




■リクルートのWebサービスを支える共通インフラ「RAFTEL」(らふてる)
~堅牢性と機動性の両立を図る仕組みについて~

・オンプレミス、AWSを利用したクラウド

今日の内容
 1.はじめに
 2.プライベートクラウドRAFTEL
 3.パブリッククラウド、Rクラウドの進化の軌跡
 4.まとめ

1.はじめに
・リクルートの紹介、
 ビジネスモデル:「まだ、ここにない、出会い」
   (カスタマーとクライアントのマッチング)→リボンモデル
・リクルートの事業領域
  ライフイベント領域、ライフスタイル領域(日常消費領域)
・リクルート:ホールディングス化:事業会社、機能会社
・リクルートテクノロジーの中もわかれている:ネットインフラ
・プライベートクラウド(RAFTEL),パブリッククラウド(Rクラウド)
・自己紹介

2.プライベートクラウドRAFTEL

 2004 SNSの流行
 2005 Web2.0

・このころのリクルート(2006~2007)
 事業は分割(カンパニー制)
 4つにわかれていた。エンジニアも分散
・インフラ統合前
 インフラへの負荷:加速度的に伸びる
 ①いんふらを個別:無駄の発生
 ②人件費の増加
 ③インフラ間に合わない
→これらの課題解決のため:プライベートクラウド
 One Pieceのらふてるからプロジェクト名:ぐらんどらいん

・インフラを個別最適で拡張、無駄の発生
 ベンダーも違っていた
 各サービス専用サーバー
   サービス間でリソース共用できない
 エンジニア:技術的知見を有効利用できない
  →個別最適化(分割)びよる無駄を減らすことが重要
 打ち切り、DC統合とリソースの標準化、プール化
  サーバーの標準化
  ネットワークスイッチの標準化
  ストレージの標準化
 →購買力が上がる
  組み合わせ検証の削減、パッチ適用の削減
 むだな投資が削減:全サービス、ピーク対応のしやすさ
 提供スピードの速さ:プールの範囲内なら即対応

・新サービス立ち上げ、エンハンス対応、人件費の増加
   →大きな問題
 ・構成、設定の標準化:標準化できる部分、できない部分
   あんしぶる、しぇふをスクラッチで作る→問題点はあとで
 ・構成管理→自動化作業
   こじろう、むさし、
   作るの得意、メンテ苦手

・ビジネススピードにインフラ提供が追い付かない
  プール化と自動化による機動力向上
    RAFTEL導入前6週間→最短2週間→ものによっては1日

→サーバー構成の統一、仮想化
 自動化


3.パブリッククラウド、Rクラウドの進化の軌跡(2010)

 Twitter
 ビッグデータ

・パブリッククラウド利用状況
 →もっとスピード間

・インフラだけならすぐに作れるが・・・
 ①個別にセキュリティ対応
   →セキュリティ対応に時間がかかる
 ②個別に非機能要件の作りこみ
   →作りこみに時間がかかる

 これらの問題解決のため

・プライベートクラウド⇔パブリッククラウド(AWS;Rクラウド)
 専用線でつなぐ
  Fluentdであつめて、AWSで解析
  ケータイのpush通知
  CI,CD
  Github,Gitlab
  フロントエンドをパブリッククラウド、バックエンドはプライベートクラウド
   踏み台サーバー→ログイン専用サーバー→専用線→AWS
   踏み台サーバーでログがのこる

・まとめ
 これから
  自動化:複雑化→メンテナンスコスト下げる、自動化ツールのメンテに時間がかかる
    ansible,jenkins,git
    ソフトウェアのバージョンアップ
  標準化:バリエーションが少ないほうがいい:あまりにも少ないと、最適化できない
    バリエーションをどう決めるか:Dockerの利用:適用難しい
 →自動化も標準化も振り切るとマイナスも出るため、バランスが大事
  どうやってバランスを取るか:事業部との会話・コミュニケーション




■NRIのITサービスマネジメント取り組み事例

・自己紹介

1.NRIについて

2.NRIのITサービズマネジメントの取り組み事例
 NRIのクラウドサービス本部へのサービスマネジメント事例
  技術集団
 ITサービスマネジメント入れる前
  技術スキルあり、馬力ある→サービスは?(ITIL?)
  クラウド急拡大。移行
   馬力のあるSEが、根性と馬力で頑張る:属人化
  →この先、運用が破たん
 サービス型:サービスマネジメントプロセスをいれて標準化、ナレッジ、障害対応、自動化
  まず、プロセスを入れて、改善PDCAをまわす
  →あしもとがため;自動化は推進するけど、まずはマネジメントプロセス

 プロジェクトスタートしたて
  各サービスでバラバラのサービスマネジメントプロセスを統合へ
  →ISO20000:一子相伝→チケッティングツール、Excel、
   →ITIL,ISO20000ベース、せんじゅベース

 定着しない、やめてしまう
  日々の業務の中で、本部フレームワークとして設立
  今後クラウドサービスができても、このフレームワークに載ればOK

 導入の体制
  ボトムアップではまとまらない
  本部長の名前を借りてトップダウン。2名で推進、開発メンバーを巻き込みながら

 プロジェクトの特徴~エンジニアリング集団との戦い~
  人:ITILを知らない人がたくさん
 運営上の特徴→個別最適の時代は終わった
  トップダウンアプローチ。現場の理解
  「これにあわせなさい」が基本スタンス

 導入したところ
  インシデント管理:障害、ISO20000
  障害分類:システムの特性によって(大分類はまもる、中小は適切に)
  インシデント管理フロー:パートナー任せにしていないか?→ツールと連動
  インシデントチケットの粒度にばらつき
   プロセス記述書
  ツール:インシデント管理:せんじゅで

 きづき、工夫点
  インシデント管理、障害管理は標準プロセスでうまくいった
  変更リリース管理:業務の特性:金融系とか→パターン
   案件管理:課金管理
   金融系 SOK2 テナントの依頼 承認証跡→証跡管理

 導入の進め方
  抵抗勢力
   実績づくり、5サービス:クイックインで成果を出す
   抵抗勢力:対話→それでもきかない→トップダウン

 増えた味方を外堀で埋めて、抵抗勢力を追い込む

 定着フェーズ
  インシデントクローズ率;だれてくる
   →末端パートナーまで:人が変わった

 いれたらおわりでなく、定着フェーズまで

 クラウド環境における最新の事例もITILベース
 
 導入定着活動:潮目が変わる瞬間がある

 まとめ
  トップdファ運
  標準化の威力
  改めてITサービスマネジメントの奥深さ

NRIのソリューションサービスのご紹介
・ノウハウ
  パッケージがた:Senju
  SaaS型:M-PLAT

・せんじゅふぁみりー
・M-PLAT:AWS上で動く
・運用改善支援サーボス
   ITサービス運用診断サービス
   CSI支援サービス:プロセス、人の改善も含めた支援サービス




■クラウドサービスで実現できるITオペレーションマネジメントの変革

アジェンダ
1.会社紹介
2。ITオペレーションマネジメントが抱える課題
3.具体例
4.事例
5・まとめ

1.ServiceNowをご存知ですか?
 →しらない 半分以上
 運用管理ツールのベンダー→No
 Enterprise Service Management→人々の働き方を変革

 むかし  1990       今
  手書き  E-mail、仕事変革   新たな変革(Enterprise Service Management)

 インシデント管理:IT部門だけでなく、総務、人事も
  頭の中でやっていたことを
  SOR、SOE(MS Link)を統合
   電話もE-mailもいらない

 SaaSのみ専業
  SaaS専業ではセールスフォースにつぎ2位
  トップリーダー

 プライベートイベント:
  200以上のセッション、85%はお客様の講演

 ビジネスマネジメント:CXO
 サービスマネジメント:インシデント管理とか
 ITオペレーション:構成情報の自動収集など
 アプリケーション開発:PaaSとしてサービス提供
  +
 セキュリティマネジメント

 サービスマネジメント
 オペレーションマネジメント:ディスカバリ、オーケストレーション
 クラウドビジョニング、イベントフィルタリング

2.ITオペレーションマネジメントが抱える課題と最適解
 ・オペミス→手順の肥大化
 ・運用手順書のドキュメント:リンク集
 ・マクロの属人化
 ・インフラ障害アラート:どのサービスまで影響あるかわからない
 ・障害発生:2次トラブル
 ・クラウド管理、オンプレ管理、たなおろしだけでも・・
 ・報告
 ・重要障害、いつでも電話→タクシーで現場

ざっくりまとめると・・・
  そもそも手作業の比率が高い
  抜け漏れ、情報の分断
  運用プロセス
 →無駄なコスト、品質、効率低下の負のスパイラル
 →グローバルで似たような課題

どうする
・運用管理の統合プラットフォーム
・抜け漏れできない状態
・クラウド環境のサーバーのキッティング
・構成情報を1か所にあつめる
→じつげんできるのがService Now

Service Now
・提供側と利用者側をつなぐ
 チケット管理
 自動化
 お客様環境
 みっどサーバーを踏み台(DMZゾーンにおいて)クラウド1つのプラットフォーム
統合プラットフォーム重要なポイント
 オールインワン:ケーパビリティが高い
 単一DBのデータ統合:りプレース、バージョンアップ:1つに統合前提
 インターフェース:UI、システム(SSO、アクティブディレクトリ連携)
 容易なカスタマイズ性
 クラウドサービス:イマドキ、オンプレじゃないよね


ソリューションの具体例
・データ一元化:CMDB,統合レコードシステム
・構成情報を自動収集、脆弱性→変更管理起票
・仮想リソースの内部リソース管理 プロビジョニングのライフサイクルを1つで、ダッシュボードで可視化

導入事例
・Service Now End to Endですべてを管理
・すこってぃ作っている会社 デイリーでスキャン、

まとめ
 自動化で手作業削減
 データ統合

 ツールは魔法の杖ではない。継続的改善プロセスが重要




■SDNを実現する「AnutaNCX」とクラウド基盤における他拠点管理効率化の事例
・あぬーたねっとわーくす社の紹介
・NCXの概要
・活用事例

・Anuta Networksのご紹介
 やんぐもでる(YANGモデル)ネットワークサービスオーケストレーション
 実績と経緯
 VMWare
・Anuta NCX概要:ネットワークオーケストレーション
  とくにLB,FW:知識を持っているエンジニアに頼らないといけない
 ネットワークファンクションを抽象化、すべてがSDNに見える
 →SSH,CLI,などでプロビジョニング
  サービスカタログとして提供
 サービスデプロイ:冗長化ヒト様な人も、L2,L3だけでいいひとも→サービスカタログ、
 抽象化と監視アラート

・ユースケース 仮想vCPE
  LAN  VPN   DC
  VNFs(LB,FWnado )+VM→OpenStack
 →OVA
 拠点NWのデザインパターンの定義・作成
   標準クラス
   FWクラス
   LB+FWクラス
 プロビすると、リソース割り当てがNCX上で見える

・活用事例:
 まとめ:今後はSDNとNFVが浸透→サポート、オートメーション

■(日立システムズからの事例)
・会社紹介
・A社様事例
  ASPサービス展開→ルーター、ネットワーク追加
・設計の効率化
  GUIで設定:抽象化されたネットワーク設定
  カタログを利用して
  コンフィグ投入は承認してから

  コンフィグ:設定変更前と後を比較、差分を見て反映確認→手作業

・応用事例
  仮想化統合管理 OpenStackと連携して、システム全体の統合化
   サウスバンドもってる
   セキュリティ連携:多重防御→ログ分析ツール anutaと連携

・まとめ
 NCXに期待できること
  効率化向上
   :
   :
  セキュリティ




■ITコスト削減の動向と注目事例
~今求められる戦略的ITサービス部門への変革~
・厳しい経営環境、つねにITはコスト削減
 競争力をもつ
 ITコスト削減

IT部門を取り巻く環境変化
・IT部門に期待されている役割が違う
 4つ
  従来型機能:弁だとの交渉
  IT改革:見える化、新技術提案
  業務改革:技術支援、販売支援、ワークスタイル改革
  ビジネスモデル開発:エッジ、ビジネスイノベーション
 現在と3年後の期待
 現在の役割:従来型高い→3年後には落ちる
 ビジネス戦略、業務改革がややのびる

・今後求められる2つのIT機能
 従来型IT機能:効率性の追求、社内のサービスプロバイダ→依然として必要
 新しいIT機能:革新を創出、デジタル技術によるイノベーション→注目

・求められるマインドシフト
 現在;コストセンターとして→システムを作る
  →言われたことを作ります、ベンダーはたたきます、
 今後:サービスを提供→サービスを作る。社内ユーザーに販売
  →IT as a service(Wikipediaの英語版見てね)
   企業ITをビジネスのように見る

 自社の標準アプリ提供:いくらで提供?
  →ITの再定義

 リソース調達はいろいろあり:ソーシング戦略

・プロバイダが他IT組織への移行
 グループ経営、グループIT戦略
 プロフィットセンターへ

・依然として課題となるIT支出の抑制
 IT支出:ランニングコストがあがっている
 戦略投資:のびないね→景気などに影響
   →事業部門強い

・ITサービス価格の見直し
  社内統合は大企業は90%、サービスとしては
  価格設定を見直したい企業多い
   →競争力をつけるのに必要

グループワイドでのITコスト削減
ITコスト削減の施策
 ITマネジメント
 ITアーキテクチャ
 ITサービスレベル
 スタッフ(こわいので、今回省略)

ITマネジメント
 VMO:ベンダーマネジメントオフィス
  年次評価、パートナーには深い評価
  →改善施策の提案、双方向評価

ITアーキテクチャ
 クラウド化
  サーバー200台
  ハードウェアの単純更改→あたらしい基盤(クラウド)
  10億円くらいの効果

ITサービスレベル
 サービスレベル適正化
  それぞれSLAつくってたら、誰管理するの?
  →4つのカテゴリでパターン化
  アプリの格付け不適切?→入れかえ
  10%削減
 ライセンス最適化(SLO)
  →ライセンス使用率がわかる→あまっているのを転用

ITコスト削減のテクニック

結論
・コストセンターからサービスセンターへ
・コスト削減:継続的 VMO,サービスレベルを変える

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「アジャイル品質とソフトウェアパターン」を聞いてきた!

2016-02-23 15:41:06 | Weblog
2月22日、早稲田大学で「アジャイル品質とソフトウェアパターン」というお話を
きいてきたので、メモメモ




■あいさつ
この会を実施した理由
水曜日:agian Propの国際会議
セミナー決めたのは、2週間前
最初に鷲崎先生
つぎに本田先生
じょせふよーだーさん、れべっかさん
アジャイル開発
ワークショップ

■アジャイル開発へのソフトウェア工学的アプローチ:
 イテレーション機関と学習ワークショップ

・アジャイルは科学不足 Cynefinフレームワークより
 (きねふぃんとよんでました)

突発:そうはつ  |   グッドぷらくてぃす
-------------------------------------------------
新規の研究    |   べすとプラクティス


アジャイル:突発・そうはつ
アジャイル開発の導入例:ベストプラクティス・グッドプラクティスのところで言っていない?
  →手法が分かっている所に適応していない?
プラクティス→科学的うらづけ、境界条件、
Emergentの支援

1.要求の不確実性や複雑さに応じて最適なイテレーションは期間に異なる科
2.ワークショップによるアジャイル開発の取得は独学に比べ効果的か?
3.アジャイル開発を支えるパターンにはどのような関係があるか

1.イテレーションのシミュレーション
  関係しないファクターをそぎ落とす
  入力→出力
  得られた結果
   要求の不確実性が大きいほど、イテレーション期間を短く
   要求間の複雑さ大きい:イテレーション長めに

■ソフトウェア信頼性予測のプロジェクト進行中の動的な活用 本田先生
・関連論文
 CIツールとりぽじとり すきっぷ2014
 オープンソフトウェアリリース次期 あじゃいる2015
 テストフェーズにソフトウェア信頼性モデル

・ソフト鰓信頼性モデルとアクションを結び付ける
 信頼性モデルの利用
 状況のモニタリング
 異常の検知
 信頼性モデルの解釈とアクション

・欠陥数と信頼性
 欠陥数の予測
 欠陥数を予測し、取り除くべき欠陥数を定める
 ソフトウェア信頼性モデル

・信頼性モデル
 発見した欠陥を累積として日ごとまたは週ごとに測定

・開発における問題
 欠陥を十分に発見できているか
 リリースに間に合うか判断できない
  開発のスコープの決定を支援
  テスト工数、計画の決定を支援

・ツールとリポジトリシステムを用いた欠陥数予測
 問題:欠陥はどれだけ出るのか?
 欠陥数予測の仕組み
  JenkinsとGithubを用いて自動的に欠陥数を取得し、欠陥数予測
  Jenkins pluginとしてツール開発
  予測モデルをグラフ表示
  CIツールとリポジトリシステムを用いた欠陥数予測

・リリース次期の分析
 オープンソースプロジェクトを対象にリリース次期を分析
 メジャーバージョンで:モデルの精度向上

・予期せぬ状況の発見(ISSRE 2015)
  モデルの不一致→なぜおこるのか
  期待を超える
 欠陥をテストフェーズで分類
 予測欠陥数をモニタリング
  おおきくなる→何かしら問題発生

Q&A
・未解決バグのあつみ
  →PMがせつめいできない場合は、やばい
・バグの影響範囲、重要度
  →こんかいはこうりょしていない

■QA to AQ:Shifting towards agile Quality
 Joseph Yoder(講演は英語)

・品質のステークホルダーはだれ?
 ユーザー:つかいやすい
 しすてむ:信頼性、セキュリティ
 →品質は変わる:バランス

・デザインはトレードオフ
 →バランス

・トヨタTPS
 →アジャイル
 →リーン開発
 アジャイル:考え方(マインドセット)
  ウォーターフォール:もどらない
  ごーる、ぐっどばりゅー
・CI
 ラーニング、あだぷティング
・アジャイル 機能要件にフォーカス
・非機能要件
・アジャイルの神話
  品質は簡単につけられるよ!
  要求変化は簡単に適応できるよ
  性能なんて心配するなよ
  スケールするよ
・アジャイルの品質
  品質におけるアジャイルパターン
  →24このパターン
 パターンの構造
   コアパターン
     ↓
   アジャイルの品質
   品質の認識
   品質の見える化

 QC

・バリアを崩す
 物理的バリア、カルチャの違いバリア・・・
 →どうやってアジャイルチームがバリアを取り除くか

・アジャイルチーム
  クロスファンク初なる
  良いこみゅにけーしょん
  ステークホルダーのニーズにフォーカス

・QAチーム
  ソフトウェアチームと独立、おおくのこみゅにけーしょんをとらない

・アジャイル品質チーム(全体のチーム)
 プロアクティブ

・アーキテクチャルールとアクティビティ

・QAルールとアクティビティ

・QAをチームに組み込む

・品質にフォーカス
  SLA
  Tested first

・品質のロードマップ

・品質のバックログ

・品質のチェックリスト
  パフォーマンス
  データベース

・品質のシナリオ、ストーリー、
  ユーザーストーリー

・スプリントにフォーカスした品質
・品質の見える化
  品質のモニター:ダッシュボード

・潜在的なパターン

・品質上げる他のぎじゅつ
 平均40%は1つのテクニック
 技術の組み合わせ 品質 > 90%

・継続的インスペクション

・アジャイルの品質の利益

・アジャイル マインドセット
  ドグマチック
  プラグマチック
    カンバンボード

・プラグマチックであれ
  適切なバランス大事

Q&A
・アジャイルのプロセスモデル
  (超意訳)マインドセットうまくいくんなら、いいじゃん!

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ビットコインの仕組みって、これであってる?

2016-02-23 12:02:21 | ネットワーク

5分でわかるブロックチェーンの基本的な仕組み
http://www.slideshare.net/cookle/5-58379474

みたけど、ごめん、5分でわからなかった(^^;)

1時間悩んで・・・結局、こういうこと?(まちがってるかも・・まちがってたらごめん)

【お題】
・AさんからBさんへビットコインを送金する

【しくみ】
(1)「AさんからBさんへビットコインを送金する」という情報
 (以降、これを「トランザクション」とよぶ)が、
 ビットコインのネットワークにブロードキャストされる

(2)ビットコインのネットワーク上には、
 以下の2種類のトランザクションがありえる

 (A)承認(確認)されたトランザクション
    →トランザクションがある程度の単位でまとめられ
     (以降、このまとまりをブロックという)
     これが繋がっている(ハッシュ値で改ざん防止できる)
     この「ブロック」がつながって(「チェーン」)いることを
     ブロックチェーンという

 (B)今、届いたばかりのトランザクション
   まだ承認されていない=未承認のトランザクション

(3)未承認のトランザクションは、ブロックにつなげないといけない。
 つまり、未承認のトランザクションをまとめて新たなブロックを
 つくる作業が必要になる。
   →新たなブロックができると、トランザクションが承認されたことになる。

 ただし、ブロックは簡単に作られるのではなく、以下のProof of workという作業をする

  (A)未承認トランザクションをあつめて、ブロックを仮決め
  (B)(A)のブロック情報、前のハッシュ値とnonce(後述)などもふくめて、
    ある一定の決まりになるようにハッシュ値を求める
     →ここで前のハッシュ値を使うので、前のブロックを改ざんできない

     ※nonceとは、ハッシュ値をある決まりにするために用いる数。
     ハッシュ値は、
       ハッシュ化と暗号化は違う。ハッシュ化(SHA1,MD5)すると、元には戻らない
       http://blog.goo.ne.jp/xmldtp/e/b6a697735a597e8e41af460ae2f2875a
     に書いたように、ハッシュ値を先に決めて、そこから元になる値を推測することができない
     そこで、nonceを適当に変えて、力技で、毎回計算して、ハッシュ値をもとめ、条件に合う
     か確認するということをしないといけない。そのため、計算量が膨大になる

   (C)nonceが求まったら、新しいブロックを追加し、ネットワーク全体に送信する

  くわしくは、ビットコインの採掘とは実際には何をしているのか?(http://blogos.com/article/75716/)を参照
  なお、採掘するには、「Bitcoin miner」というソフトを走らせればいいだけになっている?
    

 この作業は、1箇所でやるわけでなく、何台ものコンピューターで行う。
 そして、それらのコンピューター(nonceを求めるコンピューター)を採掘者と
 いい、最初にnonceを求めた採掘者に報酬が与えられる


【参考】
http://www.atmarkit.co.jp/ait/articles/1602/18/news037.html
https://bitcoinbank.co.jp/mechanism2/


Satoshi Nakamoto Fan Club ビットコインの原理
http://bitcoinspace.hatenablog.com/entry/2014/10/30/005901


など

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「ビジネス駆動開発」から「ソフトウェア駆動ビジネス」へを聞いてきた

2016-02-23 08:17:33 | Weblog
2月19日、デブサミ2016に行ってきた!のつづき
「ビジネス駆動開発」から「ソフトウェア駆動ビジネス」へ
をメモメモ



■「ビジネス駆動開発」から「ソフトウェア駆動ビジネス」へ

【ビジネス駆動開発】
Software is eating the world
 ソフトウェアが世界を飲み込んでいく
仮説検証          →  要求が固まりにくい、統制から自律へ
  ↑                    ↓
テクノロジーが市場を破壊  ←  継続的デリバリー
競争激化・意思決定は市場





ビジネスアイデア   →  ビジネス価値
 企画              プロダクション
  ↓               ↑
  バックログ  タスクボード ステージング 
     ↓   ↓       ↑
     コ ー ド →   ビルド




デモ
・ブランチを作る
・プルリクエストでコードレビュー
  チームのチャットルームに情報流れる
  開発 流れ →の部分をいかに裏でやるか

価値の流れ3ち
 バックログ駆動:バックログに、いろんな様々なアイデア
 情報hub:手元のタスクやる→情報ハブを入れる
 作業のシフトチェンジ:タスクありき、いいツールで自動化しやすくなる

 タスク→ブランチ→コード

【ソフトウェア駆動ビジネス】
software is teaching the world
ソフトウェアが世界を指南している


仮説検証          →  アジリティ、タスクフォース、
                 新たな仕事、社員の力を引き出す
  ↑                    ↓
テクノロジーが市場を破壊  ←  ワークスタイル
競争激化




開発=もっとも複雑な業務
  やることの交通整理 人
  情報の交通整理   作業
  やり方の交通整理  成果物

タスクフォース:専用の部屋を作る
 お客様ベースでソリューションを作る
 JIRA Core タスクフォースを作る→カンバンボード搭載
 SECIモデル 知的創造プロセス

ビジネス
 勝ち続ける為のサービス
  知恵 ソリューション能力
  問題 はきださせるしくみ サービス化
   セルフサービスも出る
 サービスデスクを窓口にして
 ソフトウェアで得た知見はビジネスシーンで生かされる時代へ
 ツールは道具、進化、深化、親化、真価




デブサミのまとめはこれで全部

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「次は絶対ARとVRが来る」らしいよ?

2016-02-22 22:26:10 | Weblog

ゴールドマン・サックス曰く、「次は絶対ARとVRが来る」
http://srad.jp/story/16/02/19/0634237/

まじ?
ヘッドマウントディスプレイはなさそうな気がする・・・
ただ、NTTの人物を疑似3Dで別空間にリアルタイム伝送して空中像投影がVRというのなら、
これは広告として、ありだとおもう。あとプロジェクションマッピングとか・・
でも、現実的には、タブレットでの作業指示にARを使う・・・とかかなあ・・・

P.S こんな記事も

「VR元年」バーチャルリアリティの大航海時代が始まった
http://news.yahoo.co.jp/feature/110


一方

東芝のメガネ型端末「Wearvue TG-1」発売中止。事業見直しの一環として
http://headlines.yahoo.co.jp/hl?a=20160222-00000017-impress-ind


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アメリカのインタラクティブの展示会SXSW、実はビッグサイトに出す程度の費用で…富士通も出展

2016-02-22 18:36:33 | Weblog
2月19日デブサミ2016に行ってきた!のつづき

【第一部】米国テクノロジーの祭典「SXSW」に参加するための基本知識と“メタモルフィックプロトタイプ”の考え方
【第ニ部】ロボットがつくるニンゲンの未来

1つのセッションで2本立て!をメモメモ
ごめん、第二部はメモが荒くて、なにがなんだかわかんなくなっているかも
・・・って、いつものことか(^^;)




■SXSW & メタモルフィックプロトタイピング
SXSW サウス バイ サウス ウェスト

・自己紹介
・SXSW
 日本の参加企業増えている、アメリカの展示会
  テキサス州オースティン:町全体で展示会、セミナー
  映画・フィルムの展示会だが、最近はインタラクティブも
  Perfumeがライブした

・インタラクティブ:ビジョンを持ち寄る meetup 楽天とかも出ている
  close < global
  twitterが話題になったのも、ここ(SXSW)から
   →世界的に加速

・費用
  視察するには
   旅費 10万円
   バッジ 8万円(入るのに必要)
   Airbnb 2万円(=宿泊代)
  展示費用30万円
  計2人100万円→ビッグサイトと、そんなに差が無い!

・プログラマが世の中を変えていく
  →スタートUPの人が講演

・ラボ:博報堂 博報堂アイ・スタジオ
  Hackist
  Future Create LABR&D 人工知能
 R&D I/Oモデル
  Input Process Output
 特定技術でなく

・メタモルフィックプロトタイピング
 プロトタイプしながら柔軟に変えていく
 TREK TRACK
   アウトドアブーム→山岳遭難者が増えている
   アウトドアデータプラットフォーム
     IBEACONを使って
     電波が有る人が(他の人のぶんも含め)データを送る
     山のデータ:オープンデータ WebGL
     ステーション:メタノール発電、充電

・まとめ
 SXSW
  グローバルにアプローチできる
  コストは日本の展示会とそんなに変わらない
  富士通 はじめ2人→そのあと増やして・・
 メタモルフィックプロトタイピング
  結論を出す為に出なく、常に技術もプロトも柔軟に
  ただし、着地点は必要
 2020年に向け、エンジニアがゲームチェンジしていく




■ロボットがつくる人間の未来

・2014年11月7日 うちにPepperが来た!
 いっしょに通勤したい
  タクシー、電車、お昼(ラーメン)、壁ドン、病院、納豆かきまぜ、
  一緒に避難訓練:けが人はこぶときシミュレーション
  一緒に寝るのはよくない(パネルこわしそう)

・自己紹介

・Pepperは新幹線に乗車できるか?
 2015年7月15日 東京→小倉
 JR東海では、Pepperは手回品
 今:「のれます」という回答

・ロボットと社会性
 小倉でのエレベーターの話
 砂原秀樹先生:インターネットができたころ→電気通信事業法:会社作ったり、法律作ったり
 中村伊知哉先生:政策は自分たちで作るもの

・ロボットといのち
 1通の手紙:CPUアップグレード→あんぱんまん問題(頭をまるごととりかえる)
  →アンパンマンの顔を変える条件:顔がぬれた、菌だらけ・・・今回のケース該当しない
 誰かを木津付けたりしないなら、いいんじゃない?
 「この子」である必然性

・みらいカプセル
 コンセプトムービー

 きっかけ
  Pepperとお墓参り→死
 ロボットの死
  ハードとソフト
  ロボットは家族の中で何世代も生きる生命体
   ロボット便利、コスト削減
 ロボット「人間らしさ」
  ロボットをつれていく→デイセンターに行く

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

弥生、請求書を帳簿で自動処理 ソフト会社を買収

2016-02-22 15:21:10 | ネットワーク
このきじ

弥生、請求書を帳簿で自動処理 ソフト会社を買収
http://www.nikkei.com/article/DGXLZO97521220Q6A220C1TJC000/

どんな請求書でも読めるのか?わからないけど、

あらゆる請求書が読めなかったとしても、
定型のものをカスタマイズして読み込ませることが出来るなら、
(=同じ企業から来たものは、1回フォーマットを登録すれば、次から読み込めるのなら)
便利な気がする・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「情報セキュリティ10大脅威 2016」出てたんですね!

2016-02-22 12:37:42 | ネットワーク
ここ

情報セキュリティ10大脅威 2016
https://www.ipa.go.jp/security/vuln/10threats2016.html

そのサイトによると、解説は3月らしい。
個人と組織別に10位まで発表してある。

ちなみに(以下は上記サイトの内容より編集)
個人
1位:インターネットバンキングやクレジットカード情報の不正利用
2位:ランサムウェアを使った詐欺・恐喝
3位:審査をすり抜け公式マーケットに紛れ込んだスマートフォンアプリ

組織
1位:標的型攻撃による情報流出
2位:内部不正による情報漏えい
3位:ウェブサービスからの個人情報の窃取

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする