問題解決の流れ 7つのステップ

問題解決のフレームワークとか言われても、ちっともピンとこなかったのですが、「問題を解決する流れ」というのはだいたいこんな感じではないか..というのを考えたので、まとめてみました。

ただし、システムインテグレータ(SIer)勤務で、システム障害の対応だったり、維持管理をしていての問題解決だったりするので背景は相当かたよっているとは思うのですが。

7つのステップ

図は、Xmindで作成しました。

問題
仮説
調査
検証
解決
実行
評価

のステップです。

実践すると、たぶんこんな感じ。

問題: 夜間バッチ処理が完了すべき時間までに完了しない
仮説: どこかのジョブで処理に想定外の時間がかかっているんじゃない?
調査: ジョブごとの開始終了時間の取得→時間がかかっているジョブを確認
検証: 時間がかかっていることを確認
問題: なぜ時間がかかっている?
仮説: 非効率なSQLになっていないか?
調査: SQLの詳細情報を取得
検証: 負荷の高いSQLを確認する
解決: 負荷の高いSQL効率のよいものにして、時間短縮をはかる
実行: 本番環境へリリースする
評価: 処理時間の短縮したか確認する

問題〜検証までが、問題点を明らかにするためのアクションになります。具体的な「解決」につながるようになるまで、問題〜検証を繰り返します。検証で仮説が「はずれ」となれば、新たな仮説をたてて、調査〜検証を行います。

重視するポイント

上の7つのうち、システムのお守りをしていて重要だなと感じるのは、

仮説
調査

です。

特に仮説のほうが重要です。仮説を上手に立てられると、問題解決までの時間と作業が少なくてすみます。プログラムが想定どおり動かない原因を解決するにも、目のつけどころが違っていて、いつまでたっても解決できないこともあります。ピントのずれた調査はいくらやっても徒労です。

また、現状をおさえるための調査ツールをたくさん知っていることは、調査時間の短縮につながります。

ネットワークの問題?→ping,traceroute, wireshark, サーバ上のパケットキャプチャーツール
サーバのリソース?→vmstat、sar、df

などなど。専門家にたよるにしても、こんなこと調べるための手段はある?といった質問ができると、回答が早いです。

「仮説」と「調査」がうまくなるには、システムがどう動いているか仕組みを知る必要があります。「解決」について承認を得るスキルというのも顧客に説明する立場として重要に思えます。しかしながら、しっかりした「仮説」と「調査」に基づいた説明ができれば、顧客が感じる納得感が大きくなると思いますので、結局「仮説」と「調査」が大事かなと考えます。