デブサミ2019行ってきました

プログラミング歴の浅い初心者が初めてデブサミに参加したので、自分用に感想をまとめてみました。
初心者が聞くとこんな感想になるんだなと生暖かい目で見て頂ければ幸いです。
CodeZineさんの講演関連のまとめがこちら。Togetterまとめもあるよ。

聞いたセッションのまとめ感想など

個人的に面白かったセッションは★を付けています。

2/14 セッション

★イノベーションを支えるアマゾン文化

Amazon文化が分かるセッション。
Twitterでの実況ツイートで一番反応が良く、注目度の高いセッションだと伺えました。
共通用語を持つことでコミュニケーションコストを下げる、という話はGoogleでも出てきており、大きい企業では実践されている取り組みだと感じました。

イノベーションカルチャー
イノベーションのためのメカニズム

プレスリリースをする
プレスリリース前にサマリーなどを書いてレビューを繰り返す。
FAQを決める
顧客とステークホルダー両方のFQAを決める。質問を集めるためにも早めにシェアする。

イノベーションのためのアーキテクチャ

行動規範がある
社員の共通言語になっている。人事評価にも組み込まれている。

Amazonの行動規範は、こちら。

2 pizza teams
2枚のピザが賄えるくらい少人数でチームを組む。ロードマップから運用まで作るものに対して全てをチームで負う。
チームレベルで権限が自由であるため、チームと個人とルールの相乗効果発揮されて高水準を維持。

Amazonはプレゼンテーションツールをほぼ使わない。

なぜ？
話し手の話術や聞き手のとらえ方に左右されるため。
代わりに何を使っているの？
6pagerと呼ばれるレポートにする。最初はレポートを静かに読むことから始める。

Alexaスキルで収益化を目指そう

後々日本に来るであろう課金可能なスキルを作成するノウハウを共有しようといった内容のセッション。
米国ではAlexaで課金可能なスキルが実装可能であることから米国での課金体系、課金したいスキルとは、という観点で話をされていました。
普段作成しているスキルとはまた違った観点でも考察する必要があると感じました。

収益化が見込めるスキル

課金したいと思わせるスキル

課金したいと思わせるスキル？

音声ならではのユーザー体験ができる
例えば、手が離せない、動きたくないといった音声が圧倒的に有利なユースケースを考える。音声にただのせかえただけだと使われない可能性がある。
繰り返し使いたくなる
例えば、とても便利、やめられない、習慣になると繰り返し使ってもらえ、収益化につながる。

ビジュアルをつけると市場を狭めてしまうので__音声ファースト__で考える。

セキュリティ・テストの自動化によるDevSecOpsの実現 (デモ有)

DevSecOpsの実現のために何が重要か、また自社製品を使うとどのように実現できるかといったセッション。
セキュリティ・テストの自動化のためにテスト結果の正確性が重要であるという話をされていました。
自社製品を用いてWebGoat(わざと脆弱性を持つアプリ)の問題個所を検出するデモがありました。
製品の機能についての紹介が多くDevSecOpsを実現するためには？の部分の説明があまりなかったように思います。

★日経電子版のマイクロフロントエンドとPWAによる改善事例

日経電子版のフロントエンドのセッション。
フロントエンド業界では日経電子版のパフォーマンスが高いと噂されていることもあり、かなり高い技術的な話が中心でした。
フロントエンドをある程度携わっていないと理解することが厳しいと感じました。登壇者がインターンから社員になった2018年度入社の若手の方でした(若さにショックを受ける)。
マイクロフロントエンドとは、マイクロサービスをフロントエンドで行うことで、1つの画面を複数のサービスに分割することが前提とのことです。
HTMLの50%がCCSS(Dynamic Critical CSS Optimization)らしく、各ページごとにCCSSをビルドする必要があるとのことです。
フロントエンドの知識があればかなり有意義な内容だったと思います。

★新技術導入を成功させる組織のつくりかた～spanner、GKE導入の実体験から得たこと～

新技術導入のために四苦八苦した部長さんが何をしていったかといった内容のセッション。
__未来の投資は現在の足元を悪くするが投資をやめると未来の足元がわるくなる__をキーワードに話を展開されていました。

新技術導入に対する障害

