江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog
2024年4月5日、江崎グリコは基幹システムの切り替え後にシステム障害が発生し、同社や販売委託を受けている一部の冷蔵食品の出荷に影響が生じていると公表しました。ここでは関連する情報をまとめます。 障害後緊急対応するも在庫数合わず業務停止 今回システム障害が起きたのは江崎グリコの基幹システムで2024年4月3日の新システムへの移行に伴い発生した。物流、販売、会計などを一元管理するERPパッケージ SAP社製「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明している。障害原因の詳細は同社から開示されてはいないが、システム障害の問題個所の特定は済んでいる。なおサイバー攻撃によるものではないと取材に答えている。*1 システム障害の影響に
「取得したいIT資格」は登録セキスペが1位、AWSの6連覇ならず
「IT資格実態調査」を2023年10月から11月にかけて、日経BPの技術系サイト「日経クロステック」で実施。編集部が選んだ50種類のIT資格について、アンケート形式で保有状況や役立ち度合い、今後の取得意向を調べた。IT資格実態調査は2017年から毎年実施しており、今回は7回目に当たる。 5年ぶりに情報処理安全確保支援士が返り咲く 今回はIT資格の取得意欲を見る。アンケートで、50種類のIT資格の中から「これから取りたいと思うIT資格」を最大3つ選んでもらった。 最も多くの回答を集めたのは「情報処理安全確保支援士（登録セキスペ）」で、229人の回答者のうち47人が取得したいと回答した。回答者全体に占める回答率は20.5％である。第1回IT資格実態調査で回答率1位を得たが、第2回の2018年以降からは「AWS認定各種（ソリューションアーキテクトなど）」が毎年1位だった。今回、5年ぶりに1位の座
実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
「要件定義をやめよう」の真意、普通にやると金と時間が無駄になるだけ
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX（デジタルトランスフォーメー
時価総額は2兆円 医療IT「エムスリー」の圧倒的なビジネスモデルに迫る
連載：勝手に考察！「隠れ優良企業」のビジネスモデルに学ぶ ビジネスには「絶対成功の法則」はないが、成功の可能性をあげるためのセオリーはある。勝ち続けている企業の背景にはどのようなカラクリがあるのか。 ビジネスモデル初心者を対象にわかりやすく、実際に今も躍進を続けている企業の分析を通じて我々が知っておくべき「成功のためのネタ」をご紹介します。 ※本記事は「事業がつくれるベンチャーマネージャーになるためのnote」内記事を加筆したものになっています。 テレビCMや広告で日々目にする企業ではないが、ある領域では圧倒的なビジネスを展開している会社が世の中にはあります。こうした「隠れた優良企業」のビジネスを紹介・考察する本シリーズ。 今回紹介するのは医療ITの「M3（エムスリー）」です。もはや”隠れていない”という声も聞こえてきそうですが、決算書を見るたびに学びが得られる日本を代表するB2BのIT企
日本における「名寄せ」と「照合」の黒歴史
健康保険証、銀行口座、年金記録――個人のマイナンバーに別人の情報がひも付けられるトラブルが後を絶たない。多くの事案に共通するのは、自治体や関係機関の職員が氏名や生年月日などを基にマイナンバーや住民データを照会した際に、誤って同姓同名の人の情報を引き出してひも付けてしまうというケースだ。 こうした情報のひも付けをする際、職員が住民データの照合や突合、本人確認に使うのが「氏名」「生年月日」「性別」「住所」、いわゆる基本4情報といわれるものだ。 だがこの4情報は、コンピューターによる自動処理とは絶望的に相性が悪い。例えば氏名は「邊」「邉」など旧字・異体字の揺らぎや外字の処理が煩雑なうえ、婚姻による改名もある。よくある氏名の場合、氏名も生年月日も同一というケースが頻発する。住所は時期によって変わるうえ、人によって書き方が「一丁目四番」から「1―4」まで一意ではない。 こうした曖昧な識別符号を代替す
準委任契約だけど、責任は取ってください
連載目次 準委任契約と請負契約 今回は、システム開発の要件定義工程の契約形態についてお話しする。 本連載の読者ならご存じの方も多いと思うが、情報システムの開発は、準委任契約に基づいて行われる場合か請負契約に基づいて行われる場合が多い。そして1つの開発においても、要件定義工程は「ユーザーの作業を支援する」という意味合いで、成果物の完成責任を負わない準委任契約で、設計以降の工程（ここでは便宜的に「開発工程」と呼ぶ）は「ベンダーが主体となる」ために成果物の完成責任を伴う請負契約で行う場合がよくある。準委任契約は、「専門的知識やスキルを持つ人間が契約で合意した時間働けば、その対価は払ってもらえる」というのが原則である。 では、専門家が一定時間働きさえすれば責任を果たしたことになるのだろうか。 今回取り上げる事件は、ITベンダーが要件定義工程から開発工程までを一貫して行ったが、要件定義に抜け漏れがあ
基本4情報での名寄せは難しい｜MORIDaisuke
先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所
ITプロジェクトの失敗原因、追究する5つのステップ
作業はグループで進めるのが望ましい。1人でもできるが、プロジェクトに参画した複数のキーパーソンで議論したほうが、より客観的かつ網羅的に原因を究明できる可能性が高い。 ステップ1：全ての失敗原因を抽出 ステップ1では「ITプロジェクト版失敗原因マンダラ図」から全ての失敗原因を抽出する。図に示した第1レベル・第2レベルの原因全てについて、今回のプロジェクトの失敗原因として当てはまるかを確認。当てはまる全ての原因に丸印を付けていく。 作業は左下の「無知」から始めて「未知」で終わるよう、時計回りに進める。この段階では参加メンバーが個別に確認・記入していく。 メンバーは丸印を付けた項目について、具体的な事象を書き出す。「重要性の認識誤り」に丸印を付けたのであれば、「システムダウンが引き起こす社会的な影響を経営層は軽視していた」などと書く。 これは「抽象化と具体化」という技法に基づいている。具体的な事
とにかく日本の住所のヤバさをもっと知るべきだと思います｜inuro
「住所の揺らぎ程度のことにAIを使いたいだとかデジタル音痴」だの「住所の正規化なんてExcelで2時間あれば作れそう」だの、たいへんフットワークの軽やかな言説の数々に、位置情報界隈のみならず住所の正規化や名寄せに少しでも関わったことのあるエンジニアが総立ちでマサカリを投げていたのも記憶に新しい今日この頃ですが（2023年6月6日）、この手の騒動は周期的に起こってる印象です。 ということはつまり いつまで経っても解消されない、解決が困難な課題である その困難さが界隈以外に共有されていない であるわけで、その都度Twitterにトリビアが投下されてはTLが賑わい華やかではありますが、そろそろ自分の整理としてもどれだけ日本の住所システムがカオスで、その計算機的な処理がいかに困難かをメモっておこうかと思いました。 なおこの件については既にQiitaにGeoloniaの宮内さんが鼻血の出そうな良エン
中国・韓国より低い日本の高度人材の報酬、米国の「3分の1の低賃金」が招く流出危機
1940年東京生まれ。63年東京大学工学部卒業、64年大蔵省入省、72年エール大学Ph.D.（経済学博士号）を取得。一橋大学教授、東京大学教授、スタンフォード大学客員教授、早稲田大学大学院ファイナンス研究科教授などを経て、2011年4月より早稲田大学ビジネス・ファイナンス研究センター顧問、一橋大学名誉教授。専攻はファイナンス理論、日本経済論。主な著書に『情報の経済理論』『1940年体制―さらば戦時経済』『財政危機の構造』『バブルの経済学』『「超」整理法』『金融緩和で日本は破綻する』『虚構のアベノミクス』『期待バブル崩壊』『仮想通貨革命』『ブロックチェーン革命』など。近著に『中国が世界を攪乱する』『経験なき経済危機』『書くことについて』『リープフロッグ 逆転勝ちの経済学』『「超」英語独学法』などがある。野口悠紀雄ホームページ ------------最新経済データがすぐわかる！-------
SAPがドイツで誕生した謎、無知な日本人が気付かない真実
パッケージソフトウエア製品やクラウドサービスをグローバルで展開する巨大ITベンダーといえば、そのほぼ全てが米国企業だ。グーグル（Google）やアマゾン・ウェブ・サービス（Amazon Web Services）、マイクロソフト（Microsoft）、オラクル（Oracle）……。当然、人月商売に明け暮れる日本の大手ITベンダーはグローバルどころか、国内でも存在感が薄くなる一方で、その差にもはやため息すら出ない。 だが、唯一の例外がある。言わずと知れたERP（統合基幹業務システム）最大手の欧州SAPだ。ドイツが生んだこの巨大ITベンダーは今のところ、オラクルやマイクロソフトなど米国のITベンダーの挑戦を退け、ERPで世界トップシェアを維持している。 実は、私にとってこのSAPは謎だった。なぜドイツで米国企業をしのぐ巨大ITベンダーが誕生したのか。だってそうだろう。「ドイツは日本と似ている」
日本のIT業界が詰んでいる理由 - orangeitems’s diary
IT業界も長いですが、実感したことがあったので語ります。 なんかわかってきたんだけど、社員の教育には一切お金をかけないために社員が能力不足。一方でお金を採用活動に使い中途採用で他社の能力を買おうとする。 こんなことばかりやってるから、採用もうまくいかなくなり、業界全体で詰んでる気がしてきた。 — orangeitems🍊 (@orangeitems_) December 8, 2021 25年ほど前、インターネットがまだ世の中に落っこちてきたころからこれまでの歴史を目の前で見てきたのですが、どうも人材育成という話になると、スマートには全くなってません。 この業界は技術が汎用的で、別の会社に移ってもすぐ即戦力になれる傾向があるので、転職も激しめです。だから、いくら投資して育てたとしても、育った途端に他の給与のいい会社に移っちゃうという不信感があります。それだとコストが丸損ですよね。 だから
請負契約のような準委任契約 仕事を途中で放り出したITベンダーを糾弾できるか？
請負契約と準委任契約 今回はシステム開発でよく見られる「請負契約のような準委任契約」について取り上げます。 この連載の読者の方であれば、この二つの契約の違いについては、もう十分にご存知かもしれませんが、請負契約というのは、なんらかの成果物（目的物）を約束した納期どおりに作成したり、提供したりすることを“請け負う”ことです。 請負人（ソフトウェア開発では多くの場合ITベンダー側）は、期日通りに約束した品質をともなう成果物を完成させて納品する必要がある契約です。 一方の準委任契約は、本来なら発注者がやるべきことを、専門家である受注者が代わりにやってあげるというイメージに近いでしょう。同じように情報システムを作っていたとしても、受注者に求められるのは、専門的な技量を十分に発揮して、真摯に作業を行うことであり、多くの場合は働いた時間に応じて支払いがなされ、原則的には請負にあるような“約束した品質を
フリーランスエンジニアの光と闇
世の中にはびこるフリーランス神話。果たして、フリーランスはITエンジニアの理想の働き方たり得るのだろうか――複雑怪奇なIT“業界”を解説する本連載。今回は、フリーランスという言葉の魔力に引き寄せられたエンジニアたちの理想と現実に迫る。 はじめまして。成末（なりすえ）と申します。ITフリーランス特化型のエージェントとして20年以上サービス展開をしている「ギークス」で、取締役を務めております。 ギークスは「働き方の新しい当たり前をつくる」を事業ビジョンに掲げ、フリーランスという働き方の啓蒙（けいもう）促進に努め、世の中のフリーランスの変遷をニュートラルに見てきました。 本記事は、20年強の実績で得た実例やデータを基に、フリーランスエンジニアの実態を紹介しつつ、フリーランスは魅力的な働き方といえるのか、検証していきます。 フリーランスエンジニアの歴史 フリーランスとは、案件ごとに契約を結び、仕事
日本のソフトウェア開発はなぜ世界から落伍したのか。中国人エンジニアの見方 - 中華IT最新事情
日本のソフトウェア開発はなぜ落伍したのか。中国のエンジニアの間でも話題になることが増えている。未来樹Aは、その理由をエンジニアの視点で解説をしている。委託開発が多い。システム開発の目的がイノベーションではなく、生産性の効率向上に留まっている。政府、地方自治体の案件が上位企業に集中するため、ベンチャーが育たないという理由を挙げている。 中国でも話題になっているCOCOAの件 日本でも話題になっているが、中国でも接触確認アプリ「COCOA」の件が、エンジニアの間で話題になっている。中国では、位置情報とQRコードを活用した健康コードが、2020年2月11日という早い段階で、アリババと杭州市によって開発され、1月ほどで他都市にも広まった。感染リスクが高いと判定されると赤になり、公共交通や店舗の利用ができなくなる。不便は強いられるが、それでも、生鮮ECやフードデリバリーが発達をしているため、生活はな
海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」 - Qiita
Why doesn’t Japan excel in software as they did in hardware? (なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？) という英語Quoraのやり取り、分析が興味深かったので、まとめ。 仮説1: 日本は完璧を求める 10人のエンジニアのソフトウェア開発会社を経営しているフランス人の友人が、ルイ・ヴィトン日本支社のコンピュータシステムのマネージャーと同意した話：ソフトウェアはハードウェアではなく、産業用でもない。50年間同じトヨタカローラのように構築され、洗練され、完成されたものではありません。ゼロバグでそれを「完璧」にすることは不可能であり、したがって、「ゼロデフォルト」という、総合的な品質、継続的な改善を求める日本人の精神に反するものです。 日本は職人の国であり、漢字を書いたり、折り紙を折ったりする技術を
企業内技術者も一度は読みたい「デジタルガバメント推進標準ガイドライン」の“勝ちパターン”
企業内技術者も一度は読みたい「デジタルガバメント推進標準ガイドライン」の“勝ちパターン”：政府CIO補佐官が説く「デジタル改革」の具体像（2） 政府のデジタルトランスフォーメーション（DX）を考え、民間企業にも通じる知見を共有する本連載。今回は政府が作成し、ガバナンス強化のために活用している「デジタルガバメント推進標準ガイドライン群」を解説します。 プロジェクトごとにバラバラなITプロセスが課題 読者の皆さまは「デジタルガバメント推進標準ガイドライン」をご存じでしょうか。ITを企画、立案、調達する場面から、開発（あるいは導入、利用）、テスト、検収、運用、保守に至る一連の活動について、そのプロセス（段取り）や規則、役割と責任などを政府が規定したものです。 ITは建築や製造業とは異なり、段取りが整備されておらず、個々がそれぞれの流儀で進めています。そのため、製品の品質にバラつきが出てしまいます
ソフトウエアを「工業製品」にしようとした日本の勘違い、痛恨のミスの代償は大きい
スタート以来、日経クロステックの名物コラムとなった「テクノ大喜利、ITの陣」。今回はその第20回だ。毎回、複数の識者に共通のお題（質問）を投げかけ、識者にはそれに答える形で論陣を張ってもらう。お題は日本企業のIT利活用の問題点やIT業界の構造問題、そして世間の耳目を集めたIT絡みの事件などだ。 第20回のお題は「日本の産業政策にもの申す、ダメIT業界をどうするか」。お題に答える識者の3番手は、製造現場のシステム開発などを手掛けた後にCIO（最高情報責任者）を務めた寺嶋一郎氏だ。ソフトウエアを「工業製品」にしようとした誤った発想が日本のIT業界をダメにしたとみる寺嶋氏は、垂直統制型の組織を打破し「小さな組織が良い」との認識を持つことの重要性を訴える。（編集部） 1979年に積水化学工業入社。製造現場の制御システム、生産管理システム構築などに従事。1985年マサチューセッツ工科大学留学を経て、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜ日本政府が作るソフトウェアは使えないモノばかりなのか？」――中島聡氏が考える「日本社会のDX」の要件
