作ってから考えよ

先日語ったEF66の台車について、一つ気になっていた事がある。

kohsuke.hatenadiary.com

作る過程で、見えないものを随分と細かく作らされるのだ。例えば、ある工程で、大きな歯車を苦労して車輪にくっつけたと思うと、次の工程では覆いを作らされて歯車はその中に隠れてしまう。モーターの精巧な模様も一緒に。完成したら見えない工程に何の存在意義があるのか。そんなのが幾つもある。

そんなところへ、あの記事に感応した同僚から、吊り掛け駆動方式というWikipediaの記事が送られてきた。これを読んだらガツンとやられてしまった。

 

全く僕は何を見ていたんだと思った。

 

Wikipediaの記事では、台車上にモーターを配置するという構造が、どういう意図で設計されたのかが解説されている。僕が無駄だと思っていた工程の一部は、この設計の肝になる部分を手でなぞるためであったのだ。隠れてしまう「のに」ではなく、実物では隠れている「からこそ」、内部構造を知るには模型でも作る他はないのだ。

吊り掛け方式とは、モーターの片側は車輪の軸にがっちり固定、反対側は台車にバネで吊る仕組み。まさにこれを作らされた。わざわざ台車に吊る方は接着しないという念の入れようで。ただ言われたとおりに作っただけだが、この手で作った後だから、その後で記事を見ていると、頭の中でその構造や働きが明瞭にイメージできる。写真のカレーと、目の前にカレーが実際あるのと位の違いだ。匂いや質感や、立ち上がる湯気がのようなもの。

他にも見逃していた物はないのか。更に読み進んでいく。この吊り掛け駆動方式というのは速度が上がってくると様々な問題が発生するので、向いていないとある。まてよ、EF66は高速運転用に設計されたと聞いたのにそれはおかしい。調べていくと別な記事に辿り着く。これは理解できなかったが、やがて機械学会に大昔に寄稿された記事に辿り着き、それに掲載されていた写真を見て、また目から鱗である。ああ、あの工程で作った物にはそんな意味があったのか。

前回の投稿には「全てが合理的」と偉そうに書いたが、僕はこの設計にどんな合理性が詰め込まれているのか、ほんの少ししか理解していなかった事が分かる。調べていくと、暗闇にパッと灯りを付けたようになって脳内麻薬がドバッと出る。美術館に二回目に行ってオーディオガイドを使うような気持ち。

 

話は茶道へと飛ぶ。僕の好きな日々是好日という映画で、多部未華子演じる主人公が、樹木希林演じる茶道の先生へ入門する。意味の理解できない茶道の細かい規則に辟易して、なぜ?と問うと、樹木希林は「考えるよりまずは体で覚えるのよ」というのである。意味は後からついてくる。

www.nichinichimovie.jp

まさにこれだと思った。意味も分からずまず作っているから、意味が後で理解できるのである。理解してから作るのではない。そして、意味も分からずまず作れ、という不条理は、その対象に合理性がないという事を全く意味しない。習い手が未熟だという、ただそれだけの事だ。茶道も技術も同じだ。僕の本業のソフトウェア開発にだって当てはまるところがある。これが、守破離の守か。

 

僕の中でEF66の台車はさらに輝きを増し、もはや後光が差し始めている。 

f:id:kkawa:20210125013910j:plain

 

機関車が好きなのである

ごっつければごっつい程良い。黒光りする巨大な鋼の塊が骨を震わす低音を唸らせ、君臨するような威圧感と存在感で列車の先頭に鎮座する、ゲームのボスキャラみたいなのが大好きである。これに比べたら車なんて軽薄で玩具のようだし、飛行機はお高くとまっていて嫌味なくらいだ。そういうわけで、EF66という電気機関車のプラモデルを作っているのだが、台車を組み立てていて度肝を抜かれてしまった。

