資産もソフトウェアも、価値を生むのは「持つこと」ではなく「切り離せること」

「何を持っているか」よりも、「いつでも手放せるか」のほうが、組織の健全性を見抜く指標になる。

企業の貸借対照表に大量の有価証券が並んでいるとき、そこには単なる余剰資金の運用以上の意味が隠れていることがある。本業への投資先が見つからず、資金が社外に滞留しているのかもしれない。あるいは、取引関係を安定させるために、互いの株式を持ち合っているのかもしれない。

一方、ソフトウェア開発の現場では、複数のパッケージを一つのリポジトリで管理するモノレポがある。そこでは、依存関係を整理し、必要なものだけを効率的に共有できる仕組みが重要になる。見た目には、企業の株式保有とパッケージ管理はまったく別の話だ。しかし両者は、組織が「関係を結ぶこと」と「関係に縛られること」をどう区別するかという、同じ問題を抱えている。

持っていることは、つながっていることではない

企業が他社の株式を保有する理由はさまざまだ。短期的な売買益を狙う場合もあれば、長期保有を前提に事業上の関係を深める場合もある。問題は、保有の目的が明確かどうかである。

短期売買を目的とする有価証券は、比較的わかりやすい。いつ売るのか、どの程度の利益を期待するのか、どのリスクを許容するのかを定義できるからだ。だが、売却する予定も、事業上の具体的な使い道もない資産が増えると、企業の資本は「選択肢」ではなく「惰性」に変わる。

株式の持ち合いは、その典型である。企業同士が互いの株式を所有すれば、敵対的買収を防ぎ、取引を安定させやすくなる。しかし、その安定は必ずしも価値創造を意味しない。関係を壊さないことが優先されると、相手に厳しい要求をすることも、取引条件を見直すことも難しくなる。

ここで重要なのは、資産の流動性だけではない。関係の可逆性である。

いつでも売却できる株式は、会計上の資産であると同時に、経営上の選択肢でもある。反対に、売却すれば取引関係が壊れる、批判すれば相互保有の秩序が揺らぐという状態では、その株式は帳簿上の資産であっても、経営上は拘束具に近い。

良い関係とは、離れられない関係ではない。必要なときに離れられるからこそ、続けることを選べる関係である。

この視点をソフトウェアに移すと、モノレポの設計が別の姿を見せる。

便利な共有は、依存関係を増やす

複数のソフトウェアパッケージを一つのリポジトリで管理すると、共通部品を再利用しやすくなる。変更の影響範囲を確認しやすく、開発者がプロジェクト全体を見渡せる。パッケージ管理ツールを使えば、個別に重複した依存関係を抱える必要も減る。

これは企業が他社と資本関係を結ぶことに少し似ている。共有は効率を生む。調整コストを下げ、情報を流れやすくし、個別に交渉するよりも速く物事を進められる。

しかし、共有は同時に依存を生む。あるパッケージを変更した結果、別のサービスが壊れるかもしれない。共通ライブラリの更新が、多数のチームのリリース計画を左右するかもしれない。コードが一つの場所に集まっているからといって、設計が単純になるとは限らない。むしろ、見えにくい結びつきが増えるほど、変更の自由度は下がっていく。

企業間の株式持ち合いも同じである。関係を持つことによって、短期的には安心感と取引の滑らかさが得られる。しかし、相手の業績が悪化したときに関係を見直せないなら、その安心感はリスクの先送りである。ソフトウェアでいえば、誰も使っていない共通部品まで「念のため」共有している状態に近い。

だから、モノレポの価値は、すべてを一つに結合することにはない。必要な範囲だけを共有し、不要になれば分離できることにある。優れたパッケージ管理は、依存関係を増やす技術ではなく、依存関係を可視化し、制御する技術である。

組織の資産を測る「出口」という尺度

この二つの領域をつなぐと、組織を評価するための新しい尺度が見えてくる。それは、何を所有しているかではなく、その所有や関係から退出できるかである。

これを「出口の設計」と呼ぼう。

出口の設計がある組織では、投資には売却条件があり、提携には終了条件があり、ソフトウェアの依存には削除手順がある。現在の関係を維持する理由だけでなく、維持できなくなったときの対応まで考えられている。

たとえば、ある企業が取引先の株式を保有するとする。その保有が健全であるためには、少なくとも次の問いに答えられなければならない。

・この保有は、どの事業目的に結びついているのか ・目的が失われたとき、何を基準に売却するのか ・売却によって失われるものは何で、代替手段はあるのか ・相手に対して、資本関係なしでも同じ条件を要求できるのか

ソフトウェアの依存関係でも、ほぼ同じ問いが使える。

・このパッケージを共有する理由は何か ・共有による利益は、変更の自由を失うコストを上回るか ・パッケージを置き換える場合、どれほどの作業が必要か ・共通部品がなくても、各チームは独立してリリースできるか

この対応関係は偶然ではない。資本もコードも、組織の内部で移動する「権利」と「制約」の束だからだ。株式を持つと、配当や議決権などの権利を得る一方、資金を固定し、相手への配慮を要求される。パッケージを共有すると、再利用の利益を得る一方、変更の自由を失う。

