ソフトウェアデリバリと製品の形成過程における革新は、必ずしもお互いに影響しあうわけではない。しかし、製品寿命が短くなったのと相まって、新しい製品フィーチャへの急激に増加する欲求とビジネスモデルさえもが継続的設計と継続的デリバリの周期をデリバリへの総体的なアプローチに繋げることを余儀なくしている。良い名前がないので、この記事では、我々はそれを技術革新のサイクルと呼ぶことにするが、このサイクルの段階は次のとおりである。
- アイデアの選択
- アイデアをテスト可能な仮説に改良
- アイデアを実現するための機能の選択
- これらの機能の開発とテスト
- 仮説が真であるかどうかを実証する手段の開発とテスト
- アイデアを製造に展開
- アイデアの成否の測定
- サイクルを繰り返す。
このようなアプローチをサポートするには、驚くことではないがメトリクスと分析、アーキテクチャ、テスト、実験的な設計そして継続的な設計における革新の応用が、継続的デリバリをサポートするプロセスとツールと一緒に必要である。本稿では、このサイクルを続けるために必要不可欠な技術革新を紹介する。以下で扱うトピックのそれぞれは、単独で記事あるいはそれ以上になり得るだろう。なのでこの調査をできればトピックについてもっと学ぶことを動機づける導入記事だと考えて欲しい。
メトリクスと分析
メトリクスは危険なビジネスである。誤った行動を奨励することになってしまう測定値を開発するのは非常に容易である。この危険性にも拘らず、しかし、メトリクスは上記のサイクルの重要な側面である。ソフトウェアシステムで実現される考えはそれが何をするかの観点ばかりでなく、どのようにしてその考えが良かったどうかを知る観点からの明確にされる。具体的な例を考えてみよう。マーケティング部門の誰かが購入のフローが変更された場合、それらのウェブサイト上の売上高は20％増加するだろうと考えている。この例の考えは変更されたフローである。検証可能な仮説は、新しいフローを使用するユーザーが古いフローを使用するユーザーより20パーセント多く購入するようになるということである。この場合メトリックは非常に単純である。我々は、フローごとに、ユーザー数と売上げ結果かどうか、測定する必要がある。我々は、ランダムに、新旧どちらかのフローにユーザを割り当て、フローは、その目的を達成したかどうかを評価する。 だから、これを実装するために、我々は両方のフローあたりのユーザーだけでなく、成功した販売を追跡することを確実にする必要がある。テストフェーズの終りには、マーケティング部門の考えが良かったかどうかがわかる。
実験的設計
時にはアイデアの価値を確立するために、正しいメトリックは何かあるいはどのようなタイプの分析が必要かがそれ程明らかではない。例えば、生産性を改善しようとする考えは、測定が難しい可能性がある。しかし、このアイデアが成功したか失敗したか、システムの所有者に提供されるフィードバックは、新機能の優先順位付けとシステムの進化を導くことを助けるために不可欠である。
検証可能な仮説を設計すると、機能が望ましい結果を提供するかどうかを実証する一連の実験を効果的に設計することになる。我々は、機能の結果が何であるかを決定し、その機能は、システムの動作にどのように影響するかを識別することから始める。実験を設計するための鍵は、機能の本当の影響が測定されることを保証することである。 上記の購入フローの変更の例では、新旧両方のフローを使って顧客を測り、比較することが、例えば過去のデータを調べるよりもずっと筋の通った比較を提供する。
進化的アーキテクチャ
サイクルを効率化するには、部分的には、新しいアイデアを試すために、直ちにシステムを適応する能力が必要である。理想的な世界では、システムを変えるために、我々が望むあらゆる可能な方法を予測できるが、現実の世界では、物事は本質的に予測不可能な方法で変わる。ユーザーの期待、事業環境、競争環境、規制すべてが組織の管理の外で変化する。なので、変化が想定されたものであろうがなかろうが、我々は変化に対応できる必要がある。進化的アーキテクチャと創発的設計が、できる限り容易に、そして安全に予期しない変更を行う、アジャイルソフトウェア開発のアプローチである。
次のセクションで扱うてテストは、進化的アーキテクチャと創発的設計の両方をサポートする。創発的設計は、新機能がシステムに追加された時に生じる、リファクタリングの機会を認識することで、コードを保守可能にし、綺麗に保つことに注力している。対照的に、進化的アーキテクチャは、システムの構造的要素に焦点を当てている。この中には、技術選択や異なる構造的要素間のインターフェース設計が含まれている。
この文脈における進化的アーキテクチャの目的は、システムのことな部分をそれらが互いにインタラクトする時でさえ、独立に開発できる能力を含んでいる。我々はこのことを実現するのに。それぞれのシステムが他のシステムの動きについて行う仮説を文書化する契約テストと一体になった機能を適切に隠蔽化する。各開発チームにそのようなテストを提供することは、システムが進化すると必然的に発生する潜在的な非互換性に対する早期警告となる。進化的アーキテクチャの他の目的は、データ変更、メッセージ変更、そしてコンポーネントの１つの実装を他のものと交換することである。
テスト
進化的アーキテクチャのセクションでは、革新のサイクルをサポートするためにテストの重要なスタイルについて記述した。しかし、テストの多くの様式がこのサイクルをサポートするために重要である。包括的で効果的なユニットテストは、創発的設計をサポートし、もっと一般的に追加機能をサポートする変更が既存機能を壊さない、という自信を与えるのに重要である。同様に、包括的な回帰テストスイートは、粒度の異なるレベルで同様な防御を提供する。
この革新サイクル関与するシステムの包括的なテスト戦略は、即座に新機能が動き、望まれた以前の動きが損なわれていないことを確実にする必要性に対処すべきである。このテストは、機能テストに加えて、技術的なテスト（負荷、環境など）を含むべきである。またテスト戦略には、アイデアの測定をサポートする機能が含まれていることをテストするのも重要である。このサイクルを回すには、テストの自動化が非常に重要である。手動テストサイクルは一般的に余りに長すぎる。手動テストは、重要な分野に絞るべきで、自然にずっと探索的であるべきである。
継続的設計
心強い傾向として、顧客とユーザーエクスペリエンスの設計に焦点が置かれてきていることだ。過去にソフトウェア開発の他の面で起きたように、ユーザー中心の設計は、もっとアジャイルなやり方でいかに開発かを学習している。ちょうどアーキテクチャやアプリケーション設計のように、ユーザーエクスペリエンスのフレームワークを設定するには、ある程度最新流行の考えが必要である。しかし、またしても、ちょうどアーキテクチャや設計のごとく、変化するユーザーニーズや期待と一緒に設計が進化できるように、その焦点はできるだけ初期のフレームワークを小さく設定することに置かれるべきである。
アプローチとして継続的設計は、ユーザーエクスペリエンスがシステムの進化の間に学習した知見を活用できるする。またこのアプローチによって、フィーチャがシステムのユーザーに提供するのはどのような価値かに、我々の注目が集まるようになる。上手く行けば、ユーザー中心のアプローチを使うことによって、よく我々のアプリケーションを悩ませるフィーチャの膨張を防ぐことができる。
継続的デリバリ
この調査記事の他のトピックと同様に、継続的デリバリは、複雑で包括的なトピックなのでかなりのページを占め、ほんの数パラグラフで足りるものではない。しかし、継続的デリバリの背後にある考えは、我々の革新サイクルが機能できるためのメカニズムを提供する。ここで最も関連する継続的デリバリの原則は、アイデアとその価値に対するフィードバックの間のサイクル時間を短くしながら、迅速に生産に展開する能力である。
迅速な展開を達成するには、多くの継続的デリバリ技術を必要とする。その中には、インフラの自動化、ビルドの自動化、デプロイとロールバックの自動化、データ移行の自動化、もちろん以前述べたテストの自動化もある。これらの技術のそれぞれが、新しいフィーチャ、新システムの迅速なテスト、アプリケーションの安全で迅速な生産への展開、システムが期待通りに動かないか、フィーチャが悪いアイデアであることが分かったいずれかの場合における迅速なロールバックを実装した迅速な開発をサポートする必要がある。
革新サイクル
最終的に、我々が記述しているこの革新サイクルの目標は、組織がもっと容易にアイデアをテストできるようにすることである。このアプローチ無しでは、アイデアを実装するのに多くを投資することになる。すなわちより少ないアイデアが試され、組織が特定のアイデアの成功にもっと縛られることになる。新しいアイデアを実験するコスト、時間、リスクを下げることによって、この革新サイクルは、組織がもっと多くのことを試すことができ、アイデアの隠れた宝石を発見する確率を増すことになる。
進化のアーキテクチャと包括的なテストだけでなく、他のアジャイルソフトウェア開発の実践は、アイデアを実装するために必要な開発時間を短縮する。継続的な設計は、機能がシステムの他のコンポーネントと統合する方法に着目し、また、アイデアの成功を測定する方法を考えるための観点を提供する。メトリクスの実験的な設計と適切な使用は、アイデアの成否を評価するのに必要なフィードバック・ループを実装する。 継続的デリバリは、革新サイクルを実現するために、これらのすべてが一緒に機能することを可能にするメカニズムを提供する。
実験のリスクとコストを下げることが、組織が継続的に従業員や顧客へのサービスを進化させる、基礎を提供する。我々は、革新サイクルを完了することが組織に絶対的な競争上の優位を与える、と考えている。
著者について
Rebecca Parsons博士は、 ThoughtWorksの Chief Technology Officerである。彼女は、電気通信から緊急インターネットサービスに至る産業界で、20年以上のアプリケーション開発経験を持っている。彼女には、大規模な分散オブジェクトアプリケーション、サービスベースのアプリケーション、および異種システムの統合の開発をリードする豊富な経験がある。彼女は現在も Agile Alliance 理事会の議長である。
ThoughtWorks社に来る前に彼女はCentral Florida 大学のコンピューター・サイエンスの助教授を務めていた。彼女はまた、Los Alamos National Laboratory で Directorの Post Doctoral Fellowとして働き、並列分散計算、遺伝的アルゴリズム、計算生物学と非線形力学系システムにおける問題を研究した。彼女は ２０１０年にThoughtWorksからの長期有給休暇の間に、ウガンダの Kampalaにある UNICEFのInnovation Labで働いた。
彼女は、 Bradley Universityからコンピュータサイエンスと経済学で理学士を取得し、Rice Universityからコンピュータサイエンスの修士と博士号を取得した。