GitLabからGitHubに乗り換えたただ1つの理由

こんにちは、ShareWisの門脇です。
今回はちょっと開発者寄りのテーマ。
つい先日、ソースコードを管理するために使うツールをGitLabからGitHubに乗り換えました。僕たちはどうして乗り換えたのか、今日はその「ただ1つの理由」をお伝えしたいと思います。

GitLab

ShareWis開発チームでは、ソースコードの管理やコードレビューに、これまでGitLabというオープンソースのツールを使っていました。
いわゆるGitHubクローン呼ばれるツールで、基本的な機能はGitHubと同じ。
自分でサーバにインストールして環境を整えなければならないという手間はあるのですが、

  • 無料でプライベートなリポジトリがもてる
    → GitHubでプライベートなリポジトリを持とうとすると有料
  • 頻繁に(毎月)アップデートがある
    → 不具合があったとしても改善が期待できる

という理由で採用し、4ヶ月ほど運用して便利に使っていました。

GitHubに乗り換えたただ1つの理由

基本的に便利に使えていたGitLab。しかし、ある理由で、先日GitHubに乗り換えることになりました。
その理由はただ一つ。
「オープンソースへの貢献を通して開発チームメンバーの成長を促したかったから」です。
最初は僕一人だった開発チームも、今ではアルバイトやインターンの方が数名加わり、ようやく「チーム」として成り立ってきました。
良いプロダクトをユーザーのみなさまに提供するために、僕も含めて、まだまだ勉強して身につけなければならない開発スキルはたくさんあります。
何とかして開発チーム全体で成長できないか、いろいろと模索している矢先にこんな記事を見つけました。
Paperboy’s engineer evaluation system – Gosuke Miyashita
Paperboy&Co.さんの技術者評価制度に関する記事なのですが、この中で胸が打たれるこんな文章があったので引用します。

ここを最後に強く強調してるのは、自分が技術者として成長してきた一番の根幹は、OSS との関わりにあるからだと思っているからです。blosxom のプラグインを書いて公開したり、CPAN Authors にパッチを送ったり、Plagger のコミッタにしてもらったり、CPAN Author になったり、自分が書いたコードを積極的に公開したり、GitHub で Pull Requests を送ってみたり、YAPC などの技術系カンファレンスでプレゼンしたり、と、こういった活動の中で、外部の素晴らしい技術者達とのつながりもでき、数多くのものを得てきました。
説明会でも話した「技術者や技術はオープンであるべき」という考えは、このような経験が元になっています。ありきたりな言葉ですが、「ギブ&テイク」の通り、オープンにすることによって得られるものは非常に多く、また、技術者にとっては何事にも代え難い財産になります。こういった経験を、ペパボの技術者のみなさんにもぜひ味わってもらいたいです。

記事中の「OSS」とは「オープンソース・ソフトウェア」のこと。
僕自身、少ない回数ですがPull Requestsを送ったり、技術系のセミナーでプレゼンしたりという経験はあるので、ここで書かれている内容に非常に共感しました。そういうタイミングで自分も成長してきたなと。
しかし、実際のShareWis開発チームを見ると、大量のオープンソースを活用してはいるものの、貢献に介してはほぼ皆無。本当にこのままで開発チーム全体として成長できるのか不安になりました。
もちろん、プロダクトの開発が最優先。ですが、プロダクトの開発をスピードアップさせるためにも、開発チームの成長は必要なはず。
チームのメンバーが少しでもオープンソースに関わることができるようにするためはどうすればいいのか。少しでもオープンソースと接点を増やすために、たくさんのオープンソースが登録されているGitHubを、普段の開発業務でも利用することにしました。
オープンソースに貢献する時の開発フローと同じような流れでShareWisの開発を行い、そこで得た経験や知識を、個人の時間を使ってオープンソースへの貢献に活用する。オープンソースへの貢献を通して技術者としてのスキルを高めて、仕事の方にも活かしていく。
こんなサイクルをどんどん回しながら、開発チーム全体として成長していきたい、そう思ってGitLabからGitHubに乗り換えたのでした。


ShareWis開発チームでは、OSSに興味があるエンジニア(アルバイト、インターン含む)を募集しています!お問い合せはコチラからどうぞ!

コメント

  1. […] 開発フローとしてはGitHub Flowを採用。 このフローは非常にシンプルで簡単に導入できるのですが、機能追加やバグ修正をProduction環境に反映する前にコードレビューを挟めたり、各メンバーの開発状況がリアルタイムに把握できたりと、とっても強力。 コードレビューをすることで、レビューする側もされる側も勉強になりますし、コードの品質も上がります。 GitHubを採用した理由については以前別の記事にまとめましたので、よろしければどうぞ。 GitLabからGitHubに乗り換えたただ1つの理由 […]

  2. ryosuke hujisawa より:

    感動しました素敵な記事を読ませていただきました

タイトルとURLをコピーしました