Skip to content

Instantly share code, notes, and snippets.

@stakiran
Created February 1, 2026 02:47
Show Gist options
  • Select an option

  • Save stakiran/f47736e414c0d9f2aa906a200417b992 to your computer and use it in GitHub Desktop.

Select an option

Save stakiran/f47736e414c0d9f2aa906a200417b992 to your computer and use it in GitHub Desktop.

ホフィス

ホフィス(Hoffice) とはホテル + オフィスを組み合わせた造語であり、ホテルのあり方に取り入れて設計されたオフィスを指す。

具体的なあり方は各自で設計可能だが、必ず使わないといけない制約(ホフィス原則)がある。ホフィス原則にしたがって、各社レイアウトを整備する。

ホフィス原則

  • リージョンゾーン
    • リージョンは地理的な単位を示す。たとえば東京オフィスと京都オフィスがある場合、リージョンは東京と京都で2つある
    • ゾーンはリージョン内の単一または複数存在する単位で、一つのオフィスレイアウトを定めた単位となる。より具体的には、後述するルームのタイプと比率とレイアウトを定める
  • ルーム
    • ルームはホテルでいうシングルルームのような単位であり、個人または4人以下の少人数が滞在して仕事できる程度の空間を指す。あくまでオフィスなのでホテルのようにベッド、バス、トイレなどは存在しない。逆に仕事に必要なデスクと椅子、電源と通信、空調は完備しなければならない
    • ルームは論理的な概念であり、必ずしもホテルのように物理的に区切られた個室にする必要はない。しかしプライベートかつパーソナルに仕事できる程度にはクローズドでなくてはならない。オープンオフィス上で実現する場合、ルームの出入り口以外の全方位をパーティションで囲う程度は必要である
    • ルームは不正防止のため、透明性を保持しなくてはならない。オープンオフィス上でパーティションで囲うだけなら自然と保持されるだろう。ホテルのような物理的に区切られた個室にする場合、ドアや壁を透明にしなければならない。また施錠の概念もない
    • ルームにはタイプがあり、規定されたタイプの使い方のみが許される
    • ルームの内部と設備は共通している。つまり規格である。ただタイプに応じた使い分けをするだけである
  • フロア
    • フロアは独自概念ではなく、オフィスビルにおける一階層分を指す言葉としてすでに定着している
    • ホフィスではフロアは単一または複数のゾーンから構成して良いとする。つまり1フロアは複数のゾーンを含んでもよい

ホフィスの思想

まずは従来のあり方を振り返る。近年のオフィスワーカーは ABW(Activity Based Working)が主流である。これは活動に応じてどこで働くかを「オフィス内で」選ぶというものだ。オフィスには個人ブース、会議室、オープンなコミュニケーションエリア、カフェなど複数の機能があり、この中から自由に選ぶ形となる。しかし実情はフリーアドレスにすぎず、個室数や私物保管の削減によるコスト削減と、見通しの良さによる間接的な圧力の意味合いが強い。場所を選ばず、少ない持ち物で、口頭ベースかつ割り込みにも強い「器用な者」にしか合わない、限定的なオフィスとなってしまっている。

特に個人や少人数で深く集中する営みがやりづらく、それゆえイノベーションや変革も生まれづらく、その前段となる心理的安全性その他エンゲージメントの向上も起こりにくい。あるいは機会が限定的になってしまう(たとえば会議室の争奪戦が発生する)。

この問題を根本から解消するオフィス・パラダイムがホフィスであり、ホフィスではルームという「個人または少人数で集中できる場所」を基本単位としている。ルームのタイプとその比率やレイアウトは自由につくれるが、ルームそのものは 4 人以下のコンパクトな単位であるため、この前提で設計することになる。つまりホフィスは少人数以下の単位で駆動させよ、と言っている。また、ルームの規格が単一であることから物理的にも建造しやすい。

ルームのタイプ

必要に応じて新たに定義してもよいが、代表的なタイプを示す。

プロルーム(Pro-room) は、ひとりで使うルームである。空いているときに最初に入った者がチェックインの対象となる。一時的なルームであり、オフィスの消灯までに必ず退出しなければならない。私物を残すこともできない。なおチェックアウトは明示的に行う必要がある。なので部屋を出るだけではチェックアウトはされず、したがって離席が可能である。

