◎人類のジレンマ
ゲーム理論で有名な「囚人のジレンマ」問題を心理テストに応用してみよう。これもここのコラムで最高の参照数を誇る「ウサギとカメ」（id:kido:20040424）の心理テスト同様、かなり使えるものだと思う。
というより、このテストをやると結果にかなり動揺するだろう。
なぜなら、「檻の中のライオンはあなたの性欲を表しています」というような「まるで実感のわかない深層心理の暗喩」などではないからだ。
◎あなたは共犯とともに投獄された囚人である。
しかし、警察はあなたが犯した別件の証拠は持っていない。
今、バレているのは軽い罪の犯罪だけ。
尋問中に警察はこのような司法取引を持ちかける。
「もし、共犯者のやったことをすべて暴露したら、
無罪で釈放してやろう」
共犯者も同じ取引をもちかけられているに違いない。
二人がシラを切りとおせば１年程度の刑で済む。
相手だけが自分を売れば、自分だけが有罪になる。
この場合あなたは酌量の余地無しで５年の刑になる。
二人が同時に相手を売れば、二人とも有罪になる。
ただしこの場合は罪を認めて酌量され２年の刑となる。さて、あなたならどうするか？
答えが出たら、覚悟して先を読んで欲しい。
この心理テストは、人が信義というものをどのように見ているかがわかるということだ。そのものずばりだから、暗喩でもなんでもない。
自分は信義を守り、相手も守る、と固く信じている人は迷わず「シラを切る」を選択するだろう。もしも、相手に売られたとしても、自分は信義を守ったことに満足して５年の刑期を過ごせると思っているはずだ。
自分は相手を裏切るし、相手も同程度に自分を裏切ると思う人は「裏切り」を選択するだろう。相手がもし自分の予想に反して「信義を守る人」だったとしても、「自分だけ無罪になれれば相手のそんな幻想はなんでもない」のである。
信義とは幻想でないと思えば、それは決して幻想ではなく、５年もの刑期を進んで受けられるほど美しいものなのだ。
しかし、信義は幻想だと思えば、単なる幻想なのである。
あなたは、今日、自分の信義というものに決着をつけてしまった。あなたの世界に信義は存在するかしないか。それはわたしの知ったことではないが、あなたの世界は今、決定されてしまったのだ。
もう２度と迷ったりしないでいい。
さて、今日の本題は「あなたの世界における信義」などというわたしにとってどうでもいいことではなく、ゲーム理論というあなたにとってはどうでもいい話なのである。
ただし、ここで正確にゲーム理論での「囚人のジレンマ」を解説しているわけでも、正しく応用しているわけでもない。
というか、意図的な曲解なので、正確な情報は
http://www.ssc.upenn.edu/polisci/prisoner/japan/jpdframe.htm
などを参照して欲しい。
そろそろタネを明かそう。
二人の囚人をひとつのチームとしてみよう。
この場合、互いにシラを切った場合のチームの刑期２年（１＋１）は、すべての組み合わせの中で一番短い。チームとしては絶対に相手を裏切るべきではないのだ。
しかし、個人として見れば、相手を裏切るのが一番いい。相手がどう出るかまったくわからないとして、こちらが一方的に裏切った場合は０年、運悪く相手も裏切った場合２年。よってこの戦略の期待値は１年になる。
一方、相手を信じて互いにシラを切り通した場合１年、相手を信じて裏切られた場合は５年なので、相手がどうでるかわからない場合、信じる戦略の期待値は３年になる。
であるなら裏切ることに疑問の余地はない。
しかし、個人がそのように考えると、結果として互いに裏切り、お互いしめし会わせたチームの方が刑期が短い。そこで、前段のチーム戦略に戻って堂々巡りをしてしまう。
これが「囚人のジレンマ」のジレンマたるゆえんだ。
そもそも囚人のジレンマには前提があって、常に協調しあうひとだけが住む世界の結果は常に２年、どちらかが裏切りどちらかが必ずバカを見る世界の刑期は平均して２．５年になる。だから協調した方がトクとなる（協調優位幻想）。と、そして同時に、信じる相手を一方的に裏切るのが一番トク、次に互いに協調するのがトク、次に互いに裏切りあうのはイーブン、一方的に裏切られるのが一番ソン、という前提「エゴ優位幻想」。この二つの幻想が同時に両立した場合に発生するのだ。
これは人類が持つそもそもの矛盾した幻想である。
前提をいじって、自分が信じて裏切られた場合の刑期がもし５年でなく３年だったら、を考えてみよう。
時に裏切り、時に裏切られたとしても、平均すると１．５年の刑期になる。すると常に互いが信じ合う２年の刑期よりトクになり、もはや誰も「相手と気持ちが通じたらいいな」とは思わない。そんな世界では、誰でも「一方的に裏切る」ことを選ぶので結果、いつも「互いに裏切る」結果になる。
よってこの世界にジレンマは生じない。
また、一方的に裏切るのが、協調するより刑期が長ければ、お互いに常に協調していた方がトクになる。ここでもジレンマは生じない。
また、一方的に信じて運良く相手に裏切られたとき無罪になるなら、もちろん誰も裏切ろうとはしない。
さらに、互いに裏切りあう方が、どちらかが裏切るより刑期が短ければ、つねに「協調して裏切りあう」。
つまり、囚人のジレンマは前提が結果を規定しているのだ。
なぜ、この世がお互いさまであり、しかもしばしばエゴをつらぬく人が一番得なのかは、まさにこの前提に人類全体が固執して全員でジレンマの泥濘に囚われているからなのである。
協調幻想とエゴ幻想。どちらかが正しくどちらかが間違いであるとするならば、ジレンマは消え、答えはいつもひとつになる、ということだ。これについてはそれぞれの組み合わせをじっくり考えて欲しい。
「協調するよりお互い同時に裏切った方がトク」あるいは「エゴを貫けば結局ソン」などと人類が思い込めば、矛盾のない別の世界がそこにある、ということだ。
経営についての考察６
またまた、しごくしごくあたりまえなことを書かなければならない。なのだが、ほんとに、できてない会社が多すぎると思うのだ。
まぁ、儲かってる会社ってのはあんまりいじりたくないし、儲かってない会社ってのは、中をいじるまえに存在価値についてじっくり考えるべきなのかも知れないが。
一応お断りしておくと、わたしの会社は、ある業種のある専門分野ではシェアが県でＮｏ．２くらいのところにいる。もしかしたら、もう１位かもしれない。このシコーノカテーを書き始めたころはベスト５にいるかどうかだった。
ちょっとは「読もうかな？」という気になっただろうか？
そういう人は、幸福の財布なんかの実例に弱いので気をつけたほうがいいかも知れない。
フローをきちんと把握していると、それはＩＮＰＵＴからＯＵＴＰＵＴまで結局は一本の線になることがわかるだろう。
ところが、それぞれの専門部署では、毎日毎日同じことをやっている。フローは一本道なのだが、それを処理するところはいくつかのフローの束を同時に扱い、まとめて加工し、次の部署に手渡している。この繰り返し作業をルーチンという。
◎ルーチンを最小化し、高速化せよ。
ルーチンというのは、繰り返し処理のことだ。
プログラムのルーチン処理の中にある変数を毎回比較するプロセスが含まれているとする、しかし、その変数はルーチンに入る前に決定されているとしたら、変数の比較はルーチンに入る前にたった一回行えばすむことである。ルーチンの中で毎回行う必要はない。ルーチンの中に余分な仕事を入れない、というのはプログラミングの初歩中の初歩なのである。
ルーチンワークというのを反復して単調な仕事という悪いイメージだけで捉えてしまいがちだが、どんな仕事にもルーチンは存在する。ルーチン一回転ごとに別の部署に書類がまわり、そこでもルーチンが独自に回っていて、それが完了しない限りはじめのルーチンは完結しない。そのようになっているので、ルーチンの存在そのものに気がつかない経営者が多い。
例えば、ある人は経理、ある人は発注担当、ある人は営業の補佐のように一見それぞれの作業が分離しているように見える場合でも、フローをたどっていくとそれがひとつのルーチンになっている。受注から発注、経理までが数分で流れていないというのは、そもそもおかしい。必ずひとつのルーチンになっているはずであるし、そうなっていなければ、恐ろしく時間がかかっているはずである。
このような場合、最短で行わなければならないフローにすべての回転をあわせることが重要だ。
すべての作業をひとつのルーチンの輪の中にまとめあげ、ルーチンの中に不要な作業をルーチンの前後に配置しなおして、ルーチンを最小化するのである。
ある事務仕事をする部署では、同時に会社に掛かってくる電話の応対もしているとしよう。その机にはＡ、Ｂ、Ｃの事務員がいて、３人は分担して流れ作業で仕事をしている。これは、事務員に仕事を一度に覚えさせるのがたいへんなので、君はここまで、あなたは続きからここまで、と順次に仕事を教えてそのまま固定してしまうことによってよく発生する。その作業中に電話がなり、誰かが何かを言いつけられて席を立つと、とたんにその下流の仕事がヒマになる。そこで利口な管理者は、ルーチンの流れを守るために電話を取る専門のＤさんを雇う。これで処理はスムーズに流れていく。
というのは、間違いである。
管理者はルーチンを最小化しなければならない。
プログラムで言えば、行数を減らすとか、作業時間を短くするということになるが、ひとつのルーチンが行う多くの処理を小さなルーチンに分散させることもひとつの手段である。これを並列処理と言う。
Ａ、Ｂ、Ｃそれぞれに完結するまでの仕事をすべて教え、一番作業効率の悪い人が電話を取ればよい。たぶん、Ａ、Ｂ、Ｃ、Ｄの流れ作業より効率はよくなるはずである。また流れ作業には誰かが休むと仕事がまわらないということもよく起こる。このようなリスクとロスも１/４に抑えることができるのだ。
経営についての考察５
つらい。
自分の書いたものを読み返す悪癖のあるわたしには今回のシリーズは大失敗だったかも知れない。と書きつつ、はじめからつらいと投げて書いていることに気づいた。ちょっとはおもしろく書こうと努力しなければと思う。
会社がまがりなりにも動き出し、フローのロジックには当面いじるべきところがない。売り上げは伸びている（でなければフローか仕事そのもののどちらかを捨てなければならない）。
それでも更に効率を上げなければならない。
プログラムで言えば、フローとロジックの大部分は完成した。その後には必ずチューニングが必要となる。たいていのプログラムは、できたばかりの時は、ロジックとフローが「理想的（あるいは概念的）」すぎて動作が遅く実用に耐えない。それでも人が扱うよりはるかにスケーラブルなシステムになっているので、しばらくはもつ。ただし、その時間は短い。許容量を超える前にチューニングが必要だ。
◎ボトルネックを探し、解消せよ。
ソフトウェアが遅いとき、まずどの動作が一番遅いのかをつきとめ、スピードの速い代替方法を検討する。ソフトウェアがその動作を必ず必要とするとき、ボトルネック＝ソフトの限界性能となるからだ。ＴＯＣ流に言えばボトルネックは「制約条件」となる。
会社経営では、最も非効率な場所（制約条件）＝会社の最大効率となる。
ボトルネックには、物理的、構造的なボトルネックと、論理的、精神的なボトルネックがある。
物理的、構造的ボトルネックを発見する作業は比較的簡単で、論理的、精神的ボトルネックを発見するのは難しい。
物理的、構造的ボトルネックは、必ずフローの中にあるが、論理的、精神的ボトルネックはフローの中にあるとは限らないからだ。
この方法はダメ、試す価値はない、と考えるのが最大の心理的ボトルネックである。
ソフトウェアでは書いてあるプログラムの行数と処理時間が必ずしも一致しない。ある一定のルーチンだけがやたらと反応速度を遅くしている場合で、しかもそのルーチンがフローの中のいろいろな場所からコールされていると、うわべだけのトレースでは処理時間の遅さの原因がわからない。こんなときは、すべてのルーチンにステップインして細部までフローをたどる必要がある。
それでもシステムコールなどステップインできない深部に原因が潜むこともある。こんなときは、怪しい部分だけを時間測定したり、怪しい部分をスキップして作業時間を比較するなど、観察だけに頼らず推論と検証を繰り返し行う必要がある。
また、人がものを考えるときのロジックが必ずしもプログラムとして正しいとは限らない。ソフトウェアもちょっとした考え方の変更で驚くほど効率のいいロジックを見つけられたりして、論理的、心理的なボトルネックの解消は重要だ。
現実の会社をチューニングするときにも、この観点は実に重要なのだ。
それにしても、まずフローを徹底的にあぶり出し、把握しておく必要があるのだ。そして、その前には管理者が理解しているフローが現実とマッチしていなければならない。往々にして、管理者が思い描くフローは単なる妄想だったりする。これは心理的ボトルネックである。
もし、明らかに仕事が滞っている物理的な場所が見つかれば話が簡単だ。しかし、そういった部分は目立つので人員を配置したり、機械を入れたり、手続きを簡略化したりして流れをスムーズにすることができる。これは誰でもできることである。これが物理的ボトルネックである。
ＩＮＰＵＴを３に増やしてもＯＵＴＰＵＴが１のまま増えない。こんなとき、フローのどこかまでは増えていて、どこかから増えなければ、作業量が増えないすぐ上流にボトルネックがある。
ＩＮＰＵＴ近くが３にチューニングされていると、１を流したときヒマになる。管理者はこれを嫌うのでその部署の人を他へ再配置する。このような最適化の結果、３流した仕事が途中で２．５になり、２になり、１．５になる。これは心理的ボトルネックである。
心理的ボトルネックが物理的ボトルネックを完全に隠蔽してしまうことがある。そもそも、どこかにボトルネックがあるから３流せないのだ。どこかにボトルネックがあるときでも、ボトルネックの所在がはっきりするまでは、他の部署で余力があるからと言って気安く再配置はしてはいけない。
ある仕事が終わると必ず管理者に報告しなければならないとしよう。その管理者本人が現場でフローのチェックをしているときには、その報告が目前で行われるので誰もボトルネックに気がつかない。笑い話のような話だが、多くのボトルネックの原因が管理者であることは事実だ。そして、そんな場合必ずといっていいほど管理者はそれを必要悪と決め付けてしまう。これも心理的なボトルネックである。
１００個の部品を一度に加工してしまう大型の機械があるとしよう。その上流では必死になって部品を流しているが、１００の部品が溜まるまでその機械は動かない。一回その機械が動くと下流に一度に１００個の部品が流れる。その下流の機械が部品をひとつづつ加工していたらそのスーパーマシンの存在価値はまったく無駄になる。無駄どころか、上流でスーパーマシンが一回稼動するまで下流ではヒマである。部分最適化は必ずしも全体の最適化に寄与しない。
事務処理の場合もこのような「バッチ（単位量）」の不整合が物理的ボトルネックになることが往々にある。
ある仕事があって、それは急を要しないとき、そして発生がわずかなとき、作業手順を考える者は必ずその作業をある程度ためてから仕事をさせようとする。毎週水曜日は○○をやる日。という具合だ。それなら忘れないし、管理も楽だからだ。
これは２重の意味で非常に危険である。ひとつにはバッチの不整合を起こす可能性がるということ。もうひとつには別の作業のボトルネックの原因になる可能性があるということ。
このような習慣になると、水曜日はその仕事のために時間を空けなければならなくなる。その結果、前後の日に他の仕事を押し分けることになる。この仕事量の波が別の場所で「待ち」や「破綻」を招くきっかけになったりする。
ある仕事のフローが別の仕事のボトルネックの原因になる。
これは構造的ボトルネックである。
これらの例は製造業ではあまりに陳腐なことばかりだ。しかし事務を主体とする職場ではおどろくほどこれらの常識が無視されている。製造業の製造現場はすばらしいのに同じ製造業の事務がダメということはよくある。
実際には、事務を主体とする業種ほど、この点を改善するだけで劇的な効果が得られる。
なぜなら、生産工場には敷地や倉庫、輸送や資金などハード面のさまざまな限界があるが、事務処理は物質的な限界に囚われることが少ないので、効率向上の効果が大きいのだ。
経営についての考察４
わたしのこのシリーズは果たして「新規開業」のためのものだろうか、それとも、すでに稼動している会社をファインチューニングするためのものだろうか。
実は、書きながらそれらが明確ではないなぁと気づいている。
まぁ、シリーズといいながらも、部分的にあるいは感覚的に適当に応用すればいいのではないか、と思う。少なくとも一流会社の作り方や、カルロス・ゴーンのようなことが簡単にできるとは思っていない。
どこにでもある企業の若旦那が、ちょっとくらい会社について考えてみたいけど難しい経営手法はうちの商売に応用できるとは思えんし、いらんしなー、程度の要求に多少のヒントにでもなれば十分、といったところか。
今回は、「いかにも」というお題目で、耳にタコかも知れない。しかし、わたしの会社はこの部分がきっかけで大きく様変わりし、そこから成長をはじめたのだ。
特に、わたしが取り上げることはほとんど投資が必要のないことばかりなのにぜひ注目して欲しい。単なる発想の転換だけなのだ。
どんな会社にも作業の流れというのがある。
発注がなければ出荷はないし、営業活動をしなければ注文は来ない。自分の会社の作業フローを徹底的に洗い出して図式してみることが重要だ。例えば、経営者は意識したこともないのに、実はある命令が出ないとある作業ははじまらない、というキーイベントがいくつかあったりする。作業手順を変更することで思ってもみなかった新しい作業フローが発見できるかも知れない。
このような業界の慣例を無視した作業フローからはじまる新しい経営スタイルが、小さな差別化を生むことになる。
◎作業フローを洗い出せ
ある会社の営業の作業フローはこうなっている。
商品の選択→広告作成→チェック→広告→（客からの問い合わせ）→応対
このすべてをベテラン営業がエリアごとに個々別々に行っていた。営業が直接行っていないのは広告の作成だけだった。そして、経営者はなぜこんなにも広告の効率が悪いのかを考えていた。実際に広告は頻繁に赤字を出していて、いつどのタイミングで広告するか営業も極度に神経質になっていた。当然だが、広告による成果は営業の経験と勘の成果と考えられ、ヒットを飛ばす営業に報酬をまわすため、ヒットを飛ばせない営業には給料が払えなくなった。
結果として、歩合制の会社とならざるを得なかった。
結果が悪いと強く叱責されるので、結果が悪ければ悪いほど、広告は間遠になり、会社全体の売り上げはいつも低迷する。
ここで、経営者は延々と続けられてきた作業フローに疑問を感じ始める。
なぜなら、経営者はプログラミングの基礎を知っていたからだ。
プログラミングではいつも必ずフローを考える。それは適切な答えを出すために、まわり道や無駄な作業をしないためである。
プログラムが行うべき内部ルーチンとユーザーが決定すべきイベントは交互に適切なタイミングで交わらなければならない。ユーザーが予期しない先の作業まで一気に行ってしまうプログラムや、あまりにも頻繁にユーザーに問い合わせを行うプログラムは存在価値が低い。
自分の会社は一方的に作業を進めすぎていないだろうか？
その結果、思い違いをしてしまっていないだろうか？
そしてユーザーの意向を見落としていないだろうか？
なんとなくそんな気がしてきた。
そこで、綿密に作業フローを検証してみるといろいろ新しいことがわかった。商品情報は主に営業の開拓した仕入先からの情報に頼っていた。ほかにも業界紙や知らない会社からのパンフレットはあったが、それらを利用することはあまりなかった。また、商品の選択は季節や前回の売れ筋などから営業が決定していた。営業は、イチオシ商品の見栄えをよくするために、紙面の多くを一品に費やした。広告の作成はデザイナーにやらせていたが、これにも営業がいろいろと口を出していた。
なにしろ、営業は歩合なので、作業すべてに関わらずにはいられなかったのだ。結果的に、仕入先はこちらの要望を組んでくれる気心が知れた相手とのつきあいを優先せざるを得なかった。社内のことに目が離せないので、出荷にミスがあるかも知れない新規の仕入れ先や独自のルールで販売ロットを決定する仕入先は極度に敬遠された。
広告すると、必ず「広告に載っていた以外でこんな商品はないか？」という問い合わせが発生し、広告商品への問い合わせがあっても結局希望に沿わないためのキャンセルも多かった。他商品への問い合わせやキャンセルのとき口八丁手八丁で自社の取り扱い商品を買わせてしまうのも、営業の手腕として評価された。
作業フロー図を見ていた経営者は単純なことに気がついた。
商品の選択の先になにか見落としているのではないか？
選択の幅がせばまれば広告の内容は充実しない。結果として客が要望する商品をラインナップできない。それが「こんな商品はないのか」という問い合わせやキャンセルにつながっている。もしも、十分に情報収集して、それらの情報を管理することに営業が経験と勘を生かしたら？
そこで、営業に仕入先を固定させることを禁じ、商品を選択することを禁じ、デザイナーに注文をつけさせることを禁じ、客に問い合わせ商品以外の商品を売りつけることを禁じた。
その代わりに歩合制を廃止し、営業には商品の品質の管理と新規仕入先の開拓、仕入先との打ち合わせを徹底させた。
広告のラインナップに載せるのは新規商品と前回の問い合わせ数の上位ランキング（掲載していない商品も含め）から一定のルールで選択した。この方法なら経験も勘もいらないので、パートにも選択できた。選択ルールが簡単だし、商品と仕入れに営業が目を光らせているので、商品ラインナップを数倍に増やしても広告の作成作業や仕入れ出荷作業は滞ることはなかった。事実上、客に広告を編集させているのだから客の反響がよくなって当然だった。
問い合わせ数はすぐに数倍になり、営業が手八丁口八丁を使わなくても、客は希望どおりの商品を買っていった。
そこで、広告の回数は売り上げでいちいち加減せず、短期の赤字は無視して常に定期的に入れることにした。その結果、他の同業者が広告する数倍のサイクルで広告を打つことが可能になった。新商品情報はもっとも早く提供でき、知名度が徐々にあがりはじめ、昔ながらのサイクルで広告する他の同業者の売り上げは見る見る減っていった。
情報の収集→仕入れ先の新規開拓→商品と仕入れ先の調査→（顧客による選別）→広告→（問い合わせ）→応対
最終的な営業の作業フローはこうなった。
経営についての考察３
いまさらながら、今回のシリーズのタイトル。
大失敗。ｗ
実は、このシリーズの中で唯一きちんと文章化できる自信がないのが、今回の部分である。
組織作りというのは、データ構造の構築に非常に似ている。
少なくともわたしはそう思い、その認識で組織化をしている。そしておおむねうまくいっている、と思う。しかし、それを言葉で説明しようとするといつも壁に阻まれる。わたしの中のイメージはかなり明確なのだが、説明しようとするとみんなわからないという顔になってしまう。
なんとか文章化できればいいのだが。
あるデータの塊にあたらしいデータをちょっと付随させるだけでほとんどのプログラムは破綻をきたし、すべて作り直さなければならなくなる。２０００年問題を忘れたわけではあるまい。西暦を下二桁しか表現していなかったプログラムはほとんどが４桁に改造されるときプログラム全体に及ぶ大幅な改編を余儀なくされた。
組織の編成もこれと同じで、一度できてしまったものはなかなか改変できない。というより、その組織構造の中で仕事をすることに人が慣らされてしまう。
組織やシステムに原因があるのに、組織構造やシステムロジックを妄信し見直すことをしようとしないと、多くの場合、うまくいかない原因は簡単に人のせいに転嫁されてしまう。マルクス-レーニン主義などがいい例である。
◎データ構造から構築せよ
データ構造にはデータと構造があればよいのか？
答えは違う。
データ構造には「目的」と「未来」が伴わなければならない。
あるテーブルには何十という記入項目があるが、そのすべてを使うデータはまれにしか流れてこないとしたら、テーブルをいくつかにわけて親子関係を定義することでデータ容量を劇的に圧縮できる。これには、データの利用目的と将来の変化を先に織り込んだ構造にしておくことが重要なのだ。
そして、どのような複雑なデータもたった３つのプロセスによって構造化することができる。
これをデータの正規化という。
会社にとってデータ構造とは何か。
それは組織構造である。
データ構造構築のテクニックを応用して組織の構造について考えてみる。
１次正規化 繰り返しを排除する
ここに伝票テーブルがある。ひとつのレコードには伝票番号、日付、商品名１、商品価格１、商品名２、商品価格２、商品名３、商品価格３、合計、というフィールドがある。これだと、一度に出荷できるのは３つの商品までという制約が発生するし、ひとつの商品だけを出荷すると残りのフィールドが使われないままになってしまう。
そこで伝票番号、日付、合計という伝票テーブルと伝票番号、商品名、価格、という伝票明細テーブルに分離する。伝票明細テーブルは同じ伝票番号でグループ化されるので、いくつの商品を出荷するかは自由にあとで決めることができる。そして、伝票明細は伝票テーブルの伝票番号で管理する。
これを組織構造に応用して考えてみる。支店には必ず営業１課と営業２課と営業３課がある、という枠組みが優先されたらいかにひどい組織になってしまうかは誰でも想像がつく。
また同じような部署が複数存在するとき、それぞれに独自権限を認めず、マネージャーが統括する。各部署にはサブマネージャーを置くが、それは権限を持たない。マネージャーが管理する組織の数には枠組みを設けずマネージャーの管理能力や支店のシェアなどによって柔軟に調整する。
この第一段階で失敗する会社はあまりないかもしれない。
２次正規化 キー項目での分離をする
伝票明細テーブルの商品名、価格、には同じ商品と価格が何度も入力されるだろう。一日に数百枚の伝票が処理される中で、突然商品の名前が変更されたらどうなるだろうか。すべての伝票明細の商品名を書き直さなければならない。
そこで、伝票明細テーブルには伝票番号、商品コードだけを入力しておく。商品コードは商品テーブルで管理する。商品テーブルには、商品コード、商品名、価格というフィールドがある。これで商品名が変更されても商品テーブルを変更するだけで済む。データを分離して管理すると、変更が簡単だ、ということだ。
営業１課と営業２課と営業３課それぞれにデザイナーがいたとして、デザインの雛形や技術が別々に蓄積されていたら、デザイナーをまとめてデザイン部を作るべきである。雛形や技術の使いまわしによって、無駄な時間を排除しクオリティを最大に保つことが同時にできる。
３次正規化 キーによる間接分類をする
あるとき、商品の中でも家電製品の月間売り上げを合計してみたくなるかも知れない。このとき伝票明細テーブルに商品コード、商品区分コードとを入力したらどうだろうか？これでも毎月の商品区分ごとの合計は出せる。が、毎回商品区分コードをすべての伝票に入力することは非常に煩雑である。
そこで、商品テーブルに商品コード、商品名、商品価格、商品区分コードを入力する。月間の家電製品の売り上げを調べるには、まず商品テーブルの商品区分コードで家電製品だけを抽出する。次に抽出された商品テーブルの商品コードを使って伝票を抽出する。合計する作業は２段階になったが、こちらは月に一度の操作である。毎日の伝票明細に毎回区分コードを入れる手間を考えると圧倒的な省力化になる。
営業１課、営業２課、営業３課でそれぞれがデザイン部を呼びつけてデザイン会議を行う場合がこれに対応する。このように個別対応すると会議が３回必要な上に、デザイン部には営業１課ルール、営業２課ルール、営業３課ルールとルールの多重定義が起こってしまい、無駄やヒューマンエラーの原因となる。
そこで、それぞれの部署のサブマネージャーが各部の要望を取り上げ、デザイン部で統括デザイン会議をするべきだ。このようにすればルールを単一化できるし、どのルールが正しくてどのルールが間違っているかを討論できる。
このような正規化手順で複雑なデータも必ず正規化することができる。
また、データは多次元に扱うことも可能である。
商品テーブルにはさらに「男性用品」などの性別キーを追加することもできる。これによって伝票明細を書き換えることなく男性用品の合計が簡単に計算できる。これは商品−価格がX軸だとすると商品-分類コードがY軸、商品-対応性別がZ軸と多次元にデータを扱うことでもある。
組織の中にはあらゆる場所に「文章のうまいやつ」が隠れ潜んでいる。会社でペーパーコンテンツを作成するとき、組織の平面的な枠組みを多次元化して従来の組織構造に拠らない「プロジェクトチーム」を編成することで、社内の才能を無駄なく使うことができる。
ひところ前なら、このような組織の多重化は「互いの都合を調整して会議を行うこともままならない」状況に陥る可能性があった。しかし、社内ＢＢＳなどのグループウェアを有効に使うことで時間や場所の制約を超えて共同作業を同時多発的に行うことができる。
データ構造はデータを入れる器にすぎない。しかし、不適切な器を用意するとさまざまな問題が生じてしまう。柔軟なデータ構造を構築することは、あらかじめ起こりうることをすべてを織り込んだ構造にするということだ。
場当たり的な組織増設を繰り返してつぎはぎにしてしまうと、不要な組織がいつまでもはびこり、新しい組織の再編に支障をきたす。そもそもは、柔軟な組織構造が計画に入っていないことが原因にすぎない。
不要なポストが存在しないことがあたりまえな会社に、リストラは必要ない。
経営についての考察２
しばらくつらい内容になりそうだ。
ちょっと物を知っているプログラマにも、ちょっと経営を知っている経営者にもだるい内容になるだろう。
あまりに明らかで、あまりに平易な内容になる予定だからだ。
それにどんな意味があるかはわたしにもよくわからない。
例によって無駄思考の顕在化程度のノリで書く。
ただ、わたしはいつも、あまりに明らかで、あまりに平易なものの考え方で会社を経営してきた。それでまぁまぁうまくいっている。だからそれをまとめてみたいのだ。
◎まずＩ/Ｏを検討せよ
会社もプログラム同様システムだ。
システムには必ずＩ/Ｏが備わっていなければならず、そして、目的が達成されなければならない。
ＩＮＰＵＴとＯＵＴＰＵＴこれをあわせてＩ/Ｏ（アイオー）という。
なにが入ったとき、なにが出てくるのか。
システム（会社）の中身をブラックボックスに置き換えてみよう。中で阿鼻叫喚のすったもんだが行われていようといまいと、利用者にとってすべては適切なＩ/Ｏが備わっていて、それが目的に合致するかどうかだけが重要だ。端末の向こうでサーバーがどんなことをやっていても関係ない。ただ、われわれは何かをＩＮＰＵＴしたとき、期待するＯＵＴＰＵＴが出てくることだけを望むのだ。
長い時間をかけて入力して「登録ボタン」を押したのに、「サーバーがみつかりません」という表示とともに書いたものがすべて消えるようなシステムは誰だって望まない。
プログラムを書くときは、利用者がなにを入力し、最終的になにが出てくるべきなのかを真っ先にリサーチする。
もちろん、そもそもそんなＯＵＴＰＵＴが必要かどうかも徹底的に議論される。利用を想定する人と徹底的に話し合いを行うのだ。
そして、システムをブラックボックスに置き換えてＩＮとＯＵＴを丁寧に図解していく。
しかし、会社が利用者を相手にそこまで丁寧に打ち合わせをすることはあまりない。発注方法も一方的な手順や書式を押し付け、出荷時期も入金方法も指定する。すべて中身を優先してＩ/Ｏを最適化しようと考える。これは間違いだ。あまつさえ、工場を見せて「苦節十年」と自慢する。こんな経営者はさっさと死ねばいい。
プログラムがなぜ真っ先にＩＮＰＵＴとＯＵＴＰＵＴを打ち合わせなければならないかは簡単だ。「プログラムは使われることが前提」だとプログラマは知っているからだ。
では、「会社は使われることが前提」だと知っている経営者は何人いるだろうか？
ＩＮＰＵＴとＯＵＴＰＵＴの考察はまだまだ続く。
例えば、あるＩＮＰＵＴを受けるために最適なデバイスは何か？キーボードによるコマンド入力なのか、マウスによるクリックなのか、マイクによる音声入力なのか、時代にあわせて先端の技術を取り入れながら、必ず「最適化」することを怠らないことが重要だ。ＩＮＰＵＴの最適な代替方法は常に念頭になければならない。
また、ある会社のＩＮＰＵＴがほとんど電話ばかりだとしても、電話をかけるに至る経路は様々だ。広告を見て電話をかけたり、電話帳を見て電話をかけたり、会社に紹介されたり、記事で見たり、クチコミで知ったり、商工会議所に紹介されたり、といった具合だ。これをわたしはＩＮＰＵＴチャンネルと呼んだりしているが、ことのほか他人や他の組織を経由するＩＮＰＵＴチャンネルは重要だ。それは持続性が高くコストが安い。ポジティブフィードバックを発生させるには、小さなきっかけが小さな反応を生み、小さな反応がつぎつぎに反応を生み出していかなければならない。収穫逓増を引き起こすのは、ＩＮＰＵＴチャンネルとＯＵＴＰＵＴチャンネルだけなのだ。
最新デバイスを検討するのと同じくらい、いつも新しいチャンネルの開拓に心を砕いていなければならい。
「会社の玄関を見ればその会社がわかる」知った顔でほざくコンサルは殴ってやればよい。それは起動画面を見ればソフトの出来がわかるというゲーム評論家と同等だ。ゲームソフトのヒット作で起動画面が中身より大事だったことは一度たりともないのだ。しかし、われわれはゲームの中身など実は見たことはない。中身はブラックボックスで中身に見えるのはすべてＯＵＴＰＵＴなのだ。客にもゲーマーにも目的がある。それを満足させるのがＯＵＴＰＵＴであり、なおかつ、次のＩＮＰＵＴのきっかけを作るのもＯＵＴＰＵＴなのである。
経営についての考察１
あるプログラマがわたしに言った。
「すべての経営者はシステム工学を学ぶべきだ」
プログラマに仕事を発注する経営者が、会社のシステムをまったく（システム工学的視野で）把握していない。したがって、生産されるソフトウェアに会社のプロセス部分を内蔵したものはほとんどない。
例えば、注文を受け発注をするソフトがあるが、注文をうけた商品を検索するソフトと、発注する商品を検索するソフトと、伝票を記録するソフトがセットになっているだけ、というものが多い。なぜなら、注文を受けたあと発注に至るプロセスを人間まかせにするからだ。しかし、そのプロセスこそソフト化すべき部分なのだ。
ほとんどの会社経営者は、プロセスをソフト化する、という思考方法を持っていない。
わたしは運のいいことに、今の仕事を始めてしばらくしてプログラムを独力で習得した。当時のマシンはメモリもＣＰＵクロックも限界が低く、ちょっとしたプログラムを書いただけでうんともすんとも言わなくなる。ただ単にプログラムを知っている、というだけではほとんど何も作ることはできなかった。いかにプログラムに効率よく仕事をさせるかというプログラミングテクニックの初歩の初歩から学ばなければならなかった。
それはいかに効率よく会社に仕事をさせるか、とほとんど同じテクニックなのだ。
いかに少量のリソースで最大の仕事をするか、それがシステム工学のすべてだと言っていい。
そして、それは会社というシステムを動かす上でも同じように応用できるし、結果は歴然と現れる。
これから数日、そんなことをいろいろ思いつきで書く予定である。
しかし、何よりまず先にはっきりしていることがある。
ついこの間もＩＴセミナーなるもので講演してきたのだが。
そもそもＩＴセミナーに来ている人にＩＴの効用など無駄な話である。ＩＴを社内に定着させるノウハウも、そんなノウハウは定着するまでのプロセスにすぎないからコンサルでも呼べばいい話なのである。
ＩＴとは、あるいは、会社の経営とは、すべて夢を達成するものでなければならないのだ。
ＩＴにしろ経営革新にしろ、商品開発にしろ、すべてのハードルを乗り越えるためには、苦難をやりすごすちょっとの知恵と、苦難をものともしない大きな夢が必要なのだ。
セミナー出席者に必要だったのは、後者だと思ったのだ。
夢の見方も知らないヤツに会社を経営する資格なし。
