読者です 読者をやめる 読者になる 読者になる

ベイスターズのチャンテ0の原曲が名曲過ぎると思ったら、世界中でアレンジされまくってた

あけましておめでとうございます(今更

昨年はベイスターズが初めてのクライマックスシリーズに行ったということで感無量でした。野球が無いとつまらないですね。去年を思い出してしまいます。色々試合の動画を見ていたのですが、応援してたときも思い出して、一番大好きな応援歌であるチャンテ0を色々調べてしまいました。そして驚いたのですが、僕だけじゃなくて世界中の人がこの曲を好きであることが判明しました。気に入ったのを紹介してみようと思います。

ベイスターズのチャンテ0

これが私にとっての原曲。思い出のクライマックスシリーズファーストステージの第3戦ですね。今見てても泣けてきます。

ドン!ドドン!ドンドンドドン!×3 (オイ) ドン!ドドン!【選手名】
ララララ~ さぁ燃え上がれ
我らの 期待のせて
オーオオオーオーオーオー今
鋭く放て この一打


横浜DeNAベイスターズ チャンステーマ0 クライマックスシリーズ2016 1st 第3戦

原曲は?

わんぱくダック夢冒険(英語名:DuckTales)という1990年に発売されたファミコンのゲームの月面ステージが原曲です。ファミコンの3音ですが、充分名曲ですね。最高です。
作曲者の方は殿村裕誠さんと言われているようです。ゲームで作曲者のクレジットが出てこず定かではないそうですが、調べる限りはこの方かと。カプコン、タイトーに所属されていたようです。神と呼びましょう。


Best VGM 40 - DuckTales - The Moon

リマスター版

2013年(日本では2015年)にゲームのリマスター版が出たらしく、この曲も再度アレンジされていました。かっこよく仕上がってますねぇ。


ピアノ(これなら弾けそう)版

一人で弾いてるのに、結構原曲の雰囲気をちゃんと反映していてすごい。リズム感も良くて、左手と右手をうまくリズムをずらすことによって音とリズムに厚みが出てる。これを真似して弾いてみよう。


Ducktales - Moon Theme on Piano

ピアノ(プロのピアニスト)版

ほんと世界には色々な人がいるんですね。。。クラシックピアノ風にアレンジしてあって、めちゃむずい。これは弾けない。でもかっこ良すぎ!!!そしてピアノがファミコン(日本以外で発売してるNES)風になってる。このピアノいくらするんだろう。


DuckTales Moon Theme - Sonya Belousova (dir: Tom Grey)

アカペラ版

一人で全てのパートを歌って合わせて動画にしてます。この人マジすげー。そしてかっこいい。


DuckTales - The Moon Theme Acapella

女声合唱版

なぜ…。もう雰囲気は宗教曲ですね。どんだけ好きなんだ。癒やされます。


Women's Choir Sings Ducktales Moon Theme

ハープ版

雰囲気がぜんぜん違っていいですね。でも頑張って原曲のリズム感が出てる。面白い。


DuckTales The Moon Theme (Harp Cover)

メタル版

名曲というのはどんなアレンジにしてもいいですね。このメロディはエレキギターに合う。


Ducktales - Moon Theme Meets Metal

アコースティックギター

やべー爽やかすぎる。原曲の雰囲気をそのままに、爽快な春の風のような演奏に仕上がってます。


DuckTales - The Moon Theme - VGM Acoustic

譜面版

ファミコンはたった3重音なのに、フレーズごとに色が変わってとっても上手い。#6個(Cisdur、嬰ハ長調)なんですね。でも、演奏を聴いて(見て)るとそう見えないけど。ホントなのかな。あとで確認してみよう。


Score: DuckTales - The Moon Theme

やっぱりいい曲

どの編曲も原曲を壊しすぎて無くて、とてもいい。元気が出ますね。仕事とかで辛い時にまた聴こう。球場で応援するときもチャンテ0を歌うと楽しくなって好きなんですが、日本で生まれたゲームの原曲を世界中の人が好きだなんてなんか嬉しい。ゲームってすごいですね。僕も編曲に挑戦してみよっと。

2017年は優勝を目指して、頑張れベイスターズ!!!

開発ツールを最大限活かすために大切なこと

 アジャイルスクラムテスト駆動開発ドメイン駆動設計、継続的インテグレーション…。色々な開発ツールや開発の考え方があります。それぞれ素晴らしいツール(手段)であり、取り入れるだけで開発方法を変えることができます。ただ、このような素晴らしいツール類の弊害として、だんだん目的化してしまうということがあります。「ツールは手段であり目的ではない!」みたいな話はどこにでもあるんですが、それはそれとして、少し別の視点からツールを考えてみたいと思います。

優れた道具を使うとどうなるか

f:id:tsuyok:20140130225057j:plain:w200f:id:tsuyok:20130928154912j:plain:w354

 左側の写真は私が趣味でやっているティンパニ(右側の写真)という楽器をたたくためのマレットです。このマレットは、私がお世話になっている先生に作っていただいたものです。先生が使っているマレットと同じ作り方で、私の腕の長さなどを考慮して作っていただきました。オーダーメイドです。楽器をやっていない方々はわかりにくいかもしれませんが、このような道具が変わるだけで、大きく音が変わります。楽器が変わるかくらい違います。

 マレットを変えるとすぐに音が変わったという点だけでも驚いたのですが、最も驚いたのが、長い時間使っていくと道具に合わせて演奏スタイルも変わってきたことです。マレットの握り方、上げる角度、音のイメージ、形も考え方も一緒に変わりました。また、この道具を使っている前提で先生にレッスンをしていただくと、当然先生と同じものを使っているので、スムーズに音のイメージやフレーズの流れ方を反映できるようになってきます。そして、たまに別のマレットを使っても、自然にその音に近づけるようになりました。そこで気がついたのが、

「道具が人を育てる」

ということです。

開発ツールやプロセスを導入することで人が育つ

 私はここ数年、スクラムテスト駆動開発継続的インテグレーションドメイン駆動設計、Spring、Intellijなど、色々な開発プロセスフレームワーク、開発ツールに取り組んできました。幸運にも組織がそれを許しサポートしてくれたお陰で、組織やルールという意味で大きな障害が無く、ほぼ開発チームがどう活かすかという点だけに集中して取り組むことができています。とてもありがたいことです。

 これらに取り組んだおかげで、大きく変化しました。何が変化したかというと「人」と「組織」です。例えば、スクラムに取り組むことで、メンバーが自発的に考え仕事をするようになり、テスト駆動開発継続的インテグレーションをやることで、テストコードを書いて毎日カバレッジを意識するようになり、ドメイン駆動設計を行うことで業務をオブジェクト指向で表現をできるようになり、SpringのDIとDDDを組み合わせることで依存関係逆転の原則に則ってドメインオブジェクトを独立させるように努力するようになり、Intellijによって名前(スペルミスも含め)に気をつけ、リファクタリングを意識しIntellijの機能を使ってやるようになる。

 組織もその効果に合わせてルールや組織の体型を変えていく。私の組織は驚くほどフラットになりました。基本的にマネジメントは開発チームを極力邪魔をしないように努力をしてくれています。

 これらは一例ですが、私も含めもともとそれに取り組んだ人たちが世界のトップレベルのプログラマのようなレベルにあるわけではありません。その辺によくいる普通のエンジニアです。そういう人たちがこれらのツールを導入することによって勉強し、それに合わせて変化をしていった。ツールを導入したこと云々ではなく、それが最も大きな成果だと感じています。

目標はツールの導入ではなく人の成長である

 これまで私の開発してきた環境では、「ツールを導入するとツールが何とかしてくれるから良い開発ができるんだ」という前提でいろいろな開発手法やツールを使ってきました。しかし、残念ながらその多くは成功しませんでした。現実の案件や人やお客さんと合わなかったり、スピード感が違ったり。それはツールの問題なんじゃないかと思っていた時期もあったのですが、ずっと違和感を持っていました。「ツールは手段であり目的ではない!」というのは同感なのですが、では何が目的なんだというしっくりくる答えは出ていませんでした。ただ最近、音楽もシステム開発もやっててようやくこう気づきました。


「優れたツールを使う目的は、人を成長させるためである」


 優れたツールというのは、器が大きいです。使う人がそのツールに合わせることができれば、多くのことに対処でき、効果を上げることができます。違う言い方をすると、ツールに合わせるように努力するだけで、本質的にシステム開発に必要な優れた考え方を自然に会得し、良い開発ができるようになります。同時に自然にその人の能力も向上していきます。ここまでくれば開発効率が上がり、いい設計などのアウトプットが出てるはずです。もしツールを変えたとしても、その基本的な考え方はその人に残っていきます。

 話題になっていたり優れているように見えるツールを見ると、導入してみたくなります。まずは導入することは必要なのですが、少しでも効果が出ると一気に会社全体に広げるとか、スピード感を一気に上げたくなります。ただ、残念ながら人の成長には時間がかかります。そうなると、意図も伝わらず導入が成長を追い越してしまい、それほど効果が無いじゃないかということで止めることになります。
 逆に、「組織に合わないから導入できない」という話も聴きますが、そのメッセージは自分たちを変えるつもりがないということとイコールになり、ツール以前に大きな問題です。そういう組織は、どんなツールを導入したとしてもうまくはいかないでしょう。

 そう考えると、何も考えないで優れたツールに人も環境も合わせてみるというのも選択肢の一つかもしれません(守破離)。ツールを上手く利用して人が成長していく(守破離)。最終的にはそのツールでも物足りなくなり、自分でツールを作ったり、新たにもっと優れたツールを使っていく(守破離)。

 そのような人や組織の成長曲線を作っていくことを目的にツールを導入していけば必ず効果が出ると思っています。

アウトプットするということ

この間、入っているオーケストラの演奏会が無事終わった。パートは第九のティンパニをやらせてもらった。

f:id:tsuyok:20130928154912j:plain

練習を開始してから半年間、運営面でも演奏面でもとても苦労した。運営面では合唱やソリストがいたり、演奏面は個人としてのハードルの高さとオケとしてのアンサンブルという意味でのハードルの高さ。第九はベートーヴェンの野心作で、初演も耳が聞こえないのに大変な想いをして本番を迎えたわけだが、その時代からずいぶん文明が進んだとはいえ、同じようにハードルはたくさんあった。

アマチュアとしては、多くの準備時間をかけ、万全の体制で本番を迎えた。練習通りに本番を迎えられるか、いや、合唱もソリストも入るし、会場も大きなところでやるわけだから、練習通りに行かないが、それでも万全に準備したことを活かそうと1500人を超えるお客様の前に立った。

自分で驚いてしまったんだが、過去に無いくらい集中していた。常に次に来る音符のイメージを考えながら演奏することができた。当然うまく行ったところとそうでないところはあったが、それが認識することができるくらい集中していた。

本番前に指揮者の方とお話していて、本番はいかにオーケストラが自分の限界を越えようとするかが成功するかどうかのポイントだ、というようなことをおっしゃっていた。指揮者は練習でほとんどの仕事は終わりだ、という人がいるが、私はそれは信じていない。本番は特別だ。本番には魔力がある。良くも悪くも練習と違うものが出る。それが生きた演奏になる。予定調和の演奏なんて聴いて面白いわけがない。

多分にもれず、私にも魔力がやってきた。これまで、どちらかというと他人に合わせて、もしくは他人がどう出るかを元に自分の演奏を決めていた。しかし、何故かその時覚悟が決まった。自分の意志を込めた。他に200人近くの演奏者が同時に演奏している部分で、周りがどうしようと自分の方向を変えず、維持し続けた。そうすると、不思議なことに、周りが自分に集まってくる。

やっとだ、やっと少しだけわかった。これが第二の指揮者と呼ばれるティンパニだ。あーあ、今まで何をやっていたんだ。ひどいもんだ。散々皆さんに迷惑をかけていたわけだ。情けない。オーケストラは、練習やそれ以外で言葉で他の人達とやりとりをする上で良くすることはできるが、最も大切なのは演奏中のアンサンブルだ。どんなに素晴らしいことを言えても、演奏でできなければ何の意味もない。現場で説得力がある仕事をしなければアウトプットをしたとは言えない。そうだ、そういうことなんだ。

趣味でやっているというのに、たった1回の本番でたくさん学ぶことがある音楽というのはすごい力がある。そこに普遍性もある。趣味というのはやっていて損はない、というかやっていたほうがいい。それもこれも素人なりに一所懸命やったからなのかもしれない。でも、少し疲れたな。ちょっと時間をかけすぎた。

あ、あと、録音聴きたくないな…。全部勘違いなのがわかってしまう。

プログラマとしてレベルを上げるために必要な4つの要素

最近、プログラマの成長について考えることが多くなりました。自分自身についても仲間についても。成長しているメンバーが集まらないといいモノは作れません。個人としても、エンジニアは常に成長していかないと仕事にならなくなる瞬間がやってきます。簡単にできるものではありませんが、やらざるを得ない状況でもあり、これまでの経験からプログラマとしてレベルを上げるために必要な要素を整理してみました。

1)基礎
コンピュータサイエンスやプログラミング言語です。まずは基本が無いとしっかりとしてものを作ることができません。
2)師匠
ノウハウというものは言語化できるものばかりではありません。ちょっとしたコツや考え方は、出来る人と一緒に仕事をすることが一番です。教えてもらい見て盗む。また、一緒にやることで自分自身が感じられる世界を広げることもできます。
3)実践
実際のプロジェクトです。やり方ばかりを学んでも、実践し自分で考えて作る場がないと成長できません。プロジェクトは何のために行われるのか、そのために何が必要か。また、プロジェクトはチームでやるもの。他の仲間との関係性やコミュニケーションの取り方、進め方を実践から学んでいきます。

