プログラマの思索

SQIP2009で清水吉男さんのXDDPの講演を聞く機会があった。
アジャイル開発や並行開発、要求仕様と機能仕様の違いについて、とても勉強になったので、メモを公開しておく。
なお、メモ書きなので、分かりにくい部分は、下記の著書を読んで理解してください。

【講演メモ】
◆派生開発の特徴と問題点
保守開発
　JISで定義されている
　派生開発とは似ているが異なる
　　例：携帯電話は、電話以外の機能が次々と追加されている
　　　　保守ではない
→是正保守プロセスで改良保守を行うと問題が発生する

派生開発特有の混乱が生じている
　まずい作業で品質が劣化する

派生開発にはアーキテクチャ設計がなくても開発できる

仕様は設計しないと出てこない
　衝突は仕様レベルで出る

派生開発は新規開発よりも複雑
　追加機能と変更は異なる
　機能追加は、新しい機能の仕様やレビューしかない
　　追加と変更の2本立てにしなければならない

ソースも移植に伴い、拒否反応を起こす
　プログラムは、既存のシステムのために作られた
　しかし、他のシステムへ再利用すると、文化が違うので、拒否反応を起こす
　　免疫、臓器移植と同じ

変更方法も一つとは限らない
　例では3つ方法がある
　どれもテストOK
　しかし、1年後に問題になる
　　何のために要求が来たのか？
　　表示欄が足りないのが本来の要件

一つの変更が複数の機能にまたがる
　機能同士の依存関係
　　データなど
　　気付きやすい
　設計やプログラミングによって影響する
　　設計書に変更内容が反映されていない
　　
　　ネームロンダリング
　　　引数に渡ったデータパターンが悪さする
　　クローンコード
　　　移植するとアルゴリズムは同じだが変数名が変わるので同一ではないと見てしまう

派生開発は「部分理解」の制約が多い
　やっぱり全体を理解していない、という言葉が反省会でよく出る
　皆が納得して終わっている
　　リソースが足りないので全部を調べきれない
　　理解のレベルが曖昧
　　　理解できなかった時の対応方法が考えられていない
→部分理解しかできないのだ、という仮定で進めよう
→どのタイミングでどのようにレビューするか、が非常に重要

派生開発は一人プロジェクトが多い
　一人プロジェクトはやめよう
　　部分理解の罠に陥りやすい
　　　思い込み、勘違い
　擬似一人プロジェクトもある
　　大人数チームでも、担当者一人の作業
　　各担当者が作ったソースを結合して、初めて不具合が分かる

拙速なソース変更が状況を悪化させる
　開発期間が短いため、プレッシャーが大きい
　ソース修正期間が長いため、ながら作業になっている
　　修正方法が異なるやり方で何度もソースをいじって、品質を劣化させる
　　1日500行直したとしても、本来の正しいソースは50行だけかもしれない

バグがいつまで経っても収束しない
　バグ修正で新しいバグを埋め込んでしまう
　　テスト期間がどんどん延びる
　派生開発では、修正した箇所が問題なのに、ソースコードを弄んだために変更した箇所の手がかりを失った
　　バグ修正のプロセスが個人任せ

変更方法に基づくテストが行われていない
　機能追加だけで、変更機能のテストが行われていない

新規開発崩しで公式文書を変更している
　公式文書を削って修正するが、あくまでも作業中
　　最終版ではないので、どれが最新の仕様か分からない
　　→並行開発や五月雨開発の支障になる

そもそも組織には新規開発のSDSしかない？
　SDS
　　ソフトウェア開発スタンダード
　　CMMIの用語
　CMMIの認証は新規開発プロジェクトを対象とするケースが多い
　　派生開発用のSDSが必要
　　→XDDPが売れない理由

要求仕様のFixを要求するのが当然と思っている
　仕様が見えないので、スムーズな合意が形成できない
　　後で動くようになってから、必ず仕様変更が発生する
　要求仕様書の構成が邪魔している

作り方の品質要求が入っていない
　機能仕様書で作ろうとしている
　　機能の概要であって、作り方は書いていない
　要求仕様書を作るべき
　　作り方が入っている
　保守性の観点が漏れている
　　ソースを触るほど品質が劣化する
　　派生開発で、保守性の品質要求が記述されていない

保守性の意味が最近変化している
　Maintainabilityが基本
　しかし、Supportabilityなどが混じっている

