『ビヨンド ソフトウェア アーキテクチャ』学習メモ

設計

前書き

  • solutionをうまく構築し維持するという目的
    • business 課題を理解し，受け入れていく
    • 幅広いbusiness上の課題とarchitecture上の選択との関係について議論する
    • 誰かに価値をもたらし，持続的に利益を上げる
  • techniqueとbusinessの相互関係をmanagement

Ch01 software_architecture

  • software_architectureの定義
    • important module, process, data, structure, component間の正確な相互関係を積み上げたもの
      • どのように拡張できる・されるべきか，どのようなtechnologyに依存しているかも含まれる
    • systemの正確なcapabilityと適応性が決まる
    • → systemの構築や改修のための計画が立てられるようになる
    • 全体的な観点でみることがimportant
  • software_architectureに関する一考
    • 上記の定義と異なり，「人間」や「business」に焦点を合わせる．
    • subsystemは依存性を管理するために設計される
      • developers groups間の依存関係を管理しやすくすることを優先
    • subsystemは人間のやる気や願望に応じて設計される
      • architectureの構築の始まりはやる気や願望の考慮が必要
    • column: 全体感を生み出すsubsystemの設計
      • 自分の仕事に「全体性」や「網羅性」を感じたいという強い願望
    • より上位のarchitectureへの屈服
      • 問題領域のフォースのなすがままになることはbestではない
      • 自身の経験からの影響も重要
    • 美は見る者の目に宿る
      • 設計上の決定に関する美学から一歩引いて考えられるdeveloperはごくわずかしかいない
  • なぜsoftware_architectureが重要なのか
    • 良いarchitectureが長期的な成功には欠かせない要素のため
    • 寿命
    • stability
      • architecture levelで安定していれば，基本部分の手戻りは最小限で済むことが補償される
        • → 全体として実装コストは減少する
    • 変更の度合いと性質
      • architectureにより，systemに生じる変更の性質が左右される
        • 変更や機能追加が容易 → architectureが優れている
    • 採算性
      • technical architectureの採算性は，architecture自体とほとんど無関係
        • marketing, 流通, brandingなどが影響
      • 簡潔で洗練されたarchitectureの方が採算性の高いsolutionの基盤には向いている
    • 社会的構造
      • good architectureは構築しているteamにも影響を与える
      • どのようなprogramming languageを選んでも，それを使えるようにdevelopment_teamを作っていくしかない
      • architectureはdevelopment_teamよりも長生き
    • column: architectureを置き換えるのにどのくらい工数がかかるか
      • 今のteamの半分の人数で1年以内に以降ができそうなら，新しいarchitectureへの置き換えを真剣に検討した方が良い
        • teamを分割し，旧systemの維持と新systemの構築をそれぞれで担うことで，costの増加を最小限に抑えられる
      • 旧architectureにかけたコスト全体の40%~60%はかかる
    • boundaryを定める
      • architectureが最終的に成功するうえで極めて重要
      • business固有の要求を満たすため技術的な境界を構築する
    • 持続可能で圧倒的な優位性
      • most important
      • good architectureならば，技術的に洗練されていて，真似もしにくく，競合に対する持続的な優位性を得られる
      • good architectureならば，usabilityや性能面などにおいてもadvantageを得られるという点もある
  • architectureの構築
    • 振り返りの分析を通じて，deliveryされた現実に合わせて当初の設計を更新し，architectureを説明できるようになる
    • user/developer両方が制限を理解し管理することで，architectureのcapabilityについての自信を深めていく
      • 本物のfeedbackを受け取ることと，それに対して成功に欠かせない変更を行うことを約束することが特徴
    • architectureの最適解を見つけるために代替architectureを探すことは現実的ではない
      • 金銭的余裕がない
        • team_memberの選定時に，十分に経験を積んだ人を選び，代替案の調査をしなくても正しい決定ができるようにすることで対応する
      • 問題の性質や周囲の環境
        • 実用的な意味でのarchitectureの選択肢が限られる
        • 標準的なarchitectureを選択することになる
        • より小規模でより特化したものを調査することは，役立つことが多い
      • 実際にsystemを使用しないとわからないarchitectureの良さ
        • このprocessには長い時間がかかる
    • column: 失敗しそうなことに気づくのはいつか
      • さまざまなarchitectureの経験を積むことで，実装する前に，大きな失敗をしそうな選択肢がわかるようになる
  • pattern, architecture
    • 上記のforceが絡み合うため，初期のarchitectureを構築する際には，完全に実用的なapproachをとらなければならなくなる
    • software_pattern: あらかじめかみ砕かれた知識
    • architecture_pattern: software_systemの基本的な構造を表現
      • まず，architectureの技術的側面を扱う
        • subsystemについて説明し，それぞれの責務を定義し，特定の問題を解くためにどうやって相互作用するのかを明らかにする
      • 問題の特定の側面に的を絞れば，architecture_patternによって，architectureの種類や形式が正しいかどうか判断できる
    • software_architectureを構築する際の実用的なapproachは，文書化されたあらゆるpatternを調査し，状況に合うものを選択すること
      • 必要に応じてarchitectureをテーラリング（仕立て直し）
      • 最終的には，それを動作するsystemの中で実現する
      • systemとarchitecture_patternのgapを埋める
        • たとえば，あらゆるsoftware_architectureは，適切に設計されたinstall/upgrade process，上手く構築された設定ファイルによる恩恵を享受できる
      • これらのapproachをすべて駆使して，成功するsolutionを構築し維持することが目標
  • architectureの進化と成熟: featureをとるかcapabilityをとるか
    • clientの要望するfeatureや自分たちが望むfeatureと，それをサポートするために必要なcapabilityとの相互作用は，時とともにarchitectureがどのように進化していくかを説明する
      • この相互作用は，technologyの継続的な進化とともに起こる
        • clientからのfeedbackは，自分たちの役に立ちそうなtechnologyを見つけたことに起因することがあり得る
        • development_teamがtechnologyを見つけることもある
    • feature(または機能): productが何をするのか・何をするべきなのかを規定する
      • 要求されたfeature全体によって，productの要件が規定される
      • usecaseとしてfeatureを記述すると，featureを特定のcontextに当てはめて表現できる
        • 最も役に立つcontextは，usecase中のactorの目的に基づくもの
        • actorの目的が分かり，systemでその目的を達成できるか分かれば，product managementが価値のある提案をするために必要なデータが手に入る
          • この提案が，business model, license model. price modelの根拠になる
    • featureはmarketingによってはっきりと優先順位づけされているときが1番管理しやすい
    • feature間の技術的な依存関係がdevelopment_teamによってきれいに整理されているときが，1番上手く実装できる
      • 優れたarchitecture: 求められたfeatureを比較的容易に実装できるようにするもの
    • 関係する一連のfeatureを実装できるようにするarchitectureの基本的な能力: capability
    • architectureの成熟と進化の間に起きる相互作用: 時間とrelease cycleを変数とする関数で表現できる
    • 負債の元本: 本来あるべきcapabilityを利用して構築した場合と比較したコスト
    • column: architectureのcapabilityをとるか，featureのagilityをとるか
    • column: entropyの縮小(ER: Entropy Reduction) ～リリースの後に必ず技術的負債を支払う～
  • architectureへの配慮と手入れ
    • 技術動向
    • 技術的負債
    • 既知の不具合
    • licenseの遵守
      • vendorの更新情報は忘れずにreview
  • 一に原則，二に原則，三に原則
    • encapsulation
    • interface
      • 具体的な実装を超えた抽象化
        • e.g. ファイルへの書き込みを抽象化して，抽象interfaceに出力する
        • vendor固有のAPIに存在する「使い勝手の良さ」を諦めている
    • 疎結合
    • 適切な粒度
      • componentが関連するタスクに応じて
    • 高凝集 1つのcomponentやcomponentのgroup内で行われる活動が，どのくらい深く関係しあっているか
    • parameter化
      • IoC(Inversion of Control)
        • componentの制御を外部に任せる
        • frameworkやplugin architectureでよく使われる
    • delay
      • 決定をできる限り遅らせる
  • architectureへの理解を深める
    • development_teamにとって重要な基準: architectureについての知識の確認，説明，communication，修正を，いくつかのやり方で，それもソースコードを読み返すことなくできること
    • teamが「全体像」レベルの抽象度で作業するには，少なくとも1つはモデルが必要になる
    • Rational社の4+1 model
      • logic view
        • 時系列上の1点で，システム開発に登場するobjectやentity間のあらゆる関係性を静的な視点で捉える
        • 概念モデルと，概念モデルをDB schema上で実装したもの
      • process view
        • 並行性や同期化にかかわる設計を説明
      • physical view
        • softwareとそれが配置されるhardwareの対応を記述するもの
        • 高可用性，信頼性，耐障害性，性能といった目的を達成するよりcomponentの分散も含む
      • development view
        • 開発組織におけるsoftwareの静的な構造を表す
    • → n+1 model
      • 各viewを考慮しながらarchitecture上の決定を進める
      • viewがもたらすcommunication上の特性を理解し，必要に応じてviewを使用することが水晶
    • 時間・労力・お金を費やすに足るarchitectureは，比較的安定した問題，問題領域，business modelこれらすべてに関連する技術的solutionの固有の側面などを解決するもの
  • team
    • 初期開発を担当するteam
      • teamの経験が大きな影響
      • できる限り小さいteam
        • communicationのoverheadを最小化し，team内のまとまりを最大化
        • 3~5人まで
    • teamが成長するprocessは，teamとarchitectureが安定するか，経営陣が定めた限界が来るまで継続
    • 問題に合わせてteamの規模と構成を決定
    • teamとsystemのarchitectureが結びついていることが最も重要
  • まとめ
    • software_architectureは全体像に焦点を合わせている
    • team構造とsystem構造は相互に結びついている
    • architectureは技術的な課題にも技術的ではない課題にも関係する
    • architectureが上手くいくための主な要因
      • 長寿
      • 安定性
      • 競合優位性
      • architecture_patternは新しいarchitectureを構築する際の出発点として最適
    • architectureはfeatureとcapabilityとともに進化する
    • architectureには配慮と手入れが必要（庭のように）
    • 一度releaseを終えただけでarchitectと名乗る人間には注意
  • checklist
    • subsystem間の依存関係が明確
    • 同じteamでsubsystemを担当しているmemberは互いに仲が良い
    • 同じteamのメンバーは，誰もが生産性を改善できると考えるやり方で働いている
    • 採算の取れるarchitecture
    • 今のreleaseで取り組んでいる課題が進化のためなのか成熟のためなのか理解している
    • systemにどれだけの技術的負債があるのか理解している．負債が特定できている
    • licenseを遵守してcomponentを使っている
    • architectはarchitecture上の選択を推進するためにarchitecture原則をまとめている
    • teamの規模は，目的を達成するために大きすぎず小さすぎず適切

Ch02 product_development 入門

  • product_managementとは何か
    • 成功するsolutionを構築・維持するために欠かせない包括的な一連の活動
    • software_architectureの全体像より大きなもの
  • なぜproduct_managementが重要か
    • 技術的な正しさだけでなく，価格モデルの決定から有用なパートナーシップの構築まで，相互に関係する数々の複雑な活動が，productを全体として成功させるために必要
    • 成功するproduct_managementは，本当の意味で利益を生み出すproductと企業を作り出す
    • 何よりもclientの声を代表しているために重要
  • product_development_process: 1.0版を作る
    • product_development_process: productに関する1番大きな全体俯瞰図
    • concept提案
      • productを製造するのに十分な動機付け
        • marketの正当性を証明するうえで十分なbusiness dataと，feasibility(faisible: できる)を証明するうえで十分なtechnical dataが含まれる
    • product 提案/ business_plan
      • productの正当性を証明するために作られる主要document
        • きわめて重要
    • development plan
      • marketing_team
        • marketの要望を明確化し，優先順位をつけて，開発するproductが備えるべきfeatureとして表現する
      • development_team
        • feature間の依存関係を分析してarchitectureに求められるcapabilityを見極め
        • さまざまなタスクを完了させるのに必要な時間のざっくりとした見積もり
        • 技術solutionの評価
        • 必要なresourceの整理
    • development
      • すべてを1度に開発するわけではない
    • 最終品質保証
      • すべての基本はテスト
      • column: 自動化の目隠しに注意
        • 自動テストと最終品質保証は共に必要
        • multi platform developmentには，慎重なresourceの割り当てが必要
          • 最も主流で重要なplatformをdevelopment_teamが2・3選んで，それに基づいてsoftwareを作り，テストする
          • 最終品質保証がそのほかの環境でsoftwareの動作を確認する
            • 環境を再構築し直すコストの節約
            • 顧客の実際の環境を再現するための投資を避けて，資金の節約
        • 最終品質保証によりセキュリティテスト
    • 稼働準備
    • 本番稼働
  • よくある誤解への回答
    • waterfallと比べて，productを修正するかどうかを判断するための厳格な評価基準がある
      • stagegate
    • concept提案とproduct提案/business_planは決して欠かせないstage
  • business_plan
    • productに関係するあらゆる作業の基礎
    • 最初のarchitectureを構築するよりも前に策定する
    • すべてのreleaseに必要というわけではない
    • 表2.1: business_planの書き方
  • product_development_process release n.n.nの構築
    • product_development_processは，初回release語に一番変化する
    • conceptやproduct提案は省略されることが多い
    • business_planは，せいぜい，新規releaseの内容を反映するだけ
    • MRDはreleaseに関する中心的なdocumentになる
    • 稼働準備phaseや本番稼働phaseに求められることが，releaseによって全く異なる
  • product_development_processの補強
    • 段階的な凍結
      • 凍結: 正式な変更管理processを通じてのみ変更できるようにする
    • 変更管理protocol
      • 変更が行われる前に適切な人物に情報を与え，しっかりと準備できるようにすることが目的
      • 変更から影響を受けるstakeholderを絡める
        • 変更内容について理解し，承認し，正しく処理するため
      • 変更管理meetingは，product_management_teamが準備して仕切る
        • product中心でない組織では，project_managerやprogram_managerが準備して仕切る
    • column: document作成のバランス
      • 初期releaseは，できるだけagileなprocessで構築する
      • 成熟したproductを持つようになった開発組織は，agile_processよりも適切な，形式的なprocessへと以降
    • recycle_box
      • 有用かもしれないideaは，将来余裕ができたときのために蓄えておくrecycle_boxに入れる
      • 求められたfeatureをすべてreleaseしなければならない，というdevelopment_teamが感じるpressureを軽減する圧力弁になる
  • product_managementの重要な概念
    • marketingの4つのP
      • product
      • price(およびbusiness_model)
        • business_model: productやserviceでclientから対価を得る方法
        • business_modelに紐づく価格決定モデルによってpriceが決定
        • product_managementの中で最もやりがいのある課題
        • 効果的な価格設定は，心理学的な側面が強い
      • place(販売channel)
        • bitの集合であるsoftwareをどのように提供するか
        • productやserviceを提供するk十を誰が承認するか
        • system_architectureに影響を与える
      • promotion(広告とmarketing communication)
    • 有効市場(total_available_market)，有効市場規模(total_addressable_market)，market_segment
      • total_available_market: 利用する可能性のあるすべてのclient
      • total_addressable_market: 有効市場において対象にできる市場規模
      • 効率的なmarketing programは，total_available_marketを明確なmarket_segmentに分割する
      • market_segment: 共通する特別な性質を有するclientのgroup
        • client簡易交流がある
        • 効率を追及するなら，market_segmentをニッチ市場に分割
    • 受け入れのS字カーブ
      • カテゴリを理解することで，product_managementや関連するmarketing活動によってカーブの形を調整できる
      • カーブの形はinnovationの性質に応じて大きく異なる
      • innovator
        • 限界を超えることを好む
        • 動かすために必要なresourceを自由に使えることが多い
      • early_adopter
        • 限界を超えることを好むが，やや保守的
        • より完璧なproductを期待する
        • より多くの要素を望む
        • 全体的な成功を収められるかどうかの試金石
        • meritを納得させられれば，成功するsolutionの基礎が完成といえる
        • innovatorとearly_adopterの間のギャップを埋める: chasmを越える
      • early_majority
        • 価格性能比が争点
        • clientの成功事例やROI分析などの実証を求める
      • late_majority
        • 無視できない経済的圧力がかかるときに受け入れる
        • early_majorityに受け入れてもらったときに比べると，経済的利益ははるかに少ない
      • laggards(lag: 最後の人)
      • innovationを受け入れる理由: innovationがclientの抱える問題に対して何らかの効果をもたらすと感じるため
    • whole_product
      • 汎用製品，期待製品，拡張製品，潜在的製品の4つの概念が合わさったもの
      • target_productが上の4つを遷移していく
    • 技術的優位性と市場優位性
      • 市場優位性の方が強力
    • position, positioning
      • position: clientがproductを現在どのようにcategorizeし，認識しているかを，冷静に客観的に正確に算定したもの
      • positioning: clientの気を惹いて記憶に残るような独自の印象を生み出すための，戦略的に管理される活動
        • 未来のことが対象
        • 潜在顧客がproductを自然と思い浮かべるようにする
        • 長期的，戦略的，防衛的で所有可能なもの
        • 1つのconceptにだけ集中できるようにするもの
      • 技術的marketでは，positioningはpositionより重要
      • positioningを設定したら，何度もその目標に向かってpositionを作り直していく
      • column: effective positioningが購買動機に与える影響
        • positioningは，development_teamを含む全員にとって，魅力のある未来を創らなければならない
        • 記述形式
          • ＜魅力的な購買動機＞を持つ＜target client＞のために，このproductは＜主なメリット＞を持つ＜product category＞だ．
          • ＜主な競合＞と違って，＜主な差別化要因＞である．
    • brand
      • clientと交わす約束
        • → 重視される
      • partnership, customer support, 企業のWebサイトの性質や構造，clientに提供される商品やserviceの品質，利益を管理する方法などが，どれもbrandに反映される
      • 用語，symbol，slogan，名前など様々な要素を通じて表現され伝えられる
      • 知的財産として保護されていることが多い
    • main_message
      • positioningをcreativeに表現する短い(1,2 phrase)の文章
      • positioningを強化し，かつclientは確実に手に入るものを表す
      • press releaseから広告まで，あらゆるcreativeなmarketing communication活動を駆動するために重要
      • client中心
      • 重要な利益を表現する
        • なぜ注意を払う必要があるか，またはproductが問題をどうやって解決してくれるかをclientに伝える
      • 正確で，productが実際にsupportしているもの
  • まとめ
    • product_management: 成功するsolutionの構築と維持に必要な活動の包括的なまとまり
    • 初版のsoftware productの構築は，productを正当化するconcept提案に始まり，本番稼働に終わる
      • より幅広く包括的
      • そのあとに続くreleaseを構築するprocessはより軽量で，最初のreleaseの間に作られた素材を元に構築される
    • product_development_processがうまく運営されているかどうかは，各stageに厳格な「可／不可」の判断があるかどうかでわかる
      • そのあとに続く凍結が変更管理protocol，recycle_boxの考え方などによって強化され，改善される
    • business_planは，product_developmentを進めることを正当化する中心的なdocument
    • marketingの4つのP
    • 最大有効市場
    • 最大標的市場
    • market_segment
    • 受け入れのS字カーブ
    • whole_product
    • position, positioning
    • brand
  • checklist
    • 要件を表現するための何らかの仕組みを定義している
    • product_management_teamはclientの声を代表している
    • 企業にはproject, productを打ち切る方法がある
    • 競合他社が何を行っているか理解している
    • 勝つためには何を行うべきか理解している
    • productを誰のために構築しているのか，誰に売り込んでいるのかを理解している
    • 便利な変更管理protocolがある

