ソフトウェアアーキテクトのための意思決定術 リーダーシップ/技術/プロダクトマネジメントの活用 (Srinath Perera)

書籍情報

• 著者:Srinath Perera(著), 島田浩二(訳)
• 発行日:2024-12-11
• ISBN:9784295020769
• URL:https://book.impress.co.jp/books/1123101159

書籍目次

• 献辞
• はじめに
• 第1章 ソフトウェアリーダーシップ入門
  • 1.1 判断力が果たす役割
  • 1.2 本書の目的
  • 1.3 パート1: はじめに
  • 1.4 パート2: 最も重要な背景
  • 1.5 パート3: システム設計
  • 1.6 パート4: すべてをまとめる
• 第2章 システム、設計、アーキテクチャを理解する
  • 2.1 ソフトウェアアーキテクチャとは
  • 2.2 システムを設計する方法
  • 2.3 5つの質問
    • 2.3.1 質問1: 市場投入に最適なタイミングはいつか？
    • 2.3.2 質問2: チームのスキルレベルはどの程度か？
    • 2.3.3 質問3: システムパフォーマンスの感度はどれくらいか？
    • 2.3.4 質問4: システムを書き直せるのはいつか？
    • 2.3.5 質問5: 難しい問題はどこにあるか？
  • 2.4 7つの原則: 包括的なコンセプト
    • 2.4.1 原則1: ユーザージャーニーからすべてを導く
    • 2.4.2 原則2: イテレーティブなスライス戦略を用いる
    • 2.4.3 原則3: 各イテレーションでは、最小の労力で最大の価値を加え、より多くのユーザーをサポートする
    • 2.4.4 原則4: 決定を下し、リスクを負う
    • 2.4.5 原則5: 変更が難しいものは、深く設計し、ゆっくりと実装する
    • 2.4.6 原則6: 困難な問題に早期に並行して取り組むことで、エビデンスに学びながら未知の要素を排除する
    • 2.4.7 原則7: ソフトウェアアーキテクチャの凝集性と柔軟性のトレードオフを理解する
  • 2.5 オンライン書店の設計
  • 2.6 クラウド向けの設計
  • 2.7 まとめ
• 第3章 システムパフォーマンスを理解するためのモデル
  • 3.1 計算機システム
  • 3.2 パフォーマンスのためのモデル
    • 3.2.1 モデル1: ユーザーモードからカーネルモードへの切り替えコスト
    • 3.2.2 モデル2: 命令階層
    • 3.2.3 モデル3: コンテキストスイッチのオーバーヘッド
    • 3.2.4 モデル4: アムダールの法則
    • 3.2.5 モデル5: ユニバーサルスケーラビリティ法則
    • 3.2.6 モデル6: レイテンシーと使用率のトレードオフ
    • 3.2.7 モデル7: 最大有用利用（MUU）モデルを使用したスループット設計
    • 3.2.8 モデル8: レイテンシー制限の追加
  • 3.3 最適化のテクニック
    • 3.3.1 CPU最適化テクニック
    • 3.3.2 I/O最適化テクニック
    • 3.3.3 メモリ最適化テクニック
    • 3.3.4 レイテンシー最適化テクニック
  • 3.4 パフォーマンスへの直感的な理解
  • 3.5 意思決定における考慮事項
  • 3.6 まとめ
• 第4章 ユーザーエクスペリエンス（UX）を理解する
  • 4.1 アーキテクト向けの一般的なUXの考え方
    • 4.1.1 UXの原則1: ユーザーを理解する
    • 4.1.2 UXの原則2: 必要最小限のことをする
    • 4.1.3 UXの原則3: 良いプロダクトにはマニュアルが要らない。良いプロダクトは使い方が自明
    • 4.1.4 UXの原則4: 情報交換の観点から考える
    • 4.1.5 UXの原則5: シンプルなものをシンプルにする
    • 4.1.6 UXの原則6: 実装より前にUXをデザインする
  • 4.2 設定のためのUXデザイン
  • 4.3 APIのためのUXデザイン
  • 4.4 拡張機能のためのUXデザイン
  • 4.5 意思決定における考慮事項
  • 4.6 まとめ
• 第5章 マクロアーキテクチャ: はじめに
  • 5.1 マクロアーキテクチャの歴史
  • 5.2 現代のアーキテクチャ
  • 5.3 マクロアーキテクチャのビルディングブロック
    • 5.3.1 データマネジメント
    • 5.3.2 ルーターとメッセージング
    • 5.3.3 エグゼキューター
    • 5.3.4 セキュリティ
    • 5.3.5 通信
    • 5.3.6 その他
  • 5.4 意思決定における考慮事項
  • 5.5 まとめ
• 第6章 マクロアーキテクチャ: コーディネーション
  • 6.1 アプローチ1: クライアントからフローを駆動する
  • 6.2 アプローチ2: 別のサービスを利用する
  • 6.3 アプローチ3: 集中型ミドルウェアを使用する
  • 6.4 アプローチ4: コレオグラフィを導入する
  • 6.5 意思決定における考慮事項
  • 6.6 まとめ
• 第7章 マクロアーキテクチャ: 状態の一貫性の保持
  • 7.1 なぜトランザクションなのか
  • 7.2 なぜトランザクションを超える必要があるのか
  • 7.3 トランザクションを超えていく
    • 7.3.1 アプローチ1: 問題を再定義して必要な保証を減らす
    • 7.3.2 アプローチ2: 補償を使う
  • 7.4 ベストプラクティス
  • 7.5 意思決定における考慮事項
  • 7.6 まとめ
