猿神大学

数学についてあまり書きません。

桃太郎の歌に思う「階層構造」的思考

目次

 

序論

 

謝罪

 

こんにちは。

三角関数ちゃそです。

 

このブログには、たまにコメントをくれる『ごはんだいすき』さんがいます。

 

 『ごはんだいすき』さんは、ブログにM1グランプリ出場者が現れると、その出場者のネタをかませたコメントを書いてくれてしました。

 

野田クリスタルみたいに、ゲーム作りながらプログラミングの勉強をしようかな」みたいな記事の時は、マヂカルラブリーに合わせたコメントをしてくれました。

 

しかし、最近はこんな有様です。

 

なぜ、彼がこんな風になってしまったのか?

 

原因を考えてみたところ、最近僕がM1グランプリの芸人をブログの話題に出してないことが原因なのではないか?と思うようになりました。

 

上記ツイートでは「クオリティを維持できないなら無理する必要ないぞ」と辛辣に扱ってしまいましたが、僕が『ごはんだいすき』さんを追い詰めていたのかもしれません。

 

この場を借りてお詫び申し上げます。

 

『ごはんだいすき』さん、大変申し訳ありませんでした。

 

というわけで、今日のM1芸人は…?

 

今日は、ウエストランドのネタ「桃太郎」を見て、思ったことを書いていきます。

f:id:sarugami_univ:20210430172119j:plain

芸人に品行方正を求めんなよ!

結構まじめな記事にする予定です。

 

www.youtube.com

 

※以下、このネタの展開に関するネタバレを含みます。

 

 

 

「桃太郎」のネタについて

 

このネタは、童話としての「桃太郎」と、童謡としての「桃太郎」の構成の差が激しすぎるという着眼点から進んでいきます。

 

ja.wikipedia.org

 

童話「桃太郎」では、

 

  1. 大きな桃が流れてきて、赤ん坊が生まれる
  2. 赤ん坊が鬼退治に出かける
  3. 犬や猿、雉と言った家来を従えて鬼と戦う
  4. 鬼を退治してハッピーエンド

といった起承転結がありますが、童謡「桃太郎」では、

 

  1. 桃太郎さん 桃太郎さん お腰につけた 黍団子 一つわたしに 下さいな

 

といったところから始まります。

 

そうなんです。

童謡「桃太郎」では

 

「桃太郎がなぜ桃太郎なのか」

 

というアイデンティティに迫る、童話の前半が相当カットされています。

 

童話から作成される目次と童謡から作成される目次の間には、大きなギャップがあるわけです。*1

 

f:id:sarugami_univ:20210430165859j:plain

童話「桃太郎」。

f:id:sarugami_univ:20210430165918j:plain

童謡「桃太郎」。


 

ところで、ウエストランドの漫才の中では、童謡「桃太郎」がネタにされていましたが、仮にこれが仕事だったら…と思うと、ヒヤッとします。

 

何か問題があった時、前半がカットされた状態で上司に報告したら、全貌が見えたときにすごく怒られそうですよね。

「なんで全部報告しないんだ!」みたいな。

 

あと、数学書とか買ったとき、その中身が童謡「桃太郎」的な感じだったら、嫌ですよね。前半の定義や補題がカットされている状態で、主定理の証明を読んでも理解が難しいと思います。

 

童謡「桃太郎」は、ウエストランドの手によって見事笑いになりましたが、フツーの場合では、童謡「桃太郎」と同じ構成のものは笑いにならないわけです。

 

以下、この記事では『童謡「桃太郎」のような事態を避けるために、何を意識すればよいか』を考えていきます。

 

(今回も主観です。)

 

本論

「階層構造」として事象を眺める

私は、学生時代は数学に、社会人になってからはプログラミングに触れてきました。

 

この2つの対象には、頻繁に「抽象」といった言葉が出てきます。

  • 関数やオブジェクトをどう抽象化するのか。
  • 定理や性質をどう抽象化するのか。

といった観点で「具体」と「抽象」の間に階層を作成するわけです。

 

この「具体」と「抽象」の間にある階層構造を揃えることは重要です。以下のようなメリットがあるからです:

  1. 似た構造の事象が見えやすい。
  2. 抽象度のレベルがつかみやすい。
  3. 全体の構成がわかりやすい。

 

…といってもいまいち説明が難しいので、具体例を引っ張って説明を行おうと思います。

 

アルバムを例に「階層構造」を考える

例えば、「卒業アルバムを作成することになった」といったシチュエーションを考えてみましょう。

スタート時点では、様々な時系列・イベントの写真が1つのフォルダに混在している状態だとします:

f:id:sarugami_univ:20210430165926j:plain

ここから仕分けるぞ。

 個人的には、よい階層構造とは、「○○を探して!」と第三者に依頼したとき、その第三者が階層構造を推測しながら目的のものを発見できる状態だと思います。

フォルダ構成が適切な観点でしっかり階層化されている状態ですかね。

 

 この状態では、仕分けがされてなさ過ぎて、よい階層構造とは言えないでしょう。

 

で、どうやって階層構造を作るか。

 

今回は、卒業アルバムという例なので、イベントに着目して階層構造を作ってみましょう。

f:id:sarugami_univ:20210430165935j:plain

イベントごとに分ける。

この時点で、最初にあった写真はイベントという観点で抽象化された状態です。 

写真はほかにも時系列で分けることができるので、それでも分けてみましょう。

今回はせっかく「卒業アルバム」という概念を利用しているので、時系列の中でも学年ごとに分けるものとします。

f:id:sarugami_univ:20210430165953j:plain

卒業アルバムなので学年でわける。

 

ここまでの流れで、

  • イベント
  • 時系列

といった2つの観点から写真が分類され、フォルダの抽象度が一律にそろうわけです。

 

