「たぶんこれが問題だろう」という仮説を立てる
山田のプロジェクトでは，まずプロジェクト・メンバーがインタビューや情報収集に基づいて現行業務・システムの問題点を抽出した。しかし，問題の抽出方法をあらかじめ決めずに，各メンバーが自分なりの方法で問題を抽出したため，作業内容が適切かどうか，メンバー自身判断できずにいた。
一般に，問題点を抽出する際は，あらかじめ「たぶんこれが問題だろう」という仮説を立て，それを検証する，という考え方で進めるべきだ。事前に「落としどころ」となる仮説を設定せずに関係者にインタビューすると，抽出された問題はインタビュー相手の業務知識や経験の範囲に偏ってしまい，問題の原因を突き止めるまでに時間がかかってしまう可能性がある。山田のプロジェクトでも，この点をあらかじめメンバーに周知しておくべきだった。
また，問題点を抽出してみたものの数が多過ぎるという場合は，まずは問題を分類したほうがよい。例えば，業務・システムに関する問題を，山田が提案したように「業務」「組織」「システム」「その他」で分類するのは良い方法だ（表1）。
| 業務 | 業務の順序・流れやルール・基準が不明確。例外処理が多い。時間のムダが多い。同様の業務が分散している。必要な業務が不足している。 |
|---|---|
| 組織 | 担当者の役割，責任，権限が不明確。人員配置がアンバランス。スキルにバラツキがある。 |
| システム | 業務運用・マネジメントのためのシステム機能が不足。処理データの粒度，精度が一定ではない。 |
| その他 | 業務のPDCAサイクルが連続していない。計画と実績が対比されていない。 |
再び，ケーススタディに戻る。
山田:「問題を分類できたら，次に問題を解析して課題に落とし込んでいきましょう。経営企画部長からは，3カ月で現状業務の問題を調査して，課題を洗い出すよう指示されていますので，あまり時間はありません」
佐々木:「ちょっといいかな。問題と課題は違うのかい？」
山田:「ええ。問題は発生している不具合のことで，課題は解決すべき問題を指します」
鈴木:「しかし，具体的にどんな風に進めていけばいいのか難しいですね。まずは問題の発生原因を調べてから課題に落とし込んで整理しないといけないかな。それから課題の解決策を決めて・・・やっぱり難しそうだな」
藤堂:「実は開発部門で何人かのメンバーに参加してもらってブレーンストーミング（グループでアイデアを発想する方法の一つ。参加メンバーが自由にアイデアを出し合い，お互いの発想を連想することでさらに多くのアイデアを生み出す）を実施してみたんだ。原因を追求して課題に落とし込むつもりだったんだが，鈴木主任が言うように，どういう風にやればいいのか分からなくてうまくいかなかったよ。山田主任としては，どんな方法で問題を解析するのがいいと思ってるんだい？」
山田:「それについては考えがあります。ロジックツリーを作成するのがいいと思います」
そういいながら，山田は図1のような絵をホワイトボードに描き出した。
