仕様書通りにシステムを作りました。使えなくても知りません
仕様書通りにシステムを作りました。使えなくても知りません：「訴えてやる！」の前に読む IT訴訟 徹底解説（113）（1/3 ページ） ユーザー企業が作った仕様書に抜け漏れがあり、その通りに作ったシステムが使いものにならなかった。悪いのは、ベンダー、ユーザー企業、どちらなのか？ 連載目次 IT訴訟を例に取り、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、要件の不備についての裁判例である。ユーザーが示した要件に抜け漏れや誤りがあり、これに沿って構築したシステムはユーザーが本来望んだ動作をしなかったというものだ。 ユーザーはこれを債務不履行であると訴えるが、ベンダーは「言われた通りに作っただけで、こちらには責任はない」と反論した。 この手の紛争について、裁判所の立場はおおむね一貫しているように思われ、似たような判断が各地で示されている。今回取り上げる判決はこうした考え方の大本とな
リードタイムを測るシェルスクリプトを作ってチームの振り返り会を活発にした話 - Classi開発者ブログ
こんにちは。エンジニアのすずまさです。 去年の夏頃にリードタイムの計測を始めてから、振り返りで良い気づきを得られるようになったりリードタイムを減らすアクションが生まれたりと良いことがたくさんあったので、今回はその紹介をしようと思います。 リードタイムの定義 『LeanとDevOpsの科学』では、リードタイムを「コードのコミットから本番稼働までの所要時間」として定義しています。 私たちのチームのリポジトリではブランチ戦略としてGitHub Flowを採用しており、mainへのマージと本番稼働のタイミングが近しいため「PRをopenしてからマージするまでの期間」をリードタイムとして定めて計測しました。 リードタイム計測を始めた動機 私たちのチームでは「チームのスピードがあまり出ていない気がする」という漠然とした課題感がありました。しかし、課題感はありつつも、ではどうするかと言われると具体的なア
10年後のクルマ、電動化・ソフトの行方
自動車業界の未来は不透明だ。純粋な技術論ではなく、国や地域の間で起こる政治的な綱引きによっても求められるクルマは変貌していく。消費者のニーズも多様化の一途をたどる。そんな中でも、「電動化」と「ソフトウエア」という2大潮流は10年後も勢いを増すだろう。電動パワートレーンの行方と、ソフトが再定義するクルマの動向を追う。 第4回 ソフトがクルマを左右、鍵は自動車メーカーの車載OS 2024年1月に開催されたテクノロジー見本市「CES 2024」では人工知能（AI）などのソフトウエア技術によってクルマの価値を高めようとする動きが相次いだ。自動車メーカーは大手IT企業と連携し、生成AIの実装やソフトウエア定義車両（Software Defined Vehicle：SDV）の開発… 2024.02.29 第3回 EV鈍化でハイブリッドに脚光、エンジンが生き残りへ 現在、電気自動車（EV）の需要が鈍化傾
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
文化祭で某チェーン店を再現して失敗した話 - Qiita
要約 Wifiは無いに等しいと考えること。 (来場者1万強/日 なんていう状況下でWifiが動くと想定するのが駄目でした) 進捗管理する第三者を設けること。 ソースコード https://github.com/Na4Yu/EasyEats (RTDBのURLやSquareの個別キーは抜いているのでそのままは使えないです) はじめまして はじめまして、高校2年のNaYuです。 今回は文化祭で派手に失敗した話をさせて頂きます。 血反吐を垂れ流しながら書いていましたが、もし皆さんが文化祭を経て「この人のしたことをしなくて良かった~」なんて言っていただければ幸いです。(人の不幸は蜜の味) お願い 本記事は知見の共有を目的として個人が執筆したものであり、本記事の内容について学校、学校関係者への問い合わせはご遠慮頂けるようお願い申し上げます。 これを読んでいる後輩の方々へ この記事が私からの引き継ぎに
コードを極力いじらない開発こそ正義
「システム開発とは結局のところコーディング、と思われているようですが大間違いです」 つい先日、海外のソフト開発者と組んで仕事をしているプロフェッショナルとやり取りをした際、こう指摘された。「ソースコードを修正するには」という言い方をしたところ、「原則としてソースコードはそのまま使う。いじらない」と正されてしまった。 そのプロの説明はこうだ。今やシステムを開発することは事業や組織の開発と表裏一体である。こういう事業をやりたい、こんな組織にして動きたい、という構想がまずある。構想を支えるシステムを用意するために、世の中にあるクラウドサービスやパッケージソフトウエア、オープンソースソフトウエアなどを組み合わせ、実際に動かしてみて、必要があれば構想も含めて調整していく。これが開発である。 どうしても足りないコンポーネントを用意するためにコードを書くことはあるが、利用者の細かな要求を受け入れてクラウ
システムの全容を理解している社員がいない…みずほ銀行で大規模トラブルがなくならない5つの問題点 新システム導入後､2年たってから11回の障害
みずほ銀行の連続障害の原因を掘り下げていくと、次の五点に集約できるのではないかと考えられる。 第一に、MINORIのアーキテクチャの複雑性、第二に、保守運用フェーズでのリソース削減が急であったこと、第三に、経営とIT現場とのコミュニケーションが不十分だったこと、第四に、システム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第五に、機器の所有を各ベンダーとしたことが挙げられる。順に見ていこう。 大規模システムでは、マルチベンダー（多数のITベンダー企業が開発を分担すること）となることは不可避である。マルチベンダー自体は問題ではない。むしろ勘定系システムの本体部分が、四つの異なる基盤システムで構成されている点が問題である（図表2）。
請負契約のような準委任契約 仕事を途中で放り出したITベンダーを糾弾できるか？
請負契約と準委任契約 今回はシステム開発でよく見られる「請負契約のような準委任契約」について取り上げます。 この連載の読者の方であれば、この二つの契約の違いについては、もう十分にご存知かもしれませんが、請負契約というのは、なんらかの成果物（目的物）を約束した納期どおりに作成したり、提供したりすることを“請け負う”ことです。 請負人（ソフトウェア開発では多くの場合ITベンダー側）は、期日通りに約束した品質をともなう成果物を完成させて納品する必要がある契約です。 一方の準委任契約は、本来なら発注者がやるべきことを、専門家である受注者が代わりにやってあげるというイメージに近いでしょう。同じように情報システムを作っていたとしても、受注者に求められるのは、専門的な技量を十分に発揮して、真摯に作業を行うことであり、多くの場合は働いた時間に応じて支払いがなされ、原則的には請負にあるような“約束した品質を
銀行の基幹系システムはなぜ複雑なのか？｜つっちーさん
おはよう人類。 インフラストラクチャーという言葉は、元々ラテン語に語源があり、inferus(下部の)という言葉とstructura(構造体)という二つの言葉を合成した言葉で、言葉の意味としても、社会構造の中で上部構造である政治基盤に対応する経済基盤としての使い方(主にマルクス経済学で用いられる)と、道路や橋だけででなく教育機関など公共性の高い社会基盤の意味で用いられる。特に、後者の意味が強いのだが、インフラストラクチャーの供給源というのは国や公共的な組織だけにとどまらず、電力会社や鉄道会社、金融機関のように私有なのだが、その性質上インフラストラクチャーとして扱われるものも多い。 こういった企業を(広い意味で)インフラ業と呼ぶことも多いのだが、その公共性の高さから私有にもかかわらず、その運営には様々な規制が加えられていることが多い。設立に免許や認可が必要で、運営に関しても一般の企業とは異な
複雑化したシステムの安全性確保（STAMP） | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
複雑化したシステムの安全性確保（STAMP） 近年の組込みシステムは、個々の構成要素自体の高機能化に加え、各構成要素が接続されて連動動作することにより、益々、大規模・複雑化が進んでいます。 IPAでは、そのようなシステムにおけるシステムライフサイクルの全般をカバーした安全性・信頼性・セキュリティ向上手法の調査・研究、およびその普及を目的とした活動を行っています。複雑なシステム設計において安全性を確保するため、システム理論に基づく事故モデル(STAMP*)およびその安全性解析手法(STPA**)に注目しつつ、我が国のソフトウェア開発実態に即したリスク評価手法の調査・検討および普及を行っています。 *STAMP（System-Theoretic Accident Model and Processes) **STPA（System- Theoretic Process Analysis) ST
システム開発のプロジェクトが炎上する理由 | 株式会社アクシア
システム開発のプロジェクトの成功率は3割と言われており、業界内でのプロジェクト炎上の話題は度々耳にします。私自身もプロジェクト炎上の現場には何度か携わってきました。昨日ツイッター上でこんな投稿をしました。 システム開発のプロジェクトが炎上する理由にはどんなものがあると思いますか？リプ欄でご意見いただければ幸いです。 — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) April 12, 2018 皆様から実にたくさんのリプライをいただきました。ご協力いただけた皆様ありがとうございました。 多くの皆さまがプロジェクト炎上経験者の強者のようでして、一言ではまとめきれないほどたくさんの炎上理由が集まりましたので、その内容をこのブログにまとめてみることにしました。 情報が多かったので私なりに少し整理しまして、下記の４つにカテゴリー分類してみることにしました。 会社間での力関
外注丸投げが過ぎると何のノウハウも身につかない問題 | 株式会社アクシア
外注ばかりしていて大企業の社員が劣化しているという記事が昨日出ていました。 残業減らしで外注急増、大企業社員の劣化が止まらない この記事の中では次のような具体例が出てきます。 プログラムを一度も書いたことのないＳＥ。 戦略作成はコンサルタント頼みの経営企画部員。 文章をまったく書かない編集者。 教育制度の企画運営を全部外注する教育担当者。 代理店のインセンティブ（奨励金）プログラムを作るだけの営業本部員。 「プログラムを一度も書いたことのないＳＥ」についてはこの業界の人間として痛いほど実感があります。エンジニアと名乗っていながら技術的なことが何もできない人の問題は度々話題に上がりますね。 他の例については自分の業界ではないので実感はありませんが、「プログラムを一度も書いたことのないＳＥ」の例と同じくらい問題のある事例ということでしょう。 大手SI企業のエンジニアがプログラムを書けない理由
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ | Microsoft Docs
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ 05/25/2017 3 minutes to read 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。 こうした背景があり
カンボジアは残存率3割弱、離島の男性は全滅――山本一郎氏が聞く、オフショア＆ニアショアで働き手を開拓し続けた企業の8年間
カンボジアは残存率3割弱、離島の男性は全滅――山本一郎氏が聞く、オフショア＆ニアショアで働き手を開拓し続けた企業の8年間：開発残酷物語（3）（1/3 ページ） トラブルの原因は何だったのか、どうすれば良かったのか、同じトラブルを起こさないようにどういう手だてを取ったのか。実在する開発会社がリアルに体験した開発失敗事例を基に、より良いプロジェクトの進め方を山本一郎氏が探ります。 「オフショアの落とし穴」――察しのいい人であれば、このひと言だけで何を指すか想像できるだろう。「人件費の安さにつられ、もっと大きな損失を出してしまう」というよくある話だ。 だからといって、国内の地方に拠点を作る「ニアショア」が天国かというと、こちらはこちらでさまざまな課題がある。単価が安いのには理由があり、気楽に手を出すものではない。 いや、現実はもうちょっと複雑で、もうちょっと“エモい”。机上の計画や理屈だけではな
国内におけるアジャイル開発、どのプラクティスがいちばん使われている？ IPAが調査報告書を公開
国内でアジャイル開発を普及させることを目指し、IPAはアジャイル開発の国内での活用事例をまとめた｢アジャイル型開発におけるプラクティス活用事例調査｣として、調査報告書、およびプラクティス活用のためのリファレンスガイドなどを公開しました。 IPAがこのような調査報告書を公開する背景として、「国際競争力強化のため、世界的に主流になっているソフトウェア開発手法であるアジャイル型開発に日本でも取り組む必要がある。しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされている」と調査報告書に記述されています。 報告書では、国内の26のアジャイル開発事例についてその状況をまとめることでナレッジの集積をはかるとともに、今後の普及に向けた提言を記しています。 日次ミーティング、ふりかえり、イテレーションが国内3大プラクティス 国内でアジャイル開発の普及が阻害されている要因として、
がんじがらめのITエンジニア、優れたアイデアが生かされない
「日本のITエンジニアは“がんじがらめ”になっている」。取材した複数の外国人エンジニアからの共通する指摘だ。彼らの目になぜそう映るのか。原因は、日本ならではのベンダーとユーザーの関係にあるようだ。 要件の決定権を持つ人が違う まずは、プロジェクトの体制面における指摘を紹介しよう。ベンダーがユーザー企業のシステム構築を請け負う際、日本ではシステム部門がベンダーと利用部門の間に入って、プロジェクトを主導したり、調整したりすることが多い。 写真1●エイチシーエル・ジャパンのSreedhar Venkiteswaran氏。インド出身。インドや米国、ドイツでさまざまな業種のシステム開発経験を持つ 米国やドイツ、インドでのシステム開発経験が豊富なエイチシーエル・ジャパンのSreedhar Venkiteswaran氏（デピュティジェネラルマネージャー 日本デリバリーヘッド。写真1）は、日本で一般的なそ
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件定義とはそもそも何か