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

カテゴリ

Powered by Six Apart

« 【プロデューサーの本棚】エッセンシャル思考 | メイン | 【PMstyle Proposition:002】チームでいいアイデアを出す方法 »

2015年2月17日 (火)

【コンセプチュアルスタイル考】第10話:5つの軸について考える~抽象的であることは悪いのか?

バックナンバー https://mat.lekumo.biz/pmstyle/cat9984019/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Tyuusyo1

◆はじめに

久しぶりのです。

前回までに説明しましたように、PMstyleのコンセプチュアルスキルはコンセプチュアル・シンキングと呼んでいる5つの軸を使った思考が中心になっています。この5つについて、いろいろな視点から考察してみたいと思います。

第1弾はコンセプチュアルスキルの中核になっている抽象と具象です。


◆抽象的はダメ?!

よく抽象的なのはダメだといわれます。なぜでしょうか?

PMstyleの「コンセプチュアルスキル入門」講座では、このテーマでアイスブレークをやっていますが、出てくる意見は

・何を言っているのか分からない
・人によって言葉の意味や解釈が違う
・アクションに結びつかない

といったものが多いようです。

ところがそのグループに業務の企画や、経営企画を担当している人が入っているとちょっと風向きが変わってきます。「そもそも、抽象的であることがどうして悪いの」となるわけです。

抽象的なことが悪いというのが現場的な価値観で、経営スタッフや企画スタッフの価値観はそうでもないようです。

ここまで読んでコンセプチュアルスキルの高い方はお気づきになったと思いますが、抽象的であることが悪いとか、具体的がよいといった価値観は絶対的なものではありません。


◆抽象的な思考が必要な場合

つまり、抽象的であることが必要な場合もあるわけで、何がよいか、何が悪いかはその業務の目的次第だということです。

たとえば、製品開発において具体的な議論からは改善しか生み出しません。具体的な視点だけで無理やりいろいろ知恵を絞った結果、ガラパゴス製品が生まれました。少しだけでも現行製品の本質的な機能や価値という抽象的な特性に注目し、そのレベルでどう変えるかを考えていれば、ガラパゴス化はしなかったでしょう。

あるいは、顧客や市場のいうことを具体的な要求をして受け入れ、全然売れない製品や、最後にドン伝返しのシステム開発というのもよくある話です。これも顧客の要求の本質を見抜き、仕事を進めていれば避けれたことです。


◆「納得する」ことと「理解する」ことは違う

このような事例を考えてみると、具体的であることがよいというのは必ずしも正しくありません。ただし、具体的であれば分かりやすいし、考えやすいことは確かです。だから納得しやすいのですが、問題は納得することと理解することは違うということです。

たとえば、スマートフォンの画面への要求をWQHDの解像度と聞けばすっきりして納得してしまいますが、これで顧客の要求を理解したことにはなりません。顧客の要求は、なぜ、WQHDなのかにあるわけで、たとえば「写真をリアルに見たい」とかいったところにあったりします。

これはかなり抽象的ですが、ここでリアルとはどういうことかを真剣に考えないと要求は理解できません。これをうまくやっているのがiPhoneです。

最悪なのは、理解していないけど、納得してしまったというケースで、上に述べたような状況を引き起こすわけですが、このような状況を生み出しやすいのが具体的にしか考えないことだと言えます。

ただし、製品やシステムは最終的には作らなくてはならないわけですので、その要求やスペックは具体的でなくてはならないことも紛れもない事実です。

この矛盾をどのように考えればよいのでしょうか?


◆抽象化のレベル

この問題を考える前に、もう一つ、例を挙げてみたいと思います。

たとえば、あなたのマネジメントしているプロジェクトでメンバーから「作業スケジュールが遅れている」と口頭で報告されたとしましょう。そのときあなたはたぶん、「もう少し状況を具体的に教えてください」というでしょう。

そうお願いしたら、メンバーは、(ちょっと長いですが、真剣に読んでください)

「2週間前まではスケジュール通りだったのですが、まず、2週間前にAさんの関連作業が遅れはじめ、2月1日からこちらの××工程にも影響が出てくるようになりました。1日にはAさんのY1作業が遅れたため、工数X1の作業X1が積み残し、2日はX1はクリアしましたが、私の体調が悪くて早く帰ったのでできる予定だったX3が積み残しになりました。3日はX3の積み残しを処理し、X4に着手しようとしましたが、AさんのY3作業が遅れ、結局積み残しました。
(中略)
昨日はX8は終わりましたが、X11が残っています。以上が遅れが出始めてから昨日までの経緯です」

と答えたとします。十分に具体的な報告だといえますが、あなたはこの報告を聞いて状況を分かったと思えますか。

おそらく多くの人はこの報告を聞くとよく分からず、A4で1枚に図か表で書いてくれというのではないかと思います。このように具体的であること=分かりやすいというのは思い込みで、あまりに具体的過ぎると理解も納得もしにくく、少し抽象度を上げて、1つの図とか表にしてくれと言いたくなるわけです。その方が分かりやすいからです。

これも抽象と具体のもたらす矛盾だと言えます。


◆抽象化の2つの特徴

さて、これらから何がいえるのでしょうか。二つあります。

一つは、抽象度には適切なものがあるということです。そして、その適切さはその情報を使う目的によって決まってきます。つまり、上に述べたように企画と開発では求められる抽象度が違いますし、進捗報告であれば進捗を理解するのに適切な抽象度というのがあるということです。たとえば、上の進捗報告であれば

「2月1日にちからはAさんの作業待ちになり、2月5日にはほぼ1日の遅れ、その後も少しずつ遅れていき、昨日時点でほぼ3日の遅れになっています。」

と説明すれば進捗管理をしたい人はほぼ必要な情報が手に入りますので、適切な抽象度だといえます。

もう一つは、こちらがより大切なことですが、抽象的だけではだめであるのと同じように、具体的なだけではだめだということです。たとえば、進捗であれば


2月5日の1日の遅れ
 ⇔ 作業X1の遅れ工数○時間
   作業X3の遅れ工数△時間

というふうに抽象と具体を常にセットで考えておくことが大切なのです。

◆コンセプチュアルスキル講座のご案内

PMstyleではコンセプチュアルスキル講座を開催しています。

レベル・分野に分けていくつかの講座を開催していますが、今回ご紹介するのは、コ
ンセプチュアル思考の講座です。

━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ◆コンセプチュアル思考~見えないものに挑む思考法      ◆(7PDU's)
  日時:2015年 07月 31日(金)10:00-18:00(9:40受付開始)   
  場所:銀座ビジネスセンター(東京都中央区)
  講師:好川哲人(エム・アンド・ティ コンサルティング代表)
  詳細・お申込 http://pmstyle.biz/smn/conceptual_thinking.htm
  主催 プロジェクトマネジメントオフィス、共催:PMAJ
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  【カリキュラム】                     
  1.思考をコンセプチュアルにする思考法
  2.思考をコンセプチュアルにする思考ツール
  3.コンセプチュアルな思考を妨げるもの
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

コメント

コメントを投稿