本記事は自分向けの読書メモとしての側面が強く、単語や歴史の細かい解説はしていません。
The DevOps ハンドブックとは
以下の書籍のことです
The DevOps ハンドブック 理論・原則・実践のすべて
DevOpsという言葉は開発(Develop)と運用(Operation)を繋げた造語として2009年に登場しました。
ネットの解説によっては「開発担当と運用担当が密に連携しながらシステム開発を行う手法」という解説がなされたりする場合があります。
本書を読んだら上記解説について「トヨタ生産方式＝カンバン方式」という説明と似ていて、DevOpsの極々一部しか説明していないなということが良く分かりました。また、DevOpsとかDevSecOpsとかそういう名称の議論も極めて表面的で結構どうでもよいと感じます。（個人の感想です）
DevOpsの本質は、ソフトウェアの分野でリーン生産方式（トヨタ生産方式）の原則を適用した開発を推進するための考え方と様々なプラクティスやマネジメント理論を体系的に整理したものです。（個人的理解）
本書は、そのDevOpsの理論や原則だけでなく、
最も難しい実践までをサポートする書籍です。
読んでみての感想
良著と感じました。
DevOpsの哲学が丁寧かつ体系的に解説されており、それをソフトウェアの分野で実践するにはどうすればよいか、具体的な方法が情熱的に解説されています。
また、ソフトウェア以外の知的生産活動にも応用できると思いました。
リーン生産方式(トヨタ生産方式)は知的生産活動にも適用可能であると直感的には分かっていても、具体的実践は難しいです。
ソフトウェアの事例を通してヒントを得られると思います。
開発プロセスや文化の話が多いですが、マネージャー級に限らず、立場関係なく全員が気づきを得られる内容に感じました。
GoogleにしろNetflixにしろ、DevOpsの実践により収益を上げています。
収益上げるため、自分の賞与UPのため実践しましょう。
ただ、この方式は非常にタフでストイックな在り様を求められますが。
内容メモ
感想交じりの個人的メモです。
深く理解するなら書籍の精読が必要です。
このメモから得られることは極めて表面的であると先に述べておきます。
背景と情熱と哲学を知らないと応用やアレンジは難しいと推察します。
DevOpsというものを解説する記事は大量に存在します。
私のこの記事もそれらと似たようなことしか書かれていないかも知れません。
1. 起こりがちな悪循環
・複雑でドキュメントがしっかりしていない
・脆いアプリケーションとインフラ
このような環境の中、逃げ道を作る仕事のやり方が当たり前になっている。
（”時間があれば”対応しますと言い続けている。しかし時間ができることは無い）
この状況が続いてしまうことで、数々の妥協と納期の問題による妥協の繰り返しが起き、技術的な負債が蓄積する。
負債の蓄積により、あらゆることが少しずつ難しくなり、全員少しずつ忙しくなり、仕事にかかる時間が長くなり、コミュニケーションが遅くなり、仕事のバックログが少しずつ多くなる。
コードは少しずつ密結合になり、小さいトラブルが大事になるようになり、コードの変更が怖くなり、仕事の手待ちが増え、業務推進に労力がかかるようになる。
こういうことはどこの企業でも起こる。
少しずつ進行するのでパッと見では悪循環の発生に気づかない
・・・という雰囲気のことが書かれています。
程度の差はあれども、身に覚えがあったり見かける状況です。
これはソフト開発に限ったことではないですね。
2. 理想の姿とは？
業績が良い企業は機動性と信頼性が高い
- 製品の変更を頻繁に実施する
- 製品の変更にかかるリードタイムが短い
- 変更しても不具合が出ない
- トラブルや不具合があっても高速に復旧する
- 生産性が高く、経営目標を達成する確率が高い。時価総額も高い。
上記は書籍のそれより少し一般化した書き方をしました。
急成長している企業を見ると、一定の改善速度と品質を持っていますね。
Ankerとかは良くあてはまりそうです。
テスラや中華EVメーカーは圧倒的改善速度で伝統的自動車メーカーを抜かそうとしています。
小まめに振り返りをしながら、今の仕事や製品を環境へ最適化(改善)させ続けることはとても大切です。
3. 第1の道 フローの原則
リーン生産方式（トヨタ生産方式）に則った仕事をするための方法が解説されている部分です。
私のこの読書メモでは、なぜリーンが良いかは論じません
リーンな開発を実践するための仕組みや方法に様々なものがあります。
そのうち、分かりやすいところを並べると
- 作業を可視化する
- 制約条件（ボトルネック）を解消する
- 仕掛数を制限する
- 仕事の単位を縮小する
- 受け渡し回数の削減
- 苦痛を取り除く（無駄を取り除く）
などです。基本通りです。
仕事を見えるようにして異常を見つけやすくし、
仕事のネックを見つけて原因を取り除き、
マルチタスクを排除することでスイッチングロスを減らし、
一つ一つの仕事を極限まで小さくして品質チェックとリリースを行い、
仕事の受け渡しを無くしてリードタイムを短縮し、
業務の無駄や辛い作業を排除して、メンバーのやる気を維持するだけでなく品質とスピードを向上させる。
当然、この状態に一足飛びで行けるわけないですし、究極の状態に辿り着くこともありません。
しかし、これを羅針盤として乾いたぞうきんを絞り続けることは可能です。
4. 第2の道 フィードバックの原則
後工程から前工程に対して、素早くコンスタントにフィードバックを返すことの重要性が語られている章です。
ここでもやはりモデルはトヨタ生産方式とそれを支える現場です。
現代のシステムは複雑怪奇で、完璧な品質を実現したい気持ちはありますが、現実的にはどんな企業も不具合を出します。つまり、完璧を実現するには人間の能力が不足しています。
こんな現実に対し、重要になってくるのは、
- 各工程の問題点が素早く共有される
- 問題が見つかれば全員で対処し、新しい知識を構築する
主にこの2点。
1つ目は、問題に気づいたら、すぐその原因を作った人に教えましょうという話です。
文字にするとあまりにも当たり前な話です。
教えてあげないと、何度も同じミスを気づかずやりますし、
素早く教えてあげないと「1ヶ月前のこと？覚えてないよ・・・」となり、学習できません。
2つ目は、トヨタ生産方式の「アンドン」のことです。
致命のトラブルが起きたとき、生産ライン全体が停止し処置に入るアレです。
すべてを止めることの大切さは書籍やトヨタ生産方式の本を見てください。
みんな新しい仕事を止めることで、問題解決の邪魔になる要因が入ってこないようにし、全員が問題を知ることができ、学習や対策が捗る。上流工程が下流工程を意識した仕事をすることにもつながる。
5. 第3の道 継続的学習と実験の原則
個人がコンスタントに知識を生み出し組織に転化していくための原則です。
これも製造現場をモデルにしています。
パフォーマンスが高い製造現場では、新しい改善のために日常業務の一部として実験をしています。
それと同じように、日々色々実験して、成功と失敗を積み重ね、うまくいくものを発展させ、さらにそれを他部署に展開しましょう。
さて、この実験ですが、実製品を実験台にできるでしょうか？
昔、私は製造分野にいましたが、量産の現場では結構やっています。
なぜ、それが可能なのでしょうか？
品質確認・監査がしっかりしているから・・・だと今は感じます。
品質が担保されていれば安心して実験できます。
システム開発で品質担保はできるのでしょうか？
前の方で書きましたが、自動テスト等を頑張っても完璧には至れません。
ということで、安心な実験のためには、本番環境の回復力を鍛える必要があります。
何が起こっても、最悪素早く復帰できるようにするため、シミュレーションや訓練を行います。
実験を通して得た知識を組織全体に共有する方法も大切です。
グローバルな知識を蓄積するメカニズムを作る必要があります。
読書メモは一旦ここまで。
さいごに
この記事をここまで読んでいただきありがとうございます。
ここまでで P87 までの内容です。（全部で487頁くらいの書籍です）
DevOpsの哲学について大切なところと思う点をメモとして書かせていただきました。
全体を通して、大変参考になるというか、とても影響を受けたように思います。
この記事を読んでいただいた皆様も、ぜひともこの本を手にとって読んでいただければと思います。
以上です。ありがとうございました。