神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力２階建決算発表が出ないことを怪しんでストップ高まで買われたエックスネット、TOBされるどころか逆に資本提携解消で切られて過剰にお金が流出するお笑い劇場に
みずほ銀のシステム統合、１年遅れる見通し 開発に手間：朝日新聞デジタル
みずほ銀行が２０１６年春をめどに計画していたシステム統合が、１年程度遅れる見通しとなったことが２７日わかった。みずほグループは、１１年３月の東日本大震災後のシステム障害を機にグループ銀行を再編し、古いシステムの刷新を進めてきたが、開発に手間がかかっているためだ。 新システムが障害を起こすことがないよう慎重に開発を進めた結果、想定以上に時間がかかっているという。開発費は２５００億～３千億円と見込んでいたが、数百億円規模でふくらむ可能性がある。富士通など大手電機メーカーなどが開発している。 みずほはシステム統合で事務を効率化し、新たな金融サービスを展開する計画を立てていた。こうした計画も修正を余儀なくされ、収益に影響が出かねない。
スマホUI考（番外編） UIやUXを劇的に改善する、『ビッグオー駆動型開発』とは | fladdict
いま『ビッグオー駆動型開発』とよばれる開発手法が、業界の一部で注目を集めている。 その理由は非常にシンプルだ。『ビッグオー』は非常に安価で簡単な手法でありながら、従来の開発手法に比べ劇的にUIやUXを改善できるためである。 製品コンセプトのような上流から、ボタンのレイアウトといった下流工程、さらにはグロースハックやプロモといったリリース後のフェイズまで一つの手法でユーザビリティを評価できる。この汎用性がビッグオー駆動開発の大きな特徴であり、導入時の利点となる。 今回はこのビッグオー、の概要と具体的なやり方について論じたい。TwitterのUI拡張予言以来、久しぶりのUI系エントリである。 ビッグオー駆動開発とは何か？ ビッグオー駆動開発は、正式には『OKAN Driven Development（オカン駆動型開発）』とよばれる開発手法である。 これは自分のオカンを指標とすることで、低コスト
エクセルでできることができない何百万のシステム・・
うちの部署に入れる新しい業務システムの構築の担当になって、昨日から打合せが始まった。今までエクセルで管理してたものが多くて結構表組みで管理したいものがたくさんあったから、そういう要望を業者に伝えたら「いや～、、ハハハ・・（だったら今まで通りエクセルでやれば？）」みたいな反応。例えばフィルターとか超使ってるし、タブをドンドン増やしてハイパーリンクでつないで元データから引っ張ってきて計算して表組みを作成するとかいつもやってるような作業が新システムだと厳しい（＝できないor莫大な時間と金がかかる）らしい・・。帳票は固定になりますね、帳票増やすと増やした分だけ金かかります、みたいな感じ。いちばんビビったのがコピーペーストができないって言われたこと。列ごとコピーしてデータ貼り付けて表作るっていう単純なことが、何百万だか払って作るシステムではできないとか・・。（CSVで保存してアップロードしてください
「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏（前編）
日本でも選挙活動にインターネットを利用するという議論が始まっていますが、世界でもっとも大規模にインターネットを利用して選挙活動が行われたのが、昨年の米大統領選挙です。 その選挙戦を勝ち抜いたオバマ大統領のチーム「Obama for America」が、どのような選挙キャンペーンシステムを構築したのか。3月15日に都内で行われたAmazonクラウドのイベント「JAWS DAYS 2013」で、語られました。 そこでは、過去の選挙データやソーシャルメディアなどを元に有権者の動向を徹底的に分析し、テレビCMの打ち方からボランティアの働き方まであらゆるものを最適化する大規模なシステムをいかに構築したのか。そして、大規模システムでクラウドを活用するとはどういうことか、ということを学ぶ絶好のサンプルになっています。 国内でこのシステムの舞台裏がこれほど詳しく紹介されることは初めてのはずです。講演の内容
オバマケアのサイト不具合はなぜ起こった？ 現場の泥沼：Behind the HealthCare.gov Disaster
オバマケアのサイト不具合はなぜ起こった？ 現場の泥沼：Behind the HealthCare.gov Disaster When we spend $630 million, this is what happens. 6億3000万ドル（630億円）を投じた国家プロジェクトは、なぜ見切り発車したのか？ 米医療保険改革（オバマケア）の柱のオンライン保険購入システム「HealthCare.gov」が10月1日オープンするなり盛大にクラッシュした件で、NYタイムズが舞台裏の話を書いた。 関係者は政府も企業も全員、守秘義務があるので、これまでこういう話はなかなか出てこなかったけど、たぶんCGIはこれで切られるのかな…企業側の話もかなり入ってるよ。要点を拾っておこう。 壮大な構想を語る政府 vs. 目の前の現実を語る請負業者 システム開発を請け負ったCGIフェデラルはじめ各社は8月の段階で、「
システムを作るとはどういう事なのか？ ～人の感性は十人十色～ - plumauto892のブログ
【見積りの根拠出してくれっていったら、金くれって言われたよ】 http://anond.hatelabo.jp/20131003212934 『システム屋の常識ってものが分からないのですが・・。』 と言うことなので、作る側（あくまで作る側視点です）から解説。（反論はあろうけど、まあ、人の話は最後まで聞いてね） 以下、ベンダーって書いてるのはソフトを開発する会社と言う意味で使ってます。 実際の中身が分からんので、一概には言えないけど、 １）何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万～2200万。 まずこの時点で分かるのが、あなたの出した要求内容がシステム屋からすると曖昧で、作る範囲（機能）が確定できないってことです。 通常、作る範囲が明確なら、価格差ってのは大よそ±２０％～３０％の範囲。 但し、ＮＴＴデータとかの名のあるベンダーに頼
見積もりと設計の間の高い高い壁 - novtan別館
この元増田は他の業界のものも含めて設計をお願いしたことって多分無いと思うんだよ。 家の場合だったら、普通は設計図と各パーツの詳細見積りで初めて契約だろうが。 見積りの根拠出してくれっていったら、金くれって言われたよ その設計図は増田が事細かに出した要望を元に一から作ったものなの？って話。 つまり、出来合いのものを適当に組み合わせたものには設計料は掛からないし、そうじゃないものには設計料が掛かるってだけの話ですね。 当然だけど、システムの設計もただではない。大まかな流れを示すと以下な感じ。ちょっと適当。 ・発注元に（ちゃんとした）システム部がある場合 要求仕様を作成し、それに基づいた提案をシステム会社に依頼する。この時点で要件がある程度はっきりしている場合、概要設計を元にした詳細見積もりが可能。出来合いのものを流用できるような要件であれば精度は高く、そうでなければ概算部分が生じる（要件定義フ
見積りの根拠出してくれっていったら、金くれって言われたよ
システム屋の常識ってものが分からないのですが・・。 社内の業務をいくつかIT化することになった。ACCESSとかでも頑張ればできそうな感じだったんだけれど、システム屋にやらす方向で進めることになった。 何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万～2200万。こんな簡単なシステムなのになんでこんなに金がかかるのか・・。なんでこんな差があるのか・・。（この時点でシステム屋業界に対しての不信感が社内に生まれることになった。）結局、一番低い金額で出してきたところが、営業の印象もなかなかよく、そこに決めることになった。 その後、細かい金額出させるために何度か呼んで、必要なことを事細かく伝えて詳細見積りとスケジュール表を出せっていった。それで出てきたのが、A3の紙１枚で4項目ぐらいのざっくり見積りと、設計期間・製造期間・動作確認期間っていう期
恐怖！ヒヤリハット事例ビデオを正視できないSEが続出 - さまざまなめりっと
客先のファイルシステムをバックアップなしで消し飛ばした事あるけど、 特にトラウマになってないな。 多分、最初の時点で「終わった」って気分になったからだと思う。 人間、助かるかどうかの瀬戸際にいる時が一番精神が削れる。 もうどうやったって助かりようがない、という状況に置かれたら、特に迷ったり気を揉んだりする事もない。 （残業しないで済むかどうか、休日出勤しないで済むかどうか、という瀬戸際が一番疲れるのに似てる。 「しないで済むわけがない」という状況なら、定時は気にならない）
二階俊博氏と特許庁新システム断念の因果 - 木走日記
５日付けの毎日新聞記事から。 特許庁:新システム断念 支出５０億円、計画作り直し 東芝子会社に返還請求へ 毎日新聞 2013年01月05日 東京夕刊 http://mainichi.jp/select/news/20130105dde001010008000c.html 特許庁が６年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めました。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定します。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものでありました。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指します。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションを含め、入札には計３社が参
みずほ、復活への再挑戦 - 1年かけてシステムを総点検：ITpro
システム全面刷新・統合をなんとしても成功させ、信頼回復に努めたい──。2度の大規模システム障害を引き起こしたみずほフィナンシャルグループのシステム関係者が、重い口を開き始めた。みずほがシステム関連の個別取材に応じるのは、2011年3月のトラブル以後、初めてのことだ。 みずほは1年間がかりで再発防止策を講じ、現在は大手銀初となる勘定系システムの全面刷新・統合を進める。 大規模障害の再発は本当に防げるのか。世界最大規模となることが確実な刷新・統合プロジェクトを、やり抜けるのか。そして長年の課題である、ITガバナンスを強化できるのか。みずほ復活に向けた再挑戦を追う（関連記事：［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注）。 分担の誤謬――。2011年3月の大規模システム障害でみずほ銀行（BK）が陥ったのは、勘定系という巨大システムを維持する上で避けて通れない、人や組織の役割分
IT業界の裏話: プログラマのセリフをジブリっぽく言ってみた「ウソじゃないもん！本当にさっきまで動いていたんだもん！」
名前： 吉澤準特 職業： ＩＴコンサルタント 連絡： メルマガに記載 自己紹介のコメント： 自己紹介の詳細はコチラ→■ 外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。 Twitterやっています。 →http://twitter.com/juntoku_y マイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。 →コンサル直伝－IT業界”裏”講座 EnterpriseZine（翔泳社）で記事掲載中です。そちらもヨロシクお願い致します。 →ファシリテーションで会議を変える/ITIL解体新書/デキるシステム担当者のスキルノート 2010年7月末、日本能率協会マネジメントセンター（JMAM）より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空
ついっぷる
ついっぷる - サービスは終了しました。 「ついっぷる」は 2017年10月31日 をもちましてサービス提供を終了いたしました。 2009年12月のサービス開始より8年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。 「ついっぷるフォト」サービスおよび画像一括ダウンロードは 2017年11月30日 13:00 を以って終了いたしました。 「ついっぷるトレンド」サービスは 2021年8月31日 12:00 を以って終了いたしました。 長らく「ついっぷる」をご愛用頂きまして誠にありがとうございました。 今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 BIGLOBEのサービス一覧
僕の知ってる「特許庁」の話 | おごちゃんの雑文
私の見聞きした話の断片を憶測でつないだことなんで、話半分で読んで欲しい。ただ、個々の事実として語っている部分は事実だ。 また、スキャンダル的な部分を除けば、いろんなプロジェクトに共通することなので、一つの「寓話」として読んでもらうといいかも知れない。 特許庁のプロジェクトがコケたって話はあちこちで語られ、いい話のネタになっているようなんだけど、私が知っている範囲では、そういった綺麗な失敗ではない。 くどいようだが、話の断片を憶測でつないだことだから、その辺は用心して読むように。実はfacebookにちょろっと書いたんだけど、もうちょっと整理して書いておく。 「特許庁」のプロジェクトは、実は始まった時くらいに誘われていた。そういった話を持って来た人がいたからだ。あれだけの大プロジェクトに「その人」がなんで関わっていたかは知らない。まぁ当時は「その人」はそれなりに信用していた部分もあったので、
特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩本氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩本氏の提案についても掲載したいと思います。 以下からは萩本氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記（注：記事の元になったFacebookへの書き込み）を書いたのは、二度とこのような案件が出ないよう本質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 本質的問題を提起したつもりですが、しかし本当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
ブルックスの法則 - Wikipedia
ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。 根拠[編集] ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた
