Developers Summit 2019 参加メモ
event.shoeisha.jp Developers Summit 2019へ参加してきたので参考になった登壇のメモや感想を記載する。 参加したセッションはマネジメントや組織に関するものが多くなってしまった。セッション全体が流行りに乗ったのか課題感から参加セッションが偏ったのかはわからない。特に参考になったセッションや共感したセッションについて書いた。
- レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン
- カオス化した組織とエンタープライズシステム群を、モダン化したい！ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり
- メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと
- Site Reliability Engineering at Google
- その他
レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン
概要
- 「技術」ではなく「判断」寄りの話
- 事業サイクルが成長期から成熟期に入り業務改善もスコープに入る時期の話
メモ
### 状況
* エンジニア新規採用苦戦
* 在籍エンジニアのモチベーション低下
#### 現状調査
* 機能一覧の作成
* 画面やバッチ毎で作成
* 関係者との議論がスムーズ
* 葬り
* 不要な機能を削除
* 問題の分母を減らせるので調査、改修の見通しがよくない
* 無理しない方針
* 長期で段階的にカイゼン
* フルリプレースは工数捻出厳しい
* 取り組む問題は、絞る
* 価値と工数の２軸で評価
### 問題選定
* 今やること
* 自由なインフラ
* AWS移行
* 開発しやすい環境整備
* 先送り
* アプリケーションの根本見直し
### 移行
* ランニングコストの問題
* EnterPriseからStandardへ移行
* コスト削減
* 要件を損なわないか
* まとめ
* コストのかかるアプリケーションの改修は移行後に先送りにするが、改善効果が高いインフラや開発環境の改善を移行時の変更範囲に含めた。
* エレガントにテストができない場合、自由なインフラを活用。テスト環境を本番環境に極力合わせ、実際の挙動と比較することで品質を各保した。
* 移行時のテストはいきないここに動作確認するのではなく、まずは全体に影響するエラーを対処する。
### 振り返り
* 全サービスのAWS移転、開発しやすい環境整備、アプリ・インフラ運用が出来た
* 相当頑張った？
* 無理はしてない
* 各個撃破という戦法
* 戦法：各個撃破
* 現状把握から始める
* 1度に欲張らない
* 建設的先送り
* レガシーシステムには問題の数と質の2面の難しさがある。しかし1土に取り組む数を減らせば攻略は確実に進む
* そのため各個撃破という戦法を選択した
* 問題の質と複雑さに苦しまないように切り分ける
* 1個づつ各個撃破
* コントロール可能な範囲を徐々に広げる
* 以上を繰り返す
感想
判断に関する話に共感した。現状把握から始め無理をせず各個撃破で進めていくこと、スコープを明確にしてやること、やらないことを決めるのはPJを進める際には取り入れていきたいと思う。 使っていない機能を洗い出して葬っていくことも実践していたのでPJ及び運用フェーズにおいても継続していこうと思う。
カオス化した組織とエンタープライズシステム群を、モダン化したい！ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり
概要
- キラキラしてないエンタープライズな組織でべき論を実現するために泥臭く取り組んだ話
- 組織・戦略レベルの改善事例
メモ
### 背景
* 10年かけて巨大化した基幹システム
* 複雑化という名の高度化を遂げた業務プロセス - 長期化する影響調査と、頻発する障害対応
* 縦割り型の企画/IT企画/開発/運用組織
### 3年前の状況
* 見られ方
* 遅い
* 開発期間長い
* 納期遅れる
* 障害多い
* 3日に1回は障害
* 社内の抵抗勢力
* 難易度から話してくる面倒な組織
* 開発組織の状況
* IT企画：9人で9事業をカバー
* 開発：1社によるベンダロックイン
* 運用：インシデント消化率40&
### 戦略(計画)
* Y1-2：組織能力の拡大
* Y2-3：システムのサービス化
* Y3- ：キカクカイハツの変革
### 対応
* 組織能力の拡大(Year1-2)
* IT企画
* Result
* 9人で9事業→21人で4事業(内製10名)
* 問い合わせが業務の4割→2割
* Action
* 体制強化
* 採用(直近だけでなく未来を見据えた採用、多様性)
* BPR
* 工数の可視化
* 汎化
* ナレッジ共有
* 運用
* Result
* 常時240のインシデント→常時20
* インシデント消化率40%→80%
* Action
* 体制改善
* 継続改善
* 性能改善
* 開発
* Result
* ベンダロックイン→マルチベンダ化
* 言語、フレームワークの古さからベンダの選択肢が限られる問題は残存
* Action
* マルチベンダ化
* 支援体制の構築
* スタンス
* 秘伝のタレではなく、業界標準の技術、思想に合わせる
* 育てるスタンスで案件を依頼
* 振り返り
* 採用、保守コスト増の決済
* 否決もあり平均2.6回の承認状況だった
* 合理性は大切
* 採用
* 課題と夢を話して共感してくれる人、解決の仕方を考えられる人を口説いた
* 現状の合わせた採用をしていたら現状維持だったと思う
* システムのサービス化(Year1-3)
* 内部改善では超えられない壁に遭遇しアーキテクチャの刷新をした
* 複数ユーザの要望を受け止めた弊害
* 開発に独自の知見が必要なアーキテクチャ、外部サービスの活用に限界
* サーバサイドコントロールアプリ特有の課題
* アーキテクチャ基本思想の作成
* 柔軟性と速度を持たせること
* 流用可能な汎用性を持たせること
* データアクセス、認証処理などの自社内ルール(特性)を加味すること
* 具体的なアクション
* アーキ層を分割し開発資源の再利用性を高める
* 機能単位の改修、デプロイを容易にした
* SPA化、標準技術の取り込み
* アセット利用による開発効率向上
* 段階的にアーキテクチャとアーキテクトチームを育成
* ベンダ主体にしつつナレッジ継承のため内製組織を立ち上げ
* サブシステムから徐々にアーキを拡張
* 結果
* 開発生産性：20~30%の工数削減成功
* その他
* 静的解析、自動テスト導入はよかった
* 内製チーム結成によりシステム部門のレベル向上
* 保守をアウトソースするだけだった頃はリスクを避ける傾向にあったが適切にリスクテイクできるようになった
* サービス化のなかで出てきた疑問
* ビジネス視点でも市場は閉鎖系からオープン系に変化している。つまり事業会社都合のビジネス展開から顧客中心のビジネス展開へ変換が必要では？
* キカクカイハツを顧客中心に考えらえるように改善
* キカクカイハツの変革(Year3-)
* 「縛る/教えるアプローチ」から「協働がKeyと気付きScrumへ」
* PMBOKレクチャや改修ルールや人的交流も試したが
* 実践を通じて各組織が共通言語で語れる一体感を出すための変革
* 選抜研修、実践、宣伝、全体研修
* PO研修やScM研修を受講
* 大人数向けカスタマイズプランがあるらしい(永和さんとか)
* Scrumのジレンマ
* 局所適用にとどまりやすく全体のプロセス改善、価値を考えるアプローチはないか考えていたときにドメイン駆動と出会った
* ドメイン駆動
* プロセス中心から価値中心へ
* ドメインごとの進化と保留が判断可能
* 継続的に価値を高める組織割につなげやすい
感想
大規模な組織を本気で改善するなら戦略性を持った計画の必要性を強く感じた。現在所属する組織の課題に思う。 抽象的な指針で良いので戦略や方針がオープンになっているとコンウェイの法則よろしくでアーキテクチャと組織文化が合わさってくるのかもしれない。(Persolがオープンにしてたかはわからないが…)
組織能力の拡大の話は、過去の経験を思い返すと共感する部分が多く肯定された気持ちになった。工数の可視化やナレッジの共有、ベンダ切り替え初期のスタンスなど。
コーディングはベンダや新人に任せ、主担当はビジネスロジックやアーキテクチャ設計に専念させる思想は参考になった。任せたコーディングも静的解析ツールを導入していたのでそれで担保しているのだと思われる。 自社内でアーキテクチャ設計が出来ない(苦手)な場合に外部へ移譲する際の選定はどうしてたのかは気になった。
私自身がドメイン駆動の知識不足から理解しきれていないところがあるので学習が必要と反省。 ドメインや価値まで踏み込み組織体制にまで踏み込んだ改善をするには事業側の人間にもかなり理解した人間が必要に感じる。 パーソルの事例ではドメイン駆動を事業に取り入れる際に自信がなかったがScrumの取り組みを通して協働関係が出来ており慣れていたことがプラスに講じたらしい。学習習慣がある組織であるかが重要であるように感じた。
メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと
概要
- EMに対しポジティブな印象を与える講演
メモ
スクラムマスターへのリスペクト
* チームのパフォーマンス = チームが本来持つ生産性 + プロセスゲイン + プロセスロス
* プロセスゲイン：協同作業による正のシナジー
* プロセスロス：協同作業による負のシナジー
評価とは
* 評価の本質 期待値と現状認識のすり合わせ、人事考課は結果に過ぎない
* 成長やキャリアを支援する行為の役割
成長の支援
* 理想の状態
* 成長の実感がある
* 理想とギャップ
* なにを/どのように学べばいいかわからない
* ティーチングが有効
* 社内外の価値向上
* 学ばざる得ない状態を創る
* 人はリスクを感じると行動する
* 適切（即効性のある）なインプットを促す
* 初動から継続に続けるためにはポジティブな体験が必要である
* 学んでいるはずだが成長の実感がない
* コーチングが有効
* ハイパフォーマーほど成長に気付きにくい
* 0→1,は気付きやすい、10→11は気付きにくい
* 1 on 1
* 経験学習に重きを置いてる。書籍より実務、実務の学びを取りこぼさない
* アウトプットできる環境
* 会社としてエンジニアがアウトプットしやすい環境作り
* 社内外向けの勉強会開催
* 楽しくマネジメントを続けるために
* 自己犠牲をしない
* コントロールできない物事に囚われすぎない
* 孤独にならない
感想
前半部分はEMに対してネガティブな感情を抱えていなかったのであまり響かなかった。ただ後半部分の成長支援に関する部分は参考になることが多かった。
Site Reliability Engineering at Google
概要
- SRE本に記載されてる内容から抜粋されたSREの話
メモ
* Borgをオープンソース化したものがk8s
Googleでは単一リポジトリによるコードの管理
* すべてのプロジェクトのソースコードを１つのリポジトリに保存
* ソフトウェア開発者はすべてのソースコードが見れる
目的：安定的にサービスを提供すること
システムを運用するだけでなく安定運用するために必要なソフトウェア開発をあわせて行うチーム がSRE
業務時間の50%以上をソフトウェア開発を含む、システム安定化に関わるプロジェクト活動に充てる。
* 残りの50%で運用業務を行う。
* Burnout(燃え尽き症候群)を防止
* 自動化ツールの開発など、マニュアル作業を減らすためのモチベーション向上
運用から開発側へ突き返す権利を有する
* SREの運用範囲
* 共通インフラ・ミドルウェア
* 重要度の高いアプリケーション
* SREのかかわらないアプリ
* 小規模で重要度が低いアプリケーション
* SREが関わる必要がないほど安定運用されたアプリケーション
SREの活動原則
* 安定の定義
* 「SLOが満たされていること」＝「安定している」という共通認識の確立
* エラーバジェット = 1.0 - SLO
* エラーバジェット、エラーの許容範囲
* エラーバジェットの消費状況をモニタリングして、エラーバジェットがなくなる可能性がある場合は抜本的な対策を講じる
* この際、開発と運用メンバーが協業して対応する。
* SLOを100%にすると？
* 1件でもエラーを出さないようにするため、全リソースをエラー発生防止に注力することになる。すると開発がフリーズする。
* デザインレビューの提供
* 設計段階から「安定化」をゴールとしたデザインレビューを提供
* 設計、言語の共通化による引き継ぎコストの軽減
* Toilの削減
* Burnoutを防止
* 運用作業/障害対応の自動化を促進
* 障害対応のプロセス
* オンコール担当者が障害対応責任者となり、報告責任者と実作業担当者を任命
* 問題解決を最優先して「他人に頼ること」を本人のスキル不足とは認識しないことを徹底
* Postmortem
* 重大障害の解決後に発生要因、対応時の反省点、改善策などを文書化
* また作成はみんなで書き出す
* 個人を避難する内容は絶対に書かない(個人のミスを誘発するシステム設計したSREチームの責任)
* 改善策の実施はSREチームのプロジェクトとして実施
* 社内のすべてのエンジニアに内容を公開
* 障害対応により得られた知見をすべてのエンジニアに共有
* 障害対応の実施訓練にも活用
* 過去のPostmortemを使った勉強会、思考訓練にも使ってるらしい
SREトレーニングコースあるよ
https://www.coursera.org/learn/site-reliability-engineering-slos
感想
SRE本を中途半端にしか読めていなかったので要所を理解するのに役立った。個人の力ではなく組織(システム)的に対応する思想は本当に大事だと思うし取り入れていきたい。特にBurnoutには注意したい。
その他
- 講演は聴いてないけど参考になるスライドでした
- イベントのスライドは以下のリンク先に追加されてる。 デブサミ2019、講演関連資料まとめ：CodeZine（コードジン）