• 第8章 マクロアーキテクチャ: セキュリティへの対応
  • 8.1 ユーザー管理
  • 8.2 相互作用のセキュリティ
    • 8.2.1 認証の手法
    • 8.2.2 認可の手法
    • 8.2.3 相互作用のセキュリティを確保するための一般的なシナリオ
  • 8.3 ストレージ、GDPR、その他の規制
  • 8.4 セキュリティ戦略とアドバイス
    • 8.4.1 パフォーマンスとレイテンシー
    • 8.4.2 ゼロトラストアプローチ
    • 8.4.3 ユーザー提供コードを実行する際の注意
    • 8.4.4 ブロックチェーンの話題
    • 8.4.5 その他の話題
  • 8.5 意思決定における考慮事項
  • 8.6 まとめ
• 第9章 マクロアーキテクチャ: 高可用性とスケーラビリティへの対応
  • 9.1 高可用性を加える
    • 9.1.1 レプリケーション
    • 9.1.2 高速リカバリー
  • 9.2 スケーラビリティを理解する
  • 9.3 現代のアーキテクチャのためのスケーリング: 基本的なソリューション
  • 9.4 スケーリング: 取引のツール
    • 9.4.1 スケール戦術1: 何も共有しない
    • 9.4.2 スケール戦術2: 分散させる
    • 9.4.3 スケール戦術3: キャッシュする
    • 9.4.4 スケール戦術4: 非同期に処理する
  • 9.5 スケーラブルなシステムの構築
    • 9.5.1 アプローチ1: 逐次的にボトルネックを解消していく
    • 9.5.2 アプローチ2: シェアードナッシングな設計をする
  • 9.6 意思決定における考慮事項
  • 9.7 まとめ
• 第10章 マクロアーキテクチャ: マイクロサービスアーキテクチャでの考慮事項
  • 10.1 決めること1: 共有データベースの扱い
    • 10.1.1 解決策1: 特定のサービスだけがデータベースを更新する
    • 10.1.2 解決策2: 2つのサービスがデータベースを更新する
  • 10.2 決めること2: 各サービスのセキュリティ
  • 10.3 決めること3: サービス間のコーディネーション
  • 10.4 決めること4: 依存性地獄の避け方
    • 10.4.1 後方互換性
    • 10.4.2 前方互換性
    • 10.4.3 依存関係グラフ
  • 10.5 マイクロサービスの代替としての緩く結合されたリポジトリベースのチーム
  • 10.6 意思決定における考慮事項
  • 10.7 まとめ
• 第11章 サーバーアーキテクチャ
  • 11.1 サービスの作成
  • 11.2 サービスの作成におけるベストプラクティスを理解する
  • 11.3 高度なテクニックを理解する
    • 11.3.1 代替I/Oとスレッドモデルの使用
    • 11.3.2 コーディネーションのオーバーヘッドを理解する
    • 11.3.3 ローカルの状態を効率的に保存する
    • 11.3.4 トランスポートシステムの選択
    • 11.3.5 レイテンシーへの対応
    • 11.3.6 読み取りと書き込みの分離
    • 11.3.7 アプリケーションでロック（とシグナリング）を使う
    • 11.3.8 キューとプールの使用
    • 11.3.9 サービス呼び出しの取り扱い
  • 11.4 テクニックの実践
    • 11.4.1 CPU性能律速型アプリケーション（CPU>>メモリ、I/Oなし）
    • 11.4.2 メモリ性能律速型アプリケーション（メモリ>>CPU、I/Oなし）
    • 11.4.3 バランス型アプリケーションCPU＋メモリ＋I/O）
    • 11.4.4 I/O性能律速型アプリケーション（I/O＋メモリ>CPU）
    • 11.4.5 その他のアプリケーション分類
  • 11.5 意思決定における考慮事項
  • 11.6 まとめ
• 第12章 安定したシステムの構築
  • 12.1 システムはなぜ障害を起こすのか。私たちはそれにどう対処できるのか
  • 12.2 既知のエラーに対処する方法
    • 12.2.1 予期しない負荷への対処
    • 12.2.2 リソース障害への対処
    • 12.2.3 依存関係への対処
    • 12.2.4 人が行う変更への対処
  • 12.3 一般的なバグ
    • 12.3.1 リソースリーク
    • 12.3.2 デッドロックと遅い操作
  • 12.4 未知のエラーに対処する方法
    • 12.4.1 可観測性
    • 12.4.2 バグとテスト
  • 12.5 グレースフルデグラデーション
  • 12.6 意思決定における考慮事項
  • 12.7 まとめ
• 第13章 システムの構築と進化
  • 13.1 実際にやってみる
    • 13.1.1 基本に忠実に
    • 13.1.2 設計プロセスを理解する
    • 13.1.3 決定を下し、リスクを負う
    • 13.1.4 卓越性を求める
  • 13.2 設計を伝える
  • 13.3 システムを進化させる: ユーザーから学んでシステムを改善していく方法
  • 13.4 意思決定における考慮事項
  • 13.5 まとめ
• 参考文献
• 索引
• 訳者あとがき
• 日本語版 謝辞