Ch03 marketecture, tarchitecture

  • systemのmarketing的側面と技術的側面が一緒になってbusinessの目的を達成するさまを見る
  • 誰が何に責任を負うのか
    • tarchitect
      • software_architect, chief_technologist
    • marketect
      • product_marketing_manager, business_manager, program_managerなどシステムに責任を持つ人
    • tarchitecture: developerがsystem architectureを検討するときに参考にする主要な枠組み
      • software_systemを成立させるためのsubsystem, interface, 処理要素への責務の分割, thread modelなど
    • marketecture: system architectureに関するbusiness的な観点
      • business_modelに関するあらゆる物事を含む
        • license_model, 販売 model, value proposition, clientに関係する技術的な詳細, data sheet, 競合他社との差別化要因, brand要素, marketing_teamがclientのために用意しようとしているmental_model, systemに固有のbusinessの目的など
        • MRDやusecaseも含む
      • whole_productで説明されていたもの
    • column: 5万ドルのboolean_flg
      • marketecture, tarchitectureの違いを活用し，product_management_teamもengineering_teamも，さまざまな技術的な課題やbusiness的な課題を解決するのに最善と思われるapproachを柔軟に選択できる
  • solution_developmentの初期に現れるフォース
    • 図3-1: software_architectureを形作るフォース
    • 非機能要件
      • architectureに関する様々な品質や特性
      • 実行時にシステムを観察して見て取れるかどうかで二分
        • performance, usability
          • target_clientの意向が直接反映
        • testability, 修正可能性
          • target_clientとの将来の関係を左右
          • 明示されないので規律がきわめて重要
      • 技術的な妥協がもたらす潜在的な危険度を測るためには経験以外にない
        • tarchitectは少なくとも2回は完全releaseを経験する必要
        • productの整合性に対して長期的に関わり続けなければ，妥協を取り除いたことを確認できない
    • technology base
      • super tarchitecture
        • applicationの基本構成を規定
      • 問題領域から導かれるtarchitectureに対応したものである必要
    • 問題領域
      • 成功するsolutionを構築するための中心的フォース
      • marketect: market needsを明確化し優先順位をつける
      • tarchitect: そのneedsを満たす技術的なsolutionを構築
        • 領域における経験も設計に組み込む必要
        • 広範囲な領域の知識がほぼ必須
          • 特定の領域でsystemを構築した十分な経験と，成し遂げる十分なskillが必要
    • column: 時には難しいやり方でやるしかない
      • clientと長期間ともに過ごす
    • column: バグの深刻度，優先順位，標準化
      • bug review meeting
      • 品質の基準をあらかじめ決めておく
  • 長期的に稼働しながら短期間で結果を出す
    • clientが18か月から24か月先に求めるものをイメージするため，さまざまなデータを検証する
      • それ以前は現在なども過去のこととして捉える
    • 未来を想像できることはmarketectにとって重要な指標
    • tarchitectも同様
  • 将来像を示す
    • market_map
      • feature/merit map
      • market event/market rhythm
    • tarchitecture_map
      • 既存のtarchitectureではサポートできないだろう重要なfeatureを，核心的featureとして記録
        • 導入のために必要な変更を管理する必要
  • feedbackを利用する
    • marketect
      • user conference, technical/product support review, featureへの要望のreview, 販売担当者にinterview, main clientなどとmeeting, analystなどとmeeting
    • tarchitect
      • conference, magazine, mailing list, 自宅のPC, 好奇心
    • mapをメンテナンスし続けることでcommunication
    • column: 言ってはいけないことを言ってしまったら？
      • 本当に心配ならguidelineを示す
        • リスト
  • はっきりさせる
    • marketectの一番の目的は，development_teamのメンバが何を構築するべきかを正確に理解することで，その責任を負う
    • teamの規模と必要不可欠な外部とのやり取りの数によって，適切な構造・process・成果物を決定
    • marketectは，潜在顧客に対しても，systemが彼らの環境に与える影響をはっきりさせる必要がある
    • column: software developmentにおける文化的差異を管理する
      • 文化的差異に注意して，特定の文化でうまくいくapproachやprocessを選ぶ
    • marketectはtarchitectからの適切な情報の流れに強く依存する
  • 一致団結して作業する
    • tarchitectの創造的なenergyを，現実の顧客の現実の問題を解決することに向けられるようにすればよい
    • 合意形成
      • projectを推進するための原則を決め，それらについて合意する
    • dataが手に届くようにする
      • map, featureの可視化
  • context_diagramとtarget_product
    • context_diagram
      • marketect, tarchitectが協調するうえできわめて有用なtool
      • 重要な要素間の関係を表現することに注力する
  • まとめ
    • marketectはmarketectureに責任を持つ
    • tarchitectはtarchitectureに責任を持つ
    • marketecture/tarchitectureはそれぞれ異なるが関連し合っている
    • solution_developmentの初期ステージにおいて，特に影響力のある3つのフォース
    • architectになるための経験
    • bugの分類
    • productとその発展を示す戦略的なビューを作る
    • context_diagram
  • checklist
    • marketectがいる
    • tarchitectがいる
    • bugを深刻度と優先順位に従って分類できるDBがある
    • market_map, feature/merit map, market event/market rhythm map, tarchitecture_mapを作っている．誰もが簡単にみられるところにある
    • clientと対面する機会のあるdeveloperは，言っていいことと悪いことについて適切に訓練されている
    • marketectがsystemのcontext_diagramを作成した

Ch04 businessとlicense_modelの共益関係

  • business_model: product/serviceに関してclientに料金を請求する方法
    • あらゆるbusiness_modelにlicense_modelが結びついている
  • license_model: 利用規約，business_modelにより規定される
  • 同じphraseで両者を説明する短い文章を簡単に作れると，2つのmodelの共存を示せる
    • 2つのmodelは同じものではない
  • それぞれのtarget_marketに対して，market_shareと収益を最大化するための組み合わせを検討するべき
    • business_model, license_modelについての原理と，所定のtarget_marketでそれがどのように機能するか理解が必要
  • controlを手放さないためにlicenseが必要
  • business/license modelはmarketectureの重要な要素を体現したもので，tarchitectureにも大きな影響がある
  • column: business_modelの境地
  • 一般的なsoftware_business_model
    • column: application?suite?bundle?feature?
    • 時間ベースのアクセスや利用
      • 恒久license
        • supportや保守に関する全体的なコストが増えるため注意
        • 潜在的な欠点があるにもかかわらず一般的
      • 年間license
        • enterprise systemで一般的
        • target_marketに最適な期間を定義して，business_modelとlicense条項を適切に施行できるようにすることが難しい
      • rental_license
        • licenseが与えられた時点で使える時間が設定されているもの
        • 年間licenseもこれの一部
        • 重要な課題
          • いつから期間が始まるか
          • 期間が終わったらsoftwareはどう反応するべきか
          • 価格
      • subscription
        • upgrade, supportの権利がある
        • 何らかのbackend_serviceと結び付けられていることが多く，比較的簡単に強制できる
      • 後払い
        • tarchitectureに対して複雑なことを要求するが，softwareが利用された分のお金を必ず受け取れる
        • modelの成熟に伴い一般的になっていくもの
      • 利用者単位のlicense
        • volume_license
          • enterprise向けのapplicationには適切
      • OEM(Original Equipment Manufacturer)
        • business_modelはsoftwareへのアクセスに基づく
        • royaltyとして正当な金額を設定
    • transaction
      • あらかじめ定められた計測可能な処理の単位
      • 主にenterprise_softwareにおけるbusiness_modelで使う
      • marketectがtransactionを定義して，target_marketに対して最適なtransaction料金を組み立てる
      • tarchitectは，transactionの定義に関する法的な要素と，business_model的な要素の両方の理解が必要
      • column: good, but how to claim?
        • product/serviceの価格設定は，marketectの最も難しい課題の1つ
        • 原則
          • 価格には価値を反映
          • 価格にはかかった労力を反映
          • 価格にはpositioningを反映
          • 価格には市場勢力図を反映
          • 価格モデルはclientを混乱させてはいけない
          • 価格モデルはmarketの成熟度を反映
          • 同じproductの価格は下げるよりも挙げる方がm図鵜香椎
          • 価格モデルはtarget_marketの特徴を反映する必要
    • metering_model
      • 明確に定められたresourceやapplicationの処理内容に関する制約，あるいはそれらを消費することに基づくbusiness_model
      • 制約model
        • 既定の量のresourceにしかアクセスできないようにする
      • 消費model
        • 消費可能なresourceのpoolを作り出す
        • 消費しきると使えなくなる
      • 並行resource_management
        • e.g. user, session
        • 同時並行resource_management_model
          • @enterprise_software
      • 個別resource_management
        • systemが認証した場合にのみアクセス許可
        • 制約: resource
        • 同時並行resource_management_modelとの組み合わせ多い
        • 管理上の負担
          • 既存のdirectory infrastructure, user management infrastructureにより軽減
      • 消費resource_management
        • 課題
          • 時間の定義
          • softwareがresourceの消費を追跡する方法
          • licenseする時間の単位
        • subscriptionにも〇
        • 重大な要件
          • reporting
          • 補給
    • hardware
      • softwareにかかる料金をhardwareに結びつける
    • service
      • open_source_licenseが使われることが多い
        • marketは未成熟で未検証
    • 得られた収入/節約できたコスト
      • 歩合制
      • 本当はいくら支払うべきか追跡するのが困難で，not popular
    • column: open_sourceだからといって無料なわけではない
      • business_modelとlicense_modelの分離の恩恵の例
  • business_modelに関連する権利
    • 権利と制約ができるだけ多くなるように区別することで，より大きな価値を生み出せる
    • 図4-1: license_modelのsubsetの検討
      • 1.競合に対する優位性が得られたり，technical supportやproduct supportのコストを削減できたり，またはclientとの関係を強化できたりするのであれば，businessにこの権利を関連付ける
        • 逆にclientに関心がなかったり，厄介ごとを負わせてしまうものはやめる
      • 2.transactionに基づくbusiness_modelに含まれるべき権利
        • upgrade, bug fix, patch
      • 3.clientに受け入れられた場合は権利を関連付ける
        • hardwareではclientの権利を制限する理由がある
  • business_modelに対するtarchitectureのsupport
    • 一般的な課題
      • 必要なデータの収集
        • direct
          • systemは，business_modelに必要なデータをすべて収集し，管理している
          • 要自己完結
        • indirect
          • 必要なデータから全体像を組み立てるには，1つ以上のほかのシステムと統合が必要
      • 請求．送金に関する要件
        • 送信内容に関する書式，セキュリティ，監査の要件を定義することで簡単になる
      • business_modelの強制
        • license違反をした場合について
      • 品質特性に注力する
        • 品質特性: trustness, stability, scalability, ease of support, usabilityなど
        • 実現するための努力が，business_modelにとっての主要な目標と一致していれば理想的
        • softwareの使われ方はtradeoff
      • 収益の増加，あるいは，削減したコスト
      • 複製の防止・著作権侵害行為への対策
      • business_model, license_modelに関するparameterの妥当性検証
        • いつどこでどのように設定されるか，誰が変更できるか，妥当性をどのように検証したのか理解
    • 時間ベースのアクセスや利用
      • tarchitectureに課せられる特別な要件はそれほど多くない
      • ただし，厳密に強制する場合は，期間を過ぎたらsoftwareを無効化する仕組みが必要
      • ほとんどはupdateを受け取れなくなるだけ
    • transaction
      • transactionを定義
        • business_modelの基礎．明確さが必要
        • 定義後は，tarchitectureがそのbusiness_modelに対応できること，そしてlicenseに明記してあることを確認する
        • transactionに対して各componentがどのような役割を果たしているか考慮
      • transactionとbusiness_modelの関係を定義
        • 完了した個々のtransactionを確実にbusiness_modelへ対応付ける
      • 監査証跡を残す
      • transactionが一意に識別できるようにする
        • DBに任せず，信頼できるalgorithmで本当の一意の識別子を生成する
          • UUID, GUIDなど
          • 短縮も〇
      • transaction state, lifecycle, 継続期間を理解する
        • 請求のタイミング
    • metering
      • どうやってユーザを認証するか
        • 多額のお金を引き出すものであれば，LDAPなどユーザ認証のための確立されたinfrastructure technologyを組み合わせるべき
      • ユーザは何人いるか
        • 設定値の管理
      • 同時並行ユーザをどう数えるか
      • ユーザはいなくなったことにするのか，または非活性にするのか
        • session_management
        • 消費resource_managementを実施する場合は，tarchitectureに厳しい制約
          • ある種の状態の記録
      • hardware
        • 定義と強制方法が必要
  • license_modelを強制する
    • 自己申告制
      • 権利を放棄しているわけではない
      • 要因の注意深い分析が必要
      • enterprise_softwareでは，licenseを更新するたびにclient担当者が直接clientと話す機会があるので，購入を促すこともでき〇
      • consumer_softwareでは×
    • 自家製license_manager
      • licenseの費用に応じて専用のsolutionと比較する
      • sessionに基づくlicenseの場合は，自家製のlicense_managerのような仕組みが必要
      • column: 絶対に突破できないものでなくてよい
        • 正直者に嘘をつかせない仕組み
    • third_partyのlicense_manager, 専用のlicense_manager
      • license_generator
      • client
      • server
      • injection方式
      • API方式
      • license_managerの評価における課題
        • business_modelのsupport
        • platform, OSのsupport
        • solutionの強度を判断するために脆弱性情報を調査
        • backendとの結合，および処理量のcapabilityを確認
        • 運用環境との適合性を確認
        • brandingとuiの統制を確認
          • 国際化など
        • licenseの内容と形式を調査
          • 電子的署名
        • licenseの配布方法を調査
  • marketの成熟度がbusiness_modelに与える影響
    • target_marketの成熟度は，business_modelの選択や管理に一番影響する要因の一つ
    • business_modelの強制度合いも，target_marketの成熟度と足並みを揃える
    • business_modelを選択する
      • marketectが直面する最も困難な課題の1つ
      • target_marketは何か？その価値は？
        • どのように使ってもらいたいか
      • target_marketにおける目的は？
        • shareの確保，維持など
      • business_modelは何か？
      • どのような権利を与えたいか？
      • business_modelはどのような影響をarchitectureに与えるか？
      • 価格モデルはどうか？
  • まとめ
    • business_modelとはお金を生む方法
    • business_modelとlicense_modelは結びついている
    • license_modelとは，softwareの使用にかかわる条項，条件
    • software_business_modelがお金を生み出す方法一覧
    • userに関係するbusiness_modelによって，ユーザを管理する企業システムとの統合が促進
    • business_modelに関連する全ての権利を理解
      • 権利を分割することで，利益を生む可能性が高まることもある
    • license_modelを強制するには，自家製のlicense_managerか，third_partyの専用license_managerを使う
  • checklist
    • development_teamのメンバー一人一人が，現在のbusiness_modelや将来に向けて真剣に検討されているbusiness_modelを説明できる
    • license_contractがbusiness_modelと一致している
    • license_contractによって，clientに提供される権利が一式定められている
    • business_modelを強制するための，適切な仕組みを選択している
    • 別のbusiness_modelをsupportするためにtarchitectureを変更するcostにすいて，marketectと話し合い，理解してもらえている

