テストエンジニアへのリスクマネジメントのすすめ

4,259 views

Published on

2012/1とちぎテストの会議

Published in: Technology

テストエンジニアへのリスクマネジメントのすすめ

  1. 1. 「移り気な客のためのリスクベースドな下準備」   ~テストエンジニアへのリスクマネジメントのすすめ~ 2012/10/20  @とちぎテストの会議02   ☆☆   @goyoki
  2. 2. はじめに •  @goyoki   –  組み込みソフトウェアの開発とテストに従事  •  このセッションについて   –  テストプロジェクトでのリスクマネジメントの紹介  
  3. 3. 予測困難なお客様の相手 マネージャ 開発者 テストエンジニア 営業 お客様
  4. 4. 予測困難なお客様の相手 やっぱ仕様変更  実装遅れたから  工数2/3にして  人やめたけど   そのままで   要求仕様   間違ってた  
  5. 5. 予測困難なお客様の相手 やっぱ仕様変更   仕様変 更が多く なりそう  実装遅れたから  工数2/3にして  人やめたけど   遅れそう   そのままで   要求仕様   仕様   間違ってた   間違って そう   問題を予測
  6. 6. 予測困難なお客様の相手 やっぱ仕様変更   APIベースでテスト自動化   仕様変 更が多く なりそう  実装遅れたから  工数2/3にして   見積りを早期から共有  人やめたけど   インクリメンタル開発を採用し 遅れそう   そのままで   前倒しで機能テスト実施  要求仕様、ユーザ 仕様   の意図と   間違って ユーザビリティテストの追加   矛盾してた   そう   プロトタイピングの拡充   問題を予測
  7. 7. プロジェクトリスクの  予測困難なお客様の相手 リスクマネジメント やっぱ仕様変更   APIベースでテスト自動化   仕様変 更が多く なりそう  実装遅れたから  工数2/3にして   見積りを早期から共有  人やめたけど   インクリメンタル開発でテスト 遅れそう   そのままで   前倒し  要求仕様、ユーザ 仕様   の意図と   間違って ユーザビリティテストの追加   矛盾してた   そう   プロトタイピングの追加  
  8. 8. プロジェクトリスクの   リスクマネジメント •  プロジェクトにダメージを与えるリスクを管理し、許容 できる水準までリスクの回避や軽減を行う管理手法   ダメージの可能性  開発開始 リリース
  9. 9. プロジェクトリスクの   リスクマネジメント •  プロジェクトにダメージを与えるリスクを管理し、許容 できる水準までリスクの回避や軽減を行う管理手法   ダメージの可能性   軽減・前倒し   予測・分析して対応 予防 開発開始 リリース 補償の準備
  10. 10. テストエンジニアにとって  リスクマネジメントはとても重要です! 要求分析 設計 実装 テスト ふつうのWF リリース テストエンジニアは   後工程を主担当
  11. 11. テストエンジニアにとって  リスクマネジメントはとても重要です! バグは出すな   リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース テストエンジニアは   後工程を主担当 担当が品質や   デリバリーに直結する
  12. 12. テストエンジニアにとって  リスクマネジメントはとても重要です! バグは出すな   遅延 リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース スケジュール遅延の   担当が品質や  しわ寄せを受けやすい デリバリーに直結する
  13. 13. テストエンジニアにとって  リスクマネジメントはとても重要です! バグは出すな   遅延 リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース バグ混入 要求定義   のミス テスタビリ ティの悪さ 仕様バグ 粉飾 見積りミス 隠れた   仕様変更 スケジュール遅延の   担当が品質や   放置したリスクが具体的な問しわ寄せを受けやすい デリバリーに直結する 題に顕在化してくる
  14. 14. テストエンジニアにとって   リスクマネジメントはとても重要です! 仕様やプ 遅延や  問題対応   契約やプ ロトタイピ 設計や先 残業や増 スピリチュ ロセス、計 行テストでの選択肢 画で対策 ングで対 対策   員で対策   アル系で   策   対策 要求分析 設計 実装 テスト ふつうのWF リリース 後工程に行くほど   問題対応の選択肢が少なくなる
  15. 15. フロントローディング開発へ 問題 対応 問題 問題 問題 問題 対応 対応 対応 対応 問題 対応 要求分析 設計 実装 テスト 問題 問題 対応 対応 ふつうのWF リリース
  16. 16. フロントローディング開発へ 予測して、予防・軽減・備 えを検討する 問題 対応 問題 問題 問題 問題 対応 対応 対応 対応 問題 対応 要求分析 設計 実装 テスト 問題 問題 対応 対応 ふつうのWF リリース
  17. 17. フロントローディング開発へ 前倒しで対策しダメージを軽減する 問題 対応 問題 問題 問題 対応 問題 対応 対応 問題 対応 対応 要求分析 設計 実装 テスト ふつうのWF リリース 課題山積&打つ手なしの状態を回避し、  フロントローディング開発に移行するための   基盤の一つがリスクマネジメント
  18. 18. リスクマネジメントの流れ
  19. 19. リスクマネジメントの流れ リスクマネジメントプロセス 計画 リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  
  20. 20. リスクマネジメントの流れ リスクマネジメントプロセス 計画 リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ   開発プロセスから独立したプロセス 開発プロセス 要求   計画   …   …   テスト   分析  
  21. 21. リスクマネジメントの流れ リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  開発初期からはじめる 開発プロセス 要求   計画   …   …   テスト   分析  
  22. 22. リスクマネジメントの流れ リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ   五月雨式に運用 継続的にリスクを監視 開発プロセス 要求   計画   …   …   テスト   分析  
  23. 23. リスクマネジメントの進め方 リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  
  24. 24. リスクの識別 •  リスクを収集して、管理すべきリスクを特定し ます   –  いろいろな手法があります。   –  今回は代表的なものを紹介します
  25. 25. [リスク収集の分析手段]   リスク識別分類の活用 •  Ex)SEIのリスク要因分類   –  要件   •  安定性   •  …   –  設計   •  インターフェース   •  …   –  開発プロセス   •  公式度   •  …  
  26. 26. [リスク収集の分析手段]   リスク識別分類の活用 リスクモデルやリスク分類を観点に•  Ex)SEIのリスク要因分類   リスクをピックアップします –  要件   •  安定性   •  …   –  設計   マインドマップ •  インターフェース   •  …   公式度 –  開発プロセス   開発プロセス 運用コスト 適合度 •  公式度   プロジェクトリス が重い ク •  …   新編成のテスト 体制 管理   プロジェクト組織 プロセス アウトソースが中 心 リスクブレークダウンストラクチャ
  27. 27. [リスクの収集手段]   リスク分析の観点を加えたレビュー •  成果物のレビューに、リスク識別の観点を加 えます  開発プロセス成果物 設計   テスト仕様 計画書   要求書   …   仕様書   書   誤った要求定義 誤った要求定義 … … … … … … … … … … … … … リスクは ないか?
  28. 28. [リスクの収集手段]     タイムライン分析 •  対象を時系列のフローに分解。   フェーズごとにリスク要因や問題可能性がな いか分析します   要求分析 基本設計 詳細設計 実装 誤った要求定義 … … … … … … … … … … …
  29. 29. [リスクの収集手段]     構成要素分析 •  対象を構成要素に分解し、構成要素ごとにリ スク要因や問題可能性がないか分析します テスタビリティの システム 低さ … 基板A 基板B … CPU ASIC DSP 【分析対象例】   ・システム構成   ・WBS   ・組織   ・手順  
  30. 30. [リスクの収集手段]     ふりかえりやミーティング •  ブレインストーミング、KPT、KJ法、なぜなぜ分 析など、一般的な振り返り手法・課題分析手 法も有効です。  •  リスクの収集は定期的・継続的に行うべきも のです。定例会などに収集や分析の機会を 組み込むと効果的です。  
  31. 31. リスクマネジメントの進め方 リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  
  32. 32. リスクの分析 •  抽出したリスクは一般的にリスク管理表で管 理します リスク 対応手段 対応状況 リスク   リスク要因 リスク内容 移行基準 リスク   対応手段 軽減後の   対応状況 カテゴリ 重大度 重大度 あくまで例です。色々なバリエーションがあります
  33. 33. リスクの分析 •  リスクカテゴリ   –  FMEAにおける故障モード   –  過去の蓄積の分析結果やリスクモデルを元に設 定します   –  うまく定義することでリスクの分析や管理が容易 になります リスク リスク   リスク要因 リスク内容 移行基準 リスク   カテゴリ 重大度
  34. 34. リスクの分析 •  リスクの原因   –  リスクを引き起こす要因  •  リスクの内容   –  リスクの内容  •  移行基準   –  リスクの可能性が問題に具現化する基準 リスク リスク   リスク要因 リスク内容 移行基準 リスク   カテゴリ 重大度 あくまで例です。色々な書き方があります
  35. 35. リスクの抽出と分類 リスク リスク要因 リスク内容 移行基準 リスク   重大度 開発工程でのバ 手戻り工数が増大 バグに起因し A グ見逃しが常態 し、リリース遅延を た2回以上の化 発生させる 手戻り発生
  36. 36. リスクの重大度評価 •  リスク重大度は定量的に評価します   –  定量的な優先付けや選択が可能になります  •  一般的な手法:   –  リスクマトリクス   –  重みづけ   重み付け リスク リスク重大度 リスク   リスク要 リスク内 移行基 ダメージ 発生   回避性 リスク   カテゴリ 因 容 準 可能性 重大度 5 5 1 25
  37. 37. テストエンジニアによる   リスクの収集 •  担当を超えて、プロジェクト全体に対するリスク を洗い出しましょう。クリティカルなリスクも考えま しょう  •  継続的に行いましょう  •  リスク分析のインプット情報確保のために、なる べく早いタイミングからプロジェクトのタスクを担 当しましょう   –  例えば   •  ドキュメントレビュー   •  テスト設計の前倒し   •  テスト実施の前倒し  
  38. 38. リスク分析の運用 •  最初からリスクを完璧に識別するのは不可能です   リスク識別・分析は定期的・継続的に行いましょう   –  リスクのインプット情報:   •  プロジェクトが進展するほど豊富かつ具体的になってきます   •  プロジェクトが進展するほど変化していきます    •  継続していれば、間違いや予期せぬ変化が発生し ても正常状態に復帰できます  
  39. 39. リスクマネジメントの進め方 リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  
  40. 40. リスク対応の検討 リスク 対応手段 対応状況 問題事象 リスク要因 リスク内容 移行基準 リスク   対応手段 軽減度の   対応状況 重大度 リスク重大度
  41. 41. リスク対応の検討 •  リスクが明確化されたら、その重大度を目標 レベルに下げる対応策を検討します。   リスク 対応手段 リスク要因 リスク内容 移行基準 リスク   対応手段 軽減後の   重大度 重大度 開発工程でのバ 手戻り工数が増大 2回以上の A ・スモークテストを作成。それに合 B グ見逃しが常態 し、リリース遅延を 手戻り発生 格してからテスト工程に移行する  化 発生させる ・実装工程中、前倒しで単機能テ ストを実施する
  42. 42. リスク対応の検討 •  リスク対応のアプローチ   – 回避/予防/軽減/移転  •  例「機能Aが複雑であり、バグ見逃しが発生 する可能性がある」   –  回避:「機能Aを削除する」   –  予防:「機能Aを開発者レベルで詳細に検証しておく」   –  軽減:「機能Aのテストの組み合わせを増やす」   –  移転:「機能Aはバグリスクがあるとお客様から了解を得 る」
  43. 43. リスク対応の検討 •  必要であれば、リスクやリスク対応手段を見 定めるための調査のアクションも管理します  •  最初から完璧な分析を行うのではなく、継続 的に分析の精度を高めていきましょう   対応手段 対応手段 軽減度の   リスク管理のアクション リスク重大度 モジュールAのてスタビリティを評 価する システムBのスケジュール遅延を 監視する
  44. 44. リスク対応の実施とフォローアップ •  リスク管理は継続的に保守し、適切にリスク 対策が行われているか監視していきます リスク 対応手段 対応状況 問題事象 リスク要因 リスク内容 移行基準 リスク   対応手段 その他作業 対応状況 重大度 リスク移行 なし 予防策実施 済み
  45. 45. テストエンジニアによるリスク対応 •  困難な場合が少なくありません。   それでも対応検討を行い、”お客様”に提案し ましょう   –  プロジェクトの脅威を可視化できます   –  プロジェクトの改善策を可視化できます  •  開発初期からプロジェクトに関わりましょう   –  ドキュメントレビュー/テスト設計・実施の前倒し等   –  リスクの情報収集ができます。リスク対応の担当 者にもなれます  
  46. 46. テストエンジニアによるリスク対応 •  対応を実施できなくとも、分析結果を共有するだけ でも価値はあります。  •  継続して改善していけば説得力も増していきます ●仕様変更があったので遅 ●この仕様変更があると✕✕のれました   遅延リスクがあります  ●納期短縮があったためバ ●納期短縮すると重大度○○のリグが流出しました   スクが残留することになります  
  47. 47. さいごに •  テストエンジニアは数多くのプロジェクトリスクに 晒されています。  •  何も考えずにいけば、山のような問題やトラブル に巻き込まれ責務すら果たせなくなります  •  これを緩和しプロジェクトを成功に導くためには、 フロントローディング開発への移行が重要です  •  その基礎でありはじめの第一歩の手段となりえ るのがリスクマネジメントです  
  48. 48. おまけ
  49. 49. 大人のマネジメントと   子供のマネジメント •  子供のマネジメント –  親の庇護の元で狭い世界と向き合う   •  「宿題めんどい!学校うざい!」   •  「自由に遊びたいのに親がうるさい!」   •  「小遣い少ない!親がけち!」 •  大人のマネジメント –  社会と向き合う   •  「将来を考えて勉強させないと」   •  「事故や重大犯罪から守らないと」   •  「病気や失職を考えないと」  
  50. 50. 大人のマネジメントと   子供のマネジメント •  子供のマネジメント –  親の庇護の元で狭い世界と向き合う   •  「宿題めんどい!学校うざい!」   •  「自由に遊びたいのに親がうるさい!」   •  「小遣い少ない!親がけち!」 •  大人のマネジメント –  社会と向き合う   •  「将来を考えて勉強させないと」   •  「事故や重大犯罪から守らないと」   •  「病気や失職を考えないと」  •  違いを生んでいるのがリスクマネジメントの規模
  51. 51. 大人のマネジメントと   子供のマネジメント •  子供のマネジメント –  担当の壁の中で狭い世界と向き合う   •  「単純バグ多すぎ!開発者はバカ!」   •  「要求変更が多すぎ!ぐれてやる!」 •  大人のマネジメント –  プロジェクトと向き合う   •  「単純バグ多すぎ!スモークテストを実施しよう」   •  「要求変更が多すぎ!プロトタイピングを提案しよう」  
  52. 52. 大人のマネジメントと   子供のマネジメント •  子供のマネジメント –  担当の壁の中で狭い世界と向き合う   •  「単純バグ多すぎ!開発者はバカ!」   •  「要求変更が多すぎ!ぐれてやる!」 •  大人のマネジメント –  プロジェクトと向き合う   •  「単純バグ多すぎ!スモークテストを実施しよう」   •  「要求変更が多すぎ!プロトタイピングを提案しよう」  •  違いを生んでいるのがリスクマネジメントの規模 •  リスクマネジメントをこなして大人のテストエンジニア になりましょう!
  53. 53. ご清聴ありがとうございました

×