Developers Summit 2019 Summerに参加してきた
Developers Summit 2019 Summer？
通称デブサミ
https://event.shoeisha.jp/devsumi/20190702
おすすめ
編集がめんどかったためメモをそのまま載せています。
長文のため、個人的なおすすめのセッションをピックアップ。
- 開発系
- インフラ系
- 組織系
聞いたセッション
- メルカリのエンジニア組織とマイクロサービス化への取り組み
- アプリケーションの全てを計測せよ！〜DevOps文化醸成における計測の重要性
- 新卒社員研修からはじめるアジャイルソフトウェア開発チームのつくり方
- 組織にテストを書く文化を根付かせる戦略と戦術
- Infrastructure as Codeでインフラチームはもっと強くなる 〜ぼくのかんがえたさいきょうのいんふらちーむ〜
- 顧客が使いたくなるアプリを作る方法
- エンジニアとマネージャーは、いつも勝負をしているのだと思う
- クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計
- 本気で実践している人たちにしかできない話が聞きたい
- 後日: 参加して
以下メモと簡単な感想
メルカリのエンジニア組織とマイクロサービス化への取り組み
キャリア
職務
- Front, Back, SREの職種割からドメイン毎に縦割りにしようとしてる
システムのマイグレーション
- オンプレからの移行
- GCP
- Micro Service Archite
感じた事
- メルカリのキャリアラダー見てみたい
アプリケーションの全てを計測せよ！〜DevOps文化醸成における計測の重要性
DevOpsやってますか
こんなDevOpsはいやだ
- スーパーエンジニアに2人分の働きをしてもらう
- スタートアップ時は必要かもしれないが、スケールしない
- 社内でDevOpsを推進しようとしても、現場に浸透しない
- 推進者 -> App... | インフラ...
- 組織のサイロを解消しないといけない
- 推進者 -> App... | インフラ...
- 自動化ルールを導入すればいいんでしょ？
- ツールは行動に影響を与えるが、DevOpsの十分条件でない
DevOpsは文化
DevOpsの文化とは
- 個人同時のコラボレーション
- チーム同士のアフィニティ
- DevOpsというチームやロールはない <> SRE
- ゴールを共有する人たち全てが関係者
- Dev, Ops, 営業, マーケ
- 最終形態ではなく、継続的なプロセス
ツールを活用しているかが重要 ステークホルダーが関わり合って改善し続ける文化
秘伝のタレを各人が守っている
- どうするか
スタート
- 現状をしり共有認識を得る
- アプリケーションを計測
- 現状をしり共有認識を得る
DevOpsにおいて計測は文化情勢の手助けとなる
- ステークホルダーがこれらを計測する
- システムの変化
- 日常的な変更を前提としている
- ビジネスの変化
- 顧客の思考・行動は日々変化する
- システムの変化
- 変化を計測した情報がDevOpsに関わる人々の間で何をすべきかの共通認識となり、協業が生まれる
こんなことが実現可能に
- スーパーエンジニア(辛い人)が減る
- 組織のサイロの解消
- 自動化ルールも進化を発揮
DevOpsの成熟度評価基準
- CALMS
- Measurement(計測)
- 高度に成熟したDevOpsチームの66%はキーとなる
- システムメトリックの計測を自動化し、34%はビジネスレベルの計測をオンデマンドで取得可能な状態にしている
- Measurement(計測)
- 高度に成熟していれば
- 頻繁にコードをデプロイ
- コミットからデプロイまでのリードタイムが短い
- 更新っぱい率低い
- 復旧早い
DevOps計測のチャレンジ1 ツールのサイロ化
- ポジションによって、計測したいことが異なる
- それにより利用ツールが分散
- 計測したいことは実際には
- 綿密に関わり合っているのでツールも共通化するのがベスト
- それにより利用ツールが分散
計測チャレンジ2 複雑で動的なシステム
- 従来のシステムと比べて構成要素が多く、動的に変化する
計測チャレンジ3 そのために時間をとる
New RelicにとるDevOpsの計測ソリューション
フルスタック
- 全てを計測し、見通すための場所
特徴
- DevOpsに必要な全てを計測できる
アプリ、インフラのパフォーマンス計測
カスタマーエクスペリエンス
ビジネスゴールの計測
クライドに最適化される
- クラウドコスト
- サービス利用状況
導入が楽
- Agent入れるだけ
ガイド
- 手を付ける場所がわからない
- ソリューションガイド有
New Relic自体のDevOpsを実践経験をもとに。
準備
- SLO策定
- アラート設定
- 活性化
- Dashbordで可視化
- 最適化
- アプリ、体験、インフラなど
まとめ
- DevOpsは動的な環境変化に対して上手く対処するための司式文化
正しく計測することで成熟度や硬貨の工場が期待できる
-
- バックエンド側の人間もフロント側の品質を意識できる
感じた事
- DevOpsの認識を正した
- 複数チームが協力するのがDevOpsって感じだったが、組織全体での活動だった。
- New Relic入れてみたい
- DevOpsへのソリューションガイドがある
- 部門毎に利用ツールや情報が分散している問題を解消できそう
新卒社員研修からはじめるアジャイルソフトウェア開発チームのつくり方
ざっくり
- セゾンの新卒研修
- BizとDev役員の指摘のベクトルが別.
- 内容をどっちに倒すか困った
- BizとDev役員の指摘のベクトルが別.
- 研修者のレベル差
- ペアプロさせた
感じた事
- 前職ネタ
組織にテストを書く文化を根付かせる戦略と戦術
- 疲弊仕切った現場
- 荒みきったコード
- 屋根の上に更に増築..
- 爆弾処理のようなリリース
テストが無いコードはレガシーコード
レガシーコードの定義
- テストがないコード
- 言語は関係ない
- テストがないコード
2つのならわし
- テストを書く時間がない
- 因果ループ図
- 自動テストから入れる
- 自動テストで浮いた時間で更にテストをかける良いループに入れる
- 自動テストから入れる
- テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです。
- 因果ループ図
- 動くコードに触れるな
- 現代において、関連ソフトのアップデートが入るので勝手に落ちる可能性がある。
- 動かなくなっていくので競争力がおちる
- コードフリーズしても動かなくなる
- Edit & Pray(しんどい) には死が待っている
- Cover & Modify
- リリースに自信がもて、すぐに巻き戻せるようにしたい
- この要素の一つがテスト自動化
- テスト文化がない企業にテストを書かせるようになるためには、2-5年かかる
銀の弾丸はない
- 地道に.
イマココから始める
- Tobeではなく、AslsとNotTobeから始める
- 隣の芝は青い。きにしないこと
- ひとは自分の速度でしか成功できない
- プロジェクトも同様
- まわりがやってるから。は劇薬
- 刺さりすぎる
理論武装する
- 不具合の発見が遅れれば遅れるほどコストがかかる
- TDDすると
- 15-35%ぐらいかかるが、不具合8割減る
- TDDはデバッグ時間がへる
テストは品質をあげない
- 品質がわかるようになる
- 体重計のよう
- わかるところを増やしていく
- 品質を上げるのは設計とプログラミング
- 再設計とリファクタリングをテストで支える
テストでは品質は上がらないですと。テストはあくまでも品sつを上げるきっかけ。品質をあげるのはプログラミングです。昔から層。
組織にテストを書く文かを根付かせる 戦術編
みちしるべ
- レガシーコード改善ガイド
- コードを変更するためにはテストを整備する必要がある。
多くの場合、テストを整備するためには、コードを変更する必要がある。
- コードを変更するためにはテストを整備する必要がある。
- レガシーソフトウェア改善ガイド
- 改善ガイドより抽象度が高い
- 3つ選択肢
- リファクタリング
- リアーキテクエィング
- 一部を切り崩していく
- ビッグ・リライト
- 成功確率ひくい
- 旧システムとのsyncとか。期間が伸びていくと死ぬ.
- 成功確率ひくい
どこにテストを書いていくか
- 一番やばいところは？
- 困っているところは？
- 金
- 個人情報
- 新機能
- バグ修正
- おすすめ
- 不具合が発生するポイントは固まっているため
- 傷んだ部分 or 価値の高い部分
自動化コストを見積もる
- トリアージ
- テストケース, リスク, 受動テストのコスト, 自動化コスト
どうやって書いていくか
- 書籍
こだわるな
- 最初から全部やらない
こだわろう
- 良いユニットテストの指標にも優先度がある
- 再現、繰り返し可能
- 独立している
- 他はそれからでよい
設計の可動域を確保する
自ら体験して、背中を見せてテストを書く
感じた事
- レガシーコード = テストのないコード って概念に納得した
- とりあえずテストを書く
- 短期的に見るとテストはコストだが、継続した開発サイクルにおいては、テストをしない事のほうがコストだと感じた。
レガシーコード改善ガイドを読む- ぽちった。
nfrastructure as Codeでインフラチームはもっと強くなる 〜ぼくのかんがえたさいきょうのいんふらちーむ〜
課題
- 構築手順のロスト、陳腐化
- ノウハウが蓄積しない
- オレオレ作業
- 人の作業が多い
チームメンバーなら誰でも対応可能な、交換可能なしくみ・組織にしていく必要がある
IaC (Infrastructure as Code)
リソース管理
- Terraform, Ansibleを両用
- Ansiblehはクラウドリソースの管理がし辛い
- Terafformは状態を持つが、Ansibleは持てないため
- クラウドリソース管理はTerraformがデファクトになりつつある
- 情報収集やすい
本番環境以外の管理
開発環境は検証などでリソース変更ありがち 厳密にIaC管理すべきだが難しい そこで - 本番環境以外はDevでも触れるようにしているが、修正内容を確認できるようにした - Terraformは状態を保持しているので、リソースを修正したら差分が発生する - terraformingなどで差分抽出 -> BotでSlack通知
インフラチームの方針
- マネージドサービスを使う
- 自前ツールを作らない、まず探す
- それでもなければ作る
GCP上のCron
感じた事
- 序盤にいっていた交換可能なしくみ・組織を実現しようとしていた。
- そのためにいろいろと思考錯誤をしていた
- 自作ツールの考えについては納得
- とはいえ自分で作るとその分技術が上がるメリットもあるのでTPOを考えるようにする
- RUNDECK便利そう
- AWS環境下でも使えるのかな
顧客が使いたくなるアプリを作る方法
顧客が使いたくなるアプリを作る方法
伝説の定義はPOとの共同作業
プラクティス集
- Open Practice Library
- 事例
取り組むべき課題の掘り下げ
- 顧客が存在するのか
- 解決に値する(💰をはらってもいい)課題が見いだせるか
課題に対する解決策が妥当か
サロン立ち上げ失敗
- 会計士狙い
- SNS以前かつ、会計士は内気
- まったくつかわれなかった
- SNS以前かつ、会計士は内気
- 会計士狙い
仮設を検証可能な形式で表現する
- プロダクトバックログアイテム(PBI)の形式へ落とし込む
- 顧客に対しる理解
- ビジネスモデル作成
- メンバー感で共有理解の情勢(合意形成)
- ここでつまづきポイント
- POとの合意形成を促すしかけが必要
- MBPを定義
- プロダクトバックログを明確化
POとの合意形成を促す仕掛けの作り方
- 複数のプラクティスを組み合わせたワークショップ
- イベントストーミング
- Open Practice Library に乗ってる
- contributeできるぜ
まとめ
- 製品リスクに対処
- アジャイル開発の説明、POとの向き合い方あたり
感じたこと
- Open Practice Libraryを覗いてみよう。
エンジニアとマネージャーは、いつも勝負をしているのだと思う
- 技術力の高いエンジニアを管理するマネージャー
きっかけ
- 優秀なメンバーの転職
- 自分に腹がたった
よくある悩み
- メンバーの成長
- マネージャーの重要トピック
- どれぐらいフォーカスするのかわからない
- マネージャーの重要トピック
- 成長は事業にとって良いこと
- 成長: 事業成果に還元される変化
- 失敗を許容するために能力不足は許容できない
- HarbardBizSchool
- 不確実な環境では知識は動く標的になるが、そんな環境で新たなスキルを学ぶことが、およそどの業界でも競合するうえで不可欠になっている
- チームが機能するとはどういうことか
成長
- Will
- 本人の望む成長
- Need
- 組織が望む成長
- 重なりが大きくなるように努力する
- Will
重ならないNeedへの対応
- WillとCanが重なる別メンバーを探す
- 専門集団として組織化
- グループ外連携
- Needを動かす
- 事業ニーズのハックBizDev
Willを動かす
- 本人のきづきを見逃さない
- Visionが重要
- なにを目指しているのか。動かすきっかけになる
- Visionが重要
- 自主性を見逃さない
- 本人のきづきを見逃さない
チームと指定成長していく
- NEEDが重要である以上、特定業種のみ成長すればよいわけではもちろんない
- 基本的に全てのメンバーの成長
事業という制約条件
- 成長環境の制約条件に議場貢献があるよ言う割り切り
- 事業成長、事業衰退ともにメンバーの成長に大きな影響を与える
- 競合他社や技術発展も成長環境整備の制約条件
メンバーのWillがないプロジェクトは寝かせる,待つ
まとめ
- メンバーの能力向上や学習が必要
- 本人のWillと周囲のNeedを上手く調整する仕事が必要
洗浄を定義
- プロは自分にも他人にも厳しい
技術力勝負はきびしい(マネージャー側)
マネージャーの弱み
- 技術力
- 自分より優秀な人材を採用する ゆえのジレンマ
- マネージャーの成長のためにメンバーがいるのではない
- マネージャーの脅威
- ライフイベント
- 強み
- 組織構造の決定権
- システム構造の決定件
- 評価の基準の決定権
- 予算を取りに行く力
- 機会
- 上司が偉い人
- 部下が優秀な人
💰でかいけつできることがある
- 書籍
- カンファレンスの参加費
- 計算機料金
勝ち筋を整理する
- 強みと機械を最大限活用して成長環境を整備仕様
事例
成長フェーズの分類
- キャッチアップフェース
- ある程度まかせられるが、自分より強いメンバーがいる
- 開拓フェーズ
- 学習すべき事柄に、自分より強いメンバーがいない
- キャッチアップフェース
キャッチアップのサポート
- 1 on 1
- 成長が早くてわかりやすい
- 気をつけていること
- 偉い人との 1 on 1 をすることで成長している事に安心できる
- 成長期間をちゃんとつたえる
- 1年かかるとか
- 開拓のサポート
- 新サービスの開発リーダー
- リーダーは会社に残りやすい
- サポートをお願いしたメンバーは転職していくことが多い
- とはいえリーダーを絞るのは大原則
- 新サービスの開発リーダー
研究開発案件は兼任体制で
- 研究の定義
- 重要だけど緊急でない問題
- チームを分けるべきか？
- メンバーの成長にフォーカスすると、波及効果があるため分けていない
- 技術力向上の手段としてアカデミアをレバレッジ
出向
- 中にいなかれば外の専門家に面倒をみてもらう
技術顧問制度
- 外の専門家に見てもらう
- 効果が微妙
- 受け側のエンジニアリソースが足りてない
- 効果が微妙
早くからマネージャーにしない
- アンチパターン
- 本人のWillがないのに、望まない形でマネージャーにしない
- 何人も失敗した
新卒動機を集める
- 雑談しやすい(ごはんとか)
- 情報共有とか勉強とか発生しやすい
- マウントを取るメンバーが発し絵しづらい
- 一般化すると社内のソーシャルグラフを利用する
ファシリテーター
- スクラムマスター
- マネージャでなく、1メンバが仕切っているのが非常に助かっている
- 同じPMチーム所属でもPMチームのマネージャーが仕切るのと、メンバーが仕切るのではおそらくエンジニアメンバーのやりやすさに違いが生じる
- 指示系統ラインがつよくないｒすぎないようにする
- 開発が企画側の考えや進捗を把握できない
- 除法格差が生まれやすい(登壇者主観)
- 開発が企画側の考えや進捗を把握できない
まとめ
みれんかった
入社メンバーの受け入れ
開拓フェーズ
マイグレーションの良いこと
- Good
- 仕様をきらなくていい
- 技術選定できる
- Bad
- 泥臭い仕事がある
- マイグレーションしやすいシステムにしておかないと辛い
感じたこと
- Will(本人の望む成長)とNeed(組織が望む成長)が重なるといいな
- 逆に重ならない時の対処は考えないといけない
- 定期的な 1on1 して指向性のすりあわせは必須と感じる
- Will変化があるのでなるたけ適度に短いサイクルがいいのか。
- 定期的な 1on1 して指向性のすりあわせは必須と感じる
クラウドネイティブ時代のマルチテナントアーキテクチャとデータ設計
技術
DB
- サーバーで分離
- サーバー、機能で分離
- 機能で分離
- MongoDB
- 共有
シャーディング利用してない
- ので自前で振り分け処理をやっている
ES
- マネージドサービスでは利用したい機能が消されてたので、自社運用
- Javaのバージョン問題なのでクラッシュしていた
- マネージドサービスをおすすめする
リクエストのテナント識別方法
おすすめは1, 同時に複数テナントログインとかできる
パフォーマンス
- 影響が広がる傾向にになる
- Cloud Watch Logs Insightsによるパフォーマンスチェックしてる
- API呼び出しよりも少し細かいログ出力にしている
- 処理時間もだしている
- 重たいAPI問題
- LBで重たい処理の振り分け
- 特定ユーザーによる資源専有
- あとから制限は難しい、事前に初期に計画しておくことが大事
感じたこと
- 設計大事
- あとで移行しやすいような設計にしておくことはもっと大事
本気で実践している人たちにしかできない話が聞きたい
登壇者の選定
- 理論と実勢の違い
- 悩んで答えを出した人たちを集めた
- 本気でやってき人たちの言葉を持って帰ってほしい
まだ見ぬかちへたどり着くためのデータプロダクト開発と組織づくり
- データプロダクト
- データ活用に価値
- レコメンドとか
- データ活用に価値
- チームメンバーを他チームに社内留学だした。
- 他チームのリソースをくわなくするため
マイクロサービスにおける技術と組織の衝突に向き合う
- マイクロサービスは組織論？
- 理想系
- ビジネスドメインで切り出される
- 1 サービス, 1チーム
- 公明の法則下痢主義がいる
- 組織が目的になっているのはNG
- 技術、組織の両輪ですすめるもの！
協力の組織デザイン
技術目線
技術と組織が衝突する実例
- 共通機能サービス
技術と組織がconflict コンウェイ？
組織本能の考察
https://speakerdeck.com/dskst/consideration-and-adaption-for-organizational-instinct
- 白い🍚を食べる文化を急に🍚NG, パンの文化にしようとすると争うが起こる
民族が民族を変えようとする時
- 分断される
組織本能
組織本能を変えるには
- 経験
- 断言
- 反復
- 感染
- 経験
エトス、パトス、ロゴス
圧倒的なトップダウンと言う強カードもある
エンジニアリングマネージャーは何をする人なのか
https://speakerdeck.com/yunon_phys/what-are-roles-of-engineering-managers
組織を変える前に変えること
- ラリー・ペイジ
- こんな広告は糞だ。
- Googleだからできた？
- 自分のところでは？
- 自分はできない。
- こんな広告は糞だ。
- 心理的安全性さえもマウンティングの対象となる
- 威嚇と嘲笑
- NG
- 普段からの人との向き合い方
- 心から相手を気にかけれるか
- 超属人的
- 継続できるか
感じたこと
- 組織を変えたい場合、かならず対立がおきる
- 新しい概念を経験させる
- 断言
- 反復
- 感染
- 考え方よりも感情を揺さぶったほうが通じる
- 新しい概念を経験させる
- 解消したい事がEngineering Managerの領域をかぶる部分がある
- 手法を学んで適用できるかもしれない
- 勉強する
- EM.FMきく
- 手法を学んで適用できるかもしれない
- 心理的安全性がおまじないみたいに使われている
- もっと具体的に、普段からの人との付き合いを考える
- EQ上げる(あがるのか)
参加して
TODO: 追記する...!
