CAM TECH BLOG

株式会社CAMのエンジニア・デザイナーの活動を綴るブログです

株式会社CAMの技術ブログです。 エンジニアとデザイナーの活動や組織文化を綴ります。

OpenAPI Generator にコントリビュートしたら社名が載った話。

f:id:cam-engineer:20190701153648p:plain コントリビュータ ( Contributor ) とは、文字通りあるプロジェクトに何らか貢献してくれた人を指す呼び名です。

CAM では最近、相次いで2名の技術者が OpenAPI Generator にコントリビュートし、CAM のロゴがサイトに掲載されました。そこに至った経緯や、コントリビュータになる意義について取材しました。


目次


【 話を聞いた人たち 】
f:id:cam-engineer:20190614172801p:plain:left ejithon
サーバーサイド、アプリ・Webのクライアントサイドと幅広く経験し、直近はWebの最新技術を追いながら新規サービスを開発中。
f:id:cam-engineer:20190614173223p:plain:w30:left ejithon (Yukio Ejiri) · GitHub
f:id:cam-engineer:20190613182824p:plain:left keijumt
日々、Androidの最新の技術を追いかけています。スノーボードが好きで、雪山が癒し。
f:id:cam-engineer:20190614173223p:plain:w30:left keijumt (Keiju Matsumoto) · GitHub

なぜコントリビュートしようと?

ejithon の場合

ejithon: 去年、新規プロジェクトのアプリの開発で OpenAPI Generator を初めて使ってみたんです。 これがどういうものか、まず簡単に説明しますね。

僕たちネイティブや Web フロントのエンジニアがサーバと通信するにあたり、どんな API があるか、どんなパラメータを送ればいいのかとか、戻り値はどんな形式なのか、バックエンドのエンジニアとやり取りしながら作っていきますよね。

その時にどうしても認識が違ったり、ドキュメントの形式がまばらだったり、開発メンバーによってやり方が様々だったりするんです。

そこで統一の規格が有ったほうがいいんじゃない?ということでできたものが OpenAPI Specification というものです。

そのフォーマットに則った仕様書を書きやすくしてくれる Web エディタに、Swagger Editor というのがあり、ビジュアライズもされて構文チェックもリアルタイムにされるので、ミスに気付きやすいんです。

更にそれで書いた YAML ファイルを OpenAPI Generator に渡すと、Swiftや、Java、Kotlin、JavaScript、PHP…といった様々な言語の API クライアントに転換してくれます。

1つのテキストファイルから、様々な言語のクライアントを生成できるので、工数が大幅に省けてとても便利なのです。

f:id:cam-engineer:20190614184001p:plain


以前、その OpenAPI Generator を導入してみたのですが、、、いくつか問題点が出てきまして。

OpenAPI Generator はそれだけ多くの言語に対応しているので、当然1人ではなく言語ごとにメインのメンテナーがいらっしゃるようで、複数名で開発しています。

その時、僕らは Kotlin を使おうとしていましたが、generator の方は まだだいぶ手を入れる必要がある状態でした。

バグが直るのを待つか、でも新規開発中で時間がない中、いつ直るかわからないのを待つより、ここは安定の Java に転向した方がいいんじゃないか、という議論をしていたら、CTO がやって来て「そんなの自分で直して、GitHub でプルリク(エスト)したらいいのに」と、さらりと言うわけです。

当時の自分にはまだその発想はなかったので、ものすごくハードルが高く感じました。でも、確かにそうだなと思ったのと、改善提案だったら難易度が高いけど、バグ修正なら可能性があると思い、なんとか動くように直して、ドキドキしながらプルリクを出しました。

大抵の OSS にはプルリクエストをする場合のルール、Contributing Guidelines がそれぞれにあります「プルリク出す前に、必ずこれを実行して確認してね」とか「それでも解決しなければ、これ(条件)を書いて送ってね」といった内容が書かれています。

僕は最初、ちゃんとそれを読まずに出してしまい、コメントが返ってきました。でも、怒られたりせず、親切に対応してくれることがわかったので、最終的には Kotlin 、 Swift で6種類の修正をすることができました。


keijumt の場合

keijumt: 僕が送ったプルリクは全部合わせてもまだ2つです。ejithon さんがプルリクを出した時は Swagger Codegen というものだったのですが、それが色々強化されて OpenAPI Generator というものに進化しました。

進化版の方がいいだろうということで、僕のプロジェクトでは後者を使い始めたのですが、ここでもバグが見つかりました。

最初はローカルに該当のリポジトリをダウンロードして、それを修正して使おうかと思っていたのですが、これもいい機会だからプルリクエストしてみようかな、ということになりました。

f:id:cam-engineer:20190614185910p:plain
▲ 初めて出したのはこちら

僕も ejithon さんと同じく、チェックリストに条件が書いてあったのに、それを無視して出して、差し戻されちゃったのですが、ウィリアムさんという OpenAPI Generator のコアメンバの方が丁寧に指摘コメントをくださり、無事マージされました。

2つ目は比較的最近出したプルリクエストです。

こちらは通信ができなくなるレベルの重大なエラーでした。Swagger Codegen から OpenAPI Generator に変わった時点で、かなり大規模な変更があったのですが、その時に確認不足かなにかで、バグがあるままマージされてしまったようで、僕のプロジェクトに導入したところ、通信の時点で失敗するという現象が起こりました。

かなり深刻なバグなので、これはプルリクを出すべきだろうと感じました。

プルリクを出した後、そのプロジェクトメンバーから英語で「Should fix #2961.」というコメントがありました。

f:id:cam-engineer:20190614184318p:plain

僕はこれを ”YOU should fix ”#2961”!( 君は #2961も直すべきだ! )”って意味かと思って、びっくりしました。

