なぜ「同期割合」を下げると組織が速くなるのか

AI が普及して、「作る」時間は明らかに短くなりました。コードも、資料も、下調べも、以前の何分の一かで仕上がります。

それなのに、プロジェクトが終わる日付はあまり変わっていない。心当たりがあるなら、この記事はその理由の話です。

並列化できない部分が、全体を支配する

アムダールの法則は、もともと並列計算の話です。

プログラム全体の高速化の上限は、並列化できない部分の割合で決まる。

処理の 40% が逐次実行なら、残り 60% を何万コアで回しても、全体は 2.5 倍までしか速くなりません。逐次部分が 1% まで落ちてはじめて 100 倍が見えてきます。

数式は単純です。逐次部分の割合を s とすると、

最大の高速化 = 1 / s

分母が小さくなるほど効きが急に大きくなる。ここが直感に反するところです。

組織における「並列化できない部分」

組織を1台の並列計算機だと思ってみてください。並列化できるのは実行——コードを書く、資料を作る、調べる。AI が安くしたのは、まさにここです。

では並列化できない部分は何か。他の誰かと同期しないと進まない仕事です。

• 会議が終わるまで決まらない
• 返信が来るまで動けない
• 承認が下りるまで止まっている
• 「これで合ってますか」の確認待ち

これらは人数を増やしても並列になりません。むしろ人数が増えるほど同期点は増えます。

実行が無限に速くなった世界では、組織の速度を決めているのはこの同期領域だけです。

40% を 1% にする、という目標

同期割合 40%（週の 2 日分が待ちと会議に消えている、くらいの感覚です）のとき、上限は 2.5 倍。

• 40% → 上限 2.5 倍
• 10% → 上限 10 倍
• 1% → 上限 100 倍

10% から 1% へ削るのは、40% から 10% へ削るより体感としてずっと地味な作業です。でも効き目は 10 倍から 100 倍へ、桁で変わります。終盤ほど効くというのが、この法則のいちばん実務的な含意です。

「速く働く」ではなく「同期を減らす」

ここで大事なのは、同期割合を下げることは急ぐこととは違うということです。会議を短くしても、それが意思決定の唯一の場である限り同期点は残ります。

減らすべきは、時間ではなく依存です。

• 会議で決めていたことを、非同期で決められる形にする
• 「誰のボールか」を、聞かなくても分かるようにする
• 期限を、口頭ではなく構造として持たせる
• 承認を、人ではなくルールに委ねられるところは委ねる

どれも「速く働く」話ではありません。構造の話です。

そして、構造は見えないと変えられない

ところが多くの組織では、自分たちの同期割合が何%なのかを誰も知りません。

どのタスクが、誰の、どの意思決定で止まっているのか。それが見えていないから、「なんとなく進みが悪い」で終わってしまう。

UTSUROI がやろうとしているのは、まずこれをデータにすることです。日々のコミュニケーションとタスクの動きから仕事の状態を取り出し、滞っている場所を指し示す。管理のためではなく、流すために。

移ろい——淀まず、移り変わり続けること。組織がそうあるための構造を作っています。

実際の使い方はオンボーディングから。