ほとんどの起業家は、何かが壊れたときに仕組みを構築する。
受信箱があふれる。チームが締め切りを逃す。クライアントに誤ったファイルを送ってしまう。そこで初めて、プロセスづくりに奔走する。それは事後対応型の思考であり、想像以上の代償を伴う。競合に先んじる企業は、火が燃え上がってからではなく、火種が生じる前に仕組みを構築している。
支払うことになるコスト
仕組みなしに行うすべての業務には、二重のコストがかかる。まず、その作業に時間を費やす。次に、やり直しにも時間を費やす。再現可能な構造がなければ成果にばらつきが生じ、品質がぶれるからだ。結局、同じ問題を15週間にわたり15通りの方法で解決することになり、エネルギーは消耗していく。
一貫性の欠如は、ビジネスにとって高くつく。クライアントとの信頼を損ない、チーム内に混乱を生み、最も限られた資源である認知的余力を食いつぶす。一方で仕組みがあれば、その業務をどう進めるかを考える必要がなくなる。実行は速く、予測可能になる。
起業家が早期に仕組みを構築しない理由
物事が落ち着いているときに仕組みを構築するのは不要に感じる、というリーダーの言い分はよくわかる。余力はまだあり、期限も差し迫っていない。「後で考えればいい、必要になったら対応すればいい」と思うのだ。しかし、その時が来ると、忙しすぎるうえに仕組みが足りず、考える余裕がない。本来なら成長の果実を得るべき時間が混乱に変わり、成長は止まってしまう。
事業量が倍増すると、考える時間は減る。仕組みが最も必要になる瞬間こそ、それを構築する余力がまったくない瞬間なのだ。自分自身が、自社のオペレーションにおけるボトルネックになってしまう。
不足に直面してからではなく、余裕があるうちに構築するほうがよい。これこそ、うまく運営されている組織に共通する、直感に反する真実である。
機能する仕組みとはどのようなものか
仕組みとは、構造化され、反復可能な一連の流れであり、3つの中核要素で成り立つ。
1. インプット：何がその仕組みを起動するのか。新規クライアントが契約する。注文が入る。コンテンツ制作の依頼が届く。起点を定義する。
2. プロセス：正確な手順を、正確な順序で、正確な役割が担う形で示す。曖昧な指示はすべて、将来のミスの種であることに注意すべきだ。疲れ切り、気が散り、締め切りに追われている自分でも実行できるように、手順を書く必要がある。
3. アウトプット：完成した成果物はどのような状態か。品質を定義し、基準を定める。アウトプットが主観的であれば意見の対立は増えるが、定義されていれば、仕組みの実行精度は高まる。
何を最初に仕組み化すべきかを見極める方法
自分が行うすべての業務について、2つの問いを立てる。この業務はどれほど頻繁に発生するのか。そして、一貫性を欠いた場合に何が壊れるのか。
頻度が高く、影響が大きいもの。それが最初に仕組み化すべき対象だ。クライアントのオンボーディング、請求書処理、コンテンツ公開、採用を、あなたは業務として捉えているかもしれない。しかしこれらは単なる業務ではない。たった一つの不一致が組織的な損害へと積み重なる領域である。ただし、過剰設計もまた勢いを削ぐことを忘れてはならない。まずはクリティカルパス、たとえば収益を直接生み、評判を守り、チームの機能を可能にする活動に狙いを定めるべきだ。最初に仕組み化すべきなのはそれらである。それ以外は順番待ちでよい。
仕組み設計における10倍ルール
すべての仕組みは、現在の10倍の業務量に対応できるよう設計する。2倍ではなく、10倍だ。一見、過剰に思えるかもしれない。だが、そうではない。現在のニーズに合わせて構築された仕組みの多くは、事業成長が加速した瞬間に崩壊する。最も余裕がないときに、全面的な再構築を迫られるのだ。
まだ達成していない規模を前提に、ビジネスをつくるべきである。立ち上げ時にはインフラが過大に見えるかもしれないが、それは意図的なものだ。新たなチームメンバー、新たなクライアント、新たな複雑性という制約が、後からその余白を埋めていく。仕組みは、その負荷を破綻せずに吸収できなければならない。
明日いなくなるつもりで文書化する
すべての仕組みは、月曜日から働き始める見知らぬ人に引き渡すつもりで書く。多くの業務文書が失敗するのは、作成者が文脈を前提にしているからだ。作成者はソフトウェアを知っており、チーム内の用語を知っており、明文化されていないルールも知っている。しかし見落とされがちなのは、読み手がそうした前提部分をすべて知っているわけではないという点だ。そこに抜けが生まれ、混乱が続く。
あらゆる前提を取り除き、使用するツールを明記し、ショートカットも説明する必要がある。動画による手順解説を録画し、スクリーンショットを使い、すべての手順に番号を振る。FAQセクションをあらかじめ追加し、新しく加わった人が尋ねる質問をすべて記録し、文書内で回答する。仕組みの強度は、最も弱い指示に左右される。手順が一つ欠けるだけで、連鎖は途切れる。
仕組みのメンテナンス
業務の仕組みは劣化する。インフラとして扱う必要がある。ソフトウェアは変わり、チームメンバーは離れ、クライアントの期待も変化する。1月に機能していた仕組みも、誰も更新しなければ10月には負債になる。
四半期ごとに仕組みのレビューを予定し、責任者を割り当てるべきだ。各仕組みについて監査し、古くなった手順を指摘し、改善を実行する担当者を1人置く。責任の所在がなければ、文書は博物館の展示物になる。情報としては役立つかもしれないが、実務には関係がない。優れた企業は、ソフトウェアのように仕組みに名前を付ける。バージョン1.0、バージョン2.3といった具合だ。エンジニアがコードを扱うのと同じ厳格さで、プロセス文書を扱うのである。
今日、一つの仕組みから始める
事業全体を一度に監査してはならない。フレームワークをつくるためのフレームワークを構築してもいけない。代わりに、毎週繰り返している業務を一つ選ぶ。一貫性の欠如によって、すでに時間、資金、品質のいずれかを失った業務を一つ選ぶのだ。今日、それを文書化する。インプット、手順、アウトプットを書く。そして一度テストし、改善する。それが土台になる。
翌週に次の仕組みを積み上げ、その次もまた積み上げる。構築する仕組みが一つ増えるたびに、次の仕組みはより速くつくれ、より維持しやすくなり、チームにとってより価値あるものになる。
