この書籍のベースになっているPhoenix Projectを読んでなかなか面白かったので関心があった。
DevOpsについて人に話す機会が出てきていることもあり読んだが、この本をベースにチームビルドするのは結構良さそう。
顧客が感じる時間はリードタイムなので、プロセスの改善では、プロセスタイムではなく、リードタイムに注目する。しかし、リードタイムの中でのプロセスタイムの割合は、作業効率の重要な指標になる。高速なフローとリードタイムの短縮を実現するためには、ほとんどかならずバックログとして滞留している時間の削減が必要になる。(Kindle Locations 955)
Webアプリの話に置き換えて考えるとわかりやすい。リクエストを受け取ってキューに入り、実際に処理が始まり、処理結果が変える。ユーザーから見るとこのターンアラウンドタイム（TAT）が短くならなければ意味がない、というのは当たり前だし頷ける。
デプロイのリードタイムを短縮するための制約条件の変化については次の4つの順に変化していくと記載されていて、この制約条件を打ち破った場合、通常は次の制約条件は開発部門か製品オーナーとなる。(Kindle Locations 1162)
- 環境の作成
- コードのデプロイ
- テストの準備と実行
- 過度に密結合なアーキテクチャ
これは経験的にもそうだなと思える。
私たちは、ソフトウェアサービスや製品をグリーンフィールドかブラウンフィールドかで分類することが多い。これらの用語は、もともと都市計画やビルの建築プロジェクトで使われていたものだ。グリーンフィールド開発は、未開発の土地を開発することである。それに対し、ブラウンフィールド開発は、もともと工業目的で使われていた土地を開発することで、それらの土地は有害なゴミや汚染物質によって汚染されている危険性がある。都市開発では、多くの要因から、ブラウンフィールドプロジェクトよりもグリーンフィールドプロジェクトの方が簡単である。取り壊さなければならない既存の構築物はないし、取り除かなければならない有害物質もない。 (Kindle Locations 1741-1745)
もし組織のどこかでDevOpsをやりたいという話になるときは、可能であればグリーンフィールドで実施した方が、純粋に実施したいことを実施できる可能性が高まりそうな感じがする。ただ、ブラウンフィールドの方が実施できた時の効果の実感度合いが高い、とも思える（途中で頓挫してしまう可能性もあるけれど）。
バリューストリームに関わるすべてのチームが持ち込んだ幅広い知識を使って、次の事柄の精査に力を入れなければならない。
- 本番に近い環境の作成、変更承認プロセス、セキュリティレビュープロセスなど、数週間、あるいは数か月にわたって待機が必要な場所。
- 大量の手戻りが生まれるところ、そう言った手戻りを受け入れるところ。
(Kindle Locations 1960)
すぐ近くではC/A率（完全正確率）を高くすることの重要性も書かれていた。C/Aが何の略かパッとはわからなかったけど、趣旨としては開発してそれが差し戻しになって手戻り、となるようなところはバリューストリーム上のバリューの滞留箇所になってしまっている可能性があるからやり方を変えるとかそういうのが必要ということか。
バリューストリームとしては、全体のリードタイムと、価値の追加にかかるプロセスタイム、そしてこの完全正確率、3つの指標をマッピングしてどこを短くしていけるだろうか、どうやって短くしていけるだろうかと考えるみたいだ。
GWSチームを率いるBharatMedirattaは、自動テストが役に立つはずだと考えていた。また、Blandの話を聞いてみよう。「非常に厳しい線が引かれました──自動テストがついていない変更は、GWSには受け入れないということになったのです。彼らは継続的ビルドをセットアップし、律儀にそれを実行し続けました。また、テストカバレッジのモニタリングをセットアップし、時間とともに必要とされるテストカバレッジのレベルは上がり続けました。また、テストの方針とガイドが作られ、社内外のコントリビューターはそれに従うよう強く求められました」 (Kindle Locations 3097-3102)
これも面白くて、テストを必ず実施する方針、Lintを必ず実施する方針にしても、それが自動化されていないとつい忘れられてしまうということはよくある。
こういうときに、適切に、この例のようにCIを有効にして、面倒なことは自動で検知して素早くフィードバックするような仕組みが必要なのだと思う。
以前にAngularのアプリを作っていたとき、コミュニティのスターターをベースにアプリを作るとHuskyというものが有効になっていた。
これはPre-commitとしてLintやテストを挟むことができる代物で、言い換えればLintやテストが済んでないものは自動検知でコミットできない、つまりPushできなくなる。まあ、作業時などで一旦区切りでLintやテストなしでもコミットしたいときはあるからこれは賛否あるとは思うけど。（一方でPre-pushも使ったことがあるけど、あれだとコミットしたのにPushしたら弾かれてコミットログが汚れる感じが少し気分を悪くする）
納期が迫ってくると、デベロッパーたちは、私たちの「完成」の定義に逆らって、ユニットテストを日常業務の一部として作るのを止めてしまうことがある。これを防ぐために、テストカバレッジを測定して（クラス数、行数、順列などの数の関数として）可視化してもよい。一定レベル以下になったら確認テストスイートを不合格にしてもよいくらいだ（たとえば、ユニットテストを持つクラスが全体の80%未満になったとき） (Kindle Locations 3260-3264)
単にテストがパスしていることのみにしていると、気づけばカバレッジがどんどんと低下していく。実際これまでいた現場でも同様の事象は起こっていた。（ひどいケースだとpassと書かれていてテストが書かれていないものだとか！その後TDDの基礎についてレクチャーせざるを得なくなった）
理想的な自動テストピラミッドと理想的でない自動テストピラミッドの話もチームでは共通理解をしておきたい。(Kindle Locations 3285)
理想的にはユニットテストやコンポーネントテストなどでより多くのエラーが見つかり、それでも溢れるものが自動GUIテストやマニュアルテストで検知される。これが薄いと、結局ピラミッドが逆三角形になり、マニュアルテストで見つかるものが多く、テスト工数が高止まりしてしまう。
書籍内でも出典の記載のあったTestPyramidについては下記。2つ目のはそれの開設版のような位置付け。（とても長い）
トヨタ生産方式の中心的な考え方の1つは、「問題に最も近い人間が問題をもっともよく知っている」ということだ。（中略）仕事をする人（つまり、変更の実装者）と仕事をすることを決定する人（つまり、変更の承認者）の距離が離れれば離れるほど、結果が悪くなることは、繰り返し実証されてきたことだ。(Kindle Locations 5616)
これは自分も実感があって、徐々に立場が上に押しあがっていく状況でも、現場というか、実際のソースコードを書く立場に自分を置こうとするのにはこういう感覚があると言ったところ。組織的には、上に立ったらレビューだけしていればいいのだから現場仕事は人にやらせないと、なんて話をよく言われるのだけど、それだとレビューが形式的で内容のないものになってしまう、形骸化されてしまうリスクがあるなあというのは思う。
Googleのコードレビューの対象分野は次の3つとのこと。
- 言語ごとのコードの可読性（スタイルガイドへの準拠）
- 一貫性と正しさを維持するためのコードサブツリーのオーナー指名
- コードの透明性とチームをまたがるコードのコントリビューション
(Kindle Locations 5704)
ちょっとここはわかるようでわからなかったけれど、可読性は一般に使われるスタイルの適用であるとかPythonならPEPのようなガイドへの準拠のような話で、オーナー指名のところは元をよくわかっている人をレビュワーにしましょう、最後のは他のチームも使っているかもしれない内容に土江は他のチームのリポジトリ等々へのコントリビューションも同時にしているかを確認しましょう、的な意味だろうか。原著をあたった方がいいかも。
John Allspawが新しく採用された若いエンジニアについて話したことについて考えてみよう。このエンジニアがAllspawにHTMLの小さな変更をデプロイしてもいいかと尋ねてきたので、Allspawは次のように答えたという。
「私にはわかりませんが、それでいいんですか。あなたは誰かにその変更をレビューしてもらいましたか。この種の変更でレビューを頼む相手としてもっとも優れた人は誰かご存知ですか。この変更が本番環境で設計通りに動作するという確信をつかむために、できることは何でもしてみましたか。もししたのであれば、私になど尋ねていないで、すぐに変更をかけなさい」
Allspawは、このように答えることによって、自分の変更の品質について責任を負えるのは自分だけだということをこのエンジニアに思い出させたのである。
この変更はきちんと動作するという確信を得るために、彼女ができる限りのことをしたのなら、誰かに承認を求める必要はなく、変更を加えるべきだ。変更の実装者が、変更の品質についてすべての責任を負えるような条件を作り出すことは、私たちが追求している生産的な高信頼マネジメントの文化を築くための重要な一歩である。さらに、このような条件があれば、全員が目標達成のために境界を越えて助け合うという未だかつてない安全な作業システムを構築することができる。(Kindle Locations 5871-5882)
ちょっと長いけど。
この逸話はすごく好き。できる限り自分もそういうチームを築きたいと思う。結局、取り組む各担当者が自分が当事者だという意識を持つことができると、これが問題ないと確信を持つためには自分は何をすると良いだろうかと考える方向に頭が回るという実感がある。
ポストモーテム（障害発生などの後の事後検証）で実施することは次の内容：
- 誤りを犯した人を罰しないようにしながら、さまざまな視点から障害の詳細な事実を集めてタイムラインを描く。
- 自分が障害の発生にどのように関わったかについて詳細に説明できる場を設けて、すべてのエンジニアに安全性向上のための意欲を与える。
- 将来同じ過ちを繰り返さないための方法を社内のほかの人々に教えるエキスパートになるように、誤りを犯した人々を励ます。
- 人にはアクションを起こすか否かを判断する裁量の余地がかならずあり、その判断のよしあしの判定はあと知恵だということを認める。
- 将来、同じような事故が起きないようにするための対応策を提案し、期限とフォローアップ責任者を決めてその対応策の実施記録をかならず作る。
(Kindle Locations 6007-6015)
意外とこういうのが難しいとは思ってる。責めたい気持ちがある。前にも言ったのにという思いが前面に出そうになる。でも、そこはチーム全体の学習機会だと捉えて、事後の検証を進めるのが良いというのは昔からある話だし、次にトラブルが起きた時にはこのページに戻ってくることになると思う。
また、ポストモーテムで記録する内容の例は次のもの：
- 問題が起きたのは予定されたインシデントのためか、それとも予定外のインシデントのためか
- ポストモーテムの責任者
- 関連するIRCチャットログ（正確なメモが作られないことがある午前3時の問題では特に重要になる）
- 解決のためのアクションとその締め切りが書かれたJIRAチケット（管理職にとって特に重要な情報）
- 顧客フォーラムポストのリンク（顧客が問題について苦情を寄せる場所）(Kindle Locations 6065)
事例の中のEtsyという会社は検索や保存、過去のポストモーテムのメモを使った連携が難しくなってきたことを受け、上記のようなフォーマットである程度簡易に利用できるようにした模様。
どこかに記載があったけれど、トラブルが起きたら過去のポストモーテムをザクっと調べて同種の時にどうしたかをすぐに出せるようにしている話もすごく良いと思った。新しくきた人もそれを読むと学びがありそう。
5 訳註：アメリカンフットボールのフォーメーションをまとめた本。(Kindle Locations 6242)
プレイブックという用語に対する訳註。プレイブックはこの5年くらいでよく聞くようになった単語のように思うけれど、語源はアメフトだったとは。スクラムもそうだけど、アメフトというのはチームプレイにおいて結構重要なスポーツなのかも。
出所：(Kindle Location 7626)
Some Myths about Industrial Safetyという研究の結果のまとめが書かれているもの。インシデント発生時にこれを覚えていないと、誤った方向に対策を打ってしまいそうという点で面白い内容だった。
最後にはNetflixのChaos Monkeyの紹介もあった。Chaos Gorilla（AZの障害シミュレート）までは知っていたけど、Chaos Kong（Regionの障害シミュレート）というのもあるんだな。
Chaos Monkeyもさらに細かく、Latency（意図的な遅延を入れる）、Conformity（ベストプラクティスに沿ってないインスタンスをシャットダウンする）、Doctor（ヘルスチェックに通らないもので修正が加えられないものはシャットダウン）、Janitor（未使用のものを削除）、Security（セキュリティ違反や脆弱性を持つインスタンスをシャットダウン）など色々とファミリーがある模様。
なかなか骨太な一冊だった。
サラッとは読めなかったけど、学びがあってよかった。これをベースの価値観にできるとチームとしては強そう。良本だったしおすすめ。