DevOps の小説を読んだ感想
今回のお題はDevOpsです｡
よく聞くワードですし､もうITエンジニアには一般化されてるような気がしたんですが自分が本業として取り組むにあたってふんわりとしたイメージしか知らないなあ､ということで導入を兼ねてDevOpsを教えてくれる小説を読みました｡
ストーリーの大筋としてはデスマプロジェクトを指揮することになった主人公が会社のトップともやり合いながら､部門の壁を超えて連携する（DevOpsを構築する）ことで解決する､という流れです｡最近､小説もご無沙汰だったので読んでて面白かったです｡軽い感じでサクッと読めます｡
以下､心に残った点です｡
3つの道と4つの仕事
本書で提示されているDevOpsのコアバリューが3つの道で4つの仕事とは仕事を4象限のマトリクスに分割したもの｡
3つの道で示されている価値観というのは高速に価値提供して､フィードバックループを回し､よく実験してよく学ぶことの3種です｡一般的な価値観ですが､ソフトウェアのリリースを絡めてこれらの価値観を実現しなければならない点がDevOpsの難しいところでもあります｡
一方で4つの仕事とは平たく言うと7つの習慣に出てくる､緊急・重要のマトリクスのような分類の仕事を指したものです｡主人公は開発チームが作ったリリース用のソフトウェアパッケージをリリースするのですが､重要では無い急ぎの仕事や人的に依存したタスクなどで本来やるべき価値を生み出す仕事を全く進められない状態になっていました｡
この状況をDevOps的な部門を超えた連携と工場の生産管理をベースにしたリリース管理を行うことでなんとかしてしまいます｡
この工場の生産管理というのもうまい設定で､DevOpsの原点にはリーンの哲学があるといいます｡リーンとはスタートアップでよく使われる考え方で最小限の機能を提供するプロダクトを顧客に提供し､そのフィードバックを元に方針を少しづつもしくは大きく変えながらサイクルを回して価値を生み出していく考え方です｡リーンのベースはトヨタ生産方式にあり､この書籍ではリーンの概念を飛ばしてDevOpsと工場の生産管理を結びつけて表現しているのが面白いところです｡
devopsの目的
devopsがリーンやトヨタ生産方式を原型にしているとは書いたんですが、その目的は3つの道以外にも開発コストの回収も含まれます。
一回ごとのリリース期間を短期間化して高頻度のリリースサイクルを回すことで一リリースで回収すべきコストが分散される…とされています。開発が長期間化すれば人件費もその分かかるので分かる話です。
開発視点でもビックバンリリースと言われるような変更量の多いリリースはバグが含まれやすく、その原因追跡も変更量の多さから難しくなるとされています。
具体的なデプロイ頻度
これは具体的に書籍にも登場していて一日20回のデプロイを目指すように書かれています。
この1日20回という頻度は個人的にはハードルが非常に高いなーと思いますが、ここはプロダクトの種類やチームによっても異なりそう。
それよりも気になったのはそんな頻繁にデプロイしてたらQA工程が追いつかなくないか？ということ。 これに関しては自動テストで代替したり、フィーチャーフラグを立ててステージングやプロダクションでは機能のオンオフを変更するんだそう。ここも開発チームの特徴が出そうなポイントだと思います。
その他
書籍から離れた話。
devopsの立ち位置
結局devopsがなんなのかというと、ソフトウェア開発（saas）でリーンを実現していくための哲学や方針といったかなり抽象度の高い概念だと思いました。
devopsが掲げる目標を実現する手段としてCICDとかアジャイルとかオブザーバビリティなどがある、感じですね。
devopsは哲学ということでdevopsを学んだだけでは中々devopsの実現は難しいのですが、普段CICDなどを触ったりしてる身からすると「why」が知れたのは収穫でした。
今回は小説でdevopsの触りだけ知ったので、今はリーンスタートアップやトヨタ生産方式などのdevopsの背景的な情報を取得しつつ、SRE領域のdevopsを実現するHOWも学習しています。