Ch05 in_license technology

  • license_contractのriskと見返り
    • (merit)
      • (risk)
    • 複雑さやリスクの削減
      • 責任がproviderに移り，依存性が高まる
    • component化
      • technologyとsolutionとの結びつきが強いと変更が難しくなる
    • system構築がはかどる
      • 設定が複雑になりうる
      • 互換性の問題
      • license上の制約が増える
    • 特許によって保護されたlicenseにより，法的に保護
      • 補償からの免責を勝ち取ることが難しい
    • technologyのreuseによるmarket投入までの時間短縮
      • 必ずしも短くはならない
    • 品質
      • 必ずしも高くはない
    • 軽量，最適化
      • そうでない場合も多い
      • 調整困難
    • technologyの流行を追う苦労の軽減
      • 必ずしも素早く更新してくれるわけではない
    • 費用
      • 不要な費用になるかもしれない
    • service/support cost
      • 外部から導入したことによる新しいエラーへの対処が難しい
      • 適切にsupportできるか確認する必要
    • column: 他人の書いたコードを修正してもらう
      • vendorとの協力が重要
  • contract: どこで何を約束したのか
    • technologyのlicense取得の核心: 使用に伴う規約を定義した契約を交わすこと
    • contractの基本
      • 申し込み
      • 受諾
      • 約因
        • 両者の間で取り交わされるあらゆる価値
    • license条項
      • 定義
        • licenseの契約書に記されたあらゆる重要な項目や条項に関する正確で法的な説明
      • 使用あるいは許諾
        • 外部から導入したtechnologyの使い方に関するもの
      • 期間や条項，その他の重要な日付
        • 契約の開始と終了に関すること
        • 有効期間
        • 期日
        • 支払日
        • 試用期間
        • 解除通知
        • その他
      • column: 高くついた更新費用
        • 更新期限の意識が重要
      • 領域
        • 特に地理的な制約
      • 特定の用途
      • 独占権
        • ほとんどの場合では不要
      • sub_license
        • 組込technologyで必要
      • 終了，解除
        • 予告期間はできるだけ長い期間にするよう交渉する
          • 置き換えに時間がかかるため
      • 更新
        • 自動更新は非推奨
      • 料金または支払条項
        • tarchitectureが必要な支払条項をsupportしていることが重要
      • deploymentの制限事項
      • その他の一般的な制限事項
        • できないことも慎重に定義されている
        • いずれもtarchitectureに影響を与える
      • 競合禁止条項
      • source_codeへのアクセス
        • 第三者機関がsource_codeの複製を委託されていても，結局管理できなくなっていれば意味はないことが多い
      • marketingの要件
        • 注意深く読む必要
        • tarchitectureにとって好ましくない影響を与える可能性もある
  • business_modelの衝突→交渉の始まり
    • 自分たちのbusiness_modelがvendorのbusiness_modelと整合していることをlicense取得前に確認
    • 不整合 → 妥協点を交渉
      • tarchitectureに重大な影響
  • license_contractの遵守
    • tarchitectureに影響を与えるもの
    • technical用語の定義
      • license_contractを遵守するうえで最も重要
      • 実際のproductを反映
      • version number
      • OSや運用環境の定義
      • business_planに従って，productを利用する権利がある
    • API
      • 公開できるかどうか
    • support
    • branding
  • in_license technologyの管理
    • wrapperのコスト
  • open_source_license
    • licenseの詳細の確認
    • productへの統合の仕方を定めている部分の確認: 最も重要
      • open_sourceの定義のバージョンを確認
  • license_cost
    • vendorのbusiness_modelが反映されていることを考慮する
    • 先払い
      • tarchitectureへの影響は最小限
        • technologyをsystemに統合するうえで最大限の柔軟性があるため
    • 使用量
      • tarchitectureに影響がある
      • 実現しやすい
    • 収益に対する割合
      • tarchitectureには景況が小さいが，marketectureには影響が顕著
    • 交渉の戦略
      • productを陳腐化させない
      • 価格付けを守る
      • milestoneごとの支払い
      • column: 価値に基づく費用交渉
        • moduleごとに価格設定を別にする
        • system全体の費用を体系化
      • 研修コストと開発コスト
  • licenseの収益構造
    • 収益構造を理解してリスクを事前に検知
    • in_license契約のコストをproduct planやbusiness_planに組み込むことの重要性
  • まとめ
    • どんなシステムでも，in_license契約のtechnologyを含む場合がある
    • 効果的なin_license契約のためには，marketectとtarchitectの両者が，リスクと対価について完全に理解する必要がある
      • 強い立場で交渉に臨める，より有利な契約を結べる
    • in_license契約はどれも，marketectureとtarchitecture両方に，direct/indirectな影響を与える
    • あらゆるbusiness_modelと整合させて，solution全体を組み立てる
    • in_license契約したtechnologyの管理には，さまざまなtechniqueが必要
      • 本質的: tarchitectureとtechnologyを分離する
    • 費用の取り決めと，license_contractに関連するコストの理解が必要
    • open_source_licenseのtechnologyの進化
  • checklist
    • licenseを取得したcomponentやtechnology全てについて，妥当な契約を交わしているか
    • in_license契約に関する主要な利用規約を理解しているか
      • 契約違反の原因になる行為を全て確認し，気づかないうちに破ってしまうことがないことを確認
    • licenseを取得したcomponent, technologyを置き換えることの影響を評価したか
    • licenseを取得したcomponent, technologyと，productのbusiness_modelは互換性があるか

Ch06 portability

  • portabilityのmerit
    • 〇複数のplatformに対応すれば，新しいmarketに参入できる
      • segment分割を上手くやることが長期の成功のために重要だが，これはplatformでのsegment分割ではなく，clientの問題を基準にするべき
      • 普通はbusiness課題によってplatformが選択される
    • そのほかはportabilityを追及するための根拠となるmotiveが適切なことはあまりない
    • 本当にportable applicationなら，platformに依存したfeatureが生み出されないように設計される
  • portabilityに関連するbusinessの事例
    • cost大きい
    • target_marketが十分に大きいときのみ，コストを正当化できる
    • cross_platformの条件
      • market分析の結果，複数のplatformに対応したproductを開発・サポートし続けていくコストを正当化するだけの十分な収入が見込める
      • supportするすべてのplatformについての開発・テスト・サポートにかかるコストの合計が考慮済み
      • 対応する複数のplatformについて，構築・テストするための人員を確保できている
      • supportしなければならないさまざまなplatformの開発活動に与える相対的な影響を理解し管理できる
    • applicationを移植可能にするより，technologyを移植可能にする方が説得力がある
      • technology: より大規模なsolutionを構成するための部品として設計されているsolution
    • 結局はtarget_marketがはっきりしているかどうかが重要
      • → development_teamがapplicationをどのように作るべきか決める
    • column: portabilityはお金のためでしかない
      • 単独のplatformでしか動かなくても素晴らしいsolutionであることが重要なcase
      • core technologyとしてportabilityが重要なcase
  • portabilityのあるapplicationの構築
    • interpreter_languageを使う
      • 実行環境との結合を疎にする豊かな絶縁層があるため
      • compiler_languageの場合は，条件付きinclude/compileが必要
    • 標準的なpersistence_storageを使う
    • business_logicを移植可能にする
    • 利用者へ寄り添うことで失われる可能性
      • portabilityに最大限の投資をするなら，backendやinfrastructure
    • subsystem間の相互運用性と標準化のためにXMLを使う
    • portabilityの名のもとにplatform固有の能力を埋もれさせるのは×
  • 苦痛のmatrix
    • 苦痛の最小化のために，developerや品質保証チームにmarketにおけるportabilityの相対的な優先順位を伝える
    • 優先順位づけのtechnique
      • developerや品質保証チームが利用する，marketありきの構成のmatrix(苦痛のmatrix)を作ること
        • all pair法の変形でもある
      • step1: 構成を減らす
      • step2: 組み合わせをランク付けして並びかえる
        • 理由となるもののリスト
        • red/yellow/blueに背景を分ける
      • step3: final_cutを決める
        • clientの環境の分布について情報収集し，パレート図にする
      • 初期段階における組み合わせと優先順位を，marketの特徴から自動的に算出する方法が必要 → all pair法
        • marketからの要求を満たしているかreviewは必要
  • 約束には用心する
    • 契約上の管理とサポートする対象にはくれぐれも用心する
      • 「以降」などは×
      • 販売した後のことも配慮する
      • 対応するversionとplatformは具体的に明確にするべき
  • まとめ
    • portabilityを求めるためには適切な理由が必要
    • portabilityのあるapplicationが欲しい理由も，それを構築したい理由も，実際は大したことではないことが多い
    • portabilityのあるapplicationを作るためにbusiness上の正当な理由があるとしたら，それは利益が出るということのみ
      • costを正しく見積もる
    • portabilityのあるapplicationを作るのは考えているよりもずっと困難で，長い時間がかかる
    • 苦痛のmatrixはtestしなければならない組み合わせを網羅
      • 無意味な組み合わせ，対応しない組み合わせを取り除く
      • 優先順位をつける
      • reviewを実施してfinal_cutを決める
    • supportする構成を常に明確にする
      • 新しい構成をサポートする場合は慎重にすすめる
  • checklist
    • 対応しているそれぞれのplatformについて，開発，品質管理，技術サポート，営業のresourceが足りているか
    • 対応しているそれぞれのplatformをテストするのに十分な時間をかけているか
    • productが動作するplatformのvendorによって提供された重要なreleaseが，technology loadmapに追加されているか
    • テストに費やす労力を最適化するため，market_drivenな構成matrixを作っているか

