[Compass開発記 Ep0] 小さな会社ほど、経営OSが要る — 羅針盤 Compass を作り始めた理由
経営者が「全部見る」は、物理的に無理だった
Play Life Studio は、正社員が数人、一緒に動いてくれる業務委託・フリーランスがその数倍、という形の会社です。私自身も代表でありながら別の組織に所属していて、会社に張り付いていられる時間は限られています。
こういう会社の形は、これから珍しくなくなると思っています。人を雇い切らず、案件ごとに専門家と組み、AI に任せられる仕事は任せる。身の丈で回す会社の、たぶん普通の姿です。
ただ、この形には、やってみて初めて分かる弱点がありました。「今、会社がどうなっているか」が、どこにも残らないのです。
誰がどの案件にどれだけ動いているか。誰にどのツールや AI のアカウントを、何のために、いつまで許可したか。今月の稼働は枠に収まっているか。Slack にも Notion にもスプレッドシートにも、断片は流れています。でも「状態」として置いてある場所がない。経営者が全部を見に行けば分かる、という前提は、私の時間の都合で早々に崩れました。
そこで、経営の「状態」を持つ場所を自分たちで作ることにしました。社内では PLS Compass（羅針盤） と呼んでいます。この記事のタイトルにある「経営OS」は、この「会社の今の状態を 1 画面で持ち、判断と更新がそこで回る仕組み」のことです。この記事はそのシリーズの導入回で、なぜ作ったのか、何を大事にして作っているのかを書きます。具体的な作り方は次回以降に分けます。
背景: 少人数・業務委託中心・代表も兼業、という会社の形
もう少しだけ、前提を共有させてください。
私たちは XR や AI を使ったシステムの受託開発と、自社プロダクトの開発を並行しています。開発組織は部門で区切らず、担当者ごとの稼働按分で各事業のコストを計算しています。正社員と業務委託の区別は極力つけず、誰とでも長期的な関係を目指す、というのが組織設計の基準です。
この設計自体は気に入っています。ただ、運用すると次のようなことが日常的に起きます。
ある案件が終わったあとも、その人に渡した生成 AI ツールのアカウントが残っている。「まだ使っていますか?」と聞く相手が十数人いる
稼働の記録は集まるが、枠に対して使いすぎているのか、案件の売上に見合っているのかは、月が締まってから分かる
誰かが誰かを陰で助けている。でもそれは Slack の流れの中で消えて、評価にも感謝にも残らない
「その規模ならスプレッドシートと Notion で足りるのでは」と言われそうです。実際、稼働の集計はスプレッドシートで回してきましたし、今も使っています。崩れたのは更新ではなく、横断でした。稼働はシート、権限は誰かの記憶、貢献は Slack、数字は会計ソフト、と置き場所が分かれていて、それを突き合わせるのが経営者の手作業になる。その手作業を、私は続けられませんでした。
どれも致命傷ではありません。でも積み重なると、経営者は「見えていない不安」を抱えたまま判断することになります。私が知りたいのは大きなレポートではなく、今週、どこを見ればいいかでした。
構想: 「状態」を持つ 1 枚の羅針盤
Compass は、社内向けの Web アプリです。ログインすると、その人の権限で見られる範囲の「会社の今」が 1 画面に出ます。
置いているものは、大きく 5 つです。
稼働と案件 — 誰がどの案件にどれだけ動いたか、枠に対してどのくらい使ったか
費用と売上 — 案件ごとの原価率、月次の見通し。会計ソフトの正データから組み立てる
ツールと AI の利用権限 — 誰に・何を・何の用途で・いつまで許可したか。申請と承認、そして「まだ使っていますか?」の棚卸し。ここは作ったばかりで、Ep1 で画面を見せます
貢献の可視化（Kudos） — 誰かを助けた、感謝された、という行動を軽く記録し、上位と称号は全員に、内訳は本人にだけ見せる
Vision — ミッション・行動基準・組織設計基準を、数字と同じアプリの中に置く。手書きの原本もそのまま載せている
5 番目を入れたのは意図的です。経営の数字と会社の理念は、普通は別の場所にあります。数字は会計ソフトに、理念は入社時の資料に。でも判断は両方を同時に見て行うものなので、同じ画面にあるべきだと考えました。ログインした全員が、稼働を入力する画面の隣で「なぜ Gamify するのか」を読めるようにしています。
技術的には、Next.js と Supabase で作り、Vercel に置いています。会計ソフト、Notion、Slack、スプレッドシートは今までどおり使い、Compass はそれらから読み取って「状態」として束ねる層に徹しています。今使っているツールを捨てさせないことを最初に決めました。
考え方: 作りながら決めた 4 つの設計原則
Compass は最初から設計書があったわけではなく、受託の合間に小さく出しては直す、を繰り返しています。その中で、これは守ろう、と決めたことが 4 つあります。
① 状態を持つ。会話に流さない
Slack は便利ですが、会話は流れます。「誰に何を許可したか」のような情報は、会話ではなく状態として置き、変わったら更新する。あとで検索して探すのではなく、開けばそこにある。地味ですが、これが一番効きました。
② 人が握る場所を、先に決める
AI に開発も運用も手伝ってもらっています。だからこそ、人が最後まで握る場所を先に決めました。本番データベースの変更、権限の設定、環境変数の変更。ここは AI ではなく責任者だけが触る。危険な変更は上位者に通知が行き、承認がないと進まない。便利さより先に、この線を引きました。
正直に言うと、これは「責任者 1 人がボトルネックになる」リスクとのトレードオフです。全部を見きれない、と言った本人が、最後の承認だけは握っている。ここをどう移譲していくかも含めて、Ep3 で書きます。
③ 非エンジニアが、自分で育てられる
営業やマーケティングの担当者が「こうしたい」と思ったとき、開発者の順番待ちにならない仕組みを目指しています。今できているのは、要望を Notion のチケットにして AI が実装し、私が確認して本番に出す、という流れまでです。次に作っているのが、Compass の中の AI アシスタントに話しかけると要望を整理してチケットにしてくれる窓口と、依頼した本人が自分のログインで確認できる仕組み。「誰でも作れる」の社内版で、Ep2 では実装済みの部分と、これからの部分を分けて書きます。
④ 貢献が見える
私たちの会社は「ゲーミフィケーションで機会の平等をつくる」ことを掲げています。これは研究テーマであると同時に、自分たちの組織にも当てはめるべきものです。稼働時間や発言数ではなく、他者への貢献、特に明示的な感謝に重みを置いて可視化する。上位と称号は全員に見え、内訳は本人にしか見えないようにして、静かに助けている人が報われる形にしました。ここは自社の思想そのものなので、Compass の中でも特に大事にしている部分です。
この 4 つは、私たちが外向きに掲げている 3 つの軸、「民主化（誰でも作れる）」「Built to be Used（作って終わりにしない）」「Human-Centered（人と社会のために）」を、社内に向けて実践したものだと思っています。
作り方の姿勢: 小さく出して、使われなければ消す
もう 1 つ、姿勢の話をします。
Compass は AI（Claude Code）と一緒に作っています。要望を Notion に起票し、AI が実装し、私が確認して本番に出す。1 つの機能が数時間から数日で出ます。貢献を可視化する Kudos は、音声メモで構想を話してから 2 日後には本番で動いていました。この速度は、少人数の会社にとって本当に大きい。
ただ、速く作れることと、使われることは別です。私たちは「Built to be Used」を掲げているので、使われていない機能は消すことにしています。そのために、機能を出し入れしやすいモジュール構成にしました。ゲーミフィケーションのような機能は、管理画面から丸ごとオンオフできます。必要な分だけが見える、軽い画面でいたいからです。
これは、将来この仕組みを社外の同じ形の会社にも開くかもしれない、という含みでもあります。社内の検討はまだ入口で、決めていませんし、価格も時期もありません。この記事への反応そのものが、最初の判断材料になります。ただ、「小さな会社ほど、経営の状態を持つ場所が要る」という感覚は、私たちだけのものではない気がしています。
次回からの地図
このシリーズは、あと 3 回に分けて書きます。
Ep1 組織体制とツール基盤 — 原則①の実装。誰に・何を・いつまで許可したかを忘れない会社にするために、窓口と承認の線をどう引いたか。ツール台帳・許可・棚卸しの画面
Ep2 営業・マーケ担当が自分で更新できる AI インターフェース — 原則③の実装。改修依頼を「会話」にして、チケット・実装・確認・承認を 1 枚で追う
Ep3 安全に運用する仕組み — 原則②の実装。AI に社内システムを触らせるとき、人が握るべき 3 つ（権限・環境・監査）
各回、「困っていたこと → やったこと（画面つき）→ 作っていて気づいたこと → 明日から真似できる最小手順」の順で書きます。スプレッドシート 1 枚から始められる形も、必ず添えます。
最後に 1 つ、お願いがあります。同じような形、少人数で業務委託と一緒に回している会社の経営者の方に、30 分ほどお話を聞かせてもらえないでしょうか。「うちではここが困っている」を教えていただけると、Compass の次の一手が決まります。ご連絡は、この記事へのコメントか、Play Life Studio のお問い合わせ窓口からお願いします。
著者: 清水啓太郎 — Play Life Studio 代表取締役。XR × AI × ゲーミフィケーションの受託・プロダクト開発と、HCI 分野の博士課程研究を行き来しながら、「使われ続けるシステム」の作り方を探しています。X: @GIZAGIZAHEART
