タグ

トラブルと開発に関するkei_0000のブックマーク (4)

  • みずほ銀行 再びシステムトラブル 藤原頭取が会見し謝罪 | NHKニュース

    ATM=現金自動預け払い機の障害などシステムのトラブルが相次いでいるみずほ銀行の藤原弘治頭取は、午後9時すぎから記者会見し、新たなシステムトラブルが発生し海外送金に遅れが出たことを明らかにしました。このトラブルで主に企業から依頼があった外貨建ての送金、およそ300件に遅れが出たということです。 トラブルは、システム関係の機械の故障で、11日午後11時39分に発生したということです。機械は、12日午前6時38分に復旧し、最終的な送金の処理は12日午後8時前に完了したとしています。このトラブルで、主に企業から依頼があった外貨建ての送金、およそ300件に遅れが出たということです。 藤原頭取は「先月28日のトラブルに加え、今月3日、7日と立て続けにトラブルが起きている。このような事態が続いていることを極めて重く受け止め、心から深くおわびします」と述べ、陳謝しました。 そのうえで藤原頭取は「経営責任

    みずほ銀行 再びシステムトラブル 藤原頭取が会見し謝罪 | NHKニュース
    kei_0000
    kei_0000 2021/03/13
    原因はいろいろあるだろうが、 https://xtech.nikkei.com/atcl/nxt/column/18/00867/071800018/ この4社分割発注が一番の原因では。システム開発におけるコミュニケーションコストとか、企業間の壁を軽視した様に思える。
  • システム過負荷でなぜATMにトラブルが? みずほ銀システム障害、運用面の課題あらわに

    2月28日に発生したみずほ銀行のシステム障害。同行の藤原弘治頭取は3月1日に記者会見を開き、システムの過負荷が原因だったとして謝罪した。この障害の影響で、同行が持つATM約5900台のうち4318台が一時取引できない状態に。ATMに挿入したまま戻ってこなくなった通帳やキャッシュカードは5244枚あったという。 障害の原因となったシステムの過負荷はなぜ起きたのか。そして、なぜATMにトラブルが波及したのか。藤原頭取は、「今回の障害は想定の甘さに起因するもの」と説明する。会見の質疑応答から、システム障害の全貌が垣間見えた。 データ更新と月末処理がバッティング みずほ銀は27日、1年以上動いていない定期預金口座のステータスを「不稼働」に変更するデータ更新作業を行っていた。処理したデータは45万件。この作業を行うにはシステムに十分なデータの空き容量が必要だという。 同行は事前のテスト環境でシステム

    システム過負荷でなぜATMにトラブルが? みずほ銀システム障害、運用面の課題あらわに
    kei_0000
    kei_0000 2021/03/02
    リニューアルして、こんな早くから負荷に起因する問題か。スケールアウト出来ないシステム設計なら、この先もやばいのでは。運用でやりくりするのも限界があるし、現場はストレスで疲弊しそう。
  • プロジェクトマネージャーは神経質であれ 大学教授が教えるプロジェクトに重要なリスクマネジメント

    年に一度のプロジェクトマネジメントに関するイベント「Backlog World 2020 re:Union」。今回「プロジェクトリスク&クライシスマネジメント」のテーマで登壇するのは、数多くのシステム開発の現場でプロジェクトマネジャーに従事し、現在は広島修道大学で教壇に立つ佐藤達男氏。後半は佐藤氏の今までの経験から培ったリスクの危機管理方法やトラブルの対処方法、またマネジメント全体から現場レベルの関わり方について話します。 リスクの底を知る 私は、プロジェクトマネージャーは現場で現状を知るべきだと思っています。 ここから実際の経験の話を少ししていきたいんですが。私がシステム開発のプロジェクトマネージャーをやっていたときに開発の仕事がたくさんある。しかし、依頼を引き受けてくれるソフト開発の会社が見つかりませんでした。 そんなときに「100台のパソコンと100人のエンジニアがいて、御社の仕事

    プロジェクトマネージャーは神経質であれ 大学教授が教えるプロジェクトに重要なリスクマネジメント
    kei_0000
    kei_0000 2020/09/01
    「「リスクマネジメントは重要なので、十分に洗い出しました」と言う人がいたら、私は基本的には信用しません」これは同意。ただ信用してないことが態度に出ない様に注意。内容を調べて後で具体的かつスマイルで指摘
  • パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ

    連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。今回は「要件の範囲がい違ったことにより生じた紛争」を解説する。 ユーザーが望む機能がシステム開発の要件から抜け落ちたがために発生する紛争は、連載でこれまでにも何度か取り上げてきた。 IT紛争の類型は種々さまざまであり、過去の判例が全てそのまま適用できるわけではないが、裁判所が「たとえ要件としてユーザーから明示されていなくても、その機能が契約の目的を果たす上で、当然に必要な事柄であるとベンダーが認識し得る状態にあれば、ベンダーにはその機能を作り込む義務(債務)がある」と判断した例が幾つもある。 要件定義書よりも契約の目的の方が重いとする考え方だ。 今回取り上げる判例も、「ユーザーが必要と考える機能が、ベンダーの作成した要件定義書から抜け落ちており、これを作り込まなかった」というものだ。これまでと少し異なるのは、パ

    パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ
    kei_0000
    kei_0000 2019/05/08
    これありがち。知識不足の担当者が、ベンダーの営業からパッケージの良い点だけ吹聴されたのでは。パッケージのデメリットも含めきちんと説明されたなら、現行と同じもの作れなんていう要求はしないはず。
  • 1