DevOpsのROIを測定する方法

  • Posted by Digital Stacks
  • On 2021年8月23日
DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか? どうやって投資を価値あるものにしますか?   DevOpsがROIに与える影響 DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。   あなたのチームはあなたの最大の資産です DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。   ROIをビジネスの目標に結び付ける では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか? これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。   時は金なり 鍵は効率化 柔軟に最適化を チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。 ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。 どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。   そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。 「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」(ウィリアム・ブルース・キャメロン)   ビジネスへの教訓 DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか?」という問いになってきています。   ROIの決定に使用できるDevOps指標 これらをあなたのビジネス目標に当てはめてください 指標 詳細とメリット 1日/週/月あたりの本番環境へのプッシュ数 本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。 1か月/年あたりのダウンタイムの分数 自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します。 自動テストカバレッジ 自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。 新入社員がコードを本番環境にデプロイするのに必要な時間 新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。 新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間 手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。 従業員の幸せ 作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS(Net Promoter Score)を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。
Read More

PagerDuty Summit 2021の概要 Part 2

  • Posted by Digital Stacks
  • On 2021年7月12日
多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる  時間を確保できることなどが期待されているからです。
Read More

PagerDuty Summit 2021の概要 Part1

  • Posted by Digital Stacks
  • On 2021年7月2日
多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる  時間を確保できることなどが期待されているからです。
Read More

DevOpsを高速化するための6つのステップ

  • Posted by Digital Stacks
  • On 2020年10月15日
多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる  時間を確保できることなどが期待されているからです。
Read More

DevOpsトランスフォーメーションに血を通わせる

  • Posted by Digital Stacks
  • On 2020年9月16日
チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。 「これがDevOpsと何の関係があるの?」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。 では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか? PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。   避けられない変化を認識する 今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。 しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。 あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。 DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。   ビジョンへの賛同を得る  トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。 小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。 アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。 開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。   インセンティブの変化を理解する  PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか? 従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。 DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。 オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。   DevOpsを自分のものにする  チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。 DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。 このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。   指標を理解する DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。 新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか? デプロイの頻度は? バグのトラブルシューティングにはどのくらいの時間がかかるか? 四半期ごとのダウンタイムはどのくらいか? これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。 理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間(MTTA)と解決する平均時間(MTTR)に注目しますが、重要な指標はこれだけではありません。 これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。 本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Read More

アジャイルとスクラムに関する問題

  • Posted by Digital Stacks
  • On 2020年9月9日
「アジャイル」はソフトウェア開発でよく使われるバズワードで、一部の組織やチームはアジャイルを装っていますが、実際  には全く違うことをしています。
Read More

PagerDuty:私たちは常にオンです

  • Posted by Digital Stacks
  • On 2020年8月17日
COVID-19の急速な感染拡大に伴い、多くの企業が完全なリモートワークに移行しています。顧客、ベンダー、パートナーがオンラインであることは、企業にとってこれまで以上に重要です。PagerDutyでは、従業員、その家族、そして私たちが属するより広い地域社会の健康と安全に主眼を置いていますが、他の最優先事項の1つは、特にこのような困難な時期には、顧客へのコミットメントです。 ご存知の方もいらっしゃるかもしれませんが、現在、全世界の従業員がリモートで仕事をしており、出張を停止しています。これが今のところの新しい常識かもしれませんが、リモートワークは当社にとって新しいことではなく、当社は最初からこのようなシナリオを想定して作られています。 当社の従業員は世界中に分散しており、分散したリモート環境での当社プラットフォームの開発と運用に慣れています。つまり、この事態にもかかわらず、お客様のデジタルビジネスが24時間365日稼働するように、PagerDutyを稼働させ続けることができます。 お客様へのコミットメント デジタル運用管理のマーケットリーダーとして、当社はこの分野で最大規模、最も信頼性が高く、回復力のあるプラットフォームを提供しています。当社のお客様からは、昼夜を問わず、いつでもシステムに問題が発生したときに、リアルタイムで適切な対応を行うための支援を受けることができるとの信頼をいただいています。では、それをどうやって実現しているのでしょうか。 当社のチームメンバーが分散しているのと同様に、当社のプラットフォームアーキテクチャも分散しています。当社は、複数の物理的なデータセンターからなる地理的に独立したクラウドリージョンに分散して配置されています。当社のアーキテクチャは、お客様からのトラフィックの急増を想定しています。例えば、旅行業界やEコマース業界とは異なり、予測可能なトラフィックパターンには季節性がありません。1万2700人以上のお客様からの予期せぬトラフィック量の増加に最善の準備をするために、必要に応じて動的にスケーリングできるように準備しています。 当社は、「失敗の金曜日」シリーズでカオスエンジニアリングを実践し、お客様のために信頼性と回復力を維持する能力を実践していることで知られています。時間をかけて障害シナリオのシミュレーションに取り組んできた結果、現在では「Failure Anydays」(失敗はいつでも起こる)を実施しています。そう、当社のチームの1つまたは複数が、お客様へのサービス提供の質に影響を与える可能性のある問題を迅速に特定して軽減するために、制御された障害テストをいつでも実施しているのです。2013年以来、当社のプロセスと実践をお客様と共有してきたので、失敗からの学習への投資は新しいものではありません。私たちは、プラットフォームアーキテクチャ、ベストプラクティス、そしてお客様への取り組みを維持するために懸命に努力し続けるチームに適した要素を備えていると確信しています。 ダウンタイムといえば、PagerDutyでは予定されたダウンタイムはありません。あなたの時計は止まることはありません。当社のサービスレベルアグリーメント(SLA)は、お客様に提供する可用性とパフォーマンスの両方をカバーします。メンテナンスのために計画的なダウンタイムを実施することはありません。問題が発生した場合、設定された配信期間内にお客様が通知を受け取ることができるように、プラットフォーム製品に冗長性を持たせています。 多くの企業がリモートワークへのシフトを行おうとしているか、または行っています。そして今、これまで以上にデジタルビジネスが稼働し続けることが不可欠です。PagerDutyはそれを助けるためにここにいます。 本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Read More