この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、AWS事業本部コンサルティング部に所属している今泉(@bun76235104)です。
皆さんはDevOpsを実践されていますか？私は1年くらい前から真剣にDevOpsについて考え始めて、いくつか書籍を読んだり、輪読会に参加してきたりしました。
技術的にはまだまだ未熟な私ですが、何人かのエンジニアの話を聴きながら、自分なりにDevOps的な思想のとっかかりくらいは掴めてきた気がしますので、私なりの考えをご紹介させていただきます。
なお、 Effective Devops の書籍においては 書中のなかで「devops」と表記しているため、引用箇所などは小文字表記として、 それ以外は「DevOps」という表記にしております。
前置き
本記事は以下技術書・専門書の内容を一部抜粋し、私なりの解釈などを付け足させていただいております。
Effective DevOps
私はオライリーの技術書に多少苦手意識があったのですが、こちらは比較的読みやすかったです。
具体的なツールや方法論というよりも、DevOpsの根本的思想や、組織としてどのような点に注意すべきかなどを書いてくださっています。
The UNICORN PROJECT
こちらは、物語形式で、一人のエンジニアが開発現場に絶望し、徐々に協力者を増やしながら、DevOpsを実践していく過程が記載されております。
非常に読みやすく、またエンジニアとして共感するポイントも多く、初めて読む方にもおすすめの書籍となっております。
The DevOps HandBOOK
上記「The UNICORN PROJECT」と同じ作者が書かれています。
The UNICORN PROJECT で登場した人物が書いた本として位置付けられているため合わせて読むことで理解が深まりました。
ドラゴンクエスト ダイの大冒険
リーダブルコードなどに続き、DevOpsエンジニア必読書(一部界隈除く)と呼ばれている名書です。
こちらの技術書は、30年以上前に刊行されたにもかかわらず、今でも非常に人気のある書籍となっております。
とはいえ、技術的なことは書いておらず、我々エンジニア(というより人間)が困難に見舞われた際にどのようなメンタルで望むべきか。
などといった内容が記載されており、上記書籍を読んだ後に この漫画 この書籍を読み直すことで、DevOpsに対する理解が深まった気がします。
そもそもDevOpsとは何か
EffectiveDevOpsによると
devopsはものの考え方であり、仕事の進め方である。
と冒頭に記載されております。 (その他文化運動だとかいう言葉でも紹介されております)
始まりは、組織全体のエンジニアリングとしての課題として、Development(開発)とOperation(運用)との対立を無くすことを目的に作られた造語のようです。
今となっては、運用だから開発だからという対立は昔ほど感じないのですが
例えば
- セキュリティルールを守らせる必要のある情シス部門 vs 自由に開発したいエンジニア
- 各種手続きに事前レビューをする必要のあるコンプラ部門 vs 早く開発したいエンジニア
などと置き換えればわかりやすいかと思います。
私個人としては、「単に運用と開発を同じチームにする」とか「特定のツールを使っているからDevOpsをやっている」 という単純なものではないのだと思いました。
よくわからないので、引き続き上記書籍のエッセンスをみていきます。
DevOpsを実践するために大事な考え方
上記書籍では、DevOpsの取り組みを成功させるために、組織があるべき理想的な状態・方法論について語られています。
- Effective DevOps では 4本柱
- コラボレーション
- アフィニティ
- ツール
- スケーリング
- The DevOps HANDBOOKでは 3つの道
- フローの原則
- フィードバックの原則
- 継続的な学習と実験の原則
- The UNICORN PROJECT では5つの理想
- 局所性と単純性
- 集中、フロー、楽しさ
- 日常業務の改善
- 心理的安全性
- 顧客第一
これらは、各書籍でコンテキストやスコープが違うにしろ、根本にある考えや思想は似ているものだと私は理解しています。
そのため、 Effective DevOpsで述べられている4本柱を例に、どのような点に留意すべきか考えてみました。
効果的なdevopsのための4本柱(Effective DevOpsより)
コラボレーション
ざっくり言うと、個々人に才能・個性を発揮してもらって、うまく協働することが大事だよということだと思います。
Effective DevOpsでは以下のように留意すべき点などについてまとめてくれています。
- 効果的なコミュニケーションを行うために注意すべき点
- チームの中に不満を感じている人がいるならば、原因は？
- 技術的に優れているが、人間的に問題のあるエンジニアの採用・進退について
- etc
同書籍では、以下のように記載されております。
devopsの取り組みを成功させることの大部分は、突き詰めればそれぞれの人たちが以前よりも効果的に共同作業を進められるようにすることだ。
devopsは技術を重視したものだという印象を持つ人たちにはわかりにくいかもしれないが、devopsのもともとの目標は、2つの異なるチームに属する人たちを対話させることだった。
要するに、個々人の才能・個性・得意分野を生かせる環境づくりが大事だということなのだと思います。
ダイの大冒険でも、最初ポップという仲間の魔法使いはすぐ逃げるとても嫌なやつでしたが、仲間と対話・冒険を重ねていくうちに、自身の「勇気」という才能を開花させ、最終的には敵組織の幹部から「真っ先に始末しておきたい男」と評され、敵組織の親玉からも恐れられる存在となります。
当初一見能力が低いと見られるポップも師匠・仲間、魔法使いが活躍するべきフィールドを与えられることで、才能を開花させることができました。
そもそも組織に属する人間が求められることは「個々人の長所を生かして、組織としての目標達成に貢献すること」のはずです。
そう考えると、DevOpsも情報システムも組織としての目標（売上など)を達成するためにあると言えるのでしょう。
手動による作業を減らし、エンジニアがもっと生産性の高い作業に集中し、良い情報システムを作り続けることで、組織としての目標を達成する重要性をUnicorn Projectでは説かれています。
要するに デプロイの自動化・作業の自動化そのものがDevOpsというのではなく、「多くの人が本質的な作業に集中できる環境を継続的に作っていくこと」がDevOpsの根本的な思想なのではないかと思います。
ダイの大冒険では、勇者であり、敵組織の親玉を倒すことができる可能性のある主人公ダイに目的に集中させるため、ダイの師であるアバン先生は以下のようなことを話しています。
「すべての戦いを勇者のためにせよ・・・・・・!!」（略)これからの戦いは「ダイ君をいかに無傷に近い状態で大魔王の前までたどりつかせるか」にかかってきます。私たち仲間はその1点にすべての力を注がなければなりません。（略）」
このように個々人にはそれぞれ個性・才能があるため、その人の力を発揮してもらえるための環境づくりがDevOpsの真価なのではないかと思いました。
アフィニティ
私はこの単語の意味がよくわかりませんでした。
辞書的な意味では「密接な関係・婚姻関係」という意味があるそうです。
要するに、「チーム内の個人間の結びつき・信頼を高めて、より良い組織を作っていくことが大事だよ」的なことが書かれているのだと思います。
- チームの文化を作っていくこと
- 多様性のあるメンバーを集める
- 採用時に注意すべき点
- etc
言うまでもありませんが、ダイの大冒険でも最初は勇者ダイと魔法使いのポップからはじまった冒険も、仲間を増やし、それぞれが協力することで物語が進みます。
最終的には、パーティメンバー(仲間内)に留まらず、あらゆる国同士が協力し合うことで、魔王軍討伐という大きな目標を達成することができたのです。
正直、この分野に関しては抜粋できないくらい名場面が多いので、詳細は割愛させていただきます。
ツール
要するに、ツールはあくまで、組織の文化・目標に合わせて選ぼう。ということかと思います。
「いけてるから」「流行っているから」「他の会社で上手くいっているから」などの理由で選定するのは危険だよというようなことが書いてあります。 (もちろん、技術を使うコンテキストによります。さっくり試すときは上記のような理由で十分だと思います)
これは最もなことであり、システム開発のためのツールと言えるプログラミング言語の選定も求められる要件で変わってきますよね。
最近では自社としての標準とする技術を定める会社も増えてきたように思えます。
ツールは良くも悪くも文化に影響するため、存外馬鹿にせず、きちんと理由を持って選定する必要がありそうですね。
聖書 ダイの大冒険でもツールの重要性について言及されており、なかでも主人公ダイの武器探しの話がそれに該当するかと思います。
ダイは竜の騎士というとても力のある存在であり、自身の力を本気で発揮してしまうと並の武器ではすぐに破損してしまうため、自身の力に耐えられる武器を探していました
その間、とある国家の都市を敵組織に襲撃され、仲間や大事な人が危機にさらされてしまうことになります。
ダイはその間、心配になり、武器の完成を待たずして、仲間のところへ向かおうとしますが、仲間を信じ武器の完成を待ちました。 (目先ではなく、大局をみてやるべきことを選択した)
それにより、ギリギリのタイミングで武器が完成し、ダイが存分に力を振るうことで一都市の危機を救うことに成功します。
我々も仕事をする上で妥協が必要なタイミングがありますが、重要なツールの選定には気をはらいたいものだと痛感させられました。
スケーリング
システム的なスケーリングだけでなく、組織としてスケーリングし、さまざまな障害を乗り越えていくために重要なポイントなどについて書かれています。
例えば以下のような点について
- 顧客ベースの拡大・収益の拡大・プロジェクトやチームの拡張などに対して、スケーリングするための組織の構造
- チームとしてのスケーリング
- 採用
- 下請けの利用
- 社員の定着
- 文化と文化適合性
DevOpsエンジニア的な文脈で「スケーリング」と聞くと、どうしてもシステム的なオートスケーリングなどを想像してしまいますが、組織がスケーリングするためにも柔軟な構造を作る必要があるようです。
組織が成長すると、考えもなしにチームを大きくしてしまうことがある。しかし、大きなチームでは知識を共有したり、同僚から互いに自由に学び合ったりするのが難しくなっていく。チームのメンバーそれぞれの得手不得手が把握できなくなると、ワークロードを柔軟にこなせなくなってくる。
理想的なチームの人数については、その時々のコンテキストにより大きく変わってきそうですが、Effective DevOpsでは以下のように述べられています
1970年代になって、J・リチャード・ハックマンとニール・ビッドマーは、ハーズバーグの動機付け精神論にもとづき、グループの最適な規模に関する調査を行った。(略)この調査に基づき、彼らはグループの最適な規模は4.6人と結論づけた。あなたのチームの規模もできる限りこの数値に近づけるようにすべきだ。ものごとを同意に基づいて決定することが多い場合には、3人とか5人といった奇数のメンバー数を選ぶと良いだろう。
とあります。
そう、ダイの大冒険の主なパーティー人数に近いですね。
初期: ダイ、ポップ、マァム
中期: ダイ、ポップ、マァム、クロコダイン、ヒュンケル
スケーリングを意識したチーム人数を考えるのにすら、ダイの大冒険がお手本になると言えます。
これらを通してわかったこと
DevOpsとは、「自動化をすること」「あのいけてるツール(サービス)を導入すること」ではないようです。
Effective DevOpsには以下のような記述があります。
devopsは単なるアジャイルなのか(略)devopsはアジャイルの原則を取り入れて、それを発展させたものであり、開発プロセスだけでなく組織全体が適用の対象となる。
以上から、「DevOpsはエンジニアがすること」とも違うようです。
私としては、「みんなの良いところを引き出すために、いらないものを省き、もっと組織がすごくなるための考え方です」というくらいが広義の意味のDevOpsにマッチするのではないかと考えました。
つまり私のこの考えで言えば、DevOpsにとって重要なことは、大概ダイの大冒険に書いてあるということになります。
最後に。ダイの大冒険はいいぞ。
ということで締めくくらせていただきます。
12
