Richard Imaoka's Blog

2017年より職業Scalaプログラマになった、リチャード・伊真岡のブログです。

OSSハッカソン第2回 株式会社セプテーニ・オリジナル主催

さて、先日OSSハッカソン第2回目が株式会社セプテーニ・オリジナルさんの主催で開催されました。

osshackathon.connpass.com

セプテーニ・オリジナルさんは技術コミュニティカツドウに積極的に貢献していて、

www.septeni-original.co.jphttp://labs.septeni.co.jp/

技術ブログでの発信やScalaMatsuriでの「読本」の配布なども行っています。

labs.septeni.co.jp

(リンク先は2017年版ですが、2018年版もScalaMatsuriで配布されました。)

先週のオプト・テクノロジーズさんもそうですが、こういった技術コミュニティやOSSカツドウを支援してくださる会社の存在はありがたいですね!

ハッカソンにて共有されたOSS貢献のコツ

第2回も第1回に引き続き、3人のOSSメンテナが参加してくださいました、ありがとうございました!

名前 備考 参加枠 担当プロジェクト
xuwei_k Scalazを始め多数のScala OSSのメンテナ OSSメンテナ Scalaz scalaprops msgpack4z argonaut-io scalapb-json 他
kounoike GitBucketメンテナ OSSメンテナ GitBucket
あおいの Monocleコミッタ OSSメンテナ Typelevel.scala 関連など

さて、ハッカソンの中でxuwei-kさんにOSSコントリビューションに関して有用な知見の共有をしていただきました。下のツイート自体は数ヶ月前のものですが、当日もxuwei-kさんは、この方法を使ってpull requestを上げていました。

当日あげていたPRがこちら。

github.com

こうやって効率的に自分の好きなOSSにコントリビュートできる方法があると、OSSにコントリビュートしてみたい人にとっては助かりますね!

基本的にはOSSメンテナは自分のOSSプロダクトに興味を持ってもらえること自体が嬉しいので、こういった形での貢献でも歓迎してくれることが多いと思います。(この手法を紹介してくれたxuwe-kさん自身がScala界では超有名なOSSメンテナです。)

ココからは私の意見ですが、自分ができることからOSSにコントリビュート始めて、慣れてきてから新機能の追加や手強いバグの修正など難易度の高いコントリビューションに挑戦するとよいのではないでしょうか。最初から「役に立つことをやらなきゃ!」と気負う必要はありません。

ハッカソンの様子

ハッカソン中はお菓子を食べながら、みんなもくもくと、ときに歓談(?)をはさみつつ作業を進めていました。今回はblac_k_eyさんもお菓子を持ってくてくれました。優しい!

実際には一番お菓子をたくさん食べていたのは私リチャードでした。圧倒的に一人だけモリモリ食べてましたね、他の参加者の皆さんごめんなさい笑

(会場の写真は撮り忘れたので以下はイメージです。そのままではないけどこんな感じのお菓子が提供されたっていうことで…) f:id:richard-imaoka:20180707220024p:plain

当日の会話のようすは誰でもいつでも参加可能なOSSハッカソン用Slackワークスペースからも一部ご覧いただけます。OSSハッカソンの様子が気になったら、「YOU入っちゃいなよ」です。参加してください!

そして今回の成果の一部です。この他にも皆さん成果を上げていたようですが、全ては把握していません、ごめんなさい!

kounoikeさんは自身のプロジェクトに対するPull Request含めて4件と生産性がたかい!さすがOSSメンテナです。

github.com

https://github.com/kounoike/gitbucket-ipynb-plugin/pull/6

https://github.com/kounoike/gitbucket-ipynb-plugin/pull/7

https://github.com/kounoike/gitbucket-ipynb-plugin/pull/8

blac_k_eyさんは前回から引き続きServerlessフレームワークに取り組んでいたようです。継続的に貢献する対象があるっていいですよね!私も継続して貢献するプロジェクトが見つかってからは楽しかったのでわかります。

github.com

私はPull Requestは上げあられませんでしたが、イシューを一つ報告しておきました。

github.com

ハッカソン中の写真は取り忘れてしまったので、代わりに懇親会で食べたおいしそうな鯛のカブトのようすをどうぞ。

f:id:richard-imaoka:20180707220428j:plain

次回予告

次回は7/28土曜日に行う予定です。オンライン懇親会という目玉企画(!?)を用意しています。オンライン懇親会の詳細については準備中ですので、しばしお待ちを!

osshackathon.connpass.com

OSS Gateに参加してきた

OSS Gateというイベントに参加してきましたのでレポートです。

oss-gate.github.io

OSS活動のためのワークショップ運営ノウハウについて勉強になる点が多かったです。2年以上続いているイベントだけに、初心者がつまづくポイントの把握と現場での対応、資料の充実度が素晴らしいなと思いました。

