失敗プロジェクトマネージメントの事例研究                               ISSN 2187-5049 Vol.08 2014-01-03 (c) naoki inagaki
　 PM(Project Manager) ＆ RM(Risk Manager)For You！




　  研修コース
１：開発の背景
　①金融機関は、従来に増してアウトソーシング傾向を強める中にあって、金融庁検査や日本銀行考査が委託業務管理と受入試験の負担を金融機関に期待する姿勢がある。
　　　（本来ユーザー側の具備すべき義務のはずである。各種委員会を設置したのみで形骸化し実効を伴っていない？）
　②昨今、東証事件やスルガ銀行事件など金融機関裁判が目立つが、小事件やシステム障害で顧客信頼性が揺らいる。
　　その根本に、システム力不足やシステム企画力の不足が顕著になりつつある。（人材不足）　　　※人材不足（約185KB)
　③大型プロジェクト案件が無くなり、現場を通した次の世代人にシステム力の承継が望まれているが、案件が見当たらなく人材不足である。（OJTが困難）
　④今後、金融機関のシステム体力不足傾向に反比例して、複雑巨大化するシステムの為にプロジェクトマネージメント力/リスクマネジメント力に応えるて行かねばならない。



２：養成コースの狙いと効果
　①ベンダー、ユーザー共に社内人材養成でOJTや先輩からの知恵の伝達機会が少なくなり、過去経験の知恵伝達は困難になっている。
　②従来よりＰＭ教育としてWBSやPMBOK/CMMI等のコースはあったが、基本管理項目を網羅した解説であったり資格取得のためであり、現場実務プロジェクトに生かされていない知識偏重の傾向がみられた。
　　本コースは実際にあった判例を中心にケース教材としているので、現場の目線で自分が実体験できないケースであり実務に近い仮想環境下のなかで自己発見で身に付ける事ができる。
　③最近のIT裁判判断で明確になりつつある「プロジェクトマネジメント義務」と「協力義務」や「過失認容の線基準」を体感しながら身につける。（ITSSレベル5～6目標）
　④従来のPMBOK/CMMI管理型人間にない、考える力の源泉である「リスク感覚の素養ある新しいPM/RM人」を目指す。→ISO27000指向の形成過程でシステムに係わる人の自己革新の動機づけのマインドセットができる。
　⑤研修成果は、受講後のe-mail learningでフォローする事により、現場で自己発見の「気づき」や「ひらめき」を組織的に蓄積し、誰でも共有・閲覧できるコミュニケーション力の源とする。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　

３：コースの概要
　①コースは、「集合教育２日→現場復帰３か月後→再研修２日＋フォロー・コース」の最初のステップ提供にある。全体は貴社と協議させていただきます。
　②教材は、カテゴリー別に抽出されたIT裁判の判例文（１６のケースの中から打合せ選択制）を解読するなかで、自己学習で気づきくPM/RM項目を見出し、PMやRMの実態との差を自身で確認するコースである。（個別企業毎の事前ご相談で設計）
　③カリキュラムは２通りとして、ベンダー側PMは金融業務システム知識に比重を置き、ユーザー側金融機関側PMはPM技法そのものに重点を置く。　　　
　④金融機関実務ケースに基づき進行する過程で、直接現場の会話に生かされるように現在プロジェクトに携わっているPMO/CIOがコーチィングし対話する。
　⑤学習後のフォローの為、顧客品質会議やリスク委員会に参加し質問や報告を受けフォローする。

　カリキラム紹介
　　　○基本理念
　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　全体概要説明（約２７KB）

　　　○コース日程（金融業務編）
　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　※研修日程基本（約17KB）

　　　○研修（座学のフレーム）
　　　　　同一ケースを２面から眺めるため（便宜的に原告側と被告側に分かれて）の構成で、参考材料に原告主張と被告主張を教材として渡す。
　　　　　それに基づき、自由討議で「自分ならばこうした、こういう対処方法もあるのでないか・・・」等議論をする。
　　　　　その過程でいままでの自分既知識や既経験で気ずかない事の新発見は必ずメモをとる。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　※進行基本フレーム（約50KB）


　　　○この研修の狙いである『各人の「気づき」をどの様に企業力に高めるか！』
　　　　　　この課題に対する基本は、QC運動や改善運動と同様その企業文化として「風通りの良いボトムアップ」にある。
　　　　　　　　（そして、その方法論は、各企業様の文化によって異なるので典型的な試案を示唆する）

　　　　　　研修部門は、受講生各人がその「動機付けけ」が出来て、「気づき」が（表面に表されなくても）他人にも理解されたと思われ、
　　　　　　複数人へ拡大する「基点」となるチャンスを与える事であり、本提案のIT判例を使った座学によるケース学習は組織的フォロー態勢の確立で、より生きてきましょう。



