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

Transcript

1. ソフトウェアアーキテクチャについて 語るときに 僕の語ること 2023/3/17 Nakaya Ryota
2. 自己紹介 ギフティ入社：2019年1月 所属：技術本部 Distribution Section GiftExperience dev Unit お仕事：お茶汲み（オフィスでコーヒーを淹れること） 前職：バックオフィス系システムのパッケージベンダー (上流メイン) 分報：#times_nakaya 最近のトレンド：花粉症
3. ソフトウェアアーキテクチャ（っぽいもの）との出会い
4. 色々と読み進め...
5. ソフトウェアアーキテクチャとは...？
6. ソフトウェアアーキテクチャとは...？ →捉えどころのない概念
7. Software Architecture: It Might Not Be What You Think It Is https://www.infoq.com/articles/what-software-architecture/
8. 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（アーキテクトはアジャイルチームが具現化するスキルであり、役割であってはならない ）
9. 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（アーキテクトはアジャイルチームが具現化するスキルであり、役割であってはならない ） 多くの人のメンタルモデルと違う のでは...？
11. ソフトウェアアーキテクチャは、ソフトウェアコンポーネント、それらの外部特 性、またそれらの相互関係から構成される。また、この用語はシステムのソフ トウェアアーキテクチャの文書化を意味することもある。『Wikipedia』
12. ソフトウェア・アーキテクチャはとても複雑だ。 そのせいで、専門家たちがさまざまな定義を生み出しているが、受け手にとっ てみればどれも一長一短である。 （中略） ほとんどのアーキテクチャ本では、アーキテクチャ上の設計プロセスにおける 人間的要素を削りすぎている。 『ビヨンドソフトウェアアーキテクチャ』
13. ソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進す るためにソフトウェアをどう構成するかということに対する、重要な設計判断が 集まったもの。 『Design It!』
14. システムの構造、システムがサポートしなければならないアーキテクチャ特 性、アーキテクチャ決定、そして設計指針の組み合わせで構成されるもの。 ※モノリスかマイクロサービスアーキテクチャか、とかはシステムの構造につ いての話であって、システムのアーキテクチャの話ではない。 『ソフトウェアアーキテクチャの基礎』
15. アーキテクチャとは、絶え間ない懸命な取り組みの一つである。 プログラミングと密に連携し、変化する要件に対応するだけでなく、プログラミ ングがもたらすフィードバックにも対応できるようにする取り組みだ。 『進化的アーキテクチャ』
16. • これといった確かな定義がない • そもそも何を対象とするか、も決まったものがない • デザインパターンとかコーディングアーキテクチャとかの話でもない • モノリシックやマイクロサービス、イベント駆動などのシステムの構成の話でもない • 特定のフェーズやシステムの構成を表すものではなく、ソフトウェアの開発、運用に 対するかなり包括的なものを指すことが多いっぽい
17. ソフトウェアアーキテクチャとは • 望まれる品質特性に対する重要な設計判断（トレードオフ）の集合 • 絶え間ない継続的な活動 • より良いソフトウェアをより長きに渡って使えるようにし、ユーザー体験、開発者体験、ビジネ スをドライブさせる取り組み全般を指す • ソフトウェアアーキテクチャについて考えるということは、ソフトウェア開発のあらゆるトレード オフについて考えるということである
18. ソフトウェアアーキテクチャについて なぜ「今」考えるのか
19. 概念としてのソフトウェアアーキテクチャの起源は、1968年のエド ガー・ダイクストラの研究や1970年代初期のデイビッド・パーナス の研究である。『Wikipedia』
20. 概念としてのソフトウェアアーキテクチャの起源は、1968年のエド ガー・ダイクストラの研究や1970年代初期のデイビッド・パーナス の研究である。『Wikipedia』 → 半世紀以上前から存在する 2000年代以前にも SOA など、様々なアーキテクチャが話題に なってきた
21. Software is eating the world. -- Marc Andreessen https://a16z.com/2011/08/20/why-software-is-eating-the-world/
22. Software is eating the world. -- Marc Andreessen あらゆるものがソフトウェアに飲み込まれ、 ソフトウェアが事業価値にダイレクトに繋がる世界 https://a16z.com/2011/08/20/why-software-is-eating-the-world/
23. https://startup-db.com/magazine/category/research/marketcap-global-2022
24. https://startup-db.com/magazine/category/research/marketcap-global-2022
25. https://startup-db.com/magazine/category/research/marketcap-global-2022 上位のほとんどがテックカンパニー
26. かつて TOYOTA がサプライチェーンのアーキテクチャで 競争優位性を作ったように、 ソフトウェアのアーキテクチャが企業の競争優位性を 作る時代に
27. かつて TOYOTA がサプライチェーンのアーキテクチャで 競争優位性を作ったように、 ソフトウェアのアーキテクチャが企業の競争優位性を 作る時代に → この流れはまだしばらく続きそう
28. 2022年は二冊の名著が発売され、 巷のアーキテクチャに関する関心の高まりが感じられた 2022年3月発売 2022年10月発売
29. 変化のスピードの速さ • 技術の移り変わりが早く、今作ったものが数年後には陳腐化している可能性 • ソフトウェアはコピー可能 • アジャイルアプローチによる高速フィードバックサイクルへの対応 • 作って売り切りではなく継続的に、より早く変化に対応する必要がある
30. マシンリソースの潤沢さ • ハード性能の向上やクラウド化によって、従来では取れなかった様々な構成が選択できるよう になってきた
31. 分散システムにおけるエコシステムの充実 • マイクロサービスなどの考え方を筆頭に、分散トランザクションやイベントソーシング、コンテナ オーケストレーションなどのエコシステムが充実してきた • 様々な取り組みの公開された知見も増えてきて、モノリシックアプリケーション以外の選択肢に チャレンジしやすい環境ができてきた
32. モノリシックアーキテクチャの限界 • 事業がグロースすればするほど、ソフトウェアの規模も大きくなる • 規模が大きくなればなるほど保守が難しくなる ◦ 1000人で一つのソフトウェアを開発するのを想像してみると ... • ソフトウェア規模の拡大に合わせた何らかの秩序が必要になってくる
33. ソフトウェアアーキテクチャがなぜ重要か
34. ソフトウェアは、それを構築したチームよりはるかに長く存続する • ソフトウェアのライフサイクルの中で数多のステークホルダーが関わることになる • アーキテクチャという土台、指針が優れていないと長期にわたって明らかな負債を抱えること になる（巨大な泥団子）
35. 良いアーキテクチャは、安定性を高める • 安定した土台があれば、多くの無駄を省き、多くの利益が得られる • 変更が容易であればあるほど、より早くより多くのユーザーにメリットを提供できる
36. 良いアーキテクチャは、安定性を高める • 安定した土台があれば、多くの無駄を省き、多くの利益が得られる • 変更が容易であればあるほど、より早くより多くのユーザーにメリットを提供できる ソフトウェアビジネスは極めて競争の激しい業界。 ある会社が他の会社より、他が同じ条件で、より良いソフトウェアをより速く 書いたとしたら、他の会社はいずれ潰れる。 -- Paul Graham
37. アーキテクチャは、社会的構造に影響を与える • どんな技術的要素を選択したとしても、それを使えるように開発チームを作っていくしかない • アーキテクチャによって組織ケイパビリティが形作られ、組織によって次のアーキテクチャが決 定づけられる • 優れたアーキテクチャは採用競争力を生み、優れたアーキテクト、エンジニアへの求心力となる
38. 優れたアーキテクチャは、模倣しづらい • ソフトウェアはいくらでもコピー可能 • ソフトウェアアーキテクチャは簡単には模倣できず、それ自体が競争優位性を生む
39. ソフトウェアアーキテクチャが向き合う課題
40. アーキテクチャとは Google で答えが見つからないものだ -- Mark Richards
41. 事業ドメインや組織の置かれている状況によって問題は様々
42. 事業ドメインや組織の置かれている状況によって問題は様々 雪の結晶のようなもの
43. 事業ドメインや組織の置かれている状況によって問題は様々 No Silver Bullet 雪の結晶のようなもの
44. 未来永劫安泰なソリューションはない • 未来を予言できる人はいない • 今下したアーキテクチャ上の判断は、何であれ、いずれ時代遅れになる 『ソフトウェアアーキテクトが知るべき97のこと』
45. 正解はない あるのはトレードオフだけ
46. アーキテクチャについて考えるとは トレードオフを考えるということである 正解はない あるのはトレードオフだけ
47. トレードオフをどう分析するか
48. 良し悪しを可視化する
49. 良し悪しを可視化する → 品質特性に目を向ける
50. Architectural Drivers ビジネス制約 Business Constraint 機能要件 Functional Requirement 品質特性 Quality Attribute https://peacepipe.toshiville.com/2007/01/4-arch.html 技術制約 Technical Constraint
51. 変更容易 性 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
52. IPA: つながる世界のソフトウェア品質ガイド（ https://www.ipa.go.jp/files/000055008.pdf）
53. 品質特性を適用する対象を決める • プロダクトによって優先したい品質特性は変わる ◦ （品質特性によってアプリケーションを分けることもある） • 巨大な泥団子では個別最適化した品質特性を定義できない可能性がある • 適切な粒度でアプリケーションを分割する必要がある ◦ まずは、アプリケーションの結合を明らかにして、適切な粒度に分解していく
54. 品質特性を定義する • 自分達が大事にしたい品質特性を決め、優先順位をつける • 品質特性の中には、同時に実現するのが難しいものがある ◦ 例えば ▪ 可用性を上げるためにはコストが嵩む ▪ セキュリティのために暗号化を入れると速度性能が落ちる
55. 品質特性を定義する • 自分達が大事にしたい品質特性を決め、優先順位をつける • 品質特性の中には、同時に実現するのが難しいものがある ◦ 例えば ▪ 可用性を上げるためにはコストが嵩む ▪ セキュリティのために暗号化を入れると速度性能が落ちる トレードオフ
56. 品質特性を守る • 仕組み化する • 品質特性に対する適応度関数を作る ◦ 適応度: ある品質特性がどの程度満たされているかを評価する客観的な指標 • CI などで自動化され、機械的に評価を行い、統制する
57. ここまでやりきれると非 常にリッチ 品質特性を守る • 仕組み化する • 品質特性に対する適応度関数を作る ◦ 適応度: ある品質特性がどの程度満たされているかを評価する客観的な指標 • CI などで自動化され、機械的に評価を行い、統制する
58. ソフトウェアアーキテクトとしての素養
59. • アーキテクトの仕事とは、重要なものを全て理解し、 釣り合いを取ることだ • 要素の中には明確なもの（パフォーマンスに関わる SLA など）もあれば、ビジネスの性質的に 不明確なもの（会社が合併や買収に乗り出しているなど）もある 『進化的アーキテクチャ』
60. • アーキテクトにとっては深さより幅が重要 • 技術的制約に能力を適合させる決定を行わなければならない 『ソフトウェアアーキテクチャの基礎』
61. 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 エンジニアの考える幅
62. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ
63. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ マーケット調査
64. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ マーケット調査 ユーザビリティ
65. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ マーケット調査 ユーザビリティ 組織ビルド
66. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ マーケット調査 ユーザビリティ 組織ビルド 政治 説明責任
67. エンジニアの考える幅 企画 業務 設計 要件 定義 設計 実装 テスト リリ ース 保守 運用 マネタイズ マーケット調査 ユーザビリティ 組織ビルド 政治 説明責任 etc
68. • ソフトウェアアーキテクトは、ソフトウェアのビジネス目標と要求を定義する • フィーチャーではなく品質特性に目を向ける 『Design It!』
69. • 自分自身で手を動して作る • 自分の専門分野のエキスパートである必要がある • 常に技術的探索を行う
70. 求められること • 自分で手を動かして • ビジネスと経営も理解して • 組織のことも考えて • 技術的プラクティスも幅広く探索して
71. 求められること • 自分で手を動かして • ビジネスと経営も理解して • 組織のことも考えて • 技術的プラクティスも幅広く探索して → スーパーマンでは？
72. 求められること • 自分で手を動かして • ビジネスと経営も理解して • 組織のことも考えて • 技術的プラクティスも幅広く探索して → スーパーマンでは？ → はい
73. 求められること • 自分で手を動かして • ビジネスと経営も理解して • 組織のことも考えて • 技術的プラクティスも幅広く探索して → スーパーマンでは？ → はい ソフトウェアを真面目に正しく育て ていくには必要なロール
74. • ソフトウェアアーキテクチャとは、望まれる品質特性に対する重要な設計判断（ト レードオフ）の集合である • ソフトウェアアーキテクチャの重要性は年々高まっている • 品質特性でアーキテクチャに通知表をつけて、良し悪しを評価する • アーキテクトというスーパーマンを育てる まとめ
75. 〜fin~