問題解決のしかたを本で読んで、実際にやっていくときにどう使っていくのかのイメージがつかない人が多そうなので書いてみる。 理解が深いほどある程度解決のための型があって、フレームワークの評価から実行へ移したくなったりもするけれど、過程で関わる人の理解がそろっていくのも大切なのでそこをどんなスピードとプロセスで進めていけるかが実地の問題解決者としてのアートな部分でもある。
- なにはなくとも現地現物。一次情報を聞きに行く
- 解決志向的な質問を立てる
- 分析をして確度を上げていく
- 解決をしていく
の順で説明をしていく。
- インタビューの設計としては、ざっくりと自分の中で様子を見て、問題となることのあらすじをつくっておく *1
- たとえば開発組織の問題を見にいくのなら
- 「組織能力が不足していて、モダンな開発プロセスへの理解と実践ができていない」
- 「開発するものの意思決定がその場その場で行われていて誰も開発すべきものの共通理解を持っていない」
- 「皆が見られるバックログがない」
- 「バックログへの追加が個人との依頼と交渉になっている」
- 「開発の過程で互いにレビューする習慣がなく個人個人の品質でプロダクションコードがコミットされる」
- 「自動テストがない」
- 「構成管理が不十分で本番資源の再現ができない」
- 「品質のステージと、それに対応するテスト環境、テストプロセスがない」
- 「プロセスとチームに対してふりかえりで具体的な改善がされていない」
- 「ふりかえりがされていない」
- 「ふりかえりがされているが本当の問題へ誰も言及できていない」
- 「開発するものの意思決定がその場その場で行われていて誰も開発すべきものの共通理解を持っていない」
- 「組織能力が不足していて、モダンな開発プロセスへの理解と実践ができていない」
- あたりがよくある形なので、「この現場はこうだろう」という見立てのうえでその反証や裏付ける事実を聞いていく
- 反証が見つかったら自分の理解がずれているので、シナリオを見直しする
- ヒアリングしていく中で最初のあらすじと実際の状況から一番多くの現象を解決する根っこになってる問題はこれだなという見極めをしていく
- 途中からヒアリングの中でもその見極めが正しいかを検証していく質問に変えていき、見極め自体の検証を回す
- たとえば、「求める水準の仕事をするのに組織の人の能力は十分なのか？」というような質問の見極めをしていく
- それによってこんなかんじで打ち手が変わってくる
- 「いろいろできていないがそれは能力の問題で、人を全部変える以外にはない」
- 「基本的な理解はあり、やれば実践する素養はある。だが、環境がないので必要なことをやれる意思決定ができる場にする必要がある」
- 自分で考えるときには、「それによって打ち手が変わってくるから、一番最初にケリをつけないといけない問題はなにか」という考え方をしている
- この辺はオーソドックスな問題解決の本に書いていて、『企業参謀』だと「ものの本質を考える」という章に書いている。『イシューからはじめよ』だと「仮説を立てる」の『「スタンスをとる」ことが肝要』の内容
- 企業参謀によると、「設問のしかたを解決志向的に行うこと」の一文で表されている*2
- これがYESかNOかで結論がぜんぜん違ってくるよなという要所をえぐる設問を設定することで、解決への道筋の質が大きく変わってくるので一番大事
- たとえば、途中で「いや、能力はある」となると「能力はあるわりに組織として目的意識が希薄で、それはどうやらマネージャーに人望がないせいだ」ということがわかってきたりする
- さらにここから深めていくと「実は人望がないのでなく目的をそろえる組織マネジメントのプロセスがないのだ」という結論になったりもする
- 解決志向的な質問としては YES/NO の二値で答えられるものにする
- そうじゃないと、「組織の能力として今なにが問題なのか？」「Aも問題だ」「Bも問題だ」「Cも問題だ」→「大変だ」みたいになって解決へ近づけない
- サンプルでは、「求める水準の仕事をするのに組織の人の能力は十分なのか？」という YES/NO で答えられる質問を立てた
- 仮説を立ててアクションをする人がいるが、基本的には仮説は分析の軸を決めるために立てるもの
- 上でも重複しながら進めているが、仮説を立てた内容 (解決思考型の質問) に対してその真偽を決着つけるような事実を集めていく
- 早々に判断つくような仮説はシナリオを修正していく
- 一方で、コンサルタントの問題解決じゃないので、大体ここが分析のフェーズでわけて大量に時間をとるというわけでなく、走りながら考えるというかんじになる
- 正解はないので、前に進みはするから十分として走ってしまうときもある
- 大体の場合、時間に追われてというのが一番の理由
- とはいえ、限られた時間でなんの勝負をするかという見極めは非常に大事なので「よいイシュー*3」を追いかけることをサボらず、素早く事実 (定性、定量) による検証を回す習慣を欠かさない
- イシューの質を上げるために「もしこうだったら最悪に都合が悪い」という視点で物事を見て、構造を追いかけていくのもよくやる
- 最終的には「どういう構造 (切り口) で対象のドメインを見て、成否の判断をしていくのか」というのを頭に描けると大体問題の解決への道筋が立つ
- ツールとしてはイシューツリーだったりとして知られるが、構造化して分解するツールというよりも「トップレベルになんの質問を持ってきて世界を見るか」というツールとしてとらえて使う
- トップレベルの質問が変わると後続の質問が動的評価で更新されるかんじ
- 当初から仮説を決めていくことの価値は分析にあって、仮説がないと全網羅的に情報を収集し分析をしていく必要がある。仮説があると、問題にケリをつけるために必要な情報以外を収集しなくてよいことになる。このためより根本の問題の解決へアプローチしながら労力は少なくなるという結果が得られる。これが仮説志向のアプローチの最大の利点
ここからは解決をしていくのだけど、いきなり解決策を考えない。現象から反転させて打ち手とするのでなく、はたしてこれはなにが問題なのだろうと抽象化して考え、アプローチを考える。
現象→グルーピング→抽象化→アプローチ設定
が一手順*4。
ここから具体的な打ち手を考えて実行していくのが解決の流れとして一手順。
この段階での「つまり、これはなんの問題か？」を考え、そこから解決方法を考える活動の最良の参考書は「トヨタ生産方式」だと思う。どういう視点で物事を見て、そこから抽象化し、具体化するときにはどういう風に頭を働かすのかという読み方をすると、車の生産ではないときの物事の見方としても役に立つ。
最後に短くまとまってしまっているが、解決を考えることも単独で創造的な活動だ。解決を考えるときのヒントとしていつも頭に置いている7つのリーン原則を書いておく*5。
- ムダを排除する
- 学習効果を高める
- 決定をできるだけ遅らせる
- できるだけ速く提供する
- チームに権限を与える
- 統一性を作りこむ
- 全体を見る
このプロセスを安宅さんがわかりやすく書いたのが「圧倒的に生産性の高い人（サイエンティスト）の研究スタイル」という「イシューからはじめよ」出版のきっかけとなったエントリ。
この辺が完成形としてイメージできるとやるべきことが見えやすい。
例えばこんな感じ、ある朝いつものようにラボにやってくると、
Hey Kaz, I have an idea for a work, let's have a chat、みたいな感じで
やってくる。行くと紙をペラッと持っていて、一番上にタイトル（メインメッ
セージ）、その下は左がサブメッセージが五つぐらい並び、その右に一つ一つ
データ、実験結果のイメージ、見せ方が絵コンテのように入っている。要は紙
芝居的なストーリーラインになっている。その一つ一つが大体非常に手堅い手
法によって、どの程度のワークロードが発生するのか、誰にどう聞くとすぐに
立ち上がるのか（註：同じラボの人とは限らない）が見えている。
また個々のサブ論点（sub-issue）でも、何がどういえるかどうかが勝負、とい
う本当の見極めどころがものすごくクリアにある。
- *1: ここである程度包括的な構造理解があるか、それとも1周目として全部自分の体験で理解していくかで解決までのスピードが大きく違ってくる。また、見立てをただの書籍からの知識を正として立てるか、実践の血肉の通った経験として立てられるかでパンチ力が大きく違ってくる。当然、多少の粗さも乗りこなせる実践から来る柔軟さがあるほうが問題解決の手段に幅も出るし、突破力も高くなる。
- *2: 「企業参謀」の「第1章 戦略的思考とは」のうち、「1. 戦略的思考とは」「2. ものの本質を考える」「3. 問題点の摘出と解決のプロセス」「4. つねに本質に迫るための方法論」で 50 ページに満たない程度でほぼスタンダードな問題解決について説明しきってるのでおすすめ。
- *3: 「イシューからはじめよ」でいう「よいイシューの3条件」
- *4: 特別なものでもないがこの手順自体も「企業参謀」の「問題点の摘出と解決のプロセス」から引用した。
- *5: 「リーンソフトウェア開発」より。