既存の仕組みを棄てる技術 カイゼン 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

ここで２択 ▷ （過去の人も行ってきた）アドホックな修正だけを行って今を生きる ▷ 書き直しを行って、コードが動くようにする 9

業務改善の４つの視点 ▷ 排除（Eliminate） ○ 作業をやめられないか ▷ 結合（Combine） ○ 別々の工程・作業を一つにまとめられないか ▷ 交換（Rearrange） ○ 工程や作業の順番を入れ替えられないか ▷ 簡素化（Simplify） ○ より簡単な方法で実現できないか 10

ここで２択 ３択目 ▷ （過去の人も行ってきた）アドホックな修正だけを行って今を生きる ▷ 書き直しを行って、コードが動くようにする ▷ もう役目を終えていることを示してやめる ○ コードが利用されていないことを証明 ○ 利用するツールに追加された機能で代替する 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