「派生開発」を成功させるプロセス改善の技術と極意

[表紙]「派生開発」を成功させるプロセス改善の技術と極意

A5判/416ページ

定価(本体2,580円+税)

ISBN 978-4-7741-3249-5

電子版

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

トラブルが頻発する「派生開発」を改善するにはどうしたらよいか。著者が現場で培ってきた方法論をまとめあげました。「派生開発」専用のこのプロセスにより,確実にプロジェクトを成功させます。現場で抱える問題の解決に必ず役立つ,「定番」となる一冊です。

こんな方におすすめ

  • 派生開発をスムーズに進めたいプロジェクトマネージャやエンジニアに
  • 派生開発でデスマーチに陥った経験のあるエンジニアに
  • システムの変更を発注する側の人にも

この書籍に関連する記事があります!

失敗のない「派生開発」を目指す
意外に知られていないことかもしれませんが,実はソフトウェアの開発現場では「新規開発」の機会なんて滅多にないといいます。開発のほとんどは「派生開発」だといわれています。

目次

第1章 派生開発の現状

  • 1.1 派生開発でのトラブル
    • 1.1.1 動いていたシステムが止まる
    • 1.1.2 わずかな変更でも納期をはずす
    • 1.1.3 結合して動かしてみると動かない
    • 1.1.4 変更モレが頻繁に発生している
    • 1.1.5 デバッグの仕方がおかしい
    • 1.1.6 納期が先に決まっていることがおかしい?
  • 1.2 派生開発はなぜ失敗を繰り返すのか?
    • 1.2.1 変更要求をつかんでいない
    • 1.2.2 全体を理解しようとして失敗している
    • 1.2.3 派生開発の特徴を理解していない
    • 1.2.4 市場トラブルを通常のデバッグプロセスで対応している
    • 1.2.5 一人プロジェクトの問題
    • 1.2.6 疑似一人プロジェクトも起きている
    • 1.2.7 「間に合わないモンスター」の襲来
    • 1.2.8 データをとっていない
    • 1.2.9 他人のソースを簡単に理解できるか
    • 1.2.10 崩れた設計思想
    • 1.2.11 忘れられた保守性などの品質要求
    • 1.2.12 恐怖の「ドラえもんのポケット」
    • 1.2.13 スペックアウトの技術を持たない
    • 1.2.14 ソースコードの変更が早すぎる
    • 1.2.15 潜在バグの意味
    • 1.2.16 どこを変更したのか誰も知らない
    • 1.2.17 インクリメンタルモデルでも失敗する
    • 1.2.18 複雑なコンフリクトに対応できていない
    • 1.2.19 既存の分析・設計技法はすべて新規開発向け
    • 1.2.20 「新規開発崩し」で混乱している
    • 1.2.21 構成管理を崩壊させる
    • 1.2.22 CMMでの取り組みの誤り
    • 1.2.23 思考を止めた組織

第2章 派生開発プロセス「XDDP」の提案

  • 2.1 XDDPの誕生
    • 2.1.1 厳密な変更制御
    • 2.1.2 変更した行数からわかること
    • 2.1.3 データをとることで見えてくること
    • 2.1.4 派生開発での特徴を知る
    • 2.1.5 「部分理解」を克服する
    • 2.1.6 派生開発に特化したプロセスを提案
  • 2.2 ライフサイクルモデルとしてのXDDP
    • 2.2.1 ウォーターフォールモデルからインクリメンタルモデルへ
    • 2.2.2 派生開発専用のライフサイクルモデル
  • 2.3 「変更要求仕様書」の導入
    • 2.3.1 変更内容や変更箇所を特定するための文書
    • 2.3.2 変更箇所に関する情報を提供
    • 2.3.3 ソースコードを“変更仕様”として扱う理由
  • 2.4 2つのPFD
    • 2.4.1 変更要求と機能追加要求で求められること
    • 2.4.2 変更要求用のPFD
    • 2.4.3 機能追加用のPFD
    • 2.4.4 “差分”に徹する
  • 2.5 XDDPの成果物
    • 2.5.1 変更要求仕様書
    • 2.5.2 追加機能要求仕様書
    • 2.5.3 トレーサビリティ・マトリクス
    • 2.5.4 インパクト・マトリクスとの違い
    • 2.5.5 変更設計書
    • 2.5.6 その他の成果物
  • 2.6 変更用PFDの各プロセスの説明
    • 2.6.1 変更要求項目を仕様書に記述する
    • 2.6.2 ソース等を調査しながら変更仕様を抽出する
    • 2.6.3 追加機能の変更要求仕様書を作成する
    • 2.6.4 変更要求TMを作成する
    • 2.6.5 変更設計書を作成する
    • 2.6.6 ソースコードを変更する
  • 2.7 追加用PFDの各プロセスの説明
    • 2.7.1 追加機能用の要求仕様書を作成する
    • 2.7.2 追加機能を設計する
    • 2.7.3 追加機能の関数設計書を作成する
    • 2.7.4 追加機能のソースコードを書く
  • 2.8 XDDPとソフトウェアエンジニアリング
    • 2.8.1 XDDPは100%近い成功率を誇る
    • 2.8.2 変更用PFDは基本的にはウォーターフォールの変形
    • 2.8.3 追加用PFDのプロセスは選択可能

