こんにちは、QAコンサルタントのODCオジサンです。今日は抽象と具体という、ちょっと変わった話をしたいと思います。
このテーマを選んだ理由
仕事中に提案書・報告書・会議の議事録などのたくさんの書類を眺めていると、これを書いた人はどうしてここまで細かく書いているんだろう？とか、ここもうちょっと詳しく知りたいんだけど丸められちゃってるな、と読み手としての期待とずれてしまっていることが多いと感じます。また、プレゼンテーションや発表の場でもしかりです。細かい説明にムダな時間を割いてしまって、肝心の本題に入れずに会議時間をオーバーしてしまうことってないでしょうか？
このブログでは「抽象」と「具体」という概念をもう一度見直して、「抽象」と「具体」を自由に行ったり来たりできるとこんないいことがあるよ、というのをお伝えしたいと思います。単に日常生活だけでなく、ビジネス全般やソフトウェアテストにも使えるよ、といった応用までいけるといいかなと考えています。前半は『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）（以下、細谷本）の内容をベースに、「失敗学」や不具合分析の例を加えてまとめていきます。
抽象と具体とは
抽象と具体とは、二つの対立概念です
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）
それぞれ辞書を引くと、
抽象：事物または表象からある要素・性質をぬきだして把握すること
具体：物事が、直接に知覚され認識しうる形や内容を備えていること
大辞泉
となっています。具体はまぁそうかなという感じですが、抽象は定義自体が難しいですね。
日常生活で抽象と具体という言葉が使われる状況を考えてみましょう。何かを説明するときに「具体的にどういうことですか？」とか「もう少し具体的に話してもらえますか？」ということってないでしょうか。「具体」にはわかりやすいイメージがあります。その一方で、「抽象」にはなんだかわかりにくい、難しいもののようなイメージがあります。「あの人の話は抽象的でわからない」のような場合です。
抽象と具体の特徴を表すと次のようにまとめることができます。
| 抽象 | 具体 |
|---|---|
| 直接目に見えない 実体と一見乖離している 分類してまとめて対応できる 解釈の自由度が高い 応用が利く 学者の世界 | 直接目に見える 実体と直結 一つ一つ個別対応 解釈の自由度が低い 応用が利かない 実務家の世界 |
なぜ抽象と具体が重要なのか？
抽象と具体がなぜ重要かについては「細谷本」から引用します。
社内勉強会などのイベントを何か開催するところを想像してください。イベント後に上司から次のような指示を受けたことはないでしょうか？
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）
- パターン1
- A「本は本棚に返して、お皿は食器棚に戻して、椅子と机は倉庫に返して….」
- B「要は片付けろってことですよね？」
- パターン2
- A「この部屋のものを片付けて」
- B「えっ、抽象的で何を言っているかわかりません。もっと具体的に言ってください。本やお皿はどの棚に返す、とか、総務部の誰に連絡すればよいのかとか…」
パターン1でAさんは「具体病」のように見えます。
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）
- すべて具体的事例がないと理解も実行もできない
- 言われたことをそのまま実行することしかできず、一切の応用が利かない
- 一度ルールや線引きが行われるとそれを絶対的なものと信じて疑わず、環境の変化に適応できない
会社の同僚や上司がみなAさんのようになってしまった場合を想像してみてください。
一方でパターン2でAさんは「抽象病」のように見えます。
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）
- いかにも賢そうに見える。べき論を語るのが好き
- 他人の行動・失敗に対して理想論でアドバイスするだけで実際にアクションすることがない
- ベストを尽くす、徹底的に強化します、など目標や施策がすべてあいまい
こちらはこちらで問題です。必要な問いかけをしても何も返してくれないので、それこそ途方に暮れるしかなくなります。一方で、何かを言うとまとめてくれそうなので、抽象化のレベルさえ合っていれば仕事が早く進みそうです。
これらの「抽象病」「具体病」ですが、いずれもどちらかに偏ってしまっているのが問題なので、うまく行き来できるようになるのが重要ということになります。
ではなぜ抽象と具体が重要なのでしょうか？
人間は新しい知識を獲得するごとに、それを個別の事象として記憶するか、他に応用できないか考えるクセがついています。例えば木に落ちる雷に一度でも遭遇したことのある人は、これはたまたま偶然だったのだと考えて、それ以上の分析をやめてしまう人が一定数います。一方で、雷はどういった場所に落ちやすいかを調べて、木の下を避けるとか避雷針を立てて雷を回避する策を考える人がいます。これが目の前の「木に落ちる雷」といった具体的な事象から、「雷の性質」という抽象概念に登れる人と登れない人の差になってきます。
具体から一度抽象に移り、再び具体に戻ることによって、人間は知の拡大を続けてきました。これを表すのが『知のピラミッド』（細谷本）です。
この『知のピラミッド』の具体例については「応用例」の方で述べますが、これを使って知識を拡大できないと、様々な知識を例え獲得できたとしても、単なるバラバラな事象になってしまい、膨大な具体的な知識の塊となって、人間の頭の中に入らないで捨てられてしまいます。抽象化と具体化を繰り返すことで、バラバラな事象から一定の法則や理論の形で知識を蓄えることができ、他の場面に活かすことができます。
これはあらゆる仕事にも当てはまります。抽象病や具体病に陥ることなく、抽象と具体を行ったり来たりできる人こそ、具体から抽象を吸い上げて、それを知識として蓄えることで活用できるので、真の仕事力を持っていると言えます。
では「抽象化」「具体化」について見ていきましょう。
抽象化
抽象化で一番大事なことは「目的のために必要な情報以外を取り除く」ことです。例えばリンゴで例えると、自分が仮にリンゴを販売したい農家だとして、売り上げを上げるために必要な情報はリンゴの「個数」「重さ」「糖度」などであって、その他の情報、例えば「販売経路」「梱包方法」などは実際に購入するときには必要かもしれませんが、「売る」という目的には直接は関係ないので取り除きます。こうして重要な情報だけを抜き出して構造化したものが「モデル」となります。
先ほどの片付けの例でいくと、「本棚に返す」「食器棚にしまう」「倉庫に返す」の共通点を見つけていきます。そうすると、何かを本来それが合った場所に戻すらしいぞ、となって「片付け」という上位概念がでてきます。
これはAならばBの関係になっているので（本棚に返す→片付け、食器棚にしまう→片付け、倉庫に返す→片付け）、is-a関係と呼ばれます。
こうした「一言で述べる」以外に抽象化で使えるテクニックを細谷本から抜粋します。
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）※筆者加筆
- 自由度を上げる：一部を変数にしてみる（「タンメン」を食べる→「ラーメン」を食べる）
- Whyを問う：因果関係を考える
- 全体を俯瞰する：隣との関係性でなく一歩上の視点に立つ
具体化
具体ばかり述べる人は必要ないような話をしてしまいましたが、実は抽象化した後に具体化しないと、何も実行できなくなりますので、実は具体化も重要です。抽象化も具体化もバランスが取れていることが大事です。
先ほどの例だと「片付けろ」だけでは具体的に何をどこに移動させるかが示されていないので、その場にいる人に聞いて動かすものを指定してもらいます。あるいは手順書に何か書かれているかもしれません。
具体化のテクニックを細谷本から抜粋します。
『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）※筆者加筆
- 自由度を下げる：変数に具体値を当てはめる（例：「ラーメン」を食べる→「タンメン」を食べる）
- Howを問う：実現手段を考える
- 数字と固有名詞にする：ダイエットしなさい→「オートミール」を朝に100グラム食べなさい
モデリングの世界ではhas-aという関係を使うと具体化できます。例えば「車」はさまざまな部品でできていますが、「車」という製品を作るには個々の部品を考えて設計製造する必要があります。
プロジェクト管理の世界では「WBS(Work Breakdown Structure)」というものがありますが、あれもhas-aの関係で成り立っています。「要件定義」には「顧客要求の引き出し」「要件定義書作成」「要件レビュー」などが含まれる、のように大きなプロセスを個々のアクティビティやタスクに分解していきます。これも具体化の事例です。
抽象と具体の応用例①
抽象と具体を行ったり来たりできるようになるとこんなことができるようになるという事例です。『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之）（以下、濱口本）より引用します。
とある病院で、看護師が入院患者AさんとBさんを食堂に連れて行き、食前薬を渡すときにAさんにBさん用の薬を渡してしまった。そうなるとBさんの薬が見当たらないので薬局に探しに行っている間にAさんがBさんの薬を服用する直前で防止できた。
『失敗学 実践編: 今までの原因分析と対策は間違っていた!』
（濱口 哲也、 平山 貴之）
という事例です。未然防止はできていますが、一つ間違えると人命に関わるヒヤリハットです。
この事象の再発防止策として、抽象化を行わないと「名前と薬の確認を徹底する」や「本人を示すタグと名前を照合することを徹底する」というのを思いついてしまいます。そうするとこの病院の特定の病室や、似たようなシチュエーションでしか使えない単なるチェックリストになってしまいます。
これを1段階抽象度を上げると、格段に応用の利くものになります。
AさんとBさんの区別が付かなくなったことと、それぞれの薬の区別が付かなくなったことの両方の事象を一歩上から見ると『本体とラベルを分離すると識別不可能』（濱口本）となります。つまり、Aさん本人と、ラベルを示すもの（名前を聞く、タグを確認する）を切り離してしまうと、区別がつかなくなるのでかならずセットにした状態を保ちましょう、ということになります。
これは応用範囲が広いです。例えば、最近の病院では患者を間違えないために患者の足にタグのようなものを付けると思いますが、それはここから来ています。また、人工授精後の受精卵は、シャーレの蓋に名前を書くだけでは蓋を取った途端に区別が付かなくなってしまうので、シャーレの中身（培地）の方に名前を書く（または識別可能なものを置く）、となります。
抽象と具体の応用例②
ソフトウェアテストの現場から、テストで検出した不具合を分析する例を見てみましょう。
車載オーディオ製品で、その製品の仕様上聞けてはいけないはずの特定地域の放送局（A局）が聞けるようになっていました、という不具合がありました。聞けたわけですから、製品品質としては悪くないわけです。テストベースとした仕様書がA局は聞けることになっていたため、それを使って設計したテストでは合格となっていました。ところがマーケティングが後から横やりを入れてきて、結果的に欠陥という扱いになりました。
この例を抽象化してみましょう。「ビジネス要件をきちんと分析していなかった」→「ビジネス要求が最優先」→「より優先度の高い要求に上書きされる」。
これを他の例に当てはめてみましょう。昨今ソフトウェア開発は新規より派生開発が増えています。新規機能や改変対象の機能については、要件定義・設計・コーディングまでしっかりとトレーサビリティを確保しながら開発を進めることが多く、またそういったトレーサビリティを確保するための方法論がいくつかあります。ところが新規機能や改変機能に気を取られて、隠れた要求の変化に気がつかないケースがまれにあります。そうした変化した要求が残っていないか、あるいは時間の経過とともに新しい要求が発生していないかをレビュー観点として残し、設計レビューで活用することは未然防止として意味があります。「より優先度の高い要求に上書きされる」という抽象化された法則を、ソフトウェア欠陥を防止する目的で使う例として挙げさせていただきました。
まとめ
抽象と具体について、事例を交えて説明してきました。具体的な事象を我々は普段目にしているわけですが、そこから抽象化して本質を見極めるにはある程度訓練が必要です。身近なものに対しても、これは一体どういうことだろう、というように一歩上の視点から眺める訓練をしておくと、仕事にも役立ちますので一度試してみてはいかがでしょうか？
出典
- 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）
ISBN-13 : 978-4569845999 - 『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之）
ISBN-13 : 978-4817195999 - 『大辞泉』（小学館）
ISBN-13：978-4095012131
