『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2参加メモ（翻訳者である島田浩二氏の講演）

技術書「ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ」の翻訳者である島田浩二氏の講演のメモ。

https://timeedev.connpass.com/event/254336/

開催概要

── 「一人ひとりの時間を豊かに」を掲げるタイミーが発信するTech勉強会
株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。

第2回目はCTO亀田の愛読書でもあり、現在タイミーが向き合っているアーキテクチャについて学びの深い書籍である『ソフトウェアアーキテクチャの基礎』を題材にしたイベントを開催します。

今回は豪華ゲストとして『ソフトウェアアーキテクチャの基礎』の翻訳者 島田 浩二 氏をお迎えして、基調講演いただきます。 事例講演として弊社CTO亀田（@kameike）が今タイミーが向き合っている課題や成し遂げたいアーキテクチャ、何を考え、今に至って、これからどうしていくのかをお話します。 Q&Aセッションも設けますのでアーキテクチャに向き合ってきた講演者2名にぶつけたい質問もお待ちしております！

話すこと

• ソフトウェアアーキテクチャとは
• アーキテクティングのプロセス
• アーキテクティングへの向き合い方

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

• アーキテクチャパターンとも言われる
• 特定の性質を備える構造に名前が付けられたもの
• アーキテクチャは構造を決定するものだが、ソフトウェアアーキテクチャには構造だけでは説明できない部分がある

３つに分けると

• 構造になったもの
• 構造にならなかったもの（システムを構築する上でのルールやガイド）
• 備えるべき性質（アーキテクチャ特性）

ソフトウェアアーキテクチャの目的

内外からシステムに作用する力に対してシステムが崩壊しないように保つ

• 内から作用する力：規模や複雑さ
• 外から作用する力：障害、システム付加、サイバー攻撃・・・

アーキテクチャ特性の候補

• ility（イリティ）
  • Availability, Reliablity, Testability, ...

アーキテクティングのプロセス

ステップ１：要件やドメインの関心ごとから優先すべきアーキテクチャ特性とその程度を定める

まずは要件やドメインの関心ごとからアーキテクチャ特性を明らかにする

• 例）市場への投入速度を速めたい->アジリティ(Agility)＝複合的なアーキテクチャ特性（ほかのilityを達成することで達成できる。例えば、デプロイ性(Deployablitiy)、テスト性(Testability)、保守性(Maintainability)）
• アーキテクチャ特性の全部入りはできない。
  • 設計や構造が複雑になりすぎてしまうため
    • 例）ヴァーサ号の悲劇（豪華に見せるための彫刻品や細部の装飾に拘り、大砲も積むなどし過ぎた結果、処女航海で沈没）
  • アーキテクチャ特性は互いに干渉しあうため
    • 例）セキュリティ向上の取り組みは基本的にパフォーマンスに影響する
• 参考になるアプローチ
  • 品質特性ウェブ（Design It!にのっている）
    • ブレストおよび視覚化のアクティビティの一種
  • トレードオフスライダー（モノリスからマイクロサービスへにのっている）

ステップ２：さまざまな影響を考慮してアーキテクチャ上の決定を行っていく

アーキテクチャはさまざまなものに影響を受ける、与えるためそれらを考慮して決めていく必要がある

• 開発チームの能力、スキル、知識
  • 開発チームがシステムを構築するまで、構造は実際には存在しない
  • 作らないとアーキテクチャ特性を満たしているかも計測できない
  • 開発チームが作れない構造では意味がない
• ソフトウェア開発エコシステムの変化
  • 構造は何らかの技術を用いて実現される
  • ソフトウェア開発のエコシステムは絶えず変化
  • 施術の変化はアーキテクチャ特性の実現容易性等に影響を与える
  • 現在エコシステムがどう変化しているか、この先どう変化していくかを考える必要がある
• 組織のコミュニケーション構造
  • システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を宇満たしてしまう（コンウェイの法則）
• データ
  • データは貴重でシステムよりも寿命が長い
    • どこにどのように格納するかは重要
  • 分析データの扱いはアーキテクチャ特性に影響を与える
    • 例：パフォーマンスやセキュリティ
    • （個人情報の扱いが難しくなってきている等）

アーキテクチャにおけるすべての影響を事前には把握できないという難しさもある

どのように進めていくと良いか

• 銀の弾丸はない
• アーキテクチャは、Googleで見つけられない
• アーキテクチャには正解も間違いもない。トレードオフをどうするか
• 何と何が本当にトレードオフで、そこから何を、なぜ選択するかが重要（ビジネス、技術、組織等）

アーキテクティングの指針

• トレードオフを見極め、最善ではないかもしれないが、最悪ではないものを選ぶ

アーキテクティングへの向き合い方

①イテレーティブな活動であると捉えること

• 必要最小限のアーキテクチャを心がける
  • 責任を持てる限りにおいて判断を遅らせる
    • 最終責任時点：決定を下し損ねると、重要な代替案がなくなる時点
    • 最大責任時点：決定することで、最も前向きな影響を与える時点
  • アーキテクチャ特性に直接影響しない設計判断や具体的な実現の仕方は開発チームに委ねる
    • 開発チームと一緒に実現していく
  • 開発や運用からのフィードバックを得ていく

②継続的な活動であると捉えること

• アーキテクチャを見直し続ける
  • システムが備えるべきアーキテクチャ特性はビジネスの状況や環境の変化で変わっていく
  • アーキテクチャに影響を受ける・与えるものの状況も時間の経過とともに変化していく
  • アーキテクチャが経年劣化しないように改善していく
• Jez Humble (The DevOps HANDBOOK)
  • "成功を収めた製品、組織のアーキテクチャは、かならずライフサイクルの過程で必要に迫られて成長します。"
  • "すべての規模のすべての製品に適したたった１つのアーキテクチャというものはありえない"

技術書「ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ」には以下のような内容がある。

まだアーキテクチャに取り組んでいない場合は、今取り組んでいるシステムにどんなアーキテクチャ特性があるか、といったことを考えてみるところからスタートすると良いと思うとのこと。