Ch07 deployment_architecture

  • deployment_architecture: clientが自分の手でsystemをdeploymentするやり方のときに使う
  • deploymentの選択肢
    • client site
      • clientのmachineにinstall
      • client自身が設定，運用，保守
    • application_service_provider(ASP)
      • 限定されたサービスを提供．完全なsolutionを提供することはほぼない
    • managed_service_provider(MSP)
      • ASPの拡張
        • 提供だけでなく運用も行う
        • ASP: 汎用/期待product
        • MSP: 期待/拡張product
      • 非常に特殊なhardwareを必要とするニッチなmarketに焦点を合わせている
      • ASP/MSPとも，SLAの締結が一般的
      • 少なくとも何らかのclient dataはservice providerの所有する機材に格納されてしまう
    • transaction(Web service)
      • 単一の完全なtransactionで応答を算出
      • Web service protocolを介して実行されることが多い
      • 個々のユーザに向けてサービスを提供
    • column: hybrid deployment_architecture
  • deployment_architectureにおけるclientの影響力
    • clientの期待に見合うdeployment_architectureの選択は重要
    • management, integration
      • systemをonsiteで運用しているのと変わらない水準で管理できることが重要な場合
      • 長期間にわたるデータの保全と管理
      • marketectが，clientが最も重要と考える管理面での課題を理解する必要
      • integrationへの要求が増えると，systemがclient siteにdeploymentされる可能性も高くなる
    • security, privacy, peek_load(ピーク負荷)
      • systemの扱うデータの性質に応じてdeployment_architectureに対するclientの印象は異なる
    • cost, vendorへの信頼
      • solutionの販促素材は，単にsolutionの利点を示すだけでなく，marketにおける長期的な生存可能性を示す必要がある
        • 生存可能性テスト
      • clientのデータをどのように保存し維持していくかが関心の的
        • いつでも古いデータが取り出せるとclientに安心してもらうことは，solution全体を設計するうえで重要
    • clientのskillと経験，地理的な分布
      • applicationとそのdeployment_architecture次第で，client企業に求められるskillや経験が変わる
      • clientの要求だけでなく，client企業の目的もよく理解できるようにつとめることがとても重要
    • column: credit card informationを粗末に扱わない
      • 運用管理の手順について慎重なreviewと監査を要求する権利がxSPに対してある
    • column: riskが大きくなり過ぎたときは
      • 諦めて成功するsolutionをしっかり構築するべき
  • 企業がdeployment_architectureに与える影響
    • 持続可能な成功するsolutionのためには，marketectが利用する企業の様々な事情を理解する必要がある
    • sales_cycle
      • 売り上げを算出するまでにかかる期間や手順
      • 価格やsoftwareの複雑さと相関
      • もしsales_cycleの短縮に取り組むなら，xSPとしてdeploymentすることや，正式な審査の元にlicenseすることを検討する
    • infrastructureへの投資
      • 長期的なサービスを提供し続けるためにどれだけの投資が必要になるか注意深く考える必要
      • 投資額の計算には技術的resourceと非技術的resourceをともに含める
      • 信頼できるinfrastructureを構築するための資金がない場合は，xSPやWebサービスの運営は×
    • cash_flow
      • 余剰資金を管理するための確実なアプローチが必要
    • 柔軟性
      • xSPやWebサービスでは管理の主導権がある
        • upgrade scheduleなどをかなり柔軟に予定できる
      • 新規市場では政調のためにrelease_cycleを素早く回すことは欠かせないし，必要なときに必要なだけupgradeすることもできる
    • 地理的な広がり
    • 価格よりサービス
  • softwareのdeployment_architectureを選択する
    • 図7-1: clientと企業が及ぼす影響とdeployment_architectureとの関係性
  • deployment_architectureと作業の分担
    • 図7-2: deployment_architectureと作業の広がり
  • information_appliance(ance: していること)
    • 明確なtarget_marketにおける包括的なsolutionをより良いものとするために設計された専用のdevice
    • Linux OSが受け入れられている → 発展
    • 複雑なsolutionを単純化することが求められている
  • deploymentの選択がsoftware_architectureに与える影響
    • 柔軟でparameter化されている，または統合の選択肢がない
      • xSPこそ標準化に取り組むべき
        • 構築も管理も単純になり，運用コストdown
      • 機能と比較的単純な境界がうまく定義されている場合は，統合の選択肢を一切与えないことはうまくいく
    • upgrade policy
      • systemを開発する初期の時点でupgradeを容易にする変更を行うことで，MSPなどは頻繁に安全に本番システムを変更している
    • data保護とアクセス
      • application dataの保守は，applicationや利用者，データのsensitibity，重要さに応じて，適切に行う必要
    • 移行手段の選択肢
      • 移行の与える影響は，architectureの全体的な設計においても考慮されるべき
  • 一般消費者向けsoftwareの未来
    • softwareのlicenseはrental, subscriptionが望まれる
      • 持続性があり，信頼性も高く，高速なインターネット接続を経由してWebサービスへ接続するようになる
    • 一般消費者向けsoftwareの環境も，enterpriseクラスのsoftwareと同じように複雑になっていく

  • まとめ

    • deployment_architectureとは，顧客の使用するシステムがどうやってデプロイされるのかを説明するもの
      • 一般的な選択肢
        • client siteへのdeployment
        • application_service_provider
        • managed_service_provider
        • 様々な種類のservice provider(xSP)
        • Web service(transaction応答型サービス)
      • 今後は，hybrid形態が一般的になっていく
    • deployment_architectureの選択におけるclientへの影響
      • 管理統制に関する要望
      • ほかシステムとの統合
      • dataのsecurity/privacy
      • peek_loadを捌く処理能力
      • 初期コストと保守コスト
      • 信頼関係
      • systemを運用するスタッフのスキルと経験
    • deployment_architectureの選択における自分たちの所属する会社からの影響
      • 理想的なsales_cycleと実際のsales_cycle
      • infrastructureへの投資
      • cash_flowに代表される財務モデル
      • 効果的で素早いclient基盤の管理
      • client側拠点に合わせた地理的な広がり
    • どのdeployment_architectureを選択しても，うまくシステムを管理するために必要な作業の全体量は変わらない．変わるのは作業の分担
    • information_applianceは，幅広い環境におけるdeployment_architectureにおいて，成長し続けている分野
      • open_sourceの契約モデルは所有者にとっての全体コストを下げてくれており，成長を支えている

  • checklist

    • 自分たちのdeployment_architectureはtarget_marketにおける次のいずれかの要望に合致している
      • 管理
      • 統合
      • データのsecurity/privacy
    • 有用な性能モデルがあり，自分たちのdeployment_architectureが期待されている仕事量を処理できる
    • 適切な運用policyを定めている
    • 自分たちのdeployment_architectureでは，次の事項についてどのような選択をしたのか説明できる
      • sales_modelとsales_cycle
      • infrastructureへの投資
    • clientにやってもらう作業の量を定義している

Ch08 integration, extention

  • integration: systemがどれくらいほかのsystemと連携できるか，またはどれくらいほかのsystemと連携しなければならないかを表す度合
  • extention: systemを元にしてextended_productを作り出すとしたら，どれくらいextendできるかを表す度合
  • clientをやる気にさせる--原動力
    • integration/extentionとも，複雑なシステムならどちらでも，より優れたproductを作る能力が得られるという同期
    • 自分たちが管理しているという感覚から，作業が増えても満足度が上がるケースがある
    • integration/extentionの動機
      • 予測はできないが計画はできる
        • 統合や拡張のための方法をclientに提供することで，未来を予測できなくても未来に備えることができる
      • clientはできませんと言われるのを嫌う
        • 統合したり拡張したりする戦略が必要
      • 大規模なsolutionは複数のより小さいsolutionから構成される
    • 自分のsystemにはない情報がほしい
      • 興味を引くreportや分析結果のために，別のシステムの情報と組み合わせる必要があることがある
    • 切り替えコストを増やしたい
    • productのecosystemを作りたい
    • column: 何かと組み合わせなければならない
      • 他システムとの統合が前提のケース
    • 一般常識
      • 優れたtarchitectは，どんなときでも何らかのAPIをシステムに追加して，自動かテストframeworkによる厳格なregression_testを容易に行えるようにしている
      • 優れたmarketectは，この技術的な資本を活かす方法を考える
      • featureをproductに追加するために必要なのはdocumentを用意することだけ
      • APIを提供することをclientに対するcommitmentとして，初めから開発活動に含めるべき
      • APIを利用する関係者との信頼関係は長期間続く
  • layered_business_architecture: logic_structure
    • business_applicationのsystem_architectureとして最も一般的な物の1つに，subsystemを論理的にも物理的にもlayer化するというものがある
    • ui layer
      • userに情報を提示するとともに，情報に対するuserのinteractionを管理する
      • applicationの国際化に関する作業のほとんどを引き受ける
      • simpleなcommand_line interfaceがおすすめ
        • 自動化テストが容易
    • service layer
      • application固有のさまざまなserviceを提供
      • serviceとusecaseは似ている
        • 1つのusecase全体が1つのserviceとして表現されることもあれば，1つのusecaseのなかの1つの手順がserviceに相当することもある
    • domain_model layer
      • businessの重要概念やapplication domainの規則を表現
      • enterprise applicationにおいてこのlayerは付加的なもの
      • このlayerが必要になるのは，単純なサービスでは表現しきれないほどbusiness ruleが複雑だったり，構造化されたobjectをメモリ上で表現した方がより効率的な場合くらい
      • domain_modelが必要とされるときは，applicationの中核として生まれ出ることが多い
        • 正確性が重要
      • domain_modelとpersistence_data_modelは実際はほとんどのapplicationのtarchitectureにおいて同一
      • domain layerをuiやtransaction管理layerから分離しておくと，system開発はかなり柔軟になる
        • 基盤となるapplication logicに手を入れることなく，service agent向けに表示する画面を，interactiveな音声対話システムやWebページに置き換えることもできる
        • 凝集度も高まる
          • architectureを構成するそれぞれのlayerは関連する操作の集まりに責任を負う
      • 先だって設計しておけば，uiを設計する際に役立つ
      • domain_modelの提供する公開interfaceに従ってuiを実装
    • persistence_data layer
      • ほとんどのbusiness_applicationは，persistence_storageに格納したobjectの管理をDB管理システムに任せている
      • domain layerのobjectとrelational_DB内のobjectの間のmappingを管理するlayerを別に設けるやり方が一般的
      • 基盤となるDB schemaとの連携を効果的に，かつ簡単にするために，domain_modelを構築した方がよいことも珍しくない
      • DB schemaが以上に複雑だったり，性能要件があまりに厳しいときは，domain_modelは取り払ってservice layerとDB schemaを単純に結びつける方が良い
      • business_logicをDBの中に移す
        • portabilityを損なう
        • persistence_data layer teamがSQLを効率的に使えていないことにもなる
        • それでも，慎重を期した上で移す方が適切な場合もある
          • 性能
            • 巨大なDBのときは特に
          • 高度な制約付きdataを扱う場合
            • 条件付きでデータを削除する場合など
          • dataの操作がどうあれ，何らかのアクションを行われることを保証したい場合
            • DB layerでシステムを統合することを許すような場合は特に重要
    • themeに応じた変化形
      • distributed_computing, legacy_systemの統合, 構造的な関係性, 特別なDBのサポート, 特別なhardwareのサポートなどを考慮する場合
  • layered_business_architectureの構築
    • ほとんどのlayerの基本的な部分は，スパイクと呼ばれるprocessで構築
      • スパイク: 利用者の目に見える機能をtarchitectureに含まれるすべてのsubsystemやlayerを通して適切に実装するprocess
        • すべてのsubsystemをまたぐ特定の機能を「通す」という特徴
        • subsystem間のつながりのための釘
        • incremental_developmentのための手法
        • 最初のスパイクはarchitectureの基本的な部分を検証し，risk_managementの土台となる
        • 開発の起点はservice layerかuiのどちらか片方で決める
    • serviceの定義が重要
      • service interfaceを正しく決められれば，残りのtarchitectureを正しく組み上げていくのはずっと簡単になる
      • すでに存在しているserviceを元に，新しいserviceの実装もできる
    • DB設計から始める場合もある
      • 既存の膨大なデータを扱う必要があったり，persistence_storageの要件が極端な場合など
    • 並行開発
      • architectureにおける中心的なsubsystemを早い段階で確立することが重要
        • subsystemのinterfaceについて合意
        • subsystemの同期を保証するために日次または週次でビルド
      • service/domainどちらかのレイヤから始めることに合意する必要
    • column: 全layerをスパイクする
      • 機能がすべてのレイヤを通ることが重要
  • business_logic layerにおける統合と拡張
    • technologyと制御ポイント
      • technology
        • service architectureやmodelを上手く設計し，target_marketの必要とするtechnologyをサポート
      • 制御ポイント
        • 呼び出し元が主導権
          • applicationは結果を生成
        • システムが主導権
          • 登録モデル，callback modelで呼び出し元が何らかの機能をシステムに登録できるようにする
    • APIによる結合
      • ほかのapplicationから統合したいという要望のために使われる
      • service layer自体の公開が直接的なやり方
      • 考慮
        • platformの傾向
        • market_segmentの傾向
        • partnerの傾向
        • 命名規約
        • security. session information
        • clientが必要なものだけを公開
          • security access controlで内部向け/拡張向けを管理
      • column: timingがすべて
        • session_managementの動作をclient向けに明確に表現する必要
      • releaseを重ねるごとに安定
      • できることを明確にする
    • registrationによる拡張
      • registration: developerが何らかの方法で自分のcomponentやcallback_functionを登録して，applicationのcapabilityを拡張する処理のこと
      • 制御ポイントはシステム側
      • e,g, web_browserのplugin
      • callback, listener, plugin, event_notificationなどの仕組み
      • 検討事項(伝えるべきもの)
        • registration modelを定義する
          • registration可能なcomponentを構築するためのprogramming_languageについて，詳細な技術情報をdeveloperに提供する
        • event modelを定義する
        • 実行制御semanticsを定義
          • timingに関する要件
        • resource_management policyを定義
        • error/exception protocolを定義
  • persistence_dataの統合と拡張
    • view
      • DB_schemaのデータの使われ方と，実際の定義を橋渡しする中間層
    • column: business_logicをDBに組み込む
      • 必要な場合もある
        • より単純で効果的な場合
        • clientに統合オプションとして提案できる安全な方法がほかにないとき
    • user_definition_field
      • 些細な利便性に対して，本当にapplicationにとって適切なのか判断が必要
    • table_hook
      • 関連の完全性の強制は難しい
      • 遅延の可能性があるのでできるだけ小規模にする
    • 表計算ソフトのpivot_table
      • dynamicなreport生成のためのcapabilityが必要なときの例
    • ETL(Extract, Transform, Load) script
      • DBに格納されている構造化データを操作しやすくするために設計された，utility program
      • tarchitecture的な見方として，clientが確実に正しいデータを得られるようにできる
      • marketecture的な見方として，ETL_sctiptを製品化して利益を得られる
        • product全体の価値を大幅に高められる
      • column: ETL_sctiptに課金する
    • 何が起きているのか伝える
      • data dictionary, data, table, 命名規則, 特定のカラムの値の大事な意味などを詳細に記したドキュメントを公開する
  • businessへの影響
    • 専門サービス部門
      • clientが統合によって目標を達成するのを手助けしたり，質問に回答したり，環境で動いているシステムを統合するのにかかる時間を短縮したりする
      • marketectが価格付けを支援する
      • marketectは専門サービス部門から上がってきた要望をdevelopment_teamに連携する
      • 開発部門は，APIの使い方を示すsample programを作成する
    • 研修program
      • target userの具体的な目的に合わせる
      • clientの満足度を高め，サポート負担を軽減
      • tarchitectはbest practiceを捉え表現して伝える研修教材を作る
      • systemの設計や統合拡張の方法の理解を深める
      • stakeholder全員への考慮が必要
      • column: どうやってdocumentを追加するか？
        • documentの重要性
    • 資格認定
      • market shareが十分に大きいときのみ
      • 検討事項
        • product ecosystem
        • 競合優位性
        • 流行
        • professional認定
        • 独立した資格認定
        • 学術的な信用
    • user_community
      • 一次情報源
      • marketectが健全で活発なuser_communityを探して支援する必要
      • 手掛かりとなりそうな活動
        • community_Web_site
          • 企業が用意する
        • 教育素材
        • column: ありがとう，でも自分たちのuiは自分たちで作るから・・・
          • userが好みのuiを作ることもある
          • uiへのニーズはそれぞれある
        • mailing_list
        • user_conference
    • 使用許諾契約
      • APIの仕様を必要以上に制限する文言がないことを法律部門に確認
      • column: testにlicenseは要らない
        • 同上
  • 複数回のreleaseに向けてAPIを管理する
    • 統合や拡張のtechniqueを用いているclientが，どんな変更に対してもそれに向けて計画し適応するための時間を取れるようになる必要
    • technique
      • 十分すぎるくらいに警告を出す
        • n+1回目のreleaseの内容をn回目のreleaseで周知
      • 1 release分の共存期間を設ける
      • 後方互換性layerを設ける
      • 廃止されたAPIの呼び出し箇所を特定したり置き換えたりする自動ツールを用意する
  • まとめ
    • integration: systemをprogram的にほかのシステムと接続するprocess
    • extention: plugin architectureのように，明確に定義されたやり方でsystemに新しい機能を追加するprocess
    • integration/extentionによって，clientが探し求めているproductを構築できるようになる
      • 副次的な効果として，clientとの関係性がより密になり，競合他社への乗換リスクが軽減
    • layer化architecture_patternとは，論理的，物理的なlayerによってシステムのさまざまな機能を構成するもの
      • enterpriseクラスのsoftware_systemにおける統合や拡張に際して非常に優れた選択肢
      • main layer
        • ui
        • service
        • domain_model
        • persistence_data
    • architectureがどんな構成でも，スパイクが必要
    • service layerやdomain_model layerに統合や拡張の口を設けるやり方はいくつもある
      • 公開されたAPIを利用
      • Web_browserのようなplugin architectureでcomponentを登録
    • persistence_dataの統合・拡張を実現する手段
      • view
      • table_hook
      • 表計算ソフトのpivot_table
      • ETL_sctipt
    • 統合や拡張が可能なapplicationがbusinessに与える影響
      • clientを誘導する専門サービス部門
      • clientが自分たちが何をすればよいのか理解するための研修program
      • applicationのecosystemを作るための資格認定program
      • applicationを取り巻くuser_community
      • integration/extentionを明示的にサポートする使用許諾契約
    • applicationの統合や拡張に際してclientと接することになる方法はすべて，慎重に管理
      • それらの安定性について公にcommitmentしているため
  • checklist
    • system integration/extentionを可能にするやり方それぞれについて，clientが期待した結果を得られるよう，support資料を備えている
    • applicationがどのように外部のapplicationと統合されるのかをcontext_diagramで示している
    • 一貫したAPIを提供するための命名規則がある
    • APIの性能や呼び出しごとに消費されるresourceについてdocument化されている

