ビヨンドソフトウェアアーキテクチャ
https://images-na.ssl-images-amazon.com/images/I/517ldsHdACL._SX399_BO1,204,203,200_.jpg
概要・感想
原著は 2003 年に発行
ビジネスの視点からソフトウェアが語られる
アーキテクチャの技術的な側面 (ターキテクチャ) とマーケティング的な側面 (マーケテクチャ) を軸に、ソリューションとして成功をおさめて、継続的に価値をもたらし続けるために何をしなければならないかを幅広い視点から説明 内容メモ
前書きなど
ソリューションをうまく構築するためには、ソフトウェアアーキテクチャの枠組みを超えて、ビジネス課題を理解して受け入れなければならない
本書に繰り返し登場するテーマ : 技術とビジネスの相互関係をマネジメントする
1 章 ソフトウェアアーキテクチャ
アーキテクチャの進化と成熟
アーキテクチャの話としては初期構築について強調されがちだが、実際には既存アーキテクチャ上での作業を主にやる人の方が多い
プロダクトが何をするのか (あるいは何をするべきなのか) を規定するのはフィーチャー 顧客からのフィードバックにより新たなフィーチャーの実装をしようとすると、そのためのケイパビリティ構築が必要になる → フィードバックを通じてこそケイパビリティは成熟していく
成熟と進化のサイクルを中断して、チームが主にケイパビリティについて議論するという状況もありえる
既存システムを完全に再設計・再構築する必要がある状況 (必要なケイパビリティを備えておらず、それを追加するためのコストが高すぎる場合)
期待されるフィーチャーを提供するためのケイパビリティがないのに、そのフィーチャーを実装しようとすると、技術的負債を負う 負債の元本 : 本来あるべきケイパビリティを利用して構築した場合と比較したコスト
活動をするときには、どのモジュールや関数を改善するのか、具体的な計画を立ててピアレビューする 1, 2 週間では終わらないような大規模な変更を提案することもあるため
チームがアーキテクチャについて全体像レベルで作業するためには何らかのモデルが必要 建築でも、敷地図、配線図、照明図、などのたくさんの図面がある
チームでのエクササイズ
メンバーに紙を渡して、そこにシステムのアーキテクチャを手で描いてもらう
終わったら全員分のアーキテクチャ展覧会をする → ずれがあるか？ ずれがあるならそれはなぜ？
2 章 プロダクト開発入門
ほとんどの開発者は、プロダクトマネジメントに必要な、基本的で重要な考え方をほとんど理解していない
著者の定義 : 成功するソリューションを構築・維持するために欠かせない包括的な一連の活動
https://gyazo.com/6a99ba07044dd64f85501f1326aa810c
伝統的なウォーターフォールは開発フェーズを説明するもの
効果的なプロダクト開発プラクティスでは、各ステージの結果に対して厳密に定義された 「可/不可」 判定を行う
このプロセス全体はステージゲートと呼ばれる (厳密に定義された金銭的な指標であることが多い) ステージゲートプロセスとウォーターフォールプロセスの違い : プロジェクトを丁寧に審査して打ち切る
プロダクト中心主義が浸透している企業では、ベータテストの途中でもプロダクトを打ち切ることがある
初回リリースの後にはプロダクト開発プロセスも変化する
段階的な凍結
凍結するのは変更を防ぐことが目的ではなく、正式な変更管理プロセスを通じてのみ変更を許すこと
変更管理プロトコル
クリエイティビティを抑圧するのが目的ではなく、変更前に適切な人に情報を与えてその人が準備できるように
プロダクト中心の組織において、変更管理ミーティングはプロダクトマネジメントチームが準備して仕切る
プロダクト中心組織でないなら、プロジェクトマネジャーやプログラムマネジャー
プロダクトマネジメントの重要な概念
3 章 マーケテクチャとターキテクチャ
この章は、ビジネス目標達成のためのシステムのマーケティングの側面と技術的な側面の話
アーキテクチャという観点で見た時のソフトウェアシステムは 2 つの方向性
https://gyazo.com/ebc08ad18442fa3516d2068e276a706f
このリスクを最小化するために、将来どうしたいかを示す図をたくさん描く : このような図を筆者はマップと呼ぶ 4 章 ビジネスとライセンスモデルの共益関係
ほとんどのソフトウェア企業は、少数のビジネスモデルしか用意せず、それが標的市場に受け入れられることを期待している
成熟したマーケットにおいては、収益を最大化して各セグメントのマーケットシェアを確保するため柔軟性が必要 アプリケーションはフィーチャーの集合なので、各フィーチャーを別々のビジネスモデルおよびライセンスモデルで提供可能 ビジネスモデルに対するターキテクチャのサポート
5 章 インライセンステクノロジー
インライセンステクノロジーを管理する際のテクニック
ラッパーやアダプターを作る
別のテクノロジーへの切り替えがやりやすくなる
欠点は、最大公約数的なインターフェイスになりがちなこと (そのテクノロジーの固有の機能を使えないなど)
オープンソースの定義のバージョン 1.9 () に従っているライセンスなら何も不安に思わなくてよい 自分のプロダクトにオープンソーステクノロジーの一部を統合することは完全に自由
6 章 可搬性
可搬性に伴う苦痛を最小化するために大事なことは、マーケットにおける可搬性の相対的な優先順位を開発者と品質保証チームに理解させること 優先順位が不明確だと、間違った部分を開発して時間を無駄にしたり、本当に必要なところのテストができていないなどが起こりうる
優先順位付けのテクニック : 開発者や品質保証チームが使う、マーケットありきの構成のマトリックス (苦痛のマトリックス) を作ること 7 章 デプロイメントアーキテクチャ
デプロイメントの選択肢
顧客サイト
トランザクション (Web サービス)
8 章 統合と拡張
統合や拡張の動機 : より優れたプロダクトを作る能力が得られる
状況によっては、統合や拡張の作業は顧客に引き継がれる
顧客にとってやることが増えるかもしれないが、顧客満足度は上がる
レイヤ化アーキテクチャの話
UI レイヤにアプリケーションロジックを含めてしまわないか → 今の UI を完全に置き換える (例えば音声入出力にするなど) としたら、どこを変更する必要がある？ と自問する
実際に情報を表示するレイヤ
UI とサービス間でマイクロワークフローを仲介するレイヤ
ユースケース全体が 1 つのサービスとして表現されることも
1 ユースケースの中の 1 ステップが 1 サービスに該当することも
データベースの中に業務ロジックを移すことが適切な場合もある
性能のため
高度な制約付きのデータを扱うため
9 章 ブランドとブランド要素
ブランド要素はプロダクト全体に織り込まれるので、アーキテクチャの一部になることが多い → 適切に管理する必要 インストール先についての筆者のおすすめ : 会社名/プロダクト名/サブコンポーネント名
名前は変わりやすいので、コードネームを使うべき
GUI は見た目やアイコンといったブランド要素に影響を受ける 10 章 ユーザビリティ
成功するソリューションとは、実際に使えるソリューションのこと
本章はユーザビリティのそれ以外の点 (特に性能と拡張性) マーケテクトにとって : システムの競争上の優位性を確保するため ユーザーとユーザーが利用する状況を理解するのは重要
それがユーザビリティの量的、質的な指標になるから
量的な指標 : 性能やデータ入力エラー率
質的な指標 : 満足度や理解のしやすさ
ユーザーを理解するための手法は様々 : 観察、インタビュー、質問、直接体験など
できるだけ実際のユーザーと同じようなタスクをやってみた後で、その経験に基づいてユーザーが使いやすいと思うシステムを構築する
ユーザビリティを高める理由 : それがお金になるから
研修コストの削減、サポートとサービスコストの削減、エラー発生時のコストの軽減、ユーザーの生産性の向上、顧客満足度の向上、保守性の向上
ユーザーインターフェイスとターキテクチャ
使いやすいシステムに重要なヒューリスティクスのひとつはユーザーにフィードバックを返すこと
バリデーションもフィードバック
一度受け付けたリクエストは中断できるようにすべき
リクエストの中断できるようにするためには慎重なターキテクチャ設計が必要
中断も取り消しもできないビジネストランザクションについては、トランザクションの相殺ができるように
それができないシステムは極めて扱いづらい
タイムアウトを適切に設定する
値が不適切だとユーザビリティを損ねるし、システムリソースを不必要に消費したりする
障害回復
多かれ少なかれシステムは故障する
それをシステムがどう扱うかがユーザビリティに直結する
性能
可能な限り高速なシステムを構築するよりもはるかに重要
nobuoka.icon 「不確実な見積もりでできるだけ早くシステム構築するよりも正確な見積もりが欲しい」、という話と似ているな
システムが本当に一瞬で応答できないなら、何らかのフィードバックの仕組みが必要
フィードバックの大まかな分類
即時的 (1 秒から 2 秒) : 共通オブジェクト (マウスカーソルなど) を変化させるなど
継続的 (2 秒以上) : 共通の繰り返しアニメーションなどが適する
確実に性能を向上させるなら、プロファイラを使うのもひとつの手 ただし、プロファイラで特定・改善できるのはアーキテクチャに関係しないボトルネックのみ
キャッシュを使う場合は、キャッシュされた結果をいつどのように再計算すべきなのかを明らかにしておくこと nobuoka.icon わかる (キャッシュ周りは結構大変だった)
キャッシュの影響をテストできるように、動的にキャッシュの有効・無効を切り替えられるアーキテクチャにする
コンピュータシステム以外の点での性能改善の手としてセルフサービスがある
この考え方はターキテクチャ上の設計に役立つ : 呼び出し側のコンポーネントが処理するようにする、など
11 章 インストール
多くの開発組織ではインストールに関する課題は後回しにされる
インストールの設計が拙いことで経済的な損失が発生する可能性が高い
インストールに関するわかりやすい目標をマーケテクトがターキテクトのために設定していれば役に立つ
例 : 「平均的なユーザーがサポートなしでインストールを完了すること」 など
が、現実にはマーケテクチャやターキテクチャの様々なフォースや選択がインストールプロセスに影響を与える
サブコンポーネントの管理やインライセンス契約なども
法務部門は、ライセンス契約の一部あるいはすべてをインストールプロセスに含めたいと考える ユーザーはマニュアルを読まないことが多いかもしれないが、マニュアルは重要
開発チームと品質保証チームに、システムの振る舞いについて検証可能な記述を提供する
インストールとアンインストールはどちらも十分にテストする必要がある
片方あるいは両方をちゃんとテストしていない品質保証チームも多い
プロダクト開発サイクルのかなり早い段階でインストーラを作り始めるのが最良の選択
自動ビルドプロセスに組み込める
インストール処理をスクリプト化する
理想的には、一度手動でインストールしたものについて、将来同じ設定で自動実行するためのスクリプトを生成する
12 章 アップグレード
アップグレードはインストールよりも問題になることが多い
顧客にとって深刻な被害を引き起こしやすい
データベーススキーマの設計を慎重に行っていれば、データ移行の労力は劇的に軽減される
めったに変更されないもの、一度作成したら変更すべきではないもの、頻繁に変更されうるもの、の 3 つにわける
アップグレードの苦痛を取り除く
アップグレードをどれぐらいの頻度で提供すべきかは、マーケットに起こるイベントやリズムを理解する
最適なアップグレード方法を決めるために、現在のインストール状態を評価するのは良い考え
フィーチャーを取り除くことは、追加するのと同じかそれ以上に大変
アップグレード時に設定情報とカスタマイズ情報もアップグレードされることを確認すること
新バージョンが既存のコンポーネントを置き換えるか共存するか？
可能な限り置き換えるべし
そうでないならユーザーはいつ古いバージョンを削除すべきなのかがわからず混乱するかもしれない
テストの複雑さも増える
イノベーターは未成熟なプロダクトに寛容だが、アップグレードについては別
特にデータ移行
イノベーターは大量のデータを入力しているので、それを無駄にしてはいけない
13 章 コンフィギュレーション
設定可能性に配慮する大きな理由はコスト
設定パラメータに反映すべきはシステムの文脈という基本的な情報
nobuoka.icon ファイルやディレクトリの配置だったり、DBMS の種類だったり、そういう類のもののことっぽい 設定パラメータにするのはそれを設定しないとシステムが動作しないものだけにして、それ以外は変更可能なパラメータとして妥当な初期値を与えておく
nobuoka.icon 「設定パラメータ」 は起動時に与える必須のもので、「変更可能なパラメータ」 は任意のもの、という感じ？
システムの初期化時にすべてのパラメータを処理するやり方だと、ちょっとした設定変更でも再起動が必要になる
可能な限り動的に変更できるようにすると良い
14 章 ログ
ログの適切な設計は、マーケテクチャ上の目標達成のための重要なタスクの役に立つ
ログを収集する根本的な動機 : 誰かがシステムについて何らか知りたいことがある
デバッグ
システム設定管理も含む
システムクラッシュ時の実行状態の復元
性能評価
キャパシティプランニング
行動追跡と監査 (マーケティング観点、あるいはセキュリティ観点)
運転状態管理
ログデータは慎重な取り扱いが必要になる場合があるので、暗号化したり、特別な権限が必要な場所に格納する
顧客の負担を軽くするために、自動的にログを収集して技術サポートに転送する仕組みを検討するとよい
ロギングの標準
15 章 リリース管理
ソフトウェア構成管理の専門家によって定義された基本的な用語
「何をリリースするのか」 と 「誰を対象とするか」 を混同しがち
リリースの完全な識別子は、プロダクト名とプロダクトの適切なリビジョンやバリエーションを含むバージョン情報によって構成される アルファリリースや一般リリースといったものにそれぞれ異なる識別子を割り当てる流儀もあるが、おすすめしない
それは、「何をリリースするのか」 と 「誰を対象とするか」 を混同している
パッチリリースは、何らかのイベントや不具合それぞれに対応していることが多い パッチを作ることになった原因と紐づけるため、名前と日付で参照することを推奨
「プロダクト名-x.y(.z(.ビルド番号))-パッチ名」 というような形式
顧客に販売するプロダクトは、棚卸や販売レポートなどの様々な目的に使うために社内で区別する必要がある
SKU はプロダクトの在庫管理のため、プロダクト自体を分類して追跡できるようにするためのもの 個々の顧客に販売したプロダクトひとつひとつを区別することはできない
リリース管理がターキテクチャに与える影響
メッセージやプロトコルはバージョン管理されなければならない
コンポーネント間で送信されるメッセージは内容や処理ルールを管理できるように
データベースやテーブルにはバージョン情報を入れなければならない
ひとつの方法 : スキーマ内の各テーブルのバージョン識別子を含むシステムテーブルを作る
16 章 セキュリティ
ソフトウェアセキュリティは物事を難しくするという点で根本的に違う
セキュリティは成功するソリューションにとってきわめて重要だが、システムが完成する直前まで見落とされがち
ターキテクチャを設計していく中でセキュリティについても検討する必要がある
4 種類のセキュリティについて検討する必要
アイデンティティ管理
認可には静的な側面と動的な側面がある (他のセキュリティ要素と同様)
静的 : 各種権限をどの主体が持つのか
動的 : ユーザー・主体が特定の操作やアクセスをするときに必要な権限を持っているのかチェックすること
認可とアクセス制御を提供するテクノロジーや権限管理システムはいろいろある
LDAP はその最たるものだし、ユーザーのロールに基づく認可制御を提供する RBAC やファイルシステムの認可制御の ACL など 認可制御のためのシステムを分離し、自前の認可制御レイヤで包み込むのはよい考え
トランザクションセキュリティ
目的は、監査可能性、一貫性、機密性、説明性を成り立たせること
監査可能性 : 認証が必要
一貫性 : 情報の改ざんや改変を検知するためにダイジェスト関数を使うなど
機密性 : 権限のない人が情報を見られないようにする
説明性 : 否認防止の仕組み
電子署名されたメッセージが保存されていれば、それを送信したのはその秘密鍵を持っている人であると後からでも証明できる
ソフトウェアセキュリティ
ライセンスチェックが単純な if 文だとクラッカーにディスアセンブラされて検証コードをスキップするよう改変されるので、クラッカーを騙すためにはより難しいコードでの検証が必要
情報セキュリティ
情報セキュリティの一番の対策は一か所からしかアクセスできないようにすること
ネットワーク装置としてのファイアーウォールや侵入検知システム、パスワードポリシーチェッカーなどのユーザー管理システム
パスワードについては、生のパスワードを保存しない
あるいは、インターネットからはアクセスできないローカルファイルシステムに保存する
セキュリティレベルを上げることはできるが、100 % システムを守れることは決してない
一般的に、知られていないことによって成り立つセキュリティはセキュリティの形態として最弱のうちのひとつ
補遺 A : リリースチェックリスト
補遺 B : 戦略的プロダクトマネジメントのためのパターン言語
プロダクトマネジメントパターン
資料集
ソフトウェア開発における人やプロジェクトの管理
ソフトウェア開発におけるプログラムコードと関連する技術
プロダクトマネジメント・プロダクトマーケティング
定評のあるビジネス書
ソフトウェアアーキテクチャ