最近Railsにはまっている。LAMP(Linux,Apache,Mysql,PHP)でソフトを開発することが多 い中、WEBDBの操作が非常に簡単にスピーディに出来るこのフレームワークに惚れた。もっともRubyという言語の楽しさもある。そこで、Railsを つかって簡単なアプリをつくってみる。

「人間若いときに苦労はするものだ」とか「若いときの苦労は買ってでもすれ」とか言う言葉がある。私はあまりこの言葉は好きではない。ようは忍耐力をつけ ろということであって、苦労の末、破綻することだって多いのだ。また、苦労の末、頂上的成功者になるのだったらわかるが、そこそこの成功を収める場合(企 業内で言えば、役員や部長になった程度)は始末が悪い。若いときの苦労をし過ぎた者でそれが自分の位置の維持に多大なエネルギーを費やし有能な若者をだめ にしてきている例を多く知っている。つまり、新たな知識を自ら学び続けるのではなく、「黙って人を動かす法」とか「戦国武将に学ぶ」的なHowTo本で武 装し、その方法を実践する。研究開発よりは陰謀屋とか策士になってしまい、若い連中を自分の管理下においてしまう。
ある企業でニューリーダープロ ジェクトなる組織を立ち上げた苦労人がいる。どう考えても、これらがニューリーダーなのかと疑念を感じてしまう連中を配下においている。その苦労人に反発 した者は結構策にはまって他部署や関連会社に飛ばさせている。他部署の人間はチアリーダープロジェクトと言っている。
このチアリーダープロジェク トでは何も成果が上がっていない。まあ、大政翼賛会的なもので、批判は禁止されている場合が多いのだ。批判がないとメンバーは張子のトラのように頭を縦に 振るしかない。対案は出ない。活性化はされない。そこで、今は、有名な経営者や自分の会社のトップが書いた金字塔を読んだりしている。そりゃ、中国の古典 もいいけど、秒針分歩の現代に古典趣味で戦いに向かい大本営発表をまともに聞いているだけのチームが敗れるのは目に見えている。

最近「成功事例や体験の横展開」とよく言われている。一つの成功事例を共有しようとするものだ。この考えは一見正しいとそうに思えるが、とても組織的には危険を誘発する可能性がある考え方だ。
成 功に対するこの考え方はともすると失敗を絶対させない方針となりうるからだ。ところが、現実には成功と失敗なぞは表裏一体の場合が多いのがビジネスの世界 だ。そのため、失敗を恐れるために消極的になったり、隠蔽したりする体質が生まれる場合がある。社会保険庁の納付率の改竄である。これは民間ではないから 更迭などといって実質的に責任を取らずにすむが、民間ではそうはいかない。倒産だってありうるのだ。その意味で言えば予断だが、社保庁なんか解体して民間 にするのがよい。
だからこそ、成功事例の横展開のどといって失敗を否定するのは、社長の息子で世襲で社長を受け継いだような連中や、常に成績トップで一流企業に入りそのまま出世したか、官僚になりそこそこの出世で天下るような連中が大部分であろう。
私 のセクションのメンバーには失敗経験の量と質を要求する。要領がよく、マニュアルも丁寧に読み、システムをつつがなく最短時間と手数で完成させる人間はあ まりにも必要性が乏しい。つまり、システムを構築するときに人間は間違うものだし、システム屋だってユーザーだって間違うし、その間違いの上に構築された システムは堅牢だ。間違えや失敗の連続は堅牢なシステムや組織や営業を行うことの前提条件として意味がある。隠蔽体質のもとでは花は咲かない。疲弊するの みである。失敗事例は管理され、丁寧に扱われるべきである。最後のテストでその失敗事例と照らし合わせることでよい仕事が出来る。その意味で、失敗事例な どは無いわけだ。すなわち、全ての失敗事例は仕事を成功に導くための必要不可欠な要素だということを全組織をあげて最高度の財産と考えるべきであろう。そ うした時に初めて、活気は生まれる。だから、小うるさい年長者や意地悪な管理職、上しか見ない社員だけがはびこっている組織には失敗事例を大切にする習慣 は生まれない。失敗することは成功することとどう意味であり、成功を追及し続けることは失敗し疲弊し崩壊することに他ならない。