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