Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

「紛争事例に学ぶ、ITユーザの心得」連載一覧

61件中46~60件を表示
  • 2015/07/16

    第16回 ITユーザが情報漏えいに備えてやっておくべきこと(後編)

     前々回、前回と情報セキュリティについてお話をさせて頂きました。情報を預かる組織はセキュリティに関する情報を日頃から収集、学習し、ベンダ等からのセキュリティ対策提案があれば、まずは検討すべきであること、万一の情報漏えいに備えて情報を重要度に応じて分別(トリアージ) して、対応策をあらかじめ準備しておくべきであること等、多少面倒な作業かもしれませんが、昨今のセキュリティ事情を考えるとやはり無視できないことではないかと思います。

  • 2015/07/07

    第15回 ITユーザが情報漏えいに備えてやっておくべきこと(中編)

      前回は、平成26年1月に東京地裁に出された個人情報漏えい事件の判決を参考に、情報を漏えいさせてしまった組織は、場合によって不法行為を問われ、損害賠償を請求される可能性があること、それを防ぐためには、組織が情報セキュリティに関する情報を日頃から収集・学習し、ITベンダからのセキュリティ対策提案等があったときには真摯に検討すべきであること、といったお話をしました。「不法行為」なんて言葉にはちょっと構えてしまいますが、常識といえば常識かなといったところでしょうか。

  • 2015/06/18

    第14回 ITユーザが情報漏えいに備えてやっておくべきこと(前編)

     日本年金機構から125万件の個人情報流出、東京商工会議所から最大12000件の会員情報流出と、ここのところ情報セキュリティに関する大きな事件が続いています。言うまでもなく、個人に係る情報が流出してしまうと、その企業や組織は、多額の慰謝料や損害賠償金を払わなければならないだけでなく、社会的な信用を失い、経営的にも大きな打撃を受けることにもなりかねません。読者の皆様の中にも自分の会社は大丈夫だろうかと気を揉んでいる方や上司から自社のセキュリティ対策を検討しろと言われて頭を悩ませている方もいるかもし...

  • 2015/05/12

    頓挫したプロジェクトの責任はどこにあるのか―ユーザが協力義務を怠ったとされる場合について

     今回は、久しぶりに、「システム開発におけるユーザの協力義務」についてお話ししてみたいと思います。システム開発において、ユーザは単なるお客様ではありません。新しく作るシステムの要件を十分な詳細さと正確さをもって、しかるべき時期までに定義し、プロジェクトの最終局面では、できあがったシステムが、要件通りにできているか検証することは、ユーザの義務です。また、システム開発の中盤においても、ベンダが必要とする資料や情報をタイムリーに提供したり、ベンダとの会議には、しかるべき人間を出席させて、様々な判断をし...

  • 2015/03/20

    そのソフトウェアの不具合は瑕疵か瑕疵でないか

     前回、ソフトウェアの不具合を損害賠償請求の対象となる“瑕疵”と見なすかどうか、その線引きはどこにあるのか、といったお話をしました。仮に不具合があったとしても、遅滞なく補修を行い、業務に使えるようにしていれば、必ずしも“瑕疵” ではなく、ユーザがベンダに対して行う賠償請求も認められない場合がある、と言った内容でした。実は、今回も同じようなお話なのですが、前回よりも、より明確に、このあたりに言及し、且つ前回は触れられていなかった新たなポイントに触れた判決を例示したいと思います。説明の都合上、前回と...

  • 2015/02/20

    ソフトウェアの不具合は不可避だが全てが許されるわけではない

     日本という国は、モノの品質に非常にうるさい国で、デパートでモノを買って郵送してもらったとき、その包装が破れていただけでも返品されるケースもあるくらいです。そんな日本の消費者や使用者から見て、「いったい何だこれ?」と言いたくなるのがソフトウェアの品質でしょう。Windowsが突然動かなくなったり、EXCELが間違った計算をしたりするのを見て、「これで人から金をとるのか?」とあきれる日本人は今でも多くいます。「もっと真面目にテストしろ。」と言いたくなった経験はベンダ出身の私にもあるくらいです。

  • 2015/02/04

    紛争の責任をベンダ側が負う場合

     この連載では、これまでどちらかというとユーザ側に厳しい判決の出たIT紛争事例について書いてきましたが、そもそも、IT訴訟というのは、いつもこユーザ側に厳しい判決が出るものなのでしょうか。もちろん答えは否です。裁判では、ベンダに厳しい判決もかなり出ており、「ユーザが期限通りに要件を決めないのは、ベンダが、ちゃんとプロジェクト管理を行わないからだ。」とベンダの責任を重く見るものが多く見られます。もし、ユーザ側の立場にある読者の皆様が、これらの判決を見たら、「あー、自分はコッチ側の人間でよかった。」...

  • 2015/01/06

    第9回 契約せずに範囲外の機能追加。ユーザは費用を負担すべき?

     お陰様で、この連載は多くの方に読んでいただけているようで、私のところにも多くのご意見、ご感想をいただけるようになりました。お付き合いのあるITユーザの方やベンダの技術者、裁判所の民事調停委員の方々からも、この連載で書いたIT紛争やその結末について様々なお話をいただくのですが、それらの中には、「勉強になった」「納得した」 というものもあれば、 「ユーザに厳しすぎる」「なぜ、こんな判断になるのか?」と疑問を投げかけるものもあります。中には、非常に鋭い洞察で記事の内容について別の角度から解説をしてく...

  • 2014/12/04

    第8回 そのシステム、何のために導入したのでしたっけ?

     ユーザ企業が情報システムを導入するのは、必ず何らかの経営的なメリットを求めてのことです。従来の事務処理を効率化してコストを削減するとか、顧客の管理を充実させて売上を拡大させるなど、その内容は様々ですが、とにかく、ユーザ企業はシステム導入に掛る費用以上のメリットを得られると踏んでシステム導入プロジェクトに”Go”をかけます。なので、もし、システム導入にかかわる作業を外部のベンダに請負発注するなら、その契約書(もしくは別紙) にシステム導入の目的を記述し、ベンダに良く理解してもらう必要があります。...

  • 2014/11/07

    第7回 ベンダが勝手に機能を追加した!それでも費用を払うべき?

     前回、IT開発では一旦決めた機能を変更することも常識で、裁判所もこれについては ”不可避” であるとの見解を示しているといったお話をしましたが、今回お話しする機能の追加も、裁判所が ”普通のこと” と言うように日常茶飯事です。

  • 2014/10/22

    第六回 要件変更と追加費用

     ITの要件は、企画段階から要件定義工程の完了に至るまで、新しい業務はどうあるべきか、その為にシステムに持たせるべき機能はどうかを一生懸命に検討し、予算や期間とのバランスを考えながら決定されていくものです。経営層、ユーザ部門、システム部門それにベンダの人間が多くの時間と労力を費やし、何回も打ち合わせを重ねて、やっとの思いで決定していく訳ですから、その内容は決していい加減なものではないでしょう。

  • 2014/10/08

    第五回 業界の常識を知ること・知らせることの大切さ

     前回から、システム開発のトラブル原因の横綱ともいうべき “要件定義”についてお話ししています。システム開発に失敗したユーザの9割が、失敗には要件定義が関係していると考えていることに、読者の皆さんはどのような感想をもたれたでしょうか?「さもありなん。」、「当然のこと」 と感じられた方も多かったかもしれませんね。それくらいに、この要件定義にまつわるトラブルは、システム開発において日常茶飯事であり、大多数のユーザが最も頭を痛める問題でもあります。

  • hosokawa_arena.png
    2014/09/25

    第四回 システムの要件定義とは

     今回から何度かに分けて、コンピュータシステムの要件定義についてお話したいと思います。要件定義というのは、導入するシステムにどんな機能を持たせるか、どんな速度でどんな使い勝手にするかといったことを定義していく作業ですが、実はこれが、一般のユーザにとっては相当に難しい作業で、システムに持たせたい機能や性能をベンダにうまく伝えられず、出来上がったシステムを見て 「こんな筈じゃなかった」 とベンダ相手に大喧嘩をするプロジェクトが後を絶ちません。ユーザが「ここは、顧客の購買履歴のサマリを出してくれって頼...

  • hosokawa_arena.png
    2014/09/04

    第三回 正式契約なく着手し頓挫した開発費用は精算されるか。

     皆さんはITベンダに仕事をお願いする際、きちんと契約を結んでから作業着手してもらっているでしょうか?私は、そういうことに特別うるさいITベンダで仕事をしておりましたので、契約書のない作業着手や協力会社への作業指示を行なった経験は皆無と言って良いほどですが、IT紛争に陥り裁判所にやってくるプロジェクトの中には、契約を結ばず、口答や簡単な注文書だけで作業を開始したものがかなりあります。契約書のない作業は、その範囲や役割分担が曖昧な上、何か不測の事態が発生したときの対応についての様々な約束事もありま...

  • hosokawa_arena.png
    2014/08/01

    システム開発プロジェクトにおけるユーザの協力義務(後編)

     「紛争事例に学ぶ、ITユーザの心得」。今回は、前回ご紹介した東京地方裁判所 の平成16年3月10日判決を元に、ベンダのプロジェクト管理義務についてお話ししたいと思います。この連載は主としてユーザの方向けに書いていますので、中には、「ベンダの義務なんて知らないよ。」とお考えの方もいらっしゃるかもしれませんね。でもベンダにきちんとしたプロジェクト管理をしてもらう為には、やはりユーザにベンダを選定する目とベンダに協力する姿勢が必要です。

46~60件(全61件)
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5