DevOpsはエンタープライズからスタートアップへの横恋慕 #devops #プロダクトマネージャー #leanstartup

DevOpsはエンタープライズのスタートアップへの憧れ

と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ？そもそもあってるっけと思いFacebookストーキングしたら違ってた。

"DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん

と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。

自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下（Dev部門、Ops部門、ビジネス部門、...and so on）においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近のDevOpsブームの前提が色々としっくりこないことがあったが、やっと先日のPoppendieck夫妻とMSの牛尾さんのバリューストリームマッピング研修に出たことで腹落ちした。実際はその研修の内容とはまったく関係ないのであるが、Maryの一切ブレないリーンの本質の部分に触れることで、よいキッカケをもらえたことに感謝している。

ちなみに私はDevOpsを以下のスコープ及びニュアンスで理解してる。勝手に理解してるだけなのでみんなの心の中のDevOpsを否定するつもりは微塵もない。TPSをみたり、リーンを学んだりでその流れでDevOpsを見てしまっているので、DevOpsというよりは、単純にリーンにバリューストリームを全体最適させる目線が強いかもしれないが。

• 広義
  「コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践」
• 狭義
  「DevOpsは高品質を保ちつつ、システムに変更をコミットしてから、その変更が通常の本番システムに組み込まれるまでの時間を短縮することを目的とした一連の実践である。」
  （こちらはDevOpsの教科書という本での定義である）

DevOpsのスコープとリーンスタートアップの仮説検証サイクル

私自身が、リーンスタートアップスタイルの仮説検証型でずっと新規事業をやってきた流れが強いので、そこからDevOpsに光をあてて理解していくのがとっつきやすいと思い、このような図になっている。小さくてわかりにくいかもなので補足すると、図の下部にある○の連なりは、IDEAS->BUILD->PRODUCT->MEASURE->DATA->LEARNと書いてあります。よくあるリーンスタートアップでのBMLループである。

狭義と言った部分が、すごくざっくりいくと赤い部分(BMLループのBuild部分)で、広義といったのが青い部分(BMLループ全体)になる。同時に赤い部分はエンジニアが直接結果をコントロールできる範囲であり、青い部分は利用者・ユーザの行動を介すことで結果に不確実性が伴う部分でもある。リーンスタートアップ等の仮説検証を効率よく回すという目線でみると、赤い部分はあくまでもBuild部分の最適化であり（一部Measureも入ると思うが）やや、狭く感じる。やりたいことは青い部分の仮説検証サイクルの高速化である。ここが新規事業畑だった自分が感じた違和感だった。赤い部分だけをDevOpsとして最適化しても、結局のところは、仮説のスジが悪いことでゴミを作り続けて出荷するムダ、また、良いものを作ったとしても、マーケのミスでユーザに届かないというムダが生まれてしまうのである。

シード期やアーリーステージでのDevOps

開発部門、事業開発部門みたいなような組織デザインではなく、ハスラー、ハッカー、デザイナーのようなチームで始まるド新規なサービス開発の場合。自分たちの持ち出しもしくは会社であれば少額のバジェットで開始するにあたり基本的にバーンレートが重要になる。 思い込みによるフルスイングでバーンレートを最大化させることよりも、小さく仮設検証型でやり失敗を小さくして学び効率を最大化させ、バーンレートを下げるスタイルとしてリーンスタートアップがある。 つまりは、ゼロから何か事業、サービスを始める場合においてバーンレートを下げつつ学びを最大化させようとすると1つの手段として仮説検証型になることになる。（起業家の嗅覚でフルスイングして、大当たりするケースもあるので、これは個人の自由である。）

仮説検証ベースの場合、価値観として最小工数で最大の学びが得られることが大事とされるため、極論、作らない。作るとしても表面だけで裏側のアルゴリズムは人力で回すとかになる。それでユーザーが価値を感じれば（コンバージョンすれば、継続利用すれば）あとから実装すればよいのである。いわゆるMVPによる実証である。 そんな感じでシード期は過ごすわけで、そこでその価値観に染まると、徐々にユーザーが増え始めてきてアーリーステージになり、シリーズAの出資を受けるフェーズになった際にも、仮説検証がベースのエンジニアリングになっている。

例えば、ある新機能をリリースする場合、新機能のリリース日から使い始めたセグメントの継続率と、従来ユーザの継続率の比較をするケースがよくある。継続して利用されるということは少なからずユーザに何らかの使い続ける理由があるのである。つまりは、ユーザの課題をいずれかの形で解決している状態である。Problem-Solution Fit（PSF）といわれたりする。（余談ではあるが、結婚指輪のECをやるような場合は継続されると気まずいのでここはビジネスモデルによる部分ではある。）

そこで真っ先に入れることになるのがコホート分析である。

ここでのコホートは、新規利用開始日のコホートになっており、使い始めた日毎にユーザをセグメントしており、その毎日の継続率を示している。そのため、ユーザ獲得キャンペーン等を実施した日に他のリリース等の他のイベントを行わなければキャンペーンの本当の効果を測定できる。

しかし、この運用だと問題があり、毎回ユーザ全体に新機能をリリースすることで既存ユーザへの影響というリスクが発生する。毎回、機能追加が成果があるならよいものの大半は失敗する。そのため、最初は一部のユーザにのみリリースして実験したくなるのである。その結果フラグが必要になり結果的にFeature Flag運用になる。（既存と新規機能のA/Bテストの場合もある。） 結果として、自然とDevOpsのプラクティスとしての文脈ではなくFeature FlagやFeature Toggleベースの開発を行うのである。（ここでのFeatureFlagは本番へすべてのコードリリースの文脈ではなく、ユーザー毎の機能の出し分けON/OFF文脈である。） よくあるケースとしては、外部のSaaSを使うケースである。OSSもたくさんある。CookpadさんのChankoは有名である。他にはここらへんのサイトを見ておくとわかりやすい。 また、同時にユーザーのセグメント機能も実装することになる。そのセグメントに対してFeature Flagをオンにするために。 例えば、開発チームメンバだけに公開、次に、自社メンバ、次に、全体のユーザの数％のみとなる。 昨年度、協業して自分自身もエンジニアとして参画していた99designsでの実際のFeature Toggle運用はブログで公開されているので参考に載せておく。基本的にセグメント切りおよびオンオフはAdminコンソールにて行う。

また最近でいうとFirebaseがmBaasとして提供している機能郡とかも、非常に親和性は高い。
・Remote Config x Analytics（ユーザセグメント）で機能の出し分け
・上記結果をAnalytics（コホート分析）でセグメント単位で効果検証

https://firebase.google.com/docs/remote-config/

ここらへんのセグメント化 x 機能出し分けによる仮説検証は、アーリーステージにおいて、DevOpsのプラクティスとしてよくある各種自動化よりも先に実施される感覚がある。このフェーズであれば、部門もわかれておらずその場で会話すれば解決するようなピザ2枚状態だし、システムも重厚長大ではないため、そういう順序でも問題がないかはおいといて結果的に現場のオペレーションが回る。（重厚長大ではない状況で、先んじて諸々自動化しておくことが大事なのはわかっているが話が混ざるとシャープではないので振り切って話すことにする。また、現場の毎日が文化祭前夜感を経験している人にはビジネス価値 > 負債量産の状況はわかるはず。）

そういう意味で以下の牛尾さんのスライドにある主要なプラクティスとサブプラクティスの優先度がサービスをゼロからグロースさせてくると自然と一部プラクティスが逆転していたりする。DevOpsにこれをやれという絶対はないものの、通ってくる文脈によって導入するプラクティスの位置づけも優先度も変わるというのは当たり前といえば当たり前であるが面白く感じた。

https://docs.com/ushio-tsuyoshi/5912

アーリーステージでのエンジニアリングの優先度として、コードベースが複雑でなかったり、実験なので破棄することもあるため、細かい自動化による小さなムダの排除よりも、そもそも使われないモノを作らないことであったり、作ったものがちゃんとターゲットユーザに届く(認知される)ことであったり、ユーザが途中で離脱しないことであったり、そちらにパワーを割いたほうがトータルでムダが少なかったりするケースが多い。そこで、結果的にDevOpsとか意識せずFeature Flagだったり、仮説に基づく開発（運用環境でのテスト）が行われる。（サービスを安定運用させるために、自動スケーリングさせたり、パフォーマンス監視だったりは当たり前でやるとして。）

DevOpsが見る夢は、ワイワイやってたあの頃への回帰

最近DevOpsが語られるときには、エンタープライズDevOpsであり、基本的に負債や重厚長大なプロセスを持った組織の改善という文脈が多いが、そうじゃなくオーガニックに組織が成長していく過程だと上記のように、また違ったアプローチでDevOps（のようなものを結果的にやっていく）していくことになる。そこが個人的には今まで本やウェブ上の記事で感じていたギャップなのかもしれない。

冒頭にも書いたが、今回、Poppendieck夫妻の研修に参加し、組織やプロセス、技術に対してリードタイムを如何にさげるか、リソース効率ではなくフロー効率をいかに高めるかを考えるようになり、そこら辺がクリアになった。クロスファンクショナルチームとかスモールチームとかよく言われるがそれはあくまでフロー効率を最大化するための一つの手段なのである。

DevOpsが目指している本質は、「何かあったときに会議なんかせずに席の周りにみんな集まってその場で議論して進められてたあの頃に戻ろうよ」ということなんだなあと。 例えばアジャイル（スクラム）で"開発チーム"があの頃に少しは戻ったとしても、それだけだと不十分で、インフラ、ビジネスサイド、営業、みんなでワイワイやってたあの頃に戻りたいんだろうなあと。

まさに、"DevOpsはエンタープライズからスタートアップへの横恋慕"である。

結果的には「コンセプトをキャッシュに変えるフロー効率及びリソース効率を最大化する一連の実践」である。

あの頃に戻るためには、いきなり戻ろうとするのではなく、今まで作り込んできた組織構造上のムダ、アーキテクチャ上のムダ、プロセス上のムダ、そしてそれらが複雑に絡み合った状態をほどいていく必要がある。（そういうふうにエンタープライズ下でのDevOpsでは考えるようにしている。）

そこで一つの取っ掛かりになるのが、散々語られているがバリューストリームマッピング(VSM)による現状把握と改善である。 VSMによる改善を回すと、真っ先に現場レベルでできることは基本的に自動化であり、その次にボトルネックはどうしても組織構造に移る。 その文脈の中で、様々な記事や文献でいわれているように、以下のような組織、プロセス、アーキテクチャのリファクタリングが伴う。そのため、VSMによる改善活動を行う場合は、権限を持っている人の同席が必須である。

• 組織デザイン
  
  • 権限をチームに与え、クロスファンクショナルでスモールチーム化：スタートアップ回帰
    
  • 責任と自由（権利）について
    
    • どこかは伏せるが自分が近くで見てきた例としては、売上を上げている単位のサービスでチームをわけて権限委譲＆下記のマイクロサービス化をしていた事例がある。
      
• アーキテクチャ
  
  • スモールチームで回せるサイズ（例えばマイクロサービス）：スタートアップ回帰
    
    • どこかは伏せるがMSAにするのに15ヶ月かかってるのを見ていたりもするのでこれは大きな経営判断を伴う。
      
• プロセス
  
  • 人による承認のようなゲート方式からパイプライン方式へ：スタートアップ回帰
    

そして、その結果チームは本当の意味での継続的デリバリーを手に入れることになる。

以下は、昔、夏サミで発表したスライドであるが、このときの内容はDevOpsとしてではないが、太字部分は結局DevOpsプラクティスで得られる効果そのものを指していたりする。

http://www.slideshare.net/i2key/devsumi-natsumic7

「あのころ」に回帰したチームにおいて、プロダクトオーナー/プロダクトマネージャーはmini CEOである

クロスファンクショナルなチームにおけるチームの責務はサービスのグロースであったりビジネス上のKGI/KPIの達成であるため、組織体としてもスタートアップのような何かである。エンタープライズ型の重厚長大なプロセス、セクショナリズム、アーキテクチャ上の制約が仮になくなれば仮説検証を行うサイクルタイムは今までよりも早くなり、仮説を市場に問うリードタイムは最小化される。

それとともにプロダクトマネージャーの役割もスタートアップ帰りが起こる。DevOps関係なくそうだとは思っているが、DevOpsが機能しだすとより顕著である。 そして、馬田さんがPM = mini CEOとよくいっているがまさにそれである。

http://www.slideshare.net/takaumada/zero-to-product-manager

