isLandcenter 非番中

ブログトップ | ログイン

インフラ系の技術者にとっては、メーカーのカスタマエンジニア(CEさん)は神様か、あるいはどーでもいい存在の場合もある。まずプログラマや開発系SEの場合、あまりお世話にならないだろう。

そんなCEさん達の話を、大昔に書いた文書から再現してみた。

- 自称チェンジニア -

ワタクシの顧客のシステムの調子が悪いということで診断してみたら、しっかりディスクが壊れていた。交換するしかない。しかしメーカーのD社の代理店に頼むと当時1Gのディスクドライブが20万円するという、当時でも20万円も出せば、ディスクどころか本体が2台買えちゃう時代なのにだ。

怒った顧客はやはりメーカーの外資系C社に見積もりを依頼した? なんとサービスマンが来て5万円で修理するという。

ン? なんでC社なんだ?

ということで交換の日、やってきたフィールドSEはD社のH君だった。そう。D社と言えば当時の業界人で知らない人はいない。外資系C社に吸収された大手外資系コンピューターメーカーなのだ。まぁ、イニシャルとはいえD社とC社、後のH社と言えばそのまんま。想像が付かない人なんていないよな。
それより、H君を見るまで想像が付かなかったワタクシが悪いといえば悪い。

H君はいまだ元D社の新宿区内にあるサービスセンターにいた。彼は以前よく「静電気マン」ことワタクシが壊したマザーボードを交換にワタクシの会社に訪れた事があり、よく知っている仲だったのだ。
一応システム屋のワタクシに対して、H君は「いやぁ、システム屋さんはいいですよね。ボクらエンジニアじゃなくってチェンジニアだもん」彼は謙遜してそう言ったものだ。

「ねぇC社のコンピュータも修理するの?」とのワタクシの問いにH君は答えた「いやぁ、あれC社の資格がないと修理できないんですよぉ。C社ってまぁウチのカイシャなんですけどねぇ」

でもやはり彼はプロだ。「いやぁ次は渋谷なんですよぉ」とのんびりした口調でマザーボードの入ったカミブクロを二つぶら下げ、炎天下、雪カ谷大塚の駅に向かうH君の後ろ姿を見送った。

PR


-お喋りなCEさん-

国道16号を遥かに超えた客先でチンケなPHSのバイブレータが鳴る。

「xxさんの所のシステムが止まっているらしい」

という緊急連絡だ。あぁぁ、本日も出先からの5時上がりはなしだ。早速なんとか客と連絡を付けると、どうもシステムのマザーボードがイカレているらしい。メーカのサポートに連絡取らせて交換の指示をすように言うと、都心に向かう夕方の上り電車のヒトとなったワタクシである。

客先に「どぉもー」と声を掛けて入り込むと、しゃがみ込んでマザーボードの交換に精を出すヤツがヒトリ。グレーのシャツにパンツスーツに包んだ細身の体、肩が細くて胸はペッタンコ。なんと女性のCEさんだ。ここのハードウェアは箱崎製だ。なんと、あそこは女性のCEさんもいるのだな。さすがアッチ方面は侮れない。
それにしてもよく話すCEさんだったなぁ。

「あ、いやね、このモデルね。結構このテのトラブル多いんですよっ。特に4桁のここが2のモデルねっ。なんかあったら必ずさっさとMB交換することにしてンですよっ」

(頼む、黙っててくれ、そのサーバ売ったのウチなんだから....)とヒヤヒヤしているコッチを尻目に、コイツは客の前で次々とべらべらと「Iさんの内輪話」をまくし立てる。「もうこいつは所詮パソコンなんだからぁ。よくやっちゃうんですよねっ。大事なシステムはやっぱこっちにしましょうねぇ。」なんてAZ400だとかというデカイ筐体を指差しながらマザーを交換する彼女。

楽しそうだなぁ。(止してくれよぉーお、オレその「パソコンの大事なシステム」の専門家なんだからぁ)まぁ楽しいといえば楽しいヒトトキであるし、お茶をこぼしてお茶ッパくっついた客のメインフレームのマザーボードを交換した話なんて聞かせてくれる。泣きたくなるくらい爆笑できた。おもしろいヤツだといえばそのとおりだ。頭にくるけど、専門家としてはコイツの話は聞いておくに限る。

とにかく、「黙ってむっつり」が基本のフィールドエンジニアが業界のほとんどなのに、とにかくI社のエンジニアはゴキゲンなヤツが多いし、結構気軽に話しに乗ってくれているヤツらが多いのも事実。さすが日本のITビジネス業界の中では、サービスに長けているだけのことはあるよな。気の利いた冗談とマジメな「ホンネ」のひとつもサービス業である彼らの仕事なのかも知れない。

大体が、客の文句を黙って聞いてあげるのがサポートの役割だ。壊れたからって言って彼らに直接文句を言うのは可愛そうというもんである。文句あるなら作ったやつと設計したヤツと売ったヤツに言えばいいのだ。

とにかく女性でこんだけ明るいCEさんは初めてだった。


- 能書き垂れるCEさん -

いかにこのディスクが入手困難かの能書きだけ垂れて、ホットプラグのディスクを「ガチャリ」と交換して「修理終わりました」と深々とお辞儀をして宣言して帰った三田方面のCEさんがいた。

ここは官庁に強い。ボクの先輩の顧客もいた。先輩から、三田方面からCE と営業が来て、修理するから立ち会えという。どういう状況かも判らないまま、暇こいていた後輩Y君を連れて、ユタビーチの後背地に「パラシュート降下」しに行ったわけだ。

