ユニットのステータス：全員が見られる唯一の情報源

第一部では、可視性のギャップとそれが生じる場所を明らかにし、問題の大きさを数字で示す一週間のカウント演習で締めくくりました。それを実施したと仮定しましょう。いまあなたの手元には、いくつかの横にメモが付いたユニットの一覧があります。賃貸中と記録されているが実際は空室、期限が切れたまま更新されていない賃貸契約、対応する記帳がないまま入ってきた入金。次の問いは単刀直入です。記録が二度と現実からずれないようにするには、現実をどこに記録すればよいのでしょうか。

答えは、より良いファイルでも、より注意深い担当者でもありません。ユニットごとに宣言された一つのステータスであり、必要とする全員が同じ瞬間に見ることができ、担当者・タイムスタンプ・書類を伴う記録された操作によってのみ変更されるものです。これと今あなたが持っているものとの違いは、ツールの違いではありません。情報を保存することと、状態を把握することの違いです。情報は一度書かれると静かに古くなっていきます。状態は、その後のアクションが依存しているため、担当者に最新の状態を保つことを義務づけます。

すべてのユニットは、どの時点でもちょうど一つの状態にある

どんなツールよりも先に、ステータスのリストそのものについて合意しなければなりません。ほとんどの事務所には承認されたリストがないため、ある社員は「空き」、別の社員は「利用可能」、三人目は「手続き中」と書きます。その背後に明確なアクションはなく、誰も絞り込みに使えない三つの言葉です。ステータスは自由記述ではありません。閉じたリストの中の一枠であり、各枠には誰も異論を挟めない一つの業務上の意味があります。

  • 空室・未準備。入居者が退去し、ユニットは清掃中、修繕中、または撮影待ちです。まだ募集は出ていませんが、初日から時計は進んでいます。
  • 準備完了・募集中。撮影済み、価格設定済み、広告掲載済み。準備ができているのに募集に出ていないユニットは理由なく先送りされた収入であり、それをあぶり出すのがこの状態です。
  • 予約済み。保証金や手付金を支払った真剣な申込者がいます。予約は本質的に一時的なものなので、この状態には有効期限を持たせなければなりません。さもないと、どのレポートにも現れない隠れ空室になってしまいます。
  • 賃貸中。開始日、終了日、支払予定のある有効な契約があります。ここでのステータスは一枠ではなく、契約書、その書類、その日付という一件のファイルへの入り口です。
  • メンテナンス中。入居中か空室かを問わず、引き渡しを妨げる作業が進行中です。番号付きのメンテナンス依頼に紐付けなければなりません。そうしなければ、この状態は壊れたまま誰もフォローしなかったあらゆるものの隠れ場所になります。
  • 運用停止。オーナーによる賃貸一時停止の判断、または規制上・構造上の制約です。空室とは分けて管理してください。募集実績のマイナスには数えられず、誰も作業する必要のないものだからです。

このリストには一つのルールがあります。ユニットはどの時点でもちょうど一つの状態にあり、「不明」という状態は存在しません。あるユニットの状態を誰も知らないなら、それは空欄ではなく、名前のある担当者への緊急タスクです。スプレッドシートの空欄は誰も困らせません。だからこそ何か月も空欄のままなのです。

なぜスプレッドシートでは状態を表せないのか

予想される反論はこうです。それならもう自分のシートにある、「ステータス」という列がある、と。違いは、シートが保存するのは値であり、業務に必要なのは状態だという点です。値はセルの中のテキストであり、状態はアクションを引き起こす約束です。どれほどきちんと管理していても、ファイルにできないことは次のとおりです。

  • 誰がいつ変えたかを知らない。ユニットはキー一つで賃貸中から空室に変わり、二か月後にオーナーが入居者はいつ正確に退去したのかと尋ねても、痕跡は残っていません。変更履歴のない記録は意見であって、証拠ではありません。
  • 誰にも通知しない。シートはあなたが開くのを待っています。業務に必要なのはその逆です。記録の側からあなたのところに来て、賃貸契約が一か月後に終わること、あるユニットが十二日間準備完了のまま募集に出ていないことを伝えるべきです。
  • 矛盾する複数のコピー。パートナーに見てもらうためにファイルをチャットに送ると、相手が編集し、正しいバージョンが同時に二つ存在することになります。唯一の情報源は組織上のぜいたくではなく、「ステータスは何か」という問いをそもそも意味のあるものにする条件です。
  • 状態をそれを証明するものと結び付けない。空室と書く――引き渡し記録はどこにあるのか。予約済みと書く――保証金の領収書はどこにあるのか。書類を伴わない状態は、最初の紛争で崩れます。
  • ありえない状態を許してしまう。シートは、契約が二か月前に切れているのに賃貸中と記されたユニットを平然と保持します。二つの列の関係を理解していないからです。その関係を理解するシステムなら、矛盾を拒否するか、すぐにフラグを立てます。

