現場を知り、現場とつくる｜NOT A HOTELが“一体で開発する”理由
💡 この記事はNOT A HOTELのソフトウェア開発連載
「Inside the SOFTWARE TEAM」の第8日目です。
はじめに
こんにちは。NOT A HOTELでPdMをしている中川(fumifumi__8)です。
NOT A HOTELはソフトウェアだけでなく、滞在体験を提供する運営（食事提供や清掃現場対応、・チャット対応など）もすべて自社で開発・運用しています。
カジュアル面談をしていると「運営も自社なんですね！」と驚かれることが多く、意外と知られていないことに気づきました。
私は以前ホテルのコンシェルジュとして働いており、当時感じていたのは「システムと現場の距離」です。
ホテル内の課題はホテルで解決し、システムの不具合はサポートデスクに問い合わせるだけ。パッケージソフトウェアを利用していたため機能要望を伝える機会はなく、それがホテル業界では当たり前の理解でした。
NOT A HOTELでは違います。
各チームの距離が近く、一つ一つの事象に全体で向き合います。しかもフルリモート体制で実現しています。
今回はソフトウェア開発でのチーム間の協働、そしてホテル運用システム"PMS(プロパティ・マネジメント・システム)"の機能開発を例に、NOT A HOTELがどのように現場と一体となって開発を進めているのかをお伝えします。
※PMS(プロパティマネジメントシステムとは、ホテル運営に必要な予約管理・顧客管理・請求処理などを一元管理するシステムです。
NOT A HOTELでは、PC操作を前提としたPMSに加え、運営メンバーの使用に特化した「Helpstaff」というスマホ向けのツールも自社開発しています。
一体となった開発の進め方
以下のチームが連携してお客様体験をつくり出しています。
ホテルサービス(運営)チーム: ホテル現場でのお客様対応、清掃・設備管理などの実務を担当
カスタマーサクセス(CS)チーム: チャットを通じたお客様対応、問い合わせ対応を担当
オーナーリレーション(OR)チーム: オーナー様との関係構築、要望のヒアリングを担当
ソフトウェア(SW)チーム: オーナー向けアプリ・ホテル管理システム・スマートホームの開発を実施
ホテル開業当初は「現場の声が届かない」等の課題がありました。試行錯誤を重ね、開発プロセスそのものによりホテル運営を巻き込む仕組みができてきました。
フルリモート×チャット対応と現場対応が混在という環境
NOT A HOTELはフルリモートの組織で、チャット対応(オンライン)と現場対応(オフライン)が混在しています。
運営チームはオフラインでお客様対応をしていますが、その内容はすべてSlack・Google Meet・Discordで連携・蓄積されます。だからSWと運営・CSのコミュニケーションはオンラインで完結でき、とても取りやすいんです。
現場の状況も、チャットでのやりとりも、すべて把握できる状態。ログが残るので情報も遡りやすく、いつでも気軽に声をかけられる文化です。
こうした環境の上で、以下3つのポイントで開発を進めています。
日常的な対話｜要望を拾う
双方向キャッチアップ｜互いに理解を深める
リリースサポート｜形にして届ける
ポイント1：日常的な対話
定例MTG(月2回程度)
運営・CS・OR・SWが集まって、要望を起票して目線を合わせます。どういう点が課題か、困り事かをしっかり出し合う場です。
Slack(日常的)
お客様影響があった事象やミスが発生した場合は、即座に議論を展開。システム目線での改善もしっかり検討して、再発防止を意識した開発に取り組んでいます。
個別MTG(必要に応じて)
一つの課題を深掘りしたり、NOT A HOTELの成長に伴う中長期的な課題を一緒に検討することもあります。
ポイント2：双方向キャッチアップ
＜運営→SW＞
CS 、ORそして運営サービスメンバーやシェフも、オーナー様やお客様が使うアプリをステージング環境で確認できるようになっています。
お客様目線で物事を考えて、「この機能、ここの部分こうならないか?」「お客様がよく間違われているんですよね」みたいな解像度の高い声が届きます。
＜SW→運営＞
ソフトウェアチームが現場の声を聞きたい・リアルな運用を確認したい時は、CSの昼会や運営現場の朝会(1日の予約内容の確認 / 連携)にGoogle Meetより参加させてもらいます。
新拠点がオープンした時には朝会へ顔を出しての挨拶や、PMSを用いた現場での運用オペレーションを直接知る機会もあります。
ポイント3：リリースサポート
＜開発中＞
運用に関わる部分をヒアリングして認識齟齬がないか、使う上で課題はないかを議論します。開発で難しい部分は、ミニマム要件で運用現場に回してもらってから少しずつ追加開発することも。
＜リリース前＞
必要に応じて実際に触ってもらい、違和感がないかを教えてもらいます。利用条件に制限がある機能の場合は注意事項を細かく記載して、運用観点での補足マニュアルも作成して社内周知します。
＜リリース後＞
Slackでいつでも質問できる距離感。操作の質問も近い距離でやりとりします。
具体例：コンビニチェック機能の開発
コンビニチェック機能とは
NOT A HOTELの各お部屋には、オーナー様やゲストが自由に利用できるちょっとしたコンビニスペースがあります。飲料や食品などを設置しており、利用した分だけ後日請求される仕組みです。
この請求内容の管理をこれまでは紙とスプレッドシート等を用いた運用となっており、二重管理や請求ミスが発生しやすいという課題がありました。
それを解消するために、Helpstaff（運営向けのスマホツール）に機能を統合し、正確さと効率を高めることを目指しました。
要件定義前：現場の声を聞き、現状を正確に把握する
具体的にどこでミスが発生しそうか、どんなところに時間がかかるのかを各メンバーへヒアリング。
分かったこと:
運営でのチェックオペレーションとCSの連携フローの複雑さ
請求完了処理までのステップの多さ
ステータス管理(「コンビニチェック完了」など)の必要性
要件定義：認識合わせを重ね、機能へどこまで落とし込むのかを判断
開発の重みとスピード感のバランス、運営効率を考え、今回の場合まずは紙で行っていた管理をHelpstaffに落とし込む部分のみをシステム化することに。
ミニマム要件:
チェックイン前: 設置数を入力・確定
滞在中: 補充数を記録
チェックアウト後: 請求数を入力・確定 → 自動でオーダー作成
開発で難しい部分(商品マスタの管理など)は、まずは手動運用で回してもらい、後から追加開発する方針に。
リリースに向けて：使いやすさへの配慮とオペレーションへ落とし込むための工夫
システム面での操作における注意事項をまとめたマニュアルを作成し、現場のオペレーションに組み込みやすい情報を提供。運営メンバー向けに運用説明MTGも実施しました。
リリース後：実際に運用をしたうえで、寄り添うための改修を入れる
「この画面からすぐにアクセスしたい！」というような、実際に使ったことでわかるちょっとした改修はすぐに対応しています。
追加した機能:
1. ハイライト機能 請求数を入力したら、該当商品をハイライト表示。「どれを請求したか一目で把握したい」という声に応えました。
2. OTA予約対応 OTA(Online Travel Agent)経由の予約では、OTA独自の特典内容にも対応しミスなく迷わない機能を追加しました。
3. ホーム画面からの遷移 ホーム画面から、ワンタップでコンビニチェックシートへ遷移できるように。
小さな改善ですが、運用オペレーションの動線を考慮したことで「1クリックが減り楽になった」「ミスをしやすいフローが改善された」という声をいただきました。
成果: リリース後、請求ミスが1件まで減少
でも、すべての要望にすぐ応えられるわけではない
リリース後も改善要望はたくさん届きます。
運営との距離が近い分、困り事への共感も強くなります。「これ、早く解決してあげたい」と思うこともたくさん。
限られたリソースの中で、より多くのお客様体験を改善できるよう優先度を慎重に判断しています。
「なぜ今は難しいのか」「いつ頃なら検討できそうか」を丁寧に伝え、対話を続けることを大切にしています。距離が近いからこそ、コミュニケーションを丁寧に重ねる。その積み重ねが、より良いお客様体験につながると信じています。
一体感を生む原点とは
ある日、運営現場で「現場のことを一番考えてくれているソフトウェアの人です」と紹介していただいたことがあります。前職で感じていたシステムと現場の壁、との違いを実感した瞬間でした。
3つのポイントで開発プロセスを説明してきましたが、こうした距離感を作れるのにはもう一つ理由があるんです。
それは私含め、SWチームみんながが現場を知る機会を大切にしていることです。
出張時のまかない
たまに運営現場へ出張する機会があるんですが、お昼のタイミングが重なると、まかないをいただけることもあります。
運営メンバーと一緒にまかないを食べる時間は「一緒に体験を作っているんだな」って実感する瞬間です。
現場見学・宿泊体験
開発メンバーが実際に運営現場へ見学に行ったり、旅行補助を使ってホテルに宿泊することもあります。
サービスを実感して改善点を見つけるきっかけになっています。
個人的には、バックオフィスで一緒に働かせてもらうこともあります。ふとした時に出てくる疑問などをその場で教えてもらえることができる、とても良い環境なんです。
お客様の声を知る
アンケートには「超いいね」「いいね」「イマイチ」の3段階があるのですが、NOT A HOTELでは「いいね以下」だった場合に改善点を考える文化があります。
運営メンバーがどういう点を改善したいか、それに伴いシステム側もこうなったらいいよね、という連携をもらえます。
だから、こう変わっていった
前職だと「システムって遠い存在だな」と思っていましたが、NOT A HOTELでは「あ、これ一緒に作れるんだ」という気づきがありました。
開業当初は運営メンバーも最初は遠慮がちだったんですが「ここ、こうならないですかね？」と具体的に相談してくださり、
「いいですね、試してみます」と返したら、だんだん「あ、言っていいんだ」というような空気が広がりました。
このような提案が実際に形になってさらに積極的に意見をくれるようになる。この好循環が、NOT A HOTELの開発を支えているんだなって思います。
結果としてお客様体験もどんどん良くなっていく。このサイクルが回り続けることが、NOT A HOTELの強みだと感じています。
まとめ：一体となって、お客様体験をつくる
NOT A HOTELのソフトウェア開発は、運営/CS/ORと近い距離で一体となって進めています。
なぜ距離にこだわるのか。
それは、最高のお客様体験は、サービスを提供している運営/CS/ORの体験から始まると考えているからです。
使いやすいツール、迷わず操作できる画面、ミスを防げる設計によって運営メンバーの体験が良くなれば、お客様へのサービスの質も自然と高まります。逆に、メンバーが困っていたらその影響は必ずお客様に届いてしまいます。
だからこそ、私たちは運用・現場を知り、声に耳を傾け、一つ一つの事象に全体で向き合います。
オフライン・オンラインで距離があっても、Slack・Google Meet・運営現場へ参加の機会を通じて、距離を縮める工夫をしています。
すべての要望にすぐ応えられるわけではありません。
でも対話を続け、運営/CS/ORにとって、そしてお客様にとってより良い体験を作ることを諦めません。それがNOT A HOTELのソフトウェア開発です。
NOT A HOTELでは一緒にお客様体験を作るPdMを募集しています。
運営と近い距離で、一体となって開発したい方。お客様体験の起点となるホテル運営メンバーの体験を大切にしたい方。フルリモートでも、対話を重ねながら前に進みたい方。
そんな方と一緒に働きたいと思っています。
ご応募をお待ちしております。
