🦜

精読「ソフトウェアアーキテクチャの基礎」(3)

2025/01/15に公開



ソフトウェアアーキテクチャの基礎
本書は、ソフトウェア開発におけるアーキテクチャ設計の基本原則と実践的な知識を体系的に解説した一冊です。初心者から中級者まで、システム設計の基礎を固めたい人に最適なガイドです。アーキテクトだけでなく、チームリーダーや開発者にも役立つ内容が詰まっています。

関連記事

アーキテクチャ決定

アーキテクチャ決定は、システムの構造や技術選択に関わる重要な選択。優れた決定は情報収集、妥当性確認、文書化、そしてステークホルダーへの伝達を通じて行われ、開発チームに適切な指針を提供する。

アーキテクチャ決定に関するアンチパターン

アーキテクチャ決定に関するアンチパターンには、以下の3つが挙げられる。

  1. 資産防御アンチパターン
    決定を避けたり、先延ばしにすることで、選択の誤りを恐れる状況。これを避けるには、開発チームと密に連携し、適時調整を行うことが重要。

  2. グラウンドホッグデーアンチパターン
    決定の根拠を示さず、繰り返し議論が行われる状況。決定の根拠は技術的・ビジネス的な理由の両方を明確に示し、ビジネス価値を提供することが必要。

  3. メール駆動アーキテクチャアンチパターン
    決定が関係者に効果的に伝わらない状況。決定を伝える際は、電子メール本文に詳細を含めず、記録したシステムへのリンクを提供することで、情報の一貫性と伝達を確保する。

これらを克服することで、効果的なアーキテクチャ決定が行える。

アーキテクチャ上重要なもの

アーキテクチャ上重要な決定は、アーキテクチャの設計に大きな影響を与える要素に関するものであり、技術的な選定を超えてシステム全体の構造や機能に関わる。Michael Nygardが指摘しているように、アーキテクトが行うべき決定には、構造、非機能特性、依存関係、インターフェイス、構築手法といった広範な側面が含まれる。これらの決定は、システムのスケーラビリティ、保守性、パフォーマンス、ユーザーインターフェースなど、最終的なシステムの品質に直接的な影響を与える。

  • 構造は、システム全体の設計におけるパターンやスタイルを決定する。例えば、マイクロサービスアーキテクチャを採用するかどうかという選択は、システム全体のデータ共有やコンテキスト分けに影響を与えるため、アーキテクチャ決定になる。
  • 非機能特性(パフォーマンス、スケーラビリティ、セキュリティなど)は、システムが求められる品質基準を満たすために必須。例えば、高いパフォーマンスが必要なシステムで特定のデータベース技術を選定することは、アーキテクチャ決定となる。
  • 依存関係は、システム間の結びつきがどう形成されるかを決める。これにより、システムの拡張性やモジュール性、保守性が大きく左右されるため、アーキテクトが責任を持って決定すべき。
  • インターフェイスは、システム内で異なるコンポーネントがどのように連携するか、また外部システムとどのように統合するかに関する決定だ。APIやサービス間のインターフェイス設計は重要なアーキテクチャの選択となる。
  • 構築手法は、使用するプラットフォーム、フレームワーク、ツール、開発プロセスに関する選択だが、これもシステムの実装や運用に影響を与えるため、アーキテクトの判断を要する。

これらの決定は、技術的な選択に見えるかもしれませんが、システム全体のアーキテクチャにおける影響を考慮する必要がある。

アーキテクチャディシジョンレコード

アーキテクチャデシジョンレコード(ADR)、アーキテクチャ決定を簡潔に記録するための手法で、Michael Nygardが提案し、その後広まった。通常、1〜2ページのテキストファイルで、AsciiDocやMarkdown形式で記述される。ツールも存在し、ADR-toolsが代表例で、管理が容易に行える。

