第5章 devopsに対する誤解とアンチパターン

5.1 devopsに対するよくある誤解

この節は、各項（章, 節, 項の項）のタイトルがよくある誤解を表している。一覧してみよう。 （下記の数字リストは、5.1節の項番号に対応している。）

1. devopsに関係があるのは開発者とシステム管理者だけだ
   ==> 否。devops運動が開発者 Development とシステム管理者（運用者 Operations）の部署間ではじまっただけ。この運動の本質はすべての部署に適用できる。
2. devopsはチームである
   ==> 否。専門家チームを作ると却って悪化する。devopsは誰かの役割ではない。大事なのはdevopsの心持ちを理解し「皆で」実践すること。
3. devopsは肩書きだ
   ==> 否。devopsエンジニア = developmentもoperationもできるスーパーエンジニア は誤り。
4. devopsはウェブ系のスタートアップだけの問題だ
   ==> 否。コラボ、アフィニティ（親近感、一体感）、ツールの改善によって利益が得られるのはスタートアップ企業に限らない。
   • 本書のあとの部分では大企業や政府機関にもdevopsの考え方を応用する方法を示す例を紹介する。
5. devopsには認定資格が必要だ
   ==> 否。必要なし。そもそもdevopsは文化。文化を認定はできぬ。
6. devopsとは、半分の人員で全ての仕事をすることだ
   ==> 否。この誤解は危険。一人分の給料で開発と運用の両方の仕事ができる人間を手に入れる（育てる）のがdevopsである、というのは大間違い。
   • devopsはサービス障害の回数と時間を削減したり、開発にかかる時間を短縮したり、個人とチームの力を底上げしたりして、仕事の品質と効率を上げるための手段なのだ。
7. devopsには「正しい方法」（または「間違った方法」）がある
   ==> 否。どの企業にも適用できる方法が存在するわけではない。devopsは仕事の過程、道具、実践方法に対する批判的（振り返り）な思考を奨励する。「唯一無二の方法」を批判せよ。
8. devopsを取り入れるためにはX 週間/Xヶ月かかる
   ==> devopsはいわば旅の過程。旅の目的地ではない。したがって、どれくらいの時間がかかるかは予測困難。
9. devopsはツールの問題だ
   ==> 否。特定のツールを使わなければいけないという縛りがあるわけではない。ただし、良いツールの導入はとても効果がある。ツールは各企業の（devops）文化の一部である。
10. devopsとは自動化のことだ
    ==> 自動化は使い所。頻繁に行う作業で、自動化のための手作業（コマンドを打つなど）にかかる時間を差し引いて時間のお釣りがくればやるべき。
    • 注意点としては、関係者相互の文脈の共有や相手のニーズに対する配慮がなければ、自動化は却ってリスクを増やす。より大事なのは透明性やコラボの水準を上げて理解を深めること。
    • （例）2013年7月アシアナ航空214便の事故では、パイロットが完全に理解できていない自動操縦システムを過度に信頼したために飛行速度の監視が不十分だったため生じた、との問題も指摘された。
    • 補足: 自動化の心持ちはもしかするとこれ。
11. devopsは一時的な流行だ
    ==> 否。devopsは技術やツール、プロセスに縛られたものではないので古びる可能性は低い。ITILやアジャイルとは異なり、devopsは持続的な対話の文化だから。

5.2 devopsのアンチパターン

この節も、各項のタイトルが知っておくべきアンチパターン（devopsの対極にあるもの）を表している。一覧しよう。

1. 非難文化 ミスが発生したときに個人レベルでも組織レベルでも、人を非難し処罰する傾向のこと
   （例）エラーやインシデントを作った犯人探しが行われる。持ち込んだコードにバグが多い、作業量が少ないことで叱る。
2. サイロ 同じ企業の他のチームと知識を共有する気がないチームの雰囲気のこと
   （例）サイロ + 非難文化 => 「Xのやり方を知っているのが私だけなら、私をクビにはできないだろう」という情報の抱え込み。
   • 他のチームの人からリソースや情報を得るために、指揮系統の階層構造を何階層も辿らなければいけない。
   • 同じような仕事をするのに、それぞれのチームが全く異なるツールやプロセスを使う。
   • 水研ではツールはエクセルでも構わないが、計算プロセス（シートの順番, シート内の表の使い方）をできるだけ統一した方が良いと思う。有識者の先生方にとっても。
3. 根本原因分析 問題やニアミスの元となった「根本」原因を明らかにして再発防止のための適切な行動をとろうとする手法
   （例）「5回のなぜ」、特性要員図（石川ダイアグラム）などがある。しかし、根本原因分析では多くの場合、原因項目を一つしか指定できない。間接的に影響を与えたかもしれない要素が目に入らなくなる。
4. ヒューマンエラー ミスを犯した人言自体がエラーの直接的な原因だとする考え方
   （例）根本原因分析の結果では、ヒューマンエラーがよく原因とされる。別の人が担当ならそのようなミスはしなかっただろう、という暗黙の前提を伴うことが多い。
   • しかし、人間がミスを犯すことを単純な怠慢、疲労、能力の低さによるものだと考える傾向があり、その人の判断や実際の行動に至った様々な要因を無視してしまう。
   • 非難文化では、ミスを犯してまずい結果を引き起こしたのはだれかを考えることが中心になることが多く、ミスを犯した個人を見つけたところで議論は終わる。
   • 非難のない文化や学習する組織では、ヒューマンエラーは目的地ではなく出発点として扱われる。そして、判断をめぐる文脈やその時点で行なった判断が合理的に感じられた理由が活発に議論される。