QCon Tokyo 2016参加レポート

More than 1 year has passed since last update.


はじめに

QCon Tokyo 2016に行かせていただきました。

招待いただきありがとうございました。

個人的なまとめを、つらつら書いていきます。


基調講演1

エンジニアリングの物語り(ストーリーテリング)~人に語るに値するカルチャー

Engineering Storytelling - Culture Worth Talking About

Pete Soderling 氏 Hakka Labs

最高のエンジニアリングチームを作るにはどうすると良いのか?

* カルチャーは、いろいろな衝突を解決することに醸成されてきた。

* 文化を学びストーリーテリングを学ぶと、よりよいリーダーになることができる。

* ストーリーを語り文化を伝えると、インスピレーションを他の人に与えることができる。

良い文化とは、

* 自主性、自立性がある

例: Googleは、最小限のマネージャー、全体の20%は自由な時間

そうすることで、インスピレーションが生まれ、チームの繋がりも強くなった。

カルチャーを変えるなら、「Move fast with stable infra」: 迅速に作って壊す

* インパクトを与える

* オーナーシップを持つ

「自分の書いたコードに責任を持つ」

エンジニアがサービスの責任を持つということにすると、文化が変わった。

また、アーキテクチャの変更が文化の変化につながった。

* 常に学習し続ける

ペアプロはいいぞ。


基調講演2

ポスト・ムーア法則時代のコンピューティング

佐藤一郎 氏  国立情報学研究所 アーキテクチャ科学研究系 教授

ITは、ムーアの法則に依存している。

現代は、ITに依存しているから、ムーアの法則は現代に影響する。

ムーアの法則が綻びると、ITによる生産性課題の解決ができなくなるってことが懸念される。

コンピュータ性能が向上しないということは、課題解決が向上しないということ。

電力的な限界と経済的な限界がきている。

最新のコンピュータに変えても性能向上しないと気付くと、ソフトを変えない

システムを更新しなくなる。

現状のシステムをなるべく長く使うことに関心事が変わる。

世界には、2種類のコンピュータしかない。

壊れたコンピュータと、

いずれ、壊れるコンピュータ


基調講演3

日本の情報システムの未来革新に向けて

~日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道

浦川 伸一 氏 損害保険ジャパン日本興亜株式会社 取締役 常務執行役員

http://qiita.com/y_q1m/items/d818786d10f6df1d2b69


マイクロサービス・アーキテクチャのパターンとベストプラクティス

Patterns & Practices of Microservices

Wesley Reisz 氏 C4Media社

* CQRS

* EventSourcing

* サーキットブレーカー


DDDとマイクロサービスの現実と可能性


(1)現場からの実践報告

上坂 貴志 氏 株式会社ネクストスケープ

マイクロサービスのパターン?非同期処理のパターン!

クラウドデザインパターンの本に解説がある。

モデリングとER図は違う!!

間にはレイヤーがある。

DDD導入を成功させるには、

* ユビキタス言語を定義する。

* モデルをドメインレイヤーに閉じ込める。

クラウドの良さを生かすなら、非同期処理。


なぜDDDなのか

DDDは設計手法だけではない。

開発プロセス全部まとめてやるから意味があります。

ユーザーと開発側と差が生じる。理油は、お互いが暗黙的な一般常識に当てはめてしまうから。

コンテキストが違えば、同じ言葉でも違う意味を持つので、ユビキタス言語として定義していく必要がある。

モデル駆動は、お客様の前でやるからこそ、DDDは威力を発揮する。

分析用と実装用のモデル2つ用意することもあるけれど、意味がない。


(3)DDD&モデリング導入のコツ

増田 亨 氏 ギルドワークス株式会社

ドメイン駆動設計の効果

* 役に立つソフトウェアを

* 確実に

* 効率的に

ドメイン駆動設計の基本の活動

* 知識をかみ砕く

* 言葉を活用する

* モデルと実装を一致させる

ドメインをかみ砕く = ドメインのオブジェクトモデルを作っていくこと

ドメイン駆動設計を支える技術

* オブジェクト指向

データクラス + 機能クラス → ドメインオブジェクトの世界へ

* インクリメンタルな設計

具体的にチームの習慣にする

ドメイン駆動設計の2つのブレークポイント

* オブジェクト指向

* インクリメンタルな設計

オブジェクト指向のおすすめ本

* オブジェクト指向エクササイズ

9つのルールがポイント

