テストエンジニアをはじめとしたエンジニアの肩書きを持つ方々には、往々にして問題解決能力が求められると思います。最近、私の関わる活動の中でそういう流れが高まってきたので、問題解決入門を読んでみました。
そのまとめをつらつらと。

書籍の詳細には例題やらいろいろ合わせて書かれており、非常に理解しやすかったです。
エンジニアは往々にして問題解決能力が求められることは多いと思いますが、その基礎的な内容を体系的に頭にインプットする、という意味で非常に良い書籍だと思いました。

内容

問題とは

問題とは、目標と現実のギャップであり、解決すべき事柄である

• 目標
  • あるべき姿
  • 望ましい状態
  • 期待される結果
• 現状
  • 実際の姿
  • 予想される状態
  • 予期せぬ状態
• 数値化可能な目標
  • 定量的目標
• 数値化が困難な目標
  • 定性的目標
    • 勤労意欲、知名度、満足度など

問題と問題点

• 問題
  • 結果として起きたことが問題
• 問題点
  • 問題の原因の中に存在する
  • 原因の中で手を打って改善可能なこと
    • 手を打つことができないことは、問題点として扱うことができない
  • 手を打つ必要のあること
    • 手を打つ必要の無いことは、問題点として扱う必要はない

通常、問題1つに対して問題点は複数ある。

問題の確定

• 問題を確定させるためには、解決すべき主体が明確である必要がある。
  • 誰にとって問題なのかがはっきりしないと、何が問題なのかを明確にすることができない
• 制約条件
  • 目標達成を阻害する客観的な事実
  • 時間的余裕が無い、情報不足などにより、問題を回避するにあたり制約がある、というようなもの

1. 問題の基本構造は、目標と制約条件によって決まる
2. 自分にできること、できないこと(制約)をはっきりさせることが、問題解決を考える上では重要

問題の種類 ~ 問題のパターン認識 ~

問題発見、問題形成、意思決定の能力が問題解決では大事で、往々にしてゼネラリストにはこの技術が求められる

1. 既に起きている問題: 発生型の問題
2. 今より良くしたいという問題: 探索型の問題
3. この先どうするかという問題: 設定型の問題

既に起きている問題

既に起きている問題に対しては、以下の2つを考える必要がある。

1. 同様の問題が再発する可能性を低くすること
   • 目標を達成できなかった
2. 既に起きた問題に対して対応すること(事後処理)
   • 期待した状態から逸脱したので、ギャップを埋めたい

発生型の問題をさらに区分すると、

• 目標に対して達成できなかった未達問題
• 期待した状態から逸脱した(ギャップが生じた)逸脱問題

に区分される。

問題が発生した時に生まれた損失を取り除いて正常な状態に戻すこと、顕在する問題を減少/回避させることが目的となる。

今より良くしたいという問題

1. 改善問題
   • 何か良くするために新たなことを始めるなど
2. 強化問題
   • 既にできていることを、さらに良くする、というようなもの

機会損失を減少、もしくは回避するためのもの。

この先どうするかという問題

設定型の問題
1. 開発問題
– 新規に何か始めたりするときに現れるリスクに対する問題
2. 回避問題
– 将来の様々な危険を予想し、あらかじめ準備をしておくようなもの

問題の区分

時系列で表現すると以下のような形。

<---原因志向---> <---目標志向--->
過去           現在            未来
▽              ▽             ▽
--------------------------------->
<==発生型の問題==>
       <==探索型の問題==>
                <==設定型の問題==>

また、それぞれを誰が当事者になりやすいか、で考えると以下。

経営レベル => 設定型の問題
管理レベル => 探索型の問題
現場レベル => 発生型の問題

問題の組み立て

1. 目標から現状を見てギャップをとらえる
2. 現状から目標を見てギャップをとらえる

問題自体は以下の2通りで対策まで考えることができるが、通常は論理分析の順で問題解決を計る。

• 問題=> 原因=> 対策
  • 論理分析
• 原因 => 問題 => 対策
  • 時系列分析

問題の構造化も必要。

原因群に対して、状況が加わり、問題となったか、というのを把握する必要がある。

環境の変化により問題が変化したり、環境の変化により問題が生じる、という場合もある。
政治、経済、社会、技術、文化、自然が大きく区分としてある。

