民泊を副業の候補として検討し始めたとき、最初に立てた見立ては「本業（FDEとしてのAI導入支援）のスキルがそのまま横展開できるだろう」というものだった。複業ログでは以前、そのスキルが複業側に横展開しやすいと書いたし、動画生成の自動化やコンテンツ配信の仕組み化は、実際にエンジニアリングの経験がそのまま効いている。
ところが民泊について調べ、既に運営している人の記録を読み込むほど、この見立ては危ういと考えるようになった。民泊運営には「要件が曖昧な状態から動くものを作る力」も「仕組み化して再現性を持たせる力」も通用しにくい領域が存在する。この記事は着手前の検討であり、運営実績にもとづく話ではない。 参入前に自分の武器がどこで空振りしそうかを洗い出しておく、という趣旨で書く。
エンジニアリングの勝ちパターンが通じにくい理由
エンジニアリングの仕事は、突き詰めれば「不確実性をコードとシステムに固定化する」作業だ。要件が曖昧でも、一度動くものを作れば、その後は再現性が生まれる。同じ入力には同じ出力が返る。バグは直せば直った状態が維持される。この前提の上に、私の複業のほとんど（storeforgeの受注処理、afflowの投稿予約、aerial-earth-studioのレンダリングパイプライン）は成り立っている。
民泊はこの前提が根本から崩れる。相手は人間で、しかも毎回違う人間だ。ゲストの国籍・言語・文化的背景・宿泊人数・到着時刻はすべて予約ごとにバラバラで、「一度うまくいったやり方」が次回もそのまま通用する保証がない。仕組み化して手離れさせようとしても、最後に「人と人とのやり取り」という、コード化できない工程が必ず残る。
空振りしそうだと見ている3つの場面
抽象論で終わらせず、参入前の時点で「ここは自分の武器が効かないだろう」と見ている場面を挙げておく。実際にどうだったかは、運営を始めてから答え合わせする。
- ゲストからの問い合わせ対応: 「チェックイン時間を早められるか」「近くのおすすめの飲食店は」といった問い合わせは、テンプレート返信を用意しても、そのまま使える場面は限られるはずだ。相手の文面のトーン、こちらの予約状況、その日の清掃スケジュールなど複数の変数を都度その場で判断する必要があり、「一度作った関数を使い回す」発想が機能しにくい
- 清掃・原状回復のオペレーション: エンジニアリングなら「手順書を作ってチェックリスト化すれば再現性が担保できる」と考えがちだが、実際の清掃現場ではゲストの使い方次第で毎回違う汚れ方・破損・忘れ物が発生すると聞く。チェックリストは最低限のカバー率しか担保できず、最後は「その場で気づいて対応する」現場力に依存する
- クレーム・トラブル発生時の初動: システムのインシデント対応なら「ログを見て原因を切り分ける」動きが有効だが、対人トラブルは事実確認そのものが双方の主観に左右される。技術的な原因切り分けの型がそのままでは使えない
唯一持ち込めそうなのは「フェイルセーフの発想」
完全に無力というわけでもなさそうだ。1つだけ本業から持ち込めると考えている発想がある。「人間の判断が必ず失敗する前提で、最悪のケースを小さくしておく」というフェイルセーフの考え方だ。
具体的には、返信が遅れても致命傷にならないよう、よくある質問への回答をハウスマニュアルとチェックイン時のメッセージに事前に埋め込んでおく。清掃漏れが起きても宿泊体験が破綻しないよう、消耗品や予備の寝具を必要数より多めに常備する。トラブル発生時に一人で抱え込まないよう、清掃業者や近隣の緊急連絡先をあらかじめリスト化しておく。
これらはいずれも「その場の対応力を仕組みで代替する」試みではない。「対応力が発揮できなかった場合の被害を小さくしておく」という、システム設計でいう防御的プログラミングに近い発想だ。対応そのものを自動化しようとする部分は機能しないだろうが、被害の下限を設計する部分ならエンジニアリングの発想がそのまま生きるはずだ。
「仕組み化できない事業」を候補に残す意味
正直に言うと、検討を始めた当初は「本業のスキルがあれば、他の事業よりも早く仕組み化できるだろう」という甘い見立てがあった。調べるほど、むしろ逆で、民泊は検討中の事業の中で最も自分の得意な武器が使えない事業になりそうだと分かってきた。
ただ、これは候補から外す理由にはならないと考えている。仕組み化できない領域があると認識したことで、「自分は仕組み化することに逃げがちだ」という本業側の癖にも気づけた。要件が曖昧な段階でまず仕組みを作ろうとするのではなく、まず現場で何が起きているかを自分の目と手で確認してから設計する。この順番の大切さを、民泊の検討そのものが教えてくれている。
まとめ
- エンジニアリングは「不確実性を仕組みに固定化する」作業だが、民泊は毎回違う人間が相手で、この前提が崩れる
- ゲスト対応・清掃・トラブル対応のいずれも、テンプレート化やチェックリスト化だけでは再現性を担保できないと見ている
- 唯一持ち込めそうなのは「対応の自動化」ではなく「対応が失敗した場合の被害を小さくする」フェイルセーフの発想
- 仕組み化できない事業を候補に残すことで、逆に本業側の「すぐ仕組み化に逃げる」癖にも気づけた
これは着手前の見立てであり、実績ではない。運営を始めたら、この3つの見立てのどれが当たり、どれが外れたかを書く。
