https://www.youtube.com/watch?v=edWYe9q5aCg
-
基調講演「システムの陳腐化が減価償却の速度を追い越した時代に生きる僕たち・私たち 」原 トリ / Tori Hara 氏
- 緩やかに死んでいくシステム
- トリさんの登壇はどれも素晴らしいのだよなあ
- 最適は時間の経過によって変化するので継続的な改善が必要
- 「継続的に改善できる」ようなものになっているかどうか。これめちゃくちゃ大事なんだよな
- Needs to be a Detective 笑
- 継続的な改善を殺すものは？
- 主体的思考の欠如、緩慢なオーナーシップ
- 肥大化した組織・チームによる緩慢かつ遅い意思決定
- チーム開発意識の欠如
- 知見を共有するのではなく、安易にWrapしていないか？
- 長老だけが知るシステムの全体概要
- あるある
- AWSは継続的な改善を止めないためにチームを小さく保っている。チーム内外の依存関係を減らすことで意思決定と改善の速度を挙げる。
- また、デザインドキュメントを書いている
- ECSのアーキテクチャ図読みてえ〜
- design docが継続的に更新されていたら、改善のためのアプローチを見つけやすくなる
- コードを読むだけじゃわからないコンテキストは存在する。それを記録することが重要。それな
- AWSにおけるPrincipalEngineerの役割、興味深い
- 「当時何も考えていなかった」ということが記録に残っていることも重要
- 元システムを知らずにフルスクラッチで作り直すのは悪手すぎるなｗ
- トリさんの発表は刺さりすぎる
- 質問タイム
-
- design doc書いて実装した後に設計やっぱ違うな、となることありそうだけどどうしているのか
- => トリさんが所属しているチームだとPoCを書きつつドキュメントを書いている人が多い。人によってはいきなりDesignDocがでてくることもある。そういう場合はPoCを作るなりしてデータをとってこいと言われることもある
- なるほどな
-
- design docを定期的に更新する仕組みはあるか？
- => 仕組みはないが、機能追加時にdocを書くときに親docを書くことはある。docの更新漏れは「ある」。誰かが歯を食いしばりながらなおすことになる。 (edited)
-
-
- 「Wrap」はどういうニュアンスか？
- => ツールなどで安易に複雑性を隠蔽してしまうと、継続性な改善が阻害されてしまう（例：k8sのマニフェストを開発者が書かなくてもよくなるようななにか）
- AWS、組織的にちゃんとマイクロサービスしているがそれゆえにサイロ化して辛いこともあるらしい。
-
事例1「NewsPicksにおけるクラウドネイティブな継続的改善を支える組織文化」 株式会社ニューズピックス 執行役員CTO 高山 温氏
- クラウドが普及して10年。クラウドで作ったシステムも陳腐化する
- クラウドを使うことが「手軽」ではない。一人で全てカバーすることはできない
- r_takaishi.icon 手軽だった時代ってあったっけか…？
- なので継続的改善のための組織力が必要
- NewsPicks、インフラエンジニア出身の人は今もほぼいないらしい
- News Piccksでもイマイチな仕組みが残ってたりするんだな
- 開発者体験を向上させるための改善活動（デプロイを楽にする、手動オペレーションを減らす、自動テスト、セキュリティ監査の自動化など）
- r_takaishi.iconこれはめちゃ大切だよな。
- 過去の時点では最適な選択を行ってきているということは重要
- 「枯れる」は幻想？
- r_takaishi.iconそれはまああるかもねえ
- r_takaishi.icon式年遷宮的な。
-
事例2「全社課題として向き合う技術的負債 -サービスの成長と技術改善を両立できる組織であるために-」 株式会社アルファドライブ 執行役員CTO 赤澤 剛氏