20130517 What's done in venders' bug fix process ?
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

20130517 What's done in venders' bug fix process ?

on

  • 1,180 views

drstudy 2013

drstudy 2013

Statistics

Views

Total Views
1,180
Views on SlideShare
1,168
Embed Views
12

Actions

Likes
4
Downloads
8
Comments
4

1 Embed 12

https://twitter.com 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

20130517 What's done in venders' bug fix process ? Presentation Transcript

  • 1. Bug が直るまで∼メーカサイド∼2013年5月17日ミドクラジャパン株式会社高嶋隆一^55393_21948_18149_2516_4716$
  • 2. Copyright ©2013 Midokura All rights reserved本日のアジェンダ2u 本日の目的u Bug修正の流れu 現場のSEの苦悩
  • 3. 本日の目的3
  • 4. Copyright ©2013 Midokura All rights reserved本日の目的この間申告した Bug まだ直ってないんだけど?何で!?4ココを考えてみる申し訳ございません、本件に関しましてはn  1年後のメジャーバージョンアップで修正する事になりましたn  ハードウェア上の制限という事になり、特に修正を行わない事になりましたn  お客様以外での事例がなく、再現も不可能の為不具合と認められませんでした
  • 5. Bug修正の流れ5
  • 6. Copyright ©2013 Midokura All rights reserved障害申告窓口へ連絡どうやってトラブル申告をしているか?6Case 1担当営業、SEに連絡Case 2
  • 7. Copyright ©2013 Midokura All rights reserved【前提知識】よくあるメーカの組織構成7SalesTACProductEngineeringl  Development (新規追加開発)l  Sustaining (既存修正)l  Quality Assurance (品質管理)l  Technical Assistance (受付)l  Product Manager (製品仕様)l  Sales Representative (営業)l  Systems Engineer (SE)部門 機能客先SEは 営業部門受付と 直す部門は別ポイント仕様決定と 開発・修正 部門も別
  • 8. Copyright ©2013 Midokura All rights reservedCase1.障害申告窓口へ連絡時の役割8TAC Eng. ProductEnd userエスカレーションの流れ優先度決定役割既知問題調査再現試験 詳細調査問題修正問題申告仕様影響検討仕様修正
  • 9. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合9優先度の認識が合わない障害なんだから最優先で直して!通常、メーカサイドでは「全断継続中 > 間欠的断継続> その他不具合」程度の優先度の段階分け殆どのケースは「その他不具合」に相当
  • 10. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合10優先度の認識が合わないPhoto Credit: sambrown92 via Compfight cc 営業エスカレーション解 オプションサービスの購入Photo Credit: Steve Wilson via Compfight cc
  • 11. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合11修正タイミングがあわない何で次の次のパッチで修正なの!?次で直してよ!リリース時の QA (品質保証) 試験は、最低数日から一週間程度かかり、不具合がでると修正後最初からやり直し項目が追加になると試験項目の追加も必要にリリース間隔にもよるが、通常は一ヶ月は最低必要
  • 12. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合12修正の影響が大きいメジャーバージョンアップを待てってどういうこと?l  OSの機能全体へ修正が波及する様な修正l  FPGAのコードが必要になる様な修正等については、デグレの危険が大きい為、メジャーリリースサイクルを待つしかないケースも…
  • 13. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合13修正タイミングがあわないPhoto Credit: ryoichi360 via Compfight cc 本当に致命的な不具合の場合は緊急パッチを検討顧客専用パッチ作成も可能 (後の混乱を招くので非推奨)解修正の影響が大きい&
  • 14. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合14情報が少ないサービスがとまったっていったでしょ? え、障害解析ログ!?とにかく止まったのよ!再現試験や詳細解析を進めるには、l  障害ログ (show techの類)l  時系列の作業ログl  周辺機器の状況や時系列のログは最低必要。複雑な障害であればあるほど、状況を特定する情報が必要となる
  • 15. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合15情報が少ないPhoto Credit: Mr. Fibble via Compfight ccc 障害発生時にはサービス継続との兼ね合いを考慮しながら、可能な限り多くの情報を保存しておく解
  • 16. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合16再現しないうちの機器で障害が起こったじゃない! 解析できないってどういうこと?障害時の解析ログで問題が自明に分かるケース以外では、再現しない事には実はメーカでも解析の進めようがないその場合、コードレビュー等の手探りの解析となり、迷宮入りとなるケースも多い
  • 17. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合17再現しないPhoto Credit: Dan Gilbert via Compfight cc 障害環境の保存障害ログの保存解 リモート接続の提供Photo Credit: Mr. Fibble via Compfight cc
  • 18. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合18直せない申告した内容が直せないってどういう事!?仕様しているハードウェアの不具合により修正が後から出来ないケース、該当機能を修正する事で他の機能や性能に著しく悪影響を与えるケースでは「制限事項 (リミテーション)」として製品仕様を修正するケースがある
  • 19. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合19直せないPhoto Credit: ryoichi360 via Compfight cc 担当営業、SE 土下座解
  • 20. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合20不具合ではなく機能拡張○○対応って書いてあるんだから、××が実装されていないのおかしいでしょ!?標準の解釈や、最初にその機能拡張を要求した顧客の要件によっては、あってしかるべき機能でも不具合ではなく「機能拡張要求」として扱われる場合があるその場合、通常メジャーリリース間隔を跨ぐ必要があるし、そもそも機能拡張が取り込まれるかどうかも…
  • 21. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合21相性問題何で某社と繋がらないの!?標準に解釈の余地が残されていたりすると、どちらも正しい実装をしているのに繋がらないこともある相手のほうがシェアが大きい場合にはデファクトスタンダードとして扱われ、自社側が不具合扱いされる場合も
  • 22. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合22不具合ではなく機能拡張Photo Credit: Annika1982 via Compfight cc 事前検証解担当営業、SE を通じた機能拡張要求Photo Credit: AndyC_pics via Compfight cc 相性問題&
  • 23. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合23機能影響が少ない不具合簡単に直せそうな不具合なのに、いつまでたっても直らないじゃない!簡単に直せるものでも、実サービスに影響がないものは、他の優先度の高いものに押されて、トコロテン式に先延ばしにされるケースも
  • 24. Copyright ©2013 Midokura All rights reservedCase1. ややこしい場合24機能影響が少ない不具合Photo Credit: striatic via Compfight cc 実サービスに影響有と説得するだけのロジックを組み立てる解
  • 25. Copyright ©2013 Midokura All rights reservedCase2. 担当営業、SEに連絡25担当営業、SE Eng. ProductEnd userエスカレーションの流れ役割問題申告TACCase1と同じ仕様影響検討仕様修正内容判断不具合機能拡張
  • 26. Copyright ©2013 Midokura All rights reservedCase2. ややこしい場合26大抵、ややこしい障害受付に話してもラチがあかないのよ!調査して折り返します。。。
  • 27. Copyright ©2013 Midokura All rights reservedCase2. ややこしい場合27担当営業、SEのお仕事お客さんにかわり障害情報の情報整理を行い、TACやEngineering へのエスカレーションを行うお客さんにかわり機能拡張の情報整理を行い、ProductManager へのエスカレーションを行う如何にこのお客さんが大事か、状況がマズイかを TAC、Engineering, Product Manager に伝え、優先度を上げさせるお客さんにかわり再現試験を行い、TAC や Engineering に証拠をつきつける
  • 28. 現場のSEの苦悩28
  • 29. Copyright ©2013 Midokura All rights reserved要するに29THE 板挟み
  • 30. Copyright ©2013 Midokura All rights reservedそれが仕事ではありますが30直接お客さんと話す部署だけに、見解が異なると厄介TAC直さないといけないロジックを詰めないと使い方がおかしい、といわれたり…Engineering機能拡張を要求したら、当然売り上げ増を約束させられます…Productあなたから買って、私が困ってるんだから何とかしてよ! とはいわれたらもう。。。お客さん大変ですが、お客さんがいるからがんばってます!ギリギリ
  • 31. 31Thank you!