メンバー集め
50%の工数でチームを結成する。経験はないが新しい技術に興味のある若い人を導入。
短いスケジュール
スケジュールはマネジメントによる所が大きい。本番に必要な機能を優先順位して行う。
本番導入での障害
テストや負荷試験をしてても不足の事態が起こる。
諦めないで色んなひとにきく。
オーバーエンジニアリングとの戦い
問題発生の確率、発生のリスクも考慮して特にはやらない、も大事。

新技術導入での気づき

若いひとにチャレンジしてもらう
経験ある人だけでやりつづけるのは不可能なので組織を育てる意味でも大事。
課題からテクノロジーを選定する
興味だけで選定したテクノロジーは泣きをみる。プロダクションで使うときは課題にフィットするものを選定すること。
小さい変化を積み重ねて大きな変化に繋げる
成果を出せば大きな変更もできるようになり、気持ち的にも余裕がでる。
最終目標を共有し続ける
導入すると迷いが出てくる。雑談などで目標を共有する。
未来の課題をないがしろにしない
既存の業務に目が行きがちだが、未来へ投資をすることを忘れない。マネージャーのマインドチェンジが必要。

今後は、マイクロサービスへ挑戦や定常的なことを自動化するなどを目標に掲げていました。

レガシーとのいい感じの付き合い方〜15年続くウェブサービスのシステム改善パターン〜

15年もののレガシーなシステム改善の判断をどうしたかという事例紹介のセッション。
会場では10年以上前のシステムを使っている方が多く立ち見も出ていたことから、皆の関心が高いことがうかがえました。

システムが古くて大規模、サーバーがメンテ放置でカオスな状態を変えたいという思いで、改善を試みる。

やったこと

調査
機能とパスを調べあげ、機能一覧を作成することで、議論しやすくする。
不要な機能を削除
機能の母数を減らし、問題を手間をかけず減らしていく。機能数を1800から700まで減らす。

調査と不要な機能を削除をしてみた結果

コントロールできるインフラがあるとアプリの改善しやすい。
インフラによって改善のしやすさが変わってくる。

改善は無理しないことが重要

現状把握をしっかりする。
長期で段階的に改善する。
フルリプレースは工数捻出が難しい。
取り組む問題は絞る。
価値と工数の2軸で絞って、現在取り組めないものは先送りする。

【祝】k8sデビュー！エンタープライズ巨大アプリをマイクロサービス・コンテナ化。段階的移行(中)の全記録を追う。

既存アプリをマイクロサービスに分解しコンテナ化、k8sで運用した話でした。
モジュール間の依存関係が複雑化していったため内部をマイクロサービスに分解していった実体験をベースに話を展開されていました。
サービスの選定理由など具体的な技術話が多かったです。k8sは設定ファイルとしてYAMLを多く管理しなければならず、kustomizeで管理しているとのことです(kustomizeとは)。
k8sのことをある程度理解していないと聞くのは難しいセッションでした。

k8sとは
アプリやコンテナの運用自動化のためのオープンプラットフォームで、自動デプロイやスケーリングetcに対応できるようになる。
詳しくはこちらの記事へ。

2/15 セッション

★ドラゴンクエストXを支える失敗事例

やっぱり失敗談は面白い！というわけでドラクエXオンラインゲームの開発時の3つの失敗談の話です。
失敗談はあるあると頷くようなよくある話でしたが、失敗が発生するような仕組みになっていることが問題だと話されていて、自分たちの職場でも振り返りたいと感じました。

オンラインゲーム開発の良い設計

顧客への対応が柔軟であること
そのために運用・運営経験が重要。

運用後の失敗談について

効果音がなり続ける不具合
背景：別の効果音を無効化した影響で別の効果音が鳴り続ける障害になってしまった。
対策：システム改修はBTSチケットにし影響を再検討する。運用後は修正の影響範囲を狭くすることが重要である。
オートマチッングが不成立
背景：サーバーに条件をべた書きする暫定対策を直すことを忘れており、条件が合わなくなっていた。
対策：暫定対策をチケット管理する。
釣った魚のサイズに合わせた報酬が得られない不具合
背景：浮動小数点数の丸め処理の誤差修正にミスが生じていた。
対策：表面化していない不具合はある前提で対応する。

リリース後の改修は注意すべき

影響範囲を確認
影響の軽さによらずチケットに登録
チケットで最後まで管理

