日本のソフトが輸入超過なのは価格差。外国に売るならケータイのフレームワークだよ！

　冷静に考えてよ、アメリカが輸入超過だからって、インドや中国に農産物売ろうって、考える（－＿－）

ここのニュース
大同団結で今こそ海外進出に挑むべし
http://www.itmedia.co.jp/enterprise/articles/0704/05/news011.html
にかいてあるんだけど（以下斜体は上記記事より引用）


電子情報技術産業協会（JEITA）、情報サービス産業協会（JISA）、コンピュータソフトウェア協会（CSAJ）の3社団法人が共同で実施した2000年のソフトウェア輸出入統計調査によると、輸出額は約90億円（対前年比96.7％）、輸入額は約9189億円（同127.6％）となっている（下図参照）。輸入は輸出の約102倍だ。


そりゃ－、輸入超過だろうなあ。。
日本で、ソフトを売れば、高く売れるので、輸入は多いだろうし、
逆に、日本が海外で、ソフトを売ろうとしても、そんなに高くは売れないので、利益が出ないから、輸出は少ないだろうなあ。。。

アメリカが中国製品を多く買って輸入超過なのと同じ理屈で、それはアメリカの技術、産業レベルの問題でなく、価格差の問題ってやつ。だから、アメリカが、自国の技術は他国に遜色ないっていうので、中国やインドやアフリカに売りに行く。。。っていうことがないように、日本も、ソフトを売りに行くことが無い。

---

　具体的に話そう。

　輸入の多くはWindowsやＭａｃ，それと、ＤＢなどだろう。

　これらＯＳやデータベースは、日本でも作れる技術は当然あるが、まず、国内で売っても結構な初期投資が必要だが、利益は出ない（だから、Ｌｉｎｕｘディストリビューターがどんどん統廃合される）。

　ましてや海外に売るには、もっと大きな資金が要る。

　実際、それだけの資金を借金して調達する。。なんていうことは、難しい。。。

　そして、仮に進出したとしても、海外では、利幅が低い。
　もともと物価が安いので、ソフトも安くしないと売れない。だから、日本と粗利のパーセンテージが同じでも、金額にすると小さい。そーなると、資金回収するのが大変。

　結局、ＯＳで利益が出せる会社は、マイクロソフトぐらいしかなく、またＤＢで海外進出できるくらいの利益が出せるのも、オラクルなど、限られた会社であろう。現在これらの市場に出るには、莫大な資金がいるし（仮に国内で対抗するにしても）、そこまであほなことしないでも、もっと利益になるソフト市場はあるので、そっちに進出する。

　だから、日本のソフトハウスは、海外で売ろうとは考えず、もっと利幅の大きい、提案型ビジネス、コンサルティング事業を、国内の、それも上客相手にやろうとしている。
　むしろ、国内でも、買ってくれる客に絞り込みつつある（そして利幅を伸ばす）。儲からない海外に、なんでわざわざ手を広げる・・・

　それは、見栄とか、名誉欲しかない。。

---

　もし、海外でやるなら、

・ソフトを買えば、そのソフトを利用してべらぼうに儲かる。
・それを、外国の金持ち相手に売る

　この２つの条件を満たすのなら、できるかもしれない。

　まー、すぐに思いつくのといえば。。。

　ケータイのフレームワークかなあ？

　東芝ソリューションが、ＢＲＥＷのフレームワークを開発したという話を
「BREWフレームワークを開発」－東芝ソリューション
http://blog.goo.ne.jp/xmldtp/e/806c03e59986db25c787a4fdd209cac2
に書いたけど、これを、クアルコムの海外版のＢＲＥＷでも利用できるように拡張して
（つまり、ＫＤＤＩの固有部分を使えなくするか、それ相当のライブラリを作って）
海外でも使えるようにする。

・そうして、中国の金持ち（富人）と、例えば東芝ソリューションとか
　（まあ、東芝でもＫＤＤＩでもクアルコムでもどこでもいいんだけど）で、
　合弁会社を作り、

・その合弁会社に、このフレームワークを売り、

・それで、海外でＢＲＥＷケータイアプリをじゃんじゃん作ってもらう

・そして、その会社が、香港市場に上場する。

そうすると、その中国人は、商品（ＢＲＥＷケータイアプリ）が売れてもうかり、さらに、上場後、株を売って儲かり、２度儲かることになる（って、どっかで聞いたせりふだなあ）だから、そのフレームワークを、初期投資として導入してくれる。

　こういうように、そのソフトを導入することが、会社の話題作りになり、上場できるとか言うのであれば、買ってもらえる可能性はあるとおもうけどお・・

　

画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その２

　以前、「画面定義をHTMLで行い、呼び出しWebAPIを求める設計手順の試案１」というのを書きました。

