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

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

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産業はもっぱら内需にしか向かっていません。






[PR]
by islandcenter | 2016-04-20 21:21 | Trackback | Comments(0)


- 現象 -

Hyper-V が動作すコンピュータのメモリ利用状態が90%を超えた状態で、全てのレスポンスが異常に遅い。すべてのアプリケーションを終了させたが、メモリ利用状況は変わらず 90% を超えている。

a0056607_06361868.jpg
なんじゃこれ!

- 内容 -

やむを得ずシステム全体を再起動したが、状況は2日程度で再現する。

Hyper-V で仮想マシンが動いていたのでシャットダウンしたら現象が回避できた。

a0056607_06372430.jpg
なんじゃこれ!

- 原因 -

Hyper-V で仮想マシンをシャットダウンしたら修復できた。 Windows + Hyper-V のメモリリークと思われる。ちなみに動作していた仮想マシンは 768Mb のメモリしか占有していなかったにも関わらず6G以上のメモリがリークされ、ガーベジコレクションも行われない。ちなみに同じ仮想システムイメージは他のハイパーバイザーでは再現しない。

- 対策 -

- Hyper-V ハイパーバイザーを定期的にリブートする
- 仮想コンピューターを定期的に夜中にリブートする。
- Hyper-V から別なハイパーバイザーに乗り換える。

なお、仮想コンピューターをシャットダウン、リブートするコマンドラインはないので、VBscript などを書くか GUIから手動で行わなければならない。夜中の業務時間外にリブートするコマンドは標準では実装できないので、深夜出勤してGUIで操作するか、 Hyper-V 自体のハードウェアを UPS や Shutdown コマンドで定期的に業務時間外にリブートする方法が最適と考えられる。


だから、 Hyper-V だけは絶対やめた方がいいと言っただろうが。

関連記事





[PR]
by islandcenter | 2016-04-11 06:41 | Windows | Trackback | Comments(5)

Administrator 以外の一般ユーザがリモートデスクトップPCクライアントを利用できない。

- 現象 -

ドメインに参加しているPCに対して Administrator@mydomain.intra ユーザがログオンすることができるが、一般ユーザ user@mydomain.intra がログインできない。MSTSC からログインしようとすると

このリモートコンピューターにログオンするには"ターミナルサービスを使ったログオンを許可する" 権利が必要です.....」

a0056607_11044474.jpg
と表示されログインできない。なお、このユーザは "Remote Desktop Users" グループに所属させている。
a0056607_11052581.jpg


- 対策 -

リモートデスクトップPCに接続するユーザを「対象のPC」にリモートデスクトップ接続できる様にリストに追加する必要がある。

具体的には、Administrator@mydomain.intra でログインしてから、コンピューター > 右ボタン「プロパティ」 > リモートデスクトップ接続、の中の「ユーザの選択」の中に「追加」ボタンから、リモートデスクトップ接続を許可するドメインユーザ(もしくは別途作成したユーザグループにユーザを追加し)を検索して「追加」する必要がある。
a0056607_11060802.jpg

ちなみに、このグループに Builtin Group である"Remote Desktop Users" はリストに出ないため選べない。(すごい仕様だ)
a0056607_09310267.jpg
ビルトインの Remote Desktop Group なんてないじゃん。

この作業を行わないと、ドメインユーザがVDIなどのサーバーにインストールされた仮想PCのリモートデスクトップが利用できない。
a0056607_09313717.jpg
これはおなじみだったりする

ちなみに、この問題のユーザを ドメインの中で "Remote Desktop Group" から削除しても、ローカルPCにリモートデスクトップユーザ、あるいはユーザグループとして登録しておけば、問題なく接続できる。(つまりDCで Remote Desktop User を設定しても無意味なんだな、何のためのDCなのよ...とほほ)DCサーバー側からの制御はできない。

a0056607_11052581.jpg
本当か .....? ってかこの方法しかなかったンだけど、他にいいアイディアがある方はコメントください。



ちなみにユーザかグループは選べるが、コンテナ(OU) は選択できない非常におバカな仕様である。当たり前だが Novell eDirectory よりバカだな、やっぱり Windows って。


[PR]
by islandcenter | 2016-04-01 11:13 | Windows | Trackback | Comments(0)