まえのエントリで仮想通貨の話が出たので・・・
仮想通貨が、地域通貨になる事例
仮想地域通貨9月「近鉄ハルカスコイン」社会実験｜円や仮想通貨との交換構想
http://virtualmoney.jp/I0001095
仮想通貨が、地域通貨になる事例
仮想地域通貨9月「近鉄ハルカスコイン」社会実験｜円や仮想通貨との交換構想
http://virtualmoney.jp/I0001095
５月２６日
2017年5月期 AITC技術セミナー＆オープンラボ 「ブロックチェーンの最新動向を掴む」
https://aitc-seminar.connpass.com/event/57209/
に行ってきた！のでメモメモ
■ブロックチェーンの展望と課題 ～仮想通貨から社会インフラへ～
ビットコインのブロックチェーンから分散型台帳技術へ
台帳→ネットワーク
・基本的な仕組み
ブロックがチェーンのようにつながる
→いったん忘れてＯＫ
Ｂ２Ｂネットワークが基盤
・分散型台帳とは
データベースの対比
クライアントから書き込み要求
異なる要求を同時に受け付ける
何を正とするかきめる→アクセスコントロール
分散の場合
異なる要求が同時にきたら？
どれを正とするかをみんなできめる
→コンセンサスアルゴリズム
ＰｏＷなど
→エンドユーザーからはアルゴリズムは見ないでいい
分散したデータベース
分散型台帳を使うメリット
貿易業務
情報のバケツリレーが複雑→証跡性
リファレンスデータの共有
ＮＴＴデータの取り組み例
スマートコントラクト
貿易分野に力をいれている
貿易保険
今後はほかの分野も
ブロックチェーン 仕組みと理論
■地域金融機関とブロックチェーン
・日本ユニシス金融ソリューション
地方銀行１０行にはいっている
→たいへん
地域の中：２０１５年人口減少；地域に影響（お金の流れ減少）
Fintech：銀行以外の決済、楽天、Ａｍａｚｏｎが融資
→コーディネーターとしての役割
仮想通貨：地域通貨と新たな決済手段
・デモ
・クレジットカード
手数料コスト、初期コスト→手軽に導入できない
イーサリアムのフレームワークを使っている
問題点：出資法→銀行が発行する場合メリット（いつでも換金）
・その先
だれからだれにわたっているか：お金の流れ
ビットコイン：まわっていく→為替リスクある
地銀のばあい、１ポイント１円とかきめてしまう
さるぼぼコイン
ＱＲコード
インバウンド向け
琉球コイン
独立貨幣として提供：時価で変動
余ったら、資産価値→投資を呼び込む
・とりくみ２つ
地域通貨＋α：農産物 食品とーさびりティー＋お金の流れ
お金と物とトレーサビリティを一元管理
・まとめ
キャッシュレス送金→あらたな金融サービス→経営支援
■Blockchainの展望
・自己紹介
・グローバルに拡大する社会問題
過去１０年間でエネルギー価格は３倍
世界人口７０億人
６０歳人口 日本３０％
ロボットを動かす：電気→効率的
・イノベーションがもたらす豊かな未来
ヒューマンセントリックインテリジェントソサイエティに向けて
・地域スタンプラリー
クーポン、スタンプラリー：ブロックチェーンを使って
決済基盤Finplex ブロックチェーンと金融ＡＰＩ
・証券クロスボーダー取引
セキュリティ強化技術開発
ネットワークサービス
プラットフォームサービス
はいぱーれっじゃーを準備している
参加メンバーの管理
・コンセンサスアルゴリズム
社会実装
ＰｏＷ：電力が問題
Ripple Protocol
・まとめ
Society 5.0
マイクロサービスの提供：ＷｅｂＡＰＩとして
パーソナルなデータストア
■ＢＣＣＣ＆ブロックチェーン～最近の活動と実証実験～
・ブロックチェーン推進協会（ＢＣＣＣ）
・プライベート
・未来
・ブロックチェーン推進協会：ＢＣＣＣ
１４０社超が加盟
金融だけではない
流通
公共
製造
医療
→改ざんできない（管理者であっても）
最近の動向
金融機関に加え、幅広い業界から加速
・部会
広報部会
金融部会
スマートシティ部会：ＩｏＴ
リスク管理部会：ビジネスリスク
・社会実験
デジタルトークンＺｅｎ
仮想通貨
問題点：為替変動が大きすぎる
為替があっても安定する（保障ではない）
複数のブロックチェーンをまたがる
アウトではない
・Ｚｅｎ
イーサリアムをつかっているが、みじんとかも使える
ブロックチェーン大学校
・プライベートチェーン
電子マネー：ありがち
→処理スピード
野菜のトレーサビリティ
→パブリックチェーンにひも付：かいざんできなくさせる
行政サービス
アントワープ市だが、みじんが使われている
マイクロファイナンス
プライベート、コンソーシアムが増えてくるのでは？
・未来
ブロックチェーン：第二のインターネット
階層・規律・統制 ２０世紀型
自立・分散・協調 クラウド・データ連携（ＡＰＩ）・決済／契約
インターネット：コンピューター間の通信
クラウド：ＩＴリソースの最適化
ＡＰＩ：組織を超えたサービス連携
ブロックチェーン：中央を必要としない決済
スマートコントラクト：自律的な契約
■パネルディスカッション
ブロックチェーンが開く次世代システム連携
・ＱＡ
・ブロックチェーンがシステム開発の方法論を変えるか
イーサリアムとはいぱーれっじゃーふぁぶりっく
イーサリアム：言語ある
はいぱーれっじゃ；Ｊａｖａ
→機能的な違いがある
どのフレームワークにコミットするかは早い
いま、イーサリアム：柔軟性が高く、シンプル
ファブリックも選択肢の１つ
→ふくざつになり、運用難しくなる懸念
富士通：イーサリアムにも取り組んでいる
ケースバイケースで
ＢＣＣＣ：ブロックチェーンニュートラル
決め打ちするとイノベーションを阻害する
Ｚｅｎがイーサリアムの理由：現時点でそれしか選択肢がなかった
→どのブロックチェーンにもつながるところに挑戦している
いんふぉてりあ：みじん パフォーマンス
データベースでいいじゃないといわれないように
興味：ファブリックとコンソーシアムプライベートのチェーンの乗り入れ
個別の実装は大変
用途を置き換えるのは難しい
全銀協：ブロックチェーン でんさいねっとでも応用
データのフォーマット ＸＭＬ
スマートフォン前提？違うデバイス？
日本の電子ウォレット：まだひくい
地方高齢の人が使うか？はあるが、
個人認証として、生体認証と組み合わせるための使われ方
技術的にはかんけいない
スマホがフロントになっている
現金はなくならない、キャズムをこえるかが重要
ものごい：ＱＲコード
コストやすくなる？
電気代を考えると・・・
手数料など、エンドユーザーのトータルの価格でかんがえるといい
普及するとやすくなる。今は安くない。
システムの作り方が変わる。その部分で安くなる
ブロックチェーンがむいているところ
いろんな当事者：住宅のライフサイクル
著作権・利益の配分
株主総会の投票→投票にブロックチェーン
2017年5月期 AITC技術セミナー＆オープンラボ 「ブロックチェーンの最新動向を掴む」
https://aitc-seminar.connpass.com/event/57209/
に行ってきた！のでメモメモ
■ブロックチェーンの展望と課題 ～仮想通貨から社会インフラへ～
ビットコインのブロックチェーンから分散型台帳技術へ
台帳→ネットワーク
・基本的な仕組み
ブロックがチェーンのようにつながる
→いったん忘れてＯＫ
Ｂ２Ｂネットワークが基盤
・分散型台帳とは
データベースの対比
クライアントから書き込み要求
異なる要求を同時に受け付ける
何を正とするかきめる→アクセスコントロール
分散の場合
異なる要求が同時にきたら？
どれを正とするかをみんなできめる
→コンセンサスアルゴリズム
ＰｏＷなど
→エンドユーザーからはアルゴリズムは見ないでいい
分散したデータベース
分散型台帳を使うメリット
貿易業務
情報のバケツリレーが複雑→証跡性
リファレンスデータの共有
ＮＴＴデータの取り組み例
スマートコントラクト
貿易分野に力をいれている
貿易保険
今後はほかの分野も
ブロックチェーン 仕組みと理論
■地域金融機関とブロックチェーン
・日本ユニシス金融ソリューション
地方銀行１０行にはいっている
→たいへん
地域の中：２０１５年人口減少；地域に影響（お金の流れ減少）
Fintech：銀行以外の決済、楽天、Ａｍａｚｏｎが融資
→コーディネーターとしての役割
仮想通貨：地域通貨と新たな決済手段
・デモ
・クレジットカード
手数料コスト、初期コスト→手軽に導入できない
イーサリアムのフレームワークを使っている
問題点：出資法→銀行が発行する場合メリット（いつでも換金）
・その先
だれからだれにわたっているか：お金の流れ
ビットコイン：まわっていく→為替リスクある
地銀のばあい、１ポイント１円とかきめてしまう
さるぼぼコイン
ＱＲコード
インバウンド向け
琉球コイン
独立貨幣として提供：時価で変動
余ったら、資産価値→投資を呼び込む
・とりくみ２つ
地域通貨＋α：農産物 食品とーさびりティー＋お金の流れ
お金と物とトレーサビリティを一元管理
・まとめ
キャッシュレス送金→あらたな金融サービス→経営支援
■Blockchainの展望
・自己紹介
・グローバルに拡大する社会問題
過去１０年間でエネルギー価格は３倍
世界人口７０億人
６０歳人口 日本３０％
ロボットを動かす：電気→効率的
・イノベーションがもたらす豊かな未来
ヒューマンセントリックインテリジェントソサイエティに向けて
・地域スタンプラリー
クーポン、スタンプラリー：ブロックチェーンを使って
決済基盤Finplex ブロックチェーンと金融ＡＰＩ
・証券クロスボーダー取引
セキュリティ強化技術開発
ネットワークサービス
プラットフォームサービス
はいぱーれっじゃーを準備している
参加メンバーの管理
・コンセンサスアルゴリズム
社会実装
ＰｏＷ：電力が問題
Ripple Protocol
・まとめ
Society 5.0
マイクロサービスの提供：ＷｅｂＡＰＩとして
パーソナルなデータストア
■ＢＣＣＣ＆ブロックチェーン～最近の活動と実証実験～
・ブロックチェーン推進協会（ＢＣＣＣ）
・プライベート
・未来
・ブロックチェーン推進協会：ＢＣＣＣ
１４０社超が加盟
金融だけではない
流通
公共
製造
医療
→改ざんできない（管理者であっても）
最近の動向
金融機関に加え、幅広い業界から加速
・部会
広報部会
金融部会
スマートシティ部会：ＩｏＴ
リスク管理部会：ビジネスリスク
・社会実験
デジタルトークンＺｅｎ
仮想通貨
問題点：為替変動が大きすぎる
為替があっても安定する（保障ではない）
複数のブロックチェーンをまたがる
アウトではない
・Ｚｅｎ
イーサリアムをつかっているが、みじんとかも使える
ブロックチェーン大学校
・プライベートチェーン
電子マネー：ありがち
→処理スピード
野菜のトレーサビリティ
→パブリックチェーンにひも付：かいざんできなくさせる
行政サービス
アントワープ市だが、みじんが使われている
マイクロファイナンス
プライベート、コンソーシアムが増えてくるのでは？
・未来
ブロックチェーン：第二のインターネット
階層・規律・統制 ２０世紀型
自立・分散・協調 クラウド・データ連携（ＡＰＩ）・決済／契約
インターネット：コンピューター間の通信
クラウド：ＩＴリソースの最適化
ＡＰＩ：組織を超えたサービス連携
ブロックチェーン：中央を必要としない決済
スマートコントラクト：自律的な契約
■パネルディスカッション
ブロックチェーンが開く次世代システム連携
・ＱＡ
・ブロックチェーンがシステム開発の方法論を変えるか
イーサリアムとはいぱーれっじゃーふぁぶりっく
イーサリアム：言語ある
はいぱーれっじゃ；Ｊａｖａ
→機能的な違いがある
どのフレームワークにコミットするかは早い
いま、イーサリアム：柔軟性が高く、シンプル
ファブリックも選択肢の１つ
→ふくざつになり、運用難しくなる懸念
富士通：イーサリアムにも取り組んでいる
ケースバイケースで
ＢＣＣＣ：ブロックチェーンニュートラル
決め打ちするとイノベーションを阻害する
Ｚｅｎがイーサリアムの理由：現時点でそれしか選択肢がなかった
→どのブロックチェーンにもつながるところに挑戦している
いんふぉてりあ：みじん パフォーマンス
データベースでいいじゃないといわれないように
興味：ファブリックとコンソーシアムプライベートのチェーンの乗り入れ
個別の実装は大変
用途を置き換えるのは難しい
全銀協：ブロックチェーン でんさいねっとでも応用
データのフォーマット ＸＭＬ
スマートフォン前提？違うデバイス？
日本の電子ウォレット：まだひくい
地方高齢の人が使うか？はあるが、
個人認証として、生体認証と組み合わせるための使われ方
技術的にはかんけいない
スマホがフロントになっている
現金はなくならない、キャズムをこえるかが重要
ものごい：ＱＲコード
コストやすくなる？
電気代を考えると・・・
手数料など、エンドユーザーのトータルの価格でかんがえるといい
普及するとやすくなる。今は安くない。
システムの作り方が変わる。その部分で安くなる
ブロックチェーンがむいているところ
いろんな当事者：住宅のライフサイクル
著作権・利益の配分
株主総会の投票→投票にブロックチェーン
５月２５日、
JSUG勉強会 2017年その4 ～ Springを使ったバッチアプリケーション特集
https://jsug.doorkeeper.jp/events/60629
を聞いてきた！ので、メモメモ
■バッチは地味だが役に立つ
・一般的なＢａｔｃｈのイメージ
・バッチ処理とは
まとめて一括処理
大量データを処理するとき
・反対：オンライン処理
即座に処理
・ゴール：３つ
１．ＳｐｒｉｎｇＢａｔｃｈの基本機能や概念
２．できること、できないこと
３．てらそるなばっちフレームワーク
・Ｓｐｒｉｎｇ Ｂａｔｃｈについて
大量のデータを処理するために
便利な機能を提供
・なんでＳｐｒｉｎｇＢａｔｃｈについて話すのか？
身の回りで話を聞かない、Ｗｅｂでもまとまった情報がない
ＪＳＵＧのアンケートでは、長年興味があるテーマの上位
ＮＴＴデータの社内事情
てらそるながＳｐｒｉｎｇＢａｔｃｈを採用
・コンテンツ
１．ＳｐｒｉｎｇＢａｔｃｈ
２．てらそるな
・Ｓｐｒｉｎｇ Ｂａｔｃｈ
クイックスタート（でも）
・プロジェクトを作る
・バッチコンフィグレーション
公式ページをはる
うごく
・基本構成（チャンクモデル）
JobLauncher：Ｊｏｂを起動するためのインターフェース
Job:バッチアプリをまとめた実効単位
Ｓｔｅｐ：構成するしょりの単位
ItemReader/Proceeeser/Writer
読み込む
処理
かきこむ
ＸＭＬふぁいるでのジョブ定義
基本設定
Ｒｅａｄｅｒ定義
Ｐｒｏｃｅｓｓｏｒ定義
特徴：５つ
処理モデル
起動方法
データ入出力
処理の効率化
ジョブの管理
処理モデル
タスクレットモデル
Ｊｏｂ－Ｓｔｅｐ－Ｔａｓｋｌｅｔ
ＪｏｂのＢｅａｎ定義
タスクレットの実行
Ｊｏｂ－Ｓｔｅｐ－Reader/Processer/Writer
→ほとんど同じ。使い分け：ジョブごと
リカバリシンプル：タスクレット
起動方法
同期実行方式
非同期実行方式（Ｗｅｂコンテナ）
業務用件によって選択
データの入出力
・ふぁいるのよみこみ
Ｂｅａｎ定義
LineMapperの定義
Tokenizerの定義
Field Set Mapperの定義
・かきこみ
・処理の効率化
フロー制御
スケジューラーとフレームワーク機能で実現
ＪＯＢは１つ、複数のＳｔｅｐでフロー
nextに後続ＳｔｅｐのＩＤをかく
分岐
■Spring Boot アプリをPivotal web Serviceに
デプロイする４つの理由
（１）デプロイがめちゃ楽 cf push
（２）Spring Boot Actuatorのビューワー付き
（３）Spring Cloud Service
（４）PCF Metricsで分散トレーシング
http://run.pivotal.io/
■Yahooの広告レポートシステムをSpring Cloud Stream化するまで
・自己紹介
・概要
２０１３ 第一世代 集計、自前 perl,php
２０１５ 第二世代 Spring ポーリング型
：リクエスト数、ＲＤＢが耐え切れない
２０１７ 第三世代 RabbitMQ
・広告レポート
広告の配信実績の確認
レポート出力項目、集計単位は指定可能
ユースケース
通常レポート
定期レポート
レポートのリクエスト数：右肩上がり
システム全体
ＡＰＩから
配信ログ集計
・第一世代
課題：処理が依存し合っている→品質を担保できない
開発に時間がかかりすぎて、ログ量の増加や機能拡張に追いつけない
運用コストが高い
眠れない
→開発スピードを上げたい、寝たい
・第二世代
Spring 疎結合、Hiveでリアルタイム
Hive on Tez：二次集計が不要、眠れるようになった
くわしくは
ＪＪＵＧ ＣＣＣ ２０１６ Ｓｐｒｉｎｇ
Spring 広告システム刷新の舞台裏 PHPからJavaに変えてみました
https://www.slideshare.net/techblogyahoo/jjugccc-cccf1-phpjava
全体のスループットは遅くなった
ＲＤＢが高負荷
・第三世代 Spring Cloud Stream
ＭＱ？
レポート作成をイベントドリブンに行いたい
Spring Cloud Stream
マイクロサービス
パブリッシャー、サブスクライバ型
Spring Boot
consumer group・・・スケールアウトして対応できる
binder abstraction
レポート作成を１つのグループにする
リリース：ダウンタイム０に
新システム稼働→旧システムＯＵＴ
性能比較
プロセスはどちらも５５８
ポーリング 第二 １６９２８ 第三 ０
レポート作成数 第二 ４４１２１ 第三 ６３９３４
イベントドリブンにレポート作成、
デッド・エラー・キュー
・Ｔｉｐｓ
Spring Boot APIは苦労なかった
Spring Batch
１アプリケーション１jarにした
単発バッチ
常駐バッチ
１サーバーに複数プロセス
spring.main.web-environment=false
→２．０から非推奨。WebApplicationType
DataSourceを２つ指定
プレゼン資料は
https://www.slideshare.net/techblogyahoo/spring-cloud-stream-jjugccc-ccca4
にある
JSUG勉強会 2017年その4 ～ Springを使ったバッチアプリケーション特集
https://jsug.doorkeeper.jp/events/60629
を聞いてきた！ので、メモメモ
■バッチは地味だが役に立つ
・一般的なＢａｔｃｈのイメージ
・バッチ処理とは
まとめて一括処理
大量データを処理するとき
・反対：オンライン処理
即座に処理
・ゴール：３つ
１．ＳｐｒｉｎｇＢａｔｃｈの基本機能や概念
２．できること、できないこと
３．てらそるなばっちフレームワーク
・Ｓｐｒｉｎｇ Ｂａｔｃｈについて
大量のデータを処理するために
便利な機能を提供
・なんでＳｐｒｉｎｇＢａｔｃｈについて話すのか？
身の回りで話を聞かない、Ｗｅｂでもまとまった情報がない
ＪＳＵＧのアンケートでは、長年興味があるテーマの上位
ＮＴＴデータの社内事情
てらそるながＳｐｒｉｎｇＢａｔｃｈを採用
・コンテンツ
１．ＳｐｒｉｎｇＢａｔｃｈ
２．てらそるな
・Ｓｐｒｉｎｇ Ｂａｔｃｈ
クイックスタート（でも）
・プロジェクトを作る
・バッチコンフィグレーション
公式ページをはる
うごく
・基本構成（チャンクモデル）
JobLauncher：Ｊｏｂを起動するためのインターフェース
Job:バッチアプリをまとめた実効単位
Ｓｔｅｐ：構成するしょりの単位
ItemReader/Proceeeser/Writer
読み込む
処理
かきこむ
ＸＭＬふぁいるでのジョブ定義
基本設定
Ｒｅａｄｅｒ定義
Ｐｒｏｃｅｓｓｏｒ定義
特徴：５つ
処理モデル
起動方法
データ入出力
処理の効率化
ジョブの管理
処理モデル
タスクレットモデル
Ｊｏｂ－Ｓｔｅｐ－Ｔａｓｋｌｅｔ
ＪｏｂのＢｅａｎ定義
タスクレットの実行
Ｊｏｂ－Ｓｔｅｐ－Reader/Processer/Writer
→ほとんど同じ。使い分け：ジョブごと
リカバリシンプル：タスクレット
起動方法
同期実行方式
非同期実行方式（Ｗｅｂコンテナ）
業務用件によって選択
データの入出力
・ふぁいるのよみこみ
Ｂｅａｎ定義
LineMapperの定義
Tokenizerの定義
Field Set Mapperの定義
・かきこみ
・処理の効率化
フロー制御
スケジューラーとフレームワーク機能で実現
ＪＯＢは１つ、複数のＳｔｅｐでフロー
nextに後続ＳｔｅｐのＩＤをかく
分岐
■Spring Boot アプリをPivotal web Serviceに
デプロイする４つの理由
（１）デプロイがめちゃ楽 cf push
（２）Spring Boot Actuatorのビューワー付き
（３）Spring Cloud Service
（４）PCF Metricsで分散トレーシング
http://run.pivotal.io/
■Yahooの広告レポートシステムをSpring Cloud Stream化するまで
・自己紹介
・概要
２０１３ 第一世代 集計、自前 perl,php
２０１５ 第二世代 Spring ポーリング型
：リクエスト数、ＲＤＢが耐え切れない
２０１７ 第三世代 RabbitMQ
・広告レポート
広告の配信実績の確認
レポート出力項目、集計単位は指定可能
ユースケース
通常レポート
定期レポート
レポートのリクエスト数：右肩上がり
システム全体
ＡＰＩから
配信ログ集計
・第一世代
課題：処理が依存し合っている→品質を担保できない
開発に時間がかかりすぎて、ログ量の増加や機能拡張に追いつけない
運用コストが高い
眠れない
→開発スピードを上げたい、寝たい
・第二世代
Spring 疎結合、Hiveでリアルタイム
Hive on Tez：二次集計が不要、眠れるようになった
くわしくは
ＪＪＵＧ ＣＣＣ ２０１６ Ｓｐｒｉｎｇ
Spring 広告システム刷新の舞台裏 PHPからJavaに変えてみました
https://www.slideshare.net/techblogyahoo/jjugccc-cccf1-phpjava
全体のスループットは遅くなった
ＲＤＢが高負荷
・第三世代 Spring Cloud Stream
ＭＱ？
レポート作成をイベントドリブンに行いたい
Spring Cloud Stream
マイクロサービス
パブリッシャー、サブスクライバ型
Spring Boot
consumer group・・・スケールアウトして対応できる
binder abstraction
レポート作成を１つのグループにする
リリース：ダウンタイム０に
新システム稼働→旧システムＯＵＴ
性能比較
プロセスはどちらも５５８
ポーリング 第二 １６９２８ 第三 ０
レポート作成数 第二 ４４１２１ 第三 ６３９３４
イベントドリブンにレポート作成、
デッド・エラー・キュー
・Ｔｉｐｓ
Spring Boot APIは苦労なかった
Spring Batch
１アプリケーション１jarにした
単発バッチ
常駐バッチ
１サーバーに複数プロセス
spring.main.web-environment=false
→２．０から非推奨。WebApplicationType
DataSourceを２つ指定
プレゼン資料は
https://www.slideshare.net/techblogyahoo/spring-cloud-stream-jjugccc-ccca4
にある
５月２５日、
第５回 日経コンピュータサミット
日経コンピュータから読み解く、デジタル・ＩＴの最新潮流
を聞いてきた！はなし、最後は「極言暴論！」
■「極言暴論！」筆者が問うデジタル時代の”常識の非常識”
・ITPro若い人が読んでいる
・働き方改革
噴飯もの。
ライフスタイル改革
そもそも、業務改革があった→できてないですよね！
ここで、働き方改革って・・創意工夫で頑張って？
会議を減らす・・・はいいけど、
リモートワーク：場所はおうち、休みたいとき→リモートワーク＝おうちで働く？
ワークフロー：どこまでも追いかける：昔だったら代理がやったのに・・・
→いまのやりかたで・・・サイゼリアで仕事してる？
属人化してる：いまでも
それを変える→業務改革：効率化→短時間
それをしない→残業がみえなくなるだけ
標準化→部分最適化
別の言葉でいえば、カイゼン 改善が最もばかげている
経営者が丸投げしてしまう
２つのケースがある
マイナス：労基署に入られた。労働時間削減 そこで仕事辞めるしかない
→働かせない
プラス：社内にいろんな人。どこでも働けるように。１０年かけてリモートワーク
→改革リーダー：働き方改革 ＳＮＳで情報共有 表彰
情報システムは働き方改革できるのか
午前中までによろしく
・ＩｏＴ，ＡＩ
ＩＴ部門：うちじゃないです。事業部さんが独自に・・・
攻めのＩＴ増やせば、守りのＩＴ＝ＩＴ部門が減っていく
（憂いているわけではない）
経営判断として、事業部
いまのところ、トライアルだから、単独で大丈夫
ＩｏＴ金儲けのためのシステム
うまくいったら、どうなるの？
→基幹系との接続は？
第二の部門を作れ！
それぞれ別個でやればいい
スマホが進化→いいものができる
ＩＴ部門が手一杯：デジタルの連携手一杯
第５回 日経コンピュータサミット
日経コンピュータから読み解く、デジタル・ＩＴの最新潮流
を聞いてきた！はなし、最後は「極言暴論！」
■「極言暴論！」筆者が問うデジタル時代の”常識の非常識”
・ITPro若い人が読んでいる
・働き方改革
噴飯もの。
ライフスタイル改革
そもそも、業務改革があった→できてないですよね！
ここで、働き方改革って・・創意工夫で頑張って？
会議を減らす・・・はいいけど、
リモートワーク：場所はおうち、休みたいとき→リモートワーク＝おうちで働く？
ワークフロー：どこまでも追いかける：昔だったら代理がやったのに・・・
→いまのやりかたで・・・サイゼリアで仕事してる？
属人化してる：いまでも
それを変える→業務改革：効率化→短時間
それをしない→残業がみえなくなるだけ
標準化→部分最適化
別の言葉でいえば、カイゼン 改善が最もばかげている
経営者が丸投げしてしまう
２つのケースがある
マイナス：労基署に入られた。労働時間削減 そこで仕事辞めるしかない
→働かせない
プラス：社内にいろんな人。どこでも働けるように。１０年かけてリモートワーク
→改革リーダー：働き方改革 ＳＮＳで情報共有 表彰
情報システムは働き方改革できるのか
午前中までによろしく
・ＩｏＴ，ＡＩ
ＩＴ部門：うちじゃないです。事業部さんが独自に・・・
攻めのＩＴ増やせば、守りのＩＴ＝ＩＴ部門が減っていく
（憂いているわけではない）
経営判断として、事業部
いまのところ、トライアルだから、単独で大丈夫
ＩｏＴ金儲けのためのシステム
うまくいったら、どうなるの？
→基幹系との接続は？
第二の部門を作れ！
それぞれ別個でやればいい
スマホが進化→いいものができる
ＩＴ部門が手一杯：デジタルの連携手一杯
アクセス
トータル
ランキング
