ソフトウェアアーキテクチャについて語るときに僕の語ること

by nakaryooo

Slide 1

Slide 1 text

ソフトウェアアーキテクチャについて語るときに僕の語ること 2023/3/17 Nakaya Ryota

Slide 2

Slide 2 text

自己紹介ギフティ入社：2019年1月所属：技術本部 Distribution Section GiftExperience dev Unit お仕事：お茶汲み（オフィスでコーヒーを淹れること）前職：バックオフィス系システムのパッケージベンダー (上流メイン) 分報：#times_nakaya 最近のトレンド：花粉症

Slide 3

Slide 3 text

ソフトウェアアーキテクチャ（っぽいもの）との出会い

Slide 4

Slide 4 text

色々と読み進め...

Slide 5

Slide 5 text

ソフトウェアアーキテクチャとは...？

Slide 6

Slide 6 text

ソフトウェアアーキテクチャとは...？ →捉えどころのない概念

Slide 7

Slide 7 text

Software Architecture: It Might Not Be What You Think It Is https://www.infoq.com/articles/what-software-architecture/

Slide 8

Slide 8 text

https://www.infoq.com/articles/what-software-architecture/ Software Architecture: It Might Not Be What You Think It Is ● Software architecture is about capturing decisions, not describing structure （ソフトウェアアーキテクチャとは、構造を記述することではなく、意思決定を把握すること） ● Architecting is a skill that agile teams embody, which means that Architect should not be a role（アーキテクトはアジャイルチームが具現化するスキルであり、役割であってはならない）

Slide 9

Slide 9 text

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

ソフトウェアアーキテクチャは、ソフトウェアコンポーネント、それらの外部特性、またそれらの相互関係から構成される。また、この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある。『Wikipedia』

Slide 12

Slide 12 text

ソフトウェア・アーキテクチャはとても複雑だ。そのせいで、専門家たちがさまざまな定義を生み出しているが、受け手にとってみればどれも一長一短である。（中略）ほとんどのアーキテクチャ本では、アーキテクチャ上の設計プロセスにおける人間的要素を削りすぎている。『ビヨンドソフトウェアアーキテクチャ』

Slide 13

Slide 13 text

ソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったもの。『Design It!』

Slide 14

Slide 14 text

システムの構造、システムがサポートしなければならないアーキテクチャ特性、アーキテクチャ決定、そして設計指針の組み合わせで構成されるもの。 ※モノリスかマイクロサービスアーキテクチャか、とかはシステムの構造についての話であって、システムのアーキテクチャの話ではない。『ソフトウェアアーキテクチャの基礎』

Slide 15

Slide 15 text

アーキテクチャとは、絶え間ない懸命な取り組みの一つである。プログラミングと密に連携し、変化する要件に対応するだけでなく、プログラミングがもたらすフィードバックにも対応できるようにする取り組みだ。『進化的アーキテクチャ』

Slide 16

Slide 16 text

● これといった確かな定義がない ● そもそも何を対象とするか、も決まったものがない ● デザインパターンとかコーディングアーキテクチャとかの話でもない ● モノリシックやマイクロサービス、イベント駆動などのシステムの構成の話でもない ● 特定のフェーズやシステムの構成を表すものではなく、ソフトウェアの開発、運用に対するかなり包括的なものを指すことが多いっぽい

Slide 17

Slide 17 text

ソフトウェアアーキテクチャとは ● 望まれる品質特性に対する重要な設計判断（トレードオフ）の集合 ● 絶え間ない継続的な活動 ● より良いソフトウェアをより長きに渡って使えるようにし、ユーザー体験、開発者体験、ビジネスをドライブさせる取り組み全般を指す ● ソフトウェアアーキテクチャについて考えるということは、ソフトウェア開発のあらゆるトレードオフについて考えるということである

Slide 18

Slide 18 text

ソフトウェアアーキテクチャについてなぜ「今」考えるのか

Slide 19

