派生开発
- 1. 「派生开発」を成功させる プロセス改善の技術と極意 ２０１２年 ６月２７日 鈴木 尚 1
- 2. 注意事项 この資料は、個人的に本の内容を簡単 にまとめたものです。 よって、必ずしも、本の内容を正確に 反映しておりません。 また、記述内容は随時見直していきま す。 資料： 2
- 3. 派生开発とは ＜派生开発の分類＞ ◆機能変更 ?今回変更となる機能 ?変更により影響を受ける機能 ◆機能追加 ?今回追加される機能 ?追加により影響を受ける機能 資料： 3
- 4. 派生开発におけるリスク ＜現場で起こっていること＞ 今まで動いていたものが動かなくなる。 もしくは誤動作をする 主な原因 ①変更モレ、仕様誤理解、テスト不足 ②部分理解。ソースコード理解不足。短納期 ③開発と保守で担当者が異なる。 しかも、仕様書不備。ソースコードが正という現状。 どうすれば納期や品質の要求を達成できるのか？ 資料： 4
- 5. 今までのやりかた ＜いままでの開発フロー＞ ソースコードの理解が 変更仕様書から 進むので以前変更した ざっくり工数を見積もる 変更の実装モレが見つ かった もう「完了」 ソースコードを読んで変 しているので 更箇所にあたりをつける 触りたくな い??? 以前変更した箇所を ソースコードを変更して 更に変更することに 動作確認をする なった 「完了」した うまく動けば「完了」 部分を迂回し システム 次の変更テーマに移る て実装しよ が複雑に う！ なる～ 資料： 5
- 6. 対策 ＜新しい開発フロー＞ 担当者による思い込みや思い違いを「チーム の力」で発見する 改善後の開発フロー案 ①「変更要求仕様書」に変更仕様を書き出す ②「変更設計書」に実際に変更する箇所を書き出す ③レビューをする 思い込みと勘違いが入る世界において、適切 な機会に効果的な角度からのレビューを取り 入れるため 資料： 6
- 7. 派生开発用のプロセスフロー ＜PFD＞ 変更 ３ 元の 設計書 テスト ソース ケースを 変更 変更する 変更要求 要求書 仕様書（TM) １ 変更要求 を実現す テストケース る 既存 変更後の 仕様書 ソース 追加機能 要求仕様書 ４ 統合テス ト ２ 追加機能 追加機能 機能追加分 統合後の の要求を 要求書 のソース ソース 実現する 資料： 7
- 8. 変更要求のプロセスフロー ＜PFD＞ 1.2 スペックア ソースを ウト資料 1.5 調査して TMの交点 元の 変更仕様 に対して ソース を抽出 変更設計 書を作る 変更 設計書 変更 1.1 要求書 変更要求 変更仕様 を抽出 仕様書（TM) 1.6 既存 変更設計 仕様書 書に従っ 1.3 て修正 追加機能 1.4 受入用の 変更要 追加機能 変更仕様 求TMを スペックア 変更後の 要求仕様書 を抽出 作る ウト資料 ソース 資料： 8
- 9. 追加要求のプロセスフロー ＜PFD＞ 変更用プロセスへ 追加機能 2.1 追加機能 2.3 要求書 追加機能 要求仕様書 追加機能 の要求仕 のソース 様を作る を書く 既存 仕様書 追加機能 の設計書 2.2 （クラス、 追加機能 メソッド） 機能追加分 毎に設計 のソース 通常の「設計」の範囲 資料： 9
- 10. 開発プロセスの説明 ＜変更仕様を抽出する(1.1,1.2,1.3)＞ 【概要】 ?依頼者から届いた変更要求を、要求と仕様に分けて記述する ?提示された要求については、変更仕様を記入する ?仕様を提示された場合は、空いている変更要求を追記する ?ベースの機能仕様書から変更点（変更仕様）を抽出する ?ソース等を調査しながら変更仕様を抽出する。 ?事前に、文書一覧、ソース一覧を準備しておくと良い ?わかったことはスペックアウト資料を起こして記録する ?追加する機能に対する「変更」も変更要求仕様書に記述する ?見積もりがブレる可能性が高いものから着手すると良い 資料： 10
- 12. 開発プロセスの説明 ＜変更設計書を作る(1.5)＞ 【概要】 ?その箇所を変更するのが適当だと判断されてから作成する ?どのモジュールのどの箇所をどのように変更するかを記述する ?後で確実に変更方法を思い出すことができる情報を記述する ?変更箇所のみを簡潔に記述する。全体を記述しない ?ソースコードを書き込むのは原則禁止 資料： 12
- 13. ソースを直接書かない理由 ＜直接ソースを変更した場合の弊害＞ ?その変更箇所が適切かどうか、レビュアーが判断できない。 ?その変更方法が正しいかどうかも判断できない ?後でもっと良い直し方がわかっても触りたくなくなる ?潜在バグとなって残ってしまう。 ?「設計書を書く」作業がムダに思えてくる 「部分理解の罠」に陥る 資料： 13
- 14. ソースを直接書かない理由 ＜変更箇所を文章で書く利点＞ ?後で間違った判断に気がつく事ができる ?レビューで有識者に見てもらえ、モレに気がつく ?後でもっと良い変更箇所がわかったとき、簡単に捨てれる ソースを変更してしまった後だと手戻りになるので、 なかなか捨てられない。 チームでのレビューが可能になる 資料： 14
- 15. ソースコードを変更する ＜ソース変更後に行なうこと＞ ?実際にソースコードの変更にかかった時間を記録する ?変更前と変更後のソースの差分をとり、変更設計書と突合せる ?設計書に書かれていることが、実際に変更されていない ?設計書に書かれていないことが、変更されている 資料： 15
- 16. レビューの観点 ＜各成果物のレビュー＞ ■変更要求仕様書 ?変更要求に対して、変更すべき箇所が適切に変更仕様として抽 出されているかどうかを確認する ?担当者の勘違いや思い込みをチームで発見していく ■トレーサビリティマトリクス ?変更要求仕様書のレビューを終えてから実施する。 ?他に変更する箇所はないか。無関係な場所を変更していないか ■変更設計書 ?変更要求仕様書で捉えられた変更の意味とマッチするか ?変更方法は適切か ?その変更方法に対する確認内容は適切か？ 資料： 16
- 17. 見積もりについて ＜見積もり方法＞ 派生开発を行なっていくうえでは、サイズに基づいた見積もりが 不可欠。 仕様化前の段階で仮説見積りをして、工数と期間を計画する。そ の後は随時、実績値を見ながら見積もり値を検証（調整）し、計 画割れしないかどうかを監視する。 ?調整後の見積りが仮説見積りを超えていた場合は要対策 見積もりタイミング 変更仕様項目数 変更ソース行数 仕様化前 初期（仮）見積り値を記 初期（仮）見積り値を記入 入 仕様抽出後（1.3) 実績値を記入 仕様の実績値から再見積り TM記入時(1.4) ‐ ソースを見ながら再見積り 変更設計書(1.5) ‐ ソースを見ながら再見積り ソースコード変更 ‐ 実績値を記入。反省会 (1.6) 資料： 17
- 18. 成果物①（WHATを表現） ＜変更要求仕様書＞ 「変更して欲しいこと」について関係者の間で 特定（仕様化）できたことがまとめられた文書 【概要】 ?「今こうなっているところをこうしてほしい」と具体的に記述する ?適切に分割する（時系列、構成、状態、共通） ?仕様書にはソースを直接書かない（HowよりWhatに集中） ?変更要求を洗い出した時点で仮説見積もりをおこなう （指標）変更仕様の数、ソースコードの変更ステップ数 ?仮説見積もりに生産性と人数をかけて日数を算出する 資料： 18
- 19. 成果物②（WHEREを表現） ＜トレーサビリティマトリックス（TM)＞ 【概要】 ?機能の単位毎に列挙する 【利点】 ?仕様毎の変更箇所が一目でわかる。 ?他に影響箇所があるのでは？という「気づき」を誘発する 資料： 19
- 20. 成果物③（HOWを表現） ＜変更設計書＞ 【概要】 ?「変更点」だけを書く。既存仕様は書かない。 ?設計書にソースを直接書かない ?変更要求仕様を全てレビューしてから作る ?必要な変更箇所を全て拾ってから作る 【利点】 ?変更後にテストで確認する内容がイメージできる ?バグが出たとき、どこをどのように直したかわかる 資料： 20
- 21. 派生开発実施時の注意 ＜取り組み開始時によくあること＞ ?１回目のコンサルティングで「成功」したと勘違いしない ?文書を減らそうという圧力に対抗すること ?サイズ見積りも計測も省かない ?１回の派生开発で扱うのは、ベースのソースに対して３割以下 ?それ以上になるなら、イテレーションを分ける 資料： 21
- 22. 工数が短縮される仕組み ＜ソースを直接変更するフロー＞ 「ソースを直接直した方が早い」と言っても、実際はこれぐらいの作業を 行なってます。 ソース 既に変 変更内 コード 関連箇 更した 関係資 ソース 容の確 の調査 所への 箇所と 料の調 コード 認と検 とメモ 影響調 の調整 査 の修正 討 的な設 査 と読み 計 返し 見えていない（無意識におこなっている）作業 この部分を文書化してレビューをすること で品質を上げる。また、不具合が早く見つ かることで対応工数も減らす 資料： 22
- 23. ＜参考＞ （１）清水吉男氏 「派生开発」を成功させるプロセス改善の技術と極意 技術評論社 23