パスポート電子申請、中止。。。ほかのe-Japan構想は？

ちと古いですが、ここのニュース
旅券電子申請、中止へ　無駄遣いと指摘受け外務省
http://headlines.yahoo.co.jp/hl?a=20060710-00000130-kyodo-pol

あんまり、使ってなかったからだからみたいですけど、
ほかのe-Japan構想のものってどーなんでしょーねー。
これをかわきりに、ほかのも。。。とか。。。

え、他のは、みんな使ってます!って？

。。。ちなみにウィリアムのいたずらは、引越しして、住民票が必要でしたが、
市役所にいったときに、一緒にとっちゃったし。。
所得税は、税務署に行って納付してきました。

ＩＰＶ６の概要と、移行の時期と可能性

　ちょっと順番逆になってしまいましたが、昨日のＩＰＶ６の話のつづき、
　ＩＰＶ６の概要と、移行の時期と可能性についてのまとめ

---

■ＩＰＶ６とは
　現在のＩＰであるＩＰＶ４によるアドレスの枯渇等の問題を解決すすために出てきた次世代のＩＰ。バージョン５（RFC1190, RFC1819等など）がすでにあったので、ＩＰＶ６（バージョン６）となった。

大きな特徴としては
・アドレス空間が大きくなった（それに伴って、アドレス表記もかわる）
・アドレスの割り当て方法はＩＰＶ４と異なる
・パケットフォーマットもＩＰＶ４と異なる
・などなど、ＩＰＶ４との互換性はない
　→共存させるにはトンネルさせる等のしくみが必要。
　　移行コストがかかる。

■活動団体について
KAME BSDベースでIPV6対応をしたプロジェクト。
　　２００６年３月、活動終了
USAGI LinuxベースでIPV6対応をしたプロジェクト
　

---

■IPV4からIPV6への移行に必要なこと
・プロバイダ等
　プロバイダやプロバイダが回線を仕入れるＩＸなどがＩＰＶ６に対応しないと、ＩＰＶ６は広まらない（というかできない）。現状、ＯＣＮやＯＣＮ，ＩＩＪはサービスを行っているが、それ以外の大手はまだまだである。これについては「ＩＰＶ６の移行の時期と可能性」で述べる

・ルーターなどのネットワーク機器
CISCOについては、ここやここ
　YAMAHAのネットボランチをみたら、次世代インターネット・プロトコル「IPv6」を標準搭載ってかいてあったから、マニュアルとか見ればわかるんだろう。
　CiscoとYAMAHAのネットボランチが対応してればＯＫ
　（って、おいおい、それでいーのか　＾＾；）
　ＩＰＶ６対応スイッチなども出てきている。

・プログラム
　IPV6対応が必要。
　Linuxの場合、USAGIによって、いろいろ対応してるみたい（ここ）
BSD（Mac OS X カーネル）は、KAMEによって、いろいろ対応してるみたい
　Windowsの場合、Windows XP SP1からは、対応しているよう（ここ）

　ただし、上記の話は、あくまでもＯＳレベルの話で、自分がネットワーク関係のＡＰＩを呼び出して作ったプログラムを、なにも手を入れないでそのまま動くかという話は別問題。
　

---

■ＩＰＶ６の移行の時期と可能性
　技術的には、あとプロバイダが対応すればＩＰＶ６に移行できる。
　そこで、移行に必要なものは、あと
　・人的な対応
　　→ネットワークの移行手法の問題、
　　　業務プログラムでネットワーク関係のＡＰＩを呼び出しているところの見直し
　・資金的な問題
　　移行にかかる資金的な問題。
　　これは、ユーザーがわだけでなく、プロバイダ側にも、おこる
　　→新サービス提供となるため、ハードだけでなく、そのためのサポート部隊
　　　その他もろもろいろいろかかる。

　また、移行の時期の影響要因として、
　　・ＩＰアドレスの枯渇の時期
　　　→これは、現在、IPv4 Address ReportのAn Analysis of IPv4 Addressesに書いてある。
　　　　２０１１年ごろ