作り直しても何も変わらない
　アーキテクチャを作り直しても、派生開発に追われて新しいアーキテクチャを勉強していなかった

派生開発を意識しないと明日はない
　不適切な派生開発プロセスで対応している
　　Faster、Cheaper、Worse！

◆XDDPの解説
XDDP＝USDM＋PFD
　要求仕様の書き方
　　USDM
　プロセスを自由自在に設計する
　　PFD

USDMは表現に重点を置いた仕様化の方法
　最近のモデリング
　　要求の発見を重視する
　　しかし、要求の表現方法はあまり触れていない
　せっかく発見した要求も適切に表現されなければ、仕様が漏れる

USDM
　機能要求は、振る舞いを表現する
　　その中に仕様がある
　要求と一緒に理由を表現する
　　要求の意図や背景を補足する
　　認識のずれを軽減する
　仕様は、要求の中の動詞、目的語にある
　　動詞を的確に表現することで必要な仕様を引き出す
　　→本には触れられなかった
　要求と仕様を階層で表現する
　　要求も2階層で表現したりする

　コミュニケーションの不完全性を相当程度カバーする
　　アジャイル開発で頻出する
　　　「分からないならさっさと作ってリリースした方がいい」という考え方がアジャイル開発

要求仕様書と機能仕様書の違い
　要求仕様書
　　今回のプロジェクトで実現して欲しいこと(Requirement)
　　作ることの関係者が、実現内容について特定(Specify)できている
　　　関係者も特定できている
　　　　作る人、依頼する人、確認する人
　　今回限りのドキュメント
　機能仕様書
　　関係者を特定できないので、表現は均一になる
　　VerUpしていく

プロセスと成果物は表裏一体
　プロセスを変えると成果物も変わるはず
　でも、プロセス改善を叫ぶ所では、30年前の設計書を使っている
　
新規開発
　機能仕様書(企画)がInput
　新規に作る時に、機能仕様書に変身する
　　完成後に機能仕様書に戻り、VerUpしていく
　　要求仕様書は途中で作られる

派生開発
　要求仕様書は2種類必要
　　変更、機能追加
　　要求仕様書は差分の情報だけ
　　2つの要求仕様書に基づいて開発していく
　完成後に、機能仕様書へマージして更新する

追加機能要求仕様書
　追加分＋変更分の2個がある！
　変更分は、BeforeとAfterがある

変更要求仕様書
　変更分

XDDPは2種類のプロセスを並行で動かす
　変更分＋追加分
　追加機能要求仕様書を作成後、変更要求仕様書を作る

変更プロセス
　Input
　　変更箇所の仕様
　　ソース調査
　　追加要求の仕様
　OutPut
　　変更要求仕様書
　　TM(トレーサビリティマトリクス)
　更に、変更設計書を作成する
　　ソースレベルで変更箇所を特定し、修正方針を作る
　ソースコードを一斉に変更する
　　最初のソース調査、変更設計書の作成時、今回の3回もソースを見ているので漏れがない

機能追加プロセス
　機能追加を扱うプロセス
　変更プロセスとの間で、追加機能を受け入れる方法を調整しておく
　　終了したら、そのまま設計に取り掛かる
　変更プロセスと関係なく進める

変更プロセスは3点セット
　変更要求仕様書　What
　TM　Where
　変更設計書　How
↑
アーキテクチャが存在しているため、TMまで作れる！

仕様→設計する→設計書

設計するためにソース調査の観点
　データ構造
　制御構造
　判定構造

XDDPの特徴
　変更と機能追加のプロセスを分ける
　差分で進めるので並行開発が可能
　テスト終了後に公式文書へ反映する

◆追加機能要求仕様書
　普通の新規開発と同じでよい
　要求と仕様を階層化する
　認定仕様の考え方を受け入れる
　　納期を考慮した暫定の仕様

要求の発見
　ユースケース
　　最近は、振る舞いの一部の動作しか表現しない傾向が見られる
　　　動詞が見えづらい
　　ロールに要求があるはず
　状態遷移
　　イベントから振る舞いを表現する
　操作画面の要素
　　画面も一つの状態
　　ボタンはイベント発生源

機能要求は振る舞いと範囲で表現する
　範囲
　　イベントの始まりと終わり
　　　バッチ処理ならジョブ実行のみ
　範囲に注目しよう

要求には理由を付ける
　理由は要求の一部
　理由から代替仕様を提案できる