今まで、車体ばかりで台車なんて正直気に留めた事もなかった。大体にして、プラットフォームより下にあるから普段は目に見えない。しかし、作っていると、目に見えないこっちが主役で車体は飾りだという事がよく分かる。今まで何となく、車のようにモーターは車体の中に納まっているんだろうと思っていたが、実際には台車にくっついている。馬鹿でかいのが、6つも。そして、博物館でみる本物はあまりに重厚で車輪以外には全く何も動きそうにないが、プラスチックの手のひらサイズで作ると、実は台車は可動部分満載の「柔らかい」機械であることもよく分かる。例えば、6輪あるから、カーブの時は中央の台車は車体の外に少し出なくてはいけない。だから、前後方向には牽引力を伝えつつ、左右方向には動けるようにする仕組みが必要だ。車体が動く時に発生する上下動や振動の吸収は言うに及ばない。そして、それを取り巻くメカの数々。ブレーキ。ギア。軸受。バネ。それらの内臓ほとんど全てがさらけ出されていて、無骨で、飾り気ない。

その昔、ガンプラを作っていて、そのあまりの技術的合理性のなさに、こんな設計をするやつが本当にいたら阿呆だと感じたのを思い出した。あんな見た目に騙されちゃ駄目だ。所詮、エンジニアリングの事なんか何も分かっちゃいないやつの空想だ。それに比べてこいつはどうだ。1000tの重さを引っ張って100km/hで走るという目的のために全てが合理的。これぞ本物のエンジニアリングだ。何というカッコ良さ。この電気機関車を設計した技術者の人達は今どこで何をしているのだろうか。この仕事についてどこかに発表は残されているのだろうか。

こちらの三連休、こういう事を考えつつ一つ一つ部品を接着して至福の時間を過ごしていたら、台車が完成してしまった。これからこのカッコ良すぎる台車達が、車体の下にしまわれて見えなくなってしまうのかと思ったら、急にやるせなく感じられ、この気持ちを書き残すことにした。

もういっそこれで完成としてしまおうかな。

f:id:kkawa:20210118113734j:plain

f:id:kkawa:20210119061729j:plain


(二枚目の画像はWikimediaより)

 

大昔に自分が書いたプログラムが出てきた

高校時代の後輩が僕が当時書いたプログラムを見つけてくれた。山が崩れないように字牌を順番に取っていくというゲーム。Windows 3.1時代の16bit アプリなので現代のWindowsでは動かないが、僕はLinux使いなのでWineで問題なく動かすことが出来た。

f:id:kkawa:20210116233508p:plain

ソースコードもこちらに公開しておく。今ならもうちょっと抽象化の度合いをあげて実装すると思うけど、全体としてはそこそこ無難に実装されていて興味深く見た。必ずクリア出来るようなパズルが自動生成されるところなど、データ構造がよろしくなくて計算効率が悪いところを除けば、我ながら良く出来ているじゃないか。今度エンジニアのインタビューに使ってみようかな。

 

Launchableでは再びエンジニアを募集しています

Launchableでは再びエンジニアを募集しています。我こそはと思う人は、ぜひhello-applicant at launchableinc dot comまでメールして下さい。

f:id:kkawa:20201030134802p:plain

早いもので、Launchableを作ってもう一年が過ぎました。先日は、それを記念してvirtual team photoを作りました。

この会社は世界が股に掛かっています。シリコンバレーの投資家から資金調達して、開発者向けのツール作りに関わったproduct designerやproduct managerがいます。当初思い描いていたように、日本にエンジニアリング拠点を作ることも出来ました。この業界の皆さんはよくご存じのYoshioriさん、ninjinkunさんを始め、僕の大学時代からの付き合いである超絶エンジニアの岡嶋さん、仕事外でもプログラミングに精力的な北川さんと、とても力のある個性的なメンバーが参加してくれています。

yoshiori.hatenablog.com

ninjinkun.hatenablog.com

お陰で様で、ヨーロッパで、アメリカで、そして日本で色々なソフトウェア開発現場に我々の作った技術が広がりつつあります。テストの実行時間が掛かりすぎるのを何とかするという僕らの取り組みは、間違いなくソフトウェア産業にある大きな悩みの一つに正面攻撃をかけています。

このミッションに共感してくれるエンジニアの人にぜひ来てほしいです。世界に広がっているテクノロジー産業の繋がりを感じて、そこに加わってほしいです。ソフトウェア製品を作って売るというのはどういう事なのか、そのためにどういう役割分担が必要なのか、どうして日本だけに閉じていてはこの先成り立たないのか、Launchableに来て、ぜひそれを体得して、それを肥やしに次に繋げていってほしいです。僕がどうしてこの会社で日本にエンジニアリング拠点を作るのに拘っているかについては、詳しくここに書きました。

