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

Bug が直るまで～メーカサイド～

2013年5月17日ミドクラジャパン株式会社

高嶋隆一 ^55393_21948_18149_2516_4716$

Copyright ©2013 Midokura All rights reserved

本日のアジェンダ

2

u 本日の目的 u Bug修正の流れ u 現場のSEの苦悩

本日の目的

3


本日の目的

この間申告した Bug まだ直ってないんだけど?

何で!? 4

ココを考えてみる

申し訳ございません、本件に関しましては n  1年後のメジャーバージョンアップで修正する事になりました

n ハードウェア上の制限という事になり、特に修正を行わない事になりました

n お客様以外での事例がなく、再現も不可能の為不具合と認められませんでした

Bug修正の流れ

5


障害申告窓口へ連絡

どうやってトラブル申告をしているか?

6

Case 1

担当営業、SEに連絡 Case 2


【前提知識】よくあるメーカの組織構成

7

Sales

TAC

Product

Engineering l  Development (新規追加開発) l  Sustaining (既存修正) l  Quality Assurance (品質管理)

l  Technical Assistance (受付)

l  Product Manager (製品仕様)

l  Sales Representative (営業) l  Systems Engineer (SE)

部門機能客先SEは営業部門

受付と直す部門は別

ポイント

仕様決定と開発・修正部門も別


Case1.障害申告窓口へ連絡時の役割

8

TAC Eng. Product End user

エスカレーションの流れ

優先度決定

役割

既知問題調査

再現試験詳細調査

問題修正

問題申告

仕様影響検討

仕様修正


Case1. ややこしい場合

9

優先度の認識が合わない

障害なんだから最優先で直して!

通常、メーカサイドでは「全断継続中 > 間欠的断継続> その他不具合」程度の優先度の段階分け

殆どのケースは「その他不具合」に相当



10

優先度の認識が合わない

Photo Credit: sambrown92 via Compfight cc

営業エスカレーション解オプションサービスの購入

Photo Credit: Steve Wilson via Compfight cc



11

修正タイミングがあわない

何で次の次のパッチで修正なの!? 次で直してよ!

リリース時の QA (品質保証) 試験は、最低数日から一週間程度かかり、不具合がでると修正後最初からやり直し項目が追加になると試験項目の追加も必要に

リリース間隔にもよるが、通常は一ヶ月は最低必要



12

修正の影響が大きい

メジャーバージョンアップを待てってどういうこと?

l  OSの機能全体へ修正が波及する様な修正 l  FPGAのコードが必要になる様な修正等については、デグレの危険が大きい為、メジャーリリースサイクルを待つしかないケースも…



13

修正タイミングがあわない

Photo Credit: ryoichi360 via Compfight cc

本当に致命的な不具合の場合は緊急パッチを検討顧客専用パッチ作成も可能 (後の混乱を招くので非推奨) 解

修正の影響が大きい＆



14

情報が少ない

サービスがとまったっていったでしょ? え、障害解析ログ!? とにかく止まったのよ!

再現試験や詳細解析を進めるには、 l 障害ログ (show techの類) l 時系列の作業ログ l 周辺機器の状況や時系列のログは最低必要。複雑な障害であればあるほど、状況を特定する情報が必要となる



15

情報が少ない

Photo Credit: Mr. Fibble via Compfight ccc

障害発生時にはサービス継続との兼ね合いを考慮しながら、可能な限り多くの情報を保存しておく解



16

再現しない

うちの機器で障害が起こったじゃない! 解析できないってどういうこと?

障害時の解析ログで問題が自明に分かるケース以外では、再現しない事には実はメーカでも解析の進めようがないその場合、コードレビュー等の手探りの解析となり、迷宮入りとなるケースも多い



17

再現しない

Photo Credit: Dan Gilbert via Compfight cc

障害環境の保存障害ログの保存解リモート接続の提供

Photo Credit: Mr. Fibble via Compfight cc



18

直せない

申告した内容が直せないってどういう事!?

仕様しているハードウェアの不具合により修正が後から出来ないケース、該当機能を修正する事で他の機能や性能に著しく悪影響を与えるケースでは「制限事項 (リミテーション)」として製品仕様を修正するケースがある



19

直せない

Photo Credit: ryoichi360 via Compfight cc

担当営業、SE 土下座解



20

不具合ではなく機能拡張

○○対応って書いてあるんだから、 ××が実装されていないのおかしいでしょ!?

標準の解釈や、最初にその機能拡張を要求した顧客の要件によっては、あってしかるべき機能でも不具合ではなく「機能拡張要求」として扱われる場合があるその場合、通常メジャーリリース間隔を跨ぐ必要があるし、そもそも機能拡張が取り込まれるかどうかも…



21

相性問題

何で某社と繋がらないの!?

標準に解釈の余地が残されていたりすると、どちらも正しい実装をしているのに繋がらないこともある相手のほうがシェアが大きい場合にはデファクトスタンダードとして扱われ、自社側が不具合扱いされる場合も



22

不具合ではなく機能拡張

Photo Credit: Annika1982 via Compfight cc

事前検証解担当営業、SE を通じた

機能拡張要求

Photo Credit: AndyC_pics via Compfight cc

相性問題＆



23

機能影響が少ない不具合

簡単に直せそうな不具合なのに、いつまでたっても直らないじゃない!

簡単に直せるものでも、実サービスに影響がないものは、他の優先度の高いものに押されて、トコロテン式に先延ばしにされるケースも



24

機能影響が少ない不具合

Photo Credit: striatic via Compfight cc

実サービスに影響有と説得するだけのロジックを組み立てる解


Case2. 担当営業、SEに連絡

25

担当営業、SE Eng. Product End user

エスカレーションの流れ

役割

問題申告

TAC

Case1と同じ

仕様影響検討

仕様修正

内容判断不具合

機能拡張



26

大抵、ややこしい

障害受付に話してもラチがあかないのよ!

調査して折り返します。。。



27

担当営業、SEのお仕事

お客さんにかわり障害情報の情報整理を行い、TACやEngineering へのエスカレーションを行う

お客さんにかわり機能拡張の情報整理を行い、Product Manager へのエスカレーションを行う

如何にこのお客さんが大事か、状況がマズイかを TAC、Engineering, Product Manager に伝え、優先度を上げさせる

お客さんにかわり再現試験を行い、TAC や Engineering に証拠をつきつける

現場のSEの苦悩

28


要するに

29

THE 板挟み


それが仕事ではありますが

30

直接お客さんと話す部署だけに、見解が異なると厄介 TAC

直さないといけないロジックを詰めないと使い方がおかしい、といわれたり… Engineering

機能拡張を要求したら、当然売り上げ増を約束させられます… Product

あなたから買って、私が困ってるんだから何とかしてよ! とはいわれたらもう。。。お客さん

大変ですが、お客さんがいるからがんばってます! ギリギリ

31

Thank you!

Documents

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