単純にシステム開発のスキル不足（マネジメント面含む）だと思う。

校務支援システムってなんでこんな微妙なんですか？という方は、とりあえず”要件定義”という言葉を知った方が良いなと思う今日このごろ。

「人員や予算の確保には当然、経営陣の意思決定が必要になる。現場任せ、専門家任せのままでは、DXの成功は遠のくばかり」と。

失敗の一番要因は、企業の担当者に発注経験がないという、ベンダーとのコミュニケーション方法が分からない
点だと思います。

理由はそれぞれだろうけど、何も無い所からタンカー一隻作ろうとかしてない？
作るための施設も運用するための港も大事なんだよ。
↓

ソフトに設計図が必要ってわかってない人が山ほどいるから仕方ないw

失敗を指摘して何が言いたいのかわからない

開発中止の理由に社内の派閥争いや人間関係もあると思うけど、、、

【そんなわけで】
ちょっと読んでみませんか★

自分のささやかな経験では「その機能本当に必要ですか？」と言える人間がベンダーと顧客側のプロジェクトメンバーに1人でもいれば随分違ったろうな...と思うことが多々ある。

"

そもそもの計画が無理なプロジェクトが多すぎる。つまり最初から費用の超過は分かっていて、それを誰が負担するかの綱引きをしているに過ぎない。私は綱引きに勝つことしか興味ないね。納期はどうせ守れん。

154億はエグいな…2015年からやってたというと足掛け8年か。失敗の原因とか総括が見てみたい。

154億の損失！

本当にこれ。

責任の所在が現場止まりだからじゃない？開発失敗したって理由でお偉いさんが辞任したって変じゃないと思うけどな。

問題ははっきりしている
システム設計時に従来業務の置き換えでなく業務の最適化のコンセプトを出したか?
業者任せになっていないか、業者のレベルや適正を見極めたか?
難しい事ではない

お客様の解約理由で「自社開発する」が割とあるんだけど、いろんなシステム導入を見て来たこちらとしては「茨の道でっせ……頑張ってな、、」と思って見送ってます。ダメだったら戻っといでね。

途中で遅延や失敗が判明していても、上に行くほど耳ざわりの良い言葉による報告以外を認めないから対応が後手後手になるんでしょ。

「役員にそんな説明はできない」
「ここの日付を弄れば遅延は無くなる」
「五月雨で対応すれば大線表的にはオンスケです」

ホントに世界に取り残されたIT後進国化が深刻。

成功した開発なんて、一度も聞いた事が無い。

役員がDXやITに関する前提知識が薄い組織が失敗から改善するには、理解ある者をトップに据えて意思決定力を新陳代謝するしかないと考えてる。

JTBの基幹システム開発って中断してたのか。

せやねん

ムズカシイアルネー

システム開発に失敗する主な理由は、現状の仕事のやり方をそのままシステムに載せようとするからで、余計な手順やややこしい権限分担を先に整理すべき。本来の仕事の目的や判断基準、決済者が曖昧なままではシステムにのらない。

偽 装 請 負

引用：
例えば「既存製品・サービスの高付加価値化」という項目への「成果あり」との回答は、見識のある役員比率が0〜3割未満の会社で36.5％なのに対し、同7〜10割の会社では52.1％にも..

ベンダーに丸投げかな。開発前から失敗してそう。

> 遅延が発生した要因については、「開発ベンダーとのコミュニケーションに問題があったのではと社内で分析している。納品前において、成果物の検証をしっかり行うプロセスができていなかったのではないか」

システム開発なんて、個々の会社でやるもんじゃないよ。業界団体が仕様取りまとめて、共通のプラットフォーム使えばよいのよ。と、僕、思います。〇〇Payとかも各社好き放題やってるし、飲食店の券売機とかも各社好き放題やってる。システム利用者は使いづらくて困ってるよ。

以前ベトナムでオフショア開発をやっていましたが、形がないシステムを完璧に要件定義することの難しさたるや。しかもこの規模の要件定義、仕様書作成など、ウォーターフォールでは無理なんじゃないかと思ってしまう。
エンジニアの皆さんはほんとにすごい。

成功するまで続けないからでは？

もっと初歩的に。
ペーパーレスで承認サインを電子に移行したが、書くのに難儀するほどの低品質の電子ペンを配る会社がある。そして、移行期間をろくに設けていない。

実際に失敗プロジェクトやってる人たちははじめから失敗することわかってるでしょ、大抵の場合。「なぜ失敗するとわかってても止められないのか」の方が正しい問いだと思うけど。

【2階雑誌】
『週刊 特集:文系管理職のための失敗しないDX

システム開発の失敗は、けっこう恐ろしい…★

くっそ怖い話。
粗利10%と考えて、1500億円の売り上げをドブに捨てたのと一緒。
明日は我が身((((；ﾟДﾟ))))

耳が痛い。
「つくりたいもののレベルに合ったベンダーをそもそも選定できていなかったりすることが背景にある。」

