« 理念先行 | トップページ | 恩讐はいつまでも去っていかない(1/2) »

仕様書も用語も言語も独自

日本の保守的な企業は技術者が入れ替わらない。外のやり方や状況を知る必要がないから知識や技術が陳腐化する場合があるということを言う人がいる。
つまり、ほかの例を知らないから、技術者は成果物の質の良し悪しがわからないのだと。そうなると品質ではなく組織内での競争は成果物ではないということらしい。人当たりや気遣いなどになり、成果物の質が低い人でも上になるとかいう。
ブログランキング・にほんブログ村へ
もっとも、最近は大手のソフトベンダーにおいても人員の中途採用をしている例は多いらしい。
ある大手電機系システムハウスで聞いた事例には

1:入社時に3月以上かけてソフト制作に関する基礎研修を行う。
2:そして実際業務を上流工程から下流工程まで一応経験する(3年サイクルとか)
3:3年ぐらいたったところで残っている人を100%とすると、ここで退社する人も多い。そのまま勤務する人が30%ぐらいいて、あと70%は向き不向きもあるのか退社することが多い
4:ところが、退社するもののうち半分はやはりソフト系の業務についている。これは一応基礎的力量をはじめにつけていることもあるので、意外と外注会社が採用することがあるらしい。
5:ここで、独立する人もいる。もちろんそういうところが業務をほしがっていたら割りと出すようにはする。本当に力がある人は外に出て行くことは一種のCSRとして容認する姿勢を見せる。しかし、いくら能力があっても運がないと言う感じで独立してもうまく行かない人のほうが圧倒的に多い。
6:ここで、また戻ってくると言う人がいると、それはむしろ喜んで採用する結果、30%ぐらいはなんだかんだいっても最初の会社に戻ってきたりする。戻らなくても、また外注で業務する場合となれば業務フローがお互いに分かり合えるのでパートナーとして活用しやすい。
7:意外とこのような再入社組のほうが全体を見ることが出来、そしてその全体を見る中で既存の社内業務フローをパーツとして当てはめる形で使うことが出来るから、技術のまとめ者に進んで登用している。

というのがある。一見オープンに見えるが実は、よそ者の参入を排除しながらちゃっかりノウハウを得ようと言うのだが、ソフトの世界では他流試合が必要な反面、所属企業の大きさによってやる仕事の難易度がことごとく異なると言うことであろう。

