PdMにもオススメしたい「具体⇔抽象」トレーニング
本日はこちらの書籍について
とても示唆に富む内容だったので、特にプロダクトマネージャーやビジネスパーソン向けにおすすめしたいポイントをピックアップして簡単な感想とともにまとめます。
要約
物事の優先順位を決めたり、変化に柔軟であるためには具体的な視点だけでなく、抽象度を高くする必要がある
問題発見（Why）は抽象化された川上、問題解決（How）は具体化された川下。これは、それぞれ異なる価値観によって議論される
価値観のギャップを埋めるためには座標軸をもつこと、前提条件を明確にすることが大事
具体と抽象を往復することの重要性
具体的であることと、抽象的であること。それぞれに利点も欠点もあります。
重要なのはどちらかに偏るのではなく、具体->抽象->具体と、抽象化と具体化を往復しておこなうことです。
問題解決においては、具体的な視点だけだと表層的な問題解決になります。また、抽象的な視点だけでは机上の空論になってしまいます。
観察された具体的な事象から抽象度を高くすることによって、法則性を見出したり、問題の本質に辿りつくことができるようになります。
また、法則を見出すということは、それを転用することもできるようになります。これは、正解のないような未経験の分野への予測可能性も向上させることにつながります。
戦略的思考に不可欠な抽象化の視点
戦略をたてる際に、重要な視点は物事に優先順位をつけることです。
優先順位をつけるためには抽象度の高い視点で俯瞰し、複数の具体的な事象を同時にみて比較、評価をする必要があります。
たとえばチームAのあげる具体的な課題A、チームBのあげる具体的な課題Bがあるとして
「どちらも重要だよね。どちらもなんとかしよう」
というのは戦略的ではありません。
課題Aと課題Bどちらを先にやる？もし課題Aが解決したら、課題Bの状況はどんな影響をうける？課題Aと課題Bの根っこには課題Cがあるんじゃないか？
課題は相互に影響しあっています。
将棋やチェスをイメージしてみてください。駒を動かせば盤面の状況が変わります。
戦略的思考とは、盤面の棋譜と相手の手を読むこと。
一手攻められたからといって、そこを防ごうと右往左往してしまうのは抽象化ができていない表層的な問題解決とよく似ています。
頭隠して尻隠さず
角を矯めて牛を殺す
というような、悪手となる問題解決を避けるためにも抽象化をするということが重要になります。
問題発見の川上と問題解決の川下の違い
新しいプロダクトやサービスを生み出す際には、「そもそもなぜそれが必要か？」を問います。これは抽象度をあげる言葉です。
逆に、一度定義された問題を具体的なプロダクトやサービスに落とし込むときには、「どのようにして？」を問うことで具体化をすることが重要になります。
抽象度の高い川上と、抽象度の低い川下ではそれぞれ異なる価値観があります。
コンセプトを考える建築家と、それを施工する工事業者では、価値観や視点、「あるべき」とされる働き方が大きく異なります。
お互いが相手の領分に口を出し始めれば、それが折り合わないのは火を見るよりあきらかです。
このことを理解せずに、同じ土俵で議論してしまうと「どちらが正しいのか？」という不毛な議論に陥ったり、コミュニケーションギャップがうまれるようになります。
抽象度の高い川上では、少人数が個性を発揮して白紙の状態に全体像を描きます。個別の例外よりも原則が重視され、解釈に自由度があります。
抽象度の低い川下では、ある程度、定義された問題に対して、大人数で取り組みます。やることが具体的であり、秩序や計画性、均質であることが重視されます。解釈の自由度は制限され、例外に対して敏感になります。
座標軸と前提条件を理解すること
「上は抽象的なことばかりいって、現場のことをわかっていない」
「現場は不満ばかりいって、視野がせまくネガティブだ」
よく聞くこのような衝突も、具体と抽象の価値観、視点の違いによるものです。
重要なのは、具体と抽象という異なる視点があるということを知り、今行われていること、考えていること、問われていることはどの座標にあるのか？ということを判断する軸をもつことです。
また、抽象度が高い座標にあることを議論する場合には、前提条件を理解するということも重要です。
前述のとおり抽象的なものは解釈の自由度があります。
つまり、都合のよいように切り取って解釈することで、否定的な人は否定的に、肯定的な人は肯定的にとらえて批評することができます。
また、そのような恣意性がなかったとしても、とらえる人のバックボーンや知識によってその解釈は異なるものになります。
認識を揃えてより建設的な議論をすすめるためには、
「どういう条件のもとで」「どのような目的で」というような前提条件を理解していること が重要になります。
おわりに
プロダクトマネジメントは問題発見と問題解決。そしてステークホルダーとのコミュニケーションというように、まさに本書でいう具体化と抽象化を繰り返す仕事だと思います。
さらに、多くのテック企業が目指しているようなアジャイルな自律型組織であろうとする場合には、開発チームそれ自体が、具体と抽象の概念を理解して使い分けることが重要です。
プロダクトやサービス、そして組織の成長にしたがって具体と抽象の世界の距離は拡がり、大きな変革には衝突も起こりやすくなります。
本書で述べられている具体化、抽象化の能力はそのようなケースでもきっと役にたつのではないかと思いました。
おしまい
この記事が気に入ったらサポートをしてみませんか？