2009年12月06日

会社と社員の関係(会社の辞め方 総括)

以前アメリカで2年働いた経験があるが、カナダのベンチャー企業で2年ほど働いてみて、これはまた色々と学ぶことがあった。

カナダの会社ではリストラで1/3の社員のクビを切るというのも大変な経験であった。それまで行け行けで来ただけに、一生懸命がんばっている社員をばっさり切る様子は信じ難いものであった。
(株式公開してキャッシュは十分にあったのに、である。なんと、その後シリコンバレーのベンチャーを買収する余裕があった。)
リストラを受けた辛そう社員たちの表情がしばらく頭から離れなかったが、直後にオフィス近くの寿司屋でCEOとCTOが楽しそうに寿司を(当然経費で)食っているのを目撃したときには、会社への忠誠心は完全に無くなった。

日本のある営業担当は、非常に成績がよかったが、口が悪く本社に対してずけずけとものを言うタイプであった。会社のためを思っての発言ではあったので、みんな言うことを聞いていたが、本社からは実は嫌われていた。
この人は結果を出していたのだが、このリストラであっさりクビになった。

日本のあるセールスエンジニアはすごい働きっぷりだった。朝から夜中まで、週末も含めて何年もまったく休みなく働いていた(勿論残業代や休日手当てなどない)。おかげで日本のクライアントからは非常に好評であった。
ここまで会社のためにがんばるって凄いと私も思っていた。彼はそのリストラは乗り越えたが、その後本社のマネージャーと喧嘩になった後、日本の売り上げ低下の理由にされてクビになった。

これらの経験は私にとっても相当ショックであった。あそこまで必死に働いてくれる人間をこうも簡単にクビにするのかと。
日本市場での失敗は本社の判断ミスにあったわけで、彼らの必死の提言をもっとちゃんと汲んでやるべきだったという思いが私にもあった。こうなってくると会社への猜疑心は深まるばかりだ。

勿論、ここはCEOやCTOが作った会社であり、彼らの集めた金であるためそれを自由に使うのは彼らの権利であろう。雇われ社員はいくら騒いでも駒にすぎないことを実感した。(これはまあ、日本も北米も同じか。)

そういう状況で、日本関係の残務処理をすべて押し付けられた私としては、辞めるときに一矢報いてやれて本当にうれしかった。

そこで改めて思うのは、会社も社員も非常にドライな関係であるということだ。
家族を犠牲にして、自分を殺してまで会社のために尽くす人はほとんど見たことがないし、いても前述の日本人たちのように、だめと見なされるとあっけなくクビとなる。

会社は必要な人材を必要なときに集めて使う。要らなくなったら切る。それだけだ。切るときのために、契約書は会社に有利な内容になっている。それを目くじら立てていると採用されないだけである。
カナダの社員は、会社のそういうアプローチを知っているので、普段から会社からの要求以上のことに深入りしないし、会社に人生を預けたりしない。
そこにあるのは給料、ストックオプション、プロモーションへの期待である。出世すれば次の会社でいいポジションに着きやすいというだけだ。

Javaの有名なフレームワークにSpring Framework(JBoss Seamも)というのがある。オブジェクト間の結合関係を弱くして、変更、追加を容易にするデザインパターンがベースにある。

1. 以前のJavaのコードでは必要な機能を、その機能を使いたい人が、呼び出して、利用するという流れが普通だった。
conventional.jpg
2. SpringによってDI(Dependency Injection)が可能になり、必要な機能を必要に応じて変更、追加して注入することが可能になったのである。
injection.jpg
(Spring in Actionより)

ここで思ったのは、日本企業の雇用スタイルは今でも1が主流であり、北米企業は2が主流になっているのだ。

1では社員オブジェクトの実装手順やロジックを作り上げるのも会社オブジェクトの仕事なのである。依存関係は深くなり、取替えは難しくなる。そのため全然違う機能を無理やり追加実装して、スパゲティコードになるリスクもある。ユニットテスト(評価)もしにくい。

2の雇用関係では会社と社員の間にあるのはインターフェース(契約書)だけということになる。社員クラスのインターフェースには
createProduct()
sellProduct()
などのメソッドがあるだけで、その実装自体は使う側は気にすることはない。テストもしやすい。

2の仕組みはまだまだ日本では受け入れにくいだろうが、北米ではうまく回っているし、滅私奉公によって死ぬような思い(を強制されること)にもならない。
個人は自分のインターフェース(=スペシャルティ)がはっきりしているので、他の会社オブジェクトからも使いやすい(転職しやすい)。

一方で1の会社オブジェクトべったりの社員オブジェクトは機能も不明確であり、会社特有の機能に依存していたりしているため、再利用は難しくなる。精々35歳以下という会社依存性の高い実装が少ない場合だけ、再利用可能となる。

会社の業績がいいとき(ソフトウェアが要求仕様を満たしているとき)は、1も2も大して変わらないが、業績が傾く(仕様変更が必要になる)と1は硬直化していて動きがとれなくなる。そのしわ寄せが社員オブジェクトへかかるのである。(エンジニアに営業とか。)
2は会社にとっても社員(と家族)の幸せのためにも、柔軟で対応しやすい仕組みだと言える。

そのためにはインターフェースの定義(契約書、ジョブディスクリプション)とその正しい運用(誤用されたら辞める、訴える)が重要であることは言うまでもないし、社員オブジェクト側も会社オブジェクトに対して、対等に独立したオブジェクト(POJO)として振舞うことが重要なのである。そこで、会社と対等にやりあう手段が弁護士だったりする。(会社側は当然弁護士を雇っていて、解雇に関して不利にならないように条件をつけている。)

成熟した社会においては、このLoose Couplingがベースになっていることを理解し、振舞うことが重要なのかもしれない。ソフトも就職も。

Spring in Action

1933988134
Spring2.0入門 Java・オープンソース・Web開発自由自在

4774130001
JBoss徹底活用ガイド ーJava・オープンソース・JBoss Seam・JBoss AS

4774133795


posted by りもじろう at 03:25 | Comment(3) | TrackBack(1) | カナダの生活 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
うまい例えですね。でもプログラマにしか分からないかも。
Posted by プログラマ at 2009年12月06日 12:10
程度の差こそあれ、外資でも内資でも
「太鼓持ちスキル」「嫌われないスキル」
はまあ、必要ですよね…。
Posted by @ at 2009年12月06日 13:35
面白かったです。僕はここ10年間クラウドコンピュティング環境でXML-RPCのAPIを提供している状態でした。社員も会社もお互いのビジネスモデルをよく理解しないでことを進めてしまうと大変ですからね。:)
Posted by ビル at 2009年12月09日 10:58
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック

こういう文章がやっとでてきた
Excerpt: 1では社員オブジェクトの実装手順やロジックを作り上げるのも会社オブジェクトの仕事なのである。依存関係は深くなり、取替えは難しくなる。そのため全然違う機能を無理やり追加実装して、スパゲティコードになる..
Weblog: 野球、西武、携帯関連、IT全般、アニメ、鉄道、車、その他雑文を気ままに書くところ
Tracked: 2009-12-06 23:30
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。