QCon Tokyo 2016に参加してきました。以下は参加記録メモ（自分用）です
QCon Tokyo とは
InfoQJapanが主催で、最新技術を追い求める技術者・アーキテクト・プログラマ・クリエイターのためのカンファレンス
開催概要
- 開催日: 2016/10/24
- 場所: ベルサール新宿グランドコンファレンスセンター
基調講演
■エンジニアリングの物語り（ストーリーテリング）～人に語るに値するカルチャー
Pete Soderling 氏 （Hakka Labs)
- エンジニアリングカルチャー
- 大事なものをハイライトしてくれる
- アメリカでは、チームの多様性をどう保つのかとデータサイエンティストにどうやってコーディングを教えればいいのかが問題になっている
- OSSのコーポレートサポート
- アメリカではOSSを会社がサポートしていることを誇りにしている
- 在宅勤務
- エンジニアにとってオープンオフィスでうるさい環境を何とかしてあげたいという解決策
- エンジニアリングのカルチャーが上手いく解は存在しない
- レシピは存在しない
- ストーリーを語って文化的な価値を届けてくれる
- 物語
- 規範的ではなく記述的
- 知識を共有するのに良い
- 我々が存在している理由を語ってくれる
- モチベーションを高めてくれる
- なぜ文化が大事なのか？
- 他の人間にインスピレーションを与えることができる
- チームをまとめていく力になる
- エンジニアリング文化のExample
- Autonomy（自立性）
- エンジニアは管理されたくない
- 例：Google
- エンジニアはマネージャを信用しない
- マネージメント層を減らしている（ただし、マネージャを0にしたらそれは失敗した）
- インスピレーションが生まれ、イノベーションを生む
- トレードオフ
- 文化を変えるためには一度文化を破壊する必要がある
- Impact（影響力)
- 例：Facebook
- 速く進んで壊すということをずっと実施している(ただし、今は壊すという部分は変えた。)
- あまりQAをしない
- 入社して2日目で、すぐにコードをリリース対象に含めることになる
- トレードオフ
- 成長に伴って文化を変えていく必要がある
- 例：Facebook
- Ownership
- 例：Etsy
- 全てエンジニアが責任を持つ
- 書いたコードに誇りを持たせる
- 例：Netflix
- もともとモノシリックなアプリケーションを作っていたが、マイクロサービスに分解して30以上のチームもに分けた。
- 個々のチームにサービスを所有させた（エンジニアにサービスについての責任を持たせた）
- 例：Etsy
- Learning
- 例：Pivotal
- XPを採用
- ペアプログラミングを実施している
- 新卒で採用したエンジニアをペアプログラミングで優れたエンジニアに育て上げる
- 例：Pivotal
- Autonomy（自立性）
- フォーカス
- 例：Etsy
- Code as Craft
- 求人広告は通常無味乾燥なものだが、Etsyでは求人広告でストーリーを語ることで魅力を高める
- 例：Etsy
■ポスト・ムーア法則時代のコンピューティング
佐藤一郎 氏 (国立情報学研究所 アーキテクチャ化学研究系 教授)
個人的にこのセッションがもっとも興味深かったです。
- ムーアの法則
- トランジスタの数は毎年倍増する
- スケーリング則
- 半導体微細化が1/kになれば速度はk倍、集積度はkの2乗倍、消費電力は1/k倍
- ムーアの法則が成り立っている間は、ソフトウェアのオーバーヘッドを気にしなくても良かった。いずれハードウェアが早くしてくれる
- ムーアの法則の綻び
- 微細化のスローダウンが進行中。36カ月で2倍に修正
- IT機器の性能が上がらなくあってきている
- 半導体の製造技術の限界
- 電力的な限界および経済的な限界（重要）
- 半導体製造技術の状況
- 5nm未満では量子効果により特定にばらつき（物理的な限界）
- スケーリング則の破綻
- 2000年代中頃にはスケーリング則は成り立たなくなっている
- 動作周波数が上がらなくなっている。消費電力量も下がらなくなっている
- 電力的限界:ダークシリコンの増加
- 発熱を考えると消費電力が100Wを超えるチップは作れない（エネルギーの壁）
- 稼働率を上げられない回路（ダークシリコン）が増加
- 微細化が進むとダークシリコンの比率も上がっていく
- ダークシリコンを活かすには
- メニーコア化して、動作周波数を下げる
- ダークシリコンをキャッシュメモリとして活用
- 経済的な限界
- 14nmクラスの半導体工場は1兆円超え
- 1兆円の工場でペイしようと思うと月産100万枚以上
- 14nmでは半導体工場への最低注文数は300万枚以上
- 性能コスト費が改善しなくなった時点で、経済活動としてムーアの法則が成り立たない
- トランジスタ価格比は28nm以降は悪化
- 微細化そのものは可能でも計算量当たりの単価は上昇
- フィンテック
- ブロックチェーンのProof of Work はコンピュータの性能向上が前提
- ムーアの法則の限界はブロックチェーンの限界になりえる
- ブロックチェーンのProof of Work はコンピュータの性能向上が前提
- 半導体に頼らずにソフトウェアの性能向上を目指す必要がある
- クラウドビジネス
- クラウドのコストの大半は電力代
- 計算量当たりのクラウド利用料は下げ止まる可能性がある
- クラウドのコストの大半は電力代
- ベンダー&SI
- 新しいコンピュータを買っても性能が上がらない
- システム更新メリットがなく、運用期間が伸びシステム更新案件が減少
- 新しいコンピュータを買っても性能が上がらない
- 性能改善（ハードウェア編）
- 正解は見つかっていない。様々な挑戦をするしかない
- カンブリア紀の進化爆発状態
- 現在上がっている方向性
- メニーコア化
- 多コア化はメモリバスの輻輳をもたらす
- マルチスレッドプログラミングは避けられない。が、本質的に難しい。
- 大容量メモリを活かす
- 不揮発生メモリの利用
- 機械学習の世界では必要性が高い
- 専用ハードウェア・GPUによるアクセレーター
- NVIDIAの１強状態なのが少し怖い
- 専用チップ（ASIC他）
- FPGA
- 分散処理（サーバ台数）でカバー
- 壊れたコンピュータといずれ壊れるコンピュータしか世の中には存在しない
- データセンター間の遅さをどうするか
- Rack-Sale Architecturue
- 非フォンノイマン型アーキテクチャ
- メニーコア化
- ポストムーア時代にソフトウェア技術者はどうすればいいか？
- 余計なことにトランジスタは使わない
- コンピュータサイエンスに基づいた改善が必要
- ハードウェアやソフトウェアの原理を扱うコンピュータサイエンスの知見は不可欠
- ソフトウェア技術者屋の性能改善が認められる時代になるかもしれない
■日本情報システムの未来革新に向けて
浦川伸一 氏 （損保保険ジャパン）
- VUCA
- ResilienceとLFP（軽い足跡）ベースの経営
- 現行システムの状況
- Complex
- Fat
- Narrow
- 刷新の後に目指すところ
- 3つのS
- Simple
- Slim
- Speed
- データ移行はしない。あきらめた
- 3つのS
- Architecturueの検討
- IF社
- 戦略的な部分が全部内製している
- SoR / SoE
- 全社のシステム環境を絵分類し疎結合化
- Microservices
- 難しい。使えるエリアを限定してトライしている
- 直接インスタンス生成（new）を使わないようにしている（徹底的にやっている）
- Framework
- 基幹系でSpring, Wicket, Playは情報量が少ないのでつらい。Java EEに決定した。
- Cloud
- 日本にデータは置きたい
- IF社
Engineer Track
■モダン化が進むソフトウェア開発環境に取り入れるべき最新のツール事情
根本 竜也 氏 (マクニカネットワークス)
- ソフトウェアを中心とした価値開発の変革
- あらゆる分野で重要性を増すソフトウェア開発
- 4つのキーワード
- Time to Market = 市場の声に迅速に応えられるか
- Quality to Success = 安定した品質を提供し続けられるか
- Elexibility to Change = 一刻と変わるニーズに対応できるか
- Focus on Development = 開発者は開発に集中できるか
- 最高なソフトウェア開発環境の提供⇔優秀な人材の確保⇔企業の継続的な成長
- Modernizationの重要性
- 今あるソフトウェア開発環境は最高の環境といえるのか？
- 4つのキーワード
- 最高の環境とは？
- 統一された開発基盤
- プロジェクトメンバー全員で共有できる
- 開発に関するあらゆる価値が集約される
- アイデアを出しやすくする環境
- 手間のかからないテスト環境
- 開発者が開発に集中できる
- 管理運用の複雑性が排除される
- 高速処理を実現できる
- 生産効率を向上させるプロジェクト管理
- プロジェクト全体の進捗が一目でわかる
- タスクごとの重要性や寒冷性が容易に把握できる
- 統一された開発基盤
- モダン化を実現するツール
- GitHub
- Circle CI
- ZenHuba
- ソフトウェア開発者の現場の声
- リリースサイクルが長い
- コードレビューが徹底できてない
- いつ、誰が、なぜ、その機能追加・修正を行ったのかわからなくなる
- 似たようなモジュールを何度も作る
- 開発ノウハウが蓄積されない
- オープンソースの成功
- コラボレーション：
- 知識の共有化
- 透明性：問題・課題。アイデアをオープン議論
- GitHub Enterprise
- GitHub Flowというシンプルなフロー
- 企業文化のイノベーション
- 開発サイクルの短縮とリスクの最小化
- 開発環境の活性化
- コードの積極的な共有や活発な議論が起き、品質の高い開発を実現する
- 脱属人化・若手社員の教育にも
- より良いエンジニア確保のために人事からGitHub Enterpriseの予算が出て、買うというパターンも存在する
- レガシーCIツールの課題
- メンテナンスにコストと時間がかかる
- 選任管理者が必要
- Circle CI
- YAMLベースでコンフィグレーションできる。選任管理者が不要
- 並列ビルドによりパフォーマンスを実現
- 効果
- 開発者はより開発に集中できる
- ZenHub
- プロジェクト管理の理想
- PM： 全体的にどこまで進捗しているのか？
- 現場: 自分が関連するタスクの進捗をしっかり把握した
- GitHub専用のKanbanツール
- GitHub上のUIで使える
- 複数リポジトリをのissueを集約して管理することができる
- プロジェクト管理の理想
■DDDとマイクロサービスの現実と可能性
(1) 現場からの実践報告
上坂 貴志 氏 (ネクストスケープ)
- なぜDDDか
- 書籍紹介
- ユーザからの不満
- 開発側が自分たちのビジネスを良く知らない
- 解決したい課題・達成したい事がちゃんと伝わっているかわからない
- システム開発側視点
- ユーザの話は目的と手段が混在していて整理が大変
- ユーザからの話は解決したい課題や達成したいことそのものとは限らない。背景まで説明してくれないことが多い
- 原因は何？
- ユーザとシステム開発側、双方が持つ暗黙知が悪さをする
- DDDが提案する複雑さに対する解（一部）
- ユビキタス言語
- ユビキタス言語はモデル名やメソッド名、パッケージ名等あらゆる箇所で実際に使用する
- モデル駆動による設計
- 分析用モデルと実装用モデルの2つ用意するのは意味がない
- ユビキタス言語
- DDD実践報告
- メンバーにDDDを教育しないで始めてしまったため、メンバーがモデリング→実装をイメージできなかった
- モデリングが初期しか行われなかった。
- ER図から脱却できなかった。モデリングではなくER図になっていた。
- 原因は色々あるけど理由は恐らく「不安」
- 開発プロセスへの不安
- オブジェクト指向を採用することの不安
- 実は最大の原因はモデリングに対するベテランのおごりではないか
- オブジェクト指向が分かる＝モデリングができる という勘違い
- モデル＝ER図 という勘違い
- 成功例
- ソフトウェアアーキテクチャとサンプルを用視する必要がある。
- 成功・・・なの？
- モデリングに興味のない人は最後まで興味がない
- しばらく経ってから再度ソースコードを見直してみるとモデリングがおかしいことに気付く
(2) DDD & モデリング導入のコツ
増田 亨 氏 (ギルドワークス)
- ドメイン駆動設計に2つのブレークポイントがある
- ドメイン駆動設計の効果
- 役に立つソフトウェアを
- 確実に
- 効率的に
- ドメイン駆動設計の基本の活動
- 知識をかみ砕く → 開発者が業務を知る
- 言葉を活用する → チームで認識を合わせる
- モデルと実装を一致させる → 要求とコードを一致させる
- ドメイン駆動設計の原理
- 開発者が業務を広く理解すればするほど、役に立つソフトウェアを確実に効率的に作れる
- 2つのブレークポイント
- (1) オブジェクト指向
- データクラス＋機能クラスの世界からドメインオブジェクトの世界へ
- (2) インクリメンタルな設計
- 設計不要でもなく上流工程で設計するでもない世界へ
- (1) オブジェクト指向
- 体で覚えるオブジェクト指向
- オブジェクト指向エクササイズ
- 名前をつける
- データとロジックを凝集させる
- 複数の関心事を持たない
- 新規コードを書くときに本ルールを適用する場合より、既存コードからの置き換えのほうが理解のためには効果がある
- オブジェクト指向エクササイズ
- インクリメンタルな設計
- コードを書いてから動かしてから設計を改善する
- 最初から良い設計は見つからない。動いていても良い設計とは限らない
- インクリメンタルな設計 発想の転換
- アウトラインからはじまり少しずつ加筆し整形していく
- コードを書かない人間に設計やモデリングをさせない
- 初日からコードを書こうとしてみる
- ソフトウェアの設計を毎日行う
- 名前の変更、メソッドの抽出、クラスの抽出、フィールドの移動、メソッドの移動・・・etc
- コードを書いて動かして新しく得た業務知識をコードに反映する
- 変えるのは無理？
- どんな状況でも改善できる
- どんなときでもあなたから改善を始められる
- どんなときでも今日から改善を始められる
(3) DDD実践ベストプラクティス
加藤 潤一 氏 (ChatWork)
- 戦術
- CQRS
- コマンド・クエリ責務分離
- あらゆるメソッドはアクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方を行ってはならない。
- 質問をすることで回答を変化させてならない。
- ストレージもわけるCQRSアーキテクチャ
- Read StackにDomain Layerを含めない
- ドメインイベント
- データではなく何かしらの出来事=ドメインイベントをモデリングの主役する
- ドメインモデルをデータとして格納するのではなく、発生するイベントを格納する
- イベントのリプレイはSnapshot&Journal
- ドメインイベントとマイクロサービス
- Bounded Contextの連携にもドメインイベントが利用可能になる。
- CQRS
- 戦略
- マイクロサービスとコンウェイの法則
- システムの設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す
- 単一システム/単一チーム
- システム内の閉じた粒度の細かいコミュニケーション特性を持っているサービス内の変更やリファクタリングは効率的
- 単一システム/複数チーム
- 変更やリファクタリングのコストも相対的に高くなる。
- 大規模システムの保守が難しくなる
- チーム間のコミュニケーションはナローバンドになる
- マイクロサービスは、技術ドメインではなくビジネスドメインに倣ってモデル化されたサービス
- モデルを声に出して説明することの重要性
- 1つのチームに１つの言語
- 1つの境界に複数のモデルが存在するとバグの温床や信頼性の低下につながり、チームのコミュニケーションが混乱する
- マイクロサービスとコンウェイの法則
(4) パネル討論：DDDのいま 課題はなにか・今後どうなる
- Q: コンテキストマップ戦略
- 腐敗防止層
- レガシーシステムに対して新しい機能を作る際に採用した。初期実装コストはかかったが、それ以降の開発のコストは小さくできた
- 汚れたモデルを持ち込んでいたら、もっとコストがかかったと思われる
- 腐敗防止層
- Q: DDDはマイクロサービスの設計手法として有効なのか？
- 自然なチームの成長やコミュニケーションのためにマイクロサービス化していくのが良いのではないか？
- アップフロントでマイクロサービスとして作るのはまずいのではないか？現場の秩序を保つのにマイクロサービス化するのが良い
- 境界づけられたコンテキスト＝マイクロサービスが必ずしも正しいとは限らない
- Q: コンテキスト/集約と整合性
- ビジネスの要件次第
- Q: CQRSを採用しているか？
- 業務的な観点でCとQの間のリレーションを失ってはいけない
- CQRSで分けることを先行してしまうとこうなる可能性がある
- 業務的な観点でCとQの間のリレーションを失ってはいけない
■リアルタイム処理とコネクショニズム
庄野 逸 氏 (電通大) ・ 寺田 英雄 氏 (オープンストリーム)
- オープンストリームの技術経営
- 事業創造力を持った人材育成
- 戦略的な技術強化
- リアルタイム行動解析
- 行動分析、行動認識、・・・・
- 電通大庄野研との共同研究の理由
- AIの専門家の力を借りる
- 音楽の情報処理をAIで実施する
- 音楽情報処理はリアルタイム行動解析そのもの
- 庄野 逸
- 電通大でディープラーニングの医用画像応用 などの研究を実施している
- ビッグデータ時代のデータ解析
- インターネット時代の幕開けとともにデータの質、量が変化
- 分析技術は、多変量解析→機械学習、人工知能 と変遷
- データ科学・・第4のパラダイム
- ディープランニングの衝撃
- ディープラニング機械学習と書かないと予算が通りにくい。。。。
- ニューラルネットモデルを用いた人工知能技術
- 深い階層構造を持つことが特徴
- 人工知能界隈の歴史おさらい
- 記号処理的AI・・・Watson
- 特徴抽出の設計を人がやっていたが、大変になってきた
- 組み合わせ特徴を抽出するには？
- ハンドメイドな設計は辛い
- 人が扱う限度を超えたビッグデータだから
- ネオコグニトロン(DCNN)概説
- Convolution（単純型細胞モデル） Layer
- Subsampling(複雑型細胞モデル) Layer
- Alpha GO = DCNN + Q-learning + MCMC
- DeepMindのポリシー
- 目に見えるものにはDCNNで対応できる
■HTML5/フロントエンド開発最前線
白石 俊平 氏 (オープンウェブテクノロジー)
- TechFeed
- ITエンジニア向キュレーションサービス
- Webはいまだに重要なのか？
- ザッカーバーグ「HTML5を過大評価したのはわれわれ最大の失敗」
- 2016/2 Firefox OS開発終了
- 技術トレンドとしてはどうか？
- 検索キーワードや記事数などは減少傾向
- Extensible Web
- ユースケース駆動のAPIは抽象度が高すぎて使いにくい(１行書くと色々できるが、ユースケースにはまらないと使えない)
- プラットフォームとして見ると
- Webの利用時間は減ってきている
- Webは技術的な制約や問題が多い
- Webの利点
- Secure(安全)
- Linkable(リンク可能)
- Indexable(インデックス可能)
- Composable(再構成可能)
- Ephemeral(一時的な利用)
- Deep Link / Universal Link
- Webブラウザ上のURLを踏んだらアプリを起動する（踏んだリンクをアプリに渡せる）
- App Indexing
- Googleの検索結果からアプリを直接起動できる
- Webとネイティブ、双方のプラットフォームを往来する
- Web技術の利点
- クロスプラットフォーム
- Apache CORDOVA
- JavaScriptは世界で最も人気のある言語
- まだまだ進化がやまない
- 飽くなき速度向上への取り組み
- AMP(Accelarated Mobile Pages)
- 外部キャッシュ・高速レンダリングを前提とした制約付きWebページ
- Google/Twitterが仕様策定
- HTTP/2
- 1つのサイトにつき1つのTCP接続を永続的に割り当てることで高速化
- ES.next
- ECMAScript = JavaScriptの仕様
- この仕様をもとに各ベンダーがJavaScriptエンジンの開発を行っている
- ES.nextでクラスとモジュールが使えるようになった
- モジュールバンドラー
- モジュールバンドラ―でimport/exportをJSコード変換できる
- ECMAScript = JavaScriptの仕様
- 非同期処理
- Promise
- async / await
- コンポーネント指向開発
- AMP(Accelarated Mobile Pages)
- 飽くなき速度向上への取り組み
- プログレッシブ・ウェブアプリ
- クロスプラットフォーム
資料
本カンファレンスの発表者が公開している資料です。（私が聞いていないセッションのものを含みます）
