猫の抽象化

本エントリを書こうと思った動機

リリカルさんが、2017年12月4日に、

結局なんの話をしていても行き着く先は抽象度の上げ下げの技術なんでしょっていうのが最近おもってることです

とツイートしました。
~~煽り方が、~~テーマの出し方が、上手いですよね。

このツイートを読んで、「そうかもしれないし、そうでないかもしれないなぁ」と思いました。そこで『猫の抽象化と、ドラえもんのモデリング』という事例を考えてみました。

※　このお話は、続 テストガールRINA（指教編）で、まりまりが講義するはずだったのですが、予想外に長くなってしまったので、こちらに持ってきました。
でも、「小ネタ」にするには重いので、前半の『猫の抽象化』に話を絞ります。リリカルさんのツイートでもモデリングには言及していませんし。←言い訳

※ 『ドラえもんのモデリング』の方は、“ドラえもん”をUMLのクラス図、コンポーネント図、ユースケース図、状態遷移図、アクティビティ図、コミュニケーション図に、モデル化した話（要は代表的なUMLのダイアグラムの描き方紹介）でした。

1. 抽象化技術との出会い

リリカルさんがいう「抽象度の上げ下げの技術」は、まとめていえば「抽象化技術」のことだろうと思います。
私が「抽象化技術」に興味を持ったのは、2010年のことです。比較的最近ですね。

2009年1月29日（木）。JaSST'09 Tokyo 2日目のクロージングパネルで、そのころ、テストを頑張っていた人たちが各々のやり方を紹介しました。
そのパネルで、にしさんは、『テスト観点に着目した　テスト開発プロセス(VSTeP)の概要』と題して『テスト観点』の説明をされました。ちなみに、智美塾が生まれたきっかけとなったパネルです。

翌年の2010年のこと。IPA/SECの『高信頼化のための手法　WG』に呼ばれた私は、みっきーさんと、にしさんと一緒に『高信頼化ソフトウェアのための開発手法ガイドブック』の、『第6章　テスト網羅性の高度化技法』という章を担当しました。
並行して智美塾でも似た議論をしていたのですが、当時は、

にしさん「テストを大項目・中項目・小項目って3段階に分けてExcelで書く人が多いけど、＊いつも必ず＊3段階に固定するなんてできっこないので、例えば、本当は5段階のものを3段階にギュッとまとめたりすることになるよね。
「１，２，３，４，５」を「１(2)(大)，３(中)，(4)５(小)」とかさ。そうすると、２と４については見えにくくなっちゃうから検討が不十分になってテスト漏れが発生しちゃう。」

まぁ、古い話なので記憶違いかもしれないけど、私はこの話を聴いて感動したのです。「これがテスト漏れの原因だったのか！！」って。

にしさんは続けます。

にしさん「固定の大項目・中項目・小項目に合わせ込むんじゃなくって、丁寧に一段ずつ“テスト観点”を段階的に詳細化する（ときには上に遡り正しく詳細化できていることをチェックしながら進む）ことが重要だと思うんだ。」

って。

※　上記が「NGT/VSTePの根っこの考え方」だと私は思っています。

そして、この段階的詳細化の逆が（段階的）抽象化（＝抽象化技術）となります。つまり、詳細化と抽象化は、「詳細化：トップダウンに分割する」か、「抽象化：ボトムアップに綜合する」かの違いだけで、どちらも対象を理解するための手法です。
ですから、詳細化と抽象化のどちらかにこだわる必要は無く、行きつ戻りつしながら行うものです。上に書いたように、にしさんが「ときには上に遡り正しく詳細化できていることをチェックしながら進む」と言ったのはこのことかなと思います。

2. 猫の抽象化

さて、具体例で確認していきましょう。ペットショップに行って様々な猫を100匹買って来たとします。1匹5万としても500万円にもなるのでそんなヤツはいないけど。まぁ、頭の中で想像するだけならタダです。

さて、100匹もいると、分類したくなります。血統で分類するなら、三毛猫、‎ペルシャ猫、アビシニアン、アメリカンショートヘア、、、サーバルちゃんはネコかしら？
それとも色で分けちゃう？　黒猫、白猫、灰色ネコ、茶ネコ、、、赤毛とかあったっけ？
柄というのもあるよね。ぶちネコ、ハチわれ、トラネコ、、、ポイントとかは柄でいいの？

