プロジェクト管理

プロジェクト管理
（情報システム開発におけるプロジェクト管理）
第７回
2009年12月05日（土）
(2009年11月20日版）
• トピックスＣＭＭ
• トピックスガバナンス、ＩＴガバナン
ス、内部統制
• トピックス日本版ＳＯＸ
• トピックスＣＯＢＩＴ
2009年
プロジェクト管理(7) 21pages
1
プロジェクト管理シラバス
講義計画（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
2
プロジェクト管理シラバス
講義計画（2009年度）
• 12/12 [8] 演習
プロジェクト計画、ツールの使用
• 12/12 [9] 事例（１）
• 12/19 [10] 事例（２）
• 12/19 [11] 事例（３）
• 12/19 [12] 事例（４）
• 12/19 [13] まとめ
2009年
プロジェクト管理(7) 21pages
3
ＣＭＭとは
• ＣＭＭ(Capability Maturity Model)とは
– 米国カーネギーメロン大学
– ＳＥＩ(Software Engineering Institute)ソフトウェア工学研究所
http://www.sei.cmu.edu/
– 組織としてのソフトウェア開発プロセスやシステム開発プロセスの
成熟度モデル
– レベル１からレベル５（レベルが高いほど成熟している）
• ＳＷ－ＣＭＭ
–
–
–
–
ＣＭＭで、特にソフトウェア開発についての成熟度を扱う
ＳＰＩ(Software Process Improvement)活動の１つ
ソフトウェア（開発）プロセスの改善活動
国防総省のソフトウェア開発では、受注業者はレベル３以上を要求
• 各レベルでは、以下をさだめている
– ゴール
– キー・プロセス・エリア（ＫＰＡ）
– ベスト・プラクティス（推奨されるキー・プラクティス）
2009年
プロジェクト管理(7) 21pages
4
ＣＭＭのレベル（１／３）
• ＣＭＭレベル１（初期の成熟度）
–
–
–
–
原始的な状態
ソフトウェア開発プロセスは場当たり的
プロジェクト・マネジメントのためのプロセスが定義されていない
プロジェクトの成功は個人まかせ
• ＣＭＭレベル２（反復できる成熟度）
– プロジェクト・マネジメントのための基本的なプロセスは定義され
ている
– プロジェクトごとに
– エンジニアリング（各種の分析や設計手法）のプロセスは未整備
– 過去の同様のプロジェクトについては、経験が活用できるように整
備されている
2009年
プロジェクト管理(7) 21pages
5
ＣＭＭのレベル（２／３）
• ＣＭＭレベル３（プロセスが定義された成熟度）
– プロジェクト・マネジメントおよびエンジニアリグのプロセスが組
織の標準として定義されている
– 文書化、標準化、統合化されている
– 組織として、ソフトウェア開発プロセスが標準として整備されてい
るので、すべてのプロジェクトにおいて、あたりはずれがなく、
いっそう効果的な活動ができる
• ＣＭＭレベル４（管理された成熟度）
– ソフトウェア開発プロセス、成果物品質に関して、過去の多数のプ
ロジェクト活動データが収集されていて、統計的な分析が可能な状
態
– 定量的なマネジメント（見積もりや進捗）が可能な状態
2009年
プロジェクト管理(7) 21pages
6
ＣＭＭのレベル（３／３）
• ＣＭＭレベル５（継続的な最適化が可能な成熟度）
– 進行中のプロジェクトについては、レベル４の定量的データから継
続的なプロセス改善が可能な状態
– 最適化が可能な状態
2009年
プロジェクト管理(7) 21pages
7
ＣＭＭレベルの図
• 成熟度モデル
レベル５（最適化）
レベル４（管理）
レベル３（定義）
レベル２（反復）
レベル１（初期）
2009年
プロジェクト管理(7) 21pages
8
ＣＭＭのＫＰＡ（１／３）
• ＣＭＭレベル１のＫＰＡ(Key Process Area)
– なし
• ＣＭＭレベル２のＫＰＡ(Key Process Area)
–
–
–
–
–
–
2009年
ソフトウェア構成管理
ソフトウェア品質管理
ソフトウェア外注管理
ソフトウェア進捗管理
ソフトウェア・プロジェクト計画
要件管理
プロジェクト管理(7) 21pages
9
ＣＭＭのＫＰＡ（２／３）
• ＣＭＭレベル３のＫＰＡ(Key Process Area)
–
–
–
–
–
–
–
ピアレビュー
グループ間調整
ソフトウェア・プロダクト・エンジニアリング
ソフトウェア統合管理
トレーニングプログラム
組織としてのプロセス定義
組織としてのプロセス遵守
• ＣＭＭレベル４のＫＰＡ(Key Process Area)
– ソフトウェア品質管理
– 定量的プロセス管理
2009年
プロジェクト管理(7) 21pages
10
ＣＭＭのＫＰＡ（３／３）
• ＣＭＭレベル５のＫＰＡ(Key Process Area)
– プロセス変更管理
– 技術変更管理
– 欠陥予防
2009年
プロジェクト管理(7) 21pages
11
ガバナンス
• ガバナンス
– 統制・統治
– おさめる
• コーポレートガバナンス
– 企業統治
– コンプライアンス（法令遵守）
– リスク管理体制、内部統制システム、会社法（2005年7月公布、
2006年5月1日施行）330条、355条
2009年
プロジェクト管理(7) 21pages
12
ＩＴガバナンス
• ＩＴガバナンス
– 通商産業省、日本情報処理開発協会（JIPDEC)
「企業が競争優位性構築を目的に、IT戦略の策定・実行をコント
ロールし、あるべき方向へ導く組織能力」
– 日本監査役協会 ITガバナンス委員会
「主にIT化により新たに生じるリスクの極小化と的確な投資判断に
基づく経営効率の最大化、すなわち、リスク・マネジメントとパ
フォーマンス・マネジメントであり、これらを実施するに当たって
の、健全性確保のためのコンプライアンス・マネジメントの確立で
ある」
– 情報システムコントロール協会 IT Governance Institute
「ITガバナンスは取締役会および経営陣の責任である。それは企業
ガバナンスの不可欠な部分で、リーダーシップおよび組織的な構造、
および組織のITがその組織の戦略および目的を保持し拡張すること
を保証するプロセスから成る」
– http://www.atmarkit.co.jp/aig/04biz/itgovernance.html
2009年
プロジェクト管理(7) 21pages
13
内部統制
•
内部統制（ないぶとうせい、internal control)
– 会社自らが業務の適正を確保するための体制を構築していくシステム（組
織形態や社内規定の整備、業務のマニュアル化や社員教育システムの運用、
また規律を守りつつ目標を達成させるための環境整備、そして株主など外
部への正確かつ有益な財務報告など）
– 企業会計審議会内部統制部会の公開草案では、次のとおりに定義され、
2007年1月31日に了承された。
– 『内部統制とは、基本的に、
•
•
•
•
業務の有効性及び効率性、
財務報告の信頼性、
事業活動に関わる法令等の遵守並びに
資産の保全
– の4つの目的が達成されているとの合理的な保証を得るために、業務に組み
込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環
境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活
動）及びIT（情報技術）への対応の6つの基本的要素から構成される。』
– 日本の多くの企業がこうした仕組みについて未整備であり、さきがけとし
て知られる米国のSOX法を参考に、日本でも法制化され、2008年（平成20
年）4月1日以後に開始する事業年度から適用される
– 金融商品取引法（日本版SOX法）
– http://ja.wikipedia.org/wiki/%E5%86%85%E9%83%A8%E7%B5%B1%E5%88%B6
14
2009年
プロジェクト管理(7) 21pages
ＳＯＸ法（１／２）
• サーベンス・オクスリー法
– 米国企業改革法 / サーベンス・オクスレー法 / 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）下院議員の名にちなんで、「サーベンス・オクスリー
法」と呼ばれる。日本では「企業改革法」と意訳されることも多い。
– http://www.atmarkit.co.jp/aig/04biz/sox.html
2009年
プロジェクト管理(7) 21pages
15
ＳＯＸ法（２／２）
• サーベンス・オクスリー法
– 全11章69の条文から構成され、公開会社会計監視委員会（PCAOB：
Public Company Accounting Oversight Board）の設置、監査人の
独立性、財務ディスクロージャー（開示）の拡張、内部統制の義務
化、経営者による不正行為に対する罰則強化、証券アナリストなど
に対する規制、内部告発者の保護などが規定されている。
– 特に注目されるのは第404条。これはCEO(Chief Executive Officer
最高経営責任者、代表執行役)とCFO(Chief Financial Officer 最
高財務責任者、財務担当役員)に対してSEC（米国証券取引委員）へ
提出する書類に“虚偽や記載漏れがないこと”“内部統制の有効性
評価の開示”などを保証する証明書と署名を添付することを求めて
いる。虚偽があった場合には個人的な責任が問われることになり、
罰則として罰金もしくは5～20年の禁固刑という厳しい刑事罰が設
けられている。
– http://www.atmarkit.co.jp/aig/04biz/sox.html
2009年
プロジェクト管理(7) 21pages
16
日本版ＳＯＸ法
• 日本版SOX法
• にほんばんそっくすほう / 日本版企業改革法 / J-SOX
– 相次ぐ会計不祥事やコンプライアンスの欠如などを防止するため、
米国のサーベンス・オクスリー法（SOX法）に倣って整備された日
本の法規制のこと。上場企業およびその連結子会社に、会計監査制
度の充実と企業の内部統制強化を求めている。
– 「日本版SOX法」という呼び名は俗称で、実際には証券取引法の抜
本改正である「金融商品取引法」の一部規定がこれに該当する。
– 同法では第24条の4の4で「有価証券報告書を提出しなければなら
ない会社のうち、
金融商品取引所に上場している有価証券の発行者である会社その他
の政令で定めるものは、事業年度ごとに、当該会社の属する企業集
団及び当該会社に係る
財務計算に関する書類その他の情報の適正性を確保するために必要
な体制について評価した報告書（内部統制報告書）を有価証券報告
書と併せて内閣総理大臣に提出しなければならないこととする。ま
た、内部統制報告書には、公認会計士又は監査法人の監査証明を受
けなければならないこととする」と定めている。
– http://www.atmarkit.co.jp/aig/04biz/jsox.html
2009年
プロジェクト管理(7) 21pages
17
ＣＯＳＯフレームワーク
• COSOフレームワーク
• コーソー・フレームワーク / COSO Control Framework
– 1992年に米国のトレッドウェイ委員会組織委員会（COSO：the
Committee of Sponsoring Organization of the Treadway
Commission）が公表した内部統制のフレームワーク
事実上の世界標準
– COSOでは、内部統制を次のように定義している。
• 内部統制は、以下の目的を達成するために、合理的な保証を提供する
ことを意図した、取締役会、経営者およびそのほかの職員によって遂
行される1つのプロセスである。
– 業務の有効性・効率性
– 財務諸表の信頼性
– 関連法規の遵守
• そしてCOSOは、内部統制の構成要素として「統制環境」「リスクの評
価」「統制活動」「情報と伝達」「監視活動」を5つを挙げ、これらを
内部統制を評価する際の基準として位置付けている。
– http://www.atmarkit.co.jp/aig/04biz/coso.html
2009年
プロジェクト管理(7) 21pages
18
ＣＯＢＩＴ（１／２）
•
•
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段階で定義する。
– http://www.atmarkit.co.jp/aig/04biz/cobit.html
2009年
プロジェクト管理(7) 21pages
19
ＣＯＢＩＴ（２／２）
– COBITの4つのドメインと34のITプロセス
• ■計画と組織
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）
– http://www.atmarkit.co.jp/aig/04biz/cobit.html
2009年
プロジェクト管理(7) 21pages
20
第７回のまとめ
• 今回の内容をまとめなさい。
• レポート用紙1枚程度。
（手書きよりも、ワープロが望ましい、皆さん
の手元に残るので）
• 期限：次回(12月19日）の最初に回収。
• 第８回は演習（ツールの使用）
• 第９回から第１２回は事例研究（横塚先生）
2009年
プロジェクト管理(7) 21pages
21

Download Report