bon now

DevOpsの定義を改めて調べようと思ってググったら以下のQiita記事を見つけた。
「DevOps」を全く知らない人のために「DevOps」の魅力を伝えるための「DevOps」入門-Qiita

冒頭から耳の痛い言葉だなーっていう。「（Opsが）他メンバーの修正を上書きして消してしまう」とか「開発環境では動かない」とか。あれ？書いてあることと違うなぁ。。 これはそもそも僕がOps側ではないので、DevOpsがないことの痛みを開発側の視点で経験しているからである。 ちなみに僕は前職、現職ともにちょっとばかりDevOpsに片足を突っ込んで開発プロセスをめちゃくちゃにするっていう仕事を任されている。 そういった立場から、DevOpsが本当に機能しているかどうかを客観的に示す完成度みたいなのを書いてみようと思う。

アジャイルでDevOpsができると思うな

前職は完全SIerだったし2010年ちょい過ぎみたいなものだったのでまだまだアジャイルがSI現場に浸透しきってない頃だったこともあり、 DevOpsはウォーターフォールの一貫として取り入れるか、なんちゃってアジャイル(と言う名の保守作業や軽微な改修案件)に対して環境を自動で作るみたいなところで使われていた。 というのも、巨大な案件でない以上あまりDevとOpsが別れてることがないてのと、Opsはお客さん側のタスクという場合もあり、 本番環境やステージング環境でさえDevOpsのサイクルを回す機会そのものが比較的少なかったんじゃないかなと思うからである。 あとこれもそもそも論で、巨大なエンタープライズシステムをDevOpsに合うアーキテクチャに直すのが難しいっていう問題もあるにはあったと思う。

現職ではアジャイルを開発プロセスに取り入れつつDevOpsを実現するためにCIツールを入れたり、DockerやKubernetesを導入したりした。 これでDevOpsはアジャイルとともに完璧だ！と、そう思うことは早計だったのだ。

つまるところ、アジャイルとDevOpsは全くと言っていいほど関係ない。これについては以下のWebサイトが僕の代わりに丁寧に説明してくれている。
Agile Vs. DevOps: What’s the difference?-guru99

アジャイルは「顧客(社内開発では広義にステークホルダーで良いと思う)と開発者」のギャップを埋めるもの、 DevOpsは「開発者と運用者」のギャップを埋めるもの、ということである。 つまり、アジャイル開発手法を取り入れたところで、DevOpsがちゃんとうまくいくなんて保証はどこにもないのである。 結局エンジニアから遠い位置に運用者がいる以上、DevOpsなんて以心伝心よろしく、うまくいくわけなんてない。阿吽の呼吸？それができるなら一生涯のカップルにでもなりましょう。

てめぇのCI、ちゃんとOpsは理解してるんか？

エンジニア(Dev側)が一生懸命自分たちの生産性と保守性を向上させるためにシステムの構築や検証で手作業じゃなくても良い部分を、 CIツールを導入して自動化していくっていう流れは至極当然でありかつ現代では必須のプロセスである。 もちろん、多くの場合はこのCIツール導入段階で、開発環境へのデプロイ自動化を取り入れることにもなるだろう。 じゃあ、その開発環境を運用するのは誰だろうか。

ひとつは開発環境も運用者がやる場合。もうひとつは開発環境は開発者が運用する場合の2通りが少なくとも存在すると思う。 後者なら、開発環境とそれ以外の環境は完全に分離されていることが前提になっていて、なおかつ開発環境以外の環境はすべて運用者が面倒をみる、と言う状況だと思われる。 でもこれって、結局DevとOpsの距離感を遠ざけているだけじゃないのだろうか？別の表現をすれば、役割が組織分断されている状況であり、従来と何も変わらないのではないだろうか。 つまり、DevOpsっていうのはDev側の夢じゃないのかな？というのが僕の所感。
また、前者の場合はもちろん開発者が一生懸命イジイジしたCIの仕組みやそのプロセスに、Opsが理解を示してくれているに決まってるよね。え？そんなことない？ じゃあDevとOpsは、一体なんのためにCIを作ったの？？なんのコラボレーションもないCIに、自動化した以外の価値なんて生まれない。それ以上スケールしないのである。 組織が大きくなろうがOpsが方針を変えようがDevが途中で飽きようが、そのタイミングで終わりなのだ。継続的インテグレーションをもし実践しているというのなら、 どこが「継続的」か答えられないのであればそれは絵に描いた餅システム、別名自己満足ツールに過ぎない。