私以外の人のレポートも、過去回のレポートもワークショップレポートから読めますよ。

ビギナーが主役、OSS活動の「最初の一歩」に特化

下記の資料を見ていただくと、OSS Gate「ワークショップでやりたいこと」は「未参加・興味あり」から「(やったことあるけど)自信ない」への変化です。つまりワークショップの中だけで「自信がある」状態にすることは目指してないわけです。そして、「自信がある」状態にするためにはOSS Gate関連の別のイベントがあって、そこでOSS活動のレベルアップを支援する仕組みになってます。

Richardの感想

このターゲットをしっかり絞っている点は興味深く、それによってマニュアルの充実や知見の蓄積を促進できているのかなと想像しました。ターゲットを絞っていることが、下で説明している「基本的な作業の流れ」のフォーマットが決まっていることにも通じてきます。

ビギナー役とサポーター役がペア

当日はビギナー役とサポーター役が一対一でペアになって取り組む形式でした。この「一対一ペア」形式は、サポーターの負担を減らすために最近始めた形式らしいです。

基本的な作業の流れ

OSS Gateの作業は、OSSの公式チュートリアルをなぞって改善点をOSSプロジェクトにフィードバックするという流れだったようです。

例えば、「チュートリアルのココが間違ってる」とか「チュートリアルのココがわかりにくいので、改善してほしい」という提案をイシューとしてあげる、もしくはPull Requestとして送るなど。

Richardの感想

無理に既存のイシューやバグに取り組んだりせず、公式チュートリアルに沿うことを推奨しているのは、ビギナーにとっては敷居の低い方法になるのでしょう。

そして運営側にとっても「公式チュートリアル沿う」という作業の進め方を推奨することで同じ進行方向に対する知見が溜まっていきます。たとえば、チュートリアルのどういう点に気をつけて読むと、OSSプロジェクトに提案すべき改善点を見つけやすいか、といった点など。

ただ「公式チュートリアルに沿う」という形がしっくりこない人もいるかと思います。そういう人はOSS Gateの「もくもく会」の方に参加すると良いでしょうね。

oss-gate.doorkeeper.jp

スタッフがビギナーのつまづくポイントを把握している

流石に二年開催しているイベントだけあって、細かいところでビギナーがつまづきそうなところ、あるいはサポーターも困りそうなことをスタッフが的確に指導できるだけの知見の蓄積を感じました。

例えば、スタッフの方から「サポーターの人は、ビギナーと一緒に悩んでください。サポーターが知っていることがあっても先回りして教えすぎないでください。ビギナーが混乱します。」という案内がありました。これ、サポーターで自分の知識に自信がある人はやってしまいがちですよね。かならずしも「正解を教えること」を再重視するわけでなく「ビギナーがOSS活動のGateをくぐる」ことがいちばん大事なので、ビギナーが納得行くように、自分で似たような問題に直面したときに自力で解決できるよう、自分がどうやって解決したのかを見つめ直す手助けをするのが良いサポートのようです。

その他にも、ビギナーからの積極的なアクションを引き出す方法、つまづきやすいポイントなどを2年という長いイベント開催の経験からしっかりと把握しているという印象でした。

作業メモ

ビギナー役参加者は、当日の作業録を事細かにGitHub Issuesに残します。

かなり細かく、ターミナル上で実行したコマンドの一つ一つとその出力結果を記録する感じです。そうすることで、違う人が作業メモだけをみても全く同じ手順を繰り返すことができる、というのを目指しています。

Richardの感想

やってみるとけっこう面倒くさい作業ログ笑。でもこれを過去回で一生懸命ビギナーにお願いし続けてきたからこそ、今のこれだけのサポート体制があるのだろうなと思いました。

すでに400件近い作業ログが溜まっているようなので、これらを分析したら面白いデータが抽出できるかもしれませんね。

情報発信について

OSS Gate公式サイトをみると、ドキュメント、動画スライドチャットと本当に情報が充実しています。歴史のあるイベントならではですね。

OSS Gateを自分で主催しタイ人向けに「OSS Gateを開催するには」という開催手順マニュアルまであります。

Richardの感想

OSS Gateの資料は本当に充実していると思います。しかし充実している分、それを外に向けて発信していくのはなかなか大変そうだなと思いました。

まあ、参加してくれるひとが、次第に理解を深めていってくれればいいし、現場で混乱が起きないように対応できるようスタッフさん達で知見の共有がされているようなので、情報発信に関して問題は特にないのかなとも思います。

ただ、チャットに案内する導線が弱い気はしました。OSS Gate公式サイトのトップページを見てもあまりチャットの参加を強く呼びかけてはいないようですし、実際チャットを活用するよりは現地でのサポーターxビギナー間の対話を重視しているような印象でした。