範囲が広いと仕様が漏れやすい
　隠れた動詞が多い
　動詞を探して時系列に分割する

分割は2階層程度で抑える
　階層化で隠れている動詞を全て洗い出す

分割方法は構造化設計の技術で十分
　モジュールの分割基準

設計しないと仕様が出てこない
　設計とは分割すること
　時系列にシナリオを作ること

仕様とは、要求に含まれる具体的な処理や振る舞いを表現したもの
　仕様はテスト可能
　　検証可能
　仕様は全てソースコードになる
　　実現可能

仕様は階層の中で捉える

認定仕様
　仕様化する必要がない要求
　　既に分かっているなら設計しなくてもいい
　　　工数削減
　　□で書いておく
　　　チェックボックスの代わり
　→要求仕様書だから可能
　　　機能仕様書はこのような記述は認められない
　→邪道らしいが、現実的
　　　XPのシンプルと同じ
　
例：要求＝70個
　　　50個＝認定仕様
　　　　→仕様化する工数は不要
　　　20個＝きちんと作る
　　　　→1120個の仕様が出てきた

必要なら仕様にも理由を書く

仕様のグループ化
　動詞の単位でグループの下に仕様を引き出す

仕様から要求を作る
　みにくいアヒルの子
　　要求と理由があるのに、仕様とマッチしない状態
↓
対応方法：
1・他の要求へ仕様を移動する
2・適切な要求を作り、仕様を移す
3・要求と理由を変更して、範囲を広げる
↓
新しい要求を設定すると、新しい仕様に気付く
　従来の要求仕様書では、このテクニックは使えない

画面配置図の下に仕様化する
　画面仕様書と同じ
　画面操作は1階層で殆ど対応可能

作り方の要求も仕様化する
　保守性などの品質要求も仕様化しないと実現しない
　　XDDP特有の開発スタイル
　検証できるように表現する
　　仕様だから
　　作業者に対する指示書になる
　　　従来の機能要求書には、保守性は書けない
　　　　保守性は機能ではないから
　　保守性も要求である
　　　従来の本には、保守性の要求を表現する技術が書かれていない

「見なす」という文言がXDDPには出てくる
　要求はこれだけの仕様を満たす
　「見なす」には承認作業が含まれている？

問題は要求漏れ
　仕様漏れが原因ではない
　要求を表現しないから仕様漏れと認識される

Excelでは、行を折り畳む機能がある
　要求だけを一覧表示する
　　仕様を隠す
　TMが一番重要
　　行は、要求＋仕様
　　列は、機能
　　変更箇所が交差する所

◆変更要求仕様書の書き方
　全ての変更を扱う要求仕様書
　　変更要求と変更仕様を階層化する
　実現方法まで特定する(Specify)
　　変更仕様はソースコードのレベルで記述する
　　→追加機能の場合と異なる

変更要求の範囲と理由を表現する
　範囲を明確に表現することで、要求になる
　Before、Afterを表現する
　　追加する、削除するには、Before、Afterの情報が含まれている
　Beforeに影響箇所の情報がたくさん含まれている

変更は要求ではなく、仕様で届く時が多い
　問題
　　依頼された箇所を変更するだけでは済まない
　　　そもそも適切な箇所とは限らない
　対応
　　変更仕様から変更要求と理由を探して、改めて変更仕様を探す
　　
　→要求と仕様を区別しない状態では、これが問題と思われない

　機能仕様書などの文書から探す
　　具体例あり
　　　変更仕様だけでは仕様漏れが出る
　　　変更要求と理由を見つけると、新たな仕様が出てくる
　ソースコードを見ながら探す
　　具体例有り
　　　ソースコードを解析する
　　　発見した変更すべき箇所を変更要求の下に書き出す
　　　　すぐにソースを修正しない！

変更仕様はグループ化すると分かりやすい
　抽出された変更仕様が色んな箇所に散らばる場合、グループ化する
　要求仕様：関数の仕様＝１：N
　　XDDPは、ソースコードの変更は、仕様変更と捉える
　　
　変更要求の要求仕様でよい
　　そのままソース修正できる
　要求仕様をさらにばらす
　　関数レベルの仕様まで落とす

機能追加は、2種類の要求仕様書で対応
　追加要求仕様書
　変更要求仕様書

移植は2段階の変更が必要
　移植元での変更要求
　　移植先の状況に合わせるための調整作業
　移植先での変更要求
　　インターフェイスを合わせる