既にCE氏は、荷物を開いて準備している。夏なのに上着を着ていて、セビロの背中から汗の粉を吹いていた。

「えぇー、ここにあるディスク2個、一つは昨日仙台にありました。もう一つは昨日の夜に、成田にあったものです。つまり日本には同じ型番のHDDは、ここに二個しかありません」

と、斎藤道三の油売りの口上の様なことを言うと、ディスクをガチャリガチャリと交換して

「治りました」

と宣うたのである。

勘の鋭い方ならお分かりであろう。壊れたのはディスク二個、Raid は 5 、そう、全滅なのである。最悪の状態に立ち会ってしまったのだ。

「では終わりましたので、これで失礼します」

と、クダンのCE氏は、粉吹いたセビロの背中を見せて、真夏の三田方面に撤退して逝った。

残されたワタクシ達と、セールスマン氏は茫然と見送るばかりである。その後、五分後には私も手が出ないという事で、引き揚げたんだけど、その後のセールス氏と顧客とに間に、どの様なやり取りがあったかは知らずじまいである。

ただ記憶に残るのは、同行したY君の

「あのCEさん、背中に気合入っていましたね

という感想だけで記憶に残っている。

--

影でコソコソして結構シェアだけは多いF2、よく壊れ、行くと必ずCEが昼間っから客のサーバの筐体開いて『解体新書』を読んでいる技術のH、むっつりが多くて、キーボートを触るのはシゴトじゃないと、涙流してこちらの立場を鑑て宣言した、C社のCE。とにかく新品でも最初から調子が悪くてどこでも必ずMBを交換したという話ばかりを聞かされるのに全然マトモに動かない高井戸のP。

--

ある現場で、どうしてもしつこいトラブルが出続けて、訳が分からず、HDDと筐体以外全部交換してもらったことがある。その時、CEさんがHDDのファームウェアが一つだけ古いのを見つけてくれた。そう言えば、このサーバーは以前空調がトラブった時に、HDDを交換したのだ。そいつのファームウェアが悪さしていたらしい。それから、しつこいトラブルは狐憑きが無くなったように調子が良くなったことがある。CEサマサマな出来事だった。

--

銀行では、現金に触らない役割ほどエライのだそうだが、IT業界も似たようなものだ。コンピュータに触らないニンゲン程エラいのだ。

CEさんは「電話と言う飛び道具」だけで、ズルい遠距離攻撃しかできない電話サポートと違って、直接顧客と客先というアウエイの土俵に一人で乗り込んで組取りで真面目に闘っている。正にIT業界の最前線だ。中にはベンダーのCEさんではなく外注さんの場合もあり、名刺交換に応じる事ができないCEさんもいる。「名前のないCEさん」だ。

だから私は必ず相手を尊敬し、

「もしまた別な現場で会ったらよろしくお願いします」

と挨拶することを忘れずにやっている。重量物を持ち上げる時や、大きなASYを交換する時なんかは、必ず手を貸しすし、明るく下世話な冗談飛ばしながら、彼らにとって「一期一会の楽しかった良い現場」にしようと心がける。

正にCEさんとの付き合いは茶道なのだ。

私は全てのCEさんの仕事は尊敬している。中々できる事じゃない。

PR 最後までお読みいただきありがとうございました。









by islandcenter | 2019-06-21 17:43 | 雑文 | Comments(0)

日本のソフトウェア産業は「製造業」

というちょっと古いコラムが話題となっていました。

Europe: Software as a science -ヨーロッパにとってソフトウェアは「科学」
Japan: Software as production -日本のソフトウェアは「製造業」
India: Software as a service -インドのソフトウェア産業は「(プロフェッショナル)サービス」
U.S.: Software as a business -アメリカのソフトウェア産業は「ビジネス」

というのが趣旨ですね。

結果として、約1兆ドル(100兆円)と言われるソフトウェア市場の5割を、アメリカ企業が占める結果となっているそうな。

というわけで、お国の違いが色々あるわけだけど、
日本のソフトウェア産業はこのまま製造業を続けるのか、アメリカ的なビジネスなソフトウェアにしたいのか、
というのは考える余地がありそうだ。

と、このコラムは〆ています。

問題は「1兆ドルのソフトウェア市場」の正体が「ソフトウェアサービス」と付随するIT分野の話であること。日本の「製造業」を始めとする、サービス業、金融サービスははITによって莫大な利益を得ているという事を忘れてはいけないことなのですね。

先日の航空会社のシステムトラブルで「何億円の損失」とか騒がれたけれど、それまで「何百億円」ものコストカットがITシステムで得ていたことを忘れてはいけないのです。

しかしここで日本のIT産業が忘れてはいけない問題が2つあります。

1)日本のサービス、金融に使われるITは内需産業である。
2)日本の製造業は外需産業でありITを忘れている。

という2点です。

日本の「クレージーな鉄道運用システム」は、一つの光明なのかもしれません。もっぱら「内需産業」だった、「シンカンセンシステム」は輸出産業へと転換しつつあります。

しかし、製造業がそのクレージーさについて行っていない。いまだに80年代から90年代に莫大な投資をおこなった製造方法に頼っているのが現状じゃぁないか、と現場を見て考えてしまいます。

製造業のトップが考えることは、

「製造コストを外注化していかにコストを下げるか」

という事で、目を付けたのは、海外の安い人件費でした。まずは中国、次にインド、そしてマレーシアやベトナムといった外注先に部品や製品の製造を発注することでした。基本的な製造技術の研究開発は後回しで、50人の日本人がやっていた部品の製造コストを1/10の人件費の海外で100人で製造することでコストを下げてきた。日本の1/10の人件費が中進国でも1/2になれば、倍の人数では結局製造コストは変わりません。