コルーム(Co-room) は、複数人で使うルームである。ホフィス原則により上限は 4 人までだ。コルームはミーティングや協調作業を意図しており、部外者の相席は想定しない。飲食店でいうテーブル席1席に相当する。空いているときに最初に入った者がチェックインの対象となる。一時的なルームであり、消灯までに完全退出が必要である。チェックアウトは n 分ごとに自動で行われるため、必要に応じて明示的に延長しなければならない。n の値はゾーンの設定値としてカスタマイズできる。つまりゾーン内では一律となる(空調制御と同じだ)。

拠点ルーム(Base-room) は、消灯までに完全退出せず私物を残しておけるルームである。チームやグループといった組織単位が拠点として使うものである。しかしホフィス原則により、4 人以下の空間であるから、おそらく全員が居座れるだけのキャパシティはない。なお施錠の概念があり、チームの私物を保管できる。たとえば鍵付きロッカーや金庫を導入しても良い。

これら 3 タイプを整理すると、次のようになる:

ルーム名 人数 日ごとにクリアする? チェックアウト
プロルーム 1 yes 利用者が実施
コルーム 2~4 yes n分ごとに強制だが、延長は可能
拠点ルーム N No -

この 3 タイプはラフにつくられているが、より細かくつくることもできる。たとえば「1時間ごとに強制チェックアウトされ、1日1回しか使えず、通話も一切禁止のプロルーム」や「同時に2人しか入れない1on1用のコルーム」をつくることもできる。また古典的な組織では役員向けの役員ルームをつくることにはなるだろう。

すべてのルームは全社員もしくはリージョンの勤務者全員が利用可能であるため、あまり特殊なタイプはつくるべきではない。限定的に利用させたいものは拠点ルームの形でつくり、かつゾーンを分けるべきである。これを拠点ゾーンと呼ぶ。役員ルームも拠点ゾーンにつくるべきだろう。

ホフィスをつくるには

ここではゾーン設計に焦点を当てる。

ゾーン設計では以下を定める:

  • 1: 使用するルームのタイプ
  • 2: 各タイプの比率
  • 3: 各ルームとその他共用設備や共用空間のレイアウト

例1: 従来の ABW をベースにした設計例

  • 1: 使用するのはプロルームとコルーム
  • 2: 比率はプロルームが 7 割、コルームが 3 割
  • 3: レイアウトはフロア中央から以下の順に配置する
    • エレベーターなど移動動線
    • 共用設備や共用空間などのオープンエリア
    • コルームの区域
    • プロルームの区域

例2: 例1に拠点も追加した設計例

  • ゾーン1
    • プロルームが 7 割、コルームが 3 割
  • ゾーン2
    • 拠点ルームが 10 割
  • フロア
    • フロアの西側をゾーン1、フロアの東側をゾーン2とする
    • ゾーン1のレイアウトは例1のとおり、中央から賑やかな空間を配置していく

上記概念が有効になる条件(前提)と、破綻する条件を列挙して。

有効になる条件(前提)

1) 業務特性が「少人数・高密度」に寄っている

  • 成果の中心が、個人の深い集中(設計・実装・執筆・分析・企画)や、2〜4人での詰め作業(レビュー、ペア作業、仕様調整、意思決定)である
  • 大人数の常時コラボ(10人以上が同一空間で同時に動く)を主戦場にしていない
  • 「口頭で割り込みながら進める」より「各自が集中して同期点で合わせる」ほうが生産的な職種比率が高い

2) ルーム運用を支える“制度・ツール・マナー”が用意できる

  • チェックイン/チェックアウト(明示、強制、延長)が摩擦なく回る仕組みがある(アプリ、サイネージ、センサー、運用ルール等)
  • 「離席=占有し続けてよい/よくない」の扱いがタイプごとに明確で、納得感がある
  • 監視ではなく“公平な利用”として受け止められるガバナンス設計(ログの扱い、目的、開示範囲)がある

3) 需要(人数・滞在時間)に対して供給(ルーム数)が足りている

  • 1人用(プロ)と2〜4人用(コ)の需要予測ができ、ピーク時でも致命的な不足にならない
  • 会議室争奪戦と同じ問題を「コルーム争奪戦」に移植しない程度の供給がある
  • 「全社員が利用可能」という思想と、拠点ルーム(占有資源)が共存できるだけの床面積がある

4) 透明性とプライバシーの“落とし所”を設計できる

  • 不正防止の透明性(ガラス壁等)と、集中・安心のための遮音/視線制御(吸音、目隠し、距離、動線)が両立できる
  • 機密情報・個人情報の取り扱いが、透明個室でも成立する(画面フィルタ、席配置、印刷運用、持ち出し制御等)