これらはどれも Excel の欠陥ではないことに注意してください。Excel は優れた計算ツールですが、業務ツールではありません。問題は、人と人との間の義務を時間をかけて管理することをスプレッドシートに求めたときに始まります。

ステータス変更のたびに伴わせるべきもの

ここがこの部全体の実践的な核心です。ステータスの変更はフィールドの更新ではなく、完結した一つの業務イベントです。そして各イベントは四つのものを伴わなければなりません。そうでなければ、記録された噂にすぎません。

  • 誰が変更したか。共有アカウントではなく、名前のある個人です。誰かに帰属しない責任は存在しません。
  • 正確にいつか。誰かが思い出した時刻ではなく、出来事そのものの時刻です。この二つのタイムスタンプの間の距離こそ、第一部で述べたギャップです。
  • どの状態へ、そしてなぜ。固定リストから選ぶ短い理由です。契約終了、立ち退き、解約、メンテナンス完了、オーナーの判断。この理由が、後にユニットが実際に空いている理由を教えてくれるレポートになります。
  • 添付書類。各状態には本来の書類があります。退去には日付入りの写真とメーター検針値を含む引き渡し記録、予約には保証金の領収書と予約の有効期間、賃貸には契約書とその関係書類、メンテナンス入りには依頼番号が伴います。

四つの上に立つ最も重要なこと。それは、すべてのステータス変更が次のアクションを自動的に生み出すべきだということです。退去は清掃タスクを開き、清掃完了は撮影と価格設定のタスクを開き、価格設定は募集掲載のタスクを開きます。こうして、準備の整ったユニットが誰も思い出さなかったせいで二週間も募集に出ないまま放置される、ということがなくなります。アクションへと押し出さないステータスは、見た目のよいアーカイブにすぎません。

建物ごとのファイルではなく、ポートフォリオに一つの画面を

よくある形では、建物ごとにファイルがあり、オーナーごとにもファイルがあります。アーカイブには便利ですが、意思決定には致命的です。現実の問いはどれも建物をまたぐからです。いまポートフォリオ全体でどのユニットが空室で、どれくらいの期間空いているか。今後六十日以内に終了する契約はどれか。延滞残高や未完了のメンテナンス依頼があるユニットはどれか。別々のファイルからこれらのどれかに答えるには手作業での集約が必要で、オーナーに求められない限り誰も行いません。

検討中のツールに対する実践的なテストはシンプルです。立ったまま数秒でこの三つの質問に答えられるか、それともエクスポートと統合が必要か。ポートフォリオ全体をステータスと最終変更からの経過時間で並べ替える一つの画面こそが、記録を意思決定ツールに変えます。とりわけ経過時間による並べ替えは、静的なステータスが隠しているものを明らかにします。三日間空室のユニットは普通ですが、七十日間同じ状態にあるユニットは市場の問題ではなく、価格設定か募集掲載の問題です。

Origami の視点

不動産とホテルは当社の専門分野の一つであり、この分野のプロジェクトはどれも、画面を一つ設計する前に、ステータスのリストとその担当者を確定することから始めます。誰も合意していない状態の上に美しい画面を作っても、誰も信用しない数字を表示するダッシュボードができあがるだけだからです。そして数か月もしないうちに、チームは使われないツールに対価を払ったまま、チャットと電話に戻ってしまいます。

私たちが推奨する順序は次のとおりです。まずステータスとその担当者を定義し、次にステータスの変更を事後の追加作業ではなくプロセスそのものにし、その上に回収、更新、メンテナンス、レポートを構築します。このシリーズの残りの部分もこの順序に従っており、これが私たちが不動産・ホテル分野に取り組む方法です。後のすべての層はステータスから読み取るため、ステータスが間違っていれば、その上にあるものすべてがより強い確信をもって間違うからです。

今週できること

最初の改善には購入は一切必要ありません。必要なのは、書き出して採用する小さな決定です。

  • ステータスのリストを一枚の紙に書き出し、リスト外の記述を一切認めずに正式に採用します。六つの状態でほとんどのポートフォリオをカバーできます。
  • 各ステータスに担当者を一人だけ割り当てます。ユニットをその状態に移す権限を持ち、そこから出す責任を負う人です。
  • 各変更に必要な書類を定め、後で送るという約束で受け付けるのではなく、書類がなければ変更は未完了として扱います。
  • 各ステータスを、それが開くアクションに結び付けます。最初は簡単なタスクリストでもかまいません。
  • 長い間ステータスが変わっていないユニットを毎週見直します。この記録における静止は安定ではなく、不具合のサインだからです。

次回

ステータスは確定し、その背後には担当者、タイムスタンプ、書類があります。次回はその上に、不動産で最も重いサイクルであるお金の流れを構築します。すべての契約に予定された支払期日、期日の後ではなく前に届くリマインダー、入金と同時の記帳、延滞を回収するための段階的な手順、そして立ち退きではなく交渉ができるほど早く届く更新アラートです。

出典