課題達成の手段と活動

課題達成のためには、以下のような入力と出力の関係があり、これを通してギャップを小さくしていく施策を実施していくことが必要。

入力(手段)->プロセス(活動)->出力(結果)<=[ギャップ]=>目標

※つまり、現状は、過去の活動の結果である、ということ。

制約条件を考えると、それは
1. 入力(手段)を制限する
2. プロセス(活動)を制限する
の2種類に分けられる。

これを考慮すると、以下のような形で問題は組み立てられる。

     [制約条件]
        ||
入力(手段)->プロセス(活動)->出力(結果)<=[ギャップ]=>目標
|=========原因=========|

問題点

原因自体、目に見える問題と目に見えない問題がある。※ホワイトボックス,ブラックボックス

問題点は以下のような種類が存在する。

• 目に見えないブラックボックス型の問題: チームワークなど
  • これらは、目に見えないのでブラックボックスの推論、として問題点としてあげられるようになる
• 予期せぬ外因的な不可抗力障害のような外乱: 地震など
• 入力が宜しくない問題: xxを想定して行った入力(手段)なのに、それが的外れだった
  • 入力が不足してる、入力が不適切である、という2種類に大別される
• プロセスが宜しくない問題: やり方がまずかった、xxをしておけば良かったがやらなかったなど
  • 行為ミス、欠落ミス
• 自身の手に負えないという問題: 何か別な修正をしたら制約ではなくなるようなことや、天気や法律のように自分が簡単にどうこうできないもの
  • 一時制約、絶対制約
  • 問題点を考え、解決するには、何をこの制約条件としてとらえていくかが大事

できる範囲とできない範囲

入力が宜しくない問題、プロセスが宜しくない問題、自身の手に負えないという問題に対しては、できる範囲とできない範囲を知ることが重要。
問題の主体者によってとることができる手段の範囲も変わってくるので、問題の主体者の権限内でできる対策で解決できる権限内の問題点か、問題の主体者の権限内でできる対策では解決しない権限外の問題点かを切り分けて対応していくことが大事。

解決策

問題点の洗い出しが重要だが、そのような欠けている事実を出し切ることは困難。ただ、KJ法のような手段を使い、それを洗い出してくことは可能。

以下のような対策が実際的ではないため、解決策には遠い。

• コミュニケーションを良くする
• リーダーシップを発揮する
• 人間関係を改善する

これらではなく、より具体的なやらなければ行けないことは何かを見つけることが解決策を考えること。そのためには、まず制約条件や事実をブレインストーイングやKJ法を使い洗い出し、それぞれの問題点を権限内の問題点/権限外の問題点か判断、対策をうてるなら実際に行動して解決できる方法を決めていくことが必要。

目標を変える

解決策の1つとして、目標が不適切（目標が抽象的すぎるなど）な場合、それを落とし込んだり別の内容に置き換えて、適当な形で再設定することも大事

応急処置

対策(解決策)には当面策と根本策がある。
以下のようなものが当面策で、これらは多くの場合事後処理でしかなく、問題の再発防止にはならない。

1. とりあえずの一時的対応: 応急処置
2. 緊急を要する場合の対応: 緊急対応
3. 事実確認のための事情聴取: 情報収集

戦略と戦術レベルの解決

根本策には、

1. 権限内の問題点で、戦術レベルの根本策で解決できる
2. 権限外の問題点で、戦略レベルの根本策で解決できる

ものがある。戦略と戦術は、与えられた制約の下での対策が戦術であり、制約条件そのものを動かすかが戦略という関係にある。

大事なこととして、解決策には優先度をつけて対応していくことが大事で必要。

最後に

ここまでまとめてきましたが、実際の仕事ではより複雑な問題を解決することも多いと思います。問題形式チャート、意思決定チャートなどのツールを使い、問題を整理して解決へと進んでいくと情報が整理できて良いかもしれない。

また、内部で改善活動を進める場合、どのようなパターンの問題に対して、どいう形で落とし込みたい、というようなことをまとめ、それらを地道に伝搬していくことも大事だとつくづく思った次第。

仲間に価値を届け、それがエンドユーザにも繋がるように改善活動を続けていきたい！
※それが、各々がやりたいことに注力できる道と信じて・・・