デロイトに続いてアクセンチュアも?!
なかなかの金額ですね。
日本通運が基幹システムの開発失敗を巡ってアクセンチュアを提訴、124億円の賠償請求 | 日経クロステック（xTECH）
https://xtech.nikkei.com/atcl/nxt/column/18/00001/09779/
日通、新・国際航空貨物基幹システム開発を断念 | LOGISTICS TODAY
https://www.logi-today.com/526733
> 開発プロジェクトの開始は2017年4月25日。当初は3年4カ月の開発期間、委託料の総額は123億4400万円（税抜き）と見積もっていた。
SAPでなく大規模スクラッチでしょうか？
煽りたいだけではなく…振り返りの共有をお願いしたいですね。
顧客に影響は出てないけど損害賠償請求されてる分、デロイトよりマズいとも捉えられますね
デロイトも水面下では進んでるかもしれませんが
時期がチュアのほうが早かったからでしょうね。
リリース前なのでまだマシだと思います。
グリコは4ヶ月？ほどの出荷停止なので、デロイトのほうがまずいと思ってます。
悪戦チュア
座布団1枚！
ニュース出たからか今日の今日で事例から消されてました…早い。
wayback machineで見れます。
日本通運：サプライチェーンの変革：世界的ニーズに応える ｜事例｜アクセンチュア
PRのリスク管理とアピールのうまさは素晴らしいですね。
何年か前にユーザー側と仕事した事はありますが、石橋叩きすぎ、予算削り過ぎだった印象。
うーん、基幹系なので石橋叩くのは悪くないと思います。
ただ感覚とか気持ちとかでなく、ファクトに基づいて判断してる(チュア側が提示することが前提)かどうかだと思いますね。
この案件とニアミスしてた＆多少その界隈の経験があるのですが、国際物流の基幹システムって本当にカオスだと思います。
アレに手を出せるなんてさすがACさん！と思っていた人も少なくなさそう。
いやあ、ホントそうですよね！私がちょっと覗いたのは海の方ですが、歴史的経緯と国際物流に絡むステークホルダーの多さには目眩がしました。貿易って世界でも指折りに古い事業なんだなあと思った次第です。
輸送伝票（船荷証券、BL）が有価証券になるって最初は意味がわかりませんでしたが、｢最初（東インド会社ができる前）は、船を出すたびに会社を作ってたんだよ｣とか、｢コンテナ（docker containerではありません）は、輸送をアウトソースする嚆矢となった革命だったんです｣などなど、話を聞いていると世界の歴史を紐解かれている気分になりました。
両社とも色々やったことあるので思うのですが、、、NXさんはこの手の失敗が多く過去に某外資ITでも失敗しててもっと少額で見極めるべきだと思いますし、もっと芽のあるところに投資継続をした方が良いのかなと、、、
ACさんはことシステムについてはIT業界の下請構造を社内で確立して対外的に見えなくさせてるだけなので開発クオリティは、、、ですし上流の営業要素ばかり強く、開発周りに関してはIT業界への悪影響含め本当に印象良くないです。。。（諸々個人的な感想です）
https://xtech.nikkei.com/atcl/nxt/column/18/00001/09780/
これ見ると、ITbでバグが出まくった成果物しかでてこなかったことに日本通運側は切れていて、アクセンチュア側はITbなんだからユーザー側で打鍵チェックなんかするなあとで修正するんだから、って言ってますね。
このレベルで裁判になるってことは、問題が発生した後のトップレベル合意がうまくいかなかった印象を受けます。
偉い人通しで仲良くやれてればこんなことにはならなかったんじゃない？とか第三者的に勝手に思っています。プロジェクトを主導した偉い人が転職しかとかいなくなったとか。
まあアクセンチュア側も、うまくいかなそうだからこれ以上開発はやりたくなくて、それを日本通運側も察知したからこんなことになっているんじゃないでしょうか。
全て何も知らない個人の妄想です。
その記事読んで同じ印象を受けました。
実際のITbとしての品質、テスト計画の合意がどうなっていたか気になりますね。
アクセンチュアのプロジェクトフェージングを知らないですが、ITbのあとで採番要件みたいな基本的なトランザクション制御に関わるところを直すフェーズってあるのかなあ。｢順序性なし採番｣、｢順序性ありで抜け番許容｣、｢順序性あり抜け番なし｣みたいに要件と並列性のトレードオフ別に機能コンポーネントが全部用意されてて切り替えるだけならできるかもしれませんが。。。
金融以外で100億超えのウオーターフォール案件の話を久し振りに聞きました。
やっと有料部分読めました。
これはさすがにNX側が分が悪いように見えますね。
採番方法は仕様書でも合意してそうですし。
日本通運・アクセンチュアのシステム開発訴訟、裁判資料を読んで胃がキリキリした | 日経クロステック（xTECH）
https://xtech.nikkei.com/atcl/nxt/column/18/00138/092601608/
この記事だとアクセンチュアが悪者感出てますね。
真相が気になります。
ところで日経クロステックのタイトルは個人ブログみたいなノリなんですね😅
この記者さんが読み取った範囲だと、排他制御は楽観ロックしか想定していなかった模様ですね。
15年ほど前に金融系のシステムを見ていた感覚としては｢100億超えのSIでそんなことある？共通機能チームは何してたの？｣という感覚ですが、最近の基幹系SIのトレンドはそうでもないのでしょうか？
# ロールバックを考慮すると悲観的排他制御でも抜け番は防げないので、もうちょい細かい作り込みがいりますが、それはそれということで、、、
一部記事にあった伝票番号が連番になるように悲観ロックすべしという日通の指摘でしょうか？
これはどちらがあるべきとかはなく、性能やら、連携先システムの制約や、現行踏襲(個人的には意味があるとは感じませんが)などを加味して両社で決めるべき点だと思います。
よくある話ですし、要件定義で握ってると思うんですけどね。
握れていたかどうかで言うと、裁判の文書に登場している以上、「握れ」てはいなかったのではないでしょうか？アクセンチュア側の説明不足、日通のIT部門がエンドユーザーと意思疎通ができていなかった、など可能性は色々ありそうですが、こうやって係争の一要因になっています。
業務システムのカバー範囲が大規模になると、単一のトランザクション制御要件では対応できないことが多く、システム全体としては「ある仕様で合意する」では済まなくなります。そのため、大規模なプロジェクトでは”共通機能”とか”フレームワーク”といった呼ばれ方をするチームが多様な非機能・機能要件に応じた枠組みを用意し、アプリ開発を担当するチームが業務業務要件や平衡性要件に応じて適切なものを選択するやり方を多く見てきました。今回のケースだと、採番の要件に応じた仕組みや、排他制御のポリシーあたりが該当するかと思います。そのような体制になっていれば「ある業務がどれを選んだか」という話であり、間違っていれば（並行性の制約の範囲で）選び直すことができます。
ところが、今回はアクセンチュアが「普通は楽観的制御をする、悲観的制御を要求するのは日通の特殊な業務要件だ」といった主張をしていて、そこに違和感を持ちました。私も最近の事情をよく知らないので、現役で大規模な業務システムに携わっている方に「最近の基幹系SIのトレンドはそうでもないのでしょうか？」と問いかけた次第です。
はい、概ねおっしゃることはわかります。
今回は日通の主張が主なのでなんとも判断が難しいですね。
わたし自身大規模基幹システム屋さんでして、同様の係争案件(勝訴してます)に携わったことありますが、ちゃんと説明、証跡残しまくりの仕様でもいちゃもんつけられまくったのでなんとも…
アクセンチュア側の主張待ちですね。
要件定義や設計フェーズの納品をしてるはずなのに、ITbで指摘してくるのも不思議な話なんですよね🤔
これもSAP絡みなのかな？
なんとなく違う気がしてます。
外資IT営業の給与ガイド
#給料
#営業
外資IT営業の給与体系・株式報酬、期待できる年収値や上がり幅を、WorkCircleのユーザー様且つパートナー企業チャレンジャーベース社市川さんと、外資エンタプライズ向けソフトウェア(SaaS)営業の経歴を持つ西村さん共同で記事にしました。
RSU完全ガイド(確定申告用スプレッドシート付き)
#給料
外資企業で多く採用される給与の一つ、RSUの構造や仕組み、リスクや確定申告方法に関してWorkCircleのユーザー様、且つパートナー企業チャレンジャーベース社代表の市川さんと紹介します。
外資・日系IT企業のRTO(オフィス出社)状況リスト
各企業のRTO(オフィス出社)状況をリスト化しました。 提供元データは所属企業が証明されているWorkCircleユーザーによるものです。 希望する働き方や転職先を決める軸の一つとして、是非参考にしてください！
