図解　システム化とアドリブのよい使い分けとは？

世の中をみると、官僚的なシステム化と現場主導のアドリブ、二つの世界観に二分されがちです。本当は両者の中間がベストなのに、どうしても片側に寄ってしまうようです。

偏る原因は、おそらく両方が得意な人が少ないため。

このためシステムとアドリブの住み分け、バランスの取り方を人に説明するのは難しいものです。僕も長く悩んでいましたが、最近、ようやく頭の中でメンタルモデル化できました。

岩として考える

システムとアドリブの特性は、以下のようにモデル化できます。システムは大きな岩。アドリブは多くの小石。

システム化：単一の大きな岩
アドリブ化：大量の小石

システムの考え方

平地にドンと置かれた大岩が安定するように、システム化は地盤がしっかりした環境で力を発揮します。また大きな問題をざっくり埋めるような、手っ取り早く80点をとるような場合にも便利です。

一方、大岩を坂道のような不安定な足場に置くと、とても危険です。不安定な環境では、まずは足場の整理が重要です。システムも同じように、不安定な環境では、最初に環境を安定させるよう意識しましょう。

たとえば、店舗ごとのニーズに差が多い場合、本体システムと別に差分を吸収するシステムを作るのがオススメです。

複雑な環境で理想的なアプローチは、環境側の方を標準化してしまうことです。ITに限らず、（制約条件がない場合には）、システム化として理想的な状態です。

変な神エクセルを延々と作り続けるよりは、パワーポイントの利用訓練をするほうがよいのです。

一方で、推奨できないアプローチは、標準化の余地を無視して、「特殊な環境に特化をしたオーダーメイドのシステムを作る」です。

システムを環境特化に設計した場合、様々な弊害があります。

環境特化オーダーシステムの短所
・コストが高い
・システムの横転用がきかない
・人材の横転用がきかない
・汎用フレームワークに維持やR&Dコストで勝てない
・環境の変化を吸収できない

どうしても環境特化のシステムを組みたい場合も、必ず特化パートを独立した別システムとして構築すべきです。

自社の独自事情にあわせて、Slackのようなものを自力開発するのは愚かなアプローチです。まずはSlackを導入してから、プラグインなどで自社独自の拡張したり、教育制度をもって社員のオペレーションを整えるとよいでしょう。

アドリブの考え方

小さな石ころや砂の集積が、柔軟に形を変えられるように、アドリブは柔軟な対応が強みです。

一方で、個々の小石が異なる形を持つように、アドリブには再現性があまりありません。このため、大きなアドリブを単発で行うのではなく、小さなアドリブを積み重ねて、総体としてバランスをとることが重要になります。

一方で、単発で大きなアドリブは、無計画な環境特化システムとほぼほぼ同じことになります。

起伏のある地形を小石や砂で埋めるように、アドリブの積み重ねは環境に例外が多い分野では有効です。数の多さが、個々の施策の当たり外れや、適不適を吸収し、統計的な総体としての問題解決が行えます。

一方で、個々の施策の効果や数字化を行うことは難しい。

システムとアドリブをどう組み合わせるのか？

では、システム化とアドリブ化のバランスをとるには、どうすべきでしょうか？ あるいは、どう棲み分けるべきでしょう？

一番シンプルなアプローチは、砂利で地面の凸凹をうめて下地を作るように、環境とシステムのズレをアドリブで吸収することです。

もう一つのアプローチは、堅牢なシステムの上に、アドリブで拡張や研究開発を行い。確定後に、それをシステム化していくアプローチです。

このようなアプローチをとれば、システム化の強みと、アドリブの柔軟性、即時性を有効に組み合わせることができます。

基幹レイヤーほどシステムが大事。表層レイヤーほどアドリブが有効。

ダメな設計では、表面のお化粧にシステム化を使い、裏側がドロドロとしたアドリブの組み合わせになりがちです。

不安定な石塔が高く積みあげられないように、このようなシステムは環境変動に弱く、横展開もできず、発展にもすぐに訪れます。

もうひとつの失敗パターンは、堅牢なシステムを構築したものの、そのうえにアドリブをひたすらに積み上げてしまったパターンです。こちらも、ちょっとした環境の変動で全てが崩れてしまいます。

長く使いすぎたシステム基盤のにおいて、定期的な汎用化やメンテナンスをサボると、このような状態に陥りがちです。アドリブは、定期的に標準化を行い、安定したシステムへと更新していきましょう。

システムとアドリブは組み合わせて真価を発揮する

以上のように、システムとアドリブはどちらが正解というわけでもなく、車輪の両輪であり、陰陽のように組み合わせることで真価が発揮されます。

ところが、世の中では両者は０か１で語られがちで、運用もどちらかに偏りがちです。

日本の企業がよくやるような、

・自社オペレーション特化しすぎたオーダーメイドを作り、普遍的なプラットフォームに敗れる
・システムをだましだまし使い、環境ルールの変動期に崩壊する
・上っ面だけシステム化して、内部運用をマンパワーと経験に頼り疲弊する

などは、どれも典型的な負けパターンです。

これは仕組み化の得意な人に、組織の仕組み化を完全に任せると、すっべてが仕組み化されてしまうためです。大きな会社は特にそうなりがち。人間は大局としてベストパフォーマンスを出すことよりも、日々の小さなトラブルを避けたがることも原因です。

たとえばnoteのイベントなどなら、イベントの告知や運用フローは標準化してシステムに落とす。登壇ゲスト毎のモチベーションコントロールや、当日の例外トラブル、盛り上げのための合いの手などはアドリブ運用…といったように、固定的で繰り返す基盤はシステムに、環境要因で変動しがちなものはアドリブ…という見極めが大事です。

結局は両者は、用途のちがうツールなので、どちらか片方に偏ることなく、適材適所で利用したいところです。

孫子の兵法で語られる、「正法と奇方」のくだりは、およそこのようなものなのかなと思いました。

まとめ
・システムは大きな石、アドリブは大量の小石として扱う
・アドリブで短期的な穴埋めや、勝ちパターンの模索を行い、勝ち筋を見つけ次第、システム化していく
・基幹ほどシステム化が望ましく、応用や環境との接触面はアドリブで吸収するのが望ましい。