件の ”#2961” は、見た感じ問題なさそうだったので、修正すべき箇所がわからず、自信なく"既に修正されてると思うのですがどうでしょうか?" と返信したら、Oh no ! そういう意味じゃないヨ!みたいな反応で。

どうやら「 should fix 」の意味を取り違えてたようで、本当は ”(君の修正によって)#2961も直ったはずだ” って意味だったんですよね。英語って難しいですね。

でも、時々そういうのはあるにしても、何度かやりとりして分かったのですが、たとえ片言でも、単語連呼してたらいけると思います。僕も英語が苦手ですが、最悪、Google 翻訳駆使すれば大丈夫だなという手応えはあります笑


ejithon: 僕らは英語というよりコードで会話できてますからね。僕のGitHub のプロフィールにはちゃんと Tokyo, Japan って書いてあるからきっと大丈夫、向こう(海外の人)もそんな流暢な英語でやりとりできるなんて期待していないんじゃないかなと思います。


貢献してみた感想

ejithon: 今だから思えるのは、バグ修正なんて普段からやっていることなのに、世界中で使われているライブラリに対して自分が手を加えるなんて、、みたいに、プルリクすることに謎の心理的ハードルがあるだけなんだなと。


keijumt: まずは勇気を出して1回投げることですかね。例えば僕みたいに英語のやり取りで見当違いな事を言ったとしても、違うよってしっかり教えてくれるので。それをクリアしたら、心理的ハードルは下がりましたね。

ただ、スラング的な話し言葉が理解しづらいことはありますね。何を言ってるんだろうと Google 翻訳にかけると、全然違う内容を返してきて、余計に混乱することもありました。


ejithon: 指摘に対して再修正して上げ直したあとに、合ってますかね?ってコメントを返したら、シンプルに” Definitely!!”って返ってきた時があって、あれは嬉しかったなぁ。

f:id:cam-engineer:20190614184749p:plain


どうやって課題を見つける?

ejithon: 業務で使用している中で不具合として発見して、解決しないと仕事が進まなくなるから修正する、というのが大半です。

常に最新でパーフェクトなライブラリなんて存在しないし、日々開発されているけど更新が間に合ってないという時もあるし、はたまた、そもそもの持ち主本人が力尽きちゃって開発をやめてしまうケースもあるから、当然他の人がやるしかない。

フォークして直したり、ローカルにコピーして修正する手もありますけど、、OSS の本質じゃない。使わせてもらっているばかりではなく、自分でもできるのだから、本家に取り込んでもらうべきだなと。

今の CAM には「(自分だけよければいいという考えは)違うよね?」っていう空気があって、それが文化として定着しつつあるように見えます。


CAMのロゴ掲載の経緯

keijumt: 僕のプルリクがマージされたあとに、プロジェクトのコアメンバーのウィリアムさんから直接、連絡が来たんです。僕の GitHub のアカウントを見て、 CAM inc. という組織に所属していると知って、会社で ” OpenAPI Generator をどんなふうに使っているのかとか、Android や iOS などのクライアント側なのか、サーバ側でも使っているのかなど、具体的な使用事例を紹介してほしい” という内容でした。

これに返信したところ、"もしよかったら、会社のロゴをサイトに載せてみないか?” とオファーを下さったので、ロゴを送りました。


f:id:cam-engineer:20190605121628p:plain
▲ CAM のロゴ(黄色の丸の箇所)が掲載されています!

openapi-generator.tech

さらに、Twitter で ”OpenAPI Generator にプルリク出してみた” という内容を呟いたら、今度は日本人のコントリビューター のコアメンバーの方から「お気に入り」をもらい、この方からも組織名掲載しませんか?というオファーをもらいました。事例を積極的に載せたいという姿勢が見て取れましたね。


コントリビュートしてよかった事

ejithon: フランクに、コアメンバーの方からメールがきたりします。英語なんですけど、「HI! Yukio-san!」って「さん」づけしてくれて、かなりフレンドリーでしたね。

何度かやりとりする中で、何か要望はないかと聞いてきたので、”欲を言えば〜” のような希望を伝えたら、早速チケット化してくれたり、面白い展開になりました。

一方、彼の方も自著の電子本を買ってほしいというので、購入しました。こういうコアメンバーとの直接的なやりとりができるのも、コントリビュータの醍醐味かもしれません。


keijumt: 個人的な趣味ですけど、自分の GitHub のプロフィールページに、自分の貢献度や内容や、活動傾向だったりが可視化されていくのを見るのが、ゲーム感覚で楽しかったりします。

緑のマスは年間カレンダーで、コミットした日のマスに色がつく仕様です。自分の貢献が目で見えるので、モチベーション維持に効果的です。(365日達成しました!)

f:id:cam-engineer:20190607164713p:plain
▲ 緑のマスはコミットした日を示す。コミット数が多いほど色も濃くなる


ejithon: プルリクを通してオンラインでやりとりした人と、国際的なカンファレンスの会場で会って、直接お話しできたりするのも、なかなかできない貴重な体験ですね。


コントリビュートを考えている人へ

keijumt: 最初、英語のハードルは高いかもしれませんが、やったもん勝ちです。

プルリク出して、何言われるのかな、とか不安でしたが、間違っていることを書いても、ちゃんと優しく教えてくれるので、一度経験すると、ぐっとハードルが下がります。


ejithon: 普段の生活では知り合えない人と知り合えたり、こちらのことをワールドワイドレベルで知ってくれる人が増えたりすることも、価値があると思います。

バグ修正まで行かなくても、バグ報告(issue)だけでも貢献になるので、できるところからまず実行に移す事で、様々な可能性が拓けてくるかもしれません。


f:id:cam-engineer:20190614185037p:plain:w300


(取材・文: クリエイティブ広報 桑田)