仕事をしていると、目の前には具体的な問題がたくさん出てきます。
入力作業が多い。
確認に時間がかかる。
同じ情報を何度も入力している。
担当者によってやり方が違う。
こうした問題を見ると、すぐに「どう直せばいいか」と考えたくなります。
もちろん、それも必要です。
ただ、目の前の問題をそのまま解こうとすると、
答えもその問題の範囲に収まりやすくなります。
私は会社員時代、長くBPR（業務プロセス改革）に関わってきました。
その中でよく使っていたのが、具体的な問題を一度「抽象化して考える」という方法です。
いくつかの問題を眺めながら、
「これは、結局何が問題なのだろう」
「どんな状態をつくれば、まとめて解決できるだろう」
と一段上から考えてみる。
すると、目の前の問題とは少し違う「解決のコンセプト」が見えてきます。
そのコンセプトから具体的なアイデアを出し、出てきた案を見ながら、もう一度抽象化する。
私は、このように具体と抽象を行き来しながら、
コンセプトとアイデアを磨く考え方を、自分なりに「コンセプト思考」と呼んでいました。
この記事では、私がBPRの現場で使ってきたコンセプト思考をもとに、
抽象化を具体的な解決策につなげる方法を考えてみます。
抽象化すると、問題の見え方が変わる
目の前の問題は、たいてい具体的です。
たとえば、
「入力作業が多い」
「同じ情報を何度も転記している」
「確認に時間がかかっている」
といった問題です。
一つひとつを見ると、それぞれ別の問題に見えます。
すると、
入力画面を直そう。
転記を減らそう。
確認の手順を見直そう。
というように、問題ごとに解決策を考えがちです。
それで解決できることもあります。
ただ、少し視点を上げると、別の見え方ができます。
「なぜ入力が何度も必要なのか」
「なぜ転記が発生しているのか」
「なぜ確認に時間がかかるのか」
と考えていく。
すると、
情報が途中で分断されている
という共通する問題が見えてくるかもしれません。
これが、私が考える抽象化です。
抽象化とは、難しい言葉に置き換えることではありません。
複数の具体的な出来事に共通しているものを見つけること
です。
具体的な問題だけを見ていると、解決策もそれぞれに分かれます。
一方で、共通する問題が見えると、
「これをまとめて解決するには、どうすればよいか」
と考えられるようになります。
私はBPRの現場で、目の前の問題をすぐに直そうとする前に、
「これは結局、何の問題なのか」
と考えるようにしていました。
一度抽象化することで、
部分的な改善だけではない、新しい方向が見えてくることがあります。
個別の問題だけでなく、その前後や周囲とのつながりを見ると、共通する構造が見えやすくなります。
全体のつながりを見る考え方は、以下の記事で紹介しています。
私が使っていた「コンセプト思考」
私がよくやっていたのは、抽象化して終わることではありません。
具体と抽象を何度も行き来すること
でした。
まず、具体的な問題から共通するものを探します。
そこから、
「情報を一つにつなげる」
「判断を人だけに頼らない」
「同じ作業を何度もしない」
といった解決の方向を考える。
私は、この方向をコンセプトとして置いていました。
次に、そのコンセプトを実現する具体的なアイデアを出します。
たとえば、
「情報を一つにつなげる」
なら、
入力を一か所にまとめる。
必要な部署へ自動で情報を渡す。
同じ情報を別のシステムへ転記しない。
といった具体策が考えられます。
そして、出てきた案をもう一度眺めます。
「この案が本当に実現したいことは何だろう」
「もっと本質的な考え方にできないだろうか」
と、再び抽象化します。
すると、
「情報を一つにつなげる」
というコンセプトが、
「情報は、発生した場所で一度だけ取得する」
という、より明確な考え方に変わることもあります。
そこから、もう一度具体策を考える。
具体 → 抽象 → 具体 → もう一度抽象
と行き来することで、コンセプトもアイデアも少しずつ磨かれていきます。
コンセプト思考の3つのステップ
では、コンセプト思考を実際に使うとしたら、どう考えればよいのでしょうか。
私は、次の3つに分けると使いやすいと思っています。
1．具体的な問題から共通点を探す
まず、起きている問題を具体的に出します。
たとえば、
- 入力作業が多い
- 同じ情報を何度も転記している
- 確認に時間がかかる
- 部署ごとに違うデータを持っている
ここでは、まだ解決策を考えません。
まず、
「何が起きているのか」
を並べます。
そのうえで、
「これらに共通していることは何だろう」
「一段上から見ると、何の問題なのだろう」
と考えます。
すると、
「情報が分断されている」
という共通点が見えてくるかもしれません。
複数の具体から、共通する本質を取り出す。
これが最初のステップです。
問題を抽象化する前に、まず要素を分けて整理すると考えやすくなります。
物事を分けて比べる方法は、以下の記事で紹介しています。
2．解決の方向をコンセプトにする
次に、
「どう直すか」
ではなく、
「どんな状態になれば、この問題は解決したと言えるか」
を考えます。
「情報が分断されている」のであれば、
「必要な情報が一つにつながっている状態をつくる」
という方向が考えられます。
これをコンセプトとして置きます。
コンセプトは、まだ具体的な施策ではありません。
「システムを導入する」
「入力画面を変える」
よりも一段上にある考え方です。
先に「何を実現したいのか」を決めておくことで、
その後に出てくるアイデアを判断する基準ができます。
3．具体案を出し、もう一度抽象化する
コンセプトを置いたら、具体的なアイデアを出します。
たとえば、
- 入力場所を一つにする
- データを自動連携する
- 他部署でも同じ情報を使えるようにする
- 転記そのものをなくす
といった案です。
そして、ここで終わらず、
「この案に共通しているものは何だろう」
「本当に実現したいことは何だろう」
と、もう一度考えます。
すると、
「情報は、発生した場所で一度だけ取得する」
という、より強いコンセプトが見えてくるかもしれません。
そこから、また具体案を考える。
この往復が、コンセプト思考の中心です。
仮説をつくる前に、具体的な問題から一段上のコンセプトを考える方法もあります。
詳しくは、以下の記事で紹介しています。
事例｜業務の問題からコンセプトをつくる
たとえば、ある業務で、
複数の部署が同じ情報を入力している。
転記のたびにミスが起きる。
入力内容の確認にも時間がかかる。
そんな状態だったとします。
目の前の問題だけを見ると、
入力画面を改善する。
確認項目を減らす。
チェックを増やす。
といった案が出てきます。
ここで一度、
「なぜ、こうした問題がいくつも起きているのだろう」
と考えてみます。
すると、
情報が部署ごとに分断されている
という問題が見えてきます。
そこから、
「必要な情報を一つにつなげる」
というコンセプトを置く。
すると、
入力場所を一つにする。
一度入力した情報をほかの部署でも使う。
システム間を連携する。
といった案に広がります。
さらに、
「これらの案が本当に目指しているものは何か」
と考えていくと、
「情報は、発生した場所で一度だけ取得する」
という考え方に進むことがあります。
ここまでくると、単に転記を減らすだけではありません。
誰が最初に情報を持つのか。
どこで取得するのか。
その情報を、どこまで使えるようにするのか。
業務全体の設計まで考えられるようになります。
最初は「転記を減らす」という改善だったものが、
「情報の持ち方そのものを変える」
という改革へ変わっていく。
私はBPRの現場で、こうした変化を何度も経験しました。
抽象化と具体化を往復すると、アイデアが尖ってくる
具体と抽象を往復するメリットは、単にアイデアが増えることではありません。
一つは、
アイデアを選ぶ基準ができること
です。
コンセプトがなければ、思いついた案を並べるだけになりやすい。
でも、
「何を実現したいのか」
が決まっていれば、その方向に合わない案を外すことができます。
反対に、コンセプトを強く実現する案は残ります。
結果として、
その問題だからこそ必要な、尖ったアイデア
が見えやすくなります。
もう一つは、コンセプトそのものも磨かれることです。
最初に置いたコンセプトが完成形とは限りません。
具体案を出すことで、
「少し違う」
「もっと本質的な言い方がありそうだ」
と気づくことがあります。
そこで、また抽象化する。
コンセプトからアイデアをつくり、アイデアからコンセプトを磨く。
この往復によって、両方が少しずつ絞られていきます。
そして、最後は具体に戻ります。
何を変えるのか。
誰が動くのか。
どこから試すのか。
何をやめるのか。
ここまで考えると、コンセプトが実際の行動につながっていきます。
最初に浮かんだ解決策で止まらず、もう一段考えることも大切です。
答えを掘り下げる方法は、以下の記事で紹介しています。
抽象化するときに気をつけたいこと
抽象化すればするほどよいわけではありません。
あまりに抽象度を上げすぎると、
「効率化する」
「価値を高める」
「顧客中心にする」
といった、何にでも当てはまる言葉になってしまいます。
これでは、具体策につながりません。
大切なのは、
具体から離れすぎないこと
です。
私は、
「ここから具体策に戻れるだろうか」
と考えることが一つの目安になると思っています。
戻れないほど抽象的なら、少し具体側へ下げる。
反対に、目の前の問題に近すぎるなら、もう一段上げる。
その間を行ったり来たりしながら、ちょうどよい場所を探します。
抽象化の目的は、立派な言葉をつくることではありません。
より良い具体策を考えること
だからです。
コンセプトが見えてきたら、次はその考えをもとに未来の全体像を描きます。
全体像を構想する方法は、下記の記事で紹介しています。
まとめ
抽象化は、目の前の問題を難しく考えるためのものではありません。
具体的な問題から共通するものを見つけ、
解決のコンセプトを置き、
そこから具体的なアイデアを考える。
さらに、具体案を見ながら、もう一度コンセプトを磨いていく。
この、
具体 → 抽象 → 具体
の往復が、私が「コンセプト思考」と呼んできた考え方です。
この方法を使うと、
個別の問題への対応だけで終わらず、より本質的な解決策が見えやすくなります。
また、コンセプトが決まることで、
アイデアを選ぶ基準ができ、具体的な行動にもつなげやすくなります。
目の前の問題にすぐ答えを出すのではなく、
「これは結局、何の問題なのだろう」
「どんな状態をつくりたいのだろう」
と、一度だけ視点を上げてみる。
そこから、今までとは違う具体策が見えてくるかもしれません。
抽象化とは、具体から離れることではなく、より良い具体に戻るための思考です。