富士通製メインフレームが残り700台の衝撃、保守期限までの撤廃に求められる策
「まだ700台も残っているのか」――。富士通と米Amazon Web Services（アマゾン・ウェブ・サービス、AWS）の会見を聞いた筆者の感想だ。両社は2024年3月18日、グローバルパートナーシップの拡大と顧客システムのモダナイゼーション支援を発表した。その中で、富士通の島津めぐみ執行役員副社長COO （サービスデリバリー担当）（現職）が同社のメインフレーム残存数に触れたのだ。 島津副社長によれば、現在約700台のメインフレームと約9400台のUNIXサーバーが稼働しているという。富士通は2030年度末にメインフレームの製造・販売から撤退し、5年後の2035年度末で保守を終える。UNIXサーバーは2029年度下期に製造・販売を終了し、2034年度中に保守を終える予定だ。 脱メインフレームは間に合わない 果たして2035年度末までに700台あるメインフレームをすべて撤廃できるだろうか
一休レストランPython移行の進捗 - 一休.com Developers Blog
レストラン事業部エンジニアの id:ninjinkun です。 一休レストランでは10年以上動いているシステムをPython 3で書かれた新システム（以下restaurant2）に順次移行する作業を進めています。現在ではPC用のレストランページ や主要な API を含め、いくつかのページがrestaurant2で提供されるようになっている状態です。本記事ではこの移行の経緯と、restaurant2システムの詳細、Pythonを選んだ理由、現在の進捗状況をお伝えします。 経緯 一休レストランはサービスローンチ時よりClassic ASP（言語はVBScript）でシステムが構築されてきました（こちらに驚かれる方も多いと思いますが、歴史的経緯という言葉で強引にまとめて話を先に進めます）。このシステムは現在も一休レストランを支えているのですが、長年の改修による複雑性の増加、言語の古さ、言語機能の
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供
みずほ、新システム夏完成へ 2度の障害、統合後初統一 - 共同通信
みずほフィナンシャルグループ（FG）が開発中の次期システムが今夏に完成する見通しとなったことが2日、分かった。第一勧業、富士、日本興業の3銀行が2000年に経営統合して発足したみずほグループのシステムは、2度の大規模障害を経て、初めて統一される。運用開始は来年度以降になるとみられる。 次期システムの開発は、02年と11年に大規模なシステム障害を起こし、11年は当時の銀行トップが引責辞任する事態に発展した、みずほグループにとって最大の経営課題だ。だが、2度にわたる開発の延期で当初の想定以上の資金と人員を投入しており、収益を圧迫していた。
IT業界で無事にいたいなら銀行に関わるな
IT業界で無事にいたいなら銀行に関わるな 3Kとか7Kとか言われているが、底辺の会社にいなければそれほどひどくないし、正直どうでもいい。しかし関わった人は皆同じことを口にする。 銀行には関わるな。特に最新技術に詳しい人ほど真っ先に壊れる。すぐに逃げ出せ。 新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。 休みが人並みに取れると思うな。深夜まで仕事をするのが当たり前。GWと正月はないと思え。しかも一回や二回ではなく仕事辞めるまでずっとだ。 仕事の出来を褒められることを期待するな。動いて当然、止まったら新聞沙汰だ。当然直るまで何日でも徹夜。 キャリアの役に立つと思うな。業
COBOLなどの既存システムから日本語の設計書とJavaソースを作成、富士通が新サービス
富士通と富士通アドバンストソリューションズ（FASOL）は2012年8月15日、企業情報システム向けの「設計書化モダナイゼーションサービス」を発表した（図1）。同日より販売活動を開始する。 このサービスでは、富士通およびFASOLの担当技術者が顧客企業のメインフレームを調査。COBOLやPL/Iなどで書かれているアプリケーションのソースコードを解析し、日本語の設計書に置き換える（図2）。アプリケーションの保守担当者はソースコードではなく日本語の設計書によってアプリケーションの仕様が把握できるため、アプリケーションの保守性が向上するという。 また、日本語の設計書から新規システム用のJavaソースも生成可能。この作業で富士通側はFASOLの開発支援ツール「InterDevelopシリーズ」を使う。同ツールはテスト関連の機能も備えており、設計書からJavaソースの動作テスト項目の候補を自動抽出す
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
南米発のツールがIT業界に与えるインパクト
「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus（ジェネクサス）」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生
見積もり・発注 - 技術情報Wiki
発注／調達 † 値切ってはいけない 2009.3.6 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには，PMは出てきた見積もりを査定する能力が必要であり，かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか ＲＦＰ（Request For Proposal：提案依頼書） ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998 ＳＰＡ（Software Process Assessment）
Q.電球を変えるのに、SE/PGが何人必要か - SiroKuro Page
答え 約2000人月 開発の流れ 要件定義 顧客の発注を受ける １次請け、要件定義書の執筆を始める １次請け、顧客と交渉し、家の中に繋がっている家電製品を全て調べ上げる 一次請け、基本設計実施要領の執筆を始める 基本設計 この工程は、２次請け以下には秘密裏に行われている 詳細設計 １次請け、詳細設計実施要領の執筆を始める １次請け、だいたいこのあたりで２次請けへと乾坤一擲 ２次請け、使用する規格やフレームワークなどの部品を選定開始 詳細設計書の執筆がスタート、電球の大きさや重さ、丸み、光度、味、匂いなどを定義する このあたりで、既に５次請けくらいまで仕事が割り振られている 製造 １次請け、製造工程実施要領の執筆を始める １次請け、単体テスト実施要領の執筆を始まる ５次請け、電球フィラメントのくるくるを手で作成しはじめる ４次請け、求める匂いが上手く出せないと３次請けに駄々をこねる ３次請け
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
SI契約に変革迫る「進行基準」 IT業界に激震走る！：ITpro
ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ケルビン＠斜壊人 on Twitter: "ラーメン屋で「醤油ラーメン」と注文した後に「半ライスつけて。餃子つけて。やっぱ塩で。ネギ多め。やっぱ炒飯で。メンマつけて。やっぱ味噌で。もやしつけて。海苔要らない」位の追加注文した客が、最初の醤油ラーメン代だけ払って帰るのを呆然と見るのがシステム開発です。"