ADRは、タイトル、ステータス、コンテキスト、決定、影響の5つの主要セクションから構成され、場合によっては代替案や備考を加えることもある。

  • タイトル: 連番と簡潔な説明を含む。
  • ステータス: 提案済み、承認済み、破棄など。破棄の場合は新しいADRに取って代わる。
  • コンテキスト: 決定がなされた状況や背景を記述。
  • 決定: アーキテクチャ決定を命令的に表現。
  • 影響: 決定がシステムや関係者に与える影響を文書化。

ADRの運用には、ツールや明確なステータス管理が重要で、承認基準(コストや影響など)も明確に定められるべき。

アーキテクチャ上のリスクを分析する

アーキテクチャのリスク分析について説明している。リスク分析を行うことで、可用性、スケーラビリティ、データ完全性に関する問題を事前に特定し、対策を講じることができる。主な手法として、リスク限定、リスクアセスメント、リスクストーミングが紹介され、これによりアーキテクチャの欠陥を発見し、リスクを軽減することが可能。

リスクマトリックス

リスクは影響度と発生可能性で評価し、それぞれを1〜3でランク付けし、掛け合わせてリスクを分類する。これにより、リスクを客観的に評価できる。

リスクアセスメント

リスクアセスメントは、リスクマトリックスで評価されたリスクをドメインごとに整理したレポートで、色分けや数値を使用してリスクを視覚的に示す。リスク評価は、特定のリスク領域や基準ごとに累計され、改善の傾向を追うことが可能。評価結果は状況に応じてフィルタリングされ、リスクの方向をプラスやマイナスの記号や矢印を使って示す方法も紹介されている。

リスクストーミング

リスクストーミングは、アーキテクチャのリスクをチームで特定、合意、軽減するプロセス。まず、各参加者が個別にリスクを特定し、次に集まりリスクの評価を合意する。最後に、リスクを軽減するための対策を共同で検討する。この方法により、開発者の視点も得られ、アーキテクチャに対する理解が深まる。

ユーザーストーリーリスク分析

ユーザーストーリーリスク分析では、リスクストーミングを活用して、与えられたイテレーション内でストーリーが完了するリスクを評価する。リスクマトリックスを使用すると、ストーリーのリスクは「未完成時の影響」と「完成しない可能性」の2つの観点で特定できる。これにより、チームはリスクの高いストーリーを早期に特定し、優先度をつけて追跡することができる。アーキテクチャと同様に、ストーリーにもリスクマトリックスを適用することで、リスクを管理しやすくなる。

リスクストーミング例

リスクストーミングでは、システムの可用性、弾力性、セキュリティに関するリスクを評価し、以下のように改善が行われた。

  • 可用性: 中央データベースのリスクを減らすため、2つのデータベースに分割し、SLAに基づいて診断エンジンやカルテ交換の可用性を評価。データベースの分割で可用性を改善。

  • 弾力性: 高負荷時に診断エンジンのリクエスト処理が追いつかないリスクに対し、非同期キューや診断アウトブレイクキャッシュを導入して、スケーラビリティを向上。

  • セキュリティ: APIゲートウェイを役割別に分け、アクセス制御を強化し、HIPAA準拠のセキュリティリスクを軽減。

これにより、システムの可用性、弾力性、セキュリティが向上した。

アーキテクチャの図解やプレゼンテーション

アーキテクトにとって、図解とプレゼンテーションは重要なコミュニケーションスキル。アーキテクチャの全体像を最初に示し、その後で詳細を掘り下げることで、観客は混乱せずに理解できる。表現の一貫性を保つことが鍵となる。

図解

アーキテクトは、アーキテクチャのトポロジーを図解で表現し、共通理解を形成するために図解スキルを磨く必要がある。ツール選びは重要だが、設計初期段階ではアナログなアーティファクトが有効。UML、C4、ArchiMateなどの標準ダイアグラムを使うことで、設計を可視化できる。

図解には、レイヤー、ステンシル、マグネットなどのツール機能が有効。作成する際は、タイトル、線、図形、ラベル、色、凡例などに注意を払い、効果的に表現することが求められる。

