未来のソフトウェアのための技術

クラウド、コードによるインフラ構築、APIにより連合されたアーキテクチャとアンチフラジャイルなシステム。Mary Poppendieck氏が主張するところによると、これらは目的に素早く到達するソフトウェアシステムを開発するための技術である。彼女はGOTO Berlin 2016でソフトウェアエンジニアリングの未来について講演を行った。

１つの計算機で処理するには大きすぎるデータがある場合、２つの選択肢がある。スケールアップするかスケールアウトするかである。さらに巨大な計算機を使用してスケールアップすることは通常向かうべき方向としては正しくない、とPoppendieckは主張した。より多くの計算機によりスケールアウトし、計算機システムを構築する必要がある。

Poppendieck氏はスケールアウトするための異なる方法について言及した。

• ファイルをスケールアウトする：ひとつの例としてGoogleが検索に用いているアプローチがある。ファイルは細かな断片に分割され、複数の計算機に複製されている。それから検索は並列に行われ、全ての計算機で処理した結果は１つの検索結果に結合される。
• アーキテクチャをスケールアウトする：Amazonはこれをトランザションを複数のサービスに分解し、そのサービスに特定のサーバを用いることで行っている。もしボトルネックがあれば、サービスを複数のサーバに複製することができる。各サービスは半自律化された”２つのピザ”のチームにより所有されている。

システムはクラウドに向けてどんどん進んでいる。あなたの未来にはクラウドがある、とPoppendieck氏は述べた。彼女は下記のように述べた。

クラウドは安価で、より安定しており、よりセキュアであり、大部分のオンプレミスのデータセンタより拡張性があります。

既存のアプリケーションをクラウドベースのアプリケーションに移行することは難題となることがある。Poppendieck氏はIBMのArthur Cole氏を引用した。

伝統的なデータアーキテクチャのために設計されたアプリケーションを良好に動作させるためには、多くの再実装が必要となります。

Poppendieck氏は既に存在しているいくつかのコードによるインフラ構築のソリューションを提示した。

• プロセスを標準化・自動化するためのコンテナ。
• 低価格に柔軟な計算能力を提供するサーバレスアーキテクチャ。
• スケールするためにハードウェアの代わりにソフトウェアを用いた、ソフトウェアにより定義されたネットワーク。

中央に１つのデータベースを保有することは、全てのアプリケーションがそのデータベースに依存するという依存の問題を生み、データベースの変更は多くのアプリケーションにインパクトを与えうる。Poppendieck氏は”エンタープライズデータベースは大規模な依存生成器である”と述べた。個々のチームはデータベースを共有する他の全てのチームと業務を調整する必要があるため、独立して配置を行うことはできない。１つのデータベースを保有する代わりに、個々のモジュールやサービス要件に適切に対応し、APIを通じてのみアクセスされる、複数のローカルデータストアに分割された、連合されたアーキテクチャが必要である。APIは中央の共有データベースを置き換え、IoTを可能にする。APIによるソフトウェア工学を行うために学ぶ必要がある、とPoppendieckは主張した。APIを責任を持ったチームにより所有された製品であると考えて、APIの顧客が進化し新しい能力を開発できるよう集中しよう。

失敗のないシステムを作ろうとするのを止めて、異なる考え方を導入する必要がある、とPoppendieck氏は述べた。現在のシステムの多くは脆弱である。それらは頑健なシステムとして運用を開始されたが、時が経つに連れて維持するのが難しくなる。最近のシステムはアンチフラジャイル、つまり失敗を受け入れることができるシステムである必要がある、とPoppendieck氏は主張した。何か間違ったことが起こった時、システムは被害を限定し、失敗から復旧する能力を持っているべきである。

アンチフラジャイルシステムはシステムをテストする手法によって得られる。これは何か間違ったことを起こすために失敗を注入することで行われる。Poppendieck氏は、今日期待されるレベルの可用性とロバストネスを獲得するために、システムが隔離され、失敗から自動的に復旧する必要があると指摘した。

Poppendieck氏は今日においてソフトウェアを開発するために必要不可欠な側面について言及した。彼女は継続的デリバリを可能とするためのデプロイメントパイプラインと、継続的デリバリにより約束された恩恵を得るために、プロダクトマネジメント、テスター、運用を含む機能横断的なチームが必要であると述べた。デプロイメントパイプラインはテスト、マイグレーション、配置のための自動化されたプロセスに依存している。継続的デリバリは、トランク上で継続的インテグレーションを行うことで、全てのチームにコードベースを通じてやりとりをすることを要求する。チームはソフトウェアを常に製品化の準備ができている状態を保つ。もし一旦立ち止まって製品化の準備をしなければならないのであれば、この状態には当てはまらない。インテグレーションは継続的であるが、役に立つ増分や能力の準備ができたときは、リリースをいつでもトグルもしくはスイッチによりインクリメンタルに行う。

継続的デリバリは必要不可欠なシステム全体のフィードバックを提供する、とPoppendieck氏は主張した。プロダクトマネージャーは時間の半分を誤って消費し、仕様上の機能の3分の2は不必要であると研究は示している。これは、ある機能が問題に本当に対処しているかを実際に確認するための実験を行う前に、何を開発するかを決めてしまった結果である。リーンやアジャイル開発を実践するの本当の価値は、対処された問題に対する良好な解決方法の開発を保証するために、実際の使用から素早くフィードバックを得られることである。Poppendieck氏は、単に運用するというチームから、有意義な制約の中で問題を解決するチームに変わっていくことを提案している。

実験のための基礎的なエンジニアリングプロセスを用い、実際の制約から学び、要件や機能からではなくパターンと兆候をもとにシステムを開発することをPoppendieck氏は推奨している。次に、問題に焦点を当てて仮説を用いて業務を計画しよう。これらに基づいて複数の実験を行い、どう継続していくかを決定するためにこのデータを活用するのである。