justInCaseTechnologiesで働くエンジニアメンバーのキャリアに迫るインタビュー企画。
今回はバックエンドエンジニアとして活躍する宮田が登場。
jicTechに所属する傍ら、KotlinのプログラミングコントリビューターとしてOSS活動に取り組む彼に、その活動のきっかけや意義をインタビューしました。jicTechだからこそ目指せる自分らしいキャリアについて、胸に秘めた思いを語ります。

目次

1 .プロフィール
2 .宮田が取り組むOSS活動とは
3 .OSS活動へのコミットのきっかけ
4 .業務とのつながり
5 .コントリビュートを始めたいと考えている方へのメッセージと今後の目標

プロフィール

宮田木織　Backend Engineer
2018年から広告代理店にてDSP側管理画面の開発を経験したのち、2021年にjustInCaseTechnologiesへ入社。現在はバックエンド開発を主軸にSaaS型保険システムjoinsureの開発/運用を務める。

近藤晃弘　Software Engineer 
2004年からSIerにてWebアプリケーションを中心としたシステム開発を経験したのち、広告代理企業にて広告配信/運用データプラットフォームの開発/運用に従事。
2023年にjustInCaseTechnologiesに入社し、バックエンド開発を主軸にSaaS型保険システムjoinsureの開発/運用を務める。

宮田が取り組むOSS活動とは

近藤：まずは自己紹介をお願いできますでしょうか。

宮田：宮田と言います。簡単な経歴を申し上げると、2021年12月justInCaseTechnologies に入社しました。当時は社会人4年目くらいだったと思います。入社後は主にバックエンドエンジニアをやっています。現在は「joinsure※」の中でもコア機能を中心に作っているSquad Yankeeというチームに所属して、バックエンドエンジニアをやっています。

近藤：ありがとうございます。では早速、今回のテーマであるOSS活動について、具体的な取り組み内容をご紹介いただけますか。

宮田：そうですね、成果として大きな部分でいいますと、まず  Jackson のKotlinの部分（Jackson Module Kotlin)のメンテナーとして、リポジトリの全権限を握って、メンテナンス活動をさせていただいたりしています。その他にも、さまざまなOSSに、パフォーマンス改善等の細かい貢献をしていたり、Kotlinっていう言語のリポジトリの方で、主に、リフレクション関連の改善や、パフォーマンス改善に取り組んできました。

近藤：ありがとうございます。Jackson  Module Kotlin の管理者権限を持っているということは、リリースなど、例えば管理面や運用面までも任されているのでしょうか。

宮田：細かい話になりますが、 リリース作業は私ではなく、Jackson 本体のメンテナーが担当していて、 中のコードをどういう風にしていくかといったところを私に一任いただいてるという状況です。

近藤：ありがとうございます。では、改めてKotlinとJackson についての簡単な概要も ご紹介いただけますか。

宮田：まず、Kotlinいうのはalt Javaと呼ばれるような言語でして、Javaというとても有名な言語がありますが、それを動かすプラットフォームであるJVMの上で動かせる別の言語という感じでしょうか。基本的にはJavaをより改善した言語というイメージです。 Jackson は、JSON形式のデータを処理するためのJavaライブラリで、JavaやJVM言語のJSON処理のライブラリとしては、世界で最も使われているものの1つです。

近藤：Kotlinのコントリビューターとしては、リフレリクレクション周りのパフォーマンス改善をやってきたということですね。

宮田：そうですね。パフォーマンス改善のほかにも、Kotlinの機能としてvalue classというものがあるのですが、それをリフレクションで使う際に 、いくつか重大なバグがありまして、その修正にも貢献してきました。

近藤：value class は比較的新しい機能ですよね？

宮田：そうですね。少し前にStableになったといわれていたのですが、重要なバグが長い間残ってしまっていたので、それを私が解決したという感じです。

近藤：正直なところ、value class ってあまり業務では見たことがないのですけど、結構ユーザーがいるものなんですか？

宮田：分からないというのが正直なところです。私はとても有用な機能だと思っていますし、いろんな人が使ってみたい機能じゃないかなとは思うんですが、一方で リフレクション周りとか、あとちょっとJavaとの互換性の部分があまり担保されていない機能ですので、その辺りに利用のハードルはありそうだなと感じています。

近藤：逆に、こんな時にぜひ使ってほしいとかっていう事例はありますか。やはりパフォーマンスが求められる時、とかでしょうか。

宮田：そうですね。パフォーマンスが求められる、かつ、リフレクションをあまり使ってないようなところにvalue class の利用箇所を限定できるのであれば、十分役立つ機能だと思います。

※SaaS型保険システム「joinsure(ジョインシュア)」