f:id:tsuyok:20131205005822p:plain

これらが相互的に重なり合ってレベルが上がっていきます。順番があるわけでもなく、どれか一つができれば卒業ということもありません。そして、3つの要素のベースとなるものが

「センス」

です。言葉にしなくても感じるセンス、少ない説明で理解できるセンス、すぐにアウトプットに繋げられるセンス。すべての係数に掛け算として関わってきます。つまり、残酷ですがいくら上記3つを時間をかけても、センスが無いと成長角度は小さいままです。その場合、長い人生を考えると、早いうちに諦めたほうが得策です。

これが私なりに整理した結果ですが、特にプログラミングを行ったことが無く、マネジメントに従事している方々は、経験と違うと思われるかもしれません。Excelの設計書さえあればプログラミングは誰でもできる、という考え方をよく聞くためです。なかなか伝わりにくいのは事実です。

プログラミングは、ソフトウェアは動けばいいという考え方もあり、とりあえずソフトウェアが動いてしまうとそこで貢献したプログラマが誰なのかが可視化しにくいのです。つまり、職場の人たちの仕事ぶりを遠くから見ていたとしても、誰が優れているのかいないのかはまったくわかりません。本当の個人のレベルは、一緒に仕事をした人しかわかりません。一緒に仕事をしていないのにわかったことにしてしまうと、教育をすれば誰でも伸びるのではないかという誤解や、正当ではない個人の評価が蔓延ります。

