堺市職員がレンタルサーバーで個人情報1000人分“公開”、開発スキルが裏目に
堺市は2015年9月7日、同市の外郭団体の職員約1000人分の個人情報がインターネット上で公開状態になり、外部に流出していたと発表した。会計室の課長補佐級職員が個人契約していたレンタルサーバーに保存したデータが流出したという。 市の説明によれば、当該職員はシステム開発のスキルを持ち、市の外郭団体から依頼を受けて短時間勤務職員の出退勤システムを作成していた。この外郭団体から提供を受け、レンタルサーバーに保存していた約1000人分の個人情報が4月から6月までの間公開状態になっており、外部に流出した。 流出データには短時間勤務職員約1000人分の氏名、性別、生年月日、住所、電話番号と、給与実績データなどが含まれる。当該職員が業務上保有していた別の外郭団体のアルバイト応募者11人分の個人情報も流出した。 「選挙管理支援システム」が発覚の発端 こうした事態が発覚する発端になったのが、6月24日に堺市
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。 「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。 次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。 この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。 銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
ソフトウエア興業が破産へ
帝国データバンクによると、ソフトウェア受託開発のソフトウエア興業（東京都千代田区）が債権者から破産を申し立てられ、6月11日付けで東京地裁から破産手続き開始決定を受けた。負債総額は2013年3月期末時点で約191億円。 1974年に創業。通信関連や金融、官公庁などのシステム開発も手がけ、2008年3月期には約310億円の売上高があった。だが競争の激化による収益悪化や、研究開発、不動産購入などで売上高に匹敵する借入金が重荷に。リーマンショック後の10年3月期には売上高が約191億円に落ち込んでいた。 11年6月には創業者と社員らが法人税法違反で逮捕される事件が起き、信用失墜もあり12年3月期は約113億円まで売上高が縮小。昨年1月には資金ショートを起こして実質的に事業を停止していた。不動産売却による負債圧縮を進めていたものの、物件売却が進まなかったため、債権者が今年4月に破産を申し立てていた
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） - やまもといちろうBLOG（ブログ）
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
システムエンジニアであるということ。 - ミッションたぶんPossible
今日(もう昨日か)、ちょっと嬉しいことがありました。 オレは今、自社発信の携帯電話向けコンテンツの面倒を見てます。占いだったりタレントさんやアイドルのサイトだったり、まぁ色々です。うちの会社は今・・・ちゃんと説明は出来ないんですが・・・色々とゴタゴタしてて、まともに開発ができない状況です。それ以前からもシステム開発をする環境としてはかなりヨロシクない状況でしたが、今は輪をかけてヒドイです。運用も開発も面倒見なくては行けない状況にいますが、最近流行の「DevOps」なんて単語の意味するところからは程遠い位置にいます。この2ヶ月は障害対応とトラブル対応しかやってません。自転車操業よろしく、オレと相方とでヒーヒー言いながら、山のように積まれたタスクをなんとかこなしている有様です。「ロクでもない事になっちゃったねー。」なんて、皮肉と嘲笑で乗り切る日々。 そんな中でも(殆どはタスク満載で断らざるを得
要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22（平20ワ16510号） - IT・システム判例メモ
ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
