システム開発はなぜこうも｢失敗｣を繰り返すのか

コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕

[BOOOOOOOON]

大体のプロジェクトが「要求定義できない発注者」と「開発できない受注者」の組み合わせなのでしゃーない

[junglejungle]

日本は現場が強すぎるので、現場にやる気がなかったら絶対に無理。積み重なって膨大になった手順や再発防止策を全部入れろとか無茶を言うので開発費が膨大に。悪い意味でお客さん気質なので、過剰機能だらけになる。

[tanatana456]

逆に成功例は給与に合わない高い能力と情熱を持った人達が運良くいたから成功してただけなのかもしれない

[emt0]

アジャイルとか以前の話だしね。経営層が全員IT音痴。シス管は利用のみで産み出しは苦手。社内SEは名ばかりのPC先生。そして誰も責任取らず音頭も取らなく全部ベンダー丸投げで現場が求めてないゴミ出来たら相手に訴訟

[legnum]

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

[ata00000]

id:emt0 現場担当者は要件定義に非協力的で社内SEに丸投げして完成後に文句をいう、も追加で。

[versatile]

開発するから失敗するなんていうクソ意見はおいといて。難しいことをするから失敗する。だから簡単なことを積み重ねていくしかないってのがアジャイルなんだが、だいたいの大きい開発はメテオフォールだから無理なの

[inatax]

トップブコメの「ｽｰﾊﾟｰﾊｶｰ大集合のドリームチームが潤沢な予算とスケジュールを得てまるでダメだったチャンドラーの例」が気になって調べてみたけど全然見つかんない / 追記感謝

[getcha]

「うまく言ったな」という案件を見ると、横串で自分の担当を超えて活躍するスーパーマンがいて上手く行ってない所をカバーしてくれるという、身もフタも無い感想になるな。

[Lat]

なぜ失敗するのかは、DXの成功事例があるのにそれを参考にしないで手探りや経験則で実施したからでは？成功しているカインズホームなりを見習おうよ。

[altar]

「失敗」が打ち上げ中止的な文脈のアレなのかそうでないのか、全文読んでもわからなかった。解釈に困るカギカッコを付けないで欲しい。サブタイの「億円単位」に至ってはカギカッコの情報量ゼロじゃん。

[xlc]

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

[rck10]

正確な見積もりも出来ないのに期間と予算をギリギリまで詰めるから、大体のプロジェクトは予定超過になる。最初から2～3倍の期間と予算があれば"オンスケ"にはなると思うよ。

[hiroomi]

“開発を断念。これに関わるソフトウェア仮勘定について、154億円の減損損失”

[kagoyax]

どっちもやってる自分だから言えるけど記者のあんたが3ヶ月でも現場放り込まれたらなぜ失敗を繰り返すのかわかるだろうな。取材とか原稿とかそんな簡単なもんじゃねーのよ開発ってのは

[kagerou_ts]

「現場任せ、専門家任せのままでは」むしろ現場に予算とスケジュールの裁量がないからご覧の有様なんじゃない。納期最優先で「いわれたまま」のもの作ったらまあそうなるて。

[kura-2]

目的に対して実装だけでなくお金も追い付いてないってのもありそう。変なコストダウンを狙った開発や必要な予算が全然つかない案件の話は多いと思っていた。

[snare_micchan]

事例に、昔仕事でお世話になった会社が…上手く行ってないとは聞いてたけどまたかい…

[aaasukaaa]

「原理原則[9] 要件定義は発注者の責任である」 https://www.ipa.go.jp/files/000005109.pdf

[uuchan]

今まさに失敗しそうなDXに取り組んでるうちの会社、どうにかして少しでも損失の少ない方向に行って欲しい。むしろ止めたい。社内で評価されるために「やってる感」出す活動とかもう最悪。

[homarara]

おい顧客。「要件定義ではステークホルダー全員が必ず聞き取りに応じろ」「設計工程終わった後に仕様を変更したきゃ、二次開発まで待て」「受け入れテストは十分にやれ」そんだけ守ればシステム開発は失敗しない。

[Shalie]

要件定義の甘さ、ベンダー選定段階での失敗などを挙げているけど、少なくとももう一、二段掘り下げないと何も語っていないに等しい。

[fu_kak]

失敗する理由はこのはてブの星つけてるコメントみたいな人ばっかりだから、というようにも思う。賢いことが価値を生むわけではないってことだよな。つまり賢しいのだ。

[at_yasu]

ムズカシイアルネー

[gecko_a5]

Fit to Standardをトップダウンで指示できない会社は、業務側の要件を聞きまくって既存システムと同じものをスクラッチ開発することになり、えてして失敗しがち。

[rlight]

要因として、ベンダーとのコミュニケーションや要件定義の問題、リリース後の不具合の問題、経営層の無理解、を挙げている。必要な全てのピースが揃っていても運や時代に左右される部分がありそう。

[hatayasan]

「発注者側が門外漢ばかりでは、ベンダーとのコミュニケーション齟齬に陥るリスクがある」

[Cichla]

ピーターの法則のシステム開発版ないのかな。「システムは開発能力の限界まで膨れ上がる，よって必然的に失敗する」とか。

[ichiken7]

何もしない中抜きやが噛むから

[natu3kan]

大企業に頼むとしても既存の安定性のあるパッケージのカスタムにしないで発注者が業務知識も理解しないままフルスクラッチしようとするとか。業務側がITに合わせてデータや業務を作り直さないとか、いろいろありそう

[Karosu]

それは、完了させるより、開発を始める方が儲かる仕組みがあるから、失敗すると思うよ

[awkad]

これでベンダが小さい会社だと損害賠償請求しても結局払えない。さらに「なんでそんな小さいところに発注したんだ！」と発注担当はお叱りを受ける。かくして大手SIerに発注しよう、となる。

[toro-chan]

予算が潤沢で失敗した場合と、そうでない場合で分けてほしい気はする。なんとなく予算が潤沢で失敗した例はないような気もするけど、、

[yogasa]

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

[matsui]

顧客現場の多くはヤル気を出すと周囲からバカにされる雰囲気を感じる。

[moqojiy]

過去を捨てることができないからだと思う。シンプルなシステムを作ってそれに運用をあわせるなら成功する。

[shibainu1969]

システムとビジネスの両方が分かる人はこれから引く手あまた。

[coffeeglass]

T社が駄目すぎでボロボロになって崩壊した特許庁案件がリストにない件。

[mmuuishikawa]

パッケージを使えよ それか内製

[Finding]

コメント欄がうなずきしか出ない。プロとしてはそれでも成功に導くべし、とは思うけどね…。