  |
はてなキーワード: ベンダとは
http://anond.hatelabo.jp/20110508220817
http://anond.hatelabo.jp/20110508211402
http://anond.hatelabo.jp/20110508211038
あと、情報-SE系なら、東証での誤発注事故の責任は東証？証券会社？ベンダ？議論なんかも。)
・所有者・使用者側の問題なのか、
・製造者・設計者側の問題なのか、
によって、追求する矛先や程度は変わってくると思います。
その辺がクリアにならないまま東電だけが徹底的に叩かれてることに疑問を感じつつ、いつ自分の会社がそうなるかに恐々としています。
逆に聞くが、『今住んでいる家が狭くてかなわん。広くしてくれ。』って言われたらどうするよ？
土地も増やさず引越しもせず増築もせず、リフォームだけで広くしろって言っても無理があるだろうに。
素直に増築すりゃあいいんだよそんなもんはよ。
別の言い方をすると、「他社にない独自の要素を盛り込むことで、機能追加時や保守時にベンダを簡単に替えられないリスクを伴う」ってことも分かって欲しい。
そんな開発先と一蓮托生になるようなシステム、俺は作ってもらいたくはないね。
※酔っぱらった勢いでてきとーに書く
俺の人生またオワタな予感！
わーわー、このまま行くと彼女と近いうち別れるんじゃね？
けど会えね。
彼女には「シューカツしてるから！もう27だし今年いっぱいシューカツ頑張ってみたいから！」って言って数ヶ月あってない。
けど、あえない理由はびみょーに違う。
いや就活してるのは事実なんだけど、俺の意志で彼女と会うのを断ってるのではなくて、
ぶっちゃげ俺の親の意志ｗｗｗｗｗ
まぁあんまりにもフリーターのままいすぎた＆これまでシューカツ頑張ってなかったから親にｺﾞﾙｧされて
「デートする暇あるなら就活死にものぐるいでやれやゴルァ！」って言われたわけｗ
で、彼女には会ってないけどシューカツもノンベンダラリの亀亀モードでやってるわけｗｗｗｗｗｗ
当然彼女には親のことは言わずに単純に「俺ｗｗｗ就活してｗｗｗ職が見つかったらｗｗｗ彼女と会うんだｗｗｗ（死亡フラグ）」とだけ言ってるんだｗｗｗｗ
そして亀で見つかるわけも無く、あえないまま今に至るとｗｗｗｗ
あははー、どこかの鳩ぽっぽを見てるとこう思うよｗｗｗ
「あｗｗｗなんか俺っぽいのがいるｗｗｗｗ」
頑張る→頑張りません→いろんな人に色々言われる→やっぱり頑張る→頑張りません→オワタ
うわぁ俺のドッペルゲンガーが総理になってるｗｗｗ日本凄いｗｗｗｗ
てかこのまま降られるねｗｗｗ
はー、きっと俺は自分の趣味だの楽しみだのにしか頑張れないダメ人間なんだよｗｗｗ
勉強だの就活だのは恐怖で動作が硬直したり、楽しい方に動いちゃったりで何も出来ないｗｗｗ
そのくせ世渡りは下手っぴｗｗｗ
何もできねぇしｗｗｗ親の意志がでかすぎてアウトローにもなれないしｗｗｗ
自殺？ｗｗｗ無理だろｗｗｗ出来るならもうここにいないしｗｗｗｗ
きっといろんな物を呪いながら生き続けてゴミ屋敷を作って奇声ををあげてまき散らす老後か、
痛い痛いと良いながらのたうち回って死ぬこともフツーに生きることもできないまま底辺（わら）であり続けるんだ
毎日時間構わずネットをねっとりブラウジングして時間つぶして穀潰し。
パチ狂いと似たよーなもん。成長も生産も何もない。衰退と消費のエヴリデー★
豆腐を食べたいなぁ。
最近マークアップエンジニア志望の若者と話す機会が多いのだけれど、そこで気づかされるのは、彼らの中に過去のHTML（特に90年代以前の仕様）を読んだことのあるという人が、驚くほど少ないことだ。
例えば「マーク・アンドリーセンをどう思う？」と聞くと、「アンドリーセンって誰ですか？」という答えが返ってくる。「ヨスケの独自要素で何が一番好き？」と聞くと、「見たことがありません」と言われてしまう。「ではきみは、昔のHTMLを見たことがあるの？」と聞くと、たいていが「とほほでやっていたものくらいなら……」という答えしか返ってこない。
今の若い人の間では、HTMLを体系的にとらえようという人は少ないようだ。見るのは専ら近年の話題仕様ばかりで、歴史を辿ってみたり、系譜をひもといて標準化団体ごと理解しようとする人はほとんどいない。
これは、ちょっと由々しき問題だと思わされた。HTMLは、もう長いこと（90年代の早い時期から）インターネットの王者としてあらゆるWeb関連技術の上に君臨してきた。だから、Webを作ることを仕事にしたいなら、何をするにせよ避けて通ることはできない。
HTMLは、表・画像・フォーム・音楽・デザイン・フレーム・動画など、さまざまな分野においてその時代々々に達成された最新の成果を持ち寄るようにして作られてきたところがある。だから、HTMLを読まずして現代のインターネットは語れないと言ってもいいくらいだ。
もし何かクリエイティブなことをしたいのなら、HTMLを読むことは欠かせない。また、単に読むだけではなく、それを包括的・体系的にとらえることも必要だ。なぜなら、HTMLを包括的・体系的にとらえることによって、現代のインターネットそのものを、包括的・体系的にとらえられるようになるからだ。そしてそうなれば、Webを作ることの道理や筋道が理解でき、何かクリエイティブなことをする上で、大きな助けとなるからである。
そこでここでは、昔のHTMLをほとんど見たことがないという人や、あるいはHTMLそのものもあまり見ないという人のために、これを見ればHTMLを体系的に理解でき、現代インターネットの成り立ちや実相までをも包括的にとらえることができるようになる、7本の仕様を紹介する。
ここで紹介するHTMLは、いずれも後のWeb業界に決定的な影響を与えたものばかりだ。これらが、HTMLという標準のありようや方向性を決定づけた。この7本を見れば、HTMLというのはどのようなきっかけで生まれ、どのような変遷を辿って、どのような足跡を残してきたかというのが、体系的に理解できるようになる。そしてそれが、世界のインターネット利用シーンにどのような影響を及ぼしてきたかということも、知ることができるようになるのだ。
まず最初は、ちょっと強引かも知れないけれど、第一次ブラウザ戦争前のHTMLをひとまとめにするところから始める。
80年代末にティム・バナーズ＝リーの発明したHTMLというメディアは、その後『HTML 1.0』（1993年）『HTML+』（1994年）『HTML 2.0』（1995年）などの仕様で次第にそのスタイルを確立していき、マーク・アンドリーセンが一大産業として発展させた後、『HTML 3.0』に行き着く。そして幸運なことに、ここに集大成されるのだ。
ブラウザ戦争前のHTMLは、これ1本だけ読めば良い。このHTMLに、戦前のHTMLの全ての要素（属性）が詰まっている。このHTMLを見れば、HTMLのインターネットの王者としての風格、スターという存在の大きさ、作者以上にブラウザが重視される「産業」としての側面、お尻Pから終了タグ省略可へ・文字情報から画像付きへと移り変わった技術革新の変遷など、戦前のHTML史やWeb業界のありようが全て分かるのだ。
このHTMLの魅力は、説明し始めるといくら紙幅があっても足りないので、ここではその一端を紹介するにとどめておく……といっても、気の利いたことを言えるわけではない。『HTML 3.0』の魅力を知るには、まずは読んでもらうこと――これに尽きるからだ。そして、もし一度でも読めば、その魅力はたちどころに理解できるだろう。
『HTML 3.0』を見て驚かされるのは、現在のHTMLと比べても全く遜色ないところである。破棄されてから14年の時が経過しているが、現代人の読解にも当たり前のように堪えうるのだ。それは、逆にいえばHTMLというものは、今から14年前、つまりこの『HTML 3.0』が作られた時点で、様式として一つの完成を見たということでもある。
『HTML 3.0』は、HTMLという標準が到達しようとした一つの極みである。それゆえ、HTML史というものは、『HTML 3.0』以前と以降とで分けられるようになった。これ以降に作られたHTMLで、『HTML 3.0』の影響を免れたものはないからである。
iモードが世界のHTML史に与えた影響というのは、一般に理解されているよりもはるかに小さなものである。日本人というのは、「日本の技術が世界に影響を与えた」というと、なぜか鼻高々と聞いてしまうところがある。「日本はガラパゴス」という言葉は聞いたことがあっても、「それって日本人が過小評価しているだけじゃないの？」と、眉に唾をしてとらえるところがある。
しかしiモードは、真に日本のHTML史を塗り替えたサービスの一つである。特に、このサービスの後世に与えた影響には、本当に計り知れない大きさがある。
iモードは、ドコモのメインストリームだったポケットベルが、それまでの栄華の反動で深刻な低迷期に陥っていたPHS流行後すぐの時期、そんなポケットベルに取って代わって、日本で最も輝いていた携帯サービスであった。それゆえ、広末に見蕩れた世界のHTMLファンたちは、iモードのWebサイトを見ることによって、失われかけていたWeb制作の魅力を再発見することにもなったのである。
iモードは、没落したHDMLに変わってモバイルWebの命脈をつなぎ止めた、言うならば救世主のような存在であった。海外のモバイル陣営が営々と築きあげてきたそれまでの栄光を切り捨て、日本の後代へと引き継いだ重要なリレー第一走者としての役割を、HTML史において担ったのである。
そして、そのバトンを受け取った日本の若きWebデザイナーたちが、2000年代に入って雨後の竹の子のように現れたことで、モバイルWebは鮮やかな発展を遂げる。だから、もしiモードが存在しなければ、HTMLの様相は今とは違ったものになっていたかもしれないのだ。
そんなiモードHTMLのバージョンはいくつもあるのだが、中でも特に多くのHTMLファンを――取り分け日本の若きWebデザイナーたちを魅了したのが、この『Compact HTML』である。この仕様の一番の魅力は、なんといってもその大胆に構築されたW3C Noteであろう。HTML史において、これほど拡張多く適当なディテールで構成されたNoteは他にない。そのためこのNoteは、これ以降無数に手本とされ、真似され、拡張されることとなるのである。
正字正仮名の影響を受けた日本の若き日記書きたち――言うなれば「CSSコミュニティ」――が頭角を現す直前のW3Cで、HTML史に乾坤一擲の巨大な爪痕を残した1本の仕様が誕生する。
この時期、情報技術の進歩によって、HTMLにもさまざまな新しいテクノロジーがもらたされていたのだが、それらを十全に取り入れたばかりではなく、縦横に駆使することによって、これまでとは全く違った国際化、全く違ったアクセシビリティ体験を生み出すことに成功したのが、この仕様『HTML 4.0』を勧告したWorld Wide Web Consortiumである。
『HTML 4.0』は、HTML史において最も革新的な仕様の一つとなった。この仕様に初めて触れた当時のWebデザイナーたちは、そのあまりの目新しさに度肝を抜かれた。そこでは、これまで全く見たことのないマークアップがくり広げられていた。そのため、これまで想像さえしたことのなかった全く新しいHTML体験を、そこで味わうことになったからである。
W3Cの果たした一番の功績は、テクノロジーとHTMLを見事な調和をもって融合させたことだろう。例えばそこでは、「スタイルシート」という新しい技術のデザインと、それでレイアウトされたページが閲覧者に与える独特の感覚というものを、双方ともに熟知していた。だから、それらを効果的に融合させることによって、全く新しいHTML体験を生み出すことができたのである。
この仕様『HTML 4.0』には、そうしたテクノロジーとHTMLとの融合が、至るところに散見できる。その数の多さとクオリティの高さによって、HTMLはここに、新しい時代の幕開けを迎えるに至ったのである。
先に述べた「CSSコミュニティ」がWeb日記業界に論争をもたらすのは、2000年代に入ってからのことである。そして、そのきっかけとなったできごとの一つが、1947年生まれの非政府組織で、IECとも協力した生粋の工業標準化団体であった国際標準化機構が、この仕様『ISO/IEC 15445:2000 (ISO-HTML)』によって成功を収めたことである。
このHTMLは、単にJIS的に標準化しただけではなく、文化的な意味においても、フラットでリニアな構造の力を広く世界に知らしめることとなった。この仕様の成功によって、世界の人々は、レベル付けされた見出しの魅力の大きさを知る。そしてそれが、やがて見出しのレベル分けが世界のスタンダードとなり、誰もが当たり前のように使う状況を育んでいくのである。
またこの仕様は、CSSコミュニティそのものにも大きな影響を与えた。この仕様の成功に刺激を受けた才能ある若きコミュニティ住人たちが、その後立て続けに台頭し、いくつもの名サイトを生み出していくからである。
それらが相まって、やがてCSSコミュニティは空前の黄金時代を迎えることになる。その端緒となり、道筋を切り開いたのが、他ならぬこの『ISO-HTML』なのだ。
『HTML 4.0』で繁栄の足がかりを築いたW3Cは、この仕様『XHTML 1.0』によって、ついにその栄華の頂点に達する。そして、それを成し遂げたメタ言語も、W3C勧告のの一つであり、また『HTML 4.0』を作ったSGMLの改良でもあった、Extensible Markup Languageであった。
この勧告は、史上最も商業的に成功した仕様となる。そのためこれ以降、この勧告にならって商業的バズワードを盛り込んだ仕様が数多く作られるようになり、しかもそれらが、実際に大きな商業的話題を集めていくのだ。すると、そこで生み出された多くの意見は、やがて再びW3Cに還元され、さらなる発展をもたらすことにもつながった。
そんなふうに、この仕様がきっかけとなってW3Cにもたらされた意見は、HTMLという言語を変革させていくことになるのだが、それに伴って、HTMLそのものにも大きな革新をもたらすことになる。
その変革も、他ならぬW3Cの手によってなされた。ここで『XHTML 1.0』の成功によって手にしたメンバーをもとに創設した文書マークアップの開発集団「HTML Working Group」が、より魅力的な拡張性を追求していく中で、やがてM12n（モジュール化）という技術の開発に至るのである。するとそれが、これまでのHTMLを一変させたのだ。
M12nは、HTMLに魅力的かつ効果的な特殊語彙を、DTDでしかも複雑怪奇にもたらすことに成功した。おかげでそれは、あっという間に世界から見捨てられていった。そのため今では、M12nの使われているHTMLを探す方が難しくなったくらいだ。それくらい、この『XHTML 1.0』がWeb業界にもたらした変革には、大きなものがあったのである。
2000年代以降、繁栄を謳歌したW3Cは、しかしその栄華の大きさゆえ、00年代中盤に入るとそれを存続させることに力をそがれてしまい、革新的な仕様はなかなか生まれてこなくなった。
しかし、そんな時代が5年は続いた00年代の後半になって、今度はその栄華のただ中で育った新しい世代のHTML WGメンバーたちが台頭してくることにより、再び変革の時を迎えることとなる。
その新しい世代のHTML WGメンバーとは、マイクロソフトやモジラ・ファンデーション、オペラらに代表される「ブラウザベンダ」と、無関係な編集者たちであった。
彼らに共通するのは、文書構造に不必要なものなら全て――とるに足らないガジェット的なものまで含めて――残らず切り離そうとする「オタク的な性質」を持っていたことだ。
彼らは、それまで見過ごされがちだったHTMLの些末な要素にスポットを当て、それを別仕様に押し出すことで、従前とは一風変わった、新たな魅力を持った草案を生み出していった。そして、その真打ち的な存在として00年代の後半に登場したのが、XHTML2 Working Groupだ。
XHTML2 WGは、特に99年に最後の草案が作られたこの仕様『XHTML 2.0』によって、オタク的なHTMLの楽しみ方が、一部のマニアだけにとどまり、それ以外の多くの人たちには受け入れられないことを証明してみせた。この失敗が、デ・ファクト的な新生HTML WGにさらなる脚光を浴びせることになったのはもちろん、それに影響を受けたWeb WorkersやDOM Level 3 Eventsといった、次世代のWeb標準たちの誕生にもつながっていったのである。
最後は、第二次ブラウザ戦争の集大成ともいえるこの仕様である。
『HTML5』は、HTML史においては『HTML 3.0』と同じような意味を持つ。つまり、それまでのHTMLの要素が全て詰まっているのだ。この仕様を見れば、それ以前のHTMLの歴史というものが全部分かる。
『HTML5』には、HTMLのあらゆる要素が詰まっている。ここには、『HTML 3.0』のような歴史的な仕様としての「総合性」があり、『Compact HTML』のような「実装の実在さ」がある。『HTML 4.0』のような「マルチメディアとアクセシビリティの融合」があり、『ISO-HTML』のように「セクション構造の魅力を全世界に知らしめ」た。また、『XHTML 1.0』のように「バズワード的に成功」したのはもちろん、『XHTML 2.0』が別仕様に押し出した「オタク的ガジェット」にも満ちている。
全て詰まっているのだ。なんでもあるのである。つまりこのHTMLは、『HTML 3.0』と全く同じ意味合いを持っているのだ。HTML史というものは、『HTML5』以前と以降とで分けられる。これ以降に作られるHTMLで、『HTML5』の影響を免れるものはないであろうからである。
以上、これさえ読めばHTMLを包括的・体系的にとらえることができる7本の仕様を、制作された年代順に紹介した。
こうして見ると面白いのは、歴史的に重要な仕様は、必ずしも定期的に現れるのではなく、あるところでは連続しているし、あるところでは長らくなかったりすることだ。それはまるで「素数の分布」のようだ。一見規則性はないように見えるものの、何かしらの法則が隠されているようでもあり、興味深い。
それから、ここに挙げた仕様は、いずれも「読むことによって他の仕様にも興味が移行する」ということを念頭に選んだ。
例えば、『HTML 3.0』を読んだならば、ブラウザ戦争前夜の独自HTML拡張に自然と興味がいくだろうし、『Compact HTML』を読んだなら、iモードのそれ以外のバージョンのHTMLも見たくなるだろう。CSSコミュニティについてもそれは言えるし、『ISO-HTML』を読んだなら、このHTMLを流行らす土壌ともなった「フラットでリニアな構造」というムーブメントにも自然と興味がわくはずだ。さらには、『XHTML 1.0』はXMLオタクになるきっかけになるだろうし、『XHTML 2.0』はその他の「オタク的なXML EventsやXForms」の仕様も見たくなるという効果を持っている。
ただし、最後に選んだ『HTML5』だけは、こうした例とは別に考えなければならないかも知れない。なぜならこのHTMLは、完成度があまりにも高いために、これを見た後に他のHTMLを読むと、どうしても物足りなく感じてしまうからだ。
しかしいずれにしろ、これらの仕様を読むことによって、HTMLをさらに愛さずにいられなくなるのは疑いない。そしてまた、これらの仕様を読むことによって、HTMLを包括的・体系的に見る目を養ってもらえれば、その後のクリエィティブな活動にも、大きな助けとなるはずだ。
上に挙げた仕様への理解は、以下に紹介する著作を読むことによって、さらに深まる。これらを読むことによって、ぼくは「HTMLを体系的に見るとはどういうことか」を学んできた。
高校時代に読んだこのサイトによって、「リソースとは何か」ということを、ぼくはを知った。
「HTMLはSGMLの応用だ」ということが、このサイトを読むことでよく分かる。何気なく見ていた省略記法でも、その裏には、実にさまざまな技術や、それを開発してきた歴史というものが隠されていた。
世界がCSSコミュニティの何に驚かされたかといえば、それはやっぱり精緻に書き込まれた正字正仮名にだ。ノジタンの日記には、HTMLの本質が詰まっている。だからこそ、あれだけ多くの日記で多くのコミュニティ住人に、言及されたり模倣されたりしたのだ。
ここでは取りあげられなかったのだが、とほほ氏がHTMLというジャンルに及ぼした影響にも、本当に大きなものがある。そして、ぼくが上に挙げた感想のいくつかは、このサイトに書かれていたばけらさんとの「スタイルシート論争」を参考にしたものなのだ。
これらのサイトを読めば、どんなHTMLが素晴らしく、どんなHTMLがそうではないというのが、よく分かる。その判定基準を知ることができ、審美眼を養うことができるのだ。なにしろ、あのCSSコミュニティ住人の言うことなのだ。これにまさる教科書は、他にはない。
【元ネタ】
クラウドコンピューティングがいかに素晴らしいか、的な話を各所で見かけるけど、騒ぐほど凄いことなのかと疑問が。
末端の一エンジニアとしては、技術的にそんな凄いことないんじゃね？程度にしか思えないのです。
導入企業にとってはシステム導入に伴う費用の会計上のメリットがあることは認識してますが。
で、タイトルのとおり、クラウド産業と不動産業って実は似てるんじゃないかと。
自前でサーバ持つか持たないか、それって持ち家か賃貸かってことと同じなんじゃないの？
カスタムでアプリ作るか、パッケージで済ますかも、注文住宅なのか分譲住宅なのかと同様に。
等等。
結局、どちらもメリットデメリットがあるんだから、何でもかんでもクラウドクラウド言うの辞めればいいのに。
で、この視点に立つと不動産業の場合、家主や建築業者や内装業者より仲介業者が一番おいしいと思ってます。
（不動産業の実態は知らないのであくまでも個人的な想像ですが。）
ということは、データセンタ、ハードウェアベンダ、ソフトウェアベンダなど広義のSIerよりも、仲介業者的コンサルが一番おいしいのだろうなと。
うん、そこんとこはいいと思うよ。
プロテクト破りのない(法令の範囲内の)自作 or 3rd-partyのハード・ソフトは
認められてしかるべきだと思うよ。
・・・って、追記で訂正！
ここってどうなん！？そりゃイカンでしょ。。。
さっきの車の件の増田ですが、言いたかったのはそこんところ。
「『アマチュアで遊ぶ』という主張なら、法令の範囲内で遊べばいいじゃない。」
法令を逸脱している部分(不正競争防止法)と、法令的にグレー～シロの部分(自作ソフトと著作権)を
ごっちゃにしてゴネてる気がしたから書いてみた。
車だって、法令による車検制度・安全基準はあるけれど、その範囲内であれば改造・自主制作パーツも許されている。
マジコンだって、法令で許されている範囲内で制作するならば、マジコンベンダもマジコン利用者も許されていいと思うのだが。
どうしたんかいな、とネットワークトレースをとってみた。そしたら、トップ画面の要求に対してこんな応答が返っていた。
GET / HTTP/1.1 Host: www.yodobashi.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 02:02:31 GMT Server: Apache Pragma: no-cache Cache-Control: private Expires: -1 Set-Cookie: JSESSIONID=FAE13F42154EB566479E047B57CBF2EA; Path=/cs Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: BIGipServerPool_www_yodobashi_com_cms=1258399936.20480.0000; path=/ Content-Length: 83878 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Windows-31J
えーと。どこから突っ込んでいいのやら。
大都会のシステム開発に、ぽっかりと大きな穴が開いているようだ。
東京都内で、バグの多すぎる納期間近の３６０人月のプロジェクトが七つの外注候補に緊急要請を断られた。約１時間１５分後に官公庁に運ばれてサービスインしたものの、３日後にデータベースまわりのバグで動作停止となった。
同じようなことが一昨年、奈良県でもあった。バージョンアップ中のバックエンドシステムが動作不良になり、デバッグが必要になったが、隣の大阪府も含めて１９の外注に受け入れを断られ、やはりDBのバグで動作停止なった。
背景には、全国的なプログラマ不足がある。急な開発を受け入れる余力が、ITベンダに乏しくなっているのだ。
それにしても、ITベンダがたくさんあるはずの東京で、と驚いた人も多かったのではないか。厳しい条件の中でも、なんとか開発をやり遂げる態勢をつくるにはどうすればいいのか。今回起きたことを点検し、今後のために生かさなければならない。
動作停止したプロジェクトは仕様上の曖昧な部分や契約面での不透明な箇所があった。元請けベンダの手に負えないことから、下流工程での受け入れ先を探した。
最初に連絡したのは、危険の大きい開発案件に２４時間対応するために都内に９カ所あると言われているベンチャー系開発企業の一つ、○○だ。
ところが、○○では中堅社員の過労による退職のため、７月からは週末や休日の開発要員は１人になり、急な開発の受け入れが原則としてできなくなっていた。
この日は土曜日だった。１人だけのプログラマは受け入れを断り、他の開発企業を紹介したという。紹介した企業にも「COBOLを書ける人間がいない」などの理由で次々に断られ、○○は２度目の依頼で退職者を呼び出して対応した。
ベンチャー系開発企業は最後のとりでだ。そこが役割を果たせないようでは心もとない。プログラマ不足という事情があるにしても、東京都には急な仕様変更に備える態勢づくりにさらに努力してもらいたい。
いくつもの企業で受け入れを断られた背景には、都市圏ならではの要因もある。地方と違って開発企業が多いため、ほかで受け入れてくれると考えがちなのだ。
そうした考えが、危険なプロジェクトに備えるSI業界のネットワークが必ずしも十分には機能しないことにつながる。マネージャ同士でもっと緊密に連絡を取り合うことに加え、ネットワークの中で使い勝手の良い外注先を探す司令塔のような存在をつくることも考えたい。
もう一つ大切なことは、全く別々に運用されている元請けと下請けの連携を強めることだ。元請けで開発が進まないときは、とりあえず下請けを投入する。そうした柔軟な発想が必要だ。
プログラマ不足を解消する努力はむろん大切だが、SI業界やマネージャの間で連携に知恵を絞ることはすぐにでもできる。
http://www.asahi.com/paper/editorial20081023.html#Edit1
ほとんど開発系ばかりだよね
あまり私のようなインフラ系の人の話は見かけない気がするが単に比べ物にならないくらい少数ってだけだろうか。
確かに開発系のように新しい言語だ技術だなんだってのが頻繁に飛び交うような世界じゃないし、激務薄給が多数を占める業界じゃないからなのかな。
インフラ系は各ベンダのプロダクトにべったり紐づくものばかりだから表に出しにくいってのもあるかとは思うけど…
1:コンサルタント
3:インフラ構築(サーバ、ストレージ、ネットワーク、ミドルウェアの一部)
4:アプリケーション設計
5:アプリケーション開発
6:運用
7:保守
1はほぼ独立、2と3は兼ねている場合有り、3と4は兼ねている場合あり、4と5は兼ねている場合あり、て感じかな。
当然2と4でも繋がってたりするわけだけど。
ネット上での話題はほぼ4と5なので少し寂しいと感じたり感じなかったり。一緒にワイワイ盛り上がりたいよ(笑)
日立コンサルティングという会社がある。日立製作所100%出資の戦略子会社という位置づけだ。戦略子会社の定義は、しかしながら、おそらく一般化できる類のものではないと思う。日立コンサルティングのそれは、投資案件も積極的にこなすという意味である。投資案件なので、今後の継続案件獲得を目指した赤字受注もいとわない、と言えばわかりやすいだろうか。
かつて、IT系公共事業の「１円入札」が問題になった。日立製作所も、他ならぬそのプレイヤーの重要な一角を占めていた。１円入札とは、言うまでもなく、今後の継続取引を確保するための戦略だ。いったんシステムを構築した上で自社仕様に「ロックイン」してしまえば、あとは保守運用などの要件を別口で、かつ随意契約で獲得し続けることができるという、ベンダにとっては実にありがたいエコシステムがあった。
そうした投資案件は、日立製作所をはじめとする巨大コングロマリットにとってはまさに「お家芸」であった。そのお家芸の矢面にいきなり立たされることになったのが日立コンサルティングである。
日立コンサルティングの設立にあたっては、現・製作所社長の古川氏が直々に音頭を取ったことがよく知られている。元ベリングポイント会長のポール与那嶺氏を招聘、トップに据えた。この時点で、日立製作所とベリングポイントの間に過去どういうビジネス関係があったかを推し量ることは可能かもしれない。とはいえ、それは皆さんにお任せする。
日立コンサルティングは、国内に拠点を置く数々のファームから熟練コンサルタントを呼び集め、人員規模的には順調な成長を見せた。しかしながら、与那嶺氏が籍を置いていたベリングポイントのような、熾烈な市場競争をくぐり抜いてきたプロフェッショナル・ファームの文化と、日立製作所のロックイン式お家芸のそれとは、そもそも相容れるものではなかった。
そんなとき、日立コンサルティングという組織の中でどういう化学反応が起きたか。それはいわば「易きに流れる」というものであった。元エントリに触れられているように、本来顧客に対する十分な説明（情報開示）を、しっかりとしたドキュメントとプレゼンテーションをもち行うというコンサルタントの強みは損なわれ、日立製作所式の高コスト・ソリューションの提案作業に明け暮れる日々が続くこととなった。
コンサルタントの中には、そうした流れに異を唱える者ももちろんいた。自分は日立グループの豊富なリソースを自在に組み合わせた業界最強のソリューションを提供できるという期待を持ちここに入ってきたのに、ソリューションやコンサルティング部隊をそれぞれ抱える日立製作所をはじめとするグループ企業各社との調整に常に腐心せねばならない不経済はどうにかならないものかと疑問を持つ者もいた。
しかしながら、日立ブランドという、日本有数のコングロマリットの代弁者へと既に身をやつしていた上級コンサルタントは、もはやグループの、あるいは自己の地位を守るための理想をぶつ存在でしかなかった。
こうして日立コンサルティングという会社は、良くも悪くも、日立というブランドを背負う御用聞き役を担い、そしてその役割に失望したコンサルタントたちは、続々とそこを離れることとなった。
えっと、これ、ネタですか？
SLAは文字の通りAgreementなんで、契約ですよ？非常に高い？それは具体的に何ですか？
内容の無い契約なんか出来るわけ無いじゃないですか、Availabilityがですか？年間何分のダウンまで許容できますか？
そこら辺をきちっと説明してもらわないと見積もりなんてやりようありません
機械は壊れるものですし、プログラムはバグがあるものです、もちろん、そういうのが全く許容できない用途だって言うのなら
そう言ってくれれば済む話ですし、そういう場合は、一年分程度の全入力を機器に流してみたりもします
具体的に、このシステムの停止時間で許容できるのは年間何分の停止である、ついては見積もりだしなさいと言えば済む話でして
それはやりたくない、という話なら、今のままの契約と機器しか無いと思います
しかし、それって言ってしまえば、ダウンは全く許容できない、遅延も許容できない、って言ってるのと同じ事で
ベンダに対してそれを言うと
例えば、壊れない車をよこせって言ってるのと同じ事で、そう言われてしまうと、専門のエンジニアを常時待機させた上で
代替車を全国に10台常に確保し、ヘリで故障地点まで運ぶ体制を作りますみたいな案が出てきて当然なんです
もちろんそういう用途はありますし、そういう体制が必要かどうかはユーザーが判断することです
こっちは、言ってしまえば、地震がおきても通話に制限が無い携帯電話網を作れと言ってるようなもんで
どの程度の負荷を想定して、想定した負荷の場合の応答時間は何秒だ、それを守れって言われないと
際限なく金をかける結果になります
まぁ、言っちゃえば、世界のどこで何があるか分からないから
日本人の脱出用の航空機を世界の全空港に手配する必要があると思います？
そんな話なんですよ
SWとHWを一元的に見られるメーカ／サービスプロバイダって、少ないからねー。
サードベンダに任せれば、上ものは安くできるかもしれないけど、その下のOSとハードウェアは、BIOSとかマイクロとかいって、メーカじゃないと責任持てなくて、ミッションクリティカルなシステムの場合は、HA機能のソフトウェアが、下層のOSとサーバに密結合してるから、手が出せない。
ちなみに、メインフレーム、悪くないよ。というか、むしろ技術的には、UNIX/Linuxよりも優位性があると思う。
詳しくは、"Principles of Operation"でも読め。今でも、たいして変わってないと思う。最新の事情は、各社のドキュメントを読め。
擁護したいわけじゃないのだが。
契約した当時、HP-UXやAIXを除いてミッションクリティカルシステムのOSサポートしてるとこあったのかなぁ？
数年前のLinuxでは、とてもじゃないけどこれに耐えうるシステムは作れなかったし、ベンダサポートすら存在しなかった。ミドルウェアの対応も不十分だったと思うんだけど。
ソフトウェアの問題だから理解し辛いのかもしれないけど、
ハードウェア側で同じレベルのリスクをとるってことは、「サーバなんて不要。パソコンで十分で組み立てた方が安いからパーツ買ってきて自分で組み立ててサーバ立てたよ。壊れても自分でパーツ買ってきて直すから問題ないよ」と同じようなものなのだと思うとわかりやすいかなと思う。
元増田は判っているかも知れないけど、誤解されていそうな所について。
メイン・フレームも馬鹿高いのですが、ＵＮＩＸベースのサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、ＯＳ、ミドルウェア等々も全部買いなおしになってしまいます。
http://anond.hatelabo.jp/20080720205422より
それは、ベンダお任せで安定な（HAな）システム更新を行うときには、常識です。「何を言っているんだ、この化石反動め！」という声も聞こえてきそうですが、まあ落ち着いて読んでください。
そのように、上から下まで１社で揃えるのは、垂直統合と言われます。そのメリットは、あらゆるトラブルについて、そのベンダにワンストップでクレームを入れて調査対応させる事が出来る事です。コンシューマでは考えられないかも知れませんが、何らかの原因でシステムが動かないときに、「ありゃ、ダメだ」では済まないシステムでは、トラブルを迅速に解決できることが極めて重要であり、重要性に応じて必要なコストは払わねばならないものなのです。安定性の重要性を無視して目先のコストに囚われても、利益機会損失などで安物買いの銭失いと言う事になります。
この垂直統合のメリットですが、その中にサポート期間か切れてしまう物や組み合わせが((OSの対応ハードとか、ミドルウェアの対応OSバージョンとか)）サポート外の物があると半減してしまいます。ベンダ側も、保守コストを抑制しなければ商売出来ませんから、サポート期間も組み合わせも有限に設定せざるを得ないのです。
ですから、そのような一斉リプレースは常識と言えます。
その一方で、そこまでの安定性（可用性）が求められない場合、安い物を組み合わせた方が、コストダウン出来るのは当然です。また、トラブルが起きても、ベンダ任せではなく、自力でトラブルシュート出来る場合も、勿体ない出費といえます。しかし、自前でそんな高スキルのエンジニアを抱えていなければ、適切なトラブルシュートは出来ません。さらに、OSやミドルウェアのソースで確認しなければ((OSSを使っていてもちゃんと自前ビルドして自前でソース管理していなければなりません。単純にバージョンアップすると非互換によりシステムが動かなくなる場合があります))、そのトラブルシュートが正しい保証がありません。目の前の問題は回避出来ても、実は不十分だったり、下手したらもっと深刻な問題を発生させてるかも知れません。
垂直統合はやはり高コストになりやすいので随分割合が少なくなってはいるのは確かだと思いますが、それは、トラブルのリスクを負う事でコストダウンを図っていると言う事なのです。
http://anond.hatelabo.jp/20080721002901より
確かに、これらはメインフレームの特徴であり、オープン系からすると奇妙であり、そしてオープン系に比べてベンダ側の利益率が高い（それでも、世の中もっとボッタクリ商売はいくらでもあるけどね）もの。
この辺は、実際の所、明確な根拠は存在し得ないはず。というのは、「なんかあったら何でもやります」という料金だから。何でもやります、というのは大袈裟に聞こえるかも知れないけど、オープン系なら諦めるような事まで徹底してやるのは事実。そして、その作業の安定性への拘りも、オープンより明らかに饑えだし、安売り専門PCサーバ屋とは桁が違う。そこまで出来るのは、やはり沢山お金を貰ってるから。コストでストップ掛けずに徹底してやれる。とはいえ、今のITの世界の中では、ボッタクリと言われるような利益率なのはその通り（繰り返すけど、IT業界の中では）。
以上、元増田は判ってるかも知れないけど、万一のためと、読者の誤解を招かぬよう。戦った結果「こんなはずじゃ」というオチにならないように。
若い役人が、こう頑張るのは素晴らしい。ぜひ、その心を終生忘れずにいて頂きたい。
しかし、地方SIは自前で受けられない。理由はスキル不足、人手不足、経験不足、体力不足。
結局、お客さんもコストの問題で東京に作るものを地方の会社を使って人件費を減らし、
SIベンダも人件費を下げるのに地方に立地する。東京に会社を作るより、地方の人件費で出張費を出しても
一例を挙げれば
・福岡で経験5年のWEBエンジニア（oracleSilver9i）が58万。
東京の1ルームのマンスリーが15万、出張手当が5万としても10万浮く。
お客さんは地方にはいない。
だって地方の企業はそんなに大きなシステムを作成する必要が無い。
結局、人が集まるのが先か、経済が集中するのが先か。
鶏と卵のようになったが、お互いがお互いを循環しているのだから
ってことは恐らく、今この状況こそが不自然に見えて自然な状態なのだ。
成熟した森なのだ。確かに、不整然としてごちゃごちゃで火事場や泥沼のPJTしか見ないけれども
それこそが雑木林。
ITバブルという陽樹林から、少ない日光で最大の生物を養える陰樹林が現在のIT業界なんだ。
次に訪れるものは、小さな進化ではなく大きな変化だと思う。小手先の流行など、エンドユーザーに対してもなんの感動も与えないし、エンジニアも@ITに踊らされはしない。
まずは環境の変化・・・ホワイトカラーエグゼンプションか、海外へのオフショアか。
地方SIベンダで比較的安定しているのは、大手SIの地方分社と取引をしているところ。
FとかCとかNとか。
こういうところは安定している。
エンドユーザーの要件定義は大手SIの本社が行い、サブシステムについて大手SIの地方分社が行う。
そこに更に細かく切り分けた部分を、地方SIベンダが受ける。
ただし、これだと孫受けで良いほう。ひ孫、玄孫、も当たり前。
永遠に自社のオリジナリティを出す機会は無い。まして況や受託など、受けれたとしても採算ベースに乗せるのは難しい。
マネジメント力、コスト管理、、、、地方が受ける受託費用が上がるよりも早く、人件費が上がる。
結局のところ、地方SIが完全自立する可能性は、ほぼない。
大手のように、本社を東京、そして地方分社化というのが一番正しいのだろう。
でも、それは本当に地方を盛り上げていくことになるのか。
先は見えない。
http://anond.hatelabo.jp/20070317225847
ちなみに、クッキーモンスターの話は直接関係しません。それも(好まれない)技の一つとして使えるという事ではありますが。
たとえば、ここ匿名ダイアリをみると、www.google-analytics.com にリファラ付きでアクセスし、そこからクッキーが飛んでくる。これは、今、私が書いているページでも同様だ。ということは、クッキーの値と、私のIDが関連付けできる、ということでもある。そして、私があんなブログやこんなブログを見に行った時、そこにも google analytics が設置してあれば、はてなと同様に、www.google-analytics.com にリファラ付きでアクセスし、そこへクッキーを飛ばす。
つまりそれは、
と、www.google-analytics.com にはわかってしまう、ということでもある。もちろん、www.google-analytics.com の所有者である google は、analytics のアカウント毎のアクセスしかユーザには教えないし、内部でも個人単位のアクセス動向を調べるようなことはしていない、と信じている。
私には、それを確かめるすべはないが。
analyticsは、文字通りアクセス解析の仕組みなのだが、同様の事を行なっているのは、そういうサービス以外に広告サービスがある。doubleclick.net などが有名だ。彼らは、自社のサービスである広告の効果やアクセス動向を知るための、アクセス解析を行なう目的で使っている、はずだ。それ以外では使っていないと信じたい。しかし、あまたある広告サービスやアクセス解析サービスが、
とか
という話はある。
とか売ってるかも知れない。それを肯定する材料も否定する材料も、私はもっていない。
こういうのは tracking って呼ばれてるんだっけか。下はIPアドレスとリファラの関連付けからはじまり、このクッキーで精度を高める方法、さらに JavaScript で滞在時間等も出すとかある。たしか。
で、これらは実施者からみれば、アクセス動向を正確に知りたいだけなんだよ、ブラウザの標準機能を使ってるだけなんだよ、って話だけど、アクセス側からみると、本来関連付けられる事のない、別サイトのアクセスが関連付けられるのはどよ、ってなるわけだ。私がサイトAとサイトBをみていた事を、なんであんたが知ってるんだと。A店とB店で価格を見比べていた、なんて事があんたに知られるのはキモイんだよと。それってストーカーじゃないのかと。
とは言え、私の1クリックは、何千何万何百万のうちの1つだし、実名や住所と紐付いているわけでもないし、クッキーなくてもIPアドレスとリファラはあるわけだし、ユーザ動向の調査が目的で倫理に反するような事には使わないっていってるし、そんな悪い事をするなんて、ごく一部だろう。そもそも、そんなにうまくいくほどのものではないだろう、気にするほどの事じゃない。ともいえる。
ちなみに、この時クッキーモンスターを使うと、情報収集している主体をわかりずらくする事ができる。*.ne.jp でクッキーを送ると、そのクッキーを送ってくるアクセスを逃すと、どこが送ったのかわからない。foo.ne.jp bar.ne.jp hoge.ne.jp ほかさまざまなドメインをとっておけば、関連しないと思ったアクセス間でも関連付けられる。そういう意味で、トラッキング目的のクッキーである可能性は高いし、隠蔽工作を行なっているならば、ろくなものではないだろう、とはいえる。単に、CGIなどのバグの可能性もあるけれど。
ここらあたりは、論理的にできる事、技術的に妥当な所、倫理的にあるべき所、一般ユーザとして当然と思える事、行なう側が当然であるべき事が、まだまだ一致しきれていないから、良い悪いが揺らいでいて、個別事例を、一般解として、これはNG、これはOKと判断するのが難しくて、スパイウェア検知ソフトベンダ各社は、そういう部分は人それぞれですので、低いラインに併せて検知するようにしているんです、判断は自社基準です、実施側の理解不足や基準見直しなどで、随時変更します、という。クッキーは「ウェア」なのか？という事は抜きにして。
まぁその、そこの名物社長さんの講演を聞いて懇親会って内容で、正直あんま期待しないで行った。
会場につくと結構な数の参加者が。見たところ200人くらい？多分ほとんどがITベンダの部課長か企業のIT戦略部とか、いくらか偉いさん。平均年齢45オーバーな感じ。
で、まぁ講演。チキュウオンダンカとかキッコウ異常とか、アルゴアさんとか、あー、はい。とか思って聞いてたんだけど、途中からヒートアップしてきていろんなものをdisり始めたあたりから俄然面白くなってきた。
大企業とかマスコミとかアメリカとか税制とか、特に大口お客さんであるはずの業界人とかそのIT担当にエネルギー、電気の使いすぎヨクナイ！って、あんたが言うかよ！って感じで会場からも笑いが漏れてた。
なんか微笑ましい人であることはよく分かった。なんか部下は大変そうであるが。
名物社長がテーブル回ってきたので名刺交換させてもらって頭下げたら、ゴム草履履いててた！靴下のうえに！
もう、食ったばっかのからあげ吹いた。いやギリギリ止まったが。
