個人的なデブサミ2018のまとめ



## Developers Summit 2018
<img width="1531" alt="スクリーンショット 2018-02-26 21.19.28.png" src="https://qiita-image-store.s3.amazonaws.com/0/82601/31da02b6-6467-362d-8ce6-4843b1498707.png">

　  

先々週の2/15-16（木-金）にデブサミがあって初参加してきました。
観に行きたいのが2日目に固まっていたので、仕事の兼ね合いで2日の午後の3つのセンションしか聞いてませんがまとめたものを書いてきます。

あ、[資料はここ](https://codezine.jp/article/detail/10684)にまとめてあるみたいです。


## 【16-B-3】「サーバーレス」のポテンシャルとシステム表現（原 康紘 [SUPINF]）

### サーバーレスのポテンシャルとシステム表現

資料: [サーバーレスのポテンシャルとシステム表現 / How Serverless Loves Event-Driven Architecture](https://speakerdeck.com/toricls/how-serverless-loves-event-driven-architecture)

* **アーキテクチャ面でのメリットがでかい**
  * とにかく伝わりにくい
  * 今までの考えとは違うやり方でサーバーサイドを実現させる
  * いろんなきっかけが起きる　
* **プラットフォームの特性を生かすことを意識しないとダメ**
  * プーリングを意識しないといけない ＝ プラットフォームの特性をちゃんと考えていない。
  * PaaSなどのサービスをちゃんと知ることも必要
  * サーバーレスやサービスがあるからコストカットできるからといって、何もしないことが多いわけではない。
  * 今までの面倒ごとを簡単にしたということ
* **サービス間の相互作用をイベントとして表現できれば**
  * サービス間が疎結合に保たれて
  * 洗礼されたアーキテクチャが手に入る
* **サーバーレスは楽しい＝モチベに繋がる**
* **フルサーバーレスはただの中二病**
* **[おまけ] 脳内**
  * サーバー管理からの解放
    * ベンダー様の思惑・ロックインのお花畑
  * サーバーレス・アーキテクチャ
    * イベント・ドリブン・アーキテクチャ
    * fully-managed FaaS
    * 「俺のFaaS」

### 感想
「サーバーレス＝サーバーが死ぬことはない」とか思っていたけども、そうなると「サーバー管理０＝サービス管理０」とかになってしまって、サービスが運用である意味死んでしまうような気がした。


## 【16-B-4】大規模サービスにおける価値開発の“これまで”と“将来” ～新たな“じゃらん”のチャレンジに関して～（坂東 塁 [リクルートライフスタイル]）

### 大規模サービスの中でどのようにPDCAをやっているか
- **リーン開発に関して**
  - 目的：カスタマーに提供する価値検証において、大規模サービスでPDCAをはあ役回す
  - じゃらんは高いレベルのビジネス企画、インディードは圧倒的な高速開発。
- **体制について変えたこと**
  - 意思決定・判断の簡略化
  - パフォーマンス最大化のため、フロー最小化
- **リーン開発を導入する際の懸念点**
  - ディレクター・エンジニア・デザイナーが別ロケーションによる認識の認識齟齬などが出て出戻りする
- **だいたい誰でも社員はSQLをかける**
- **データサイエンティスト**
  - サービス横断でリアルタイムにデータを収集
  - 分析結果をWebAPIとして各サービスへ提供する
- **非エンジニアでもデータをアップロードするだけでWebAPIにできる仕組みを作て運用している**
- **Beam SDKによるリアルタイムなデータ提供の仕組みを取り入れている**
- **モニタリング指標を大切にする**
  - 多くの指標を日々確認
  - Redshift, BigQuery, Adobeデータとの連携
- **パフォーマンス最大化に向け取り込んだ点**
  - プロダクトオーナー・エンジニアのパフォーマンスの最大化
  - プロダクトオーナーのパフォーマンスの最大化
  - エンジニアがパフォーマンスを発揮する環境づくりと結果出し
- **スクラム/アジャイルの導入**
  - 体制の開発スタイルの急な変更
    - 管理ツールの導入、知り合い紹介からのコミュニケーション、チーム全員で楽しむ環境を意識して作っていった。
  - 一緒に進めるメンバーが生まれる
- **PDCAに取り組むためのプロダクトオーナーの役割**
  - プロダクトオーナーの責任は重大
    - 意思決定、環境づくり、成果物への思いをチームに浸透させることで、チーム体制が大きく変わる。
- **これからのチャレンジ**
  - リリースしたら終わりではなく、リリース後も検証と見直しを新たに進めていく。
  - プロダクトチームを構築、あるべき姿を考える、MVPを検証
  - プロダクトに成功に専念するプロダクトマネージャーとして考える
  - リクルートの文化は、「お前はどうしたい？」の企業文化
  - プロダクトのあるべき姿、成功にこだわり抜ける体制にできた
  - エンジニアとして信頼できるテックリードがいること、だけでなく、自立したエンジニアのメンバーも重要。
  - プロダクトの方針を定めて、成功にフォーカスできる。

### 感想
今回3つのセッションを観た中で一番勉強になった話でした。
「開発とは」「チームに最適な環境とは」「コミュニケーションとは」「やるべきこととは」「メンバーのパフォーマンスを向上させる取り組みとは」「面倒ごとはツールを作って解決させる」「マネジメントとは」など、いろんな話しが詰まっていて登壇者はどこでそのモチベを作ったり・向上させたり・保っていられたのかと疑問でしたが、最後まで行くと結果としてチーム力が大きな価値になっていったからではないか、と思いました。


## 【16-E-5】Swaggerを使ってPHPエンジニアとUnityエンジニアがもっと仲良くなった話（仙道 航 [グリフォン]）

資料: (DevelopersSummit2018_SwaggerでPHPエンジニアとUnityエンジニアがもっと仲良くなった話)[https://speakerdeck.com/sgeengineer/developerssummit2018-swaggerdephpenziniatounityenziniagamotutozhong-liang-kunatutahua]

- **APIのつなぎこみ**
  - 仕様書やワイヤーフレーム ->サーバーとクライアント間で認識合わせ-> API開発-> 疎通確認
    - 現実は疎通確認で出戻りになってしまう。
  - サーバーエンジニがcnfluence にドキュメントを作る。そのドキュメントをクライアントエンジニアが確認し、相談・実装する。
- **swaggerについて**
  - コメントにjdocのように各機能の詳細を書き込んで、各ビルド方法でドキュメント作成ができる。
  - swagger Spec
  - swagger UI
  - swagger Codegen
  - APIのつなぎこみ
    - サーバーエンジニアはspecを書く、ドキュメントを自動生成される、クライアントエンジニアはそのドキュメントを見て開発していく。
    - 常に正しい状態が保てる。
- **活用事例**
  - サーバーエンジニアがswagger Specを記述
  - クライアントエンジニアはswagger UIを見て対応
  - Specification Extension
    - X-から始まるユーザー独自のプロパティ
- **まとめ**
  - Swaggerはサーバーエンジニアの開発スピードと一緒にできるものだから、クライアントエンジニアはサーバーエンジニアと同じ開発スピードで作業が可能になる。
  - プロジェクトの規約ややりたいことに合わせたコード生成は少し敷居が高いかも
  - ファイル分割の規約はきちんと決めた方がいい

### 感想
Swagger用のリポジトリを作ったというところが驚きました。
また、Dockerをうまく使ってCIの運用までを整えたところはすごくよかったなと。
インフラをしっかりと整えるのも大事だけども、ささっと用意して開発しやすい環境を作れるようにはなりたいなと思いました。


## まとめ
デブサミ初参加でしたが、開発に関わる話だったらいろんなジャンルのセッションがあって、2日丸々参加してたら脳みそパンクするなってぐらい濃密な話が多かったと感じました。

あと、企業ブースでもいろんな話やノベルティーとか本の出版もされていて、お祭り感覚でとても好きでした。

来年も参加できればなと思います。