Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

組織で発生する問題のヒントを拾いあつめる2つの技術

チームや組織の問題を解決したい。
なんとなくあの人が問題にみえる。
なんとなく組織の問題にみえる。

こういった荒い粒度から一歩進む2つの方法について考えます。

問題のヒントを拾いあつめる2つの方法

  1. 観察する
  2. 質問する

観察する

組織において発生している問題をできるだけ細かく観察します。
人、構造など、どのような要素が絡み合って現在の問題が発生しているのか。
なんとなく。たぶん。その領域を減らします。

  • 登場人物
  • 登場主体
  • 業務プロセス
  • 組織内で流通している情報
  • それぞれの関係性

などが主要な着目点です。
普段自分が関わっているところだけではなく、その業務全体や、組織そのものの構造から問題が発生していることもあるのでできるだけ広い範囲で観察します。

質問する

観察した上で、まだ曖昧で分からない点があれば、その部分に詳しいと思われる人に質問をします。
例えば、問題であることはわかるが、その問題をどう取り扱っていいかわからないようなものは、おそらく粒度が荒く曖昧な点が残っています。
その内容がはっきりする材料を得ることができるように、質問で問題を掘り下げます。

これにより今まで聞いていなかった前提条件や、問題の原因となっている人の感情の絡み合いなどが発見できることがあります。

問題があり、その問題の全体像や真因がどこにあるのか?
それが分かるまで質問を繰り返します。

ここで障壁となるのは、質問する相手との関係性です。
信頼関係がプラスであれば、質問は円滑にできますし、中立程度ならなんとかなるでしょう。
マイナスだった場合は難しいところです。迂回するなり、不仲なりになんとか事実を引き出すなり、先に信頼関係を作り込むなりの努力が必要になります。
普段からできるだけ関係性を良好にしておくと、いざというときに役立ちます。
別にそんなことは関係なく、一緒に仕事をする相手とは良好な関係でいたいですけど。

分析する

観察質問 により、手元には今までよりも多くの思考材料があります。
手元のヒントが増えたため、今までよりも深く・的確に分析できるようになります。

この情報を元に、

  • 今起こっている問題とは何か?
  • その個別の症状と原因の関係は何か?
  • 絡み合う各要素の真因は何か?

を原因・結果を矢印で結ぶ関連図で整理します。
できれば複数名で分析するとよいでしょう。

システム思考の図や、 TOC の現状問題分析ツリー の図のように、かっちりとルールが決まったようなものでなくてもよいので、丸で囲んだ要素と矢印でつなげた関係性がわかるようになっていればよいと思います。
箇条書きだと関係性がわかりにくいので、関連図にすることをおすすめします。

まとめ

問題を解決するためのヒント集めについてまとめました。

例えば、問題を解決するためには偉い人の意思決定が必要で、それが得られないのなら末端で何をしてもムダだよ・・・と考える人もいるかもしれません。
しかし、問題の詳細を把握し、真因を導くスキル自体はいざ適切な意思決定が得られる環境に身をおいたときに大きく役立ちます。やっておいて損はない、と思います。