ここで一つ問題になるのが、お金である。 エンタープライズの場合、スタートアップのように都度資金調達していくスキームではなく、例えば、年次予算を組んで事前に計画を立て、その目標へのコミットとして翌年の予算が決まるモデルが一般的である。つまり、1年以上先の未来を予測＆予測にコミットすることになる。計画が間違っていたとしても、その計画の達成率が評価になるのである。そこにはピボットは含まれないし、仮説検証による学びからの計画変更は加味されていない。結局、そこの年次予算のリズムが大枠のサイクルタイムになってしまう。 では、仮説検証型で細かくサイクルを回すためにはどうすれば良いか。 ここらへんは先日のバリューストリームマッピング研修にて、MaryやTomから簡単に説明があったり、やはりその後日のリーンエンタープライズの公園にてBarryも全く同様の話をしていたりで、要はBeyond Budgeting（脱予算経営）をしなさいというところだった。 （そんなこと簡単に言われてもさー。というのが正直なところではあるがそれだと当事者意識が低めなのでここでだけ言わせてもらう。そんなこと簡単に言われてもさー。）

かいつまんで説明すると以下である。

• 年次の予算モデルからの脱却
  • 予算確保のための計画、予算調達、実行、振り返りが年次予算である場合、そのリズムになってしまう
  • 大企業は中央集権な予算管理モデルが、意思決定をまとめて行いやすいため効率的に見えるが、不確実性が高い状況下におてそれはフロー効率を下げることになる。
  • Beyond Budgeting（脱予算経営）
    • 楽天の川口さんが昔ブログに簡単にまとめていてわかりやすい
    • http://kawaguti.hateblo.jp/entry/20120315/1331798274
    • Agile 2014 Closing Keynote: Beyond Budgeting でも語られていたようです
    • https://www.infoq.com/news/2014/08/agile2014-keynote-beyond-budgeti
  • 大企業内の新規事業組織とかはほかからの干渉をさけるため出島化することは多い。

しかしながら、現場レベルでも今すぐトライできるやりかたを考えたい。上記に比べるとミクロ視点すぎるため、全体最適とまではいけないが。要は、一旦確保したバジェットの中で如何にムダな金遣いを減らすか。確保したバジェットでできる仮説検証回数を最大化させるかがポイントである。お金の使い方のリーン化である。手前味噌ではあるが、有効なお金の使い方をするのに良いフォーマットがある。

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib

これをもとに仮説検証で学びたいこととそれに対するコスト、期間を見てメンバは責任者に決裁を取ることになる。都度、実験に対して決裁を取るので、組織として年次で確保したバジェットを小分けにして使いやすい。組織の事情を全く考慮せず言っているのであくまで一例としてではあるが。

さいごに

なぜこのタイミングでこんなことを突然語りだしたかというと、世の中で語られているDevOpsがビジネス価値ガーとかいうものの、ビジネス価値までスコープにはいってないではないかという疑問であり、そこらへんの整理をしたかったからであったりします。一見、DevOpsはただのエンジニアリングに見えるものの、結果的には実はビジネス上の不確実性を小さく効率よく取り除き、赤い線の部分の活動の効率化が、しまいには青い線の効率化に昇華する部分をうまく言語化したかったものの、少しわかりにくかったかもしれません。Feature Flagなんて特に青い線の部分の大失敗を避けるインフラであったりします。エンタープライズの中でリーンスタートアップのような仮説検証型でビジネスリスクを下げつつやる場合は、それ相応のエンジニアリングが必要でそれがDevOpsというワードで括っているスコープである理解になります。

あとは、こんな話を交えて

プロダクトオーナー祭り2016 ※2016/11/29更新 プロダクトオーナー祭りでパネルディスカッションで下記の話をしました i2key.hateblo.jp

Regional Scrum Gathering Tokyo 2017 パネル: DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

にプロポーザルを出しているので投票してネ！という記事広告の目的もあるのである。 最後までおつきあいありがとうございました。

また、全体的に論点をシャープにするため、極端に表現している部分はあります。アーリーステージだって、自動化もするし、やらないわけではありません。両立させている素晴らしいスタートアップも新規事業組織もたくさんあります。というわけで、あくまでビジネスコンテキスト上での優先度として、どちらが最優先されるかという意味になっております。あしからず。