はじめに
清水吉男氏の以下の2つの書籍を読んで重要だと思ったことをまとめておく。
- 「「派生開発」を成功させるプロセス改善の技術と極意」 ，技術評論社，2007
- 「[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 ～仕様が書けていますか?」，技術評論社，2010
まとめていることは、派生開発カンファレンス2022での発表で参考にさせていただいたことである。
『「派生開発」を成功させるプロセス改善の技術と極意』
スペックアウト P.60、P.109、P.128、P.129
設計書の不足を補うために、ソースコードから必要な設計書を起こす行為を「スペックアウト」と呼んでいます。
具体的な変更箇所や変更すべき項目（変更仕様）を拾い出すために、ベースのソースコードを読んでそこで行われている処理を理解することになります。このとき、適当な設計資料が残されていない場合は、理解した内容を「設計書」を補完するような資料の形にして残します。この行為を「スペックアウト作業」と呼んでいます。
ソースコードを読むのは、必ずしも変更箇所を探すためとは限りません。変更仕様は見えているのですが、それを確かめるためにソースコードを読むこともあります。
調査の結果わかったことを残す資料の形
- 関数の呼び出し関係を構造図にする
- クラスの関係を理解した状態を図と説明にする
- 構造体の図を描いて個々の要素のとる値の範囲や説明を付ける
- グローバルデータを表にして、アクセスしている関数との間でマトリクスを作る
変更要求に対して変更仕様を抽出する方法 P.144
- ベースのソースコードに対応する機能仕様書や操作仕様書などの文書から変更箇所を拾う
- 関係しそうな箇所のソースコードを読んで，変更する箇所を拾う
- ソースコードの関係個所をスペックアウトしながら，変更する箇所を拾う
変更要求単位で該当箇所を探す P.179
ソースコードから変更仕様を抽出する作業は、必ず「変更要求単位」で行います。「スペックアウト」によって作成された成果物は、変更要求が所属する機能に対応した資料となり、その過程で発見した変更箇所を「変更仕様」として変更要求の下に記述することができます。
補助資料の効能 P.221
派生開発における影響範囲は、通常の処理構造などの「スペックアウト」だけでカバーしきれないことも少なくありません。
変更が影響することを見逃さないために理解しておくべきこと
- 機能の依存関係
- 機能とパラメータの関係
- ハードのリソースとそれを使う機能の関係
成果物のレビュー P.318
XDDPではこのほかに、変更要求に対してスペックアウトで作成した成果物や、現状のアーキテクチャを解析したときの成果物などがあります。このような調査資料は公式にはレビュー対象になっていませんが、このソフトウェアシステムを調査した担当者が認識を間違えたままではこのあとで正しい変更作業はできません。
『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』
要求仕様にまつわる問題の種類 P.34
- 仕様の記述モレ
- 良い手が仕様を誤って解釈してしまう仕様の誤解釈
- その仕様が自分に関係する仕様とは気づいていないという認識不足
- テストの段階に入ってようやく発見される仕様間の衝突
設計の階層 P.75
設計には段階があります。
各段階における仕様に対して、これら3つの視点から実現方法を考え決めていくことになります。
"仕様"になっていない P.92
要求仕様書のレビューで一番の障害は、そこでの表現が「仕様」になっていないことです。まだ抽象的な表現が残っていて、その表現のなかにどこまでの動きを含んでいるか見えないのです。つまり、書き手がどこまで認識してこのような文章（仕様表現）にしたのかが見えないため、漏れていると指摘するにも迷ってしまうのです。
要求の分割の基準 P.201
- 時系列分割（時間軸分割）
- 構成分割
- 状態分割
- 共通分割
何が変更されるかを表現する P.304
「変更要求」をしっかりと表現する
変更要求で大事なことは、それが“変更”であることを明確に表現すること
差分を書く P.305
派生開発における「要求」は、基本的には現在のシステムに対する「差分」です
ソースの変更を変更仕様として記述する P.307
ソースコードを変更するということは、ソースコードになった「仕様」を変更するということです。この場合の「仕様」は、最初の機能の振る舞いを記述した仕様とは限りません。設計工程の分割と階層化の過程でクラスや関数の仕様として設定した仕様が対象となることがあります。
「変更要求仕様書」では、このような実装レベルの仕様（ソースコードになっている）の変更も変更仕様として記述することを求めます。
派生開発のトラブルの多くはこの種の変更を「仕様変更」として記述しないところから発しているのです。
派生開発において、このような実装レベルの仕様の変更を「変更要求仕様書」に記述しなければ、重大な変更のミスを発見する機会を失うのです。
関連記事