そのツケとして、海外での人件費の高騰でさらにまた違う安いコストの発注先を探してきた、というのがニッポンの製造業の実態です。結果、最終製品をアセンブリする製造業は最新の設備を使っていても、中小の下請け製造業は何十年も使っている旋盤機を未だ使って金型を製造しているわけです。

その結果、日本国内での製造コストは20年前と変わらず、海外での外注コストばかりが上がっている。

私は、日本の製造業のトップが過去20年間、無策で無能だったと考えています。

メイドインジャパンは日本の誇りなのです。日本の製造業のトップはメイドインジャパンの印を捨ててまでコスト競争に走ってしまったのです。

80年代に100人で作っていた製品を50人で製造し、さらにIT技術をプラスした付加価値をつけて10人でも製造できるだけの技術を模索すべきであると言いたいのです。そのためには日本のクレージーなITの品質を信用しても良いでしょう。結果として、その技術が「ニッポンのクレージーに正確無比なシンカンセンシステム」でも、バカみたいに燃費がいい自動車でも、ホーチミンで走り回っているホンダのカブでも、中国人がバカ買いするトイレットペーパーでも構いません。

その生産技術で外需が稼げるのであれば、内需専門の日本のIT技術者も報われるのかも知れません。

これは、日本のIT産業でも同じで、国内で開発するソフトウェアを海外に外注すれば1/10のコストで出来上がるというナイスな考え方をしたIT産業のトップも同罪です。日本国内でのエンジニアのスキルを使って従来のコストの半分で、ソフトウェアが開発できるという発想がなかった。おかげで日本のIT産業はもっぱら内需にしか向かっていません。






by islandcenter | 2016-04-20 21:21 | 雑文 | Comments(0)

- ローパー社員は組織の必要悪?-

よく働きアリ2割の法則があるように、組織の中にローパー社員がいるのはある意味仕方がありません。必要悪なのです。パレートの法則のように、トップヘッドの2割が売り上げの8割を生み出す、と言いますが、スーパーマーケットの売れ筋2割以外を全て棚から撤去したら、どうなるのでしょうか。利益は上がりますか?

実際に、ロングテールを無視して、売り上げトップの製品だけを扱う事にした、某SI業者は見事にその後消滅しました。もっとも、その決断をしたトップは、主要株主が送り込んだ切れる東大経済学部出身の刺客であり、その会社を潰すのが目的だったので、従業員にとっては酷なことでも、株主にとってはハイパーだけを残す事は、組織を潰すにはよい選択だったのかもしれません。まぁ、東大経済学部卒の一流企業のエリートサラリーマン人生の仕上げが関連会社を潰す事だったというのも、ちょっと悲しいサラリーマン人生だったな(つまり親会社のローパー社員だった)と今では同情します。南無南無(って殺すなよ)

そもそもパレートの法則にあるように、ローパー社員は組織にとっての必要悪であり、常にあり得る事なのです。また、ロングテールを抱える事も事業にとっては必要な事です。全ての組織はパレートの法則で動いているのです。

-ハイパーな2割がローパー化する-

よく「ローパーな癖に高い給料貰いやがって」と言われますが、高い給料貰っていたからにはそれなりの理由があるはずですね。最初からローパーであれば、給料なんて上がるわけがない。前述の東大出の社長もハイパフォーマンスだったからこそ、給料が高かったわけです。

しかしハイパーだったのに、必要なスキルを身に着ける時間もなく、仕事に追われて行先を失うと「ローパー」の烙印が押される。私も経験があるのですが、部署内で休みも取れないくらいの最大の顧客と売り上げがあるにも関わらず「ローパー」な気分を味わっていたことがあります。

働きアリ2割の法則にもあるように、働きすぎるハイパーなアリはローパー化しやすいのです。

ローパー社員を増やすには、ハイパー社員を殺すほど働かせればよい。たちまちローパー化してしまうでしょう。この事実に気が付かない経営者は、すぐに事業に失敗するはずです。

そもそもハイパーな人材が、自分のビジネスの行き先を僅かでも見失うと、たちまちローパー化してしまうわけなんですね。

ローパー社員なんてのは最初からいないのです。ハイパー社員がパレートの法則に従ってローパー化する、というのが実態なのです。

-ローパー化を防ぐために-

ローパー化を防ぐ絶対的な方法はありません。そもそもが2割ぶら下がり社員の法則なわけですから。

ただ、組織を活性化させて、ローパー社員とハイパー社員のローテーションはトライすべきでしょう。自分自身の経験からすると、そもそも属人化するほどのハイパーな人材、やっぱりどこかで「ぶら下がり社員化」させるべきなのです。たとえ給与が下がっても、身分や格が落ちてもいったん撤退、降格させて、休んで周囲を見渡す機会が与えられるべきでした。

確かに腐るでしょう。士気も落ちます。それでも、人材を社内で流動化させるには、ハイパーな人材がピークを迎える前に一旦降ろさせるなどしないと、組織の活力は落ちます。誰もがハイパー社員になりたいわけではなくても、ぶら下がり社員の中にもハイパー化するチャンスが欲しいという社員はいます。

全ての人材の6割はぶら下がり社員なのです。ハイパー社員に無理させても、当人の収入が他の社員とそれほど違うわけじゃない。むしろ無理しているだけ。実際、組織の中ではハイパー社員と「ぶら下がり社員」との収入差が大きなわけではありません。

