Menu

楽しく成功するプロジェクト・マネージメント

基本情報

編者: 東條経営科学研究所

定価:1,430円(本体 1,300円+消費税 10%)

仕様:199ページ/2色

▼購入先の電子書籍販売サイトを選択してください。
(販売サイトにより価格が変動する場合がございます)

amazon.co.jp Booklive!で買う honto 電子書籍

  

PMBOK(SWEBOK)だけでITシステム開発のプロジェクト管理はできるのか!
実践から生まれたプロジェクト管理の指南書

本書は、システム開発におけるプロジェクトマネージメント(PM)の実施について、その体系的なガイドラインとなることを目的としています。
実践レベルの経験を基にして、プロジェクトの実態からシステム開発の基本プロセス、各フェーズにおけるPMの役割と注意点について、具体的な事例も交えつつ解説しています。

※記載されている会社名、製品名などは各社の登録商標または商標です。

  

目次、ダウンロード、正誤情報・追加情報

  • ▼目次

    1. プロジェクトの実態

    1.1 何故プロジェクトの成功率は低いのか
    1.2 PMは経験を大切にすることと常に最新技術を把握する
    1.3 マネージメント力には顧客対応力を含む

    コーヒーブレーク(1)

    2. システム開発は社会造りと言える

    2.1 顧客の立場でシステム設計しなければならない
    2.2 プロジェクト失敗の事例

    コーヒーブレーク(2)

    3. システム開発での基本的なプロセス

    3.1 Water-Fall開発型
    3.2 Spiral開発型
    3.3 XP開発型
    3.4 Concurrent開発型

    コーヒーブレーク(3)

    4. プロジェクト・マネージャの意味と役割

    4.1 プロジェクト・マネージャの意味
    4.2 プロジェクト・マネージャの基本的スタンス
    4.3 プロジェクト・マネージャの機能

    コーヒーブレーク(4)

    5. PMO(プロジェクトマネージメントオフィス)とPM

    5.1 PMO(Project Management Office)の概要
    5.2 PMOによる組織的なプロジェクト・マネージメント支援が急務になった背景
    5.3 PMO機能の展開
    5.3.1 PMOメンバー
    5.3.2 PMOの形態
    5.3.3 PMOの機能
    5.4 PMとしてPMOをどう生かすか
    5.4.1 自社のPMOについて知ろう
    5.4.2 レビューに対して、PMOを味方にしよう
    5.4.3 標準化推進については、PMOに協力しよう
    5.4.4 PMOの支援やアドバイスは貪欲に受けよう

    コーヒーブレーク(5)

    6. 各プロセスでの実行上の注意

    6.1 プロジェクト企画
    6.1.1 この時点での基本的なビジネス・スタンス
    6.1.2 企画を行う手順
    6.1.3 企画書のまとめ方
    6.2 提案
    6.2.1 顧客企業の事情
    6.2.2 提案書作成時での実施事項
    6.3 プロジェクト設計
    6.3.1 プロジェクト設計の基本的作業項目
    6.3.2 プロジェクト設計での基本方針
    6.3.3 プロジェクト計画
    6.3.4 プロジェクト計画具体的実施概要例
    6.3.5 要件定義の出力内容
    6.4 業務運用設計
    6.4.1 要件定義フェーズで業務運用要求を明確に設定する
    6.4.2 プロジェクトに入って、開発に関与する人間は業務運用内容を把握する
    6.4.3 業務運用に関する改善点を明確にすることが重要である
    6.5 業務機能設計
    6.5.1 RFPの記述内容は全体の機能の1/2程度と思うべきである
    6.5.2 顧客はシステム開発のために専門チームを編成するのは少ない
    6.5.3 積極的に想像力を発揮して、顧客に「余計な発言である」と言われる程に提案を行う
    6.6 試験設計
    6.6.1 試験データの設計を行う
    6.6.2 試験SEが注意すべき点
    6.6.3 試験SEの重要な責任とスタンス
    6.6.4 インタフェース試験設計の実施方式
    6.7 保守設計
    6.7.1 業務システムが停止した場合の損害額は膨大である
    6.7.2 業務システムへの誤入力は毎週の様に発生している
    6.7.3 システム機能的なバグに起因するシステム停止の被害額は馬鹿にならない
    6.7.4 保守設計と構造設計を適切に実施することで、システム寿命が決定される
    6.8 インフラ/性能設計
    6.8.1 インフラ耐用年数を設定する
    6.8.2 使用するインフラ・ベースでのアプリケーション性能を測定する
    6.9 データベース設計
    6.9.1 DOAによるDB設計の注意点
    6.9.2 UMLによるオブジェクト指向DB設計
    6.10 構造設計
    6.10.1 業務機能の詳細内容の整理
    6.10.2 業種の同じ内容のモジュールを探すことが必要
    6.10.3 ハードウェアの設計では当然の構造設計がソフトウェアで行われない理由
    6.11 開発
    6.12 試験
    6.12.1 機能試験
    6.12.2 想定ミス運用対応試験
    6.13 ドキュメント作成
    6.14 完成試験
    6.15 サービス・イン基準判定
    6.16 稼働支援

    コーヒーブレーク(6)

    7. データ移行設計とデータ移行

    7.1 移行データの種類
    7.1.1 移行前データにミスが無いかチェックを行う
    7.1.2 移行前と後のデータを比較して意味を確認する
    7.1.3 移行前データとそれを生成した旧システムのバージョンの整合性を確認する

    8. 開発時と稼働後の障害管理

    8.1 開発時の障害管理
    8.2 稼働時の障害管理

    コーヒーブレーク(7)

    9. 顧客からみたシステム開発プロジェクト

    9.1 顧客企業におけるIT投資評価
    9.1.1 IT投資評価に対する歴史的価値観の変遷
    9.1.2 IT不良資産解消への努力
    9.1.3 ITケイパビリティ
    9.1.4 バランスド・スコア・カード(BSC)に関して
    9.1.5 総合的投資評価への道筋
    9.2 顧客企業におけるCIOの関心事
    9.2.1 CIOをとりまく環境
    9.2.2 子会社化した情報処理会社の本社への再集結
    9.2.3 情報システム部門担当者の意識改革
    9.3 ソリューション・ベンダーへの顧客企業の期待感
    9.3.1 顧客企業を理解しよう
    9.3.2 素性の良いシステムとそうでないシステム
    9.3.3 顧客企業は提案を待っている

    コーヒーブレーク(8)

  • 現時点で掲載情報はありません。

  • 現時点で掲載情報はありません。