Slide 19 text

概念としてのソフトウェアアーキテクチャの起源は、1968年のエドガー・ダイクストラの研究や1970年代初期のデイビッド・パーナスの研究である。『Wikipedia』

Slide 20

Slide 20 text

概念としてのソフトウェアアーキテクチャの起源は、1968年のエドガー・ダイクストラの研究や1970年代初期のデイビッド・パーナスの研究である。『Wikipedia』 → 半世紀以上前から存在する 2000年代以前にも SOA など、様々なアーキテクチャが話題になってきた

Slide 21

Slide 21 text

Software is eating the world. -- Marc Andreessen https://a16z.com/2011/08/20/why-software-is-eating-the-world/

Slide 22

Slide 22 text

Software is eating the world. -- Marc Andreessen あらゆるものがソフトウェアに飲み込まれ、ソフトウェアが事業価値にダイレクトに繋がる世界 https://a16z.com/2011/08/20/why-software-is-eating-the-world/

Slide 23

Slide 23 text

https://startup-db.com/magazine/category/research/marketcap-global-2022

Slide 24

Slide 24 text

https://startup-db.com/magazine/category/research/marketcap-global-2022

Slide 25

Slide 25 text

https://startup-db.com/magazine/category/research/marketcap-global-2022 上位のほとんどがテックカンパニー

Slide 26

Slide 26 text

かつて TOYOTA がサプライチェーンのアーキテクチャで競争優位性を作ったように、ソフトウェアのアーキテクチャが企業の競争優位性を作る時代に

Slide 27

Slide 27 text

かつて TOYOTA がサプライチェーンのアーキテクチャで競争優位性を作ったように、ソフトウェアのアーキテクチャが企業の競争優位性を作る時代に → この流れはまだしばらく続きそう

Slide 28

Slide 28 text

2022年は二冊の名著が発売され、巷のアーキテクチャに関する関心の高まりが感じられた 2022年3月発売 2022年10月発売

Slide 29

Slide 29 text

変化のスピードの速さ ● 技術の移り変わりが早く、今作ったものが数年後には陳腐化している可能性 ● ソフトウェアはコピー可能 ● アジャイルアプローチによる高速フィードバックサイクルへの対応 ● 作って売り切りではなく継続的に、より早く変化に対応する必要がある

Slide 30

Slide 30 text

マシンリソースの潤沢さ ● ハード性能の向上やクラウド化によって、従来では取れなかった様々な構成が選択できるようになってきた

Slide 31

Slide 31 text

分散システムにおけるエコシステムの充実 ● マイクロサービスなどの考え方を筆頭に、分散トランザクションやイベントソーシング、コンテナオーケストレーションなどのエコシステムが充実してきた ● 様々な取り組みの公開された知見も増えてきて、モノリシックアプリケーション以外の選択肢にチャレンジしやすい環境ができてきた

Slide 32

Slide 32 text

モノリシックアーキテクチャの限界 ● 事業がグロースすればするほど、ソフトウェアの規模も大きくなる ● 規模が大きくなればなるほど保守が難しくなる ○ 1000人で一つのソフトウェアを開発するのを想像してみると ... ● ソフトウェア規模の拡大に合わせた何らかの秩序が必要になってくる

Slide 33

Slide 33 text

ソフトウェアアーキテクチャがなぜ重要か

Slide 34

Slide 34 text

ソフトウェアは、それを構築したチームよりはるかに長く存続する ● ソフトウェアのライフサイクルの中で数多のステークホルダーが関わることになる ● アーキテクチャという土台、指針が優れていないと長期にわたって明らかな負債を抱えることになる（巨大な泥団子）

Slide 35

Slide 35 text

良いアーキテクチャは、安定性を高める ● 安定した土台があれば、多くの無駄を省き、多くの利益が得られる ● 変更が容易であればあるほど、より早くより多くのユーザーにメリットを提供できる

Slide 36

Slide 36 text

