少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が

システム開発の失敗を理由にスルガ銀行が日本IBMに対して損害賠償を求める訴訟を起こした件で、2008年4月14日、第1回口頭弁論が東京地方裁判所で開かれた（関連記事）。 裁判では両社が提出した資料が確認された。日本IBM側である牛島総合法律事務所の牛島信弁護士が「答弁書の続きを提出したいので、（作成のために）2カ月時間がほしい」と要求。裁判長はこれを了承し、「争点の整理は今後速やかに行う」と話した。 現在、スルガ銀が提出した訴状を閲覧できない状態が続いている。日本IBMが東京地裁に訴状閲覧制限を申請し、審査が終わっていないためだ。この理由について日本IBMは「係争中のためコメントは控える」（広報）としている。今回の公判でも、訴状の内容は明らかにならなかった。 スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。2004年9月にプロジェクトを開

システム開発における上流工程の問題をテーマとした「要求シンポジウム」（主催：独立行政法人 情報処理推進機構、NTTデータ）の第2回が1月23日、都内で開催された。特別講演を行ったのは、東京証券取引所 常務取締役（最高情報責任者） 鈴木義伯氏。「東証次世代システム開発の上流工程と課題」と題し、現在構築中の次世代売買システムにおける開発プロセスの改善について講演を行った。 東証が構築中の売買システムは2010年の稼働を予定しており、現在は詳細設計の段階にある。開発の上流工程で品質の作りこみを行うことにプロセス改善の力点を置いていると鈴木氏は言い、要件定義から基本設計段階の作業について、具体的な数値を挙げながら話を進めた。 プロセス改善の取り組みとして、鈴木氏はいくつかのポイントを指摘する。1つは、発注者責任の明確化。今回のプロジェクトでは、ベンダを選定する際に、詳細入札仕様書（RFP約1500

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます デスマーチはデスマッチになりやすい――。SI業界でよく言われることだ。しかし、そのデスマーチを撲滅するための即効薬は、いまだ存在しない。そうしたなかで、デスマーチを撲滅するための「小さな一歩だが、大きな飛躍」と関係者から期待されている文書類が公開された。 NTTデータなど大手SI事業者6社が2006年4月から共同で立ち上げた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（発注者ビュー検討会）の第1弾の成果物がこのほどウェブで公開されたのである。同検討会には、NTTデータのほか、富士通、NEC、日立製作所、構造計画研究所、東芝ソリューションの計6社が参加している。 発注者ビュー検討会は、情報システムの仕様について、ユーザー企業に

年金問題に端を発して，社会保障番号の導入についてのニュースが新聞やテレビを賑わせている。住基ネットで使われている11ケタの住民票コードを転用する案も出ているようだ。だが，2002年～2003年ごろの住基ネット一次稼働・二次稼働の時ほど，市民からの反対意見は聞こえてこないように思える。 「ITpro電子行政」では今年春，大阪高裁による住基ネット違憲判決を受け入れた大阪府箕面市について，藤沢純一市長のインタビューや，同市の検討委員による“選択制”提言についての速報ニュースを掲載したが，「思ったほどの反響は呼ばなかった」というのが正直な実感だ。「住基ネット/国民総背番号」問題全般について，世の中の関心が薄れているのかもしれない。 だとしても，いざ社会保障番号が導入されるとなれば，住基ネット導入前後のような混乱がまた起こらないとも限らない。実際，住基ネットの場合，いくつかの地方自治体の首長が反対の

いきなり失礼しました。はてなのインフラチームの打ち上げは渋谷で焼肉と相場が決まっています。これは前回の打ち上げで行った焼肉屋での一枚。明後日にははてなダイアリーデータセンター移転打ち上げを開く予定です。 ...ということで、昨日ようやく、はてなダイアリーをさくらインターネットのデータセンターへ移転しました。恒例の写真で振り返る移転レポート、はてなダイアリー移転編です。 今回の移転は深夜に行いました。0:00 に会社に集合。移転にあたって一ヶ月くらいかけて準備をしてきたので慌てることもなく、サービス停止時間の 2:00 までわりとマターリ進行でした。僕は id:hideoki と PSP でモンハンしてました。 これは ENERMAX LIBERTY 電源。最近はてなの自作サーバーで愛用している電源です。はてなダイアリーの移転にあたり動いているサーバーを止められるチャンスだったので、これを期

