プロジェクト管理 （情報システム開発におけるプロジェクト管理）

Presentation on theme: "プロジェクト管理 （情報システム開発におけるプロジェクト管理）"— Presentation transcript:

1 プロジェクト管理 （情報システム開発におけるプロジェクト管理）
プロジェクト管理（第７回） 2009年度 プロジェクト管理 （情報システム開発におけるプロジェクト管理） 第７回 2009年12月05日（土） (2009年11月20日版） トピックス ＣＭＭ トピックス ガバナンス、ＩＴガバナンス、内部統制 トピックス 日本版ＳＯＸ トピックス ＣＯＢＩＴ 2009年 プロジェクト管理(7) 　21pages

2 プロジェクト管理シラバス 講義計画（2009年度） 11/28 [1] 情報システム開発とプロジェクト プロジェクトとは
11/28 [2] PMBOKの内容－1 スコープ、コミュニケーション 11/28 [3] PMBOKの内容－2 タイム、コスト 12/05 [4] PMBOKの内容－3 品質、人的資源 12/05 [5] PMBOKの内容－4 リスク、調達 12/05 [6] PMBOKの内容－5 統合 12/12 [7] ＣＭＭ 2009年 プロジェクト管理(7) 　21pages

3 プロジェクト管理シラバス 講義計画（2009年度） 12/12 [8] 演習 プロジェクト計画、ツールの使用 12/12 [9] 事例（１）
12/19 [10] 事例（２） 12/19 [11] 事例（３） 12/19 [12] 事例（４） 12/19 [13] まとめ 2009年 プロジェクト管理(7) 　21pages

4 ＣＭＭとは ＣＭＭ(Capability Maturity Model)とは ＳＷ－ＣＭＭ 各レベルでは、以下をさだめている
米国カーネギーメロン大学 ＳＥＩ(Software Engineering Institute)ソフトウェア工学研究所 組織としてのソフトウェア開発プロセスやシステム開発プロセスの成熟度モデル レベル１からレベル５（レベルが高いほど成熟している） ＳＷ－ＣＭＭ ＣＭＭで、特にソフトウェア開発についての成熟度を扱う ＳＰＩ(Software Process Improvement)活動の１つ ソフトウェア（開発）プロセスの改善活動 国防総省のソフトウェア開発では、受注業者はレベル３以上を要求 各レベルでは、以下をさだめている ゴール キー・プロセス・エリア（ＫＰＡ） ベスト・プラクティス（推奨されるキー・プラクティス） 2009年 プロジェクト管理(7) 　21pages

5 ＣＭＭのレベル（１／３） ＣＭＭレベル１（初期の成熟度） ＣＭＭレベル２（反復できる成熟度） 原始的な状態
ソフトウェア開発プロセスは場当たり的 プロジェクト・マネジメントのためのプロセスが定義されていない プロジェクトの成功は個人まかせ ＣＭＭレベル２（反復できる成熟度） プロジェクト・マネジメントのための基本的なプロセスは定義されている プロジェクトごとに エンジニアリング（各種の分析や設計手法）のプロセスは未整備 過去の同様のプロジェクトについては、経験が活用できるように整備されている 2009年 プロジェクト管理(7) 　21pages

6 ＣＭＭのレベル（２／３） ＣＭＭレベル３（プロセスが定義された成熟度） ＣＭＭレベル４（管理された成熟度）
プロジェクト・マネジメントおよびエンジニアリグのプロセスが組織の標準として定義されている 文書化、標準化、統合化されている 組織として、ソフトウェア開発プロセスが標準として整備されているので、すべてのプロジェクトにおいて、あたりはずれがなく、いっそう効果的な活動ができる ＣＭＭレベル４（管理された成熟度） ソフトウェア開発プロセス、成果物品質に関して、過去の多数のプロジェクト活動データが収集されていて、統計的な分析が可能な状態 定量的なマネジメント（見積もりや進捗）が可能な状態 2009年 プロジェクト管理(7) 　21pages

7 ＣＭＭのレベル（３／３） ＣＭＭレベル５（継続的な最適化が可能な成熟度）
進行中のプロジェクトについては、レベル４の定量的データから継続的なプロセス改善が可能な状態 最適化が可能な状態 2009年 プロジェクト管理(7) 　21pages

8 ＣＭＭ レベルの図 成熟度モデル レベル５（最適化） レベル４（管理） レベル３（定義） レベル２（反復） レベル１（初期） 2009年
プロジェクト管理(7) 　21pages

9 ＣＭＭのＫＰＡ（１／３） ＣＭＭレベル１のＫＰＡ(Key Process Area)
なし ＣＭＭレベル２のＫＰＡ(Key Process Area) ソフトウェア構成管理 ソフトウェア品質管理 ソフトウェア外注管理 ソフトウェア進捗管理 ソフトウェア・プロジェクト計画 要件管理 2009年 プロジェクト管理(7) 　21pages

10 ＣＭＭのＫＰＡ（２／３） ＣＭＭレベル３のＫＰＡ(Key Process Area)
ピアレビュー グループ間調整 ソフトウェア・プロダクト・エンジニアリング ソフトウェア統合管理 トレーニングプログラム 組織としてのプロセス定義 組織としてのプロセス遵守 ＣＭＭレベル４のＫＰＡ(Key Process Area) ソフトウェア品質管理 定量的プロセス管理 2009年 プロジェクト管理(7) 　21pages

11 ＣＭＭのＫＰＡ（３／３） ＣＭＭレベル５のＫＰＡ(Key Process Area) プロセス変更管理 技術変更管理 欠陥予防 2009年
プロジェクト管理(7) 　21pages

12 ガバナンス ガバナンス コーポレートガバナンス 統制・統治 おさめる 企業統治 コンプライアンス（法令遵守）
リスク管理体制、内部統制システム、会社法（2005年7月公布、2006年5月1日施行）330条、355条 2009年 プロジェクト管理(7) 　21pages

13 ＩＴガバナンス ＩＴガバナンス 通商産業省、日本情報処理開発協会（JIPDEC) 「企業が競争優位性構築を目的に、IT戦略の策定・実行をコントロールし、あるべき方向へ導く組織能力」 日本監査役協会 ITガバナンス委員会 「主にIT化により新たに生じるリスクの極小化と的確な投資判断に基づく経営効率の最大化、すなわち、リスク・マネジメントとパフォーマンス・マネジメントであり、これらを実施するに当たっての、健全性確保のためのコンプライアンス・マネジメントの確立である」 情報システムコントロール協会 IT Governance Institute 「ITガバナンスは取締役会および経営陣の責任である。それは企業ガバナンスの不可欠な部分で、リーダーシップおよび組織的な構造、および組織のITがその組織の戦略および目的を保持し拡張することを保証するプロセスから成る」 2009年 プロジェクト管理(7) 　21pages

