毎日使うシステムだから、細部まで磨く。NOT A HOTELのオペレーションツール開発

はじめに

こんにちは。NOT A HOTELでオペレーションツールの開発を担当しているYaguchiです。
突然ですが、皆さんの会社には「社内システムだから、それなりのクオリティで良い」という空気はありませんか？私たちNOT A HOTELでは、むしろ逆です。毎日使うシステムだからこそ、使いやすさや品質に一切妥協しません。 今回は、そんな私たちのチームの開発スタイルや、大切にしている価値観についてご紹介します。

オペレーションツールとは？なぜ内製しているのか

私たちが開発しているのは、NOT A HOTELの運営に必要なあらゆる機能を統合したオペレーションツールです。 いわゆるPMS（プロパティマネジメントシステム）の機能——予約管理、顧客情報管理、チェックイン・チェックアウト業務など——も含まれますが、それだけではありません。清掃やルームサービスメニュー、車両や商品、タスク、クーポンの管理など、ホテル運営に関わる幅広い業務をサポートする包括的なシステムです。 世の中にはPMSを含む各種SaaS製品が存在しますが、私たちは自社のビジネスモデルや運営スタイルに最適化されたシステムを実現するため、内製を選択しました。

予約ひとつとっても、NOT A HOTELでは多様な予約種別が存在します。オーナー様の自己利用や相互利用、一般ゲストの宿泊利用、ギフトとしての利用など、それぞれ異なる予約フローや制約があります。これらは事業の成長に応じて今後も変化していくため、柔軟に対応できるシステムが不可欠です。また、スマートホーム機器との連携により、チェックイン・チェックアウトのタイミングで照明や空調を自動制御するなど、NOT A HOTEL独自の要件もあります。

自社の運営特性に合わせた柔軟性を確保することで、NOT A HOTELならではの体験を支えるシステムを目指しています。

チーム構成

チームは現在6名で構成されています。

• プロダクトマネージャー（PdM） 3名

• フロントエンドエンジニア 1名

• バックエンドエンジニア 2名

小さなチームですが、エンジニアとPdMが密に連携しながら、日々プロダクトを磨き続けています。

開発リソースの配分

時期によって変動はありますが、開発リソースの配分をならすと概ね以下のようなバランスになっています。

• オーナーアプリ側の機能追加に伴う機能開発：30%

• 独自の機能開発：30%

• 各部署からの要望対応／チームで挙げた改善：30%

• 定期的な運用関連タスク：10%

新機能開発が60%、改善・運用が40%というバランスが、私たちのチームの特徴だと考えています。 新しいものを作り続けながらも、既存機能の改善や日々の運用業務を疎かにしない。プロジェクトのフェーズによっては新規開発に集中する時期もありますが、中長期的にはこのバランスを保つことで、現場の声を着実にプロダクトへ反映させています。

細部へのこだわりが、積み重なって大きな価値になる

メインユーザーであるCSチームと運営チームでは、業務内容や利用シーンが異なるため、それぞれに最適化されたインターフェースを提供しています。運営チームには現場で使いやすいスマホ向けビュー、CSチームにはデスクワークに適したPC向けのビューを用意するなど、役割に応じた使いやすさを追求しています。

一見些細に見える操作、たとえばラジオボタンを選び直す動作も、毎日何十回と繰り返せば大きな時間のロスになります。チリも積もれば山となる。だからこそ、私たちは細部の使い勝手にもこだわります。

リモート環境だからこそ、現場を見に行く

私たちはフルリモート勤務ですが、定期的に現場同席や観察の機会を設け、実際にツールを使っている様子を確認しています。オフィスに足を運んだり、Google Meetで画面共有をしてもらいながらCSチームの業務を観察することで、ドキュメントやフィードバックだけでは気づけなかった発見が数多くあります。 「ここでワンクリック増えてしまっている」「この画面遷移、実は使いづらかった」——そんな気づきが、より良い改善につながっています。

自律的な改善文化を支える仕組み

週次の改善要望ミーティング