標準化や業務運営の仕方は確かに国際的に「最適化」になっていないと言うのは良く分かるのだが、その求めている顧客の要求内容のロジックがもともと国際化を求めていないと言うものに対しては、他からのノウハウが入らないと言う弊害もあるが、一方自社の仕様書が国際的に理解されたらそれはそれで受注が以降他者に回ってしまうと言う問題を内包するとも言える。すなわち企業間の業務標準化という業務ならば、上記のフローに見え隠れする「囲い込み」が達成できないと言うところに突き当たる。
ここで意外と考えなければならないのは、たとえば企業にとって業務フローは社会に共有されなければならないのかという問題である。最適解がひとつしかないとはとてもいえないものに対して共用化は必要でない。つまり技術者の資質向上において何でもオープンな海外においては武者修行という意味では好適だが、いかに自分のところに「技術者を抱え込む」「顧客を抱え込む」「大きな仕事を抱え込む」「次の仕事を抱え込む」という抱え込みのビジネスモデルでは既に様々な文化や言葉の間で標準化業務ををやっているのは、社会的に参入企業がたくさんある場合はきわめて有効だが、寡占状態の上仕事をツリー状態に割り振るという形での階層ができあがってそれが利益分配の元になっている場合はどうかなあとおもう。
-------------------------------------------------
私は基本的に機械屋であるので、あまりソフトのことをどうこうという立場にはないのだが、思うと、自動車を1車種開発するとして、其の開発フローは自動車会社によって大きな骨子以外はあまり共通性がない。試作評価の仕方や機能評価などのステップ、初号車ラインオフまでを工程表に纏めたらオリジナリティーがある。そして基本これらは細々とは外部に伝えられるが、自動車会社によって各々異なるものである。逆に評価がそこで行われるから、この会社の製品はこのような特性を持っているんだなと思う。
で、アメリカにおいてどうかというと、大手3社のフローはそうかわりがないらしい。これは相互に人材が流動しているからどうしてもそうなってしまうらしい。但しある会社は、フローを2つ以上持っていて日本車に近い製品はこれというようにフローを使い分けることはあるそうだ。また、日本企業でもたとえばアメリカ市場向けの車をアメリカのリサーチ部署で起こす場合はあえてアメリカのメーカーのフローを模擬した手法で作るとも聞く(そしてそれを立案執行するのはアメリカの自動車会社から移ってきた技術者だったりする。)
ここで考えるべきは、確かに技術者が他の事例を習得するシステムが成り立たないには残念で、海外の標準仕様で仕様書をかけず、用語も独自というのは、国際調達の面では厄介とは思う。しかし其の企業式の業務をパッケージ化して他国に分散させるということのほうが「囲い込み」という利益配分方式(それは国際標準化とは相対するものである)にあるなら、それは商習慣自体に議論を持っていかないと、なんら問題の抽出にならない。
-----------------------------------------------------
もっとも、効率も悪いから延々デスマーチを起こすというのは、このエンジニアリング手法が元来銀行基幹システムのように大きなシステムをメインフレームで動かし、また絶対にミスがあってはならないという志向(これはこれでおかしな話であるが)から来ているものであったとおもう。個人家屋を作るのに大きなゼネコンがかかってもいいものは出来ないし、日本の家屋を作るのに分業で積層化された構成をやっていればそら、うまくいかないとなるのが当然。たとえばPC用のシステムと言った場合にも、このようなメインフレーム的な仕事をすれば不合理である。そこに対して(特に業務ソフトの場合)業界の流れを無視し海外に15年は遅れているというのは、あるだろうなあと思う場面も割と見る。そしてこの場合標準化や品質管理は誰かがしなければならない。またそういうクラスだと欧州(アメリカは又違うような)は標準化活動に対し、積極的に動いている。よいものは(第三者が保守が出来ることも評価項目だし)よいと認めているのだが、これは逆にいうと企業の利潤回収の安定化ということを考えると、「利潤が取れない」ものになる。
公益のために技術者がソフトを作っているが、其の裏には標準化は利潤が今出たとて次には利潤が出ないという修羅場を作っているため、一部の天才による品質や新たなスキームが出来上がる利点以外に、一般の開発者が品質やスキームを見いだせなくて最終的には疲弊で進歩がサチレートする場面が何回か起こることで、使用者が妥協を始め、最後には純化(進化ではない)が止まるという、きわめてひねくれた解釈さえありうる。
日本の通信やIT業界にいる人は、若いうちに外国でのプロジェクトや仕事を一度でも経験した方が良くも悪くもいいとは思う。もちろん其の利点を甘受するのがいいだろう。実際外国にでても案外仕事があったり食べていけるのは、ベンチャーや個人事業者やってきた方というのはあろうし、実際 どこでも通用する知識・技術・営業力があるが、日本のシステム屋さんと相容れない考えを持っていた知人は、海外に行った(ちなみにアメリカ国籍になった)らそれなりの商売ができていると言う人もいる。しかし、其の業務には日本のシステムの作り方を分かってそれを展開してアメリカの顧客に収めてるものもあるとかで、決してアメリカや欧米のシステムや回し方が手放しで最適だとはいえないというのである。特にいい事例を指摘しても、外を知らないから意味がわからんということはあり、当人は分かっているとしても、パートナーに対して其の手法をいいと言うこと自体に困難がある。
---------------------------------------------
機械屋さんがシステムと言うときはプラントエンジニアリングの場合がひとつ当てはまるだろう。
日本のプラントエンジニアリングの企業は日本語で仕様書を書くこともあるが、多くは英語で仕様書を書くしドキュメントは英文を正にして書くこと(日本文も作るが、あくまで副である)が多い。またこの手のプラントエンジニアリングの企業は逆に海外の英文仕様書を読んで仕事をしたり、物品を作ったりということがある。
そこで私は一時英文仕様書を元に発注する製品を設計・製造管理するということがあったのだが、其のうち大元の仕様書をよんで詳細検討をしたり詳細仕様を設定して日本・韓国の企業に指示する仕事、また逆に英文仕様書を書いて海外のプラントエンジニアリング企業に指示を出す業務の一部をやって見ないかという話が、一緒に仕事をしていた大手プラントエンジニアリング企業から来た。

悪い話でないし、経験を踏むのを後押ししてくれる人も居たので、諸事情もあり最初に仕様書を書いてみた。こういう英文はいかなる国の技術者でも分かるよう Simple English でかくことになっており、技術タームはごく限られたものしか用いない。逆に内容は特性などを明確に示しているものでなく、任意性がありそこに対して性能調整を行うということまでは示されているが、それはあくまで「命令」である。(しかも其の設計仕様に対して適した機器選定とは思えないというところもあった)
このように疑問があったので、問い合わせを英文FAXで送ったのだが、其の答えは妥当性とかの答えでなかったのである。『指示通りにやれ』と一言。
まあ仕方がないわなと思う。多分にこれはプロマネの業務責任によるものであるが、どうも聞いていると現物を作っても性能があわないために機器を作り直すとかそういうことが往々にあるらしい。またプロマネが仕様書を作るときはサブの技術者に性能確認をさせるらしいのだが、これが能力があるという人でないことはほとんどだし、欧米の企業だとそのような検討だけフィリピンの技術者・インドの技術者に振るだけということがあるらしい。(日本でもそのようなシステムを組む人員配置が増加している。だからSimple Englishなのだという)
一方、仕様書であるが、(これはISOとかでもそうだが)仕様書が判で押したように使う語彙も一緒である。しかし、この仕様書をみて機器を集めても、形にはなるが装置にはならないのが分かっている。基本構想などの書面はドキュメントで書くのだが、これを実は一緒にやっているプラントエンジニアリング企業には開示しないため、手探りで物を作る(推察と言う行為もNG)ことをさせているのである。このような階層構造の業務ではドキュメントを当たり前の形式で書くことができる段階では単に字を埋めるのと大差ない「カタログエンジニア」と罵倒する選択しかできないし、交換が効く内容だから「クソジャップは首だ」で終了となるような世界は容易になりうるのであるし、さらに長い間を得てもこの仕事をやっている限りは刹那的で、一向に技術はOJTでは向上しない。(教育システム自体も企業で用意をしないわけだ。もっとも日本の大学の新卒は一応研修は企業側でやっていたらしいし、その様な教育機関ももっていたらしい)
日本文は論理的にあやふやと言う側面が確かにあり、英文は其の点直接的である。しかし仕事の中で日本文的指示や進行を行うと、お互いの相談や調整を行うことができ(そこでちゃんとその内容を明らかにしておく行為は必要だが)これは時間を食って効率も悪いから延々デスマーチとなる可能性がある。一方英文では謙譲語もない世界であるから業務は「私命令出す人」「私仕事をする人」で進め、問題が出ると危惧した場合「命令の訂正を求める」形になる。業務の推進は図られるが、仕事を通じて社会に貢献するとかいう形の技術者としての満足感がまったく浮かび上がらずということになる。何のために仕事をしているのかを切り替えてゼニのために仕事をしていると考えないと精神的にもたない。

と言うわけで、機械的にSimple Englishを書くことに聊か不信感を抱きながらも1月ほど何個かの業務をやっていたとき、其の当時の上司がやってきた。もともと某社でプロマネをやっていてかつアメリカで10年ほどプロマネの指導をやっていた人物でありアメリカPE資格を持っていた人である。
上「Nエンジニアリングさんから一部仕様書の検討業務を受けてるなあ」
デ「こういうのです。(英文を見せる)例の問い合わせ英文FAXの答えは『そのまま進行せよ』でしたが、あんな仕様の機械どこにあるんですかねえ」
上「あれね。Nエンジニアリングさんからのコメントは確か、責任は発注元にありとなっとったな。仕様書を見せて」
デ「はい」
上「・・・・・・・・・うーむ。これ君不完全燃焼してないか」
デ「はあ?」
上「仕様書の書式はちゃんとしているし、ドキュメントも適正だ。表向き論理性はあるようにかんじるが、技術的なキーを重視してない仕様書だねえ。こんなのを読まされるNエンジニアリングさんにも同情するな。言語明瞭、意味明快、しかし検討不十分で最終責任は試運転屋(プラント立ち上げの専門技術者)さん任せってやつか」
デ「そうですか・・・。これ最新の○○国向けの仕様書ですが」
上「・・・・・・・これも、あんまり変わらんな。これでは君の仕事のレベルを落とすだけだ。・・・そうだな。Bくん(入社2年目)がおとつい別件が一段落したからこの後はやってもらう。Bくんにはちょっと専門外だし引継ぎと技術的指導を彼にしてくれたら彼の経験になる。」
デ「はい・・・。それ大丈夫ですか、相手さんあるのに」
上「いや。ちょうど専門的な業務の依頼がきて、誰に頼むか思案してたから。相手にはその理由で言っておく。少なくともプロマネが出来る人(このとき既に私も技術士資格(=アメリカのPE資格に近い)を持っていたため)がする仕事じゃないぞ。(持ってきた)営業にも注意しておくから。」

日本では特にIT業界など会社ごとに仕様書も用語も独自だという。(最も銀行でもどこでも専門用語は結構方言がある企業文化がある)だから、外からきた同じ国の人だけではなく、外国の人は一緒に仕事するのに大変な苦労している。海外企業でも裏では独自の用語使ってて意味不明でドキュメントすら書けないとかがないわけでない。まあ、ドキュメント類の文書の書式はともかく、定型文章をかけないと言う技術者も確かにいるんだよなあ。こういうのは自分で問題意識を持つことで上司に聞きに回るとか、参考となる図書を教えてもらうとかの自主的活動ぐらいはしてほしいですな。けどこういうのは基本的に階層的に上位と言う意味で見てしまうとなんでもそうなると言う側面もあるため、実はお互いに効果を打ち消しあう関係になっている可能性もある。
もちろん自分達のドキュメントややり方が一番だという判断基準は今すぐ払拭するべきであり、少なくても其の研鑽をやらないなら意味がない。外国でのプロジェクトや仕事を絶対経験した方がいいのは思う。違う世界を知らないと分からないものだ。ただ要求元の要件定義に係わる考え方と心理的な立ち居地が異なるのに、片寄せで一方が正しいということを声高に叫ぶやからの内容の荒さもちょっと気になる話である。

|

« 理念先行 | トップページ | 恩讐はいつまでも去っていかない(1/2) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/100146/55731286

この記事へのトラックバック一覧です: 仕様書も用語も言語も独自:

« 理念先行 | トップページ | 恩讐はいつまでも去っていかない(1/2) »