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

Transcript

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

2. 自己紹介 • 末並 晃 @a_suenami • 生息している界隈: DDDとか、TDDとか、RDBとか • お仕事で使ってる技術スタック:

   Rails, React, 最近 Java とかも 少々 • 好きな RDBMS: PostgreSQL • 好きな制約: チェック制約 • 好きな焼肉の部位: ハラミ • 好きな（ｒｙ

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

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

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

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

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

8. ユーザーファーストの功罪 • ユーザーファースト ≠ ユーザの言いなり • 何も考えずに開発をすすめると、アプリケーションの構造がその 時点でのユースケースと密結合になる。 • 分析や設計をするべきポイントはおさえておく必要がある。

   • 「あとでリファクタリングする」の罠。 ◦ その「あとで」は永遠に訪れない。 ◦ 市場からのプレッシャーが弱まることはない。

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

   あるべき姿と言える

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

11. SoRとSoE • SoR: System of Record ◦ その名の通り、「記録」のためのシステム。 ◦ 入力の事前チェックの堅牢性、データ整合性の担保などが求

    められる。 • SoE: System of Engagement ◦ 利用者との関係を構築するためのシステム。 ◦ 今どきの言葉を使うとよい UX を提供するためのシステム、と 言い換えてもよい。

12. SoRとSoEの対比 SoR SoE 基本的な設計観点 データ整合性 柔軟性、性能 データストア トランザクショナルな DB 多くの場合、RDB

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

13. 事例: 2-sided platform • モール型 E-Commerce サービスを考える • アプリケーション利用者 ◦

    予約者ユーザ ◦ 店舗ユーザ モール型 EC プラットフォーム 購入者 店舗

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

15. 複数のアクターの要求がDBに直撃する 購入者 出荷担当者 いつ届くの？ キャンセルしたい 商品を間違ったので 変更したい 出荷しないと！ 在庫が残り少ないので仕 入れ指示をしたい

    キャンセルされたので出 荷を止めます 共通DBにある語彙はは購入者と出荷担当者で同一のように思 われるが、多くの場合、次第に乖離し始める。 共通DB ふ、ふええ…

16. 中央に事業者向けのモデルがあると考える 購買者向け システム 購入者 店舗 店舗向け システム 事業者の モデル •

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

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

    モデル SoE SoR
18. None

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

20. 共通性と可変性 • 共通性と可変性。 ◦ マルチパラダイムデザインにおいて、設計の中心とされている 概念。 • 共通性は分析によって見出し、可変性は実験によって最適化す る。 ◦

    共通性の発見には従来の分析手法が依然として重要。 よいアーキテクチャとはよい抽象を提供する

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

22. 例: 地図 • 方角、距離、面積などのあらゆ る変数があるなか、それを正 確に表現できているのは地球 儀のみ。 ◦ それでも完全に正確とは言 えない。

    • メルカトル図法、正距方位図法 など、目的に応じてさまざまな 図法がある。

23. 例: 連立方程式

24. 共通性と可変性の例 共通性 可変性 型 総称型（ジェネリクス） クラス、オブジェクト 型パラメータ Trait 外部キー制約 参照整合性

    存在（挿入）の順序 実際の存在タイミング 開発フロー Git チケットやそのステータス ブランチモデル（git-flow, github-flow） ワークフロー設定 請求管理 / 収支管理 複式簿記 請求ルール（締日、支払いサイト etc） 割引ルール、その他業務ルール 記事掲載管理 記事フォーマット 公開/非公開基準 執筆時のライフサイクル レビューフロー 飲食店予約管理システム 予約確定条件 座席確定タイミング 決済手段

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 / 共通 性 の分析も重要である。

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

    『キングダム』 46巻

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

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