経営についての考察３

いまさらながら、今回のシリーズのタイトル。
大失敗。ｗ

実は、このシリーズの中で唯一きちんと文章化できる自信がないのが、今回の部分である。
組織作りというのは、データ構造の構築に非常に似ている。
少なくともわたしはそう思い、その認識で組織化をしている。そしておおむねうまくいっている、と思う。しかし、それを言葉で説明しようとするといつも壁に阻まれる。わたしの中のイメージはかなり明確なのだが、説明しようとするとみんなわからないという顔になってしまう。
なんとか文章化できればいいのだが。

あるデータの塊にあたらしいデータをちょっと付随させるだけでほとんどのプログラムは破綻をきたし、すべて作り直さなければならなくなる。２０００年問題を忘れたわけではあるまい。西暦を下二桁しか表現していなかったプログラムはほとんどが４桁に改造されるときプログラム全体に及ぶ大幅な改編を余儀なくされた。
組織の編成もこれと同じで、一度できてしまったものはなかなか改変できない。というより、その組織構造の中で仕事をすることに人が慣らされてしまう。
組織やシステムに原因があるのに、組織構造やシステムロジックを妄信し見直すことをしようとしないと、多くの場合、うまくいかない原因は簡単に人のせいに転嫁されてしまう。マルクス-レーニン主義などがいい例である。

◎データ構造から構築せよ
データ構造にはデータと構造があればよいのか？
答えは違う。
データ構造には「目的」と「未来」が伴わなければならない。

あるテーブルには何十という記入項目があるが、そのすべてを使うデータはまれにしか流れてこないとしたら、テーブルをいくつかにわけて親子関係を定義することでデータ容量を劇的に圧縮できる。これには、データの利用目的と将来の変化を先に織り込んだ構造にしておくことが重要なのだ。
そして、どのような複雑なデータもたった３つのプロセスによって構造化することができる。

これをデータの正規化という。

会社にとってデータ構造とは何か。
それは組織構造である。
データ構造構築のテクニックを応用して組織の構造について考えてみる。

１次正規化　繰り返しを排除する
ここに伝票テーブルがある。ひとつのレコードには伝票番号、日付、商品名１、商品価格１、商品名２、商品価格２、商品名３、商品価格３、合計、というフィールドがある。これだと、一度に出荷できるのは３つの商品までという制約が発生するし、ひとつの商品だけを出荷すると残りのフィールドが使われないままになってしまう。
そこで伝票番号、日付、合計という伝票テーブルと伝票番号、商品名、価格、という伝票明細テーブルに分離する。伝票明細テーブルは同じ伝票番号でグループ化されるので、いくつの商品を出荷するかは自由にあとで決めることができる。そして、伝票明細は伝票テーブルの伝票番号で管理する。
これを組織構造に応用して考えてみる。支店には必ず営業１課と営業２課と営業３課がある、という枠組みが優先されたらいかにひどい組織になってしまうかは誰でも想像がつく。
また同じような部署が複数存在するとき、それぞれに独自権限を認めず、マネージャーが統括する。各部署にはサブマネージャーを置くが、それは権限を持たない。マネージャーが管理する組織の数には枠組みを設けずマネージャーの管理能力や支店のシェアなどによって柔軟に調整する。
この第一段階で失敗する会社はあまりないかもしれない。

２次正規化　キー項目での分離をする
伝票明細テーブルの商品名、価格、には同じ商品と価格が何度も入力されるだろう。一日に数百枚の伝票が処理される中で、突然商品の名前が変更されたらどうなるだろうか。すべての伝票明細の商品名を書き直さなければならない。
そこで、伝票明細テーブルには伝票番号、商品コードだけを入力しておく。商品コードは商品テーブルで管理する。商品テーブルには、商品コード、商品名、価格というフィールドがある。これで商品名が変更されても商品テーブルを変更するだけで済む。データを分離して管理すると、変更が簡単だ、ということだ。
営業１課と営業２課と営業３課それぞれにデザイナーがいたとして、デザインの雛形や技術が別々に蓄積されていたら、デザイナーをまとめてデザイン部を作るべきである。雛形や技術の使いまわしによって、無駄な時間を排除しクオリティを最大に保つことが同時にできる。

３次正規化　キーによる間接分類をする
あるとき、商品の中でも家電製品の月間売り上げを合計してみたくなるかも知れない。このとき伝票明細テーブルに商品コード、商品区分コードとを入力したらどうだろうか？これでも毎月の商品区分ごとの合計は出せる。が、毎回商品区分コードをすべての伝票に入力することは非常に煩雑である。
そこで、商品テーブルに商品コード、商品名、商品価格、商品区分コードを入力する。月間の家電製品の売り上げを調べるには、まず商品テーブルの商品区分コードで家電製品だけを抽出する。次に抽出された商品テーブルの商品コードを使って伝票を抽出する。合計する作業は２段階になったが、こちらは月に一度の操作である。毎日の伝票明細に毎回区分コードを入れる手間を考えると圧倒的な省力化になる。
営業１課、営業２課、営業３課でそれぞれがデザイン部を呼びつけてデザイン会議を行う場合がこれに対応する。このように個別対応すると会議が３回必要な上に、デザイン部には営業１課ルール、営業２課ルール、営業３課ルールとルールの多重定義が起こってしまい、無駄やヒューマンエラーの原因となる。
そこで、それぞれの部署のサブマネージャーが各部の要望を取り上げ、デザイン部で統括デザイン会議をするべきだ。このようにすればルールを単一化できるし、どのルールが正しくてどのルールが間違っているかを討論できる。

このような正規化手順で複雑なデータも必ず正規化することができる。

また、データは多次元に扱うことも可能である。

商品テーブルにはさらに「男性用品」などの性別キーを追加することもできる。これによって伝票明細を書き換えることなく男性用品の合計が簡単に計算できる。これは商品−価格がX軸だとすると商品-分類コードがY軸、商品-対応性別がZ軸と多次元にデータを扱うことでもある。
組織の中にはあらゆる場所に「文章のうまいやつ」が隠れ潜んでいる。会社でペーパーコンテンツを作成するとき、組織の平面的な枠組みを多次元化して従来の組織構造に拠らない「プロジェクトチーム」を編成することで、社内の才能を無駄なく使うことができる。
ひところ前なら、このような組織の多重化は「互いの都合を調整して会議を行うこともままならない」状況に陥る可能性があった。しかし、社内ＢＢＳなどのグループウェアを有効に使うことで時間や場所の制約を超えて共同作業を同時多発的に行うことができる。

データ構造はデータを入れる器にすぎない。しかし、不適切な器を用意するとさまざまな問題が生じてしまう。柔軟なデータ構造を構築することは、あらかじめ起こりうることをすべてを織り込んだ構造にするということだ。

場当たり的な組織増設を繰り返してつぎはぎにしてしまうと、不要な組織がいつまでもはびこり、新しい組織の再編に支障をきたす。そもそもは、柔軟な組織構造が計画に入っていないことが原因にすぎない。

不要なポストが存在しないことがあたりまえな会社に、リストラは必要ない。