【IT】「神様が来て全てを壊した」 繰り返される仕様変更、本当にあったAIプロジェクトの怖い話【メテオフォールの現場】
■ このスレッドは過去ログ倉庫に格納されています
https://image.itmedia.co.jp/news/articles/1903/20/l_abeja_sixtry_01.jpg
AI(人工知能)ベンチャーのトライエッティング(愛知県名古屋市)の長江祐樹社長
「人事系のAIシステムを8カ月で作ってほしい」――この依頼から、全てが始まった。
AI(人工知能)ベンチャーのトライエッティング(愛知県名古屋市)の長江祐樹社長は、同社が体験した“大炎上プロジェクト”の経験を振り返る。
同社は企業のAI活用を支援するAI専任のSIerだ。ヒアリングから設計、業者選定、施行管理や納品までを一括で担当。実際のシステム構築はベンダーに委託し、上流設計やアルゴリズム構築などを担う。
2016年創業の若い会社だが、早くも炎上プロジェクトの洗礼を受け、そこから大きな学びを得たという。19年3月現在も進行中のプロジェクトの話だが、学びを生かして状況は改善。いまは順調にプロジェクトを進めている。
長江社長は、18年にネットで話題になった「メテオフォール型開発」そのものだったと当時を振り返る。メテオフォール型開発とは、顧客の要望でこれまでの要件定義や基本設計などの仕様がひっくり返り、プロジェクトがうまく進まない様子を表現したもの。神様が気まぐれで全てを滅ぼすメテオを発動するという意味だ。笑い話のような内容だが、実際に体験した人たちは全く笑えないだろう。
神様降臨(2人)とメテオ発動、その後の対応までを、3月5日に開催されたAIイベント「SIX 2019」で語った。
□「IRに書いちゃったから、2カ月前倒しでよろしく」
問題のプロジェクトは、「人事系のAIシステムを8カ月で開発する」というもの。現場部門の担当者が人事担当にシステム開発の要望を出し、情報システム部が要件を取りまとめてトライエッティングにPoC(概念実証)を依頼した。トライエッティングはシステムの上流工程の設計とアルゴリズム構築を担当し、システムのユーザーインタフェース構築はシステムベンダーに再委託した。
現場担当や人事担当もモチベーションが高く、開発から3カ月ごろまでは順調に見えた。しかし、ある日突然「裏の決裁者」という人事担当の上司が登場。「役員が期待してIRにプロジェクトの内容を記載してしまった」と告げられた。クライアントにはPoCの結果が良かった旨を報告していたが、予想していなかった事態になった。
https://image.itmedia.co.jp/news/articles/1903/20/l_abeja_sixtry_02.jpg
「裏の決裁者」が登場
人事担当の上司は「スケジュールを2カ月前倒ししてほしい」と続けた。社名付きでIRに書かれてしまったためトライエッティングは断ることもできない。同じく“寝耳に水”状態の情シス担当と協力し、何とか間に合うようにプロジェクトの仕様やスケジュールを変更した。プロジェクト開始から3〜4カ月目の出来事で、あと2カ月しか時間がない。
その後、スケジュール通りに何とかリリースにこぎつけたが、ここで1人目の神様が登場する。
>>2 に続く
2019年03月20日 13時27分 公開
ITmedia NEWS
https://www.itmedia.co.jp/news/articles/1903/20/news092.html >>1 から続く
https://www.itmedia.co.jp/news/articles/1903/20/news092_2.html
□「使い勝手」と「スケジュール」 2人の神様に挟まれて
1人目の神様は現場部門から現れた。どうやら、情シスが固めた要件定義に現場からの要望が十分に反映されていなかったらしい。現場の神様は「現場はもっと○○な機能を求めている」と仕様変更を求める。人事担当の上司は「現場がこう言っているし、あと2カ月待つから実装してよ」とむちゃぶり。情シスとトライエッティングがそのあおりを受けることになった。
要件定義だけでなく、AIやユーザーインタフェースも実装し直しだ。全て実装が完了するまでに、プロジェクト開始から12カ月がたっていた。すると、新たな神様がコーポレート本部から登場した。
情報共有が不十分だったため、本部はプロジェクトが8カ月で終わるものと思っていたのだ。本部の神様は納期がずれ込むことを嫌い、当初のスケジュール通りに終わるよう、情シスに他の会社を探すよう命令した。
https://image.itmedia.co.jp/news/articles/1903/20/l_abeja_sixtry_03.jpg
2人の神様
情シスは10社ほど要望を実現できそうなAI会社に相談したが、どこも断られたという。長江社長は「いま思うと、われわれは相当しんどい技術的要求を乗り越えていた」と苦笑する。
現場の神様も黙ってはいない。新たに実装したシステムを提示すると「Excelレベルの、もっと使い心地のいいものが欲しい」と要望はエスカレート。現場の要望と納期、2人の神様の板挟みにあい、トライエッティングは苦しい状態だった。
□「4月から人事構成が変わる」 ダメ押しのデータ変更
災難はまだ終わらない。何とかシステムのリリースにこぎつけたが、本部の神様は無慈悲にも「4月から人事構成図が変わり、従業員の所属IDも変わるからデータ変更に対応するように」と告げた。
https://image.itmedia.co.jp/news/articles/1903/20/l_abeja_sixtry_04.jpg
度重なる仕様変更で疲弊する現場
社員のマスタデータが全て変わるため、1件1件IDを振り直す必要が出てくる。せっかくシステムが完成したのにデータの問題で動かないという事態に陥り、このころからトライエッティング社内で「メテオフォール型開発」というワードがはやり始めたと長江社長は苦笑しながら思い出す。
>>3 に続く >>2 から続く
https://www.itmedia.co.jp/news/articles/1903/20/news092_3.html
□「プロジェクトの成功はチーム構成で7割決まる」
難航したプロジェクトも、いまはチーム構成を工夫したことで比較的順調に進んでいるという。長江社長は「プロジェクトの成功はチーム構成で7割決まる」と豪語する。
具体的には、神様たちとも情報の共有漏れが起きないよう工夫した。第1会議体として現場担当、人事担当、情シス担当、トライエッティングで話し合いを行い、第2会議体として現場の神様と人事担当の上司との定期ミーティングを設定。本部の神様には会議の内容を定期報告する他、第1会議体のメンバーも直接コミュニケーションできるようにしたという。
https://image.itmedia.co.jp/news/articles/1903/20/l_abeja_sixtry_05.jpg
チーム構成を工夫した
「現場の神様にもミーティングに入ってもらうことで、われわれが頑張っていることが伝わりやすくなった。プロジェクト進行においては依頼者側の安心感も必要」(長江社長)
また、長江社長は「長期的にみたシステム構築をする際、データ仕様の変更は必ず発生するので、それも込みで設計すべきと感じた。今回の件で、5年使ってもらえるシステムを構築するにはどうすればいいのかを考えるきっかけにもなった」としている。
データ仕様が変わっても柔軟に修正やアルゴリズムの追加ができるシステムのカスタマイズ性、実装の際に大幅なリプレースが不要な従来システムとの結合性、大規模なデータ処理や大量のクエリをさばけるシステムの冗長性など、技術的要件を抑えておくことも重要だ。
AIプロジェクトは長期的に取り組むことが前提になることが多い。失敗から学べることは多そうだ。 なにが「神」だよw
文系(あるいは理系のくせに文系同然)のクズ老害どもじゃねーかw 日本って、どこもかしこもクソみたいな組織だよな。
今まで中国や朝鮮に滅ぼされなかったのが不思議なくらいだよw AIに限らずこれはあるある事案だわ
情シスが取締役側に寝返るのは普通のこと 被害者ぶってるけど、
現場のヒアリングをサボった間抜けの話だろ >>7
それを言わないクソ営業な
「今後もあるから戦略的赤字で」とか本気で死ね >>1
普通にある事案だろ
しかも人事構成や部署の異動とID変更なんて普遍的に繰り返す変更後とでしょ
そんな当たり前の仕様を想定せずにいたプロジェクト責任者の能力不足だろ プロジェクトというのは、お客さんの担当者の上司をいかにして以下略 まだ完成していないけど、順調みたいだか、この調子で AIは別に関係ない話でトライエッティングってところの
マネージャーが経験不足だっただけという話だね 納期が示された時点で組織が変わる事は分かるんじゃないか。
あと一発目は現場要望は無視しとけよw
改修でいいだろw しょうもない相手と取引したということを学習すれば、次は失敗しない。
何故ならその相手とは二度と取引しないから。 >同社は企業のAI活用を支援するAI専任のSIerだ。ヒアリングから設計、業者選定、施行管理や納品までを一括で担当。実際のシステム構築はベンダーに委託し、上流設計やアルゴリズム構築などを担う。
中抜きしかやってなくて、しかもAIwwwww
詐欺会社やね そんなもん突っぱねないで炎上するような会社は潰れろ そもそも内容も決まってないのに締め切りを設定してる時点でアレだろ
最初から間違ってる 別にAIに限らず日本の仕事って昔からこんなもんだけど
設計やプログラムで、あってもなくてもいいものを高額払って、わざわざやらせるなら尚更w
神様がどうだってより、足元見て、最初からなし崩しで押し切るつもりだった?
若い企業家がいい経験をしたってだけの話
よかったじゃんw 相手には金の話より先に「納期延びますよ」だよね
できないものはできないんじゃい! 「何で俺が異動なんだよ、左遷じゃねーか。誰が決めた、え?人事の誰だ?」
「それがですねー・・・実はAIが導き出した結論でして・・・」
↑
「ねっ?こんなやつだよ、こんなやつ、こんなやつ作ってよ、頼んだよーはっはっは」 神w同士が最初からラグナロクしとけばいいんだよ
共倒れだとなおいい >>15
全体的に20世紀にコボラーが経験したことを21世紀に繰り返してるようにしか見えない AI開発なんかクソのつく素人だけど
何でそもそも契約時点で、発注元がカッチリ詳細を詰められてないわ
違う部署からコロコロコロコロ矛盾するような要求だされる点を反論せんのん?と思ったけど
ここまでのレス見てやっぱり発注元がクソなんだなと納得した >>31
エンジニアの言うGodは悪口だよw
ゴッドメソッドとかゴッドクラスとか >>1
最初に無断でIRに書かれた時点で裁判に訴えれば良かったな
賠償金で儲ければ楽 ITMediaって、ソフトバンクグループなのに、予算無いんだな。
画像がいらすとや どこかに月額定額制のSIerがあったな。
これなら発注先も受け手も最悪一ヶ月の我慢で逃げることが可能だ >>32
会社も若いし、経験なかったのだろう
そのレベルでプライム取るのもどうかと思うけれど
生きているならいい経験と思うしかないな
客としてはいい練習台にされたようなもんで散々だけど
見抜けなかった落ち度はあるし ◆【虎ノ門ニュース】3/20(水) 井上和彦×藤井厳喜
https://freshlive.tv/toranomonnews/265487
・国産ミサイルの射程を延伸へ 事実上の長距離巡航に
・奄美 宮古 南西地域で陸自駐屯地が続々と拡充
・英議長 3度目の離脱案採決否定 メイ首相再び難局
・NZ銃乱射テロ 3ヵ所目のモスクも襲撃計画
・昭和の英雄が語る大東亜戦争偉大なる記憶(沖縄戦 同期の戦友に託された言葉)
・視聴者からのメール(大叔父も水上偵察爆撃機“ 瑞雲”に乗っていました)
・自衛隊員2人4月中旬派遣 シナイ半島停戦監視
・和牛受精卵 中国の牧場が依頼か
・改憲「政治責任果たす」安倍総理が防衛大で
・商品券 9月出生まで拡大 消費増税対策 間に入る人間が多いほど、仕様もカネも無駄が出るって事だよね AIとか社外とか関係ない
「社内だけでこれが起きる」
「社内にメテオフォール開発しかない」
これがうちの現場
俺はもう無理 金をもらえるなら炎上も結構じゃないですか。何が不満なんですか?
足りない工数は割り増し前金の請求書と契約違反による破棄を客に選ばせれば
何も問題もないですよ。トラブルは金に換えればいいんです >>47
経営者的にはな
エンジニア的にはたまったもんじゃない
歳だけとって無能になる 既に書かれてるけど、人事構成変更の件は開発者のミスだよね
人事変更対応は、2次開発予定だったというのなら理解できるけど、
最初から想定外なのは、マヌケとしか言いようがない
自分達のミスをクライアントに転嫁してるだけ
あと、それまでに付き合いのない客なら、
規模の大きい開発中の仕様変更やスケジュール変更は、
料金に反映することや、変更の限界を客に理解させておかない事が
そもそものミス 一番偉そうなのが後から出て来るとかアホな会社だな
その会社はメテオフォールと呼ばれよう
で、どこ?w そもそも一旦完成させて
そこから変更要望あげろよ
こっちは付き合う義理0.0001%もねーんだよ どうせ神の言うとおりにしたって現場の本当の作業者に使わせて見れば
百個以上の改善要望が上がってくんだろ?
まず繋がった時点で一回使えよ
そこからこうだったらいいなをあげろよ 発注側がgdgdなんだからプロジェクトがgdgdになるのは当然
ちゃんと作業内容を契約で縛っておかないからこうなる 神じゃなくて典型的なデスマーチじゃねーかw
IRに書いちゃったから前倒しとか無茶だろ。 >人事系のAIシステム
まず、これが意味不明だわなw >>56
人事考査とか配属判定とかにAI使うのは割とある 追加利用金を請求しないのが理解できない。
納期を2か月早く→追加料金請求しろよ。
仕様変更→追加料金請求しろよ。
再度の納期変更→追加利用金請求しろよ
データの差替え→追加料金請求しろよ
等など… よくある話
営業が安請負しちゃうことはどんな企業でもあるでしょ
IBMでもそういうことは起きる
社内レビューとかきちんとしたルールはいろいろあるけど
それでも営業は突っ走るからね データが変わったら動かないって何それ?
銀行で新規に顧客が口座を開設したら動かなくなるシステムなんてないだろ? >>1
要は仕事の段取りを無茶苦茶甘く見てましたと しかもAIなんて効果は数値で測れないぞ
納めた後でも文句言われて金を払ってもらえないだろ、このクライアントでは >>3
これ、契約したやつが無能だろ。
イラストレーターなんかの契約に多いんだけど、ラフの段階で許可もらったら、その後の変更にはその都度追加料金が発生するようになってる。
計画出して許可もらった時点で金銭要求する契約にして、変更の場合は追加で日程と金銭要求して、途中で辞めてもそれまでの金額は請求できるような契約書作らないと。馬鹿が永久に仕様変更してくるぞ。 仕様 要件もよう決まらんで発注するなんて青天井恐ろしすぎて出来ないわ >>1
仕様変更のたびに料金は N 回ならば最低 N 倍を課すのは当然の権利だ プロジェクトには現場に精通している人間を一人入れろと30年前の教科書に聞いてあるぞ。
ステークホルダーを洗い出し、根回しするのも常識だ。 >>20
話からだと交渉してない様子。
その辺語らないと内容無い。
頓挫して、訴えられたら負ける。 >ITmedia NEWS
この記事書いたやつ、駆け出しのシロウトさんだってわかるわ。
おまえらのほうが、地獄の経験が豊富だし、現実を的確に描写してる。 >>25
弊社は~以下に並んでるタスクからして、結局、何もやってないのに「一括」とは如何に
上流設計までベンターに投げて相当な恥知らず ワイ極小法人のプレイングプレジデント
ここ変えろって後でいわれるなってところは大体分かるんで
あらかじめ備えて設計しておく(無論簡単に変えられることは顧客には伝えない
仕様に潜在する問題もあえて指摘しない
案の定、変更が入ったら
先方には「今更困難」と伝える
で、大きい追加工数を貰う
あとは鼻歌歌いながらチョイと変えて仕上げて
数日遊んで納期夕方に納品
中小は元請けから絞る賢しさがないとダメよ 長いけど、どうせ馬鹿どもがデスマで死んだって話だろ?くだらん! 現場のマネジメントくらいしろってw
相手の要求聞いてたんじゃ仕事終わらんぞ
会議体の話じゃない >>11
どっちかってうとそんなのホイホイきくなよと思ったが。 >>56
>>人事系のAIシステム
>
>まず、これが意味不明だわなw
トライエッティングのメインプロダクトは、今年9月にリリースした「HRBEST(ハーベスト)」。過去の採用実績のデータから新しく採用する人材の成長率を予測できる”人財”管理AIです。
ってことみたいよ。
https://nagoyastartupnews.jp/tryeting-pre-series-a-fundraising/ 顧客側の情シス部門が弱いとこうなるという典型的なパターンかな。
情シス部門が社内をまとめなきゃダメだよ。 >>78
AI(的要素、もどき)をちょっと入れたみた人事系システム、だろ
少なくとも>>1は、中身がAI系だから特に起きた、起きがちだというものでもないだろう 未だにこのレベルの発注なのかw
ほんと文系が上司になる会社は駄目だな まだAIなんて言ってるのか
単なる判断ルーチンだろ しなくていい無駄な努力で達成感感じるバカは要らない このプロジェクト、当初見積もりの10倍吹っ掛けても安いだろ 自分も文系で、文系が分かってないくせに理系を牛耳って勝手な事や面倒を押し付けてる
事はよくある事で行けない事だと思うよ。
この場合のクソな文系は発注元の会社ではなく受注側の営業だろう。
ある程度は発注側を啓蒙しつつ進めて行かないと。 ステークホルダー達を無理やりにでも引っ張ってこれる政治家が
プロジェクトにいないとこうなる 文系とか関係なく、そもそも説得できなかったのは
まずいと思うぞ。
最初から顧客の言うこと鵜呑みはまずいぞ。
そんな営業なら赤ちゃんでもできる。 たぶん開発の計画や進行が00年代みたいな杜撰な感じだったんだろうねw
単純に>>1の開発経験不足だと思うわ。
「お客様は対面の情シスだけ」という思い込みで工程ごとの検収も受けずに勝手に開発を進めていたという、
昔の業務システム開発によくあった話を今更「メテオフォール開発」というバズワードで新しい話のように言ってるだけだろうな。
AIを使いこなす賢そうなやつに見えるのに残念なやっちゃで。
>>90
それ政治力云々ではなくPMOを置けとか言い古された話だぞw >>91
おそらく圧倒的に経験値不足でようするに受託開発をするには素人集団だったんだと思う。
まあ、ナレッジとしてノウハウが一般化されていない事柄だけに倒産しなくて良かったねwというところだろうな。
今頃、反省会と称して「失敗の本質」あたりを頑張って読んでそうだけどw まあ、失敗の原因を政治力云々ではなくチーム構成、
つまり組織論に求めたところから見て根本的なところから馬鹿なやつってこともないと思うね。
天才的ではないが経験を積みつつ上達する素材だろうとは思う。 >>90
いらないよそんなの
一生仕様変更で金とってやる
重要人物とワザと会わない 受け入れ部門がゴミだと何もうまくいかんわな
真の顧客は誰かを探して調整するのはSEの仕事 >>41
人の手で作られたもので壊れないものがあるのか 「よくわからない会議ばかり多くて全然進まない」とかいうプロジェクトはこうやって生まれる うちもシステム屋だけどこんなの日常だよ
クライアントからの仕様変更が急に降ってきて
人件費が追加でかかるから予算増やせっていうと
「そこをなんとか」ってタダでやってくれと言ってくる
できないと突っぱねてもそのワガママを言ってきたのが役員か社長で
その担当者がそいつらに予算の話をできないヘタレらしくて
結局こっちに無理をねじ込んでくる
うちの営業窓口もそこは大口取引先だからとタダでやってとねじ込んでくる
俺ら現場が突っぱねるとうちの役員や社長がいいからタダでやれと落としてくる
で、結局タダでやってやる
これでうちとその会社とのやりとりがなあなあ関係になって後でこっちが損をする羽目になる
こういう会社って数年後絶対に潰れてるんだよね >>6
中国はわかるがなぜ朝鮮に滅ぼされるの?いや、文明のレベルの低さの前に規模的に小さいでしょ >>3を見ると、俺が一人でこなしてるレベルのシステム規模っぽいな
俺から一つアドバイスしておくと、運用予算で実装技術が変わってくる
実装技術が変わってくると、システムの最大ポテンシャルも変わってくる
だから実装技術の中では最大限のチューニングを施して、平時の100倍までは対応出来る技術を投下しておくこと
実装技術の変わり目は、DBインスタンスを基盤として使う、メモリ技術を基盤として使う、といった所。 ■ このスレッドは過去ログ倉庫に格納されています