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
740
既存の仕組みを棄てる技術
20211215 の カイゼン Tips LT会 (#kaizenlt) で発表した内容です。
athagi
December 15, 2021
Tweet
Share
More Decks by athagi
See All by athagi
社内でAWS GameDayを開催しよう
athagi
2
490
petなEC2をまとめて監視してみた
athagi
1
230
冴えない開発環境の育てかた
athagi
0
89
GitLab-CI でPrivate Registry を利用する話
athagi
0
1.5k
Kubernetes がない世界の CloudNative ジャーニー
athagi
0
370
ゆるキャンはじめました。
athagi
0
1.6k
Windows Server にAnsibleを使ってみた話
athagi
2
2.1k
Other Decks in Technology
See All in Technology
【あのMCPって、どんな処理してるの?】 AWS CDKでの開発で便利なAWS MCP Servers特集
yoshimi0227
6
950
Introduction to Bill One Development Engineer
sansan33
PRO
0
260
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
3
2k
助けて! XからWaylandに移行しないと新しいGNOMEが使えなくなっちゃう 2025-07-12
nobutomurata
2
200
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
3
380
“日本一のM&A企業”を支える、少人数SREの効率化戦略 / SRE NEXT 2025
genda
1
270
An introduction to Claude Code SDK
choplin
2
1.2k
LIXIL基幹システム刷新に立ち向かう技術的アプローチについて
tsukuha
1
380
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
130
VS CodeとGitHub Copilotで爆速開発!アップデートの波に乗るおさらい会 / Rapid Development with VS Code and GitHub Copilot: Catch the Latest Wave
yamachu
3
460
Transformerを用いたアイテム間の 相互影響を考慮したレコメンドリスト生成
recruitengineers
PRO
2
440
ロールが細分化された組織でSREは何をするか?
tgidgd
1
420
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
340
Facilitating Awesome Meetings
lara
54
6.5k
BBQ
matthewcrist
89
9.7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
GitHub's CSS Performance
jonrohan
1031
460k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Into the Great Unknown - MozCon
thekraken
40
1.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Side Projects
sachag
455
42k
Building Adaptive Systems
keathley
43
2.7k
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