クラシック演奏家をベースに考えてみた

実は、これは元ネタがあります。私はオーケストラで打楽器をやっているのですが、楽器で成長するための実感です。ということで、上記の3点をクラシックの演奏家に当てはめてみたいと思います。

1)基礎
音階練習のような基礎練習です。また、楽典やソルフェージュなど、音楽の基礎もあります。個人の努力の積み重ねと、知識は音楽教室や音楽学校で習うことができます。
2)師匠
優れた音楽家につくことで、直接教えてもらったり、演奏を見たりし、自分の引き出しを増やしていきます。演奏の仕方だけでなく、作曲家の特徴や、音楽とはなにか、プロとしてどのような姿勢でいる必要があるのかなど色々なことを学びます。
3)実践
オーケストラやアンサンブルでの演奏です。合奏は複数人でやるものです。アンサンブルは一人では練習できません。複数の人とのアンサンブルを重ねることにより、そのコツを掴んでいきます。また、聴衆とのふれあいやフィードバックから学ぶことも多くあります。

プログラマと同様に、それぞれの掛け算で「センス」が必要です。もうこれが無いとアマチュアでいたほうがいいです。努力ではどうにもなりません。私もプロになろうとは一度も思ったことはありませんでしたが、なにか間違ってプロになろうと思わなくて良かったと思っています。

つまり、私の実感として、プログラミングというのは、音楽家と極めて近いもでした。ダメな人は本当にダメです。逆に出来る人は勝手に信じられないスピードで伸びていきます。教育は絶対に必要ですが、教育だけでも何ともなりません。

現状は、例えば未経験でもセンスを見ずに学歴とコミュニケーション能力がアレば…云々で採用してしまい、どうしようもないソフトウェアが量産されていくということがあるようです。そして、一部の下請けの下請けくらいのある程度競争を勝ち残ってきた人材がプロジェクトの鍵をにぎるということが起こります。さらに、なぜかその人の給料が一番低いという悲劇が…。

プログラミングだけじゃないかも

今回はプログラミングの話としてみましたが、プログラミングだけでなくマネジメントもその他も実は近いものがあるのではないでしょうか。そしてそういう仕事こそセンスが高い人が努力を重ね、レベルが上がれば大きな価値を生む。もし、センスがゼロでも努力だけでなんとかなるような仕事は、簡単に変えがきいてしまうので、価値も生みにくいですし、個人のキャリアとしてもリスクが有るということではないでしょうか。

ちゃんと見れる人が、人を見て採用し、人を見て評価し、人を見て役割を決める。自分自身の成長も、採用も、現場での評価や給料体系も、この考え方をベースにできないかなーと毎日悩んでおります。

