魔が差す心理的なきっかけ

きっかけ

下記のサイトを見て、チームビルディングについて改めて考えさせられた。
思ったことをちょっとまとめてメモっておく。

www.lifehacker.jp

哲学

「高潔さとは、誰も見ていないときも正しいことをすることだ」－C.S.Lewis（イギリスの学者）

開発している最終は、誰かに見られていないことのほうが多い。
もちろんレビューとかあるけど、レビューする前に精度が高いもののほうがいいハズ。
精度が悪い状態でくるのは、個人的には、魔が指す要素もある気がしている。
誰も見てないところで、適切に開発を行うことが、エンジニアに必要なのでは？と読んでいて思った。

魔が差す

気の迷いによりどのように道徳的指針を失い、道を踏み外す説としては下記の内容がある。
組織を作る場合は、下記を考慮して、人をまとめる必要がある。
※自分流に理解しやすいように、リンクの内容とは少し変えてる。内容は一緒。

1. 補償作用
2. 深刻さをちゃかす表現
3. 認知的不協和
4. 割れ窓理論
5. 目標達成圧力
6. ピグマリオン効果
7. 同調プレッシャー
8. 権威に対する服従
9. 勝者総取り方式
10. 絆
11. 権力に目がくらむ
12. 衒示的消費
13. 些細な盗みの看過
14. リアクタンス理論

補償作用

補償作用とは、不快感を払拭するための代償的な心理作用のこと。
例えば、１週間ランニングしたから、ご褒美としてケーキを食べるスイーツ女子の考え方がそうである。
気の緩みを起こさせないような制度設計をしておかないと、人はすぐに怠けてしまい、魔が差しやすい。

深刻さをちゃかす表現

表現の仕方が不適切であるがために、人し齟齬を起こし、結果として反倫理的な行動に繋がる。
方針等の重大な内容の告知は、表現を適切にしておかないと、悪用する輩が増える。
聴衆の立場をよく考えた上で、表現方法を考える必要がある。

認知的不協和

自分の心情に反しているけどやらねばならない行動をすること。
最終的に、行動と信条の不協和音から、破滅に至る。
ドラマでよくある魔が差すきっかけ。
指示を出す時は、その人の信条が何なのかを考えて、指示出しする必要がある。

割れ窓理論

混乱や無秩序があると、反倫理的なことを起こしやすくなる現象。
ソフトウェアの世界でもよく言われる。
バグ・エラー・警告を放置しておくと、最後に痛い目を見るのは、どこでも一緒である。

目標達成圧力

目標達成のために、思いやり・倫理的観点が欠落した行動を取ってしまうこと

ピグマリオン効果

他人からの扱いに応じた振る舞いをする傾向のこと。
血液型性格診断がコレにあたると思われる。

囚人と看守の役割期待が有名

同調圧力

所属するグループがとる反倫理的な行動に参加してしまうこと。
その行いに対し、大目に見る傾向が強い。グループの中で孤立するリスクも内包している。

孤高の存在である俺には、あまり脅威ではない。

権威に対する服従

権威ある人の指示は、無視しにくい。
また、自分の意志で行動するわけではないので、罪悪感が薄い。

上司からの命令が間違っていると分かっていてもやってしまうことはある。
あえて使うこともあるのではなかろうか？上司を辞めさせたいときに。

勝者総取り方式

勝者がすべてを持っていくやり方。
このやり方をやっていると、敗者になる人は、不正をしてでも勝とうとするので、いい結果にはならない。
一社独走態勢になれば、周囲から盗作されるリスクも高まるし、一回のミスが大事に取り沙汰されることもある。
また、競争相手がいなくなれば、勝者総取りの価値もなくなる。
独占禁止法は、存在しなければ、魔が差すきっかけができやすくなるとも言えるのではなかろうか？

絆

自分の価値を認められていると、忠誠心が強くなるが、疑心の目を向けられると、回避するために反倫理的な行動になりやすくなる。
絆は、いいことだと思っている輩もいるが、魔が差すきっかけにもなることには注意しなければならない。
結局のところ、絆を作るのはいいが、個々人でも倫理観はしっかり持ち、ダメならダメと言う必要がある。

権力に目がくらむ

権力のある人は、優れた特殊な存在だと思いがちで、他人が持っている倫理基準より甘い行動を取りやすくなりがち。
結果として、それが不祥事に繋がったりする。

散財

財力を派手に見せびらかすと、身勝手な度合いが強くなる。
結果として、欲望を優先させて動くようになる。

些細な盗みの看過

ささいな盗みを許容すると、限度なく膨れ上がる現象。
ささいな罪でも取り締まる必要がある。

リアクタンス理論

人は自由を好む。遵守すべき規則が厳しすぎると、規則を破ることが多くなり、規則が機能しなくなる。

まとめ

魔が差さないようにするのは、結構しんどい。
小さくても組織を作る際は、魔が差すきっかけがどこにあるのか、把握している必要性を感じた。

【用語】Rust 情報メモ

Rustとは

Mozilla Foundationが中心となって開発したOSS。
可能な限り抽象化のコストを下げるように設計されている。

特徴

• ゼロコスト抽象化
• ムーブセマンティクス
• 保証されたメモリ安全性
• データ競合のないスレッド
• トレイトによるジェネリクス
• パターンマッチング
• 型推論
• 最小限のランタイム
• 効率的なCバインディング

特徴メモ・解説

トレイトによるジェネリクス

トレイトとは、型が提供する機能をコンパイラに伝える機能のこと。
それをジェネリクスに適用している。
Javaをやっている人からすると当たり前に感じるかもしれない。

採用例

Servo

Mozilla Researchによって開発が進められている新しいWebレンダリングエンジン。
長期的なロードマップとして、Firefoxで採用されているレンダリングエンジンGeckoを、徐々にServoのコンポーネントに置き換えることが計画されている。

関連サイト

プログラミング言語Rust

プログラミング言語 Rust

Google Error Proneのサンプルを動かす

Error Proneとは

Google の バグチェックツール。
FindBugsみたいなもんといえば、Javaエンジニアなら想像しやすいはず。

環境情報

必要なものは、JavaとGradleだけあれば、とりあえず大丈夫

Java

Java9の調査をしてたので。。。
切り替えるの面倒だったから、Java9で試したが、Java8でもイケるハズ！
試すの面倒くさいからしないけど。

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+171)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+171, mixed mode)

Gradle

gradle -v

------------------------------------------------------------
Gradle 3.5
------------------------------------------------------------

Build time:   2017-04-10 13:37:25 UTC
Revision:     b762622a185d59ce0cfc9cbc6ab5dd22469e18a6

Groovy:       2.4.10
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          9-ea (Oracle Corporation 9-ea+171)
OS:           Windows 10 10.0 amd64

eclise

Eclipse Java EE IDE for Web Developers.

Version: Neon.2 Release (4.6.2)
Build id: 20161208-0600

