OSSの世界で活躍するエンジニアも、最初から突出した技術を持っていたわけではありません。RubyKaigi 2026への登壇やRuby本体へのコントリビューションなど、精力的に活動する神山 大智（@_dak2_）さんも、かつては伸び悩み、「自分はエンジニアに向いていない」とすら感じていたといいます。
何をきっかけに、エンジニアとして飛躍できたのでしょうか。これまでの歩みを伺いました。「仕事で伸び悩んでいる」「OSS開発をしてみたいが、一歩を踏み出せない」という方にこそ、読んでいただきたいストーリーです。
仕事で成果を出せない。原因は「要件だけを見ていた」ことだった
― 神山さんは精力的にOSSの開発を続けられている印象を受けます。キャリアの初期から、ずっと順風満帆だったのでしょうか？
いえ、かつてはまったくそんなことはなく、むしろ挫折感を覚えていたくらいです。新卒の頃なんて、仕事でうまく成果を出せず、毎日がしんどくて。日曜日の夜などは「明日から仕事が始まってしまう」という恐怖から、眠れずに夜更かしをしていました。
― かなり苦しい時期ですね。失礼を承知でお聞きするのですが、当時はなぜ成果を出せていなかったのだと思いますか？
一番の課題は、要件を正しく実現することだけを意識していて、要件の裏にある要求を汲み取れていなかったことだと思います。「この人はなぜこのリクエストをしているのか」「その裏にある真の課題は何か」といった背景を、理解できていませんでした。
だから、言われた通りの機能をそのまま実装してしまう。すると上司や同僚から「軌道修正しよう」と止められて、何度も手戻りが発生する。そんなことを繰り返していました。
それに、そもそも当時はチーム全体や事業全体を俯瞰できておらず、「個人の成果」に固執していたように思います。その考え方が、かえって成長を阻害していました。あの頃は「自分はエンジニアに向いていないんじゃないか」と本気で思い悩んでいました。
― そこから何を機に、状況が好転したのですか？
入社2年目の頃が転機でした。従来の仕事のスタイルを続けてもうまくいかないと気づき、成果を出している人のやり方を徹底的に真似してみようと考えたんです。
当時所属していたチームに、とてもスキルの高い先輩がいました。そこで私は、まずその方の仕事ぶりをお手本にすることから始めました。具体的には、「すべての物事に理由を求める姿勢」を取り入れたんです。そうすると、「要件を実現するには無理があるから、要求の精査ができないか」といった視点を、自然と持てるようになったんですよね。
― 「優秀なエンジニアを真似する」と言っても、何から手をつけていいかわからない人も多いと思います。神山さんは何を基準に、どうやって取り入れたのでしょうか？
「失敗したときや、もっとうまくやれたはずだと思ったときに、うまくやれている人との差分を見る」という方法を徹底しました。優秀な人は、自分と同じ場面でどう動くのかを観察してみる。そして、自分との間にある行動や思考の差分を見つけて、そこを少しずつ埋めていくことを意識していました。
加えて、この会社では後にプレイングマネージャーを担う機会をいただきました。この立場になってから、「チームとして事業に貢献する」という視点が身についていったんです。先ほど述べたような「個人の成果」に固執するスタンスも、徐々になくなっていきました。
「最初から完璧を目指さない」OSS開発の一歩を踏み出すために
― 神山さんは2024年からOSS活動を開始したと伺っています。きっかけは何だったのでしょうか？
一番大きかったのは、現在の所属企業であるタイミーへの転職ですね。もともと「いつかOSS活動をやってみたい」という気持ちはずっとあったものの、なかなか行動に移せずにいました。でも、転職して新しい環境に入ったことを機に、「自分がやったことのない領域にチャレンジしよう」と思えたんです。
― 最初は何から手をつけたのですか？
最初に取り組んだのは、TypeScriptのESLintにあった「Good First Issue」で、型定義の修正タスクでした。もともとTypeScriptの柔軟な型システムが好きで、強い興味を持っていたというのもありますし、リンターは自分にとって身近なツールだったからです。
その後は、Ruby関連のOSSへのコントリビューションを行うようになりました。タイミーではバックエンドエンジニアとしてRubyをメインで触るようになったので、「Rubyのエコシステムにも貢献したい」という思いが自然と湧いてきたんです。
RBSに型定義を追加するところから始めて、徐々にRuboCopにもPull Requestを出すようになりました。例えば、型チェッカーであるSteepのインラインコメント形式をRuboCop側で許可するような変更ですね。
― RuboCopのように歴史が長く、世界中のエンジニアが使っている巨大なプロダクトに手を入れるのは、怖さやプレッシャーはありませんでしたか？
めちゃくちゃありました（笑）。
ただ、そこは考え方を割り切るようにしたんです。「ちゃんとテストを書いてCIが通っているなら、実装者の役割としてはOKだろう」「そこから先、マージするかどうかはメンテナの方の判断に委ねよう」と考えました。
最初からすべてを完璧にやろうとすると、ハードルが上がりすぎて身動きが取れなくなってしまいます。だから、「自分が欲しい機能をつくってみたのですが、どうですか？」くらいの素直な気持ちで出すようにしました。
RuboCopのメンテナの方々は本当に優しくて、Pull Requestを出すとすぐに反応をくれたんです。コミッターの伊藤浩一（@koic）さんから直接レビューしていただいたり、設計の相談に乗ってもらったりして。「巨大なOSSでも、メンテナンスする方々と密にコミュニケーションを取りながら開発に関われるんだ」と、新たな面白さを知りました。
― 既存リポジトリへの貢献だけでなく、ご自身でもMethod-RayというOSSを開発されていますよね。こちらはどのようなきっかけで生まれたものなのでしょうか？
当時、Rubyの型検査にSteepを使っていたのですが、業務アプリケーションの開発で型注釈を書くのはそれなりに面倒でした。加えて、CLIコマンドの実行に結構時間がかかっていたんです。待ち時間が開発のボトルネックになっていて「なんとかして高速化できないか」と思ったのが最初の動機でした。
設計思想としては、Unix哲学のように「ひとつのことをうまくやる」という割り切りをしています。すべての型推論を行うのはあえてやめて、「レシーバーがそのメソッドを持っているかどうか」の判定だけに機能を絞り込みました。その上で、メソッド探索のようなCPU負荷の高い処理をRustで実装することで、処理の高速化を実現しています。
― 読者の中には「自分でもオリジナルのOSSをつくってみたい」と考えている方もいると思います。アイデアを形にするためのヒントがあれば教えてください。
私がアドバイスするのもおこがましいのですが、まずは日々の業務や開発の中で、「自分が面倒くさいと感じているポイント」に意識を向けてみるのが一番の近道だと思います。自分が欲しいものを出発点にすると、モチベーションも続きやすいですし、同じ悩みを抱えている他の誰かの役にも立つはずです。
RubyKaigi登壇を経て、広大なCRubyの世界へ挑む
― RubyKaigi 2026にも登壇され、神山さんにとって2026年は大きな飛躍の年になったと思います。特に印象深かった出来事を挙げるとしたら何でしょうか？
Method-Rayのgemをある程度形にできたこと、RubyKaigiに参加・登壇できたこと、そしてRubyKaigi後にZJIT（CRubyのJITコンパイラ）へコントリビューションできたことですかね。
順にお話しすると、RubyKaigi 2026のプロポーザルはMethod-Rayをテーマに出していたんです。すると採択の通知が届いて「マジか！」と驚きましたね。同時に、「通ったからには、本番までにMethod-Rayをちゃんと動く形にしておかないと」と、一気にやる気に火がつきました。
― 一般の参加者として聴講するのと、スピーカーとして登壇するのとでは、見える景色は違いましたか？
全然違いましたね。まず、シンプルにめちゃくちゃ緊張しました（笑）。自分の発表が終わるまではずっと気が抜けないので、他のセッションがちゃんと頭に入っていたか怪しいくらいです。
ただ、何より大きかったのは、発表後にセッションを聞いてくださった方々が直接話しかけてくれたことです。一人の参加者としてその場にいるだけでは、絶対にできなかったコミュニケーションが生まれたのは、登壇者ならではの貴重な経験でした。
― RubyKaigiの期間中は、セッションはもちろん、夜の飲み会などでも名だたるコントリビューターの方々と交流する機会がありますよね。そうした場での会話からは、どんな学びがありましたか？
「自分が何を知らないのかがわかる」というのが、一番の学びでした。以前、Rubyコミュニティで有名なジョーカー（@joker1007）さんも「RubyKaigiの発表内容なんて、最初はわからなくて当たり前。わからないことが何なのかを知ろうとする姿勢が大事だ」とおっしゃっていました。
それはセッションだけでなく、居酒屋での雑談も同じです。お酒を飲みながら話している中で、マニアックな技術の話が当たり前のように出てきます。圧倒されると同時に、自分の無知を知り、新しい世界の入り口を見つけられる。それがカンファレンスの醍醐味だなと感じました。
RubyKaigi 2026後の神山さんの投稿
― そうした強烈なインプットを経て、ZJITへのコントリビューションへとつながっていくわけですね。
そうですね。RubyKaigi 2026で、Aaron Patterson（@tenderlove）さんのZJITに関する発表を聞いたのが直接のきっかけでした。
ZJITをさらに高速化するための戦略として、CPUのレジスタレベルにまで関与して最適化しているという話があって。「そんなことまでできるんだ」と、ものすごい衝撃を受けたんです。そこから「一体、内部はどういう実装になっているんだろう」と興味が湧いてきて、コードを読み解き始めました。
― CRubyのコードベースは長年の積み重ねがあり、初学者からすると果てしなく広大に見えます。巨大なコードを読む際、どこからアプローチするのがおすすめですか？
私自身もすべてを理解できているわけではないのですが、まずは「全体の構造・大まかな流れ」を把握しておくのがいいと思います。
例えば、よう（@youchan）さんが執筆された『CRuby Quest 〜 Rubyのぼうけんのしょ 〜』という技術同人誌があるのですが、この本を読んでみるのもおすすめです。Rubyのコードが読み込まれてから、レキサー（字句解析）、パーサー（構文解析）を経て、仮想マシンで実行されるまでの処理の流れがわかりやすく解説されているんです。
初めからC言語のコードを1行ずつ追おうとすると遭難してしまいます。まずは「プログラムがどういう経路をたどって動いているのか」という大枠のアーキテクチャを頭に入れて、構造からアプローチしていくと、迷子にならずに読み進められるのではないかと思います。
OSS活動は「面白そう」「知りたい」の気持ちを大切に
― 今後のさらなる活躍が楽しみです。最後に、これからOSS開発に挑戦する方に向けてのアドバイスはありますか？
まずお伝えしたいのは「OSSは決して遠い世界のことではない」ということです。私も最初は恐る恐るPull Requestを出しましたが、それがレビューを経て取り込まれると、「自分でもできる」と自信が湧いてきました。そうした小さな成功体験を、まずは一つひとつ積み重ねていってほしいですね。
ただ、注意点があるとすれば、AIを使って雑にコードを書いてPull Requestを出すだけでは、当然ながら歓迎されませんし、マージもされません。「なぜこの書き方を選んだのか」「なぜこの設計にしたのか」を自分の言葉で説明できるかどうかが大事です。コード1行1行の理由を突き詰める姿勢さえ持っていれば、コミュニティのみなさんは温かく応えてくれます。
そして、結局のところ「自分自身が楽しめているかどうか」に尽きると思います。私がこうしてOSS活動を続けられているのも、純粋に「中身の仕組みを知るのが楽しいから」なんですよね。何よりも大切なのは、自分の好奇心に素直でいることです。「面白そう」「知りたい」という気持ちを大切に、一歩を踏み出してみてほしいなと思います。
OSS活動自体は、特段すごいことだとは思っていません。普段の業務でやっているエンジニアリングとそんなに大差ないと考えているからです。課題を見つけ、Issueを立てたりPull Requestを送ったりして解消していく。そう考えると、自分にもできそうな気がしてきませんか？
最近はAIがコードを書いてくれる時代になりましたが、「こうしたい」「ああしたい」という理想を描き、OSSへ提案していくこと自体は、まだ人間にしかできないことなんじゃないかなあ。この活動は、一種の「人類への貢献」だと勝手に思っています。
撮影：山辺恵美子