プレゼンテーション

PowerPointやKeynoteを効果的に活用するスキルが重要。アーキテクトは、スライドのトランジションやアニメーションを使ってアイデアを段階的に展開し、聴衆の注意を引く。過剰な情報を避け、スライドと発表者のバランスを取ることが求められる。空のスライドを使って、発表者に注目させる「不可視化」も有効なテクニック。プレゼンツールをうまく使うことで、アーキテクトのアイデアがより効果的に伝わる。

効果的なチームにする

アーキテクトは、単にアーキテクチャを設計するだけでなく、チームがそのアーキテクチャを実装できるようにガイドする必要がある。アーキテクトがチームと密に連携し、サイロ化された環境でアーキテクチャを作成するのではなく、チームと協力して問題を解決することが重要。

チーム境界

アーキテクトは、開発者がアーキテクチャを実装する際に制約を作り、それを伝える役割を担っている。制約が適切でないと、チームはアーキテクチャを正しく実装できなくなる。

アーキテクトが作る制約は、きつすぎても緩すぎても問題。きつすぎると、チームは必要なツールやライブラリを使えずフラストレーションを感じ、緩すぎると、チームがアーキテクチャの決定をすべて任されることになり、混乱や生産性の低下を招くことになる。

効果的なアーキテクトは、適切なレベルのガイダンスと制約を提供し、チームが効果的にアーキテクチャを実装できるようにする。

アーキテクトのパーソナリティ

アーキテクトには3つのタイプがある。

  • コントロールフリークアーキテクト: 開発の詳細に過剰に介入し、チームに厳しい制約を課す。多くの場合、チームのフラストレーションを生む。

  • アームチェアアーキテクト: 実装の詳細を無視し、チームから切り離れて抽象的な設計だけを行う。結果的にチームのガイドライン不足を招く。

  • 効果的なアーキテクト: チームに適切な制約を設け、必要なサポートを提供し、障害を取り除いて生産性を向上させる。理想的なリーダーシップを発揮する。

効果的なアーキテクトは、チームの目標達成を支援し、最適な環境を作る。

どうやって管理する?

効果的なソフトウェアアーキテクトは、開発チームをどの程度コントロールすべきかを判断するために、以下の5つの要因を考慮する。

  • チームの親しみやすさ: チームメンバーが互いにどれだけ知っているか。親しいほどコントロールは少なくなる。
  • チームサイズ: チームが小さければコントロールは少なく、大きければ多くなる。
  • 全体的な経験: 経験豊富なメンバーが多い場合、コントロールは少なくて済む。ジュニアメンバーが多ければ、コントロールが増す。
  • プロジェクトの複雑さ: 複雑なプロジェクトほど多くのコントロールが必要。
  • プロジェクトの期間: 短期間のプロジェクトほどコントロールは少なく、長期間の場合は多くなる。

これらの要因を評価し、プロジェクトの進行に応じてアーキテクトはコントロールのレベルを調整する。たとえば、経験豊富なチームでシンプルなプロジェクトの場合、アーキテクトはほとんど関与せず、チームに任せるべき。一方、ジュニアメンバーが多く複雑なプロジェクトであれば、アーキテクトはメンタリングや指導を行い、コントロールを強化する必要がある。

チームの警告サイン

大きなチームで発生しやすい問題として、プロセスロス、多元的無知、責任の分散が挙げられている。

  1. プロセスロス:
    チームメンバーが増えることで生産性が下がる現象。プロジェクトに人が増えると、コミュニケーションコストや調整コストが増大し、実際の生産性が低下する。アーキテクトは、プロセスロスを減らすために、並列作業ができる領域を探し、チームの規模を適切に調整する必要がある。

  2. 多元的無知:
    大きなチームでは、メンバーが問題を指摘しにくくなることがある。多元的無知とは、誰もが他のメンバーの意見に従い、内心では異なる意見を持ちながらも発言できない現象。アーキテクトは、会議や議論でメンバーの発言を引き出し、こうした状況を防ぐ必要がある。

  3. 責任の分散:
    チームが大きくなると、誰が何を担当しているのかが曖昧になり、責任が分散してしまう。アーキテクトは、チームの規模が大きすぎる場合、コミュニケーションや責任の明確化を行い、チームが効率的に協力できるように調整することが求められる。

