みずほ銀行の新システムが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
「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい - プログラマの思索
倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。 新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。 以下はラフなメモ書き。 【研修資料】 【参考】 アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索 アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change! ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change! アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change! ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは
COBOL「私を殺すと言ってた言語は、みんな死んだよ」 | おごちゃんの雑文
ITPro方面に火種があったので。 COBOLやVB6との決別、初手は不良資産の一掃 中を読めばいつもに日経コンピュータなんだが… 例によって、日経コンピュータがCOBOLを悪者にしている。まぁ、いつものことなんで、それ自体は割とどうでもいいんだが、見出し詐欺はいけない。何がそうかと言えば、後半の「かんぽ生命」の話。 1200億円の巨費を投じて基幹系システムをNEC製メインフレームから米IBM機に移行し、2017年1月に稼働させたかんぽ生命保険も、ツールで全体の1割に相当する不要資産を廃棄した。NECの独自言語「IDLII」からCOBOLにツールでリライトした。 見出しに「COBOLやVB6との決別」とか言いながら、よく見れば COBOLにした という話だ。見出しと違う話なんで「あれれ？」と思ってTwitterで聞いたりもしたんだが、 かんぽ生命副社長・井戸潔が語る基幹系システム刷新、成功
市教委「今年から通知表を電子化します…が、お金はかけられないのでExcelです。」「あ、これ絶対しわ寄せが現場にくるタイプだ…」 - パパ教員の戯れ言日記
通知表の時期来たる 今年も1学期が終わろうとしています。そろそろ通知表の時期になってまいりました。 通知表といえば、法律には何も定まっていないのに何故か学校側が出している書類として、仕事負担の増加への寄与度が圧倒的に高いラスボス的な存在でございます。 40人学級だった時にはマジで死ぬかと思いました。今でも、1週間近くは朝3時起きで仕事しないと間に合わない。その時ばかりは娯楽を断ちます。 手書きの通知表は時間がかかる。 今の学校は手書きでやれという指示だったので、全部手書きです。 文章だけで、 総合的な学習の時間の所見 特別活動（係やクラブ、委員会）の所見 外国語活動の所見 総合所見 の4種類がありました。一人につき4種類です。それぞれは50文字程度から200文字程度ですが、一人につき原稿用紙2枚分ほどの分量を書くというのはなかなか骨が折れます。特に外国語活動。「AETの発音をよく聞き、大き
みずほ銀、システム統合再延期 動作テスト延長 運用18年以降 - 日本経済新聞
みずほ銀行は2016年12月に予定していた新たな勘定系システムの完成時期を遅らせる検討に入った。システムの一部で実施中の動作確認テストを延長する必要があると判断した。遅らせれば2度目の延期となり、新システムの運用開始は18年夏以降になるとみられる。みずほは過去に2回の大規模なシステム障害を起こしており、今回も万全を期すことにした。勘定系システムは、口座の入出金や資金決済、口座管理などを担うシス
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
「DB」「要件定義」が通じない？ 顧客の知識レベルを探る
「DB」「要件定義」が通じない？ 顧客の知識レベルを探る：ITエンジニアの市場価値を高める「営業力」（8）（1/2 ページ） 「相手の役に立つことを言う」「相手の知らなかったことを言う」「相手の好奇心を満たすことを言う」からなる三大発信方針は、心掛けるだけで、顧客のあなたに対する印象が良くなる（つまり、市場価値の向上につながる）というものです。 当たり前のことのように思えますが、これらを意識して心掛けているという人は、私の知る限りほとんどいません。なので、心掛けるだけでも差別化につながります。 では、どうすれば心掛けていることが相手に伝わるのでしょうか？ 適切な質問ができればいいのです。適切な質問ができない限り、相手の役に立つことが何なのか、相手が知らないことが何なのか、相手が興味を持っていることが何なのかは、一つとして分かりません。 三大発信方針を心掛けている人は、まず「この人は心掛けて
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
SEが苦手にしがちなドキュメント力を強化する5つの視点
SEに最も必要なスキルは「伝える力」だと言われています。分業が前提となるシステム開発において、意志の伝達がうまく出来ないことは致命的だからです。 よって、作成するドキュメントにも正しく伝える技術が求められるのですが、しかし多くのSEはドキュメント作成を苦手としているようです。 そこで今日は、SEがドキュメント作成で失敗しがちなポイントと、ドキュメント力を強化するための5つの視点について、『エンジニアのための文章術再入門講座』からご紹介します。 1.SEがドキュメント作成で失敗しがちなポイント SEがドキュメント作成に失敗しがちなポイントは、主に以下の2つです。 相手の関心と不一致 知識差のための説明が不足 例えば、システム開発プロジェクトの部長向けの進捗報告の場面を思い浮かべてください。性格にもよりますが、一般に部長クラスの方が気にするのは「予算を超過しないか」「顧客との関係は良好か」「今
「スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令」 - カレーなる辛口Javaな加齢日記
http://itpro.nikkeibp.co.jp/article/NEWS/20120329/388219/ http://itpro.nikkeibp.co.jp/article/COLUMN/20110804/363621/ http://itpro.nikkeibp.co.jp/article/COLUMN/20120330/388310/ http://slashdot.jp/story/12/03/30/1830220/ http://togetter.com/li/280424 メモ 発言を見る限りは有りがちなデスマーチ． 勘定系システムの開発失敗を巡り、スルガ銀行が日本IBMに115億8000万円の支払いを求めた裁判で、東京地方裁判所は2012年3月29日、日本IBMに74億1366万6128円の支払いを命じる判決を言い渡した。 スルガ銀行は2000年代初頭に勘定系シス
「改変を強要された」、スルガ銀－IBM裁判で日本IBM副会長
「議事録や提出資料の内容を、スルガ銀行にとって都合がいいように変更するよう求められた。『日本IBMが悪かった』という表現を議事録などに織り込むようにも迫られた」。日本IBMの金田治副会長は3月4日午後2時40分、東京地裁の411号法廷で証人尋問に臨み、こう主張した。 この証人尋問は、スルガ銀行がシステム開発の失敗で被った損失など111億600万円の支払いを日本IBMに求めた裁判についてのもの（表）。2008年3月にスルガ銀行が日本IBMを提訴してからちょうど2年。裁判は非公開での弁論準備手続が続いていたが、この2月から3月にかけて、3回の証人尋問が公開形式で行われた。 日本IBMからはプロジェクト当事全社の営業責任者を務めていた金田副会長、スルガ銀行からは乾精治常勤監査役のほか、両社の開発現場における責任者を務めていたメンバーが出廷した。 今回の証人尋問で注目されるのは、現役の日本IBM幹
年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う- 日経コンピュータReport：ITpro
次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省は「年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した（図）。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット（現TIS）が、契約を履行できなかった。 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」（厚労省年金局）。一方、システム基盤設計の進行は遅れた
特許庁の基幹システムはなぜ失敗したのか。元内閣官房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億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
テスト／品質系エンジニアが身に付けておくと得をする7つの技術 - 現場のためのソフトウェア開発プロセス - たかのり日記
「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます！ テスト／品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。 プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。 ※注 今回記述した内容は、以下のような私のドメインに偏ったモノになっています。 ミッションクリティカル／エンタープライズ系 Java／.NET 他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。 バージョン管理／課題管理 今や、必須のスキルと言えるでしょう。 バージョン管理（SCM／VCS／DVCS）としては、 集中型のSubversion（SVN） 分散型のGit／Mercurial などが有名ですね。 分散型の場合は、各エ
開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう
日本のオープンソース会の重鎮（そして自称プロのよっぱらいでもある）楽天技術理事のよしおかひろたか氏が、はてなダイアリーの未来のいつか/hyoshiokの日記で「IT産業には民族誌が必要だ」というエントリを書いています。このエントリにはとても共感するところがあります。 よしおか氏は以前から、ハッカー中心の企業文化を日本に根付かせたいという意志をもってさまざまな活動をされていて、今回の「IT産業には民族誌が必要だ」という意見もそれを実現する要素の1つです。 ではなぜ民族誌が必要だとよしおか氏が書いているのか、本題に入る前に、よしおか氏が言う「民族誌」とは何なのかを、今年の2月にデベロッパーサミット、通称デブサミでよしおか氏が行った講演「ハッカー中心の企業文化を日本で根付かせる」のスライドから少し読み解いていきましょう。 ハッカー中心の企業文化を根付かせるために この講演でよしおか氏は「良いソフ
障害対応の工数は謎だらけ - rabbit2goのブログ
開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調査に難航し、さらに修正確認にも手間取るものが珍しくなかったりする。 何故そんなに時間がかかってしまうのだろうかと思って改めて考えてみたところ、対応に時間を要するものはこんな特徴を持っているようだ。 障害レポートに記載されている再現手順に従っても問題が再現しない。記載されていない情報に相違があるらしいので、レポートの報告者に詳細を問い合わせをする必要があり、そのやり取りに時間がかかってしまう。 原因調査のためにログ出力を追加したら問題が発生しなくなってしまう。ログ出力処理が、タイミングを何か変えてしまっているらしいが、その原因や影響理由が分からない。 不特定
.NET開発者のためのJenkins入門 - ＠IT
.NET開発者中心 厳選ブログ記事 .NET開発者のためのJenkins入門 ―― ブログ「present」より ―― t_nakamura 2011/11/17 2011/11/19 更新 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 ■はじめに 仕事でSubversionとTracを使っていますが、残念ながら、「活用できている」とは言えません。「継続的インテグレーション（以下、CI）？ 何それ、おいしいの？」という状態。そもそもCIするために、T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いまだにSE・PGな発想から抜け出せないSI業界？