私の後輩で何でもブツブツ文句を垂れて、「俺は何でも仕事ができるぜピノキオ野郎」がいましたが、彼は上司が変わった途端ローパー化ても「ブツブツピノキオ野郎」でした。そこまで落ち込む事を放置したマネージャーの責任だと思います。彼はその後退職しました。うまく使えばもっといい仕事もできたかも知れません。

どんな人間もいい時はあるものです。しかしこれもパレートの法則のように、いい時期は人生の2割しかないという事もきがつかなければいけません。キヨハラだって、80年の人生で光が当たったのは十数年しかなかったのです。

ハイパー社員が、急激に価値を失って高賃金のローパー化する前に、降格の味、あるいは「サラリーマンは気楽と来たもんだ」という気分を味わわせた方がよいのかも知れません。賃金だって、「普通」にすればよい。どうせ、賃金成果主義なんて、日本企業ではできっこないのです。成果主義で同じ格の人間でも業績が数値化できないので、せいぜい1割程度の割り増しなんですよね。そんな、「オレオレピノキオ野郎」がたちまち価値を失ったとき、ビジネスは崩壊を始めます。

ハイパー社員が本格的にローパー化すると立ち直れなくなるでしょう。





by islandcenter | 2016-03-25 12:29 | 雑文 | Comments(0)

私はフリーエンジニアとして IC (インディペンデントコントラクター)としての道を選びました。サラリーマンエンジニア時代も「細く長く」お付き合いしてきたお客様が多く、そのまま引き継いだためSES(システムエンジニアリングサービス)という仕事の形態は最初からなかったなぁ。

SESという言葉自体、最近まで私は知らなかったのだけれど、IT業界ではよく行われる「(名目)請負業務、(実態)偽装請負」のことです。中には「PC持ち込み歓迎!」とかの条件を出して、わざわざ「(実態)派遣業務」を「請負業務」に見せかけるやり方もあります。請負業務としては「成果物」を納品しなければならないのだけれど、SESの「成果物」はずばり人月評価が簡単な「タイムカード」。その時間に常駐し、技術を提供していたというのが成果物です。実態として、「顧客の要求(”指示”と読みます)」に従って仕事をするため、顧客も指揮系統、作業の要求のやり方を、一歩間違えれば、確実に「偽装請負を受け入れた」ことになります。Plan Do Check Action の PCDA サイクルの Plan が全くないまま、成果物という目標が描けない。DO と Action のサイクルしかないのですね。

実際にIT関連の人材募集で「業務委託」という案件があれば、ほぼ確実にSES、事実上の派遣業務です。

なぜこんな滅茶苦茶な仕事の在り方が日本で通っているかというと、一言で言えば、日本のIT産業の未成熟さ、人月商売から脱却できない。多重請負、PM不在の顧客などの日本固有のビジネススタイルにあります。さらに言えば顧客のセンスのなさ、それを補って付け入る、技術力がないSI事業者、などがあるでしょう。

不思議なのは、外資系企業で仕事を請け負うと、こんな国際的な非常識が全くまかり通らない事です。たいていは日本人のITマネージャが居て、フリーランス、外注、ベンダー、派遣社員の業務目標をしっかり管理できる人が居ることです。だからなのか、私は日本企業の顧客のITマネージャの質を高く見ていないし、その足元を見ているSI事業者も信用しない。だから外資系企業のIT担当者は大抵、外資系企業を渡り歩いてスキルアップして、転職した方でもまだお付き合いがあります。なぜか外資系企業の方が責任が明確でやりやすいし、仕事にも集中できる。代々の日本の国策は「雇用の安定」を謳っていますが、「雇用の流動性」がないため、経済社会が固定化されて進歩しない。

よく「フリーITエンジニア、年収800万」とかあるけれど、実際SESで800万稼ぐとなると、たぶん地獄を見そうな気がします。アイドリングできないのですね。それだけスキルを磨く暇もない。人月60万の仕事を12か月連続で受注できれば、それくらいにはなるけれど、12か月連続受注というのがそもそも無理。しかもこの800万の中には経費も含まれるから、実質手取り500万程度が現実でしょうね。さらに、「売上1000万」のフリーエンジニアであれば、しっかり「消費税」という落とし穴があるから、「年収1000万超」のフリーエンジニアの実質手取りは700万程度じゃないかと思います。月単価80万で12か月なら「年間売上1000万」も夢じゃありませんが、これはSES価格であり、実際には顧客からの発注額は120万位だと思う。その価格だったら、「あなたの命は保証できない」という業務内容になりそうです。

それより無理なのはICで年収800万稼ぐことも現実無理なんですけれどね。でも、ICの場合、準備3週間、3日稼働で100万稼げる場合もあれば、1年で10万にしかならない仕事もある。

ITエンジニアでも、運用、保守、構築系の技術仕事では、「人月」ではビジネスにならない。システムの構築に3時間で終わっても、60万取る場合もあるし、10分で設定1行変えて30万とか、3か月かけて毎週週末の深夜に原因を調べてトラブルシューティングして5万というケースもある。作業時間の実績より具体的な成果が物申す仕事なのです。SESのフリーエンジニアと違い、ICエンジニアは具体的な「成果、結果」をださなければならないため、安くても完遂するし、短い時間の労働であっても高い「報酬」を得ることも可能なのですが、IT業界自体が「時間」という物差しでしか技術者を評価できない業界の慣習のため、「成果」を時間でしか評価できない。