システム開発は失敗するのが当たり前の世界なのでうまくいかなくてもしょうがない精神は大事よ

経営層が所詮事務処理だからやらせとけ、って考えてるんだよねー。

プロジェクトの難易度が高いのに、他部署や社外からエース人材を引っ張ってきたりせず、既存の部員で対応しちゃうからだと思う。

はなぜこうも｢失敗｣を繰り返すのか

「開発ベンダーとのコミュニケーションに問題があったのではと社内で分析している。納品前において、成果物の検証をしっかり行うプロセスができていなかったのではないか」

【「丸投げ」してなんとかなる世界ではない】 人員や予算の確保には当然、経営陣の意思決定が必要になる。現場任せ、専門家任せのままでは、DXの成功は遠のくばかりだ。

燃ーえろよ燃えろーよー炎よ燃ーえーろー
火ーの粉を巻き上ーげー天ーまで焦がせー
(上層階的な意味で)

これはシステム会社もユーザー企業も両方が意識しないといけない内容ですね

巨額の損失は防ぎたいものですね

まず文系管理職っていう謎の括りやめろ
開発したことないのに管理職やっちゃってるエセイーを使うのを辞める所からだ

基本、子会社に投げればいいや→孫請け会社に投げれば良いやと
実態が無い中抜きとそれによる質の低下
トカゲ切できる環境で責任の所在も希薄になる
*

とりあえずタイトルを回収しなさい／大規模開発の問題でどうにかし辛いものとして「予算取り」があるよね。要件定義後に予算や期日オーバーが見えてもそれをちゃんと手当する、ってできればそうそう失敗しない

👉研究開発費は最終的に消費者に回さなければ処理できません。失敗はそのまま損失です。税額控除があるけど失敗で消費者から補填。秘密主義は不正の温床、もう少し公開を・・・

みずほの事例とかを見ると、やっぱり一番は人の争いが絶えないから

Saasと内製化がお勧めですけどね、個人的には…。

発注者はなんでもできると思い、やりたいことを言う。受注者は、やりたいことを実現すればそれだけ工数が増えて売り上げが上がる構造となっているからな気がする

『発注側』にもある程度のITリテラシーは必要。

単にシステム開発は難しいという話だと思うよ。
僕がSEやってた25年ぐらい前でも、「完成して稼動に漕ぎ着けるシステムは50%で、その半分の25%は当初予定の2倍の開発期間(予算)を要する」とか雑誌に書かれていた記憶がある。

顧客の要求の変化や要件定義が、などが原因として多く挙げられておりますが、
将来的には顧客が求めているイメージを可視化して叩き台を出力してくれるAIが登場するのではないかな、と思います。

海外って失敗しないの？
知りたいわ

「開発ベンダーとのコミュニケーションに問題があったのでは」

ベンダー目線だと仕様変更と追加要件でずるずる長引いてにっちもさっちもいかなくなることが…🥹 担当者レベルではよくても..とか

👉

「開発ベンダーとのコミュニケーションに問題があったのでは」

ベンダー目線だと仕様変更と追加要件でずるずる長引いてにっちもさっちもいかなくなることが…🥹 担当社レベルではよくても..とか

👉

(｡･ω･｡)ﾉ

いろいろ要因はあるけど

「顧客起点」でなく「企業がやりたいこと」を要件にしてしまい、顧客にとって優先度が高くないものまで一気につくろうとしてしまっている

が大きな要因だとおもふ。

High time to shift to project benefit-management/monitoring...

耳が痛い内容です。

正論言えば皆さん仰る通りだが、私はここで敢えて言いたい。『結局、発注する奴が馬鹿だから。』と。

原因の一つに「要件定義の不備」とあるけど、「この世に存在しないシステムの要件を事前にドキュメント化する」という行為自体に不備があると思う。根本的に考え方や作り方を変える、要件定義に固執せず柔軟に軌道修正する工程に変える、などやるべきことは多そう。

🐈「なーご。」

■今人気の記事■ 【

以前としてメインフレーム、中央研究所型の思考から抜け出せていない、日本人。／得卦「風地観九五」：二番煎じで立ち遅れ／

失敗のツケを新人や下請けにつけまわしてきた人たちが大企業の中枢に溜まってるからですよねきっと。
知らんけど。

キチンと面倒見れる人を配置して、オープンソースにしたらええやろ。業務もツールに合わせろ。

潤沢な予算と、規模に見合った締切だけあれば、おたくらの言う失敗のうちの少なくとも8割は成功に転じるでしょうね

＼
こういうのを根本的に解決せずに、世界／

ホラバレで悔しい翌日は、こんな記事に乗っかり意味が理解出来ずにマウントに利用するだけの ｗｗｗだったら職場の遅れているシステムとやらもなんとかなるようにしろｗｗｗ

システムは情報分野のインフラ
開発はもちろん維持するにも投資が必要

