超上流のアンチパターン：ITproシステム開発プロジェクトの上流工程では、業務や要求の分析を通じてシステムが担うべき役割を定義していきます。ここで作成する成果物が、システム開発の起点となります。実際のプロジェクトで作成されている上流工程の成果物の中には、せっかく作ったのに使われなかったり、後工程になってから作り直したりと、品質面で問題のあるものも少なくありません。本連載では、実際のシステム開発プロジェクトの上流工程で発生した問題に焦点をあて、その原因や対策をお伝えします。
ＩＢＭ対スルガ銀行事件判決評釈（東京地判平成２４年３月２９日第一法規判例体系） - アホヲタ元法学部生の日常
巨象も踊る 作者: ルイス・V・ガースナー,山岡洋一,高遠裕子出版社/メーカー: 日本経済新聞社発売日: 2002/12/02メディア: 単行本購入: 22人 クリック: 313回この商品を含むブログ (94件) を見る １．はじめに ITクラスタに多大な衝撃を与えた、IBM対スルガ銀行事件判決。判決直後の「４月１日」に、その時点で明らかになっていた情報から憶測して、以下のネタ記事を書いたことは記憶に新しい。 判例評釈速報：ＩＢＭ／スルガ銀行システム開発事件〜東京地判平成２４年３月２９日判例集未登載（控訴） - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常 判決直後には、ＩＢＭ側の申立てにより開示されなかった*1判決本文が、平成２４年５月１６日、第一法規判例体系に掲載された。同業他社のデータベースを確認したところ、現時点の掲載はないとのことであるので、第一法規の「スク
スルガ銀が事実上の全面勝訴 IBMの責任認めた判決の深層
勘定系システムの開発失敗を巡りスルガ銀行が日本IBMを訴えた裁判で、東京地方裁判所は3月29日に約74億円の賠償を日本IBMに命じる判決を下した。4年間にわたった裁判は、ITベンダーとユーザー企業にそれぞれどのような教訓を残したのか。弁護士やIT業界の有識者への取材から、スルガ銀－IBM裁判の深層を探る。 「ある程度は過失相殺が認められると思ったが」。システム開発をめぐる紛争に詳しい、ある弁護士は、驚きを隠さない。勘定系システムの刷新プロジェクトが頓挫したことによって損失を受けたとして、スルガ銀行が委託先の日本IBMに約115億円の損害賠償を求めた裁判の判決についてだ。東京地方裁判所は2012年3月29日、日本IBMに約74億円の支払いを命じた。 金額だけを見ると、スルガ銀の請求のうち64％しか認められなかったように見える。だが実態は、スルガ銀の全面勝訴に限りなく近い。なぜなら、64％とい
“スルガ銀−IBM裁判”を振り返る - 週末スペシャル：ITpro
「約111億円」という巨額の損害賠償を求めて、スルガ銀行が日本IBMを提訴したのは2008年3月のことだ。それから3年余り、裁判は終盤戦を迎えているという。システム開発に多少のトラブルは付きものだが、これほど大きな損害賠償請求に至ったのはどうしてか。ここで、裁判で示された問題を振り返ってみよう。 プロジェクト破綻までの経緯と裁判の様子 スルガ銀行は勘定系の次期システムとして、IBMのパッケージ「NEFSS/Corebank」の導入を決め、2004年9月にプロジェクトがスタートした。だが、要件定義を3回繰り返すなどシステム開発は難航。2008年1月の稼働予定を延期した。日本IBMはスコープの大幅な縮小や追加費用を要求したが折り合わず、2007年5月にスルガ銀はプロジェクトの中止を決断した。 スルガ銀が日本IBMを提訴、システム開発の債務不履行による損害など111億円超を賠償請求 スルガ銀行と
年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う- 日経コンピュータReport：ITpro
次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省は「年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した（図）。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット（現TIS）が、契約を履行できなかった。 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」（厚労省年金局）。一方、システム基盤設計の進行は遅れた
「規模見積もり」が消えてしまう？
システム開発プロジェクトでは通常、事前に「何を作るか」を検討する。この作業を一般に「規模見積もり（Sizing）」と呼び、その結果が成果物スコープとなる。規模の単位はファンクションポイント（FP）やステップ数（LOC：Line of Code）、ユースケースポイントなどだ。しかし最近、この「規模見積もり」が消えてしまうのではないかと、危機感を募らせている。 なぜこんなことを思うようになったのか。それは、クラウドサービスを使った開発や、アジャイル開発が広がりを見せているからだ。これらはスピード重視の開発だけに、作りながら実装すべき機能を詰めていくことが多い。つまり、何を作るかという規模見積もりに相当する作業を、工程の中に組み込んでいるとも言える。 「それならそれでいいではないか」と思う人がいるかもしれない。実際あるベテランのプロジェクトマネジャーは「何を作るかを考えるのが上流工程の役割。要求
“ダメなシステム部門”から脱却するための4カ条
いままでのシステム部門は、システムを整備・維持することが主な仕事であった。ユーザー部門の御用聞きに徹し、彼らの要望にもとづくシステムを作り、それを維持する「システムのお守り役」を担っていた。 しかしながら、今のシステム部門は経営層からの期待に応えていない。前回の『経企部門が吐露する「システム部門への不満」』で紹介したように、「なぜ事業戦略の遂行にもっと関与できないのか」「なぜ変革を促すような提案を積極的にできないのか」「なぜ成果に対する説明責任を果たせないのか」――といった不満があがっている（図1）。 このことはシステム部門が「単なるシステムのお守り役」ではなく、システムという道具を駆使して「ビジネスを変革する集団」としての役割が期待されていることの表れであろう。こうしたビジネス変革集団を、ここでは「ビジネス・トランスフォーメーション・オフィス（BTO）」と呼ぶことにする。 前回述べたよう
療養費の通知書を作るシステムの仕様がすごい | 水無月ばけらのえび日記
公開: 2011年8月21日15時55分頃 こんなニュースが……「療養費支給額「３兆円」 都広域連合がケタ違いのミス (www.asahi.com)」。 東京都後期高齢者医療広域連合からはおわびの文書が出ていますね。 後期高齢者医療高額療養費支給決定通知書誤記載についてのお詫び (www.tokyo-ikiiki.net)後期高齢者医療高額療養費支給決定通知書の誤記載について (PDF) (www.tokyo-ikiiki.net)本来は「平成23年8月16日」「￥1,351」となるはずのものが、「平成23年80月16日」「￥3,510,000,000,000」となってしまったそうで。 その理由がちょっと驚きです。 同広域連合によると、通知書を作る際、職員がパソコン操作を誤った。支給額欄には１３桁の数字を入れることになっているが、１３５１円を支給する場合も千の位の「１」の前にゼロを９個入力
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
サーバ管理者日誌 2010年12月07日
以前に、 IT版ストックホルムシンドローム[http://www.nantoka.com/~kei/diary/?20100819S1] として、 システムを人質 に取られた結果、システム業者の言いなりになっていく発注者を指摘した。 今回、「システムを人質に取られる」ということがどういうことか。 ある図書館[http://sasaguri1.uxt.cknet.co.jp/] の事例を入手したのでご紹介したい。 「図書館システムレベルアップに関する提言書」という資料を入手した。「提案書」ではなく、「提言書」である。 この時期、笹栗町は、導入していた旧版のMELILからのシステム更改の時期を迎えており、旧版のMELILを導入していた千代田興産株式会社が、図書館システムの「レベルアップ」を行うための検討資料として「提言」した文書であろう。 旧システムを導入、保守していた立場であるから、ある意味
南米発のツールがIT業界に与えるインパクト
「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus（ジェネクサス）」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
第3回 君も“赤字”だね
IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（毎週月曜日更新、編集：日経情報ストラテジー） ダメな“システム屋” 「聞いてください！あのプロジェクトはもうダメです」 上司 「何、どうした？」 ダ 「問題山積なのに、リーダーの話が長くて何も解決しないし、先に進まないのです」 上 「問題山積って、どんな問題がいくつあるの？」 ダ 「もう大変です、契約、体制、技術、期間、何もかも問題だらけなんですよ」 上 「だから、どこがどのように問題なの？」 ダ 「一番問題なのはリーダーの話が長いことですよ。話の長い男は赤字ですよ！」 上 「話が大げさな君も赤字だと思うけど」 ダ 「・・・」 ダメな理由：減点法が
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
設計ミスをなくそう！現場を救うレビューの秘訣：ITpro
設計レビューは決して，次工程に進む儀式ではない。設計ミスをなくし後工程での手戻りを防ぐ，貴重な機会だ。やり方を工夫すれば，そんなレビューを実現できる。現場が編み出したレビューの秘訣を紹介する。
プロジェクトの進捗遅れはなくせる
「システム開発プロジェクトで、進捗をきちんと守ることなんて到底無理ですよ。いいシステムを作ろうと思うほど、進捗が遅れるんですから。雑誌作りだって同じでしょう？」。 日経SYSTEMS 2010年8月号で「進捗遅れをなくそう」という特集を担当するにあたり、懇意にしているITエンジニアのAさんに相談したところ、特集の意義を真っ向から否定された。 記者は言葉に窮した。自分で言うのも何だが、記者は進捗（締め切り）遅れの常習犯である。自分のことを棚に上げて、システム開発プロジェクトの進捗遅れに意見する資格はない。 それでも、一点思うところがあったので指摘した。経験的に言って、進捗を遅らせたほうがいい記事になるとは限らない、ということだ。むしろ進捗通りに進んだときのほうが、記事の出来はよいように思う。 記者の指摘に対し、Aさんは「システム開発でも同じかもしれない」と答えた。単純な話、進捗を守ると余裕期
現状：オープンシステムが危ない
「オープンシステムは素晴らしいものに思えた。早く開発でき、拡張の自由度が高く、製品の価格自体も安いのでコストダウンもできる。だが実際に導入してみると、それまでメインフレームで培ってきた運用体制をたった半年で失った。あっという間だった」。合成ゴム製造大手の日本ゼオンの情報システムを開発・運用するジスインフォテクノの石橋健取締役は、1990年代半ばをこう振り返る。同社は現在、運用体制を10年越しで立て直している最中だ。 オープンシステムの輝きに隠された影の部分。それが今ユーザー企業を苦しめている（図1）。早く安く作れるというメリットは、運用のことまで意識しないままにオープンシステムを乱立させた。その結果、運用がままならない状況を生み出した。新技術を使えるというメリットはベンダーの開発競争の成果だが、それが製品や技術の短命化につながった。マルチベンダーの製品を組み合わせることで1社に縛られなくて
ベンダ任せにしないで情シスもPDCAサイクルを回せ！
基本設計の工程がなかなか終わらないので、状況がどうなっているのかを開発ベンダに確認したところ、開発ベンダからこのような返事をもらったことはないでしょうか。 仕方なく、ひとまずコスト追加やスケジュール変更をしたにもかかわらず、リリースの直前になって、今度は次のような要望を受けた方は多いはずです。 昨今の経済環境下では、経営層やユーザー部門からシステム開発に向けられた視線は厳しく、コストやスケジュール削減の圧力は高まるばかりです。その一方で、予定通りにシステム開発を完了させることは難しく、追加コストやスケジュール遅延、運用でカバーするというのが、多くの開発現場では半ば当たり前のようになってきています。 筆者は、このように予定したコストやスケジュール通りにシステム開発が進まないという状態のことを、「プロセスのギャップ」と呼んでいます。この「プロセスのギャップ」が常態化している現場では、「システム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://itpro.nikkeibp.co.jp/members/bn/mokuji.jsp?OFFSET=0&MAXCNT=20&TOP_ID=340063
WBSでプロジェクトを成功させる - ＠IT情報マネジメント