したがって、資産や部品の価値は、それ自体の価値だけでは決まらない。利用価値から切替コストを引いたものとして考えるべきである。

簡単な式にすれば、次のようになる。

実質価値 ＝ 利用による利益 － 依存による拘束コスト

拘束コストには、売却できないこと、別の相手に切り替えられないこと、変更の影響範囲を把握できないこと、関係を維持するために本来必要のない妥協をすることが含まれる。

この式を使うと、表面的には利益を生む関係が、実は組織の柔軟性を食いつぶしている可能性に気づける。

「安定」を選ぶ前に、失っているものを数える

安定は魅力的な言葉である。株式の持ち合いは取引を安定させる。共通パッケージは開発を安定させる。長年続く関係は、未知の相手と新しく関係を築くコストを減らす。

ただし、安定には二種類ある。

一つは、変化に耐えられる安定である。構成要素が適切に分離され、問題が一部にとどまり、必要なら交換できる。もう一つは、動けないことによって保たれる安定である。こちらは一見穏やかだが、環境が変化した瞬間に脆さを露呈する。

古い組織で起きやすいのは、後者である。誰も関係を見直さないため、問題が表面化しない。誰も共通部品を削除しないため、依存関係が増え続ける。静かであることが、健全であることと誤認される。

たとえば、十年間取引している会社があるとする。その関係が本当に優れているなら、競合相手から見積もりを取っても、同じ会社を選ぶ理由を説明できるはずだ。逆に、「昔からそうだから」「株式を持ち合っているから」という理由しか残っていないなら、安定ではなく慣性である。

ソフトウェアでも、ある共通ライブラリを使い続ける理由が「全員が使っているから」だけなら危険だ。更新が遅く、機能が過剰で、どのチームも責任を持っていない共通部品は、技術的な持ち合い株に近い。

ここで必要なのは、関係を疑うことではない。関係を定期的に再選択することである。選び直せない関係は、選んでいるように見えて、実際には過去の決定に従っているだけだからだ。

関係を資産に変えるための実践原則

では、組織はどのようにして、関係を拘束ではなく資産として扱えるのだろうか。鍵は、所有や共有を減らすことではなく、目的と境界を明確にすることである。

第一に、すべての重要な関係に「目的の一文」を与える。投資なら、「この保有によって何を可能にするのか」を書く。パッケージなら、「この共有によって誰のどの負担が減るのか」を書く。目的を書けない関係は、継続の判断もできない。

第二に、入口と出口を同時に設計する。投資を始めるときに売却条件を決め、パッケージを共有するときに分離の条件を決める。出口を考えることは、関係を冷たく扱うことではない。むしろ、終了の手続きが明確だからこそ、日常の協力に余計な不安が生じない。

第三に、隠れた依存を定期的に棚卸しする。会計では、長期間保有している有価証券を、現在の事業目的と照合する。開発では、依存グラフを確認し、変更の影響を受ける範囲と、実際には使われていない共有を調べる。

第四に、関係の外側に代替案を持つ。一社にしか売れない資産、一つのパッケージにしか依存できないサービス、一人の担当者しか理解していない業務は、見かけ上の効率と引き換えに、交渉力を失っている。代替案は、実際に使わなくても価値がある。手放せるという事実が、関係を対等にするからだ。

Key Takeaways

・資産や共有部品を評価するときは、利益だけでなく「手放せるか」を確認する

・すべての投資、提携、依存関係に、目的と終了条件を一文で設定する

・長く続いていることを、健全性の証拠ではなく再評価の合図として扱う

・共通化による効率と、変更の自由を失うコストを同時に計算する

・代替案を持つことで、関係を惰性ではなく選択として維持する

本当に強い組織は、結びつき方を選べる

資本主義において、所有は力の象徴と考えられがちだ。ソフトウェアにおいても、すべてを統合し、共通化し、中央で管理することが強さだと思われやすい。しかし、所有や統合の量が増えるほど、組織が強くなるとは限らない。

本当の強さは、関係を増やす能力ではなく、関係の形を選び直す能力にある。必要なときは深く協力し、必要でなくなれば摩擦を抑えて分離する。共有するものと、独立させるものを区別する。安定を享受しながら、安定のために自由を売り渡さない。

企業の有価証券も、ソフトウェアのパッケージも、単なる保有物ではない。それらは、組織がどの程度の依存を受け入れ、どの程度の自由を守ろうとしているかを映す鏡である。

持っているものの一覧表は、組織の過去を示す。いつでも手放せるものの一覧表は、組織の未来を示す。

次に資産台帳や依存関係を眺めるとき、数や金額だけを確認するのはやめよう。その一つ一つについて、こう問いかけるべきだ。

「これは私たちの選択肢を増やしているのか。それとも、過去の関係から抜け出せなくしているのか」

その問いに答えられる組織だけが、関係を資産に変え、変化の中でも自分の意思で動き続けられる。