はじめに
月曜日は経営会議。事業戦略を話す。
水曜日は技術戦略会議。アーキテクチャを話す。
金曜日は組織開発会議。チーム編成を話す。
それぞれの会議には、それぞれの参加者がいる。経営会議には経営陣。技術戦略会議にはエンジニアリングリーダー。組織開発会議には人事と各部門長。それぞれが、それぞれの言葉で、それぞれの関心事を語る。
私はいろんな立場でこれらの会議に呼ばれる。そして、いつも同じ違和感を覚える。
「この話、別の会議でも関係あるんじゃないの？」
言えない。言っても通じない。経営会議で「それ、アーキテクチャの話と関係ありませんか」と言っても、「それは技術の話だから水曜日に」と返される。技術戦略会議で「それ、組織の問題では」と言っても、「それは人事の話だから金曜日に」と返される。
きれいに分かれている。整然としている。効率的に見える。
分断は、様々な形をとって現れる。会議の分断。言葉の分断。評価指標の分断。事業部門は売上で評価される。技術部門はシステムの安定性で評価される。人事部門は採用数と離職率で評価される。それぞれが、自分のKPIを最適化しようとする。そのKPIが、会議を分け、言葉を分け、関心を分ける。
分断が最も激しくなる瞬間がある。計画変更のときだ。市場が変わった。競合が動いた。顧客のニーズが変化した。そのとき、事業戦略は変わる。しかし、技術戦略は変わらない。組織体制も変わらない。なぜか。計画変更は「誰かの責任」を問うことになるからだ。変更を認めると、最初の計画が間違っていたことになる。だから、誰も変更を言い出さない。計画通りに進めて、最後に「間に合いませんでした」と言う方が、傷が浅い。
分断が弱まる瞬間もある。危機のときだ。システムが落ちた。顧客からクレームが殺到した。そのとき、部門の壁は一時的に消える。全員が同じ部屋に集まり、同じ問題に向き合う。しかし、危機が去ると、また元に戻る。危機対応は例外であり、日常ではない。日常に戻れば、分断も戻る。
私は何度も見てきた。
月曜の経営会議で決まった「3ヶ月で新機能をリリースする」という事業戦略が、水曜の技術戦略会議で「今のアーキテクチャでは6ヶ月かかる」と判明する。金曜の組織開発会議で「その機能を作れるエンジニアがいない」と分かる。3つの会議で、3つの事実が、別々に語られる。しかし、誰も全体を見ていない。
分業には理由がある。効率だ。専門家が専門領域に集中できる。会議の時間は短くなる。責任は明確になる。組織が大きくなれば、分けなければ回らない。それは、正しい。
ここで、一つ認めておくべきことがある。分けることには、正当な理由がある。
「統合して議論する」は綺麗だ。しかし、関係者が増えるほど会議は重くなる。境界をまたぐ話は論点が多くなり、合意形成も難しくなる。「決められない組織」になるリスクがある。市場は待ってくれない。分けて速く回す方が勝つ局面は、確かにある。私も、全員参加の会議が延々と続いて何も決まらない組織を見てきた。あれを見ると、「分けた方がいいのでは」と思う気持ちは分かる。
さらに言えば、サイロには「心理的安全性の防波堤」としての機能もある。組織には「安心して話せる範囲」が必要だ。小さな範囲（サイロ）があるから、本音や問題が出る。越境を強制すると、政治が混ざって発言が萎縮し、かえって問題が隠れることがある。全員参加の場は、評価や立場を気にして「無難な話」になりがちだ。
だから、私が言いたいのは「分けるな」ではない。分けることの正当性は認める。「分けたまま、境界の情報を消すな」——これが、私の言いたいことだ。
——と書いて、自分でも分かっている。「境界の情報を消すな」と言うのは簡単だが、消さないためにどうするかが難しいのだ。
分業は必要だ。しかし、分業の効率は「誰にとっての効率か」を問う必要がある。会議運営は効率化される。意思決定者の認知負荷は下がる。しかし、その恩恵を受けるのは会議を設計する側であり、しわ寄せを受けるのは境界で仕事をする人々だ。調整コスト、手戻り、後から判明する「言ってくれれば」。これらは、分業の効率がもたらす隠れたコストだ。
しかし、その効率の代償として、境界の情報が消える。
消えるのは「事実」ではない。事実は、それぞれの会議で語られている。「3ヶ月で新機能を出す」は事実だ。「今のアーキテクチャでは6ヶ月かかる」も事実だ。「その機能を作れるエンジニアがいない」も事実だ。消えているのは、事実と事実をつなぐ「前提」と「代替案」だ。「この技術的制約があるから、この事業戦略は実行不可能だ」という前提。「機能を絞れば3ヶ月で出せる」という代替案。「採用が間に合わないなら、この部分は外注する選択肢もある」というリスク回避策。これらは、どの会議の議題にもならない。
境界情報が消えたことは、どうすれば分かるか。沈黙で分かる。会議で「他部門への影響は？」と聞いたとき、誰も答えられない。手戻りで分かる。開発が進んでから「これ、最初に言ってくれれば」と言われる。会議の往復で分かる。月曜に決まったことが、水曜に覆り、金曜にまた覆る。責任の押し付けで分かる。「それは技術の問題」「それは事業の判断」「それは人事の話」。押し付けが始まったら、境界情報が消えている証拠だ。
境界情報が生き残るケースもある。特定の人物が媒介しているときだ。複数の会議に出席し、それぞれの文脈を理解し、翻訳できる人。しかし、その人に依存すると、その人が異動したり退職したりすると、情報は途切れる。人ではなく、仕組みで残す必要がある。事業の会議で「技術的な制約と代替案」を議題に入れる。技術の会議で「事業インパクト」を必須項目にする。形式を変えなければ、境界情報は消え続ける。
事業の会議では技術の話は「水曜に」と先送りされる。技術の会議では組織の話は「金曜に」と先送りされる。誰の責任でもないから、誰も語らない。分けた瞬間に、最も大事な情報が抜け落ちている。
前回、私は「おい、戦略を語れ」と書いた。戦略とは「選択」であり、「何をやらないかを決めること」だと。目標を入れる。スローガンを入れる。希望を入れる。妥協を入れる。蓋を閉じて、「戦略」というラベルを貼る。それは戦略ではない、と。
しかし、書き終えてから気づいた矛盾がある。
「何をやらないかを決める」には、「何ができるか」を知らなければならない。技術的に可能なことを知らなければ、事業戦略は選択できない。組織の能力を知らなければ、実行可能性は判断できない。戦略を語るためには、事業・技術・組織を「分けて」考えてはいけなかったのだ。
今回は、その続きを書く。事業と技術と組織と戦略を、別々に語ることの危険性について。
これは、そういう自分への苛立ちから始まった文章だ。
私自身、無意識に分けていた。「事業のことは経営が決める」「技術のことは自分たちで決める」「組織のことは人事が決める」。それぞれの領分を侵さない。それが「プロフェッショナル」だと思っていた。
しかし、それは本当にプロフェッショナルだったのか。単に、考えることから逃げていただけではないか。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
「何をやるか」と「どうやるか」の分離
多くの組織で、こんな分業が成立している。
経営が「何をやるか」を決める。開発が「どうやるか」を決める。
事業戦略が「What」を定義し、技術戦略は「How」を担う。依存の矢印は「事業 → 技術」の一方向。経営会議で方針が決まり、それが開発チームに「降りてくる」。開発チームは、降りてきた仕様を実装する。
きれいな分業だ。責任が明確だ。経営は経営の仕事をする。開発は開発の仕事をする。
この分業が成立する前提がある。経営が「Howは後で決めればよい」と信じていることだ。Whatさえ決まれば、Howは技術者がなんとかする。技術は手段であり、事業の下流にある。そう信じている。
技術側にも、この分業を受け入れる理由がある。Whatを所与として受け取る方が、楽だからだ。事業戦略に口を出せば、責任が生じる。「仕様通りに作りました」と言えば、失敗しても言い訳できる。Whatに関与しないことは、責任回避の手段でもある。さらに、評価制度がこれを強化する。技術者は「技術的な成果」で評価される。事業への貢献は、評価項目に入らないことが多い。
しかし、この前提には反例がある。
技術発で市場を作るケースだ。iPhoneは「タッチスクリーンでアプリが動く」という技術的可能性が、事業を規定した。AWSは「サーバーを時間単位で借りられる」という技術が、クラウドビジネスを生んだ。Howが先にあり、Whatが後から来た。
組織能力が先に制約になるケースもある。「AIを活用したパーソナライゼーション」という戦略があっても、データサイエンティストがいなければ実行できない。Whatを先に決めても、Howの制約で実現不可能になる。
「What → How」の一方向モデルは、現実を単純化しすぎている。
そして、この単純化には実害がある。この分業は、組織の可能性を無意識に狭めている。
なぜか。「どうやるか」が「何ができるか」を規定するからだ。
例を挙げよう。
あるプロダクトチームで、新機能の開発が議論されていた。経営会議で「この機能を3ヶ月で出す」と決まった。開発チームに降りてきた。しかし、開発チームは頭を抱えた。今のアーキテクチャでは、その機能を追加するのに6ヶ月かかる。密結合なモノリスで、特定の部分だけを変更することが難しい。
開発チームは「3ヶ月は無理です、6ヶ月かかります」と報告した。経営は「なんとかしろ」と言った。開発チームは無理をした。品質を犠牲にした。技術的負債が積み上がった。次の機能追加は、さらに時間がかかるようになった。
これは、珍しい話ではない。むしろ、日常的に起きている。
問題は、どこにあるのか。開発チームの能力不足か。経営の無理解か。どちらでもない。問題は、「何をやるか」と「どうやるか」を分けて考えたこと自体にある。
もし、アーキテクチャがモジュール化されていたら。特定の機能を切り出して、独立して開発できる構造になっていたら。3ヶ月で出せたかもしれない。あるいは、1ヶ月で出せたかもしれない。
つまり、技術的な選択が、事業の選択肢を規定している。
逆もまた真だ。技術が事業を規定するだけでなく、事業の方向性が、技術的な選択を正当化する。
「このセグメントの顧客を取りに行く」という事業判断があるからこそ、「この部分をマイクロサービスとして切り出す」という技術判断が意味を持つ。事業の方向性なしに技術判断だけがあると、「なぜそのアーキテクチャなのか」が説明できない。
事業と技術は、双方向に影響し合っている。一方向の依存関係ではない。
私は以前、この双方向性を無視した組織をいくつか見てきた。どれも同じパターンに陥る。
アーキテクトがアーキテクチャを設計する。マネージャーが組織を設計する。それぞれが、それぞれの会議で、それぞれの論理で。アーキテクトは「理想的なシステム構成」を描く。マネージャーは「効率的なチーム編成」を考える。両者が同席することはない。
数ヶ月後、問題が起きる。チームAとチームBが、同じコードベースに手を入れる必要が出てくる。しかし、チームは別の部門に所属している。コミュニケーションパスがない。マージコンフリクトが頻発する。リリースの調整に時間がかかる。「なぜこんなことになったのか」と誰かが問う。答えは単純だ。組織の設計とアーキテクチャの設計が、別々に行われたからだ。
コンウェイの法則を知っている人は多い。「組織構造がアーキテクチャに影響する」。私も何度も引用してきた。しかし、知っていることと、実践することは違う。私自身、何度もこの法則を引用しておきながら、組織設計に口を出すことは避けてきた。「それは自分の領域ではない」と。結果、アーキテクチャの提案が実装されないまま終わることが何度もあった。組織が変わらなければ、アーキテクチャは変わらない。当たり前のことだ。しかし、その当たり前を、私は見て見ぬふりをしていた。
戦略と組織能力の不可分性
同じ問題が、戦略と組織の間にもある。
多くの企業が「何をやるか（戦略）」を先に決め、「誰がどうやるか（組織能力）」を後回しにする。
戦略会議で、美しいスライドが映し出される。「我々は、AIを活用した次世代プラットフォームを構築する」。参加者はうなずく。ビジョンは明確だ。方向性は正しい。
しかし、誰がそれを作るのか。今の組織に、その能力があるのか。ない場合、どうやって獲得するのか。採用か。育成か。外部委託か。それには、どれくらいの時間がかかるのか。
これらの問いは、戦略会議では議論されない。「それは人事の話だから」と先送りされる。
結果、戦略は「願望」に留まる。実行可能性を欠いた計画になる。
私も、同じ過ちを犯したことがある。あるプロジェクトの戦略会議で、私は組織能力の話を一切しなかった。「それは人事部門の仕事だ」と思っていた。技術的には正しい方向だった。市場分析も悪くなかった。しかし半年後、プロジェクトは頓挫した。実行する人がいなかったのだ。戦略は正しかった。ただ、誰もそれを実現できなかった。
これは、戦略と呼べるものではない。願望だ。「こうなったらいいな」を紙に書いただけだ。「誰が、どうやって、いつまでに」を書けないものは、戦略ではなく詩だ。良い戦略には、実行可能性が組み込まれている。「何をやるか」と「誰がどうやるか」は、同時に議論されなければならない。
さらに厄介なのは、事業領域によって必要な組織能力が根本的に異なることだ。
例えば、エンタープライズSaaSと、HRソリューションを考えてみよう。どちらも「SaaS」だ。しかし、勝ち方が違う。
エンタープライズSaaSでは、競合との機能差が短期間で縮まる。だから、高速な同質化が勝敗を分ける。競合が出した機能を、素早く追随する。実装スピードが命だ。必要なのは、高速に開発できるエンジニアリング組織だ。
一方、HRソリューションでは、顧客データを活用した差別化提案が価値の源泉になる。データサイエンスや顧客理解の深さが求められる。必要なのは、データを扱える人材と、顧客の業務を深く理解するドメインエキスパートだ。
同じ「SaaS」でも、必要な開発スタイル、営業モデル、採用すべき人材像が根本的に異なる。
戦略を語るなら、組織能力を語らなければならない。逆に、組織能力を語るなら、戦略を語らなければならない。
私はかつて、ある企業の「AI戦略」を聞いたことがある。美しいスライドだった。「機械学習を活用してパーソナライゼーションを強化する」。しかし、その会社にはデータサイエンティストが一人もいなかった。「採用する予定です」と言っていた。一年後、まだ一人も採用できていなかった。戦略だけがあって、実行する能力がない。それは戦略ではない。絵に描いた餅だ。
内製か外注かという問いの本質
「内製すべきか、外注すべきか」。この問いも、事業・技術・組織を分けて考えると、間違った答えを出しやすい。
技術の視点だけで考えると、「今のチームにその技術がないから、外注しよう」となる。合理的に見える。今持っていない能力を、外部から借りる。効率的だ。
しかし、外部委託は「今持っていない能力を一時的に借りる」行為だ。短期的な補完にすぎない。
問題は、勝ち筋を支える中核能力は、外部から買えないことだ。
中核能力（コアコンピタンス）は、試行錯誤を通じて組織に蓄積される。失敗から学び、改善を重ね、暗黙知が形成される。
外注で失われるのは「何をしたか」ではない。コードを見れば「何をしたか」は分かる。失われるのは「なぜそうしなかったか」の記憶だ。
例えば、「なぜこのAPIはRESTではなくgRPCにしたのか」。コードを見れば「gRPCを使っている」ことは分かる。しかし、「最初はRESTで作ったが、レイテンシ要件を満たせず、2週間かけてgRPCに移行した」という経緯は、ドキュメントには残りにくい。「RESTでも工夫すれば動いたが、将来のスケーラビリティを考えてgRPCにした」という判断の背景は、人の頭にしか残らない。外注先の担当者が変わったとき、この記憶は消える。次に同じ判断を迫られたとき、組織はまた2週間を失う。
「今回は外注で」を繰り返すと、何が起きるか。組織の中に何も残らない。プロジェクトは完了する。成果物は納品される。しかし、それを作る能力は、組織の中にない。次に同じようなことをやろうとすると、また外注することになる。
これは、競争優位の源泉を自ら手放していることに等しい。
もちろん、すべてを内製する必要はない。競争優位に関係ない部分は、外注でいい。しかし、「この能力が勝ち筋を支える」と判断したなら、時間がかかっても内製すべきだ。
この判断をするには、事業戦略と技術戦略と組織戦略を、同時に見る必要がある。
では、「同時に見る」とは具体的にどういうことか。ここで参考になるのが、ドメイン駆動設計の考え方だ。「一緒に変わる概念は、一緒にしておけ」。新機能を追加する際、どの概念が連動して変化するか。それらを1つのまとまりとして整理すると、それがドメインになる。逆に言えば、一緒に変わる概念を別々のチームに分けると、調整コストが爆発する。
- 事業戦略：どの市場で、どう勝つのか
- 技術戦略：そのためにどんな技術的優位性が必要か
- 組織戦略：その優位性を支える能力を、どう構築・維持するか
これら3つは、一緒に変わる。事業戦略が変われば、技術戦略も変わる。技術戦略が変われば、必要な組織能力も変わる。一緒に変わるものを、別々の会議で、別々の人が議論していては、正しい判断はできない。
技術が事業の選択肢を創出する
技術の側から見ると、この関係はより具体的に見える。優れたアーキテクチャは、事業の選択肢を増やす。
例えば、こんな状況を考えてみてほしい。
競合が新機能をリリースした。市場が反応している。うちも追随したい。普通なら半年かかる開発だ。しかし、うちのシステムはモジュール化されている。既存のモジュールを組み合わせれば、1ヶ月で検証できる。
これは、技術的な選択が、事業の機動性を生んでいる。
別の例。
ある顧客セグメント向けに、機能を絞った廉価版を出したい。普通なら、別プロダクトとして作り直す必要がある。しかし、うちのシステムは機能がモジュール化されている。特定のモジュールだけを切り出して、別プランとして販売できる。
これは、技術的な選択が、事業モデルの柔軟性を生んでいる。
逆に、技術的負債が蓄積すると、事業の選択肢が狭まる。
新機能を追加したい。しかし、コードが複雑すぎて、どこを触ればいいか分からない。影響範囲が読めない。テストがない。触ると壊れる。結果、機能追加のコストが指数関数的に増大する。
「やりたいけど、できない」が増えていく。事業の選択肢が、技術的負債によって奪われていく。
では、アーキテクチャとは何のためにあるのか。「コードを綺麗にする」ためではない。「事業の機動性を高める」ための戦略的投資だ。
ただし、「機動性」という言葉は曖昧だ。事業側が腹落ちするには、もっと具体的に語る必要がある。
事業側に説明するとき、「モジュール化しました」では伝わらない。「この投資によって、競合が新機能を出したとき、追随までの期間が6ヶ月から2ヶ月に縮まります」と言えばいい。「この機能を落としたとき、他に影響が出ないので、撤退判断が3ヶ月早くできます」と言えばいい。時間の話をする。機会損失の話をする。撤退の容易さの話をする。経営が理解できる言葉で語る。
——と書いて、立ち止まる。これは本当だろうか。私はこれまで、事業の言葉で語ってきただろうか。「このコードは密結合で」「テストカバレッジが低くて」と言い続けてきたのではないか。分かりやすく整理しているが、自分ができていなかったことを、さも正解のように語るのは、どうなのか。
それでも、書く。できていなかったからこそ、書く。
この視点がないと、アーキテクチャの議論は「技術者の自己満足」に見えてしまう。経営からすると、「なぜそんなことに時間をかけるのか」となる。技術的負債の返済は後回しにされる。結果、事業の選択肢がどんどん狭まる。
忘れられない言葉がある。以前、一緒に仕事をしたCEOが言った。「エンジニアはみんな潔癖性だ。いつも技術的負債だの、システムの書き直しだのと言っている」。
正直、腹が立った。しかし、同時に、自分のことを言われている気もした。
私は技術的負債の説明をするとき、どんな言葉を使っていただろうか。「このコードは密結合で」「テストカバレッジが低くて」「デプロイパイプラインが」。技術者には通じる。しかし、経営者には通じない。通じないどころか、「また技術の話か」と思われていたかもしれない。
そのCEOの言葉は、不当だった。しかし、そう思われてしまう構造を作ったのは、私たちでもある。「技術的負債を返済すると、機能追加のスピードが2倍になります」と言えばよかった。「このリファクタリングで、新規市場への参入が3ヶ月早まります」と言えばよかった。技術の話を、事業の言葉で語る。それができていなかった。
技術と事業を分けて考えているから、こうなる。いや、違う。私が、分けて語っていたから、こうなった。
現場が握る「隠れた変数」
ここまで、組織のレイヤーで話をしてきた。しかし、組織が動くのは、個人が動くからだ。組織構造を変えても、個人が動かなければ、何も変わらない。次は、個人のレイヤーで話をしよう。
現場でコードを書くエンジニアは、プロダクトの「手触り」を一番知っている。
「今のアーキテクチャなら、実はこんな機能も低コストで実現できる」
「これだけのものを作るには、一度基盤を整備してから一気に作ったほうが速い」
「この部分を先に切り出しておけば、将来の拡張が楽になる」
これらは、経営会議では見えない。事業戦略のスライドには載らない。現場だけが知っている「隠れた変数」だ。
しかし、多くのエンジニアは、これを声に出さない。
「事業のことは経営が決めること」
「自分の仕事は、決まった仕様を実装すること」
「事業戦略に口を出すのは、越権行為だ」
無意識に、自分の領分を技術領域に限定してしまう。事業戦略を「所与のもの」「固定された定数」と捉えてしまう。
しかし、現場からのインサイトが、経営会議の決定をひっくり返すべき場面がある。
「その機能、今のアーキテクチャだと6ヶ月かかりますが、この部分を先にリファクタリングすれば、3ヶ月で出せます。しかも、その後の機能追加も速くなります」
これは、事業判断を変えうる情報だ。しかし、エンジニアが「自分の仕事は実装だけ」と思っていたら、この情報は経営に届かない。
エンジニアが技術戦略を磨くことは、経営に対して「このルートならもっと速く、高く登れる」という登山ルートを提案することだ。
降りてきた仕様をこなすだけの存在ではない。事業の未来を提案する「シンクタンク」であり、それを最速で形にする「実行部隊」だ。
しかし、この意識を持つことは、簡単ではない。なぜなら、「実装担当」に留まる方が、楽だからだ。
私自身、長い間「実装担当」に留まっていた。事業戦略は「上」が決めるもの。自分の仕事は、降りてきた仕様を高品質に実装すること。そう思っていた。なぜか。その方が楽だからだ。事業戦略に口を出さなければ、責任を取らなくていい。「仕様通りに作りました」と言えば、失敗しても自分のせいではない。
しかし、その「楽さ」には代償がある。自分の仕事の意味を、他人に委ねることになる。「なぜこれを作るのか」を自分で理解していないまま、コードを書く。モチベーションが上がらない。「作れと言われたから作った」。それは、職人の仕事ではない。
ある時期から、変えようとした。事業戦略の文書を読むようになった。経営会議の議事録を見せてもらうようになった。「なぜこの機能が必要なのか」を、実装前に質問するようになった。最初は煙たがられた。「エンジニアがビジネスに口を出すな」という空気を感じたこともある。
しかし、続けていると、変わってくる。「この機能、技術的にはこうすればもっと早く出せますが、どうしますか」という会話ができるようになる。事業判断に、技術的な選択肢を提供できるようになる。降りてくる仕様を待つ存在から、仕様を一緒に作る存在に変わる。
エンジニア以外にも当てはまる
ここまでエンジニアの話をしてきた。しかし、「現場の知見が経営に届かない」という構造は、エンジニアに限った話ではない。専門性を持つ人が、その専門性ゆえにサイロに閉じ込められる。この構造は、あらゆる専門職に当てはまる。
デザイナーの話をしよう。私が一緒に仕事をしたデザイナーに、Aさんという人がいた。Aさんは、ある機能のモックを見た瞬間、「これ、誰も使わないですよ」と言った。私は「なぜ分かる」と聞いた。「導線が3クリック深い。離脱します」。
彼女は正しかった。リリース後、その機能の利用率は5%だった。しかし、Aさんはその機能の企画会議に呼ばれていなかった。「UIの話は後で」と言われていたのだ。後で呼ばれたときには、もう要件は固まっていた。Aさんにできたのは、決まった要件を「見やすく」することだけだった。本質的な導線の問題は、触れられなかった。
PMも、セールスも、カスタマーサクセスも、同じ構造の中にいる。それぞれが、顧客や市場の「手触り」を知っている。しかし、その知見が意思決定の場に届くことは稀だ。届いたとしても「参考情報」として扱われ、決定を覆すことはない。
専門性を持つ人が、事業戦略に影響を与えられる。これが、本質的な構造だ。しかし、多くの組織では、専門性が「サイロ」に閉じ込められている。デザイナーはデザインの会議に出る。PMはPMの会議に出る。それぞれが、自分の領域だけを語る。経営会議には呼ばれない。呼ばれたとしても、「報告」のためだ。「意思決定」のためではない。
分けているから、全体が見えない。見えている人の声が、届かない。
不確実性を飼いならすための対話
事業と技術と組織を統合して考える理由は、もう一つある。不確実性への対処だ。
どんな計画も、想定通りには進まない。
技術的な挑戦には、不確実性がつきまとう。「想定より時間がかかる」「パフォーマンスに問題が出る」「思った通りに動かない」。これらは、避けられない。
問題は、この不確実性が顕在化したときに、どう対処するかだ。
事業と技術を分けて考えていると、こうなる。
技術側で問題が起きる。開発が遅れる。技術チームは「なんとかします」と言う。無理をする。品質を犠牲にする。それでも間に合わない。最後の最後で「すみません、間に合いません」と報告する。事業側は怒る。「なぜもっと早く言わなかったんだ」。
これは、フィードバックループが壊れている状態だ。
あるべき姿は、こうだ。
技術側で問題が起きる。その事実を、即座に事業側にフィードバックする。「この技術的課題があります。対処には追加で2ヶ月かかります」。事業側は、その情報を受けて、戦略を再検討する。「2ヶ月遅れるなら、機能を絞って先に出そう」「このセグメントは後回しにして、別のセグメントを先に取りに行こう」。
技術の不確実性が、事業戦略を動的に更新する材料になる。
私が見てきた中で、うまく機能していたフィードバックループには、ある傾向があった。問題が判明したら、「なんとかなるかもしれない」で抱え込まずに、早めに共有していた。中間管理職を経由すると情報が歪むので、技術リーダーが直接、事業の意思決定者に伝えていた。「遅れます」だけでなく、理由と代替案もセットで。
——もっとも、これがどの組織でも通用するかは分からない。「直接伝える」が政治的に難しい組織もある。それでも、報告した人を責めない文化がなければ、どんな仕組みも機能しない。「遅れます」と言った人を責めた瞬間、次から「遅れます」は聞けなくなる。責めるほど、嘘が増える。
これは、事業側にも当てはまる。市場環境が変わる。競合が予想外の動きをする。顧客のニーズが変化する。これらの情報は、技術側の優先順位を変えうる。「この機能は後回しでいい。代わりに、こっちを急いでほしい」。
計画は「確定したもの」ではない。「継続的に更新されるもの」だ。
しかし、実際には多くの組織が計画を「約束」として扱う。「3ヶ月後にリリースすると言ったじゃないか」。この言葉が出た瞬間、計画は更新できなくなる。変えることは「約束を破ること」だから。分けて考えていると、それぞれが自分の計画を守ろうとする。変化に抵抗する。結果、組織全体が硬直化する。
「計画＝約束」になってしまうのは、なぜか。
一つは評価制度だ。「計画通りに達成したか」で評価される。計画を変更すると、達成率が下がる。だから、変更を避ける。計画通りに進めて、最後に「外部要因で達成できませんでした」と言う方が、評価上は有利になる。
もう一つは顧客へのコミット構造だ。「この機能を3ヶ月後に提供します」と顧客に約束している。変更すると、顧客との信頼関係に影響する。だから、社内の計画変更が許されない。
さらに文化の問題もある。「一度決めたことは守る」が美徳とされる組織では、計画変更は「意志が弱い」と見なされる。合理的な理由があっても、変更を言い出しにくい。
これらを変えるには、評価制度を「計画通り」ではなく「成果」で評価する。顧客へのコミットを「機能」ではなく「価値」でする。文化として「計画変更は適応であり、失敗ではない」と認める。簡単ではないが、ここが変わらないと、フィードバックループは機能しない。
分離が生む「責任の空白地帯」
分けて考えることには、もう一つの弊害がある。責任の空白地帯が生まれる。
こんな状況を想像してほしい。
新プロダクトがローンチした。しかし、売れない。
事業側は言う。「プロダクトの品質が悪い。技術の責任だ」。
技術側は言う。「要件が曖昧だった。事業の責任だ」。
組織側は言う。「人が足りなかった。採用が追いつかなかった」。
誰も責任を取らない。責任が、部門の境界に落ちている。
責任の空白地帯は、悪意から生まれるのではない。制度が再生産している。
KPIを見てほしい。事業部門は売上で評価される。技術部門はシステムの安定性で評価される。「事業と技術の連携」を評価する指標は、どこにもない。予算も同じだ。事業予算と技術予算は別に管理される。「境界をまたぐ問題」に使える予算は、どちらの予算からも出しにくい。稟議も同じだ。事業の稟議と技術の稟議は、別のルートを通る。「両方に関わる案件」は、どちらのルートでも通りにくい。
空白地帯で起きる典型的な現象がある。なすりつけ——「それは技術の問題だ」「いや、要件が曖昧だった」。回避設計——対話を避けるために、技術的な回避策を作る（後述するフロントエンドチームのように）。冗長な仕組み——同じ情報を、事業用と技術用に別々に管理する。二重管理——両方の部門が同じことを別々にやる。
私が技術顧問として入った、ある会社の話をしよう。
その会社には、二つのチームがあった。ユーザー向けのウェブサイトを担当するフロントエンドチーム。社内向けAPIを運用するプラットフォームチーム。フロントエンドチームはマーケティング部門に所属していた。プラットフォームチームはIT部門に所属していた。部門が違う。上司が違う。KPIも違う。
両チームの関係は、最悪だった。会話がない。Slackのやりとりも最小限。必要なときだけ、冷たいチケットが飛ぶ。私は最初、技術的な問題だと思っていた。APIが遅い。エラーが多い。パフォーマンスチューニングをすれば解決する、と。
しかし、掘り下げていくと、違った。問題は、技術ではなく、人間関係だった。
発端は、一年前のインシデントだった。ウェブサイトがダウンした。原因はAPIの障害。しかし、経営陣はフロントエンドチームを責めた。「なぜ監視していなかったのか」「なぜ障害を検知できなかったのか」。プラットフォームチームには、何も言わなかった。
フロントエンドチームは、怒った。自分たちのせいではない。しかし、責められた。プラットフォームチームとは、もう協力したくない。そこで、彼らは技術的な解決策を選んだ。APIからデータを抽出し、自分たちのデータベースに保存する仕組みを作った。「あいつらに依存しなければ、責められずに済む」。
私は、その設計図を見て、頭を抱えた。データの同期処理。キャッシュの整合性チェック。障害時のフォールバック。複雑なシステムが、一枚の紙に描かれていた。これは、技術的な解決策ではない。人と話したくないから、システムを複雑にしているだけだ。
案の定、問題は悪化した。データの不整合が起きる。「商品の価格がウェブサイトと管理画面で違う」というクレームが来る。フロントエンドチームは「プラットフォームチームのデータがおかしい」と言う。プラットフォームチームは「フロントエンドの同期処理がおかしい」と言う。責任のなすり合い。問題の根本は、誰も見ていない。
私は、両チームのリーダーを同じ部屋に呼んだ。最初は気まずかった。しかし、一時間ほど話していると、お互いの不満が見えてきた。フロントエンドチームは「APIが遅いから、ユーザー体験が悪くなる。それで自分たちが責められる」と言った。プラットフォームチームは「APIの改善を提案しても、予算がつかない。経営はフロントエンドばかり見ている」と言った。
両チームとも、被害者意識を持っていた。そして、その被害者意識が、アーキテクチャに反映されていた。話したくないから、システムを分ける。責任を取りたくないから、境界を作る。その結果、システムは複雑になり、問題が増え、さらに話したくなくなる。悪循環だ。
これは、分けて考えることの必然的な帰結だ。
私はこのエピソードを振り返るたびに、あるパターンに気づく。両チームとも、悪意があったわけではない。むしろ、それぞれが合理的に行動した結果、全体としてはうまくいかなくなった。
これは、私だけが見た現象ではない。組織論では「構造的無能化」と呼ばれる。組織の考えたり実行したりする能力が、合理的に下がっていく現象だ。成熟した組織にとって、ほとんど宿命のようなものだ。
そのメカニズムはこうだ。まず断片化が起きる。分業化が進み、縦割りになる。次に不全化が起きる。変化の兆しを察知しても、自分の領域ではないから動けない。最後に表層化が起きる。問題の根本に手を付けられず、場当たり的な対応を繰り返す。
フロントエンドチームがデータベースを作ったのは、まさにこの表層化だ。根本的な解決（チーム間の対話）を避け、技術的な回避策（自前のDB）を選んだ。
事業戦略は事業部門の責任。技術戦略は技術部門の責任。組織戦略は人事部門の責任。それぞれが、自分の領域だけに責任を持つ。
しかし、成果は、領域の境界で生まれる。
プロダクトが売れるかどうかは、事業戦略だけでは決まらない。技術戦略だけでも決まらない。組織戦略だけでも決まらない。三つが噛み合って、初めて成果が出る。
分けて考えていると、この「噛み合わせ」に誰も責任を持たない。それぞれが自分の領域を最適化しようとする。しかし、部分最適の総和は、全体最適にならない。
さらに、分けることは認知負荷を増やす。私がよく見るのは、本来は不要な調整、整合性の確認、コミュニケーションのオーバーヘッドだ。フロントエンドチームがプラットフォームチームと話すためだけに、週に2時間の会議を設定する。その会議で話す内容は、同じチームなら5分で済む。分けたことで、本質的でない仕事が増える。
では、誰が全体を見るのか。CEOか。CTOか。プロダクトマネージャーか。私の経験では、肩書きは関係なかった。大事なのは「誰が」ではなく「どうやって」だった。全体を見る「人」を任命するより、全体を見る「機会」を作る方が効果的だった。むしろ、肩書きに頼ると失敗する。「それはCTOの仕事だ」「それはCEOが考えること」。そう言って誰も動かない組織を、何度も見てきた。
私が見た中でうまくいっていた組織には、一つの習慣があった。
月曜の朝会で、各チームが「先週、他チームから聞いた話」を30秒で共有する。「営業チームから聞いたんですが、顧客がこの機能の使い方で困っているらしいです」「インフラチームから聞いたんですが、このAPIの負荷が想定の3倍らしいです」。内容は何でもいい。「他チームから聞いた」という形式が重要だ。強制的に越境させる。
最初は形式的だった。「特にありません」で済ませる人もいた。しかし、3ヶ月ほど続けると変わってくる。「あ、それ、前に営業の人が言ってましたよね」という会話が、会議の外で自然に生まれる。6ヶ月後には、「他チームから聞いた話」を集めるために、意識的に他チームと話すようになる。
全体を見る「人」を任命するより、全体を見る「機会」を作る方が、よほど効果的だった。
ここで、一つの反論に答えておきたい。「統合しても、責任は明確にならず、むしろ曖昧になるのではないか」という懸念だ。
これは、正しい。
統合すると「みんなで決めた」になって、誰も責任を取らない別種の無責任が生まれる。「合議の免責」だ。境界があると「ここから先はこの責任者」と決めやすい。統合は、その明確さを失わせる。私が見てきた組織でも、「全員で議論して、全員で決めた」結果、うまくいかなかったとき誰も責任を取らなかったケースがある。
だから、越境と責任の明確化は、両立させなければならない。統合して議論するが、決定は一人が行う。「みんなで決めた」ではなく、「みんなの情報をもとに、この人が決めた」にする。——言うのは簡単だ。しかし、これを実践するのは難しい。最終決裁者を決めると、「自分の意見が通らなかった」と不満を持つ人が出る。合議の方が、波風が立たない。だから、組織は合議に流れる。
それでも、誰かが決めなければならない。決めた人が責任を持つ。これを曖昧にすると、分断と同じ問題が起きる。
越境するということ
では、どうすればいいのか。自分の領域を超えて、考える。発言する。それぞれが、自分の専門性を持ちながら、他の領域にも関心を持つ。
これは、「全員がゼネラリストになれ」という話ではない。専門性は維持したまま、境界を越えて対話するということだ。
ここで、よくある誤解に触れておきたい。越境を推しすぎると、専門性が薄まるのではないかという懸念だ。全員が「半分だけ分かる人」になり、技術の判断が雑になり、事業の理解が単純化され、組織の問題はスローガン化する。
この懸念は正当だ。私自身、越境を意識するようになってから、技術の深い部分に割く時間が減った気がする。最新のフレームワークを追う余裕がなくなった。コードを書く時間が減った。「全体を分かる」ことと「専門が深く鋭い」ことは、トレードオフの関係にある。両方を同時に極めることはできない。
だから、越境とは「専門性を捨てる」ことではない。エンジニアがビジネスを学ぶのは、ビジネスの専門家になるためではない。自分の技術的判断を、ビジネスの文脈で説明できるようになるためだ。2割の時間で、他の領域で何が起きているかを知る。それだけで、残り8割の専門領域の判断が変わる。
——と言いながら、私は本当に8:2でやれているだろうか。正直、分からない。越境に時間を使いすぎて、技術の深さが失われていないか。その不安は、常にある。
私が見てきた中で、うまくいっているチームは「独立」と「孤立」を混同していなかった。自分たちで決められることは自分たちで決める。しかし、他チームとの依存関係は認識している。必要なときは、ちゃんと話す。分けることは、孤立させることではない。依存関係を認識し、意図的に管理することだ。問題は、分けた瞬間に依存関係を忘れてしまうことにある。
エンジニアは、エンジニアリングの専門家であり続ける。しかし、その専門性を、事業の文脈で語れるようになる。「このアーキテクチャは技術的に美しい」ではなく、「このアーキテクチャは事業の機動性を高める」と語る。
事業担当は、ビジネスの専門家であり続ける。しかし、技術的な制約と可能性を理解する。「なぜできないのか」ではなく、「どうすればできるのか」を一緒に考える。
ただし、ここで一つ注意がある。
「越境」と聞くと、「相手の言葉で話せばいい」と考えがちだ。技術者なら経営の言葉を学び、経営者なら技術の言葉を学ぶ。それ自体は悪くない。しかし、「すべてを一つの言葉に翻訳しろ」と言っているのではない。
すべてを財務言語や経営の言葉に翻訳すると、技術的な微妙なニュアンスが失われる。「このAPIのレイテンシが50msから200msに悪化する」を「ユーザー体験が悪化する」と翻訳すれば、経営には通じるかもしれない。しかし、50msと200msの差がどれほど深刻か、どのユースケースで問題になるか、という技術的な判断の根拠は消える。
組織の話も同じだ。「チームの心理的安全性が低い」を「生産性が下がっている」と翻訳すれば、経営指標には載る。しかし、なぜ安全性が低いのか、誰と誰の間に問題があるのか、という組織特有の文脈は失われる。
事業の話も同じだ。「この顧客セグメントは価格感度が高い」を「値下げすれば売れる」と翻訳すれば、技術チームには分かりやすい。しかし、なぜ価格感度が高いのか、競合との関係はどうか、という市場の文脈は消える。
翻訳は、情報を圧縮する行為だ。圧縮すれば、必ず何かが失われる。
翻訳で失われてはいけない情報がある。判断の根拠だ。「このAPIは遅い」は翻訳できる。「ユーザー体験に影響がある」と。しかし、「なぜ遅いのか」「どのユースケースで問題になるのか」「どうすれば速くなるのか」という判断の根拠は、翻訳で消えやすい。
翻訳の失敗には典型パターンがある。数値の意味が変わる——「50msから200msに悪化」が「ちょっと遅くなる」に翻訳される。因果が消える——「テストがないからリリースに時間がかかる」が「リリースが遅い」に短縮される。責任が曖昧になる——「この設計判断には、こういうトレードオフがあった」が「技術的な事情」に丸められる。
対策は二重記録だ。経営向けの短い翻訳と、技術や組織の原文脈を、両方残す。経営会議の資料には「ユーザー体験に影響がある」と書く。同時に、技術的な詳細は別のドキュメントに残し、参照できるようにする。翻訳は「圧縮」だが、原文を捨てる必要はない。「詳細はこちら」というリンクがあればいい。
だから、越境とは「自分の言葉を捨てて、相手の言葉で話す」ことではない。自分の言葉を保ちながら、相手の言葉も理解することだ。技術者が経営の言葉を学ぶのは、自分の技術的判断を捨てるためではない。技術的判断を、経営が理解できる形で伝えるためだ。そして同時に、経営の言葉で語られた制約を、技術的な文脈に引き戻して考えるためだ。
専門性を持った人たちが、それぞれの専門性をリスペクトしながら、共通のゴールに向かって越境し合う。それは、言語を統一することではない。複数の言語が交差する場所で、対話することだ。
私はあるとき、同じ会議で同じ資料を見ていたエンジニアと営業が、まったく違う結論を出すのを見た。エンジニアは「これは技術的に難しい」と言い、営業は「これは売れる」と言った。同じ資料だ。同じ数字だ。しかし、見えている世界が違う。
それぞれが、自分の専門性に基づいた「解釈の枠組み」で見ている。エンジニアはコードの複雑さを見ている。営業は顧客の反応を見ている。どちらも正しい。しかし、見ているものが違う。
組織の中で起きている「わかりあえなさ」は、この解釈の枠組みの間に溝ができていて、しかもそのことに気づいていない状態だ。溝があることに気づかないから、「なぜ分からないんだ」「なぜ伝わらないんだ」と苛立つ。
対話とは、溝を埋めることではない。溝に橋を架けることだ。溝は前提としてあり続ける。エンジニアと営業の見ている世界は、完全には一致しない。しかし、橋があれば、行き来できる。相手の世界を訪れ、自分の世界に戻ってくる。その往復が、越境だ。
情報が流れる仕組み
「越境せよ」と言うのは簡単だ。しかし、越境するには材料がいる。相手の世界で何が起きているかを知らなければ、質問も提案もできない。越境するためには、情報が流れる仕組みが必要だ。
多くの組織で、情報は縦に流れる。経営から現場へ。現場から経営へ。しかし、横には流れにくい。
技術チームで起きていることは、事業チームには見えない。事業チームで議論されていることは、技術チームには届かない。それぞれが、自分のサイロの中で仕事をしている。
これを変えるには、意図的な設計が必要だ。
ここで、別のアプローチに触れておきたい。「常に一緒に話す」のではなく、境界を前提にしたインターフェース（契約）を設計すればいいのではないかという考え方だ。
依存関係は消せない。ならば、「越境」より「情報の受け渡しの形式化」を磨くべきだ、という主張だ。制約（SLO、人員、期限）を明文化し、変更時の通知ルールを作る。「同席して統合」より「契約で連携」の方がスケールする、と。
この考え方には一理ある。いや、一理どころか、実際に機能している組織を見てきた。境界を明確にし、インターフェースを定義し、変更時の通知ルールを作る。日常的な連携は、これで十分だ。私自身、あるプロジェクトでAPI仕様書とSLOを明文化しただけで、チーム間の調整コストが激減するのを見た。
ただ——問題は、インターフェースに書かれていない依存関係が発見されたときだ。
「この事業判断が、技術に影響するとは思っていなかった」。そういう場面で、インターフェースは機能しない。「期限が1ヶ月延びました」という通知は届く。しかし、「なぜ延びたのか」「その延長が事業にどう影響するのか」は、インターフェースでは伝わらない。契約に書かれていない依存関係は、対話でしか発見できない。
だから、どちらか一方ではない。日常的にはインターフェースで効率的に連携し、境界をまたぐ問題が発生したときや、計画変更があったときには、対話で補う。当たり前のことを言っているように聞こえる。しかし、この「当たり前」ができている組織は、驚くほど少ない。
では、私自身はどうだったか。
ある会社で、技術戦略会議に事業担当を呼んでもらったことがある。最初は「技術の話だから関係ない」と言われた。しかし、「アーキテクチャの選択が、3ヶ月後の機能追加速度に影響します」と説明したら、参加してくれた。その会議で、事業担当は「そんなに影響があるとは知らなかった」と言った。私は「そうなんです」と言った。そして、なぜ今まで呼ばなかったのかを考えた。面倒だったからだ。調整コストを払いたくなかったからだ。
別の会社では、事業戦略のドキュメントを技術チームにも共有してもらうようにした。最初は「読まないでしょ」と言われた。確かに、読まない人もいた。しかし、読む人もいた。読んだ人が「この戦略なら、このアーキテクチャは合わない」と気づいた。それだけで、価値があった。
これらは、コストがかかる。効率は下がるかもしれない。しかし、分断のコストを計算したことがあるだろうか。
私が関わったあるプロジェクトでは、事業部門と技術部門の認識のずれを修正するのに、毎週2時間の会議を3ヶ月続けた。それでも修正しきれず、最終的に機能の30%を作り直した。作り直しにかかった工数は、最初から一緒に話し合っていれば発生しなかったものだ。分断は「効率的」に見える。しかし、その効率は幻想だ。後から払うコストを、先送りしているだけだ。
なぜ変われないのか
ここまで読んで、「分かった、越境しよう」と思った人もいるかもしれない。しかし、それだけでは変わらない。私自身、何度も経験してきた。
「越境すればこんなにいいことがある」と説明した。「対話すれば問題が解決する」と語った。しかし、魅力的な提案が受け入れられないのは、魅力が足りないからではなかった。相手が受け入れたくない理由があるからだ。
ある会社では、「今のやり方で回っているのに、なぜ変える必要があるのか」と言われた。惰性だ。今のやり方に慣れている。変える理由がない。
私はこの種の人たちを何度も見てきた。出世競争から降りて、自分のペースで仕事をこなし、昼休みには決まった仲間と弁当を食べ、定時に帰る。悪い人たちではない。むしろ、穏やかで、職場の潤滑油になっていることもある。しかし、変化の話をすると、途端に顔が曇る。「それ、本当に必要ですか」「今のままでも回っていますよね」。
彼らにとって、改善か改悪かは問題ではない。変えること自体が脅威なのだ。長い時間をかけて築いた居場所。慣れた仕事の流れ。気心の知れた同僚との関係。今の自分を成り立たせているものが、壊されるかもしれない。その不安が、あらゆる変化への抵抗になる。
私は最初、この人たちを「抵抗勢力」だと思っていた。説得すれば分かってくれる、と。しかし、あるとき気づいた。彼らの反応は、合理的だ。変化のコストを払うのは彼らだ。新しいやり方を覚える。慣れた関係が崩れる。評価の仕方が変わる。一方、変化の恩恵を受けるのは誰か。たいてい、変化を推進した側だ。「改革を成功させた」と評価されるのは、推進者だ。コストを払う人と恩恵を受ける人が違う。それなら、抵抗するのは当然ではないか。
私が「越境しよう」と言うとき、そのコストを誰が払うのか。私ではない。現場の人たちだ。私はその認識が、ずっと欠けていた。
別の会社では、「それをやる余裕がない」と言われた。労力だ。相手の言葉を学ぶコスト、会議を調整するコスト、認識のずれを修正するコスト。その余裕がない。
また別の会社では、「あなたに何が分かる」と言われた。感情だ。専門性へのプライド。自分の領域に口を出されることへの反発。
そして、「上から押し付けられた」と感じた瞬間、内容に関係なく拒否される。心理的反発だ。これが一番厄介だった。
魅力をいくらアピールしても、これらの抵抗があれば動かない。魅力をいくら積み上げても、抵抗が1つあれば動かない。掛け算のどこかにゼロがあれば、答えはゼロだ。むしろ、魅力を強調するほど、「押し付けられている」という反発が強まることすらある。
私の経験では、最も強い抵抗は心理的反発だった。「誰が言うか」の問題だ。同じ内容でも、言う人によって受け入れられ方が違う。外部の人間が言うと「現場を知らないくせに」と反発される。内部の人間が言うと「自分の領域を広げようとしている」と疑われる。
拒否しているのは「内容」ではなく「手続き」や「語り手」であることが多い。内容に反論できないから、手続きに難癖をつける。「そのやり方は聞いていない」「なぜ事前に相談しなかったのか」。内容ではなく、プロセスで拒否する。
抵抗を下げる最小の一歩は何か。会議に一人、他部門の人を呼ぶ。それだけでいい。最初は「オブザーバー」として。発言しなくてもいい。ただ、聞いているだけでいい。その一人がいることで、「他部門から見たらどう見えるか」を意識するようになる。それが、越境の始まりになる。
だから、私は変えた。魅力を語る前に、抵抗を減らすことを考えるようになった。惰性を崩す小さな一歩を提案する。労力を下げる仕組みを作る。感情に配慮する。押し付けではなく、選択肢として提示する。それでも、うまくいかないことは多い。
個人の努力では足りない
ここまで「越境せよ」と書いてきた。しかし、ここで立ち止まって、自分の主張を疑う必要がある。
「越境せよ」は、誰に言っているのか。
越境の権限がない人に言っても、負荷を増やすだけだ。越境が評価されない構造で「越境せよ」と言っても、個人を疲弊させるだけだ。
私はこの記事で、分断の弊害を語り、越境の価値を語ってきた。しかし、その主張が新たな「べき論」になるリスクがある。「越境すべき」「事業の言葉で語るべき」「全体を見るべき」。これらは、個人への要求だ。
しかし、なぜ越境が難しいのか。それは構造の問題だ。
評価制度を見てほしい。技術者は「技術的な成果」で評価される。事業への貢献は、評価項目に入らないことが多い。越境して事業に口を出しても、評価されない。むしろ、専門性が薄まったと見なされるリスクがある。
KPIを見てほしい。事業部門は売上で評価される。技術部門はシステムの安定性で評価される。「境界をまたぐ貢献」を測る指標は、どこにもない。
キャリアパスを見てほしい。技術者としてのキャリアは、技術を深めることで築かれる。越境に時間を使うと、専門性が薄まる。越境は、キャリアリスクになりうる。
この構造がある限り、越境しない方が合理的だ。
言い換えれば、越境は、評価されないボランティアだ。ボランティアに依存する組織は、ボランティアが疲弊した瞬間に壊れる。
私が「越境せよ」と言うとき、暗黙のうちに個人の努力に頼っている。善意に頼っている。「組織のために」という献身に頼っている。しかし、善意は持続しない。献身は燃え尽きる。
越境を個人に求めるだけでは足りない。越境が合理的になる構造を作らなければならない。
具体的には何か。
評価制度を変える。「境界をまたぐ貢献」を評価項目に入れる。技術者が事業に貢献したことを、技術的成果と同等に評価する。事業担当が技術的制約を理解し、計画に反映したことを評価する。
KPIを変える。部門ごとのKPIだけでなく、「部門間の連携」を測る指標を作る。例えば、「他部門からのフィードバックを計画に反映した回数」「境界をまたぐ問題を早期に発見した件数」。
キャリアパスを変える。越境経験を、キャリアの強みとして評価する。「技術も事業も分かる人」を、専門家と同等に評価する。
予算を変える。「境界をまたぐ問題」に使える予算枠を作る。事業予算でも技術予算でもない、「連携予算」のようなもの。
会議体を変える。月曜・水曜・金曜と分かれた会議を、定期的に統合する場を作る。全員が同席する必要はない。しかし、境界の情報が消えないための仕組みが必要だ。
しかし、ここで自分の甘さを認めなければならない。
私は以前、ある会社で評価制度の変更を提案したことがある。「越境的な貢献も評価項目に入れましょう」と。提案は通った。評価シートに「部門間連携」という項目が追加された。半年後、何が起きたか。項目は増えたが、行動は変わらなかった。みんな、その項目に「特になし」と書いて提出していた。形式だけが変わり、中身は何も変わらなかった。
そのとき気づいた。部門を統合しても、会議体を変えても、中の人々が行動を変えなければ、結局、何も変わらない。当たり前のことだ。しかし、私は「構造を変えれば人が変わる」と信じていた。構造さえ整えれば、人は自然とその構造に沿って動くはずだ、と。甘かった。
評価制度を変えても、その評価制度を運用する人が変わらなければ、何も変わらない。会議体を変えても、会議で発言する人の意識が変わらなければ、何も変わらない。構造は、行動を促すきっかけにはなる。しかし、行動を強制することはできない。
では、構造を変えることに意味はないのか。そうではない。構造を変えることは必要だ。しかし、十分ではない。構造を変えると同時に、「なぜこの構造に変えるのか」を語り続ける必要がある。形式だけでなく、意味を伝える。それがなければ、新しい構造は空箱になる。
——と書いて、これらを変える権限が自分にないことに気づく。私は技術顧問だ。評価制度を変える権限はない。KPIを変える権限もない。予算を変える権限もない。
では、権限がない人は何もできないのか。
そうではない。権限がなくても、できることはある。
まず、構造の問題を言語化することだ。「越境が難しいのは、評価制度が越境を評価しないからだ」と言葉にする。問題を個人の能力や意欲の問題ではなく、構造の問題として語る。それだけで、議論の土俵が変わる。
次に、小さな実験を提案することだ。評価制度全体を変えるのは難しい。しかし、「このプロジェクトでは、境界をまたぐ貢献も評価してみませんか」と提案することはできる。小さな実験が成功すれば、それを拡大できる。
そして、越境できない自分を責めないことだ。越境が難しいのは、あなたの能力の問題ではない。構造の問題だ。構造が変わらない中で、できることをすればいい。
ただし、ここで一つ、認めておくべきことがある。
全員が越境する必要はない。
越境できる人がいて、専門性を深める人がいて、それぞれが価値を出す。これも、一つの分業だ。全員が同じ行動をする必要はない。越境が得意な人が越境し、専門性を深めるのが得意な人が深掘りする。その組み合わせで、組織は機能する。
「越境せよ」という主張が、「全員が越境すべき」という画一的な要求になってはいけない。越境しない人を「視野が狭い」と見なしてはいけない。専門性を深めることにも、価値がある。
私がこの記事で言いたいのは、「全員が越境せよ」ではない。「越境が必要な場面で、越境できる構造を作れ」だ。
私自身の反省
正直に言えば、私自身、この分断に加担してきた。
技術顧問として呼ばれる。「アーキテクチャについてアドバイスしてください」と言われる。私は、アーキテクチャについてアドバイスする。それが、私の仕事だと思っていた。
しかし、アーキテクチャの問題は、純粋に技術的な問題であることは稀だ。組織の問題であり、事業の問題でもある。
「なぜこのアーキテクチャになったのか」を掘り下げると、組織の歴史が見えてくる。「チームが分かれていたから、システムも分かれた」。「この部分は外注したから、ブラックボックスになった」。「この機能は急いで作ったから、技術的負債が溜まった」。
技術の問題を、技術だけで解決しようとしても、うまくいかない。組織を変えなければ、技術は変わらない。事業の優先順位を変えなければ、技術的負債は返せない。
私は、そこまで踏み込むことを避けてきた。「それは私の領域ではない」と。しかし、それは、本当に価値のある助言だったのか。
踏み込まないことで、私は何を守っていたのか。関係性だ。嫌われたくない。次も呼ばれたい。だから、言いにくいことは言わない。契約範囲だ。「アーキテクチャのアドバイス」で呼ばれた。組織や事業の話は契約外だ。だから、踏み込まない。安心感だ。技術の話をしていれば、自分の専門領域にいられる。組織や事業の話をすると、自分が素人になる。だから、避ける。
しかし、これらを守った結果、私のアドバイスは実行されないまま終わった。価値を提供できなかった。守ったものは、守る価値があったのか。
最近は、少しずつ変えている。技術の話だけでなく、組織の話も、事業の話もする。「このアーキテクチャを実現するには、チーム編成を変える必要があります」「この技術的負債を返すには、事業側の優先順位を変える必要があります」。
踏み込むときの言い方には、工夫がいる。診断として言う——「私の見立てでは、技術だけでなく組織の問題もあるように見えます」。断定ではなく、観察として伝える。仮説として言う——「もし組織構造を変えたら、アーキテクチャの変更がスムーズに進むかもしれません」。押し付けではなく、可能性として提示する。選択肢として言う——「技術だけで対処する方法と、組織も含めて対処する方法があります。どちらを選びますか」。決定権は相手に渡す。
言いにくいことだ。領域を越えている。しかし、言わなければ、本当の解決にはならない。
おわりに
「おい、分けて語るな」。この言葉は、会議室の誰かに向けているようで、実は自分に向けている。
この文章を読んでも、明日から「事業と技術と組織を統合して考えられる人」にはならない。私自身がそうだったから分かる。
組織の分断は、風邪のような急性疾患ではない。薬を飲んで寝れば治る、というものではない。慢性疾患だ。劇的な手術で一気に治すことはできない。できるのは、セルフケア的なアプローチだ。小さなことから、少しずつ、継続的に変えていく。一気に問題を解決しようとは思わないこと。問題解決モードを抜け出し、対話モードで慢性疾患に向き合う。
「分けて考えるな」。言葉では分かる。しかし、明日の会議で、実践できるか。経営会議で「それ、技術的にはこういう含意があります」と発言できるか。技術戦略会議で「それ、事業戦略とどう関係しますか」と質問できるか。
正直、自信がない。質問した瞬間、場が凍りつくかもしれない。「また技術の話か」と思われるかもしれない。そう思うと、喉まで出かかった言葉を飲み込んでしまう。これまでも、そうだった。
でも、一つだけ提案がある。次の会議で、一回だけ、こう質問してみてほしい。
「この決定は、[別の領域]にどういう影響がありますか？」
答えが返ってくればいい。返ってこなければ、それが発見だ。その沈黙は「分断がある」という証拠だ。
私は過去に3回、この質問をした。1回目は無視された。2回目は「それは技術の話だから」と流された。3回目は違った。CTOが一瞬黙り、それから「いい質問だ」と言った。会議室の空気が変わるのを感じた。CTOはその場で技術責任者を呼んだ。30分後、経営会議に技術責任者が同席するという、その会社では初めてのことが起きた。3回目が、その会社の変化の始まりだった。
1回で変わることは稀だ。しかし、質問しなければ、変わる可能性すらない。沈黙が3回続いたら、それは「この組織には分断がある」という診断結果だ。診断結果が出れば、次のアクションが見える。
明日も会議がある。月曜は経営会議。水曜は技術戦略会議。金曜は組織開発会議。きれいに分かれている。整然としている。
月曜の経営会議で、一つだけ、技術の話をしてみようと思う。「この事業戦略、技術的にはどういう制約がありますか」と。沈黙が流れるかもしれない。「それは水曜に」と言われるかもしれない。それでもいい。
その沈黙こそが、分断の存在を証明している。そして、証明された瞬間から、修復は始まる。
私が「分けて語らない」姿勢を貫くとき、最初に変わるのは何か。会議か。人か。成果物か。
私の経験では、最初に変わるのは成果物だった。技術レビューに事業インパクトの項目を入れる。事業計画書に技術的制約の項目を入れる。アーキテクチャ決定記録（ADR）に「事業への影響」を必須にする。成果物の形式が変わると、それを作る過程で、自然と越境が起きる。
次に変わるのは会議だ。技術の会議に事業担当を一人呼ぶ。事業の会議に技術担当を一人呼ぶ。最初はオブザーバーでいい。聞いているだけでいい。その一人がいることで、会議の空気が変わる。
最後に変わるのは人だ。人の意識や行動は、簡単には変わらない。しかし、成果物の形式が変わり、会議の参加者が変わると、少しずつ変わっていく。「他の領域のことも考える」が、習慣になっていく。
——と書いたが、本当にそうだろうか。成果物や会議が変わっても、人が変わらないケースも見てきた。形式だけ整えて、中身は変わらない。「事業インパクト」の欄に、適当なことを書いて終わり。そういう組織もある。
それでも、形式から入るしかない。形式が変われば、少なくとも「考える機会」は生まれる。考えた結果、変わらない人もいる。変わる人もいる。変わる人が一人でもいれば、その人から広がる可能性がある。
この声は、会議室の誰かにではなく、自分自身に向けられている。
