古の情報共有プロジェクト - Qiita に続き、古（2010年頃）のトラブル解消フローを掘り起こし要約したもの。現在は使われていません。一方で、現在も参考になりそうなところのみ太字にしてあります。
- Q&Aを書こう
- 調べてから聞こう
- 人に教えてもらったら、判断の基準を聞いて次は自分でできるようにしよう
フローチャート:
- Step 1 - 情報収集・整頓する
- Step 2 - ヘルプを仰ぐ準備をする
- Step 3 - 具体的な調査をする
- Step 4 - ふりかえり・起票する
要点
問題の範囲の確認
- 全体的な問題（Version Upやパッチ適用の際に発生）か
- サブシステム独自の問題か、他にも発生しうる問題か
- あるユーザーや端末だけの問題か（設定を確認）
- ユーザーの環境（H/W、M/W）に特別な状況はないか
問題が起こった範囲を確認します。
ある特定の処理に関する問題でしょうか？ある特定のサブだけに関する問題でしょうか？
ある特定のデータに関する問題でしょうか？ある特定の端末で操作したときだけに起こる問題でしょうか？問題が自分が担当している以外にも及ぶ場合、影響が大きいので優先順位が上がります。
独自の問題ではなく、他にも影響があったり現象が発生する問題である場合、その担当者にこういう問題があったと周知しておくことが必要です。
特定のユーザーや特定の端末だけで起こる問題であり、他の端末で操作してもらうなどの回避策がある場合、優先順位を下げてもいいでしょう。
ユーザーのフェーズはどういう状況にあるか
- 導入初期
- 稼働直前
- 個別の対応が必要かどうか
導入状況を把握します。
導入の初期で機能の仕様を確認しているのか、稼働直前でこの問題が導入スケジュールに致命的な影響を与えるのか、本稼動中でこの問題が解決しないと振込みに間に合わないのか。
それぞれで緊急度合は変わります。
問い合わせのステータスはどういうものか
ステータスを確認しましょう。
重要度・緊急度はどうなっているのか。
ステータスを考慮した優先順位をつけましょう。
調査材料は足りているか
ユーザーからの問い合わせの場合、調査に必要な根拠（データやログ）は不足していることがほとんどです。
そのため、調査を進めるために何が必要なのかを考える必要があります。
そして、そのやり取りはなるべく手間をかけず、少ないやり取りで、必要最小限のデータを頂くようにしましょう。
問い合わせの根拠を確認
- ユーザーがどの画面を見て問い合わせしてきているかを推測する。
- 画面表示だけの問題かどうかで切り分ける
「どこ」で「何が」起きたから問題だという問い合わせが来ているのでしょうか？
ユーザーが何を根拠に判断したのか、その判断と根拠のデータは正しいのかをチェックする必要があります。
処理で結果が違うのであればその根拠となる設定はどうなっているでしょうか？
CSV取り込みを行った結果が意図どおりで無いのであれば、その根拠となるCSVデータはどうなっているでしょうか？
ユーザーの言うことを鵜呑みにせずに調査材料として確認する必要があります。
問題の発生箇所はどこか
- エラーの種類を判別できる手がかりを探す
- ログやスクリーンショットを依頼したジョブや画面は正しいか
- ログの取得方法
- サブ独自のログは存在しているか
- SYSTEMOUTなどログのありかを明記
ログが出る処理では、問題が起こった時のログを頂きましょう。
ログを取得していただく場合、どこでどう取得すればいいのかを伝えましょう。
通常の手段で取得できるログで問題解決が進まない場合、より詳細なログを頂く必要があります。
EXEであれば別途調査用のEXEを作成し操作していただかなくてはなりませんし、バッチ処理ではデバッグログを頂く必要があります。
ログを依頼する心構え
- ユーザーにとっても負担になる、ということを意識する
- そのログで何を知ろうとしているのかを改めて考える
- そのログだと何がわからないかを考える
ログの取得をお願いするに当たって、開発者が心に留めておかなくてはいけない点があります。
お客様にとって、それは問題解決の手段であり本来であれば必要の無い行動だということです。
ですので、無駄なやり取りはなるべく避けなくてはなりません。
ログの取得依頼をする前に、問題の解決に本当に必要か一度考えましょう。
ログの依頼方法
- 膨大なログにならないか
- 再現しない状況のものを依頼していないか
- ログの取得はユーザーでも可能か、いつまでにログが欲しいのか
ログ取得を依頼する際には、いくつか気をつけなくてはいけない点があります。
膨大なログにならないでしょうか？
サーバー容量を圧迫するような容量になりませんか？
再現しない状況のものを依頼していませんか？
前提となる処理状況は正しいですか？特定の処理を回した後などの条件は無いですか？
条件がある場合、ちゃんと指定していますか？
処理対象のデータは再現するデータですか？
事後のケア
デバッグモードのログを取得した場合、デバッグモードから元に戻す手順も連絡する必要があります。
ログ自体が大量である場合、サーバーの容量を逼迫するのでログ削除の案内もしておきましょう。
具体的な調査に着手する
- そもそも…を考える
- この調査により何を知ろうとしているのか？
- 調査そのものが目的になっていないか→何を優先させるかを考える
調査にのめりこんでしまう前に、目的を明らかにしましょう。
いつのまにか手段が目的とすりかわってしまうことはままあります。
そもそも、この調査で何を知りたいのでしょうか？
例えば、「ある処理で異常終了になった」という問い合わせが来たとします。
しかも、本日中に振込みを行わなければならない、この処理が終わらねば振込みができないという状況です。
異常終了の原因を調査するのも一つの方法です。
ですが期限が迫っている以上、「振込みを行う」ことに注力すべきです。
取込で値を調整すれば乗り切れるのであれば、それも問題解決の一方法です。
もちろん異常終了した原因は調査しなければなりませんが代替案があるのであれば
必ずしも今日やらなくてはならないことではないはずです。
今日やらなくてはならないのは「振込みを行う」こと。
そして、後ほど異常終了の原因を調査し、取り込みで調整した値のケアを行うのです。
今やろうとしている調査の、期限とゴールはなんですか？
ナレッジの検索、確認
- 過去に同様の問題があったか確認
- マニュアルの確認
まずは、ナレッジの検索を行いましょう。
過去に同じような問題は起こっていないか、起こっていれば今回と同じではないか？
時間を作ってQ&Aを増やし、キーワード検索で引っかかりやすいように書きましょう。
お客様に提供しているマニュアルも活用しましょう。
それぞれ独自に資料を作っている場合があります。
ミドルウェアの情報はネットや書籍でも調べることができます。
処理に時間がかかっている場合
- 同時に同じテーブルにアクセスしようとして待ちが発生していないか？
- 無駄にSQLを発行していないか？
- 設定が適切であるか
- 同時に同じテーブルにアクセスしようとして待ちが発生していないか？ デッドロックという状態です。
- 無駄にSQLを発行していないか？
- 統計情報が適切か？
- 統計情報の取得状況によっては同じデータに対する同じSQLであっても速度がまったく違うということがありえます。
- 設定が適切であるか？
- 開発想定外の無駄な設定があると動作が遅い場合があります。
- サーバーの容量が満杯なのでは？この場合処理が進まなくなります。
データだけ、ソースを読んだだけで結論を出すのはいけません。
ちゃんと社内環境でデータを作成して、プログラムを動かして検証をしましょう。
その際、お客様環境のバージョンを確認する必要があります。
返答の際のコツ
- 問題が解決した場合
- 何が問題だったのかを明確に伝える
- 設定の問題なのか、不具合なのか
- 不具合の場合には回避策はあるのか
- 不具合の場合には恒久的な対応はどうするつもりなのか
- 何が問題だったのかを明確に伝える
問題が解決した場合、まず必要なのが何が問題であったのかを明確に伝えることです。
お客様に仕様が伝わっていなかったのか、環境の一時的な問題なのか、設定の問題なのか不具合なのか。
プログラムの不具合であった場合は、内容に加えて今後どのようにするのか恒久的な対応方針を伝える必要があります。また、不具合によって運用が止まる場合には回避策を考える必要があります。
問題が解決しない場合
- 解決しない場合でも回答期限前に一報を入れる
- 他に調査材料が必要な場合 ⇒ 調査材料のフローに戻る
問題が解決しない場合であっても、回答期限前に進捗報告を行いましょう。
調査は進んでいるのか止まっているのか、調査に必要な情報が足りていないのか？
必要に応じて追加のデータ取得、ログ取得をお願いしてください
開発環境で状況が再現した場合、不具合か否かを決める前に判断が必要です。
修正してしまって良いかどうかがまずは問題になります。
不具合によって動作が変わるのであれば、
今までの動作を前提に運用をしているお客様がいる可能性があります。
その場合、オプションをつけて機能追加で対応すべきです。
また、影響範囲が大きすぎる場合、バージョンアップで修正するべき内容となることもあります。
単独の処理では不具合の動作であるが関連する処理でリカバリーをするように
動いている場合もあり、回避策が取れる場合もあります。
なぜ今まで問い合わせがなかったのかを考えてみることも重要です。
良く使われる機能なのに初めて不具合が発覚したという場合
実は使われていなかったのか、それとも設定によって不具合が起こらないのか。
特定のユーザーのみでしか発生しないという場合、特別なプログラムが動いている可能性もあります。
以上、10年以上前の文献です。マインド的には変わらないところもあり面白いななど。ということで話半分でお楽しみいただければ幸いです。