私は10年以上、手を動かすエンジニアとして仕事をしてましたが、直近ではPL補佐みたいな立場で上長と共に、大規模SaaSの保守・障害対応をしてます。
自分で直接なおすわけではないため、技術的なスキルよりは、コミュニケーション能力や問題解決能力が求められます。その部分で大事だと思ったことなどをまとめておこうと思います。
不具合の対応におけるポイント
1 ユーザーや営業からのヒアリング
2 開発者側への伝達
3 実際の対応
1 ユーザーや営業からのヒアリング
観察しろというのは……
見るんじゃあなくて観ることだ…
聞くんじゃあなく聴くことだ
えージョジョネタをかましたところで、言いたかったのは「ヒアリングの大切さ」です。
今回の仕事に就く前は「不具合のヒアリングなんて簡単でしょ」と思っていたのですが、実際は全く簡単ではありませんでした・・・。
というのも
- システムが業務用のかなり複雑なものでそもそもユーザーや営業自体が不具合の状況をうまく伝えきれていないことが多い
- 営業からの報告は「特定の伝票が保存できません」といった漠然とした内容が多く、かつ間違っていることも多々ある
- 不具合ではなく、設定ミスや前提条件の共有不足
- 不具合であることがわかっても、再現度が100%でないため、開発環境で再現できないことも多い
上位背景の把握
そもそもなんですが、ユーザーの目的は何か？何をしようとして、そしてどうしたいのか？といった背景を「聴く」ことが大切です。
- ユーザーの状況理解: ユーザーの動作を思い浮かべる。具体的な業務の動きを頭の中にイメージする
- 根本的な解決方法の模索: 単に言われたことではなく、ユーザーが真に実行したいことは何か？他の方法はないか？もっと簡単な方法があるのではないか？
問題解決の基本姿勢
質問に対して直線的に答えてしまうと、それがユーザーにとっての正しい答えとはならないんですよね・・・。
これ新規開発の要件定義とかもそうなんですが、自分の要望を言語化するのって非常に難しいので、「こうしてください」をそのまま実行するとやっぱり違うんで・・・のようなやりとりのラリーが必要になり、お互いに疲弊してしまいます。
そのためにも以下のような視点でのヒアリングが必要になってきます。
- 背景理解: 操作の背景（どのような業務フローの中でそれが起こったのか、お客さんは何をしようとしたのか、見逃されている前提条件はないか）
- 操作の特定: システムのどの箇所でどの操作をしたときに起こったのか
- 特定情報: 伝票番号やエラーメッセージなど不具合を特定できる情報があるか
- 再現性: 不具合であれば開発環境などで再現できるか
2 開発者側への伝達
次のステップとしては開発者に伝えて対応してもらう段階です。
不具合を修正する、というのは単純なものだったら極論、営業と開発サイドでのやりとりだけでもよいのですが、
情報をうまく翻訳、整理してあげることでプロジェクト推進がスムーズになります。
そのために開発者には以下のような視点を伝えて不具合の修正をお願いしております。
技術的情報の整理
- 背景情報: そもそもユーザーは何をしようとした時にそれが起こったのか
- 前提情報: 不具合が起きる場合の基本的な前提情報（設定やデータなど）
- システム情報: ログなどシステム的な情報が取得できるか
- 視覚的資料: 再現できる場合はスクリーンショット付き、動画があればベスト
- 優先度: 緊急度のレベル設定
- 関連情報: 関連する他の不具合やその他の情報
- 期待値: どうして欲しいのか、何をもって修正されたといえるのか(そもそも開発側で再現できないものもある)
- スコープの検討: その箇所のみで収まるものなのか、他の設定全体に影響を及ぼすものなのか
3 実際の対応
実際に対応する(正確には対応してもらう)フェーズですが、直すまでに時間がかかったり、緊急度が高い場合はすぐになおすことだけではなく、一時的に不具合がでないようにし、そのあと恒久的な対応をするなどの対処が有効な時もあります。
またなおすのではなく、別の代替手段で一時的に回避してもらったり、あるいはそもそも発現率が非常に低くコストに見合わない場合、無視する、といったケースも考えられます。
- プログラム修正: 根本的なコード修正(基本的にはこの方針)
- データメンテナンス: 緊急度が高い場合、一時的にデータを修正し、その後恒久対応もあり
- 代替手段: 修正コストに見合わない場合、別の方法を検討することも（確率が非常に低く修正コストが高い場合は無視も選択肢）
修正記録として残しておきたいもの
エンジニアに実際に直してもらう場合、以下のような記録や情報があると後で見返した時に何をやっているかが追いやすいです。
- 修正フロー: 実際の修正内容（PRとエビデンス、デグレード確認含む）
- 仕様に関する質疑: 仕様などで疑問におもったことや解消したこと
- 所要時間: 作業にかかった時間の記録
- 影響度: 他システムや機能への影響有無
- 根本原因: 発生原因の分類（設計不備、プログラム原因、検知すべき工程の問題など）