Synergy! プロダクト開発業務において、開発と保守・運用は、同じメンバーが対応しています。分かれてる会社もあると思いますが、弊社ではサブシステム単位で担当グループが決まっており、開発しながら保守・運用を行っています。 お客様からの問い合わせで、不具合ではないか？と思われることもあります。 今回は、保守・運用の中でも大事な問い合わせ調査についてまとめてみようと思います。
田渕 陽子（タブチ ヨウコ）お問い合わせ発生！！
弊社ではサポートを行う部署があります。ほとんどの問い合わせについては、サポートのメンバーがお客様とやり取りを行い、解決しています。ただ、サポートでは判断できない事象や不具合と思われる事象については、最終的に開発まで調査が回ってきます。問い合わせがあった場合は、開発中であったとしても、手を止めて、問い合わせ調査を最優先で進めることにしています。
まずは、問い合わせの状況を確認する
お客様の問い合わせの内容を確認します。
- 通常ならボタンが押下できるがなぜか押下不可状態となっている
- ページ遷移のレスポンスが遅く、業務を進めづらい状況になっている
- データを抽出しようとするとシステムエラー画面が表示され、実行できないなどなど
次に、お客様が想定している操作を行い、正常に操作できるかを確認します。 問い合わせ内容と同じ状態になるようでしたら、その操作を元に調査できますが、異なるようでしたら、お客様のデータを確認し、異なる点があるか？レコード数はどのくらいか？などを確認します。データベースの応答が遅い場合は、お客様のデータベースの状況を調査し、クエリの実行計画などを確認します。
状況の確認ができたら、再現環境を準備する
まずは、事象の解消ができないかを最優先で検討します。原因がすぐにわかれば原因の説明と事象の解消をすぐに行うのですが、原因追求に時間がかかる場合もあります。その場合は、事象を解消することを優先します。 そのためにも、再現環境を準備することは大事で、再現環境から事象を解消する手順を導き出します。
データの問題である場合は、同じ状況になるように設定を行います。通常の画面遷移で再現できない場合は、DB を直接書き換えて再現します。パフォーマンスに関する場合は、同程度のデータを準備して同様のパフォーマンスになるようにします。
再現環境から回避策を検証し、提示する
今起こってる事象を解消するための回避策を、再現環境上で検証します。 画面上の操作から回避できるようなら、それをお客様に試してもらい、業務に支障が出ないよう事象を解消してもらいます。 画面上の操作から解消できない場合、データを手動で更新して解消できるか？を再現環境で確認します。
パフォーマンスに関する場合は、explain などを実行して、index の付与などのチューニングを検証します。 回避策が見つかったら、お客様に提示して、事象を解消します。
引き続き原因の調査を行う
すぐに原因がわからない場合は、色々な観点から調査を行います。
- アクセスログから操作を推測する
- ある操作をした際にのみ引き起こされる事象、ということがあります。その場合、アクセスログから画面遷移を再現し、画面遷移によるデータの推移を確認して、再現環境と同じ状態にすることができるか検証します。
- 場合によっては、以前操作した内容によって、今回の事象が引き起こされる、といった場合もあるため、古いログの調査が必要な場合もあります。
- データから推測
- 特定の項目のデータに不整合が発生していた場合、その項目を更新するパターンを洗い出します。
- 更新している箇所が少なければ、その処理を通るパターンを洗い出してみて、どういった操作でその更新が実現できるかを検証します。
- プログラムから推測
- アプリログから原因を推測します。出力されるべきアプリログが出力されていない、などが読み取れる場合は、その処理の実行条件などに合致しないことが考えられます。その処理の条件になぜ合致しないのか？などをプログラムから読み解いていきます。
- 画面表示のレスポンスが遅い場合などは、無駄なループがないか？不必要に多重ループになっているところがないか？一か所に集約すれば処理時間を短縮することができないか？などを読み解きます。
- 並列アクセスに対応した作りになっているか？を確認します。単体テストなどでは発見できず、アクセスが集中して初めて露呈することもあります。スレッドセーフになっているか？並列数は問題ないか？データベースへの接続は並列数に対して適切に確保されているか？などを確認します。
プログラム改修の検討
原因が判明したら、プログラム改修が必要かどうかを検討します。 不具合であれば、もちろん修正してリリースを行いますが、不具合ではない場合でも、不正な画面操作などによってデータの不整合が起こる場合があれば、それを防ぐためのバリデーションを追加するといった対応を行います。
さいごに
毎回、問い合わせ内容は異なりますので、イレギュラーなこともあったりしますが、大体上記の内容を行っています。 そして、調査も大事ですが、依頼元にきちんと連絡することも同じくらい大事です。 不安で問い合わせしたものの、いつになっても回答が返ってこないと不安になるものです。 調査が長引いている場合は、長引きそうであること、また、問い合わせ当日の 17:00 くらいを目途に、現状わかっていることを必ず依頼元に報告するようにしています。
開発のメンバーは、お客様と直接やり取りをすることはないのですが、直接やり取りをする方々のことを考えて、必要な情報を的確に伝えることができるようになりたいものです！