派遣業であれば、業者が個々の派遣さんのスキルアップをして単価を上げる努力をするのですが、SES契約では、個々のスキルアップはエンジニアが単独でやらなければならない。もちろんそのコストは顧客は払いません。しかしそのスキルもエンジニア個人に属人化するため、顧客にノウハウが残らないのです。しかしより顧客目線のICは「タイムカード」という成果物以外のノウハウを顧客に残そうとするでしょう。こうした成果物が後の受注につながるのです。しかし、残念ながらSESという「甘味」を知った顧客にはタイムカード以外の「成果物」を評価できないのですね。顧客もエンジニアも「時間」でしか、成果をコミットできない。

それにしても、私が独立してから、フリーエンジニアという言葉がずいぶん一般化してきたように思います。しかし、その実態はほぼSESであり、ICのように、たくさんの顧客の中を泳ぎ回るような形態ではないのは、エンジニアの側にも問題があるのでしょう。ICは営業力とかアイディア、技術がキモなのです。営業力のない技術バカな私の様なフリーのICは厳しい世界なのです。そしてフリーエンジニアの営業力を阻害しているものがSESをはじめとするSI業界の悪弊かも知れません。もちろんICを名乗らないフリーエンジニアの中でも独創的なアイディアと技術を持って、「ご指名仕事」をする人もいます。こういう人には本当に頭が上がらないですね。

SESではなくフリーエンジニアとして成功するには、コネと特殊な技術、それで営業する能力です。

SESという「ビジネス」に未来永劫将来があるとは思えません。法律の抜け穴を使った一時的なボッタくりバーのビジネスです。もっともSESという一時的な「口入屋」を専門にしているのならばそれで構わないのですが、SI事業者を名乗っているのに自社請負の業務をSESに丸投げするのは、自社の技術力を放棄している事に他ありません。本来ならば、受託できる部分は受けて、足りない部分をフリーランスに協力して自社のPMが管理して請負すればいいのですが、それができないのが多くのSI事業者なのですね。だからいつまでたっても多重派遣構造から抜けられないし、PMも育たない。だから、求人サイトで何度も同じ業者の名前を見つけた時は「まだこいつやってんのか」って気分になります。これはSES業者であっても、顧客企業でも一緒ですね。

そんな不自然さに気が付いたSI事業者や顧客は、二度とSESの求人広告は出しません。自社技術が必要だという事に気が付い社員教育にお金と時間をかけています。

PMも、顧客がやるのならまだしも、中堅レベルの下請けSI事業者のPMとは、肩書でしかないわけです。職場から一歩も出ず、仕様書やメールのチェックが仕事。つまり、中間管理職になり損ねたプロフェッショナルのゾンビがPMというSI屋の肩書なのです。当然、何もさせてもらえないのに、部課長クラスと同じ給料を支払うため、下請けに出す時のコストに跳ね返ってくる。一方、顧客のPMも肩書だけの場合もありますが、多くの中小企業の場合、ビジネスの継続に必死ですから、事業担当者が兼任PMとして頑張る場合もあります。たいていこういうケースでは、お客様は事業継続に必死だし決断も早く、私も応援したくなる臨時PMさんになってくれますし、私の考え方も理解してくれるようです。私より年配の方でも「勉強になった」と謙虚な人が多いようです。

ICとして、付け入るスキがあるとするならば、顧客のPM業務をICとして請け負うことかもしれません。PMにならなくてもいい。PMを補助できる仕事をしてみたいものです。

islandcenter.jp
by islandcenter | 2016-03-05 12:59 | 雑文 | Comments(0)

生体認証の恐怖

よく、指紋だとか光彩だとか、顔認証だとかの生体認証があるでしょう。まるでパスワードを置き換えてやろうというくらいに注目されていますね。

しかし重要な欠点があるのです。例えば指紋認証のデータが漏えいした場合、パスワードのようにリセットする手段がない。

指をリセットしろというのは「や×ざ」になれというようなもので取り換えるわけには行かないのです。

実際、マレーシアかどこかで、自動車窃盗団が、ベンツを盗もうとしたが、指紋が一致しないとエンジンがかからない。通りかかったオーナーの指を切り取って車を盗んだ、という事件がありました。ずいぶん昔ですけど。

最近は3Dプリンタなんぞが流行していて、まだ、指紋DBから指紋を再現できるほどの精度はたぶんないのでしょうが、そのうち、「××さんの指サック」なんてのが作られると、指紋認証なんて簡単に突破できてしまうのでしょう。

たぶん。実際、いろいろな手段で指紋認証だとか静脈認証なんてのは破られているわけです。

セキュリティに完璧はない。生体認証のデータが漏えいした場合の影響力は、指でも切り取らないと永遠です。

何しろ生体認証はリセットする方法がない。あなたは自分の人生をリセットする自身ありますか。


by islandcenter | 2015-11-19 11:31 | 雑文 | Comments(0)

先日、とあるインフラ系ソフトウェアの評価版を入手してひどく驚いた事がありました。

なんと、インストール用のソフトウェアやドキュメントと言ったディレクトリがDVDメディアの中で「インストール」などと日本語で書かれていた事です。
a0056607_11470035.jpg

思わず天を仰ぎました。

セットアッププログラムなどが「インストール」というディレクトリにあるのです。通常だったら DVD:\setup などの英数字のディレクトリにあるのですが、このソフトウェア、なんと製品やドキュメントを収めたディレクトリ名、ファイル名が全部「日本語」なのです。

そこそこに名のあるソフトウェアです。同様なライバルのソフトウェアは世界中にあります。

この国産メーカーの製品には将来はないな、とすぐ感じました。例え日本で10%のシェアがある製品であっても、世界では1%にも満たないシェアしか取れません。例え日本で100%のシェアを取っても、製品自体が日本語にしか対応されていないので、それ以上、60億人が住む海外に市場を伸ばすことは不可能なのです。

逆に海外では5%しかシェアのない製品であっても、日本で爆発的に売れれば、海外ベンダーと言え日本法人を作ったり、ローカライズや日本国内でのサポートの充実を図ります。

APC-UPS(現在のシュナイダーエレクトリック)やVMWareなどが日本で販売開始された時はそれこそごく小規模に始まりました。ローカライズさえされていませんでした。

私は、ほぼ外資系製品を専門に扱ってきたため、若干のローカライズの不備などがあっても実用性に困ったことはありません。また日本語の情報が少なくても、一般的な高卒程度の英語の知識で情報を入手できるため、困ることはまずありません。

また海外製ソフトウェアは、基本的に海外のそれぞれのローカルタイムでサポートを行うため、「電話問い合わせ」が頼りにできない代わりに、セルフサポートが充実しています。製品サポートのための自発的なコミュニティもあります。オンラインでの情報が充実しています。

製品を利用する分母の規模が違うのです。

しかし、多くの「国産ソフトウェア」は、サポートが JST 9to5 です。製品サポートも、まずユーザ登録をしない限り受ける事ができません。事前評価の体制さえできていないケースが非常に多くあります。

分母が違うから、脆弱性の問題や不具合などは早い段階で指摘される。もっとも悪用されるのも早い段階である、という事もデメリットかもしれません。しかし分母が少ない製品では、そもそも脆弱性がある事自体発覚しない事もありますし、使っているミドルウェアをしっかり把握していないと、セキュリティ上の問題に気が付かないケースもあり得ます。

--
よくある話なのですが、日本資本の、海外現地法人が、海外製ソフトウェアを導入して成功したサクセスストーリーを見かけます。ほとんどの日本のSIベンダーが海外で仕事ができない仕組みである以上、海外進出した日系企業の現地法人は、自然と海外製のソフトウェアを導入するしか方法がなくなるわけです。
そこでグローバル化した日本企業は、国産ソフトウェアの海外展開ではなく、海外製品を逆輸入して国内導入するケースは決して少なくはありません。

この様な状況で「日本国内に日本語でサポートを受けられる」事のメリットしかない国産ソフトウェア製品の多くは淘汰されて行くでしょう。

当然このソフトウェアは、海外に現地法人がある日本企業で使われる可能性は、絶対「あり得ない」と言い切る事ができます。

何しろ、海外製品は例え少ないシェアしかなくても分母が大きい以上、開発からサポートに至るまで豊富な経験を積み、グローバルで売れるため資金面もケタが違ってきます。ソフトウェアのライセンス料金も分母に従い多くの利益が出せて、いずれ、製品の価格や機能に還元されます。

--
もし、このソフトウェアのハードコーディングされているメニュー部分を英語と日本語の両用対応にして、ヘルプとマニュアルを日英両方で書けば、それだけで簡単に英語版として出荷できるはず。メディアの中身まで日本語であれば、日英両方のメディアを作る必要があります。どう考えても、このソフトウェアベンダーが海外に進出しようという気持ちが見られません。悲しい事ですが、「どうせ日本というガラパゴス諸島で売れればいい」という意図が杜撰に見えてしまいます。

おそらく、このプログラムのソースコードもそれなりの言語でかかれているのでしょうが、コメントは全部日本語でしょう。元々海外言語にローカライズなど考慮の範囲外です。30年前のプログラムであれば、その様な開発も当たり前ですが、現代のグローバル時代に、グローバルを見据えていないパッケージソフトウェアに未来はありません。

--

残念ながら国産で海外でも成功しているソフトウェア、ITサービスは、外資系日本産サービスの LINE とスーパーマリオを始めとするゲームソフト位しか耳にしません。

--

別に海外製品を礼賛している訳ではありません。日本のソフトウェア、IT産業がグローバル化していない以上、日本の情報産業はますます特殊な市場、ガラパゴスな市場として特化するしかないのです。

多くのIT産業を志望する学生が「知っている日本のSIベンダーは?」と問われれば、いくつもの名が上がるのに対して、「知っているソフトベンダーは?」と問われて、ジャストシステム位しか思い浮かばない、というインタビュー記事を読んだことがあります。もっとも、日本の法令に従って、作らなければならない会計ソフトなどは、それなりに「日本」というガラパゴスの中で生き残る事はあり得るでしょう。

しかし、ネットワークという万民言語が使うシステム管理ソフトウェアが「日本語」にしか対応していないのは、もう完全に市場をあきらめています。

日本のプロプラエタリなソフトウェア開発者は所詮「日本市場」しか意識していないでしょう。その代り、優秀なソフトウェア開発者はオープンソースや外資系ソフトベンダーへ修飾する事が当たり前になります。

その事に気が付かず、「優秀なソフトウェア技術者を集められない」、と嘆く、ソフトベンダーの経営者は何か勘違いしているに違いありません。


islandcenter.jp
by islandcenter | 2015-03-17 14:14 | 雑文 | Comments(0)

よく文章を作るアイディアパッドとして Evernote を使います。個人としては便利なのですが、 Evernote を使って他人とアイディアを共有しようと言うつもりはありません。同じことが DropBox 始め、様々なクラウドのストレージサービスに言えます。

相手の事を考えてみましょう。

私が Evernote のある文書を、誰か他者のユーザと共有できる、と触れ込んでも、その方は使ってくれるでしょうか。

まずは、相手が共有を受け入れてくれるかどうか。

次に、こちらがアップデートした情報を読んでくれるかどうか。

そして共有したい情報を気軽にアップデートしてくれるかどうか。

これらを考えると社外のユーザとの情報共有というのは非常に「難しい」と言えます。