６年間でチケットが20万浪江臆されたとのこと・・・。

★CI/CDを使い倒して数段上のソフトウェア開発をしよう！

CI/CDについてなぜ必要なのかどのように導入すべきかを丁寧に解説されていました。
CI/CDについて詳しくなくても聞くことができます。プレゼンスキルが高かったことも面白いセッションでした。

CIはテスト自動実行する仕組み。
CIは以下の問題を解決してくれる。

問題：テストの実行し忘れ
- 解決策：常にテストを回す
テストが壊れて動かない　「使われない自動化は壊れていく」
- 解決策：壊れた時点で検知。直さないとマージできない
問題:結果が環境依存
- 解決策:CIを唯一のテスト環境にする

CIは便利だが、CI導入を妨げる問題がある。

テストがない
テストがなくてもCIツールは使えるので、構文チェックなどのタスクから自動化していく。
CI結果を可視化することで、チームに興味を持たせる。
マージブロックを有効化していき、無理のない程度に少しずつテストを追加していく。
メンテナンス
CIのメンテは大変なので、Jenkinsおじさんが生まれがち。CircleCIなどクラウド型を採用し、運用コストを下げる。

CDは継続的デプロイメント。CIの先の話。
リリース後の問題をフィードバックループ(細かい単位でリリースし、フィードバックを速めに得る)によって、改善しようとする。
そのためには、CIが不可欠。

CDを始める上で問題がある。

CDに向いていないアーキテクチャ
エンタープライズやレガシーなアーキテクチャは、サービスが密結合しているためリリースが難しくなる。
CDに向いていない組織
「エンジニアリング組織論への招待」を読んで！

新システムにはまずCI/CDを導入しよう。
CircleCIでは、1年かけて、Docker/k8s導入、マイクロサービス化を行った。
=> CI/CDの会社でもCDの導入は1年かかる。

テスト可能な部分は、限られているため、結局、リリースしてみないと分からないことは多い。
しかし、CI/CDを導入することでプログラミングの心理的安全をもたらす。

ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～

ゲームのガチャの品質の担保の話でした。
ガチャは法律上、確率を表示しそれ通りに排出されることを保証しなければならないため、テストを行う必要があるとことです。

テストツール

Google Vision APIを利用しているが、学習できないとのこと。

苦労話

画面キャプチャとテキストをマスタと自動で突き合わせてテストしている
テキストが加工されているとOCRで検出が難しい
画像が被っていると認識が難しい

苦労話のようにAIなど実用するには前処理・後処理がかなり重要となってくるようです。
そのため、全自動を諦める、全体的な処理時間を減らすことが目的という割り切りも必要とのことです。

Site Reliability Engineering at Google

SREができた背景やどのような立場であるかなどの話でした。

__SREとは、開発者の考えた最強の運用者__である。
GoogleのSREは

50%システム安定化に関わる開発50%運用業務を行う
50%が守れないときは開発チームに運用作業を返却するまたは要員要請をする権利がある
運用ばかりで燃え尽き症候群になることを防いでいる
SREチームの究極のゴールは、自分たちが運用するシステムを無くすこと

エラーバジェット(エラー許容量のようなもの)が基準を超えると、開発チームは新機能のリリースを中断し安定化に注力するなど開発とSREが密な関係であるようです。

また、__SLOを満たすためにチームを超えた「安定」の共通認識を持つことが重要__としており、共通認識があると組織として動きやすいんだろうなと感じました。
重大障害の解決後に、発生要因や対応時の反省点・改善策をメンバー全員で文書に書き込み、知見を全てのエンジニアに共有しているのだそうです。これはチームでも取り組めるのではないかと思いました。
__ミスを誘発するシステムを設計することが問題__という話は素敵でした。

Googleは、共通ミドルウェアサービスが決まっていたり、開発者が全てのコードの閲覧が可能であるなどユニークな環境で開発をしている印象を受けました。

サーバーレスで最高に楽しめるアプリ開発

サーバーレスの強みと実際のアプリ開発での構成などの話でした。

サーバーレスの強み

アイデアを即形にできる
実行ランタイムを手軽に扱える
ログや監視も統合されている

__サーバーレスはピタゴラ装置を組み立てるような楽しさがある__とおっしゃっており、組み合わせによって各クラウドの強みが引き出せるのはサーバーレスならではだと感じました。