そこでやろうとしたことは、
　いままでやろうとしていた、HTMLで、AJAXのXMLHTTP（ないしはXMLHttpRequest）でサーバーのCGIなどを呼び出し、その結果をXMLで返してもらうことによって、次画面を構築する方法、これによって、クライアント画面のHTMLと、サーバーのCGIと完全分離する（CGIで次画面を作らなくていいので、画面部分が完全に分かれる）という方法において、

　画面をHTMLで書いたあとの設計手順についての検討でした。

---

■そこまでのまとめ
　で、そこでは、
（１）画面をHTMLで作成する（ここがスタート）
（２）アクションなど、イベントを拾うところで、
　　　　onイベント=ファンクション
　　　として、とにかく、ファンクションをfunctionでつくってしまう

（３）作った関数について
　　　サーバーアクセスするものは、関数の中に
　　　　　sv_access(呼び出し元、呼び出したいサーバーアプリ,""）
　　　みたいなかんじで、ダミー関数を書く
　　　（あらかじめ、sv_accessは、他のjsファイルにダミーで（＝中身は空で）
　　　　書いておき、それを、参照するようにする）

ってことまでかきました。
　今日は、そのあとのgrepでとってくるところとかです。

---

■サーバーアクセスする関数をまとめる

（４）grepで、（３）のダミー関数（sv_access)を、一覧で取得
　　例：みやぐれっぷ【検索専科】とかで、オプション１で、「サブフォルダも検索」させて
　　sv_accessを検索、一覧を出させて保存

（５）検索した内容をファイルに保存し、Excelで読み込み、
　　　WebAPIのサービス一覧を取得する

　・（４）をファイルに書き出し、Excelでその内容を読み込む。
　　Excelの場合、テキスト区切りに、タブ、,両方設定できる上、
　　その他で、特定の文字も設定できるので、その他で(　も選ぶ、
　そうすると、
　　sv_acess 呼び出し元 呼び出したいサーバーアプリ )
　となるので、呼び出したいサーバーアプリをコピーする

　・このとき、何回も呼び出していると、複数行になるので、
　　これを、単一化する。
　　単一化する範囲を選んだ後、

　　データ→フィルタ→フィルタオプションの設定

　　を選択し、出てきたダイアログで、「重複するレコードは無視する」
　　にチェックを入れると、単一化する

（６）でてきた呼び出したいサーバーアプリ＝サービスを、
　　　１サービス１シートで、下記のようなExcelシートにまとめる。

　・引数は、たいてい画面の入力項目である
　・返り値は、画面の出力項目や、次画面、なにを表示するかの判断材料である
　　返り値はXMLで書くので、タグの場合は、タグの中にあるタグは、
　　字下げして書く。
イメージの例において、ユーザー名がuser1で、結果のコードが０、
　サーバーのCGIのURLはhttp://127.0.0.1/cgi-bin/とすると、

　呼び出しCGIは、
　http://127.0.0.1/cgi-bin/alltest.cgi?user=user1
そのときの返り値は

＜?xml version="1.0" encoding="UTF-8"?＞
＜result＞
  ＜code＞0＜/code＞
＜/result＞

（上記＜　＞　は本当は半角

のようになる。

---

■この後の展開
　上記のExcelシートにWebAPIをまとめたら、それに対応する
ダミーCGIとダミーの返り値を作成し、画面側が、作成できる
ようにします。

---

ということで、ダミーCGIの話は、このシリーズの次回で。。

開発の初めから順番に書いていってみる その２３：要求分析（９）雛形とカスタマイズ

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前前回、要求仕様の問題について書いて、そこで、「プロトタイプ」の話と、「雛形があってそれをカスタマイズ」の話を書くということを書きました。
　前回、プロトタイプの話を書いたので、今回「雛形があってそれをカスタマイズ」の話です。

　なお、今回の話はあくまでもウィリアムのいたずら個人の意見であり、一般的な意見ではありません。

---

■ラーメンのスープをしょうゆのとんこつにして。。

　要求仕様の問題点のところで、「要求仕様にできないことが書いてあるかもしれない」ということを書きました。

　これは、ユーザーの要求は、実現してないものを要求としてあげるため（っていうか、実現しているものは要求する必要ないけど）現実的には、無茶なことを要求してしまうことがあります。
　これを、たとえ話で言うと、ラーメンを作るとしましょう（ラーメン＝システム）
　今の気分は、こってりしつつ、あっさりしたのがたべたい。

　こってりした、とんこつはたべたことある。
　あっさりした、しょうゆラーメンを食べたことある
（ちがうかもしれませんけど、仮に、そうだとします）。

　そこで、ラーメン屋さん（SEさん）にむかって

　「ラーメンのスープをしょうゆのとんこつにして。。」

　といってしまうと。。。
　どんな味になるんだ？？

---