【DDDメモ】サービス

エリック・エヴァンス ドメイン駆動開発P.104 ソフトウェア表現されたモデル サービス

 ドメインから生まれる概念の中には、オブジェクトとしてモデル化すると不自然なものもある。こうしたドメインで必要な機能をエンティティや値オブジェクトの責務として押し付けると、モデルに基づくオブジェクトの定義を歪めるか、意味のない不自然なオブジェクトを追加することになる。
【中略】
優れたサービスには3つの特徴がある

  • 操作がドメインの概念に関係しており、その概念がエンティティや値オブジェクトの自然な一部ではない。
  • ドメインモデルの他の要素の観点からインターフェースが定義されている。
  • 操作に状態が無い。

【中略】
ドメインにおける重要なプロセスや変換処理が、エンティティや値オブジェクトの自然な責務ではない場合、その操作は、サービスとして宣言される独立したインタフェースとしてモデルに追加すること。モデルの言語を用いてインタフェースを定義し、操作名が必ずユビキタス言語の一部になるようにすること。サービスには状態を持たせないこと。

 サービスの責務は、気を抜くとどんどん大きくなる。エンティティや値オブジェクトの責務をサービスに書いてしまう。それは、どうしても仕様を手続き的に分析し、それをもとにサービスを書いていくという点がある。そうならないよう、ドメインモデルとユースケースや業務フローと行ったり来たりしながら、モデルにフィードバックをしていく必要がある。

【DDDメモ】関連

