サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
連載目次IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「要件の範囲が食い違ったことにより生じた紛争」を解説する。 ユーザーが望む機能がシステム開発の要件から抜け落ちたがために発生する紛争は、本連載でこれまでにも何度か取り上げてきた。IT紛争の類型は種々さまざまであり、過去の判例が全てそのまま適用できるわけではないが、裁判所が「たとえ要件としてユーザーから明示されていなくても、その機能が契約の目的を果たす上で、当然に必要な事柄であるとベンダーが認識し得る状態にあれば、ベンダーにはその機能を作り込む義務（債務）がある」と判断した例が幾つもある。 要件定義書よりも契約の目的の方が重いとする考え方だ。 今回取り上げる判例も、「ユーザーが必要と考える機能が、ベンダーの作成した要件定義書から抜け落ちており、これを作り込まなかった」というものだ。これまでと少し異なるのは、パ
基幹システムの刷新でトラブルが起きやすい典型パターンは、旧システムの機能を、現状のまま新システムに載せ替えるケースだ。既存システムには自社業務や業界慣習に基づく機能を組み込んでいる。こうした機能を「現状のまま」新システムに反映させるのは本質的に難しい。 既存のレガシーシステムを新システムにリプレース（置き換え）する。近年の基幹システム刷新プロジェクトの多くはこのパターンだ。プロジェクトを始めるきっかけは、メインフレーム、オフコン、OS、パッケージ、ミドルウエアなどのサポート切れが多い。まったく新しいシステムを一から開発するよりも、既存システムの機能をそのままに、新システムへと置き換えるほうがリスクは少ないように見える。 ところが、システム開発トラブルの多くはこのパターンのプロジェクトで起きている。 日本の企業は20年から30年くらい前に、販売管理、生産管理、会計管理などの基幹システムを相
要件定義書の書き方がわからない、要件定義って何やればいいの？という方もいると思うので、発注側としての要件定義書の作り方をまとめておく。 要件定義書に書くべき内容の図による表現 手順①：[作業]あるべき姿の確認 手順②：[作業]現状の把握 手順③：[作業]問題(あるべき姿と現状の乖離)の中から、問題点を特定する 手順④：[会議]あるべき姿と現状と問題点の認識に関する合意をとる 手順⑤：[作業]問題点をどこまで解決するかの目標を決める 手順⑥：[作業]問題点の真因を分析する 手順⑦：[会議]目標と真因分析結果に関する合意をとる 手順⑧：[作業]真因に対する対策を検討する 手順⑨：[作業]対策の中から、システム化対象のものを明確化し、要件化しておく 手順⑩：[会議]対策、システム化対象課題、要件に関する合意をとる 手順⑫：[会議]要件定義書の内容に関して合意をとる 手順⑬：[作業]要件定義書に承
「人材の流動化か囲い込みか（http://remote.seesaa.net/article/147006872.html）」で示される問題は、SIerの案件であれば１つや2つはよく起こっている。ここまで問題が積み重なっててひどいのはあまりない（...と思いたい）以下は実際にみてきた現場の惨状。 2.ドキュメントが無茶苦茶excel方眼紙はよく見かけます。修正にやたらと手間がかかるので苦痛です。継続的にメンテナンスする必要があるドキュメントには向いてません。あと、ソースコードを日本語訳したようなひどい設計書が多いです。そんなもんソースコードで十分だろって思います。 3.プロダクトのソース管理が無茶苦茶本番環境でコンパイルしたりとか、恐ろしい事をしている現場がありました。それでソースコードレポジトリとの同期が取れてなくてどのファイルが実際に稼働しているコードなのか分からなくなったりもして
こんにちは、NewsPicksの北見です。 ところで皆様、テストコードって書いてますか...? ネットでテストコードについて検索すると 「テストコードを書きましょう」 「テストコードとはこうあるべし」 「TDD(Test Driven Development)だ」 等々が叫ばれています。 ただ、なんとなく「方法論ありきでとにかくテストを書け」と言われているようで、テストの必要性について納得感に欠けている方もいらっしゃるのではないでしょうか? なぜ テストコードを書くのでしょうか? テストコードを書く理由 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる 最後に テストコードを書く理由 諸説ありますが、私が思うテストコードを書く理由は 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる の2つです。
2010年に経営破綻した日本航空。そうした苦境下においても「安全運航への追求」は欠かせない。そのとき大胆な革新のために立ち上がりデジタル化を先導したのは、実際に飛行機を操縦していたパイロットだった。 先鞭をつけたのは、日本航空運航訓練部 A350訓練室に在籍し、機長も務めていた和田尚だ。破綻を改革につなげるために彼は自ら勉強会などに参加し、ローコードでの開発を可能にするツール「クラリス ファイルメーカー」を学んだ。そして現役パイロットの訓練評価を効率的に行うシステム「JAL CBCT（Competency Based Check and Training）」（以下、CBCT）を内製で生み出したのである。 今回は、和田から数えて3代目、約10年にわたり改革のけん引役を務める、日本航空運航本部 運航訓練部 訓練審査企画室室長の京谷裕太と、ともに訓練審査企画室 マネジャーとして改革に尽力している
大創産業は1972年、家庭用品を販売する商店として創業された。今やよく知られた『100円SHOPダイソー』を運営する事業者である。ダイソーの展開に着手したのは1987年。2019年には国内3367店舗を数え、海外ではアジア、北米を中心に28の国、地域で2175店舗を構えるほどのグローバル展開を果たしている。 キッチン用品や文具、衣服やコスメ、食品やガーデン用品など、幅広い商品展開もダイソーの魅力の一つだ。商品数は7万点を超え、売れ筋の電池は1秒間に5本、ネクタイも15秒に1本、“つけまつげ”は1.3秒に1つ売れる勢いとのことだ。 取り扱う商品が多く、また尋常ではない速度で売れていくことは、それだけデータ管理の難しさが増すということでもある。アイティメディアが2019年9月17日に開催した「ITmediaDX Summit 2019年秋・ITインフラ編」に登壇した大創産業 情報システム部
深刻な人手不足と言われる中、IT企業の給与はどのように変化しているのか。IT企業大手の年間平均給与や役員報酬から、その実態を探る。 これまで、NEC、日立製作所、富士通という最大手企業の給与実態を見てきた。 ここからは、システム開発やITコンサルティングを中軸事業にしているITサービス最大手5社の給与について見てみる。分析対象は、2016年度売上高のトップ5社。NTTデータ、キヤノンマーケティングジャパン（キヤノンMJ）、大塚商会、野村総合研究所（NRI）、伊藤忠テクノソリューションズ（CTC）である。 1000万円以上はNRIのみ 2016年度における年間給与が最も多かったのはNRIだ。同社の従業員の平均年間給与は1151万4000円である。2番目のキヤノンMJ（841万996円）とは、300万円以上の差がある。
あるITベンダーの経営者がこんな話を披露してくれた。日本のIT業界をよく知る外国人から「日本のIT業界は全くダメだ」と言われそうだ。さすがにムカッとして「そんなことはない」と反論しようとしたら、相手は「世界に全く貢献しない日本の業界など産業としての存在価値は無い」と言い放ったそうだ。「さすがに、ぐうの音も出なかった」とその経営者は話していた。 確かに、ソフトウエア開発を請け負う“純粋な”SIerや受託ソフトウエア開発会社はもとより、コンピュータメーカーも含め日本のITベンダーは、世界に対してほとんど価値を提供できていない。「日本のITベンダーだってグローバル展開を始めている」と反発する人もいるかと思うが、それは単に世界で商売しようとしているだけの話である。 要は、ITの領域では日本発の技術や、それをベースにした製品・サービスがほとんどないのだ。画期的な技術を生み出すことで新たな価値を提供す
セゾン情報システムズは2016年3月28日、クレディセゾンと同社子会社であるキュービタスから受注した大型システム開発案件の開発遅延のために2社から損害賠償を請求されていた問題で、条件付き和解を行う方針を決めたと発表した。 セゾン情報が支払う和解金はクレディセゾンに対して83億9700万円、キュービタスに対して65億7800万円の合計149億7500万円である。これは、開発業務にかかる契約に基づいてクレディセゾンとキュービタスのそれぞれからセゾン情報が受領した対価と同一である。クレディセゾンとキュービタスは、今回の紛争に関する他の請求を放棄する。 セゾン情報にとっては、受け取った金額を“全額返金”する格好になるが、「当社としては、合理的な和解案であると判断している」（経営企画室）という。 和解案は企業間交渉で策定した。今後、第三者機関であるソフトウエア専門のADR（裁判外紛争解決）機関の「ソ
昨日の日記で、「NTTデータのデルサービス事業買収でITインフラの覇権はどう変わるか」と書きました。買収の舞台裏は「巨額買収に動いたNTTデータ 北米事業大きく前進、その勝算」にあります。 もっと驚いたニュースがありました。「セゾン情報が大型システム開発の遅延で約150億円支払いへ、希望退職50人募集」です。 記事にあるように、「全従業員716人のうち、50人の希望退職者を募る」という事実は重いものです。クレディセゾンと同社の子会社であるキュービタスが相手ですから、カード会社向けのシステム開発プロジェクトに関わるものでしょう。 カード会社の開発は難しいものだということを改めて感じさせられます。いやカード会社だけに限らないのでしょうが。 この記事の目次へ戻る
ある米国ITベンダーの日本法人の社長は、本社の幹部から「なぜ日本にはITサービス会社があんなにたくさんあるのか」とよく聞かれるそうだ。確かに米国には、それに相当する企業はEDSやアクセンチュアなどわずかしか存在しない。質問の答えは「日本のユーザー企業は独自仕様のシステムを作りたがるのに、その開発を外部委託することが多いから」である。ただ、この説明では米国人には理解不能だろう。 米国企業の多くは、付加価値を生まないバックヤードのシステムにはERP（統合基幹業務システム）などのパッケージを可能な限りそのまま使う。だが事業戦略上で重要なシステム、儲けるためのシステムは自前で作る。だからこそ米国では、ユーザー企業のシステム開発の内製化率が高く、システムインテグレーションという業態は発達しなかった。米国のそうしたリアリティーからすると、システム開発を外部に丸投げするのは、不思議で仕方がないはずだ。
最近ソフトウェア開発の内製化が話題に成っていますが、実際に内製化に取り組まれている企業はどのような結果を出しているのでしょうか？ こんにちは。 ライジングサン・システムコンサルティングの岩佐です。 システム開発の内製化を進める上で、ぜひ手にとっていただきたい本があります。 それが、日経BP社マーケティングより出版されている「開発・改良の切り札 システム内製を極める」です。本書は恐らく、国内でも「システム開発の内製化」に特化して書かれた唯一の書籍と思われます。初版が2011年の7月と若干古い書籍ですが、実際に読み解いていけば極めて普遍的。 現在でも十分に通用する内容だと思います。 この記事は、本書の書評も込めて、システム開発内製化の先進企業から学ぶ３つの教訓というテーマでお伝えしたいと思います。本書から私達が学ぶことのできる教訓は、つぎの３つの点です。 1.適切なポートフォリオを組むこと
1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/02/23 11:49:47うちの団体で、インターネットで講習会を申し込めるようなシステムを作ることになって、ネットで調べた何社かに見積りを頼んだら、出てきた金額が業者によって２５万～４００万で出てきた。 見積りの項目も各社バラバラだしそれぞれの意味も、なにがなんだか素人の俺にはさっぱりわからない。 年間に１万人ぐらいが100会場でやる研修の申込みを受付けられるようにするってだけの機能なのになんで各社こんなにもバラバラなのかが理解不能。 若いってだけでITに詳しいと思われて、担当にあてがわれて、２５万～４００万の間で業者決める手掛かりが全くない状態でどうすればいいんだ？（それでもし業者選びに失敗したらやっぱり俺のせいなのかな。。） 続きを読む
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