単にセキュリティ上の問題だけではありません。あるいは情報漏えいに繋がるのではないか、という問題でもありません。

相手の文化の問題です。

相手の文化に自分のやり方を押し付ける。

これは中々できるものではありません。

ちなみに、私は Microsoft Office を使いません。Libre Office を愛用しています。とは言え、せいぜい見積書を作るとか簡単なレイアウトを使った文書を作るだけです。大抵、問題なく相手は開けます。そんな私の元に、あの悪名高い "Excel 方眼紙" のフォームが送られました。Libre Calc で読めるし変更もできるのですが、返送したら、見事に文字化けしたそうです。

たったそれだけの事で何万円もする Microsoft Office を必要だと思いません。これも仕事のやり方の押し付けです。

私も経験があるのですが、gmail のアカウントを作ったので、そのアカウントから、システムベンダーに問い合わせる様に、というルールを押し付けられた事があります。しかもセキュリティ上「メールは POP してはならん」ということです。全てウェブ上で作業を済ませろというルールです。

先方はそのルールで長年お仕事をしてこられたので、受け入れやすく、こちらにも押し付けることができます。またそのルールには長けています。

私は既に gmail のアカウントを持っていて、様々な Google のサービスを利用しています。そのアカウントを捨てて、別な gmail のアカウントを使う事を強制するわけですね。そのアカウントでログインしている限り、Google カレンダーにもアクセスできない。しかもパスワードは複雑で、共有する以上、パスワードの変更はできない。

しかし、こちらは長年POPメールを使っていて、メールのバックアップも取る習慣がある訳です。
当然その運用ルールには慣れる事ができませんでした。先方としては「便利だから」という理由なのですが、それは便利の押し付けに過ぎません。こちらでは便利なものでも相手には非常に不自由で不愉快なこともあるわけです。

これはグループウェアを使う時、最大の問題となる点です。

特にスケジュール管理は、手帳でやる人、スマートデバイスを使う人、それぞれやり方が違うところに、無理やりグループウェアを導入しても、手持ちの手帳に転記するわけにもいかないし、使っているスマートデバイスが対応していなければ、結局誰も使わなくなります。

Yahoo のカレンダーを使っている人が、先方との打ち合わせや、資料を Yahoo のカレンダーにアップしても、誰も使わないでしょう。その本人にとって便利なことでも、相手には単に迷惑になるだけなのですね。

この様なお付き合いが爆発的に増えると、朝のチェック項目が爆発的に増えてしまいます。

取引上、弱者は、相手のルールに従わざるを得ません。それだけ時間もコストもかかるということを元請は考慮しません。

という事で、連絡や資料の共有などは、徹底的にレガシーな方法、電話か電子メールで済ませます。
by islandcenter | 2014-11-04 15:32 | 雑文 | Comments(0)

お遊びです。

またまた Windows 8 は 32bit か64bit か

という無責任記事がまだ人気があるらしく、ずいぶんご覧頂いています。ありがとうございます。

じゃぁ、本当に 32 ビットと 64 ビットとのコードの大きさとか性能差ってあるのか。
実際に試してみました。と言っても、Windows には標準でコンパイラが付いていないので、 SUSE Linux の x64 版でのプログラムコードの違いを見てみました。

-テストコード-

/* test.c*/
int x=5;
int y=9;
int z=0;
int main()
{
z=x*y;
}


これみて、「なんで変数がグローバルなのよ、馬鹿じゃないの」と思われた方。鋭いですね。しかし内部変数だと、スタックポインタからの相対値なので、32ビットコードも64ビットコードも命令には変わりなくて、面白みがありませんでした。実際にオペランドアドレスがどうなるのか、と考えてみたら、グローバル変数を使ってみると、ずばりでした。20年ぶりのC言語なので大目に見てください。ご批判もあるでしょうね。

このコードを64ビットネイティブでコンパイルした結果と、32ビットオプションでコンパイルしてできたバイナリのサイズは次の通りでした。

ls -l test64 test32
-rwxr-xr-x 1 me users 9773 Aug 28 18:54 test32
-rwxr-xr-x 1 me users 11852 Aug 28 18:54 test64

こんな簡単なソースコードでも、実際コンパイルしてみると1~2割程度、64ビットコードの方が大きくなったようです。main() の処理より前後に付いているOS用のコードの大きさが実バイナリのサイズの差にあるようです。ただしその周囲のバイナリを見ても64ビットのオペランド処理はほとんどやっていないようです。ただし、x86 なら1バイトの命令でも rXX の64ビットレジスタ同士の演算はプリフィックスが付いた3バイト命令がありました。全体的にはコード自体は32ビットコードの方が複雑でも、1命令自体が1バイトだったりしています。


-32ビットコンパイルと逆アセンブル-
cc -m32 -o test32 test.c
objdump -d test32 > test32.asm

-m32 オプションを付けると32ビットコードを出してくれます。これを objdump -d オプションでダンプすると、逆アセンブルしてくれます。

※ SUSEでは yast > Software Management > から gcc の32ビット環境をインストールします。

main 関数の部分だけ抜き出して見ました。


080483e4 (main):
80483e4: 8d 4c 24 04 lea 0x4(%esp),%ecx
80483e8: 83 e4 f0 and $0xfffffff0,%esp
80483eb: ff 71 fc pushl -0x4(%ecx)
80483ee: 55 push %ebp
80483ef: 89 e5 mov %esp,%ebp
80483f1: 51 push %ecx
80483f2: 83 ec 04 sub $0x4,%esp
80483f5: a1 1c a0 04 08 mov 0x804a01c,%eax
80483fa: 8b 15 10 a0 04 08 mov 0x804a010,%edx
8048400: 0f af c2 imul %edx,%eax
8048403: a3 20 a0 04 08 mov %eax,0x804a020
8048408: 83 c4 04 add $0x4,%esp
804840b: 59 pop %ecx
804840c: 5d pop %ebp
804840d: 8d 61 fc lea -0x4(%ecx),%esp
8048410: c3 ret


