OSを変える企業、目標を変える組織：不確実性を成長の構造に変える方法

「目標を毎回達成するチーム」と「OSを大胆に乗り換える企業」は、正反対に見える。前者は計画性の象徴であり、後者は不確実性への賭けに見えるからだ。

しかし、両者の根底には同じ問いがある。

いま使っている仕組みを、成果そのものと勘違いしていないか。

スマートフォンの世界では、利用者が触れるのはアプリであり、OSの名前ではない。組織では、経営者が目にするのは売上や達成率であり、目標設定の仕組みそのものではない。けれども、表面に現れる成果は、見えにくい基盤の設計に強く左右される。

OSを変える話と、目標管理の話を一緒に考えると、企業やチームが変化に適応するための重要な原則が見えてくる。それは、成果を守りたいなら、成果を生み出している基盤を定期的に疑わなければならないという原則である。

目標達成率が高いほど、危険なことがある

多くの組織では、目標の達成率が高いほど良い状態だと考えられている。毎月の売上目標を達成し、プロジェクトを予定通り終え、設定した指標がすべて満たされる。管理者にとっては安心できる光景だ。

ただし、目標管理の仕組みが本当に機能しているなら、常に完全達成になるとは限らない。十分に安全な目標しか設定していない場合、達成率は高くなる。しかし、それは組織が優秀だからではなく、失敗しない場所に目標を置いているからかもしれない。

ここで重要なのは、成果の数値と、学習の質は同じではないということだ。簡単な目標を達成しても、未知の市場について何も分からず、技術的な制約も発見できず、顧客の本当の需要にも近づけないことがある。逆に、野心的な目標に挑戦して達成率が低くても、次の判断に使える知識が大量に得られる場合がある。

たとえば、あるチームが新機能の利用率を三十パーセントにする目標を立て、実際には十八パーセントにとどまったとする。この数字だけを見れば失敗である。しかし、導入を妨げていた原因が、機能の魅力不足ではなく、初期設定の複雑さだったと判明したなら、そのチームは単なる未達ではなく、次の改善につながる情報を獲得している。

一方、最初から利用率五パーセントを目標にして、それを達成したとしても、組織は何も大きく学ばない可能性がある。

低い達成率は、必ずしも弱さの証拠ではない。安全すぎる目標の一〇〇パーセント達成こそ、停滞の証拠かもしれない。

この視点に立つと、目標は評価の物差しではなく、探索のための装置になる。目標を達成したかどうかは重要だが、それ以上に、目標への挑戦によって何が明らかになったかが重要になる。

OSの移行は、名前の変更ではなく依存関係の再設計である

新しいOSへの移行も、単に画面やブランドを変更する作業ではない。OSは、アプリケーションが動くための基盤であり、開発者が利用する道具、端末が提供する機能、ユーザーが期待する体験を結びつけている。

だからこそ、OSを変更する場合に最も大きな問題になるのは、「新しいOSの名前を知っているか」ではない。現在の製品や開発プロセスが、どの基盤にどれほど依存しているかである。

新しい環境でアプリを開発するために、共通のソフトウェア開発キットが使われるとする。これは、移行の負担を減らす抽象化の層として機能する。開発者はOS固有の細部をすべて直接扱うのではなく、共通の道具を通して複数の環境に対応できる。

しかし、抽象化は魔法ではない。表面上は同じコードで動いていても、性能、通知、画面の挙動、端末固有の機能など、下層の違いが消えるわけではない。抽象化によって隠される部分と、いずれ理解しなければならない部分を区別する必要がある。

これは組織の目標管理にもそのまま当てはまる。売上、利益、利用者数、継続率といった指標は、組織の活動を数値に変換する抽象化の層である。数値は比較しやすく、共有しやすく、意思決定を速くする。だが、数字の下にある顧客の不満、現場の疲弊、技術的負債、偶然の成功までは自動的に説明してくれない。

指標は組織にとってのAPIのようなものだ。 APIが内部の複雑さを外部に提供しやすい形へ変換するように、指標は組織の活動を判断可能な形へ変換する。ただし、APIが現実のすべてではないように、指標も現実のすべてではない。

この区別を失うと、目標管理は危険になる。数値を上げることが目的になり、数値が表していたはずの現実が壊れていくからだ。問い合わせ対応の速度を上げるために、難しい問い合わせを別の窓口へ回す。利用者数を増やすために、短期的な登録だけを促す。開発速度を上げるために、将来の保守コストを無視する。

数値は改善しているのに、製品や組織は悪化している。この現象は、指標という抽象化の層と、現実の下層がずれているときに起こる。

野心的な目標と大胆な移行を同時に扱う

では、変化を促す野心的な目標と、日々の安定運用をどう両立すればよいのか。ここで有効なのが、組織を三つの層に分けて考える方法である。

第一は、基盤層である。OS、開発環境、データ構造、組織の権限設計など、普段は意識しないが全体を支えているものが含まれる。

第二は、活動層である。開発、販売、顧客対応、採用、実験など、日々の仕事がここにある。

第三は、結果層である。売上、利用率、利益、顧客満足度など、外部から見える成果である。

通常、組織は結果層の数字だけを改善しようとする。しかし、結果が伸びない原因が基盤層にあるなら、活動を増やしても問題は解決しない。古い開発環境のまま人員だけを増やしても、複雑さは増す。顧客対応の手順が壊れているのに、担当者へ「もっと速く」と求めても、品質が下がるだけである。

大胆な目標とは、必ずしも結果層の数字を極端に高くすることではない。基盤層を変える目標を持つことも、十分に大胆な挑戦である。

たとえば、次のような目標が考えられる。

「新OS対応を完了する」だけでは、単なる作業目標に近い。

