ソフトウェアアーキテクチャへの効果的なアプローチとは？ 取り組み方のポイントを紹介
次に島田氏は、ソフトウェアアーキテクチャに取り組む際に心に置くべき3つのポイントを述べた。1つ目は、アーキテクチャにおける全ての要素の影響を事前に把握することは不可能であるということ。設計や計画に組み込める既知の要素は問題ではないが、未知の未知という、事前に想定できない要素が存在するため、それらに対して意識的に取り組む必要がある。
2つ目は、品質特性を全て満たすことは不可能であるという点。品質特性を盛り込むほど、要求が高まり構造が複雑化し、取り扱いが難しくなるため、合意形成の中で共通理解を作ることが重要となる。
3つ目は、ソフトウェアアーキテクチャの前提は変化するということである。チームのスキル、ビジネス目標、組織構造、技術のトレンドなどは静的ではなく動的であり、変化に応じてアーキテクチャを見直す必要がある。決定したアーキテクチャを固定することなく、状況に応じて柔軟に対応することが求められるのだ。
現在のソフトウェアアーキテクチャの取り組み方について重要なアプローチは「必要十分なソフトウェアアーキテクチャ」で進むことだ。これに関しては『Just Enough Software Architecture』という書籍が参考になる。多くの実践者が、過剰ではなく必要十分なアーキテクチャの重要性を説いている。例えば、『Design It!』の日本語版序文では平鍋健児氏が、全て前もって設計する「ビッグ・デザイン・アップ・フロント」や事前に何も設計せずに、実装しながら設計する「ノー・デザイン・アップ・フロント」のリスクを指摘し、適切な設計アプローチとして「イナフ・デザイン・アップ・フロント」の概念を提案している。
また、「Minimum Viable Architecture」という、リーンスタートアップの文脈で有名になったMVP（Minimum Viable Product）のように「最小限の実行可能アーキテクチャ」を意味する。これは、必要最小限の品質特性だけを作り込んで進むアプローチであり、必要十分という考えが根底にある。
島田氏はさらに、アーキテクチャのプロセスを継続的に行うことも重要だとした。「Continuous Architecture」は、品質特性と技術的負債からのアーキテクチャの改善を考え、プロダクション環境でのフィードバックループを回し続ける考え方である。ほかにも「Evolutionary Architecture」というコンセプトもあり、これはアーキテクチャの決定要因が変化するにつれてアーキテクチャの変化を管理するものだ。
島田氏は、『モノリスからマイクロサービスへ』というサム・ニューマンの書籍は、モノリスから始めて、さまざまな決定要因を踏まえて決断をしてプロセスを考えて、マイクロサービスへ行く道をガイドする貴重な資料だとした。また、ジーン・キムらの『The DevOps ハンドブック』では、プロダクト開発サイクル中にアーキテクチャや技術的負債に対して一定のリソースを割り当てる重要性が説明されている。これらの要素を踏まえて島田氏は、現代のソフトウェアアーキテクチャに取り組む方法としては「必要十分」に進みながら、そのプロセスを「継続的に行う」ことが重要であるとまとめた。
アーキテクチャに無関心な設計は、システム利用者の負担に！ 開発者の責任とは？
続いて島田氏は、ソフトウェアアーキテクチャに無関心であることの影響について話し、その重要性を強調した。アーキテクチャに無関心な設計は、過去のプロジェクトを単にコピーするか、流行や会社の標準に従うことを意味する。このような設計では、システムが運用され始めた後に品質特性の問題が顕在化する可能性がある。例えば、パフォーマンス、保守性、可観測性の不足により、システム利用者や開発者の作業が妨げられることがある。
アーキテクチャは、さまざまな要因に影響されるが、それにより関わる人々にも影響を及ぼす。このため、アーキテクチャに対する自覚が必要である。さらに、開発者自身もその影響を受けるため、悪影響のサイクルに陥らないように注意が必要である。また、ソフトウェアアーキテクチャは開発者自身の仕事であり、アーキテクチャに対するケアが可能なのもソフトウェア開発者自身であるため、開発者にはアーキテクチャに関する大いなる責任が伴う。そのため、機能だけでなくソフトウェアシステム全体に対する関心と責任を持つことが大切である。
島田氏は最後に「ソフトウェアアーキテクチャに関する取り組みは、根本的にはシステムを利用する人々の人間性を高めるための活動だと感じています。これからこの分野を学ぶ方々には、自身のソフトウェアアーキテクチャの追求を進めていただきたいと思っています」とコメントし、セッションを締めくくった。