第3章 XDDPによる変更のプロセス

  • 3.1 変更要求をまとめる
    • 3.1.1 変更依頼の内容を変更要求と変更仕様に振り分ける
    • 3.1.2 カテゴリに分類する
    • 3.1.3 「before」「after」で“変更要求”を表現する
    • 3.1.4 変更要求も「範囲」を持つ
    • 3.1.5 変更する“理由”が必要なわけ
    • 3.1.6 変更要求を分割・階層化する
    • 3.1.7 変更要求における分割基準
    • 3.1.8 下位層の変更要求にも「理由」が必要
    • 3.1.9 必要なら変更要求をグループ分けする
    • 3.1.10 変更依頼が「仕様」でされることへの対応
    • 3.1.11 変更仕様にふさわしい変更要求を立てる
    • 3.1.12 積み残しのバグを変更要求として対応
    • 3.1.13 変更でいくか追加でいくか
  • 3.2 ソースコードから変更仕様を探す
    • 3.2.1 文書やソースファイルの情報を整理する
    • 3.2.2 変更要求単位で該当箇所を探す
    • 3.2.3 ソースコードを探して変更仕様を拾う
    • 3.2.4 スペックアウトで変更仕様を拾う
    • 3.2.5 スペックアウト作業の注意
    • 3.2.6 システムのアーキテクチャを確認する
    • 3.2.7 仕様も「before」と「after」を表現する
  • 3.3 関連文書から変更仕様を探す
    • 3.3.1 ベースとなる機能仕様書などから変更仕様を拾う
    • 3.3.2 関連箇所を漏らさない工夫
    • 3.3.3 TMにマークしてから,あとでソースコード上で確認する
    • 3.3.4 変更要求仕様書でテストケースを更新する
    • 3.3.5 変更内容に応じた耐性を確認するテストが可能
  • 3.4 追加の機能仕様から変更仕様を探す
    • 3.4.1 機能追加を“変更”としても扱う
    • 3.4.2 機能追加の実現方法を明らかにする
    • 3.4.3 変更要求仕様と追加要求仕様書との連携
  • 3.5 変更仕様の抽出時に注意が必要なこと
    • 3.5.1 変更要求の下に変更仕様を記述する
    • 3.5.2 仕様変更としての追加と削除
    • 3.5.3 意外と書けない「before」「after」
    • 3.5.4 変更要求の表現が適切でないと変更仕様が拾えない
    • 3.5.5 完成後の機能仕様を作ってみることも
    • 3.5.6 補助資料の効能
    • 3.5.7 グループ化で変更のテーマを整える
    • 3.5.8 先にグループを設定する効果
    • 3.5.9 変更内容を文章で書くことが難しい?
    • 3.5.10 変更要求仕様にソースを書かない理由
  • 3.6 変更要求TMを作成する
    • 3.6.1 列方向に持ってくるもの
    • 3.6.2 クラス名では小さすぎる
    • 3.6.3 TMの「列」情報を固定する効果
    • 3.6.4 XDDPの“要”としての役割
    • 3.6.5 変更要求TMにマークする
    • 3.6.6 新規開発時に作るトレーサビリティ・マトリクスとの関係
    • 3.6.7 トレーサビリティ・マトリクスにこだわる理由
    • 3.6.8 理解の食い違いに気づく
    • 3.6.9 「TM」部分は省かれる傾向がある
  • 3.7 変更方法を変更設計書にまとめる
    • 3.7.1 変更設計書に記入すること
    • 3.7.2 変更方法を文章で書く
    • 3.7.3 異なる変更仕様で同じ関数に変更が重なるケース
    • 3.7.4 変更で新たな関数が作られるケース
    • 3.7.5 変更設計書はいつ書くのか?
    • 3.7.6 間違った変更を防止する最後の砦
    • 3.7.7 変更方法の適正さを検証するための単体テスト
    • 3.7.8 マージできるだけの情報があればよい
    • 3.7.9 変更仕様の粒度の問題
    • 3.7.10 バグも書き残す
  • 3.8 ソースコードの変更は足並みを揃える
    • 3.8.1 抜けがけ禁止のルール
    • 3.8.2 ソースファイル単位に集める
    • 3.8.3 3度目の訪問
    • 3.8.4 ソースファイルを共有しているケース
    • 3.8.5 変更作業に費やした時間を記録する
    • 3.8.6 書き直しがない
    • 3.8.7 変更後の単体テスト
    • 3.8.8 ソースコードの合体
    • 3.8.9 ソースコード変更後にすること