kohsuke.hatenadiary.com

そして、今回僕が特に声を届けたいと思っているのは、所謂日本の典型的なソフトウェア開発現場ではマイノリティである人達です。僕は最近、多様性について考えたり発信したりする機会が色々とあって、より多くの人がモノ作りに参加できる世界を作りたいと思ってきました。我々の会社は、最初から世界中に散らばって、リモートで時差を挟んで働いている環境です。オフィスで対面で長時間労働をしないとチームに溶け込めないような、そういう職場ではないです。子供が出来て生活サイクルが変わった人とかに、普通の会社では難しい柔軟な働き方を提供できると思います。対面労働の文化や習慣が定着した大きな会社では、その枠にはまらない人が輝くのは難しい。でも、僕らの会社はそうじゃありません。

ぜひ、Launchableに来て下さい。詳細なjob descriptionはこちらにあります。

www.launchableinc.com

一緒に仕事をしましょう。

 

クリエーションライン社の技術顧問を引き受けることになりました

ここ最近、日本とアメリカのソフトウェア産業に橋を架けようと色々な活動をしています。その縁で、今度、クリエーションライン社でも技術顧問の仕事を引き受けることになりました

クリエーションラインさんともお付き合いは長く、そもそもはCloudBeesでJenkinsの事業をやっている時に、日本でも導入・普及・コンサルティング・サポートなどを一緒に出来ないか、というお話が切っ掛けでした。この種の会社には珍しく、クリエーションラインさんにはLos Angeles在住の鈴木逸平さんという人がいて、アメリカの会社とちゃんと事業開拓をする体制が出来ていたのに関心したのを覚えています。

そして、クリエーションラインさんの面白いところは、ツールやソフトウェアのリセールだけじゃなくて、DevOpsやAgile支援、またソフトウェアの内製化を進めるコンサルティングを手がけているところです。

僕は、日本のソフトウェア産業アメリカのソフトウェア産業の違いの多くがソフトウェアの内製か外注かという契約構造にあるんじゃないかと思っていて、その上でそれぞれの合理性を理解し、そこから次の一手を...と思っています。その問題意識の中で言うと、クリエーションラインさんの方針は、アメリカ式のソフトウェア作りを日本に持ってきて成功事例を作ろう!という事で、それは応援したい取り組みだし、僕の経験や知識も役に立てられるんじゃないかと思っています。

仕事や役割分担の仕方といったものは、言葉やスライドで幾ら習うよりも、実際にやってみるのが一番だと思うので、日本にうまくアメリカ的ソフトウェア開発のモデルが根付けば、そこで経験した人達が次の職場に花粉を広げて...となるかもしれないな、と。

楽しみです。

f:id:kkawa:20200901062826j:plain

ウェビナー: 機械学習によるテスト選択と並び替え

f:id:kkawa:20200819010935j:plain

テスト時間掛かりすぎ問題。職業としてソフトウェア開発に関わった事のある開発者の方なら誰しも経験があると思います。時間が掛かるだけじゃなく、テストの頻度が低いし、実行しても信頼性のある結果が得られない。僕自身にも経験があります。プルリクエストの検証にテストが走るようにしたものの、時間が掛かる割には何の理由もなく失敗したり、その上テストが全件通ったから安心できるかといえば、そうでもない。そして、テストが通るまでの間の時間を潰すために、マルチタスクをする必要もありますね。

今年の頭に、Launchableを興したのは、ソフトウェア開発で昔からおなじみで、どこにでもあるこの問題を解決するためです。我々は機械学習の力がこの問題の解決に有用であると思っています。

今回、我々の取り組みを日本語で紹介するウェビナーを開く事にしました。この問題が、手を変え品を変え様々な形でソフトウェア開発現場にどのように現れるのか、そして皆さんがこの問題を苦労なく解決し、より質の高いコードをストレスなく出荷するためにLaunchableが何をしようとしているのかを紹介しますので、見に来て下さい。