  |
はてなキーワード: データセンターとは
http://cloud.watch.impress.co.jp/docs/column/cloud/20140314_639562.html
ただ、一口にAzureといっても、北米と日本のデータセンターで提供されているサービスは異なる。どちらかといえば北米はフルセットのサービスで、日本はサブセットになっている。また、東日本と西日本で提供されているサービスも異なる。
例えば、Mobileサービスやビッグデータの解析を行うHDInsight、BizTalk Serviceなどは、日本のデータセンターでは現時点で提供されていない。Media Serviceは西日本データセンターだけで提供されている一方、ネットワークのVirtual Networkは東日本データセンターだけで提供されている。
なんだこれ。
今の仕事が徹底的に向いていない。仕事というのはつらいだけか。そんなもので人間性が磨かれるのだろうか。
どうしてこんなことを仕事にしている会社があるのだろう？ 本当に疑問だ。社会に求められている仕事だとは思えない。なんだろうこの仕事は。誰のための仕事なんだろう、客がいない。見えない。データセンターに客はいない。そりゃ営業は客に会ったのだろう。俺はあってない。残念だ。本当、なんの仕事なんだろう。発狂しそうだ。毎日狂いそうだ。俺だけが狂いそうじゃない。いや、俺だけが狂いそうなのか、狂っているのか。これほどいやな仕事。お金のためとはいえ、自分をここまで犠牲にするほどお金が大切なのか。一日でいいので楽しく働きたい。毎日が苦痛だ。自分じゃないと自分は助けられない。ほかに同じ境遇の人はいないだろうか。狂ってしまえば終わるのなら、いますぐ狂いたい。発狂したい。うつ病ならそれでいい。もう嫌だ、
原本を電子データで持つかアナログデータで持つか、って問題だよね？
デジタルデータだって電磁波兵器やら太陽風なんかで消失する可能性だってあるし、データセンターが災害でアボンとか、バックアップや移行作業の失敗で消失とか、サイバー戦争とか、リスクはあるぜ。
アナログデータにも、挙がってるように消失や劣化のリスクがある。
原本さえあれば、あとはデジタルだろうがアナログだろうが、好きなように「出版」できる。
べつにデジタル/アナログどちらか一辺倒にならなければならない宗教に加入していないのであれば、原本データはハイブリッドで持つのがいいんじゃないの？
こんなのもあるよ。
A4サイズの紙1枚に1MBのデータを印刷してバックアップできるソフト「PaperBack」を実際に使ってみました - GIGAZINE
ちなみにプラネテスの月面で生活してる人たちはオール電子書籍だったね。それは紙とか物質資源を運ぶコストのほうが高くつく、という事情があるからだけど。
試験業務中心だった。
その中でもシステムテストとかやったりしてるのでネットワークやサーバー、アプリは商用の状態に近い環境で試験をしている。
具体的にはサーバーはLB使って冗長化/スケールアウトされていたり、クラスタリングされていたり、データセンターにあるサーバーにリモートでログインして試験をしたりとか。
rebootコワイヨーとかHW障害うざいよーとか思いながら。
ソフトウェアの受託開発の会社で、Javaの業務アプリを設計・開発・試験していた様な人達が集まっているので、ネットワークやLinuxなどアプリよりは低レイヤなところに詳しい人が地味にいなかった。
システムテストの項目書をExcelで作るお仕事や、試験を実施するお仕事は凄くやる気しなかったが、試験の実施方法を検討するお仕事や、試験をするための環境を構築したり、仕様書を読んでミドルウェアやアプリにコンフィグを投入する仕事は楽しかった。コンフィグを投入する作業をスクリプトで怠惰に自動化したりするのは、けっこー楽しかった。
リグレッションテストや、バージョンアップでの改修テストなどで環境を再構築する際に、作成した自動化スクリプトは腐らさせずに誰かに展開することが出来たので、自動化した工数も無駄にはならなかった（ちゃんと効率化に！）大量にデータを投入するとき、さすがにだるい。ツールも使えば使うほどバグなくなるし良い感じ。PerlやBashを覚えるきっかけにもなるし。
今思うと出向も楽しかった！メーカーSIの会社は社員食堂とかあったので、うわすげぇドラマみたい！とか朝はエレベーターの前に人が並ぶのでうわすげぇ人多い！とか。（最初だけだけど）
後はサーバー室でサーバーとかLBとかを目の前で見れたのがテンション上がった。うわこれF5じゃね？うわこれJuniperやん…いくらすんだよ…HPのブレードサーバーだ！いくらするのかググった。
まぁ、普通に誰も興味示さないw あの時は商用ネットワーク機器という物に憧れている少年だったw
作業で疲れたときはぶらぶらして眺めてた。
何かの見学の時は「おいふらつくな」とか誰かに怒られそうだけど、仕事で来てると誰も何も言わないので見たい放題。転んでケーブル抜いた日には大問題になりそうなので、さすがにそこは気をつけた。
あの1UサーバーにRHELをインストールするとか、少年には楽しすぎた。でも手順はMacのVirtualBoxにCentOS入れるのと変わりはなかった…。ただ、仕事として1UサーバーにRHELをインストールした、という経験を持つことが嬉しかった（少年だから）
でもいいさ。
F5なんか使わずにLVSやUltraMonkey-L7で負荷分散すればいいし、商用のアプライアンス機器なんか使わずにオープンソースで解決してしまおう。AWS使うならELB使えばいいし。そういう環境行ってみようぜー。
最近は、女性向けの同人活動ということで、pixivをメインとした活動もされるようになった。pixivのランキングで女性向けのイラストが入っていたり、一部の方が大衆の不快にしてしまう行為をしてしまうけれど、女性向け同人として、pixivは同人活動においてなくてはならないものとなっている。pixivでの活動自体は、2年前ぐらいからはあったが、現在、さまざまなジャンルのアンソロジーの企画ページを見ると、参加者の一覧での参加者ページのリンクがpixivだけになっていることが多い。もう、同人活動のメインとして、pixivがメインなのだ。
実際、pixivはあくまでもSNSサイトであって、ホスティングサービスでないのは事実。Facebookを市のサイトとして全面移行しようとした佐賀県武雄市と同様に、腐女子がpixivを作品を展示できるホスティングサービスと勘違いしているのも事実。
もし、pixivがなくなったらどうなるんだろうか。一からHTMLを学んで、レンタルサーバーを借りて、ホームページを作ったり、FC2ブログで似非サイトを作ったりするんだろうか。
私自身、pixivは、信用できない企業だと思っている。画像データがIDCフロンティアのデータセンターから配信されているのはいいのだけれども、メインシステムがpixivのオフィス、つまり、データセンター向けでない普通のビルにあるらしい。何かpixivオフィスであれば、サービス停止ということもあり得るし、セキュリティ的にもよろしくない。pixivブログのサービスもそのうち停止してしまうらしいし、需要があるのかわからない「ショーケース機能」（有料で一定タグを宣伝できる）をリリースしたみたい。
これらから、pixivはWebサービス提供者として信用できない企業だと思う。ホスティングサービスとしてのpixivに期待する腐女子もあれだが。しかし、pixivには安定した運営と、利用者の声を反映した運営をお願いしたい。というか、現在のpixiv運営だと、コラージュ騒動のときと同様に、何かあったときにうまく収めることができるのかわからない。
僕はどちらかといえば原発容認の立場なのだが、福島の状況がここまでになってしまうと、
な人たちの意見も多少は尊重しなければいけないかなとも思ってくる。
しかし彼らはネットで喚いたりデモ行進はしても、もっと具体的な行動はなかなか起こしてくれない。
で提案なのだが、そんな原発要らない！なご家庭は今すぐにでも電力会社との契約アンペアを10Aかせいぜい15Aにまで落としてもらえないだろうか。
計画停電や効果の曖昧な節電のお願いなどよりはよっぽど効果的だと思うのだが。原発全てを止められるかも。
加えて、ハゲのくせに「ワシの怒髪天を衝く！」とかトップが喚いてる企業は、早々に本社やデータセンターを住金鹿島のような独自の電力を供給可能な事業者の近くに移転させてそこから電力供給を受けてもらいたい。もちろん全てのアンテナや基地局も太陽電池や小型の風力発電機で必要電力を賄ってもらう。
3/11の東北・関東震災にて 当方の勤めている企業 以前勤めていた企業 また友人の企業などの対応を聞き こうも対応に差が出るもんだなぁと思った
想定外の状態がおきたときに企業とか経営陣とかの本質が顕著にあらわれるんだねぇと感慨深くなりました
保守のひとはシフト勤務だったりして 休みがないので大変なんです
あと災害と停電と津波の影響でデータセンター（サーバがいっぱいあるとこ）やシステム間連携にどんな不具合が出ているのか
早急に判別しなきゃいけなかったり そんな理由で出勤したひとはたくさんいると思います 某銀行とかね
なんつーか企業のありかたがすぐ出るのが 想定外の事象がおきたときだということがよくわかりました
このエントリは実際おきたこととか伝聞とか妄想とかがないまぜになっているから そんなのネーヨと笑い飛ばしてもいいです
社員に「東北・関東震災のときの御社の対応はどのようなものでしたか？」と聞くこと！
その会社がどんなカンジなのかすぐわかるよーな気がするよ
ウェブページを見る程度はするけど、仕組みについては知識ゼロ、という前提で書きます。
ホームページを公開する手段を大雑把に挙げます。下に行くほど簡単かつ自由度が低い。
で、元増田が例に挙げてるページの場合、デザインお仕着せのブログサービスやWikiサービスでは難しくて、ホームページ公開サービスより上の方法で、HTMLやCSSという形式で書いて公開することになります。
HTMLによるホームページの作成方法については、入門書がたくさん出ているので探してみてください。ある程度文法がわかったら、参考にしたいページで右クリック→ソースを表示、とやれば、実際にどう書かれているか見られると思います。
という感じでOK?
「ツイッター信者」にその素晴らしさを熱く語られたときの平和で適当なかわし方｜石原壮一郎「大人のネットマナー教室」
http://diamond.jp/articles/-/7884
-----------------------------------------------------------------------------------------------
クラウドほど、経営層の人と現場の人との温度差が激しいIT用語はないと言えるでしょう。
経営層やCIOの人の中には、「クラウドの素晴らしいビジネスチャンスをもっとうちにも取り入れなければ！」という危機感を抱いて、
ことあるごとに現場の人への啓蒙活動に励もうとする“信者”が少なくありません。
その博愛の気持ちは尊いといえば尊いのですが、現場の人がさほどクラウドによるビジネスにメリットを感じない場合は、
どう対処していいのか困ります。今日も全国各地で、クラウド信者の経営層の熱い講釈を受けて、
尻を叩かれる現場の側が苦笑いを浮かべているという構図が繰り広げられていることでしょう。
自社がクラウド事業に参入することにさほどメリットを感じない側のあなたが、そういう災難にあったときはどう対処すればいいのか。
程度の差こそあれ、クラウドを熱く勧めたがる信者のみなさんは、「クラウドによってもたらされる新たなビジネスチャンス」を信じ、
そんなクラウドの知見を人より早く深めていることに、ちょっぴり優越感を抱いていると言えるでしょう。
どう見ても熱が入りすぎている人の中には、クラウドに過大な望みを託して、
いまいち不本意な会社の現状から自分達を救い出してくれる救世主のように見ているように思えるケースもあります。
いや、あくまで極端な例をあげているだけなので、「俺は違う！」とムキにならないでください。
もちろん、私の周囲のクラウド好きの経営層やCIOや上司に対して、私がそういう目を向けているわけでもありません。
今後の人間関係を考慮した言い訳で話がそれましたが、クラウドを熱く勧めてくる人にとって、
クラウドにはまっていることが誇りであることは確か。何はさておき、そこを見逃さないようにしましょう。
たとえば、最近クラウドにはまっている経営層や上司に、「うちも取組んだほうがいいだろう」と熱心に勧められたとします。
自分の会社がクラウド事業に参入する必要性を説かれても、いまいちピンと来ないからといって、
「うーん、よくわかんないですねえ。コアコンピタンスなシステムをみんなが勝手にリソースを食い合いしている共用環境に置くなんて
なんか気持ち悪い世界のようにも思えるんですが」
「柔軟にリソースを拡充できるっていっても、ハードを跨って分散処理できるシステムならともかく、
結局リソースプ－ルの上限内の話ですよね。なんか嘘っぽいですね」
などと、偉大なる「クラウド様」の仕組みを否定する言い方をしてしまうのは危険すぎます。
ムキになってさらに熱く語ってくるぐらいならまだしも、「ハァ～」と深いため息をつきながら、
救いがたいダメ社員を見るような目を向けてくるかもしれません。
まあ、わかり合えなくてもべつにいいといえばいいんですけど、経営層や上司に悪い感情を抱かれたり、
異動のきっかけになるのは避けたいところです。
向こうだって、今の時期たまたまクラウドにはまっているだけで、けっして悪気があるわけじゃないし、
SOAのことを忘れてしまったわけでも、人間として何かを失ってしまったわけでもありません。
一生懸命にクラウドの魅力を語ってくれたら、たとえピンと来なくても、
「なるほど、そういうふうにインフラ環境を意識せずにインターネットでつながるっていうのも、ユニークな考え方ですね」
と、独自性に衝撃を受けたかのような反応をしておくのが、大人の包容力であり相手をそれなりに満足させるマナーです。
そういうふうに言えば喜ぶのはわかっていても、まるでその相手までホメるみたいで抵抗がある場合は、質問に逃げましょう。
「仮想化によるサーバ統合とか、ホスティングとか、ＷＥＢ２．０とか、データセンターにアウトソーシングするのとはどう違うんですか？」
と、クラウドの旧称を持ち出してきて、クラウドの優位性をさらに語らせるもよし、
「なんか利用分だけ請求する従量制課金にして、結果、利益率の低くなるのをスケールメリットで吸収しないといけないんですよね？」
そんな歪んだ先入観丸出しの誤解（じゃないけどな）をわざとぶつけて、ひとしきり説明させるもよし。
いずれにせよ、無理無理と思っている気持ちを覆い隠したまま、相手にそれなりの満足を覚えてもらうことができます。
まったくクラウドに興味がないわけではなく、ちょっと前に自社製品をＳａａＳやＡＳＰ化してやってみたけど、
全然受注できなくて放置してあるケースも、けっこう多そうです。
そういう状態にあるあなたに、はまっている上司や経営層が例によって熱い口調で、
「まずは、機能限定の無償版をいろんなユーザーに提供してみると、フリーミアムの凄さがわかるよ」
「何でもいいからどんどん無償提供すれば、そのうち有償版にアップグレードする客がでてきて利益がでるよ」
とフリーミアム教、じゃなかった、クラウド教、じゃなかった、クラウド界における定番の説得フレーズを説いてきたとします。
「ほお、そうなんですね。今期の研究課題として取組んでみます」
と適当に納得しておくのはいいとして、つい勢いで、
「しかし、ずっぽりはまってますねー。クラウドの話をするときは生き生きされてますし」
などと冷やかしてしまわないように気をつけましょう。
はまっている上司や経営層は、誇らしさの裏側に、多くは無自覚にですけど、
「自社の戦略に自信がなくてクラウドにすがっているように見えるんじゃないか」
「競争力が欠如した製品をクラウドの冠で紛らわそうとしているように見えるんじゃないか」
といった不安を抱えています。
何気ない冷やかしが引き金になって、心の奥の地雷を踏んでしまいかねません。
そこまでややこしい話じゃなくても、はまりっぷりを感心するセリフの裏側に、
「よっぽどヒマなんだな」
「丸投げばっかりで、手動かしてるの外注ばっかりで、Hello Worldぐらいしかプログラム作れないうちの生産部隊が
どうやってフレームワーク備えたPaaSなんか構築するんだよ」
なんせ今までビジネスセンスではなく社内の空気を読む根回しセンスで出世してきた経営層や上司だけに、
仮にビジネスセンスのないことに対してカケラも自覚がなかったとしても
（カケラも思っていないケースは稀ですがビジネスセンスがないことは稀ではないでしょう）、
相手はそう受け取るでしょう。
はまりっぷりに対しては、ひたすら、
と前向きな返事をすることが無難であり、相手に対する大人のやさしさ。単なるおためごかしではなく、
そのセリフを聞いたときの上司の満足そうな表情を見ることで、社畜としての深い喜びも味わえるでしょう。
仮に、クラウドの話題をきっかけに経営層や上司との距離を縮めたいなら、その場の口先だけではなく、次に顔を合わせたときに、
「あれから、SalesForceとかGoogle AppsとかAzureとかAmazon WSとか、試験導入してPythonやJavaでHello World作ってみましたよ」
と具体的な実績を話せばバッチリです。
熱く勧めてきた上司や経営層が、特に自分の進級昇格を左右する人物だったりした場合は、
とりあえず勧められたとおりにやってみて、クラウドの魔力に魅せられたフリをしましょう。
「やってみると使えますねー。勧めてもらってよかったです」
とまで言っておけば、さらに完璧。
たとえ動機が不純でも、それをきっかけに部内から企画をあげたという実績ができればこっちのものだし、
上司としてはこの上ない喜びを……おっと、結局、経営層へのご機嫌取りという本音が出てしまいました。
曖昧な立場で書いてきましたが、私は何を隠そう、嫌々クラウド事業に取組んでいる社畜のひとりです。
スケールメリットなんか出せねえんだから競争力ある価格設定なんか無理、
無理矢理仮想化しなくても安いサーバで提供すりゃいいんじゃねーの？
そもそも高い人件費のプロパー使ってレンタルサーバ屋と競争してどうすんのよ？
とかいう会社じゃ言えない本音に悶々としながら、仕事中にこっそり書かせていただきました。
そんなことを踏まえつつ、それぞれの立場や環境に応じてお役立ていただければ幸いです。
※
次回も、引き続きクラウドをテーマにしてみたいと思います。（嘘）
今期の事業戦略などで、「クラウド事業への取組み」なんつーキーワードが出始めた場合の対処法や、
自分に企画立案を振られた場合の振る舞い方について考えてみましょう。
■今回のマナー
「クラウド信者」が抱える誇らしさと不安――その両方を見逃すべからず
全然かわせてねー！なんか立案しないとマズい
明日から本気出す
BIG-server.com binboserver.com メンテナンス / 障害報告
03/02 00:03 障害報告：【2010/3/1】ネットワーク障害報告
2010年3月1日11時40分より発生しているネットワーク障害について、
PIEデータセンターよりステートメントを発表いたします。
------------------------
2月28日 米国西海岸時間18時35分ごろより確認しておりますMaido3.com、
そしてPIE.us へのDDos攻撃につきまして報告いたします。
今回の障害は世界各国のボットコンピューターより大量のアクセスが
数万IPアドレスから行われ、ネットワーク機器が過負荷に陥り発生しました。
に登録しておりますが攻撃は継続しております。
また、自動化されたスクリプトの可能性もあり現在米国公的機関に
米国企業に対するサイバーテロとして調査依頼の準備を行っております。
現在弊社帯域はほぼ正常値に戻っており、
緊急体制より準緊急体制へPST 3月1日 午前6:00に引き下げます。
PIE.us
Ryan Iwasaka
おいおいｗ調査依頼の準備されてるよｗ
ログ大量に取ったんだろうな
どうなることやら
このスラングが発祥した当時、日本のSIerの発する広告では、データセンター・ホスティングなどのサーバ運用環境全般を「クラウド」という単語に言い換えることが盛んに行われており、企業内サーバを「プライベートクラウド」と言い換える造語なども登場した。このような商品に新たなイメージを付与するための言い換えやキャッチコピーによって消費を煽ることは、商売上の理由からしばしば行われるものだが、こうしたブログやIT系ニュースによって仕掛けられた言葉に踊らされ、そのような流行を追うことを先進的なものとして享受しているようなSIerたちが、決まって「サーバ」を「クラウド」と言い換えて呼んでいるような現象をギークがからかい、皮肉の意味で「（笑）」をつけて呼んだことが、このスラングの由来であると言われている。
あくまで俗語の類であり厳密な定義はなく、このスラングを用いる者や受け取る者の解釈や文脈、その時の気分によって意味や微妙なニュアンスが異なる場合もあるが、報道媒体などで紹介される場合には、
を意味する単語であり、軽いからかいや冷笑、冷やかし、蔑み、あるいは馬鹿にするような意味を込めたスラングであると解説される。
ネットワーク自体に興味をもたれたら、インターネットを支えるネットワーク技術について、もう少し掘り下げてみるとよい。
例えばグーグルについてだと、http://japan.cnet.com/special/story/0,2000056049,20374847,00.htm や http://www.geekpage.jp/blog/?id=2009/9/1/2 、http://www.geekpage.jp/blog/?id=2009/12/7/1 あたりがある。
なかなか難しい用語が多いが、グーグルってのはすでに単なる検索サービスの会社ではなく、世界屈指のネットワークをもつ会社でもある。
aguse.jpの結果も、aguse自身が接続するぷららからOCN、NTTコミュニケーションズを経て直接グーグルのネットワークに接続し、そこから先はグーグル社内のネットワークとなっている。社内ネットワークの位置情報なんてそんなに公表されるわけでもなく、わかるのは4つのIPアドレス、66.249.89.99 66.249.89.147 66.249.89.104 66.249.89.103 についての情報に過ぎない。そして、同じIPアドレスにアクセスしても、グーグルほどの規模になると誰もが毎回同じサーバに接続しているわけでもない。だから、aguseは単に代表的住所としてIPアドレスの管理担当であるグーグル社の住所を示しているに過ぎないと思う。ちなみに http://geomaplookup.net/?ip=66.249.89.99 によると、アーカンソー州となってる。根拠は知らない。
次に、www.gov.cnを見てみよう。aguseによると 117.18.237.20 だそうだが、うちからだとなぜか 130.223.220.74 となる。後者はスイスのローザンヌ大学の管理である。117.18.237.20 は http://geomaplookup.net/?ip=117.18.237.20 によると一応中国となっている。さて、このアドレスをwhoisして見よう。すると「EdgeCast Networks Asia Pacific Network」の管理と言うことがわかる。EdgeCast Networks とはコンテンツデリバリネットワーク/CDNの大手らしい。CDNといえばアカマイが思い浮かぶがwikipediaによるとEdgeCastは第二位らしい。CDNだからオーストラリアにもあるだろう。ローザンヌ大学のそれもその関係なのかもしれない。いずれにしろCDNを使っているとなればアクセス元によって世界中のサーバから都合の良いサーバに割り振られたにすぎないのだろう。
ちなみにアカマイといえばマイクロソフトアップデートがおもしろい。静的とはいえ、それなりのサイズのファイルが世界中からダウンロードされるマイクロソフトアップデートではアカマイを使用している。その時々によりNTTやKDDIほか様々なネットワークにあることがわかる。
3つ目はwww.cabinet.iqだ。これが一番単純だ。195.217.167.249 を管理してるのは ATA Sodtware Tech. Ltd http://www.atasoft.com/ 見ての通り、アラビア語の翻訳ソフトを開発している会社である。イラク政府から委託されてホスティングしてるのか、管理まで任されているのかはしらない。
さて、ここでわれらがはてなを見てみる。http://www.aguse.jp/?m=w&url=www.hatena.ne.jp NTTから東京とされるさくらインターネットの59.106.82.204を経由し、なぜか大阪となる。はてなのサーバはさくさインターネットの東京のデータセンターにあったと思うが、なんにせよ、さくらインターネット社内の話なので実際はわからない。
つまりaguse（に限らずだが）の位置情報など、そんなものだ。
総務省が掲げる霞が関・自治体クラウドの計画が本格的に動き始めた。同省は2009年8月10日、「政府情報システムの整備の在り方に関する研究会」の中間取りまとめを公表した（資料はこちら）。これは、2015年の本格稼働をターゲットとして、府省の情報システムの将来像を描いたものだ。これによると、現在は府省ごとでバラバラに構築・運用している情報システムのうち、共用可能なものを霞が関WAN内のデータセンターに集約する。その際に、基盤となる「政府共通プラットフォーム」を開発。この上でアプリケーションをSaaS（ソフトウエア・アズ・ア・サービス）形式で利用する。政府共通プラットフォームには、府省間で共通利用するデータを連携する機能も含まれる（図1）。この政府版プライベート・クラウドが、霞が関クラウドの実態である。
府省横断の業務改革が不可欠に
この取り組みで重要なのは、どれだけアプリケーションを共用化できるかという点だろう。府省ごとに利用しているアプリケーションをそのままSaaS化するだけでは、単にWebアプリケーションのホスティングにすぎない。システムだけの統合・集約に終わらずに、業務プロセスの統合・集約、すなわちシェアード・サービス化にまでつながらなくては、大きなメリットを得ることはできない。
そのためには、府省を横断した業務の標準化が不可欠となる。中間取りまとめでも、業務の見直し（BPR）を課題として掲げている。しかし、その道筋は見えてこない。中間取りまとめの資料には、2009年度から2015年度までのスケジュール（予定）が掲載されているが、業務の見直しに関連するような工程は2010年度中の「要件定義」と「最適化計画策定」の2つだけだ。府省横断で業務を改革した上でシステム要件を定義するまでを、1年足らずの期間で完了できるのだろうか。
短期間での業務改革を実現するためには、強力なリーダーシップが必要だ。府省を横断して大なたを振るえるとしたら首相しか考えられないが、総選挙を間近に控えた今、実働部隊となるプロジェクトメンバーを選ぶことさえもままならないのではなかろうか。
一方の自治体クラウドも実現へ向けて大きく動き始めている。総務省は2009年7月17日、「自治体クラウドに係る開発実証団体」の募集を開始。実証実験に参加する都道府県を募り始めた（資料はこちら）。都道府県CIOフォーラム（詳しくはこちら）の事務局を務めている日経BP ガバメントテクノロジーでは、8月のフォーラム開催に向けて事前アンケートを実施しているが、実際にいくつかの都道府県が実証実験に参加する予定だと回答している。
自治体クラウドは、自治体専用のWANである総合行政ネットワーク（LGWAN）内にあるデータセンター（3カ所の予定）に市町村のシステムを統合・集約する取り組みである。市町村レベルでのシェアード・サービス化ととらえることできる。市町村の場合は、それぞれが同じような住民サービスを提供しているため、シェアード・サービスに向いているといえる。
理想論でいえば、全国の自治体が利用するシステムを統一すれば、コスト面で大きなメリットを得られるし、ガバナンスを効かせやすいというメリットも生まれる。しかし、アプリケーション（あるいはSaaS事業者）の品質を維持できるのかが見えない、地域特性による個別のサービスが提供しにくい、あるいは地場のITベンダーが育成できないなどデメリットも少なくない。実際、総務省の実証実験では、ASPやSaaSは自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位のシェアード・サービス化ということになりそうだ。
ただし、都道府県単位でバラバラの仕様のシステムを作るわけではない。自治体クラウドの要件の中には、「自治体クラウド連携インターフェイス」というものがある。これは、アプリケーション間でデータを連携するためのインタフェースで、将来的には都道府県間の連携も見据えたものになっている。
とはいえ、都道府県を横断したアプリケーションの共用化は容易ではないだろう。都道府県をまたいで業務を標準化しなければならないからだ。自治体クラウドと霞が関クラウドの両方に共通することであるが、IT面での研究や実証・分析に偏らずに、業務の標準化にも力を入れていかなければ成功はおぼつかないだろう。というよりも、IT面の実装よりも、業務の改革・標準化のほうがハードルが高いのではないだろうか。
（吉川 和宏＝日経BP ガバメントテクノロジー） [2009/08/21]
http://itpro.nikkeibp.co.jp/article/Watcher/20090818/335667/
韓国のソフトを輸入してきてローカライズする会社で鯖管やらインフラ周りをやっていたことがあるのだが、この韓国独特のネットワーク環境のせいで色々と苦労をさせられた。
P2Pを利用したコネクションを張るソフトがあるんだが、韓国はブロードバンドルータを使わない≒大概皆さん1台のPCにグローバルIPが張り付いている≒NATの必要性が存在しない。そんな「NAT越えって何スかそれ」みたいな状況でP2Pをやっているので、ルータがデフォの日本環境にもってくるとまともに動かないという。
あとブロードバンドルータがない≒ファイアウォールなしでサーバがネットワークに接続されている状況も割りとザラ。
さらにまったく関係ないがデータセンターがただのサーバ置き場。「今係員がいないので携帯電話で呼び出しています」というせりふは日本のIDCに慣れているとなかなか聞けない一言。
