以前
アメリカで2年働いた経験があるが、
カナダのベンチャー企業で2年ほど働いてみて、これはまた色々と学ぶことがあった。
カナダの会社では
リストラで1/3の社員のクビを切るというのも大変な経験であった。それまで行け行けで来ただけに、一生懸命がんばっている社員をばっさり切る様子は信じ難いものであった。
（株式公開してキャッシュは十分にあったのに、である。なんと、その後シリコンバレーのベンチャーを買収する余裕があった。）
リストラを受けた辛そう社員たちの表情がしばらく頭から離れなかったが、直後にオフィス近くの寿司屋でＣＥＯとＣＴＯが楽しそうに寿司を（当然経費で）食っているのを目撃したときには、会社への忠誠心は完全に無くなった。
日本のある営業担当は、非常に成績がよかったが、口が悪く本社に対してずけずけとものを言うタイプであった。会社のためを思っての発言ではあったので、みんな言うことを聞いていたが、本社からは実は嫌われていた。
この人は結果を出していたのだが、このリストラであっさりクビになった。
日本のあるセールスエンジニアはすごい働きっぷりだった。朝から夜中まで、週末も含めて何年もまったく休みなく働いていた（勿論残業代や休日手当てなどない）。おかげで日本のクライアントからは非常に好評であった。
ここまで会社のためにがんばるって凄いと私も思っていた。彼はそのリストラは乗り越えたが、その後本社のマネージャーと喧嘩になった後、日本の売り上げ低下の理由にされてクビになった。
これらの経験は私にとっても相当ショックであった。あそこまで必死に働いてくれる人間をこうも簡単にクビにするのかと。
日本市場での失敗は本社の判断ミスにあったわけで、彼らの必死の提言をもっとちゃんと汲んでやるべきだったという思いが私にもあった。こうなってくると会社への猜疑心は深まるばかりだ。
勿論、ここはＣＥＯやＣＴＯが作った会社であり、彼らの集めた金であるためそれを自由に使うのは彼らの権利であろう。雇われ社員はいくら騒いでも駒にすぎないことを実感した。（これはまあ、日本も北米も同じか。）
そういう状況で、日本関係の残務処理をすべて押し付けられた私としては、
辞めるときに一矢報いてやれて本当にうれしかった。
そこで改めて思うのは、会社も社員も非常にドライな関係であるということだ。
家族を犠牲にして、自分を殺してまで会社のために尽くす人はほとんど見たことがないし、いても前述の日本人たちのように、だめと見なされるとあっけなくクビとなる。
会社は必要な人材を必要なときに集めて使う。要らなくなったら切る。それだけだ。切るときのために、契約書は会社に有利な内容になっている。それを目くじら立てていると採用されないだけである。
カナダの社員は、会社のそういうアプローチを知っているので、普段から会社からの要求以上のことに深入りしないし、会社に人生を預けたりしない。
そこにあるのは給料、ストックオプション、プロモーションへの期待である。出世すれば次の会社でいいポジションに着きやすいというだけだ。
Javaの有名なフレームワークにSpring Framework（JBoss Seamも）というのがある。オブジェクト間の結合関係を弱くして、変更、追加を容易にするデザインパターンがベースにある。
1. 以前のJavaのコードでは必要な機能を、その機能を使いたい人が、呼び出して、利用するという流れが普通だった。
2. SpringによってDI(Dependency Injection)が可能になり、必要な機能を必要に応じて変更、追加して注入することが可能になったのである。
（Spring in Actionより）
ここで思ったのは、日本企業の雇用スタイルは今でも1が主流であり、北米企業は2が主流になっているのだ。
１では社員オブジェクトの実装手順やロジックを作り上げるのも会社オブジェクトの仕事なのである。依存関係は深くなり、取替えは難しくなる。そのため全然違う機能を無理やり追加実装して、スパゲティコードになるリスクもある。ユニットテスト（評価）もしにくい。
２の雇用関係では会社と社員の間にあるのはインターフェース（契約書）だけということになる。社員クラスのインターフェースには
createProduct()
sellProduct()
などのメソッドがあるだけで、その実装自体は使う側は気にすることはない。テストもしやすい。
２の仕組みはまだまだ日本では受け入れにくいだろうが、北米ではうまく回っているし、滅私奉公によって死ぬような思い（を強制されること）にもならない。
個人は自分のインターフェース（=スペシャルティ）がはっきりしているので、他の会社オブジェクトからも使いやすい（転職しやすい）。
一方で１の会社オブジェクトべったりの社員オブジェクトは機能も不明確であり、会社特有の機能に依存していたりしているため、再利用は難しくなる。精々35歳以下という会社依存性の高い実装が少ない場合だけ、再利用可能となる。
会社の業績がいいとき（ソフトウェアが要求仕様を満たしているとき）は、１も２も大して変わらないが、業績が傾く（仕様変更が必要になる）と1は硬直化していて動きがとれなくなる。そのしわ寄せが社員オブジェクトへかかるのである。（エンジニアに営業とか。）
２は会社にとっても社員（と家族）の幸せのためにも、柔軟で対応しやすい仕組みだと言える。
そのためにはインターフェースの定義（契約書、ジョブディスクリプション）とその正しい運用（誤用されたら辞める、訴える）が重要であることは言うまでもないし、社員オブジェクト側も会社オブジェクトに対して、対等に独立したオブジェクト(POJO)として振舞うことが重要なのである。そこで、会社と対等にやりあう手段が弁護士だったりする。（会社側は当然弁護士を雇っていて、解雇に関して不利にならないように条件をつけている。）
成熟した社会においては、このLoose Couplingがベースになっていることを理解し、振舞うことが重要なのかもしれない。ソフトも就職も。