　　　　個別企業様の研修体系企画・編成のお問い合わせは、IT-ADR　Centerまで



このページの先頭へ



　　ケース別一覧表教材　　IT領域別のシナリオと学習ポイント

　（注１）：この一覧表記載の判例は、必要な事柄のみ抽出しているので事案を解説するものでない。©Naiki Inagaki 2010
　（注２）：ケース１は判例の見方でありコースに必須。ケースM-1,M-2は経営者向き、ケース２以降を、受講者レベルと研修目的に照らして個別に選択する。
　（注３）：ここでは、便宜的にベンダーとユーザー側の表現を使っていますが、企業間・グループ間にも当てはまる事案である。

ケース
No.		 研修領域 シナリオ概要と背景 ケースから学ぶ学習ポイント
（PM/RM　職責から学ぶべき教訓点）		 有用と思われる参考資料・条文/JIS/ISO 概要図
1 上流工程 コンサル会社がユーザとベンダーの中間に入り、パッケージを使ったシステム業務開発を委託したが、稼働にいたらなかった事案。コンサル会社が原告となりベンダー側に債務不履行としたケース。 法的視点から債務不履行を問われかねない争点となった中核部分のポイントを抽出、裁判所の視点やPM推進過程での教訓を学ぶ。
　①パッケージ適用時の方法、留意点
　②カスタマイズ仕様書の内容と非機能部分の表記法
　③PMの途中交代時の課題		 原告、被告の主張の対比を行いその論争点から教訓を得る。 PDF1
2 コンサル会社の幻想 コンサル会社がユーザー側の指導・助言役としてコンサル業についた３者契約であったが、稼働に至らなかった。ユーザは納入プログラムの不具合が多く、旧システムに戻し混乱を極め開発ベンダーに損害賠償請求したが、納入プログラムには、ユーザの使用に耐えない重大な瑕疵がありベンダーの全面敗訴のケース。 ユーザーはコンサル会社の「美しい提案」を受け、原告（ベンダー）に業務委託請負契約を行った。要件定義作業やカスタマイズ仕様書の未確定（途中Fit & Gap作業をおこなったが、成熟度低く解釈も双方ずれがあることが後刻鮮明になる）のまま納入をした。
不具合箇所の瑕疵部分の対応手順の齟齬、品質管理が不在によるPMの失敗ケース。		 原告・被告企業における情報の非対象性に依拠した、プロジェクトマネージメント義務違反の視点から要求定義書、仕様書確定作業（ユーザー側の主張JIS　0160-1996）。
民法545条、632条、633条、634条、641条。		 PDF2
3 ソフトウエアの瑕疵判断 ユーザーはリース会社の提案を受け３者で開発契約を締結。ベンダーが完成納品した残金を支払えの起訴に対し、被告（発注者）は納品物が業務に耐えられない瑕疵があり、納品物は債務不履行であるとしたケース。 システム全体の総合設計やPM推進に齟齬が混在したプロジェクトで「裁判所」は、当該ソフトウエアを、どのような点を、どのような基準で、どのように判断したかの法的視点を学習する。
要求定義書にあるないに係わらず、納入ソフトウエアが処理時間等で使用に耐えない状況では、ベンダーはユーザー業態の本質や業務の流れを調査・分析し理解する義務があるとされた点の学習。		 ISO15504取得管理プロセスのためのプロセス評定（項目　　）
CMMI		 PDF3
4 取締役の善管注意義務・忠実義務 住友信託銀行のプロジェクトファイナンスに対する株主代表訴訟で棄却された事例
役員16名は、それぞれ￥56億円支払えのケース		 銀行のプロジェクトファイナンス業務における「リスクマネジメントのリスク測定技法」と実際の業務執行内容（業務規定/職務規程）の不一致/齟齬があるとして、どの様な争点になったか。
ガバナンス上どのような視点が必要か？		 取締役の善管注意義務と忠実義務違反の解釈
『商法254の3、254-3項、266-1、267条』『民法644条』		 PDF4
5 システム障害と
システム保守責任		 インターネットサービス業者にプログラムの脆弱性を指摘した後に、不特定多数の聴衆にセキュリティーホールから進入し個人情報ファイルを入手し映像実演公開をおこなった。
被告は懲役8ヶ月、訴訟費用全額支払え		 プログラム作成が脆弱性の指摘行動やネットワークの安全性を高める行為であれば、犯罪行為となる「違法性」は阻却されるか？
法的に「違法性」はどの様な視点から構成要件となるか？		 『不正アクセス行為の禁止の関する法律』
　第3条1、3条2、8条1の構成要件		 PDF5
6 不具合の法的判断 販売管理システムの請負契約の納入システムに重大な瑕疵が認められて契約解除が有効となった事例
被告は￥3258万、訴訟費用3/4支払え		 どの様な「不具合」が契約の目的を達成することが出来ない重大な瑕疵であるか？
不具合事象が争点になり、「仕様問題か？」「瑕疵か？」「修正作業範囲か？」の事実認定で、実環境によるテスト確認で約５年を要した。
プロジェクト・スコープ・マネジメントにおける、新技術導入（新Version汎用DBソフトや開発ツール）に潜むリスクマネージメントと『品質管理技法』不在によるプロジェクトの泥沼化。		 ①JISQ9001:2000『品質プロジェクトマネジメント』
②PMAJ；リスクマネジメントにおける要件の不確実性に係わる事前検証
③『非機能要求の6分類139小項目』非機能要求グレード検討会；2009年9月（予定）

