  |
はてなキーワード: マイグレーションとは
毎度毎度、バージョンアップで非互換な修正加えてコードの修正が必要になって、Gemも上がって依存が壊れて
いつまでやってんだよｗ
Railsのプロジェクトでどれだけの人が最新版に追従できてんだよ？テストを書いてれば余裕？
本当かよ？正直に言ってみろよ？実際はレガシーRailsの山だろｗ
ヘルパーやらマイグレーションの仕組みやら最初は良いかなと思ったけど、どう考えてもやり過ぎだ
短くかけるとか喜んでるやつは一度考え直せ
それで良いんだって？自分がコントロールできない知らないコードに依存して結局バージョンアップで地獄みてるだろｗ
最低限中で何が起きてるか理解しとけよｗまあ理解できるころにはRailsでなくても良かったんやｗってなるけどなｗ
RAILS_ENV=productionだとstaticファイルは自分で返さないassetコンパイルで小さくしましょう
→ developmentで動いてたけど本番だと動きませんでしたｗ
毎度毎度、アホみたいにGem入れやがって、もう自分で把握できる状態じゃねーだろ？
bundlerだから完璧にvendoring出来ますだって？
本当かよnaitive extensionのGemなんてどう考えたってRails管理外のヘッダファイルに依存すんだろ
めんどくせーなbundlerもこけるし、rbenv使ってrubyのバージョン揃えろとか
ホントめどくせーよ
deployもcapistrano便利とか言ってるけれど、そんなに便利じゃねーよｗ
あんなDSL覚える時間あんならシェルスクリプト書けるようになっとけ
rackサーバがたくさんあってよかったねじゃねーよ集約しろ馬鹿ｗ
unicorn, pumaで比較しましたとかアホ記事書いてる暇あるなら集約するかなにかしとけ
この手の話すると信者が使わない方法もある・選択しない方法もあるとか擁護してくるけど
そりゃあるけどそれ調べんのがめんどくせーって言ってんだよｗ
何でもかんでもレールに乗せてそれを強要してくるような感じがすんだよｗ
タブとスペース混じりのインデントなど、見るに堪えません。
updateやfixなど英語一単語だと何が変更されたのか非常にわかりにくいです。
あと職場に英語圏の方はいなかったので無理に英語を使う必要はないと思います。
環境を再現することやサーバの中身を把握するのが困難になります。
世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。
開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。
動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人の迷惑にしかなりません。
テストコードを書ければ良いのですが、最低限手動でもいいのでご自分で確認してください。
利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。
不整合が起こらないように気をつけてください。
GETしただけなのに201を返すなど意図にあっていないものがありました。
他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます。
先輩は技術的知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。
CTO含む
人によるとは思うけど、俺が関わった会社のプログラマの年齢の傾向から言うと全員あてはまる。
過去の栄光を引きずり過ぎ
過去にそれで納品したか、褒められたかしらないけど、遺物を自慢しすぎ
今の時代にそぐわないプロダクトや、フローを自慢気に話されても何の得にもならない
「自動化とか意味ないでしょ、ドキュメントありゃ誰でもできるよ、DBのマイグレーション？めんどくせえ、スキーマのダンプ管理しろよ」
はあ？どんだけ時代に逆行してるんですか？CTOがそれいっちゃオシマイでしょ。時代の流れ読めないの？
そう言ってるヤツのおかげでどんだけチームが苦労してきたと思ってんだよ
「PHPとか誰でもできんだから、フレームワークとかいらないでしょ、そんなの使わずにスピーディに仕事しろよ」
はあ？ひとりでやってろよ
口は達者だけど、svn や git 使えない。svn も使いたくないけど。
誰かの書いた独りよがりのコードのせいで、リリースはだいぶ辛かったりする。
それが最近は自動化や、フレームワークのおかげで、リリースの負荷は軽減されてる。それを全然鑑みないのはマジでクソ。
技術力はひと昔前のトップクラスなのかもしれない（多分そうではないと思っているが）が、マジで迷惑
属人的な要素を排除しようと、自動化やCIでヒューマンエラーを極力抑えても、俺様な一言でまたプロジェクトが壊れる
HTMLとCSS, JavaScriptはちょっとだけ分かる
dotinstallとか見てブラウザでタイマー作ってわーいって喜んでるくらいのスキル感。
→本を買ってやるのは安上がりだけど途中で挫折しそう
→じゃあお金稼ぎながら学んだらいいんじゃ
バイト始めることになった
バイト始まる
課題を出されて、できたら業務に入れる
誰も教えてくれない
ググってググってググりまくる
ひーひー言いながら2~3週間でなんとか終えた
なんとかなった
このときくらいにパーフェクトPHPを読んだ。FWは、つくれる！
あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね
分かった気になる←分かってない
GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない
FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービスの受託をやる
まあ良い経験になった
フレームワークいくつかやって、web開発のいろんな概念やtipsがたくさん頭に入ってきて、
あーあれかーくらいには思えるようになった
DBのCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインでコード生成,認証周りのプラクティス ...
さて、バイトが本格的？になってくる
一人で開発 責任おもい
でもなんか躓いた。
書いたコードに自信が持てない
これでいいのか不安になって手が進まない
セキュリティで手直しはたくさんもらった
フレームワークにはDB操作のライブラリがちゃんとついてるのにそれ見ずに自分でSQL組み立てて案の定エスケープしてないし、とか
でも、なんとか完成させた
プッシュして、マージされて、できちんと本番環境で動いてる。やったね。
Rubyを知った
PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。
Railsも知った
それからは空いている時間の大半をRubyとRailsにつぎ込んだ
まずはRailsTutorialをやってみた
テスト周りでつまづいたけどなんとか終わらせた
dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ
はじめはRubyを理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた
はじめてのRuby・はじめてのプログラミング・たのしいRuby・プログラミング言語Ruby... 入門系の本を乱読した
PHPでさんざん苦労していたからか、Rubyでオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた
その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra（支那虎じゃなかった）やらについて学んだり、
メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatzの言葉痺れたなー
バイトのほうも何とかこなせるようになってきた 成長すげー
Vagrantをかじる
AWSでいろいろ遊ぶ
webスクレイピングとか検索APIとか使ってムフフな画像をアハーンしたりして遊んでた
Rubyで言語をつくろうだの、スクリプティングを極めようだの、JavaとRubyがどうだの。
メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。
借りられる本は借りて済ませた。全部買ってると破産する
他にもRubyとつかない本もいろいろ。
プログラマが知りたい97の何とか。いい本
Rubyの関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる
OOPと全く違う。
就活はじめるよー
まあ、エンジニア枠で探すことにする
エントリーめんどくさい
ので、1社受けて落ちたら次の会社エントリーするという作戦にした
無計画玉砕作戦
とはいえ、なんとかなると思ってやってく
気を揉む期間
やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない
せめてよく使ってる言語くらいはのっけておいて欲しい。
で、１社選んで応募して、選考が始まった
面接、失敗したなと思ったところもあったが
嘘つかない
知らないことを知ってるように話さない
は通せたので良かったと思う。
で、進んでいって最終面接。これもなんかよく分からないうちに終わってた
相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる
うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。
前から気になってた会社ではあった。勝手にリスペクトしてた会社。
自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる
いろいろと運が良かった。嬉しい
他の会社はどうしようかな。
受けてみたい気もするけれど、エントリーがめんどくさい
続けるかどうかは未定だけど、ひとまず休憩することにする
Rails of Ruby on Rails サポートサイト
http://railsofrubyonrails.com/download/locus_files.zip
Heroku | Cloud Application Platform タグ「heroku」を含む新着エントリー - はてなブックマーク
BitNami :: From InstantRails To RubyStack
Amazon.co.jp： Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~: Plan de Sens, 清水 智雄: 本
「Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~」を含むブログ - はてなキーワード
満足せる豚。眠たげなポチ。:RAILS OF RUBY ON RAILS が実にすばらしい件
RAILS OF RUBY ON RAILS - 世界線航跡蔵
いろんな意味で新しい Rails 本: Rails of Ruby on Rails - まちゅダイアリー(2008-05-24)
Rails of Ruby on Rails ～Case of LOCUSANDWONDERS.COM～
Introduction
Ruby on Railsの基礎知識
Chapter 01 開発環境構築
データベースの内容を確認する
スキャフォールドジェネレータで管理画面を作る
レイアウトを変更する
各ページのデザインを変更する
FileColumnプラグイン
モデルの修正
フォームの変更
Auto Discoveryを追加
コメント機能
ベースを生成
モデルの修正
コントローラの修正
コメント機能を記事に組み込む
トラックバック機能
スキャフォールドでベースを生成
モデルの修正
コントローラの修正
トラックバック機能を記事に組み込む
記事にタグ付け機能を追加する
商品管理
商品管理
ショップ画面
商品一覧画面を作成
商品詳細画面の作成
ライトボックス系JSライブラリを使って商品画像を効果的に見せる
注文処理
決済・注文画面の作成
メール送信のための設定
コンタクトフォーム
フォームの作成
入力の検証をする
Herokuを設定する
アプリケーションを公開する
Chapter 06 ユーザー事例
ケース1 Saigenji (http://saigenji.com)
作品集 (Saigenji & Happiness Records 編)
ケース2 UK.PROJECT (http://ukp-pr.com)
作品集 (UK.PROJECT 編)
ケース3 Traffic (http://trafficjpn.com)
動的データを静的ページに表示したい
ケース4 RX-RECORDS (http://rx-records.com)
複数の画像が切り替わるFlashバナーをRailsで管理・生成したい
作品集 (RX-RECORDS 編)
ケース5 石田ショーキチ (http://scudelia.net)
通常のページ構成以外の特設ページも管理したい
作品集 (石田ショーキチ 編)
ケース6 V2 Records (http://v2records.co.jp)
ケース7 橋本昌彦 (http://www.hashimotomasahiko.com)
天気と連動した画像を表示する
ケース8 BUMP OF CHICKIN (http://www.bumpofchicken.com)
作品集 (HIP LAND MUSIC 編)
ケース9 Cradle (http://cradleorchestra.com)
見たい記事だけをアコーディオン表示させたい
作品集 (Cradle & Palette Sounds 編)
Appendix
主なエラーの例と対策
Reference
http://d.hatena.ne.jp/isayama/20080720/1216562529
にキレイにまとめららていて、また当方の耳に痛いことも進言してくださいました。ありがとうございます。
事実とか思いとか、「日立製作所」の問題か「官公庁のＩＴ調達」の問題か、といった部分がないまぜになって単なる愚痴っぽい文章に終わっていますね。読み返すと。読者のみなさん、申し訳ありませんでした。
さて、内の組織や日立製作所を始めた大きな組織が急に体質を変えて、適正なＩＴ調達と技術の適用がすばやく進むとは思えません。日本的なボトム・アップ式のゆるやかな改革の連続が、いつか壁を突き破ることにつながることになるだろうと思います。
私が担当ベースで粘り強く取り組むことは以下のとおりかと思います。
（１）日立のメインフレームの見積もりで高い、または前回購入時よりほとんど下がっていない点については徹底的に説明を受け、当方の組織に納得できるよう資料を提示してもらう。
・以前、ガートナージャパンの亦賀ヴァイス・プレジデントが「国産メインフレームの最大の問題は価格の不透明さ、そして、今後の技術のロードマップが不透明なところである」と言っていました。
この点を担当者として、勉強もしながら疑問点を洗い出して、ベンダーにぶつけ、友好的な交渉の後、適正な価格・構成で契約すべきでしょう。
疑問点の洗い出し（「なぜ」を何回も繰り返す）
・１プロセッサーあたりの処理能力は向上しているのに、ＩＢＭのように筐体統合（論理分割＝ＬＰＡＲ）を推奨案とせず、メインフレームの台数が多い構成を薦めるのだろうか（秦野市のハード工場の維持のため台数出荷は押さえておきたいポイントなのか）
・１プロセッサー（50MIPS程度）で提供価額１億円を超えており、明細がないが説明をしてもらう。
プロセッサー単体＝１億ではなくある程度パッケージ化された固まりなので１億円の大台になってしまうのだと思う。交代用プロセッサー、ＳＶＰと言われるプロセスを監視する機構、あとメモリ（４Ｇ）等いろんな部位があってこういった値段になっている。福袋のようにまとめて、１億とか言われると思考停止するので、ここは明細を出してもらい、サービスマニュアルでどんな働き、冗長性を持っているかを理解して価格交渉するべきですね（デカルト「困難は分解せよ」）。
・詳細な見積もり書の提出を日立が拒む可能性は大きい。これまでも数度にわたり交渉したが、先方は牛歩作戦でうやむやにしてきました。ここは企業対企業なので、いろいろ駆け引きもあるようですが、地道に交渉します。気の利く営業マンだと「今の時点では正式な紙としてお出しできませんが、口頭ベース未確定でメモをお取りいただいたということで・・・」と言って企業名の入っていない内訳メモを出して、こちらの気を揉ませることのないよう配慮するのでしょうが。
・ＣＰＵ周辺部品の明細徴求
メインフレームは入出力用のチャネルと言われる部品も一個250万円ほどしてそれが、何十個と搭載する必要となるとすごい金額になります。昔メタルチャネルで、その次は光ファイバチャネル、そして最近光ファイバ多重チャネルと何種類かの接続機器が混在し見積もり金額が高くなるのです。周辺機器も順次、上位の接続規格にグレードアップしていけば、統合・集約ができるのですが、どうしてもレガシーな接続方法が残ってしまうのですね。パソコンに喩えるとUSBみたいなものですが、高いうえに融通が利かないのです。また、ここは日立独自の技術というよりＩＢＭから技術供与を受けているみたいですね。日立物流のトラックから当該部品が入ったダンボール箱の荷下ろしを目撃したのですが「ＩＢＭ ESCON」と堂々と箱に書いてありました。光多重チャネルは24多重まで可能であるので、数は減らせるはず、減らせないなら納得のいく説明をもらう。また、下位のレガシーチャネルは周辺機器の入れ替えの関係もあり１年も使わず廃棄といった勿体無いことがおこりそうです。
日立もグリーンＩＴを推進しているので、自社検証センターや共同システムセンタでさほどクリティカルでない場所でセカンド・ユースして下取りすることは可能か聞いてみます。
最近ＣＰＵ専用のプロトコル（日立ではＸＮＦという）をTCP/IPに変換するホスト側のミドルウェアが実装され、サーバへのデータ転送はＦＴＰ転送で可能になりました。メインフレームには内蔵ＬＡＮアダプターというギガビット・イーサーを搭載でき、またこれが２ポートついているのですが、１個200万円するんです。もっと高かったかな。それでサーバーと接続するのですが、普通、複数のサーバとやり取りするならば、中間にスイッチを置いてメインフレーム側のＬＡＮアダプターの数は抑制しますよね。
日立の技術者はめっきりネットワークに弱く、サーバと1対１通信をするため、相手のサーバの数だけ内蔵ＬＡＮアダプターを買わせようとしているのです。メインフレーム側の仕様かなと思い日立のメインフレームＸＮＦ／ＴＣＰマニュアルを精読すると１つのＬＡＮアダプターに64個までのＬＡＮの設定定義が可能となっていました。でも「ネットワークは自分の専門でないから・・・」等々言って動きたがらないのです。しかし、ここはしっかりお願いをして、場合によってはネットワークに強いベンダーさんを読んで帯域制御なり、ＶＬＡＮなりの十分汎用化した技術を使って最適な構成をやってもらおうと思います。
他の日立のユーザさん、どうですか。ネットワーク接続で目茶苦茶原始的な接続設計で高いハードをたくさん買わされていませんか。こういうハードはロット生産なので本社から在庫があるので、少々言葉は悪いけど無知なユーザにはハードを売り捌けという指令が飛んでいるのかもしれません。
日立はこれを「ＡＰ保守料（サービス料）」と読んでユーザに契約させ、１ヶ月毎払いで年間数億円請求しています。当官庁のサイトには常駐のＳＥさん、ハード保守の人に100人とまではいかないけど、詰めてもらってその方たちには、その保守料とは別に人月ベースで人件費を払っています。このＡＰ保守料は何か「本社への上納金」のような気がして仕方がないのです。すべてのユーザがお支払いしているのかも不明なので、いったいどういうものか質問してみます。ユーザサイド常駐ＳＥがいて、それとは別に事業維持のため上納金が欲しい。けれど月々の活動明細は提出しない。資金使途は教えられないというのでは「みかじめ料」みたいですね。日本ＩＢＭさんではこの制度はないようです。
■他社への参考見積もり
日本ＩＢＭ社に同等規模のシステムを構築するといくらくらいになりますか、ということで見積もりを取りました。
ハードの置き換えでなく、使用しているソフト料等のランニング費用を出してイニシャル×ランニングでトータルで参考値を提出してもらいました。
１ヶ月くらいかけて問診シートをもとに結構精緻な資料をつくってもらい日本ＩＢＭ社には感謝しています。メインフレームは独自ハード、独自ＯＳ、独自ミドルといったところで、全面コンバージョンは非常に難しいところがあるのですが、ＩＢＭさんは「参考になれば」ということで、しっかりとした資料をまとめてくれました。
一番、移行に対してハードルが高いのは20年来使っているＤＢのミドルウェアとのインターフェースが互換性がないということでした。形式が違うため、ＤＢのつくり、アプリケーションから参照するデータ・テーブルを全面改造するとなると、すべてのシステムをゼロから書き直すといったことが必要になり、今のこちらの体力では難しいという結果となりました。
しかし、ＩＢＭ側もこちらのシステムのつくりを把握することができたので「ここの機能はオープン・パッケージにマイグレーションするといい」と言った提案は今後してくれるとのことでした。
印象的だったのは日立のように秘密主義、なにも説明してくれない主義とは違って、自分たちの技術に自信、誇りを持って的確な資料を短期間に纏め上げてきたことです。感嘆しました。また、非売品だそうですが、「ＩＢＭ Ｚシリーズハンドブック」という、あまり専門的な知識がなくてもＺシリーズのイロハが分かる日本語の参考書をくれました。これは分かりやすくて、熟読して「日立」には「これはどうなの」と言った質問をしています。顧客に見せるナレッジ・マネジメントという意味ではＩＢＭの方が数段上のようですね。
メインフレームのプログラムは150種類くらいあって、個別に月々レンタルというかたちで使用料を払っているのです。ものすごく高いです。全部で70千万円くらいかな。価格体系も複雑で、またプログラム種類も多岐にわたり、理解が難しい。これなんかは提供側とユーザの情報の非対称性を「悪用」した「不安商法」といえるかもしれません。でも、税金が無駄に使われているかもしれませんので、頑張ってチェックしていかなければ。
■結論■
あまり、味方がいないので、体を壊さないようスケジュールを作ってこつこつ日立製作所との不公正な取引があれば理詰めで解消していきたいと思います。また、他の官庁、自治体で同様な無駄、過剰な契約をしていることがあれば、本当に必要なのか吟味して、全体として適正な方向に向かえばいいと思います。あまり革命は望んでいません。
最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。
官公庁で使用しているメインフレーム・システムは1980年代に通産省のコンピュータの国策化を目論む計画もあって、日立や富士通に置き換わっていったそうです。そもそも、日立や富士通、ＮＥＣは多額の税金を補助金として国産メインフレームを作ったという由来があるそうです。それでも日立、富士通はＩＢＭへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。
1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民の税金を使って多額の対価を得る。調達側も、日立、富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。
あまり健全ではない状態が日本のＩＴ力を弱めていると思います。東大、東工大の大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本の税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界で競争力を持つ部分に能力をあてがうべきです。
日立ですが、メイン・フレームも馬鹿高いのですが、ＵＮＩＸベースのサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、ＯＳ、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がＵＮＩＸサーバを自社技術で確立できず、ＩＢＭのＡＩＸやＨＰのＨＰ??ＵＸをＯＥＭ提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「（日立メインフレームの）基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。
よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムへマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。
最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。
官公庁で使用しているメインフレーム・システムは1980年代に通産省のコンピュータの国策化を目論む計画もあって、日立や富士通に置き換わっていったそうです。そもそも、日立や富士通、ＮＥＣは多額の税金を補助金として国産メインフレームを作ったという由来があるそうです。それでも日立、富士通はＩＢＭへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。
1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民の税金を使って多額の対価を得る。調達側も、日立、富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。
あまり健全ではない状態が日本のＩＴ力を弱めていると思います。東大、東工大の大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本の税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界で競争力を持つ部分に能力をあてがうべきです。
日立ですが、メイン・フレームも馬鹿高いのですが、ＵＮＩＸベースのサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、ＯＳ、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がＵＮＩＸサーバを自社技術で確立できず、ＩＢＭのＡＩＸやＨＰのＨＰ??ＵＸをＯＥＭ提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「（日立メインフレームの）基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。
よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムへマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。
最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。
官公庁で使用しているメインフレーム・システムは1980年代に通産省のコンピュータの国策化を目論む計画もあって、日立や富士通に置き換わっていったそうです。そもそも、日立や富士通、ＮＥＣは多額の税金を補助金として国産メインフレームを作ったという由来があるそうです。それでも日立、富士通はＩＢＭへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。
1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民の税金を使って多額の対価を得る。調達側も、日立、富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。
あまり健全ではない状態が日本のＩＴ力を弱めていると思います。東大、東工大の大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本の税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界で競争力を持つ部分に能力をあてがうべきです。
日立ですが、メイン・フレームも馬鹿高いのですが、ＵＮＩＸベースのサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、ＯＳ、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がＵＮＩＸサーバを自社技術で確立できず、ＩＢＭのＡＩＸやＨＰのＨＰ??ＵＸをＯＥＭ提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「（日立メインフレームの）基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。
よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムへマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。