実際のアプリ開発では、コールドスタートが遅いという問題に直面し、リリース一か月前にランタイムを速いNode.jsに変更したという話がありました。

発表で出てきたDependabotが依存パッケージに更新があればプルリクを出してくれるサービスが便利そうでした。個人なら無料ですが、ビジネスで使うと有料のようです。

コールドスタート問題とは
利用可能なコンテナがなく、一からコンテナを作成し新規にLambdaを起動することで時間がかかってしまう問題。

コールドスタート問題がアンチパターンの1つとして紹介されていたスライド資料。面白いです。セッションでも参考として紹介されていました。
全部教えます！サーバレスアプリのアンチパターンとチューニング - Taste of Tech Topics

GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio?

GKEでのIstio環境の構築についてのセッション。
Istioとは、サービス間通信を管理するためのオープンプラットフォームとされており、__会場内でも本番環境で使っている人は0人と、まだ普及率の低い__もののようです。
GKEだと簡単にIstio環境を作ることができます。Stackdriver(GKEの監視サービス)でSLOなどのモニタリングを行うデモを行っていました。
コンテナやマイクロサービス化についてある程度知識がないと楽しく聞くには厳しいセッションだと感じました。

まとめ

AmazonやGoogleは組織として共通用語を持つことでコミュニケーションコストを下げている
コントローラブルなものをコントロールする仕組みを作り、ミスを削減したり環境を改善することが重要である
今、サービスを組み合わせてアプリを開発するマイクロサービス化が熱い！マイクロサービスを支える技術(k8sやCI/CD)の共有に注目が集まっていた

何故、マイクロサービスが熱いのかという理由は、
Googleエンジニアが語る「マイクロサービス」「コンテナ」の基礎知識にもあるように

機能ごとに異なる最適な技術を採用可能
開発の同時並行が可能
機能単位でコンポーネント化されているため、再利用と置換が容易
チームも機能ごとに少人数で構成可能

であり、アプリがどんどん大規模化・マルチプラットフォーム対応をしていくにあたって、必要な技術になっていると感じました。

個人的な気づきとして、使ったことないサービスをどんどん減らしていく必要があると感じました。
セミナーに参加して「ほぼ知らない」から「セミナーで聞いたことある、何となく知っている」への成長はちょっと勿体なくて、「使ったことがある」から「より良くするための知識を増やす」のがセミナーに参加して一番わくわくする成長の仕方だと思いました。
そのためには、作ったことある、知っているを増やす必要があると感じます。

初めてデブサミに参加して

会場の雰囲気

デブサミ2019は、ホテル雅叙園東京で行われ、途中ここで合っているか半信半疑になるくらいオシャレで綺麗な会場でした。
また、クロークがあり荷物や上着は預かってもらえたため遠方勢には大変有難かったです。
全体的にどのセッションも人が多く、事前登録していないセッションを聞こうとすると立ち見になってしまう印象です。

セッション

デブサミは、アプリケーション開発やアーキテクチャなど技術的なものからエンジニア組織、開発プロセスなどマネジメントに関するものまで多種多様なセッションがあります。
多種多様なセッションがあるため興味の幅が広げられてよかったです。
ただ、セッションの中には技術のある程度、知識が必要とされるセッションもありました。
CEDECのように、セッションの難易度が分かると良いなと思いました。

お昼

お昼は飲み物とサンドイッチが出ました。

おひるごはん！結構ごーか#devsumi pic.twitter.com/MEGEglvoxN
— nori (@nori0__) 2019年2月14日

セッション間が20分なので、あまりゆっくりは食べれません。
ただ、軽食を聞きながら食べることが可能です。

おまけ：Twitterにタグをつけて沢山つぶやくと…

今回は、自分用にメモを取るくらいならTwitterにタグをつけて沢山つぶやく！を目標に取り組みました。
メリットとデメリットを簡単に紹介します。

メリット

デブサミだとCodeZineさんがTogetterにまとめてくれるため見返すのが楽
聞き逃した話など他の人がつぶやいてくれると見返せる
自分とは異なる観点での気づきが得られる

デメリット

報告書が作りにくい
「小話はつぶやかないでほしい」など制約があると個人用メモと併用して使う必要がある