Posts for: #Go

七夕と願い

#founding  #management  #issue management  #go  #design 

23時に寝て2時に起きて6時に起きた。旅行から帰ってきてから最近はこのパターンになってきた。

google のロゴが Tanabata 2023 になっていて七夕だと気付いた。もう私にとって願いというのは健康を祈るぐらいしかない。残された寿命を使い切る前にいまやっていることをやり切りたい、もしくはその結果をみたいと思っていて、そのために必要なことは健康ぐらいかなと。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

他社の社員旅行へ同行してみての所感として学ぶことは多々あった。

  • 強制参加にはしない (断ってもよい)
  • 仕事だけではない人間関係の構築という価値観を大事にしている
  • 上下関係がフラットなので参加者が自由に行動したり話したりできる
  • 経営陣や上司に忖度しないメンバーがいることでフラットな関係性を共有できる
  • チーム単位で行動できるので組織の全体行動を強制される感覚が緩和される

野中郁二郎先生は業務外での暗黙知を共有する「場」づくりが大事だと説いている。会社が危機のときやしんどいお仕事をこなすとき、最後は経営者やリーダーの人生観や価値観がモノを言うという考え方がある。そんなときにこういった価値観の共有は役に立つのかもしれない。「社員旅行」という単語自体が古い価値観をイメージしてネガティブに聞こえる。いまだったらワーケーションと呼ぶ方がよいかもしれない。

過去にスタートアップで働いていたとき、会社が M&A で売却して、私にとってはあまりメリットがなかったので即断で辞めると伝えた。即断できたのは経営者に理念がなかったからというのも大きな要因の1つだといまになって思える。時期の差はあれど、私以外の主要メンバーもその後に全員辞めた。要はそういうこと。

go の generics 勉強会の準備

水曜日から資料を作っている。昨日はほぼまる一日コードレビューをやっていた。午前中の半日を費やしてようやく完成した。この資料は一般の go 勉強会でも使えるなと思ったのでお手伝い先のプロダクト開発に関するところを取り除いた資料を別途公開した。資料の中でその内容を検証するサンプルコードも次のリポジトリで公開している。

go の generics 勉強会へ向けての準備

#go  #design 

0時に寝て6時に起きて7時に起きた。週明けから忙しくて余裕ない。それでもよく眠れていることが幸い。

go の generics 勉強会の準備

今週末の金曜日に勉強会をする想定で作り始めた。generics は難しいのでなかなか本腰を入れて取り組めていなかった。基本的には tenntenn さんの プログラミング言語Go完全入門 15章ジェネリクス（型パラメタ） の資料をベースに、自分で理解できるように調査したり、サンプルコードを書いたり、自分で理解した内容を補足したりして資料を作り始めた。go 1.18 のジェネリクスで導入された概念は次になる。これらのキーワードに関するところをそれぞれ調べることにした。

  • 型パラメーター
  • 型引数
  • インターフェースによる制約 (Type constraint)
  • 型セット (Type sets)

リフレクションにはまった半日

#go  #ldap  #mongodb  #reflection 

23時に寝て5時に起きて6時半に起きた。ストレッチで伸ばしたせいか、いつもよりよく眠れた。先週は主に旅行へ行っていて非日常でリフレッシュした。今朝は朝ご飯に野菜サラダを作って食べて7時半には家を出れた。

非同期の ldap 検索の api

先日送った go-ldap の pr を完了した。送ったときはチャンネル用いた検索 api だったのだけど、それから設計を議論して非同期検索を主とした api として生まれ変わった。レビューに1ヶ月を要したものの2人のメンバーから approve をもらって無事にマージされた。

この一歩は大きくてこの機能を突破口にうちらの要件に足りない機能を実装していく。プロトコル部分の修正が過去の draft 実装から参考にできるのであれば今週中にはまた pr を送りたい。

mongodb の unmarshal 実装

mongodb-driver での bson の marshal/unmarshal を実装する。mongo-driver/bson に unmarshal について2つの interface が紹介されている。

type Unmarshaler interface {
	UnmarshalBSON([]byte) error
}

type ValueUnmarshaler interface {
	UnmarshalBSONValue(bsontype.Type, []byte) error
}

bson の byte 列を unmarshal するにあたり、構造体そのものには UnmarshalBSON() を、構造体のメンバーには UnmarshalBSONValue() を使う。これでうまくいきそうに思えたのだけど、interface を介したデコード処理で意図した振る舞いにならないことに気付いた。mongodb-driver は decode/unmarshal 処理を reflect を使って実装している。要件の詳細は省く (interface を使いたい背景がある) が、再現コードが次になる。

type MyInterface interface {
	MyFunc() error
}

type MyType struct {
}

func (t *MyType) MyFunc() error {
	return nil
}

var tMyInterface = reflect.TypeOf((*MyInterface)(nil)).Elem()

func some(v reflect.Value) {
	f := v.Convert(tMyInterface).MethodByName("MyFunc")
	fmt.Println("got", f)
	fmt.Println("=========")
}

func main() {
	t1 := &MyType{}
	some(reflect.ValueOf(t1))
	// the zero value of an interface is nil
	var t2 MyInterface
	some(reflect.ValueOf(&t2).Elem())
}

このコードを実行すると次のエラーになる。

panic: reflect: Method on nil interface value

ドキュメントにも interface の nil の値を呼び出すと panic するよと書いてある。

Method returns a function value corresponding to v’s i’th method. The arguments to a Call on the returned function should not include a receiver; the returned function will always use v as the receiver. Method panics if i is out of range or if v is a nil interface value.

https://pkg.go.dev/reflect#Value.Method

scim 調査に着手

#remote work  #scim  #go  #design  #meta programming 

22時に寝て24時に起きて4時に起きて6時に起きた。実家だとやることないので寝るのも早くなる。早く起きているので始業も7時半ぐらいになる。早起きは三文の徳。

リモートワークのタグを新設

神戸のオフィスに行かなかった日は day off というタグを付けている。名前の通り、お休みしたということを表す。この定義に従うと、実家に帰ってリモートワークをしたときもお休みになってしまうため、それを区別するように remote work というタグを作った。

scim 調査

id 連携の文脈で System for Cross-domain Identity Management (頭文字をとって SCIM、すきーむと呼ばれている) という標準がある。基本的には rest api とスキーマを扱うように仕様が決められていて、それに準拠したサービス間で id 連携を標準化する狙いがある。id 連携と同じ用途を表す用語として id プロビジョニングという用語もあるが、多くのクラウドサービスでは id プロビジョニングのために scim 対応していたりする。

たまたまサイボウズさんが okta と scim 連携に対応しているプレスリリースをみかけた。

その延長で調査していたところ、go の scim ツールを提供していることに気付いた。しかもこれを作っているのが Maki さん。これはソースを読んでおこうと思った次第。Maki さんはメルカリに所属していたと思うのでこれは副業でやっているのかな？

scim-server は scim ライブラリを実際に使うときの参照実装としてアプリケーションの開発者に開発の雰囲気を伝えるための実装になっている。これ自体をプロダクトのサーバーとして使うわけではない。sqlite を使ってユーザー／グループの crud な操作と検索機能を提供している。

scim ライブラリのソースコードも軽くざっと読んでみた。github.com/lestrrat-go/sketch という go でスキーマを記述してコード生成する Maki さん製のツールがある。これを起点に scim のプロトコルやリソースの仕様にしたがって go のコードでスキーマを定義し、リソースに関する go のコードと scim スキーマを自動生成している。sketch というツールに関連して他にも Maki 製のメタプログラミングライブラリを多用していて、scim の標準化されている部分のエンドポイントやリソースのインターフェース部分をすべてコード生成している。

go generate やコード生成の実際の応用例として非常に参考になる。このライブラリは scim のプロトコル仕様に関する開発者と、そのエンドポイントの実際の処理 (バックエンド) の開発者を明確に分離するという開発体制を期待している。scim に関するところは Maki さんが独りでコード生成を多用してオープンなプロトコル仕様の開発を担当し、そのバックエンドをサイボウズさんの開発者が実装するという分業体制を想定しているようにみえる。

scim 対応のアプリケーション開発のプロトコル部分を外部に委譲するといった設計になっているが、scim が十分に安定していてプロトコルの仕様が変わらないのであれば理に適っているとも考えられる。バックエンドの開発者はいくらか sketch の学習コストを強いることになる。そのため、アプリケーションはその学習コストを支払ってもコード生成のメリットが上回るだけの規模や特性を要求する。おそらく scim はそれだけの価値があると判断されたのだと推測する。

私はメタプログラミングが好きな方なのでこういうやり方もあるんだなと設計の参考になった。またコード生成の要件があったときにソースを参考にしようと思う。

実家での初めてのリモートワーク

#remote work  #go  #network  #founding  #coworking 

23時に寝て2時に起きて4時に起きて6時に起きた。親が4時頃から作業し始めるからそのぐらいからだらだら起きている。その影響で8時前からお仕事を始めた。

パスワードの表現の答え合わせ

先週末に課題としていた パスワードの表現 になかなか苦労したようで半日ぐらいかかった。私が答えを言うのではなく、本人が自分で考えて、自分で調べて実装できるまで粘り強く待っていた。概ね、私の模範解答に近いものを実装してきて、コードレビューで少し手直しはあったものの、go でコンストラクタに近いものを実装する方法を学んだと思う。

実家の離れスペースで働いてみた

今朝は軽く雨が降っていて、それ以降もずっと曇っていた。天気がどんよりしていたのもあり、エアコンは除湿に設定してソファで働いてみた。数年前から淡路島に帰ってきてリモートワークをしたことは何度かあったが、すべてマクドナルドへ行って電源を借りて作業していた。実家で丸1日リモートワークで働いたのは今回が初めてだと思う。どんな施設でもインターネットとエアコンさえあれば働けるということを改めて実感した。実家なのでお昼になったらおかんがお昼ご飯だと呼びに来る。食べるものも考えなくてよい。

iphone で作った wifi ルーター の 2GiB プランで契約している。普通に macbook でリポジトリを操作したり、課題管理を使ったり、ブラウザで調べものしたり、slack でやり取りしたりしていたら約9時間で 987 MiB の通信量となった。いまやネットワークの通信量を意識することはないと思うが、普通にお仕事したらいまの時代1日 1GiB ぐらい使うもんなんやと気付いた。

iijmio の管理画面で日次の通信量を当日分も含めて確認できる。

1週間とか、実家でリモートワークするなら 2GiB プランだと全然足りない。機をみて 5/10 GiB 程度のプランに変更するとよさそう。これでコワーキングスペースにして複数人が使う想定なら光回線をひかないとネットワークが厳しいということも理解できた。光回線をひくと安くても5,000円/月は固定費がかかってくるので維持費の問題は悩ましいことも分かってきた。

トイレにうんこ

#life  #communication  #go  #design 

0時に寝て4時に起きてドラクエタクトやりながらだらだらしているうちに少し寝て7時に起きた。

トイレにうんこを詰まらせた

いや。正確にはトイレが詰まってうんこを浮かべた。朝トイレへ行ったら洋式トイレにトイレットペーパーが漂っていた。前に使った人が流していないのかな？と考えて気持ち悪いのですぐ流した。これまでも過去にそういうことがたまにあった。あとから考えると、誰かのいたずらでなにかしらトイレに詰まるものがトイレットペーパーの下に隠されていた可能性もある。この時点で次に水が流れるかどうかのチェックをするべきと洞察できていなかった。

それから、うんこして流したらトイレが詰まったようで流れない。微妙に便器から水が溢れてきた。ぎりぎり溢れ返ることにはならなかったのでトイレの床にうんこが散乱する最悪の状況にはならなかった。しかし、トイレにうんこがぷかぷか浮かんでいる状態になった。べつに私が悪いわけではないと思うのだけど、トイレにうんこが浮かんでいる状態にしてしまったことにとても罪悪感を感じた。

幸い朝8時からシェアオフィスにいるのは私ぐらいで、多くの利用者は10時前後にならないと出社してこない。いまトイレに誰かが入ってきて犯人扱いされることはなさそう。なんか行き当たりで人を殺めてしまった殺人犯みたいな心境になった。運営会社のサポートは9時から。1階へ降りていって掃除のおばちゃんに尋ねてみたけど、うんこが浮かんだトイレの階は自分たちの管轄じゃないと断られてしまった。(´・ω・｀) 仕方なく、時間を待って9時ぴったりにサポートに電話して聞いてみる。サポートにも断られたらどうしよう？不安と緊張が走る。サポートのお姉さんは (当然ではあると思うけれども) 全然平気ですよーと快く応じてくれて安心した。まぁ、電話しているお姉さんが対応するわけじゃないしね。

電話で一報を終えて、その後、トイレ業者さんが来るまで自分のうんこを浮かべておいていいのかどうか、すごく悩んだ。かといってうんこを取り出す勇気もなく結果的にそのまま放置した。人間がしょぼい。40年以上も生きてきて自分のうんこの処理もできないのかと思うと本当に情けなくなった。「入るな、危険」ぐらいの張り紙しといてもよかった。本当の犯人だったらここでとんでもないトリックを思いついて実行するところだけど、一報したことでそこまでの切羽詰まった状況でもなくなっていた。もし警察がやってきてもサポートのお姉さんが犯人じゃないと証言してくれるだろう。

9時から打ち合わせがあって、1時間半後、恐る恐るトイレを見に行ったらすでに詰まりは解消していてうんこもなくなっていた。平和な日常が戻ってきてよかった。

平安時代とか、都はうんこまみれだったという記事を昔読んだのを思い出した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

最初の30分でサイトデザインをみながら、はらさんのレビューの視点や背景を教えてもらっていくつか気付きを得た。後半は来月の雑談会へ向けて、課題管理の資料のレビューを始めて、いつもは1時間で打ち合わせを終えるのだけれど、つい課題管理の話しでテンションあがって話し過ぎてしまって30分オーバーした。打ち合わせのような時間を決めている会議で議論に熱くなるのはよくない。失敗したなーと反省した。

パスワードの表現

go でパスワードを扱うときに平文をハッシュ化して保持するためのユーザー定義の構造体を作りたい。構造体にハッシュ化した値をもつとしても、プログラマーが誤って任意の値を設定できないように制御したい。ここで go はオブジェクト指向言語ではないのでコンストラクタという概念がない。私が知っているもっともシンプルな方法は interface と private な構造体を組み合わせてコンストラクタに近いものを実装する。コードレビューしていてメンバーにパスワードがハッシュ化されていることを保証する仕組みをお題として指摘してみた。

今日のところは解決できなくて月曜日に持ち越しになった。私の想定する模範解答は次のようなものだけど、ちゃんと自分で考えて実装できるかなぁ。

type Password interface {
	Authenticate(s string) error
	Get() []byte
	String() string
}

type passwd struct {
	hashed []byte
}

func (p *passwd) Authenticate(s string) error {
	return bcrypt.CompareHashAndPassword(p.hashed, []byte(s))
}

func (p *passwd) Get() []byte {
	return p.hashed
}

func (p *passwd) String() string {
	return string(p.hashed)
}

func NewPassword(s string) (Password, error) {
	h, err := bcrypt.GenerateFromPassword([]byte(s), bcrypt.DefaultCost)
	if err != nil {
		return nil, err
	}
	return &passwd{hashed: h}, nil
}

go の channel 制御の学び

#go  #design  #refactoring  #rabbitmq 

0時に寝て2時に起きて5時に起きて6時に起きた。久しぶりに夢をみたような気がする。

go の channel とクローズ制御

rabbitmq/amqp091-go を使った pubsub の consumer の実装で次のような for ループでメッセージを取得していた。この場合 deliveries の channel が閉じられると内側の for ループが終了して、外側の for ループの接続処理へ遷移する。

for {
    // コネクションの接続処理

    for d := range deliveries {
        // メッセージ処理
    }
}

この処理を context を使ってキャンセルできるよう、次に書き換えた。channel の Receive operator のドキュメントによると、channel は2値を返すことができて、戻り値の2番目の ok の値を調べることでその channel がクローズされているかどうかを判定できる。この仕組みを知っていれば select で ok を調べてエラー処理を実装できる。そうしないと deliveries の channel が閉じられれたときに select では常にゼロ値のメッセージが返るようになって意図したメッセージ処理とならない。

