開発したシステムに問題が発生した！
顧客から、早急な対応を要望されているが、効率よく解決させるために何から手をつけて良いかわからない…
この記事では、上記の状況になった時にどのような方法で早急に解決に導くかを解説しています。
問題発生時のアクション
システム開発やパッケージ製品導入に長年携わっていると、システム運用開始後に問題が発生し、顧客からクレームが来ることは、残念ながら避けられません。設計工程でのレビューやテスト工程での実機テスト等、品質確保施策を行っても完全に問題を取りきれず、流出してしまうのが現状ではないでしょうか…
問題発生の連絡を受けたら、まず問題確認と原因分析のために以下のようなアクションを取るのではないかと思います。
- 問題発生のエビデンス（エラー画面やコード等の画面ショット）とシステムが出力するログをできる限り入手し、エラー内容を解析する。
- 問題が発生した機能を実現しているプログラムのソースコードを頭から順番に調査する。
情報が多く、これらを端から調査していくので時間がかかります。このため、問題が発生すると夜通し対応に追われるということは、容易に想像のつくことですね。
さて、仮説思考を適用すると何が変わるのでしょうか。次節から説明していきます。
仮説思考とは？
仮説思考は、
「現時点で入手している情報から、想定し得る最も確からしい結論を出し、それに沿って行動を起こす」
と定義できます。
仮説ですから、色々な事柄が実際には確かめられていない状況で結論を出すことになります。よって見解に沿って行動をした結果、状況が変化しなかったり悪くなったりすることもありますが、結果が出ない場合は、別の仮説を立てて行動に移す。それでもダメな場合は、別の仮説を立てる…というサイクルを繰り返すことによって状況を良化させていきます。
ただ、上記のように見解に誤りがあった際に、仮説→検証サイクルを繰り返すことは理想ですが、大体の場合は思考が停滞して結局時間がかかってしまうため、実際にどのようにするのか、考えていきます。
思考プロセスについて
行動の方向性を決めるために、現時点での情報でまず複数の見解を出すことが最初のステップになります。
システム問題発生時を例にすると、
問題発生の連絡を受けた段階で入手する不具合の事象から、どのような原因によるものかを机上で複数検討します。その時点では、設計書を含むソースコードやシステムログなどの詳細情報は見ません。
この機能がこのような動作をしている際に発生する。または機能が停止している際に発生する等、現時点で考えられる発生条件と不具合の事象に至るシナリオを複数検討します。複数検討できたら検証をするために優先順位をつけていきましょう。
その後、検証プロセスに入ります。問題発生シナリオに沿って設計書やシステムログ等の詳細情報を参照し、妥当性を順に確認していきます。
仮説が外れると、焦って思考が停滞することが経験上よくあったため、現実的には最初に仮説を複数立てるという方法がよいと思います。
まとめ
重要なのは、仮説（ここでいう問題発生シナリオ）を検証するために、必要な情報を入手していくという考え方です。仮説がない状態で、設計書の読み込みやあらゆる情報を入手したりすることは、時間という制約がある中で行うべきことではないと考えています。
最後までお読みいただき、ありがとうございました。