請負契約における『民法635条、541条の類推適用』		 PDF6
7 契約書記載の
「基幹システム立ち上げ」の解釈		 「新基幹システム」のシステム範囲と「立ち上げ」の意味・検証の内容の相違でボーナス労賃を支払わなかった例で、信義則・権利濫用を生じる余地があるとされた事例；「オリエント信販事件」 一DBに統合した新システムにおいて基幹系、情報系、コールセンターとの覚書記載の「新基幹系システム」とはどこまで含まれるか？
複数ベンダーがらみのシステムで「立ち上げ」とはどの様な状態をさすか？通常業務を行う事が可能と判断した司法の判断基準は？		 RexBlack『基本から学ぶテストプロセス管理』日経BP社
外部PM委託の場合の支払条件付き（業務名）記載の労務覚書の労賃支払い（労働判例）		 PDF7
8 著作権侵害 特定の第3者にのみ許諾されたプログラムにつき、許諾を得ずプログラムを貸与した行為は貸与権の浸害である。
貸与を受けた者は使用料相当の不当利得返還が認められた事案。		 ①「著作権侵害」における貸与権、複製権、譲渡権の考え方
②「使用権許諾」を行う場合の使用権設定契約の定義は		 リスク管理と訴訟
『ソフトウエア開発プロジェクトのリスク管理』John McManus著　構造計画研究所		 PDF8
9 PM義務と協力義務 国保とSI業者において、請負契約時のSI業者に「PMの適切な対処の義務」があると明確に判示された事例。
 双方に課せられている、ベンダー側の「プロジェクトマネジメント義務」とユーザ側の「協力義務」のそれぞれの内容と履行時の齟齬について司法の判断は？。 PMAJ;System Integrationプロジェクトの実践リスクマネジメント PDF9
10 業務パッケージの解釈 愛知県海部郡におけるNEC社製地方自治体向け提案の『総合行政情報システム』の範囲とサブシステム接合時の齟齬で頓挫した事例 業務パッケージ適応時のリスクアセスメントの姿
業務パッケージ採用プロジェクトにおける成功のポイントは		 ①PMBOK4「プロジェクト統合マネジメント」
②『ソフトウェアパッケージ採用プロジェクト』のリスクアセスメント；IBM Provision No.44
③『業務パッケージ採用プロジェクト』におけるメリット最大化のポイント；プロジェクトマネジメント学会2001		 PDF10
11 納入プログラムに瑕疵があった場合の判断 スーパーマーケットに納入されたEOSシステムに瑕疵があり、請負契約の解除 ベンダーはシステムの構築に当たって、ユーザーから十分なヒアリングをすべき「善管注意義務」及びシステムを本稼動させるまでの「サポート義務」がある、また運用テスト結果に応じて「システムを改善する義務」とされた事案について、その義務違反と認定される範囲と限度は？ ①JISQ9001:2000『品質プロジェクトマネジメント』

民法「635条、541条、415条」		 PDF11
12 受注者のソフト性能保証義務 提携リース会社の見積力不足に加え、ベンダー側も納入ソフトの性能が出なかった時にユーザー側の資料提供不足を主張して泥仕合となった事案 ユーザーは契約締結前に目的が必ずしも煮詰まっていなく、また特殊な資料を提出し具体的な内容の説明もしなかった。またベンダーは専門的・技術的知識の提供をすべきものを怠った。
本件契約の重要な要素に錯誤があったことで契約そのものが無効と認められた。
プロジェクト進行中の双方経過は「信義則」に照らして判断すべきとした。		 ①PMAJ 8-3;お客様からの要求事項・要件定義に係わるリスクの罠
②PMAJ 8-4;お客様からの提案・見積依頼（RFP）に係わるリスクの罠