良いアーキテクチャは、安定性を高める ● 安定した土台があれば、多くの無駄を省き、多くの利益が得られる ● 変更が容易であればあるほど、より早くより多くのユーザーにメリットを提供できるソフトウェアビジネスは極めて競争の激しい業界。ある会社が他の会社より、他が同じ条件で、より良いソフトウェアをより速く書いたとしたら、他の会社はいずれ潰れる。 -- Paul Graham

Slide 37

Slide 37 text

アーキテクチャは、社会的構造に影響を与える ● どんな技術的要素を選択したとしても、それを使えるように開発チームを作っていくしかない ● アーキテクチャによって組織ケイパビリティが形作られ、組織によって次のアーキテクチャが決定づけられる ● 優れたアーキテクチャは採用競争力を生み、優れたアーキテクト、エンジニアへの求心力となる

Slide 38

Slide 38 text

優れたアーキテクチャは、模倣しづらい ● ソフトウェアはいくらでもコピー可能 ● ソフトウェアアーキテクチャは簡単には模倣できず、それ自体が競争優位性を生む

Slide 39

Slide 39 text

ソフトウェアアーキテクチャが向き合う課題

Slide 40

Slide 40 text

アーキテクチャとは Google で答えが見つからないものだ -- Mark Richards

Slide 41

Slide 41 text

事業ドメインや組織の置かれている状況によって問題は様々

Slide 42

Slide 42 text

事業ドメインや組織の置かれている状況によって問題は様々雪の結晶のようなもの

Slide 43

Slide 43 text

事業ドメインや組織の置かれている状況によって問題は様々 No Silver Bullet 雪の結晶のようなもの

Slide 44

Slide 44 text

未来永劫安泰なソリューションはない ● 未来を予言できる人はいない ● 今下したアーキテクチャ上の判断は、何であれ、いずれ時代遅れになる『ソフトウェアアーキテクトが知るべき97のこと』

Slide 45

Slide 45 text

正解はないあるのはトレードオフだけ

Slide 46

Slide 46 text

アーキテクチャについて考えるとはトレードオフを考えるということである正解はないあるのはトレードオフだけ

Slide 47

Slide 47 text

トレードオフをどう分析するか

Slide 48

Slide 48 text

良し悪しを可視化する

Slide 49

Slide 49 text

良し悪しを可視化する → 品質特性に目を向ける

Slide 50

Slide 50 text

Architectural Drivers ビジネス制約 Business Constraint 機能要件 Functional Requirement 品質特性 Quality Attribute https://peacepipe.toshiville.com/2007/01/4-arch.html 技術制約 Technical Constraint

Slide 51

Slide 51 text

変更容易性 Modifiability Architectural Drivers ビジネス制約 Business Constraint 機能要件 Functional Requirement 品質特性 Quality Attribute https://peacepipe.toshiville.com/2007/01/4-arch.html 技術制約 Technical Constraint 性能・速度 Performance 堅牢性 Security 可用性 Availability テスト容易性 Testability 使いやすさ Usability

Slide 52

Slide 52 text

IPA: つながる世界のソフトウェア品質ガイド（ https://www.ipa.go.jp/files/000055008.pdf）

Slide 53

Slide 53 text

品質特性を適用する対象を決める ● プロダクトによって優先したい品質特性は変わる ○ （品質特性によってアプリケーションを分けることもある） ● 巨大な泥団子では個別最適化した品質特性を定義できない可能性がある ● 適切な粒度でアプリケーションを分割する必要がある ○ まずは、アプリケーションの結合を明らかにして、適切な粒度に分解していく

Slide 54

Slide 54 text

品質特性を定義する ● 自分達が大事にしたい品質特性を決め、優先順位をつける ● 品質特性の中には、同時に実現するのが難しいものがある ○ 例えば ■ 可用性を上げるためにはコストが嵩む ■ セキュリティのために暗号化を入れると速度性能が落ちる