保険ビジネスのDXを支援するSaaS型保険システム「joinsure」はSaaSとして利用できる基幹システムで、新会社立ち上げ時、新商品開発時、プラットフォーマーとの連携時のミドルシステムとしての導入などに幅広く活用いただいています。https://justincase.jp/joinsure

OSS活動へのコミットのきっかけ

近藤：ありがとうございます。ではちょっと視点を変えて、OSS活動へのコミットのきっかけについて教えてください。

宮田：そうですね、最初は、新卒で入った前職の職場でKotlinを導入したことがきっかけでした。Kotlinを導入するにあたって、どうしてもJavaのツールの置き換えが必要になってしまったんです。それをやらないとものすごく各コードの量が増えてしまうから、これをなんとかしないと置き換えは難しいんじゃないかという話になりまして。その時に、これだったら自分で作れるなって思って作ったのが始まりでした。その後、その時に作った社内向けのものに機能拡張や性能改善を施してOSSとして公開しました。それを1年ぐらい細々とメンテしていたというのが最初の最初ですね。 やってみると、その中で得た知見が意外とさまざまなリポジトリに展開できることに気づいて、 外部のリポジトリへのコミットを始めたという流れになります。

近藤：なるほど。で、その外部のリポジトリへのコミットが、Jackson だったり、Kotlinだったりしたということですね。

宮田：そうですね、いろんなところに関わってきたのですけど、特にJackson Module Kotlinには改善できるところが多いなと感じて、 いくつかやり取りをしていくうちに深く関わるようになり、最終的にメンテナーになっていたという感じです。Kotlinの方に関しても、Jackson でそもそもvalue class をサポートできないのかっていう話から、kotlin-reflectの方の問題を解決したりといった感じでつながっていきました。

近藤：KotlinにはJackson 経由でつながっていったということですね。

宮田：そうですね。

近藤：ありがとうございます。個人的にライブラリよりもプログラミング言語の方がコミッターになるに当たっての障壁が高いイメージを持っているんですけど、その辺はいかがだったのでしょうか。

宮田：私の場合、2年程度自分で開発していた時期があったので、わりと自信を持って入っていけたというのはあると思います。

近藤：なるほど。Jackson Module Kotlin へのコミットで主だったところ、どんなことを解決したかご紹介いただいてもいいですか。

宮田：そうですね、結構いろんなところを触ったり、機能追加したりということをしてきたんですが、1番大きなところとしては、おそらくJackson Module Kotlin でのvalue class サポートの追加っていうところです。先ほどもお話しした通り、value class は、Javaとの互換性があまり無い機能でして、それをさまざまな手法でJava製のツールであるJackson に適合させて、value class のサポートまでやりきったというのが1番大きな貢献だと考えています。

近藤：ありがとうございます。ではvalue class のサポートやKotlinのパフォーマンス改善をやっていく中で、 技術的なところで苦労した点はあったのでしょうか。

宮田：大きく2つあります。1つは、結構深いところまで見るっていうことをしないと、value class の場合は解決できない問題が多かったので、 いろんな機能を探ったり、とにかくいろんなものを読んだり、実験して挙動を探ったりっていうところが結構大変でした。性能改善の取り組みも結構やっていたんですけど、そういう話でいうと、やっぱり結果の検証がとても大変でしたね。「〇〇を改善しました」だけではやっぱりダメで、ベンチマークを使って「性能がこんなに改善されました」って示したりする必要があったのですが、そもそもベンチマークは何を作ったらいいかというところから始まって、それを仕上げて、時間のかかるベンチマークを回してという工程は結構大変な作業でした。

近藤：value class の挙動を調べたということですが、日本語では文献が少ない印象があるんですけども、深いところは公式のコードを読んで把握された感じですか。

宮田：その点については、最も深く潜っていたところはそもそもドキュメントが無かったので、byte code を読んだりとか、そういう状況でした。

近藤：byte code を読んだのですか。

宮田：細かいところだとそうですね。ただ、文献すら無かったっていうのは逆に良かったところかもしれません。英語ができなくてもあんまり変わらない部分ですから。

近藤：なるほど。byte code を読んで、JVM上だとこう表現されているからこう対応したら良いだろう、みたいなことを考えて対応していったということですね。byte codeを読めない人から見ると、笑っちゃうくらいすごい話ですね。

宮田：もう1つは、もうとにかくいろんなところにブレイクポイントを仕込んで、 実際にどう動くかっていうのを追いかけるっていうところが結構大変でしたね。

近藤：ありがとうございます。JVMのディープなところに踏み込んだということで、技術的に苦労したことが伺われます。ちなみに、ベンチマークに関して工夫した点はあるんでしょうか。