全日空は、5/27（日）の未明から同日15時半まで、国内搭乗手続きに関するシステムで障害を起こしました。 これによって運行の遅延や一部欠航が生じ、6万人弱に影響が出たそうです。 同社の発表によれば、システム障害の発生箇所は「総合旅客システム（able-D）」と呼ばれる全日空グループの予約・ 発券システムのうち、国内旅客系に関するホスト端末間（全6系統中3系統）であったとのこと。 問題となった3系統（サーバ3台）は5月上旬から24日まで2週間かけてアプリケーションのアップデートを行っており、 26日になってから原因不明の処理速度低下が発現していたと述べられています。 暫定処置として、更新したサーバを旧サーバに戻して更新前の状態を復元したところ、 処理速度が回復して問題を回避することができたということも発表されました。 同社広報は「週末に顧客が増え、システムに負荷がかかった可能性もある」という

さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸

日経コンピュータ2006年4月3日号の記事をそのまま掲載しています。執筆時の情報に基づいており現在は状況が若干変わっていますが、BCP策定を考える企業にとって有益な情報であることは変わりません。最新状況は本サイトで更新していく予定です。 「電力が大問題」。データセンター事業者から悲鳴が上がっている。ハードウエアの消費電力と発熱量は増える一方で、空調設備を含めると電力の供給が追いつかない。ハード・メーカー各社は相次いで省電力技術を使った製品を売り出した。 「最新型のブレード・サーバーを大量に導入したものの、電力の引き込みが追いつかずラックにサーバーをすべて詰め込めない。せっかくのラックはスカスカの状態だ」。こう打ち明けるのは都内のあるデータセンターの責任者だ。このセンターは5年前に建設されたが、2005年の半ばから深刻な電力不足に見舞われている。原因は、サーバー本体、サーバーを冷やす空調設備

前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを

IT化を推進するということは「ペーパレス化の促進」のような効果をうみ、地球環境にとても良いことである、と思い込んでいたのだがどうも最近はそうではないらしい。Nicholas Carrは近頃コンピュータの電力消費量の増加について興味満載らしく、下記のエントリーを書き、問題提起をしている。 "Server electricity use skyrockets" "Avatars consume as much electricity as Brazilians" 上記のエントリーのポイントは下記の通り。 2000年から2005年にかけて全米のサーバー（但し、Googleの構築しているようなカスタムサーバーは調査対象から除く）の電力消費量が2倍にまで膨れ上がった 2005年のサーバーの電力消費量は、全米のカラーテレビの電力消費量に匹敵するものである Second Lifeのアバター1つあたり、年

日経コンピュータ2006年10月30日号の記事をそのまま掲載しています。執筆時の情報に基づいており現在は状況が若干変わっていますが、BCP策定を考える企業にとって有益な情報であることは変わりません。最新状況は本サイトで更新していく予定です。 「2010年代、都内ではデータセンターの需要に対して30万m2足りなくなる可能性がある」――。野村総合研究所（NRI）は今年春に実施した調査の結果から、こうした結論を導いた。同調査によれば、首都圏（1都3県）のデータセンターの供給面積は、2005年は60万m2だったのが、2010年には86万m2まで増える見込みである。それでも、利用率は2005年の45％から2010年には66％まで上がり、特に人気の東京都千代田区大手町を中心とした都内では30万m2足りなくなりそうだという。 ホスティングからITサービスまで ひとくちにデータセンターといっても、その利用

先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を

東京証券取引所が次世代売買システムの要件として挙げたのは、世界最高水準の高速性と信頼性、拡張性を確保することだ。開発を受注した富士通の提案は、この3点についてそれぞれ独自の新技術を投入、東証はこれを「10年先にも世界最高水準を維持できる」と判断したようだ。まず、高速性について、富士通が東証の要件にどのように応えたのかを検証しよう。 東証は2006年4月に発表した「次世代売買システムにおけるコアファクター」で、次世代売買システムに求める性能として、「10年先にも世界最高水準を維持できる」ことを見据えた条件を設定した。具体的には、現在約1～2秒かかっている注文に対する応答時間を10ミリ秒以内にするという内容だ。これは東証の売買システム利用者に対する公約でもある。 アルゴリズム取引で負荷が増す 現在、証券市場では、米国の機関投資家を中心にコンピュータ・プログラムによって自動的に注文を実行する「ア

大量トランザクションを処理するためには、アプリケーション・サーバを複数台並べて負荷分散する一方で、マルチプロセッサのDBサーバを採用しDB処理能力を確保するアーキテクチャが用いられることが多い。さらに高い処理能力が求められる場合には、DBの並列処理やオン・メモリ処理を併用するデザインもあるが、重要なことはスケーラビリティを確保するアーキテクチャ設計と、負荷を平準化する工夫である。

Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。 そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。 団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。 冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。 とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。 冷蔵庫に限らず、洗濯機、ラジオ、テレビ、

■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる