マイナンバー制度に絡むシステムの問題は、依然として残っている。行政事務の効率化の要となる情報連携は、当初予定より半年以上遅れる見通しだ。根本原因は、制度全体に関するガバナンスの欠如にある。 システムトラブルにより滞っていたマイナンバーカードの交付は、改善の兆しが見えている。総務省によれば2016年5月までに受け付けた申請に対し、市区町村の9割強が8月までに交付通知書を発送できる見込みだ。 交付通知書をマイナンバーの通知カードや本人確認書類とともに自治体の窓口に持参すれば、マイナンバーカードを受け取れる。総務省は「カード申請から交付通知書の発送までの期間を1カ月以内にする」としている。 しかし、これでマイナンバー制度に関わるシステムの問題を全て解決できたわけではない。自治体セキュリティの整備は遅れ気味である。さらに無視できないのは、マイナンバーを利用して税や社会保障との間で情報を連携する「情
政府は2017年2月14日、「働き方改革実現会議」の第7回を開催し、残業時間に関する上限規制案を提示した。同案は、労働基準法を改正して月45時間、かつ年360時間という上限を法律で規定するというもの。臨時的な事情に対応するために労使が協定を結ぶ場合でも、年間720時間（月平均60時間）を上限にする。同案に沿って労働基準法が改正され、施行された場合、IT企業の職場にも大きな影響が及びそうだ。 現状の労働基準法においては、労使が協定（いわゆる36協定）を結べば、事実上無制限に残業を増やせるようになっている。厚生労働大臣告示では月45時間以内、年間360時間以内という限度基準が出ているものの、強制力がないためだ。今回の政府案は、法律に残業時間の条件を具体的に規定することで強制力を持たせる。 一部報道で出ていた、「繁忙期には月間100時間までの残業を認める」「前後の月との平均で80時間まで認める」
よしおかさんがざっくりいいきるときは、だいたい適当なので、突っ込んだ方が損した気になったりするものなので、適当には適当で返しておこうと思います。なのでこちらの話はとても適当ですので、突っ込まれると知識不足が露呈しますが、予めご容赦ください。 システム管理者、感謝の日イベントに参加した。 - 未来のいつか/hyoshiokの日記 どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。 建築プロジェクトではデスマーチの代わりに工期遅延が起こる ワールドカップやオリンピックごとに、建築間に合うのか問題が起きているのは、日
IT業界が外部の人間から敬遠される理由の一つに「デスマーチ」がある。 ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。 そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。 このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。 デスマーチのきっかけ 営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成
労働時間が長いとされるＩＴ企業で働く人の過労死を防ごうと、企業の担当者を集めたセミナーが３０日、東京で開かれました。 厚生労働省が昨年度に行った調査では、「過労死ライン」と呼ばれる、月８０時間を超えて残業した社員のいる企業の割合が、ＩＴ企業を含む情報通信業で４４％に上り、すべての産業で最も高くなっています。 セミナーでは東京に本社があるＩＴ企業、およそ３０社から回答を得た調査結果も示され、突然のシステムトラブルへの対応や厳しい納期での発注のため、システムエンジニアやプログラマーの多くが長時間労働を余儀なくされている現状が伝えられました。 中央労働基準監督署の古屋希子署長は「ほかの産業でも長時間労働の問題はあるが、都心ではＩＴ企業の問題が大きく、過労死や過労自殺も見られる。企業には法律を知ってもらい、リーダーシップを持って対策を進めてもらいたい」と話していました。
むかついているがどうにもできない。そのことにさらにむかついている。 背景俺は新卒で入ったSIerに勤めて数年になる。 うちの会社は社員数も売上高も数千の中規模SIだ。いつからかわからないが中国にも支社があり、現地の技術者を採用したりもしている。（こうした実績からグローバル企業を謳ったりもしている…） 新卒でも中国人を採用していて俺の同期には5人いた。 同期の中国人技術者の優秀さこの会社に入って最初の合同研修期間で彼らと接することになったのだがまずスペックの高さに驚いた。 まず3ヶ国語を扱える。中国語はもちろんネイティブ、英語はビジネスレベルで習得しており、個人差はあるもののみんな日本語での日常会話に支障はない。外国人に難しいとされる日本語の読み書きも、漢字をある程度知っているだけあってアルファベット圏の人々より習得が早いらしい。 全員バリバリのコンピュータサイエンス出身。 俺は文系学部出身
2017年最初の「極言暴論」である。実は、この極言暴論を書き始めてから、まもなく4年を迎える。よくまあ飽きもせず、というか、暴論のネタが尽きなかったものだと思う。言い換えれば、それほど日本企業のIT活用がデタラメで、IT部門もダメダメ、そして日本のIT業界の御用聞き体質や多重下請けの“人でなし”構造などがひどい状態だったわけだ。 だが、極言暴論を書き始めた当初と比べ、今は状況がかなり異なってきた。当初はIT部門とIT業界の双方から「何をひどいことを書いているんだ」と怒りの“つぶて”が数多く飛んできた。中には暴論の内容に理解を示してくれる読者もいたが、それでも感想は超低温状態。「言いたいことは分かるが、IT部門（or IT業界）はずっと変わることができなかった。だから、木村さんがどんなにほえても何も変わらないよ」といった具合だ。 それが最近では、随分反応が違う。まず今回の記事の本筋でないほう
MRJの開発の遅れは2016年秋ごろに表面化し、これまで三菱重工は「精査中」とのスタンスを示していた。大きな要因は、商業運航に必要な安全性などを航空当局が調べる「型式証明」を円滑に取得できる見通しが立たなかったことだ。取得にあたっては書面審査や飛行試験で膨大なチェック項目を満たす必要がある。必ずしも明文化されていないノウハウの部分も多い。 「日の丸航空機」の重圧、外国人活用が後手に 民間の完成機では開発経験の乏しい三菱重工だが、政府も含めて「日の丸航空機」という金看板を掲げた手前、不慣れな日本人技術者を中心に試行錯誤で開発を進めてきた。防衛省向け戦闘機や米ボーイングの民間機への部品供給などで三菱重工の評価は高く、航空機に対する一定の自信があったからだ。だが、次第にそのペースでは到底納期に間に合わない現実を思い知る。 転機となったのが2016年11月ごろ。事業会社の三菱航空機主体の開発体制か
2014.08.11 人事給与関係業務情報システムというものがある。 人事院が管理する省庁の人事、給与、共済、統計などの業務のためのシステムだ。 もともとは分散型システムのはずだったのが、途中で方向転換して、集中型システムになった。 １１府省が利用し(府省と言っても宮内庁、衆議院、会計検査院、公正取引委員会なども使っている)、平成２８年度末までには最高裁判所や参議院を含め、すべての省庁が利用することになっている。 元々の計画では初期投資に８４億円、毎年の運用経費が１５億円というはずだった。 しかし、初期投資の予算から各府省のシステム移行経費４２億円が漏れていたりして、結果的には１４３億円の初期投資と２７億円のランニングコストがかかっている。 しかも平成２２年度に導入されたシステムなのに、いまだにソフトウェアに大きな問題がある。 例えば、人事の発令に併任がかかっていたり、あるパターンの発令が
情報セキュリティの重要さを啓蒙する自主制作アニメ「こうしす！」（関連記事）。前回から2年越しで、第2話「やはり弊社の業務システムは間違っている」がニコニコ動画で公開されました。今回のテーマは業務システムの開発。セキュリティの脆弱なシステムが生まれる背景を描いています。 物語の舞台は、京都と姫路を結ぶ中堅私鉄「京姫鉄道株式会社」のシステム課。第1話の事件以来、主人公のアカネは通常業務から外されて、子会社へ出向。自社システムの開発要員に組み込まれるのですが、そこには絶望的なデスマーチが待ち受けていました。 配属先に近づくごとに消耗したスタッフが通りすがり、中に入るとバイオハザードが 配属先の部署は死屍累々といった様相。スタッフはゾンビのように疲弊し、責任者は発注元の親会社から進捗の遅れを責められ、みんな心が壊れかけています。 親会社の総務部長に責められる課長代理。パワハラだぁ！ というのも、プ
http://fumit.blogspot.com/2012/01/55.html http://blogos.com/article/30357/ これはヒドイ． もちろんブログの方がね．*1 SOLは平成18年に60人体制で設計を開始したが、翌年初めには遅延が始まったため、順次増員。平成19年3月には200人、5月には450人体制に膨れ上がる。増員しても作業効率の向上には繋がらなかったのだが、TSOLは更に大幅な人員の増強で工程の遅れに対処しようとし、平成20年11月以降には1,300人もの体制を整えたが、このような急激な増員は、かえって設計指示の不徹底や実施手順の不統一を招き、設計成果物の 「品質の不均一」 が生じることとなった。こうして混乱が続き、 このブログの主は，これを「尋常ならざる事態」と思って引用したのかもしれんけど，初期開発メンバーの１０〜２０倍規模なら，ごく普通のデスマ
「#ITエンジニアだらけの運動会」というハッシュタグがTwitterで盛り上がった。「デスマーチ持久走」「障害たらい回しリレー」など、競技名を見ているだけで疲れそうなハードさだ。 Togetterのまとめ 始まりは「というか #ITエンジニアだらけの運動会 やりたい」というツイート。このツイートを見たユーザーが「システム障害物競争」「バグ食い競争」「火消し人員借り物競争」など次々と競技名をつぶやき、Togetterには2000つぶやきを超える大作まとめができた。 「ルールを知らないPMを担いで騎馬戦」「RedBull吊るしてRedBull飲み競争」「タスキを渡す相手がいない引継ぎ駅伝」など、つらそうな競技名も盛りだくさん。さらに「競技のルールが進行中に変わる」「延長戦（サービス）もあるよ」などなど、現場にありがち（？）な状況を運動会に当てはめたツイートも。「顧客情報ポロリもあるよ！」って、
2005年の古い記事だが、レガシーマイグレーションという名のシステム移行に関して、概念が良くまとまっているのでメモ。 【元ネタ】 ITレポート（動向／解説） - 失敗しないレガシー・マイグレーション（1）：ITpro ITレポート（動向／解説） - 失敗しないレガシー・マイグレーション（2）：ITpro 【1】レガシー・マイグレーションとは一言で言えば、旧式（レガシー）のシステムを新しいシステムに移行すること。 メインフレーム上のCobolシステムをオープン系のWebシステムに変えたい、VBとSQLServerのクラサバをJavaやPHPのWebシステムに変えたい、とか。 レガシーマイグレーションを実施したい理由は、いくつかあるだろう。 保守費用が高い割には、業務ロジックのカスタマイズが追いつかず、既存の業務に影響を与えていること。 あるいは、長年の手パッチによる修正によって、保守性や移植
今週もやってまいりました。 全日本デスマーチ選手権。 日本中の兵どもが、プロジェクトを破壊するために死闘を尽くします。 本日は解説にギコさんをお呼びしております。 さぁ、ギコさん、ウンコーダ選手のまなざしはどうですか？ 「いやー面接じゃなにもわかりませんからねぇ。どんな荒業が飛び出すか想像もできません」 では、注目してみてまいりましょう。 おっと！ウンコーダ選手、テストコードの記述を拒否！！！！！ やったことがないから、できませません！！！！！ でたーーーー！！開幕早々の大技だ！ 「これはすごいですね。難しそうな作業は全部拒否するATフィールドを展開して、リーダを牽制しています」 おっと、リーダ、食い下がる。 しかし、理屈にならない理屈を並べて攻撃をかわします。 「面接でみせた、一見、口が上手くてコミュニケーションが得意そうにみえるという罠にはまりましたね。現場を離れた人が面接官だとよくひ
どうも濱田です。 AIITの上田先生・・・というかシェル芸おじさんと一緒に去年やろうやろうと言っていた「明るいデスマーチ研究会(通称: デス研)」を4月17日にようやく開始しました。すでにこちらにレポートが上がっているのですが、第1回目をやってみた感想などをつらつらと。最初の会合では、上田さん、私のほかに、いわゆるSIの現場で活躍されている方、WEB系な方、コンサルタントが集まり、ケーススタディに事欠かないくらいでした。。。 ■ なぜデス研を始めたか いつものように、USP友の会では勉強会後の懇親会や定例会(という飲み会)で、あんなことやろうこんなことやろうと盛り上がります。その中の1つとして挙がったのがデス研なのですが、過去いろんな方がデスマーチの発生メカニズムや戦場での振る舞い方を研究されていたりしているはずなのに、なぜIT業界(の一部？かなりの割合？)からデスマーチが無くならないのか
![[デス研]明るいデスマーチ研究会 Vol.1開催しました – (っ´∀｀)っ ゃー | 一撃](https://cdn-ak-scissors.b.st-hatena.com/image/square/dc180a53546f471929fc6bed793ff09665f21006/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fnullpopopo.blogcube.info%2Fwp-content%2Fuploads%2F2014%2F04%2Fdm.jpg)
玩具卸最大手のハピネットが販売システムの開発失敗を巡って、開発受託ベンダーのSRAとの間で双方を訴えていた係争に一旦の区切りがついた。ハピネットとSRAホールディングスは2016年10月31日、東京地方裁判所の判決が言い渡されたことをそれぞれ公表した。 SRAがハピネットを訴えたのは5年前の2011年3月31日。「ハピネットが2009年に一方的に開発作業を停止するように指示し、既に納品・検収したものや現に使用しているものについても代金の支払いを拒否した」として、未払いの開発費など4億245万9817円の支払いを求めた（SRAホールディングスのプレスリリース）。これに対し今回、東京地裁はハピネットに2232万5625円の支払いを命じた。 SRAの提訴から6日後の2011年4月6日、今度はハピネットが支払い済みの開発費など11億5843万7653円の返還を求めてSRAを反訴した（ハピネットのプ
日経BPは10月9日～11日の期間、ITカンファレンスイベント「ITpro EXPO 2013」を東京ビッグサイトで開催している。2日目となる10日、日本情報システムユーザー協会（JUAS）でエグゼクティブフェローを務める細川泰秀氏が、JUASの独自調査を基に日本企業のシステム開発の現状を報告した。細川氏は「日本から失敗プロジェクトをなくしたい」と意気込んだ。 細川氏が着目したのが、ユーザーとベンダー間の取引・契約モデルについてである。システム開発の契約形態として、大きく自社開発、委任（準委任）、請負がある。準委任と請負の違いは、仕事の完成義務と瑕疵担保責任が準委任にはないということ。経済産業省では、要件定義やシステム設計のフェーズに関して準委任型の契約を推奨しているが、実態は4割ものユーザー企業が請負型になっているという。 実は、すべてのフェーズで請負型を採用する企業は、プロジェクトの工
名前： 吉澤準特 職業： ＩＴコンサルタント 連絡： メルマガに記載 自己紹介のコメント： 自己紹介の詳細はコチラ→■ 外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。 Twitterやっています。 →http://twitter.com/juntoku_y マイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。 →コンサル直伝－IT業界”裏”講座 EnterpriseZine（翔泳社）で記事掲載中です。そちらもヨロシクお願い致します。 →ファシリテーションで会議を変える/ITIL解体新書/デキるシステム担当者のスキルノート 2010年7月末、日本能率協会マネジメントセンター（JMAM）より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