Ch09 brand, brand_element

  • brand_element
    • 名前
      • system_componentの物理的配置
        • 会社名/product name/sub component nameが〇
        • product name/sub component nameとなることもある
        • 認知や拡張について〇
      • 主要componentの名前
        • 重要な戦略
        • marketectやmarketingの知見を持つ人が命名するべき
        • 何をするものか技術的に正しく伝わる必要がある
        • 実装と名前の乖離は正当化できる
          • 変更にはコストがある
          • marketectureと関わる名前の変化は技術的な面よりも遅い
        • column: developerが名前をつけるべきなのは変数名くらいで，product名をつけさせてはいけない
          • 良いproduct nameは成功の可能性を高める
          • enterprise marketでは，product名以外の要素が支配的
            • 提供元企業に興味がある
      • 名前の国際化の必要性
      • brand_elementは設定ファイルやログファイルにも潜んでいる
      • brand_elementはerror_message, diagnostic_message, information_messageにも潜んでいる
      • 名前は変わりやすい，最初のreleaseならなおさら
        • codenameのようなもので当面は呼んでいた方が良い
    • 見た目，スローガン，その他のbrand_element
      • icon, splash_screen
      • brand_color
      • 音声のbranding
    • trademark(™)記号を使うべきタイミング
      • 法律上の権利を保護
      • 注意を促す
      • 商標記号は形容詞としてだけ使う
      • productを配布するときや，productを利用しているときは，登録商標を表示する
      • 法律上の制限はあるものの，internet domain nameはtrademarkにできる
  • in_license_brandの管理
    • 適切に扱う必要
    • column: 続行するためにOKをクリックしてください
      • splash_screenを扱う必要があったとき
  • brand_elementのカスタマイズ
    • marketectは開発サイクルの早い段階で要件を具体化する必要
      • どの要素が変更可能/変更すべきかを把握することが最重要
        • 前者は常識的な初期値を決定，後者はカスタマイズの手続きの定義が必要
    • 正確で詳細な情報の伝達
      • bitmap画像の大きさ，サポートする画像形式，brand_elementとしての既定値など
      • brand_elementをカスタマイズするための特別な契約が必要な場合もある
  • brand_elementの変更
    • 困難な理由
      • brand_elementの変化は大変ゆっくりしたもので，変更できるようになっていない
      • brandがproductやarchitectureに与える影響が分かりにくい
    • productの関連要素への影響
      • subsystemの名前
      • source_code repository
        • product nameそのものが使われていなければ問題ない
        • product nameに合わせている場合は必ず同期する
      • 品質保証と技術サポート追跡システム
        • categoryについて，実際のproductとの差異を小さくするよう保守
      • componentの物理的配置
      • APIの名前と構造
      • error_message, log file, diagnostic_message
      • 品質保証processと自動化テストのinfrastructure
      • 販促品
    • 変更と品質保証
      • brand, brand_elementの変更にあたって，品質保証は非常に大きな役割
  • まとめ
    • brand_elementは，tarchitectureに対して，すぐにはわかりにくい影響を広範囲に与える
      • icon~install先にまで及ぶ
    • product nameを考えるのはmarketectの仕事
    • brand_elementの国際化は難しい
    • product nameに関するさまざまな法的表示の使い方の理解
    • in_license technologyはbrand_elementとしての要件を強制する場合がある
    • product nameを変更する際は，あらゆる観点のclient experienceを総合的にreviewする
  • checklist
    • 必要なbrand_elementはすべて整理したうえで合意できているか
    • すべてのbrand_elementが必要に応じて国際化されているか
    • error_message, diagnostic_message, log fileに，合意済みのbrand_elementがきちんと反映されているか
    • 登録商標やtrademarkなどの記号が適切に使われているか
    • partner企業や技術license供与者による変更など，置き換えられる可能性のあるbrand_elementが明確になっているか

Ch10 usability

  • 性能と拡張性について
  • tarchitectureがusabilityに与える影響，特に性能を改善する要因としての影響を見る
  • usabilityはお金になる
    • usabilityはuiよりもはるかに奥が深い
    • ほとんどの場合tarchitectureが影響している
    • user自身と，systemを利用する状況の両方の理解が必要
      • marketectにとっては，システムの競争上の優位性を保証するため
        • userにとって最も重要なニーズを確実に満たし，長期にわたって友好関係を築くために必要な基礎を整えるためでもある
      • tarchitectにとっては，性能や国際化などをより一層追及したcapabilityを構築するため
      • usabilityの量的，質的な指標になる
        • 量
          • 性能やデータ入力エラー率など
        • 質
          • 満足度や理解のしやすさ
    • userを理解するための手法
      • 観察，interview，質問，〇直接体験
        • 直接体験: 経験的な要件
    • usabilityはproductの生涯にわたって見返りをもたらす
      • merit
        • 研修コストの削減
        • support, serviceコスト削減
        • error発生時のコスト軽減
        • userの生産性の向上
        • client_satisfactionの向上
        • 保守性の向上
    • column: market needsとusability
      • usabilityのmeritは社内でもmarketと同じように受け入れられるはず
  • mental_model, metaphor, usability
    • userがどのようにタスクに取り組むかについて理解が深まれば，そのタスクについてのmental_modelを理解できるようになる
    • mental_model: 世界の物事を説明したり，simulation，予想，制御したりするうえで，心の中に抱く一連の考え方や構造のこと
      • taskやそれを達成するためのツールに応じて形成される
      • 時間とともに変わっていく
    • 概念モデルはmental_modelの表現の1つ
    • mental_modelを理解し，概念モデルの役割を明確にする → metaphorを生むための基盤
      • metaphor: systemを作ったり修正するために使える，ある物事の理解を助けるために別の言葉で表現するもの
      • tarchitectは，application architectureを説明するのにmetaphorを使うことが多い
      • よいmetaphorは，tarchitectureとuiの両方を具体化してくれる
      • tarchitectが選んだmetaphorが，明確に定義されたmarketに対して適切なやり方で伝えられる必要がある
      • metaphorはbrand_elementや価格モデルにも影響する
        • systemが最大の価値をもたらす特定のmarket_segmentがmetaphorによって強調 → 価格モデルに影響
      • 完全に新しいproduct: productの機能や提供の仕方を伝えられるかどうかmetaphorによる
      • これらのすべての理由から，metaphorはmarketect/tarchitectが密に連携して開発する必要がある
    • metaphorはusabilityに影響を与える点で特に重要
      • training cost激減，満足度急上昇，システム全体が快適になる
  • ui設計におけるtarchitectureの影響
    • 影響範囲
      • cardinality(濃度)
        • あるrelationに参加しているentityの数
        • tarchitecture全体とui設計それぞれで必要
        • 増加し続ける大規模なデータを可視化するツールは幸運にもたくさんある
      • feedback
        • 最も重要なheuristic(探したり発見するのに役立つ → 発見的（手法）)の1つ
        • e.g. progress bar
          • tarchitecture上の課題がいかにしてui設計に影響するかの例
        • validationなど，最高のusabilityを得るにはそれぞれのdeviceごとのcapabilityを理解する必要がある
      • 明示的なuser_model
        • systemの振る舞いをmental_modelにあうように調整する
        • e.g. word processor
      • workflow support
        • workflow: ある種の目に見えるuser_model
          • mental_modelへの理解の上に成り立つ
      • transaction support
        • transactionはuiに特有のcapabilityをsupportするように設計されている
        • e.g. 情報の表示方法など
      • error_response
        • errorの表現方法に関する選択も，基礎となるtarchitectureに影響する
      • globalization/localization
        • OSやplatformはuserが言語を指定するためのinfrastructureを備えている: 大きな利点
        • development_teamの設計上の選択がglobalizationを困難にすることがある
          • e.g. 部品を固定サイズにしてしまうこと
        • userの目に触れる情報はsource_codeには埋め込まず，何らかの識別子を参照する必要がある
        • development processのできるだけ早い時期に，対象言語を定めるべき
        • column: 詳しく，もっと詳しく，もっともっと詳しく
      • requestの中断
        • requestを区別するための識別子が必要
        • かなりのコストがかかるが，見合うだけの成果がでることもある
      • requestの取り消し
        • transaction managementやpublish_subscribe protocolなど洗練されたtarchitecture設計では，状態が共有されていても適切に取り消せるcapabilityを提供できることもある
        • 高機能なuiがありapplicationの永続状態が適切に反映されていれば，操作の取り消しに意味があるかどうかを判断するための情報をユーザに提供できる
      • transactionの相殺
        • 設計の早い時期に追加することでusabilityは劇的に改善する
      • timeout
        • 初期値の選択は非常に繊細な判断が必要だが，うまくやればusabilityが改善する
        • sessionに関するparameterをsystem administratorが変更できる必要がある
      • network_availability, network_speed
        • userの置かれる状況を考える
      • shared_resource
      • 障害回復
        • systemが障害を制御して，妥当なやり方でそれを復旧するのが望ましい
        • systemに関連することはユーザに注意を促す方が好ましい
  • speedの必要性
    • 話している対象をはっきりさせよう
      • 性能用語
        • throughput
        • performance
          • throughputの逆数
        • latency
        • capacity
          • entity数
        • scalability
        • reliability
        • response_time
      • 最小限未満，最小限，平均，理想，最大限
      • ますはシステム構成を特定（「固定」）
      • 次に，テストしたいtransactionあるいは操作を特定し，利用するデータを用意する
      • systemの性能は線形増加しない
      • queueの上限を知ることは重要
        • serverが処理できる最大のバーストがわかる → 信頼性を構成する要素の1つ
      • systemの応答に関する心証は性能値と必ずしも一致しない
      • response_timeはできるだけ短いほうが良い
        • 5s~10s以内である必要
      • 故障への適切な対応 → 信頼性の一因
      • user_modelの定義が重要
        • 多様な操作のsupport
        • 本番環境で取得したシステムの操作に関連したログファイルを使うと，優れたuser_modelを導ける
      • testの複雑さについて，性能の見積もりは控えめを心がけるべき
    • marketectが性能について心から望むこと
      • 性能に関連した質問について，自信に満ちた，信頼できる，正しい回答をしたい
      • 新しいreleaseや推奨hardwareの変更があった場合は，性能を計算しなおす必要がある
        • 性能改善が期待される
    • userに応答を返す
      • 本当に一瞬で応答できないなら何らかのfeedbackが必要
      • feedbackの仕組み
        • 即時的(1s~2s)
          • 共通objectの見た目を変える
          • 音声で応答
        • 継続的(2s~)
          • 共通の「繰り返し」animationが〇
          • progress indicatorを，中断できないタスクはステータスバーに，できるなら別のdialogue windowに表示する
          • 時間の見積もりは精度が重要
        • column: feedbackは不要なタスクを軽減
          • response_timeとfeedbackはシステムの性能に対する定性的で心理的な認識
          • 心理的に許容できる応答を返すことは低コストで効果がある
    • 性能とtarchitecture上の影響
      • hardware任せの問題解決
        • 最も簡単
        • tarchitectureのscalabilityが理解されている場合だけ，適切に機能する
      • 粗粒度transactionを使う
      • thread処理が性能に及ぼす影響
      • profilerで計測
      • 通常の処理と異常時の処理を分離
        • 通常時は高速，異常時は適切さが必要
      • 結果をキャッシュする
        • 誤った結果を返してはいけない場合を特定しておく必要
        • dynamicにcacheの有効無効を切り替えできるarchitectureが必要
      • background_processing
      • self_serviceで使えるように設計
      • platformのidiomを学ぶ
      • taskを減らす
  • まとめ
    • usability: systemが備える属性で，ユーザが必要なタスクを完了させるうえで簡単に，効率よく，最小限のエラーで済むようにするためのもの
      • 使いやすさ: 目的を達成するためにfrastrationを全く感じないか，ごくわずかで済むこと
    • usability: product brandingにとって中心的feature, productのあらゆる面に関係する
    • 成功するsolutionのusabilityは優れている．長期的な利益に貢献
    • mental_model: 観測しているものを説明，模擬，予想，制御するための考え方や構造の集まり
    • 概念モデル: mental_modelの何らかの表現
      • 言葉/図，形式的/非形式的
    • metaphor: あるものを別の観点から理解するためのモデル
    • uiをtarchitectureから分離することで保守性が高まる
      • 絶対確実な方法はない
    • 性能は重要
    • marketectは性能に関する質問に対して，自信をもって正確で信頼できる回答をしたいと思っている
      • especially, enterprise_software
    • 性能改善のためのtechnique
      • cache, background_processing, 空いているprocessorへ処理を渡す，処理自体をなくすなど
  • checklist
    • 主要なタスクのusabilityをテストしている
    • 概念モデルを描いており，userのmental_modelを理解したり，システムのmetaphorを作るのに使っている
    • systemの設計や実装を見れば，systemのmetaphorが分かるようになっている
    • 性能を定義する合意された用語集がある
      • marketing部門や販売部門が構成を見積もるための方法を提供している
    • 問題解決をhardwareに任せるのはいつなのか，どうやるのか理解し，それによりどうなるか理解している

