DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012
DevOpsに関する国内最大のイベントとなった「DevOps Days Tokyo 2012」が5月26日に都内で開催されました。
前の記事「DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012」では、John Wills氏の講演を紹介しました。この記事では、企業の中でDevOpsを通してビジネスを改善するために欠かせないメトリクスについて解説した、Damon Edwards氏の講演のハイライトを紹介します。
DevOps Business Justification and Metrics
DTO Solutionsの共同創業者、Damon Edwards氏。
普段はインフラについてのコンサルティングなどをしている。eコマース、金融、オンラインゲームなどの会社などが顧客だ。
DevOpsによって改善されている価値をどう計るか？ なにがビジネスにとって重要なのか、お金の流れなどを見ていく必要がある、というのがテーマ。
いまは超競争時代で、勝者と敗者がすぐに決まってしまう。しかも一位と二位の差が大きく、それ以下はいない。Winner takes all（勝者の総取り）が起きている。
お客様がビジネスの主導権を握っており、レビューサイトやソーシャルメディアなどによって、製品やサービスのまずさをマーケティングで隠すことができなくなっている。
そしてインターフェイスの標準化が進むなど、戦いの場が平等になってきて差別化するのが難しい。
ビジネスから見て、こうした状況の中でどう競争していくのか。3つの要素がある。
- スケール
- 低コスト
- 継続的イノベーション
しかしスケールは競合も同じように取り組んでいくだろう。低コストについては、進めていくと最後には無料にするしなければ勝てなくなるので、これを追求するのはやめだ。
だとすると焦点を当てていくべきなのは継続的なイノベーションだろう。
イノベーションを起こすにはサイクルを早くする
イノベーションは、そのアイデアを思いついた人がイノベータになり、世界を制すると考えられがちだが、現実にはそうではなく、数のゲームだ。
ある企業の調査によると、イノベーションの成功率は4％なのだそうだ。つまりイノベーションを起こそうとしても、その96％はむだになるということ。
とすると、イノベーションのゲームに勝つためにはチャレンジする数を増やして勝算をあげていくしかない。
企業Aが、チャンスが１回にひとつにリリースしかしないのに、企業Bはそのあいだに4回から10回リリースしたら、どちらが競争優位か？ たくさんリリースできる方が勝つだろう。
つまりビジネスのニーズは、できるだけリリースサイクルを短くして、しかもフィードバックに対応できるような柔軟性を持てるようにすることだ。
ITがそれにどう貢献できるだろうか？
かつては生産工場がビジネスの中心だったが、いまはITこそ生産の手段になっている。
その中心にあるのがDevOpsだ。それは私たちから見ればDevとOpsに分かれているが、会社からみれば1つのシステムである。
このシステムを分析するには、どのように計測すればいいだろうか。リーン生産システムを知っているならば、この分析はなじみのあるものだと思う。
システムをどのように計測すればいいのか
システムのどこを計測すると、どうなっているのかが分かるようになる。DevOpsを改善していくことで、よりよい効果が出ているかどうかを計測するために、ここに挙げたようなメトリクスが考えられる。
よくあるのはサイクルタイムの計測だ。Rapid Transformatin（迅速な変化）やFastfeedback（素早いフィードバック）の能力が分かる。
いちばん右も項目に「Data Source」とあるが、これがこのKPIを決めていく元となるデータの例だ。
Scrap Rate（スクラップレート）は、リーンから出てきた言葉。あるステップのアウトプットが次のステップで使われなかった頻度はどれくらいかを示す。例えば、5台サーバが必要だったとして、5台のサーバを入手したら期待したスペックではなかったため、サーバを再構築しなければならなくなった。これがスクラップの例。こうした隠れた無駄が組織のいろいろに隠れている。
Backwash（逆流）は、次のフェーズの準備で出来たはずのものが、どのくらいの頻度で、前のフェーズに戻ってやり直さなければならないか。一回の流れでスムーズに進むのではなく、戻らなければならないことが何度あるかを示す。
例えば開発者が「リリースの準備ができた」と言ったのに運用担当者が試したらうまくいかなかったと。すると開発に差し戻して修正が行われ、「今度は大丈夫」と言われたが、結局またうまくいかなかった、といったことだ。BackwashとScrap Rateはおたがいに関係する値である。
Process errors（プロセスエラー）とdeviations（逸脱）は、最後にはなんとかしてうまくいったけれど、プロセスには従っていない、というもの。
Delivery Efficiency（デリバリ効率）は、投資がどれだけ効率的にいくか。この考え方はシンプルで、チームでどれだけ価値のあるものに対して時間を使っているか。ただし現実にこれを正確に計測するのは難しいだろう。
組織の中にあるコンテキストと合わせて分析する
データは、コンテキストから外れて分析しても意味がない。そしてコンテキストは組織の中にある。具体的には、何かアクティビティやチェンジがあったときが重要。
DevOpsで何が起きたかをメトリクスとして把握するには、グラフ全体を見てアクティビティやチェンジが起きたところ、例えばリリースをしたとかデプロイをしたなどのメトリクスの変化を見て、それまでと比較していく。
あるいは上限と下限を作っておいて、そこを逸脱したメトリクスを見て、越えたときに、なぜそこを越えたのかを分析していく。
メトリクスを見るやり方はいろいろあるが、組織全体で共有するための大きなモニタを買おう。もう高いモノではない。そして、そこにみんなが群がって、ここを変えようとか、話し合っている状態にしよう。
以下は当日のUstreamのアーカイブ。
DevOps Days Tokyo 2012
DevOps関連記事
あわせて読みたい
<!- script for simple analytics events -->