クレジットカード情報の漏えい事故の責任 東京地判平26.1.23判時2221-71 - IT・システム判例メモ
クレジットカード情報が漏えいしたことについて，ウェブサイトの保守事業者の責任が問われた事件。 事案の概要 XはYに対して，平成21年2月4日，Xのウェブサイト（本件ウェブサイト）のウェブ受注システム（本件システム）の導入を合計約900万円で発注した。本件システムは，EC-CUBEをカスタマイズして開発された。Yは，本件システムを完成させ，平成21年4月頃に検収を受け，同月15日から本件ウェブサイトが稼働した。XとYとの間では，何度も発注が繰り返され，代金合計は約2000万円に上った。 その後，XとYは，本件システムの利用を毎年更新した。Yは，Zとの間でサーバ利用契約を締結し，Zが設置したレンタルサーバ（本件サーバ）に本件システムのデータを保存していた。 平成22年1月に入り，YはXの依頼を受けて本件システムを変更し，顧客のクレジットカード情報（カード会社名，カード番号，有効期限，名義人，支
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
俺の価値創造契約
〜新しい契約形態での受託開発サービス立ち上げ 1,396日間の記録〜 2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。その貴重なエピソードを発表します。 @XP祭り2014
プロジェクト運営
進捗管理 品質管理 組織要員管理 協力会社管理 費用管理 機密・契約管理 変更管理 ◆進捗管理 大日程計画(マスタスケジュール) 工数計算 ＰＥＲＴ 成長曲線 予実管理 差異分析 進捗遅れの具体的原因の指摘 ◆品質管理 前向き品質と後向き品質 「あたりまえ品質」(プログラム品質)と「魅力的品質」(設計品質) 機能性、信頼性、使用性、効率性、保守性、移植性 デザインレビュー ウォークスルー * 検討される成果物の担当者自身がレビューの設定を行う。 * 役割分担された担当が、その場でレビューを実施する。 インスペクション * 訓練を受けた議長が進行を行う。 * 事前に配布された資料を基に各自検討を行いレビューに臨む。 パレート図 特性要因図 新ＱＣ七つ道具 ＫＪ法 ＰＤＰＣ、ＦＴＡ、ＦＭＥＡ、ＶＡ、ＶＥ、ＡＨＰ、ＰＳＡ トップダウンテスト、ボトムアップテスト サンドイッチテスト、ビックバンテス
顧客に価値を届ける、ってなんだっけ - (define -ayalog '())
2013-12-09 顧客に価値を届ける、ってなんだっけ 開発 日記 最近、@syobochimのブログを読んでいたら、こんな言葉が書いてあった。 顧客に価値を届けたい。 私はいま、価値届けられてるんだろうか。 アジャイルサムライを読んだら意識高まってつらい - そこに仁義はあるのか(仮) 僕はどうだろうか。今のプロジェクトはありていに言えば"炎上"している。 そんな中で「誰の考え方が一番正しい」のか分からなくなった。ので、今日はそんな話を書いてみようと思う。 この話の登場人物 あやぴー 僕です。 マツダさん 僕と同じ会社の先輩。エンジニア歴10年位。 モリさん 僕と同じ会社の上司にあたる人。エンジニア歴20年位の大ベテラン。 イノウエさん 元請けの会社に8月くらいに中途で入社したエンジニアさんで立場的にはプロジェクトリーダー(PL)的な感じ。転職するまでPL1とかVBとかのお仕事を
コメント欄 - （追記しました）現場の人からシステムさんに一言、いや二言三言いわせてほしい - 矛盾銀行株式会社
2013-12-06 現場の人からシステムさんに一言、いや二言三言いわせてほしい 日常業務四方山話 読んだ。 エクセルでできることができない何百万のシステム・・ いや、そうなんだよ。そうなんだよ。２回も言ってしまった。 ぼくもそう思ってた。ぼくもシステムに関してはじくじたる思いがあるので、ちょっと言わせてほしい。 ぼくもこの増田さんと同じように、社内のシステムさんとあれこれ打合わせすること多かったんだけど、いつも「それってExcelでできないのかね」と思ってた。Excelにはデータベース仕様あるじゃん。VBAあるじゃん。WEBクエリあるじゃん。素人感覚で「ちょいちょいっ」てできそうじゃん。 いや、本当にExcelで作ってほしいと思っているわけではないし、ましてExcelを作ってほしいわけではない。ただ、「現場の人間」の感覚からすると、システムさんのことって本当によくわからないのですよ。だか
Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
退職します。
流行の退職ブログが書ける日が来るとは！ 今月付で、都内某ソフトハウスを退職する。６年半務めた。 ２年前くらいからオフショア開発を始めた。近年では全部中国開発だ。だから辞めた。一番大切な部分を他人に任せているような気になったからだ。 最初は詳細設計書を渡して、成果物が納品されていた。そのうちに詳細設計の一部が現地対応のほうが早い（工数がかからない）となり、それがどんどん増えていった。こちらに中国語が喋れる人はおらず、大陸側に日本語をしゃべれるコーディネーターがいて仕事を進めている。 これはつまり、こちらから見れば大陸のソフトハウスは替えが効かなくなってしまっている。向こうは日本語が喋れるのだから、日本語圏の仕事ならどこでも問題なくプラグインできるというわけだ。最初のころは社内に中国語が喋れる日本人がいたのだが、日本語が喋れる中国人のほうが安いので入れ替わった。これも経過とともにそうなった。
SI事業者のプロジェクトマネジメント責任 東京地判平16.3.10判タ1211-129 - IT・システム判例メモ
納期までにシステムが完成しなかったことの責任がベンダ，ユーザのいずれにあるのかが争われた事例。 事案の概要 ユーザＸ（健保組合）が，ベンダＹに対し，基幹情報システムの開発を委託したところ，期限までに完成しなかったなどとして，支払済みの約2.5億円の返還と，損害賠償約3.4億円の支払いを求めたのに対し，ベンダＹは，システムの開発が遅延したのはユーザＸの協力がなかったことが理由であるとして，約4.6億円の損害賠償を求める反訴を提起した。 ここで取り上げる争点 ベンダＹ及びユーザＸは，契約上どのような義務を負っていたか。 開発が遅れて完成しなかった原因は何か。その責任はいずれが負うべきか。 裁判所の判断 【プロジェクトマネージメント義務】 裁判所は，次のとおり，システム開発業者が負うべき義務として，プロジェクトマネージメント義務があるということを明言している。 Ｙは、システム開発の専門業者として
要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22（平20ワ16510号） - IT・システム判例メモ
ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ
「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない＆サーバサイドしか見たことない＆WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
「ソフトウェア工学は失敗している」のか？
IGAKI Hiroshi @hirocell 見てみたら最近流行りのただの釣りタイトルだった．まぁでも，ソフトウェア工学の認知度が低いのは確かにその通りなんだろうなー．何でこの類の現場の人はソフトウェア工学の勉強とかしようと思わないんだろう．門戸はいつでも開いてるのに． 2013-03-23 09:54:43 IGAKI Hiroshi @hirocell アジャイルソフトウェア開発宣言をした人たちの中にソフトウェア工学の研究者が大量にいることとか知らないんだろうなー．まぁ知らなくても使えれば全然OKだとは思いますが，背景を知ってると知らないのだと理解度はだいぶ違うと思うだけどなぁ．残念だ． 2013-03-23 09:56:22
ソフトウェア工学は失敗だったという論評について
Yasuharu NISHI @YasuharuNishi アジャイルはソフトウェア工学の正統な進化形である、というのが僕の立ち位置だ。だから、アジャイルがでてきた今ソフトウェア工学は失敗だった、という論評を読むと、TPSが出てきたからベルトコンベアは無意味だった、というような論評に思える。生産的ではないし、レトリックとしても品が無い。 2013-03-24 17:47:31 Yasuharu NISHI @YasuharuNishi 最近は主にアジャイル、その昔もOOやCMM、構造か分析などもそうだったと思うが、ある技術が完璧に使えないとdisるという人たちは、生産的では無い。あらゆる技術は未来永劫完璧であることは無いし、多くの場合は現時点でも完璧ではない。 2013-03-24 17:50:44
軽減税率がITに与えるインパクト - 急がば回れ、選ぶなら近道
http://www.nikkei.com/article/DGXDZO50933940U3A120C1MM8000/ どうやら本格的に複数税率が消費税に適用されるようです。まだ、決定でもないし、今後の業界の猛烈な反対もあるだろうから、どうなるか分からないのですが、その辺を部外者的に（かつ元関係者的に）記録として書いておきますよ。 この軽減税率で、もっとも変更のコストがかかる「仕組み」の一つはITであることは、多分論を待たないと思います。特に、税率を複数適応する羽目になる流通・サービス系のITは下手をするとかなりのコスト負担になるところも出てきます。またか！またコストですか！いや、これこそがITなのですよ。 まず影響が出てくるところ予想すると、事の大小はありますが、ほぼ大抵のところで手を入れる必要がある気がします。んで、例によって、多分この辺が正確に予想できている、CIOを除く経営陣は皆無
ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した本当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1
技術的負債の把握と改善を促すために - mixi engineer blog
こんにちは. 先日水道を止められて水のありがたみを再確認したgoccyこと五嶋@たんぽぽグループです. 今回は, 先日q_zouさんから紹介のあった技術的負債を減らす取り組みの一環で, 僕が開発したビジュアライザについてご紹介させて頂きます. はじめに 弊社では主な開発言語としてPerlを採用しており, そのソースコード量は数十万行単位に上ります. 自社で開発したライブラリ群はプロジェクトルート下のlib/Mixi/配下に設置されており, 更にその下でサービスや用途毎にNamespaceが分かれています(lib/Mixi/APIやlib/Mixi/Photo, lib/Mixi/Voiceなど). ※以降, 文章中のNamespaceという表現は, これら(lib/Mixi/APIなど)を指すものとします. 本来であればNamespace単位で疎結合化されているべきですが, なかなかうまく
データモデル自体はアジャイルなのだが... - 極北データモデリング
全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。 データモデリングなきアジャイル開発は危ういか？：An Agile Way 平鍋さんが「(業務システムの)データモデルの変更コストは非常に高い」という意味のことを書かれている。これについて。 データモデル自体の変更コストは非常に低く、後戻りし放題である。新しいスキーマでcreate tableして、データをロードして、drop table/rename tableするだけだからな。 しかし、データモデルに手を入れるためには、同時に既存アプリケーションへの影響を調査して、漏れなく修正しなければならない。 プロジェクトが進行するほど、データモデル改変の影響範囲は広がり、修正点も増えていくだろう(元記事でデータモデルを「高リスク制約」つまり「プロジェクト開始からの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「システム構築に潜むヒヤリハット事例」なる教育ビデオ
