puttinpuddinのブログ

コンサルタント見習いの仕掛かり作業

team problem solving (feasibility編)

入社して3年ほど経った頃、恩師から"team problem solving"という概念を教わった。一般的な用語なのか定かではないが、「チームのすべてのメンバーでissueを特定すること」と彼は定義していた。

 

issueはimpactとfeasibilityで決まるが、feasibilityには、検討と実行の各フェーズにおけるfeasibilityがある。コンサルティングサービスの場合、実行のfeasibilityは「とるべき打ち手が特定されたとしてそれがクライアントの組織にとって実行可能か」というお馴染みの問いで表現されるが、検討におけるfeasibilityは「そもそも打ち手を特定できるか」という問いで表現され、詰まるところ、ファームの専門性の多寡/実力の高低が問われる。

クライアントへの価値提供のみを追求するのであれば、理想的には検討のfeasibilityは制約条件とすべきではない(実際、投下時間の制約が緩かった時代はある程度無視されていた)ものの、現実には厳然と存在するため、issueを定義するうえでは正しく評価しなければならない。

 

 

では、どのような手続きでこれを評価するべきか、という話になる。僕の知る限り、「マネージャー以上で行う」派と「チームメンバー全員で行う」派との間でかなり根深い対立がある(冒頭で述べた"team problem solving"は後者)のだが、僕は基本的には後者の方が望ましいと考えている。そう考えるのにはいくつか理由があるが、主だったところとして以下3点が挙げられる。

先ず、ジュニアメンバーは「本当に実行出来るか」と自ら問う中で、検証のプロセスを一度緻密にシミュレートすることになり、想定されるリスクを前倒して洗い出すことができる。

また、issueが導かれた背景の理解が深まることで、仮説検証やクライアントコミュニケーションの結果として論点構造が再構成される場合にも精度の高い対応が期待できる。現実的には細かく分解された論点のうちの1つを切り出してその範囲内で仮説検証の作業を担ってもらうことになるが、それでも一定確率で論点の再構成が発生することを考えると、論点の全体像を理解してもらう価値は大きい。

最後に、高い職業倫理が問われるこの職業において、健全な自尊心と動機付けは不可欠であり、それらを失わないためには「自分自身で決める」ことは不可欠だと思っている。

 

 

但し、このような"team problem solving"が機能するためには、ジュニアメンバーがfeasibilityを過小にも過大にも評価しないという前提条件が満たされなければならない。実力を誇示しようとfeasibilityを過大に評価すればチームとして過剰なリスクを抱えることになるし、負荷を下げるために過小に評価すればクライアントへの提供価値を損なう。実力値からの大きな逸脱は経験量で勝るマネージャーが防ぐことが出来るとはいえ、議論を通じた合意である以上、頭ごなしの否定はできないため、このやり方は、評価の過程を「議論」ではなく「交渉」として扱う人が出てきた場合には機能しなくなる。

つまるところ、まっとうに評価できるだけのスキルレベルがあること、また、予め信頼関係が築けていることが重要になる。

経営コンサルティングのプロジェクトはプロジェクト期間の1/3〜1/2のタイミングで答えがほぼ固まっていることが健全さの目安であるため、逆算すると、理想的にはプロジェクトの開始の瞬間、遅くとも開始2週間くらいには信頼関係が築けているのが望ましい。この信頼関係の構築が上述のタイミングで望めない場合は、残念ながらteam problem solvingは諦めなければならない。このように考えると、信頼関係を築く技術もさることながら、そもそも信頼関係を築ける者同士でチームが組成されていることが重要になる。

 

 

恩師は「マネージャーが目指すべきは、team problem solvingが機能している状態だ」と繰り返していた。

feasibility評価に限っても、「feasibilityを評価できるだけのスキルレベルが担保されていること」、「ジュニアメンバーと信頼関係を築く技術があること」、「そもそも信頼関係を築けるだけの人材を獲得できていること」といったように、マネージャーとして様々な困難を超えた先にしか実現できないものであり、高い理想を追求する人にとっては適切な結果指標だと思っている。

team problem solvingはソフトウェア工学の世界で「アジャイル」と呼ばれている思想/方法論とも近似していると理解しているが、アジャイル宣言が出されてから約20年、マス層への適用を追求した結果、先駆者たちの掲げた思想が「スクラム」という根本的に思想の異なる方法論に派生しているのは興味深い。自分がソフトウェア工学の先駆者たちの描いた世界にいるのかマス層にとっての現実にいるのか、明らかになるように思う。