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

昨日読んだ本。いろいろ考えさせられる本だった。

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

当書籍では、「派生開発」という用語を「新規開発」以外の開発すべてを指す用語として使用している。「派生開発」は、改修や機能追加のすべてを含む。
※「派生開発」は、著者が作成した用語である。
よく知られている通り、ソフトウェアライフサイクルの殆どはこの「派生」に属し、費用も新規開発の何倍もかかる。従って、この部分をどれだけ効率よくできるかが、TCOの削減に大きく寄与する。また、当然のことながら、「派生」で障害が発生すると業務に支障が出、顧客に迷惑をかけることがあるため、重要度はとても高い。
にも関わらず、「派生」に対する適切なプロセスがないことがずっと気になっていたため、書籍のタイトルとアマゾンの紹介を読んで飛びついた。

以下に、概要と所感を記録する。一読し、理解した内容と感想を元に記載したものであるため、著者の意図とずれている可能性があることをご容赦いただきたい。

概要

趣旨

当書籍の趣旨は、以下の通り。
ライフサイクルの大部分を占める派生開発ではプロセスが整備されておらず、混乱を極めている。しかし、新規開発時の重量級プロセスを適用する余地がないことが多い。最小限のコスト、スケジュールで品質を確保するプロセス（XDDP - eXtreme Derivative Development Pocess）を紹介する。

混乱を極めている

だいたい以下のような説明であった。

• 仕様書が碌すっぽないため、ソースコードから仕様を理解する必要がある
• 全体を理解しないまま、短期間／低コストで開発を行う必要がある
• 変更要求などは「仕様」レベルの変更であることもあり、文書化されていないこともある
• 修正を加えていくと、ソースコードはどんどん劣化する

が、「こんな現場あるの？」というのが率直な感想。あるのかな？重量級プロセスに金払うシステムに関わることが多かったから、私の感覚がずれているのかもしれないな。

XDDPプロセス

以下の３つの成果物に絞る

• 要求仕様書
  • 「要求」と「仕様」を区別して記載すること
  • 要求が生まれた理由も記述すること
• トレーサビリティマトリクス
  • どの仕様に対し、ソースレベルでどこに修正が発生するかをマトリクスで示す
  • 網羅性を確保すること
  • 不足があればレビューで指摘できること
• 変更設計書

いずれも、ポイントは以下の通り。

• 変更箇所に絞ること
• アウトプットされており、レビューできること

所感

特に画期的なことは言っていないが、主要な成果物を３つに絞りポイントを絞って示すシンプルさが、このプロセスと書籍の価値だと考える。実践しやすいプロセスである。
しかし、導入部分で「こんな現場あるの？？」という疑問符がついたまま読んでしまったので、申し訳ないけどこのプロセスの価値も「？」がついたままパラパラ読み進めてしまった。
この手のものは、読んで「分かる」とものでなく、実践して「腑に落ちる」ものなので、現場から遠ざかっている私は読者として不適切だったかもしれない。

少しどうでもよい感想を追加。
「派生開発」という用語は気に入らない。（以降、敢えて保守と呼ぶ）。冒頭で述べた通り、保守開発はとても重要だと思っているため、中の人が「メインストリームでない」と言っている状態では、費用もかけられないので、プロセスが整備されることもあり得ないのではないか？
そもそも保守のプロセスが整備されにくいのは、新規開発に比べて扱いが軽いのか費用や期間が十分に用意されず、プロセス整備のように緊急度が低いように見えるものに工数を裂けないからなのではないか？
「顧客がカネだしてくれない」と文句を言うのは責任転嫁である。モノを作る側こそが複雑度やリスクを十分に知っているので、顧客やスポンサーに説明し、費用や工数をきちんと確保するべき。保守はもっと立場を主張すべき。これはプロマネの責務なのではないか？