前方倒立回転跳びーーハンドスプリングといった方が通じるだろうか。体操の跳馬で内村航平選手が跳んでいるアレの、複雑な工程を廃し最も簡単な跳躍部分だけを行う技である。

17年前、私は中学生だった。異動してきた体育教員は昨年までの教員と方針が違うらしく（ひょっとしたらカリキュラムも変更されていたのかもしれないが）夏休み明けから跳び箱を跳ぶ羽目になった。
小学校と同時に卒業したはずの、6段手前でもたつく私を尻目に皆が8段を飛んでいたあの跳び箱が、再び私を苦しめる。そのはずだった。

前方倒立回転跳びーーハンドスプリングと呼ばれるその跳び方は、運動スキルの高いサッカー小僧もヤクルトスワローズ外野手の息子（何故かいたのだ）も苦しめた。当然私も出来無かった。

体育教員曰く「ロイター板を強く踏め！」「体を伸ばせ！」「ビビるな！」
他にも何か言っていたはずだが覚えてはいない。参考資料にきれいな図解が載っていたが、なぜその跳び方が可能になるか、私には読み取れなかった。

気付き　初めて繋がった運動と数学

体調不良かズル休みだったかは記憶にない。今はEテレと名を変えた教育テレビで高校講座を見ていた。数学だった。ベクトルの合力の解説は、休みの後ろめたさも後押ししてか空っぽの頭にすんなり入ってきた。
講師曰く「x軸の正の向きの力と、y軸の正の向きの力が合わさっただけ」「この式を図式したものがこの斜めの矢印になる」

不貞腐れ気味に順番を待つ私の目に勢い余って分厚いマットに顔から突っ込む同級生の姿が映った時、何かがつながった。

「ひょっとしてこれは……ベクトルなのか！？？」

助走がx軸の正の力だとすれば、ロイター板の踏切がy軸の正の力なのか？だとすれば二値の合計が跳躍なのだろうか？だとすれば負の力とは何か？
同級生が頭から突っ込んだのはy軸方向の力が弱いために……回り始めた頭に体育教員の言葉が入り込む余地は既になく、私を罵る野次も遠くなっていた。

二度の観察で予感を確信に変えつつあった私は遂にその時を迎える。余計な力が働かないよう可能な限り恐怖心を押し殺し、助走を殺さず前向きの力を、強く踏んだロイター板の反作用で上向きの力を得た体は二値の合計を体現する跳躍で人生初の喝采を浴びた。

今思えばこれが始まりだったのだろう。喝采の跳び箱以来、私の考え方は変わっていった。分野の異なる学問は決して無関係ではなく、異なるアプローチをしているだけで別々の視点を活かす方法があるのだと考えるようになっていったのだ。二年後、改めて物理と数学を知ることになったが、苦でなかったのはこの体験のおかげだったかもしれない。

体育教員はどうすれば跳べるか？ではなく、なぜ跳べるか？を示すべきだったのだ。（数年後の話だが大学で暇に飽かせて調べたところ助走局面・踏切局面・着手局面・空中局面などのシーンごとに理屈が詰まっており、それほど単純なものでもなかったのだなと笑った覚えがある。）必要なら理科や数学教員の手を借り、跳躍の仕組みを分解する試みも有効だったかもしれない。現在のカリキュラムがどのような指導方法を推奨しているのかは知らないが、なぜ？を考えることと、他の教科を手がかりにする能力は中学生なら十分備わっているはずだ。

コードの読めないITマン

授業で一度喝采を浴びた程度で五輪を目指したりはしない。普通に大学を卒業した私は人手不足甚だしいIT業界へ進んだ。

文系の三流大を漫然と卒業した身にプログラミングスキルなどあるはずもなく、ポッカリと空席だった営業部に配属される。たった一人の営業部員。上司も部下もなかったが便宜上社長が面倒を見てくれる格好になった。

曰く「SESは多重派遣ではない」「我々は下請けではないパートナーだ」「銀行の案件は断れ」「Javaを探せ」「Javaはいたか？」「Javaはまだか？」

あーるすぺっく 必ず失敗するように

ろくな案件のない社内で一つ、生き生きしている（ことになっている）チームが有った。アジャイル開発チームだ。Rubyという開発言語を聞いたことはないだろうか？
チームリーダー曰くレイルズ（Ruby on Rails＝ruby開発等に用いるフレームワーク）を使いこなせれば受注単価は鰻登り。稼働も短くできるとのこと。まんざら嘘でもなさそうなので、社内ニートの給料泥棒は手に余る就業時間を使いざっと概要だけ舐めて話についていこうとする。とことん不真面目だったのだが件のフレームワークを調べる内、奇妙な記述を見つけ目が止まった。

テストケースは必ず失敗するように書く

奇妙ではないだろうか。テストとは書いたコードが想定通りの挙動をするか確かめるものだ。想定通りに動くことを確かめるのだから、想定ケースを列挙していくのだろうとその時の私は考えていた。
しかしテストケースを記述するRspecとは、失敗することで動作を規定するという、イメージと反対の手法だったのだ。テストの記述作法一つの話ではあるが、なにかが腹に落ちていく感覚が有った。

理屈の確かめ方 その失敗は失敗として正しい

必ず失敗するテストケースを書くとは、言い換えれば外側からプログラムのあり方を規定していくような、輪郭を描くようなものではないだろうか？
必ず失敗するテストという座標が複数集まると、それらの並びがさながら輪郭線のように、内側のプログラム像を立ち上がらせる。そんなイメージが強く浮かんできたのだった。

物事の正しい佇まい・理屈を確認する時、間違った姿勢を突きつけ失敗させることでも正しさを規定できる。
間違った姿勢を突きつけたとき、もしも失敗しなかったら？間違いに気付かず、正しいと勘違いして本来望ましくない挙動をしてしまったとしたら？？

その理屈には誤りがあるのではないか？だって失敗しなきゃいけなかったのに。。

既にお気づきの通り私は今でもコードが読めない。プログラミングスキルは毛ほども身につかなかった。慇懃無礼なメールを打っては足繁く単価交渉へ出向く、スマートとは程遠い営業マンだったのだから当たり前だ。（そんな奴がどうにかこうにか受注案件を複数回せてしまうのだから不思議な業界である。）
それでも　テストは必ず失敗するように書く　この視点を得られて、視野が広がった気がするのは勘違いではないと信じている。

安心してほしい

跳び箱とRspec　如何でしたか？エンジニアにおかれましては突っ込みたくてうずうずしていらっしゃるか呆れていらっしゃるか、イライラさせてしまったかもしれない。私はあなたの会社にも取引先にもおりませんので安心してほしい。元同僚の皆様におかれましては特定するとか電話をかけてくるとか当時の素行をネットに流すなどの行為をどうか、どうかそれだけはご勘弁を。
私の視野を広げてくれた気付きや出会いは他にもあるが、それはきっとあなたにもあったはずだ。
願わくば、あなたの視野を広げてくれた体験や考えをいつか共有してほしいものだ。またいつかお会いしよう。