Ch11 install

  • 設計が拙いと経済的な損失が大きい
  • OOBE(Out of box experience)
    • computerなどの端末を初めて使うときの経験を表現
    • installに関連するわかりやすい目標をmarketectがtarchitectのために設定していると有用
      • e.g. 平均的なユーザがtechnical supportに電話しなくてもinstallできるようにするというもの
    • column: installが拙いことのコスト
  • 痛い！きっと怪我をしたに違いない
    • clientが恐れていること
      • 難しすぎる
      • 複雑すぎる
      • 簡単に何かを壊してしまう
      • どのくらい時間がかかるか分からない
      • 入力する情報が多すぎる
  • installとarchitectureの関係
    • forceと選択
      • sub_componentの管理
        • installerを用意するのが自分かユーザか決める必要
          • どちらのケースもある
      • in_license_contractの要件
      • license_contract
        • EULA(End User License Agreement)
          • license_contractの一部または全てをinstall programに含めておく
      • column: 準備ができたら引き継ぎます
        • install準備programで，softwareに必要なcomponentがあること，適切に設定されていることを保証
      • business_model
        • business_modelはinstallerの作り方に影響
        • install processがbusiness_modelを実現する助けになる
      • installの責任分割
        • InstallShieldなどのinstall programにどれだけのことができるのか学習しておく
      • install先の環境
        • target_marketの環境によって望ましいprocessが異なる
      • installの役割
        • 複雑なinstallも役割ごとに対応してまとめておく
      • developerに気づかせる
        • developerにやってみてもらう
  • installのやり方
    • installのための情報を収集し，事前条件を検証する
      • 必要不可欠なすべての構成情報と，重要なcustomize情報を出しておく
      • 検証内容
        • 空き領域
        • network_connection
        • 必須entityの設定
        • access権限
          • 必要な場面を限定する
    • install
      • 進行状況を示す
      • 視覚的な見取り図を提供する
      • 進行状況をログファイルに書き出す
      • installを中断できるようにする
      • platformのガイドライン西潟宇
      • 強制的な再起動を避ける
      • 不必要な質問を避ける
      • column: cross_platformなガイドラインは存在しない
    • install後に確認する
      • softwareの実際の動作に注目
      • ログを記録
      • 後始末
      • manual
      • user registration
  • 仕上げ
    • userはmanualを読まない
      • 一目でわかるロードマップを提供する
    • install/uninstallをテストする
      • installerは最初のiterationでテストする
        • 自動ビルドprocessに組み込める
      • あらゆるoptionを試す
      • 自動化する
      • platformのガイドラインに従う
      • install処理をscript化する
  • まとめ
    • installはお金そのもの
    • ほとんどのユーザはinstallを恐れている
    • installはarchitectureの構造によって決まる
      • すべてのcomponentとcomponentの依存関係は適切に管理が必要
    • 検討中のinstall processがすべてのlicense条項を満たしているか確認する
    • softwareをinstallする典型的なalgorithm
      • installに利用する情報を収集し，事前条件を検証
      • install
      • install後に確認
    • 内部でテストするため，install processを自動化する
      • enterprise環境のために自動化しやすくする
    • とにかくテスト
  • checklist
    • install processによって，sub_componentがそれぞれどのように扱われるのかを明らかにしている
    • install processが全てのlicenseされたtechnologyの要件を満たしている
    • software_architectureのinstall担当者に求められるスキルレベルを明らかにしている，レベルは妥当である
    • installの正しさを検証する方法がある
    • install processは対象platformのガイドラインに完全に従っている
    • 平均的なユーザならdocumentを見なくてもinstallできる
    • install/uninstallをともにテストしている

Ch12 upgrade

  • upgradeはinstallよりも問題になることが多い
    • clientにとって深刻な被害を引き起こすことがある
      • dataの喪失，統合の問題，元のfeatureの振る舞いの変更など
    • 最初のreleaseの売上よりもupgradeの売り上げの方が多い，marketingの主な役割はclientの発見と関係性の維持
  • installと同じように悪いことしか思い当たらない
    • upgradeに伴う恐れ
      • 手戻り
        • 特に統合の問題
      • upgradeの連鎖
        • upgradeに関連する依存関係を全て明らかにする必要がある
      • data移行
        • DB_schemaについて，めったに変更されないもの，一度作成したら変更すべきでないもの，頻繁に変更され得るものを分離することが重要
          • 労力が大きく減る
      • data保全
      • 認証process
      • new API
        • clientのニーズに基づいて慎重な管理が必要
      • column: 一度統合したものは二度とupgradeしない
      • 新しいfeature
        • 学習コスト
      • systemにアクセスできない
      • 切り戻し
        • upgrade processの手順を入念に計画して理解を深められれば，簡略化できる可能性がある
      • column: 私はもっと違うことで困っている
        • upgradeに伴う苦痛の一覧を作る必要がある
  • upgradeの苦痛を取り除く
    • 苦痛のないupgradeのための選択肢
      • 回数とtiming
        • marketに起きるevent, rhythmを理解する必要
      • upgradeの準備
        • Ch11と同じ
        • clientが現在利用しているversionの確認
      • data移行
        • column: yesよりnoが簡単
          • featureを取り除けるのはupgrade processの間だけ
          • featureはapplicationのpersistence_dataと何らかの関連を持っていることが多い
            • 調査 → featureが使われているかどうか突き止められる
          • 最適なupgrade方法を決めるため，現在のinstall状態を評価するprogramを書くのは良い考え
            • upgradeでできること，やるべきことがわかる
          • featureを取り除く
            • development_team全体への調整が必要
            • featureの追加と同じくらい大変，たいていはそれ以上に大変
        • 移行processの間のみ移行できる
        • ツールを使う場合
        • ファイルのデータを変換するときは警告が必要
      • 設定情報とcustomize情報のupgrade
        • あわせてupgradeする
      • old version
        • clientがすべて同じold versionではない
        • 一段階移行
          • すべてを最新に直接upgrade
        • 多段階移行
          • 最新のversionへupgradeできるいくつかのold versionを部分集合として抽出する
      • 共存，または置き換え
        • 可能な限り置き換えが〇
          • ほかに削除するタイミングはないため
        • column: どのversionを使えばよいのだろう
          • 共存はテストの複雑さやサポートコストが象か
  • upgradeとmarketの成熟度
    • innovatorはほかのprocessとは異なりデータ移行についてはかなり重要視している
    • 欠陥のあるupgrade processはmarket_segmentによらず将来的に重大な問題を起こす
  • まとめ
    • upgradeは，相当数のclientにとて実に様々な形で頭痛の種となる
    • 継続的なtechnologyの進化によって，upgradeの連鎖が発生する
      • 前提となる条件を詳細に調べる必要
    • upgradeの間にclientのdataを削除しないようにする
    • clientにとって，どのくらいの頻度ならupgradeを受け入れられるのか理解する
    • upgradeの準備ができているか評価するtool
      • upgradeの影響が分かる
      • 不要な/未使用のfeatureを取り除けるか分かる
    • すべてのmarketのadopter segmentは優れたupgrade processを求めている
  • checklist
    • upgradeによって何かしら問題が生じる可能性のある分野が特定できていて，それを小さくしようと試みている
    • すべての移行パスをテストしている
    • どんなclientであろうとも，現在のversionへupgradeできるのは，以前のversionの中でも特定のversionを使用している場合だけであると定めている
    • upgradeに伴いどのくらいの停止期間が生じるのか定めている
    • upgradeを完全にuninstallし，すべてのdataを旧versionに戻すための詳細な手順を用意している
    • upgradeが正常に完了したかどうかを確かめ，もし失敗したならどこで失敗したか特定できるテストを用意している

Ch13 configuration

  • 設定しやすくすること自体が，marketectにとってもtarchitectにとっても価値ある目標
  • 設定可能性--usabilityの一因
    • costの問題
    • architectureの性質に左右される
      • module化を進めると影響も大きくなる
    • 設定に関するコストは増え続ける
    • 適切な設定parameterが必要
  • system_context
    • 設定parameterに反映する必要があるもの
    • systemを適切に機能させるために必要な，あらゆる側面におけるcontextの情報
    • 取得・設定できるようにすることで，developmentのときとdeploymentのときそれぞれで設定できるようになる
    • contextの情報
      • tarchitectが整理する
      • 主要なfile, directoryの配置
      • 起動するための情報
        • 情報が失われた場合も，必要最低限の機能を提供できるようにしておく
      • portability switch
      • 互換性の制御
        • clientと問題を共有して，いくつくらいの設定parameterを使って対応するか決めてもらう
      • 性能parameter
        • 高度に洗練されていれば自動調整もできる
        • いくつかの簡単なparameterは利用者が調整できるようにしておく
      • column: 過ぎたるは猶及ばざるが如し
        • 設定しないとシステムが動作しないものだけを設定parameterにするべき
        • 必要な場合は，変更可能なparameterとして妥当な初期値を設定しておく
  • 初期化と実行
    • 実行中にも設定を変えられるようにしておく必要があるもの
    • 透過的なparameter
      • 実際はapplicationを素通りしてin_license componentに引き渡されるparameter
    • tarchitectは，初期化中と稼働中それぞれのtimingでどの設定を扱うべきか検討が必要
  • 値を設定する
    • system administratorのような人間，system間の相互通信によって値をやりとりしたり指示を受け取ったりするような他システム，1つ以上の値を自動的に設定するように構成されたシステム自身の3つのentityが連携して設定する
    • それぞれにそれぞれの権限がある
    • marketを念頭に置いてどのentityによる変更を優先するか決定する
  • 適切な値を設定する
    • parameterの影響を受けるユーザのニーズと，それを設定するユーザのニーズの両方を満たす必要
    • 複雑になるほどusabilityを損なう
    • どんな値を，どうやって，なぜ設定するのか，システムの運用にどのような影響があるのかの理解が必要
      • 設定ファイル自身に記載する
  • 設定parameterのheuristics
    • 簡単に変更できるよう，そして，たとえシステムのほかの部分がダウンしていたとしても変更できるようにする
      • 単純で管理もしやすい平文のまま，システムの外部に配置する
    • 全ての情報を一か所に配置する
    • 分かりやすい場所に分かりやすい名前のファイルを配置する
      • 「システム設定情報」のような名前で，installしたapplicationのroot directoryに出力するなど
    • XMLは，単純で必要に応じて詳しく書け，管理もしやすい
    • Windows registryのようなものを使う場合は十分に注意する
      • 移植性がなく，技術に明るくないユーザが変更するのは困難
    • 設定情報の取得と技術サポートへの送信を簡単にできるようにする
    • 設定する値を間違いにくくする
      • 間違えたら，すみやかにユーザに伝えて，システムを停止するか，妥当な初期値に変更して続行する
    • 対故障性に優れた設計では，設定parameterを何らかのentityやobjectの属性を永続化したものとして扱う
      • ほかのobjectやsubsystemはこの設定objectを介して情報を取得できるようになる
        • file管理も関知不要
      • 検討すべきobject
        • system context objectでシステム全ての環境の情報を格納する
        • computer, service instance, user, user profileそれぞれを表すobject
        • 設定情報の意味を理解するobject
      • あとからつじつまを合わせるのはとても面倒
  • まとめ
    • 設定とは，usabilityにおけるきわめて重要な観点
    • 設定parameterはsystem_contextを表現できるように設計される必要
      • system_contextの定義
    • systemの設定が必要なtimingは，実行前と稼働中
      • 実行中に設定を変更できるようになっているとデバッグしやすい
    • clientが自ら適切な設定をするには支援が必要．労を惜しまないようにする
  • checklist
    • systemのすべての設定parameterを決定
      • それぞれのparameterについてsecurityと監査の要件を規定
      • 初期化中にだけ設定を使うのか，実行中に変更できるようにするのかも決定
    • それぞれのparameterの設定方法をdocument化し，正しい設定をするための手引きを提供

Ch14 log

  • column: たとえ後からでもやらないよりはマシ
    • logは掛けた手間に見合う成果ある
  • 何が起きているか知りたい
    • log category
      • debug, error
      • error recovery
      • performance tuning
      • capacity planning
      • 行動追跡と監査
      • system configuration
      • 運転状態
    • 正しいcategoryに出力する
    • logにはsystemが生成した情報だけを出力する
      • 付随的な処理に過ぎない
    • column: 2つに分けるくらいなら，分けない方がマシ
      • eventの種類ごとに適切な識別子をつけて，1つのlogファイルに出力
  • 事実だけではない
    • logの生成には，起きていることを表現するのに十分なcontextを含める
    • logはprogramのtraceをきれいに見せるためのものではない
      • developer用のデータを出力するログは別のファイルにするのが〇
  • logの書式と管理
    • logの書式
      • globalization
      • timestampを千t脳に出す
      • source_code中の位置を特定するための識別子を付加する
      • transactionを特定する方法を提供する
      • flatfile出力
        • 解析しやすい
        • 読みやすい
        • 常識的な場所に出力
        • 常識的な命名
        • ゴミや特殊文字を含めない
        • documentを書く
        • 突き合わせ，および監査のための識別子を付与する
    • logの管理
      • dynamic logging
        • logのparameter（詳細レベルや出力対象など）を実行中に変更できる機能があると〇
        • 必要に応じてlog出力
      • threadごとのlogging
      • log level
        • 開始と終了に加えて，詳細レベルの指定を可能にする
        • logに出力されるべきか表す数値の割り当て
        • 補完として，labelづけもある
          • e.g.
            • debug
            • information
            • warning
            • error
        • categoryに従う
      • API
      • 設定可能な構文
        • 異なる書式の方が処理しやすい場合もある
      • あらゆる例外をログに出力
      • 消せるようにする
        • ファイル名に日付があると消しやすい
      • security
        • 暗号化，権限
      • 転送の自動化
    • loggingの標準とlibrary
      • platformへの依存の有無
      • libraryは代替手段
      • column: logのreuseには十分に気を付ける
        • userが変更しやすいなどの問題になる
  • logの後処理
    • 圧縮サービス
      • 循環ログなども〇
    • 同期ツール
      • logの時間の同期を保証
    • log viewer
  • logging service
    • loggingをdevelopment_teamに提供するサービスとして考えることは有用
    • 賢いログを実装することに伴う複雑さを抽象化
    • ほとんどはsingleton
    • 中央集権的なサービスとして実装するmerit
      • globalization
      • 時間的な順序の統一
      • 柔軟な出力先の選択
      • 複数のinstanceやサーバを跨いだ統合
        • log file nameやその内容に，instanceやserverの情報を付加
          • e.g. processやthread id, machine IP address
  • まとめ
    • logが情報提供以外に支援する活動
      • debug
      • error recovery
      • performance tuning
      • capability planning
      • 行動追跡，および監査
      • system configuration
      • 運転状態
    • logは利用者目線で構成が必要
      • 文脈を表す情報を含めるべき
      • 分析しやすいように構成
    • log fileが運用や環境に与える影響を評価
      • disc領域が不足しているときの異常発生などにも適切に処置できるようにしておく
  • checklist
    • log fileそれぞれの目的が定まっている
    • log fileそれぞれについて，利用する立場になって有用性を確認した
      • 適切な情報が適切な書式で含まれているなど
    • log fileからdeveloper専用のdebug informationを注意して除去した
    • log fileはui部品のために用意されたglobalization guidelineに従っている
    • log fileはsystemのほかの部品のために用意された可搬性guidelineに従っている
    • log fileは分析しやすい