とりあえず開発はコイツを使う。
コイツにGradleのプラグイン（たぶんBuildship Gradle Integrationだったと思う）を入れてテスト

試す

とりあえず、今回の目標は、exampleで提供されているものを実行してエラーになることを試す。

Gradleプロジェクト作成

eclipseから新規Gradleプロジェクトを作成

build.gradle を変更

下記リンク先のソースに置き換えれば大丈夫のハズ。

error-prone/build.gradle at master · google/error-prone · GitHub

念のため、自分が使った内容を晒しておく

// See https://github.com/tbroyer/gradle-errorprone-plugin
buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.8'
  }
}

apply plugin: 'java'
apply plugin: 'net.ltgt.errorprone'

repositories {
  mavenCentral()
}
configurations.errorprone {
  resolutionStrategy.force 'com.google.errorprone:error_prone_core:2.0.19'
}

サンプルソースの配置

Gradleでプロジェクト作ったら、Library.javaみたいなソースがあったので、それは消した。
そんでもって、下記のファイルを配置した。
どこでもいいと思うが、例にならって、src\main\java\Main.javaに配置した。

error-prone/Main.java at master · google/error-prone · GitHub

/*
 * Copyright 2013 Google Inc. All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

public class Main {
  public static void main(String[] args) {
    // Dead exception
    new Exception();
  }
}

FindBugsやってなくても、コレは「変」って分かるはず。
Exceptionをthrowしてないって。

実行

Gradleを clean & build ！
そうすると、下記のエラーが出てくるはず。

..src\main\java\Main.java:20: エラー: [DeadException] Exception created but not thrown
    new Exception();
    ^
    (see http://errorprone.info/bugpattern/DeadException)
  Did you mean 'throw new Exception();'?
エラー1個
 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed with exit code 1; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 0.841 secs

たぶん、意味的に「new Exception();っておかしくね？ throw new Exception();がやりたかったんじゃね？」ってことを行っていると思う。（銀魂風に翻訳してみた！）

感想

なんとかサンプルを動かすまでできた。
Gradleの存在は知っていたけど、使い方は知らなかったので、かなり手間取った。

あと、日本語の情報が異様に少ない。
みんな、FindBugsを使っているのかな？

コンパイル時に弾かれるから、直さないとUnitテストもできないので、かなり強制力が強い気がする。
※もしかしたら回避できるかも知れないが、俺にはここまでの実力しかないようだ。。。

ルールをカスタマイズしたりできるらしいが、ぶっちゃけよく分からん。
英語に対する苦手意識が強い。
FindBugsが本格的にダメになってきたら、ガンバってドキュメント読んで見る。
もしくは、誰か翻訳してぇ～
Google先生に翻訳お願いするしかなくなる。

今後のTODO

ルールのカスタマイズ

参考リンク

ksby.hatenablog.com

Error Prone

Installation

java9 Jigsaw 試し実装

きっかけ

Java Day Tokyo 2017, JJUG CCC Spring 2017 に出て、そろそろJigsawをキャッチアップしねぇと不味いなと感じ、とりあえず触ってみた。

環境情報

Microsoft Windows [Version 10.0.15063]

javaのバージョン

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+171)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+171, mixed mode)

コンパイラのバージョン
必要かどうか迷ったが、最初に入れたときにコンパイラバージョンがJava8のままで、module-info.javaが怒られて、結構迷うという恥ずかしい事態になったので、気付きの観点で載せる。

>javac -version
javac 9-ea

実験

公式サイトのクイックスタートガイド

Project Jigsaw: Quick Start Guide

自分は、Greetings worldからはじめました。

Greetings world

やっていることは、org.astroっていうモジュールを作って外部公開し、それをcom.greetingsで利用しているだけ。

src/org.astro/module-info.java
src/org.astro/org/astro/World.java
src/com.greetings/com/greetings/Main.java
src/com.greetings/module-info.java

$ cat src/org.astro/module-info.java
module org.astro {
    exports org.astro;
}

$ cat src/org.astro/org/astro/World.java
package org.astro;
public class World {
    public static String name() {
        return "world";
    }
}

$ cat src/com.greetings/module-info.java
module com.greetings {
    requires org.astro;
}

$ cat src/com.greetings/com/greetings/Main.java
package com.greetings;
import org.astro.World;
public class Main {
    public static void main(String[] args) {
        System.out.format("Greetings %s!%n", World.name());
    }
}

一番注目するべきは、src/org.astro/module-info.javaと、src/com.greetings/module-info.javaの内容。
exportsで外部公開。requiresで依存関係を宣言している。
そして、module-info.java以外は、Java8以前のものと一緒。
覚えなければ行けないのは、module-info.javaだけみたい。

実行方法

出力先のディレクトリを作成

自分windowsでやってたので、意図を汲み取ってディレクトリを作成。たぶん、macなら下記コマンドでいけるハズ。

$ mkdir mods/org.astro mods/com.greetings

org.astroをコンパイル

$ javac -d mods/org.astro src/org.astro/module-info.java src/org.astro/org/astro/World.java

com.greetingsをコンパイル

注目すべきは、--module-pathでモジュールを含むディレクトリを宣言しているところ。
指定はしなくてもいいんだね。

$ javac --module-path mods -d mods/com.greetings src/com.greetings/module-info.java src/com.greetings/com/greetings/Main.jav

実行

java --module-path mods -m com.greetings/com.greetings.Main

感想

とりあえず、やりたきことは確認できた。
覚えなければならないことは、module-info.javaの記述方法と、コンパイル＆実行方法だけみたいだね。
今回はサンプルのローカル確認で終了したが、次は自分で作ったソースでやれることを確認したい。

参考サイト

Project Jigsaw: Module System Quick-Start Guideをテキトーに訳した - kagamihogeの日記

JJUG CCC 2017 Spring 参加報告

公式サイト

JJUG CCC 2017 Spring

受講内容

感想・メモ

感想とメモが混じっているので、読む時は注意 スピード重視で書いているので、内容や誤字脱字は大目に見てね！

jjug総会

メーリングリストからDoorkeperに移行。 会員数が多すぎるのと、スパムメールが増えてきたため。

最近のスパムメールは、苛立ちを覚えていた。
帰ったあと疑問に思ったが、メーリングリストはクローズされるんだよね？
残っていたら、スパムメールが飛び続けるのではなかろうかって思った。

非機能要件とSpring boot

speakerdeck.com

非機能要件とは

主目的以外の要件。性能やセキュリティ機能など。 機能横断要件でとらえるのもありとかも言ってた。
これはIPAの定義だろうか？ どこから引用しているか見れんかった。

お客さんは、非機能要件がなんなのか分かりづらい。
その場に立ったことがないので、何とも言えんが。。。。
そんな場合は、IPAの非機能要求グレードを使うのが効果的らしい。
IPAが非機能要求グレードを出しているって初めて知った。
今回も合意のために利用しているようだ。

非機能要件にもいろろあるが、一部の要件は、フレームワークで対応することができる。それが、SpringSecurity & SpringBootActuratorなるものらしい。

Spring Boot Actuator

運用監視、活性保守をサポートする。 HTTP、JMXでアプリをモニタリング・管理できる。

インストールは、POIに依存性追加するだけ。

あとは、ブラウザでアクセスすればいい。 そうすると、JSONで結果が帰ってくる。

AuditEvents

認証認可イベント

health

アプリのミドルウェアの死活監視
独自の監視項目を追加することも可能

info

デフォルトではなにも表示されない
プロパティでinfo.があればそれを表示

git-commit-id-plugin

gitのバージョンを見れるようにしてくれる
gitバージョンを見れるのは良さそう
環境構築だけでなく、テストの障害報告とかにもバージョン情報はあると解析しやすいからね。

loggers

ログレベルの設定を確認できる。
特定のログレベルの確認もできる。
springbootでログレベルを変えられるので、効果が大きい。

metrics

cpu、メモリの情報が見れる exporterを実装するとredisなどにデータをエクスポートできる

trace

そのまま トレースログ見れる。

Spring security & other

パスワードポリシー

passay パスワードポリシーの作成ライブラリ

誤入力防止

terasolunaが提供している相関チェックアノテーションなるものがある。

ぶっちゃけ、Terasolunaって苦い経験しかなくて、あんまり使う気になれないのが、心情。

アカウントロック

spring fW @eventlistenerでイベントハンドリングする

データの秘匿

shaは辞めた方がいい。
sha系は速度優先のため、強度がそれほど高くない。
なので、ちょっと習熟すれば簡単に突破できるらしい。
passwordencoderを使うといいと勧めていた。

機密情報の暗号化

jasyptというライブラリを使って、暗号化すると楽らしい。
springboot-staterで提供されている

なお、シークレットキーはプロパティに入れないほうがいい。
入れたら暗号化の意味ないってのは、冷静にならないと分からなかったりする。

不正追跡・監視、トラッキングログ

サービスを跨いでも大丈夫なように、ユーザIDとリクエストごとに一意なトラッキングIDをもたせるのが一般的 横断的に追跡できる仕組みを用意しておくこと

Web対策

spring securityを使うことで、下記のことがデフォルトで対策される

• セッション固定攻撃対策
• xss対策(ただし、tymeleafを使った時)
• csrf対策(同上)
• セキュリティヘッダを自動で付けてくれる
  • キャッシュコントロール
  • https強制
  • コンテンツタイプの判定無効化

感想

springbootはアプリを簡易に作成できるだけのものだと思ったが、運用設計がやりやすい機能もあったのは意外だった。
SpringBootは、まだ知らない機能がいっぱいある。
使い始めが簡単なので、試してみる。　→　TODO 特にセキュリティは、知らないとまるで意識しないので、重点的に確認する。

知らぬ間に立ち見がいっぱいおった。 何気ないところでゴキブリを見つけた気分だ。 それくらいびっくりしたわ。

terasoluna押しやった。
ntt系の会社とお仕事しているのかな？って思ったら、主要取引先にあった。
長年terasoluna使っているっぽいね。

エンプラ開発におけるレガシーアプリケーションの巻取りとモジュール分割の戦い

2017spring jjug ccc_f2 from Kazuhiro Wada

www.slideshare.net

現状

Struts1系。
変更履歴をコメントアウトで保持。
既存のアプリがあり、新規アプリを担当。
既存アプリとは別口のアプリを作成した。

新規アプリを作るときに決めたこと。

レガシーフレームワークを引き継がない 従来の開発文化を引き継がない

変化スイッチ

なんのことかよく分からんかった。
意識が変わったきっかけってことでＯＫ？

終始、頭のなかで「やる気スイッチ」のＣＭが駆け巡っていたわ。

ブランチ運用

運用ルールが明確に定義されていない

バージョンごとの開発ブランチを作るような感じになっていて、masterへのマージは、リリース時

テスト自動化

エビデンス納品対象の制約があって、自動化にも制約がかかってしまった。
単体テスト　→　junitのソース納品
結合テスト　→　excelにハードコピーをペタペタ
結合は、seleniumのラッパーライブラリを使って効率化を図っている様子。
どこでもやってそう。

エビデンス納品を、単体レベルでも要求してくるところではなくてなくてよかったね！と言いたい。
単体レベルでも要求してくるところが、現実世界でもある。
※おとぎ話ではない！

辛いだけで、お客さんがそれを見てないと、何のために作ったのか分からんって思ってた。 実際、見てないしね。。。
恵まれているほうだと思う。

テストフェーズ

ここの開発でやっていたテストフェーズの概念

• 単体
  機能確認。JUnitでテスト自動
• 画面単体
  画面の機能確認。JUnitではテストしきれない機能を確認
• 結合
  機能間の連携確認。Excelペタペタ

開発時の課題

テストケースのレビューが辛い。
JUnitのソースが見づらいと、網羅性が分からない。
レビュー者の負荷が高いので、レビューしやすいようにテストケースを作ることを心がけた。

現在の課題

ロジックに沿ったテストになってしまっている。 仕様に沿ったテストケースにしなければいけない。

テスト環境デプロイ

ローカルに落として デプロイが手作業で煩雑 並行開発だとテスト環境が足りない

pushするとビルドが走る。 デプロイする場合は、ビルドされたもの選択してデプロイしている

大人の事情

大人の事情により、既存アプリの保守も担当することに。
大人の事情だから、たぶん既存アプリの保守していたチームが、疲弊したか、障害多すぎてお客さんに愛想つかされたかのどっちかだろうね。

デプロイの話を聞いていたが、あり得ない状態だった。
本番warを解凍　→　classファイル差し替え　→　再圧縮　→　デプロイ
最初のwarは、eclipseでビルドされたものらしい。
闇を見た気がする。
そうとうに業が深い。
お客さん側に、システム開発に精通した人が居なかったのだろうか？って感じた。

新規アプリで確立・成功したデプロイ方法になるように、既存状態を改修。
その過程は、省略だったのが惜しい！

モジュール分割

当初、ベンダー単位でモジュールを分割していた。そのせいで、できていないことが結構あった。
1社体制でのモジュール分割 　マージ最小化 　依存の最小化 　モジュールごとの非機能要件

古いアプリを徐々に新しいアプリに移植
　→　新しいモノリシックなアプリを作っているだけでは？
確かにその通り。
結局のところ、APIで機能を作らないと、いくら刷新してもモノリシックな状態のものが出来上がるだけだと思っている。

変化

成功例がでないと、変化は起こしにくい印象

一括再構築

信頼関係のもと、段階的に再構築するしかない 世のトレンドをどうやって適用できるかを考えておかないと、説得ができない

チャンス

最後のチャンスを使う話は納得
チャンスは誰でも平等にくるけど、それを掴めるのは、準備している人だけ
だから、常日頃から、流行のトレンドをどうやって適用していけるか考えておかないと、変えるチャンスが来ても、逃してしまう。

感想

エビデンスの話は、言いたいことが結構ある。
まだ、恵まれている方だと思うが。。。
本当に辛いところは、単体レベルでもExcelペタペタを要求してくる。しかも、説明のコメント付きで。
SIerに多い印象がある。

チャンスの話は、ビジネス書みたいな感じだった。
日頃から準備してないと、チャンスが来ても逃げるってのは、納得。
ものにできないで終わるか、そもそも気づかないか。
常日頃から神経を研ぎすませていないとダメだと思う。

SpotBugs(FindBugs)による大規模ERPのコード品質改善

Java静的解析ツール機能・動向

checksyle

ソースコード解析をコンパイルなしで実行 コーディング規約の確認が主目的
OSSでは割りと使われている。 理由は、いろんな人が開発に携わるため。

PMD

ソースコード解析をコンパイルなしで実行 問題の発見が目的 CPD(コピペ検出)機能がある。

FindBugs

ソースコードではなく、バイトコード解析をする

SpotBugs

FindBugsの代価でデカくなってきた。

checker Framework

JSR308を利用する。 デファクト化しつつある。

Google error-prone

コンパイル時に動作 ソースコードの自動修正機能がある eclipseに非対応

Javaスキルの高い開発者がおおい

アノテーションの利用催促とspotbugs

Javaスキルにばらつきがある

checkstyleでコーディング規約を守るようにする

QA

Sonar lintがないのはなんで？
→　チェック内容の実態は、PMDとかFindBugsと変わらないので出さなかった。 　　複合的にルールを組み合わせるとこは素晴らしいと思っている。

コード品質が抱える問題と解決

開発している製品のアピールが長い！ チェンナイってどこ？

デフォルト設定のまま使っていた

ビルドに時間がかかり、FindBugsを使うとパフォーマンス出ず、チェックをスキップする輩がいた。

きちんとやる／やらないを考えて適用を考える。

個人的にはデフォルト設定で運用して、変えてくでもいいと思っている。 明確な基準がある場合は、別だけど。

FindBugsが遅い

G1GC→回避できない
そもそも使うメモリが多ければ大丈夫だけど、それをするのは大変

他にも何か言っていた気がするが、ちょっと意識が飛んでた。。。。
たぶん、別の誰かが憑依したんだと思う。

文型さえおさえれば英語を読む力は上がる！

speakerdeck.com

ポイント

• 辞書の意味を当てにするな
• 文脈に頼りすぎない
• 例外を気にしすぎない
• 雰囲気で読まない

Google翻訳するなって言ってなかったからＯＫでいいよね。。？

５文型

というか、「文型」って書いて「ぶんけい」って読むことに驚いた。
てっきり誤字かと思ってたわ。。。

• SV
• SVC
• SCO
• SVOO

なんか、SVって言われると頭が痛い。。。
なんかの業務でSVってのが居た気がするが、なんだっけ？
商流系だった気がする。

文型については、意識したことない。

気をつけること

日本語の単語のまま使うのはダメ。
名刺っぽい単語でも、他動詞になるものがある。

introduction of project jigsaw

言っていることは信じないでくださいか。。。
jigsawがどうなるか分からないってことだろうか？
仕様承認の投票で、SE9は通ったけど、jigsawが通らないっていう謎の状態なのね。。。

red hat, ibmが反対
だから、信じないでくださいにつながるのか。

背景

いつものjar地獄とhadoopのクラスパス
Jigsawの話でココらへんのことを知らない人は居ないと思うので省略。

module

moduleかどうか判断する場合は、module-info.javaの存在有無を確認する。
ある→モジュールとして使う
ない→モジュールとして使わない

module-infoに書くもの

• 依存関係
• 公開範囲

module-info.javaの置き場

トップレベルに書く

module-ingoの内容

依存関係

requiresで指定する。

java.lang　→　必ず使うので、記載しなくても依存に含まれていると思って良い。

publicは、exportしない限り、以前のpublicと同じではない。

モジュール化で公開有無が変わったため、Class.getInstanece()が使えなくなっている。

モジュール化したい場合

jdepsを使って、依存を見極める

jdepsについては、JavaDayTokyo2017のまとめにも出てきたので、よかったら見てみて

suzaku-tec.hatenadiary.jp

jreの自作

–genarate-module-info をjavacにつけると、独自のjreを作ってくれる

モジュールの扱い

自信はモジュールで、モジュールじゃないものを使う
automatic moduleを使う
安易なモジュール名になってしまうのが論点になっている。
automatic-module-nameを付けましょう的な流れになっているが、どうなるかは分からない。

QA

mavenとmoduleは、どうやって整合性をもたせるのか？　→　まだ決まってない

メタ情報なのにjavaなのはなんで？jsonじゃダメ　→　jsonbが入ればそうなるんじゃない？
javaでjson使うのは面倒くさいので、javaでいいんじゃない？

module化した場合としない場合の起動のち外　→　そんなに変わらない。モジュール読む量によるかも。

moduleのバージョン　→　いまのところ掛けない

スーパーパッケージ　→　なくなった。

Java8コーディングベストプラクティス & NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

jmxでデータを収集して、influxdbに突っ込み、grafanaで見る。

深層学習の話は、ある程度、知識としてあったので、なんとかついて行けた。
教師データは、たしかに教師データが正解だから、深層学習する意味ないよねってのは分かる。
深層学習を追い求めるロマンティストだったんだね。。。

Java8のプラクティス

基本的に、分かっているつもりの内容だったので、あんまり聞いてなかった。
たぶん、意識飛んでたと思う。

マチコ&河村の怒り新党 〜真の最終回〜

本家終わりましたからね。

初頭のトークは何を言っているかわからなかったが、内輪ネタかな？

場所を選ばないはずのITなのに東京開催の勉強会に腹が立つ

東京くれば？ もしくは、自分で内輪で開催すればいいのではなかろうか？

実際に地方にいる人の意見だと、開催できない最大の要因は、金より人材な感じっぽい。
やっぱり数は力なんだね。

動画配信要因は、有志で募集中 勝手にやるのはNGなんで、声かけてね！

人いっぱいいるから、動画撮影好きのヤツはいる気がする。
それが山本さんだけなのかな？

CCCを地方開催するには、金の問題と人が集まるかが問題な気がする。
個人的には、関東でなければ、行かないと思う。

自分の上長の期限を伺うために、自分の部下に無茶振りする上司に腹が立つ。

そもそも昔からある。 企業文化として根付いている気がするので、このまま行けば仕事をしていれば出世できると思うよ？

周りに期待してもしょうがないから、転職すれば？って意見が最終だった

Javaの人は別の言語を勉強しろ！

この人はJavaしているのか不明の状態でスタート。。。

自分は、Python勉強中、Typescriptを業務で使用中。Javaは使ってないんだよね。。。
別の言語を勉強してもいいけど、Javaから多言語でも通用するような普遍的な知識を得られているから、結局他の言語勉強しなくてもいいかな？って思う。
一つの言語に習熟したら、他の言語もだいたい通用する。
現に、自分はTypescript知らなかったけど、全然問題なく使えているもの。

確かに、言語で何をしたいかが重要だね。
言語は手段であって、使えることが目的になると、ビジネスが成り立たなくなるような気がしないでもない。
「こういうこと言うからには、もちろんお前は複数言語を同じレベルで使えるんだよな？」って、喧嘩腰で聞きたくなる。

同僚が全く勉強しません

同じネタだね。。。

別にいいんじゃない？
自分が必要性を感じてないなら。
外部から働きかけても、内部からやる気を起こさないと、無意味だと思うんだよね。
その環境なら、転職するしかないね。 環境に不満を感じているなら。

勉強とは、周囲とのギャップを埋めるための勉強ってのは、納得の意見だ。 周囲が勉強しないことに不満を感じているなら、それは自己満足ってのも納得。 上司は、だいたい自己満足で勉強しろって言ってくるからな！

個人的には、周囲が勉強しないのは、むしろ好環境ではなかろうか？って思う。 だって、自分は勉強して優位に立てるんだから。 むしろお願いしたい。周囲の人に勉強しないでくださいって！
周囲との差別化も測れて、上司受けは好調にもなるしね！
ずっと自分の優位性が確保できる環境って素晴らしいと思うんですよ。

出た意見として、社内で少数でもいいから勉強する土台を作って、そこから徐々に変えて行くのがいいのではなかろうか？って意見もあった。

やった身の上からすると、だいたい付いて来ない。
上から圧力かけるかしない限りは、動かない。

老害が許せません

居場所を守るためにコミュニティを作ったり、昔の自慢話するのが許せない。

前回もあった気がする。
自分はぼっちなので、特に思うことはない。
一番気になるのは、電車で喋っている２人組で、上長っぽい人が自慢話が一番許せんと思うな。
なんか、スゲー偉そうにしていて、腹立たしく思うことが多々ある。
自社は、特に関係がないので、なんとも感じない。

我慢して時間が流れるのを待つしかないのか。。。？ あれだ、電話かけてもらうアプリを使って、その場を切り抜けるってのが優良策かな？

新しいことにチャレンジしたいなら、老害を論破するしかない。
論破も、完膚なきまで。
そこまでできないなら、自分も害悪になっていると思うしかないね。

怒り心頭なこと

最後募集かけてたけど、人前でそういうこと話すのは、スゲー雰囲気悪くするから、名乗りでないと思うんだよね。。。

帰りの電車の中で思ったが、いくつかあったわ。

1. 言っていることが矛盾しているPJリーダーに腹が立ちます。改善案を出せと言ってきたので、出したらみんなが聞いている前でディスる所業が始まりました。なんとか耐えましたが、その後、改善案を出す人は居ませんでした。このリーダーは本当に改善案を求めていたんでしょうか？
2. 勉強しろという上長に腹が立ちます。上長は大して勉強していないくせに、配下メンバーには勉強を強いてくる。ここは、自分がやって言える立場になってからいうことだと思うのですが。。。
3. 満員電車に腹が立ちます。満員状態で乗ろうとしたら、おっさんがDio並に「無理無理無理」って連呼してきました。乗るのを辞めたら、後ろから若い女性が乗り込もうとしました。その女性は乗れたのですが、その時は「無理」って言わないんだな。死ねばいいのに。
4. 長いものに巻かれる上司に腹が立ちます。アーキテクチャの概念から、機能配置はこうあるべきと進言したのですが、上長で却下されました。理由を説明しましたが受け入れてもらえませんでした。その後、エンドユーザーのシステム開発のアーキテクトレベルの人が、まったく同じ指摘をしてきたら、その指摘は反映されました。なぜ？

あんまりシステム開発とかに関係ない気がする。。。

次回

かりそめになるのか。
かりそめ天国は、はっきり言ってつまらんからな。。。

ちょっと不安が募るわ。。。

Sli.doとか使って、匿名で意見もとめないと、発言しにくいんじゃなかろうかって感じる。
ただ、節度ある発言ができるかは疑問が残るけどね。。。

懇親会

LINE株式会社の寿司提供。
ありがたや～

寿司も、ワサビ付がデフォで良かった。
今のワサビ抜きの考えは間違っていると思うんですよ。

特に誰とも話すことなく、ある程度食して終了。
思ったけど、みんな顔赤すぎではなかろうか？
こんなに弱い人が多いんだなって感じた。

全体通しての感想

今回は、午前中（総会までかな？）は、人が全然いなかったのに、一気に増えた。
1000人もあのフロアでうごめいていたのかと思うと、驚愕。
全員倒したら、無双になれる！ってどうでもいいことを考えながら懇親会で食べてました。

あと、全員顔見知りなのだろうか？
自分、超小企業から来ているので、単独で参加している。
なんかみんな顔見知りみたいな感じで、ちょっといづらさは感じた。
いつもなら感じないんだけどね。流石に人が多すぎて、感じずにはいられなかった。

ToDo

• Jigsawを試す
• そろそろカンファレンスに登壇を考えてみる
• Spot Bugsを試してみる
• Google error-proneを試してみる
• Spring Boot Actuatorを使ってみる
• Spring Securityを使ってみる

関連リンク

前回のJJUG CCC

suzaku-tec.hatenadiary.jp

直近のJava記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

Java Day Tokyo 2017 参加報告

開催概要

公式サイト

www.oracle.co.jp

受講セッション

• 基調講演
• Java 9 and Beyond: Java Renaissance in the Cloud
• Modular Development with JDK 9
• Introduction to JShell: Official REPL Tool for Java Platform
• Java SE 9のすすめ

内容・感想

かなり大雑把に書いてあるので、ちょっと間違てるかも。

去年のJava Day Tokyo内容

suzaku-tec.hatenadiary.jp

基調講演

日本オラクルCEO 杉原氏

IT人材→2030年に60万人不足の見込み。
オラクルとして、一人一人のちからを伸ばす、百人力で解決していくらしい。
問題は、全員そう思っているかどうかだね。
その場に流れされて作業しているようでは、この問題への解決は難しいと思われる。
本人が能力向上を真摯に考えてないと、外部からいくら働きかけても、生産性の向上は低いと思われる。
やはり、能力高い連中がいる中に入っていかなければ、ならないと感じた。

今後のJava EE & SE

オラクルとして、クラウドに本格的に注力している見込み。
その主軸であるJavaには、クラウドをより快適に使えるような機能が追加されていく。

Project Valhara

データの定義の仕方に注力していく印象

Project Panama

Arrays2.0 データの扱いに注力している印象

今後の動向

データに関するインパクトが大きい印象を受けた。 その根底には、関数に必要となる柔軟な型が必要だと感じているのではないかと思われる。

Mazda

今年はMazda。
工場ラインにJavaが使われているらしい。
てっきりC, C++とかだと思ったけど。

データ管理部分の基幹系で使っているみたい。

従来

開発環境、アーキテクチャ、フレームワークを全て共通化している。 基幹系として使っているので、後方互換があるJavaが最適だった

最近

関数を使った柔軟なプログラミング。 大量データ処理。

フレームワークは、肥大化しつつある。そのため、Jigsawには期待している また、大量データを利用しているので、GCの問題に直面している。
今後、データを効率的に活用できる機能に期待している。

jshell

javafxと組み合わせると、統計とかが即時に見れたりしそう。
活用方法が、スクリプトくらいだと思っていたが、他にも用途がありそう。
とくにjavafxと組み合わせると、分析を効率的にできるのではなかろうかと思った。

以前、記事でまとめた。

suzaku-tec.hatenadiary.jp

自転車競技でのJava

現実世界の弱虫ペダル？？
計測危機を競技用自転車につけて、勝つために必要な指標をだしたり、勝てるようにするためにトレーニングに活かしているらしい。 個人的に熱かったのは、加速のところ。 ギア比を適切に変えて、適切な負荷をかけていかないと、加速が得られない。 いかにトップスピードに乗れるかが鍵らしいね。

コーチ向けに、データ分析方面には、javafxを使っているらしい。 そして、各サービスは、spring bootで実現しているような資料だった。

今後、勝つために必要な指標の算出、勝つために必要なトレーニング＆能力向上の最適化されたトレーニングの発案のためにIoTが使われていく。

そこら辺は、ＩＴナビゲーター２０１７年版にも書いてあったな。
今後、この流れは主流になりそうな気がする。

suzaku-tec.hatenadiary.jp

Java 9 and Beyond: Java Renaissance in the Cloud

javaで機能追加する優先度

1. セキュリティ
   クラウドで一番気にされるから必須
2. 更新しやすさ
   クラウドのメリットである開発速度の向上を目指す
3. 密度
   安価で安心なものを提供していく。これはクラウドでも要求されるので

Java9

モジュラーと、セキュアでクラウドで更新が簡単なモノを提供するのが、主な内容

jlink

jreを自作できる 小さくつくることができるので、カスタマイズでき、必要なものだけ入れることができる 静的なライブラリになるので、環境にあったものができるようになる。

容量によるライブラリの選別が可能になる。 容量多いから、自前で必要最低限の機能を用意するとかもできるのか。。。
というか、そんなことできるのか？
嘘じゃないか凄く疑いたくなるんだけど、いろんな記事で言及してあるし、嘘じゃないっぽいな。

AOT

静的コンパイラ

翻訳になってるのか？ 直訳すぎて、内容が意味不な箇所がいくつかある。 やっぱり覚えないといけないな、英語を

jshell

Javaでスクリプトチックなことができるようになった。

G1GC

Java9からデフォルト。

Java9の先

• ユニフォームモデル
• メモリの最適化・コンパクト化
• 相互互換性
• ライブラリのコンパクト化
• パフォーマンス

すべてクラウドで結果を残せるようなことを念頭において、機能追加していく印象。
基調講演でも言っていたが、クラウド対応には本腰を入れてやっていくみたい。

データ構造

データは、容量を食いやすい。
もっと最適でコンパクト化されたクラス定義を探している状態。 Cのストラクチャのような、コンパクトなデータ構造を考えている。
データの入れ替えを簡単にできるようする予定。

ネイティブ系に近いことをするのだろうか？
ココらへんの話は、以前チラッと聞いたことがあるきがする。
Java10でメインの機能になりそうな気がする。

Project Panama

ネイティブにデータが存在していることが多い。 そのアクセスにはかなりコストがかかる。 それを楽にすることを主眼に置いている。

Modular Development with JDK 9

全てがモジュール化されるようになった。

アクセス修飾子

public protected なし private

パッケージ間で使うには、publicしかなかった JDK9では、publicが3つの意味を持つようになった。

java.base

javaならどんなパッケージでも使っているはず。

指定が間違っているとコンパイルエラーが発生する。

exports：外部に公開するパッケージ requires：依存するモジュール(パッケージ単位ではない)

java9のモジュール化の違い

module-infoのある／なしだけ
ソースへの影響は、最小限になるように注意したある様子。

jdk

起動・コンパイル時にモジュールの依存関係が非同期でチェックされるため、ClassNotFoundExceptionが実行時に発覚することが少なくなる。

Manavenとか使っていると、よく発生した記憶がある。
解決しようとすると、インフラ担当やフレームワーク担当に事象の説明したり調整が必要だったり、スゲー大変だった。
それがなくなるのだとしたら、早く使いたい。
ただ、解消されるまでに、かなりの山を超えなきゃいけない気がする。
まぁ、いまJavaは使ってないんですけどね！

発生しうる問題

循環参照

だいたいが開発ミスなので、デフォルトNG

モジュールをまたがったパッケージ

そんなのつくっちゃラメェェェ！

モジュールの導入方法

jdkがモジュール化しているので、合わせれば自ずと最適なモジュール化になるはず。

jdkがモジュール化されているからといって、既存のライブラリはモジュール化する必要はない。 モジュール化するには、上から順々に配置場所を確認して行くといい。 そのためには、jdepsを使って、依存を確認して、配置場所を見分ける。

jdeps

Java8から入っているが、依存関係をわかりやすくするツールとして使える。
コイツを使って、依存関係をはっきりさせて、Java9を楽しもう的なことを行っていたと思う。たぶん。。。

外部javaライブラリのモジュール化

automatic modulesで解決出来る。
自動でモジュール化する機構らしい。
ただし、すべてのモジュールに依存するようになるので、なるべく書かないほうがいいと感じた。
使わないで済むなら、そうなるようにすべきだと思う。

モジュール化でやらなければいけないこと

モジュールパスにライブラリのパスを通すだけ

モジュール化

価値もあるけど、注意も必要。
例えば、今まで見えていたクラスが見えなくなって、コンパイルエラーになるなどもある。
特に、作ったライブラリを提供している時は、どうするかをよく考える必要があると思われる。

第三者のライブラリは、automatic moduleで対応できる

Introduction to JShell: Official REPL Tool for Java Platform

手元で数行のコードを各

IDEを汚す

Webサービスでやる セキュリティの観点から、独自ライブラリを上げづらい バージョン対応

他の環境

replツールを使って、即時実行できる環境が提供されている Javaにはなく、徐々に人気が失われている要員になっている

jshell

クラス宣言不要

public, final →無視される なぜなら、jshellで記載されたらどこからでも参照されるので、無視

宣言は、修正して更新することも可能

前方参照

宣言を行う前に参照を記述できる そのため、記述しておいて、あとで宣言することも可能。 入れ子になっていたりする場合は、この仕組で解消している。

強い型付け言語のJavaでこれができるのは、以外

jshellコマンド

すべて"/“で始まる

できること 履歴／スニペット表示／編集／保存

Startup

jshell起動時に実行される カスタマイズ可能。 デフォルトは、jdkの大名パッケージ 設定は、/setコマンドで実行可能

設定した内容は、永続化されない。 永続化するには、/setで永続化オプション(-relate)を付ける

JShell API

jline→jshell tool→jshell coreの順に伝わる 入力が終わったら、コンパイルされ、クラスファイルができて実行されるらしい。 デモ見た限りだと、そこまで遅い印象はない。

• jshell
  入力の受け口
  受けっと値を評価して、ShippetEventoに渡す

• SnippetEvent
  評価さえたコードを受け取る

• SourceCodeAnalysis
  入力が終わったのか判定する

• xxxsnippet

debugコマンド

内部の挙動のトレースができる

Q&A

jshell→スクリプトファイルにできる

jshell内でスレッド実行　→　別JVMで動いているので、jshellには影響なし

jshellの用途　→　今後模索

同一JVM内で実行しない理由は？　→　jshellに影響をあたえるため、別JVMで実行している

thisは使えるか？　→　トップレベルでは無理

いつも使うライブラリをデフォルトで読み込めないか？　→　コマンドで頑張ればできるから、頑張れ

製品として組み込みで使えるか？　→　難しい。やればできるけど、おススメはしない。 JVMがデフォルトで２つ立ち上がるので、パフォーマンスが悪い

importしたものをあとで外す　→　コマンドで外せる

jshellのステップ実行　→　現段階では無理。今後できるようになるかも

Java SE 9のすすめ

compatibility

language & library

アンスコだけの変数　→　使えなくなる 　そもそも使っている人は少ないから、たぶん大丈夫だと思う 　Java8使ってたころは、警告等は見かけなかった。

アンダースコア始まりは、問題なく使えるので、大丈夫

いろんなメソッドが使えなくなっている。(使用頻度少なそうなやつ) ほぼJigsaw関連。 deplicateの奴があり、いつ使えなくなるのかわからないので、注意して開発する必要がある。

vm & tools

Java Plug-in Applet サポートが無くなる

Windows x86 Client VM →　なくなった Javaでクライアントサイドのやつを使ってやる人は、要注意

JavaDB →　消えた

operation & management

Visual VM →　死んだ hprof, jhat →　なくなった

運用面は、結構被害が大きそう

JRE構造

• jre-9
  • bin
  • conf
  • lib

rt.jar, tools.jar, lib/ext, -Xbootclasspathは、天に召された。

G1GCがデフォルトになる。メモリが少ない場合はParallel GC。
CMSは、deprecatedになった。
いつなくなるのか不明のため、早めに移行計画をする。

brand new

reactive streams

非同期処理のためのインタフェース インタフェースだけの提供。実装は今後。

JEP incubator modules

キュウべぇのことではない。
non-final applicationsのこと。
つまり、最終版ではないAPIをいれようぜってことらしい。
なくなるのか、どうなるのか分からないので、使う場合は要注意。

試験的な位置づけらしい。
研究職向けなのかな？
意図までは、セッションでは分からなかった。

update

milling project coin

ちょっとした変更をいれようぜって感じだと受け取った。
project-coinで入ったものを、もう少し使いやすくするらしい。

try-with-resources

readerの変数定義をtryでしなければいけないので、面倒くさい finalにすれば指定可能にする 実質finalの概念も適用される

ダイヤモンド演算子

匿名クラスでは、ダイヤモンド演算子が使えなかった。
それが解消された。 ワイルドカード(?)など、型推定できない場合は、エラーになることがある。

匿名クラスは、ラムダが出たので、使う機会が少ないかもしれない

streams

ラムダでfor分みたいなことができるようになった。 Collectors.flatMapping, Collectors.filteringが追加。

Optional

• stream()
• ifpresentorelse
• or

Collection

of()

作られたものはイミュータブルになる。 今まで定数としてlistとして使いたい場合、かなり面倒くさいことをしてたものが、かなり楽になる。

いわゆる不変コレクションってヤツが作れる。
下記の記事で一回まとめた。

suzaku-tec.hatenadiary.jp

String

char →　byte に変わった 文字列が占める容量の割合が大きいために対応されたみたい。
日本語は、以前と同様にutf-16になる。

＋連結

StringBuilder →　InvokeDynamic 必要なときに容量確保されるので、最適化がされるはず。

deprecated

何時からってのが使える様になる deprecatedのものは、必ず確認or消す努力をしないと、アップデートできないって事象に陥る可能性がある。

全体通しての感想

疲れた。
朝の満員電車で、体力をゴソッと持って行かれたのが辛い。
年のせいか、体力が持たない。
まだ２０代のハズだが。。。
ポケモンGoで毎日チャリに乗って３０分くらい駆け回っているけど、そんなんじゃ体力強化できないってことがわかった。

Java9は、Jigsawの変更内容が追いきれていないって感じがした。
あと、Jigsawばっかりに目が行って、他の変更が頭に全然はいってないってことがよくわかった。
特にStringは、char→byteになったのは結構衝撃的だった。

jshellは、やり方知っていたけど、全体を俯瞰しての作りを知れたのは大きい。
ソフトウェアに組み込むのは難しい印象を受けた。
どっちかというと、開発を補助するツールって印象。
JavaFXとの親和性が高い印象を受けた。
JavaFXを学ぶことの有用性があった気がする。

今後するべきタスク

• Jigsawのサンプル確認
• Stringの変更点確認 char→byte
• jshellとJavaFXの連携

【書評】ITナビゲーター２０１７年版

ITナビゲーター2017年版

目次

• 第1章　2022年に向けてICT・メディア市場で何が起こるのか
• 第2章　デバイス市場
• 第3章　ネットワーク市場
• 第4章　プラットフォーム市場
• 第5章　コンテンツ配信市場
• 第6章　ソリューション市場

感想

第1章　2022年に向けてICT・メディア市場で何が起こるのか

ケータイ事業は、スマートフォンへの補助金が削減。
そのため、ＭＶＭＯが台頭。
ケータイ３社は、物より価値を売る努力をしないと存続が難しい。
ＭＶＭＯは、補助金が続くので、２０２０年まで価格競争が起きそう。

ＡＩ

判定のブラックボックス化が進む。
ＡＩ分野は米国に遅れを取っている。
普及した時、選択肢がGoogleしかない可能性がある。
日本がGoogleに勝つには、特定分野で勝つしかない。
各業界に与えるインパクトは、下記の通り。

製造業

• 故障の予知
• ロボット同士の協業

金融

• クレジットの査定
• ローン審査

ＡＩで判定がブラックボックス化してしまうため、リスクの少ないマーケティング分野での適用から順次開始されると思われる。

医療

• 問診結果から病名の特定
• 臨床試験の分析

教育

採点分野での適用

小売業

• 代理店舗（Amazon Alexaとか）
• 在庫管理

アート分野

コストの高い作曲・作画分野に適用する動きがある。

ＶＲ

軍事目的から発展。
バーチャルボーイは、発売当初の技術では足りないものが多すぎた。

課題

• ＵＩ
• 消費者の活用シーン
• 商品用途

ＶＲの利用シーン

一人一台となるため、他人と面白さを共有しにくい。
体験機会をどうやって増やすかが課題

商品用途

アミューズメント・不動産・イベント運営が牽引

アミューズメント

アトラクションの疑似体験。
建築費の削減と費用回収期間の短縮、新規アトラクションの早期立ち上げが見込まれている。

不動産

現地確認のコスト削減

イベント運営

冠婚葬祭などのイベント内容をイメージしやすくさせる。

ＶＲの今後

集客のあり方に変化があるかも。
現実を超える時、ライフスタイルの変化が起こりそう。

ブロックチェーン

経済産業省より、インパクトの大きい技術との発表あり。
今後、政府主体で何かに導入される可能性が高い。

特徴としては、Ｐ２Ｐを利用した履歴管理。
履歴をブロック単位で管理し、すべての内容をノードで共有している。
システム停止が発生しにくいことが最大の特徴。

活用シーン

• 行政
  投票・土地の登記簿などの書類関連、本人証明の簡略化など。
• 金融
  相対取引への適用
• IoT
  認証関連

課題

活用用途を模索中の段階。
標準化、人材不足、法整備が問題としてある。

Ｃ２Ｃシェアリングエコノミーと個人

Ｃ２Ｃシェアリングエコノミーとは、インターネットを介して行われる個人間の取引。

今後、こういったインターネットを介しての取引が、より活発になる。
異業界の連携が主戦場になりそう。

課題

補償・衛生面の問題がネック。
統合管理が難しい。

スポーツを進化させるＩＣＴ

ＩＣＴを活用して、戦術の立案・分析に活用する。
利用目的として、競技レベルの向上、ファン層の拡大とコア化を狙っている。
スポーツにも、データアナリストを置くような流れになっている。

第2章　デバイス市場

IoTの普及

データが爆増。
デバイス側で精査する流れ。

携帯電話端末

中国が飽和状態。
次の市場として、インド・アフリカが有力視されている。

日本の市場は、やや鈍化。
ガラケーの利用者は、もう減らないレベルまで到達。
端末としての販売は、国際市場では厳しい。
ただし、利用される部品が広く普及しているため、日本製の携帯端末がなくても直近の問題はなさそう。

タブレット・電子書籍端末

縮小傾向。
電子書籍端末は、タブレットでよくね？って流れになりつつある。

市場は、Amazon優位。
キーボード着脱式のタブレットが普及しつつある。

次世代テレビ市場

買い替え需要で２０２０年前後がピーク。
国際市場では、中国・韓国メーカーが問題。
価格競争以外で勝負する必要がある。
４Ｋ・８Ｋは、政府による推進がある。
今後、実用チャンネル数は増えていく。

産業用イメージングデバイス

順調に成長。
中国メーカーとの価格競争が激化。
テロ等に悪用される危険があり、法整備が急務。

カメラ単体での付加価値は低い。
解析機能を含めたシステムの提供が必須。

車載情報端末

カーナビは、購入時の購入率が高い。
後付は、減少傾向。

サイドミラーが、カメラモニターに代用されるようになってきた。
アニメにあったようなことが技術的に可能になってきたが、普及の問題がネック。

ウェアラブル端末

Apple Watchの発売をきっかけに、スマートデバイスの認知が高まる。
市場拡大には時間がかかりそう。

Ｂ２Ｂロボット

産業用以外の協調型ロボットが好調。
インフラ整備を含めた生産ラインの見直しが起こりつつある。

機械をシステムの一部として捉える流れがある。
ＩＴ業界は、他業界の接続する、グルー（糊）的な業界になりつつある。

３Ｄプリンター

市場は拡大中で、シェア争いが激化しそう。
製造業以外にもインパクトが大きい。
物流は、データ受け渡しによる貨物の現象。
流通は、メーカーからのデータ購入が、今後起こりそう。

第3章　ネットワーク市場

求められる要件が多様化している。
次世代通信規格の５Ｇによって、大容量、高速、低遅延、高密度が実現されそう。
固定・モバイル通信の違いはなくなりそう。

固定ブロード回線

飽和状態。習熟度の低い人をどうやって取り込むかが課題。

モバイルキャリア、ワイヤレス

回線数は増加中。
固定・無線回線が一体となる２０２０年がネットワーク環境の転換ポイントになりそう。

第4章　プラットフォーム市場

スマートペイメントが成長。
インターネット広告は、スマホにシフトしつつある。
ポイントサービスは、共通ポイントが焦点になっている。

第5章　コンテンツ配信市場

ゲーム市場

PlayStation、任天堂が牽引。
スマホとの差別化が問題。
海外を視野に入れた販売戦略が浸透しつつある。
ソシャゲでは、Pockemon Goが躍進。
今後は、戻ってきたユーザを逃がさない策略が必要。
有名キャラを使ってユーザを取り込む流れが強い。

電子書籍・雑誌・新聞

大きな変化はない。
市場の拡大は鈍化しそう。

動画配信

定額制が躍進。
広告・ＣＭをどうするか重要。

放送・メディア

４Ｋテレビの普及の流れ。
ＴＶの位置づけが低下しているのが市場拡大のネック。

第6章　ソリューション市場

クラウドデータセンタ、法人ネットワーク

トラフィック量が拡大中。
クラウドで技術の変化、多様化するようになり、予測ができない。

IoT

ソフトウェア開発とともに拡大。
利用しやすいシステム構築が求められている。

エッジコンピューティング

ローカルにデータを保管して、必要なものだけクラウドに送る。

エナジーハーベスト

環境エネルギーから電力を貰い、機器を連続稼動させる。

感想

全体的にIoTのインパクトが大きい印象。
ラズパイとかいじってると面白いから、開発側のやる気も高いのではないかと思われる。

意外だったのは、クラウド関連。
予想する側が分からんって言うのか。。。って感じた。
確かに、カオスモンキーとか頭狂ってる奴しか思いつかねぇだろうって思う。

あとは、ＶＲ・ＡＲがインパクトデカそうな印象。
早く進化して、遊戯王の実体化デュエルをしたい！！

今後の目下の目標は、IoTといったネイティブな環境の開発スキルをサブウェポンとして身につけたい。
Web系は、継続して学習かな？
まだまだ発展の要素がある。
7:3くらいの割合でやっていきたい。