　以上の要因をあわせて考えると、ＩＰＶ６普及のために必要な要員は、ＩＰＶ６移行のための教育とプロモーションをだれが、いつ行うかということと、ＹＡＨＯＯなどの大手プロバイダがいつ動くかということになる。

　ここで重要なことは、ＩＰＶ６にしても、すぐにサービス上、目立ったメリットがユーザーにあるわけではないので、このＩＰＶ６を利用して、ユーザー獲得というマーケティングができないことだ。ユーザー獲得のためのマーケティングは、高速通信をうたった、ＦＴＴＨのほうが効果的と思われる。
　そこで、余裕のあるプロバイダ（ＯＣＮなど）は別として、他のプロバイダは、さきにＦＴＴＨなどで、顧客を獲得した後で、ＩＰＶ４のアドレス枯渇のために、アドレスを早く取得しようキャンペーンを行い、その後ＩＰＶ６へと移行してくると思われる。

　これらのことを考慮すると、プロバイダがＩＰＶ６に力をいれることを考えるのは、次期中期経営計画をたてるとき（中期経営計画はふつう３年位ごとに立てる）と思われる。それが実行に移されるのは、１年程度あると見ると、２００７年ごろからはじまるかもしれないが、２００９年ごろあたりから本格的に力を入れだすと考えられる。

　なお、アドレスに比較的余裕のあるアメリカより、日本のプロバイダからこの動きは仕掛けるものと思われる（具体的には、ＹＡＨＯＯかＯＣＮかフレッツ）。

---

　
　この予測の波乱要因としては、以下のことがあげられる

・アメリカで、ＩＰＶ６をしのぐ、あたらしいプロトコルが開発され、マイクロソフトが採用する

・ＯＣＮとフレッツがＹＡＨＯＯＢＢつぶしのため、ＩＰＶ６をメインとした新たなサービスをはじめた場合
　→ただし、それでも、２００７年以降と考えられる

・ＤＴＩが、小西真奈美人気を利用して、「起立！礼！小西真奈美です。ＩＰＶ６しよ！」といって売り出した場合
　→まずありえないが、やったら、今の小西真奈美なら、世の中をひっくり返すかもしれない。

・だれも、ＩＰＶ６を仕掛けなかった場合
　　　ケータイがネットワークの中心となってしまった場合
　　　　→オンラインゲームなどもケータイに移った場合
　　　インターネットが使われなくなった場合
　　　　→戦争が起こり、自由な通信が認められなくなった場合
　　　などなど

・非常に大きな不景気になった場合
　企業がどんどん減り、ＩＰアドレスがどんどん返上された場合
　プロバイダに再編がおこり、ＯＣＮとフレッツしか、のこれなかった場合
　　→この場合、再編が起こった後で、移行が進む。

---

Ｐ．Ｓ個人的な素朴な疑問
そもそもpureなIPV6だけの環境って、今、出来るのかなあ。。
ＤＮＳの名前解決にＡＡＡＡレコード（＝ＩＰＶ４の場合のＡレコード）をIPV4パケットで送るって書いてあったけど（中身はＶ６でも）

地図をケータイで表示する場合の方法

　で、本題の地図をケータイで表示する場合。
　今回は、以前ロボットで考えたように、建物内でも、建物外でも使えるものを考えよう。

　つまり、建物内の場合、
　・なにか目印が合って（もちろんＱＲコードが建物に貼ってあって、それを読み込むんでも、
　　まがりかどに２Ｆ－１のように、番号が書いてあって、それを見るのでもＯＫ）
　　それをケータイに入力し
　・行き先を選ぶと
　・地図に、ルートを表示してくれる

　建物外の場合、
　・ＧＰＳかなんかから、位置を取得し
　・行き先を選ぶと
　・地図に、ルートを表示してくれる

　っていう２つの機能を、同時に持っているとする

---

　前のブログでかいたように、このような場合は、
　・ある記述言語、データの形で送る（ベクトルデータ）
　・イメージにしておくる
　の２とおり考えられる。

　地図の場合、地図データのベクトル表現ってのは、各社各様に行われている。
　したがって、このベクトル表現を転送して、ケータイでこれを表示するっていう形になる。
　ケータイ会社が違えば、プログラムも各社ごとに用意することになる。