これらの警告サインをアーキテクトが認識し、早期に対応することで、開発チームをより効果的に運営できるようになる。

チェックリストの活用

チェックリストは重要。特に航空業界や医療の現場でその効果が証明されているように、ソフトウェア開発にも有効だ。重要なのは、必要なプロセスを網羅し、エラーを防ぐこと。チェックリストは、手順が単純で自動化できる部分は除き、エラーが起きやすい場面に適用することが推奨されている。また、チェックリストを使うことで、開発者の行動が改善され、チームの効果が向上することが期待される。

ガイダンスの提供

このセクションでは、ソフトウェアアーキテクトが設計指針を提供し、開発チームを効果的にサポートする方法について。具体的には、サードパーティのライブラリ(技術スタック)に関するガイダンスを提供することが例として挙げられている。

  • ライブラリの重複確認: 新しいライブラリが既存機能と重複していないかを確認し、無駄な重複を避ける。
  • ビジネス的根拠の提示: 新しいライブラリが本当に必要かどうか、技術的およびビジネス的な根拠を求めることが重要。ビジネス上の価値を考慮することで、プロジェクトが健全に進行する。

アーキテクトは、開発者がどのライブラリを使うかを適切に決定できるように、技術スタックの管理指針を示すべき。たとえば、特定用途のライブラリは開発者が選定できるが、汎用的なライブラリやフレームワークライブラリについてはアーキテクトの承認が必要。

まとめ

開発チームを効果的にするためには多くの経験とスキル、特にピープルスキルが必要だが、エラスティックリーダーシップやチェックリスト、設計指針の提供といったシンプルで実践的なテクニックが非常に有効であることが示されている。

さらに、アーキテクトが単に技術的なガイダンスを提供するだけでなく、アーキテクチャの実装を通じてチームをリードし、チームの力学を観察し変化を促進することが、効果的なアーキテクトとそうでないアーキテクトの違いを生む。

交渉とリーダーシップのスキル

交渉とリーダーシップのスキルを効果的に身につけるためのテクニックについて。これらのスキルは学習と実践を通じて習得する必要があり、これからの内容はそのための出発点となる。

交渉とファシリテーション

ソフトウェアアーキテクトは、技術的な決定に異議を唱えられることが多く、交渉やファシリテーションが重要なスキルとされている。ビジネスステークホルダーとの交渉では、語法やバズワードを活用して関心事を理解し、事前に情報を収集することが鍵。また、コストや時間を強調するのは最後の手段として使い、要求を分割して交渉を進める。アーキテクト同士の交渉では、実証を重視し、議論を避けて冷静にリーダーシップを発揮することが求められる。

リーダーとしてのソフトウェアアーキテクト

ソフトウェアアーキテクトはリーダーシップを発揮し、チームをガイドする役割を担う。アーキテクチャの実装を通じて、効果的なコミュニケーション、協力、明瞭さ、簡潔さを重視する「アーキテクチャの4つのC」を活用することで、チーム内での信頼と尊敬を得ることができる。

優れたアーキテクトは、ビジョナリー(未来を見据えた計画)とプラグマティック(現実的な解決策)のバランスを取る必要がある。ビジョナリーであることは戦略的思考を適用することを意味し、プラグマティックであることは現実的な制約を考慮して実用的な解決策を提供することを指す。

また、効果的なリーダーは肩書きに頼るのではなく、手本を示してチームを導くべきである。アーキテクトが自らの行動を通じてリーダーシップを発揮し、尊敬を集めることが重要だ。ピープルスキル(人間関係スキル)を活かして、開発チームとの協力と効果的なコミュニケーションを促進することが求められる。

