経営についての考察5

つらい。
自分の書いたものを読み返す悪癖のあるわたしには今回のシリーズは大失敗だったかも知れない。と書きつつ、はじめからつらいと投げて書いていることに気づいた。ちょっとはおもしろく書こうと努力しなければと思う。


会社がまがりなりにも動き出し、フローのロジックには当面いじるべきところがない。売り上げは伸びている(でなければフローか仕事そのもののどちらかを捨てなければならない)。
それでも更に効率を上げなければならない。


プログラムで言えば、フローとロジックの大部分は完成した。その後には必ずチューニングが必要となる。たいていのプログラムは、できたばかりの時は、ロジックとフローが「理想的(あるいは概念的)」すぎて動作が遅く実用に耐えない。それでも人が扱うよりはるかにスケーラブルなシステムになっているので、しばらくはもつ。ただし、その時間は短い。許容量を超える前にチューニングが必要だ。


ボトルネックを探し、解消せよ。
ソフトウェアが遅いとき、まずどの動作が一番遅いのかをつきとめ、スピードの速い代替方法を検討する。ソフトウェアがその動作を必ず必要とするとき、ボトルネック=ソフトの限界性能となるからだ。TOC流に言えばボトルネックは「制約条件」となる。
会社経営では、最も非効率な場所(制約条件)=会社の最大効率となる。
ボトルネックには、物理的、構造的なボトルネックと、論理的、精神的なボトルネックがある。


物理的、構造的ボトルネックを発見する作業は比較的簡単で、論理的、精神的ボトルネックを発見するのは難しい。


物理的、構造的ボトルネックは、必ずフローの中にあるが、論理的、精神的ボトルネックはフローの中にあるとは限らないからだ。


この方法はダメ、試す価値はない、と考えるのが最大の心理的ボトルネックである。


ソフトウェアでは書いてあるプログラムの行数と処理時間が必ずしも一致しない。ある一定のルーチンだけがやたらと反応速度を遅くしている場合で、しかもそのルーチンがフローの中のいろいろな場所からコールされていると、うわべだけのトレースでは処理時間の遅さの原因がわからない。こんなときは、すべてのルーチンにステップインして細部までフローをたどる必要がある。
それでもシステムコールなどステップインできない深部に原因が潜むこともある。こんなときは、怪しい部分だけを時間測定したり、怪しい部分をスキップして作業時間を比較するなど、観察だけに頼らず推論と検証を繰り返し行う必要がある。
また、人がものを考えるときのロジックが必ずしもプログラムとして正しいとは限らない。ソフトウェアもちょっとした考え方の変更で驚くほど効率のいいロジックを見つけられたりして、論理的、心理的ボトルネックの解消は重要だ。


現実の会社をチューニングするときにも、この観点は実に重要なのだ。


それにしても、まずフローを徹底的にあぶり出し、把握しておく必要があるのだ。そして、その前には管理者が理解しているフローが現実とマッチしていなければならない。往々にして、管理者が思い描くフローは単なる妄想だったりする。これは心理的ボトルネックである。


もし、明らかに仕事が滞っている物理的な場所が見つかれば話が簡単だ。しかし、そういった部分は目立つので人員を配置したり、機械を入れたり、手続きを簡略化したりして流れをスムーズにすることができる。これは誰でもできることである。これが物理的ボトルネックである。


INPUTを3に増やしてもOUTPUTが1のまま増えない。こんなとき、フローのどこかまでは増えていて、どこかから増えなければ、作業量が増えないすぐ上流にボトルネックがある。


INPUT近くが3にチューニングされていると、1を流したときヒマになる。管理者はこれを嫌うのでその部署の人を他へ再配置する。このような最適化の結果、3流した仕事が途中で2.5になり、2になり、1.5になる。これは心理的ボトルネックである。
心理的ボトルネックが物理的ボトルネックを完全に隠蔽してしまうことがある。そもそも、どこかにボトルネックがあるから3流せないのだ。どこかにボトルネックがあるときでも、ボトルネックの所在がはっきりするまでは、他の部署で余力があるからと言って気安く再配置はしてはいけない。


ある仕事が終わると必ず管理者に報告しなければならないとしよう。その管理者本人が現場でフローのチェックをしているときには、その報告が目前で行われるので誰もボトルネックに気がつかない。笑い話のような話だが、多くのボトルネックの原因が管理者であることは事実だ。そして、そんな場合必ずといっていいほど管理者はそれを必要悪と決め付けてしまう。これも心理的ボトルネックである。


100個の部品を一度に加工してしまう大型の機械があるとしよう。その上流では必死になって部品を流しているが、100の部品が溜まるまでその機械は動かない。一回その機械が動くと下流に一度に100個の部品が流れる。その下流の機械が部品をひとつづつ加工していたらそのスーパーマシンの存在価値はまったく無駄になる。無駄どころか、上流でスーパーマシンが一回稼動するまで下流ではヒマである。部分最適化は必ずしも全体の最適化に寄与しない。


事務処理の場合もこのような「バッチ(単位量)」の不整合が物理的ボトルネックになることが往々にある。
ある仕事があって、それは急を要しないとき、そして発生がわずかなとき、作業手順を考える者は必ずその作業をある程度ためてから仕事をさせようとする。毎週水曜日は○○をやる日。という具合だ。それなら忘れないし、管理も楽だからだ。


これは2重の意味で非常に危険である。ひとつにはバッチの不整合を起こす可能性がるということ。もうひとつには別の作業のボトルネックの原因になる可能性があるということ。
このような習慣になると、水曜日はその仕事のために時間を空けなければならなくなる。その結果、前後の日に他の仕事を押し分けることになる。この仕事量の波が別の場所で「待ち」や「破綻」を招くきっかけになったりする。
ある仕事のフローが別の仕事のボトルネックの原因になる。
これは構造的ボトルネックである。


これらの例は製造業ではあまりに陳腐なことばかりだ。しかし事務を主体とする職場ではおどろくほどこれらの常識が無視されている。製造業の製造現場はすばらしいのに同じ製造業の事務がダメということはよくある。

実際には、事務を主体とする業種ほど、この点を改善するだけで劇的な効果が得られる。

なぜなら、生産工場には敷地や倉庫、輸送や資金などハード面のさまざまな限界があるが、事務処理は物質的な限界に囚われることが少ないので、効率向上の効果が大きいのだ。