実は、今挙げた三毛猫、ペルシャ猫、アビシニアン、アメリカンショートヘア、サーバル、黒猫、白猫、灰色ネコ、茶ネコ、赤毛、ぶちネコ、ハチわれ、トラネコ、ポイント、これらは全て、買ってきた100匹の猫（と、それに加えて想像しただけの猫もいるかもしれないけれど、それら）を抽象化したものです。

それぞれの猫が「持っている性質」のなかで、複数の猫が「共通して持っている性質」を取り出すことを『猫の抽象化』といいます。
ここで、ちょっと難しい言葉を使いますが、「（ある概念……今の例では分類後の猫のグループ……が）共通して持っている性質」のことを「内包（ないほう）」といいます。
このページの一番下に、『猫の抽象化』結果をツリー構造であらわした図を載せましたので参照ください。図をみると“猫”を分解したように見えますが、買ってきた実体として存在する（具体的な）猫を抽象化した結果である点に注意してください。
※　分類してから分類したときに使った関心事を内包として取り上げて言葉にするのか、先に関心事として内包を見つけて言語化した結果を用いて分類するのかについては、哲学的な問いとなりますのでここではパスします。興味のある人は廣松渉の本を5冊くらい読んでみてください。

今確認したように『猫の抽象化』は『猫の内包を取り出すこと』と言い換えることができます。
猫を分類したいときには「共通した性質」、すなわち内包に着目すると便利です。でも、「共通していない性質 = 不要な内包」を捨てるほうが簡単な場合もあります。
※　分類する目的が決まっている場合は目的外の特徴を捨てるほうが早いことがあります。

ここで、何かの特徴を捨てることを捨象といいます。捨象していって残ったものは抽象したものと同じですから、「抽象化するときには何を捨象するかを考えろ｣とアドバイスする人もいます。

3. 抽象化とテスト要求分析

何かを分析するときに、抽象化技術が良く使われます。テスト要求分析も同じです。
日本国語大辞典によれば、分析とは、

もつれている事柄や複雑な事情を、一つ一つの要素や性質に分けること。

とあります。
このページの一番下の図の『猫の抽象化』結果の右側にCIBFWという「テスト観点の種類」をツリー構造で描いたものを載せました。テスト要求分析という活動で、テストしたい関心事（テスト観点）を種類わけするときの大きなカテゴリーの一つです。
にしさんによる「テスト観点はふんわりね」というアドカレ記事中にある「テスト観点の種類」をもとに勝手に図化したものです。同記事に、

別にこのCIBFW、“条件（Condition）”、“テスト対象（test Item）”、“ふるまい（Behaviour）”、“嫌なこと（things Faulty or hazardous）”、”世界（World）”にいつも分ける必要はありません。自分がテスト設計の時に意図することを好きなだけ入れて、整理してやればいいんです。

とあるように、必ずこの種類に分割しなさいということではない点に注意してください。例えば、HAYST法では6W2Hというフレームワークを用いてテストに対する関心事を分析しています。

4. 抽象化と一般化

抽象化と似た言葉に一般化というものがあります。
例を挙げてみます。

• リンゴとミカンを一般化すると果物
• ご飯とパンを一般化すると炭水化物を多く含む食物
• サンマとサバとイワシを一般化すると青魚

などなどです。さらに上に挙げた7つの概念を『食べ物』に一般化できます。
ところで、「サンマを抽象化したものを青魚と呼ぶ」といえそうな気がします。一般化の多くは抽象化と呼んで構いません。少なくとも先に上げた3例はOKです。
きちんと言葉で定義するなら、『例示したもの（例：リンゴとミカン）に共通した上位概念（例：果物）を導くこと』を一般化といいます。上位概念は、例示した各々に内包しているものですから、その意味で、一般化と抽象化は同じです。

抽象化と呼べないものとしては、「体重を変数Wとする」といった、『何かを記号に置き換える』一般化です。また、『概念を広げて普遍的に適用する』意味の一般化も抽象化とは違います。「一般相対性理論」は「特殊相対性理論」の抽象化とは違います。
※ 特殊相対性理論の本質を抽出してその概念を拡大した意味で抽象化に近いものですが。

まりまり「もうお腹いっぱいです。」¹

おしまい

1. まりまりは、めんどくさいのが大きらいである。 ↩