Jez Humble氏は、現在のソフトウエアデリバリは価値あるソフトウエアを開発するということに対して最適されておらず、イノベーションを起こすには3つの問題を解決する必要がある、と言う。第一に従来のプロジェクトモデルが不適合であること。第二に組織全体の価値の流れを考慮する必要があること。第三に問題が根ざしているのはプロセスや文化であり、組織構造やツールではないということ。
Continuous Deliveryの共著者で、Lean Enterpriseの著者でもある氏は、ストックホルムで開催されたJfokusカンファレンスでの講演を、現代のソフトウエアデリバリは典型的なプロジェクトモデルを基盤としているということから話始めた。このモデルは元々はアメリカ軍が大きなもの、例えば、ミサイルや戦闘機を開発するために生み出したものだ。
氏によれば、このモデルは一度作ったら大きく変化しないもの、開発中に重要な情報が見つからないもの、使われる前に開発プロセスが完全に完了するもので有効に働く。しかし、この条件は現代のソフトウエアには適合しない。
この15年、ソフトウエア開発の‘方法論戦争’が展開された。ウォーターフォール、Vモデル、軽量なアジャイル手法が人気となった。
Humble氏によれば、アジャイル宣言が生まれたことで変化が促進されたものの、多くの企業は今も‘ウォーターフォール’を実践し、プロジェクトの開発フェーズのみが反復的に実施されっている。研究の‘曖昧なフロントエンド’、設計、計画はまだ単一のプロセスで実行されており、品質保証、リリース、運用のような‘ラストマイル’も同様だ。
研究や設計、計画の段階で反復がない場合、‘スコープクリープ’とネガティブに言及される状態を避けることができるかもしれないが、Humble氏がいうには、この場合、イノベーションが制限されると主張する。加えて、‘ウォータースクラムフォール’はソフトウエアをエンドユーザに素早くリリースする状態にしない。リードタイムの削減につながらないのだ。
アジャイル宣言の第一の原則は“顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します”とある。Humble氏は‘Lean Startup’の方法論と‘DevOps’の文化の組み合わせは素早い反復と素早く学び製品と市場の適合を特定することに最適化したプロセスを実現すると言う。
Eric Ries氏のサイトThe Lean Startupで紹介されている、‘ビルド、計測、学習’のプロセスを導入する手法は価値ある製品とサービスの開発に適用され、関連する市場の存在を検証するのにも使われる。Humble氏によれば、このプロセスは妥当なビジネスモデルを特定するタスクに適用される科学的な手法で、minimum viable product(MVP)を使ってしっかりとした利用者を想定して製品の価値を定義する実験ができる。
MVPは潜在的な顧客や市場に対する最初の仮定に基づいて開発される。このとき、ポジティブな結果を示す明確なビジネスメトリクスが定義されている。Humble氏は開発に80/20ルールを適用し、少量のしっかりと定義された要件だけを実現した機能だけを実装するべきだと言う。
MVPはハイスケールなソリューションとして実装されるべきではない。先端的な部分も無視されるべきだ。第一の目的は機能を素早く作り、製品を配置し、実際のユーザからビジネスのメトリクスとしてデータを集まることだ。
経験を設計する場合、Humble氏はJeff Gothelf氏やJosh Seiden氏の‘Lean UX’での仕事に従うのが良い、と言う。彼らの仕事に従えば、次のような仮説がたつ。
私たちの考えでは、
[この機能を]
[この人たちのために作ると]
[これを達成すること]ができる可能性がある。
この場合、[市場でこのようなシグナル]を見ることができれば成功と言える。
Humble氏によれば、A/Bテストは提供される機能とエンドユーザに対するインパクトの関係を示すのに最も良い方法だ。多くの企業がソフトウエアをリリースしているが、大量の変更がそれぞれプラスの影響があるかマイナスの影響があるかを判断する仕組みを持っていない。
Ronny Kohavi氏は2009年、Microsoft Thinkweek paperを発表した。題して“Online Experimentation at Microsoft”。これは、目標となるメトリクスを改善する上で、同社が実施した実験の内、効果があるのは、3つに1つであると報告している。Humble氏によれば、プロジェクトの3分の2の時間は無駄であり、A/Bテストのような実験を早い段階で実施することで、価値のない機能をユーザに提供することを防げる。
A/Bテストを設計するのは、些細なことではない。大勢のユーザを確保し、平行して行う複数の実験の相互作用を注意深く制御することも必要だ。Humble氏によれば、氏の考えでは、この点はソフトウエア開発業界で最もスキルのギャップの大きい。この実験を効率よく行うための知識体系があるわけでもなく、MBAや大学の講義で教えてくれるわけでもないからだ。
しかし、このようなスキルを持っている企業も現れている。例えば、EtsyはA/Bテストを効果的に行い、codeascraftブログやQConで詳細を発表している。“Etsy’s Product Development with Continuous Experimentation”というようなプレゼンだ。
また、Humble氏はITのパフォーマンスのための統計的に検証されたモデルを使うことについて説明している。このモデルはPuppetlabsの2014年のState of DevOps調査で取り上げられたものだ。‘スループット’は変更に対するリードタイムと変更頻度を示し、‘安定性’はインシデント後、復旧するのにかかった時間を示す。調査によれば、外部の変更はスループットを遅くするが、安定性は向上しない。そして、組織のハイパフォーマンスを示すのは、予防的な監視と組織文化、開発と運用のウィンウィンの関係だ。
講演の最後の話題は、大きな組織で効率的に失敗に対処することの大切さについてだ。Humble氏は、誰もが完璧な知識を持っておらず、現代のソフトウエアシステムのような複雑なシステムの副作用を完全に把握できないことを指摘する。複雑なシステムの障害は常に、研究の対象であり、非難の対象ではない。インシデントの振り返りはより多くの情報を厚め、問題を解決するためのよりリスクの低い行動を提供するために行う。
Humble氏は高い信頼性のある文化はイノベーションと相関関係があり、組織内のすべての人が実験や学習、イノベーションに向けて力を発揮する必要があると結論付けた。
講演の内容はJfokusのウェブサイトで確認できる。また、このトピックについては氏の新著Lean Enterpriseでさらに深く議論されている。