Ch15 release_management

  • release_management
    • clientに対して正しい成果物が出荷されることを保証する
    • 説明ラベルをつけて成果物を特定・整理・管理
    • SKUあるいは部品番号によってしかるべきback_office_systemに統合する
    • 構成管理と密接な関係
      • 構成管理
        • systemの構築中にさまざまなcomponentや関連する成果物を特定・整理・管理するprocess
  • 本当に必要なのだ
    • 変更管理が必要になる
    • 構成管理の影響
      • teamwork
      • componentの必要条件の理解
        • 問題発生を防いだり診断したりしやすくなる
      • messaging_systemでは，messageにversionの識別子が必要
        • 内容や処理条件の変更を管理
    • release_managementはclientに必要
      • どのversionを発注したのか，以前のversionと互換性があるのかどうかを知っておく必要
      • 利用可能なパッチやupgradeが自分たちの環境で自分たちの発注したversionに適用できるかどうかも知る必要
    • 複雑な問題
      • technology自体の観点もあるし，基盤となるtechnologyによっては選択肢がないこともある
  • baselineの確立
    • 用語
      • program family
        • すべてのcomponentのすべてのversion全体
      • component/成果物
        • system内部で個別に識別可能な最小単位
      • version
        • 固定・凍結したcomponent/成果物
        • source_codeと派生物(object code, API document)のバージョンの保守が重要
        • 内部用と外部用それぞれのバージョン識別子が必要
      • revision
        • component/成果物の新しいバージョン
        • 以前のバージョンの置き換えを意図したもの
      • variation
        • componentやその他の成果物の代わりになる実装
        • OSごとのsoftware componentなど
      • distribution
        • 特定のclient群に配布するために作られたバージョン
        • 1つ以上の保証されたcomponent/成果物から構成される
      • release
        • 命名されバージョンが払いだされたcomponent/成果物の集合
        • revisionとは違い，必ずしも線形ではない
    • 依存関係や前提条件の管理が重要
      • ほかのcomponentの特定のバージョンに依存するcomponentを内包していることが多いため
  • release_management
    • 何をreleaseするか
      • 完全なrelease: product全体のrelease
      • 部分release
        • base systemのcapabilityを拡張
        • option moduleなど
      • patch_release
        • install済みで既知の不具合がある1つ以上のcomponentを完全に置き換えるもの
        • 機能追加などは×
      • いずれも同じrelease process
    • 対象は誰か
      • alpha releaseは内部userが対象，ほかは外部user
      • 限定release, 管理releaseは特定のclientに対して行われるrelease
      • 誰を対象: scope, 何をrelease: size
        • 混同しないようにする
      • clientの利用状況などの理解が必要
    • なぜそれが必要か
      • アメとムチの使い分けでmarketectはclientにreleaseを受け入れてもらうようにする
      • install baseをできる限り最新に保つことが，marketectのメインタスクになる
      • どのversionからでも最新バージョンにupgradeできるようにする必要
        • 手順がややこしくなったとしても
  • releaseの識別子
    • clientがreleaseを識別できるようにするために使われる
    • 完全な識別子
      • product nameと，productの適切なrevisionやvariationを含むversion情報によって構成
      • 目的: 必要な情報をできる限り短い名称と識別子で表現 → 全体的な効率が改善
    • 完全release
      • product name + revision情報を表現するための4桁の数字文字列(x.y.z.ビルド番号) + 任意のvariation識別子
        • x: major
          • clientから見えるarchitecture, featureの変更
            • marketectが合意し，変更内容を定義
          • business上の理由もある
          • client全体にできるだけ早く配布する目的意識をmarketectは持つ
        • y: minor
          • 望まれるfeatureやその他の改善
          • marketectはバージョンをあげる契機となるイベントをすべて定義する必要
        • z: 保守, dot
          • x, yを共有するほかのdot releaseと互換性が必要
      • marketingのためには，clientにはmajor, minor numberのみ見せるのが〇
        • 管理コストを減らすため
    • 特別release
      • 識別子の形式は，ほぼ完全にmarketingの要因に依存する
      • 基本的な配布物のoptionになっていたりする場合は，4桁の数字文字列の識別子が〇
        • 命名規則が一貫
          • option componentに対するmental_modelを構築しやすくなる
          • 入手可能なproductすべての一覧の作成も容易になる
      • 一意の識別子があればよい
        • 特別に定義した名前と日付があれば十分
      • 課題
        • componentや機能の間の依存関係とそれらに対するproductの依存関係の管理
          • release_cycle識別子を管理するruleやarchitectureの設計を通じて表現
      • 互換性のruleを守る必要がある
    • patch_release
      • productのsubset
      • 既知の不具合を含むcomponentを正確にreplace
      • 識別子の採番方法の問題
        • どんな場合でも実際に使われている機能に関係がある
        • 既存のproductに強く依存しているので，patchの識別子からproductを参照できるようになっていると分かりやすい
        • 原因と紐づけるため，名前と日付の参照
        • product name-x.y(.z(.build number))-patch nameとなる
        • 複雑なproductの場合は，patchで影響を受ける領域を示すこともある
          • technical supportのWebサイトでどのパッチをダウンロードすればよいかclientが見つけやすくするため
          • patch nameの前にoption nameを入れるようになる
      • あるproductに関する大量のパッチがあるなら，すべての保守releaseにまとめるのが〇
        • service packというapproachも〇
          • documentにパッチを累積的に適用するものかどうかはっきりと記載する
      • patchをバージョン管理するとしても，どうしても必要になるまではバージョン識別子を含めない方が良い
      • → product name-x.y(.z(.build number))-patch name.patch versionとなる
      • 洗練されたarchitectureでは，patchをproductを一緒にpackagingできるし，何がinstallされ何がinstallされないかを追跡できる
        • softwareを内部で実行し自動更新できるようになっていることもある
        • ManageSoftのように企業の管理者の代わりにさまざまなPCのソフトウェアのスナップショットを取得するproductを開発している会社もある
      • architectureを拡張して，パッチ管理機能を持たせたいとき
        • 何がinstallされ何がinstallされていないかを判断できるくらい，洗練されたarchitectureが必要
        • internetを通じて更新データを取得 → remote serverと通信する仕組みが必要
        • 前提条件が整っているか判断が必要
        • 自動更新がシステムや何らかの設定を壊すことなく正しくインストールできるかどうかを判断する必要
        • これらは極めて複雑な要件なので，一般的にはおすすめできない
      • column: bug fixは無料でなくてもよい
    • variation
      • 命名してその名前を識別文字列の中に意味のある形で含めるのが最もよい
      • portability, globalization, 性能特性などが要因となり複雑になることもある
      • 冗長でも間違えにくければ〇
  • SKU(Stock Keeping Unit, 在庫管理単位)とserial_number
    • SKUの管理
      • SKUによりreleaseを一意に識別でき，社内の在庫追跡システムで1つのreleaseをその他の全てのreleaseと区別できるようになる
      • 識別子としてのSKUはreleaseとは独立したもの
      • 使用される状況
        • 特定のreleaseへの注文情報，価格情報
        • 物理的な商品の在庫数
      • guideline
        • scope, targetには関係なく，販売するreleaseにはすべてSKUを割り当てる
        • scopeに関係なく，一般releaseにはすべてSKUを割り当てる
          • 一般消費者が入手できるものを追跡しやすい
        • 取引先管理システムや頒布管理システムでSKUをキーとして用いているなら，すべてのreleaseにSKUを割り当てる
          • 誰がそのreleaseを入手したか追跡できる
        • technical supportや無料download siteなど，self serviceのWebサイトに置かれるだけのreleaseには，SKUを割り当てないようにする
          • 販売されるわけではないので，財務システム内でSKUを払いだす必要がない
          • 誰が入手したか基本的には追跡不要
        • ただし，企業のpolicyに従う
      • SKUの形式は口出しできないが，必要な量は伝えられるし，目的を達成できる形式についてともに考えることはできる
      • SKU，外部名称，完全なrelease識別子の3つの論理的なcomponentを使う例
      • productに関連するSKUの総数の見積もり(以下の合計)
        • 完全release数*完全releaseのvariation数
        • SKUを与えられる特別release数*特別releaseのvariation数
        • option component数*option componentのvariation数
        • そのほか何らかの理由で生成されるSKUの合計
    • serial_number, registration, activation
      • SKUは，個々のclientに販売したproduct 1つ1つを区別することはできない → serial_numberが必要
      • serial_numberをキーとしてclientと企業が紐づく
      • activation: 強制的なregistration
        • licenseの強制
      • 電子productへのserial_numberの埋め込みはコストをかけて開発processの変更が必要
        • license強制スキームを適用して，softwareの複製や改変を防ぐ
      • serial_numberにより貴重な統計情報を収集でき，marketing campaignを調整できる
      • serial_numberが適切に登録されれば著作権侵害行為も減らせる
        • activationも効果がある
      • activationの手順
      • activation processを採用するかどうかは戦略的判断
        • vendorの提供するサービスを利用するときは，既存・計画中のbackend_systemやworkflowを照合して評価する必要
        • backend_systemを管理する方がactivationのvendorを選ぶよりずっと大変
  • tarchitectureへの影響
    • release_managementの要件の理解 → release_managementをより簡単にする選択ができるようになる: tarchitectureの改善
    • 考慮点
      • すべて作り直す
        • 出荷するものは全て導出（ソースから実行ファイルをビルド）か構築（Framemakerで作ったマニュアルを印刷）する
      • できるだけ既存のsolutionとinfrastructureを利用する
      • できる限り早い時点でtarchitectureにバージョン情報を組み込む
      • 各componentは自身が依存しているcomponentを把握しておく必要がある
        • data_driven_approachが1番簡単
        • 設定ファイルに書き込まれた依存関係を処理する，特殊な依存性check componentを使う
      • message, protocolのversion_control
      • DB, tableはバージョン情報が必要
        • schema内の各tableのバージョン識別子を含むシステムテーブルを作る
      • update可能なあらゆるcomponentはversion_controlが必要
      • 内部のcomponentは自分が必要とする外部のcomponentのversionを把握する必要
      • version_controlされたすべての成果物について，バージョンを取得する方法を提供する
      • patchに伴うテストやサポートに注意
        • 複雑さは指数的に増大する
  • まとめ
    • release_managementとは，productを求めているclientに対して，正しい成果物の提供を保証すること
    • 考え方
      • program family
      • component/成果物
      • version
      • revision
      • variation
      • distribution
      • release
    • release_managementには3つの要因
      • 何を誰になぜreleaseするか
    • releaseは区別が必要
      • 4桁の数字文字列は識別子として実績がある
    • SKUは経理やfulfillmentなど，back_office_systemでrelease_managementするために使われる
  • checklist
    • releaseごとに，何をreleaseし，誰が対象なのかを定義している
      • releaseに対するclientの期待値を見積もっている
    • releaseを区別する仕組みを定義した
    • SKUが必要なreleaseには，SKUが振られている
    • serial_numberが必要なreleaseには，serial_numberが発行されている

Ch16 security

  • securityが根本的に違うところは，物事を簡単にするのではなく難しくするものだという点
  • 成功するsolutionにとってきわめて重要だが，完成する直前まで見落とされがち
    • 初めから入れておく必要がある
  • virus, crack, 海賊
    • identity_control
      • 利用者ごと，役割ごとに異なるcapabilityを定義できる仕組みや，公にユーザの行動を追跡する仕組み，ユーザが申告通りのユーザであることを検証する仕組みを構築する必要
    • transaction_security
      • 安全な通信
      • 未認可のcomponentと置き換えたり，メッセージに介入したり，変更したり，ハイジャックしたりできないようにする必要がある
    • software_security
      • 未承認の人は誰もsoftwareを変更できないようにするべき
      • 未認可の権限昇格を許さない
      • virusや著作権侵害行為から守ってくれる
    • information_security
      • 未認可のアクセスを防ぐ
    • applicationにとってsecurityのどの要さが重要か明確にすることが，成功するsolutionを構築するカギになる
    • risk_control
      • 安全性を高める難易度は指数関数的に上昇する
      • riskは無視はできないが管理はできる
      • securityはmarketectとtarchitectが連携する分野
      • marketect
        • riskを評価する活動を率先して行う
      • tarchitect
        • さまざまな問題を解決する方法をmarketectに説明する
        • 自身のriskを評価する
      • 対処すべきリスクや仕組みを明らかにし，潜在的な問題への対象について難しい決定を下す
    • 見ざる，言わざる
      • riskは大きい
  • identity_control
    • 認可，誰に何ができるのか定義
      • 静的な側面
        • systemの中で特定の操作を実行する権限や特定の部分にアクセスする権限，DBの特定の部分にアクセスする権限を，どの主体が持つか定めること
        • 信頼できるユーザの作成，ユーザや分類に応じて権限を定義
      • 動的な側面
        • 指定されたユーザ・主体が特定の操作を実行したり，システムやDBの特定の部分にアクセスするために必要な権限を持っているかチェックすること
        • 実行時にチェック
          • 認可ルールはさまざまな動的なパラメタに基づくため
            • アクセスしたときの役割，直前の振る舞い，システムの状態，システムを利用している別のユーザの振る舞いを同時に考慮
      • 認可とアクセス制御を提供するtechnologyや権限管理システムには，利用できるものが多くある
      • 認可制御のために利用するシステムを分離し，自前の認可制御レイヤで包み込むのが〇
    • 認証，身元を証明する
      • 主体が誰で，誰であると主張しているかsystemが保証する
      • 認可に先駆けて行う処理として重要，信頼されたtransactionに参加するだけであっても必要
      • 第三者機関による同一性の証明が必要
      • 非公開システム
        • 第三者機関による同一性の証明の必要はほとんどない
        • systemの持つ構造や操作だけで，妥当な水準の認証機能を提供する
        • 認証の要素
          • userだけが知っている情報
          • userだけが持っている情報
          • user自身の情報
          • いずれか2つを組み合わせると強力な認証になる
          • きわめてセキュアな環境では3つすべてから，複合的に応用が必要
        • 認証方式は抽象化が〇
      • 公開システム
        • 独立した第三者機関が必要
          • 電子署名の利用
          • root証明書にいたるまでのそれぞれの証明書が外部機関によって署名されていることで，認証が正当化される
        • 認証機関で証明書の取り消しもできる
          • 認証機関との直接のやりとりが必要
          • 認証の取り消しが本当に必要かどうかは慎重に検討すべき
            • 証明書に基づく認証をほかの情報と紐づけている場合は，必ずしも必要ではない
        • globalなsolutionとなる認証機関が探し出しづらくなっている
        • これらの技術面，運用面での課題に加えて，ユーザに複雑さを説明するという課題もある
      • hybrid_system
        • e.g. email
  • transaction_security
    • client-server application, Web serviceにおいて最重要
    • 目的: 監査可能性，一貫性，機密性，説明性の成立
    • 監査可能性，行為の証明
      • 振る舞いの追跡のために認証に仕組みが必要
      • 一般的には，監査情報の複製を信頼できる第三者機関によって管理されたオフサイト拠点に置く
        • 改ざんは不可能
      • motive
        • 受動的には，政府および業界の規制やガイドラインへの対応が必要
        • 能動的には，何らかのfeatureを構築するために監査情報が必要なことがある
        • 新発見を求める同期として，時間をかければ何か興味深い傾向が発見されるのではという期待もある
    • 一貫性，情報の改ざん，改変を防ぐ
      • digest_function
      • 一貫性はたいていの場合監査可能性に関係する
        • systemの振る舞いの記録が改変されていないことを保証するため
    • 機密性，権限のないものから情報を隔離する
      • 2段階のprocessを持つSSLで情報を案硬化
        • まず，共通鍵で暗号化を保証，とても高速
        • 次に，共通鍵を，送信者が受信者の公開鍵で暗号化
        • 速度と暗号強度のバランスで〇
        • RC4よりも暗号強度に優れたalgorithmであるRijndaelの方が望ましい
    • 説明性，人々に自分の取った行動の責任を負ってもらう
      • 否認防止の仕組み
      • 公開鍵や秘密鍵の操作だけは，否認防止の仕組みから除外されている
      • また，公開鍵や秘密鍵に基づく操作であれば，どんな操作であっても同じく除外されている
      • → 厳格な認証なしには責任を追及できない
      • 強固な説明性には厳格な認証が必要
      • 電子署名は厳格な認証とともに使用される
  • software_security
    • technique
      • serial_number, activation
        • softwareにlicenseの電子署名を含めるものもある
          • 正しいlicenseと正しい署名が同時に存在しないと動かない
          • 署名に必要な秘密鍵が他人には利用できないため〇
        • crackerがreverse engineeringによりserial_numberを生成するalgorithmを解読し，自分で実装してしまうケース
          • licenseの電子署名に対しては，program自体の改変か，内包している公開鍵を自分たちの秘密鍵に対応する公開鍵に置き換えるくらいしかない
      • 検証コードの保護
        • 単に真偽値を返すだけのコードでlicenseをチェックしてはいけない
        • applicationが動作するために必要な何らかの情報を暗号化して，署名されたlicenseに埋め込んでおく方法が〇
          • 初期化routineやapplicationにsub_componentを登録する機能と同じくらい，きわめて重要な機能
          • 高度なlicense_managerの実装の難しさ → Ch04
      • hardware_binding
        • machine_binding
          • 低コストで〇
          • machineのupgrade困難で×
          • crackerが最もcrackしやすいことも×
        • hardware_binding
          • softwareをserial_portやUSB_portに接続した専用の物理デバイスと紐づける
            • 一般にドングル度呼ばれる
          • portability, security強度の高さで〇
          • 金銭的・管理コストで×
    • software_securityのコストと恩恵
      • 正当なuserに面倒な思いはさせないようにする
      • 対策を実装するリスクと，潜在的な利益損失を比較する
      • crackerのWeb siteやUsenetのsoftware一覧にある場合は，強力な防護策を検討する
  • information_security
    • 1か所からしかアクセスできないようにすることが1番の対策
      • firewall, 侵入検知システム, password_policy_checkerなどのuser_control_systemが〇
    • password security
      • digest値をDBに保存
      • または，internetからはアクセスできないserverのlocal file system上にパスワードを保存
    • 情報の窃盗の問題
      • 権限昇格
    • systemのarchitectureを統制
      • 有用なツールを利用する
  • algorithmを秘匿するか，鍵を秘匿するか
    • 秘匿されたalgorithmは×
      • 知られていないことによって成り立つsecurityは最弱
      • 公開されて利用可能な優れたalgorithmのどれか1つを採用するのが〇
    • 標準的なalgorithmと秘密鍵が〇
  • backdoor
    • 窓が増えるほど安全の保証は困難
    • systemの重要部分は100%の安全性の確保が必要
    • backdoorを作るくらいなら，パスワードと鍵を管理する別会社を紹介する方が良い
    • column: client supportはbackdoorを使ってclientを盗み見してはならない
      • backdoorは断固反対
  • securityとmarketecture
    • securityは特定の分野で目に見える競合優位性
    • 影響のある領域
      • 認証，business_model，運用
        • 強力な二段階認証が重大な影響 → business_model, 運用モデル
          • userがid, passwordを共有を防ぐ
        • clientからの信頼
      • 規制の影響
        • FIPSなど
      • 業界の発展
        • internetの標準規格に従うように対策 → 受け入れられやすくなる
      • 信頼
        • securityの知識や仕組みを根拠に信頼 → 競合優位性
      • 論争の解決
        • 一貫性や説明性のテクニックがあれば，そのときどきの最適なやり方で論争を解決できる
        • security technologyで問題を回避できる分野について，法務部門に見極めてもらう
        • column: あなたの主張を証明しなければならないのはいつか
          • log fileが法的な根拠となり得るように確認していたことで〇のケース
  • まとめ
    • applicationの全体的なsecurity計画においては，適切なrisk要因を考慮する必要
    • security 4種類
      • identity_control
      • transaction_security
      • software_security
      • information_security
    • identity_controlの主張なtool, technique
      • 認可制御
        • 誰が何ができるか設定
      • 認証制御
        • 身元の証明
        • 公開/非公開システムによって仕組みが大きく異なる
    • transaction_securityの主要なtool, technique
      • 監査可能性
      • 一貫性
      • 機密性
      • 説明性
    • software_securityの主要なtool, technique
      • 著作権侵害行為を防ぎ，license条項の遵守を促す
      • softwareを，それが実行される機会やhardware tokenと結び付ける
      • information_securityの主張なtool, techniqueは，transaction_securityに用いられるものと同様であるが，少し効果は落ちる
        • 主なtechniqueは，情報が格納される環境の安全性を確保すること
    • 自分たちでsecurity algorithmを開発するべきではない
      • 適切な鍵を用意して公開されているalgorithmを使う
    • backdoorは×
    • securityが自分たちの長所となるようにする
      • 第一級のブランド要素は信頼，securityはそれを支える

