ソフトウェア開発においてアーキテクトに従事する筆者がソフトウェアアーキテクチャについて専門用語を使わずに解説します
アーキテクチャとは
ソフトウェアアーキテクチャとは何かを考える前に、アーキテクチャの定義について見てみます。
アーキテクチャとは本来建築業界において、
「建築学」、「建築術」、「構造」、「建築様式」を意味する言葉でした。
そしてIBMが汎用コンピューターの設計思想にアーキテクチャという言葉を用いたことで
建築業界からIT業界にもアーキテクチャという言葉が浸透したとされています。
もともとは、建築業界において「建築様式」などを意味する「アーキテクチャ」
では、IT業界における「ソフトウェアアーキテクチャ」とは何を意味するのでしょうか?
なお、ソフトウェア開発において、「ソフトウェアアーキテクチャ」は単に、「アーキテクチャ」を呼称されることが多いですが、本記事では、建築業界における「アーキテクチャ」と明示的に区別するために「ソフトウェアアーキテクチャ」と表現します。
ソフトウェアアーキテクチャとは
始めに、言葉の定義を見ていきます。Wikipediaの定義を見てみます。
ソフトウェアアーキテクチャとは、抽象化と問題の分割によって複雑性を減らすことを主に念頭に置いたものである。ただし、今までのところ、「ソフトウェアアーキテクチャ」という用語に関して、万人が合意した厳密な定義は存在しない - ソフトウェアアーキテクチャ
正直なところ表現が難しく、すぐに理解できる表現ではありませんね。
説明から見ると、複雑なシステムを分割して複雑性を減らすため定義されるものであると読み取れます。
もっと簡単な説明としてはシステム開発の基礎となる考え方であると言えそうです。
日常生活においても、大きな課題に取り組む際に道筋を立て細分化し、ひとつずつ解決に取り組まれるかと思います。
システム開発においても、適切な粒度にシステムを分割し、分割した単位ごとに開発し、ルールに従って分割したシステムを繋ぎ合わせていくのです。
ソフトウェアアーキテクチャが伝える事
「ソフトウェアアーキテクチャ」の一つであるクリーンアーキテクチャを例にとって考えてみます。
クリーンアーキテクチャの構造は下図のような同心円の構造となっています。
クリーンアーキテクチャの考え方は、複雑なシステムを同心円で表現された粒度で分割して複雑度を下げる狙いがあります。
また分割されたシステム間の関係は、変更の少ないコンポーネントが、変更の多いコンポーネントに依存してはならないという指針が示されています。
この指針は、青色の最も外側の円から、黄色の中心に向かって矢印が書かれていることで表現されています。
設計指針としては、
- ユーザーインターフェース(UI)など変更が多いコンポーネントは円の外側に配置する
- ビジネスロジック(Entities)など変更が少ないコンポーネントは円の内側に配置する
- 円の内側は、円の外側に依存してはならない
この設計によって、外側の変更によって、内側も変更しなければならないという事態を回避します。そして、円の中心に配置したビジネスロジックをユーザーインターフェースの変更などの影響から守り、システム全体の変更容易性を高めています。
このように、システム開発において基本となる考え方を明示し、システムとして何を重要視して開発するかを定義します。
なぜソフトウェアアーキテクチャは必要なのか?
この問いへの最も単純明快な解は
システムを楽に開発するためです
さらに付け加えるのであれば、
大規模システムを大人数で楽に開発するためです
始めに一人ですべてが完結するシステム開発を考えます。
この場合、ソフトウェアアーキテクチャは必要でしょうか?
一人で開発を進めて行く場合、誰かと設計に対する考え方が衝突することもなく
予期しない実装が行われることもありません
自分が思うように設計し、自分の思うように実装ができます。
なぜなら、システム開発の担当者は自分一人であり、システム開発の基本となる考え方も一つしかないためです。
この状態であれば、特に意識せずとも、
一人の開発者の考え方が、ある種のソフトウェアアーキテクチャとして成立します。
ただし、多くの開発者の知恵が詰まった一般的な考え方を取り入れて開発が行われることも多々あると思います。
少し話がそれますが一人で開発する場合において、一般的な考え方に基づいて開発しておいた方が良い場合があります。
それは、将来的に担当者の引継ぎがある場合や、設計内容を他者に見せる予定がある場合です。
将来に渡って開発者が同じ一人の人であれば、問題になりませんが、「僕の考えた最強の考え方」に基づいたシステムを、別の人に引き継ぐとき、「僕の考えた最強の考え方」を引き継ぐ際に学習コストがかかる場合があります。また、すべてを伝えきることも至難の業です。この時一般的な考え方に基づいて開発されている場合、情報源が自分以外にも存在するため、既に引継ぎ担当者が知っていたり、自分以外から学習できるため学習コストが下がる傾向にあります。
話を本筋に戻して、大規模システムを大人数で開発していく場合を考えます
先ほどとは異なり、様々な人の考え方が入り交じり、
「この要件は、コンポーネントAで実装すべきだ」
「いや、コンポーネントBで実装すべきだ」
といった衝突が起きたり、
「この設計の方が優れている」
「いや、こちらの設計の方が優れている」
といった軋轢が生じます
こうした複数人での大規模開発にて考え方の拠り所となるものが
基本となる考え方を示すソフトウェアアーキテクチャなのです
事前に合意の取れた基本となる考え方が存在すれば
衝突や軋轢が起こった場合に、どちらがよりに基本となる考え方に沿った考え方であるのかを基準に判断できます
またその判断基準はソフトウェアアーキテクチャを基にしており
その時々でブレることはありません
このようにある種共通認識を定義しておくことで、大規模なシステム開発におい共通した目的と秩序ある構造を持つシステム開発が可能となります。
結果として、システムに変更容易性をもたらし開発に関わる人たちがトータルで楽ができるようになるのです
アーキテクトチームは理想を追い、コンポーネント開発現場の現実を知らないと嘆いているケースもあるのではないでしょうか？
ソフトウェアアーキテクチャによって開発の負担が増加しないか?
アーキテクトチームの要望により、コンポーネント開発チームの実装負担が増加するケースは多々あり得ます。
これはアーキテクトチームはシステムの全体最適が責務であるのに対し、
コンポーネント開発チームがコンポーネント内の個別最適が責務であることによります
両チーム見ているところが違うのです
極端な話コード行数だけを見た実装負担では、Interfaceなど定義せず単純に関数呼び出しだけをしていればコード行数は少なくなります。
しかし、将来の変更に耐えられるように、楽に修正ができるようにInterfaceを定義し、
関心事を分離し、依存関係を管理することで長期的な実装量や、設計変更量を減少させます。
このような実装をアーキテクトチームはシステム全体の最適化を考慮しコンポーネント開発チームに要求します。
コンポーネント開発チームにとっては負担でしかないと見える要求があり得るかもしれません。
実際問題、開発チームAが受け入れた開発負担は、開発チームBがその利益を享受し、
開発チームAは、負担が増えるだけの場合すらありえます。
しかしながらアーキテクトチームは開発全体が楽になると信じて要求します。
1人での開発では
システム全体の最適化 = 開発者(1人)の個別最適
だったものが、
最規模開発となると
システム全体の最適化 ≠ 開発者(複数人)の個別最適
となってしまうのです。
この話は、コンポーネント開発チームが短期的視野しか持っていないから悪いとも
ソフトウェアアーキテクトチームがコンポーネント開発チームのことを考えていないから悪いといった類のことを言いたくて書いているわけではなりません。
それぞれのチームが見ていることが違うため議論が必要となるということが言いたいがために書いています。
ソフトウェアアーキテクトチームは、適用するソフトウェアアーキテクチャによってもたらされるシステム全体としてのメリットを十分に説明する義務があり、
コンポーネント開発チームは、全体最適への理解と、許容できる開発負担を論理的に説明する義務があります。
そして互いに納得した上で開発が進められることこそがシステム開発全体が楽になっていく第一歩だと思っています。
でなければ、理想としていたソフトウェアアーキテクチャは崩壊し、
コンポーネント開発チームが払った開発負担が将来にわたって回収されることのない
不幸な開発が出来上がってしまいます
0 件のコメント :
コメントを投稿