Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ドメインと向き合う - 旅行予約編
Search
hidenorigoto
September 28, 2024
Technology
4
700
ドメインと向き合う - 旅行予約編
2024.09.28
PHPカンファレンス沖縄2024
hidenorigoto
September 28, 2024
Tweet
Share
More Decks by hidenorigoto
See All by hidenorigoto
「ソフトウェア設計」のドメイン - 「データモデリングでドメインを駆動する」を読んで
hidenorigoto
10
2.8k
メルカリ バックエンド領域のこれまでとこれから
hidenorigoto
1
420
メルカリのエンジニアリング組織の変化〜Engineering Managerの視点から〜
hidenorigoto
0
8k
The changes of the engineering organization in Mercari - from the view of an engineering manager -
hidenorigoto
0
270
PHPerKaigi 2019 ランチセッション (3/31)
hidenorigoto
1
3.9k
抽象化って何? (What is abstraction?)
hidenorigoto
9
4.4k
抽象化って何? (What is abstraction?)
hidenorigoto
11
6.6k
続・SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則 センパイのコーディングノート編〜
hidenorigoto
14
5.8k
SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則編(拡大版)〜
hidenorigoto
9
5k
Other Decks in Technology
See All in Technology
スタートアップで取り組んでいるAzureとMicrosoft 365のセキュリティ対策/How to Improve Azure and Microsoft 365 Security at Startup
yuj1osm
0
210
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
260
Qiita埋め込み用スライド
naoki_0531
0
4.8k
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
110
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
13
3.7k
WACATE2024冬セッション資料(ユーザビリティ)
scarletplover
0
200
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
250
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
160
podman_update_2024-12
orimanabu
1
270
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.8k
Microsoft Azure全冠になってみた ~アレを使い倒した者が試験を制す!?~/Obtained all Microsoft Azure certifications Those who use "that" to the full will win the exam! ?
yuj1osm
2
110
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Building Adaptive Systems
keathley
38
2.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Building Applications with DynamoDB
mza
91
6.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
Being A Developer After 40
akosma
87
590k
Building an army of robots
kneath
302
44k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Transcript
None
@hidenorigoto 後藤 秀宣 ポッドキャスト『エンジニアリングマネージャーの問題集』 #EM問題集
ビジネス側と会話ができる! ビジネス側の気持ちが分かる! この発表のゴール ソフトウェアエンジニアとして、「ドメインと向き合う、ビジネスと向き合う」た めの実践的なプラクティスをおさえる!! ❌ ビジネス側や経営者と同じレベルで議論できるようになることは、スコープ外 ビジネス側の考えを、ソフトウ ェア作りに反映しやすくなる! ❌
細かい設計方法、実装方法は出てきません
ドメインと向き合うためには、ビジネスと向き合 うことが必須 ビジネスは、ドメインやソフトウェアの構造を決 定づける非常に重要なインプット 最初に 本日の内容は「ビジネスの見方の入門」
フレームワークで見る 自分が設計する 現場への無限の興味と 最大限のリスペクト 名も無い現場 ビジネスとドメインに向き合うプラクティス
ビジネスの一般論 フレームワークや理論 ドメインの一般論 ドメイン分析、モデリング技法 業界でのビジネス慣習 同じドメインを扱う業界での一般論 自分たちのビジネス 自分たちのドメイン 自分たちのソフトウェア ビジネス、ドメイン、ソフトウェア
ビジネスの一般論 フレームワークや理論 ドメインの一般論 ドメイン分析、モデリング技法 業界でのビジネス慣習 同じドメインを扱う業界での一般論 自分たちのビジネス 自分たちのドメイン 自分たちのソフトウェア ビジネス、ドメイン、ソフトウェア
どうやって儲ける か?
ビジネスの一般論 フレームワークや理論 ドメインの一般論 ドメイン分析、モデリング技法 業界でのビジネス慣習 同じドメインを扱う業界での一般論 自分たちのビジネス 自分たちのドメイン 自分たちのソフトウェア ビジネス、ドメイン、ソフトウェア
一定継続性のある 業務のやり方
ビジネスを理解するフレームワーク 3つ PPM プロダクト・ポートフォリオ・マネ ジメントによる分類 事業経済性の分類 5F(ファイブ・フォース)分析 (時間の都合でスキップ) 自社において、事業やプロダクトが置かれて いるフェーズを知る
マーケットにおいて、事業やプロダクトが置 かれている競争環境を知る 事業やプロダクトの経済的特性を知る
ビジネスを理解するフレームワーク 1 5F(ファイブ・フォース)分析
5F(ファイブ・フォース)分析 新規参入の脅威 売り手の 交渉力 市場全体の特性 買い手の 交渉力 代替品の脅威 競争環境
新規参入の脅威 売り手の 交渉力 買い手の 交渉力 代替品の脅威 競争環境 登録制(旅行業)。大きく展開す るには保証金の額も高くな る。
仕入れ提携などハードルが高 い どのOTAで予約しても施設・ サービスは基本的に同じ。イ ンターネットで特に価格の比 較が容易 需給に依存するが、送客力が よほど強いなどがなければ、 売り手の方が強い 巨大OTAの場合は逆転 圧倒的に大きなOTAが 市場を支配 他の娯楽がいくら でもある 5F - OTA業界
ビジネスを理解するフレームワーク 2 事業経済性
事業経済性 規模の経済性 稼働率の経済性 事業運営をスケールさせる際の特性や制約 ネットワーク効果 経験効果 範囲の経済性 密度の経済性 規模を拡大(生産量を増やす)するほど効率的になる(1製品あたり の固定費が下がる、仕入れ原価が下がるなど)
施設・設備などを稼働させる方式のため、規模は施設で扱える規模 までしか大きくならない。基本的に稼働を高く維持することが効率 的になる。 サービス利用者が増えるほどサービスの 価値が高まるもの。電話、CtoCマーケッ トプレイス 経験やノウハウが蓄積されるほど価値が 高まるもの。
事業経済性 - OTA (Online Travel Agent) 規模の経済性 ユーザーベースを拡大することに、自社のサービス運営においての物理的制約はない。 (サーバーコストや、サポートコストなどは関連性があるが、事業の特性としてハードにセットされて いるものではなく、解決可能)
規模を拡大するほど、サプライサイド(ホテルや、流通中間業者)に対して強い交渉力を持つ。結果、 仕入原価を低く抑えることができる。
事業経済性 - ホテル 稼働率の経済性 物理的な資産を保有(大くの場合、大きなコストをかけて建築するため固定費が大きい)し、この資産 を有効活用し、計画した期間内にコストの回収に加えて利益を生み出す。 ホテルを稼働させる場合、ホテル内の設備やスタッフなどの稼働が必要であり、ホテルの稼働率に対し て連続的に比例したコストとはならない。例えばホテルの稼働がどれだけ低くても、一定の最低運営コ ストがかかる。 このため、安定して送客を供給できる販売チャネル(現在ではOTAが主力)に依存する構造になりやす
い。
ビジネスを理解するフレームワーク 3 PPM(プロダクト・ポートフォリオ・マネジメン ト)による分類
金のなる木 負け犬 問題児 花形 投資 PPM 市場成長性 市場におけるシェア 低 高
高 低 投資 移行を狙う 移行を狙う
PPM ソフトウェアエンジニアリング観点では、1つのプロダクトを複数の機能単位 (もしくはドメイン単位)に論理的に分割することが可能。この分割したそれ ぞれをPPMの観点で眺めたときに、「ビジネス観点では」どこに投資すべきか を検討することができる。 例 大規模なリファクタリングやリアーキテクチャをエンジニアリング観点で実施する場合の実施理由、 および対象領域の選定理由
ポイント フレームワークで見る 自分が設計する 現場への無限の興味と 最大限のリスペクト 名も無い現場 最低限知っておくだけ でも理解が捗る! 目の前にある自分たち の現場を大事にする!
現場のあらゆる仕事に 興味を持ち、仕事をす る人をリスペクトして 向き合う!
注意! フレームワークや一般論ばか りをありがたがり、そこしか 勉強しない。 理論と違うからといって現場 を否定する。 NG! 事業がまわり収益を上げているのであれば、そこ には必ず何らかの正しさがある。
ドメインとソフトウェアをどうするか?
旅行予約(OTA)について、ここまでをま とめると・・・ 買い手(消費者)側と売り手(ホテルや流通)側、それぞれ交渉力が強い。 特に売り手側は歴史もあり、業界の慣習や構造が根強く残っている。 買い手(消費者) に対して 消費者に対して、他のOTAと差別化するような価値・魅力 を探索し続ける必要がある。 売り手 (ホテルや流通)
に対して 仕入れについては、現状複雑な状況になっている(大きな力 を持つ複数のプレイヤー、統一仕様がない)。継続的なビジ ネス交渉と開発投資を行う必要がある。 このあたりが、ビジネス側の気持ち
旅行予約(OTA)について、ここまでをま とめると・・・ 買い手(消費者)側と売り手(ホテルや流通)側、それぞれ交渉力が強い。 特に売り手側は歴史もあり、業界の慣習や構造が根強く残っている。 買い手(消費者) に対して 消費者に対して、他のOTAと差別化するような価値・魅力 を探索し続ける必要がある。 売り手 (ホテルや流通)
に対して 仕入れについては、現状複雑な状況になっている(大きな力 を持つ複数のプレイヤー、統一仕様がない)。継続的なビジ ネス交渉と開発投資を行う必要がある。 ここは何らかの摂理面。社内でも別の部署
ソフトウェアのアーキテクチャ アーキテクチャ(大構造)を決定するには? ドメインの構造? 「業務」の単位での分割や構造ということか? → これだけでは不十分 仕事のしやすさを生み出す構造 || アーキテクチャの1つの目的 ※エンジニアの仕事だけでなく、会社全体の仕事のしやすさを考える。
ソフトウェアのアーキテクチャとして 消費者向けの要素 ホテルや流通 向けの要素 チャネルマネージャー 接続(複数) ホールセラー 接続(複数) 検索・予約機能 会員機能
プロモーション サービスの 管理機能 コンテンツ管理 予約管理 会員管理 問い合わせ管理 値付け
ソフトウェアのアーキテクチャとして 消費者向けの要素 ホテルや流通 向けの要素 チャネルマネージャー 接続(複数) ホールセラー 接続(複数) 検索・予約機能 会員機能
プロモーション サービスの 管理機能 コンテンツ管理 予約管理 会員管理 問い合わせ管理 値付け 旅行予約ドメインの要素
ソフトウェアのアーキテクチャとして 消費者向けの要素 ホテルや流通 向けの要素 チャネルマネージャー 接続(複数) ホールセラー 接続(複数) 検索・予約機能 会員機能
プロモーション サービスの 管理機能 コンテンツ管理 予約管理 会員管理 問い合わせ管理 値付け ビジネス(消費者向け)の 要素
ソフトウェアのアーキテクチャとして 消費者向けの要素 ホテルや流通 向けの要素 チャネルマネージャー 接続(複数) ホールセラー 接続(複数) 検索・予約機能 会員機能
プロモーション サービスの 管理機能 コンテンツ管理 予約管理 会員管理 問い合わせ管理 値付け ビジネス(売り手向け)の 要素
仕事のしやすさで くくりなおしてみると...
旅行予約 関連機能群 販売・プロモーション 機能群 旅行予約 仕入れの共通化層 仕入チャネル A 仕入チャネル B
仕入チャネル C 値付けの 共通化層 ソフトウェアのアーキテクチャ ・・・ 増やしていきやすい 色々試しやすい 強化しやすい
ソフトウェアのアーキテクチャ ビジネスに沿った、「••しやすい」 を組み込めている。 ※仕事のしやすさを生み出す構造=アーキテクチャの1つの目的 「ソフトウェアのどの要素に対して、どのような活動が行われるのか?」 ビジネス目的の活動と、それを支えるソフトウェア側の活動とが、 同時にやりやすくなっている。
ポイント フレームワークで見る 自分が設計する 現場への無限の興味と 最大限のリスペクト 名も無い現場 「自分たちの問題」が スタート地点であり、 ゴールでもある 自分たちのビジネスと
ドメインに最適な構造 を設計する!
まとめ
フレームワークで見る 自分が設計する 現場への無限の興味と 最大限のリスペクト 名も無い現場 ビジネスとドメインに向き合うプラクティス
ビジネスを理解するフレームワーク 3つ PPM プロダクト・ポートフォリオ・マネ ジメントによる分類 事業経済性の分類 5F(ファイブ・フォース)分析 (時間の都合でスキップ) 自社において、事業やプロダクトが置かれて いるフェーズを知る
マーケットにおいて、事業やプロダクトが置 かれている競争環境を知る 事業やプロダクトの経済的特性を知る フレームワークを使って 自分の取り組んでいる事業・サービスを 分析してみてください!
ビジネス側と会話ができる! ビジネス側の気持ちが分かる! この発表のゴール ソフトウェアエンジニアとして、「ドメインと向き合う、ビジネスと向き合う」た めの実践的なプラクティスをおさえる!! ビジネス側の考えを、ソフトウ ェア作りに反映しやすくなる!
参考書籍 新版グロービスMBA経営戦略
ご清聴ありがとうございました!!! Xフォローお願いします! @hidenorigoto ポッドキャスト『エンジニアリングマネージャーの問題集』 #EM問題集
余談1 旅行予約 関連機能群 販売・プロモーション 機能群 旅行予約 仕入れの共通化層 仕入チャネ A 仕入チャネル
B 仕入チャネル C 値付けの 共通化層 航空券 仕入れ 航空券 予約機能 全く違う!
余談2 仕入れチャネルごとに、APIはかなり異なる! Pull型 vs Push型 ファイル型 vs SOAP vs REST
標準スキーマをある程度利用 vs 勝手スキーマ vs API仕様がExcel フィールド名がtypo 拠り所を見つけづらい! (俺が考えた最強の〜〜 が横行しやすい)
余談3 航空券予約ドメイン、宿泊と違いすぎッ! PNR、DWR、HK、TK、TKT、CPN、SEG、マリッジ、TATOO番号、VOID・・・ 何を言っているのか分からない、からスタート 用語の問題だけでなく、取り扱い方が非常に細かい 詳しそうな方にひたすら聞く
余談4 消費者向けシステムは、分解すれば大きなドメインのカタマリ 会員管理 決済 検索 SEO ・・・ それぞれ侮れない深みのあるドメイン。 しかし、初手からここの区切りで物事を分割すべきかは、慎重に検討が必要。 消費者へ提供する価値を大枠で探索しているフェーズでは、細かい分割が足枷にな
ることも。
余談5(想定質問) 純粋なSaaSで、仕入れがないんですけど? 事業経済性で言えば、多くは規模の経済性にあたる。 事業をスケールさせる上で、何がボトルネックになっているか? また変数とし て認識されているものは何か? 営業の人数 サーバーの処理能力 エンジニアの人数?
余談6(想定質問) CTOじゃなくても、このレベルの理解は必要? 役に立つか? 自分のチームで起きている問題の根を探ると、このような話に行き着くことがよ くある。 他のチームとの境界があるにもかかわらず、特定のチームといつも連携プレ イが必要という問題 自分たちのチームが提案するソリューションが、ビジネス側に理解されな い、反対されるという問題 ★このような問題を見つけた際に、現場目線しかないと、「相互理解が足り
ない、コミュニケーションを増やそう」といったものが提案されがちだが。 そのような取り組みから「構造的な歪み」の問題に到達するにはあまりに時 間がかかる。
余談7(想定質問) PPM観点でソフトウェアの要素を見たときに、「金のなる木(事業の柱で安定稼働 している。機能追加などはあまりない。)」に投資は必要ではないか?(リファク タリングとか) Yes。 しかし、「花形」などと異なる点に注意が必要。あくまで「金のなる木」として 維持していくのに最低限必要な投資を考えること。 つまり、今後のビジネス戦略において重要な機能拡張があるといった成長の ための投資要素がない限りにおいては、大幅なリファクタリングやリアーキ テクチャはtoo
much。
旅行業法 旅行業法 (e-gov) 旅行業概要 (観光庁) 企画旅行(募集型、受注型)、手配旅行がある 手配までなのか、企画・募集するのかで違う