開発チームに溶け込む

効果的なソフトウェアアーキテクトになるには、開発チームとの時間を確保し、ミーティングの管理が重要。アーキテクトは、招待されたミーティングに対して、必要性を確認し、アジェンダを確認することで、無駄な時間を避けることができる。

また、開発者がフロー状態にある時間帯を避け、効率的なミーティング時間を設定することも大切。さらに、アーキテクトはチームと物理的に一緒に座り、積極的にコミュニケーションを取ることで、チームの一員として信頼と尊敬を得ることができる。

まとめ

アーキテクトがチームやステークホルダーと良好な関係を築くためのリーダーシップのヒントが紹介された。最も重要なのは、セオドア・ルーズベルトの「人とうまくやっていく方法を知ること」が成功の鍵だということ。

キャリアパスを開く

アーキテクトになるためには時間と努力が必要だが、キャリアを進む過程でも継続的な学びが不可欠。技術は常に進化しており、過去の知識を置き換えたり捨てたりすることもある。アーキテクトは、技術とビジネスの両方において最新の情報を追い続け、日々の仕事に組み込む必要がある。最新のリソースを活用することで、キャリアを広げていくことが大切。

20分ルール

「20分ルール」は、アーキテクトが技術的な幅を広げるために毎日20分を確保するテクニック。忙しい中で新しい情報を学ぶ時間を作るため、このルールを活用する。たとえば、昼休みや仕事後の時間を使う方法もありますが、朝一番に実践するのが最も効果的。朝、コーヒーや紅茶を飲んだ後、最初にメールチェックをせず、20分を使って学びを深めることを推奨する。この習慣を続けることで、技術的な幅を広げ、効果的なアーキテクトとしての成長が促進される。

パーソナルレーダーの開発

Nealは1990年代から00年代初めにかけて小さな会社のCTOとして働き、技術の進歩を無視しない重要性を学んだ。特に、技術の進化に伴い、過剰に宣伝された技術(ミームバブル)に注意し、バブルが崩壊する前に適切に評価を行う必要があると感じた。この教訓から生まれたのが「テクノロジーレーダー」という概念で、技術のリスクとリターンを評価するための道具として活用されている。

ThoughtWorksの「テクノロジーレーダー」は、ツール、言語とフレームワーク、手法、プラットフォームの4つの象限で構成され、技術を4つのリング(取扱注意、評価、トライアル、採用)に分類する。個人のレーダーを作成することで、技術の評価を整理し、戦略的な意思決定を支援する。

ソーシャルメディアの使用

アーキテクトが新しい技術やテクニックを手に入れる場所として、ソーシャルメディアが有効である。特にTwitterなどのソーシャルメディアを活用することで、技術者とのつながりを築き、最新の技術動向にアクセスできる。Andrew McAfeeの著書『Enterprise 2.0』では、人間関係のネットワークにおいて、強いつながり(家族や同僚)よりも、弱いつながり(カジュアルな知人や遠い親戚)が新しい機会を提供することがあると指摘されている。これにより、ソーシャルメディアを通じて新たな技術の情報源を得て、急速に変化する技術的な世界についていけるようになる。

別れの挨拶

偉大なアーキテクトになるためには、練習と経験が重要である。アーキテクチャには正解も間違いもなく、重要なのはトレードオフを考えながら設計することだ。Ted Newardが述べるように、アーキテクトになる機会は限られているため、その機会を最大限に活かし、スキルを磨き続けることが必要だ。実際、アーキテクチャの設計はトポロジーや実装方法だけでなく、「なぜその決定をしたのか」が大切であり、トレードオフを考慮した決定を記録することが重要だ。最終的には、学び続け、練習を積み重ねながらアーキテクティングを実践し続けることが、優れたアーキテクトへの道だ。

参考

https://amzn.to/40x3Ztq

Discussion