14 内部統制 内部統制（ないぶとうせい、internal control)
会社自らが業務の適正を確保するための体制を構築していくシステム（組織形態や社内規定の整備、業務のマニュアル化や社員教育システムの運用、また規律を守りつつ目標を達成させるための環境整備、そして株主など外部への正確かつ有益な財務報告など） 企業会計審議会内部統制部会の公開草案では、次のとおりに定義され、2007年1月31日に了承された。 『内部統制とは、基本的に、 業務の有効性及び効率性、 財務報告の信頼性、 事業活動に関わる法令等の遵守並びに 資産の保全 の4つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びIT（情報技術）への対応の6つの基本的要素から構成される。』 日本の多くの企業がこうした仕組みについて未整備であり、さきがけとして知られる米国のSOX法を参考に、日本でも法制化され、2008年（平成20年）4月1日以後に開始する事業年度から適用される 金融商品取引法（日本版SOX法） 2009年 プロジェクト管理(7) 　21pages

15 ＳＯＸ法（１／２） サーベンス・オクスリー法 米国企業改革法 / サーベンス・オクスレー法 / SOX法 Sarbanes‐Oxley act 目的：企業会計や財務報告の透明性・正確性を高めること 米国連邦法：コーポレートガバナンスの在り方と監査制度を抜本的に改革すること、投資家に対する企業経営者の責任と義務・罰則を定める エンロン事件やワールドコム事件など1990年代末から2000年代初頭にかけて頻発した不正会計問題に対処するため制定されたもので、2002年7月に大統領署名により法律として承認された。1933年の連邦証券法、1934年の証券取引所法制定以来、最も大きな変更といわれる。 正式には「Public Company Accounting Reform and Investor Protection Act of 2002：上場企業会計改革および投資家保護法」といい、法案を連名で提出したポール・サーベンス（Paul Sarbanes）上院議員、マイケル・G・オクスリー（Michael G.Oxley）下院議員の名にちなんで、「サーベンス・オクスリー法」と呼ばれる。日本では「企業改革法」と意訳されることも多い。 2009年 プロジェクト管理(7) 　21pages

16 ＳＯＸ法（２／２） サーベンス・オクスリー法 全11章69の条文から構成され、公開会社会計監視委員会（PCAOB：Public Company Accounting Oversight Board）の設置、監査人の独立性、財務ディスクロージャー（開示）の拡張、内部統制の義務化、経営者による不正行為に対する罰則強化、証券アナリストなどに対する規制、内部告発者の保護などが規定されている。 特に注目されるのは第404条。これはCEO(Chief Executive Officer 最高経営責任者、代表執行役)とCFO(Chief Financial Officer 最高財務責任者、財務担当役員)に対してSEC（米国証券取引委員）へ提出する書類に“虚偽や記載漏れがないこと”“内部統制の有効性評価の開示”などを保証する証明書と署名を添付することを求めている。虚偽があった場合には個人的な責任が問われることになり、罰則として罰金もしくは5～20年の禁固刑という厳しい刑事罰が設けられている。 2009年 プロジェクト管理(7) 　21pages

