知識ゼロから学ぶソフトウェアプロジェクト管理 電子書籍(勝呂 暖生)|翔泳社の本
  1. ホーム >
  2. 電子書籍 >
  3. 知識ゼロから学ぶソフトウェアプロジェクト管理

知識ゼロから学ぶソフトウェアプロジェクト管理


形式:
電子書籍
発売日:
ISBN:
9784798131344
価格:
本体2,280円+税

本書籍の他の形式を確認する

  • このエントリーをはてなブックマークに追加

プロジェクトを成功させたいと願うすべてのプログラマに向けて

「なぜほとんどのソフトウェアプロジェクトは失敗するのか」そして「失敗を回避するには何が必要なのか」を、具体的に、ていねいに、かつカジュアルな文体で「最後まで必ず読み切れる」コンパクトな入門書にまとめました。情報工学博士としての膨大な読書量や研究成果とともに、超大手IT 系ベンダーを渡り歩き大小数多くのプロジェクトを経験したのち現在はプロジェクトの評価と改善を本業とする著者の「知識と経験」から導き出された「間違いなく現場で役に立つ」プロジェクト管理の考え方と対処が凝縮された一冊です。

第1章 まえがき ─なぜほとんどのソフトウェア開発は失敗するか─

1.1 本書のゴール
 ─改善─
 1.1.1 改善ができないプロジェクトマネージャー
 1.1.2 改善ができないエンジニア
1.2 本書で伝えたいこと  ─Tips─
1.3 本書の対象となる読者
 ─毎日忙しいあなた─

第2章 典型的な失敗例 ─失敗に学ぶ─

2.1 著しい遅延とコストの上昇問題
 ─ デンバー空港のプロジェクトに代表される古典的なプロジェクトトラブルの例─
 2.1.1 トラブル耐性の弱いプロジェクトとコミュニケーション問題
2.2 非機能要求の不備問題
 ─みずほ銀行のシステムダウンに見られる例─
 2.2.1 非機能要求の取り扱い誤りは致命的
2.3 致命的なバグによる大きな損害の問題
 ─アリアン5ロケットの爆発事故における例─
 2.3.1 ミスを犯す前提で品質を担保できるようなプロジェクト
2.4 まとめ
 2.4.1 モチベーションの欠如を嗅ぎ分ける能力

第3章 人が全て ─個々の開発者の効率の最大化─

3.1 個々のエンジニアの効率化
 ─開発者の生産性を上げる─
 3.1.1 これだけの差がつくソフトウェアエンジニアの生産性
 3.1.2 ミスコミュニケーションの弊害
3.2 プロジェクトは全体の効率をあげる
 ─小さい方がうまくいく─
 3.2.1 訳の判らないマネージャーが増える問題
 3.2.2 コミュニケーションコストが発生し、生産には寄与しない問題
3.3 じゃあどうすればいいですか?
 ─プロジェクトと製品リリースの考え方のスタイル─

第4章 はじめよければ全てよし ─そもそも要求定義って?─

4.1 漠然たるユーザー要求を機能要求に落とし込む
 ─然るべきスタートラインに立つために─
4.2 要求に優先順位をつける
 ─自分たちの身を自分たちで守るためにも─
4.3 テスト可能な要求を書く
 ─要求を分解するノウハウとテストのポイント─
 4.3.1 要求の網羅(要求のテスト)
4.4 非機能要求をちゃんと書く
 ─複雑であいまいで困難な作業─
 4.4.1 外部インターフェイス
 4.4.2 制約
 4.4.3 品質特性
 4.4.4 パトリオットはなぜ誤爆したか
 4.4.5 プロジェクト責任者の役割
4.5 要求の変更の耐性
 ─アジャイル時代の要求管理─
 4.5.1 イテレーティブな要求仕様
 4.5.2 テスト駆動開発
4.6 まとめ

第5章 ちゃんと設計しろって言うけど ─アーキテクチャ─

5.1 アーキテクチャとは
5.2 パターン
 5.2.2 アーキテクチャパターン
5.3 品質特性
 5.3.1 セキュリティ
 5.3.2 信頼性
5.4 ステークホルダ
5.5 アーキテクチャ品質
5.6 まとめ

第6章 オーソドックスか? アジャイルか? ─開発スタイル─

6.1 アジャイル開発
6.2 短期リリース
6.3 シンプルな設計
6.4 テスト!テスト!自動化!自動化!テスト駆動開発
 6.4.1 プロなテスト担当者を入れる
 6.4.2 煩雑なリファクタリング
 6.4.3 ペアプログラミング
 6.4.4 コーディング規約
6.5 40時間労働
6.6 アジャイル開発のデメリット
 6.6.1 大規模開発
 6.6.2 アーキテクチャ V.S. アジャイル
 6.6.3 顧客がそこにいます?
 6.6.4 成熟度の低い組織
6.7 うまい開発例

第7章 PMBOK使えばいいの? ─プロジェクト管理─

7.1 時間管理
 ─日本人の一番苦手なスケジュール管理─
 7.1.1 WBS ─ちゃんとスケジュール引こうぜ!─
 7.1.2 時間管理術
7.2 コスト管理
 ─プロジェクト・コスト・マネージメント─
 7.2.1 見積り手法(フォーマルモデル)
 7.2.2 見積り手法(エキスパートモデル)
 7.2.3 バグが与える見積りへの影響
 7.2.4 まとめ
7.3 品質管理
 ─プロジェクト・クォリティ・マネージメント─
 7.3.1 悪い品質のモジュールを徹底的に叩く
 7.3.2 品質メトリクス
7.4 リスク管理
 ─プロジェクト・リスク・マネージメント─
7.5 まとめ

第8章 それでもプロジェクトマネージメントがうまくいかない理由

8.1 オフショアリングによるコスト削減
 ─多拠点での開発─
 8.1.1 やはりオフショアは生産性に寄与しない?
8.2 人員コントロール
 ─人を選ぶのに方法論は存在しない─
8.3 プレッシャーの塩梅
 ─銀の弾丸はいまでも「ない」─
8.4 水曜で終わらせて、木曜からスタートしましょう
 ─金曜にプログラムはしない!─
 8.4.1 金曜にコーディングはしない!
8.5 エンドゲーム
 ─終わりよければ全て良し─
 8.5.1 Do Not Change Code(コード変更するべからず)
 8.5.2 失敗したら検死をしましょう(ポストモーテム:postmortem)
8.6 問題解決のためのフレームワーク
 ─MECE(ミーシー)に処理しよう─
Postscript(最後の一言)
結び

本書は付属データの提供はございません。

書籍への問い合わせ

正誤表、追加情報をご確認の上、こちらよりお問い合わせください

書影の利用許諾について

本書籍に関する利用許諾申請はこちらになります

追加情報はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2012年06月20日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 067
4.4.4 の1行目
イランのスカッドミサイル
イラクのスカッドミサイル
2012.06.20