2025年5月28日に『深堀りRubyKaigi 2025 with tompng & ima1zumi』を開催しました。イベントの内容をほぼ全文文字起こし形式でお届けします。この記事は後編です。
- プログラミングの最初は金融系のシステム
- 開発環境とエディタ
- Rubyistから見たCOBOL
- 文字コードの問題
- 文字は常にバイト列だし、バイト列しか信用できない
- Unicode実装への取り組み
- 質疑応答
- BigDecimalについて
プログラミングの最初は金融系のシステム
fujimura: では第2部ということで、RubyKaigi 2025 キーノートスピーカーのima1zumiさんに伺おうと思います。よろしくお願いします。
ima1zumi: よろしくお願いします。
fujimura: 改めて、自己紹介、プログラミングを始めたきっかけを教えてください。
ima1zumi: プログラミングを最初にやったのは大学生の時かな。私は経済学部出身なんですけど、C言語の講義をとりました。その講義では、紙にプログラムを書いて提出するというスタイルで、実行はしなかったんですけど。
その後、新卒で就職するときに、経済学部とも関係がありそうで、プログラミングがやれるんじゃないか、未経験だけどいけるんじゃないかという謎の確信があったので、金融系×SIerの会社を探しました。プログラミングを真面目にやりだしたのは、最初の金融系SIerの会社ですね。
fujimura: 金融のシステムって何をしてるんですか？計算？
ima1zumi: そうですね。保険系の会社だったんですけど、各種保険料の計算や営業職員さんのお給料みたいなものの計算をメインフレームの中ではやってました。あとは営業所に置いてある端末があって、そこから保険者さんの名前の変更などを入力するんですね。それがオンラインで飛んできて、ホストコンピュータ側に反映される、そんなシステムでした。
fujimura: 計算はすぐに実行されるんですか？それとも夜にやる？
ima1zumi: 夜ですね。データベースの仕組み上、オンラインで更新している時にバッチ更新をかけることができないっていう制約があって、で、一件一件の更新はオンライン時間中、朝の9時から夜9時ぐらいで、その後終わったら夜間バッチが動き出して、計算を一気にガッと回す環境でしたね。
fujimura: 大変なのは、終わらない時とか？
ima1zumi: 終わらなさそうな時はコールがかかるようになってました。
fujimura: 朝とか夜とか。
ima1zumi: はい。あとは1つでも途中で止まってしまうと、数珠つなぎになっているので朝、オンラインを開けることができない。私がいたのはインフラとアプリケーションの中間レイヤーみたいなところだったので、オンラインが無事始まって終わって、その日がつつがなく過ごせますように、ということをやっていました。
開発環境とエディタ
fujimura: キーノートではCOBOLやアセンブラって書いてましたけど、何でどうやって書くんですか？
ima1zumi: エディタは難しくてですね。3rdパーティ製のエディタとOSについてたISPF Editっていうエディタを使ってました。この中に使ったことがある人はいなさそう？結構低機能なエディタでした。例えば戻るボタンが何回でも戻れないみたいな、回数制限があるみたいな。
fujimura: 回数制限がある？
ima1zumi: 何回か前まで行っちゃうとUndoできないってことです。戻るを3回繰り返すとその先には戻れないみたいな。
fujimura: カーソルの戻るに回数制限があるのかと思った。
ima1zumi: そのエディタで良かったのは、Hexっていうコマンドを入れると常に16進数のバイト列が文字の下に表示されるという、それはなかなか他のエディタで見たことなくて、欲しいなってずっと思っています。
fujimura: 仕事上見る機会があるんですか？
ima1zumi: 結構あります。漢字入力をした後は不正なバイトが入ってないかっていうのを確認するために、大体Hexって打ってました。
fujimura: 不正なバイト？
ima1zumi: 入りますよ。
fujimura: エディタの話をもうちょっと聞いてみたいんですけど、感覚的にはedやviみたいな感じ？
ima1zumi: viは高機能だと思います。edはどういう機能だったか思い出せないんですけど、edよりは画面全体には出るので。
fujimura: 会場がいまedの話で盛り上がってる。そんなに使うこともないのに盛り上がれる、すごいエディタではある。
mame: そのエディタでもりもりとCOBOLとアセンブラを書いてたんですか？
ima1zumi: どっちかっていうと保守だったので読む方が長かったんですけど、書くときはそのエディタで書いてましたね。会社によっては自分の手元のコンピュータ上にコードを持ってきて書く会社もあると思うんですけど、私がやってたところはホストの中にSSHみたいなのに繋いで入って中で書くみたいな形でしたね。
mame: バージョン管理は？
ima1zumi: バージョン管理は3世代しかなかったんで3世代以上前は...
mame: 3世代？ゼロじゃないけど3世代？？
ima1zumi: 本番環境のコードが3世代分だけ残ってて、それより前のやつは確か磁気テープに保存されてたような気がします。
fujimura: テープ？
ima1zumi: 磁気テープ。磁気テープって多分今でも使われていると思います。
参加者: COBOLとアセンブラを同時に書くことが想像つかないけど、アセンブラはなぜ書いていたんでしょうか？
ima1zumi: なぜ書いていたかというと、インフラ部分のレイヤーで、アセンブラで書かれたプログラムが存在していたからですね。通信をつかさどるミドルウェアがあって、それを使ってたんですけど、それのプラグインがアセンブラで書かれていたり。あとは社内ツールですごく古いものはアセンブラで書かれてたりしたので。私が配属して最初に書いたアセンブラのコードは、文字を一個一個見てマッチしているかを確認するものでした。アセンブラのコードを書いてブランチとかを覚えました。
fujimura: STORES でアセンブラが書きたくなったらima1zumiさんに頼めばいいんですね。
ima1zumi: z/OSのアセンブラなので誰にも使えないと思います。
Rubyistから見たCOBOL
fujimura: Rubyistから見たCOBOLはどんな言語なんですか？Rubyistの皆さんにCOBOLを説明すると？
参加者: COBOLはRails。
fujimura: COBOLはRailsという説が...
ima1zumi: 確かにちょっとわかるかもしれない。言語思想としては英語のように書けるを志向した言語ではあるんですよね。代入の向きとか特徴的で、"MOVE A TO B"という書き方をするんですけど、これはAからBに右代入の形で行われる、これが一般的な代入方法ですね、というのがあったり。
その当時のコンピュータの制約を強く受けている言語だとは思います。私が触っていたCOBOLだと、列数の制限があって、70何列目以降は書いちゃダメみたいなのがあったりしました。自由度はあんまりない言語ですね。
fujimura: method_missingとかない？
ima1zumi: 想像もしたことがない。そもそも関数があったかな。
参加者: GOTOとか？
ima1zumi: サブルーチンはありましたね。
fujimura: サブルーチンって値が返ってくるんですか？
ima1zumi: 返ってくるというか、変数を全部最初に宣言するので。
fujimura: 余談ですけど僕が新卒でやった言語はABAPというSAP用のCOBOLに似た言語と呼ばれているやつなので、なんとなく想像がつきます。
mame: COBOLは書いたことありますか？
tompng: ないです。あまりわからない。
ima1zumi: Rubyを書き始めてから、COBOLに興味があるという人がいて、その人はCOBOLコンパイラを書くためにCOBOLについて知ったって言ってましたね。コンパイラを書きたい人がいたら、COBOLを。
文字コードの問題
fujimura: さっき漢字の話してたじゃないですか。EBCDICでShift-in Shift-outを使って漢字を入力する仕組みだったと思うんですけど、あれって壊れちゃった時どんな風になるんですか？
ima1zumi: Shift-outを間違って消しちゃっても、エディタ上は普通に見えるんですよね。なので思わぬバイト列になる。例えばCOBOL上で漢字を入力しました、漢字のShift-outを消して、クォーテーションで閉じるとします。その後はCOBOLの普通のアルファベットとして読めない状態になってしまうので、そもそもプログラムが実行できない、そういう状態になった気がします。
fujimura: 見た目は一緒だけど実行できたり、できなかったりする？そのためにバイトコードを見る必要があった？
ima1zumi: 漢字じゃないですけど、私が実際に一回やってしまったこととして、SQLの後の方に全角スペースを入れてしまって、それがエディタ上で視認できなかったので、実行したらエラーになってしまったことはありましたね。それで常に16進のバイト列で見る癖がついた気がします。
fujimura: Rubyは読めばどう実行されるかわかるから、便利ですねって言おうと思ったんですけど、ここにそういうことを許さないプログラムを書く人たちがいるなってふと思い出しました。
tompng: 消したら違うコードとして解釈されることってできます？エラーじゃなくてちゃんと別の動きで動く？
ima1zumi: できるかもしれませんね。バイト列が両方で解釈できるものであればきっとできると思います。
fujimura: 夢が広がってますね。ちょっとくだらない話かもしれませんが、半角カタカナのコメントって読むのは慣れるものなんですか？
ima1zumi: 慣れますね。間にスペースが入っているとだいたい読めるなって思います。詰まっているとちょっと読みづらいなっていうのはありますけど。
文字は常にバイト列だし、バイト列しか信用できない
fujimura: RubyKaigi 2025のキーノートでは、家族の絵文字が文字コードとの出会いで、家族の仕組みがバイト列であって、それが集まると一個の字になるっていう話をされていました。その仕組みって一番最初に出会った時から理解できたんですか？確かにバイトシーケンスって文字できるよねって最初から思っていたのか、それともその仕組みから理解したのか？
ima1zumi: たしかフィヨルドブートキャンプでその問題を踏んだんですけど、それに出会うより前に一回別の問題も見つけてて。フィヨルドブートキャンプの課題でwcコマンドをRubyで実装してみようっていうのがあったんですね。Rubyで実装してみて文字数カウントをしてみると、オリジナルと文字数の数えられ方が違うみたいな問題があって、文字数だったかな。正確には忘れてしまったんですけど、挙動が違うぞと。
なんで挙動が違うのかを調べていたら、wcコマンドはバイト単位で文字数を数えてて、Rubyは文字数単位で数えていたのでそこがずれちゃう。そこでマルチバイト文字っていうのがあるんだなと実感した気がします。
fujimura: その準備があった上で絵文字に出会うと、なるほどなるほどみたいな感じになってきた？
ima1zumi: そうだったのかもしれない。ちょっとだいぶ前の記憶なんであれなんですけど。
fujimura: 理論上理解すれば理解できるっていうのはわかるんですけど、そうはならんやろってところもみなさん思ってると思うんですよ。どうやって構造や仕組みを理解したり学んだりしていったんですか？
ima1zumi: それで言うとメインフレームでの経験が大きくて、文字は常にバイト列だし、バイト列しか信用できないって思ってたんですよね。
fujimura: パワーワード。
ima1zumi: 見た目と中のバイト列が全然違ったり、あとはメインフレームの中でも使ってる文字コードが何種類かあって、同じ文字を表現するために違うバイト列を環境によっては使わないといけなかった。
メインフレーム仕草がいくつかあるんですよ。ファイルのmaxサイズを確認するとか、それはJCLというJob Control Languageにファイルサイズのmaxを書いて実行するので、そこを超えちゃうと処理が止まっちゃうから困る。なので必ず最大値を気にする。これは今でも微妙に残っていて、可変長のデータベースを見るとこれは何文字まで入るんだろうなって気にしちゃう。
そういういくつか特有の気になるポイントがあるんですけど、そのうちの一つで文字のバイト列が何であるかを常に気にしたい、どうなってるのかを知っておきたいというのがありますね。
fujimura: Webプログラマとは違う準備が行われてたんだ。
ima1zumi: だいぶ抜けてきたけど、でも最大値とかバイト列は変わらないし、バイト列はもっと強くなったような気がする。
Unicode実装への取り組み
fujimura: RubyのUnicode 15.1.0の対応も、Unicodeの規格を調べて理解すればわかるし、できるって理論上はそうなんですが、なぜだ？とみんな思ってると思うんですね。どんな風にUnicode自体の仕組みや実装を触れるくらいまでアプローチしていったんですか？
ima1zumi: Unicodeの概要やユーザーとしての使い方を学ぶのは、Rubyと文字コードで遊んでるうちになんとなくわかってきたんですけど、その中の一つの仕様を実装するっていうのは少しハードルがありました。特に正規表現エンジンの中の中にあるものでノードを作ってマッチできるようにするのは初めてだったので、読み解くのは大変でしたね。
fujimura: その正規表現エンジンの中の部分を直すまでに、どのぐらいの期間をかけてたどり着くものなんですか？
ima1zumi: 場所自体はすぐわかったんですけど、その中で何をやってるかの理解をするのが大変でしたね。あとは仕様書に書いてあることを正しく理解する部分は大変でした。
UnicodeのUAX#15っていう仕様書があって、そこの中に書記素クラスタの分割ルールが全部書いてあります。文字と文字の間に割り算があるとか、掛け算があるとか、このマークが来たときは分割してはいけないんだみたいなことが書いてあるんですけど、理解した今は書いてある通り全部わかるって思うんですけど、理解する前は読んでも何もわからなくて。実装してる人が少ないから、インターネットに情報が少ないんですよね。なんなんだろうなこれはってずっと思ってました。
fujimura: 理解できれば理解できることはわかったんですけど、それはひたすら愚直に読んでいく時間もあるんですか？
ima1zumi: 実装と仕様を見比べながら、そもそもどういう意図で実装されてたんだろうとか。正規表現についてちょっと調べて、どういう形でマッチングしてるのかイメージを持つのもやったりしました。
参加者: Unicodeの書記素クラスタは正規表現を扱っている人たちの分野ですか、それとも文字もしくは文字を扱っている人たちの分野ですか？
ima1zumi: 正規表現とは限らないstringの実装としてもあり得ると思います。Rubyの場合はたまたま正規表現に実装されているっていうだけの話だと思います。
参加者: 書記素クラスタを扱っている人ってどれくらいいるんですか？
ima1zumi: 各言語の実装者の中に必ず書記素クラスタの仕様を理解して実装している人がいると思います。あと書記素クラスタはサポートしている言語も多いので結構いると思います。
参加者: 書記素クラスタって文字数をカウントするときにも使われるんですか？
ima1zumi: 文字数のカウントはまた違う話ですね。家族の絵文字は1と数えるんですけど、あれを1と数える言語は多分ないんじゃないかなと思います。
mame: 文字とは何かって難しいですよね。
ima1zumi: そうなんですよ。
mame: それを語り出すとめちゃめちゃ長いですね。
tompng: 家族の絵文字って、家族の絵文字クラスタとは言わないですよね？
ima1zumi: 家族の絵文字クラスタとは言わないですね。
mame: 素人質問なんですけど、家族の絵文字って何の需要がUnicodeに入ったものなんですか？誰が欲しがったんですか？
ima1zumi: それは考えてみたことがなかった。元々日本のガラケー由来の絵文字として家族の絵文字があったのであれば、そこから発展していったのだと思います。
mame: 日本の絵文字って多バイト長じゃないですよね？家族を増やしたりとかできないですよね？
ima1zumi: そうですね。
mame: そこからなぜそんな魔改造をしてしまったのかっていうのは...
ima1zumi: それでいうと自分の思ってるものを表現したいっていうニーズがあるんだと思います。例えば私の思う家族とは性別がこの順番で並んでいて、こういう人たちであると、肌の色はこういう人たちであるっていう自分の思う家族を絵文字として表現したいというニーズがある。
参加者: 家族の絵文字が成り立つ仕組みと日本語の半濁点がつく仕組みは同じですか？
ima1zumi: 違う仕組みです。家族の絵文字は書記素クラスタによって複数のコードポイントが1つにカウントされる。「は」と「ば」みたいな仕組みは、Unicodeの正規化の文脈で、この文字は分解できる、合成できるが全部の文字に対して決まっています。
fujimura: 字とか言語で他に興味のあるものってありますか？
ima1zumi: カリグラフィーは興味があって、やってみたいなって思ったことがありましたね。文字で言うと、物理的に文字を書くことが好きで、万年筆を使ったり、紙にこだわったりしてます。
fujimura: 字はもともと好き？
ima1zumi: どうなんでしょうね。書くことは好きでしたけど、文房具好きから発展して書くことが好きになった気がしますし、別々のルートから交わってきた気がします。
fujimura: ありがとうございます。準備の裏話も聞こうと思ってたんですけど、タイムアップでした。
質疑応答
参加者: tompngさんがコードレビューをするにあたって、15.1の仕組みをどれくらい理解しましたか？
tompng: ruby-jp Slackのima1zumiさんのtimesを見て気になってたんですけど、レビューする上で大変だったのが、ソースコード自体はよさそうなんですけど、ソースコードにコメントがあって、コメントに図が書いてあった表みたいなの。それを読み解くのが、パズルみたいで楽しかったんですけど、すごい時間かかったんですよね。
正規表現のノードをCで組み立てるんですけど、組み立てるときに一時的に使うメモリ領域をどう配置するのかみたいなのを、人が手作業でやりつつ、それをこうやりましたよってメモを書いてて、あれなんかやめたほうがいい気がするんですけど。どれくらいで理解したのかって質問の答えになってないけど、パズルみたいだなぁと思いながら。
ima1zumi:レビューにどのくらい時間かかりました？
tompng: やってることはわかった。正規表現のノードを作ってるので、そこからできた答えを見てしまえば、仕様を見て答え合わせをしてるっていう感じで、そんなに時間は..
ima1zumi: tompngさんの理解がすごく早くてびっくりしました。あと、コメントの部分は、私が間違っている箇所をペンさんに指摘されて、それで理解できたので。
tompng: 元のコメントもちょっと間違ってるところがあったので、それがよりコメントの理解を妨げてた気がするんですよね。
ima1zumi: もっといい方法があったら知りたいですね、C言語。
mame: めちゃくちゃしっかりレビューしてるんですね。すごいですね。マージボタン、ポンと押すぐらいしかしないです。直接話を聞いて、実装方針やアルゴリズムがよさそうだったら、いいんじゃないってapprove、なんならマージボタンみたいにやることが正直多いですけどね。めちゃくちゃコメントまで読んでて、すごいなと思いました。
tompng: コメントまで書いてるとガチガチでやってる感じがあるから、ガチガチでやらなきゃっていうのにちょっと思ったんですよ。じゃなきゃコメントで丁寧に表とかまでやらないかなと思ったんですけどね。
ima1zumi: 多分処理の途中で上書きしちゃわないように親切のために書いてあるのかなって思いますけど。上書きしたらRubyが起動しないんで、実はいらないんじゃないかなって気もちょっとしてます。
参加者: tompngさんはTRICKのようなコードを書いていると、反動でTRICKではないようなコードを書きたくなるのですか？
tompng: むしろいろんなコードをTRICKみたいな精度で書きたくなる。BigDecimalの方はメモリの確保量が適当で、何だろう。割り算の方で割る数、余りを格納するサイズが、答えを確保したメモリの2倍だと足りなかったから、2倍+1にしようみたいな感じのことをしているとか、そこはすごい適当で気になるんですよね。
そうではなく、それは別の条件があって、ある条件を満たしていればOKなんだけど、それをたまたま満たすように2倍とか3倍とかして通しちゃってるっていう感じのところがある。なんでそれがたまたま通ってるのかわからないようなコードが気になっちゃう。
mame: それは単に性格だと思いますよ。僕はむしろTRICKの方が雑に書きますね。適当に9倍とかしたりするし。なんで10倍じゃないかというと、10だと2文字になるから嫌なんだけど、9は1文字で書ける一番大きい数字なんで選びがちとかそんな感じ。
tompng: それはわかる。
fujimura: 聞こうと思ってたことがあったんですけど、職業プログラマでもあるtompngさんは、TRICKの技が仕事のプログラミングで役に立つ瞬間もあるんですか？
tompng: ない気がします。 IRBだったら、予めこのやり方だったらダメだろうなっていうケースを探しやすいから、仮にバグがあったとしてもこれくらいなら許容できるのかなっていうのを先に見つけられるとかは良いところかな。
fujimura: 完全別物なんですね。それはそうだよな。
BigDecimalについて
fujimura: Xで質問をいただいたので、BigDecimalの話です。
BigDecimal はパフォーマンスを犠牲にして正確性のある少数計算をするユースケースが想定されるけど、そもそもそういうシステムと Ruby に親和性があるのでしょうか
tompng: パフォーマンスを犠牲にしているのであれば別にRubyでいいのではと思うんですけど、BigDecimalが目指す方向性がどっちかっていうとわからない。最速のライブラリにしたいというような考えもあるし。
fujimura: そこそこ精度があるものにしておくべきだろうっていう。
tompng: 一つはBigDecimalをRuby実装にするっていうのがあり得ると思ってて、僕はありかなと思うんですけど、今のBigDecimalの歴史の流れというか、作っていった方針としてはそうではなく、C実装で速いのをやりたいだろうし、どうなるかな、わからないなという感じです。
mame: 多分この質問は、BigDecimalの多くのメインユーザーは銀行システムとかなんだけれども、そういう分野でRubyはそんなに使われてないんじゃないかなと思ってますし、それをおいておいても親和性ってどうなんですかねという質問なんだと思います。ima1zumiさんが答えられるかもしれない。
ima1zumi: 銀行系でRubyを使うっていうことはまあないんじゃないでしょうかね。
mame: それはなぜでしょう。
ima1zumi: 一つは開発体制の堅さもありますし、もともとやっぱりCOBOLから来てる会社が多いと思うんです。COBOLのシステムがあって、それをCOBOLはさすがにメンテしづらいから移行しようねってなった時に、まず候補に上がるのがJavaなので。ノウハウが溜まっているっていう意味でもJavaに移行しがちっていうのはあると思います。
mame: 未だにCOBOLを使っているっていうことは相当保守的なわけですね。なので、そういう意味で銀行システムでRubyとの親和性は、なかなか流れ的に入っていくのは難しいというのはあるかなとは思います。
でも一方でBigDecimalってみんなRails書いてて使ってるんですよね。DBから読みだしたらBigDecimalが返ってくるんですよね。そういう意味だとみんな使ってる。Ruby on Railsで業務システムを作ってる例は山ほどある。そういうところではBigDecimalの親和性は多少あったりするんですかね。
fujimura: ちょうど時間になったので、終わろうと思います。改めて、今日登壇してくださったtompngさんとima1zumiさんに拍手をお願いします。ありがとうございました。（完）
