『システム運用アンチパターン』輪読会 ９章「空の道具箱」

## イントロダクション

Webアプリケーション実装完了！
よしよし、あとは環境を作ってデプロイするだけだ！

ん〜...自動化するのめんどくさいな...

よし、**一旦**手動でデプロイして、いつか自動化しよっ！

---

〜半年後〜

---

お、久々にデプロイだ。

よし、ssh接続して、前回実行したデプロイコマンドをhistoryから実行っと...あれ？

なんか失敗した。

あ、変なことやっちゃった！リカバリーしなきゃ！！

あぁ...余計な工数が...

<b>最初から、手動運用などせず、自動化していたら...!!!</b>

---
## 初めに

### 空の道具箱とは

適切なツールを使用することなく作業している事実が、他タスクに埋もれてしまうことで、再現性がなくなり、トラブルが発生しやすい状況になっているが、その原因がどこにあるかわからないにもかかわらず、打開するためのコスト投資が欠落している状態。

### 本章では

プロダクトを提供するツールの自動化に投資しない場合の問題点を明らかにする。

---
## 7.1 社内ツールと自動化が重要な理由

### 要約

ツールや自動化が重要な4つのポイント

 - 待ち時間
     - タスクが手動で人から人へ流れて行く場合、必ずリードタイムが発生する
     - 自動化することでリードタイムを短縮することが期待できる
 - 実行時間
     - 塵も積もれば山となる
     - 1日2分の手動作業が発生した場合、1年間で8.5時間以上も消費する
     - 加え、単調な作業はシステムの方が早く実行できる
 - 実行頻度
     - 繰り返し行われる作業は集中力が低下する
     - 加え、別作業が横入りで入ってきた場合、コンテキストスイッチに脳のリソースが使用される
 - 実行のばらつき
     - 再現性がない
     - どのような作業でも手動で行うと必ず差分が発生する
     - 人・環境によって差分が発生するとその分コストがかかる

4つのポイントを改善することで、属人化することなくスピーディーにシステム運用することができ、エンジニアの開発に集中できる環境を構築することができる。

### 解釈・感想

 - 経営層やディレクター等の非エンジニアはこのあたりの感覚がエンジニアとかなりギャップがあるため、自動化が重要な理由をエンジニア側からしっかり説明できるようにしておくことが必要。
     - 金銭・時間的コストがどれくらい変わるか定量的に示すことができれば、否定する経営者は少ないと思う。
     - **仮に提案が却下されたとしても、明確な意志を持って計画的に改善していくことを伝えることが大事**

---

## 7.2 なぜ組織はもっと自動化しないのか

### 要約

#### 自動化を文化的な優先事項と位置付けできていない

 - 時間が足りない
     - 短期的な視野で行動をしがちである
 - 優先順位が低い
     - ロードマップには記載されることがなく、必要なリソースが担保されていない
     - 問題提起するのは少数のエンジニアであることが多い
 - 緊急性は正確性に勝る
     - 一旦このままで、次対応しよう
     - という魔法の言葉で片付けられるケースが多い

#### 自動化やツール開発の人員

 - 同質的なスキルセットを持つチーム
     - チームで採用する場合、今いるメンバーと同じようなスキルを重視する傾向がある
     - チーム内に自動化やツール開発のスキルを持っている人が不足している場合、いつまで経ってもチームにアサインされない
 - 環境の犠牲
     - システム設計上、自動化・ツールの導入難易度が高い場合、自動化・ツール作成の必要性が薄れてしまい、行われなくなる

### 解釈・感想

 - 私の周りにいるエンジニアは最新の環境、FW、言語などには飛びつきがちだが、自動化・運用簡略化する技術にはそこまでキャッチアップしていないように見受けられる。
     - 各個人のスキル向上はもちろんだが、チームとして自動化・運用簡略化する技術学ぶ環境がとても大事。
 - 自動化・ツール導入難易度が高いものに関しては**怪我を恐れず**ドラスティックな対応を計画していくことが**必須**。

---

## 7.3 自動化に関する文化の問題を解決する

### 要約

#### 文化から改善していくことが大事

 - 手動での作業は認めない
     - 仕組みを作る
     - 手動と自動の妥協点は決定する
 - 手動作業のコスト
     - プロセス実行のコストと自動化のコストを見積もり、相対的に比較することで自動化のメリットを定量的に表現する

