Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
既存の仕組みを棄てる技術
Search
athagi
December 15, 2021
Technology
0
720
既存の仕組みを棄てる技術
20211215 の カイゼン Tips LT会 (#kaizenlt) で発表した内容です。
athagi
December 15, 2021
Tweet
Share
More Decks by athagi
See All by athagi
社内でAWS GameDayを開催しよう
athagi
2
420
petなEC2をまとめて監視してみた
athagi
1
200
冴えない開発環境の育てかた
athagi
0
78
GitLab-CI でPrivate Registry を利用する話
athagi
0
1.4k
Kubernetes がない世界の CloudNative ジャーニー
athagi
0
350
ゆるキャンはじめました。
athagi
0
1.6k
Windows Server にAnsibleを使ってみた話
athagi
2
2k
Other Decks in Technology
See All in Technology
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
260
AIエージェント入門
minorun365
PRO
31
17k
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
140
What's new in Go 1.24?
ciarana
1
110
2/18 Making Security Scale: メルカリが考えるセキュリティ戦略 - Coincheck x LayerX x Mercari
jsonf
0
190
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
140
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
分解して理解する Aspire
nenonaninu
2
1k
ABWG2024採択者が語るエンジニアとしての自分自身の見つけ方〜発信して、つながって、世界を広げていく〜
maimyyym
1
140
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
280
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
6
250
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
640
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
How to Ace a Technical Interview
jacobian
276
23k
Typedesign – Prime Four
hannesfritz
40
2.5k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Transcript
既存の仕組みを棄てる技術 カイゼン Tips LT会 (#kaizenlt) あさぎ(@_athagi)
自己紹介 ▷ 所属企業 ◦ 1000~ 規模のBtoB 企業に所属 ◦ 20年程度のシステム ▷
担当 ◦ CICD周りを担当 ◦ DX推進担当 ▷ 最近 ◦ コロナになってから始めた筋トレの成果が でてきた ◦ 関節を痛めそうになった 2
こんなものを社内で見かけませんか? 3 なんでこうなっているのかわからないツール メインブランチではないブランチがメインとして扱われ ている社内ツール ドキュメントも担当者もわからない/いないけど 利用されていることだけはわかるツール
なぜ生まれてしまうのか 4
時代に則さなくなってくることで生まれる流れ 1. AとBというツールを連携させたい 2. それぞれには連携させる機能がついていなかった(解決したい問題) 3. A-Bを連携させるためのツールを作成する 4. しばらく運用される(ここでコンテキストが失われることもある) 5.
AにBと連携する機能が追加される 6. 解決したい問題がわからなくなり、なぜそのツールが存在しているのかわからな い。捨てられない。 5
構築したシステムから文脈が失われる流れ 問題に直面した人が解決するツールを作成する (1) の作成者がいなくなり、コンテキストが失われる ▷ 他の人がボランティアで引き継ぎを行う ▷ 片手間で引き継ぐので問題が発生したときにアドホックな修正だ けを行うようになる ▷
周辺の人からは運用回っていると思われる (2) の人がいなくなり、コンテキストが完全に失われ、周辺ツールも変わっ てくるので何を解決したかったのかがわからなくなる 6 1世代: 2世代: 3世代:
ハイラムの法則(暗黙のインターフェースの法則) あるAPI に十分な数のユーザーがいるとき、APIを作った者 自身が契約仕様として何を約束しているかは重要ではない。 作られたシステムが持つあらゆる観察可能な挙動に関して、 それに依存するユーザーが出てくるものである。 7 「Googleのソフトウェアエンジニアリング」
積み重ねで認知負荷が高まってくる 8
ここで2択 ▷ (過去の人も行ってきた)アドホックな修正だけを行って今を生きる ▷ 書き直しを行って、コードが動くようにする 9
業務改善の4つの視点 ▷ 排除(Eliminate) ◦ 作業をやめられないか ▷ 結合(Combine) ◦ 別々の工程・作業を一つにまとめられないか ▷
交換(Rearrange) ◦ 工程や作業の順番を入れ替えられないか ▷ 簡素化(Simplify) ◦ より簡単な方法で実現できないか 10
ここで2択 3択目 ▷ (過去の人も行ってきた)アドホックな修正だけを行って今を生きる ▷ 書き直しを行って、コードが動くようにする ▷ もう役目を終えていることを示してやめる ◦ コードが利用されていないことを証明
◦ 利用するツールに追加された機能で代替する 11
問題の母数を減らすことを考える 12
やめようとすると... ▷ ケアしたほうが良い集団 ◦ やめることをやめさせようとする人 ▪ ヒアリングしつつ、改善するための味方にできる ▪ なぜやめたほうがいいのかと説明の向きを変える ▷
ケアしなくて良い集団 ◦ 「いいぞ、もっとやれ」という人 ◦ 無関心な人 ▪ 見えるところにログを残して、自主的に進めればよい ▪ 後で問題が発生するのはここの集団なのでログを残す 13
進め方 −立ち位置− ▷ 自分がコードの管理をできる立場につく ◦ 主担当が別にいて、現状に満足していると、口を出しても(正論を言ったとし ても)動かないし、拒絶されてしまう ◦ 「わたし vs
あなた」ではなく「わたしたち vs 問題」という構図をつくる ◦ 問題が起きたときに対処する主体性 ▷ 分かる範囲で全体像を掴む 14
進め方 −調査方法− ▷ ログを確認し、連携先を確認 ▷ 問題が起こらないことを事前に証明することは難しい ◦ 「エラーが許される vs 問題が起こらないことを証明する」のコストを比較し
て、リスク許容度に応じて実行に移してしまう ▷ 解決したい問題を再定義する ◦ ドキュメントが存在しない場合、、どんな問題を解決したくてこのツールが存 在しているのかを再定義してドキュメント化 ◦ 問題の前提が変わったりしたときに棄てるタイミングが分かる 15
許可を求めるな、謝罪せよ の精神 It's easier to ask forgiveness than it is
to get permission. (事前に許可を得るより、あとで許してもらうほうが楽) − Grace Hopper − 16
進め方 −削除方法− ▷ ロールバック可能な状態で棄てようとしている機能を無効化する ◦ AMIのバックアップ ◦ 設定のバックアップ(設定値のメモ) ◦ 外部サーバと連携している場合は、対象サーバとのネットワークを遮断する
◦ 削除するのではなく、停止しておく 17
削除して初めて問題があらわになることも... ▷ 削除することで、影響範囲外にあるコンポーネントから火の手があがることもあ る ◦ ロールバックできるようにしておくことで精神的に安全になる ◦ 「利用されている箇所がわかった!」という認識 ▷ チーム内で共有しておくことでカバー
◦ 他のメンバーが問題に対応 ◦ 上司に責任を渡すことができる 18
……やったか!? (問題を倒しきりました) 19
……やったか!? (問題を倒しきりました) 20 やってない
完全に削除する ▷ しばらく削除したい機能を止めておき、安全が確認できた段階で完全に削除する ◦ 普段の仕事を行っていると忘れがち ◦ 削除をしきることで不要なコンテキストもなくせる(認知負荷が低くなる) ◦ これを忘れると、歴史を繰り返すことになる 21
重要!
まとめ ▷ 積み重ねで認知負荷が高まる ▷ 問題の母数を減らそう ▷ 許可を求めるな、謝罪せよ の精神 ▷ ロールバックできるようにしておこう
▷ 完全に削除するところまでがゴール 22