決済システムの構築は、ショパンのワルツを演奏するのに似ている。問題解決における万能的な方法がそこには含まれていて、どのような問題にも適用することができる。

先日、Erlangを学習しているという若いプログラマから、なかなか興味深いメールが送られてきました。その内容は、金融システムのサイトを構築するのにErlangは適切であるかどうかを知りたいというものでした。高度な並列処理を行うフォールトトレランスなアプリケーションの構築にはErlangが適した言語であるという記事を目にしたのと、私の本を楽しんで読んだことで、彼はErlangに興味を持ったのだそうです。

彼の質問に対する私の回答は、「プログラムYにXは適切なのか？」というタイプの全ての質問に対する回答とほぼ同じです。同じ質問に何度も答えることを避けるために、その回答をここに記したいと思います。

問題を解決する際には、まず最も難しい問題から解決せよ。

問題を解決する際に、あなたが直面するであろう、最も難しい問題が何であるかを知ることはとても重要です。最も難しい問題を解決することができなければ、その問題に対処するときにお手上げ状態になってしまいます。

全ての問題を解決するための一般的な手法は、以下の通りです。

• まず、最も難しい未解決の問題を見つけ出す。
• それを解決する。

残された問題が些細なものになるまで、そして自分で解決できると自信が持てるまでこれを繰り返します。

ただしこの手法の問題点は、いざ取り掛かろうと思った際に、最も難しい問題が何であるかに気づくことができない可能性があることです。それが分かるという人は、専門家であるか、これまでに大規模な金融決済システムを構築し、成功に導いたことのある人なのでしょう。

最も難しい問題が何であるかを探すのは簡単です。

最も難しい問題が何であるかは専門家に聞け。

この練習の一番難しい点は、専門家を探すことかもしれませんね。

専門家の知り合いがいない場合はどうするか？

専門家の知り合いがいないのであれば、その道の専門家をリサーチし、連絡を取りましょう。

私の経験上、丁寧で親しみやすいメールであれば、約50％の確率で、専門家から役立つ情報を得ることができます。専門家と呼ばれる人たちの多くは、彼らが持つ知識を喜んで共有してくれます。それも、彼らの専門分野が何であれ、それについて説明する機会が持てるからです。この方法で、興味深い話がたくさん聞けることでしょう。

決済システムにおける難しい問題とは？

私自身、大規模な金融決済システムを個人的に構築したことのある人と2人ほど話をしたことがあります。最も難しい問題は何であったかを彼らに質問すると、以下の2つの回答を得ることができました。

• 規制当局を満足させること。
• レガシーシステムとの相互作用。

金融システムにおける規制は必要不可欠です。金融取引は規制当局による承認が必要で、ソフトウェアが正しく機能していて高性能であるというだけでは不十分なのです。ソフトウェアが正しく機能し、かつ全ての規制に従っているということを規制当局に納得してもわらなくてはいけません。

金融システムは孤立した状態で機能するのではなく、古い言語で書かれたレガシーシステムと、奇妙で満足に文書化されていないプロトコルを相手に相互作用しています。「現状のままの世間のシステムと相互作用し、かつ私たちの望むシステムになっている」という条件を満たさないのは大問題です。

妙なことに、どちらの専門家もパフォーマンスを問題視しませんでした。実際、パフォーマンスを問題として挙げる者は誰もいないと言ってもいいくらいです。ソフトウェアが実際に動作し（ほとんどのプロジェクトは、「ソフトウェアが実際に動作しない」という理由により中止されてしまいます。そのため、動作した場合は大抵、奇跡と見なされます）、その動作が遅い場合、通常の解決策は”より多くのマシンを投入する”ことだけです。

数十億人のユーザを抱えていない限り、パフォーマンスは問題ではありません。初日にその問題に直面することは絶対にありません。パフォーマンスが問題となるところまで達したら、プロジェクトはかなり大きな進歩を遂げたということです。そうなると、最も難しい問題は、システムをとにかく動作させて、それを使用する勇気のある者を数人見つけることになるでしょう。

私は常に、 どんな プログラミング言語を使っても問題を解決することができると考えています。これはコンピュータサイエンティストの間では”チューリング等価”と呼ばれています。ですから、もしHorribleTran9で問題を解決することができれば、SuperNifty2でも問題を解決することができるでしょう。

とは言うものの、同一の問題を異なるプログラミング言語で解決する場合は、難易度が違います。ある言語では解決が難しくても、別の言語では容易ということもありますし、 その逆もあります。

あなたの抱えている難題がフォールトトレラントなものを作ることであれば、Erlangは良い選択です。Erlangはフォールトトレラントなシステムを構築するために設計されました。 なんと 、それがたまたま優れていたのですが、これは偶然ではなく設計によるものです。