■ユーザーが知っていると、それを組み合わせて。。とかんがえてしまう

　これは、ある程度、お客さんに知識があるとき、顕著に起こります。

　組み合わせることが、可能かどうかというのがわからず、組み合わせてしまうため、システム的に（ラーメン的に）おかしくなったり、不要に重くなってしまったり（トッピングしすぎで、らーめんかどうか、わからなくなる）します。

　お客さんじゃなくって、営業がそうしてしまうこともあります。
　営業もある程度知っているので、この手の話がおこりやすくなります。

　どこをいじると、システムがおかしくなる（ラーメンのスープの味が崩れる）かがわからないため、無茶な組み合わせをします。

---

■ラーメン屋さんは、そーはしていない。

　でも、ラーメン屋さんは、ふつう、お客さんに、しょうゆのとんこつという組み合わせをさせません。
　ふつう、ラーメン屋さんは、あらかじめ、こういうラーメンを作るというものがあって、特注とか、トッピングで多少変えます。
　だから、ラーメン屋さんはなりたつのであって、客に合わせていたら、おいしいラーメンもめちゃくちゃになっちゃいます。

---

■そー言う意味で、雛形とカスタマイズ

　そーいう「こういうラーメンを作る」っていう部分が雛形で、「特注とか、トッピング」がカスタマイズになります。
　つまり、雛形部分を自社にあわせる（自分の好みに合わせる）ために、カスタマイズが必要になってくるっていうことです。でも、雛形となる部分は、ある程度できる見込みがないと（スープをちゃんと作って、ラーメンの味が崩れないことを確認しないと）、客の要望だけではめちゃくちゃになる危険があるってことです。

　つまり、今みたいに、客の要望をきいて、それを元につくるというシステム開発は、客の側で、絶対できるという閉じた世界観のシステムを提案しない限り（ラーメンとしてスープも麺もこれでOKという裏づけがないと）、危険である、客の言ったとおりに作ってつくれるかどうかわからないということになります。

　こちらから、作れるラーメンを（雛形システムを）提案するのであれば、OKなんですけど、そーじゃないと、とんでもないものを作ろうとしてしまう可能性があると。。

---

■カスタマイズのさいのフィット＆ギャップ

　で、カスタマイズする場合、フィット＆ギャップ分析ということになるのですが、その場合、よくやるのが、製品の機能についてのフィット＆ギャップ分析です。
　しかし、ラーメンで考えると、トッピングを安易に変えても、おいしくならないわけです。作り方とかあるし。。そうやって考えると、作る材料、作り方から吟味しないといけません。

　同じように、フィット＆ギャップを考える場合でも、まず、入出力データレベルで同じかどうか、その後、処理過程が同じかどうかなど、順を追って差を確認しないと、結果だけ追っても、無茶な部分が出てきます。

　っていうことは、雛形自体の、エンティティやプロセスを明確化し、そのプロセスと出力がどう関係するかというのをだしておかないといけません。
　そのような、仕様を明確化した雛形を、各ソフトハウスが出しておくことで、システム開発の精度、要求分析の精度は、かなり上がってくると思います。

---

　ということで、次回から、外部設計です。

ネットワークのIPアドレスとあけているポートはメモしておいたほうがいいかも

　詳しくは書けないけど、教訓。。

　ネットワークのIPアドレス（とくにグローバル固定）と、
　そのIPアドレスで、あけているポートはメモしておいたほうがいいかも。。。

　複数のアプリを入れた場合、アプリごとに使うポートが違うので、
　いろいろあけたり、拒絶したりしているわけですけど、
　その情報、ネットワーク管理者は、知っているかもしれないけど、
　そーでないひとは、知らないわけです。

　で、ネットワーク管理者に頼っていると、
　その人が退職した後で、
　そのルーターが壊れたり、何らかの理由で工場出荷時の状況に直さなきゃ
　いけないとき（というか、直されてしまったとき）。。

　どのポート空ければいいんだ（＾＾；）

　ってなってしまう。。

---

　退職したとき、ドキュメントを、書いてくれる。。
　といっても、そのドキュメントをちゃんと保管してるかどうか疑問だし、
　仮に保管してたとしても、
　　やめる会社のドキュメントをまじめに書いてくれるかどうか疑問だし、
　っていうか、ネットワーク管理者がまじめに書こうとしても、
　　うっかり忘れた、間違えた！がないとはいえない。

　なので、ネットワーク構成とか、空けているポートとか、
　ネットワーク管理者がちゃんとしている（＝在職している）うちに、
　ドキュメント化し、そのドキュメントが理解できるようにしておくこと、

　書類が散在しないように、ちゃんと整理して、まとめて保管しておくことは、
　大切だと思う
　厳密に言えば、定期的なチェック、見直しも必要だけど。。。

　そこまでは、やれないか（＾＾；）