「具体と抽象」について
こんにちは。SNS領域プロダクトのプロダクトマネージャーをしている別所 (@gb_pdm)です。
GWの時間を利用して「具体と抽象」について考える機会があったので、本や記事を参考に自分なりに整理しました。
1.抽象化の特徴
[特徴1]抽象化とは「まとめて1つにする」こと
抽象化とは同じ属性を持ったもの同士をまとめて1つに扱うこと。
[特徴2]抽象化とは「デフォルメする」こと
抽象化とは枝葉を切り捨てて幹を見ること。特徴のあるものを大袈裟に表現する代わりに、その他の特徴は一切無視してしまう大胆さがある。
[特徴3]抽象化とは「構造化する」こと
抽象化とは個別バラバラの事象の間にある関係性をみつけること。
[特徴4]抽象化は物事を都合よく解釈してしまう
抽象レベルの概念は固定化されやすい性質を持っているため、これが偏見や思い込みを生み出す。
(例)
- アフリカの人は足が速い
- 東京にいる人は冷たい
[特徴5]抽象化はコミュニケーションギャップを生む
具体か抽象かは相対的に決まるため、同じ言葉でも個人よって抽象度は異なる。また抽象化されたものは解釈の自由度が高くなるため、それによってコミュニケーションギャップが生まれる。
「具体と抽象」とコミュニケーションギャップの話についてはこちらの記事がわかりやすくまとまっていて参考になります。
2.具体化の特徴
[特徴1]具体化とは「詳細化する」こと
具体化とは物事を分解・詳細化すること。
[特徴2]具体化とは「数字と固有名詞を利用する」こと
物事を明確にするには数字と固有名詞を利用する。
(例)
- 抽象的な目標
食生活を見直し健康な状態で痩せる
- 具体的な目標
大豆と鶏肉を中心に1日の摂取カロリーを2000キロカロリー以下にし、5kg痩せた状態で次回の健康診断でA判定をとる
3.具体と抽象の関係性
[関係性1]具体か抽象かは相対的に決まる
具体か抽象かに絶対的な基準はなく相対的に決まる。
この図の場合、
- ケーキからみてお菓子は「抽象」である
- 食べ物からみてお菓子は「具体」である
[関係性2]具体化はHowであり抽象化はWhyである
抽象化は問題発見のためのWhyを問うことで、具体化は問題解決のためのHowを問うこと。
[関係性3]「具体→抽象→具体」を最小単位とするツリー構造になっている
具体と抽象の最小単位は以下の三角形で表現できる。
この三角形が
①知識・情報が増えることで横に広がる
②抽象度を上げることで縦に広がる
具体⇆抽象を繰り返しながらこの三角形を大きくしていくことで、より本質的なイシューの発見と解決につながっていく。
[関係性4]一度抽象化できると下がるのは簡単
一度抽象化ができた人にとっては具体へは簡単にもどることができる。
一方で抽象化ができない人が抽象概念を理解することは難しい。
4.抽象化の効果
[効果1]レバレッジが効く
抽象化すると再利用性が高くなるのでそれによって成果を得られた場合スケールしやすい。
[効果2]より多くが同じ方向を向ける
もし「ビジョンやコンセプト」といった抽象概念や「規則やルール」などの法則もなく、具体的な個別の行動や事象のみが存在している場合、そこには多くの無駄が発生する。行動が場当たり的になり、昨日と今日の行動で整合性がとれなくなる。
組織などより多くの個の集合体になるほど無駄も多くなるため、それを包み込む抽象概念や法則により方向性を統一することで効率化ができる。
[効果3]アイデアを生み出せる
アイデアは0→1ではなく、既存の構造を他の領域にもってくる、もしくは組み合わせることで生まれる。
詳しくはこちら
5.具体化の効果
具体化は問題解決のためのパワーになる
ある問題を解決するには行動が必要で、行動を起こすには具体的である必要がある。
6.具体と抽象どちらが優れているの？
どちらもすべからく重要。
重要なのは
①全ての物事に対して「具体と抽象」の視点を持つこと
②メリット/デメリットを理解した上で使い分けること
7.「具体と抽象」とプロダクトマネージャー
個人的にプロダクトマネージャーとして特に重要な「具体と抽象」の視点は下記2つです。
[視点1]抽象化によってプロダクトの「ソフト」を設計する
プロダクトをシステムを中心とする「ハード」と、コンセプトを中心とする「ソフト」に分けた際に、それぞれに設計図が必要だと思っています。
システムを中心とする「ハード」の場合、オブジェクト指向やWebアプリケーションフレームワークなどが抽象化された設計図にあたります。ここについてはプロダクト開発時に検討・実施がされているかと思います。
一方でコンセプトを中心とする「ソフト」については、十分な抽象化(設計)がされずに具体に走っている場面を見かける気がします。
設計図を作っているだけでは家は建ちませんが、設計図がなければ仲間と建てたい家を共有することも一緒に建てていくこともできないと思っています。
プロダクトの「Core / Why / What 」といったソフトの設計を行うためにも抽象化という作業はプロダクトマネージャーにとって重要だと感じています。
[視点2]「抽象と具体」の間を埋める
プロダクトマネージャーにとってもう1つ重要だと感じるのが、抽象と具体の距離を把握し、適切に埋めていく作業だと思っています。
例えば
- 現場メンバーと経営陣の声
- プロダクトロードマップ と会社のミッション
- スプリントバックログアイテムとユーザーストーリー
- アウトプットとアウトカム
のように、プロダクト開発において抽象度の高さと具体性に距離があることで上手く噛み合わない場面はいくつもあると思います。
これらの場面でステークホルダーに合わせて抽象度の上下を行い説明をしたり、必要に応じて具体と抽象を結び付けるための梯子をかけていくという作業がプロダクトマネージャーには必要だと感じています。
さいごに
「具体と抽象」はかなり一般化された普遍的な概念なので、当たり前な話も多かったとは思いますがいかがでしたでしょうか。
自分はまだまだ抽象化スキルが足りていないと感じていて、そのために「図解」と「システム思考」がトレーニングになると考えているので、今後はこの辺りも勉強・実践していきたいと考えています。
以上となります。
最後まで読んでいただきありがとうございました！
参考
この記事が気に入ったらサポートをしてみませんか？