私たちは週に1度、カスタマーサクセス（CS）、オーナーリレーション（OR）、運営チーム、PdM、そしてエンジニアも参加する改善要望ミーティングを開催しています。このミーティングの特徴は、エンジニアが現場の生の声を直接聞けることです。 何に困っているのか、どれくらい困っているのか。その温度感を肌で感じることで、優先順位の判断がより的確になります。ドキュメントやチケットだけでは伝わらないニュアンスや切実さが、対面のコミュニケーションでは伝わってきます。 時には、軽微な修正であればミーティングに参加しながらその場でPRを作成し、レビューとQAを経て迅速にリリースすることもあります。「その困りごと、今対応を進めますね」と言えたときの現場チームの反応は、開発者冥利に尽きるものがあります。

週次の改善起票タイム

チーム内でも別途、改善できることを起票する時間を設けています。この時間の目的は、言われたことだけを直すのではなく、自分たちのプロダクトを能動的に磨き込むことです。

開発中に気づいたUI改善、リファクタリングすべきコード、開発者体験の向上など、日々の業務で感じた「もっとこうしたい」を形にする時間を意図的に作っています。

Slackリアクション1つでissue起票

さらに、社内のさまざまなメンバーからのフィードバックも逃さない工夫をしています。Slackで「ここ改善してほしい」といったコメントがあった際、リアクション1つでissueを自動起票してくれる仕組みを導入しています。 些細なフィードバックも確実にキャッチし、プロダクトに反映させる。この仕組みが、継続的な改善サイクルを回す土台になっています。

裏方のシステムにこそ、品質で応える

これはNOT A HOTEL全ての部署に言えることだと思いますが、私たちは品質に妥協しません。 オペレーションツールは直接的にお客様と接するシステムではありません。しかし、このシステムがあるからこそ、カスタマーサクセスや運営チームは本来注力すべき業務——お客様への価値提供やホスピタリティの向上——に集中できます。 「社内向けシステムだから品質や使い勝手は二の次」という考え方は、私たちにはありません。毎日使う人がいる以上、それは重要なプロダクトです。使いやすさ、パフォーマンス、保守性のいずれにおいても、プロフェッショナルとして誇れるものを作ることを目指しています。 裏方のシステムだからこそ、そこで働く人たちの時間を大切にする。それが結果として、NOT A HOTELの体験価値を支えることにつながると信じています。

オペレーションツール開発の難しさと向き合う

オペレーションツール開発には独特の難しさがあります。それは、イレギュラーにも柔軟に対応できるシステムと、誰が使っても迷いにくく、誤操作を最小化できるシステムという、一見相反する2つの要件を両立させることです。

ホテル運営では、予期しない事態やイレギュラーな対応が日常的に発生します。たとえば、急遽のハウス変更や、特別な事情による予約変更など、通常フローから外れた対応が求められることがあります。システムがあまりに厳密すぎると、現場が回らなくなってしまう。一方で、柔軟性を持たせすぎると、操作ミスや不整合が起きやすくなります。

この難しさに対して、私たちはUIの工夫や権限制御によって解決を図っています。たとえば、重要な操作には確認ステップを設ける、特定の機能は権限を持つ人だけが使えるようにする、直感的に操作できるインターフェースを設計するなど、チーム内で議論を重ねながら最適なバランスを探っています。

おわりに

オペレーションツールは、お客様の目に直接触れることのない裏方のシステムです。 しかし、このシステムがあるからこそ、現場のメンバーは本来やるべき仕事に集中できます。 週次のミーティングで現場の声を聞き、その場で直せるものは迅速に対応する。 Slackのリアクション一つから改善を拾い上げる。そうした小さな積み重ねが、使いやすいシステムを作っていきます。 正直に言えば、いただいている要望の中で、まだ実現できていないものも数多くあります。やりたいこと、作りたい機能は山ほどあります。NOT A HOTELの建築が進化し続けるように、オペレーションツールというソフトウェアもまだまだ進化の途中です。 これからも、NOT A HOTELの体験価値を裏側から支えられるよう、プロダクトを磨き続けていきます！