ヤプリの渡辺です！
いやー、毎年こんなに人が来るなんて、みんなどんだけヒマやる気あるんだろ、とか思っちゃいますが、せっかく来たのでレポートとかしてみようと思います。
まずは個人的に面白かったのは、
アマゾン文化の成長へのループはとてもいい！
日本で、熱意のある社員は、6%しかいない
GoogleのSREの50%ルールやBurnout(燃え尽き症候群)の防止、ふりかえりが素晴らしい！
って辺りでした。 で、印象に残ったまとめは以下の通りですね。
イノベーションを支えるアマゾン文化
成長へのループ
品揃え→顧客満足度->顧客数→売り手の数のループを繰り返すことで成長
さらに、そこに低コスト＆低価格を加えて、顧客満足度を上げることで、顧客の利便性を中心に検討
レガシー開発からモダン開発への挑戦
やったことのないことに、PDCAは機能しない！Planは捨てる！！
Cloud Native時代における Docker / Kubernetes による開発
サービスメッシュとは、各アプリをそのまま繋ぐのではなく、いったんProxyを介してアプリに接続するアーキテクチャにする。 こうすることで、可観測性の向上や、開発者がアプリのロジックに集中できる、などの利点が出てくる。
新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと
オーバーエンジニアリングとの戦い
期日やコスト、発生確率、リスクなど考慮して、「やらない」というのも大事
これらをマネージャとして、はっきりいうことも大事
カオス化した組織とエンタープライズシステム群を、モダン化したい！
段階的に、アーキテクチャとアーキテクトチームを育成する。
まずはアーキに強いベンダーに入ってもらってスタート
徐々に、自信をつけて、チーム主体で進められるよう
自動テストのコストは、手動の３−６倍だった。 システムを顧客中心にするだけでなく、ビジネスも顧客中心にしないとマズイ！ Scrumだけでは辛くなった時、ドメイン駆動設計を導入してとても良かった。
全体プロセスから、価値のつながりとして再整理（プロセス中心から価値中心に）
価値が低いドメインはPOORでいいよね、という意思決定がしやすい
ドメインで大切なのは、詳細にすることではなく、大まかな全体像をうまく分割すること
ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路
チームのフェーズによって適用すべきプラクティスは違う。
フレームワーク主導はNG
承認を得る方法を悩む時間は無駄
日本で、熱意のある社員は、6%しかいない
Site Reliability Engineering at Google
業務時間の50%以上をソフトウェア開発を含む、システム安定化に関わるプロジェクト活動に充てる。 「50%ルール」の効用：燃え尽き症候群の防止、運用にコストがかかりすぎた場合、SREは開発に突き返す権利がある。
Burnout(燃え尽き症候群)の防止とは
運用はつまらない、しかし必要なスキルは開発スキルである
なので、Burnout(燃え尽き症候群)の防止はとても重要
給料もらってるんだから黙ってやれ、では優秀なエンジニアは転職してしまう
なので、50%ルールはとても重要
障害対応のプロセス
オンコール担当者が、障害対応責任者となり、報告責任者と実作業担当を任命
問題解決を最優先して「他人を頼ること」を本人のスキル不足とは認識しないことを徹底
ふりかえり
重大障害の解決直後に、発生要因、対応時の反省点、改善策を文書化
解決直後に、GoogleDocsを開いてみんなで思ったことを書きなぐるらしい
他人を非難する内容は、絶対に書かない（個人のミスを誘発するシステムを設計したSREチームの責任）
改善策の実施は、SREチームのプロジェクトとして実施
社内の全てのエンジニアに内容を公開
終わってみて
あとは、「とらのあな」が求人出してたり、各言語（PHP/C/Javaなど）の水があったりして面白かったです。 こう見ると、デブサミってほんといろんなレイヤーの人がいてすごいなーと思いますね。 みんなも少しずつでも身の回りをより良く改善していけるといいですね！ でわでわ！！