そしてＩＴエンジニアたちはごく普通の人間
魔法使いでも超能力者でもないぞ（笑

前にも具体的な判例張ったけど、発注側の責任がとにかく大きいのに発注側の戦術指揮官が機能しないのは相変わらずなのかな

全部が失敗してるわけじゃないだろうけど、新規開発より、既存のシステム・データ資産があって、移行しながら新時代への対応させようとして仕様がないとか、移行でトラブル起きる方がありそう。京都市とか。

ベンダーに丸投げしたりするからじゃない。ベンダーは外様だから極論自分たちの都合のいいことをするよ。依頼元もキチンとシステム開発に専任する担当者を作るべき。

内製しないからじゃない？

お金はできるだけ出したくない、でも全部を要件に取り込みたい……があったりもしそうで。全く同じフローのままとか、人力でやっていた過剰な作業にこだわるとか。

会社の特色やサービス毎に要求が違う上に、時代に応じて変化し続けるし
数十億円規模になるともう社内で開発チーム持って明らかに不足した部分だけアウトソーシングで良いと思うんだけど
真っ先に外部の専門会社探すとこから始めるからこうなるんだろうなあって思ったり

？？？「中止は失敗じゃない！！」

発注者が何が欲しいかわかってないからかな。
1企業ですら失敗するのに国のシステムなんてどうなってる事やら。

IRRが目標未満とかじゃなくて開発中止か…昔に比べてプロジェクト成功率が高まったと言われてるけどまだまだのとこ山程あるんやね

みんな、「みずほ」みたいにはなりたくないからな。

今の時代は👇これのインパクトが大きいのでSaaSのベストオブブリードが良いのでは。
"出来上がった頃には「時代遅れ」"

受注側が発注側の業務に精通してたり、逆に発注側にシステムを理解している人が居れば良いけどほぼない。
間に優秀なプロジェクトマネージャーが居たらまた違うけど

この20年、ずっと言われ続けているような？🤔

できあがるモノを共有できてないからデスね🐑
そんで、テストでおかしいところをベンダーに確認しないから（テキトーに流すから）、あとから「おかしい」と気づくんです🐑

システム開発ではないけど、要件定義や仕様書作成せず（出来ない）ので、メモ書き程度しか出てこない。それとカネをケチるスケジュールが無理とか、途中修正を繰り返すとか、日本企業。。”

失敗したことも含めて基本は企業秘密だからノウハウが共有されずにあちこちで失敗する

最初によく考えず、途中成果も適当に流し見し、ほぼ完成って段階になって真剣に見始めて「こんなんで仕事ができるかぁあ！！！！」と大暴れする低能が大企業の上に大勢いるから_(:3 」∠)_

ぐちゃぐちゃな業務体系のままではまともな要件定義ができるはずもなく、発注側にIT人材入れても状況はあまり変わらないように思う。システム開発の失敗というより、経営者の課題。／

ベンダー 「派手に大失敗して減損しても、日本全体の GDP にはプラスに寄与するからいいんじゃね？ (ハナホジ)」

ユーザーは、ITゼネコンにすべて任せっきりで
システムができると思い込むが

ITゼネコンは、下請けに丸投げするだけ
ユーザーの意識が高く無ければ良いシステムはできない

まさに日本の問題はこれ。

衝撃的なタイトルだけで中身のない記事と感じた
「経営陣の無知」「プロジェクト遅延」が問題と喚いているだけ
「DX」を「手段」ではなくて「目的」にしてしまえば迷走して「失敗」する、という観点はない
失敗の定義も「当初目標を100%達成できない」としている印象を受ける

失敗例だけ気にして成功したら難易度低く評価する経営陣が多いからでしょ。見直すと結構綱渡り多いから乗り切ったPM以下スタッフ全員を重宝する風潮作らないと。今月18億特損発表したラックが入って無いな

作る人とクライアントがチームって感じになってなくて、vs 構造で、専門家の意見を聞かないからじゃないかなー？とゲスパー。
病気ちゃんと治したかったらお医者さんの言うこと聞かないと。

相次ぐ｢億円単位｣の減損､背景に共通の問題点

無能同士が話し合ってるからしょうがないんじゃね？

どこも非IT企業だな。発注側の問題が9割だろ。

失敗体験を集めて繰り返さないようにすることも大事なんですが、一方で同じくらい成功体験を大事にして「なぜ成功するか」の研究をしていくとより生産的になるかと思います

IPAのガイドラインにも、「要件定義は発注側が行うもので、開発側は原則責任を問われない」とあるよ。
億円単位どころか、数十万円規模の予算のウェブサイトやウェブシステム開発でさえ、要件定義をしない発注者の多いこと。
下らなすぎて、僕は言うのも嫌になっちゃうよ。

"失敗の典型として 記憶に新しいのは、厚生労働省が開発を主導した新型コロナウイルスの接触確認アプリ「COCOA」"

失敗の典型例が政府製。
マイナカードなんて、確定だろ。