マイナンバーカード普及のために仕様の公開を
筆者はしつこくマイナンバー制度の取材をしている。システム開発に巨額の税金が投入されているからだ。マイナンバー制度が納税者の将来負担の軽減や社会の効率化といった成果に結びつかなければ、この記事を読んでいる読者を含め全納税者にとって、もれなく巨額の損失になってしまう。 政府が毎年改定している「世界最先端IT国家創造宣言」は、マイナンバー制度で「マイナンバーカードの普及と利活用を推進する」という目標を掲げる。ただ、そのためにはカードの仕様を公開する必要があると筆者は考える。後述するように、このままいくとブラウザーのFirefoxでは、マイナポータルを利用できないという事態も予想されている。マイナポータルは、マイナンバーカードで誰もが自分の登録情報の確認などができるサイトである。 マイナンバー制度には3つの異なる仕組みがある。1つは、国内に住む全ての人にマイナンバー（個人番号）を付番すること。2つ
システムに完ぺきを求め、不幸を撒き散らす疫病神はあなたです
「なぜ皆さんはプログラムに完ぺきを求めるのですか。そんなの無理に決まっているでしょ！」。某官庁の大会議室。居並ぶ大手ITベンダーの経営者や著名学者らが、システム障害ゼロを目指す取り組みの重要性を説く中、つまらなそうに聞いていたITベンチャーの若手経営者は、官僚から発言を求められ、そう言い放った。会議室の空気はブリザードに襲われたように凍りついた。 随分前の話とだけ書いておくが、当時は大規模なシステム障害が多発し社会問題になっていた。この会合は、システム障害を防ぐ抜本対策という非現実な命題を検討するためのもの。出席した誰もが内心では「そんなこと無理！」と思っていたはずだが、官僚の要請なので、出来もしない解決策を順番に開陳していた。それなのに若手経営者の発言。「そいつを言っちゃあおしまいよ」。出席者たちの心の声が聞こえてきそうだった。 この会合でどんな成果物が出来たのか記憶に無いし、過去の話を
判明、ANAシステム障害の真相
大型のシステム障害の詳細が見えてきた。全日本空輸（ANA）が2016年3月22日に起こした国内線旅客システム「able-D（エーブルディ、以下では便宜上開発コード名のANACore：アナコアと称す）」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース（DB）サーバーが停止したというもの（関連記事：ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン）。今回、弊誌
企業システムが分かるクラウドエンジニアが足りない
「クラウドを使うなら、“人”をつかまえろ」。クラウド活用に積極的なユーザー企業から、異口同音にこんな言葉を聞いた。日経コンピュータの3月17日号特集「破壊的クラウドSI」の取材でのことだ。 この特集では、パブリッククラウドを舞台としたシステム構築（SI）の急速な広がりを受けて、劇的に変化するSIの姿を取り上げた。クラウドの利点を存分に生かすには、オンプレミス環境でのSIを長く手掛けてきた従来ベンダーでは不十分なケースがある。クラウド移行と共に、SIベンダーの切り替えに踏み切るユーザー企業は少なくない。 では、クラウド活用が得意なSIベンダーをどう見つけたらよいか。これを取材で質問したところ、複数のユーザー企業で聞かれたのが冒頭の言葉だ。クラウド活用力のあるクラウドSIベンダーの当たりを付けるだけでは不十分。優秀なエンジニア個人を特定することこそ肝要、というわけだ。 一例が、AWS（アマゾン
JALシステム障害、前週に追加の排他制御がデッドロックを誘発
日本航空（JAL）は2016年4月6日、4月1日に発生した重量管理システムの障害について公表した。開発元から適用されたパッチの中に、キャッシュの排他制御を追加する設計変更があり、もともと実装されていたディスクの排他制御との間でデッドロックが発生したことが引き金になった。 システムはルフトハンザ子会社製 問題となった重量管理システムは、独航空大手Lufthansaの子会社である独Lufthansa Systems（LHS）製の「NetLine/Load」。乗客の人数や座席配置、貨物や燃料の量を基に重心を計算し、貨物の最適な搭載位置を算出して指示を出す役割を担う。JALのほか独LufthansaやカナダのAir Canadaなどが導入している。JALの場合、サーバーは東京都内のJAL拠点にあり、主要9空港からアクセスして業務に使っている。 JALは自社開発の重量管理システムをメインフレーム上で
［続報］JALシステム障害、サーバー内の「滞留メッセージ」と関係か
日本航空（JAL）は重量管理システム「Netline Load」で2016年4月1日午前中にシステム障害が発生した件について、Netline Load内に滞留したメッセージを削除したところ正常稼働したと明らかにした。システム障害の影響で国内線46便が欠航し、6670人の足に影響が出たことも分かった（関連記事：JALでもシステム障害、重量管理システムの不具合で遅延・欠航相次ぐ）。 現在もJALは原因を調査中で、「滞留したメッセージ」の具体的な内容や障害との因果関係は明らかにしていない。Netline Loadは午前7時48分ころに不具合が発生し、午前9時40分に再稼働させた。 この時「サーバーを再起動し、滞留したメッセージを削除したところ、正常に再稼働した」（JAL広報）という。なぜサーバー再起動に加え、「滞留したメッセージ」を削除したかは明らかにしていない。現在JALはシステムの監視を強化
「staticおじさん」はなぜ自信満々なのか
「staticおじさん」という言葉をご存じでしょうか。「static」というのは、Javaのstaticメソッドのことです。Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。 staticおじさんについては、わかりやすく解説したブログエントリが有名です（参考リンク）。実際のシステム開発の現場でstaticおじさんに苦しめられている様子をまとめたページもあります（参考リンク）。 なお、Javaのstaticメソッドを多用する人に限らず、古い感覚にとらわれて周囲に迷惑をま
［第1回］1つの国と同規模のICTインフラを仮設、屋外はカバレッジ最優先
2015年7月28日から8月8日の12日間、山口市で「第23回世界スカウトジャンボリー」（23WSJ）が開かれた。WSJは4年に1度開かれるスカウトの世界大会。東京ドーム53個分の広い敷地に、世界161の国と地域から3万人以上の青少年が集い、キャンプ生活を共にする。国立天文台の大江 将史助教は23WSJ会場に世界最大クラスの屋外無線LANを敷設。その構築・運用について、10月1日にITpro EXPO 2015会場で講演した。本レポートは大江助教の講演を再録してお届けする。（日経NETWORK編集部） 夏に開かれた「23回世界ジャンボリー（23WSJ）」の会場であるきらら浜（山口市）に構築した情報通信（ICT）基盤ネットワークについてお話しします（図1）。広さ約250ヘクタール（ha）の大きな広場に、3万人以上が利用する屋外無線LAN（Wi-Fi）を構築しました。きらら浜は元々農業向けに作
［1］みずほ銀行「次期勘定系システム」の全貌 プロジェクト完遂へいよいよ正念場
みずほ銀行が社運を賭けて開発を進める次期勘定系システム。総投資額は3000億円以上におよび、要員もピーク時に8000人超となる巨大プロジェクトだ。 「今後30年の礎」「新生みずほの象徴」――。2002年や2011年に大規模なシステム障害を起こしただけに、同行関係者が次期勘定系システムに寄せる思いは並々ならぬものがある。開発完了予定の2016年12月まで残り1年余り。佳境を迎えたプロジェクトの内情に迫った。 三つを統合し、しかも刷新する 「最初に描いた基本的なアーキテクチャーは決して崩さない。協力会社を含めたのべ1万人の関係者にこの思想を徹底させてきた」。みずほフィナンシャルグループ（FG）の加藤朝史システム推進部部長は、初志貫徹でプロジェクトを最後までやり遂げることに自信を示す。キーワードとして挙げたアーキテクチャーが、「みずほSOA」と呼ばれるものだ。 SOA（サービス指向アーキテクチャ
［続報］CAFIS障害はFEPサーバーのダウンが原因、3割のクレカ決済に影響
NTTデータは9月6日、5日にクレジットカード決済インフラ「CAFIS（キャフィス）」に障害が発生した原因について、ハードウエア障害によるサーバーダウンだったことを公表した（画面）。5日の午後4時6分ころから午後5時39分までCAFIS経由でのクレジットカード取引に影響が生じた（関連記事：CAFISに障害、全国的にクレカ決済が2時間ほど利用できず）。「障害中は3割の取り引きを処置できなかったり遅延したりした」（NTTデータ広報）という。 障害の直接原因はFEP（フロントエンドプロセッサ）サーバーと呼ぶ、大量の処理を振り分けるサーバーがダウンしたこと。ハードウエアが不安定になり、それをコントロールするミドルウエアも制御しきれず、ダウンしたという。 FEPサーバーは複数台あるが、そのうちの1台がタウンした。SEが状況を把握、判断した上で待機系のサーバーに切り替えて復旧させたという。サーバーが不
日本IBMはなぜスルガ銀行に負けたのか
2008年3月、スルガ銀行は日本IBMを訴えた。システム開発頓挫の責任をベンダーとユーザーが押しつけ合った。ベンダーのマネジメント義務違反か、ユーザーの協力義務違反か。最高裁がスルガ銀行に軍配を挙げたことで7年に及ぶ裁判がついに終焉を迎えた。 本連載では、主にIT企業に関連する裁判例や近時のトピックを取り上げ、IT企業が法務面で留意すべき事項を指摘していく。第1回は、著名事件である「スルガ銀行 vs 日本IBM」事件の高等裁判所判決を見ていこう。本連載では紙幅の都合上、事案や判旨をかなり省略することが出てくるが、ご容赦願いたい。 2008年から続いた、スルガ銀と日本IBM（以下、IBM）の訴訟。一言で言えば両社が契約を結んだシステム開発プロジェクトが頓挫した原因がどちらにあるのかということを争い続けた。 スルガ銀はベンダーであるIBMが果たすべき義務、つまり高度な専門的知識と経験に基づいて
1000円以下で自作できるモバイル対応IoTシステム！なんとアプリ制作時間は15分
最近、親指ほどのマイコン内蔵Wi-Fiモジュールを使ったIoT応用システムに入れ揚げている。何しろ、日本の規制に阻まれ海外では活発に流通している安価なチップが使えずにいたのに、今年7月ごろから認定クリアした製品が500円台から手に入るようになったのだ。しかも、このモジュールひとつで自分専用のIoTシステムが完成する。アイデア次第で応用はまさに無限。実に面白い時代に入ったとの実感でわくわくしている。 ものの15分でIoTモバイルアプリが完成 今回はこの全体像と、この記事を見たらきっと作りたくなる人も出てくるだろうから、具体的なレシピまで紹介しよう。 何はともあれ、どんなものができ上がりつつあるか、その中間成果をご覧いただきたい。 こちらはマイコン入りのWi-Fiモジュールに温度・湿度センサーを追加して、庭木の根本に置いたものだ。以前はArduinoやRaspberry Piといったマイコンボ
最終回：「まずRFPありき」を徹底せよ ベンダー管理の要諦は“社内管理”
元ソニーのCIO（最高情報責任者）で、現在ガートナー ジャパンのエグゼクティブパートナーを務める長谷島眞時氏。連載の最終回では、ベンダーマネジメントにおける問題を取り上げる。システム開発の丸投げで存在意義を問われるIT部門に、最後の活を入れる。 IT部門に未来は無いとする、日経コンピュータの木村岳史編集委員の「極言暴論」に反論する私の連載も、いよいよ今回が最終回だ。実は、この連載を執筆するにあたり、木村氏とは何度も会って徹底的に議論した。その結果、IT部門の否定的な現状認識については、互いにほとんど差が無いことが分かった。違いは、木村氏が「もうダメだ」と主張するのに対して、私が「今でも変革は可能」とするところである。 その意味では、今回のテーマであるベンダーマネジメント（管理）の問題も同様だ。極言暴論では「IT部門はベンダーマネジメントが全くできない」という。要約すれば次のようになろう。「
スルガ銀-IBM裁判で最高裁が上告を棄却、日本IBMの約42億円賠償が確定
勘定系システムの開発中止の責任を巡り、スルガ銀行が日本IBMに約116億円の支払いを求めた裁判で、最高裁判所は2015年7月8日、両社の上告を棄却する決定を下した。これにより、日本IBMに約42億円の賠償を命じた東京高等裁判所の判決が確定した（ITpro関連記事：スルガ銀-IBM裁判で両社が上告）。 スルガ銀行は2008年2月、勘定系システムの刷新プロジェクトが頓挫した責任は日本IBMにあるとして、約116億円の損害賠償を求めて東京地方裁判所に提訴した。 東京地裁は2012年3月、プロジェクトの企画・提案段階で、日本IBMが提案した勘定系パッケージ「Corebank」の同社による機能検証が不足していたことが、システム開発においてITベンダーが負う義務「プロジェクトマネジメント（PM）義務」違反に当たるとして、日本IBMに約74億円の支払いを命じる判決を言い渡した。 一方で東京高裁は2013
「10年前からスイッチを自作」、Googleが“公然の秘密”をついに公表
米Googleはネットワークスイッチを自社で開発している――。長年IT業界でささやかれていた噂を、Googleがついに認めた。2015年6月14日から18日まで米カリフォルニア州サンタクララ市で開催された「Open Networking Summit 2015」の基調講演で、同社のFellowであるAmin Vahdat氏が公表した（写真1）。 同社がネットワークスイッチを初めて自作したのは2005年。現在Googleのデータセンター（DC）で使用する「Jupiter」スイッチは5代目に当たるという（写真2）。世界でも最大規模のデータセンターを構築・運用しているGoogleが、ネットワークスイッチをネットワーク機器ベンダーから購入せずに、自社で大量に生産しているという噂は、2007年頃から業界でささやかれていた。その噂をGoogleが公式に認めたのは、今回が初めてのことである。 「既存のネ
三井住友銀行が統合後初の勘定系更新、IT予算1000億円から戦略投資の比重高める
三井住友銀行が、2年半にわたる大仕事に区切りをつけた。2015年5月4日、住友銀行とさくら銀行の統合後初めてとなる勘定系システムのハードウエア更改作業を完了。システム基盤の整備を終えた。今後は本業の成長を支える戦略分野へのIT投資を加速させる（写真1）。 リテール分野では、営業担当者向けに2000台のWindowsタブレットを導入。運用商品のシミュレーションアプリなどを開発済みで、2015年6月末までに全てを配り終える予定だ。 バックアップ環境のハードを倍増 「今後10年の基礎ができた」。三井住友銀行の宮川琢弥システム統括部統括グループグループ長は語る。同行はゴールデンウイーク期間中に、東日本のセンターにある勘定系システムで使う4台のNEC製メインフレームを最新機種に入れ替えた。これをもって、検討を重ねた末に2012年秋に始動させた更改プロジェクトを完遂した。 本プロジェクトでは、合計16
［続報］日本年金機構、ファイル共有サーバーを5年以上前から運用
［続報］日本年金機構、ファイル共有サーバーを5年以上前から運用 ルール上は「個人情報の格納は原則禁止」 日本年金機構から125万件の年金情報が漏洩した問題で、同機構は漏洩データを保管していたファイル共有サーバーを社会保険庁時代から恒常的に利用していたことが明らかになった。年金記録などを格納する基幹システム（社会保険オンラインシステム）から個人情報をファイル共有サーバーに移していたところ、標的型ウイルスに感染したパソコン経由で情報が漏れた（関連記事：日本年金機構にサイバー攻撃、ファイル共有サーバーから125万件の年金情報が流出）。サーバー上に個人情報を置くことは原則禁止していたという。 同機構のシステム統括部によれば、少なくとも2010年1月の機構発足時には、基幹システムから抽出した個人情報をファイル共有サーバー内のフォルダに格納して、職員間や事務所間で共有していた。フォルダは階層構造であり
「年金機構事件」受け、政府がセキュリティ会議を緊急招集 各省庁に点検求める
政府は2015年6月1日夕方、首相官邸で緊急のサイバーセキュリティ対策推進会議（CISO等連絡会議）を開いた。日本年金機構へのサイバー攻撃事件（関連記事：日本年金機構にサイバー攻撃、ファイル共有サーバーから125万件の年金情報が流出）を受けて、各省庁で情報を共有。類似の手口によるサイバー攻撃を受けていないか、点検して内閣サイバーセキュリティセンター（NISC）に報告するよう指示した。 会議の事務局を務めるNISCによると、議長の杉田和博・内閣官房副長官、副議長の西村泰彦・内閣危機管理監と遠藤紘一・内閣情報通信政策監（政府CIO）に加え、各省庁の大臣官房長級の代表者らの合計40人が出席したという。 冒頭、年金機構を所管する厚生労働省がサイバー攻撃・個人情報流出事案について報告。続いて杉田副長官が各府省に対して、点検と再発防止策の徹底を指示した。 具体的には、「インターネットに接続されている情
システム障害や個人情報漏洩より驚いた、メインフレーム技術者の話
規模の大小はともあれ、システム関連トラブルのニュースが相次ぐ日があります。今日がそうでした。 「50の信用金庫で一時ATMなどが利用できず、共同基幹系システムでトラブル 」、「ニフティの＠homepageで不正アクセス、18万人分のFTPパスワード漏洩か 」、「仙台うみの杜水族館の年パス購入でトラブル、顔写真含む最大135人の個人情報が漏洩 」の3本の記事を公開しています。 ですがもっと驚いた記事がありました。「メインフレーム技術者を1週間で育成、CAが教育コース開講」です。 メインフレーム技術者だからではありません。1週間という期間で育成できるという事実に驚いたのです。記事を読むと納得するのですが、メインフレームと1週間の組み合わせは意外でした。
自分を変えたSEの体験談から「自分の変え方」を自分で学ぶ
人を変えるのは難しい。中でも自分自身を変えることが一番難しい。その難しいことをやってのけた人は一体どのように取り組んだのか。 上司や同僚、部下が「変わった」と認めたSEの方々4人に、自分を変えた体験談を『変える！仕事を、組織を、そして自分を』と題して寄稿いただいたことがある（『「みんな厳しいな」、部下の辛口評価に愕然』、『「積年のテーマに道筋を付けて帰ってこい」』、『 「それって本当にベストな解決策？」と真剣に考える』）。 4人はいずれも大手企業の情報システム関連会社に所属しているSEで、10数名の部下を持つ課長ないしチームリーダーもいる。情報システムを開発、運用、保守していくにあたって、品質の維持や若手の育成といった課題を抱えていた。 一つの試みとして4人の体験談の中から「学んだ」「気付いた」「役に立った」と書かれた文章を抽出してみた。それらを見渡すと次の4つのテーマに分けられた。 ●自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