17 日本版ＳＯＸ法 日本版SOX法 にほんばんそっくすほう / 日本版企業改革法 / J-SOX
同法では第24条の4の4で「有価証券報告書を提出しなければならない会社のうち、 金融商品取引所に上場している有価証券の発行者である会社その他の政令で定めるものは、事業年度ごとに、当該会社の属する企業集団及び当該会社に係る 財務計算に関する書類その他の情報の適正性を確保するために必要な体制について評価した報告書（内部統制報告書）を有価証券報告書と併せて内閣総理大臣に提出しなければならないこととする。また、内部統制報告書には、公認会計士又は監査法人の監査証明を受けなければならないこととする」と定めている。 2009年 プロジェクト管理(7) 　21pages

18 ＣＯＳＯフレームワーク COSOフレームワーク コーソー・フレームワーク / COSO Control Framework
1992年に米国のトレッドウェイ委員会組織委員会（COSO：the Committee of Sponsoring Organization of the Treadway Commission）が公表した内部統制のフレームワーク 事実上の世界標準 COSOでは、内部統制を次のように定義している。 内部統制は、以下の目的を達成するために、合理的な保証を提供することを意図した、取締役会、経営者およびそのほかの職員によって遂行される1つのプロセスである。 業務の有効性・効率性 財務諸表の信頼性 関連法規の遵守 そしてCOSOは、内部統制の構成要素として「統制環境」「リスクの評価」「統制活動」「情報と伝達」「監視活動」を5つを挙げ、これらを内部統制を評価する際の基準として位置付けている。 2009年 プロジェクト管理(7) 　21pages

19 ＣＯＢＩＴ（１／２） COBIT （Control Objectives for Information and related Technology） コビット / CobiT 企業・自治体といった組織のITガバナンスの指針として、米国の情報システムコントロール協会（ISACA）などが提唱するITガバナンスの実践規範のこと。フレームワークやガイドライン、成熟度モデル、ツールセットなどの一連の資料からなる。IT投資の評価、ITのリスクとコントロールの判断、システム監査の基準などに使われる。 IT組織の成熟度を測るモデルとしてはほかにCMM／CMMIなどが有名だが、COBITでは「リスク」という概念が強く打ち出されている。ここでいう「リスク」とはシステムトラブルなどの技術リスクのほか、情報漏えいに関することなどマネジメント体制も含まれる。そこでCOBITでは開発側・利用側双方をマネジメントすることで、セキュアな環境の下、ITを積極活用できる体制作りの指標を提示している。また、ベンダからの「IT調達」を前提にしている点も特徴の1つである。 COBITは、IT活動を4つの領域（ドメイン）と34のITプロセスに定義し、それぞれのプロセスについて、CSF(Critical Success Factor)／KGI(Key Goal Indicator)／KPI(Key Performance Indicator)を定義する。 その成熟度レベルを6段階で定義する。 2009年 プロジェクト管理(7) 　21pages

20 ＣＯＢＩＴ（２／２） COBITの4つのドメインと34のITプロセス COBITの成熟度モデル
■計画と組織 1.戦略的IT計画の定義 2.情報アーキテクチャの定義 3.技術指針の決定 4.IT組織の関係の定義 5.IT投資の管理 6.運用目標と指針の伝達 7.IT人的資源の管理 8.品質管理 9.リスクの査定と管理 10.プロジェクト管理 ■取得とインプリメント 1.自動化されたソリューションの検証 2.アプリケーションソフトの調達・保守 3.技術基盤の調達・保守 4.プロセスの開発・保守 5.IT資源の調達 6.変更管理 7.ソリューションと変更の導入・認定 ■供給とサポート 1.サービスレベルの定義と管理 2.サードパーティサービス管理 3.性能やキャパシティの管理 4.継続的サービスの保証 5.システムセキュリティの保証 6.識別とコスト配賦 7.ユーザーの教育・訓練 8.サービスデスクとインシデント管理 9.構成管理 10.問題管理 11.データ管理 12.物理環境管理 13.運用管理 ■モニタと評価 1.ITパフォーマンスのモニタと評価 2.内部統制のモニタと評価 3.コンプライアンス遵守の保証 4.ITガバナンスの提供 COBITの成熟度モデル レベル5：最適化されている（Optimized）レベル4：管理されている（Managed）レベル3：定義されている（Defined）レベル2：反復可能（Repeatable）レベル1：初歩的（Initial）レベル0：存在しない（Non-Existent） 2009年 プロジェクト管理(7) 　21pages

21 第７回のまとめ 今回の内容をまとめなさい。 レポート用紙1枚程度。 （手書きよりも、ワープロが望ましい、皆さんの手元に残るので）
期限：次回(12月19日）の最初に回収。 第８回は演習（ツールの使用） 第９回から第１２回は事例研究（横塚先生） 2009年 プロジェクト管理(7) 　21pages