今更ですがデブサミ2018の感想

はじめに

これは2018年2月15日から16日まで行われた、Developers Summit 2018について、主観的な感想を書いた記事です。

初参加、というか、日本に来て、開発者になってから初めて聞く開発者向けのSummitでした。情報をくれた同僚さんに感謝を…

聞いたセッションは下記の通りです。

• なぜ400以上の開発チームが同じサイクルでリリースできるのか？～Salesforceで行われているプロダクトマネジメント
• ストリームとバッチを融合したBigData Analytics ～事例とデモから見えてくる、これからのデータ活用のかたち～
• 婚活サービスにおけるシステム×サービスのイノベーション
• Shadowverseのリリースサイクルを支える運用基盤 ～高頻度リリースを実現する為の自動化・効率化事例～
• イノベーションを起こす開発チームの作り

なぜ400以上の開発チームが同じサイクルでリリースできるのか？～Salesforceで行われているプロダクトマネジメント

Salesforceを紹介しながら、開発プロセスについて語るセッションでした。
CRMのクラウドサービスを提供する会社だそうです。
https://www.salesforce.com/jp/

5人から10人に構成された400チームがあり、年3回リリース、2週間スプリントでアジャイルすることに、1000件以上のプロダクトをイノベーション（リリース）できるそうです。

• 約束した内容と違う、と言われることがないように、全社員がタスクを見れるようにして事前に知らせることになるし、計画は5年、1年、リリース、デイリー単位で分けて計画をする。
• 想像したものと違う、と言われないようにデザインプロトタイプ承認をする。デザインのレビューが通ったらポスターとして印刷して、会社に張り、ペンを置いてフィードバックできるようにする。
• なんでもっと早く見せてくれなかった？と言われないようにdaily Scrum、グループで２週に一度レビュー、全プロダクト対象に月に一度役員レビューを行う。
• 以外はリリーススプリント直前にブランチをLockしたり、開発者を無理させないシステムが大事、と聞きました。

ストリームとバッチを融合したBigData Analytics ～事例とデモから見えてくる、これからのデータ活用のかたち～

Big DataやData Scientistは学校で課題で調査したくらいだったので事例とデモの説明は非常にありがたいものでした。が、中盤から自分の理解力が足りず、家に戻った後、もう一度見ても難しい…
ざっくり言うと、上流System -> kafka -> データレイクの流れで必用なデータを疎結合に収集、適材適所のデータのマネジメント、それらを実験、検証、分析で使う。そしてこれの詳しい情報の説明でした。
プレゼン資料がアップロードされているので、興味がある方はこっちをどうぞ。

婚活サービスにおけるシステム×サービスのイノベーション

システム内製化に関する話。内製化しようとも、うまくいかなかった理由や経験、それに対する解決方法を聞かれました。

• メイン言語がPHP　->　Rubyを使いましょう。
• 要件定義が重要　->　企画段階から参加しましょう。
• 事業部単位で席を配置　->　チーム単位で配置しましょう。
• 横断的マネジメント
• 技術力重視　->　責任感、人格重視

そしてエンジニアが企業理念に対して行動を取ることも重要で、婚活サービスをしていた会社の理念と合わせて、リリースは大安にすることになった、と聞きました。なるほど…
会社がしたことは、エンジニアをできる限り放置すること。エンジニアがしたことはサービス、企業理念に合わせたエンジニア文化でした。
会社のエンジニア、互いの尊重の重要さをしる機会でした。

Shadowverseのリリースサイクルを支える運用基盤 ～高頻度リリースを実現する為の自動化・効率化事例～

以前から「自動化」って結局どうするんだ？って言う疑問があったから参加しました。
はじめに、Shadowverseとはスマホで遊べるカードバトルゲームで、ゲームにとってデバッグとはバグを「発見」する、と言う正義をまず紹介してプレゼンをはじめました。
このゲームで必要な探索の数はなんと、弱４京。これもパッチでまた増えるようです。これだと一日833億名の人数が必要なため自動化を作ったそうです。そりゃ作るわ。
これの自動化は自動バトル用のbotサーバーを作って運用するそうです。
機能は下記の通り。

• 自動プレイ
  • ある基準に従い、デッキをランダムで作る。
• アプリ管理
  • 定時にビルド検査、アップロードページを監視、ファイル名で制御。
• デバッグ管理
  • スケジュール管理、複数のデバッグ、並行開発、個別デバッグ、予約実行。
• 報告
  • エラー発生の時、なんのエラー、再現手順らを報告。社内SNSで共有。

なるほど。こうなるんですね。
今抱えてる問題はパッチでカードが増える速度に自動化ツールの速度が追いつかないため、性能改良が必要、ということでした。

イノベーションを起こす開発チームの作り

イノベーションを起こしたいろんな会社を例にして、ビジネス側とエンジニア側のコミュニケーションの重要さの話でした。
アマゾンの場合は技術のイノベーションじゃなく、発想の転換。
余るリソースをneedsに与えたAirbnb、Uber、メルカリ
IoTがもたらすのは各種センサーが送ってくるデータ、それの分析と処理。
この後はビジネス構造をエンジニアが理解するんじゃなく、エンジニアがビジネスをつくり、それがイノベーションに繋がる、と言うこと。
エンジニアとし「発想の転換」は重要ですが、またそれに認識する機会でした。