進化するアーキテクチャ構築への序文

最近、私の同僚であるNeal FordRebecca Parsons、そしてPat Kuaが、「進化するアーキテクチャ構築」という本を執筆しました。私は彼らに序文を書くことを依頼されたことを光栄に思っています。

2017年10月5日

ソフトウェア業界は長い間、アーキテクチャは最初のコードを書く前に開発し完了させるべきものであるという考えに従ってきました。建設業界に触発され、成功したソフトウェアアーキテクチャの証は、開発中に変更する必要がないことだと感じられていました。これは、アーキテクチャの再設計イベントによって発生するスクラップや手戻りの高いコストに対する反応であることが多かったのです。

このアーキテクチャのビジョンは、アジャイルソフトウェア手法の台頭によって手厳しく挑戦されました。事前に計画されたアーキテクチャのアプローチは、要件もコーディングを開始する前に固定されるべきであるという考えに基づいていたため、要件、アーキテクチャ、構築(プログラミング)というフェーズ(またはウォーターフォール)アプローチにつながりました。しかし、アジャイルの世界は、固定された要件という概念そのものに異議を唱え、現代の世界では要件の定期的な変更がビジネス上の必要性であることを観察し、管理された変更を受け入れるためのプロジェクト計画手法を提供しました。

この新しいアジャイルの世界では、多くの人々がアーキテクチャの役割に疑問を呈しました。そして確かに、事前に計画されたアーキテクチャのビジョンは、現代のダイナミズムには適合しませんでした。しかし、アジャイルな方法で変更を受け入れるアーキテクチャへの別のアプローチがあります。この見解では、アーキテクチャは絶え間ない努力であり、プログラミングと密接に連携して、アーキテクチャが変化する要件だけでなく、プログラミングからのフィードバックにも対応できるようにします。私たちはこれを進化的アーキテクチャと呼ぶようになり、変更は予測不可能ではあるものの、アーキテクチャは依然として良い方向に進むことができることを強調しています。

Thoughtworksでは、私たちはこのアーキテクチャの世界観に浸ってきました。レベッカは、このミレニアムの初期に私たちの最も重要なプロジェクトの多くを率い、CTOとして私たちの技術リーダーシップを開発しました。ニールは、私たちの仕事を注意深く観察し、私たちが学んだ教訓を統合し伝えてきました。パットは、プロジェクトワークと並行して技術リーダーを育成してきました。私たちは常に、アーキテクチャが非常に重要であり、漫然としたチャンスに委ねることはできないと感じてきました。私たちは間違いを犯しましたが、そこから学び、その目的における多くの変更に優雅に対応できるコードベースを構築する方法についての理解を深めてきました。

進化的アーキテクチャを実行する上で重要なのは、小さな変更を加え、システムがどのように開発されているかから誰もが学べるようにフィードバックループを設けることです。継続的デリバリーの台頭は、進化的アーキテクチャを実用的にする上で重要な要素となっています。著者のトリオは、アーキテクチャの状態を監視するためにフィットネス関数の概念を使用しています。彼らは、アーキテクチャの進化可能性のさまざまなスタイルを検討し、長期間にわたるデータに関する問題に重点を置いています。これは、見過ごされがちなトピックであることがよくあります。コンウェイの法則は、議論の多くを覆い隠しており、そうあるべきです。

進化的スタイルでソフトウェアアーキテクチャを行うことについて、学ぶべきことはたくさんあると思いますが、この本は、現在の理解状態における重要なロードマップを示しています。より多くの人々が、ソフトウェアシステムが21世紀の人間の世界において中心的な役割を果たしていることを認識するにつれて、変化に最適に対応しつつ、足元を維持する方法を知ることは、すべてのソフトウェアリーダーにとって不可欠なスキルとなるでしょう。