2022/06/07 13:30
iselegant
失敗を共有するって結構勇気がいるんだよね・・・Biz側とプロダクト側の相互理解につながるきっかけになったのであれば、会社が良い方向へ進むための投資とみなせるのかもしれないですね。
2022/06/07 14:22
Yagokoro
思い込みって怖いんだよな。俺は市場調査を疎かにして失敗した事がある。
2022/06/07 15:01
paradisemaker
スタートアップスーパーあるある集だ
2022/06/07 15:14
imwks
うまく行かなかったことをどうやって次に繋げるべきなのか？/ ネガティブな部分ももっとオープンにし平準化して残しておく伝えておくことができればいいが/結局工数の兼ね合い、リリース優先だと結局はだめだろう
2022/06/07 15:20
suisuin
現場専門性からの大小判断を無視して社長がどんぶり勘定で命令しちゃうと現場は誰も当事者にならずにたぶん失敗すると思いながら進めて失敗するんだよね
2022/06/07 15:42
osugi828
胃が痛くなる…
2022/06/07 16:18
takatama
失敗談。外注先ができるといったのにできなければ、お金を返してほしいよね
2022/06/07 16:32
udofukui
参考になるー
2022/06/07 16:55
mickey-strange
「開発チームは、必要な工程を飛ばさずに進めたい」のだということをエンジニア言語を使わずに説明できる開発メンバが貴重だということがよくわかる…
2022/06/07 18:04
retore
“「依頼側は任せ切れると思っていたが、本人は元々厳しいと思っていた」” あるあるすぎて草
2022/06/07 18:28
esbee
失敗事例の共有、ええことやね……誤りを認めてそれをオープンにする社風であることがわかって、心理的安全性高そうな職場だと思われることは、エンジニア採用面でメリットになると思う
2022/06/07 18:43
shag
売上拡大/新規獲得に必死な Biz が既存顧客に対する継続的な運用を疎かにする構図よね。どっちも大事なんだけどな "「必要な工程をきちんと踏んで、必要な機能を開発し、お客様に届けたい」思考が強くなる"
2022/06/07 18:51
deep_one
すでに動いているものがあるならのんびり設計をつめればよかったのです…
2022/06/07 18:56
readmemo
弊社で現在進行形の炎上プロジェクトそのままだ！もう大半の人は結構前から失敗だと思ってるけど誰も止められなくなってる。やっぱり色んな会社であるんだなー。
2022/06/07 19:27
sechs
トップダウンで締切のある仕事を無理やり振るとこうなりやすい気がする。締切が元凶なんかな
2022/06/07 20:21
shibainu1969
語られるリスク全てに耳を傾けていたら何もできなくなるし、耳を塞いで突っ込んだら失敗する。たまたまリスクが顕在化せずに成功した経験がある人が、どこかで大きな失敗をしたりする。難しい。
2022/06/07 21:00
T-norf
こういう話って、なかなか表に出ないので、大変ありがたい。少し余裕があるタイミングで、今は何もしないって決断も、地味に難しいのよ。あと、「100人/月」は「100人月」の間違いよね。未経験度合いが伝わるけど
2022/06/07 21:43
Nobkz
失敗をしっかり共有してて、素晴らしいな。
2022/06/07 22:45
saiid
失敗事例をシェアできるのつよい
2022/06/07 23:07
b_wa
すでに動いているものがあるなら、一部ずつ入れ替えていくアジャイルな開発をすれば良いのにと思うんだけど、素人考えかな？そしたら外注不要で内製できるのでは。一気にリプレイスするのはリスク大じゃない？
2022/06/07 23:32
kvx
いい
2022/06/07 23:34
razokulover
"何で開発チームってこんなに消極的なんだろう？"と思う人たちは何が見えてないのかが分かりやすいかった
2022/06/07 23:36
n314
自分も数千万の案件失敗したけれど、特に想定外はなかったんだよな…。ここの要件決まらないと進められないって最初から言ってたじゃん、みたいな。
2022/06/08 00:22
Ni-nja
あるあるだけど撤退判断ができる立場の人からの視点をまとまって読めるのはありがたい
2022/06/08 00:45
napsucks
要件定義が何より大事だね。走りだす方向性を決める。それがはっきりしないで走り出すとみんなバラバラになっちゃう。
2022/06/08 01:02
SundayIsEveryday
経験しないと理解しづらいけど、準委任だろうが委託だろうが、外注規模が大きくなるほど社内リソースも人数が必要になるよね。外注すれば社内リソースが少なくても大規模開発できるとか言う上位者がいると死ねる。
2022/06/08 01:04
mamemaki
一億なら失敗としては安くすんだんじゃないかな
2022/06/08 01:20
boomerangj
認められることはとても良かったと思う。が、みんな失敗して痛い目を見るまではここにたどり着けないんだよな。どんな材料を渡しても自分だけはうまくいくと思ってしまう。素直に権限を渡すんだ。
2022/06/08 01:36
yoh596
"テックサイドの方々からすると当たり前の話ばかりになると思いますが、こんなことも知らない人がいることを認識いただくことで、Bizとの意思疎通のしづらさが少し緩和されるのかもしれません。"
2022/06/08 02:10
endout
いつもこの間に入って調整することが多いが、プロダクト開発の流れを理解できない場合、開発チームから徐々にメンバーが離脱して、誰も居なくなることもある。
2022/06/08 02:31
tonza_dopeness
"リリース予定日の早朝時点で緊急度最高カテゴリの不具合が100以上存在しており、とてもじゃないがリリースできない結果" 思わず笑ってしまったが、こういう現場まだまだ多いのだろうな。お疲れ様です。
2022/06/08 04:55
kazoo_oo
貴重な失敗事例だ。
2022/06/08 05:28
odakaho
システム開発経験のないプロダクトオーナーが、キャパを超えたドンブリ要件を思いついてしまうと良く起こることよね。最悪エンジニアが逃げ出して会社が潰れるけど、致命傷は避けられたっぽいので良い勉強代。
2022/06/08 05:38
quality1
「・絶対にやり切ると自信を持っているテックチームの責任者はいるのか」これ。無理なものは無理って言わないと。
2022/06/08 05:48
gairasu
ここでいう失敗って何だろうか。最低でもQCDレベルで満たせなかった部分を知らないと失敗事例としては使えない。世間話として楽しむしか無い
2022/06/08 06:12
letsspeak
能力と覚悟あるやつに4000万出せば上手くいきそう
2022/06/08 06:53
koogawa
失敗事例の共有ありがたい
2022/06/08 08:25
choota
システム開発に限らない普遍的な事例に思う。やれるやれない、やりたいやりたくない、の意思疎通と共有に失敗すると、チームは死ぬ。逆にできればチームは生きる。
2022/06/08 08:28
exsoul
失敗事例の共有はとても貴重なのでありがたい
2022/06/08 09:21
Xray
1億円って担当者かチームリーダーが動かす程度の額なんだからそんなに暗くならなくても良いのでは。
2022/06/08 09:36
toruhjp
とくに専門領域を異にする相手との対話では、知識量がまるで違うし、察知力には雲泥の差があるから、遡って説明をするべきときと求めるべきときの両方がありますね。
2022/06/08 10:07
strawberryhunter
札束でエイヤーするとたいていうまくいかない。発注側のコミットメントが大切で、外注で欲しい物を手に入れるのは思ったよりも難しい。
2022/06/08 10:22
mayumayu_nimolove
こう言うのがどんどん出てきてほしい。とても参考になる。なぜならあるある話が結構あるから。
2022/06/08 12:07
YassLab
“開発方針が決まった段階で水を差す動きにはなりますが、「本当にこの開発にリソースを投下すべきなのか？」は何度でも考える価値のある問いだと思っています”
2022/06/09 13:03
manaten
この話めちゃめちゃ大事だけど、届いてほしいこれからプロダクト責任側の人は、この人と同じように失敗するまで理解できない話だろうとも思う(この人も深津さんに指摘されてたのに理解できなかったって言ってるし)
2022/06/09 22:27
fellfield
『外部のサポート企業に「可能です」と言われたことだけを信じ、徐々にそれが不可能だと分かり始め』……自分の受託開発では機能を削るように意見することが多くて罪悪感もあるのだが、完成しないよりはマシだよな。