海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

DevOps は組織や文化の話なのか?

DevOps は組織や文化の話なのか?

TL;DR

  • 畢竟そうなるけど背景を踏まえて理解しようね。

  • その前にいっぱいやるべき事を無視して DevOps!は違うんじゃないかな


DevOps 素晴らしいという話?

最近話題の DevOps

猫も杓子も DevOps

これからやりたい DevOps

みんな大好き DevOps

そんな DevOps の話

DevOps, DevOps ってなんだ。


宇宙刑事ギャバン

よく聞くこと

DevOps はツールやプロセスではなく組織や文化の話だというコラムをよく見る。

DevOps志向の組織づくりをいかに進めるか|IT Leaders

なんでそうなるのか?っていう整理がしたい。(イマココ)

DevOps の経緯を知る

例のハートマークこと必ず現れるいつものアレ。

www.slideshare.net

2009 年に発表

「毎日何回もデプロイしてるよ」

→ 「マジか」→そして DevOps ブームへ

そもそも 10 deploys/day の何が嬉しいのか

みんなデプロイ回数でお金がもらえる契約とか?

じゃなくて、早く Production で使いたいから

  • 作り出した価値を早期に獲得したい
    • どんなにカッコよく作っても本番で使われないソフトウェアに価値はないから。
    • 本番で使われるのを待ってる間に作ったモノの価値が下がる(ビジネス的な熱が冷める)
  • 正しいものを作ったのか、リリースしてフィードバックを早期に得たい。
    • それにより、思い込みで作ってしまうサンクコストを減らしたい。

だいたいこの2つ。要は価値収益の最大化とリスク低減に効果がある。

そりゃあやる価値あるよね、というのはわかる。

(ココがやる理由として腹落ちしないなら無理してやる必要ないんじゃないかな!)

(遅くていい理由で被害を被るのはビジネス側だからあんまり気づきにくいしね!)

バリューストリームマップの話

バリューストリームマップというものがある

元はトヨタかな?

www.itmedia.co.jp

全体を見てボトルネックを探すことができる。

リーンで目指しているように、ボトルネック以上のパフォーマンスはでないので、解消すべき最大のボトルネックこそが、カイゼンをする最優先箇所。

ボトルネックでない部分をカイゼンしてもトータルのパフォーマンスは上がらないから意味がない。

なんで DevOps がバリューストリームで課題になってきたのか

アプリはアジャイルになって、リリースがボトルネックになっただけ。

f:id:Bashiko:20190626020029p:plain

そこで DevOps とやらで、リリースの障壁を下げたのが元々。

リリースがボトルネックにならないように、DevOps ツールが増えてきた。

DevOps ツールの話

元々 DevOps で使われるツール群は昔からあったものが多い。Puppet とか。

この辺はサーバのコンフィギュレーションを効率化するための意味合いが強かった。

どっちかというと主目的はインフラ業務(ミドルウェア突っ込んだりとか)の効率化・自動化。今で言うところの RPA。

サーバに SSH して (またはデータセンターでひーこらいいながら) あーだこーだ構成するよりツール一発で出来た方が属人化しにくい。

更にはアプリケーションのデプロイメントだとか、クラウド時代に突入してからはインフラも含めた自動化がその延長で実現出来たので Happy になった。

ただ、これはあくまでインフラ屋さん・運用屋さんの仕事の効率化の側面がメイン。

クラウドでインフラ面の自由度が増えて、デプロイの戦略が多様化出来たので、リリースのリスクが減らせることにより、DevOps が進んだと個人的には思うけど。

もっとバリューストリームを広げて考える

f:id:Bashiko:20190626020704p:plain

こんなのが欲しい!から、コレよコレ、サイコー!(またはクソ)までの LT

欲しいと思うのをいかに早く拾えるか。

または、いかに間違いに早く気付けるか。

ここで大体開発チームだけじゃなくて、組織の壁が出てくる

職能性組織の壁、扱う言語の壁、聞いちゃいけない現状のプロセスや体制。

とはいえここに手を入れないと、早く気づく機会を失うので、組織を再編して、職能性ではなく、限りなくEnd-to-End で、Opportunity 獲得 → リリースまでを実現できる組織が必要になってくる。(Measure も必要だけど)

ちょっと感じる、大きめ古めの企業における組織文化の壁

これを進めると、作ったものの正しさをチェックする機能(いわゆるソフトウェアテストとか)ではなく、正しいものを作ったかという検査の機会を持ててしまう。

作る側だけではなく、依頼した側(こういう表現は好きではない)にも、強制的にフィードバックが働くので、投げっぱなしジャーマンスープレックスなビジネスサイドがそのフィードバックに耐えられるかどうかについては、実は文化的に超えないといけない組織は多い気がする。

まあそもそもそこに疑問を持とうとしない、言ったものが作られれば、それをユーザーが使っていようが使っていまいが興味がない、と言う組織であれば、DevOps を進めてバリューストリームの LT を削減せよ、と言ったプレッシャーもないはずだから、課題にもなりにくいかなとも思う。

まあ本来、スクラムでいえば PO が、プロダクトの成功を気にしない、なんてのはあってはならないのだけど。