OSSハッカソンについて

OSS Gateのレポートはココまでです。ワークショップの運営について、非常に勉強になる体験でした。というのも私もOSSハッカソンというイベントの管理人をやっていまして、そこで活かせそうな知見をたくさん得ることができたからです。

osshackathon.connpass.com

運営方法の「ある程度の」パターン化も取り入れるべきかな、とおもいますし、資料作りは大いに学ぶところがありました。

こちらはOSS Gateのもくもく会の方により近いイベントのようですね。

こういう試みは色んな種類があって良いと思うので、どちらのイベントも仲良く、OSS活動を盛り上げていければと思っています。

税理士事務所に行って「外部エンジニアを社内勉強会に呼ぶサービス」の税金の処理について聞いてきた

最近、会社によっては積極的に外部のエンジニアを講師として招いて勉強会を開いているようです。正直、羨ましい。

そういった勉強会をどんな会社でも手軽に開けるといいんじゃないかと思い、以下のようなサービスを考えてみました。(考えただけで、まだ作ってないです。)

f:id:richard-imaoka:20180609103430j:plain

ところでみんなが幸せになりそうなこのサービスですが、大きな問題があります。

税金の処理がめんどくさい。

そうなんです、税金がめんどくさい。消費税、所得税、それから確定申告どうすんの?とか。住民税が増えたら副業としてやった勉強会講師が会社にバレるんじゃないの?とか。

というわけで、今回私は税理士事務所に行って話を聞いてきました。

TL;DR

  • 依頼元の会社が考えるべき税金は二つ、所得税源泉徴収と消費税
  • 依頼先の講師役個人が注意すべきは確定申告、雑収入20万円超えたら確定申告が必要
  • 残念ながら副業バレを100%防ぐ方法はないけど…

この記事は私が税理士にあって話してきたことをまとめたものですが、記事を書いた後に税理士にレビューを受けたわけではありません。そして私は税の専門家でもありません。情報の正確さには最善を尽くしますが、記事内容に間違いが含まれる可能性があります。

講師料の支払い

この「サービス」は依頼元企業と依頼先講師個人をつなぐ手助けをしますが、契約自体は直接依頼元企業と依頼先講師個人の間で結ばれるという前提で話をします。

消費税

まず、依頼元企業が講師個人に支払いをするときに考えなくては行けないのは消費税です。

f:id:richard-imaoka:20180609105241j:plain

例えば講師料(税抜)が10,000円だとしたら、その8%の800円を上乗せしますよね。

「外部講師に講師料を支払い」という取引は消費税の課税対象取引になります。なので勉強会の依頼元企業は消費税を講師に支払わなくてはなりません。

No.2795 原稿料や講演料等を支払ったとき|国税庁

反対に、消費税を受け取る側の講師個人は事業としての売上が1,000万円を超えない限り消費税を納付する必要はありません。このサービスだけで1000万円稼ぐ人はいないでしょうから、もらった消費税分は懐に入れてOK。

他の個人事業と合わせて1,000万稼ぐ人は、もともと1,000万稼ぐつもりの人でしょうから、この記事を見なくても消費税を納税するつもりでしょう。

所得税源泉徴収

f:id:richard-imaoka:20180609105554p:plain

次に気にすべきは所得税源泉徴収です。外部講師は、依頼元企業から雇われてないので、給与を支払っているわけではありません。あくまで講師料の支払いなのですが、それでも講師料は所得として源泉徴収します。

No.1500 雑所得|国税庁

公的年金等や原稿料・講演料などは、原則として支払の際に源泉徴収が行われます。

つまり、依頼元企業で講師料に以下の税率をかけて、所得税分を後ほど納付しなければなりません。

f:id:richard-imaoka:20180609110142p:plain

No.2795 原稿料や講演料等を支払ったとき|国税庁

ところで、税理士さんに聞いたところ、所得税を「消費税込の金額」に対して税率をかけるか、「消費税抜の金額」に税率をかけるかは企業によってやり方が違うとか…ホントに??そんなこと許したら税額変わるんだけど、私の聞き間違いだったんですかね…?

講師料を受け取る方の講師個人は、所得税に関して特に考える必要はありません。すでに源泉徴収で依頼元企業が納税の処理を行ってくれているからです。ただし講師料を含む雑所得が年間20万円を超えると、勉強会依頼元企業に任せておけず、以下のように確定申告が必要になってきます。

確定申告と雑所得20万円の壁

給与所得受けている人は、雑所得が20万円を超えると確定申告をしなくてはなりません。

確定申告が必要な方|国税庁

それは、給与を得ている勤務先が1箇所でも2箇所でも同じです。

(2) 給与を1か所から受けていて、かつ、その給与の全部が源泉徴収の対象となる場合において、各種の所得金額(給与所得、退職所得を除く。)の合計額が20万円を超える

