DevOpsのテキスト研修

DevOpsで仮説を磨き、実験と学びを軸とした組織を育てるには

従来型のIT組織ではおそらく、製品や機能が望む事業成果を生んでいるか、そもそも実際に使う人がいるかさえ確認せず、何度もリリースを作っています。事業モデルや製品・機能のアイデアを検証するうえで最も非効率なのは、見込んだ需要が実際に存在し、そのアイデアで満たせるかを知るために、ソフトウェア製品やサービスを完成させてしまうことです。

本格的な製品やサービスを作る前に、こう問いかけます。「なぜこれを作るのか。”, “本当に時間とリソースを使う価値があるか。」アイデア、製品、機能が期待する事業成果につながるか検証するため、可能な限り短期間で、費用のかからない実験を計画して実施します。

さまざまな企業向け製品群を対象に、長期にわたる統計的な実験と測定を行ったところ、売上高、コンバージョン、注文、契約、新規顧客の獲得など、主要な事業指標を大きく改善できた変更は全体の3分の1でした。残りの3分の2は改善がなかったか、あってもごく小さく、指標が悪化した場合もあります。その3分の2に関しては、価値を生まない機能を作るよりも、チーム全員に休暇を取ってもらうほうが、組織にとって有益だったでしょう。

この課題に対処するには、A/Bテストでユーザー調査を行います。機能を本格的に作る前に、どんな成果が得られるかを試します。ユーザー調査からのフィードバックをエンジニアリングのプロセスに組み込むことで、DevOpsの手法を正しく使い、作るべきものを作っていることを確認します。実験し、学び、顧客からのフィードバックをソフトウェアエンジニアリングのライフサイクルに早く取り込めるほど、対象市場で競合を上回る力が高まります。

A/Bテストが最初に広く使われたのは、郵送によるダイレクトレスポンスマーケティングです。担当者は、言葉遣い、配色、レイアウト、見出し、本文などを変えたチラシやはがきを多数試し、どれが最も反応や売上につながるかを調べました。英国政府も、国民から滞納税を徴収するのに最も効果的な通知文を見つけるためにA/Bテストを行ってきました。現在は、マーケティングやコミュニケーションの要素を試すだけでなく、どのアイデア、製品、機能がうまくいくかを見極める一般的な手法です。

DevOpsチームでA/Bテストを取り入れるには、製品機能の複数バージョンをすばやく簡単にデプロイし、異なるユーザー層に提示できるようにします。幅広いテレメトリとビジネス層のメトリクスを使い、機能が事業成果を高めるか、高めるならどのバージョンが最も良いかを見極めます。

たとえば、DevOps組織がECサイトの購入手続きを刷新したいとします。チームの大きな新規案件にする前は、事業成果の改善に関する仮説にすぎません。仮説を調査して検証した後で初めて、チームが相当の時間、リソース、労力を投じる実際のプロジェクトになります。この購入手続きに関してチームがまず行う作業は次のとおりです。

仮説を検証する 私たちの仮説では、 新しい購入手続きによって 次の効果が見込めます。 コンバージョン率が向上する。 次の結果が得られれば、自信を持って この機能を本格的に作り、届けられます。訪問者の1%に試験的に提示した購入手続きの案のうち、一つで、その後7日間に売上が少なくとも5%増えることです。

まとめ

これまでに学び観察してきたベストプラクティスや直感だけに頼らず、実際の人が現実の環境で実験に参加してくれることを重視します。

DevOpsプロダクトオーナーは、製品や機能のアイデアを検証すべき仮説と捉えます。合理的に有望だと確かめた仮説だけを、本格的な設計、構築、テストに進めます。