Your SlideShare is downloading. ×
  • Like
テストエンジニアへのリスクマネジメントのすすめ
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 2,968 views
Published

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

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,968
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
20
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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