今のモノサシで過去を裁くな。批判家ではなく「建築家」であれ

「こんな非効率なフロー、誰が決めたんだ」と笑う前に

なんでこんな無駄な承認フローがあるんですか。
このスプレッドシートの入力作業、全部自動化できるじゃないですか。

新しいメンバーが入社し、組織の解像度が高まってきた頃、決まってこうした声が聞こえてくるようになります。あるいは、中途入社者として外から組織に入った瞬間、ツギハギだらけのオペレーションを見てめまいがすることもあるでしょう。

確かに、今のモノサシで見ればそれは非効率の塊です。手入力、二重チェック、謎の転記作業、形骸化した会議。ナンセンスだ、時代遅れだと切り捨てるのは簡単です。今の私たちには便利なSaaSが沢山あり、分業できる仲間がいるのですから。

しかし、私はこうした批判だけで終わる姿勢には明確に異を唱えます。なぜなら、その一見理不尽なオペレーションは、無能さが生んだものではないからです。それは、当時の限られたリソース、切迫した状況、そして会社を潰さないという強烈なプレッシャーの中で、先人たちが絞り出した最適解の成れの果てだからです。

私たちは批判者であってはいけません。
過去への敬意を持ち、未来を設計する建築家であるべきです。

全ては「当時の正義」で作られている

オペレーションを刷新する際、私は必ず歴史の掘り起こしを行います。なぜこのフローが生まれたのかという問いを立てるのです。

たとえば、一見すると無駄に見える3段階の承認フロー。
これを昭和的なハンコ文化だと笑うのは簡単です。しかし、当時の議事録や古参メンバーの話を紐解くと、別の景色が見えてくることがあります。3年前に大きな発注ミスがあり、会社が数千万円の損失を出しかけた。その際、再発防止策として当時のCFOが二度と同じ轍は踏まないという決意で設置したのが、この関所だったのかもしれません。

あるいは、非効率極まりない手動でのデータ転記。
API連携すれば一瞬なのにと思うかもしれません。しかし、当時はエンジニアのリソースがゼロで、SaaSを契約する月額数万円すら惜しいほどのキャッシュフローだったとしたらどうでしょう。それでも顧客に価値を届けるために、営業担当がコピペして繋いだ執念のバケツリレーだったとしたら。

全てのオペレーションには、創業者の、あるいは当時の担当者の思いや痛みが埋め込まれています。その背景を無視して今の基準だけで断罪するのは、安全地帯から戦場を眺めてもっと上手に戦えと言うようなものです。それはあまりに想像力が欠けていますし、何よりフェアではありません。

チェスタトンのフェンス

チェスタトンのフェンスという思考実験をご存知でしょうか。
道にフェンスが立っているとき、何のためにあるのか分からないから撤去しようと言う人は愚かであり、このフェンスが置かれた理由が分かるまでは絶対に撤去してはならないと考えるのが賢い人だという話です。

オペレーション改善もこれと同じです。
理由が分からないから無駄だと判断して削除した承認プロセスのせいで、数ヶ月後に重大なコンプライアンス違反が起きるかもしれません。
自動化できるからとシステムに置き換えた結果、手作業の中に含まれていた顧客への細やかな配慮や暗黙知が消失し、解約が増えるかもしれません。

現在のオペレーションがなぜそうなっているのかという背景を解き明かすこと。それがBizOpsの第一歩です。過去の制約条件を理解し、当時はこれがベストだったのだと受容する。その敬意があって初めて、私たちはメスを入れる資格を得るのです。

リスペクトの上で、容赦なく壊す

誤解していただきたくないのは、敬意を払うことと温存することはイコールではないということです。むしろ逆です。過去の意図を正しく理解したからこそ、今の環境に合わせて容赦なく作り変えることができるのです。

3年前の発注ミスを防ぐというフェンスの設置理由を理解したのであれば、今はもう人が目視でチェックするフェーズではない、システムで自動検知する仕組みに変えようという提案ができます。これなら、当時のCFOの事故を防ぎたいという思いを引き継ぎつつ、手法を現代版にアップデートできます。これが単なる批判と建設的な提案の違いです。古いからダメだと切り捨てるのではなく、魂は引き継ぎつつ器を変える。これこそが、組織の新陳代謝を促す唯一の方法です。

未来の私たちに恨まれないために

そしてもう一つ、オペレーションを再設計する際に重要な視点があります。それは、今だけでなく未来に耐えうるかという視点です。

今の私たちもまた、数年後の後輩たちから見れば過去の人になります。
今、私たちがこれが最適だと思って作ったフローも、組織が30人から100人、300人へと拡大した時には必ず時代遅れの負債になります。

だからこそ、想像力を働かせなければなりません。
今は手動で回るけれど、取引数が10倍になったら破綻しないか。
特定のスーパーマンに依存したフローになっていないか。
このツール選定は、3年後、5年後の組織規模でも耐えうる拡張性があるか。
私たちは、未来の批判者たちへの回答を用意しておく必要があります。

もちろん、全ての未来を予測することは不可能です。
それでも、少なくとも向こう2〜3年は耐えられる、壊すときに移行しやすいようにデータ構造は標準化しておくといった配慮は可能です。
今の最適解ではなく、変化に強い構造を残すこと。それが、今の私たちが未来の組織に対して果たせる責任です。

建築家としての誇りを持て

現場から使いにくい、面倒だという声が上がってくることもあるでしょう。過去の遺産に苦しめられる日もあるでしょう。ですが、そこで前の担当者が悪いと愚痴をこぼすのは今日で終わりにしましょう。その不格好なオペレーションのおかげで、会社は今まで生き延びてこられたのです。まずはその事実に感謝し、敬意を表しましょう。

その上で、今の組織のリソース、技術、そして目指すべき未来の姿を想像し、モノサシにして、新しい設計図を引き直すのです。過去を否定するのではなく、過去の上に新しい階層を積み上げる。誰かが作った道を歩くだけの評論家ではなく、自ら道を切り拓き、舗装する建築家であれ。
それが、株式会社カクシアジが提唱するBizOpsの矜持です。

3年後、誰かが今の私たちが作ったオペレーションを見て、なんでこんなやり方してるんだと笑う日が来るかもしれません。もしそうなったら、心の中でガッツポーズをしましょう。それは、私たちの想像を超えて、組織が大きく成長したという何よりの証拠なのですから。

#BizOps #業務改善 #オペレーション設計 #当時の正義

急速に拡大するニーズに伴い、専門化・細分化が進むBizOps求人市場の現在を読み解きます。あわせて、尖った専門性がないことに葛藤していた自身のキャリアが、BizOpsという概念に出会いどう再定義されたかという体験をまとめました。

Xでは、記事にする前の断片や
現場で感じた違和感を ほぼ毎日書いています。
よかったら、のぞいてみてください。
https://x.com/kakushiaji_inc