1. 1つのメソッドでインデントは1段階

2. else句はつかわない

3. すべてのプリミティブ型と文字列をラップする

4. 一行につきドットは1つまで

5. 名前を省略しない

6. すべてのエンティティを小さくする

7. 一つのクラスのインスタンス変数は2つまで

8. ファーストクラスコレクションを使う

9. getter, setter, プロパティを使わない


  • 関数に名前をつけることは、何のためにそのコードを書いているのか

    目的を強要することになるので、重要である。


  • データとロジックを凝集させる[3.6.7.8.9]


  • 複数の関心ごとを持たない[1.2.4.7]


関数に名前をつけることは、何のためにそのコードを書いているのか

目的を強要することになるので、重要である。


設計の改善


  • 名前の変更

  • メソッドの抽出

  • クラスの抽出

  • メソッドの移動/フィールドの移動


インクリメンタルな設計

できるだけ早くコードを書き始める。

動いたコードをもとに改善をする。

コードに書いて動かしてみると学びが多いし、その学びをコードに反映できる。

そういう設計の方が効率が良い。


体制とやり方

コードを書く人間が要件のヒアリングと分析をする

それができる人間を育てる。


どんな状況でも改善できる!!


(2)DDD実践ベストプラクティス 

加藤 潤一 氏 ChatWork株式会社

スライドはこちら

ドメインイベントとマイクロサービスの関係


CQRSとは


  • コマンド・クエリ分離原則

あらゆるメドッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方あってはならない。

これは、質問をすることで回答を変化させてはならないということだ。


ドメインイベントが主役になるイベントソーシング

ドメインモデルをデータとして格納するのではなく、発生するドメインイベントを全て永続化する。

DDD + CQRS

設計がシンプルになる。


パネルディスカッション ~DDDの課題は何か、今後どうなる?~


Q1 ユビキタス言語をモデリングし、いかにドメインエキスパートと共有しているか?

増田さん: エヴァンスが書いているように、ドメインエキスパートと開発者が毎日会話するのは難しい。

しかし、開発者同士の中での会話で、ドメインエキスパートが定義した言葉が出てきていなかったり、

間違って使われていたりすると、おかしいので確認を取る。

杉山さん: DDDをやっていると、言葉の意味に敏感になる。


Q2 コンテキストマップ戦略の9パターン


  1. パートナーシップ

  2. 共有カーネル

  3. 腐敗防止層

  4. 顧客/供給者

  5. 順応者

  6. 公開ホストサービス

  7. 別々の道

  8. 巨大な泥団子

  9. 公表された言語


Q3 DDDはマイクロサービスの設計手法として有効なのか?

→ コミュニケーションに重きを置いている。考え方では、適応しやすいという位置付けだと思う。


Q4 コンテキスト・集約と整合性との戦略わ?


Q5 CQRSの3タイプ

CとQの間のリレーションを失ってはいけない。

ユースケースから考えていくと、紐付けが取れていくが、

分けることを先行してしまうと、うまくいかないこともある。


サーバーレス・アーキテクチャ

伊藤 直也 氏 株式会社 一休 執行役員 CTO

スライドはこちら

常駐プロセス的な意味で、サーバーレスのお話。

function as a service

具体例はAWS Lambda

Req - S3 - kinesis - SES - Dynamo

Lambdaいっぱい作っていくと、マイクロサービスになる。

コレオグラフィーは疎結合で柔軟性がある。

どこかで失敗したら、戻すのではなくて、捨てて、新しく作り直す。

サーバーレスアーキテクチャの面白いところ、

自然と分散志向になっていって、テスタビリティが高くなっていく。

ただ、開発コストは下がらない。

あと、デバッグが大変。


DevOps導入&実践の落とし穴 - Disciplined DevOpsに見る体系的アプローチ

藤井 智弘 氏 日本ヒューレット・パッカード株式会社

DevOpsの定義は難しい。

ディシプリンド・アジャイル・デリバリー(DAD)の基礎

・スクラムの拡張

 ・スクラムはシステム構築にフォーカスが偏っている

・利害関係者との合意形成

 ・例えば法的問題が関わるなら法務と合意が必要

 ・関係者全員との議論もフェーズに含める

・ゴール駆動


終わりに

speekerの皆様、ありがとうございました。

長い1日でした。

個人的には、基調講演2とDDDのセッションとサーバーレス・アーキテクチャが興味深い内容でした。