自社システム力とベンダー企業力（多層構造時の当該Pｊ消化能力）		 PDF12
13 納入プログラムに重大な瑕疵がある場合 JIS製図規格のトレース作業処理用という特殊業務の納入プログラムに重大な瑕疵があり、請負契約の解除及び損害賠償が認められた 裁判官が「どのような状態がプログラムが不完全で、プログラムの重大な瑕疵」と認めるには、どのような事実があったか？
ベンダー側にメーカーの保証契約がある場合に、その内容と保証範囲の解釈についてどんな基準で判断するのか？（建築構造計算ルーティン等の中核部分の扱いは？）		 民法「634条、635条、415条、416条」 PDF13
14 プログラムの欠陥認定に検証実験をして争点の確定をした ダイセーロジスティック㈱は、丸紅㈱に「ソフト開発委託」をし、それをNS&I㈱に「再委託」をした。NS&Iの納入プログラムに瑕疵があるとされ稼働しなかった。その瑕疵部分は開発段階であるダイセー㈱の具体的かつ適切な指摘がなかったので「プログラムの欠陥といえない。納入プログラムに不具合はない」として、裁判所はその認否のため約２年余の実環境検証実験をおこなった。 バグについては、その存在が検収（納品）後に明らかになったとしてむ、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、またはユーザーと協議の上相当と認める代替措置を講じたときは、プログラムの欠陥と評価することはできないものであり、その反面「バグ」といえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、またその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥があると言えるとの見解を示した上、本件バグについては開発会社は、指摘がされた後に遅滞なく補修を終えており「プログラムの欠陥」とはいえないとした。

プログラムのバグがソフトウエアの欠陥であると言えるための要件とは？		 Pj進行中の手戻り作業の履行証跡や品質評価段階でのPDCAサイクル（不良事項の管理：修正プロセス体制）の確立/ISO
　①『ソフトウエアテストと品質保証の実際』岡崎著、日本テクノセンター編
　②東証ｰみずほ証券誤発注事件『拝原意見書』

ＩＳＯ/ＩＥＣ 9126:ソフトウエア品質の評価
『非機能要求の6分類139小項目』非機能要求グレード検討会；2009年9月（予定）

民法「415条、634条二項」		 PDF14
15 システム系全体設計
　　　（企画中）		 東証とみずほ証券で起きた誤入力/誤発注/未取消事件 システム系全体の品質維持（ヒューマンエラーを含むFraudデータ処理の経済性）と環境による非機能要求変化（予知・与見する基礎研究）
業界全体・利用者全体のレベル向上策、アルゴリズム取引等相反する要求とルール規範
M-1 小会社の扱い
（経営者コース）		 ICタグを活用した新物流システムを武器とするシステム開発方法（技術転移の範囲）と、運用にまつわる囲い込みのビジネスモデル戦略の親会社思惑先行で子会社との役員層間で齟齬が生じて「脇が甘かった！」時（信義則違反、協力義務違反）が問われた事例 親会社からシステム部門を子会社化する時の技術資産の扱い方や役員における同乗異夢の実態。そして子会社が独り立ちする時の親会社の「高度な協力義務」とは？
コンピュータシステム構築時における契約記載内容（意思疏通不備による）債務不履行で争った事例からくるコミュニケーションのあり方		 世に始めて送り出す新技術を活用したシステム開発成果物は？
販売にあたり技術屋が強力な武器と感じるが、そんなにマーケットがあるはずない。持株形態や提携会社との資本・役員構成、技術（特許やノーハウの無体財産の扱い）、営業展開等「どろどろした処」を正視しておく役員マインド。		 M1
M-2 態勢整備の義務
（経営者コース）		 三菱商事株主代表訴訟。
取締役や執行役の職務に対する善管注意義務・忠実義務違反は構成するとは通説的見解であり、コンプライアンス態勢構築義務の違反等で、取締役の作為義務の内容を具体的に主張立証は困難である。		 取締役等のコンプライアンス態勢の構築義務違反で、作為義務の内容を具体的主張立証は容易でないと判示。
個人情報等の安全管理措置にたいする従業員・外部委託先の監督等は、「本来構築されるべき体制の具体的な内容」が明示され社内規定の整備をもっても、「会社法」の適用で取締役の作為義務は広範な実務執行責任があるとする通説が主流。		 M-2


当研修内容を見て、
　　１：上記表示概要図PDFの、DL用PWを知りたい方は
　　２：研修企画や内容を詳細をお打合わせご希望の方は

MARI Consulting LLC ©
IT's-Prevention研修クラスターWeb Master；稲垣
このページの先頭へ



　　　ここから「IT's-Preventionの杜」のTopへ
　　　　　　　　　　Copyright　© 1996-2014 by JA2ANX Naoki Inagaki.  this HP all pages is ISSN 2187-5049