和書>ビジネス・教育>コンピュータ関連>コンピュータ読み物
著者プロフィール
東條経営科学研究所(とうじょうけいえいかがくけんきゅうじょ)
株式会社東條経営科学研究所
設立:平成10年12月 代表取締役社長:東條保子
「発展会」という名称で、社会の発展、並びに個人の発展を合言葉に大手コンピュータ・メーカの技術系管理職経験者、PMI認定PMP、各種情処理技術資格保持者、中小企業診断士、社会保険労務士など、高い技術力の保持者を集結し、コンサルティング、プロジェクト支援、人材育成を精力的に行っている。
株式会社東條経営科学研究所
設立:平成10年12月 代表取締役社長:東條保子
「発展会」という名称で、社会の発展、並びに個人の発展を合言葉に大手コンピュータ・メーカの技術系管理職経験者、PMI認定PMP、各種情処理技術資格保持者、中小企業診断士、社会保険労務士など、高い技術力の保持者を集結し、コンサルティング、プロジェクト支援、人材育成を精力的に行っている。
解説
本書は、システム開発におけるプロジェクトマネージメント(PM)の実施について、その体系的なガイドラインとなることを目的としています。
実践レベルの経験を基にして、プロジェクトの実態からシステム開発の基本プロセス、各フェーズにおけるPMの役割と注意点について、具体的な事例も交えつつ解説しています。
実践レベルの経験を基にして、プロジェクトの実態からシステム開発の基本プロセス、各フェーズにおけるPMの役割と注意点について、具体的な事例も交えつつ解説しています。
目次
1. プロジェクトの実態
1.1 何故プロジェクトの成功率は低いのか
1.2 PMは経験を大切にすることと常に最新技術を把握する
1.3 マネージメント力には顧客対応力を含む
2. システム開発は社会造りと言える
2.1 顧客の立場でシステム設計しなければならない
2.2 プロジェクト失敗の事例
3. システム開発での基本的なプロセス
3.1 Water−Fall開発型
3.2 Spiral開発型
3.3 XP開発型
3.4 Concurrent開発型
4. プロジェクト・マネージャの意味と役割
4.1 プロジェクト・マネージャの意味
4.2 プロジェクト・マネージャの基本的スタンス
4.3 プロジェクト・マネージャの機能
5. PMO(プロジェクトマネージメントオフィス)とPM
5.1 PMO(Project Management Office)の概要
5.2 PMOによる組織的なプロジェクト・マネージメント支援が急務になった背景
5.3 PMO機能の展開
5.4 PMとしてPMOをどう生かすか
6. 各プロセスでの実行上の注意
6.1 プロジェクト企画
6.2 提案
6.3 プロジェクト設計
6.4 業務運用設計
6.5 業務機能設計
6.6 試験設計
6.7 保守設計
6.8 インフラ/性能設計
6.9 データベース設計
6.10 構造設計
6.11 開発
6.12 試験
6.13 ドキュメント作成
6.14 完成試験
6.15 サービス・イン基準判定
6.16 稼働支援
7. データ移行設計とデータ移行
7.1 移行データの種類
8. 開発時と稼働後の障害管理
8.1 開発時の障害管理
8.2 稼働時の障害管理
9. 顧客からみたシステム開発プロジェクト
9.1 顧客企業におけるIT投資評価
9.2 顧客企業におけるCIOの関心事
9.3 ソリューション・ベンダーへの顧客企業の期待感
1.1 何故プロジェクトの成功率は低いのか
1.2 PMは経験を大切にすることと常に最新技術を把握する
1.3 マネージメント力には顧客対応力を含む
2. システム開発は社会造りと言える
2.1 顧客の立場でシステム設計しなければならない
2.2 プロジェクト失敗の事例
3. システム開発での基本的なプロセス
3.1 Water−Fall開発型
3.2 Spiral開発型
3.3 XP開発型
3.4 Concurrent開発型
4. プロジェクト・マネージャの意味と役割
4.1 プロジェクト・マネージャの意味
4.2 プロジェクト・マネージャの基本的スタンス
4.3 プロジェクト・マネージャの機能
5. PMO(プロジェクトマネージメントオフィス)とPM
5.1 PMO(Project Management Office)の概要
5.2 PMOによる組織的なプロジェクト・マネージメント支援が急務になった背景
5.3 PMO機能の展開
5.4 PMとしてPMOをどう生かすか
6. 各プロセスでの実行上の注意
6.1 プロジェクト企画
6.2 提案
6.3 プロジェクト設計
6.4 業務運用設計
6.5 業務機能設計
6.6 試験設計
6.7 保守設計
6.8 インフラ/性能設計
6.9 データベース設計
6.10 構造設計
6.11 開発
6.12 試験
6.13 ドキュメント作成
6.14 完成試験
6.15 サービス・イン基準判定
6.16 稼働支援
7. データ移行設計とデータ移行
7.1 移行データの種類
8. 開発時と稼働後の障害管理
8.1 開発時の障害管理
8.2 稼働時の障害管理
9. 顧客からみたシステム開発プロジェクト
9.1 顧客企業におけるIT投資評価
9.2 顧客企業におけるCIOの関心事
9.3 ソリューション・ベンダーへの顧客企業の期待感
抄録
プロジェクトには各種のモノがあり、経験の深い成功確率の高いプロジェクト・マネージャ(以下ではPMと称する)でも、100%の成功を約束できないのが現実である。しかし、経験を積んで、事態に合わせて先行的に目的を意識(適合していることが必須であるが)した高い計画性を発揮すれば、100%の成功は可能である。
但し、PMが陥る問題に関する認識を十分に行い、顧客の協力とプロジェクト・メンバー全員の協力を得ることが必須である。 このためには、PMが楽しさを意識したマネージメントを実施することが非常に大切である。この場合にはPMは人生では得難い醍醐味を味わうことが可能となる。
プロジェクト・マネージメントの実行は、経営活動と酷似しており、「定まった王道は存在しないが、努力すれば成功する資質を身につけられる」と言って良い。楽しく成功するにはPMの役割が非常に重要であり、プロジェクトはPMのマネージメント次第で厳しい環境でも楽しくもなり、面白くないモノにもなる。
プロジェクトの目的と内容、等にいかに適合した計画策定と現時的な内容を実行するかがプロジェクト成功確率を高める基本法則である。この現実的キーポイントに関して、経験則からガイドラインを示すことが本書の目的である。
PMBOK等には各種PMに関する基準があるが、厳しい現場でPMを経験した者にはピンと来ない面が多々ある。
PM経験者同士が、ユビキタス社会に向けて益々重要となるIT(Information Technology)システムの開発に関して、定期的に研究ミーティングを行って経験則に基づいたマネージメント論をまとめた結果を記述するが、先ずは現実のプロジェクトの実態に関しての概要を記述する。
アメリカのリポートではプロジェクト成功率は約25%であると報告されている。日本でのプロジェクトの該当するリポートについては、残念ながら、その存在を知らない。この数値よりも成功率が高いとは想像するが、それ程の大きな差異があるとは考えられない。
開発事業を行っている際には、総合的(多数のプロジェクトを束ねた総額に関しては)にリスク費用を8%〜9%保有することを心掛けていた。但し、単一プロジェクトの赤字額では22%〜50%に分散した形態でリスクが存在するのが実態である。
この様な体系的なデータの存在が見られないことは、貴重なプロジェクト経験を体系的に記述したドキュメントが作成されていないと判断する。断片的な部分に関して王道的なガイドラインを記述した文章&書籍は存在するが、体系的なドキュメントは実際の経験を取り入れてはいるが、新規の標準的な内容を断片的に記述した様な内容が多い。
*この続きは製品版でお楽しみください。
但し、PMが陥る問題に関する認識を十分に行い、顧客の協力とプロジェクト・メンバー全員の協力を得ることが必須である。 このためには、PMが楽しさを意識したマネージメントを実施することが非常に大切である。この場合にはPMは人生では得難い醍醐味を味わうことが可能となる。
プロジェクト・マネージメントの実行は、経営活動と酷似しており、「定まった王道は存在しないが、努力すれば成功する資質を身につけられる」と言って良い。楽しく成功するにはPMの役割が非常に重要であり、プロジェクトはPMのマネージメント次第で厳しい環境でも楽しくもなり、面白くないモノにもなる。
プロジェクトの目的と内容、等にいかに適合した計画策定と現時的な内容を実行するかがプロジェクト成功確率を高める基本法則である。この現実的キーポイントに関して、経験則からガイドラインを示すことが本書の目的である。
PMBOK等には各種PMに関する基準があるが、厳しい現場でPMを経験した者にはピンと来ない面が多々ある。
PM経験者同士が、ユビキタス社会に向けて益々重要となるIT(Information Technology)システムの開発に関して、定期的に研究ミーティングを行って経験則に基づいたマネージメント論をまとめた結果を記述するが、先ずは現実のプロジェクトの実態に関しての概要を記述する。
アメリカのリポートではプロジェクト成功率は約25%であると報告されている。日本でのプロジェクトの該当するリポートについては、残念ながら、その存在を知らない。この数値よりも成功率が高いとは想像するが、それ程の大きな差異があるとは考えられない。
開発事業を行っている際には、総合的(多数のプロジェクトを束ねた総額に関しては)にリスク費用を8%〜9%保有することを心掛けていた。但し、単一プロジェクトの赤字額では22%〜50%に分散した形態でリスクが存在するのが実態である。
この様な体系的なデータの存在が見られないことは、貴重なプロジェクト経験を体系的に記述したドキュメントが作成されていないと判断する。断片的な部分に関して王道的なガイドラインを記述した文章&書籍は存在するが、体系的なドキュメントは実際の経験を取り入れてはいるが、新規の標準的な内容を断片的に記述した様な内容が多い。
*この続きは製品版でお楽しみください。
本の情報
この本を読んだ人は、こんな本も読んでいます
形式
【bookend形式】
この書籍は、商品の初回閲覧時に必要ソフト「bookend」(無料)を手動インストールする必要があります。
詳細はbookend形式のご利用方法をご覧下さい。
bookend形式の書籍をご覧いただくためにはAdobe Reader最新版(無料)が必要になります。Adobe Reader最新版はここから無料でダウンロードできます。


























