こんにちは！ 中途採用課の倉田です。
今日は、新卒でサーバーワークスに入社して活躍中の橋本 拓弥（はしもと たくや）さんへのインタビューをお届けします！
橋本さんが最近取り組んでいる「OSSコントリビューション（*1）」の活動についてお話を伺いました。
どういった活動なのか、なぜOSSコントリビューションに取り組むようになったのか、取り組みの中での学び・やりがい等について語ってもらっています。
普段の業務上のミッションとは別にこういった活動ができる、サーバーワークスの社風も合わせて感じていただければ嬉しいです。
橋本さんってこんな人
ーまずは簡単な自己紹介と、今の業務について教えてもらえますか？
橋本： はい。私は新卒で入社し、今年で在籍10年になります。最初の2年間はOJTと営業職を経験した後、その後はずっとエンジニアとして業務に携わっています。開発業務をするようになったのは5年目くらいからです。
エンジニアとしての業務内容は、社内SEとしての開発や運用保守がメインです。業務フローやシステム構築、メンテナンス、インフラ、アプリケーションの管理などを行っています。
OSSコントリビューションのきっかけ
ー具体的にどんな活動をしているんですか？
橋本： オープンソースは、私達エンジニアが普段の業務で多大な恩恵を受けているものです。具体的には、業務で使用しているツールに対し、新機能のリクエストやバグ修正、ドキュメントの更新などをGitHubを通じて提案しています。
特に力を入れているのはAWS CDKの機能改善で、いわゆる IaC と呼ばれる技術領域のツールです。これまでに4件の提案がアクセプト（正式に採用され、取り込まれた）されました。例えば、S3 関係の便利機能をその仕様案とともに提案して、実装まで行い採用されました。そういった活動を今年から頑張ってやり始めています。
あとは、自分ひとりで頑張るのもいいんですが、こういうのは志向性が同じ仲間がいた方が楽しいし刺激受けられるので、仲間作りをしたいなと思っていました。なので、社内で興味がある人をSlackのチャンネルに集めて、情報とか実績とかを緩くシェアして繋がったりとか、そんな感じのことをやっていたりします。
オープンソース以外にもいくつか活動をやっています。例えば社外登壇もそうです。
オープンソースに関しては月1ぐらいで、4～5人で集まって何かアクティビティがあったとかそういう情報を共有したりしていますね。登壇については、こういう登壇の募集があるよとか、登壇した人がいたら実績を社内のページに書いていただいて「ナイスチャレンジ！」みたいに賞賛し合ったりします。
ーOSSコントリビューションをやろうと思ったきっかけについて、詳しく教えてほしいです。
橋本： まずは純粋な「憧れ」ですね。私は学生時代から情報工学を専攻していて、プログラム書いたりするってことは前からやっていたんです。仕事としてコードを書くようになったのは社会人の5～6年目くらいからだと思うんですけど、いつかはコードを書くことを仕事にしたい、みたいな考えは学生時代からありました。
世の中には、何百万人が使うような偉大なソフトウェアってのがあるわけですよね。世界中にいる技術力の高い人が開発して、その価値を届けてくれている。しかも無償で使えるようにしてくれている。
オープンソースへの貢献はそこに対して一石を投じる活動で、ある種の意欲や能力を証明する実績と言えると思います。承認欲求を満たせるというか、ドヤ感を出せるじゃないですけど（笑）、やっぱり憧れるんですよね。ものすごく安直で俗っぽい話ですみませんが、そういう思いも内心ありました。
私自身まだまだ実力不足だと思っているので、こうした活動を通じて自分の実力を引き上げたい、というのもありました。会社のメンバーだけが書いているコードよりは、世界中の優秀な技術者が書いた、たくさんの人に使われているコードの方がおそらくあらゆる面で高品質なんですよね。より高水準なところから学びたかった、という思いがありました。
AWS CDKへのアプローチ
ー数あるオープンソースの中から、AWS CDKを選んでいるのはなぜですか？
橋本： AWS CDKを選んだ理由は、それがInfrastructure as Code (IaC) の技術領域に属しており、会社でも頻繁に使用されている点です。使い心地の良さや、AWSとの親和性が高いこともありました。また、CDKの設計思想に強く惹かれたことも大きな要因です。
ただ、実態としては意識的に選び取ったと言うよりは、たまたま実務での必要性と私個人の興味が重なり、それがたまたま CDK だった...という感じが近いと思います。
自分が実務で使っているので距離が近いし、使っていたら「〇〇できたらいいのにな」みたいなのが出てくるじゃないですか。そういう自分なりの課題と興味関心の掛け算と今までの積み上げがあって、そういう機会が今年ちょうど出てきた感じです。
ー具体的に、どういうアプローチをしているんですか？
橋本： まずGitHubのIssueを活用し、既存の問題や解決策を調査することから始めました。トラブルや問題が起きた際に、Google検索だけでなく、一次情報であるGitHubのIssueやソースコードにあたるように意識しました。よくやりがちな「Google 検索で非公式のブログ記事を探すだけで調査を打ち切ってしまう」のような行動で済ませてしまうところをもう一歩進めて、一次情報に触れてみよう、ということです。
自分の業務上の課題とソースコードを関連付ける意識が重要だと感じています。一次情報であるソースコードに触れる習慣を身につけることでコントリビューションの機会を引き寄せやすくなる、と考えています。
挫折した経験もあるのですが、最近はコントリビューションワークショップという優れたコンテンツが日本語版で公開されたので、それをなぞってみたりもしました。
日本の CDK のコミュニティってすごい活発で、技術が好きな方がコミュニティの中心メンバーにも多いんです。そのメンバーの何名かが「CDK にコントリビュートするなら最初にこういうことやっておくといいよ」というチュートリアルのようなものを、日本語版として出してくださっています。それを活用しました。
このワークショップが、ビルドや環境構築といった、これまでハードルとなっていた部分を解決してくれました。あとは、CDKのマナー（プルリクエストのルールやコードの書き方）を学びつつ、実際にコードを書いて提案するという流れです。
得られた学び・気づき
ー活動を通じて、どのような学びや気づきがありましたか？
橋本： まず、情報収集の際に一次情報（ソースコード）に当たる習慣が身についたことです。野良の記事やブログだけでなく、自分でソースコードを見て振る舞いを予測できるようになりました。
他には他人のソースコードへの心理的な距離が縮まったことです。社内SEの業務でも他人のコードを引き継ぐことはありますが、オープンソース活動を通じて、より大規模で質の高いコードベースに触れることで、抵抗感がなくなりました。
また、世界中のエンジニアが作成した大規模なコードベースから、レビュープロセスやエコシステムに関する学びを得られたことも社内だけではなかなか得られない経験でした。
ーレビュープロセスのところ、もう少し詳しく教えていただけますか？
橋本： 野良の開発者が好き放題にリクエストを投げちゃうと、管理する側がパンクしちゃいます。だから、そうならないためにレビューのルールはこうだとか、この基準を満たしてからリクエストをかけてね、というのがあるんです。
そうした仕組みを実際に感じられたのが1個。それは多分、社内だけではなかなか得られない学びだったと思います。
あとはコードレビューの「温度感」ですね。 レビュアーって細かいことまで言ったら際限なくレビューできちゃうんですよね。日本語の文章のレビューに例えるなら、句点を打つ打たないとか、そういうレベルの話です。本質的な議論よりも小さな粒度の話で何往復もレビューするのって不毛な場合が多いんですけど、レビュアー慣れしていないとこうした細かい部分にこだわりすぎちゃうのが結構あるあるだったりするんです。 だから、致命的じゃない部分は程よく放っておくだったり、機械的にチェックできる観点は完全に自動化して議論の余地なく必須にするだったり、扱い方にメリハリをつけることが必要なんですね。
そのあたりが仕組みとして整えられているからか、最低限のルールが通っているなら細かいことはレビュアーは言わない、という風に割り切っているように見えました。
これだけ優れた人が集まる場所で「細かい点を気にしすぎず、大事なことにフォーカスしましょう」っていうスタイルでやっているんなら、自分もその考え方に寄せるべきだなと思って。私自身も細かいことを言いまくってレビューが全然進まなかった失敗談があるんですけど、それで全体の生産性が落ちるのは本末転倒ですしね。
ー今のお話以外で、何か得られたことはありますか？
橋本： 英語の表現力、特にニュアンスの違いを学ぶ機会がありました。AIツールを活用して文章を作成する際にも、単語のニュアンスの違いを都度確認することで、生きた学びが得られました。例えば、「値が存在しない」ことを表現する際に「absent」という単語を知り、他の表現とのニュアンスの違いを理解できたのは興味深い気づきでした。
また、社外での登壇活動やSNSを通じて、コミュニティ内での認知度が高まったというのもあります。自分のことを知ってくれている方も幸いちらほらいらっしゃって、自分が何者なのかをある程度説明できている状態で会話を始められると、技術的な話もやりやすいです。
社外でのつながり作り
ー社外で積極的に発信したり、活動しているのはどういう背景なんですか？
橋本： 就職活動の頃から、開発と運用、あるいは開発と営業といった職種間の対立や、内輪の閉鎖的なノリが好きじゃなかったところがあります。同じ味方のはずなのにいがみ合っているのは、本当にしょうもないなと思っていました。これって、自分が今持っている世界観や価値観の中に閉じこもって、その外側にいるかもしれない人や価値観への想像力が及んでいないからじゃないか、と思うんです。
相手の立場とか考えていることに思いを馳せたり、あるいは「俺の言葉を相手はこう受け取ったのかもしれない」とか、「俺の知らない事情があるのかも」みたいに想像力を膨らませることが大事だと思います。私にとっての外の世界に対する興味って、こうした対人コミュニケーションにおける想像力を広げたい気持ちに由来しているような気がします。
自分が「井の中の蛙」になるのが怖いというのもあります。自分は知らなかったけど、こういう考え方があったんだ、なるほどな、って。自分の世界観が広がる瞬間があるじゃないですか。なんかこう、パッと視界が開けるような感じの。あの感覚が好きってのもあるのかな。
要するに、外と繋がることで、自分の世界観を広げたいし、もっと色んなことを知りたい、って気持ちが強いんだと思います。
大切なのは「興味を持ち続ける」こと
ー橋本さんのやっているような活動に興味を持つ人へ、メッセージをお願いできますか？
橋本：ひとまず興味を持ち続けるってのは大事かなと思います。
私自身も結局、興味を持ち続けつつ、興味と機会が出会うような行動をやっていたら偶然タイミングが来たっていう感じだったんです。再現性はないんですよね。でも興味のアンテナをなくさず、アンテナに沿って行動をしていれば、いずれ機会はやってくると思うんですよ。
「長い目で見て好ましい方向付けになるような意識と行動を無理しすぎない程度にやる。そのうえで目の前の機会を機会として認識できるアンテナと、拾える好奇心を持とう」って感じだと思います。
その機会がやってきた時のハードルを下げるために、普段からお世話になっているオープンソースのコードに意識的に触れるのもいいと思います。GitHubのIssueやソースコードを調べたり、今の時代であれば、生成AIにコードを書かせるのではなくてコードを読ませることで、自分がやりたいことに関連するコードを調べやすくなります。既存の issue や、自分自身の困りごとから始めることを強くおすすめします。目的やテーマを持たずに何百万行とあるコードは読めないです。少なくとも私には無理でした。
継続するためのコツ
橋本：あと、自分1人のテンションではなかなか続けられないですね。自分1人で内発的な動機を持ち続けるのは難しいので、社外でも社内でも興味のある人と喋ってみることは大事にしたいです。モチベーションの要って多分人と会って話すことだと思うので、「俺コミュ障だから」とか言わないで、できる限りやっていったらいいんじゃないかなと。
例えばconnpass等で興味のある勉強会を探してみたり、 Discord とかSlackのグループに顔を出してみるとか。
あとは興味があるプロダクトに関するブログを書いてみるのもおすすめです。オープンソースに限らず、アウトプットとして記事を書こうとすると、その過程でこれ案外使い方知らないぞ、みたいなことが出てきます。それで自発的に調べる必要性が生まれます。つまり具体的なテーマを持ってソースコードを見に行けるチャンスなんですよね。
テーマを作りに行く努力というか、必要性を自分で作りに行くっていうことだと思います。ちなみにそういう活動が、サーバーワークスだと自由にできますよ、と急に宣伝っぽくなっちゃいましたけど（笑）。
例えば、社内の雑談チャンネルで興味を共有すれば、技術好きな人々が反応する可能性が高いです。10年間この会社に在籍していますが、肌感覚としてそう感じます。サーバーワークスでは自ら行動を起こす人が活躍しやすいと感じますし、声を出して発信する人の元には情報と機会が集まる会社です。
一緒に活動してみたい方がいれば、ぜひ気軽に声をかけてください！
編集後記
橋本さんが取り組んでいるOSSコントリビューション以外にも色々な話題に広がり、インタビューは1時間以上におよびました。
すべてをお届けすることができず残念ですが、橋本さんの技術への向上心とひたむきな姿勢がにじみ出る記事になったのではないかと思います！
橋本さん、とても興味深いお話をありがとうございました！
*1:オープンソースソフトウェア（OSS）の開発に、個人がボランティアで参加し貢献することです。バグ修正や機能追加、ドキュメント作成など、様々な形で貢献できます。