宮田：ものにもよるんですけど、そもそも性能改善はちょいちょいやってはいたので、JMH (Java Microbenchmark Harness)っていうJavaで ベンチマークを取るためのツールがあるんですけど、それを使ってベンチマークのテンプレートみたいなものを作ったりしました。それを何回か動かしながら、ベンチマークの結果が損なわれない範囲で実行時間を短くするにはどうすればいいか、といった方法を探したりもしました。

近藤：ありがとうございます。ではちょっとまた視点を変えて、 今度は技術的な話ではなく、コミュニケーション的な要素について聞いていきたいと思います。管理者権限を持っていると、特に運用回りでコミュニケーションが発生することが推測できるんですけど、そういった要素で苦労した点はありますか。

宮田：そうですね。これは今も苦労し続けている点なんですが、やっぱり英語ができないので機械翻訳頼みになるんですけど、 それでもやはり機械翻訳したもののニュアンスを直したりとかして、そうやってようやく文章ができるっていう感じになってしまうので、どうしても時間がかかってしまうっていうのは常に苦労している点です。英文としての正しさみたいな点は機械翻訳がかなり助けてくれるので、そこはあまり苦労せずに済んでいるとは思うんですけど、 それでもやっぱり時間がかかります。

近藤：言語障壁がどうしてもあるということですね。ちなみに、思想的な障壁はありませんでしたか。元々の管理者とか、Jackson 本体の管理者がこういう考え方でちょっと衝突しちゃったとかいうことは？

宮田：そういうところはあまり無いというのが実感です。自分が合理的だと思うことを説明して、向こうからも説明が返ってきて、で、お互いに落としどころを探るっていう流れは変わるところではないといいますか。当然、意見がすれ違ってしまうことや、「こういう修正はできないんですか」という質問に対して「いや、ここにこういう理由があってダメです」っていうことは当然あるんですけど、それも通常のやり取りの範囲かなと思います。

業務とのつながり

近藤：なるほど、そういったやり取りができていれば、コミュニケーションに問題は無かったということなんですね。 それでは、どんな風にコントリビューションしてきたかというお話が一通り聞けたところで、ちょっとここから業務との繋がりを深めていけたらなと思うんですけれども、OSS活動によって、業務に生きていることとか、何か繋がりを感じることはありますか？

宮田：OSS活動に限らずですけれど、会社の外で、自分1人で何から何までっていうところで開発をやっていますと、エンジニアとしての基礎体力っていうところが違ってくるかなっていう風に思うことはあります。例えば、業務では、すでに構築された基盤をあまり変えずにそのままずっと開発していくことが多いと思います。それがOSSだと色々なプロジェクトに手を出したり、自分で使いたい基盤をもうちょっと新しいバージョンにしてみようとかっていうことを積極的にやっていけると思うんですよ。それをやっていくと、やっぱりいろんなトラブルを経験するし、いろんな調査をするし、 そうやって問題を1つ1つ解決しながらやっていくっていうのは、エンジニアとしての基礎体力につながると感じています。業務だけでは得られないような知識が得られるし、仮に業務で同じような状況が発生した時にもぱっと対処できるっていうのはOSS活動が業務に生きているといえる大きなポイントかなと。

近藤：確かにその点は大いに共感します。私もOSS活動をしていて、これで基礎体力が養われてるなって思う部分があったりしますし、たまに競技プログラミング的なものにもチャレンジしたりすると、普段書いている業務プログラムとは全く別の脳みそを使うというか、 結構そこで基礎体力につながる部分はありますよね。

宮田：そうですね。業務は純粋にプログラミングだけで勝負するものではないので、頭の使うところがちょっと違うんですよね。OSSで鍛えた力っていうのは業務において使えることもあるし、不意のトラブルも、初手だと解決までに非常に時間がかかるじゃないですか。不意のトラブルで工数を食われてしまうっていうことを省いて業務ができれば、チームとしての安定感に繋がっていくところもあると思います。

近藤：基礎体力に関して、設計とか実装とかに繋がってくるのかなと思うんですが、コミュニケーション面で生きることもありますか。

宮田：そうですね、強いて言うなら、 事実を明らかにしようっていう姿勢はOSSで結構求められるものだなと思います。

近藤：事実や数字といった根拠を伝えないと相手に伝わらない、みたいなことでしょうか。

宮田：そうですね。

近藤：ありがとうございます。では、今度は逆に業務がOSS活動側へ活きること、何かアイデアが出たりとか、そういった効果を感じることはありますか。

宮田：OSS活動のきっかけっていうのは、まさに業務で必要だったから作ったっていうところからでしたけれど、 最近はあまりないですね。もちろん、細かなOSSへのコミットのヒントっていうのを、業務の中での困りごとから見つけるっていうことは当然あるんですけれど、最近は腰を据えて特定のテーマに取り組んでいることが多いので、業務からOSS活動側に移植っていうのはあまりないですね。

