「マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。
プロジェクト・マネジメント・システムは存在しうるか | タイム・コンサルタントの日誌から
「マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。
10月1日に株式売買システムで発生した障害について | 日本取引所グループ
平素は、東京証券取引所の市場運営に格別のご高配を賜り厚く御礼を申し上げます。 2020年10月1日に株式売買システム「arrowhead」で発生した障害により、投資家の方々をはじめ、多くの市場関係者の皆様に御迷惑をお掛けしましたことを深くお詫び申し上げます。 今回発生した事象に関し、経緯、原因及び再発防止措置等について公表を行いました。 また、今般、当社では、再発防止に向けたシステム障害対応やルール整備の在り方についての検討を行うため、「再発防止策検討協議会」を設置することとしました。 詳細につきましては、添付資料をご参照ください。
みずほ銀行の新システムがIBM×COBOLで昭和っぽさあるとおもったら逆で、みずほだけが「脱・昭和」できてたのか - in between days
日経 xTECH（クロステック）で「35万人月、みずほ銀行システム統合の謎」というシリーズ記事が公開されている。 tech.nikkeibp.co.jp 出典は「日経コンピュータ」誌の2019年9月5日号で、32ページにわたる特集を全19本の記事で構成している。 みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃 | 日経 xTECH（クロステック） 有料会員向けの記事ということもあるんだろうけれど、上記のような一部記事だけが微妙なかんじでバズっていて、その記事を読むと、まあこういう感想になる。 みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃 | 日経 xTECH（クロステック） 今年って昭和何年だっけ？ “基盤とアプリ開発のベンダーが異なることで特有の難しさも生じた。富士通はIBMの基盤上で動作するCOBOLプログラムを開発しなければならなかった”2019/09/10
横浜市「ＲＰＡの有効性検証の成果について」を読んで、仕事とは何かを思い知らされる - orangeitems’s diary
もう他人事ではいられないRPAの絶大なる効果 昨日のエントリー、富士通の早期退職／ジョブ再配置に関する記事の反響はとても大きく、社会全体で仕事とは何かを見つめなおす契機ともなりそうだと思いました。 一方で、もう一つ気になるニュースを見かけました。 it.impressbm.co.jp 横浜市、NTT、NTTデータ、クニエのは2019年3月18日、RPA（ロボットによる業務自動化）の有効性を検証する共同実験の結果報告書を公表した。報告によると、RPAを試験導入した事務で、平均84.9％、最大99.1％の作業時間削減効果を確認した。横浜市は、共同実験の成果を踏まえ、RPAの本格導入に向けて引き続き検証を進める。 99.1%が削減ということは、その仕事って「まぼろし」だったのではないかと思うほどです。その業務を定常的に実施していた職員は確実にいるわけで、「RPAによる人減らし」は、破壊的な威力を
三菱UFJニコスのシステム障害の原因が判明、3個のHDDが同時に故障
マスターデータから中間加工ファイルを作成するバッチ処理のシステムでHDDが故障し、障害が発生した。三菱UFJニコスによれば、HDD15個で一連の機能を果たしており、そのうち3個が同時に故障した。「2個までの同時障害は自動復旧可能な仕組みを設けていたが、3個の故障は想定外だった」（広報）。同社はシステムやHDDの開発企業を明らかにしていないものの、「発生確率は極めて低いとの報告を受けている」という。 故障したHDDは、障害が発生した2017年12月26日中に交換したが、利用会員の売上データ処理などに遅れが発生した。一部の利用会員に2重請求が発生したほか、請求が遅れるなどの事態につながった。同社はシステム機器の監視体制を強化するなどして対策を講じるという。
仕事へのスタンスの差
チーム内でAさんとBさんの仲が悪い。 二人の仕事に対するスタンスが違うので揉めるのだ。 AさんとBさんは同じ仕事を半分こしてやる、という立場。 一つ例に取って説明する。 仕事内容は伝票入力。 伝票には項目が5つあり、 システム画面に入力されてる項目と紙に書いてある項目が同じであることを確認したら、 システム上で承認ボタンを押し、 紙にはシャチハタ印を押しておわり。 こんな作業がひとり一日100枚くらいある。 とにかく眠くなるらしく二人共睡魔に耐えながら仕事をしている。 紙とシステムの差異はほとんど出ないのだけど、たまに発生する。割合としては5%くらいだ。 問題はAさんとBさんの作業クオリティが違うことだ。 Aさんはとても几帳面な人で、5つの項目すべてを一文字一文字確認している。 なので不備発見率も高く、そのための修正に時間を取られ、結果残業時間がBさんより1時間くらい長い。 Bさんはわりと
Amazon.co.jp：システム障害はなぜ二度起きたか みずほ、12年の教訓の TOSHI!!さんのレビュー
この1度目のシステム障害を、対応ベンダのうちの1社として見ていた者です。 確かに、ここまで掘り下げるのは大変だったでしょう。しかしながら、例えば、実務レベルの暗闘や困惑は 不十分というか、日経という立ち位置からか書かれていません。 私自身は別プロジェクトに居ましたが、ATM系の開発を社（当時）が請け負っており、そのマネージャーが 懇意の同僚でした。彼は、オブザーバとしてながら、実際の実務レベルミーティングに参加していたのです。 真の原因は、統合するシステムそのものの設計書・仕様書レベルで、負け組（＝新システム開発に乗れな かったカイシャ）が、意図的なイヤガラセで、「現状」の仕様や設計を開示しなかったことにあります。 システムというのは、使えば必ず手直し（所謂、バグだけでなく、法律改正に対応する修正もあります）が 多々発生します。都度、「その場しのぎのパッチ当て」から「キチンと予算を組んだ修
システムを作るとはどういう事なのか？ ～人の感性は十人十色～ - plumauto892のブログ
【見積りの根拠出してくれっていったら、金くれって言われたよ】 http://anond.hatelabo.jp/20131003212934 『システム屋の常識ってものが分からないのですが・・。』 と言うことなので、作る側（あくまで作る側視点です）から解説。（反論はあろうけど、まあ、人の話は最後まで聞いてね） 以下、ベンダーって書いてるのはソフトを開発する会社と言う意味で使ってます。 実際の中身が分からんので、一概には言えないけど、 １）何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万～2200万。 まずこの時点で分かるのが、あなたの出した要求内容がシステム屋からすると曖昧で、作る範囲（機能）が確定できないってことです。 通常、作る範囲が明確なら、価格差ってのは大よそ±２０％～３０％の範囲。 但し、ＮＴＴデータとかの名のあるベンダーに頼
見積りの根拠出してくれっていったら、金くれって言われたよ
システム屋の常識ってものが分からないのですが・・。 社内の業務をいくつかIT化することになった。ACCESSとかでも頑張ればできそうな感じだったんだけれど、システム屋にやらす方向で進めることになった。 何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万～2200万。こんな簡単なシステムなのになんでこんなに金がかかるのか・・。なんでこんな差があるのか・・。（この時点でシステム屋業界に対しての不信感が社内に生まれることになった。）結局、一番低い金額で出してきたところが、営業の印象もなかなかよく、そこに決めることになった。 その後、細かい金額出させるために何度か呼んで、必要なことを事細かく伝えて詳細見積りとスケジュール表を出せっていった。それで出てきたのが、A3の紙１枚で4項目ぐらいのざっくり見積りと、設計期間・製造期間・動作確認期間っていう期
55億円無駄に、特許庁の失敗
政府システム調達における失敗の典型例が、特許庁の基幹系システム刷新プロジェクトだ。5年がかりで臨んだが、結局は55億円を無駄にしただけ。新システムは完成しなかった。失敗の最大の要因は、発注者である特許庁にあった（図1）。関係者の証言から、失敗に至る経過を改めてひもとく。 特許庁は2004年、政府が打ち出した「業務・システム最適化計画」に沿って、特許審査や原本保管といった業務を支援する基幹系システムの全面刷新を計画した。システムアーキテクチャーに詳しい情報システム部門のある職員（以下A職員）と、刷新の「可能性調査」を担ったIBMビジネスコンサルティングサービス（現・日本IBM）を中心に、調達仕様書を作成した。 業務プロセスを大幅に見直し、2年かかっていた特許審査を半分の1年で完了することを目指した。度重なる改修によって複雑に入り組んだ記録原本データベース（DB）の一元化に加え、検索や格納など
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance
もう何周目になるのでしょうか。｢情報システム部門が経営に貢献できていない｣というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」：ITpro なんか色々ダメだしされていますが、重要なポイントは１つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば１つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく
忘れたパスワードを問い合わせられるシステムなんて作っちゃいけない | 初代編集長ブログ―安田英久
今日は、ちょっとしたシステム構築を発注するときに重要なポイントとなる、顧客情報管理の話題を。テーマは「お客さんのパスワードをどう保存するか」です。 御社には、たとえばECサイトの会員や顧客向けSNSなどの、お客さんがユーザー登録をしてパスワードでログインするようなシステムがありますか？ あるとしたら、そのシステム内で、お客さんそれぞれのパスワードはどんな風に管理されているか把握していますか？ または、システム構築の発注時に、どんな風にパスワードを管理するような仕様にしましたか？ クレジットカード情報や個人情報の管理には注意していても、パスワードの保存方法は、あまり気にしていないのではないでしょうか。しかし、それではまずいのです。システム構築時に正しい仕様で発注しないと、何かセキュリティ問題が発生したときに、思いがけぬ大きな範囲に影響する問題になってしまいかねないのです。 結論からいうと、お
ヤマト運輸の対応が素晴らしかった
クロネコヤマトモバイルサイトで情報流出があり読売新聞で取り上げたられた件に関し、早速ヤマト運輸で対応が取られ、発表がありました。 携帯版「クロネコメンバーズのWebサービス」クイックログイン機能の脆弱性への対応について｜ヤマト運輸 この対応の素晴らしさは、タイトルでわかります。「脆弱性への対応」と書かれていて、ヤマト運輸のシステム側に不具合があったことを自ら認めて発表しています。 自らのミスを被害者に見せかける「プロの脆弱性対策」を使うのであれば、ここは「スマートフォンのアプリを利用したなりすましによる不正ログインについて」などと発表してもおかしくありません。 今回の件は読売新聞でも「ｉＰｈｏｎｅで人の情報丸見え…閲覧ソフト原因」と報道されているわけで、閲覧ソフトに責任転嫁するのは簡単な状況でした。それでもヤマト運輸は自らシステムの「脆弱性」だと認め、どういう状況で発生したのかまで発表しま
岡崎市中央図書館 #librahack 事件を取材した朝日新聞記者さんへの質問と回答まとめ (8月21日分)
神田 大介 @kanda_daisuke みなさま、おはようございます。記事を書きました朝日新聞の神田と申します。今回の件では、ツイッターやブログなどネット上の情報をたくさん参考にさせていただきました。まずはお礼を申し上げます。 #librahack 2010-08-21 08:50:36 神田 大介 @kanda_daisuke この件では、およそ２か月間にわたって取材を続けてきました（毎日この問題だけに専従していたわけではありませんが）。記事に書かれていることはほんのエッセンスに過ぎず、また広範囲な新聞読者を想定しているため、いろいろと表現を「丸めて」あります。 #librahack 2010-08-21 08:53:14
自動車保険会社の業務マニュアルのバグ。事故が起きてから保険に入れるというおかしな仕組み！ - 2010-10-05 - 登 大遊＠筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記
今日は、先日の、空港の税関での出来事 に続き、似たような話ですが、もっと私たちに身近な例として、「自動車保険の保険料を、事故が起きた場合だけ支払い、事故が起きなかった場合は支払わない (返金してもらえる)」という状態になっていたという、とんでもない自動車保険会社の内部業務フローを発見し、指摘したことについて、記述します。 ちなみに、零細の保険会社の話ではありません。超有名な大手の損保会社の話です。 大手損保会社との電話でのやりとりで発覚した面白い事実 今日は、最近、ある自動車保険会社と話をした際に、その自動車保険会社が内部的に運用している業務マニュアルにどうやらとんでもない事が書いてあったという件について、以下に書きたいと思う。どこの自動車保険会社かということは明記しないことにする。なぜならば、指摘したことによって、業務マニュアルをその後直したらしく、もう実害はなさそうだからである。相手は
システムが無くなった日
自分のブログに書こうとも思ったのですが、会社が特定されてしまいそうなのでここに書きます。どこかに書かなければならないと思ったのは、この事実を誰かに伝えなければならないと思ったからです。 私が勤めていた会社はシステム屋さんです。2タイプの職場があって、一つはお客に注文を受けてシステムを開発してリリースして終了。もう一つはお客の会社に居候させてもらってシステムの維持管理をするというものです。私は後者のほうです。 お客は工場も複数構える結構大きな企業で、様々なプラスチック製品やコンピューター部品を作るところであります。日本だけじゃなくて海外とも取引があったと思います。 1. コンピュターシステムの入れ替えを要求されるこの不況のなか、様々な設備投資の資金を抑える事を進めていた中で、システムについても、もっとコストの安いものをと以前より私の会社の上役達と試行錯誤を繰り返してきたのですが、そもそものお
suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダークネスDUA