前々回では、組織はなぜ息苦しくなるのか（あくまで僕の仮説）、前回では、それに対し実質的な元請企業（の社員）ならばどう対応できるかを書いてきた。

▼組織が息苦しくなる理由
http://blogs.bizmakoto.jp/toppakoh/entry/4657.html

▼実質的な元請企業（の社員）の対応策
http://blogs.bizmakoto.jp/toppakoh/entry/4665.html

今回は、実質的な下請企業の社員の対応策について書きたいと思う。

 

こんなに話がかみ合わないものか。僕は嘆息していた。

名前は仮に木下君としておこう。木下君は当時、典型的な下請ソフトハウスで働く社員だった。

彼は、ブロガーとしてもそれなりに読者を獲得していた。下請企業で働くSEの不満を、感情はできるだけ抑え（ときどき怒り狂っていたが）、論理的に書くスタイルは、同じような不満を持つ多くのSEやプログラマの共感を集めていた。

木下君は、僕のことを慕ってくれていて、会いたいとの旨、わざわざメールをくれた。僕は快諾し、何回か一緒に飲みにいった。

基本的には共感できることが多かったのだが、あるとき彼がISO9001について批判している記事を読んで、これはたしなめる必要があると思った（思えば、この"たしなめる"という気持ちが良くなかった）。

僕は、先日も書いたとおり、ISO9001自体は利活用すべきものだと思っている。しかし、運用面で問題がある会社が多いということも感じていた。

木下君の記事は、ISO9001が正しく運用されていないことによる悲劇についてまさしく書かれていた。

どう考えても現場では不必要と思われるドキュメントを作らされる。テストの基準なども変だ。その前に開発の進め方が古すぎる（木下君はアジャイル推進派だった）。

そこまでは強く共感できた。ただ、一点、ISO9001が諸悪の根源だという主張には同意できなかった。繰り返しになるが、ISO9001が諸悪の根源ということはない。よくできた「ツール」であり、正しく活用すれば現場に利益をもたらしてくれる。

その点を論理的に説明したつもりだったのだが、ものすごい反発を買ってしまった。冒頭の嘆息は、このときにしたものだ。

最終的には関係修復ができたのだが、一時期は険悪な仲になってしまった。

 

木下君は男性であるが、男性がよく女性に対してやってしまうコミュニケーション上の失敗と同じことを、僕は木下君にしてしまったのだと、後ほど気がついた。

木下君は当時本当にひどい目に会っていた。その上（後で知ったのだが）ご家族の不幸もあった。彼は論理の正しさよりも、共感し、自分を助けてくれる人を求めていたのだ。

そこに、そうは言っても論理的にはこちらが正しいんですよ、という主張をされても、それは切れるであろう。

家族の不幸うんぬんは別としても、僕は下請企業のSEの心情に対する理解がまったく不足していた。

どんなに志が高くても、自らテーラリングができる立場にない者にとっては、元請から押し付けられる「間違ったもの」は、抑圧であり、疎外に過ぎないのだ。

もちろん、敵を見誤っていた（敵はバカな元請なのに、ISO9001という"制度"に向かってしまった）木下君に問題がなかったとは言えないが、僕がやるべきことは、まずは彼の心情について理解することだったのである。

僕自身は、ずっと自らテーラリングできる立場にあったので、彼をきちっと思いやることができなかった。そのことを当時大いに反省した。人間、自省的にならない限り、自分の立場が普通のこととどうしても思ってしまうようだ。

 

テーラリングできない立場にあるとどういうことになるか。他の企業の事例も挙げてみよう。

千葉県にある小さなソフトハウスA社は、超巨大SIer Z社の下請で、ある商事会社のシステムを開発していた。規模はそれほど大きくないが、一つの独立したシステムを、ほぼ丸投げで任されていた。

Z社は、当然ISO9001に対応しており、厳しい受入基準も用意していた。仮の数字だが、A社が受注した規模であれば、テストで1000個バグを発見しなければいけないとされていた（注）。

ところがA社にはとても腕のいいプログラマがいて、何回テストしても300個しかバグが発見できなかった。

しかたなく、それでテスト報告書を作成し、Z社に納品しようとしたところ、Z社のろくにプログラムも作ったことのない3年目の若手社員が、規則は規則だから受領できないと言い張るのだという（僕はこの話をA社の営業担当取締役から聞いた）。

作成したソフトウェアの詳細設計書やソースコードを読解できれば、1000個もバグが出ないのは一目瞭然だが、その能力がないし、上司からも厳命されているため、若手社員は頑として受入を拒んだとのこと。

A社の営業担当取締役は、泣く泣く虚偽のテスト報告書を作成し、約1000個のバグを発見したことにして、なんとか納品できたのだが、「やっぱりあったでしょう」と言うZ社の若手社員のドヤ顔を見て、殴りつけたくなったようだ。

（注）本当はこんな受入基準ではいけない。テストケースの妥当性、設計書の品質、テスト工程の進捗によるバグ発見率の収束具合など、品質管理は多面的な指標で測定するもの（製造業では常識だ）であり、規模からみて1000個のバグなどというのは大雑把過ぎる。基準がおかしいからこのような悲劇が起こる。ところが、恐ろしいことに、国産大手４大SIerでさえも、まともな品質基準を作れる社員は一握りしかいない。大概のプロジェクトでは、このような雑な基準がまかり通っているのだ。その下請でソフトを作っている会社の社員は本当に気の毒だと思う。

 

A社の営業担当取締役は、その後発注元の商事会社のCIO（情報担当役員）に直訴し、元請になることに成功した。

このような元請志向のあるソフトハウスであれば、一時期のことだと我慢すればいい。我慢ついでに、せっかくの機会と捉えて、元請の悪いところを記録しておき、自分がテーラリングできる立場になったときに活用すればいい。

木下君の場合は、実質は現場のリーダーだったのだが、元請の意向には逆らえない立場だった。

その後、木下君は独立して、自分で直接営業するようになった。苦しい決断だったと思うが、彼はその後精神的には安定し、幸せにやっているようだ。

 

下請企業で働いているのであれば、まず社長に聞いてみよう。ずっと下請に甘んじるのか、と（言葉は選んでくださいね）。

いや、そんなことはないというのなら、支えていくのがいいと思う（ただ、社長の甲斐性は自分で見抜いてください）。

もしそうだというのであれば、転職か独立どちらかしか、息苦しさから抜ける方法はない。

息苦しさを飲み込むか、転職・独立をするか、この二方向で考えるしかないようだ（もっといい案がある人は、ぜひご提案ください）。何も転職や独立が偉いわけではなく、息苦しさにあえて耐えていくのも、一つの立派な道だと思う。ただ、その場合、愚痴は言わないことだ。

僕の一番のおススメは転職だ。小さなソフトハウスでも、基本的に（実質的な）元請しかしない心意気の会社はある（詳しくはこちら。これ以外にも探せば必ずある）。

健闘を祈ります。

 

結果として、システム開発会社に特化した話になってしまったが、他の業種・業態でも参考になれば幸いです。あたりまえの結論で申し訳ないが、自分でコントロールできる範囲を増やさないと息苦しさからは抜けられないということです。