ReactNativeはじめにキッチハイクエンジニアのタクです。先日react-native-appsflyerというリポジトリに不具合修正をコミットし、初めてマージされました。キッチハイクの開発チームでは、普段利用しているOSSに対して、不具合を見つけたら可能な限りフィードバックやプルリクエストを送るように心がけています。Satelliteに登壇したデザイナーもいます。今回は、開発チームのうち3名に焦点を当てて、エピソードを紹介しようと思います。自分本位の修正でも、誰かの役に立てるまずは私自身の経験から紹介します。私はキッチハイクでアプリ開発を担当しています。他メンバーが業務の合間にOSSへフィードバックやプルリクエストを送っている中、私だけコミット経験がありませんでした。当時は開発元にフィードバックしたいという気持ちはあるものの、なかなか行動に移せずにいたのです。ところが最近になって、あることがきっかけでコミットすることができました。今回はその背景と得た学びについて書こうと思います。誰かの役に立ちたいという思いが足枷となっていた私は以前にlottie-react-nativeというアニメーションライブラリを導入したことがあります。当時ある不具合を見つけて困っていました。時間をかけて調査していくうちに、なんとなく原因と解決方法がわかりました。Issueとして不具合を報告することはできませんでした。それはある思いが邪魔をしていたからです。「もしかしたら自分が報告しようとしている情報は、他の人にとっては役に立たないかもしれない。価値のない報告をすると、かえって対応・確認するコストを増やしてしまうのではないかと不安になりました。誰かの役に立たなければいけないという思いが強すぎるあまり、一歩踏み出す勇気が出なかったのだと思います。解決方法がわかっていながら、不具合報告ができなかったことをずっと悔やんでいました。そんな思いを抱えて開発している中で、次はreact-native-appsflyerというライブラリの不具合をたまたま見つけました。アプリダウンロードに至った広告の情報を取得できなくなっていたのです。前回と違い、マーケティング業務に使用しているデータにも影響が及ぶため、一刻も早く解決しなければなりません。自信はなかったのですが、早く直したい一心でプルリクエストを出しました。このとき、自分の修正が誰かの役に立つかどうかなんて気にしている余裕はありませんでした。自分本位になってもいい。それでも人の役に立てるから。私は、誰かの役に立ちたいという過度な思いが原因で行動できなかったことに気がつきました。このときは他の人のことを考える余裕などなかったからこそ、コミットできたのだと思います。いえ、プルリクエストを出した後は不安でした。独りよがりの修正なのではないかと疑うこともありました。同じ問題を抱える人から、賛同するコメントをもらえたのです。「誰かのために役に立ってる!」と嬉しくなりました。結局、私は誰かの役に立たなければならないと難しく考えていただけのようでした。自分本位のコミットであっても、きっと誰かの役に立つ。他の人のこと気にしすぎて萎縮してしまう必要はないと思いました。不具合を見つけたら自分ごととして捉え、積極的にコミットしようと思います。***つづいては、OSSを公開するために準備を進めているメンバーを紹介します。自分を奮い立たせるための自分ルール「1日1コミット」アプリエンジニアの久保です。Nativeを使ったアプリ開発を担当してから約2年が経とうとしています。今回は「1日1コミット」という自分ルールを設けて、リポジトリにコミットした活動について紹介します。自分を奮い立たせる理由が欲しかったこれまで何度かリポジトリにコミットはしていて、そのたびに自分も同じようにOSSを作りたい思っていました。行動にはうつせません。すれば行動できるか考えていたとき、「1日1コミット」という自分ルールをふと思いつきます。ネット上で検索しても、そういった活動をしている人はあまり見つかりません。前例がないことに対して意欲が湧く私にとって、ぴったりのルールでした。このルールが私を突き動かす原動力となったのです。学びの最大化計画せっかくライブラリを作るのであれば、フィードバックやプルリクエストがもらえるようなリポジトリにしたい。それを実現するひとつの方法として、「参加しやすいコミュニティ」にすることも大切ではないかと思いました。そこで「参加しやすいコミュニティ」、つまり、現にユーザが多いリポジトリを参考にすることにしました。モチベーションを維持するためにも、フィードバックが早いリポジトリを参考にしようと思いました。Nativeはコミュニティが盛り上がっていて、フィードバックも早そうでした。Nativeはキッチハイクのアプリ開発でも使用しているので、余暇の時間を使って得た情報を業務にも活用することもできます。Nativeのリポジトリにコミットしようと決めました。Nativeのリポジトリでは、コミット時にコードフォーマッターが実行されたり、機械的なレビューをボットが行なっていたりと、自動化によって人間の作業コストが削減されていました。業務改善にも活かせる有用な情報を知ることができました。求めていた情報以外にも得るものがありました。マージされたコミットはエンジニアとしての実績になりましたし、ソースコードをたくさん読んだことでコードの引き出しも増えました。Nativeに愛着が湧いたことで、不具合やアップデートの情報を追うようになりました。多くの人に使ってもらえるようなOSSを作るために始めた活動でしたが、エンジニアとして成長できた気がします。OSSと向き合う良さを改めて実感できる活動になりました。***次はOSSとして自分で作ったアイコンフォントを公開しているメンバーについて紹介します。feathericonを公開できたのは、オープンソースのエコシステムがあったからデザイナのはのめぐみです。キッチハイクではプロダクトデザインを担当しています。キッチハイクのプロダクトではfeathericonというアイコンが使われていて、OSSとしてGitHub上に公開されています。実はこのアイコン、私が作ったOSSなのです。今から3年前の2016年にリリースしました。Awesomeというアイコンセットをご存知でしょうか?アイコンを単一で使えるだけでなく、アイコンフォントとしても使える便利なものです。GitHubリポジトリのスター数や利用者数を見ると、世界中で多くの人に使われています。日本でも、Webサイト制作に関わる人であれば一度は目にしたことがあるのではないでしょうか。Awesomeですが、私はある課題感を持っていました。キッチハイクに入社する前にフリーランスとして活動していた当時は、案件や個人プロジェクトでよく使っていたものの、どうしてもアイコンのデザインに既視感が出てしまうと思っていました。Awesomeを使っているな」とわかってしまいます。Awesomeのようなリポジトリの仕組みが分かれば、自分が好きなアイコンフォントをつくれるかもしれない」という技術的な好奇心も持っていました。このふたつがfeathericonをつくるモチベーションとなりました。OSSはOSSの上に成り立っている私はエンジニアではないので、アイコンフォントを作るのに何をどうすれば良いか検討もつきませんでした。技術的なハンデがあるからこそ実現する方法を求めて、GitHubで類似するリポジトリがないかをとことん調べました。調査した中でも特に参考にしたリポジトリは、OcticonsというGitHub製のアイコンフォントセットです。Octiconsがどういう仕組みで成り立っているのかソースコードを見て研究を重ねました。調査を進めるうちに、FontCustomというリポジトリにもたどり着きました。コマンドライン上でFontCustomのコマンドを実行することでSVGデータなどをフォントに変換できます。ゼロからコードを書かなくてもフォント化できることがわかったのです。feathericonは既存リポジトリの研究や、複数のOSSの技術を組み合わせたことで誕生しました。自分に実現できるだけの技術がなくても、他の誰かが作った技術を享受できるオープンソースのエコシステムがあったからこそ、OSSとして公開することができました。感じたOSSの良さfeathericonは他OSSの技術を使うなどして誕生しました。知り合いが案件やプロジェクトで使ったり、SNSなどでシェアしてくれて、純粋に嬉しかったです。自分で課題意識を持って取り組んだことが結果的に他の誰かの役に立つというオープンソースのエコシステムのすばらしさを改めて感じました。恩恵を受けつつ、自分も誰かに影響を与えられる(かもしれない)世界がOSS。お互いに影響しあいつつ、いいものをつくることで世界がちょっと良くなることを実感しました。まとめ今回はキッチハイク開発チームのOSSに対する向き合い方について紹介しました。「自分の課題を解決するための行動が、他の誰かのためになる」という仕組みがOSSの魅力のひとつだと感じました。この仕組みに気づけたからこそ、今後はもっと積極的にOSSと向き合いたくなりました。キッチハイクの開発チームは、よりよい世界を目指す一員として、自分たちにできること、そして自分たちにしかできないことを引き続き取り組んでいきます。