PMstyle 2024年4月~6月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 【告知】現場の頑張りを無駄にしないマネジメント | メイン | 【告知】計画の本質を学ぶ »

2013年6月 6日 (木)

【コンセプチュアルスタイル考】第2話:概念化するとはどういうことか

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本連載はメールマガジン「PMsytle Mail」で配信しています。メルマガ購読はこちらから。
PMstyleメールマガジン購読お申し込み
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆概念化と抽象化Concept

まず言葉の定義をしておきたいと思います。辞書を引くと、概念的と抽象的という2つの言葉は同じ意味のようで、微妙に違います。たとえば、「大辞泉」では概念的であることを

概念的:個別性を問わず、概括的・抽象的にとらえるさま

とあります。概念的という言葉の説明に抽象的という言葉が使われています。これは前回触れましたように、

「いくつかの事物に共通なものを抜き出して、それを一般化して考えるさま」

と説明されています。

そこに、さらにキーワードとして概括的という言葉が使われています。概括というのは内容のあらましをまとめることです。もう少し、正確にいえば、「諸事物に共通する性質に着目して、それらの事物を一つの概念のもとに「統合」すること」です。

簡単にいえば概念化するというのは、抽象化したものをある概念に統合していくことです。詳しくは改めて議論したいと思いますが、統合するためには抽象化するだけではなく、抽象化したものを具体的に展開してみて、妥当性を検証するという具体と概念の行き来を繰り返し行いながら、収斂させていく必要があります。

そうはいいながら、概念化と抽象化の区別ははっきりしない場合の方が多いと思いますので、この連載の中ではここを細かく使い分けることはしませんが、一応、このような違いがあることを頭の片隅に残しておいてください。

◆概念化のベースは言葉

概念化のベースになるのは言葉です。したがって、世の中では「名詞」についてはいろいろなところで、体系化がされ、言葉と概念の結び付けが行われています。上で辞書の話をしましたが、具体的に言葉の概念の結び付けを行っている一つは辞書です。

ビジネスに近いところでいえば、職業や業種などは、たいだい、具体的な仕事や事業に対して、上位概念が定義されています。これらは、保護や規制の対象にもなっており、法律的な概念になっているものも少なくありません。

また、商品も体系化されています。たとえば、ポテトチップスも水も大きくいえば食料品ですが、ポテトチップスはスナックで、さらに嗜好品、水は飲料で生活必需品といった区分ができます。商品の概念体系は消費税を導入する際にはこれまで以上に明確になってくるでしょう。

あるいは、終身雇用制が崩れ、転職が盛んになるについてれ職位や職種もある程度、概念化されてきています。

ということで、名詞の概念についてはそんなに悩むことはありませんが、結構、難しいのは状況や行動です。

◆状況や行動を概念化する

たとえば、

お客様Aから商品Bの新しいモデルをマニュアルを見ながら使っていたら突然部品Cが外れた

というクレームがあったとします。現場では、お客様Aに対して、謝罪とともに、トラブルの状況確認など速やかに行い、同時に再発防止策を打つ必要が出てきます。そこで、概念化が必要になります。

現場レベルで考えれば

Aという顧客が商品Bの一つの個体B’をマニュアル通りに使っていたところ、B’に取り付けられていた部品C’がはずれた

ということになります。

次の抽象化レベルでは、

過去に商品Bの古いモデルを使った顧客が商品Bをマニュアル通りに使っていたら、部品Cが外れた

ということになります。さらに、抽象化レベルを上げると、たとえば、

商品Bをマニュアル通りに使っていたら、部品Cが外れた

となります。さらに、抽象度を上げると

商品Bを使っていたら、部品Cが外れた

となります。

◆抽象化のレベル

概念化している目的は、再発防止です。当然のことながら、起こっている具体的現象の抽象化レベルによって対策の大変さが異なってきます。レベルをどのようにして決めればいいのでしょうか?これを考えるために、上の例はどのように抽象化しているかを考えてみましょう。

ま ず、最初の抽象化は個体の属性をすべて捨てています。ただし、使い方に関する属性はマニュアルに個体差がある(ミスプリなどの理由で商品個体によってマ ニュアルの内容が違う)とは考えにくいので、ここはそのまま残しています。また、顧客の属性については、Aであることは捨てています(つまり、Aだから起 こったとは考えない)が、過去のユーザであるというAも含まれる属性は残しています。

さらに、その上のレベルになると、ユーザという属性をすべて捨てています。その上は、使い方という属性も捨てています。

実 際にはこのような場合の抽象化レベルの設定は、コストから逆算して行っていることが多いと思われますが、必要なのは抽象化の妥当性からのアプローチです。 原因が明確に分かればレベルを考える必要すらもないわけですが、この手の問題で原因が分かることは稀です(設計ミス、製造不具合など)。

そこで、統合するために概念化の方針を決める必要があります。たとえば、自社の問題として考えることです。すると、

商品Bをマニュアル通りに使っていたら、部品Cが外れた

という概念化が適切だということになります。その下は顧客の問題を含んでおり、下は使い方の問題を含んでいるからです。

◆統合の方針が概念化の本質

こ のようなことを、手持ちの限られた調査データから行っていく必要があります。ここで、注意してほしいことは、上で少し触れましたように、「ものごとには原 因はある」といって徹底調査するといった発想をしないことです。調査しても事実だけが分かるとは限りませんし、誤った情報に基づいてロジックでゴリ押しす るのは最悪です。

ここで、上で述べた繰り返しになりますが、概括的という言葉が意味を持ってきます。概括的に考えて、うまいレベルに統合することが求められるわけです。上の例では自社の問題として考えるという方針が統合の方針です。

冒頭に述べましたように、概念化するとは、抽象化することと厳密にイコールではありませんが、統合するところに違いがあります。概念化の本質は、この統合の方針を決めるところにあるといっても過言ではないでしょう。

コメント

コメントを投稿