スルガ銀-IBM裁判で最高裁が上告を棄却、日本IBMの約42億円賠償が確定
勘定系システムの開発中止の責任を巡り、スルガ銀行が日本IBMに約116億円の支払いを求めた裁判で、最高裁判所は2015年7月8日、両社の上告を棄却する決定を下した。これにより、日本IBMに約42億円の賠償を命じた東京高等裁判所の判決が確定した（ITpro関連記事：スルガ銀-IBM裁判で両社が上告）。 スルガ銀行は2008年2月、勘定系システムの刷新プロジェクトが頓挫した責任は日本IBMにあるとして、約116億円の損害賠償を求めて東京地方裁判所に提訴した。 東京地裁は2012年3月、プロジェクトの企画・提案段階で、日本IBMが提案した勘定系パッケージ「Corebank」の同社による機能検証が不足していたことが、システム開発においてITベンダーが負う義務「プロジェクトマネジメント（PM）義務」違反に当たるとして、日本IBMに約74億円の支払いを命じる判決を言い渡した。 一方で東京高裁は2013
理不尽なユーザーの態度に振り回されない三つの極意
この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前々回（予期せぬ“危機”に事前に手を打つ秘策）と前回（多数決で仕様を決めて“炎上”、少数意見に目を向けよ）は暗闇プロジェクトに役立つ要件定義の進め方を紹介した。 暗闇プロジェクトでは、ユーザー側の理不尽な言動や行動にベンダーが振り回されるケースが少なくない。今回はそうした場合に備えるための三つのセオリーを取り上げる。 セオリー1 相手の土俵で相撲を取らない 「我々はITの専門家ではないので」。システム導入プロジェクトで、顧客やユーザーがよく口にするフレーズである。こう言っておくことで、何かあった場合の責任を回避したいとする担当者の気持ちが表れている。 ベンダーは、こうした顧客の態度を嫌がるどころか、むしろ歓迎する。プロジェクト推進の主導権を握りたいと考えていたところ、頼まずとも向こ
第11回 プロマネのこんなアサインは「トラブルのもと」
プロジェクト管理に関する本や研修やセミナーなどは実に多い。そして「プロジェクト管理はこうだ。システム開発はこうだ」などと色々と語られている。だが、中小規模のプロジェクトと大規模なプロジェクトのやり方の相違点や注意点については、ほとんど言及されていない。 すると、それを学んだ多くのSEはプロジェクトの規模に関係なく「プロジェクト管理やシステム開発はこうやるもんだ」と往々にして一律に考える。事実、そう考えてプロジェクトをやっているSEは少なくない。これはIT企業の経営者や営業なども、しかりである。 だが、筆者の経験からみると、それには少なからず疑問を感じる。それは、大規模プロジェクトをやったSEが中小規模のプロジェクトをやると、往々にしてトラブルを起こすからだ。また、中小規模のプロジェクトをうまくやっていたSEが大規模プロジェクトをやる場合もトラブルを起こすケースが多い。それで多くのIT企業が
［政府システム再起動4］年金システム刷新再開、2020年稼働を目指す
これまで3回にわたり、特許庁のシステム刷新について説明した。第4回は、特許庁システムと並ぶ大規模システムである年金システムの刷新プロジェクトを、続く第5回は政府システム全体のITガバナンスについて解説する。 2007年以来、事実上停滞していた年金記録管理システムの刷新プロジェクトが再始動する。厚生労働省は、個人番号（マイナンバー）管理を含めた基盤システムの設計、開発、構築を先行して進めるとともに、刷新の本丸となる業務アプリケーション開発の入札に向けて準備を進めている。 年金記録管理システムの運用保守にかかる費用は、従来の年間550億円から、3割減の300億円と大幅に減る見通し。総投資額は、計画が始まった2006年から終了予定の2020年までの総計で、法改正に伴う修正を含めて1800億円ほどとみられる 大型プロジェクトの重複で技術者が不足する「2015年問題」の動向にもよるが、早ければ201
［政府システム再起動1］特許庁の正攻法、内製・調達力を高める
特許庁のシステム刷新プロジェクトが中止に追い込まれてから、3年（ITpro関連記事：55億円無駄に、特許庁の失敗）。同庁は、失敗の事後処理と並行して、システム刷新の再開に向けて粛々と準備を整えていた。過去の失敗を分析し、新たな計画に反映していった。同じ間違いは二度と繰り返さない覚悟で、システム刷新に再挑戦する（写真1）。 今後、数百億円を投じ、8年がかりでシステムを順次更新する。現行システムは運用・保守に年間250億円を費やしており、システムの刷新で費用の3割減を目指すほか、審査業務の迅速化、利用者の利便性向上を図る考えだ。 今回のプロジェクトは、四つのポイントで過去のプロジェクトとは大きく異なるものとなった。といっても奇をてらうものではなく、いずれもシステム開発の正攻法に沿ったものである。 （1）特許庁の職員が自ら業務を可視化 （2）入札方式を技術重視に （3）開発の難易度を引き下げ （
［疑問7］課題解決がフェーズをまたぐ場合に漏れを防ぐコツは？
この連載では、PM（プロジェクトマネジャー）やメンバーが抱く、プロジェクトマネジメントに関する「素朴な疑問」に答えていきます。筆者がまとめたプロジェクトマネジメントメソッド「PROKAN（プロカン）」をベースにしていますが、PROKANのことをご存じない方でも読み進めていただけるよう配慮して話を進めます。 前回（メンバー間の情報共有の良い方法やコツはある？）は、メンバー間の情報共有を取り上げました。今回のテーマは「課題管理」です。 プロジェクトでは日々課題が発生します。いかに課題を効率よく共有・管理して、解決（クローズ）していくかは、プロジェクトを成功に導くうえで大きなカギとなります。この点について、PROKAN研修を受講したPMや、これからプロジェクトマネジメントを担う若手層から、こんな疑問が出てきました。 【疑問7】 プロジェクトのあるフェーズで発生した課題は、できるだけそのフェーズ内
［第11回］プロジェクト成功のカギ
システム開発の失敗を経営陣に報告する―。これは最もつらい仕事である。「何をしていたのか」と怒鳴られても、真の原因を言えない場合が多いからだ。 プロジェクトの成功には、経営と現場を結ぶ「ディレクション」が欠かせない。その仕組みが経営全般に役立つことを、経営陣になんとか理解してもらおう。 情報システム部門の責任者にとって最もつらい仕事は何か。おそらくシステム開発の失敗を経営陣に報告することだろう。「期限までに開発が終わりません。開発費の増額を認めていただきたい」と言った途端、「聞いていた話と違う」「何を管理していたのか」と容赦無い言葉が浴びせられる。 「要件定義の漏れ」「データベースの設計に誤り」「採用した技術の不具合」などと遅れの理由を説明しても、経営陣は納得せず「どうして気付かなかったのか」と追及してくる。「追加分の開発費を稼ごうとしたら一体どのくらいの売り上げが必要か、君は分かっているの
［マネジメント編1］モジュールは「人間関係」で分割
「暗闇プロジェクト」ではリスクを見極め、必要なら即行動に移す姿勢が欠かせない。システムのモジュールを「人間関係」を基に分割するといった“非常識”な施策も大いに有効だ。 この連載では、先の見えない「暗闇プロジェクト」でトラブルに陥らないための実践的なヒントやノウハウを紹介している。今回と次回ではメンバー追加やモジュール分割、課題管理、品質管理に関わる六つのセオリーを紹介する。 セオリー1 メンバーの追加は “下っ端”が判断する 一つめのセオリーは、「プロジェクトにメンバーを追加すべきどうかは現場の“下っ端”が判断する」である。 「遅延しているプロジェクトに人を追加すると、さらに遅れる」というブルックスの法則をご存じの方は多いだろう。筆者の経験でも確かにその通りだと思うが、こんな例もある。「デスマーチ（失敗プロジェクト）」に陥る寸前で踏ん張っていたあるプロジェクトでは、要員を追加することで、明
［プロジェクト運営編2］不安は解消せずにうまく付き合う
現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回に続いて、プロジェクト運営に関するセオリーを取り上げる。 セオリー3 「見える化」は ほどほどに セオリーの三つめは、「見える化」はほどほどに、である。プロジェクト運営で見える化が重要だとよく言われる。とはいえ、何でもドキュメントにすればよいわけではない。目的を明確にした上で、見える化のメリハリを付ける必要がある。それを怠ったのがベンチャー企業B社だ。 B社はこれまで「アジャイル開発だから」との理由で、ドキュメントをほとんど作成していなかった。システムに関する知識が属人化している状況を問題視したB社の経営層は、開発標準を整備するよう現場に指示。半年後には大企業顔
［合意形成編2］半年前の合意は“期限切れ”
現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介する。今回は前回に続いて、合意形成に関するセオリーを取り上げる。 セオリー3 難しい合意形成は 曖昧に進める 前の例のような1対1の対立でなく、「欲しい機能」や「予算」について複数のステークホルダーが異なる要求を出すケースもある。この場合、合意形成の難易度はより高まる。要求を出すのが“偉い人”の場合はなおさらだ。 「ゴールの共有」「デシジョンツリー」「チェックリストを用いた代替案の抽出」「メリット・デメリット表」といった合意形成のテクニックは、あまり役立たない。現実には、なかなかきれいに当てはまらないものだ。 こうした難しい合意形成については、あえて曖昧に進めるのも一つの方法である
（第4回）ダメ発注その3、延期は平気の“自己中なスケジュール”
ユーザー企業のIT部門の多くは「発注者責任」を果たせていないし、そもそもそのことに無自覚だ。その結果、発注のQCD（品質、料金、期日）という3つの領域で大きな問題を引き起こす。 この特集ではこれまで、発注のQとCにおける問題点についてみてきたが、最終回の今回は発注のD（期日）、つまり特集の第１回の冒頭で紹介した開発着手などのスケジュールを巡る問題に焦点を当てる。そして最後に、ユーザー企業のIT部門に求められる発注者責任の自覚について言及する。 開発着手の延期がトラブル生む 開発スケジュール面での問題は、ユーザー企業のIT部門とITベンダーの双方にとって、いわゆる“あるある話”だと思う。だが、ユーザー企業にとっては“軽い気持ち”で伝えた通告で、一方のITベンダーにとってはパニックになるような事態。両者の間でその違いは大きい。 「開発着手の直前になって申し訳ないが、今回のプロジェクトは一時延期
SIerで成長できないプロジェクトマネジャーの寒い将来
SIerにとって、有能なプロジェクトマネジャーの育成は最も重要な経営課題の一つだ。なにせ、彼らの腕次第でシステム開発プロジェクトの損益が決まってしまう。下請けのITベンダーだけでなく、プロジェクトの途中でワガママを言い出しかねないユーザー企業を適切に管理して、QCD（品質、コスト、納期）を満たすシステムを作り上げるには、相当のスキルと人間力を持ったプロジェクトマネジャーが必要不可欠だ。 さらに、SIは人月商売のため、技術者数によって売り上げのアタマが抑えられるが、SIerは内製比率を下げて、下請けのITベンダーにプログラミングなどの開発業務を丸投げすれば、請け負える案件が増え売り上げも拡大できる。しかし、それが可能になるのは、ベンダーマネジメントに長けた優秀なプロジェクトマネジャーがいればこそである。 このため、SIerはプロジェクトマネジャーの育成に力を入れる。ところが現実はなかなか厳し
知らないうちに上司を怒らせる10の方法 | ライフハッカー・ジャパン
Inc.：ガムをクチャクチャかむ、会話を中断する同僚、いつも最終決断を下すチームのメンバー...誰もがそれぞれ、オフィスでのイライラを持っています。しかし、いくつかの行動や仕事の習慣は、上司との関係において、本当にマイナスの影響を及ぼす可能性があります。 最近、ホーム·デポに買収され、オンラインウィンドウショップ「Blinds.com」を運営する企業のCEOであるJay Steinfeld氏が、その立場から考える「してはならない10のこと」は以下の通り。 1．本当は知らないことを知っていると言う 私はご機嫌取りというよりは知ったかぶり屋かもしれません。「知らないけど、そのうちわかるだろう」という答えは、会話の中でごまかすよりは断然良いです。たしかに、おそらく自分の立場上、知っておくべきトピックやデータの要素はあります。しかし、ますます職能上の枠を超えていくチームの中や、どんどん幅広くなるプ
ステークホルダーマネジメント 会議運営のワザ
会議運営の仕方一つで、ステークホルダーは協力的にも非協力的にもなる。一人ひとりの参画意識を高め、協力者になってもらおう。キックオフ、会議進行、計画策定、メンバー変更時のワザを取り上げる。 プロジェクトの全体キックオフミーティングや、各利用部門の実務代表者が参加する要件定義の検討会といった会議で、どうやって協力者を増やしていくか。ここでは、そのワザを紹介する。 まずは、全体キックオフや1回目の検討会で参画意識を高めるワザだ。最初の会議が、協力者を増やす土台になる。 次は、印象を良くする会議進行のワザ。参加者全員が言いたいことを言えるように進行する。これにより、プロジェクトに対する参加者の印象は良くなり、協力的になる。 参加者全員が検討会に継続して出席しやすくすることも重要である。いつも欠席者がいるようでは、他の参加者の参画意識にも悪影響を及ぼし、協力者を減らす要因になる。そこで、欠席者をゼロ
最新版PMBOKに学ぶ ステークホルダーマネジメント
最新版のPMBOKではステークホルダーマネジメントが知識エリアに格上げされた。そこに盛り込まれた知見はどんなものか。PMは何をすべきか。PMBOKの推進団体、PMI日本支部の翻訳責任者が解説する。 2012年12月に、PMBOKガイド注1の最新版である第5版が発表されたのをご存じだろうか。第5版では、10番目の新しい知識エリアとして「ステークホルダーマネジメント」が新設された。タイムマネジメント、コストマネジメント、品質マネジメントといったプロジェクトマネジャー（PM）の主要な活動と同列にステークホルダーマネジメントを扱う、というわけだ。 注1）PMBOKガイド：正式名称は「A Guide to the Project Management Body of Knowledge」。米Project Management Institute（PMI）が作成し発行している。 知識エリアの新設は、
今PMに求められるもの---ステークホルダーマネジメント
今PMに求められるもの---ステークホルダーマネジメント 協力者を増やす活動は必須、PMBOKでも主要テーマに ステークホルダーの合意形成が難しくなっている。プロジェクトへの「無関心」「抵抗感」がまん延しているからだ。そんな状況を打破する鍵が「ステークホルダーマネジメント」である。 「あの一言が失敗の引き金になるとは」。こう話すのは小売業のシステム部門に所属する高野重徳氏（仮名）だ。 高野氏は2012年、情報系システム刷新プロジェクトのマネジャー（PM）を任された。そのシステムは社内の大半の部門が利用するもの。そこで六つの主要な利用部門から課長クラスのキーパーソンを集め、要件定義の検討会を開催した。 初回の検討会で高野氏は、検討会に駆り出された参加者を気遣いこう言った。「本業が忙しいでしょう。検討会には、可能な範囲でなるべく参加していただければと思います」。 この言葉を、参加者は「忙しけれ
リスクを「好機」と捉えていますか？
唐突だが、あなたはあるシステム構築案件のプロジェクトマネジャーだったとしよう。あるとき部下のチームリーダーが病気になり、リリース間際の数日間現場を離れてしまう事態に陥った。さて、あなたならどうするか。選択肢は二つ。一つは「自分がチームリーダーの役割を担う」、もう一つは「サブリーダーに任せる」だ。 実はこれ、リスク管理に関する典型的な例題である。サブリーダーに任せるのは不安だろう。「自分がチームリーダーの役割を担う」を選んだあなたは、急場をしのぐ上で賢明な判断を下したといえる。しかしこの判断は、リスクを「脅威」としか捉えていない表れだ。現場は滞りなく進むかもしれないが、実は一方で大きなチャンスを逃す可能性がある。 「サブリーダーに任せる」という判断を下したあなたは、リスクを「好機」として捉えられる力がある。これは大きな武器になる――。記者はこのことを、日経SYSTEMS4月号の特集1「挑むプ
頭の中がごちゃごちゃしていませんか？ 「yPad」で整理整頓しましょう | ROOMIE（ルーミー）
みなさん、「yPad」ってご存知ですか？ 人気アートディレクターの寄藤文平さんが考案したスケジュール帳です。yPadは、寄藤さん自身の“困る”や“欲しい”をカタチにしたもの。 「いくつかの仕事が同時進行している時に困るのは、それぞれの進行のリズムが違うこと」。それを把握するために、「一日の動きと2週間分の流れを同時に確認する、プロジェクトの進行と一日分のタスクを同時に確認する」べく開発されました。 その特徴は見開きで2週間の予定を見渡せることで、2週間ごとに見開きのノートページが設けられています。 左ページは2週間分のタイムスケジュール(横ライン)で、右ページはプロジェクトやTO DOリスト(縦ライン)を書き込めるようになっています。1度に見渡せて、美しくつながります。 詳しく見ていきましょう。 先ず左ページの日付のところは自分で書き込みます。そうなんです、いつからでも使い始められるのも「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バッファーマネジメントとモニタリングシート
プロジェクトが遅れるメカニズム