### 解釈・感想

 - 仕組み化することである程度の強制力を持つ頃ができる
 - ランニングコストとイニシャルコストを理解するような環境の構築が大事

---

## 7.4 自動化を優先する

### 要約

プロジェクト成功のためにも自動化は必須。

### 解釈・感想

その通り。

---

## 7.5 自動化の目標を決める

### 要約

ツールや自動化が重要な4つのポイントで述べた、

 - 待ち時間
 - 実行時間
 - 実行頻度
 - 実行のばらつき

のポイントを指標とする。

#### 全てのツールの要件としての自動化

 - APIアクセスを可能にするSDKが提供されているか
 - コマンドラインのインターフェースがあるか
 - HTTPベースのAPIがあるか
 - 他のサービスと連携できるか
 - GUIでしか操作できない機能はあるか

#### 業務の中で自動化を優先する

 - タスクを完了することによる達成感に苛まれ、短期的な目線となってしまう可能性がある
 - 自動化を優先事項とメンバーと共有することが大切
 - スキルが不足している場合は、トレーニング・学習時間を確保する
     - 所謂技術検証、疎通確認
 - 自動化にかかる時間を見積に含める
     - 成果物の一部であることを明示的にする
     - プロジェクト初期から明示的に見積に含める
 - 自動化のためのマイルストーンを決め、スケジュールを明確にする

### 解釈・感想

 - ツール選定基準が言語化されている。インスパイアーしよ。
 - スクラム・アジャイル開発をやっているのであれば、Sprint Planningでポイントを決めれば良いが、WFで開発する際はなかなかハードルが高そう
     - 特にSESの場合、コモディティ化しているため、いかに安くするか焦点が行きがち（経験談）
     - 確固たる意志、もしくは自社開発の場合は自動化のルールを徹底する

---

## 7.6 スキルセットのギャップを埋める

### 要約

 - 自動化は素晴らしいが、全てのチームがスキルを持っているとは限らない
 - 必要なスキルは組織内に存在し、そのチームにヘルプしてもらうことはDevOpsの概念において非常に重要
     - スクラッチで構築するのではなく、あるものを利用する
 - プライドが邪魔をする場合
     - 今まで手動運用してきたことによるプライドが確かに存在する
     - 助けを求めることは無能さを認めることではない
 - 自動化を導入することにより、バグや緊急事態などの対応が発生した場合、関係するステークホルダーの工数を奪ってしまう
     - なので事前に関係するステークホルダーと合意すること
     - 感情的にコミュニケーションするのはNG

### 解釈・感想

 - 心理
     - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/300430/fb345768-8ba2-243f-46f7-d7143b1ec8bc.png)
     - ©️史上最強の弟子ケンイチ
     - システムも同じ
 - 心理的なハードルは実際問題存在する
     - 今までやってきた自信が自動化を提案することで、プライドが傷つき関係が悪化する
     - この際は、**何がボトルネックなのか**や**ツールや自動化が重要な4つのポイント**をベースに定量化してコミュニケーションを取らないといけない
     - 仲介役は大変だ（遠い目）
 - ステークホルダーとの調整が一番コストだったりする...

---

## 7.7 自動化のアプローチ

### 要約

:::note warn
工事中
:::

### 解釈・感想

:::note warn
工事中
:::

---

## 7.8 まとめ

### 要約

 - 運用の自動化はシステム機能の一つ、設計プロセスの早い段階で検討すること
 - 自動化を優先することは、自分達の作業を検討するときだけではなく、利用するツールを選定するときにも考慮すること
 - タスクの複雑さを検証し、その複雑さの応じた自動化アプローチを選択することで、適切な口語を見つける
 - スキルセットのギャップを解消するために、組織内の他の部署を活用すること

### 解釈・感想

 - 全ては文化だ...文化形成・仕組みの構築に注力する必要がある
 - イニシャルコスト・ランニングコストを計算して最適な手法を選択すれば、自ずと自動化・半自動化というアプローチになると考えられる
     - 承認を得るためにはステークホルダー（経営・ディレクター・ブロダクトオーナー）へロジカルに説明し、具体的な改善コストを明示する必要がある
     - ステークホルダーがエンジニア的視点を持ってくれている人ならやりやすいんだけどね
     - そういう観点から元エンジニア経営者・プロダクトオーナーというのは強いのかもしれない