複業ログでは以前、本業(FDEとしてのAI導入支援)のスキルが複業側に横展開しやすいと書いた。動画生成の自動化やコンテンツ配信の仕組み化は、実際にエンジニアリングの経験がそのまま効いている。ところが民泊だけは事情が違った。結論から言うと、民泊運営には「要件が曖昧な状態から動くものを作る力」も「仕組み化して再現性を持たせる力」もほとんど通用しない領域が存在する。今回は、その通用しない領域が具体的にどこで、私がどう対応したかを書く。

エンジニアリングの勝ちパターンが通じない理由

エンジニアリングの仕事は、突き詰めれば「不確実性をコードとシステムに固定化する」作業だ。要件が曖昧でも、一度動くものを作れば、その後は再現性が生まれる。同じ入力には同じ出力が返る。バグは直せば直った状態が維持される。この前提の上に、私の複業のほとんど(storeforgeの受注処理、afflowの投稿予約、aerial-earth-studioのレンダリングパイプライン)は成り立っている。

民泊はこの前提が根本から崩れる。相手は人間で、しかも毎回違う人間だ。ゲストの国籍・言語・文化的背景・宿泊人数・到着時刻はすべて予約ごとにバラバラで、「一度うまくいったやり方」が次回もそのまま通用する保証がない。仕組み化して手離れさせようとしても、最後の最後に「人と人とのやり取り」という、コード化できない工程が必ず残る。

具体的に役に立たなかった3つの場面

抽象論で終わらせず、実際に本業スキルが空振りした場面を挙げる。

  1. ゲストからの問い合わせ対応: 「チェックイン時間を早められるか」「近くのおすすめの飲食店は」といった問い合わせは、テンプレート返信をあらかじめ用意していても、そのまま使えることはほとんどなかった。相手の文面のトーン、こちらの予約状況、その日の清掃スケジュールなど複数の変数を都度その場で判断する必要があり、「一度作った関数を使い回す」発想が機能しない
  2. 清掃・原状回復のオペレーション: エンジニアリングなら「手順書を作ってチェックリスト化すれば再現性が担保できる」と考えがちだが、実際の清掃現場ではゲストの使い方次第で毎回違う汚れ方・破損・忘れ物が発生する。チェックリストは最低限のカバー率しか担保できず、最後は「その場で気づいて対応する」現場力に依存する
  3. クレーム・トラブル発生時の初動: 予約が入り始めてから、設備の不具合やゲスト間トラブルの一次対応が発生した。システムのインシデント対応なら「ログを見て原因を切り分ける」動きが有効だが、対人トラブルは事実確認そのものが双方の主観に左右され、技術的な原因切り分けの型がまったく通用しなかった

唯一機能したのは「フェイルセーフの発想」だけ

完全に無力だったわけではない。1つだけ本業から持ち込めた発想がある。それは「人間の判断が必ず失敗する前提で、最悪のケースを小さくしておく」というフェイルセーフの考え方だ。

具体的には、返信が遅れても致命傷にならないよう、よくある質問への回答をハウスマニュアルとチェックイン時のメッセージに事前に埋め込んでおいた。清掃漏れが起きても宿泊体験が破綻しないよう、消耗品や予備の寝具を必要数より多めに常備した。トラブル発生時に一人で抱え込まないよう、清掃業者や近隣の緊急連絡先をあらかじめリスト化しておいた。

これらはいずれも「その場の対応力を仕組みで代替する」試みではない。「対応力が発揮できなかった場合の被害を小さくしておく」という、システム設計でいう防御的プログラミングに近い発想だ。対応そのものを自動化しようとした部分(テンプレート返信の完全自動化など)はことごとく機能しなかったが、被害の下限を設計する部分だけはエンジニアリングの発想がそのまま生きた。

「仕組み化できない事業」を持つことの意味

正直に言うと、民泊を始める前は「本業のスキルがあれば、他の事業よりも早く仕組み化できるだろう」という甘い見立てがあった。実際にはむしろ逆で、民泊は複業4事業の中で最も自分の得意な武器が使えない事業になっている。

ただ、これは悪いことばかりではないとも感じている。仕組み化できない領域があることを痛感したことで、「自分は仕組み化することに逃げがちだ」という本業側の癖にも気づけた。要件が曖昧な段階でまず仕組みを作ろうとするのではなく、まず現場で何が起きているかを自分の目と手で確認してから設計する、という順番の大切さを、民泊運営が改めて教えてくれている。

まとめ

  • エンジニアリングは「不確実性を仕組みに固定化する」作業だが、民泊は毎回違う人間が相手で、この前提が崩れる
  • ゲスト対応・清掃・トラブル対応のいずれも、テンプレート化やチェックリスト化だけでは再現性を担保できなかった
  • 唯一機能したのは「対応の自動化」ではなく「対応が失敗した場合の被害を小さくする」フェイルセーフの発想だった
  • 仕組み化できない事業を持ったことで、逆に本業側の「すぐ仕組み化に逃げる」癖にも気づけた

次回は、民泊のゲスト対応で実際に起きたトラブルとその一次対応の実況を書く。

関連記事

Xでフォローしよう

おすすめの記事