　で、この場合、建物内の地図も、同じように、その会社のベクトル表現であらわし、それを表示するという形になる。

---

　もう１つの方法、イメージの場合、これは、以前書いた、ＤＴＰの場合とは異なる。
　ＤＴＰは、毎回、たいてい出力する文章は異なる（新聞は毎日違うこと書いている）
　ところが、地図は、（入れ替えない限り）まえの地図を表示しておけばよい。

　そのため、あらかじめ、各地域の地図を用意しておき（場合によっては拡大倍率に応じて複数用意し）、指定された地域のものを探し出し、表示するっていう形でＯＫかもしんない。

---

　ここで、２つの間の地域を選択されてしまった場合は？
　と思うかもしれない。
　それと、行き先を示すとしたら、その線は？
　と思うかもしれない。

　それについては、サーバー側で、GDライブラリをいれておき、２つの写真を合成したり、（ＧＤで）線を引いたりして、その結果を、(GDで）jpeg形式にして、書き出せばよい。

　ということで、サーバー側に、地図イメージファイルをもち、GDライブラリで線を引いたりその多加工して、出力するとしたほうがいいかもしれない。
　そーすると、ブラウザですむ。

---

　ただ、この場合でも、どう行ったらいいのか、の計算をするために、ベクトルデータは必要となる。また、建物内のデータをベクトルデータにする必要はある。
（でも、そもそも、こんな計算は可能かどうかは別の話）

　でも、これをやるとなると、ちと地図だと不便。

　今東京駅にいて、沖縄の那覇空港には、どうやって行きますか？

　って、聞いたら、ロボットなら

　浜松町にいって、羽田空港にいって、那覇に飛行機で行く

　って答えればいいだけだけど、地図で、羽田空港から那覇空港まで線を引っ張ったら、たぶん、浜松町と、羽田空港の部分は見えないぞ（＾＾；）

---

　で、もし、ケータイで地図を表現する場合、ベクトルデータを使ったとしたら、結構じかんがかかってしまう。また、細かいデータだと見えにくい。

　そういう意味で、地図をもっと、簡素化できないか？っていう話が出てくると思う。

　それで、面白い取り組みを、今度、気が向いたら書きたいと思う。
　（ってか、それを書きたくって、この話、わざわざここまで引っ張った　＾＾；）

２次元、３次元データを転送する場合と、その処理について

ちょっとある話の前フリと、まえのタイトル変えました＆Ｗｅｂ４．０とはの最後のほうで書いた

その新聞データが放送局にいって（印刷前に）その新聞記事ををパソコンで
　切り貼りしながら原稿を作る。。。


に関係のある話で、
　　２次元データ、つまり、ＤＴＰソフトの出力やＰＤＦ
　　３次元データ、つまり、ＣＡＤソフトの出力やVRMLなど
が実際に表示されるまでの処理の流れと、どのタイミングで、転送が行われないとまずいかという話。

---

　ＤＴＰソフトで考えよう。この場合は、Postscriptという、ページ記述言語でデータが書き出される。このページ記述言語には、どんな文字をどこにおくかとか、どのイメージをどこに置くかの情報しかない。

　これを目で見えるイメージに変換する。この処理をラスタライズといい、このラスタライズをする機械をRIP（リップ）という（注：ネットワークで言っているＲＩＰとは、まったく違うもの）。
　３次元ＣＡＤデータなどだと、レンダリングという。っていうか、いま、印刷業界以外の人は、ラスタライズもレンダリングって言っちゃう人がいる（印刷業界では、ラスタライズとちゃんと言うと思う）

　そして、イメージ化した画像を実際の出力機にかける。
　したがって、ラスタライズは、出力機の解像度を意識して行う。解像度が高ければ、ラスタライズも高精彩に行うことになる。したがって、時間もかかる。

---

まとめると

　　ＤＴＰ，３次元ソフト
　　　　　｜（２次元）ページ記述言語、（３次元）３次元データ
　　ラスタライズ（ＲＩＰ）・レンダリング
　　　　　｜（イメージファイル）
　　　　出力機

　という手順になる。
　なので、転送できるタイミングは、
　　　（２次元）ページ記述言語、（３次元）３次元データ
　か、
　　　（イメージファイル）
　のどちらかになる。

　ちなみに、トリビアを述べておくと、ＲＩＰは、アドビで標準的なものを出している。
　これが、CPSI（いま、違うかも。。）

---

　ここで、話を簡単にするため（というか、あとでこの話をつかうとき、２次元しか話をしないので）２次元に話を絞る。

　ページ記述言語のＰｏｓｔｓｃｒｉｐｔやＰＤＦを転送した場合、相手側のＲＩＰで、イメージ化するためのすべての情報が取得できないといけない。
　たとえば、フォントが無かったら表示できないし、写真も出力が高精彩だったら、高精彩にしないといけないので、その高精彩ファイルがアクセスできないといけない。

　しかし、逆の言い方をすれば、たとえば、新聞社の新聞を読んで、それから重要ニュースをピックアップ、放送に使うなどというときには、高精彩画像は、（すくなくとも記事を選んでいる段階では）いらない。
　これにより、転送量は、大幅に省けることもある。。。が、事故も起こりやすい（画像のリンク切れ）

---

　一方、イメージを送る場合（印刷業ではTIFF/ITというフォーマット）、ＲＩＰ終了後なので、ＲＩＰに時間がかかったら（新聞等は時間がかかる。紙面が大きいから）ページ記述言語が出来てから、転送するまでにかかる時間は、おそくなる。
　
　それと、この場合、サーバーにＲＩＰがあったら、ふつうサーバーでＲＩＰ終了するまで、転送できないということが多い。一方、ページ記述言語の場合、ラスタライズしながら表示するということも、可能ではある。

---

　そんなこんなで、さっきの「新聞社の新聞を読んで、それから重要ニュースをピックアップ、放送に使うなどというとき」には、ＤＴＰソフトからの出力（ＰＳ，ＰＤＨ，あるいはＤＴＰソフトのファイルそのもの）を転送するのが、いいみたい。

　では、地図をケータイに送る場合を考えると。。。

　ってことを、今度、機会があったら書きたいと思う。

オフシェア開発の先としての自動生成を考える必要性が早まった？最近の国際情勢で！！

　日経コンピューター２００６年７月１０日号Ｐ１８に

オフシェア開発、大型案件に浸透
”今欲しい”技術者確保に向け、発注量は前年度比２割増へ

っていう記事があります。

　オフシェア開発に大手さんは、大々的には向かっているようですけど、
　でも、ここで、オフシェアの比重を増やしてコストダウンなんてことで、
安穏としていたら、次のコーナー回ったところで、時代遅れ、業績急低下！
になっちゃいそーですよねー（＾＾）

---

　なぜか、理由は２つ！

１つは、オフシェアの単価を、
国内の（北海道など）地方で経済がぼろぼろに崩壊してしまった地域の人件費と
比べると、そんなに差がなくなりつつある、
いや、将来的には逆転すらありえそうなこと。

　上記の記事中にも、オフシェア開発の人件費が「単価４０万前後と」とあります。
　でも、国内の技術者も、地方にいけば、その程度ってことは、たしか、
　日経コンピューターでも書いていませんでしたっけ？
（ごめん、いつの日経コンピューターだかわすれた。価格崩壊の号）。

　また、海外の場合は、残業代を払わなければいけないケースがありますけど、
日本の正社員の場合、事実上、残業代を払わないでいいケースがありますよねー
（詳しく書くと、労働なんとか法の問題になりそうなので書かないけどお）。

　この場合、長時間拘束（事実上２４時間、数日拘束）などという場合、
費用は逆転しちゃいます。

　オフシェアって、今後を考えると、必ずしも安くはなりません。

　また、中国人を統制する上で、面子（めんつ）の問題は最悪ですよねー。
　仕事のすべての信頼関係は崩壊し、仕事どころではなくなる危険がある
。。って、あんまり書くと、国際問題に発展しそうなので、このへんでカット！

---

　しかし、そんな議論は、どーでもいいんすよ！
　もう一つの理由の、オフショアの先の話が重要なのです。

　オフシェア開発において、仕様書は
（以下の斜体は、日経コンピューターのＰ１８から引用）

詳細設計書における分岐条件に、日本語の「または」、「かつ」、「未満」などを
つかわず、「or」、「and」、「＜（不等号）」などで書くようにしている

と書いているように、プログラムに近くなり、さらに型にはまった
書き方になってくると思います。


　プログラムに近づき、型にはまったとくれば。。。自動生成！！

　これにより、人が必要なくなるというだけでメリットは大きいです。
　さらにそれに加えて、そこが自動生成されることで、すぐに結果がでてきて、
開発のテンポが早くなるというメリットも、これまた大きいのです！！

　なので、もし、オフショアに出しているところの自動生成に成功すれば、
他社をだしぬく、大きなアドバンテージになります。

---

　ここで、昔のＣＡＳＥの歴史や、昨今のＭＤＡの話をもってきて、
そんなのできるわけ無いじゃんって反論してくる輩がいるのは、
百も承知の上でーす！！

　しかし、そんな広範囲なことを、もともとやろうとしているんじゃないです。
　さらに、必ずしもすべてを自動化しようなんてことも言ってるわけじゃないです。
　→コスト大幅削減すればＯＫ

　仕様上、ここはこうきたら、こうプログラミングするっていうパターン的なとこ
（って、デサインパターンのパターンじゃなくって、それよりも、もっと
大きな概念の”業務パターン”）たとえば帳票出力や画面表示、作業指示書作成
などなどを自動化してしまうってかんじです。

　いや、自動生成まで行かなくても、この手順をマニュアル化し、この組み合わせで
システムを表現できれば、仕様の作成は簡単になってきます。
　オフシェアでは無理でも、パートタイムの主婦、フリーターでも、にわかＳＥ化が
可能です。彼らは１人月２０万程度のバイト代でＯＫ！
　４０万のオフシェアの半額です！！

　そーいった、部分的、ゲリラ的な自動生成＆マニュアル化におよる効率アップと、
それを利用したオフショア部分の発注削減が、これからの鍵になると思います。
（フリーターを２０万程度で活用ってのも。大手が直接フリーターを雇うというのも
　将来的にはおもしろいアプローチかもよ！？）

---

　と、ここ数日前までは、こんなのんきなこと、ぶちかましていたわけですけど、
　こんなもんは、平成のねむりをさます蒸気船じゃなかった、
　ミサイルでぶっ飛んでしまいましたねー。


　オフシェア開発は、中国、インドなんて、国際的に危ない国に発注しているわけ
じゃないですか！！。

　そりゃー危険っすよおーー（＠＿＠！）。


　中国とか、なんかがもとで、喧嘩となり、国交断絶！とまでは行かなくても
（むかしは「いくわけないじゃん（＾＾）」で済ましてたけど、きのうあたりから、
そうも言い切れなくなった）、どっかにDDos攻撃をかけて、インターネット回線が
混み合いすぎて不通とか。。ないとは、ありえそーですよね！

　もちろん、現地にいる日本人は、危険です。


　じゃあ、インドはっていうと。。。これまた危険だ。
　インドに行ったら、テロに会ったなんていうのも、ありえないことじゃなさそうだし。
　インドも（失敗ですか？）なんか、ミサイルぶっ放してたし。。

---

　てなわけで、オフシェア開発の場合、カントリーリスクがあり、
そのリスクは最近、とみに、とみに！大きくなった気がします。

　そのリスクに備えるという意味では、いまから

　自動化システムの開発や、
　地方の利用（とくに北海道や沖縄）
　パートの主婦、フリーターを直接大手が（アルバイトとして）採用！

　なーんていうことを見据えて、仕様書をパターン化（業務のパターン化）
を研究しておいたほうがいいのかもしれない。

　具体的な業務のパターン化については、このブログの趣旨（オフシェア開発とカントリーリスク）に関係ないので、別の機会に（覚えていたら）