(3) 給与を2か所以上から受けていて、かつ、その給与の全部が源泉徴収の対象となる場合において、年末調整をされなかった給与の収入金額と、各種の所得金額(給与所得、退職所得を除く。)との合計額が20万円を超える

勤務先へが副業バレる心配

勉強会の講師を引き受けて講師料を受け取るということは、おそらく多くの会社では副業規定に引っかかることと思います。

税金の面から副業がバレる典型例は、住民税の処理によるものです。

住民税は、前年度の収入実績によって当年度の住民税額が決まりますので、副業分が反映された住民税額が市区町村から会社に通達され「お前の住民税額はウチでの給与だけで想定されるより高い!副業やっとるな!!!」となるわけです。

まず、主たる給与を受け取っている勤務先からの給与は当然市区町村に把握されます。そして副業、この記事の場合は講師料の収入も源泉徴収をされているので市区町村に把握されています。

一応これには逃げ道があって、住民税を「普通徴収」というものに切り替えてもらえば、つまり会社を通してでなく直接住民税を自分で納めれば会社には住民税額は知られません。

まあ、下記のPDFのように、いろいろ厳しい世の中になってきているようですが…

http://www.tax.metro.tokyo.jp/kazei/tokubetsu/pdf/project_flyer.pdf

副業規定は民事の問題で、違反したからと言って犯罪ではないので、あとは勤務先がどれほど副業について厳しく取り締まるか、自分は勤務先にバレることをどれだけ恐れるかというバランスの問題になりますが…

というわけで、勉強会講師仲介サービス周りの税金処理についていろいろ見てきました。面倒なことは多いですが、「最悪会社にバレてもいいや」という心に余裕のある方には利用していただけるでしょうし、次第にこのサービスが(まだ作ってないんですけど)そういう「会社なんか知ったこっちゃねえ」精神の自立したエンジニアを作る一助になれば嬉しいですね。

OSSハッカソン第1回 in オプトテクノロジーズ

 OSSハッカソンの定期開催第一回が行われました!

osshackathon.connpass.com

会場提供はオプトテクノロジーズさん、休日にも関わらずハッカソンのために会場を用意してくださいました。ありがとうございました!オプトテクノロジーズさんはOSSハッカソンだけでなく様々な技術コミュニティを積極的に支援しています。

www.opt.ne.jp

14時にハッカソンが始まると簡単な自己紹介を皆さんにしていただいた後、まずはOSS貢献を効率的に行うためのノウハウ共有。例えば

  • GitHub Issuesでhelp wantedなどのタグがついたものがとっつきやすい
  • 取り掛かりたいイシューがあれば”I will take it”等とGithubのIssueにコメントすると、他の人にIssueをさらわれない
  • GitHub Issus一覧の古い方から見ていく、新しいイシューは他の人が先にとってしまう可能性がある
  • 自分の困りごとを解決するのがOSS貢献になるのが理想、他人の困りごとを解決するのは大変

(追記: その後のxuwei-kさんからのコメント)

などが紹介されました。

OSSメンテナの参加

今回はOSSメンテナであるseratchさんとxuwei-kさんがリモート参加、kounoikeさんが現地参加。立ち上げたばかりのコミュニティのハッカソンを快くサポートしてくださいました。参加者からもメンテナと一緒に作業を進められることが好評だったようです。

twitter.com

twitter.com

twitter.com

ハッカソンの作業進行

一旦作業時間に入ると、和やかながらもみな真剣に課題に取り組んでいました。

f:id:richard-imaoka:20180527231509j:plain

f:id:richard-imaoka:20180527231537j:plain

まず重要なのがその日に取り組むべきイシューを選ぶこと。難しいイシューを選ぶと時間がかかりすぎてしまうため、 とくにOSS貢献に慣れていない人は簡単なイシューから取り掛かってみるのがオススメです。

参加者は適宜他の参加者と議論したり、二人で話し合っていたところにより詳しい他の参加者が横からアドバイスしたり、 メンテナに質問したりとハッカソンOSS貢献を行うメリットをしっかりと活かしていました。 とくにメンテナからの反応が早く大きな助けになりました。(今回メンテナも参加したSlackはこちらから誰でも自由に参加いただけます。ハッカソン期間外も是非活用してください。)

休憩時間に入ると、皆で集まってミニたこやき会。この頃には皆すっかり打ち解けていた様子。

ところで余談ですが、今回kounoikeさんから、練習用レポジトリにてpull requestをマージすると光るRaspberry Piが持ち込まれにわかに盛り上がりを見せました。

今回の結果

今回会場からは9名の参加者中3件のPull Requestが上がりました! その他にもあと一歩でPull Requestがあげられるという方が数名。きっと後日Pull Requestを上げてくださるのではないかと思います。

github.com

github.com

(もう1件のPull Requestはリンクを確認中)

そしてリモートからは、メンテナとして参加されていたxuwei-kさんが、ハッカソン時間中も時間外も両方合わせて、一日全体でものすごい数のPull Requestをあげていました。圧倒的です!!

今回の感想

参加者の皆様から頂いた感想の一部を紹介します。

  • OSSメンテナからの素早いヘルプが一番ありがたい
  • 事前準備で取り組むイシューの選別、OSS貢献の取り組み方など紹介があるともっとよかったかも
  • OSSプロジェクトごとのテスト設定やコードレビューのあり方の違いがわかって面白かった
  • 簡単そうに思えたイシューに取り組んだが、やってみるとめんどくさくて時間がかかった
  • OSS貢献に集中するための時間を設けられたのは良かった
  • 英語でpull requestのメッセージを書くとき、ハッカソンだから他の人に聞いて助けを得られたのが良かった

(感想内で言及されているメリットの一部は、ハッカソン期間外でもSlackに参加することで享受することができます。)誰でもいつでも自由に参加できますので、どうぞSlackだけでも覗いてみてください。

さて、ここからは私個人の感想です。 今回は定期開催第一回目ということで、なかなか至らないところや手の行き届かないところも多かったかと思います。 そんななかで、どこを一番強化していくべきかというと、メンテナやチュータ役をどんどん集めて参加していただくことが重要だと考えています。皆さんの感想を聞いて、OSS貢献を目指す人達にとって、OSSハッカソンが提供できる一番のメリットはやはり「質問・共同作業できる機会」だと改めて思ったので、そのためにはヘルプしてくださるメンテナやチュータ役の充実が重要だと考えています。そうすれば初心者参加のハードルも下がりOSSコミュニティが拡大していくはずです。

OSSハッカソン管理人として、どんどんメンテナに突撃してハッカソンにご協力いただきたいと思っています。

来月もOSSハッカソン開催予定!詳細決まったらまた発表します。

オチ

エンジニアにとってよい転職とはなんだろう?

TL;DR

現時点での私の結論は、以下の3つの合計を長期的バランスをとりつつ最大化すること:

  • 収入が上がること
  • 自分が興味のある分野で、可能な限り影響力の大きい成果が出せること
  • 自由な時間を確保できること

エンジニアにとってよい転職とは

エンジニアにとってのよい転職とはなんだろうということをずっと考えている。

収入だけが大事ではないと思う。私も経験したが、高収入でクソのようなエンジニア職はある。

スキルが上がることが重要だろうか?たしかにエンジニアにとってスキルは非常に重要だが、スキルがあがっても年収がついてこない仕事はだいぶ悲しい。しかしスキルさえ身につけば、その次の転職で収入は爆上げできる?いや、そもそもスキル向上と年収って相反するものなのか?

それから健康的な労働環境も重要だ。例えば、長時間労働は思考力すら奪う。

どうやらいろんな項目をバランスして評価しないと、よい転職かどうかは判断できなさそうだ。当たり前と言えば当たり前だが。

3つの重要項目

では、転職に際して考慮する中で、特にエンジニアにとって重要な項目はなんだろう?自分自身の転職や業務での経験を踏まえて以下の3つを上げてみた。

  • 収入が上がること
  • 自分が興味のある分野で、可能な限り影響力の大きい成果が出せること
  • 自由な時間を確保できること

これらに異論がある人もいるだろうが、できるだけ広範な人にとって重要度が高いであろう項目をあげたつもりだ。

収入に関しては、多くの人が納得するところだろう。理屈の上では福利厚生も収入として換算できるし、年収という形ではなくてもストック・オプションがあればもちろん魅力的な転職になる。(私個人の考えで言えば、他人の作った会社のストック・オプションに期待するのは悪手だが…)。

次に「自分が興味のある分野で、可能な限り影響力の大きい成果が出せること」について。「自分が興味のある分野で」というのは、たとえば

  • 研究志向のつよいエンジニアが、2番煎じビジネスでマーケットシェアを奪ってもうれしくないだろう
  • アーキテクチャ設計を極めたいエンジニアが、カスタマーサポートエンジニアとしていくら顧客の評価が高くてもうれしくないだろう

ということ。「可能な限り影響力の大きい成果が出せる」というのは多分わかりやすいと思う。1000万円のビジネスを作った、というよりも1億のビジネスを作った、という方がおもしろいだろうし、1,000人を助けられる仕事より10,000人を助けられる仕事のほうがいいだろう。

自由な時間も大事だ。今の時代、仕事だけが人生ではないし、仕事以外の取り組みが次の仕事に活きてくることも多い。

もちろん中には「自由な時間は必要ないから、とにかく働きまくって、成果を出してめちゃくちゃ稼ぎたい」という人もいるだろう。人によって、時期によって各項目の重み付けは異なる。

それからこれら3項目にピンとこない人もいるだろう。当然まだまだ検討の余地はあるが、これらは「各エンジニアの価値観」を最重要視しているわけではなく、長期的に人生を豊かにするために重視すべき項目だと思っている。「私はコレが好きだから!」といってどんどん経済的に困窮したり、人生の時間が奪われていく選択肢を避けるための指標ということだ。

スキルについて

さて、この3項目に意図的に入れなかった項目がある。それは「スキルが身につく」という条件。

多くのエンジニアが第一に考える条件だろうし、私自身の最近2回行った転職もスキルアップを重視しての転職だった。ただ、このスキルというものは最終的には何か仕事で成果を残すためにあるのであって、つまりそれは2番めの項目の「可能な限り影響力の大きい成果が出せること」の文脈の中で考えられなければならないものだと思っている。スキル獲得自体が目的化してはいけない。スキルが重要視されるエンジニアだからこそ、あえてスキル自体でなくどのような成果が残せる仕事か、どうスキルが収入に結びつくのかについて考えてもらいたい。

よい転職評価「モデル」

ということで、この3項目をベースに転職の良し悪し判断するモデルを考えてみたいと思う。モデルというと意味がわかりづらいかもしれないが、言わば転職の良し悪しの計算ルールだ。ただし、計算ルールといいつつも数字を一発でバシッと出すのは難しく、この記事を書いた時点ではできなかった。

細かい計算についてはこの記事ではなく後々検討できたら良いと思っている。

それから先に重要項目を3つに絞ったのにはモデル化する上でも意味がある。重要項目が多過ぎるとモデルが不安定になり、いわゆるオーバーフィッティングになるからだ。例えば、参考事例の集合として東京在住のWeb系エンジニア100人をうまく説明するモデルを作ったとしよう。しかし、評価対象の重要項目が多すぎてモデルが不安定だと、101人めのエンジニアに同じモデルを適用したとき大きな誤差を生みやすい。モデルの重要項目は少なくあるべきで、そうすれば東京在住のWebエンジニアも、地方在住の組み込みエンジニアも、同程度の誤差で評価できる安定したモデルをつくりやすい。

(統計に詳しい人は、「たくさんの項目を加味して、重回帰分析で重要項目を導き出せばいいじゃん」と思うかもしれない。そういうやり方も非常に興味深いが、今回は置いておこう。計算モデルの導出が複雑になるので、ちょっと私には扱えない。いずれ重回帰分析によるモデルも検討してみたい。)

制約条件

人によっては絶対に譲れない条件があるだろう。絶対に東京で働きたい人もいるし、あるいはバリアフリーの会社でしか働けない人もいるだろう。

これら制約条件は、先の転職評価モデル内の3項目と違い「点数が高いほどいい」という類の物ではなく、「この条件は絶対に譲れない」「この閾値を超えたらアウト」というゼロイチの判断基準である。

つまり私の考える転職評価モデルは、転職者によって定められた制約条件の中で、転職者の志向を重み付けによって反映した3項目の合計値を最大化する、それをよい転職と評価するモデルになる。

なお、制約条件は奥の深い話で、実は転職者本人にとって気にする必要がない制約条件が見つかれば、それを外すことで一気に3項目の合計点を上げられる可能性がある。例えば、「絶対に英語を使う職場に行きたくない!」という人も、突き詰めて考えれば英語を使いたくないわけでなく日本にいたいだけであって、そこに気づけば一時的に英語を猛勉強して一旦外資系の会社に転職し、その後はバイリンガルエンジニアとして高級な職を渡り歩いたり、あるいはリモートワークで海外の会社に雇われることもできるかもしれない。

長期的な最大化

最後に、3項目の合計点は長期に渡って考えないといけない。直近の転職で仕事量が増え自由時間が減り、年収が落ちたとしても、大きな成果を残せることが期待できて、数年後に良い条件で転職できるならそれは良い転職といえるだろう。もちろん、未来のことはわからないので、不確実性を割り引いて考えないといけない。

ただし、長期的に考えると言っても、得られるものは早く得られる方が良い。若くして多額の資金を得られれば、別のビジネスを初めてもっと楽しい人生を歩めるだろうし、長期休暇をとることもできる。キャリアの早い段階で仕事上大きな成果を残せれば、有利な条件での転職ができ、さらに大きな成果を転職先で積み上げやすくなるだろう。

これが、現時点での私の結論だ。先に言ったようにこれらを定量化する段階まではこの記事を書くにあたって至っていない。今後機会を見て、定量的な視点を交え転職の良し悪しというものを分析できればと考えている。

akkaというOSSに100コミットした話

akkaに2年3ヶ月ほどかけて100コミットしました

ScalaOSSにakkaという非同期プログラミング用のライブラリがあるのですが、 それに対して私の総コミット数が先日100に達しました

f:id:richard-imaoka:20180520170711p:plain

イェーイイ‼︎

最初のコミットから2年3ヶ月くらいかけて100コミット達成です。まずは自分を褒めたいwけど、それ以上にakkaのOSSメンテナの人たちの素早くかつ丁寧なレビューにいつも助けられた上での100コミットでした。

100コミットというと、どれくらいすごいのか

今のところ転職オファーが大量にドバァー!とかはありません。そんなに甘い世界ではありませんでした。

そして私は自分自身のことをakkaのエキスパートだなんて少しも思っていません。まだまだわからないことがたくさんあります。今もひとつひとつコントリビュートするたび、たくさんのことを調べながらのコントリビューションです。

反対に言えばそんな状態の私でも100コミットすることは出来ました。

100って、なんかインパクトありますよね?なんていったって3桁ですよ?2桁の一個上ですから。ドラクエだったら大ダメージです

コントリビューションを続けるコツ

大したことない私がOSSコントリビューションを続けられたのには、コツのようなものがあるにはあります。

まず、コントリビュートしやすいOSSプロジェクトを選ぶことです。

  • メンテナ・レビュワーは素早く反応してくれるか
  • 貢献しやすい簡単なイシューが多くありそうか?

という点が大事です。とはいえ最初から判断するのは難しいでしょうから、(GitHub上のプロジェクトなら)Pull Requestを数件送ってみて、あからさまに反応が悪すぎるとなったら、残念ながら別OSSプロジェクトに移る必要がありそうです。

そして最初から「画期的な機能を提案するんだ!」とかいうプライドをもたずに、ひたすら簡単なイシューを探して潰していくほうが当然コミット数は稼げます。ドキュメント更新系のコントリビューションは狙い目です。画期的な機能は事前に根回しをしておかないと、苦労して実装してもメンテナから拒否される可能性が高いです。画期的な新機能は、慣れてから取り組みましょう。

それから、最初の1コミットがうまくいったとしても、やはり継続していくのは難しいです。私の場合は仕事が忙しい時、akka以外の他の技術分野に興味が湧いた時、アイカツにハマった時…様々な理由でコントリビューションが途切れました。特に理由がなくてもやる気がなくなることだってしょっちゅうでした。途切れないのが一番ですが、途切れたら再開できそうな時に再開してみることです。私は長い時は数ヶ月の間隔をおいて再始動を繰り返し、合計したら2年3ヶ月経っていました。

OSSハッカソンについて

先ほど言ったように、まだまだ自分がエキスパートになったなんて全然思いませんが、OSSコントリビューションを続けている中で次にやってみたいことが見えてきました。

そのひとつがこれ、OSSハッカソンです。

osshackathon.connpass.com

せっかく自分がやって楽しかったOSSコントリビューションを一緒に頑張る仲間が欲しい、他の皆さんをサポートしてOSSコントリビューションを盛り上げていきたいと思ってます。自分一人でやるより、大勢でやった方が全体では成果がでますからね。

実は過去にScalaMatsuriというカンファレンスのなかでOSSハッカソンを実施しています。その時は参加者の皆さんに成果、つまりPull Requestを上げてもらうことができました。(下記のツイートはPull Requestを上げた人数は10人、Pull Request合計数は12という意味。全体の参加者は25人ほどでした。)

一度やってみて手応えを感じたので、ぜひ続けていきたいです。そのためにOSSハッカソンを継続運営していくコミュニティを新たに作りました。いつか、OSSハッカソン参加者の中からOSSメンテナが出て来たり、OSSハッカソンをきっかけに有名なOSSプロダクトが生まれたりしたら楽しいですね。

それでは、みんなでワイワイOSSコントリビュートしたい人はOSSハッカソンで会いましょう。ハッカソンに参加できない方でも、Slackへの参加は大歓迎です。Slackに関しては、ハッカソン当日もハッカソン期間以外も、質問や相談、雑談ができるスペースにしていきたいと思います。OSSコントリビューションに関する細かいノウハウも教え合えるようにしていきたいです。

ではまた!

OSSコントリビューション その2 ドキュメント修正のイシューを探す

こんにちはみなさん、リチャードです。

前回「OSSコントリビューション イシューの見つけ方 その1 - Richard Imaoka's Blog」という記事でOSSコントリビューションを始めたい方向けに取り組むべきイシューの探し方を紹介しました。

しかし、ある程度規模の大きなOSSになってくると、上の記事で紹介した探し方で100を超えるような数のイシューがみつかってしまい、どれから手を付けていいのかわからない…という場合もよくあります。そんなときにドキュメント修正のイシューから始めてみては?という提案です。

TL;DR

  • ドキュメント修正のイシューは比較的手を付けやすいものが多い
  • ドキュメント修正のイシューでもちゃんと知識は身につく
  • 普段ドキュメントを修正しつつ、できそうなコードの変更があればそれをやればいい

それではいってみましょう。

ドキュメント修正のイシューは比較的手を付けやすいものが多い

私はakkaというOSSに2年ほど貢献しています。自分があげたPull Requestはこの記事を書いている時点92、マ-ジされたものは86でそのうちドキュメント修正のイシューが70あります。

70 / 86 = 81%

つまり私の過去のakkaに対する貢献は8割以上ドキュメントの修正です。

「なんじゃこいつ、コードじゃなくてドキュメントばっかりやってる素人じゃねえか」と思う方もいるでしょうが、まさにその通りです。そんな私でも90近いコミット数を稼ぐことができました。僕自身はコミット数自体を伸ばしたいと思っていて、それを点数を稼ぐゲームのように捉えているので、ドキュメントであれ何であれ簡単なイシューでコミット数を稼げるのはありがたいことです。

そうやってせっせとドキュメントの修正をしていたら、なんと2017年6月、akka 2.5.3のリリース時に紹介してもらいました

f:id:richard-imaoka:20180217132247p:plain

実はこの2.5.3リリースの前にボーナスチャンスがあって、簡単なドキュメント修正を大量のファイルに対して行うことで30コミット近く稼ぐことができました。 github.com

簡単な作業しかしてないのですが、それでもこうやって言及してもらえると嬉しいものです。

ドキュメント修正のイシューでもちゃんと知識は身につく

ドキュメント修正のイシューをこなしていても、ちゃんと対象のOSSに対する知識は身についていきます。ドキュメントの修正とはいえ、当該範囲の知識なしにできる物は少ないのです。

よくあるイシューとして「新機能を足した、しかしドキュメントが更新されてない、新機能の説明を足すべき」「このドキュメントのこの部分が実際のコードの動作と違う、修正すべき」といった例があります。どちらも「新機能自体を理解する」「実際のコードの動作を検証する」という作業をしないと正しくドキュメントを書くことができないことはわかると思います。

私が取り組んだ実際のPull Requestだとこれがよい例ですね。サンプルコードを追加しましょうというイシューでしたが、サンプルコードを書いて走らせて、動作確認して、と何度か繰り返した後Pull Requestをあげることができました。サンプルコードが思った通りの動作をしてくれなくて試行錯誤した記憶があります。それが逆にakkaの内部を理解することにつながりました。

github.com

次のこのPull Requestは別の場所(akka-http)にあったドキュメントの一部をほぼコピーだけするような作業で終わるはずだったイシューでしたが、最終的には文章に多少のアレンジを加える必要がありましたし、もちろんサンプルコードの動作確認もおこないました。おかげでakkaのthread周りについて詳しくなるきっかけを掴むことができました。

github.com

つまり、ドキュメントの修正であっても自分でコードを書いて対象のOSSを動かす作業が必要な場合が多いので、続けていけば知識を身につけることができます。

普段ドキュメントを修正しつつ、できそうなコードの変更があればそれをやればいい

そして、ドキュメントの修正をやるからといって、それだけをやる必要はないわけです。コードの変更も、どちらもやればいいのです。

ドキュメント修正のイシューの方が簡単なことが多いので、普段そちらをやってOSSコントリビューションのペースを保ちつつ、時間がたくさん取れるときや自分が得意そうな範囲のコードの変更があればそれも行いましょう。たとえ「メソッドにパラメタを一つ足す」「細かいバクの対応」といったレベルでも、自分のコードの変更がOSSに取り込まれると嬉しいものです。

OSSコントリビュートしたい方には朗報!

さて、最後に宣伝ですが、私もScalaMatsuri 2018スタッフとしてお手伝いしている以下のイベントがあります。 OSSコントリビュータとしてロケットスタートを切るには絶好の機会です。akkatwitter4ssbtaeronScalikeJDBCという有名OSSからメインの凄腕メンテナさん達が参加・指導してくれます。協力してくれるメンテナさんたちは「メンテナチームの一員」といったレベルではなく、それぞれのOSSプロダクトの創始者もしくはここ数年でコミット数1、2位の、本当に各プロダクトを代表するメンテナさんたちです。

さあ、あなたもOSS貢献の一歩を踏み出してみませんか?

jsa.connpass.com

それから例によって、僕に何かお手伝いできることがあればtwitterでなんでも聞いてくださいScala関連のOSSについて、OSS貢献したいけど英語で困っている、もうちょっと細かいイシューの探し方について聞きたい、akkaに関すること、できないことはできませんが、できることならみなさんのOSS活動をお手伝いしますよ。