身勝手の極意

本番で動かないソース、性能問題を抱えたソースは運用者の手によって書き換えられる。 それはまるで無意識下でSLAや製品品質を担保しようと体が勝手に動くかのように・・・。

Ops側の権限が強くなるのは理解できる。運用は顧客の生命線だからだ。開発が一発失敗したところで、ダメージを与えるのはせいぜい検証環境くらいだし、 本番でもしトラップカードが発動したとしてもOpsの面々が生け贄となってダメージを被るわけで、エンジニアとしては精神的ダメージ以外特に発生しないのである。 ということでOpsの力によって平和が保たれるのであれば、個人的にはシステムを預けても問題はないと思う。

問題があるのはDevOpsという立場での話だ。 DevOpsは誰もが見てわかるように、DevとOpsが手を取り合って回るサイクルである。 片方の権力によって片方の何かが潰されるような状況下において、本来の目的が達成できるとは到底思えない。 このギャップを埋めるのはコードでもツールでも技術スタックでもなく、コミュニケーションだ。 先程アジャイルとDevOpsは全然違うと述べたが、それは解決するポイントの違いであり、本質的な部分は同じである。 アジャイルが顧客とDevの対話や折衝によるコミュニケーションを重要視するように、DevOpsもDevとOpsのコミュニケーションを重要視するのである。 DevもOpsも今はまだ人間である。プルリクや議論などでコミュニケーションを図らなければ、目的や目標を同じ目線・向き先にすることは難しい。 お、ここでも阿吽の呼吸？できるならDevOpsいらないですよね。

ここまでの流れで言えることは、Dev側で一生懸命進めてる継続的CIに横からOpsたちが「自分たちの運用のためだもの」という理由でソースを書き換えまくる行動が、 僕には正しいDevOpsだとは思えないのである。なぜそれを構築前段階で協議できなかったのだろうか。それはすなわちコミュニケーションに問題があると言わざるを得ない。

身勝手の極意は、体と心・・・いやDevとOpsの意思疎通が難しいのである。

徹底的に巻き込む

そういう失敗を経て僕が今後心がけようと思っていることは「関係する人を早い段階で巻き込む」ということだ。

僕がやってた仕事で、それはほぼ僕1人が色々検証していたんだけど、あるときふと「自分だけでやってたらあとから自分にすべて押し付けられるに違いない」と思い、 工数とスケジュールの問題で(余力はあったが)人員を追加してもらったというものがある。 これの主な目的は「知見を別の人にも共有すること」、「自分にあとから降りかかるであろう災厄を今のうちに減らす」、「興味を持つ人を増やす」みたいなもので、 僕が表に出してたのは単純に「人が足りない」という点だけではあった。 けど、顧客に提供するシステム規模のエンジニアリングってだいたいはチーム作業を伴うので、 一騎当千の強者でない限りチームワークで作業の質や量を倍々にしていくしか方法はない。 だからこそ1人でも「これはやりがいのあるものだ」とか「自分がやらなくちゃいけない」とかいう当事者意識・情熱を注げるような仕事にしていくことは必要だと思うのだ。

それを実践するには、まず自分のやってることややってないことに人を巻き込むことを考えなければならない。 方法はいくつもある。上司に言う、仕事を丸投げする、相談のついでに仕事させる、打ち合わせのついでに作業をさせる方向に誘導するなど……。 人によって「火の付く方法（やる気スイッチ）」が違うので、そこをどうするかを考えるのもまた1つの仕事である。

DevOpsも行き着くところはそこであり、DevもOpsもそれぞれが「俺たちのシステムをもっと良いものにしよう」っていう共通した想いが、 初めて輪になって継続的ななにかにつながっていくものだと僕は思っている。

まとめ

• おまえら仲良くDevとOpsやってる？やってなかったら問題は往々にしてコミュニケーションだよ
• システムの面倒をみる組織は環境によって差がある？あるならDevOpsで徹底的に見直したほうがいいよ
• Ops側の権限にDevが負けてない？そうなら対等になれる仕組みを作らなきゃだめだよ
• 一人で頑張ってない？誰かを巻き込んで、少しずつチーム作業であることにみんなの意識を持っていくこと
• 阿吽の呼吸？あるならDevOpsいらないから早く次の改善に取り組もう