スタートアップは人を信頼し、大企業はプロセスを信頼する
レビュー、中間管理職、雇用安定から考える「組織の信頼コスト」
スタートアップのエンジニアリング組織と、コンサルティング会社や大企業のプロジェクトを行き来していると、同じ「レビュー」という言葉が、まったく違う行為を指しているように感じることがある。
たとえば、あるシステムの設計を考えているとする。
比較的テクノロジー色の強いスタートアップであれば、経営やビジネス側と合意するのは「この機能によって何を実現したいのか」「どんなユーザー価値を作るのか」「いつ頃までに必要なのか」といったレベルであることが多い。その下にあるアーキテクチャ、データモデル、API設計、実装方式といった技術的な判断は、CTOやTech Lead、Engineering Manager、個々のエンジニアにかなり委譲される。
もちろん会社によって程度は違うし、スタートアップだから必ずそうなるわけでもない。しかし、少なくとも成熟したプロダクト開発組織では、「何を作るか」と「どう作るか」の境界がある程度整理され、専門家が専門家として判断する余地が設けられていることが多い。
Scrum Guideを読むと、この発想はかなり明示的だ。Scrum Teamは自己管理的であり、Product Owner、Scrum Master、Developersという異なるaccountabilityを持ちながら、一つのProduct Goalに向かう。Sprint Reviewではステークホルダーと成果を検査するが、同時にScrumのイベントは「必要な透明性を作り、定義されていない追加会議の必要性を最小化する」ためにも設計されている。つまり、AgileやScrumの本旨は「ビジネスとエンジニアを分断すること」ではない。むしろ両者が頻繁に協働しながら、どこまでを共同で意思決定し、どこから先を専門家に委譲するかというインターフェースを明確にすることにある。
一方、コンサルティング、とりわけ大企業の変革プロジェクトやITプロジェクトに入ると、空気がかなり違う。
要件定義をレビューする。設計をレビューする。実装方針をレビューする。テスト計画をレビューする。そのレビューの前に、上司向けの内部レビューをする。そこで指摘されたことを直し、クライアント側の担当者と事前に認識を合わせ、さらに意思決定者の会議へ持っていく。
エンジニアからすると、「それは専門家同士で決めればよいのではないか」と感じる論点まで、かなり上の職位の人が入ってくることがある。
しかも、当然ながら全員がその領域の専門家ではない。
すると現場には、成果物そのものを作る能力だけでなく、その成果物を「専門家ではない意思決定者が判断できる情報粒度へ変換する能力」が要求される。
技術的に正しいことだけでは足りない。
なぜその方式なのか。ほかの選択肢は何か。その方式を選んだときのビジネス上の意味は何か。スケジュールへの影響は何か。リスクは何か。誰がどの時点で判断し、何を前提としているのか。
そこまで整理して、初めてレビュー可能な状態になる。
私は以前、この違いをかなり単純に捉えていた。
スタートアップは速い。大企業は遅い。
スタートアップは合理的だ。コンサルや大企業は会議と資料が多くて非効率だ。
しかし、少し考えてみると、どうもそれだけでは説明できない。
むしろ両者は、組織の中で「何を信頼しているのか」が違うのではないか。
スタートアップは、かなりの部分を人に賭けている。
大企業やコンサルは、人ではなくプロセスに賭けている。
その違いとして眺めてみると、レビュー、資料、中間管理職、会議、そして雇用制度までが、一つの線でつながって見えてくる。
信頼は、情報を圧縮する
組織で仕事をするとき、すべての人がすべてを理解することはできない。
これは単純に情報量の問題である。
CEOが、プロダクトで使われているすべてのライブラリを理解する必要はない。CFOがKubernetesのクラスタ設計を理解する必要もない。営業責任者がデータベースのインデックス設計をレビューする必要もない。
逆方向も同じで、エンジニアが会社のすべての資金調達条件、販売チャネル、法務論点、採用計画を詳細に理解している必要はない。
組織というものは、本質的には「自分が知らないことを誰かに任せる」ことで成立している。
このとき重要なのが信頼である。
「あの人が確認したなら大丈夫だろう」
「このチームなら任せておけば品質を担保してくれるだろう」
「CTOが承認しているなら、経営側がコードまで確認する必要はないだろう」
こうした信頼は、単なる人間関係の話ではない。
情報圧縮の仕組みである。
仮にある技術的意思決定を完全に理解するために100の情報が必要だとする。その100をCEOまで持ち上げれば、CEOも100を処理しなければならない。
しかし、信頼できるCTOがそれを確認し、「問題ない。このFeatureは予定どおり出せる」と要約できるなら、100の情報を数個のシグナルに圧縮できる。
この圧縮こそが、権限委譲の経済性である。
経済学者Luis Garicanoは、組織階層を「知識をどう配置し、誰がどの問題を解くか」という観点からモデル化している。現場は頻出する問題を自分で解き、難しい問題だけを上位の専門家へエスカレーションする。すべての問題を上位者へ送れば、コミュニケーションコストが膨らむからだ。つまり階層は、単に偉い人を上に置く制度ではなく、「誰が何を知るべきか」を分業する仕組みでもある。
この視点から見ると、スタートアップの速度を支えているものの一つは、人数が少ないことだけではない。
信頼による情報圧縮が大きい。
「この領域はこの人に任せる」
それだけで、上位層が処理しなければならない情報量を劇的に減らせる。
そして興味深いことに、組織研究には「信頼が高いほど意思決定を分権化しやすい」という実証研究もある。Bloomらは複数国の企業データを用い、信頼の高い環境では企業がより意思決定を現場へ委譲する傾向を報告している。因果関係の扱いには慎重さが必要だが、「信頼が分権化を可能にする」という直感は、単なるスタートアップ業界の精神論ではない。
言い換えれば、信頼とは組織におけるキャッシュのようなものなのかもしれない。
一度「この人の判断なら大丈夫」という評価が蓄積されると、それ以降の意思決定で毎回すべてを再計算する必要がなくなる。
速い組織とは、意思決定能力が高い組織というより、「再検証しなくてよい領域が多い組織」と考えた方が実態に近いことがある。
エンジニア組織には「専門家のまま偉くなる」という道がある
ここで、コンサルとエンジニアのキャリア構造の違いを考えてみたい。
エンジニアリング組織では、少なくともテック企業を中心に、Individual Contributor、いわゆるICとして専門性を深めながら昇進するキャリアラダーが比較的明確に存在する。
GitLabの公開されているキャリアフレームワークを見るだけでも、Senior Engineerの先にStaff、Senior Staff、PrincipalといったICの階層が用意され、その一方でEngineering Managementのキャリアが別に存在している。つまり、「昇進するなら人を管理しなければならない」という一本道ではない。
もちろんStaff EngineerやPrincipal Engineerになれば、純粋にコードだけを書いているわけではない。組織横断の技術判断、メンタリング、技術戦略、ステークホルダーとの調整などが増える。それでも「専門性を軸に上へ行く」というキャリアの正統性は保たれている。
コンサルティングの典型的なキャリアは少し違う。
たとえばMcKinseyの現在の職位説明を見ると、Associateは自分のworkstreamを持つ。Engagement Managerになるとプロジェクト全体の方向づけや日々の実行管理、チームのメンタリングを担う。Associate Partnerは複数案件のデリバリーに責任を持ちながら新しいクライアント機会を開拓し、Partnerになると経営層のアドバイザーとして大きなクライアント関係とファームの成長にも責任を持つ。職位が上がるほど、「自分で分析する人」から「人・顧客・案件・売上を動かす人」へ仕事の重心が移る構造が公式の役割記述にも表れている。
もちろん、これは「上位コンサルタントには専門性がない」という意味ではない。
実際には強い業界知識や機能知識を持ったPartnerも多いし、テクノロジー、データサイエンス、デザインなど専門職系の別トラックを置くファームもある。したがって「コンサルは専門性が身につく前に全員マネージャーになる」と一般化するのは雑すぎる。
それでも、総合系のコンサルタントという職種が、職位の上昇とともにマネジメント、顧客関係、営業へ比重を移していく傾向は存在する。
すると面白いことが起きる。
現場の若手ほど、ある狭い論点については最新の細かい情報を持っている。
一方、意思決定権を持つ上位者ほど、その論点を細部まで追ってはいない。
しかし、決めるのは上位者である。
この構造では、現場の専門知識をそのまま上へ投げても意思決定できない。
そこで「翻訳」が必要になる。
技術論を経営論へ翻訳する。
仕様をリスクへ翻訳する。
複雑性を選択肢へ翻訳する。
細かい事実を、一枚のスライドへ圧縮する。
コンサルでよく言われる「相手の視点に立つ」「上司が何を気にするかを考える」「クライアントが判断できる粒度にする」という能力は、単に接客業だから必要なのではない。
知識を持つ人と意思決定権を持つ人が分離している組織では、構造的に必要になる能力なのである。
スタートアップは「ブラックボックス」を許せる
エンジニアリング組織を見ていると、ブラックボックスという言葉に少し違う印象を持つようになる。
一般にブラックボックスは悪いものとして語られる。
中身が見えない。
属人化している。
何をやっているかわからない。
しかし、専門分業というのは本質的にはブラックボックス化である。
APIを使う人は内部実装を知らなくてもよい。
クラウドサービスを利用する人は、データセンターの配線を知らなくてもよい。
飛行機に乗る人はジェットエンジンの燃焼制御を理解していなくてもよい。
内部を知らなくても、インターフェースとSLAと出力が信用できれば使える。
組織も同じである。
ビジネス側はEngineering Teamの内部をすべて知る必要はない。
必要なのは、「何を依頼できるのか」「どんな結果が返ってくるのか」「どの程度の確率で約束が守られるのか」がわかることだ。
だから成熟した専門組織では、内部を透明化することより、境界を明確にすることの方が重要になる。
これがうまくいっている組織では、経営はエンジニアリングを細かく監視しない。
監視しなくても期待どおり動くからだ。
CTOやVP of Engineering、Tech Leadといった専門家が内部品質を担保し、経営側にはビジネスとして必要な情報だけが上がる。
ここではブラックボックスが「隠蔽」ではなく「抽象化」として機能している。
ソフトウェアエンジニアリングにおける抽象化とまったく同じで、内部複雑性を外へ漏らさないこと自体が設計品質になる。
この観点からすると、強いCTOの価値は「すべての技術判断を自分ですること」ではない。
経営が技術の内部詳細を知らなくても会社を運営できる状態を作ることにある。
つまり、CTO自身が巨大な抽象化レイヤーなのである。
コンサルは「組織版ゼロトラスト」に近い
ここで、少し乱暴だが便利な比喩を使ってみる。
スタートアップがトラストベースだとすれば、コンサルや大企業のプロジェクトは「組織版ゼロトラスト」に近い。
もちろん、これはサイバーセキュリティにおけるZero Trust Architectureそのものを指しているわけではない。
NISTの定義するZero Trustは、ネットワーク内部だからといって暗黙に信頼せず、ユーザー、資産、リソースを基準にアクセスを判断するセキュリティ思想である。したがって、「会議が多い会社＝ゼロトラスト」というのは技術用語としては正確ではない。ここではあくまで比喩として使う。
それでも、似ているところがある。
スタートアップでは、
「あの人がOKと言ったならOK」
という信頼の継承が起きやすい。
一方、大企業では、
「誰がOKと言ったのか」
だけでは終わらない。
なぜOKなのか。
どの観点で確認したのか。
代替案は検討したのか。
リスクは何か。
前提が変わった場合はどうなるのか。
その意思決定を後から第三者が説明できるか。
こうしたものを資料や議事録として残していく。
人への信頼をなくすというより、「人への信頼だけで意思決定を成立させない」。
これがポイントである。
Aさんが優秀だからではなく、Aさんが退職しても、異動しても、失敗しても、説明可能な状態にしておく。
すると意思決定は、個人からプロセスへ移る。
この世界ではPowerPoint、議事録、Decision Log、課題管理表、レビュー記録は単なる「資料」ではない。
組織の監査ログである。
なぜその判断をしたのかを再現するためのログだ。
エンジニア的に言えば、Observabilityを高めている。
システム内部がどう動いたのかわからないと障害解析ができないように、組織内部で誰が何を根拠に決めたのかわからないと、問題が起きたとき説明できない。
だからログを残す。
そのログを取るコストが、会議と資料作成である。
そう考えると、あの大量のドキュメントにも一定の合理性が見えてくる。
合議制は、遅い代わりに責任を分散する
スタートアップでは、一人の強い意思決定者が決めてしまうことができる。
CEOが言ったからやる。
CTOがこのアーキテクチャで行くと決めたから進む。
Product ManagerがこのFeatureを優先すると決めたから作る。
速い。
しかし当然、外したときの影響も大きい。
その人の判断能力へ組織全体がレバレッジをかけているからだ。
信頼による分権化には速度という大きなメリットがある一方で、「誰を信頼するかを間違えたときの損失」がある。
大企業型のレビューは、その逆である。
意思決定を複数の人へ通す。
法務も見る。
セキュリティも見る。
事業責任者も見る。
IT部門も見る。
場合によっては経営会議も通す。
一つ一つを見ると遅い。
しかし、一人の独断で巨大な失敗が起きる確率は下げられる。
また、意思決定の履歴が残ることで、後から「なぜそうしたのか」を説明しやすい。
ここには、責任の分散という少し生々しい効果もある。
合議で決めたことは、個人が勝手に決めたことより、特定の一人へ責任を集中させにくい。
これを単に「責任逃れ」と呼ぶこともできる。
しかし別の見方をすると、巨大組織が一人の判断ミスで破壊されないための耐障害性とも言える。
分散システムでも、単一障害点をなくすためには冗長性を持たせる。
冗長性は平常時には無駄に見える。
サーバーが一台で足りるのに二台置けば、単純にコストは増える。
しかし一台が落ちてもシステムを動かしたいなら、その無駄が必要になる。
組織の合議制も、ある意味では同じだ。
何も問題が起きなければ、レビュー参加者の半分は不要に見える。
だが「重要な判断を一人に依存しない」という目的を置いた瞬間、その冗長性に意味が生まれる。
大企業が買っているのは「速度」ではなく「失敗確率の低下」かもしれない
ここで、「大企業は非効率」という評価を少し分解した方がよい。
何を最適化しているのかが違えば、効率の意味も変わるからだ。
スタートアップにとって、最大のリスクは何か。
典型的には、資金が尽きること、市場を取れないこと、Product Market Fitに到達できないこと、競合より遅れることだろう。
つまり「何も起こらないまま時間が過ぎる」こと自体が致命傷になりうる。
だから速度には高い価値がある。
多少間違えてもよいから速く学ぶ。
間違えたら戻す。
責任者を変える。
プロダクトを捨てる。
会社そのものがなくなることすらある。
この環境では、高い可逆性を前提として意思決定速度を最大化することが合理的になる。
大企業では事情が違う。
数十年続いているサービス、巨大な顧客基盤、規制対応、既存システム、取引先、ブランド、従業員、労働組合、監査、株主など、多数の既存資産とステークホルダーを抱えている。
そこでの失敗は、「Featureが滑った」では済まないことがある。
大企業ほど常に慎重であるべきだ、と言いたいわけではない。
現実には過剰統制も大量にある。
ただ、意思決定コストだけを比較して「スタートアップの方が合理的」と結論づけると、守っている資産の違いを落としてしまう。
スタートアップは主としてアップサイドを取りに行く組織であり、大企業はアップサイドを取りながら巨大なダウンサイドも管理する組織である。
その違いが、レビュー密度に反映されている可能性は高い。
しかし、レビューには「翻訳税」がかかる
ここまでは大企業型プロセスの合理性を書いた。
それでも、現場で感じる面倒さが消えるわけではない。
なぜなら、専門家ではない人が専門的な意思決定に参加すると、必ず翻訳コストが発生するからだ。
技術者同士であれば、
「この方式だとeventual consistencyになるので、ここはidempotencyを担保して再実行可能にしましょう」
で済む話がある。
しかし、それを経営層へ説明するときには、
「一時的にデータの反映タイミングがずれる可能性があります。ただし処理を安全に再実行できる設計にすることで、ユーザー影響を限定します」
くらいに変換する必要がある。
さらに経営判断に必要なら、
「強い整合性を優先すると開発期間が約X増える。一方、このユースケースでは数秒の遅延が売上へ与える影響は限定的なので、今回は可用性と開発速度を優先する」
という形まで持っていく。
技術情報を減らせばよいわけではない。
意思決定に必要な変数へ射影する必要がある。
これはかなり高度な仕事である。
そして、この翻訳が下手だと、上位者は判断できない。
判断できないから質問が増える。
質問が増えるから資料が増える。
資料が増えるから事前レビューが増える。
その結果、現場は「説明のための説明」に追われる。
ここに大企業プロジェクトの大きなコミュニケーションコストがある。
Garicanoの知識階層モデルでも、問題を知識のある人へ伝えること自体にコストがある。Bloomらの組織研究でも、分権化するか中央へ意思決定を上げるかは、「現場が知っていること」と「上位者に聞くコスト」のトレードオフとして描かれる。
つまり「上司に全部説明する」は無料ではない。
むしろ、組織が巨大になるほど高価になる。
そこで中間管理職が「API Gateway」になる
技術とビジネスの距離が広がりすぎると、直接会話できなくなる。
正確には、会話自体はできるのだが、互いのコンテキストが違いすぎて帯域が足りなくなる。
技術側は細部を知りすぎている。
経営側は事業全体を見ている。
両方とも忙しい。
この二者を直接つなぐと、毎回巨大なコンテキスト交換が必要になる。
そこで間に人が入る。
Project Manager。
Engineering Manager。
PMO。
コンサルタント。
部長。
課長。
こうした人たちは、しばしば「何も作っていない」と批判される。
コードを書かない。
営業もしない。
製品も作らない。
資料と会議ばかりしている。
しかし、組織を情報システムとして見ると、彼らは別のものに見える。
API Gatewayである。
現場から上がってくる大量の技術情報を集約し、経営が理解できるフォーマットへ変換する。
経営から降りてくる「もっと成長させたい」「リスクを下げたい」「今年中にやりたい」という抽象度の高い要求を、現場が実行可能な粒度へ分解する。
異なる部門の用語を変換する。
優先順位を調整する。
エラーをハンドリングする。
必要な相手へルーティングする。
まさにGatewayである。
そして、この役割には研究上も一定の意味が認められている。
野中郁次郎の知識創造論では、「middle-up-down management」という考え方が提示され、中間管理職はトップと現場の間に位置し、両者の認識のギャップを埋めながら知識創造を促す存在として扱われている。後続研究でも、中間管理職がトップとfrontlineの相互作用の間にあるギャップを把握し、解く役割が論じられている。
だから「中間管理職は全部無駄」という話ではない。
むしろ、組織内部のインターフェース設計が悪いほど、中間管理職という翻訳レイヤーの価値が高くなる。
問題はそこからである。
翻訳レイヤーが必要だから存在しているのか。
翻訳レイヤーが存在するから、組織がそれを前提に複雑化しているのか。
長く続いた大企業では、この因果関係が簡単にはわからなくなる。
日本企業では「人より先に仕事を消す」が難しい
ここから雇用の話に入りたい。
このテーマを考えると、「日本の大企業は首を切れないから非効率」という言い方をしたくなる。
ただし、ここは事実として少し慎重になった方がよい。
2026年のOECD Employment Outlookによれば、日本の正規労働者に対するEmployment Protection Legislationの厳格度は、OECD平均をわずかに下回る水準とされている。したがって、「日本は世界でも突出して解雇規制が厳しい」という説明は正確ではない。
一方、日本の労働契約法16条は、客観的に合理的な理由を欠き、社会通念上相当と認められない解雇を権利濫用として無効とする。これは厚生労働省の労働条件ハンドブックにも明記されている。
さらに法律だけでなく、日本企業には長期雇用とメンバーシップ型雇用の歴史がある。
JILPTの濱口桂一郎氏は、ジョブ型を「まずjobがあり、そこへ適した人を配置する仕組み」、日本型のメンバーシップ型を「まず人があり、その人に仕事を割り当てる仕組み」と対比している。後者では会社が配置転換を含む強い人事権を持ち、人が特定のjobと一対一で結びつかない。
ここは、今回のテーマと非常に相性がよい。
ジョブ型の思想を極端に単純化すると、
「この仕事が必要だから、この仕事をできる人を置く」
となる。
仕事がなくなれば、そのposition自体がなくなるという発想とも親和性が高い。
一方メンバーシップ型では、
「この人は会社のメンバーなので、この人に何の仕事をしてもらうかを考える」
という順番になりやすい。
すると事業環境が変わって、ある仕事の価値が下がっても、「ではその人をどうするか」という問題が残る。
別部署へ移す。
新しい役割を作る。
管理業務を任せる。
プロジェクトを持たせる。
組織として人を内部に保持するなら、仕事を再配分し続けなければならない。
ここで、「雇用を守るために無駄な仕事が作られる」という元の仮説に近づいてくる。
ただし、因果関係を断定するにはデータが足りない。
少なくとも今回調べた範囲では、「日本企業の大量レビューやPMOが、雇用維持を目的として生成されている」と直接実証した研究は見つけられなかった。
したがって、ここから先は事実ではなく仮説である。
しかし、制度的な整合性はある。
「退出できない組織」は内部に調整市場を作る
人を簡単に外へ出さない組織では、環境変化を内部で吸収する必要がある。
仕事が変わる。
技術が変わる。
必要なスキルが変わる。
事業が縮小する。
それでも人を保持するなら、組織は配置転換、再教育、役割変更、管理業務への移行などで調整する。
これは労働者にとって重要なメリットでもある。
会社の事業が一つ失敗しただけで即座に失職する可能性が下がる。
会社側も長期間かけて企業固有の知識を育てられる。
部署間の暗黙知や顧客関係など、転職市場では値段がつきにくい能力を蓄積できる。
一方でコストもある。
人を外へ動かしにくいなら、内部で人と仕事をマッチングし続ける機構が必要になる。
ここに人事制度があり、異動があり、会議があり、管理職がいる。
そして、組織が大きくなるにつれて、「誰が何をできるのか」「どこに誰を置くべきか」「どの部署が何を決めるのか」を調整するだけでも巨大な仕事になる。
経済学的に言えば、外部労働市場で行っていた価格調整やマッチングの一部を、企業内部の管理機構で代替しているとも考えられる。
つまり雇用安定は無料ではない。
そのコストの一部は、失業率や給与ではなく、「社内調整」という見えにくい形で支払われる。
ここで初めて、資料作成や中間管理職を別の角度から見ることができる。
彼らは単なる余剰人員なのではない。
人を外に出さず、複雑化した組織を内部で再配線し続けるために必要になったcoordination layerなのかもしれない。
大企業の「無駄」は、一種の保険料なのか
この見方をすると、大企業に存在する一見無駄なものの意味が変わる。
大量のレビュー。
複数段階の承認。
細かな職務分掌。
中間管理職。
PMO。
説明資料。
会議。
どれも単体で見れば削減対象に見える。
しかし組織全体では、「一人の判断ミスで壊れない」「担当者が辞めても回る」「人を簡単に解雇しなくても配置転換できる」「問題が起きたとき説明できる」という性質を作っている可能性がある。
だとすれば、これは効率の悪さというより保険である。
保険は、事故が起きていないときには無駄に見える。
毎月保険料を払って何も起きなければ、そのお金は結果として使われない。
しかし保険を「何も起きなかったから無駄」と評価するのは変だ。
重要なのは、どのリスクに対して、いくら払っているかである。
大企業のガバナンスコストも同じなのかもしれない。
問題は「レビューがあること」ではない。
レビューによって実際にどのリスクが下がっているのかが不明なことだ。
そこが説明できないレビューは、本当に無駄である可能性が高い。
しかし「レビューが多いから無駄」とは限らない。
この区別はかなり重要だと思う。
スタートアップも、成長すると同じ病気になる
ここまで読むと、スタートアップ対大企業という二項対立に見えるかもしれない。
しかし実際には、これは会社種別より組織サイズと失敗コストの問題だと思う。
スタートアップも成長すれば管理層が増える。
セキュリティ審査が増える。
法務が増える。
承認フローが増える。
社内システムが増える。
「昔はSlackでCEOに聞けば決まったのに」という不満が出てくる。
これは企業が堕落したからだけではない。
人数が増え、顧客が増え、守るべき資産が増えれば、誰が何を決めてよいかを定義しなければならなくなるからだ。
組織研究でも、企業内の分権化と階層は、知識の配置とコミュニケーションコストのトレードオフとして扱われる。大きな組織ほど「全員が全員と直接話す」という方式は成立しない。
だから最終的には、スタートアップにもプロセスが入る。
逆に、大企業も過度な中央集権を続ければ遅くなりすぎるため、権限委譲、プロダクト組織化、Agile、DevOpsなどを導入して小さな自律チームを作ろうとする。
両者は別の生物ではない。
会社が成長すると、トラストモデルからプロセスモデルへ少しずつ移動する。
そしてプロセスが重くなりすぎると、再びトラストモデルを部分的に導入しようとする。
組織はこの振り子を行ったり来たりしている。
そして、コンサルはその「摩擦」を仕事にしている
ここで、少し意地悪な問いを立ててみたい。
大企業の複雑性は、誰にとって価値なのだろうか。
企業自身にとっては、当然減らしたい。
組織をシンプルにしたい。
意思決定を速くしたい。
DXしたい。
業務改革したい。
システムを統合したい。
重複業務をなくしたい。
ガバナンスを改善したい。
すると、その複雑性を整理する仕事が生まれる。
現状業務を可視化する。
ステークホルダーを整理する。
To-Beプロセスを描く。
ロードマップを作る。
PMOを置く。
意思決定会議を設計する。
チェンジマネジメントをする。
この仕事のかなりの部分をコンサルティング会社が担う。
ここに一つの皮肉がある。
大企業が複雑だからコンサルが必要になる。
コンサルが入ることで、その複雑性を扱うための会議や資料や管理プロセスがさらに増えることもある。
その結果、「複雑性を解消するための複雑性」が生まれる。
もちろんコンサルが複雑性を作っている、とまで言うのは乱暴である。
大規模変革には外部の専門知識や一時的な実行能力が必要なことがあるし、社内政治から距離を置いた第三者だからこそ進められる仕事もある。
しかし、コンサルティングという産業の一部が「巨大組織内部のcoordination costを外部から処理するサービス」である、と見ることはできる。
コンサルは企業へ知識を売っている。
同時に、企業内部で知識と意思決定権が離れていることから生じる「翻訳」を売っている。
PowerPointが商品なのではない。
翻訳された意思決定可能性が商品なのである。
そう考えると、コンサルタントに異常なほど「上司視点」「クライアント視点」が要求される理由も見えてくる。
彼らの仕事は専門家になることだけではない。
異なる専門世界を接続することだからだ。
すると「雇用安定」と「コンサル価値」は意外と近い場所にある
ここまでをつなげると、元の疑問に戻ってくる。
日本型の大企業では、人が特定jobだけに結びつかず、会社内部で長期的に配置されるメンバーシップ型雇用が歴史的に強かった。JILPTが整理している通り、「jobが先」ではなく「人が先」という構造である。
人を長く保持する。
すると環境変化を内部配置で吸収する必要がある。
内部配置が増えると組織構造が複雑になる。
複雑になると部門間調整が増える。
部門間調整が増えると、翻訳者と管理者が必要になる。
管理レイヤーが増えると、意思決定を通すための資料と会議が増える。
それでも変革が必要になると、外部のコンサルタントを入れて、その複雑性を整理する。
この因果連鎖がどこまで実証的に成立するかは別として、一つの組織仮説としてはかなり面白い。
つまり、
雇用安定とコンサル需要は、正反対のものではなく、同じ組織構造の表裏なのかもしれない。
人を簡単に切らない組織は、人を活かし続けるために複雑な内部市場を持つ。
その内部市場の調整コストが高まると、コンサルティングという外部の調整能力を買う。
少し挑発的に言えば、
「大企業の雇用安定が生み出す組織摩擦の一部が、コンサルティング市場を支えている」
ということになる。
ただし、これは現時点では仮説であって、直接的な因果を証明したものではない。
そして、たぶん現実はもっと複雑だ。
規制産業だからレビューが多い会社もある。
重大事故のリスクが高いからガバナンスを厚くしている会社もある。
単に経営陣が現場を信用していない会社もある。
過去の事故をきっかけに承認フローが増え、そのまま誰も消せなくなった会社もある。
雇用とは無関係に組織政治で管理職が増える場合もある。
だから「大企業の無駄＝雇用維持装置」と一本で説明するべきではない。
それでも、雇用制度を変数の一つとして入れると、大企業の奇妙な行動のいくつかが説明しやすくなるのは確かだと思う。
「無駄をなくせ」ではなく「何のリスクを買っているのか」と考える
スタートアップから大企業を見ると、「これ、いらなくない？」と思うことが本当に多い。
その感覚自体は間違っていないと思う。
実際、誰も読まない資料はある。
意思決定に影響しないレビューもある。
承認者が何も判断していない承認フローもある。
会議を開催することだけが目的になった会議もある。
組織の中には本物の無駄が大量に存在する。
ただ最近は、それをすべて「大企業病」で片づけるのも違うと思うようになった。
スタートアップが速いのは、優秀だからだけではない。
失敗できるから速い。
人に賭けられるから速い。
会社が小さいから情報量が少ない。
誰が何を決めたかを全員が覚えていられる。
必要なら責任者を入れ替えられる。
最悪の場合、会社そのものがなくなる。
その不安定さと速度はセットである。
大企業の遅さも同じだ。
守るものが多い。
人を長く抱える。
過去の意思決定を説明する必要がある。
誰か一人の天才に会社を賭けられない。
だからプロセスを作る。
レビューする。
記録する。
合議する。
そこへコストを払う。
この二つは、「合理的な会社」と「非合理的な会社」の違いというより、何に対して保険料を払っているかの違いなのかもしれない。
スタートアップは、失敗した組織や人を入れ替えられることによってコストを後払いする。
大企業は、失敗する前にレビューとガバナンスへコストを前払いする。
極端に言えば、そういう違いである。
それでも私は、トラストベースの組織の方が好きだ
ここまで大企業側の合理性をかなり擁護してきた。
それでも個人的には、やはりトラストベースで動く組織の方が気持ちがいい。
専門家には専門家として任せたい。
すべてを全員が理解する必要はないと思う。
インターフェースさえきちんと定義されているなら、内部実装はブラックボックスでよい。
CTOが信頼できるなら、経営陣全員が技術設計をレビューしなくてもよい。
エンジニアが信頼できるなら、毎回「なぜこの実装にしたのか」をPowerPointで説明しなくてもよい。
信頼は速い。
そして何より、人が専門家として働きやすい。
ただし、その速度は無料ではない。
信頼した人が間違えれば、その損失も引き受ける必要がある。
「あの人に任せた自分が悪かった」と言える組織でなければ、本当の権限委譲は成立しない。
権限だけ渡して、失敗したら細部まで責任追及する組織は、トラスト型の速度とゼロトラスト型の安心を両取りしようとしている。
たぶん、それが一番うまくいかない。
組織設計にはトレードオフがある。
速度が欲しければ、委譲と失敗を受け入れなければならない。
失敗を極小化したければ、検証コストを払わなければならない。
雇用を安定させたければ、人を内部で再配置するための調整コストを払わなければならない。
専門分業を進めたければ、専門家を信頼しなければならない。
そして、誰も信頼したくないなら、その代わりに大量のプロセスを作らなければならない。
結局、会社に「無駄」があるかどうかを考えるとき、本当に問うべきなのは、
「この仕事は必要か」
だけではないのだと思う。
「この仕事をなくしたとき、誰がどのリスクを引き受けるのか」
まで考えなければならない。
そこまで考えて初めて、無駄なのか、保険なのかがわかる。
スタートアップは人を信頼する。
大企業はプロセスを信頼する。
もちろん現実の会社は、その中間のどこかにいる。
そして、おそらく良い組織とは、どちらか一方を選ぶ組織ではない。
専門家を信頼してよい領域では大胆にブラックボックス化し、一方で会社を壊しかねない不可逆な意思決定には検証可能なプロセスを置く。
つまり、「どこを信頼し、どこを検証するか」を意識的に設計できる組織なのだと思う。
大企業の会議に出ながら「このレビュー、やっぱり面倒だな」と思う気持ちは、たぶんこれからも消えない。
ただ以前よりは、その面倒さを少し違う目で見るようになった。
あれは単なる非効率なのではなく、組織が雇用、責任、専門性、失敗という四つのリスクをどう配分するか、その設計思想が表面に現れたものなのかもしれない。
そして、その設計が複雑になればなるほど、それを読み解き、翻訳し、動かす人が必要になる。
その仕事の一部に「コンサルタント」という名前がついている。
だとすれば、コンサルの価値を生んでいるものは、企業の課題そのものだけではない。
企業が人を簡単には捨てず、巨大な組織を何十年も維持しようとすることによって生じる摩擦もまた、コンサルティングの価値の源泉になっているのではないか。
そんなことを考えると、「雇用安定」と「コンサル」という、一見まったく別の話が、実はかなり近いところでつながっているように思えてくる。
本稿の「スタートアップ＝トラスト、大企業・コンサル＝ゼロトラスト」は組織を理解するための比喩であり、企業一般に成立する実証分類ではない。また「雇用安定が組織摩擦を増やし、その一部がコンサル需要につながる」という部分も、今回参照した研究から直接因果が証明されているわけではなく、雇用制度論、組織経済学、実務経験を接続した仮説である。一方、日本のメンバーシップ型雇用の特徴、解雇に関する法制度、信頼と分権化の関連、知識階層におけるコミュニケーションコスト、エンジニアとコンサルのキャリア構造については、JILPT、厚生労働省、OECD、Scrum Guide、NIST、McKinsey、GitLabおよび組織経済学の研究を参照した。