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
630
ドメインと向き合う - 旅行予約編
2024.09.28
PHPカンファレンス沖縄2024
hidenorigoto
September 28, 2024
Tweet
Share
More Decks by hidenorigoto
See All by hidenorigoto
「ソフトウェア設計」のドメイン - 「データモデリングでドメインを駆動する」を読んで
hidenorigoto
10
2.7k
メルカリ バックエンド領域のこれまでとこれから
hidenorigoto
1
400
メルカリのエンジニアリング組織の変化〜Engineering Managerの視点から〜
hidenorigoto
0
8k
The changes of the engineering organization in Mercari - from the view of an engineering manager -
hidenorigoto
0
250
PHPerKaigi 2019 ランチセッション (3/31)
hidenorigoto
1
3.9k
抽象化って何? (What is abstraction?)
hidenorigoto
9
4.4k
抽象化って何? (What is abstraction?)
hidenorigoto
11
6.5k
続・SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則 センパイのコーディングノート編〜
hidenorigoto
14
5.8k
SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則編(拡大版)〜
hidenorigoto
9
5k
Other Decks in Technology
See All in Technology
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
760
新卒1年目が挑む!生成AI × マルチエージェントで実現する次世代オンボーディング / operation-ai-onboarding
cyberagentdevelopers
PRO
1
180
運用イベント対応への生成AIの活用 with Failure Analysis Assistant
suzukyz
0
170
新卒1年目が向き合う生成AI事業の開発を加速させる技術選定 / ai-web-launcher
cyberagentdevelopers
PRO
8
1.6k
SREの前に
nwiizo
9
1.3k
軽量DDDはもういらない! スタイルガイド本で OOPの実装パターンを学ぼう
panda_program
21
7.7k
AI長期記憶システム構築のための LLMマルチエージェントの取り組み / Awarefy-LLM-Multi-Agent
iktakahiro
1
240
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
1k
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
12k
Autify Company Deck
autifyhq
1
39k
一休.comレストランにおけるRustの活用
kymmt90
3
640
TinyGoを使ったVSCode拡張機能実装
askua
2
120
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Adopting Sorbet at Scale
ufuk
73
9k
How to Ace a Technical Interview
jacobian
275
23k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8k
Building an army of robots
kneath
302
42k
Code Reviewing Like a Champion
maltzj
519
39k
Six Lessons from altMBA
skipperchong
26
3.5k
Docker and Python
trallard
40
3.1k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Typedesign – Prime Four
hannesfritz
39
2.4k
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) 旅行業概要 (観光庁) 企画旅行(募集型、受注型)、手配旅行がある 手配までなのか、企画・募集するのかで違う