保守性
　機能追加
　　保守性の要求仕様を作る
　変更
　　劣化を防止するのが目的
　　保守性はアップできない

BeforeとAfterの差が見積もりの根拠
　工数が出る

TMを介して変更要求仕様書と変更設計書をつなぐ
　行：変更要求、仕様→What
　列：機能、担当者など
　交差点：変更設計書→How
　→TMでWhereを表現する

変更設計書は変更点だけ
　本当の設計書ではない

正式文書はテスト後にマージする
　公式文書の修正は短期間に行う
　　工数は確保されている
　並行開発や五月雨開発が可能になる

ソースコードは一気に変更する
　4ヶ月前に取り掛かった時と、4ヶ月調査して設計した後は状況が異なる
　プログラミングを単純な変換プロセスにする
　　生産性が高い

バグの原因解析で3点セットが役立つ
　派生開発では、バグは今回変更した箇所に存在する
　　変更箇所は全て、変更設計書に書かれている
　　範囲が絞られる

一人プロジェクトの問題を回避できる
　3点セットがあるから、レビューしやすい

XDDPで生産性向上
　ヒントはソースコード変更の生産性にある
　80～130行/時間　も可能
　設計に時間を費やして、プログラミングの作業時間を減らす

XDDPは、要求の発見よりも要求の表現方法に着目する
　仕様漏れや要件漏れは、仕様化プロセスで発生している
　設計プロセスの品質が悪いから

五月雨開発や並行開発が可能
　trunkの閉鎖期間が短い
　　一般の開発では、ソースの変更期間が長いために、実現できない
　3点セットによって、変更箇所が公開されている

彼女の表情が優しくなった
　3点セットでレビューしやすくなった

仕様変更率を５％以下を目指す
　仕様にまつわる問題が消える
　要件管理もスムーズになる
→CMMIのアセスメントが可能

2種類の生産性を出す
　今回生成したLOC/全体工数
　今回生成したLOC/実装工程の工数

SDSが派生開発の邪魔をする
　組織標準
　　新規開発用
　派生開発にXDDPを入れると、SDSを変更する必要性がある

仕様担当Gがガン
　XDDPでは、仕様担当Gの作業は、最初と最後だけ
　　追加/変更要求仕様書を作る
　　公式文書へマージする

不当支援を禁止する
　XDDPは早く終わる
　ブブカ方式
　　1センチだけ高く飛んで世界新記録
　　創造的無能を装う

【感想】
１・XDDPの良い所は、現場で鍛えられた理論であること。
　経験に裏打ちされている。
　CMMIは上からの開発プロセスだから、現場とマッチしない部分がある。
　要求開発も同様で、内容は素晴らしいかもしれないが、現場では使いづらい。
　実際の現場は、新規開発と派生開発の2種類を暗黙的に使い分けているはず。

２・「ドキュメント修正やソース修正はギリギリまで行わない」意味は、trunkに中途半端なコミットはしない、ということ。
　trunkへ中途半端な修正を入れると、品質が劣化するから。
　だから、タスクブランチを上手に使う。
　「テスト終了後、ソースとドキュメントを一気にマージする」意味は、タスクブランチの作業が完了したタイミングで、trunkへマージする、ということ。

３・追加と変更のプロセスは並行開発であること。
　つまり、trunkから2本(機能追加、変更)のタスクブランチを作る。
　既存の開発と混乱しないと言う理由は、trunkとタスクブランチを分けているから。

　XDDPがアジャイル開発のように思えるのは、並行開発だから。
　並行開発なので自然にアジャイル開発っぽくなる。
　但し、イテレーションを意識しないので、厳密にはアジャイル開発とは言えない。

４・変更要求←TM→変更設計書→ソースコード　でトレーサビリティを実現している。
　つまり、ソースから変更要求まで探すことができる。
　だから、運用保守に強いプロセスになって入る。

５・一人プロジェクトはペアプロで回避できないか？

６・XDDPは非常に面白いのに分かりにくい部分がある。何故か？
　trunkとbranchの違いが明確にされていない。
　実際の運用は、区別されているはずだ。
　変更と追加の2本のタスクブランチ上で作業しているはず。
　構成管理で整理していないので、分かりにくい部分がある。

　XDDPの特徴は、運用保守に強い並行開発。
　並行開発だから、アジャイル開発と相性がいい。
　上流工程の設計プロセスを凄く重視した開発スタイル。
　すごく勉強になった。