エリック・エヴァンスのドメイン駆動設計 P.81

 現実の世界では、多対多の関連がたくさんあり、その多くはもともと双方向である。【中略】だが、これらの一般的な関連のせいで、実装と保守が複雑になってしまう。しかも、こうした一般的な関連は、そこにある関係の性質について、ほとんど何も伝えないのだ。
 関連をもっと扱いやすくするには、少なくとも3つの方法がある。

  • 関連を辿る方向を強制する
  • 限定しを付加して、多重度を効果的に減らす
  • 本質的ではない関連を除去する

 関係性をできる限り制限することが重要だ。双方向の関連があるということは、両方のオブジェクトが一緒になった時にしか理解できないということを意味している。アプリケーションの要件が双方向に辿ることを求めないなら、一方向にだけ辿るようにすることで、相互依存関係がヘリ、設計がシンプルになる。ドメインを理解することで、本来はどちらの方向性が重要であるのかが、明らかになる場合がある。

 初期のドメインモデルの設計や、クラス設計をすると、業務にある言葉全てをオブジェクトにし、関連を持たせたくなる。現実的には存在するオブジェクトや関連であっても、あくまで目的はあるアプリケーションを手段に価値を提供することだであり、価値を提供できないオブジェクトや関連は存在意義が無い。同時に、そういうオブジェクトが増えてくると複雑化し、本質的なモデルが認識しにくくなる。そういう意味でも、現実に存在したとしても、モデリングは価値を生むオブジェクトや関連に絞るべきだ。

【DDDメモ】モデルの整合性を維持する:腐敗防止層

腐敗防止層

エリック・エヴァンスのドメイン駆動設計 P.374

 外部システムとのインタフェースには多くの渉外がある。例えば、インフラストラクチャ層は、プラットフォームが異なっていたり、異なるプロトコルを使用していたりするかもしれない他システムとの通信手段を提供しなければならないのだ。他のシステムのデータ型は、新しいシステムのデータ型に変換しなければならない。見過ごされがちなのは、他のシステムが同じ概念ドメインモデルを使用していないという可能性である。

【中略】

低レベルのインタフェースを使うと、他システムのモデルの持っている、データを説明し、その値と関係性を制約する力が奪われてしまう。また一方で新しいシステムに対しては、自分のモデルの言葉にないプリミティブなデータを解釈するという負担を課すことになる。
 必要なのは、別のモデルと接している部品の間で変換できるようにすることにより、異質なモデルの要素を消化しきれずにモデルが崩壊しないようにすることである。
 それゆえ:
 隔離するためのレイヤを作成することによって、クライアントに対して、独自のドメインモデルの用語で表現された機能を提供すること。この双は、既存のインタフェースを通して他のシステムと通信するので、他のシステムを修正する必要はほとんどないか、全くないこともある。内部的には、このレイヤが必要に応じて、2つのモデル間での変換を両方向に対して行う。

 すでにあるシステムを新しくする場合、一気に全てを捨てて新しくできることはそう無い。現状のシステムを残しつつ新しくしていくという形が多いのではないか。そういう意味で、腐敗防止層を設けてインタフェースを明確に定義するというのは有効。古いシステムになると、そのインタフェースもドキュメントが陳腐化していたり、知っている人がいなかったり、使ったり変更するのが難しくなる。そういう意味でも、仕様をもう一度洗い出し、定義し直すというのは意義があるものだと思う。

エリック・エヴァンスのドメイン駆動設計 P.379

 どんな統合にも、オーバーヘッドはつきものである。単一の境界づけられたコンテキスト内で徹底して継続的な統合を行う場合から、共有カーネルや顧客/供給者開発者チームといった、それほど深く関わりの合わないものを経て、一方通行の順応者や腐敗防止層といった防御的な態度に至るまで、オーバーヘッドは存在する。統合は非常に有益かもしれないが、必ず高く付くのだ。それが本当に必要かは、確かめなければならない…。

 設計としてはあるべき姿があるが、オーバーヘッドやコストがかかるという事実がある。その点に関しては気をつける必要が有る。作っただけで何も効果がないどころか、余計に手間とコストがかかるようでは、そもそも何のためにやるのかがわからなくなってしまう…。