「新しい環境でも、開発チームが同じ品質で機能を提供できる基盤を作る」なら、目的が明確になる。

「四半期の売上を増やす」だけでは、結果の追跡にとどまる。

「顧客が継続利用する理由を三つ検証し、次の投資判断に使える証拠を得る」なら、学習を組み込んだ目標になる。

この違いは大きい。前者では、未達が失敗として扱われやすい。後者では、結果が想定外でも、どの仮説が崩れ、どの基盤を改修すべきかが見えやすい。

共有される目標は、監視ではなく接続のためにある

目標を組織全体に公開することにも、重要な意味がある。公開の目的は、誰がどれだけ達成したかを監視することではない。各チームの活動が、どの仮説や優先順位につながっているかを見えるようにすることだ。

たとえば、開発チームが新しい共通開発環境を整え、営業チームが新しい顧客層を調査し、サポートチームが利用中止の理由を分類しているとする。個別に見れば、三つの活動は別々に見える。しかし、同じ目標に向かって「新しい利用環境で、顧客が継続利用できる製品体験を作る」ための活動だと分かれば、互いの知識が接続される。

公開された目標は、組織の地図になる。地図があれば、別の部署がどこへ向かっているかを知り、自分の仕事との重なりや不足を発見できる。逆に、目標を人事評価のためだけに使うと、人は情報を隠すようになる。難しい課題を避け、達成できそうな数字だけを選び、問題が見えても報告しなくなる。

この状態では、目標は学習装置ではなく、政治的な防具になる。

したがって、目標を公開するには、同時に二つの約束が必要だ。第一に、目標は組織の方向を調整するために使うこと。第二に、達成率を個人の価値そのものと結びつけないこと。この二つが守られて初めて、野心的な目標が機能する。

実務で使える「移行型OKR」の設計

ここまでの議論を、実際に使える形へ落とし込もう。変化の大きいテーマでは、結果だけでなく、移行と学習を測る指標を組み合わせるとよい。

1. 目標を「達成」ではなく「変化」として書く

悪い例は、「新しいOSへの対応を完了する」である。完了の定義が曖昧で、対応後に何が改善されるのか分からない。

より良い例は、「複数の環境で、開発チームが安定して製品体験を提供できる状態を作る」である。この表現なら、移行後の品質や開発速度も視野に入る。

2. 成果指標を複数の層に分ける

結果指標だけでは、問題の位置が分からない。次の三種類を組み合わせると、診断力が上がる。

・結果指標: 利用率、継続率、売上など ・活動指標: 実験数、検証した顧客数、対応した課題数など ・基盤指標: ビルド時間、障害復旧時間、再利用できる部品の割合など

たとえば新しい開発環境への移行なら、対応機能数だけでなく、開発時間、障害の発見速度、チーム間で共有できる部品の数も測るべきである。

3. 達成率と学習量を別々に記録する

目標が未達だった場合、「なぜ失敗したか」だけを尋ねると、防御的な報告になりやすい。代わりに、次の問いを追加する。

・最初の仮説は何だったか ・どの観測結果が仮説と異なったか ・何が分かったため、次の判断が変わるのか ・今回の試行によって、どの不確実性が減ったか

この記録があれば、達成率が六十から七十パーセント程度であっても、組織の知識は大きく増える場合がある。逆に、一〇〇パーセント達成でも、仮説を試さず、既知の作業を繰り返しただけなら、学習量は少ない。

4. 目標を評価表ではなく、対話の入口にする

目標の確認会議で、数字を読み上げるだけでは意味がない。議論すべきは、数字の背後にある構造である。

「利用率が低い」という報告に対して、「もっと頑張ろう」と言うのではなく、「製品の価値が伝わっていないのか、導入の摩擦が大きいのか、対象顧客の選び方が間違っているのか」と分解する。

この会話ができれば、目標は現場を縛るものではなく、現場の観察を経営判断へ変換するインターフェースになる。

Key Takeaways

・一〇〇パーセント達成を無条件に称賛しない。 目標が安全すぎなかったか、未知の課題に挑戦できたかを確認する。

・成果指標だけでなく、基盤指標と学習指標を置く。 結果が悪いときに、どの層に問題があるのか診断できるようにする。

・OSや開発環境の変更を、技術部門だけの仕事にしない。 基盤の変更は、製品体験、顧客理解、組織の協働方法まで変える。

・目標を人事評価から切り離し、共有された仮説として扱う。 未達を隠す文化では、正しい判断に必要な情報が失われる。

・目標を「何をするか」ではなく「何が変わるか」で書く。 作業の完了ではなく、顧客や組織に生じる変化を中心に据える。

変化に強い組織は、目標を守るのではなく更新する

OSの移行には、現在の資産を捨てる危険がある。しかし、古い基盤に固執することにも、見えにくい危険がある。目標管理も同じで、既存の指標を守り続けるだけでは、環境の変化に対応できない。

本当に成熟した組織は、目標を絶対的な約束として扱わない。目標を、現実に対する仮説として置き、結果を見て更新する。高い目標を掲げるのは、失敗を称賛するためではない。まだ見えていない制約や機会を、早く発見するためである。

結局のところ、OSもOKRも、現実そのものではない。どちらも、複雑な現実を扱いやすくするための基盤であり、インターフェースである。だからこそ、使い続けるほど点検しなければならない。

変化に強い組織とは、正しい目標を永遠に守る組織ではない。現実が変わったとき、目標と基盤を同時に更新できる組織である。

今日の達成率が高いかどうかよりも、その目標によって明日の判断が賢くなったかを問うべきだ。成果を生む仕組みを疑う勇気があるとき、目標は管理の道具から、組織が新しい現実へ移行するための乗り物へ変わる。