とあるコンサルタント @consultnt_a ランサムウェアでシステム壊されて復旧に1ヶ月はかかる→わかる プロに委託してシステム更新しようとしたら既存のシステムごと使えなくなった上に2ヶ月経っても直らず出荷停止し続けている→なぜ 2024-06-16 20:45:05
ランサムウェアでシステム壊されてた→わかる。プロに委託してシステム更新しようとしたらプリンが出荷できなくなった→なぜ
とあるコンサルタント @consultnt_a ランサムウェアでシステム壊されて復旧に1ヶ月はかかる→わかる プロに委託してシステム更新しようとしたら既存のシステムごと使えなくなった上に2ヶ月経っても直らず出荷停止し続けている→なぜ 2024-06-16 20:45:05
日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ →ユーザー側に必要な能力がないとプロジェクトの成功確率は落ちる
中野 仁 (AnityA) @Jin_AnityA ユーザー側とシステムを本業にしているベンダー側で組織の能力差がでるし、結果的に情報の非対称性が拡大する 外部に発注するにもユーザー側に必要な能力というのはあるし、それがないとプロジェクトの成功確率は落ちる 日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ president.jp/articles/-/819… 2024-06-01 07:41:21 リンク PRESIDENT Online（プレジデントオンライン） ｢プッチンプリン｣の出荷停止に､ゆうちょ銀行の入金遅延…日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ 江崎グリコのシステム障害によりプッチンプリンなど一部商品の出荷が停止している。4月にはゆうちょ銀行で入金遅延が起きた
社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24（平28ワ28934） - IT・システム判例メモ
開発は途中で終わった場合でも、準委任契約に基づく報酬請求はできるが、適切な計画立案・実行ができていなかったとして善管注意義務違反が認められた事例。 事案の概要 イベント企画会社Ｙは、自社の企画するイベントを管理するためのシステム（本件システム）の開発をＸに依頼することとした。 平成28年3月にＸは開発に着手したが、その時点では契約書が取り交わされておらず、4月になって、Ｘ・Ｙ間で以下の内容（抜粋）の契約書が取り交わされた（本件契約）。 1条2項 本件契約は，Ｘが（中略）業務に従事する技術者の労働をＹに対し提供することを主な目的とし，民法上の準委任契約として締結されるものとする。したがってＸは，善良なる管理者の注意義務をもって（中略）業務を実施する義務を負うものとし，原則として成果物の完成についての義務を負うものではないものとする。 3条3項 前各項にかかわらず，Ｙは，Ｘの本件サービスの業務
仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」
あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 仕事で作業クオリティが低いってコメント来たので話聞いてみると不思議な世界が広がっていた 相手「仕様に書いてないが、普通のエンジニアならできるでしょ」 私「仕様に書いてないならやれません。仕様確認会などあったのでしょうか？」 相手「そんなものない。わからなかったら確認するでしょ」 続 2022-03-16 10:02:09 あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 私「わからないところは都度確認してますが、仕様に記載されていないものを作ることはできませんし、確認すらやりようがありません」 相手「テストでいっぱい不具合出てくる」 私「クオリティコントロールの仕組みがないから当たり前では？」 相手「こっちが確認してないのが悪いってこと？」 続 2022-03-16 10:
中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
エンジニアをしていると、世間には「面倒な手続きほど価値がある」と考える人が、けっこういるとわかる。
この記事で言いたいことは、まとめると以下のような内容になります。 ・「面倒くさくて複雑」といフローは、例外もあるものの、基本的には不適切であるか、そのフローが必要とされる前提の方がおかしい ・けれど世の中には、「面倒で複雑なフロー程正しいし価値がある」と考える人が案外多い ・「面倒くさい」と言える人は貴重なんだけど冷遇されがち ・不要なJOIN句は敵だし、JOIN句の使い回しなど絶対してはならない よろしくお願いします。 さて、言いたいことは最初に全部言ってしまいましたので、後はざっくばらんにいきましょう。 先日、Twitterでこんなことを呟きました。 エンジニアをしていると「面倒くさいやり方は大抵間違っているか、あるいはそのやり方を必要としている前提の仕組みの方がおかしい」という思考は割と普通だと思うんだけど、どうも世間的には「面倒くさければ面倒くさい程正しい、ないし価値がある」と思っ
ZOZOTOWNシステムリプレイスの道のり/ ZOZOTOWN 更换云系统之道 - Speaker Deck
All slide content and descriptions are owned by their creators.
YRP常勤 【軍曹が】携帯電話開発の現状【語る】
キーワード: YRP野比, ヨコスカリサーチプリズン, デスマーチ, 軍曹 京浜急行を三崎口方面へ下っていくとYRP野比という変わった駅名がある。 アンサイクロペディアによると、YRPとはヨコスカ・リサーチ・プリズンの略称、直訳すると横須賀研究開発刑務所。 YRPでの労働環境はデスマーチの中のデスマーチと言われるほど過酷を極め、逃亡を図る者や過労死、うつ病での自殺者が絶えないと噂される。 ヨコスカリサーチプリズンでのデスマーチの惨劇を綴った有名な文章として、 2ちゃんねるのプログラマー板に投稿された『【軍曹が】携帯電話開発の現状【語る】』というものがあります。 この物語は[笑わないプログラマ]というサイトが取り上げて世に広まりましたが、既にリンク切れとなってしまっています。 いくつかのブログがコピペを保管していますが、いずれもほとんど更新がなされていない古いもので、いつ消えてしまうかわかり
客先常駐のシステム開発は炎上した方が儲かってしまう | 株式会社アクシア
システム開発に限らず、普通は同じ仕事をするなら短い時間で効率よく仕事をした方が原価となる経費が少なくなり、利益率は高くなります。仕事を完了させるまでの時間が長くなればなるほど人件費はかかりますし、残業が発生するとなれば従業員の割増賃金も発生します。仕事をこなすための時間が長くかかって良いことなど何もありません。 だから普通の企業は業務効率化を促進して効率よく仕事としていこうとなるわけですが、客先常駐でシステム開発の仕事をしているSES企業に関して言えばそうはなりません。その特殊な環境が理由で業務効率化へのモチベーションが働きにくい世界です。 システム開発とSESは全く別の業種として明確に区分すべき ここにも書いた通り、個人的にはSES企業はIT企業としてグルーピングしないでほしいと考えているのですが、この業界の業務効率化を促進して残業時間を短くしていくことを考えてみると、どう考えても客先常
「やりたい事はいっぱいあった。でも何もできなかった。」- 退職願いを書きました
僕にはやりたい事がいっぱいありました。 「挑戦」と「安定」 この二つのキーワードでお話ししたいと思います。 「挑戦」したかったこと 優良顧客の事業拡大 A社はいわゆる大企業で、莫大なお金を持て余しています。 数億円出して買ったパッケージソフトが、うまく稼働できなくても痛くもかゆくもない人達です。 会社内のシステム化はあまり上手くいっておらず、どこから手を付けても仕事になりそうなくらい、僕から見たら面白い企業でした。 A社向けのシステム開発に携わったメンバーは昨年末で全員解散し、僕一人で質問等に答えていました。 当然、瑕疵担保期間中ですので不具合があれば対応もしていました。 しかし、僕が長期の出張などで対応できないと、完全にお客様先では止まってしまいます。 僕はここを強化したかった。 それまで我が社に無かったサポート契約を実現し、その実績を作りたかったのです。 安定収入が得られることで、 僕
改正民法が成立、瑕疵担保責任はバグ発見から1年に (2017年5月28日) - エキサイトニュース
1896年の民法制定以来、初の抜本的見直しとなる改正民法案が26日、参議院本会議で可決・成立した。公布から3年以内に施行される(NHKニュースの記事、日本経済新聞の記事、ITproの記事)。 改正民法では債権・契約分野のおよそ200項目が変更され、約款に関する規定が新設された。特にシステム開発の分野では、瑕疵担保責任として納品から1年以内に見つかった不具合を無償で修正するとされてきたが、不具合が有る事実を知ってから1年間と改められ、修正がなされない場合に代金減額請求権が与えられるなど、大きな影響が予想される(解説記事)。 その他、インターネット通販や保険などの約款で消費者の利益を一方的に害する条項が無効になる、未払金の時効が5年に延長される、賃貸住宅の敷金が原則返還になる、法定利率が引き下げられる、といった日常生活に関連した部分でも大きな変更が加えられている。 今回の民法改正は法制審議会の
改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 | 日経 xTECH（クロステック）
物品の売買や契約のルールなど「債権」に関する民法の改正案が2017年5月26日、参議院本会議で可決・成立した。公布から3年以内に施行される。 民法の改正はITに関する契約に様々な影響をもたらす。システム開発委託時の契約内容や、その際に発生するユーザー企業とITベンダーの責任範囲などが変わる。 改正民法の変更点の一つが「瑕疵担保責任」をめぐる条文だ。民法634条から640条で規定されていたが、改正法では削除。代わりに（契約に対する）「不適合」という言葉を用いて同様の責任を求めている。 責任の内容も変更点がある。その一つがシステム完成後に見つかった欠陥の修正期限に関するもの。ユーザー企業はITベンダーから引き渡されてから1年以内に修正を求める必要があったが、改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求められるとしている。 外部の技術者
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ | Microsoft Docs
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ 05/25/2017 3 minutes to read 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。 こうした背景があり
みずほ銀行こうすれば救えるんじゃないかなあ - novtan別館
とにかく、3.11以来金融庁がうるさいので、ちょっと計画変えますって話もなにか問題があるのかどうなってるんだ報告しろで貴重な時間と金を吹っ飛ばすことになりかねないので計画を変えることに対して及び腰になってしまうという問題があるんじゃないかと思うんですよね。つまり、金融庁が余計な口を出さなければ計画が適正になるんじゃないの？ という話はさておき、やっぱりこっちの業界の人とあっちの業界の人では思うことにだいぶ差異があるんだなあと思いました。 で、結局何百億という予算は多重下請け構造の中で中抜きに中抜を繰り返され、最終的に実際に作業する人には時給数百円しか行き渡らないため、中国や台湾、ベトナムといったところから人が駆りだされてきて、現場の中国人が台湾人と殴り合いの喧嘩を演じるとかもう収集つかないところまで来ているという話です。原発事故の石棺処理みたいな煉獄が、こんな近所に存在しているかと思うと胸
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件定義とはそもそも何か
要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
ソフトウェア開発の見積もりにおける問題点は何ですか？
過剰なエンジニアリングを止めて、顧客が本当に必要とするものを作ろう
