tags
PdM
author
category
PM
mainImage
publishedAt
Aug 7, 2024
published
published
slug
newt-travelmanagementsystem-PM
authorDisplayName
Riho Konishi
＜目次＞
そもそも旅行管理システムって？“作る側”になって直面した課題1. 複雑な旅行ドメインと削ぎ落とし2. 事業成長のための開発とUXの天秤現時点の私なりの答えどんな開発規模であれ”Why”を見失わないドメイン・業務理解はフルMaxでシステム開発はあくまで手段の1つ難しい、だから面白い令和トラベルでは一緒に働く仲間を募集しています
こんにちは！令和トラベルで旅行管理システムのPM*をしている小西です！（*令和トラベルでは、プロダクトマネージャーをPMと呼称しています）
タイトルにも書いた通り、私ははじめからPMのキャリアを歩んでいたわけではなく実務担当から転向をしているのですが、PMという役割になってから早10ヶ月が経とうとしているので振り返りの意味も込めて
- 旅行管理システム開発における難しさ
- 日々どういうことを考えながらプロダクトマネジメントをしているか
について、特に、
- PMというポジション・役割を担ってみたい方
- 業務システムや複雑なドメインの基幹システムに携わる方
の参考になればいいな〜という気持ちで書いてみました😌
令和トラベル入社時は実務担当をしていた話や、なぜPMに転向したの？という話については下記の記事にまとめているのでぜひあわせてご覧ください！
そもそも旅行管理システムって？
先日、PM向けのイベントに参加した際に「基幹システムのPMーやっています」と自己紹介すると、
「スタートアップ規模で既に社内業務の基幹システムにPMがいるなんて凄いですね」
「基幹システムのPMってどんなことをやっているんですか？」
と尋ねられることが多かったんですよね。
令和トラベルには、
- NEWT（toCの旅行予約システム）
- 社内の基幹システム（通称 トラベルマネジメントシステム）
と、2つのプロダクトがあります。私自身は、令和トラベルに入社した当時から、それぞれにPMが存在するのが当たり前だったのですが、客観的に見るとそうではないことに気付かされました。
前置きが長くなりましたが、そんな背景も踏まえ、私がPMになって感じていること以前に、そもそも旅行管理システムとはどんなシステムなのか？について軽く触れさせてください。
ちゃんとまとめようと思うと、それだけで1記事は書けるくらい膨大なので、くわしく知りたい！興味ある！という方はぜひこのあたりの記事を読んでいただくか、カジュアル面談などお待ちしております🙌
さて、旅行管理システムには大きくわけて3つの機能があります。
- NEWTで販売する商品そのものや料金・在庫の登録・管理
- カスタマー・予約の登録・管理
- 予約をいただいた後の手配情報の登録・管理
そして、その機能の利用ユーザとなるチームがそれぞれ存在します。
ありがたいことにNEWTの予約流通額も急成長していますし、海外ツアーの対応エリアもぞくぞくと増えているのですが、チーム規模も予約数に比例して拡大しているかというと、そうではありません。
令和トラベルはビジョンにもかかげているように”デジタルトラベルエージェンシー”を目指しており、人海戦術でやっていこうとしているわけではないからです。
ということは、圧倒的な生産性が必要になります。それを実現するのが「旅行管理システム」です。
単純に”社内業務を行う”とか”情報を集約する”ためのシステムではなく、目先であれば”社内ワークフローの徹底的なオートメーション化”をミッションにかかげているプロダクトで、外部システムとの連携を行うことで在庫・料金の登録業務や旅行手配業務を自動化したりと、ある意味ビジネスモデルの基盤を作っているシステムといっても過言ではありません。
また、先述の通り、NEWTで販売している商品の登録も旅行管理システムで行っているため、商品ラインナップの拡充をする上でもシステム拡張はかかせません。
“作る側”になって直面した課題
カスタマーサポートや旅行手配の実務担当として旅行管理システムを使う立場から、PMとして作る立場に役割が変わった中で、大きく2つの難しさを感じています。
1. 複雑な旅行ドメインと削ぎ落とし
トラベルマネジメントシステムを使う立場として実務をしていたときも、覚えることの多さに苦戦していましたが、プロダクト開発に携わるようになってからは実務では担当していなかった領域のキャッチアップも必要になったため、より一層旅行ドメインの複雑さを痛感しています。
複雑さを一言で表すなら「パターンの多さ」です。
例えば、旅程。海外旅行を主軸に取り扱っているため、時差の考慮が必要であったり、フライトの出発時間に応じた分岐も発生します。よくロジックの検討でぶつかるのが「日付またぎ」です。
往路だけとっても、
- 旅程1日目に出発をして、同日中に現地に到着するパターン
- 出発は旅程1日目だけど、搭乗中に日をまたいで翌日に到着するパターン
- 空港チェックインを考えると旅程の1日目に空港にいる必要があるが、実際にフライトに乗るのは日付をまたいで翌日となるパターン
さらに、
- 到着後にそのままホテルに宿泊ができるのか
- 15時頃の通常チェックインになるのか
などなど。
極論、すべて人手で旅程表を登録するのであれば、全パターンもれなく対応することは可能ですが、今後ツアー本数がより一層増えていく中で現実的ではないですし、先に書いた通り「徹底的なオートメーション化」を目指す上でパターン整理は不可欠です。
旅程の事例は商品パターンが変わるケースですが、手配方法のように業務フロー自体が変わるような要素も存在します。
しかし、このような膨大なパターンをはじめからすべて網羅した機能開発をしようとすると、莫大な工数がかかってしまいます。
リリースしたい機能が商品ラインナップの拡充を目的にしたものだと、商品が世の中に出せるスピードが落ちることになりますし、作り込みをすることで返って負債になるケースもあります。
そのため、いかに最小単位でインパクトの大きい機能をつくることができるか？を見定めるスキルが必要で日々試行錯誤しながら進めています（どんなことを意識しているかは後述します。）
2. 事業成長のための開発とUXの天秤
先にあげた通り、いかにインパクトを出しつつスコープを最小限にするか、抜本的な対応を考えながら機能開発を進めていると、どうしても細かな使い勝手の改善は後回しになりがちです。
言葉を選ばずに言えば、その改善をせずとも業務は回るし、それを改善したから格段に予約が増えたり業務が爆速になるかというとそうではないので、対応優先度が下がってしまいます。
とはいえ、もともと要望を上げる側にいたからこそ、余計に情に弱くなってしまう部分もあります。笑
また、すぐ改善対応することが難しい一方で、要望はいただける方が良いとは思っていて。その点「言ってもどうせやってもらえないから、もう何も言わないでおこう」と信頼を失うことはしたくないという気持ちもあります。
そのため、リソースが限られる中で、いかに事業成長も止めずに要望も取り込めるか、そのバランスを取ることが難しさの1つです。
現時点の私なりの答え
そんな難しさに対して試行錯誤しながら取り組んでいるわけですが、振り返ってみると「これは大切にしたい」とか「そういえばこんなこと考えているな」ということに気がついたので、自戒も込めて整理してみました✍
どんな開発規模であれ”Why”を見失わない
旅行ドメインを紐解いて最小単位を考えるような比較的大きな機能開発でも、使い勝手をよくするような細かなUX改善であっても、共通して言えるのは”Why”、つまり「何のためにこの機能がほしいんだっけ？」といった”1番達成したい目的”を見失わないようにしています。
常に意識できるのがベストですが、具体的な要件をつめていくフェーズになればなるほど見失いがちなので「あれ、なんか迷走しているな」という瞬間や、一旦全体感を詰め終わって要件が肥大化しているな、と感じたときに特に立ち返ることを癖付けています。と、書くのは簡単なんですが実践が難しい👼
ドメイン・業務理解はフルMaxで
「スコープを最小単位に削ぎ落とすのが難しい」に関しては、一見矛盾しているように聞こえるかもしれませんが、ドメイン・業務理解を徹底的に行います。
- 実は把握できていなかった業務の方が工数負担が大きく、優先順位を見誤った
- 商品パターンとして必須事項だったのに要件の考慮から漏れていた
- 将来的な拡張を見据えておらず、1から作り直しになってしまった
ということをできるだけ避けるためです。
拡張性に関しては、「見据えた上で最小単位まで削る」のと「把握できていなかった上でそのスコープ」で全く同じものを作ったとしても、当たり前ですが前者のほうが将来的な負債を抑えられるはずです（これもまた言うだけなら簡単で、特にどこまで見据えておくかの線引が結局難しいのですが👼）
また、「社内業務で使うシステム」という性質上、単に機能の要件定義だけでなく、業務設計もあわせて行うようにしています。セットで考えないとオペレーションとシステム機能が噛み合わず、いざリリースしてみて「うまく業務が回らない」ということが発生してしまうため、その点でも解像度高く業務理解をしていることが大切です。
要件定義 / 開発フェーズ段階から、プロダクトサイドとビジネスサイドがお互いにシステム機能・業務フローの解像度が高いと、リリース後に発生する改善要望も比較的少ないように感じます（もちろん開発時点ですべての要望を取り込むことは基本的にないので、要望が上がるタイミングが違うだけ、ということもあるかもしれませんが）。
ツアー企画チームや、カスタマーサクセスチームなど、ビジネスサイドにはあらゆる方面のプロフェッショナルが揃っており、社内システムだとヒアリングできる人が身近にいる、というのが嬉しいポイントです。
そして、業務理解という点では実務経験をした上で異動したことがアドバンテージになっているなと感じます。
「業務マニュアルをみるだけ」「ユーザヒアリングするだけ」ではなく、部署に所属するまではいかずとも、実際に自分の手を動かしてみることが業務理解度を上げる上では大切だと考えます💡
システム開発はあくまで手段の1つ
最後に、優先度が下がりがちなUX改善との向き合い方ですが、基本的には定量的な軸で優先度を判断します（例えば、効率化文脈であれば工数削減など）。
ただ、発生頻度は低いが、オペミスが起こると大幅な赤字になるケースであったり、最悪の場合、カスタマーが飛行機に乗れないといったクリティカルなケースであれば、例え工数削減インパクトがなくとも優先度はあがるため、多角的に見る必要があります。
そうして優先順位をつけたバックログを隙をみては愚直に対応していくのですが、そもそもシステム開発はあくまで課題解決における手段の1つです。
よく現場では以下のようなやりとりをみかけます。
もちろんシステム化するに越したことはないのですが、
- 本当にシステム化でしか解決できないんだっけ？
- もっと前段でできることはないんだっけ？
など、暫定対応的にでもシステム開発を待たずにできることがあるケースも存在します。
これはUX改善だけでなく大きな機能開発でスコープから外すときにも共通しますが、将来的には自動化する前提はありつつ、一旦手動オペレーションで耐えうる間は人力で回してみることも時には必要です。
あらかじめ手動でオペレーションを組むことで、潜在化していた課題が見えやすくなったり、業務プロセスをおこせるので機能検討がしやすかったりと、特に自動化案件ではメリットが多いように思います。
難しい、だから面白い
旅行ドメインの複雑さには正直、頭を抱えることも多いですが（笑）、複雑だからこそそれを紐解き、業界のあたりまえを変えるような他社にはない独自のビジネスモデルを創るチャンスでもあります。
単なる業務の自動化を目指したものではなく、事業の根幹を担うようなプロダクトづくりはとても面白いしやりがいもあるので、これを読んでわくわくしてくださった方はぜひカジュアルにでもお話できたらうれしいです✨
令和トラベルでは一緒に働く仲間を募集しています
令和トラベルでは、PMに限らず全ポジション、全力で仲間探しをしています！少しでもご興味ある方はぜひ採用ページからご連絡ください📩
さらに、定期的に令和トラベルの技術や組織に関する情報発信を開催予定です。connpass にてメンバー登録して最新情報をお見逃しなく！
次回は、「NEWT Tech Talk vol.11 進化するLLM ~プロダクト開発における活用術~」をテーマに、株式会社mento × 令和トラベルの合同イベントを開催します。プロダクト開発における各社のLLM活用方法や学びなどについてご紹介いたしますので、ぜひご興味のあるみなさまはご参加ください！
それでは次回のブログもお楽しみに！Have a nice trip 🛫