Appendix A release checklist

  • product追跡用の情報
    • product name
    • version
    • FCS日付(FCS: client向け初回出荷)
  • engineering, development
    • version文字列は最終バージョン情報で更新されているか
    • debug codeやtest codeはsoftwareから除去したか
    • 埋め込まれた欠陥は全て取り除かれたか
  • 品質保証
    • すべての欠陥について最終的な処置や解決は住んでいるか
    • 最終ビルドに対する適切なテスト(完全な回帰テスト，clientによる確認テスト，スモークテストなど)が完了しているか
    • release mediaによるまっさらな対象マシンへのprogram installは完了しているか
    • program(file, registryなど)は正しくinstallできるか
    • target machineからprogramはuninstallできるか
    • upgradeのinstallは完了しているか
    • 最終版のhelp fileが含まれているか
    • 最終版のreadme fileが含まれているか
    • 移行scriptはすべて完了しているか
    • support対象のplatformはすべてテストし，検証されているか
  • 技術出版物
    • release_note
    • product内のinline help(readme, release_note, quick start)
    • tarchitectによってreview済みの最新のtraining教材
  • product_managementの必須事項
    • press release
    • 既存clientへのemail campaign
    • sales training
    • price
    • 公開plan
    • 販促物(white paper, 用語集, Web site)
  • 知識の移転-専門service
    • clientはsystemのinstall, upgrade, integrationができるか
    • systemのinstall, upgrade, integrationにどのくらい時間がかかるか
    • installしたものを機能させるために，何らかの統合をやり直す必要があるか
    • training素材はreleaseと合わせて最新化されているか
  • 知識の移転-販売と販路
    • 販売チームは既存clientに新規releaseのmeritを説明できるか
    • 販売チームは新規clientに新規productのmeritを説明できるか
    • 以前のreleaseからの変更を含むbusiness_modelを完全に理解できているか（価格の変更や販促用の値引きなど）
    • 企業に提供されるsolution全体というcontextの中でproductについて説明できるか
  • 知識の移転-technical support
    • technical supportはproductをsupportする準備ができているか
  • release活動
    • releaseされたproductに含まれる最終的なファイルの一覧は入手できるか
    • release fileのtimestampは同期しているか
    • 最終頒布media(golden master)は入手できるか
    • 頒布用mediaのvirus scanは完了しているか
    • 頒布用mediaに含まれるfileの最終確認は完了しているか
    • build environmentのbackupは変更管理課に置かれているか
    • Web siteは最新化されているか

Appendix B 戦略的product_managementのためのpattern_language

  • marketect, tarchitectにとってそれぞれの専門分野の間にまたがるgapを埋めるのに役立つ
  • patternを適用する
    • market_mapの構築 → 統合期 → feature, meritの計画 → tarchitectureの進化の管理
    • market_mapから: 狙っているtarget_marketについて，product_development_teamの中でもかなり混乱があるため
    • 1つのpatternを選んで初めて見ることが重要
      • patternは体系の一部でしかない
      • feedback loopの中で，1つのmarket_segmentを見定めることから始める
        • そのうえでmarket eventやfeatureを追加
  • 結果を表現して共有する
    • 誰にでもアクセスできる場所に専用のスペースを設けて，大きなchartを一式掲示が〇
  • market_map
    • context
      • 新しいproductのideaについて，潜在的な価値を理解しようとしている
      • 既存のproductのmarketingが効率よく行われることを確かめたい
    • 問題
      • marketをどのようにsegment分割するか
    • force
      • market_segment分割は難しい
        • 既存のmarket歯変化する
        • 台糖市場の予測は，科学的な取り組みであるのと同じくらいセンスが問われる
      • market_segment分割は極めて重要
        • まるごと相手にしては必ず失敗するだろう
        • market_segmentが異なればsolutionも異なる
      • うまくsegment分割できなければ，最も収益性の高いsegmentを見定めることもできない
      • marketのすべてのニーズを満たすことはできない
      • usabilityを考えるには，対象のmarketのことの理解が必要
    • solution
      • 同じ特徴や属性を共有するuserを分類したりgroupingしたりして，market_segmentを分割
      • 特徴
        • 決定的なニーズや購買パターン，そのほか重要な何らかの属性
        • 消費者市場の属性
          • 年齢，世帯収入，internet接続できるか，技術リテラシーなど
        • ビジネス市場の属性
          • 収益，従業員数，事業所の所在地
      • 初めは，現在のproductを実際に使っているuserに集中
        • userが直面する問題を見定める
      • できるだけうまくsegmentを定義
      • 妥当な数のsegmentになったら，featureを並び替え
      • market_mapはteam_member全員に渡す
    • 結果として現れるcontext
      • 次のproduct cycleで取り組むsegmentをより精密に分析できるようになるかもしれない
    • 関連するpattern
      • market event/market rhythm
      • feature/merit map
  • market event/market rhythm
    • context
      • 特定のreleaseや今後予定されている一連のrelease_cycleをmarketに投入する次期を見定める
      • market_segmentの調査に役立つmarket_mapが既存
    • 問題
      • 適切なrelease日を決めるにはどうすればよいか，今後のrelease_cycleを確立するにはどうすればよいか
    • force
      • たいていのclientはいつでもreleaseを受け入れてくれるわけではない
      • clientはreleaseがあまりに頻繁なことに耐えられないが，遅すぎても心配する
      • developerはrelease_dateが未定なことを嫌う
      • 販促活動には十分なリードタイムが必要
      • releaseまでの期間が短すぎるとほぼ間違いなく失敗する
      • releaseまでの期間が長すぎても失敗する
      • 長期間productをreleaseしていないと，組織から貴重なスキルが喪失
      • 長期間productをreleaseしない組織で働いていても楽しくない
    • solution
      • どんなドメインにもマーケットを動かす原動力となるようなイベントとリズムがある
      • 重要なevent
        • conference
        • 競合他社のpress release
        • productが関連するdomainに焦点を合わせた特集記事や，product/serviceに関連する特集記事
      • その他のrhythm: 歳末，新学期，夏季休暇など
      • 今後のreleaseをmarketに投入する時期やrhythmを決定する
        • 9~12か月の間でが定期的なrelease_cycle
      • market_segmentの成熟度もrelease_cycleに影響する
    • 結果として現れるcontext
      • developerは根拠を理解できる
      • release_dateの共有はdevelopment_team全体を活気づけ結びつける
      • 戦略レベルの計画の実現性を保証でき，clientが満足
    • 関連するpattern
      • market_map
  • feature/merit map
    • context
      • 重要なmarketing目標とdevelopmentで力を入れている部分の整合性の確認
      • 重要なmarket_segmentを見定めるためのmarket_mapがある
    • 問題
      • それぞれのmarket_segmentにとって魅力的なfeature, meritを表現するにはどうすればよいか
    • force
      • 特定のmarket_segmentにおける重要なfeatureとmeritを理解できていると誤認しがち
      • 1つのfeatureが複数のmarket_segmentにとってのmeritになることもある
      • 複数のmarket_segmentに訴求するfeatureがあっても，それぞれのmarket_segmentにとってのmeritは同じではない
      • developerはfeatureのことだけを考える傾向がある．marketing担当者はmeritのことだけを考える傾向がある
        • 相違をそのままにしておくと，marketで成功するはずもない粗末なproductになる
      • developerはfeatureのもたらす将来的なmeritについて，その性質や意図の質問が必要
        • tarchitectureの設計がそれらに見合ったものかどうか確かめるため
    • solution
      • 各market_segmentについて，productの購入を望む重要なfeature, meritを表現する
      • feature/meritは並べて書くことが重要
        • 省略は×
      • mapの並び順を整える
        • releaseまでの所要時間，featureの難易度や複雑さ，marketの要望の順など
      • treeでのfeatureの描画
        • productの成長の実感
        • product_development_teamの規模の拡大と関連
    • 結果として現れるcontext
      • target market_segmentの攻略のために必要な，主要なfeature/meritを表現
      • tarchitecture_loadmapを最新化するために必要な情報が技術担当チームに提供される
    • 関連するpattern
      • market_map
      • tarchitecture_loadmap
  • tarchitecture_loadmap
    • context
      • 今後も含めて複数回のreleaseを期待されたapplicationを開発している
      • market_segmentを見定めるためのmarket_mapと，market_segmentが求めているfeatureを見つけるためのfeature/merit mapがある
      • 複数のmarketに対応できるarchitectureがあるかもしれない
    • 問題
      • 技術的な変化をどのように管理し，どのように活用するか
    • force
      • applicationのarchitectureがどれほどうまく構成されていても，technologyが変化することで以前の目論見が無意味になる
      • たとえ計画していたとしても，十分な時間をかけて順応しなければtechnologyの全貌を捉えられない
      • developerは目標を知りたがる
      • developerは新しいことを勉強するのが大好き
      • developerは安易に実装されたfeatureやcapabilityをtarchitecture的に進化させる方法を追及している
        • みすぼらしいfeature/capabilityを明らかにし，改修案とともに記録する方法を求めている
      • marketing部門が望んでいる新しいfeatureは，technologyが変化することで実現できるようになるかもしれない
      • marketing部門が望むfeatureは新しいtechnologyでしか実現できないかもしれない
      • 競合他社が新しいtechnologyを採用すると，自分たちは不利な立場になるかもしれない
      • 技術脳の人間は核心的なtechnologyにあれこれ反論する
        • 時には議論を通じて課題を学ぶことになる
        • 合意のための唯一の方法は，議論に十分な時間を割くこと
    • solution
      • architectureの進化の歩みを示すtechnology loadmapを作る
      • 主要なmarket_segmentにmeritをもたらすtechnologyを示すことで，technology loadmapとmarket_map, feature/merit mapを関連付け
      • 重要なmilestoneを達成したときや，何も起きなくても少なくとも6か月ごとに，technology loadmapを見直す
        • 内部的なmilestone
          • code freeze，productの出荷，既存顧客の半分以上が最新versionへupgradeしたことなど
        • 外部的なmilestone
          • 競合他社による新しいproductのrelease発表，新しい特許の公開，技術スタッフが次世代のtechnologyを発見する，重要なmarket eventが生じる
      • technology loadmapを作成して維持していくには，少なくともチームの中の1人が外部の環境で新しい開発方法を実践する必要がある
      • needsを満たす新しいtechnologyが登場していないか定期的に確認できる → チームに集中力
    • 結果として現れるcontext
      • 将来productに搭載されるかもしれないfeatureを見通せるようになる
      • teamの規律があいまいだと，新技術渇望症候群(SNOS: Shiny New Object Syndrome)にかかってしまう
    • 関連するpattern
      • market_map
      • feature/merit map

訳者あとがき

  • Web baseのserviceの進化に伴い，licenseやinstall, upgradeに対する考え方は現在にそのまま当てはまらない