物流大手の日本通運が、航空輸送事業におけるグローバル共通基盤の構築を目的に進めていた「新・国際航空貨物基幹システム」の開発失敗を巡り、開発ベンダーであるアクセンチュアを訴えていたことが日経クロステックの取材で分かった。以下ではアクセンチュアが提出した第1準備書面を基に、日本通運の主張に対する同社の反論を読み解く。 アクセンチュアが最重要争点として挙げるのは、結合テストの後半フェーズ「ITb」に関する債務の履行を完了したことだ。日本通運は訴状で「アプリケーション開発業務」など4件の個別契約が債務不履行になった結果、システムは完成せず基本契約書で締結した「システムの完成義務」に違反すると主張していた。 アクセンチュアは請負で締結された上記4件の個別契約について、債務を履行していると反論する。同社の主張によれば、請負契約において求められるのは「仕事の完成」だ。検収は「仕事の完成」とは独立した手続
物流大手の日本通運が基幹システムの開発失敗を巡り、約124億9100万円の損害賠償を求めて開発ベンダーのアクセンチュアを訴えていたことが日経クロステックの取材で分かった。 日本通運の親会社であるNIPPON EXPRESSホールディングスは2023年1月、基幹システムの開発が当初計画に比べてさらなる開発コストの増加と開発期間の延長が見込まれることなどから、システム開発の断念を決定したと発表。2022年12月期の連結決算で154億円の減損損失を計上した。その後、日本通運は2023年7月12日、アクセンチュアを相手取って東京地方裁判所に提訴していた。 計5回の検査で大量の「不具合」 訴状によると、日本通運は航空輸送事業におけるグローバル共通基盤の構築を目的に、国内外のシステムを統一した「新・国際航空貨物基幹システム」を開発することとした。開発プロジェクトの開始は2017年4月25日。当初は3年
https://u6bg.roads-uae.com/HighWiz/status/1817197569099051158 マリーアントワネット「検証機がないなら，本番環境を使えばいいじゃない。」 これに対し，日本のITエンジニアたちは激おこである。 そして大半が本番環境でテストをするのはけからんという話に終始している。これが日本の姿である。 まるでオライリーの「オブザーバビリティエンジニアリング」で書かれていた本番環境をガラスの城として扱っているパターンそのものって感じがある。 https://netflixtechblog.com/tagged/chaos-engineering 一方，Netflixのようなグローバル大企業はすべからく本番環境でテストを行っている。 彼らは惑星規模の計算資源とその上で稼働する大規模なマイクロサービスを運用しているので，事実上，本番環境と同等の検証環境を作ることができない。 さら
今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と
うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。 バグが直った時に、slack上では開発チームに「修正ありがとうございます」って送ってるけど、なんで自分たちが「ありがとうございます」と言っているのかよくわからない。 開発チームが品質の悪いシステムをつくって、 お客さんがバグを見つけて怒って、 カスタマーサポートがお客さんのサンドバッグになって、 開発チームがバグを直して、 カスタマーサポートが開発チームにお礼を言う。 なにかがおかしい。なんだこれ。 自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。 カスタマーサポートはお客さんをサポートするための仕事なんだよ。 不出来な開発チームのための緩衝材じゃないんだよ。 本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。
オープン系の歴史は、基本的に汎用機との戦いでした。個人的にも自分の戦いも、わりとまじめに汎用機との戦いでした。Linux? おもちゃですね。Java? 飲めるの？Object指向? 品質高いの? ・・・まぁこんな感じでしたね。確かにLinuxはもはや標準になりました。Javaでの開発は普通になりました。Object指向以外の開発はまぁ普通にないですね。・・・しかし、残念ながら基幹バッチは未だに汎用機です。汎用機は未だに現役であり、基幹処理の根っこは、いまだ汎用機で動いています。信頼性は突出しているし、パフォーマンスもバッチ処理に関しては依然として最強だと言えるでしょう。新人COBOLな人のバッチが、ハイパーなOracle使いのSQLバッチを軽く凌駕する事は、まだ普通にあります。・・・なぜか？ 多重度が違いすぎますね。 汎用機はハードウェアからOSレベルまですべて、多重度が上がる事を前提に処
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
日本郵政グループのゆうちょ銀行で１２日に発生した大規模なシステム障害で、同行は１３日、午前８時５０分にシステムが全面復旧したと発表した。同日午前に会見した間瀬朝久専務執行役は「障害の原因ははっきり分からないが、送金処理の速度が落ちたようだ」と説明。利用者への影響は推計で約１万件に上るとした。 また、同行によると、１２日の苦情１４１０件に続き、１３日も１２５件の苦情があったことを公表。内容は「復旧状況を教えて欲しい」「ゆうちょ銀行同士の送金は大丈夫か」といったものだった。 トラブルは１２日午後３時２２分ごろ発生した。全国約２万６千台の現金自動預払機（ＡＴＭ）で、他行のカードを使った出金や他行への送金などができなくなったほか、インターネットバンキング「ゆうちょダイレクト」を通じた他行との取引もできなくなった。現金の引き出しなど、振り込み以外のサービスは１２日午後８時半過ぎに復旧した。
Webサーバから始めよう：いまさら聞けない!? Web系開発者のためのサーバ知識（1）（1/2 ページ） プログラマの弱点（？） ある程度の規模の開発プロジェクトでは、上流工程と下流工程、開発担当とサーバ担当、さらに開発担当のなかでもバックエンドのロジック担当とフロント周りの担当など、分業体制で進めていくのが一般的です。 ここまできっちりと分業されていない場合でも、コーディングはプログラマが行い、本番向けのサーバ構築などは詳しい人に任せてしまうといったことは多々あります。 こういった分業体制はもちろん理に適ったことなのですが、開発者が常にプログラマに徹してしまっていると、どうしてもサーバ知識が不足しがちになります。アプリケーションを動作させるために必要な最低限の環境を自分のPC上に整えたら、あとはひたすらコーディングの日々といったことの繰り返しになるので、なかなかサーバ知識が深まりません。
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
