正しく動く仕組みは、なぜ誰にも見えないのか

コロナ前夜、まだ電子契約という言葉が市場に定着していなかった頃、私はその導入を社内で進めていました。
電子契約はいずれ来る。しかし「いずれ来る」を待ってから動くのと、「来る前に設計しておく」のとでは、組織への着地がまったく異なります。急いで導入したシステムは、急いだ痕跡が仕組みに残ります。フローが歪で、例外対応が多く、誰も全体像を把握していない状態で運用が始まります。私はそれを避けたかったのです。

2020年春、コロナが来ました。多くの会社が電子契約への急対応に追われる中、私がいた組織は何も慌てませんでした。仕組みがすでに動いていたからです。そして数ヶ月後、電子契約は組織の「当たり前」として静かに馴染んでいました。新しく入ったメンバーは最初からそれを使い、特段の驚きも違和感もなく業務を進めました。
それが、設計の成功した姿です。そして同時に、設計者の仕事が最も見えにくくなる瞬間でもあります。

仕組みが機能した瞬間、仕組みは透明になる

正しく設計された仕組みは、機能するほど存在感を失います。これは皮肉ではなく、設計の本質です。

水道管を思い浮かべてください。蛇口をひねれば水が出ます。それが当たり前になった瞬間、人は水道管の存在を意識しなくなります。設計者の仕事がいかに精緻であっても、使う側にはその精緻さは見えません。見えないことこそが、設計の成功を意味します。

BizOpsの仕事はこれに近いです。業務フローを再設計し、ツールを適切につなぎ、情報が途切れない経路を作ります。うまくいけばいくほど、周囲から見た景色は「何も変わっていない」ように映ります。問題が起きないのだから、誰も問題を認識しません。問題を認識しないのだから、誰も改善の痕跡を追いません。

電気が止まらなければ電力会社の仕事は見えません。システムが落ちなければエンジニアの仕事は見えません。インフラの設計者はすべて、「何も起きない」状態を維持することが仕事の核心にあり、その成功ゆえに存在が透明化されるという構造を持っています。BizOpsもその一つです。

この透明化は、設計の精度が上がるほど加速します。粗削りな仕組みは、摩擦や不満という形で「存在の証拠」を残します。しかし精緻に設計された仕組みは、摩擦ゼロで動くがゆえに、「もともそういうものだった」という認識に上書きされていきます。設計者にとっての最高の評価が、同時に最大の不可視化の原因になるのです。

私が体験した「透明化された設計」

電子契約の話には続きがあります。私は同時期、契約書の管理が部署ごとにばらばらになっていることに着目し、契約書管理ツールの導入準備も並行して進めていました。電子契約システムとのシームレスな接続も視野に入れながら、丁寧に設計を重ねました。

この準備は、長くかかりました。電子契約の定着と、契約書管理の一元化、そして両者のデータ連携を同時に実現するための設計は、細部の詰めが多かったです。どの契約フローでどのタグをつけるか。保管先のディレクトリ構造をどう設計するか。表からは見えない、無数の小さな判断の積み重ねがそこにありました。

コロナが本格化するタイミングで、ちょうど運用変更が完了しました。電子契約が急速に普及しはじめたそのタイミングに、契約書管理の一元化も同時に実現できました。設計者として見れば、これ以上ない着地でした。

そして半年後、その仕組みは「最初からそうだったもの」として組織に溶け込んでいました。新しく入ったメンバーは電子契約で締結し、一元化されたシステムで契約書を確認します。
誰かがそれを特別だと感じる場面は、もうどこにもありませんでした。設計が完全に成功した証拠です。それと同時に、「自分がやったことを証明できるか」という問いが、静かに残りました。

価値を可視化する、というBizOpsの次の仕事

「何も起きなかった」と「何も起きない状態を設計した」は、結果として同じ景色に見えます。しかし本質は真逆です。前者は偶然であり、後者は意図と設計の産物です。その違いを証明できなければ、設計者の仕事は永遠に偶然と区別されません。

では、どうするか。私が今実践していることをひとつだけ挙げます。設計前に「正常状態の定義」を言葉にして残すことです。
業務フローを変える前に、現状の問題点と想定されるリスクを文書化します。「現在、契約書の保管場所が部署ごとに異なり、横断検索ができない。法務確認に平均３営業日かかっている」このレベルの具体性で書きます。設計後に「この仕組みが機能すれば、これらは起きなくなる」という予測を明示しておきます。３ヶ月後、６ヶ月後に振り返り、起きなかったことを記録します。

何も起きなかったことは、記録されなければ証拠になりません。しかし記録さえあれば、それは確かな設計の履歴になります。「この問題が起きる構造があった。私はそれを検知し、先に塞いだ。その後、その問題は一度も起きていない」この語り口を持てるかどうかが、設計者としての言語力だと思っています。

仕組みが組織に馴染みすぎて見えなくなったとき、それは設計の勝利です。だからこそ、その勝利を自分自身が記録しておく必要があります。
誰かに見えなくても、自分には見える。その確信を持ちながら、次の設計に向かいます。

#BizOps #組織設計 #業務改善 #電子契約 #キャリア設計

なぜ着地見込みはズレるのか？予測精度を改善したBizOpsの実践録
設計の成果を可視化する手法に関心が向いた方に。予測と記録を組み合わせて「成果の証明」を設計するBizOpsの実践論として、本記事と合わせて読むと理解が深まります。

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