Slide 55

Slide 55 text

品質特性を定義する ● 自分達が大事にしたい品質特性を決め、優先順位をつける ● 品質特性の中には、同時に実現するのが難しいものがある ○ 例えば ■ 可用性を上げるためにはコストが嵩む ■ セキュリティのために暗号化を入れると速度性能が落ちるトレードオフ

Slide 56

Slide 56 text

品質特性を守る ● 仕組み化する ● 品質特性に対する適応度関数を作る ○ 適応度: ある品質特性がどの程度満たされているかを評価する客観的な指標 ● CI などで自動化され、機械的に評価を行い、統制する

Slide 57

Slide 57 text

ここまでやりきれると非常にリッチ品質特性を守る ● 仕組み化する ● 品質特性に対する適応度関数を作る ○ 適応度: ある品質特性がどの程度満たされているかを評価する客観的な指標 ● CI などで自動化され、機械的に評価を行い、統制する

Slide 58

Slide 58 text

ソフトウェアアーキテクトとしての素養

Slide 59

Slide 59 text

● アーキテクトの仕事とは、重要なものを全て理解し、釣り合いを取ることだ ● 要素の中には明確なもの（パフォーマンスに関わる SLA など）もあれば、ビジネスの性質的に不明確なもの（会社が合併や買収に乗り出しているなど）もある『進化的アーキテクチャ』

Slide 60

Slide 60 text

● アーキテクトにとっては深さより幅が重要 ● 技術的制約に能力を適合させる決定を行わなければならない『ソフトウェアアーキテクチャの基礎』

Slide 61

Slide 61 text

企画業務設計要件定義設計実装テストリリース保守運用エンジニアの考える幅

Slide 62

Slide 62 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズ

Slide 63

Slide 63 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズマーケット調査

Slide 64

Slide 64 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズマーケット調査ユーザビリティ

Slide 65

Slide 65 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズマーケット調査ユーザビリティ組織ビルド

Slide 66

Slide 66 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズマーケット調査ユーザビリティ組織ビルド政治説明責任

Slide 67

Slide 67 text

エンジニアの考える幅企画業務設計要件定義設計実装テストリリース保守運用マネタイズマーケット調査ユーザビリティ組織ビルド政治説明責任 etc

Slide 68

Slide 68 text

● ソフトウェアアーキテクトは、ソフトウェアのビジネス目標と要求を定義する ● フィーチャーではなく品質特性に目を向ける『Design It!』

Slide 69

Slide 69 text

● 自分自身で手を動して作る ● 自分の専門分野のエキスパートである必要がある ● 常に技術的探索を行う

Slide 70

Slide 70 text

求められること ● 自分で手を動かして ● ビジネスと経営も理解して ● 組織のことも考えて ● 技術的プラクティスも幅広く探索して

Slide 71

Slide 71 text

求められること ● 自分で手を動かして ● ビジネスと経営も理解して ● 組織のことも考えて ● 技術的プラクティスも幅広く探索して → スーパーマンでは？

Slide 72

Slide 72 text

求められること ● 自分で手を動かして ● ビジネスと経営も理解して ● 組織のことも考えて ● 技術的プラクティスも幅広く探索して → スーパーマンでは？ → はい

Slide 73

Slide 73 text

求められること ● 自分で手を動かして ● ビジネスと経営も理解して ● 組織のことも考えて ● 技術的プラクティスも幅広く探索して → スーパーマンでは？ → はいソフトウェアを真面目に正しく育てていくには必要なロール

Slide 74

Slide 74 text

● ソフトウェアアーキテクチャとは、望まれる品質特性に対する重要な設計判断（トレードオフ）の集合である ● ソフトウェアアーキテクチャの重要性は年々高まっている ● 品質特性でアーキテクチャに通知表をつけて、良し悪しを評価する ● アーキテクトというスーパーマンを育てるまとめ

Slide 75

Slide 75 text

〜fin~