5) 物理設備が「小部屋の量産」に耐える

  • 空調・換気・防災・避難計画が小部屋前提で成立する(CO2、熱、音、スプリンクラー、排煙、導線)
  • 通信と電源を部屋単位で安定供給できる(Wi‑Fi設計、AP密度、PoE、配線ルール)
  • 清掃、故障対応、備品補充が“部屋数増”に耐える運用体制

6) 組織文化が「占有より回転」「暗黙より明示」を受け入れられる

  • “席取り”や“根城化”を善としない(プロ/コは日次クリアの思想に同意できる)
  • ルームの使い分け(通話可否、飲食可否、会話量など)を守る文化がある
  • 拠点ルーム(施錠・私物)を例外として認めつつ、特権化しすぎない合意形成ができる

7) ゾーンという粒度で運用を変える必然がある

  • チーム拠点ゾーン、静粛ゾーン、来客対応ゾーンなど、用途差が明確でゾーニングが意味を持つ
  • リージョンごとの差(通勤圏、採用、職種構成、来客頻度)に合わせて設計を変える必要がある

破綻する条件(うまくいかない/理念倒れになる条件)

A) 「ルームが足りない」または「偏る」

  • プロルームが不足し、結局オープン席やカフェ難民が発生する
  • コルームが不足し、ABWと同じく予約競争・立ち話・廊下会議が常態化する
  • 拠点ルームを増やしすぎて可用性が落ち、全社員利用可能という前提が崩れる

B) チェックイン/アウトが形骸化する(運用が回らない)

  • 明示チェックアウトを誰もやらず、幽霊占有が増える
  • 強制チェックアウト(n分)が短すぎて作業が分断され、長すぎて回転しない
  • 延長操作が面倒で、結局「ルール破りが得」になる
  • 運用監視・注意が必要になり、運営コストと心理的負担が増えて破綻する

C) 透明性要件が心理的安全性を壊す

  • ガラス張りが「見られている感」を強め、集中・内省・試行錯誤がやりづらくなる
  • 相談・1on1・評価・健康/メンタルの話など、繊細な会話がしづらい
  • 不正防止のはずが“監視オフィス”と解釈され、エンゲージメントが下がる

D) 音問題が解決できず「個室なのにうるさい」になる

  • 小部屋化で遮音が不足すると、通話・会話・換気音が漏れて逆に集中できない
  • コルームが実質会議室化し、周辺のプロルームに騒音被害が広がる
  • サイレント運用が守られず、注意コストが常態化する

E) 機密・コンプライアンス要件と衝突する

  • 透明壁・施錠なし・共用利用が、情報管理規程や監査要件に合わない
  • 来客・外部委託・派遣等が混在するリージョンで、入退室管理が成立しない
  • 拠点ルームの施錠運用が杜撰で、紛失・盗難・情報漏えいが増える

F) 「4人以下」が業務実態と噛み合わない

  • 5〜8人以上の常設スクラム/制作/営業チームが同席前提で回っている
  • 大人数でホワイトボード前に集まる頻度が高い(物理集合が価値の中心)
  • 製造・実験・放送・デザインスタジオ等、設備中心で「部屋が作業台」になりやすい業態

G) ルーム規格の単一化が、多様な身体性・働き方に対応できない

  • 長時間作業、立ち作業、デュアルモニタ、特殊入力機器などに合わず生産性が落ちる
  • バリアフリー(車椅子回転半径、介助、聴覚支援等)に適合しない部屋が増える
  • “規格”が現場ニーズと乖離し、勝手改造・備品持ち込みが横行する

H) 清掃・衛生・保守が追いつかない

  • 部屋数増で清掃が間に合わず、飲食・ゴミ・匂い・備品劣化が蓄積する
  • 故障(椅子・電源・モニタ・ドア等)の発見と修理が遅れ、使えない部屋が増える

I) ゾーニングが「分断」や「階級化」を生む

  • 拠点ゾーンが実質的な特権エリアになり、他社員が使いにくい空気が生まれる
  • リージョン間で体験差が大きくなり、異動や出張時に運用が混乱する
  • “自由に使える”はずが、暗黙の縄張りで実質利用不可になる

J) 目的が「コスト削減」に回収され、思想が逆転する

  • ルームを増やさず机だけ減らして「チェックイン制フリーアドレス」になり、ABWの欠点が強化される
  • 透明性が“圧力”として運用され、集中と心理的安全性を狙った思想が崩れる

必要なら、想定する会社規模(人数・出社率)、職種構成、機密レベル、1日の会議量(平均/ピーク)を教えてください。そこから「ホフィスが有効になりやすい条件に対して、どこがリスクか」をチェックリスト化して返せます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment