Innocence

Burgmüller 25 Progressive Pieces の5曲目。タラタラリンと指くぐりをしながら1オクターブ上下するフレーズが出てくる。レガートで可愛く弾く。

• 各フレーズの最初の一音を優しく弾く、てか雑に弾かない。それだけで音楽のなめらかさが全然違う
• 第2小節の C B B、第4小節の B A A は、楽譜の指示通りの指番号 4 3 2 で弾く。同じ音だけど違う指を使ってレガートを表現するテクニックだろうか
• だんだん曲数が増えてくると、楽譜を構造で覚える必要が出てくる。Burgmüller の初心者への配慮が素晴らしく、後半の左手は B♭C と A C の繰り返し。右手も実質2小節分のメロディの繰り返し
• 指示通りの運指で 2 でスタッカートを弾いて同じ音を 1 で弾く
• タラタラリン、ジャン！とフォルテで終わる。ジャン！の手前は右手だけスタッカートが付いていて、ここをうまく出来ると弾ききった感が出て気持ちよい。最後のジャン！までは指の移動量が多いが、フォルテなので外すとモーレツかっこ悪い。ジャン！の手前の左手の親指の位置が、ジャン！の右手の親指の位置になることを覚えておくとスムースに指の移動が出来る

The Little Party

Burgmüller 25 Progressive Pieces の4曲目。Legato Thirds が出てくる。装飾音から一段階レベルアップして、旋律を弾く手のほうでも、複数の音を同時に出す。新しいスキルが必要になるが、旋律は単純。1つの曲に新しいことをいくつも詰め込まない作曲家の配慮だろう。

• スタッカートとレガートの弾き分け、sf から p へのデクレッシェンドなど、強弱をしっかり意識した
• Fine のある 13、14 小節のレガートは指が6本無いと引けない。人間の指の構造上仕方なく、下の音は親指を使うよう指示されている。上の音は 5 4 3 5 4 3 4 と繋げる。事実上、右手の 1 番とそれ以外の指で異なるテクニックで音を出すことになる
• D.S で盛り上がりつつ sf になるけど、すぐ落ち着いて p にデクレッシェンドする。浮きたつけれどはしゃぎ過ぎない、そんなパーティをイメージ

Pastorale（牧歌）

Burgmüller 25 Progressive Pieces の3曲目。3和音の連打と、装飾音が出てくる。

• 和音の連打が軽く正確に響くように弾くためには手首のトレーニングが必要
• 後半4和音も出てくる。手首のトレーニングが足りないと牧歌がドラマチックになってしまうので注意
• 装飾音が主張せずに主音を飾るようにコロン！と軽く弾けるようにする

Arabesque に比べると p、mf、p、pp と、盛り上がりは無い（牧歌というだけある）。それだけに聞かせるためには技術が必要。弾けるようになるのは早かったけど、まだちゃんとは弾けない。難しいのに退屈で見せ所が無いのであまり上達していない。

Arabesque

Burgmüller 25 Progressive Pieces の2曲目。152 bpm で16分音符が出てくる。子供の頃弾いたときはずっとゆっくりだったが、これは 152 bpm で弾きたい曲。ピアノで始まり、フォルテ、sf で終わる。指を早く、正確に動かす練習と、スタッカートの効果を学べる曲。最初の繰り返しも sf でジャン！最後も後半盛り上がってジャン！って終わるので、演奏体験として分かりやすい。スタッカートを正確に、そしてピアノで弾くところを我慢してピアノで押さえて弾けるようになると、メリハリが出てよい。

• 第10小節のスタッカート、sf で半盛り上がりと思いつつ、ピアノに戻る。じらし効果
• 第11小節、2週目はレガートがスタッカートで終わる。次の右手はレガートなので、何も考えないとずるずる弾いてしまうので注意
• 最後の2小節は移動量が大きく、しかもフォルテ、sf なので、外すと最高にかっこ悪い。ただそれを恐れてテンポがずれるのも残念。これはいかに練習したかが、明らかに出るところ

Sincerity （素直な心）

Burgmüller 25 Progressive Pieces の最初の曲。小学生の発表会などで弾かれるベーシックな曲、なはずだが、楽譜を見ると繰り返しを含めて 4分の4拍子38小節で、152 bpm。そのまま弾くのは結構辛い。計算上は1分で弾き終わるところだけど、付録のCDでも1:28かかってるので、大体 100 bpm くらいが一番音楽的になるのだと思われる。指の練習として綺麗に弾きこなせるゴールが 152 bpm ってことなのだろうか。大体以下のポイントに気をつけながら練習し始めた。

• ピアノで始まり、ピアニッシモで終わる。弱い音を正確に弾くための打鍵の精度が大事
• 6小節から7小節の左手の変化は割と大きいので、6小節の全音符は4拍押さえずに最後の半拍を指の移動に使うくらいのイメージで遷移させる
• 8小節を1フレーズとして滑らかに弾く
• 14小節の sf の A が力んで抜けることがある。ピアノのせいなのか、小指の使い方が悪いのか不明
• 最終小節の遷移、4和音だが、左手の G はレガートが付いているので、足されるのは3音。ピアニッシモで綺麗に響かせるにはどうしたらよいのか試行錯誤

Burgmüller 25 Progressive Pieces, Op. 100