近藤：なるほど。そこについては、私自身も悩むことがあるんですよね。私は業務の中で「 これは汎用的に使えるからOSS化するとうけるんじゃないか」みたいに考えることがあるんですけど、汎用的にしようと思うと、会社や業務側で使っているケースが特殊過ぎてうまく汎用化できずに諦めることが結構あって。 そういったことはあまりないですか。

宮田：強いて言うなら、技術ブログにまとめたりすることはあります。個人でやっているものとか、会社でやっているものとか。 そういうところで書き出しておくのは重要かなって思っています。一方で、近藤さんのお話のとおり、 業務に特化したものを作っちゃうと、表に出すには汎用性が無いっていうのは結構あるあるだなとも思います。

近藤：そうなんですよね。さて、次の話に行きましょうか。次は何をモチベーションに活動を続けているのかという点について、OSS活動には具体的な報酬は無いと思いますが、 続けている理由はどのあたりにあるのでしょうか。

宮田：そうですね。それで言うと、やっぱり1番は楽しいから、なんですよね。私は結構ニッチな分野を攻めてOSS活動を続けてきたのですが、そうすると、自分以外の人が長年解けなかった問題が解けることがあるんです。そういうときに、やりがいや達成感を感じるし、 そういう問題を解いて、人の困りごとが解決するっていうのは結構楽しいんです。それが1番大きなモチベーションですね。もう一つ挙げるなら、プログラムの練度を維持するためにもOSS活動を続けた方が、プログラムが読めないとか、目が滑るっていうことにならなくて済むのかなと思ったりもします。

近藤：ありがとうございます。「楽しいから」を味わうと、何時間かけてでもやって良かったっていう気持ちになりますか。

宮田：そうですね。まぁ、やってる時はとにかく楽しいんですよね。

コントリビュートを始めたいと考えている方へのメッセージと今後の目標

近藤：さて、これはちょっと最初の質問に戻る感じもあるんですけど、Kotlinコントリビュートに正直私も興味があるんです。私に限らず、プログラミング言語へのコントリビュートってエンジニアなら興味ある方も多いと思うんですが、もし初めてコントリビュートしたいと思った時って、何から手をつけたらいいと思いますか。

宮田：やり方はいくつかあると思うんですけど、個人的な感覚で言うと、そもそも何にコントリビュートしたいかを考えて始めるのはやめた方がいいのかなっていう風に思っています。 身近な問題をまず解決するっていうところが、フックとしては強いんじゃないかなと。自分自身、いろんなリポジトリをさらっとでも読もうとしたことはあるんですけど、やっぱり 何もフックがない状態だと読めないんですよね。解決できる問題が見つけられない。解決できる問題を探すために時間を使うのって結構大変なので、まず問題ありきで始めた方が、「これを解決するんだ」っていう目的で何もかもできるから、そっちの方が近道だと思います。

近藤：その答え、非常にしっくりきます。

宮田：もちろん、中には解決できるイシューをトラッカーから探し出して解決をするみたいなことをしている方もいますが、私はそうではなく、あくまで「解決できそうだな」という問題をベースに始めていったっていうところがあるので、私と同じ道をたどるんだったら、まずは問題意識からスタートするのが良いと思います。

近藤：確かにそうですね。使い込んでいないとそもそも問題意識が無いですものね。

宮田：だからこそ、個人的には会社のためのツールを書くところから始めるのが1番良いんじゃないかと思ったりもします。業務の中で、「このツールがこうなってくれていたら嬉しいのに」って思うことが多々ありますから、そういうのを自分で作っちゃうっていうところから始めると良いかもしれないですね。

近藤：そういう意味では、プログラミング言語って完成していることが多いと思うのですが、そういったところへのコントリビュートは言語のコアな部分に興味がないと難しいとお考えですか？

宮田：ものによると思います。私の場合だと、リフレクションのライブラリっていうのは、 コアの言語機能からはちょっと切り離されたところにあるものだったし、 それをよく使っていたからここがダメだっていう話とかも知ることができた。その上で直すのもある程度普通のプログラミングの範疇で解決できる問題が多かったっていうのもあります。 本当に言語のコアのコアとかに行っちゃうともう本当に読めないので。

近藤：byte code の世界ですよね。では、最後の質問になります。 会社や業務的な観点も交えてなんですけれども、 今後、OSS活動やご自分のキャリアに関して目指しているところはありますか。

宮田：私の場合、解決したい課題が先にあって、それを解決するために動いているっていうことが多いので、 とにかく解決できる問題を解決していきたいということですね。もう1つは、やはりKotlinはとても良い言語だと思うので、それを使う上での障壁や不便さを無くしていくことに貢献していくことができたら嬉しいです。

近藤：私もKotlin大好きなのでそこは同じ気持ちです。本日はありがとうございました。