PMstyleプロデュース

◆抽象的はダメ？！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆抽象化のレベル

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

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

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

「２週間前まではスケジュール通りだったのですが、まず、２週間前にＡさんの関連作業が遅れはじめ、２月１日からこちらの××工程にも影響が出てくるようになりました。１日にはＡさんのＹ１作業が遅れたため、工数Ｘ１の作業Ｘ１が積み残し、２日はＸ１はクリアしましたが、私の体調が悪くて早く帰ったのでできる予定だったＸ３が積み残しになりました。３日はＸ３の積み残しを処理し、Ｘ４に着手しようとしましたが、ＡさんのＹ３作業が遅れ、結局積み残しました。
（中略）
昨日はＸ８は終わりましたが、Ｘ１１が残っています。以上が遅れが出始めてから昨日までの経緯です」

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

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

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

◆抽象化の２つの特徴

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

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

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

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

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

２月５日の１日の遅れ
　⇔　作業Ｘ１の遅れ工数○時間
　　　作業Ｘ３の遅れ工数△時間

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

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

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

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

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