タグ

ブックマーク / xtech.nikkei.com (190)

  • なぜ“ダメなシステム”は無くならないのか?

    なぜ日では“動かないコンピュータ”が量産されるのか。なぜ失敗だと分かっていても後戻りできないのか。“システム屋”歴30年以上でIT業界を知り尽くした佐藤治夫氏が問題に切り込む。

    なぜ“ダメなシステム”は無くならないのか?
    dh_SPQR
    dh_SPQR 2013/03/21
  • がんじがらめのITエンジニア、優れたアイデアが生かされない

    「日ITエンジニアは“がんじがらめ”になっている」。取材した複数の外国人エンジニアからの共通する指摘だ。彼らの目になぜそう映るのか。原因は、日ならではのベンダーとユーザーの関係にあるようだ。 要件の決定権を持つ人が違う まずは、プロジェクトの体制面における指摘を紹介しよう。ベンダーがユーザー企業のシステム構築を請け負う際、日ではシステム部門がベンダーと利用部門の間に入って、プロジェクトを主導したり、調整したりすることが多い。 写真1●エイチシーエル・ジャパンのSreedhar Venkiteswaran氏。インド出身。インドや米国、ドイツでさまざまな業種のシステム開発経験を持つ 米国やドイツ、インドでのシステム開発経験が豊富なエイチシーエル・ジャパンのSreedhar Venkiteswaran氏(デピュティジェネラルマネージャー 日デリバリーヘッド。写真1)は、日で一般的なそ

    がんじがらめのITエンジニア、優れたアイデアが生かされない
  • あなたの知らない超高速開発

    あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「利用者にすぐに使ってもらえたり早く帰れたりするので、嬉しい」と思うか、「人月で見積もっているので売り上げが減ったりこれまでのマネジメントの方法が変ったりするので、嬉しくない」と思うか。 いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企業が登場している。 記者は今年の1月と2月、日韓国で25社以上のユーザー企業を訪ねた。日経コンピュータの3月15日号に掲載した特集「『超高速開発』が日を救う ~サムスンは既に始めている~」の取材のためだ。その中で、スクラッチ開発と比べて「10倍以上に開発効率が高まった」という声を、いくつも聞くことができた。三井住友海上火災保険や朝日生命保険、東京都足立区役所などである。 これは簡易的なシステ

    あなたの知らない超高速開発
  • スルガ銀が事実上の全面勝訴 IBMの責任認めた判決の深層

    勘定系システムの開発失敗を巡りスルガ銀行が日IBMを訴えた裁判で、東京地方裁判所は3月29日に約74億円の賠償を日IBMに命じる判決を下した。4年間にわたった裁判は、ITベンダーとユーザー企業にそれぞれどのような教訓を残したのか。弁護士やIT業界の有識者への取材から、スルガ銀-IBM裁判の深層を探る。 「ある程度は過失相殺が認められると思ったが」。システム開発をめぐる紛争に詳しい、ある弁護士は、驚きを隠さない。勘定系システムの刷新プロジェクトが頓挫したことによって損失を受けたとして、スルガ銀行が委託先の日IBMに約115億円の損害賠償を求めた裁判の判決についてだ。東京地方裁判所は2012年3月29日、日IBMに約74億円の支払いを命じた。 金額だけを見ると、スルガ銀の請求のうち64%しか認められなかったように見える。だが実態は、スルガ銀の全面勝訴に限りなく近い。なぜなら、64%とい

    スルガ銀が事実上の全面勝訴 IBMの責任認めた判決の深層
  • “スルガ銀−IBM裁判”を振り返る - 週末スペシャル:ITpro

    「約111億円」という巨額の損害賠償を求めて、スルガ銀行が日IBMを提訴したのは2008年3月のことだ。それから3年余り、裁判は終盤戦を迎えているという。システム開発に多少のトラブルは付きものだが、これほど大きな損害賠償請求に至ったのはどうしてか。ここで、裁判で示された問題を振り返ってみよう。 プロジェクト破綻までの経緯と裁判の様子 スルガ銀行は勘定系の次期システムとして、IBMのパッケージ「NEFSS/Corebank」の導入を決め、2004年9月にプロジェクトがスタートした。だが、要件定義を3回繰り返すなどシステム開発は難航。2008年1月の稼働予定を延期した。日IBMはスコープの大幅な縮小や追加費用を要求したが折り合わず、2007年5月にスルガ銀はプロジェクトの中止を決断した。 スルガ銀が日IBMを提訴、システム開発の債務不履行による損害など111億円超を賠償請求 スルガ銀行と

    “スルガ銀−IBM裁判”を振り返る - 週末スペシャル:ITpro
    dh_SPQR
    dh_SPQR 2012/03/30
  • [速報]スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令

    勘定系システムの開発失敗を巡り、スルガ銀行が日IBMに115億8000万円の支払いを求めた裁判で、東京地方裁判所は2012年3月29日、日IBMに74億1366万6128円の支払いを命じる判決を言い渡した。 スルガ銀行は2000年代初頭に勘定系システムの刷新を計画し、海外製の勘定系パッケージ・ソフト「Corebank」を担いだ日IBMの提案を採用した。ところが刷新プロジェクトは要件定義から難航。新システムを完成させることができなかった。 結果的にスルガ銀行は日IBMに新システムの開発中止を通知し、2008年3月に「日IBMの債務不履行によりシステムの開発を中止せざるを得なくなった」として、日IBMに損害賠償を求める訴訟を東京地裁に提起していた。 関連記事:“スルガ銀-IBM裁判”を振り返る ■変更履歴 スルガ銀による賠償請求額について、当初の記事では「111億700万円」と書い

    [速報]スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令
    dh_SPQR
    dh_SPQR 2012/03/30
  • 残念な部下が「残念な上司」に量産される不幸

    昨年12月にこのコラムに掲載した『部下は「残念な上司」を口癖で見抜く』は多くの読者から反響をいただいた。タイトルどおり、部下は自分の上司が「残念な上司」なのかどうかを、彼らの口癖から見抜いているという内容のものだ。無意識のうちに口を突いて出る口癖の恐ろしさをお伝えできたと思っている。 春は入社や異動の季節だ。新しい上司と部下の関係が職場にまた生まれるだろう。そこで今回は、この話を別の角度から考察してみたい。 書籍『残念な人の思考法』(日経済新聞出版社)の著者である、アジルパートナーズの山崎将志氏は、「目的や納期をきちんと部下に伝えないままに仕事を頼む上司が増えている」と話す。思い当たる人は、既に「残念な上司」になりかかっている。 特にここ数年は「電子メールで部下に仕事を頼む上司にその傾向が強くなっている」とも指摘している。筆者を含め、多くの読者もうなずけるのではないだろうか。 部下の顔を

    残念な部下が「残念な上司」に量産される不幸
    dh_SPQR
    dh_SPQR 2012/03/29
  • 経企部門が吐露する「システム部門への不満」

    業務プロセスの全体を俯瞰できるシステム部門は、全体最適の観点から業務改革や戦略的な情報システムを提案・推進できる存在といわれる。だが、経営層の多くは「事業への貢献が不十分」と考え、不満がたまっている。システム部門自身も厳しい現状を自覚しているが、どうしようもない事態に陥っている。 システム部門のあるべき姿としてよく描かれるのは、「ITを使ってビジネスモデルを変革したり、全社レベル/サプライチェーンレベルで業務プロセスの最適化したりするなど、ITを利用して事業競争力や業務パフォーマンスの向上に貢献する」というものだ。これを理想像と考え、その実現に努力しているシステム部門は多い。 しかし、理想と現実は大きく異なる。システム部門の増員は認められず、予算は減らされるばかり。限られたリソースでシステムを安定運用しつつ、内部統制の強化や国際会計基準への対応など、新しい要請になんとか応えていくことで精一

    経企部門が吐露する「システム部門への不満」
  • 「情報システム部はもっとやれる」と訴えたい

    「情報システム部という組織はもっともっと会社や社会に貢献できる。部長を9年間務めて得た結論です。ところが世間を見渡してみると残念ながら、情報システム部の地位というものはなかなか上がらない。そうじゃないぞ、と何とかして訴えたい。情報システム部から離れる今、そう思っています」。 ある製薬メーカーの情報システム部長はこう語った。この発言をした時、彼は9年間在籍した情報システム部を離れ、別な部の責任者になる内示を受けていた。彼はもともと、研究開発、営業、経営企画といった各部門を経て、情報システム部を担当した。部長として着任するまで、情報システムの仕事に関わったことは無かった。 情報システム部長を命じた社長は、「ITにガバナンスがかかっていない。予算や実績が外からはっきり分かるように透明化してほしい」とこの部長に指示したという。 情報システム部がブラックボックスになっていることが気になった経営者が、

    「情報システム部はもっとやれる」と訴えたい
  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
    dh_SPQR
    dh_SPQR 2011/07/02
  • 故・ゴールドラット博士の功績を振り返る

    TOC(制約条件の理論)の提唱者、エリヤフ・ゴールドラット博士が、6月11日にイスラエルの自宅で亡くなった。10年前に発刊された『ザ・ゴール ― 企業の究極の目的とは何か』(ダイヤモンド社)がきっかけでファンになった人は多いだろう。 ITproのコラムCIO登場では、これまで4人のCIO(最高情報責任者)が「お薦めの」として同氏の著作を挙げていた。全体最適の実現に悩むCIOにも多くのヒントを与えてきたことが分かる。 そこで、同氏の死を悼みつつ功績を振り返りたい。 導入事例 同氏の理論の応用として最初に知られた手法は、DBR(ドラム・バッファ・ロープ)と呼ばれる生産管理手法だろう。「生産工程の中で、制約が大きい(ボトルネックになっている)工程を特定し、その工程の稼働率が最大になるように生産計画を組み、かつ、その工程直前に部材の在庫置き場(バッファ)を作り、上流工程はバッファの減り方を見なが

    故・ゴールドラット博士の功績を振り返る
  • オラクルが考える「次世代IT基盤のあるべき姿」

    経営環境が大きく変化する中で、情報システムにも変革が求められている。最大の要件は、ビジネスやアプリケーションの変化に備えるプラットフォームの確立だ。ITベンダー各社はどんな基盤像を描いているのだろうか。オラクルが主張する基盤像を紹介する。 “変化対応力”が企業競争力を高める 景気の低迷、円高、新興国の台頭など、外部環境は依然として厳しい状況にある。加えて将来が不透明なことから、「企業競争力を維持、高めるための“変化対応力”をいかにして企業活動全体に備え付けるか」ということに、さらなる注目が集まっている。 変化対応力は、「外部環境の変化に応じて収益と費用のバランスを迅速に変更できること」だと言い換えられる。新たな事業機会を見出したら、競合他社に先駆けてその市場に参入し、新たな収益源を確保する。もしくは、市場環境の悪化によって引き起こされた収益の減少に応じて、それに要する費用を適正化し利益を維

    オラクルが考える「次世代IT基盤のあるべき姿」
  • ベンダー9社が外部設計のコツを集約

    神谷 慎吾 NTTデータ 技術開発部 ソフトウェア工学推進センタ シニアスペシャリスト 田中 久志 NTTデータ 技術開発部 ソフトウェア工学推進センタ シニアエキスパート 発注者ビューガイドラインは「外部設計」のノウハウ集である。外部設計とは要件定義の結果を基に、インタフェースを確定させることを指す。この工程でユーザーとシステムのインタフェースである画面や帳票に加えて、外部システムとの接続部分を決めていく。基設計や概要設計とも呼ぶ。 外部設計は失敗プロジェクトを防ぐ上で非常に重要になる。ここがユーザー(発注側)とベンダー(受注側)の間で仕様を合意できる最終段階となるからだ。ベンダーがユーザーに分かりにくい形で外部設計書を記述し、それをユーザーがきちんと確認せずに開発を進めた結果、プロジェクトに問題が発生する――。こんな例が少なくない。 ビジネスの要求を素早くシステムに反映することが

    ベンダー9社が外部設計のコツを集約
  • [仮想化フォーラム]クラウドのトレンドに2つの変化---日本オラクルの下道氏

    「ハードウエアの進化にともない、クラウドインフラのアーキテクチャにも変化が起こっている」---。2010年8月3日、東京都内で開催された「仮想化フォーラム2010 Summer」に日オラクル ソリューション統括部 プリンシパルセールスコンサルタントの下道高志氏が登壇。クラウドコンピューティングの課題と、トレンドの変化について講演した。 まず下道氏は、「Oracleは、クラウドの分野においては業務システムのSaaS(Software as a Services)プロバイダーとして知られているが、PaaS(Platform as a Services)の領域でも実績がある」と説明。米Amazon.comなどのパブリック・クラウド・ベンダーへ製品を提供した実績や、米HPや米Credit Suisseに対してプライベートクラウド構築のための製品を提供した事例を紹介した。 「クラウドのメリットを

    [仮想化フォーラム]クラウドのトレンドに2つの変化---日本オラクルの下道氏
  • ITアーキテクトの「やってはいけない」:ITpro

    ITアーキテクトが知っておくべきアンチパターンを徹底解説 情報システムのアーキテクチャや実装方式を決定するITアーキテクト。データベースやネットワーク,プラットフォームなど,さまざまな技術分野の知識を持ち,全体最適でシステム開発を成功に導かなければならない。しかしそこには,つい陥りがちな「やってはいけないこと」(アンチパターン)が,数多く潜んでいる。そこでここでは,ITアーキテクトが知っておくべきアンチパターンを解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル3~レベル1の3段階あり,レベルの数字が大きいほど,やってはいけない度合いも大きい。 関連サイト: ■機器増設編 ■業務分析編 ■Windows 7編 ■Android/iPhone編 ■プライベートクラウド編 ■パブリッククラウド編 ■次世代DB編 ■運用管理編 ■プラットフォーム編 ■セキュリティ

    ITアーキテクトの「やってはいけない」:ITpro
  • プライベートクラウドの作り方

    「クラウドコンピューティング」は、いつしか「パブリッククラウド」と「プライベートクラウド」という2種類の言葉が使い分けられるようになった。前者は一般に、「Google Apps」や「Amazon EC2/S3」「Windows Azure Platform」といった、誰もが使えるサービスを指す。 では、後者のプライベートクラウドとはいったい何か。企業内(またはグループ企業内)で構築して利用するシステム基盤と何が違うのか。仮想技術はプライベートクラウドに欠かせないものといえるが、「仮想技術=プライベートクラウド」というわけではないだろう。この連載では、プライベートクラウドとは何か、それはどのようにして構築するのかを明らかにしていく。 まずは、日IBMのクラウドコンピューティング事業においてCTOを務める山下克司氏の寄稿をお届けする。 プライベートクラウド 総論 (著者:日IBM 山下克司

    プライベートクラウドの作り方
  • 「ビジネスアナリスト」は日本で定着するか

    最近、BA(ビジネスアナリシスまたはビジネスアナリスト)やBABOKという言葉を目にする機会が多くなった。ビジネスアナリシスとは、ITなどのソリューションを導くための業務分析・要求分析のことで、それを行う人がビジネスアナリスト。ビジネスアナリストとして実施すべきことを体系的にまとめたのがBABOK(Business Analysis Body of Knowledge)だ。BABOKは、ビジネスアナリシスの普及活動を行っているカナダの非営利団体IIBA(International Institute of Business Analysis)が作成・出版している。 IIBAの日支部ができた2008年末ごろは「BA」という言葉も「BABOK」という言葉も、日ではほとんど知られていなかった。しかし、それから1年半が経過した今、これらの言葉は日でもすっかりポピュラーになった感がある。要求定

    「ビジネスアナリスト」は日本で定着するか
    dh_SPQR
    dh_SPQR 2010/06/30
  • [利用編]性能と費用の調節機能が際立つ

    仮想マシンを1時間0.085ドルからの従量課金で利用できるパブリッククラウドサービス「Amazon EC2」。機能と規模で他の追随を許さない最大手だ。特集では、そのサービス仕様と実際の処理性能を、全5回にわたり検証していく。第1回では、仮想マシンや仮想ストレージといった各種リソースの品揃えとその“売り方”を解説する。 最大で8コア/68.4GBメモリーの仮想マシンを用意 EC2では、仮想マシンと仮想ストレージをコンピューティングリソースとして用意している。最大の強みは、規模を生かした幅広いリソース群にある。 2006年8月のサービス開始当初は、仮想CPUコアが1、メモリーが1.7Gバイトの「Small」仕様のみだったが、2007年10月に「Large」と「Extra Large」の2スペックを追加。以降、CPU性能を重視した「High-CPU」シリーズ。メモリー容量を重視した「High-

    [利用編]性能と費用の調節機能が際立つ
  • プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...:ITpro

    プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに,あるいは軽視して,失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが,現場でプロマネがやってはいけないことを解説する。 関連サイト: ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画&進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘

    プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...:ITpro
    dh_SPQR
    dh_SPQR 2010/06/20
  • Part1 あなたは作成できますか?

    WBSを作成する際には,思い込みや楽観的な予測を排除し,抜け・漏れのないように作業を定義する必要がある。加えて,WBSで規定する作業内容は適切な粒度まで分解し,記載する表現は分かりやすく,そして目指すべきゴールにたどり着けるものでなければならない。WBSの作成は,未知のプロジェクトを“先読み”するということでもある。定石がないだけに,WBSの作成には特有の難しさがある。 実際,WBSの作成はどれくらい難しいのか。これを検証するために,Part1では雑誌「日経SYSTEMS」の読者4人の協力を得て2009年11月末,ある例題を解いてもらった(写真1)。みなさんもぜひ,WBSの作成に挑戦してほしい。 提案作業をWBSとして定義する ここで取り上げる例題は,提案作業に関するWBSを作成するものである(図1)。ある日,あなたのもとに提案依頼が舞い込んできた。内容は「プロジェクト・マネジメント(PM

    Part1 あなたは作成できますか?
    dh_SPQR
    dh_SPQR 2010/06/15