“ユーザーファースト”の功罪 〜分析と実験によるアーキテクチャ設計〜 #bpstudy

BPStudy#147 で発表したものです。

Transcript

1. “ユーザーファースト” の功罪
   〜分析と実験によるアーキテクチャ設計〜
   2019/11/29 BPStudy#147
   末並 晃 @a_suenami
   

   View Slide

2. 自己紹介
   ● 末並 晃 @a_suenami
   ● 生息している界隈: DDDとか、TDDとか、RDBとか
   ● お仕事で使ってる技術スタック: Rails, React, 最近 Java とかも
   少々
   ● 好きな RDBMS: PostgreSQL
   ● 好きな制約: チェック制約
   ● 好きな焼肉の部位: ハラミ
   ● 好きな（ｒｙ
   

   View Slide

3. インターネット上での立場
   

   View Slide

4. インターネット上での立場
   ひたすら焼肉をタカられるという
   エンターテイメントをインターネットに提供し
   ています。
   （焼肉を奢るとは言ってない）
   

   View Slide

5. インターネット上での立場
   とはいえ、すえなみチャンスは
   わりと真面目に募集しています。
   いろいろ教えてください。
   

   View Slide

6. TB; DR
   ● ユースケースやユーザーストーリーと呼ばれるものはアプリケー
   ションアーキテクチャ（＝データやアプリケーションの構造）を導出
   しない。
   ● アーキテクチャにはユーザーではなく事業者の意思が反映され
   るべきであり、それを見出すのが設計である。
   

   View Slide

7. “もし顧客に、彼らの望むものを聞いていたら、
   彼らは『もっと速い馬が欲しい』と答えていただろう。”
   ヘンリー・フォード
   

   View Slide

8. ユーザーファーストの功罪
   ● ユーザーファースト ≠ ユーザの言いなり
   ● 何も考えずに開発をすすめると、アプリケーションの構造がその
   時点でのユースケースと密結合になる。
   ● 分析や設計をするべきポイントはおさえておく必要がある。
   ● 「あとでリファクタリングする」の罠。
   ○ その「あとで」は永遠に訪れない。
   ○ 市場からのプレッシャーが弱まることはない。
   

   View Slide

9. ユーザーファーストの功罪
   ● ユースケースやユーザーストーリーはユーザーの語彙で記述さ
   れる素朴な要求であり、理解が容易。
   ● ユーザにとっての価値をベースにしているので、優先度をつけや
   すい。
   ユースケースやユーザーストーリー記述をもとにして
   短期的な要求を満たしながら、
   中長期的な変更に耐えられる構造にするというのが
   あるべき姿と言える
   

   View Slide

10. https://speakerdeck.com/a_suenami/hisinesufalsegou-zao-woxi-uakitekutiyatoyusatofalsejie-dian-woxi-uakitekutiya-number-builderscon
    

    View Slide

11. SoRとSoE
    ● SoR: System of Record
    ○ その名の通り、「記録」のためのシステム。
    ○ 入力の事前チェックの堅牢性、データ整合性の担保などが求
    められる。
    ● SoE: System of Engagement
    ○ 利用者との関係を構築するためのシステム。
    ○ 今どきの言葉を使うとよい UX を提供するためのシステム、と
    言い換えてもよい。
    

    View Slide

12. SoRとSoEの対比
    SoR SoE
    基本的な設計観点 データ整合性 柔軟性、性能
    データストア
    トランザクショナルな DB
    多くの場合、RDB
    スケーラビリティがある高速なデータ
    ストア
    ドキュメント指向DB、KVS、全文検索
    インデックスなど
    リリースサイクル
    SoEと比べると相対的に長い（諸説あ
    るかも）
    高速なリリースサイクルが求められる
    品質評価
    トラディショナルなソフトウェアテスティ
    ング手法を適用しやすい
    トラディショナルな手法に加え、ユー
    ザーテスト、ユーザーインタビュー、
    A/Bテストなど
    カナリアリリースも実トラフィックを利
    用したテストと捉えることができる
    データ整合性 トランザクション整合性が必須 結果整合性でよい要件も多い
    要するに？ 堅牢なMutation 柔軟なQuery
    設計を駆動する（しやすい）もの
    ドメインモデル、概念データモデル UI（ビジュアルデザイン、ユーザインタ
    ラクション）、キャッシュ
    

    View Slide

13. 事例: 2-sided platform
    ● モール型 E-Commerce サービスを考える
    ● アプリケーション利用者
    ○ 予約者ユーザ
    ○ 店舗ユーザ
    モール型
    EC プラットフォーム
    購入者 店舗
    

    View Slide

14. 分断されたモノリス
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    共通DB
    

    View Slide

15. 複数のアクターの要求がDBに直撃する
    購入者 出荷担当者
    いつ届くの？
    キャンセルしたい
    商品を間違ったので
    変更したい
    出荷しないと！
    在庫が残り少ないので仕
    入れ指示をしたい
    キャンセルされたので出
    荷を止めます
    共通DBにある語彙はは購入者と出荷担当者で同一のように思
    われるが、多くの場合、次第に乖離し始める。
    共通DB
    ふ、ふええ…
    

    View Slide

16. 中央に事業者向けのモデルがあると考える
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    事業者の
    モデル
    ● DB を直接共有しないため、利用者アクターのユースケースに依
    存しない不変条件を維持することができる。
    ● システム全体が、事業者、購買者、店舗をそれぞれの要求元とす
    るサブシステムに分割された。
    

    View Slide

17. SoR と SoE
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    事業者の
    モデル
    SoE SoR
    

    View Slide

18. View Slide

19. What the system “is” / What the system “does”
    ● What the system is
    ○ User thinking
    ○ Classes & Objects
    ○ Domain Experts & Architects
    ○ Database schema
    ○ Long-term stable structure
    ● What the system does
    ○ User doing
    ○ Roles, Identifiers, Activation records
    ○ End Users & User Experience people
    ○ Interface design
    ○ Ever-changing functionally
    

    View Slide

20. 共通性と可変性
    ● 共通性と可変性。
    ○ マルチパラダイムデザインにおいて、設計の中心とされている
    概念。
    ● 共通性は分析によって見出し、可変性は実験によって最適化す
    る。
    ○ 共通性の発見には従来の分析手法が依然として重要。
    よいアーキテクチャとはよい抽象を提供する
    

    View Slide

21. “時を告げるのではなく時計を作る”
    『ビジョナリー・カンパニー 時代を超える生存の原則』
    

    View Slide

22. 例: 地図
    ● 方角、距離、面積などのあらゆ
    る変数があるなか、それを正
    確に表現できているのは地球
    儀のみ。
    ○ それでも完全に正確とは言
    えない。
    ● メルカトル図法、正距方位図法
    など、目的に応じてさまざまな
    図法がある。
    

    View Slide

23. 例: 連立方程式
    

    View Slide

24. 共通性と可変性の例
    共通性 可変性
    型
    総称型（ジェネリクス）
    クラス、オブジェクト
    型パラメータ
    Trait
    外部キー制約
    参照整合性
    存在（挿入）の順序
    実際の存在タイミング
    開発フロー
    Git
    チケットやそのステータス
    ブランチモデル（git-flow, github-flow）
    ワークフロー設定
    請求管理 / 収支管理
    複式簿記 請求ルール（締日、支払いサイト etc）
    割引ルール、その他業務ルール
    記事掲載管理
    記事フォーマット
    公開/非公開基準
    執筆時のライフサイクル
    レビューフロー
    飲食店予約管理システム
    予約確定条件 座席確定タイミング
    決済手段
    

    View Slide

25. まとめ
    ● アプリケーションの要求元を事業者と利用者に分け、そのそれぞ
    れについてモデルを構築し、実装を考えると、それは一般に SoR
    / SoE の特性と呼ばれているものと一致する。
    ● SoR / SoE という分類は Lean Architecture における What the
    system is / What the system does との対応やマルチパラダイ
    ムデザインにおける共通性 / 可変性とも高い関連性がある。
    ● SoE / What the system does / 可変性 はユーザーに対する価値
    の源泉であるが、それを支える SoR / What the system is / 共通
    性 の分析も重要である。
    

    View Slide

26. 『キングダム』 李斯の言葉
    “法とは願い！
    国家がその国民に望む人間の在り方の理想を
    形にしたものだ！
    統一後
    この全中華の人間にどうあって欲しいのか
    どう生きて欲しいのか
    どこに向かって欲しいのか
    それをしっかりと思い描け！”
    『キングダム』 46巻
    

    View Slide

27. アーキテクチャとは願い！
    

    View Slide

28. ご清聴ありがとうございました。
    

    View Slide