組織図より「直接話せる関係」——ナヴァル・ラヴィカントの小さなチーム論
組織が大きくなると、報告経路、会議、承認、チャットのチャンネルが増えていきます。情報を整理するための仕組みが、いつの間にか仕事そのものを遅くすることもあります。
ナヴァル・ラヴィカント（Naval Ravikant）は、2026年5月4日公開のNaval Podcastで、自身が関わるスタートアップの組織を「fully interconnected graph（完全に相互接続されたネットワーク）」として説明しました。階層を何段も通すのではなく、必要な人同士が直接話し、少人数のチームが自律的に動く考え方です。
これは「Slackをやめれば会社が速くなる」という単純なツール論ではありません。小さな組織だからこそ使える設計であり、成立させるには人材、責任、情報の持ち方に条件があります。この記事では、ナヴァルの話を日本の企業・経営者・個人事業主が実務で使える形に整理します。
ナヴァルが語る「完全に相互接続されたスタートアップ」
ナヴァルが説明したチームは、基本的には小規模でフラットです。共同創業者兼CEOが全体をつなぐ軽いハブになりつつ、メンバー同士は必要に応じて直接連絡します。上司から上司へと情報を渡すのではなく、問題を解くために必要な相手を自分で見つける設計です。
興味深いのは、社内チャットやプロジェクト管理ソフトをほとんど使わず、コードの共同作業にはGitHubを使い、必要な会話は一対一で行っているという点です。ナヴァル自身も、時に混沌とし、誰に聞けばよいかを探す必要があると認めています。
それでもこの形を選ぶのは、組織を階層化したときに生まれる伝言ゲーム、政治、承認待ちを避けたいからです。少人数であれば、情報を整理する管理層を増やすより、当事者同士が直接つながる方が速い場面があります。
階層は秩序をつくるが、距離もつくる
伝統的な組織は、CEO、役員、部長、課長、担当者という階層で情報を流します。人数が増えても指揮系統を保てるため、大きな会社には合理的な仕組みです。
一方で、問題を知っている人と、解決できる人の間に何層も入ると、情報が要約され、背景が落ち、確認に時間がかかります。現場の担当者が別部署の専門家へ直接聞けば10分で済むことが、会議と承認を経て数日かかることもあります。
ナヴァルの提案は、階層を全面否定することではなく、小さい段階から必要以上に階層を作らないことだと捉えると実務に落とし込みやすくなります。規模が必要とする前に、大企業の組織図だけを先に持ち込まない、ということです。
この組織モデルが成立する3つの条件
1．自分の担当範囲で判断できる人を集める
誰とでも直接話せる組織では、細かな指示を待つ人が多いほど中央のハブに質問が集中します。メンバーには、目的を理解し、自分で次の行動を決め、必要なときだけ助けを求める力が必要です。
採用では経験年数だけでなく、「不明点が出たときに誰へ何を聞くか」「前提が変わったときにどう動くか」を具体例で確認すると、この働き方との相性を見やすくなります。
2．専門家を自分で探し、直接つながれる
完全な相互接続は、全員がすべてを知っている状態ではありません。むしろ、自分に足りない知識を認識し、組織内の誰が詳しいかを探し、短く質問できることが重要です。
そのためには、部署を越えて連絡してよいという明確な許可が必要です。「まず直属の上司を通す」が暗黙のルールになっていると、組織図がフラットでも実際の情報経路は階層型のままです。
3．全体を統合する軽いハブを置く
ナヴァルのチームも、完全な無中心ではありません。共同創業者兼CEOが、製品全体を頭に入れ、複数分野を結びつける役割を担っています。
重要なのは、その人がすべてを承認することではなく、方向がずれたときに結び直すことです。日々の判断は現場へ渡し、目標、優先順位、重大なトレードオフだけを統合役が見る。この線引きがなければ、軽いハブはすぐにボトルネックになります。
AIは「上司」より社内の案内役として使う
ナヴァルは、AIで組織を上から管理するより、メンバーが必要な情報へたどり着く補助としての使い方を挙げています。たとえば、他人が書いたコードや論文を要約する、コードベースから誰がどの領域に詳しいか推測する、設計や取引先資料を横断して現在地を整理するといった用途です。
また、AIによって専門分野の境界を少し越えやすくなるとも説明しています。ハードウェア担当者が検証用の簡単なコードを書き、AI担当者がテスト用のソフトウェアを作る。完成品を別職種なしで作るという意味ではなく、待ち時間を減らし、専門家同士の接点を増やす使い方です。
日本企業で応用するなら、AIに社内メールや全資料を無条件で読ませるのではなく、権限、機密区分、個人情報、利用目的を決めたうえで、承認された情報領域から始める必要があります。便利さと情報管理はセットで設計すべきです。
日本の中小企業で試す4つのステップ
1．まず1つの小規模プロジェクトで試す
全社の組織を一度に変える必要はありません。新サービス、業務改善、採用広報など、5〜10人程度で完結するプロジェクトを選び、必要な相手へ直接連絡できる形を試します。
2．「直接連絡してよい」を明文化する
部署を越える連絡を例外扱いにせず、担当者同士で直接確認してよい範囲を決めます。ただし、契約、価格、法務、個人情報など、承認が必要な事項は別に定義します。自由と統制を同じルールの中に置くことが大切です。
3．会話と記録の役割を分ける
直接会話は速い一方、当事者しか知らない情報を増やす危険があります。相談は一対一でも、決定事項、担当者、期限、理由は共通の場所に短く残します。会話の自由化と、意思決定の記録を両立させます。
4．限界の兆候を先に決める
人数が増え、同じ質問が繰り返される、中央の統合役に判断が集中する、責任者が曖昧になる、といった兆候が出たら、役割や会議、管理ツールを追加する時期です。小さな組織に向く仕組みを、成長後も意地で維持する必要はありません。
「ツールを減らすこと」が目的ではない
ナヴァルのチームがSlackや一般的なプロジェクト管理ソフトを使わないからといって、同じツールをやめれば再現できるわけではありません。重要なのは、情報が必要な人へ早く届き、責任が明確で、決定が残ることです。
顧客対応、品質管理、規制対応、複数拠点の連携では、履歴や承認を残す仕組みが不可欠です。ツールが問題なのではなく、ツールに合わせて会話を遠回りさせることが問題です。
小さな会社では、まず直接話す。繰り返す情報だけを文書化する。人数と複雑性が増えたら、必要な範囲だけ仕組みを足す。この順番なら、管理のための管理を増やしにくくなります。
これまでの起業家記事と組み合わせる
この考え方は、レイラ・ホルモジの「Right People, Right Seat」ともつながります。直接連携型の組織では、能力だけでなく、自律して動けるか、必要な人と協働できるかという適合性が重要になります。
また、中央の統合役がすべてを抱えないためには、ダン・マーテルの「時間を買い戻す」の考え方も有効です。統合役しかできない判断と、他の人へ移せる作業を分けることで、ハブがボトルネックになるのを防げます。
まとめ：小さいうちは、組織図より通信距離を短くする
小規模な組織の強みは、大企業より制度が少ないことではなく、問題を知る人と解決できる人がすぐにつながれることです。
ナヴァルの「完全に相互接続されたスタートアップ」は、誰も管理しない放任型組織ではありません。自律した人材、直接連絡できる文化、全体を結ぶ軽いハブ、必要な記録という条件がそろって初めて機能します。
組織を成長させるとき、最初から管理層とツールを増やすのではなく、まず「この情報は、本当にこの経路を通る必要があるか」と問い直す。少人数企業にとって、それだけでも意思決定の速度は大きく変わります。
原典
ナヴァル・ラヴィカント「‘Nothing Ever Happens’ Is Over」Naval Podcast、2026年5月4日公開。記事内の「The Fully Interconnected Startup」セクションを参照。
アシーマの海外情報リサーチ
海外の起業家や企業が実践する組織設計、AI活用、事業運営の事例を、日本企業の意思決定に使える形で整理したい場合は、アシーマの海外情報リサーチをご利用いただけます。
コメント