Erlangは、GUIの作成、大量の演算、花の水やりには役に立ちません。それには別のテクノロジを選んでください。

最大の難題を選び、それを最初に解決することによって問題を解決するという一般的な方法は、多くの問題に適用できます。

ショパンとどう関係しているのか？

現在、私はショパンのワルツ第7番嬰ハ短調 作品64-2の演奏を習っています。

習い始めた時、音楽の先生はすぐに4小節目を指し、「まずこの小節を練習して、たくさんのYouTube動画を見てください。1日20分はその部分を練習しなければなりません」と言いました。

私はすぐに「1日20分は少しやりすぎだ」と思いました。この小節はたった16音符だけだからです。1日20分の練習を7日間した場合、その140分は言い換えると1音符当たり8分になります。

しかし、私は先生に言われたことを行い、比較するためにVladimir AshkenazyとVladimir Horowitzをはじめ、その他数名の演奏を録音しました。しばらくするとVladimirたちと同様に4小節目を弾けるようになりました。

私はこのことを子供のように喜びました。Ashkenazyと同じように4小節目を弾けたから、残りはたったの191小節だと思ったのです。先生が次に指示したのは33小節目から始まるPiù Mosso（より速く）の部分でした。世界最高のピアニストと言われるHorowitzは殺人的な速さでその部分を演奏します。私がそこをHorowitzのテンポで弾くのは絶対に無理ですが、自分の脳をビックリさせるくらいには速く弾くことができます。今では私の手や指は脳が理解できない速さで動きます。

比較のために、HorowitzとDysonを聴いてみましょう。

• Horowitz （38秒の部分）
• Dyson （1分08秒の部分）

Horwitzのトータルの演奏時間が3分13秒なのに対して、Dysonは4分53秒です（”どのくらい速く演奏できるか”ということが妙技だと定義されている場合に、その演奏時間の短さによって、Horwitzが高く評価されたのではないかと思います。個人的にはより現代的な（そしてゆっくりとした）解釈の方が好きです）。

そして、私は習得していませんでしたが、65小節目以降にPiù Lento（よりゆるやかに）があります。メロディが左手から右手に、巧妙に美しくシフトします。

そして84小節目です。

左手に3つの音符があるのに対して、右手は8連符になっています。「ショパンさん、冗談でしょう？」

私の持論では、ここではショパンは音楽的にかんしゃくを起こし、符号で表すことの限界にまで到達したので、自分が求めているものを単に曖昧に示唆したのだと思います。ベースの3つの音符を奏で、左手と右手の指が次の小節の最初のコードを弾くために間に合うように弾けばいいのです。それほど難しいことではありませんが、単純な8対3のテンポではありません。

休止符は簡単です（実際はそうではありません。テクニックとしては簡単ですが、細部への注意が必要です）。

ショパンの弾き方を習うことには、複雑なソフトウェアシステムを構築するのと全く同じ精神的な規律が含まれます。

• まず、最も難しい未解決の問題を見つけ出す。
• それを解決する。

難しい問題がなくなるまで、これを繰り返します。

残った問題を全て解決し、細部と品質管理に注意を払いましょう。

終わったら、標準以下の部分全てに磨きをかけていきます。

私は今では、Op.64を全て通して弾けます。でも、楽譜なしでは弾けません。基本的な作業は終わりましたので、今度は磨きをかけるべきなのです。

短所を教えてください

作業が完成に近づいたら、何が間違っているかを知るのは必須です。私の音楽の先生もそうします。先週、私はOp.64を最初から最後まで弾きました。通して弾いたのは、その時が初めてでした。弾き終えると、先生は次のようなコメントをくれました。「右手が少々あやしいですが、それは大丈夫です。でも、左手の和音でいくつか失敗したか間違っているところがあります。」私には、それを知る必要がありました。

西洋では、褒めたり激励したりする文化があり、初心者が冒す間違いを逐一批判するのは、いい方法とは言えません。しかしある時点から、激励は批判に変わらなくてはいけません。激励は、あなたをやる気にさせるのにはいい方法ですが、完璧を目指すためには不十分です。

私はこのことに、数年前に気づきました。生徒から学部学生、それから博士課程の学生へと移り変わっていく過程で、より批判が多く、より称賛が少なくなっていきました。

批判に関して覚えておかなくてはいけないのは、批判されているのはあなたではないということです。あなたではなく、あなたの仕事を批判しているのであって、その目的はあなたの仕事を向上させるためなのです。批判の受け取り方は重要です。もしも批判を攻撃だと思えば、拒絶してしまうでしょう。でも自分のやっていることを改善させるための手段だと思えば、有用だと気づくはずです。