2008年6月26日木曜日

問題解決について

俺が考えている問題解決の手順。
あくまで、『俺流』であることに注意。
最後にも書いたけど、俺自身この手順を踏まないことも多いしね。

  • 1.問題・状況の明確化
まず、何が起こっているのかを正しく把握する。
「よくわからないけど、動きません。バグってます。おかしいです。」の状況は最悪。
この状態が最悪な理由は、顧客(ユーザ)に対して説明ができないことにある。
上のセリフを客に行ったら、多分キレる。少なくとも俺ならキレる。
どのような際に起こった問題なのか。
期待すべき結果はどうだったのか。
期待すべき結果と比べ、どのような違いがあるのか。
という観点から、起こった事象を論理的に纏める。

  • 2. 原因の推定
上で纏めた事象から、原因と思われる箇所をいくつかピックアップする。
ここでピックアップする箇所は、当然のことながら少ないほうが良いのだが、漏れが怖いため、できる限り多めに選ぶ。
原因と思われる箇所を選ぶ、というよりは、決して原因になりえない箇所を消していくという消去法のほうが良いかもしれない。
また、原因となりうる箇所は一ヶ所とは限らない。
複数の箇所が、相互に作用したうえで問題の原因となっている場合もある。

  • 3. 状況と原因の結びつけ
上記でいくつか絞った原因の候補群と、実際に起こっている現象の結びつけを行う。
「Aという箇所に○○の問題があったため、次処理にて不具合を起こしたと思われる」
「Aという箇所では○○を出力する可能性があるが、Bではそれを想定していないため、結果に不具合が生じたと思われる」

のように段階を踏んだストーリー的に表せるとよい。
ここでの仮定は3段論法にならないよう注意すること。
ここまできてようやく顧客にまともな説明ができるようになる。
また、この後の作業についても顧客からの理解が得やすくなる。
そのため、作業量は多いが、可及的速やかにここまでこなす必要がある。

  • 4.裏取り
上で挙げた仮定を実証する。
ここまで来てようやく実際に手を動かすわけだが、やみくもに原因と思われる箇所に
手を加えることはできるだけ避けること。
問題を解決しなければいけないという逸る気持ちは抑え、上の仮定を実証することに全力を注ぐ。
この際、できればテストシナリオを作成し、それに沿って作業を行うとよい。
「Aという箇所に○○のような修正を加えた場合、仮定1が正しければ結果はBになるし、正しくなければ結果はCになる。」
のようなシナリオをいくつか作成し、実際に作業を行うことでいくつかあった仮定を絞り込んでゆく。
最終的に仮定が1つになれば、それがこの問題の原因であると言えるわけである。
また、ここまでくれば大概は問題に対する解決案もいくつかでてくることと思う。

  • 5. 問題の解決
ここまでで導かれた問題・状況とそれに対するいくつかの解決案を顧客に提示し、実際に行う解決法を選択してもらう。
あとは何も考えず、手を動かせばよい。

  • おまけ
実際問題として、ここまでの手順をきちんと踏まなくてはならないということはない。
事象を聞いた時点で原因が思いつく場合は多々あるし、それが正しいことは日常茶飯事である。
問題解決はスピードが命なので、即解決ができるのであれば、上のような面倒な手順を追うことは時間の無駄とも言える。
ただ、何をしてよいかわからず、ただやみくもに手を動かすよりは一つ一つの手順をおって行ったほうが
解決は早いし、顧客への説明もやりやすくなる。
状況に応じて使い分けることが必要と言える。

0 件のコメント: