Speeeの新入社員向けOSSイントロダクション
（この記事および記事中で使用している画像のライセンスはCC BY-SA 4.0です。原著作者名は須藤功平です。）
SpeeeのOSS活動をサポートしているクリアコードの須藤です。2016年からいろいろな形でサポートしてきました。たとえば、OSSの開発に参加する方法を体験するワークショップを開催したり、RubyKaigiでのコード懇親会というコード（OSS）にフォーカスした新しい懇親会のスタイルを企画したり、特定のOSSの開発を支援したり、毎月何人かの社員の方と最近どう？という話をしたり、新入社員のみなさんにSpeeeとOSSについて紹介したりしています。今回は最後の「新入社員のみなさんにSpeeeとOSSについて紹介」を紹介します。Speeeに入社するとこんな感じなんだということの一部が伝わってSpeeeに入社したくなる人が増えることを期待しています！
SpeeeとOSSとイントロダクション
Speeeは社員のOSS活動を奨励しています。私のような社外の有識者（！）とサポート契約を結んでいるのも社員のOSS活動をよりサポートするためです。
採用プロセスの中では「OSS活動を奨励している」程度の説明なので、入社後少し落ち着いた段階で私から1人ずつSpeeeとOSSについて紹介しています。入社直後ではなく少し間をあけてから実施している理由は次の2点です。
- 通常業務に慣れることに集中しているときよりも通常業務に慣れてきて少し余裕が出てきたときの方が紹介された内容を理解しやい
- 通常業務のフローや通常業務で触るコードについて理解がある方が業務の中でOSS活動に取り組むとはどういうことになるのかを理解しやすい
少しあける間はだいたい1,2ヶ月です。そのくらい経ったら、まわりの人たちに少し余裕が出てきていそうかを確認してもらって、出てきていそうなら実施します。
複数人まとめて実施しているときもあったのですが、今は1人ずつ実施しています。大まかな紹介内容は後述する通りだいたい同じなのですが、紹介の仕方はそれぞれの人に合わせて変えています。どんな感じで変えているかを言語化するのは難しい（毎回その場その場でアレンジしながら紹介している）のですが、その人の現時点でのOSSに関する知識、これまでの経験、考え方などを聞きながら紹介の仕方を変えています。たとえば、すでにOSSの開発に参加した経験がある人なら、どんな経験があったか、どのような考えで参加していたか、参加してよかったと思っていることは？よくなかったと思っていることは？などを聞きます。その上で、Speeeでの業務の中ではどんな感じでOSS活動に取り組むのがバランスがよさそうかを紹介したり相談したりします。
紹介ではまずはSpeeeがOSS活動を奨励する理由を説明します。
SpeeeがOSS活動を奨励する理由
もともとは「OSSコミュニティーのよき一員であるために単に使うだけではなく開発に参加しよう！」というのがOSS活動を奨励する理由でしたが、最近はどちらかというと次のような実用的なことが奨励する理由です。（メリットがあるから奨励している。）
- 技術力向上
- メリット：
- Speee：業務での実現力向上
- 各自：評価が上がって収入増・今後のキャリアに活かせる
- 例：
- 業務のプロジェクト以外の開発に参加→業務では得られない知見の獲得→各自の技術力向上
- 得られた知見をチームに共有→チームの技術力向上
- 得られた知見をブログにまとめる→自分の理解が整理される→各自の技術力向上（およびプレゼンス向上）
- メリット：
- 業務プロジェクトのメンテナンス性向上
- メリット：
- Speee：重要な機能の開発により多くの時間を使える
- 各自：評価が上がって収入増・日々の開発が楽しくなる
- 例：
- 問題を手元で回避せずに開発元で直す→アップデートコストを上げない
- 利用OSSのメンテナンスが滞ったときに呆然とならない
- メリット：
- プレゼンス向上
- メリット：
- Speee：人事面・広報面で活用できる
- 各自：成果・コネクションを今後のキャリアに活かせる
- 例：
- 既存のOSSの開発に参加→開発者間でのプレゼンス向上
- OSSの開発に参加→成果をブログで紹介→関連コミュニティーでのプレゼンス向上
- OSSの開発に参加→成果をイベントで紹介→関連コミュニティーでのプレゼンス向上
- メリット：
OSS活動をすると一時的に業務関連の時間が減ります。しかし、長期的に見ると上述のメリットがあるので業務の一環としてOSS活動をするメリットがあります。そのため、SpeeeではOSS活動を奨励しています。ただし、ここで上げたようなメリットがあまり魅力的ではないと感じる人には無理にOSS活動をしなくてもよいと伝えています。OSS活動以外にも事業をよりうまく進めるためにできることはいろいろあるはずなので、OSS活動とは違った形で取り組めばよいからです。OSS活動をしないことで評価が頭打ちになることもありません。
「各自」のメリットの中にある「今後のキャリアに活かせる」というのはSpeee社内でのキャリアもそうですが（Speeeにとっては残念ながら）Speeeから転職するときにも役立つという意味です。入社したばかりの人たちにいきなり話すのもアレな気もしますがこんなメリットもあるということを隠すのはフェアではない気がするので説明しています。
「評価」についても簡単に説明しています。Speeeでは技術評価制度の整備を進めていて、その中で技術力向上やメンテナンス性向上が評価される仕組みになっています。業務時間中のOSS活動をただしく評価してもらうためには、評価者にこんな感じで伝えるとどうかな！という相談にものっているとも伝えています。
説明しながら適宜質問に答えたり、必要に応じて具体例や担当している業務関連で取り組むとしたら…といったことをまじえて伝えています。ちょっと説明が長くなりがちなので、詰め込みすぎてしまっているのではないかというのがもやっとしているところです。
SpeeeがOSS活動を奨励していることを聞いたうえでOSS活動に興味がある場合はSpeeeが提供しているOSS活動関連のサポートについて説明します。
OSS活動関連のサポート
SpeeeではOSSポリシーを策定しています。これはOSS活動をしたいと思ったときに悩まずにすぐに取り組めるようにするためのガイドラインです。このようなガイドラインがないといろいろな人たちに確認して回らないと活動できないといったことになりがちで、こんなに面倒ならOSS活動をするのはやめておこうとなってしまいます。OSS活動を奨励するためにOSSポリシーを策定しています。このようなOSSポリシーは次のようにいろいろな企業で策定されています。
- オープンソースソフトウェアポリシーをつくろう - クックパッド開発者ブログ
- サイボウズのオープンソースソフトウェアポリシーを紹介します - Cybozu Inside Out | サイボウズエンジニアのブログ
- ZOZOテクノロジーズのオープンソースソフトウェアポリシーを策定しました - ZOZO Technologies TECH BLOG
SpeeeのOSSポリシーはわりとさっぱりしていて、OSS活動していいよ、するときはこうしてね、といったことが簡単にまとめられているだけです。それでもガイドラインがまとめられているとすぐにOSS活動できます。
Speeeは社内チャットシステムにSlackを使用しています。Slackには#ossチャンネルがあり、だれでもいつでもOSS活動に関することを相談できます。私もこのチャンネルに参加しており、有識者（！）として相談にのっています。数年前はあまりこのチャンネルを活用できていなかったのですが、最近は徐々に活用できるようになってきました。
オンライン（Slackの#ossチャンネル）で相談することが苦手な人・適さない話題のために月に1回オフラインで有識者（私！）と相談できる機会があります。新入社員の方にSpeeeとOSSのことを説明するこの機会もオフラインで実施しています。オンラインのときよりも広範な話題・雑多な話題をしやすいです。（オンラインの場合は特定の話題で完結しやすいです。）ただ、この1年は新型コロナウイルス感染症のことを考慮して開催しなかった月の方が多いです。一度、ビデオ会議形式で終日オンラインでの相談を受け付けるという試みをしてみたのですが利用者はいませんでした。なにが悪かったのかしら。。。
オンラインでもオフラインでも、私が相談にのるときは新しい視点を提供できるようなコメントをできるといいなぁと思って対応しています。たとえば、普段の業務での開発ではこう考えることが普通なのでこう判断したというときに、OSSの開発では業務での開発とはまた違ったこんな観点があるので別のこういう判断もありかも！？みたいなコメントをしています。
SpeeeでOSS活動するにあたってどのようなサポートがあるかを説明したらそもそもOSSってなに？という話をします。
OSSとは
OSSとはOpen Source Software（オープンソースソフトウェア）の略です。
私はOSS Gateという取り組みの中でOSS開発に参加する「入り口」を提供しています。その中でOSSに関わっている・これから関わりたいという人たちと話す機会が多くあります。その経験では、どのソフトウェアがOSSかを正しく理解している人は少ないです。多くの人は雰囲気でOSSかどうかを判断しています。たとえば、GitHubにリポジトリーがあるソフトウェアはOSSといった具合です。
みなさんは次のソフトウェアがOSSかどうかわかりますか？
OSSがどのようなソフトウェアかを説明した後に答え合わせをしましょう。
あるソフトウェアがOSSかどうかはそのソフトウェアに設定されたライセンスを確認するとわかります。Open Source Initiativeという団体が承認したライセンスを使っているソフトウェアならOSSでそうでないならOSSではありません。
参考情報：What is "Open Source" software?
Only software licensed under an OSI-approved Open Source license should be labeled "Open Source" software.
Open Source Initiativeが承認したライセンスのリストは https://opensource.org/licenses/alphabetical にあります。このリストにあるライセンスが設定されていればOSSということです。
このリストのメンテナンスは公開の場で行われています。Open Source Initiativeはライセンスをレビューするプロセスをまとめており、レビューの議論は公開されたメーリングリストで行われています。レビューする際はオープンソースの定義を満たしているかが主な争点になりますが、満たしていたとしても承認されるとは限りません。
たとえば、「パブリックドメイン」や「CC0（Creative Commonsが作ったパブリックドメインのライセンス）」はオープンソースの定義を満たしますが承認されていません。パブリックドメインはそもそもライセンスが存在しないので承認されていません。CC0は明確に却下されたわけではありません。CC0の一部（4(a)の部分）でコンセンスが得られない状態になったためレビューを依頼したCreative Commonsがレビューを取り下げました。
参考情報：
- What about software in the "public domain"? Is that Open Source?
- What about the Creative Commons "CC0" ("CC Zero") public domain dedication? Is that Open Source?
前例は見つけられませんでしたが、あまり使われていないライセンスや特定のソフトウェア・用途に特化したライセンスは承認されないかもしれません。承認したライセンスがむやみに多くなると次の理由でユーザーが困るからです。
- 新しくOSSを開発する人がどのライセンスを選べばよいかわかりにくくなる
- ライセンスに互換性がないOSSを間違って一緒に使ってしまいやすくなる
- 関連するライセンスが増えやすくなり、増えるとそれらを理解することが大変になる
参考情報：
もちろん、レビュー依頼されていないライセンスはたとえオープンソースの定義を満たしていても承認されることはありません。たとえば、Vimライセンスはオープンソースの定義を満たしていますが、だれもレビュー依頼を出していないのでOpen Source Initiativeが承認したライセンスリストには含まれていません。
注：昔のVimライセンスはDebianの用語でいうところのDesert Island Testという問題がありオープンソースの定義を満たしていませんでした。
ちなみに、Vimを起動すると「Vim is open source」というメッセージがでます。実際、多くの人はVimをOSSだと思っているでしょう。しかし、オープンソースという言葉を作ったOpen Source InitiativeとしてはVimライセンスは承認されていないのでVimをOSSとは言わないで欲しいという扱いになります。（言わないで欲しいというよりはライセンス承認リクエストを出して欲しいかもしれません。）
ライセンスやオープンソースの話をしていると、コピーレフトなライセンスを使っているとOSSではないと誤解しているケースがあります。コピーレフトかどうかはオープンソースの定義を満たすかどうかとは関係がありません。つまり、Open Source Initiativeに承認されたライセンスの中にはコピーレフトのものもあればそうではないものもあります。
コピーレフトなライセンスとはオリジナルと同じライセンスにするならオリジナルおよび派生物（たとえば改造したバージョン）を再配布可能なライセンスです。コピーレフトなライセンスのOSSならたくさんの人が間に入って再配布されても最終的なユーザーが手にするソフトウェアは必ずOSSです。
コピーレフトではないライセンス（permissiveなライセンスとも呼ばれます）では再配布するときにライセンスを変更できます。つまり、最初のユーザーは確実にOSSですが、最終的なユーザーが手にするソフトウェアは必ずしもOSSとは限りません。
たとえば、Visual Studio Codeのライセンスは非コピーレフトなMITライセンスなので、MITライセンス以外でも再配布できます。実際、マイクロソフトさんが配布している実行ファイルはMITライセンスではなくオープンソースの定義を満たさないマイクロソフト ソフトウェア ライセンスです。もし、マイクロソフトさんが配布している実行ファイルがオリジナルのソースコードになにも手を入れずにビルドされたものならユーザーはOSSを使っていることになりますが、なにか変更しているならOSSではないソフトウェアを使っていることになります。
（興味がある人には自由ソフトウェアの話もします。）
OSSとはどのようなソフトウェアかを説明したのでOSSかどうかクイズの答え合わせをしましょう。
- SQLite：OSSではない
- SQLiteはパブリックドメインでありライセンスという概念はない。そのため、当然Open Source Initiativeが承認したライセンスを設定したソフトウェアにはならない。
- Vim：OSSではない
- Vimが使っているVimライセンスはオープンソースの定義を満たすがOpen Source Initiativeが承認したライセンスリストにはないのでOSSではない。
- Visual Studio Code：OSS
- Visual Studio Codeが設定しているMITライセンスはOpen Source Initiativeが承認したライセンスリストにある。
- しかし、マイクロソフトさんが配布している実行ファイルがOSSかどうかはわからない。
これでSpeeeとOSSについて一通り伝えたことになります。これで紹介を終わりにしてもいいのですが、最後に、まずなにからやってみるかということを一緒に考えます。
最初のアクションを一緒に考える
SpeeeとOSSについて一通り伝えて「ではOSS活動がんばってね！」というやり方もあるでしょうが、それだとそれっきりになりがちなので、まずはなにか1つやってみます。
なにに取り組むかは説明を受けている人の気持ち・興味・最近やっていることなどを私がヒアリングしてその場のノリ（！）で決めます。そのため、一般論としてここにまとめることは難しいです。よっていくつか具体例を紹介します。
- ケース1：使おうと思っていたOSSがメンテナンスされていなそうだけどどうしよう
- フォークしてメンテナンスしようか！（技術力向上）
- プライベートリポジトリーから始めるとかしなくていいよ！
LICENSEファイルのCopyrightに自分の名前を追加して機能追加・問題修正していけばいいよ！- 一段落したらフォーク元に興味のある人たちに連絡するといいよ！（プレゼンス向上）
- その後：GoのAthena用database/sqlドライバーをOSSでリリースした話
- ケース2：Goを書きたいけど今の業務では書く機会がなさそう
- あれ、そういえば、ケース1の人はGoを使っていたな。。。
- チームが違うけどケース1の人と一緒に開発するのはどう！？Speeeとしてはチーム間での技術交流の機会があるといいかも！という話もあったし！（技術力向上）
- その後：一緒にうまいことやっていた。おいおいブログになにかまとめられるかも。
- ケース3：Fluentdで直接データをS3にApache Parquet形式で保存したい
- 今はAmazon Athenaを使ってApache Parquet形式に変換している：Athenaを使ったデータ処理基盤の設計
- 私が激推しのApache Arrowを使えばいけるよ！
- fluent-plugin-s3-arrowを作ろう！
- Red Data Toolsの一環としても活動して、社外の人とも関わり合いながらやっていこう！（技術力向上）
- 開発中に見つけた高速化方法をApache Arrow本体で実現しよう！（プレゼンス向上）
- columnifyを使った実装よりも狙い通り速そう！
- その後：近いうちに成果がブログにまとめられるはず！
まとめ
SpeeeのOSS活動をサポートしているクリアコードの須藤が、新入社員のみなさんにSpeeeとOSSについて紹介している内容をまとめました。そんなSpeeeで働きたいなと思った人は募集中の職種を確認してみてください！
うちの会社でもこんな感じのサポートをして欲しい！と思った人はクリアコードにお問い合わせください！違う会社でのサポートの知見をSpeeeのサポートでも活かすのでSpeeeのみなさんも違う会社のみなさんもうれしくなるはずです。