フォルダ構成とは階層構造そのものですから、「よいアルバムをつくる」みたいな視点で事象を眺めることで、その「具体」と「抽象」の間に適切な階層構造を構成できるわけです。

 

では、アンチパターンを見ていきましょう。

階層構造が同型でない

f:id:sarugami_univ:20210430170015j:plain

高3だけなぜか階層構造が異なる。

 高3だけ上期・下期の階層が入っています。これによって、高1・高2の階層構造とは、対称性・一様性を失ってしまっています。

 

数学だと、「ある整数より大きい場合は、性質が異なる!」という問題も多いですが、それは性質に対して「成立する・成立しない」という対称性を有しているので、上記の階層構造とは異なります。

 

抽象化する観点に統一感がない

f:id:sarugami_univ:20210430170026j:plain

それぞれの観点が異なっている。

高1は月、高2はイベントで分類を行っています。

高3も高1同様に時系列で分類はしているのですが、時系列と言っても「学年」「期間」と様々であるため、一様性が崩れています。

抽象度が異なるレベル感で伝わっているときは、お互いの観点が異なる定義である可能性もあるわけです。

 

そもそもの観点が客観的でない

f:id:sarugami_univ:20210430170032j:plain

それってあなたの感想ですよね?

主観による階層構造は、他者に伝わらないでしょう。

そもそもプログラミングには階層原理がある

先ほど、フォルダ構成を例に「階層構造」的思考を説明しましたが、プログラミングの場合について考えてみましょう。

 

以前の記事でも説明したのですが、プログラミングの原理原則には、階層原理なるものが存在します。

 

sarugami-univ.hatenablog.com

 

プログラミングでは、抽象度に関して階層を考えることが原理とされています。

 

例えば、Javaにはpackage、C#にはnamespaceといった概念があるのですが、これはフォルダ構成を反映していますし、MVCモデルやクリーンアーキテクチャではフォルダごとに一様性や対称性を持たせてコーディングをするのがよい設計だとされています。

 

「階層構造」的思考をもってプログラミングの設計を行えば、

  • 階層原理
  • 対称原理
  • 同型原理

をある程度担保できるかもしれません。

プログラミングの設計と聞くと敷居が高いように見えますが、要件に現れた機能やオブジェクトをフォルダに仕分けると思うと、多少は楽です(個人の感想です)。

 

f:id:sarugami_univ:20210430170053j:plain

例えばこんな感じ?

名書の目次は読みごたえがある

技術・学術的な名著は、目次がよい階層構造になっていることが多いように思います。

目次を読んで、全体の流れがわかりやすいです。

 

f:id:sarugami_univ:20210430170116j:plain

目次

逆に、個人的に読みにくいと思った本の目次は大体こんな感じです:

ジャンルわけくらいしろよ

f:id:sarugami_univ:20210430170125j:plain

階層が浅いのは、一般性がないことの裏付けでは。

「社会人が守りたい○個の法則」みたいなクソビジネス本に多い印象です。多分、「全部大事だからあえて階層構造をつけない!」みたいなスタンスなのでしょうが、せめてジャンル分けくらいはしないと、欠陥であるだけだと思います。

各階層のパワーバランスおかしくない?

 

f:id:sarugami_univ:20210430170153j:plain

主観が混ざってるんだろうな。

プレゼンや講演など、時間が限られた中で第三者に何か物事を伝えるときには、こういった階層をつける話し方は大切だと思うのですが…

本、それも学術書や技術書で、さらに「わかりやすい!」と銘打った入門書とかで、こういった偏りがあるのは、なんだかなあと思います。

その他

ところで、目次というのは本のガイドラインです。他のガイドラインにも、よい階層構造を意識することで、よいものが生まれるのかも?と思ったり。

 

例えば、仕事の作業工程なんかは、まさしくガイドラインだと思うのですが、ウォーターフォールは対称構造を、アジャイルは同型構造を重んじた階層構造なんですかね。知らんけど。

 

他にも、居酒屋のメニューとかも、いい階層構造のお店がありますよね。

「お酒」と「定番」の両方に「生ビール」を入れているお店は、すてきだと思います。

結論

「階層構造」的思考を持つことの意義

  • 抽象のレベルを調整する上で、「階層構造」的思想が役に立つ。仕事や役割をフォルダに分けるような意識で事象を眺めるようにすることで、適切な抽象度を設定できる。
  • プログラミングの階層原理・対称原理・同型原理を担保するために、「階層構造」的思考をもって、要件を分析する。
  • 何か他者に説明するときや作業工程を建てるときに、「階層構造」的思考を有して流れを考える。

最後に

思ったより真面目な記事になってしまったのですが、個人の主観なので、「ほえー」と思ってください。

 

別のこの記事もきれいな階層構造じゃないですし(今回の記事では、冒頭に「目次」を付けてみたのですが)。

まあ、途中でも述べたんですけど、話すときやブログくらいは、階層構造を多少崩して書きたいこと・伝えたいことをはっきりさせる方が面白い文章になるかもしれませんね。

 

数学やプログラミングに対して、こういう観点で物事見ていけたらいいな、という個人のメモだと思って読んでください。

 

あと、「普段クソなブログ書いているのに、GWになって急に何で真面目っぽい記事ばかり書いているの?」という意見があると思うのですが。

 

GWに入ってから、祝日最高!という気持ちになっています。

 

文化人になることで、

 

毎日文化の日、毎日休日にならねえかな

 

と思って生きるようになりました。

 

どうか、現実になりますように。

 

完。

 

*1:今回の階層構造の図は以下を参考にLaTeXで作成しています:

qiita.com

PDFを画像に変換するのは、自分でつくったプログラムを使用しています。