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
750
既存の仕組みを棄てる技術
20211215 の カイゼン Tips LT会 (#kaizenlt) で発表した内容です。
athagi
December 15, 2021
Tweet
Share
More Decks by athagi
See All by athagi
社内でAWS GameDayを開催しよう
athagi
2
520
petなEC2をまとめて監視してみた
athagi
1
230
冴えない開発環境の育てかた
athagi
0
90
GitLab-CI でPrivate Registry を利用する話
athagi
0
1.5k
Kubernetes がない世界の CloudNative ジャーニー
athagi
0
380
ゆるキャンはじめました。
athagi
0
1.6k
Windows Server にAnsibleを使ってみた話
athagi
2
2.1k
Other Decks in Technology
See All in Technology
許しとアジャイル
jnuank
1
150
業務効率化をさらに加速させる、ノーコードツールとStep Functionsのハイブリッド化
smt7174
2
130
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
550
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
410
Shirankedo NOCで見えてきたeduroam/OpenRoaming運用ノウハウと課題 - BAKUCHIKU BANBAN #2
marokiki
0
190
Adapty_東京AI祭ハッカソン2025ピッチスライド
shinoyamada
0
280
Developer Advocate / Community Managerなるには?
tsho
0
140
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
460
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
440
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
4
360
AWS IoT 超入門 2025
hattori
0
330
オープンソースでどこまでできる?フォーマル検証チャレンジ
msyksphinz
0
130
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Context Engineering - Making Every Token Count
addyosmani
6
240
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
We Have a Design System, Now What?
morganepeng
53
7.8k
Become a Pro
speakerdeck
PRO
29
5.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Unsuck your backbone
ammeep
671
58k
Facilitating Awesome Meetings
lara
56
6.6k
KATA
mclloyd
32
15k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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