第4章 追加のプロセスとXDDPを支えるものたち

  • 4.1 機能追加のプロセス
    • 4.1.1 追加機能要求仕様書を作成する
    • 4.1.2 仕様間の衝突に注意する
    • 4.1.3 変更要求仕様書と要求番号でつなぐ
    • 4.1.4 追加機能だけで設計を進める
    • 4.1.5 機能追加分のTM(トレーサビリティ・マトリクス)を作る
  • 4.2 移植を扱う
    • 4.2.1 移植は“機能追加”の変形
    • 4.2.2 2種類の変更仕様で対応する
    • 4.2.3 仕様の確認を忘れずに
    • 4.2.4 機能の一部を流用するケース
    • 4.2.5 ペーストシンドロームを回避する
  • 4.3 派生開発における品質要求のあり方
    • 4.3.1 追加機能に対する品質要求
    • 4.3.2 変更要求に対する品質要求
  • 4.4 XDDPにおけるレビュー
    • 4.4.1 3つの成果物の役割とレビューポイント
    • 4.4.2 What−Where−How の関係
    • 4.4.3 変更要求仕様でのレビュー
    • 4.4.4 追加機能要求仕様書のレビュー
    • 4.4.5 トレーサビリティ・マトリクス(TM)でのレビュー
    • 4.4.6 変更設計書でのレビュー
    • 4.4.7 その他の成果物のレビュー
    • 4.4.8 変更作業をストップさせる
    • 4.4.9 一人プロジェクトでのレビュー
    • 4.4.10 レビューの効果
  • 4.5 XDDPにおける要件管理
    • 4.5.1 派生開発での要件変更の難しさ
    • 4.5.2 派生開発における要求仕様書のベースライン設定
    • 4.5.3 ベースライン設定後の変更の可能性は減っている
    • 4.5.4 追加機能への変更は変更仕様も変わる可能性がある
    • 4.5.5 慎重な要件管理で対応する
    • 4.5.6 CCBに最終決定権を持たせる
    • 4.5.7 一人プロジェクトにおける要件管理
    • 4.5.8 暫定仕様に対する仕様変更
    • 4.5.9 変更が仕様で届いたときの対応
    • 4.5.10 作業の中断に工夫が必要
    • 4.5.11 追跡リストへの登録と運用
    • 4.5.12 もう一つの追跡リストの活用
    • 4.5.13 ぎりぎりまでソースコードを変更していないことの効果
  • 4.6 ドキュメントの維持
    • 4.6.1 公式文書はテスト中に差分によってマージする
    • 4.6.2 機能仕様書に戻す
    • 4.6.3 スペックアウト文書の扱い
  • 4.7 サイズ見積りについて
    • 4.7.1 変更要求からソースコードの変更規模を見積る
    • 4.7.2 「before」「after」が見積りの根拠となる
    • 4.7.3 変更要求仕様書を書いたあとのサイズ見積りの調整
    • 4.7.4 変更要求TMのセルをサイズ見積りにも活用する
    • 4.7.5 変更設計書でさらに調整する
    • 4.7.6 見積り値と実績値の乖離の意味
  • 4.8 XDDPのプロセスを変化させる
    • 4.8.1 PFDを使ったプロセスの表現
    • 4.8.2 PFDはシミュレーションの道具
    • 4.8.3 リファクタリングとのコラボレーション
    • 4.8.4 共通のベースから複数の並行開発も可能
    • 4.8.5 インクリメンタル開発も派生開発の特性を持つ
  • 4.9 運用時の注意
    • 4.9.1 1回目のコンサルティングでの成功を勘違いしない
    • 4.9.2 文書を減らそうという圧力に対抗すること
    • 4.9.3 サイズ見積りも計測も省かない
    • 4.9.4 親和性に注意
    • 4.9.5 「原典」に戻って
    • 4.9.6 偽装工夫に注意すること

第5章 XDDPの効果

  • 5.1 とても間に合わない……と思われたのに
  • 5.2 XDDPで納期が遅れない理由
  • 5.3 工数が大幅に短縮する仕組み
  • 5.4 バグの件数からも大幅な時間の削減が可能
  • 5.5 仕様変更と変更ミスの大幅な減少
  • 5.6 バグの根源を絶っている
  • 5.7 レビューでバグの過半が発見される
  • 5.8 デバッグ時にも大きな効果が得られる
  • 5.9 「デスマーチ」から脱出できる
  • 5.10 一人プロジェクトでも失敗しない
  • 5.11 アウトソース先と連携する
  • 5.12 次のプロジェクトへの準備ができる
  • 5.13 将来への備え
  • 5.14 日本版SOX法への対応
  • 5.15 ソフト以外への応用

著者プロフィール

清水吉男(しみずよしお)

1968年からソフトウェアの世界に入り,途中から組込みシステムの世界に転じる。CMMとの遭遇を機に,それまでの成功事例をもとにして要求の仕様化(USDM)や派生開発に特化したXDDPプロセスなどの開発方法をまとめて,95年にプロセス改善のコンサルティングに転向して今日に至る。著書に『要求を仕様化する技術・表現する技術』『「派生開発」を成功させるプロセス改善の技術と極意』(いずれも技術評論社),『SEの仕事を楽しくしよう』(SRC)。

硬派のホームページ:http://homepage3.nifty.com/koha_hp/