うぃろぅです。
今日も今日とてやっていきます。日々を積み重ねていこうな。
今日のテーマ
SEに求められる問題解決スキル
定義
「問題」を、「現状あるべき姿と現状とのギャップ」と定義する。
「1秒以内にレスポンスする」が「2秒かかっている」だとこの1秒のギャップが問題点となる。
アプローチ
- 解決
- 予防
の2点でアプローチする。
例
- 仕様が固まらない
- スケジュールの遅延
- 大量バグ
- トラブル対応マニュアルがない
- パフォーマンス低下
- システムダウン
悪夢だなぁ。打合せするたびに仕様追加してくるような客先、大変だった…。
理想
こんなSEは良いよね、という例
- 問題の予防ができる
- 問題を早期発見できる
- 問題の優先順位を明確につけられる
- 問題に対して恒久対応ができる
- 問題解決策の妥当性を説明できる
たしかにこうありたくはある。
解決に向けて
湧き上がる問題を分析すると根本原因が1つに定まる、ということがある。
バグ表にもよく根本原因を記載する欄がある。丁寧な分析、大事。
プロセス
暫定対応
- 問題発見
- 対応策検討
- 実行 / 効果確認
恒久対応
- 問題発見
- 問題分析
- 原因分析
- 解決策立案
- 実行 / 検証
恒久対応のプロセスについて順番に見ていく。
問題発見
- あるべき姿を確認する
- 現状把握
- 問題認識
「本来こうであるはず」が「こうなっている」ため、「これが問題になっている」
という論法。バグ表はこの順で書いてくれ頼む~~~~~。
問題分析
- 問題に関する情報を集める
緊急性 / 影響範囲等を見極める - 問題を評価する
という流れ。これで解決すべき問題を選出する。
原因分析
- ロジックツリーを使って問題の原因を展開する Whyツリーを使う。
- 根本原因を見つける
- 目標 / 課題を設定する
これあの時やったやつだ!! という気分になっている。やるやん私。
解決策立案
- ロジックツリーを使って解決策を展開する
Howツリーを使う。 - 解決策を見つける
- 解決策のアクションプランを作成する
適切な優先順位をつけ、具体的に解決策を提示するのが大事。言うのは簡単なんだけれどもね。
「いつまでに」「誰が」「何を」「どのように」やるか。5W1H。
実行 / 検証
- 実行
- 検証
監視 / コントロール
読んで字のごとく過ぎる。PDCAサイクルのDとCかしら。
思考法
- 仮説思考
- フレームワーク思考
- ゼロベース思考
仮説思考
いくつかの情報から類推して仮説を立てる。
スピードがあるため暫定対応するために使うことが多い。
精度を上げるために検証はしっかり行う必要がある。
「雲行きが怪しい」から「雨が降るかもしれない」ため「傘を持っていく」時はこの思考法をとっている。私は基本的に折りたたみ傘を持っている
フレームワーク思考
MECEを実現するために…ってこれやったな。
QCDとか5W1Hとか4Pとかに乗っかることでMECEが実現できる。
4Pに乗っかるって書いてちょっとテンションが上がるなど。昼はダメだわ。ならいつならいいんだ
ゼロベース思考
ココベース!? 違いますかそうですか。
既存の枠を取り払い、ゼロの状態から答えを模索する思考法。
型にとらわれるな! っていうあれ。でも新しい意見がほしいって言われたから考えて出すと「前例はあるの?」って訊いてくる上司もいるとかいないとか。どうしろと。
ゼロベースにするきっかけとして、オズボーンのリストを参照。
オジンオズボーンは関係ない。
問題解決ツール
ロジックツリー
なぜなぜとかのあれ。
今回も貼っておく。
- MECEを意識する
- 因果関係を保つ
- 具体的な原因や解決策になるよう掘り下げる
が留意点。
マトリックス
行と列で問題を分析し、解決する。2軸評価。
PPMとかSWOT分析とか。大学のときにやったな…。あとはITストラテジストの勉強をしていると出てくる。
目的を明確にして、その目的に関する情報を収集してプロットする。
2つの方法に対してメリット / デメリットを羅列していくのもマトリックス。
HDD / SSD をメリットデメリットで選ぶみたいな。
パレート図
問題解決の優先順位を判断するために用いる図。
「問題の80%は20%の原因によって発生する」というパレートの法則に基づく。
予防に向けて
ここからは予防に向けての方法。
予防の重要性
将来的なリスクを回避 / 軽減でき、負担が減る。
問題予防プロセス
リスクマネジメントプロセス
- リスクの洗い出し
- リスクの分析 / 評価
- リスク対応策の立案 / 実施
- リスクの管理 / コントロール
解決プロセスとよく似ている。
まとめ
とにもかくにも論理的思考。順番に身に着けていこう。
ではまた。