for {
    // コネクションの接続処理

    for {
        select {
        case <-ctx.Done():
            // context がキャンセルされたら終了処理
            if err := s.ch.Cancel(cid, false); err != nil {
                return fmt.Errorf("failed to cancel channel: %w", err)
            }
            return nil
        case d, ok := <-deliveries:
            if ok {
                // メッセージ処理
            } else {
                // エラー処理
                break
            }
        }

        // コネクションが閉じていればループを抜けて再接続
        if s.conn.IsClosed() || s.ch.IsClosed() {
            log.Info("the session was closed, try to reconnect", nil)
            break
        }
    }
}

同じ channel からメッセージを取り出すループ処理でも用途によって使い分けがあるなぁと今更ながら学んだ。というか、自分でバグを埋め込んで自分で直した (´・ω・｀)

マージまで約1ヶ月

先日送った amqp091-go の pr が最終的にはほぼそのままマージされた。約1ヶ月ぐらいの議論やレビューがあって取り込まれた。新しいリリースバージョン (次は 1.9.0?) が出たらうちのアプリケーションでもこの新しいメソッドを使うようにして実績を積ませる。この pr は「あったら便利」程度の機能なのでそれほど重要ではない。

この成功体験をもって次は本命の go-ldap の pr のマージに向けて勢いをつける。こっちの pr は業務に直結しているので本気でやり取りしている。

気付けば週末

#founding  #go  #noh 

1時に寝て何度か起きて6時に起きた。あまりうまく寝付けなかった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。いつもより盛り沢山。

農業体験のコンテンツ作りは 人生の楽園 という番組が参考になるんじゃないかといった話題が出た。うちにはテレビがないのでみれない。オンラインでみれるなら視聴するんやけどな。

amqp091-go の context 制御のセマンティクス

先日送った amqp091-go の pr でメンテナーから api の振る舞いのセマンティクスが変わってしまっているという指摘をいただいた。

それはその通りなんだけど、一般の go プログラマーからするとそう動いてくれた方が便利でよいんじゃない？と返してみた。

ニトリ商品受け取り

オフィスで使うスマートフックをオンラインで購入した。最寄りの店舗で受け取ると送料が無料になるというのでやってみたら2週間ほどかかった。急ぎではないので受け取りが遅いこと自体は構わない。受け取るときに店舗のスタッフに「このお店にもスマートフックの在庫あったりしますか？」と聞いて調べてもらったら、いまの時点では在庫があるという。もしかして発注時にも店舗に在庫があったとしたらそれを転用すればわざわざどこかの倉庫から2週間もかけて送る必要はなかったんじゃないか？とか考えた。こういうのをみかけると在庫システムを改善したいと思ってしまう。

【購入日】　　　　　2023年05月26日 (金)
【お渡し予定日】　　2023年06月10日 (土)
【保管期限】　　　　2023年06月24日 (土)

敦盛

第四回《真花演能会》能『敦盛』 のチケットの申し込みをした。問い合わせフォームでチケット申し込みの旨を連絡するとメールが返ってきて、銀行振込して、先方が確認したら住所にチケットを送ってくれるという。職人が参加者1人1人にメールを手書きで返す運用になっている。メールに記載された振込先の口座番号が全角文字で paypay 銀行の振り込み画面では全角文字をコピペできなかった。申し込み者も口座番号を1文字ずつ手打ちしなさいと言われた気分だった。こういうのをみかけると決済システムを自動化したいと思ってしまう。

レイオフ

#ldap  #go  #management  #failure 

4時から寝てあまり眠れなくて8時半に起きた。2時過ぎまでオフィスでブログを書いてた。

レビュー対応

昨日の go-ldap のレビュー対応 の続き。標準ライブラリの sql パッケージのソースを読みながらレビューアが提案した api を サンプル実装 してみた。実際に実装して動かしてみるとコードからのフィードバックが働き、より実践的な感覚で設計の議論できる。他のレビューアもその方がわかりやすいだろうと思ってやってみたが、はたして伝わるかどうか。

クックパッド社のレイオフ

社内 slack で知人から教えてもらって気付いた。

ちょうど晩ご飯の買い出しを終えた頃に一報があってそれからあちこちのタイムラインやニュースや掲示板などを追いかけてだいたいの雰囲気を掴んだ。私は昔からクックパッドさんを応援していて、いまも応援してはいるのだけど、さすがにもうこれは昔のような栄華を取り戻すことはないのだろうと、応援している私自身にも思えるぐらいのインパクトがあった。

この先に起こることは社長が交代する10月までに経営にとってネガティブなことをやり尽くしてその後 mbo して上場廃止にするのではないかと思う。まだまだキャッシュはあるし、右肩下がりとはいえ、現状の有償会員の売上もそれなりにあるので最低限の人員で保守していく分には十分に収益力のあるプラットフォームだと思う。2017年からの10年投資でなにか隠し玉のサービスがあるわけではなく、いろいろやって失敗したのでサービス終了して人員も整理して赤字の出ない程度で継続していくのではないかと思う。

早起きは三文の徳

#ldap  #go  #payment 

昨日は飲んだくれで帰ってきて1時に寝て何度か起きて7時に起きたものの、二日酔いではないけど、10時頃までだらだらしていた。それ以降はオフィスで作業していたのだけど、朝起きるのが遅れた分の進捗がいまいちになってしまった。翌2時過ぎまでやってもやりたかったことを完了できなかった。

レビュー対応

先日送った go-ldap の pr のレビューが付いていたので指摘されたところの修正をしたり、バグに気付いてリファクタリングしたりしていた。昨日の夜にコメントが付いていることに気付いたが、飲んだくれだったので対応が遅れた。レビューコメントの1つを除いて他はすべて対応した。残りの1つは api の設計をもっと堅牢、且つ拡張性に富んだものにしてはどうか？という提案。提案内容自体は悪くないと思う。他のレビューアのコメントも確認するためにまたしばし待つ。いまのところはよい感じ。

stripe アカウント

あるアイディアの poc を作ろうと思って stripe のアカウントを作った。当初は決済手段として paypay でやろうと思ったものの、サポートに電話して聞いてみると paypay は実店舗向けにしかサービスを提供していないらしい。テスト環境もなければ、開発会社が検証用途で使うといったことも想定していないらしい。それで stripe のアカウントを作成した。即時でアカウントを発行できて使えるようになった。さすがって感じ。

わかりにくさと能動的

#ldap  #go  #noh  #book  #communication 

22時に寝て何度か起きて7時に起きた。たまには早く寝てみた。

チャンネルを用いた ldap 検索の api

うちらの要件に足りない機能が go-ldap にある。私が機能拡張についての issue を作ったときにある開発者が先にこの機能が必要だとコメントしてくれた。もともと draft pr で実装されたコードがあったのでそれをベースに検証したら普通に動いた。あとは go のエンジニアリングとして開発者が使いやすいように、私の経験からのアレンジを加えて pr とした。テストも実装した。なにか問題があればレビューで指摘さえしてくれれば私がすぐ修正してマージできるはずと考えている。はてさて、どうなることやら。

能―650年続いた仕掛けとは―

能―650年続いた仕掛けとは― を読んでいる続き。世阿弥の紹介をしている第五章に感化された。

第四章 能にはこんな仕掛けが隠されていた

能はシテ (主役) の役柄や内容で5種類にわけられる。

  1. 初番目物 神: 神様が登場して颯爽 (さっそう) と舞う
  2. 二番目物 男: 修羅物とも呼ばれ、武将が修羅道に落ちた苦しみを描く
  3. 三番目物 女: 鬘物 (かずらもの) とも呼ばれ、優雅な美しいものが多い
  4. 四番目物 狂: 雑能とも呼ばれ、他の4つに分類されないもの
  5. 五番目物 鬼: 切能 (きりのう) とも呼ばれ、鬼や妖怪、精霊、霊獣などがシテになる

さらにこの5つの分類に入らない翁という演目もある。翁を最初に置き、この順番に上演しながら、能と能の間に狂言を演じ、最後に祝言の短い能を演じるのがかつての正式な上演だったらしい。これだけ演じると朝から晩までかかってしまうので忙しい現代ではなかなかみれなくなってしまっているという。

ひと昔前は結婚式で仲人さんや親戚が謡を謡っていたという。たしかに古風な結婚式ではそうだったような、、、と私もうっすらとそういう記憶があるような気もする。

能の身体的な特徴の1つに摺り足がある。摺り足には重い二本の刀を腰に差して腰痛にならないという効能があるらしい。ほんとかな？

世阿弥が能の構造は序破急にせよと書いている。序はワキの登場、破はシテが登場して話をして去る、急は再びシテが姿を変えて登場するといった構造になる。水戸黄門や暴れん坊将軍のような時代劇の最後の展開が急に相当する。水戸黄門で例えると次になる。

  • 序: 現状把握と善人の窮状
  • 破: 善人が騙される／襲われる
  • 急: 印籠を出す

そして、この後に書いてあることが個人的におもしろかった。水戸黄門は番組開始時点では印籠を出すようなシーンはなくて、当初は助さん角さんが敵をたたき斬っていただけだったという。そもそも印籠を出したぐらいで本物の水戸黄門かどうか分かるわけもなく悪人がひれ伏すはずがないw あるときから印籠を出すという急を作って、序破急が安定したことで人気が出て長寿番組となったと書いてある。ほんとかな？

第五章 世阿弥はこんなにすごかった

能の大成に大きな影響を及ぼした世阿弥についていろいろ書いてある。

夢幻能 という能のジャンルを完成させた。念が残る、思いが残っているといった残念を昇華させる物語の構造になっている。世阿弥は特に敗者の無念をみせる舞台構造を作ることに成功したという。もともと日本人は死者を尊ぶ習慣があったことも要因としてあげている。

世阿弥は世襲で継いでいくという家元制度を作った。これは後世に必ず継ぐシステムを作ったと言える。現代まで能が継続されている背景の1つに家元制度はたしかにあげられると私も思う。しかし、現代では基本的人権 (職業選択の自由) に反することから家元制度の批判もあるようだ。著者はこの仕組みを称賛しているが、私は現代の感覚からすると個人の自由を制限して成り立っている古い制度のように感じてあまり著者の意見に同意できなかった。

陰陽の和するところの境を成就とは知るべし

昼や晴れた日には観客の気分が盛り上がり過ぎているので控え目に演じなさい。曇りや雨の日には逆に観客の気持ちが萎えているので派手目に演じなさいといったことを言っている。要は客の状態を見て演じ方を変えなさいと言っている。これは言うは易し、行うは難しだという。能ではこれを楽器の構造から音の力で解決していると説明がある。

時に用ゆるをもて花と知るべし

ともすれば絶対的な善し悪しがあるように思い込み、そのようなものを追求しがちであるが、実際はそのようなものはない。あるのは時との関係性だけだという。易経の時中も引用している。いまがどのような「時」であるかを知り、それがもっとも適合した時期であるか、行動できるか、それこそが「花」であるという。

花と面白きと珍しきと、これ三つは同じ心なり

現代の言葉とはちょっと意味が異なる。

  • 面白き: 目の前がパッと明るくなること
  • 珍しき (愛ず): 愛らしいこと、まったく普通のことに感嘆を抱かせる工夫など
  • 花: 秘すれば花、秘密にすることで偉大な働きをすること

能では、演者はあまり観客に働きかけない。よくわからないことで、逆に観る人が能動的になり、見えないものが見え、聞こえない音が聞こえるようになる。これも秘することによって咲く花だという。師匠が弟子に教えないというのも、簡単なことでも秘することで、弟子が散々苦しみ抜いた上でその助言の価値に気付くこともあるという。

「老後の初心」という考え方。どの歳になっても初心はあるが、歳をとって体力が劣っていくからこそやることも変えていく。第一章にも出てきた能における「初心」という言葉の概念は本当におもしろい。能では体が動かなくなっていくのだから「しないというやり方も方法としてありえる」と考える。演じないことで演じる、歳を取ったときの表現方法がある。高齢な能楽師でしか演じられない境地があるから能楽師は歳を取ることを楽しみにする。この考え方はいまの時代にとてもあうように私は思えた。