20年ぶりに見るi386 アセンブラのコードです。そうだ、C3って ret 命令だったなぁと、割り込みと分岐命令「命」で調べていた、デバッカ開発のプログラマ時代を今更思い出します。この後は 90 (nop) 命令で埋まっています。(おいおい、これじゃ初期のインベーダーゲームと同じだぞ)、nop 命令もしっかりキャッシュされるわけですね。本当は掛け算の命令って何だっけと思って調べてみたのですが、 imul って便利な命令があるんですね。掛け算って cx で loop させるんじゃないんだ。(それじゃ80年代の情報処理試験とおんなじだ)そういえば DEV って便利な命令も 8086 時代に見たことあるしなぁ。8x で始まるのは確かに MOV 直値の命令だったし、 eAX は32ビットのアキュムレータレジスタです。グローバル変数の絶対アドレスを eAX にロードして imul 掛け算しています。

記憶と違って、逆アセンブルしてみると当時全盛だった MASM と違ってニモニックのオペランドの右辺と左辺が違うので、最初戸惑いました。

-64ビットコンパイルと逆アセンブル-

普通に「初めてのC」でやったようなコンパイルです。cc コマンドはオプションなしだと、今動いているプラットフォーム用(64ビット)のコードを吐き出します。


cc -o test64 test.c
objdump -d test64 > test64.asm



00000000004004ec (main):
4004ec: 55 push %rbp
4004ed: 48 89 e5 mov %rsp,%rbp
4004f0: 8b 05 3a 0b 20 00 mov 0x200b3a(%rip),%eax # 601030 (x)
4004f6: 8b 15 1c 0b 20 00 mov 0x200b1c(%rip),%edx # 601018 (y)
4004fc: 0f af c2 imul %edx,%eax
4004ff: 89 05 2f 0b 20 00 mov %eax,0x200b2f(%rip) # 601034 (z)
400505: c9 leaveq
400506: c3 retq



随分すっきりしています。大昔の x86 系のアセンブラより便利な命令が増えたということですね。

しかし、グローバル変数をアキュムレータにロードする場合は eAX を使っています。64ビット命令なら rAX レジスタの表記になります。

何のことはありません。 int x=n ; と書いた時点で、この変数は32ビット変数なのですね。 dword とかの宣言をするとまた変わるのでしょう。rIP 64ビットレジスタからの相対的な32ビット値のオペランドからデータをロードしています。この辺のコードの大きさはデータが32ビットなのであまり変わらないようです。いきなり関数の先頭で rBP のベ64ビットペースレジスタの値を push しています。

ただし便利な命令が増えたせいか、バイナリコードはやけにすっきりしています。

ただ、i486 止まりだった記憶と違ってチラ見した最新の Intel のマニュアルによると、i386 とは違い、x64 では通常の AX,BXや SP,IP ... 以外に r00 - r15 のRISCや 68000 系を思い出す汎用の64 ビットレジスタが16本あるようで(正確には8本でした)、ハードウェアからの割り込みによるスタックの退避などでは、通常の制御レジスタ以外に当然これらの16本の汎用レジスタの Push 操作も行われるのでしょう。プログラマはコードしか見ませんが、ハードウェア的にはシンプルな1命令であっても莫大なメモリアクセスを行います。タスクチェンジなどを行うとページ管理テーブルやディスクリプタ管理テーブル(セグメントテーブル)の膨大な書き換えもあります。おそらく c3 (return) 命令だけでもセグメント切り替えだとか、その前の c9 (leaveq)なんかは全部のレジスタのスタックからの復帰を行うので、大量のメモリアクセスが発生します。デバックに明け暮れた頃、ステップ実行で pop BP して c6 ret するとほっとしたものですが、この命令一発でスタックに積んだキャッシュがモノをいう時ですね。

※ C6 命令はショートジャンプなので、セグメントの切り替えは起こりませんね。間違えです。 jmpf 命令(確か EAh だったはず)

まぁ推測ですけど、32ビットのコードは効率は悪そうですけど、使うレジスタの本数が少ないので激しい割り込みが多いマルチタスク環境でもそこそこ性能は出そうだし、逆に64ビットのコードは、バイナリはそれほど使わなくても実際の動作には随分負担が重そうな感じがします。そもそも32ビットコードでは汎用のr00-r15なんて「何者だ?」の世界だからおそらく無視するでしょう。

コードは1クロック1命令ではありません。 90 nop は 1 clock で実行したような気がしますが、その他の「便利で複雑な命令」は数クロックから数十クロック実行時間がかかります。その辺りは Intel さんのマニュアルにもあるでしょう。

汎用レジスタが多いので、おそらく「素数計算」だとか、浮動小数点演算なんかやらせると、コンパイラの出来次第もありますが絶対64ビットのコードの方が早そうです。

夏休みの終わりに宿題を大急ぎで終えた気分です。Linux のソースより、バイナリから逆アセンブルした結果を調べるという実にひどい悪趣味に最後までお付き合いいただきありがとうございます。

インテルのマニュアルセット

x64のレジスタ拡張 ITmedia
by islandcenter | 2013-08-07 11:00 | 雑文 | Comments(0)