最後の更新から一年半。もはや日記としての機能もないが、後から読み返す自分のために説明しておくと、数ヶ月前からコロナ禍でリモートワークが始まったのであった。元々「世界中どこに居ても出来る仕事」が仕事を選ぶ条件であったので、リモートであること自体には特に支障がなく、普通に仕事をこなしている。

景気は良くないけれど、悪いことばかりではなかった。通勤のために燃やしていたガス代が節約され、住宅ローンの金利がここ数年で最低を更新し、借り換えによって月々の返済額が減った。

そして大きかったのが、必要のなくなった行き帰りの通勤時間ぶん約1時間強の自由時間が新しく生まれたことだ。元々通勤時間の車の運転も音楽や講義の視聴も、それなりに充実していたはいたが、せっかく家で何でも出来るのだからということで、細々続けていたピアノの練習を再開したのだった。これは第一に自分のためでもあると同時に、なかなかピアノの練習が習慣付かない子供たちに、毎日続けることの大切さを見せて、啓発する狙いもある。

ハノンは毎日、10曲ずつくらい、Burgmüller は1週間に1曲通して弾けるようにして、覚えた曲は毎日弾くという方針。ハノンは80 bpm くらいから始めて、慣れたら 2 bpm ずつくらい速度を上げ、現在 92 bpm でしっかり弾けるように練習している。このあたりの練習法は森本麻衣さんの動画を始め、YouTube に上がっているいくつかの解説を参考にした。なぜ Burgmüller なのかというと、初めから挫折しない程度の難易度で、興味を持った子供たちにも手が届いて、かつ一つ一つの練習曲が音楽的に面白いと思ったからである。

実際に練習を始めると、子供の頃には気づかなかった発見がいくつもあった。今後、リモートワークが続く限り、進捗を一つ一つを書き留めていけたらと思う。

Burgmuller 25 Progressive Pieces, Opus 100 for the Piano (Alfred Masterwork Edition: CD Edition)

楽譜はこれ。教師が居ないのでCD付きなら間違いないだろうという安直な理由で選んだ。

Clean Architecture

色々な場所で話題に上がっていた Clean Architecture（原著）を読んだ。

自分自身、実は「自称・アーキテクト」として10年以上、とあるソフトのアーキテクチャを請け負っているので、自分の中に言語化されていないノウハウがそれなりにあった。私にとってうれしかったのは、それらの言語化できていたかったノウハウが多少言語化されて整理されていたことと、この本自体が割と広く有難がられていることである。個人的に役立ったのは Chapter 13 の Component Cohesion についてだった。

プログラムの設計を議論する場合、正論と正論が矛盾するという厄介なことがしばしば起こる。経験の浅い頃は、なぜそういうことが起こるのか分からず、結局最後までネチネチ煙に巻く人の意見が通ってしまい、後で苦労することになることがあった。あるいは、正論を盾に責任を果たそうとしない口達者にも手を焼いた。経験を積んでからは「ごもっともだけど、それは今重要じゃない」と言えるようになった。この本を読めば、REP-CCP-CRP 原則のテンション・ダイアグラムを持ち出して、何をすべきかをより明確に説明できることだろう。何よりも、3つの原則がそもそも緊張関係にあることが前提なところから話が始められるようになったこと、また、アーキテクトの仕事が一つの完全な正解を導くのではなくて、与えられた境界条件から、開発効率を最大化するためにパラメータを調整することであることを、共通の言葉で説明できるようになったことが大きい。

振り返ると、基盤中の基盤ライブラリは、社内向けであっても REP の原則を最初から厳守していたし、派生プロダクトのコードをフレームワークに追加するときには CCP の原則で外に括りだすことをお願いしたこともあった。そのような数々の技術的決断を、後から答え合わせする形で再定義できた。

新たな製品をデザインするときに、コアのロジックの議論に集中したいときに「バックエンドデータベースはどうしますか？」みたいな話が出たら、「The Database Is Detail. この本読んで」。みたいな使い方ができて捗るかもしれない（しないけど）。

あ、そうそう、この本できっちりと「a software architect is a programmer; and continues to be a programmer. (p.136)」と言い切ってくれたのも、この本が使える信用できると思った理由の一つだ。

告白すると、一応、タイトルに冠されてる Clean Architecture の章まではちゃんと読んだが、以降は斜体で強調されているステートメントと結論以外は斜め読みした。その他、コンポーネントの依存関係で、なぜ circular dependency が良くないかは、それらのコンポーネント群が、結局一つの塊としてコンポーネントになってしまって管理コストが上がることは、子供のおもちゃを使ってもっと簡単に説明できると思った。コールバックメカニズムを用いて依存性問題を解消する実装上のテクニックを dependency inversion と言って仰々しくするとってつけたようなコンサルタント用語の類も、頭の片隅に入れておけば十分である。それらは言語化されているという点で便利な概念だけど、まだ本質を掠めている程度であるからだ。蛇足を承知で言うと、導入の章でソースコードの行数をもって生産性の指標にしているのは単純化しすぎと感じた。なぜならば、コーディング技術が向上したりプログラミング言語そのものがバージョンアップして改良されたりすることで行数が圧縮されるのは、生きているソフトウェアでは起こりうることだからだ。そしてそれはアーキテクチャとは関係がない。

個人的には仕事柄この本はとても有益だった。一方で、この本を読んでポカンとして何も響かなくても、別にそれがダメとも思わないし、むしろ本書に出てくるキーワードでマウントをとるアーキテクトにならないようにしようと心に刻んだのだった。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)