目次
■キャリアとスキルアップ
2022.06.13 2023.12.14 約6分
Forkwell が主催する技術イベント「Front-End Lounge」。2020.11.10開催のテーマは「フロントエンドでOSSに寄り添って生きていく」です。Wachiさんがこれまで話してこなかったOSSへの取り組み方やコツを特別に発表いただきました。
重要なポイントは
この2つだと語ります。
また実際にWachiさんが取り組んだ「コミッターの信頼を得る2つの事例」も紹介。
「どんな小さな改善でもインパクトは大きい、Node.jsを1ms早くすると世界が2.7年早くなる」と語るWachiさん。後半では、OSS開発にモチベーションが生まれた秘密をQA形式で紹介します。
フロントエンド関連の OSS を見ていると、よく ”コミュニティ” と呼ばれる人の集まりによって開発がおこなわれていることが観測されます。 そこでは、通常のプロダクト開発と同様に、日々メンバー間でコミュニケーションを取りながらソフトウェアの改善がおこなわれています。
今回は私がどのようにコミュニティを捉え、どのような意思判断を重ねて Node.js や npm の新機能開発をおこなってきたかについてお話します。シニアなフロントエンドエンジニアな方々にとって、日々の開発や今後の学習領域の選択に役に立つような会になれば幸いです。
Wachi と申します。最近は、OSS だと Node.js の WPT（ウェブプラットフォームテスト）のメンテナンスをしたり、net の bug fix を入れたりしています。また AWS で Amplify の改善もしています。
今回は「OSS開発における合意形成に JavaScript で参加し、変化を起こす」というちょっと堅苦しいタイトルですが、内容は今まであまり外に話してこなかった「OSSに趣味や仕事としてどう取り組んできたか？」です。
結構自分のバイアスがかかっているので発表に不安がありましたが、今回はpotato4dさんにお声かけいただいたので頑張って話してみます。
変化を自らの手で起こすために重要なのが、Upstreamに参加することだと考えています。Upstreamに参加すると本家から枝分かれするのを避けることができ、OSSへの貢献にもなります。こちらはOSSにおけるリリースまでの一連の流れを図にしたものです。
1番左は提案をおこなう場所です（Proposal）。最初は「イシューでこんな機能が欲しい」という一言から、実際に PR に至るまでの入口としてイシューが使われることもあります。
提案が出たうえで、具体的にどう実装すれば例外を防いだ状態で安全にリリースできるかなどを考える仕様策定のフェーズ（Clarify）があると思います。
昔はそのフェーズで議論や共感が生まれた瞬間に、+1とコメントがついていましたが、最近では絵文字リアクションでいいねがつくことで、イシューがどれくらい需要があるのかを可視化できるようになりました。実際にいいねの数でソートをかけて、人が求めている提案は何かを見るのによく使われるものだと思います（Prioritization）。
イシューを解決することで多くの人がハッピーになるときに PR を作るフェーズが出て（Code）、マージされたあとにリリース作業が発生する流れでしょう（Delivery）。
OSS開発の流れのなかでは大きく分けて3つの登場人物がいると思います。
1. 利用者（User）
提案や仕様策定、投票のフェーズで活発にコメントを書き、いいねを押す活動がリポジトリのなかではメインだと考えています。
2. コントリビューター（Contributor）
ブログで使ってみた記事を書くのもコントリビューションの1つだとは思います。提案、仕様策定、投票のみならず、 PR の作成もおこなうのがユーザーとの差分だと考えています。
3. コミッター（Committer）
マージ権限がある Write Permission を持ち、いろいろな PR があるなかで、最も今マージすべき PR が何かを考えてマージ作業をおこないます。
このように3つの登場人物が少し異なるスコープで活動しています。Upstream では、最初の提案から入ってくると End to End でより大きなことを達成できると考えています。
実際にマージ作業をおこなうコミッターの人たちが何を考えているかを理解することが重要だと思います。私も新しい OSS にコントリビューションするとき、まずコミッターへの理解を深める活動をしています。
コミッターがどのような人かわかったら、次はBのコミッターに対して信用を得るために実績を積み重ねるフェーズが発生すると思います。私は小さい PR を少しずつ積み重ねるところを入り口に、Prioritization に参加したり、仕様策定のディスカッションに参加して徐々に提案フェーズに近づいていく動きをよくしています。
全体の流れがある程度見えたうえで、Cの提案に到達すると、一発で通るような提案が書きやすくなるでしょう。
新しい OSS にコントリビューションしようと思った際に何を見ているかを上記画像をベースに話します。
これは、Node.js のリポジトリです。まず自分が利用者としてリポジトリに来たうえで、誰が開発しているのか気になることがあります。
開発者はコミットログを見れば、誰が開発しているかがなんとなく見えます。コミッター・コントリビューターによって開発されていることがわかり、コミッターが最終的なマージをおこなっていることがわかります。
スクリーンショット上だと左上の Node.js のオーガニゼーションを指しています。ここでコミッターの所属している組織が目指すものが何かを考えます。
例えば会社は売上を増やすか、コストを減らすかに関心があるように、OSS におけるオーガニゼーションも同様にコスト減、インパクト増に関心があると思います。
この文脈におけるコスト減は Node.js の開発者が求めているものの素早い提供です。
例えば開発速度を向上させるものや、 CI で Jenkins を使っているので、そこのサーバー費を削減するためにビルドの時間を少し減らすなどです。
インパクト増、OSS の利用者が求めているものの提供は、例えばいいねの数が多いイシューレポート、フィーチャーリクエストの実現などがコストパフォーマンス高くインパクト増が見込めるでしょう。
コミッターの気持ちがわかったら次に重要なのは、コミッターの信頼を獲得することだと考えています。
上記の図はハードスキルを通じた「信頼と維持のフレームワーク」です。このチャートでは「能力を使った実績を積み重ねましょう」と書いてあります。
例えば、保有した資格（Competencies）でおこなえる業務を使って何か価値を追加したり、スキル・知識（Skills & Knowledge）の分野で日本語の翻訳をおこなうのも、コントリビューションです。
他にも経験をベースにして（Expertise）、他のリポジトリでしていたことを共有する人や、ベストプラクティスを紹介する人は、コミッターから信用されます。
上記の図ではハードスキルにフォーカスしていますが、最近だとソフトスキルも重要です。誠実さや穏やかさ、倫理感、思いやり、周りの人のモチベーションをあげる振る舞いなどが該当するでしょう。
例えば、PR のレビューで優しい書き方をすると「この人いい人だな」と思ってもらうことができます。
コミッターの信頼を得るためにおこなってきた事例を2つ紹介します。
2016年からの自分のコミットを漁って、自分が何をしてきたかをまとめました。
まず小さい実績を積み重ねる部分で、fix typo in documentation をやっていました。fix typo で英語のスペルミスを直すだけの作業です。作業をしているなかで PR がどうマージされるかが少しずつわかったので、少し広げてテストの改善をしていきました。
https://coverage.nodejs.org/ の Web サイトで今テストされていない”行”がどこにあるかがわかるため、その”行”をテストする形に追加することを繰り返し、そこで自分の興味がどこにあるかがわかってきました。
その後、WHATWG（ワットワーキンググループ）が定義している URL Parser の部分でテスト改善するとバグがあることに気付いて、bug Fix などをしました。
この過程で「ECMA402のIntlのほうで Spec にこんなことあったらいいのでは」と提案やマージなどを持っていきました。経験を通じて 、少しずつ自分なりに仕様の中に存在するエッジケースを見つけられる成功体験を得られました。
URL も仕様を見ていくと、未実装パースの部分があったため、そちらにコミットしていく内に、Feature Update のタイミングでコミッターに推薦され、なりました。
このフェーズを繰り返すと、仕様でブレイキングチェンジ(破壊的変更)が発生します。他のチームでこのブレイキングチェンジを避けたいという反対意見がありましたが、一貫して Web との互換性を高めたいということで、Node.js でもこのアップデートを入れないと追随できなくなると議論を交わしたうえで、URL も新しいブレイキングチェンジを入れることができました。
以上が、インパクトを増やすことを起点にした取り組みでした。
次は、 OSS開発者のトラブルシューティングを充実させることで、イシューへの対応を減らす、コスト減を意識した取り組みです。
npm には割とカジュアルに PR を最初から投げていたので、今までの流れとは少し”ずれ”がありますが、例えば最初のコントリビューションのフェーズで、run script の改善で npm run enter とやったときに run が必要なスクリプト一覧と不要なスクリプトを分けて表示しようという Feature update から、カジュアルに機能提案・実装をしていきました。短期間でコミット数を積み重ねることができ、コミッターの人に認知されました。これがEarn trust のフェーズです。
コミッターは私が日本人であることを認識して日本語を使用し、さらに当時流おこなっていた「ねこあつめ」の写真もイシューに貼ってくれました。このときは本当に信頼を獲得し、認めてもらえたことを実感しました。このようにコミッターの人と仲良くなるフェーズが重要だと認識しています。
そこから機能提案に入っていきます。当時は npm のイシューが1000、2000とあり、3〜4人のコミッターでは捌けない状況でした。
イシューの多くには初歩的な課題がありました。例えば自分で変えたファイルパーミッションのせいでインストールできない、そもそもネットワークがオフラインだったなどです。
プロダクトそのもののイシューというよりは開発環境に起因するイシューだったため、その辺は開発者の方でセルフチェックして欲しいと CLIチームのなかで話になっていました。
ここに対して 「npm doctor というコマンドを作って自動でよくある開発環境に起因するイシューをチェックできるようにしませんか」というイシューをコントリビューターの人が出していました。その議論にダイブして具体的にこういう項目でチェックしませんか？と提案し、実際に POC を自分で作ったのが次の Proposal のスクリーンショットです。
最終的なゴールイメージを共有したうえで実際に PR を作り、今の npm にもある npm doctor が作られました。
当時の npm はサブコマンドが多くあり、新しいサブコマンドを追加することに消極的でしたが、コスト減になるので、明確に同意してもらいマージまでこぎつけられました。
OSS開発はプロダクト開発と差がないと思います。今のプロダクト開発の下のほうのブロックでは、スクラムのセレモニーを書いていますが、OSS開発とプロダクト開発で同じようなステップを開発しているため、OSS開発を特別扱いせずに普段の開発の延長と捉えて軽い気持ちで参加しても良いのではないでしょうか。
上記の図は私の author の npm package のダウンロード数ですが、大体1億以上ありました。CI なども含むので、必ず人とは限りませんが、どんな小さな改善だとしても1億以上の人に届けることが可能なため、たとえ fix typoであっても非常に重要な活動になると思います。
Node.js のダウンロード数は、大体14億以上ありました。自分のモチベーションをキープするのに、Node.js を1ms 早くするとそれだけで世界が2.7年早くなると考え、インパクトが大きいことの可視化を自らにも与えることで、小さな改善の積み重ねが重要だと思います。
Upstream をリードすることでインパクトを出せます。そのためにOSS すべての関係者の視点を持ってみませんか？ということをお伝えしたいです。
例えば UX の面だと、利用者視点で欲しいか？改善を考えることが必要だと思います。一方で、その提案が実現する可能性が本当にあるのかを見定め「1年かかるような実装では難しい」という形で小さいスコープに切って、テック面で T2M の最小化をおこないます。
コミッター視点でいろいろな提案があるので、プロダクトの価値を最大化する提案とは何かを考えて行動することで、一発で通る提案がより書きやすくなり、一発でマージできる PR を書けるようになると考えています。
Q&A
Daijiro Wachi：戦略を考えたり、ロジカルシンキングが好きなので、いつも課題を分解していただけです。利用者が多い OSS はインパクトが非常に大きいので、 OSS に少しコミットするだけで多くの人たちに直接影響を与えられます。その結果、モチベーションが育ったのだと思います。
potato4d：もともと論理的なものを組み立てることが好きだったところにきっかけが被さったのですね。OSS のコミッターに話を聞くと、目の前の課題を潰していたら、いつの間にかコミッターになっていたケースが多い気がします。その場合、再現しにくいと感じたので、戦略的に取り組む今回のお話は気になりました。
Daijiro Wachi：そうですね。一方で楽しいからやっているところもあります。やはりインパクトが大きいことがやりがいだと思います。
potato4d：ありがとうございます。PRをとりあえず出す、を超えて、より大きな成果を出すために、コミッターの意図を汲むことが書かれた貴重な発表でした。
potato4d：業務でのプロダクト開発と近いというお話がありましたが、OSS特有の面白さはありますか？
Daijiro Wachi：普通のビジネスをやっているとKPI や売上を追うと思いますが、OSS ではそこの数値に対して責任を持っている人があまり多くないと思います。
逆にアナリストみたいな形で数字ベースで分析し、それをベースに活動することがエンジニアだからこそできる部分だと思うので、そこが少しユニークな部分かもしれません。
potato4d：KPI を追い求めすぎないからこそ、KPI のために evil な実装をするケースがなく、健全性が保たれているのでしょうか？
Daijiro Wachi：KPI を追い求めて evil になるのは、おそらく KPI設計の問題だと思います。ビジネスで OSS をやっているところもあれば、Node.js などは財団のなかで動いています。参加者は雇われているわけではないので、同じ数字を追い求めなければならないなどトップダウンのコミュニケーションは難しいと思います。
そのため自分が追い求めている KPI や価値観を数値化したものに共感できる人たちを何人か見つけて、共同で作業をするおもしろさがあると思います。
大きいコミュニティのなかで、自分にとって快適な小さいコミュニティを作ることは、特別アサインされていない OSS の環境だからこそ発生していると思います。
potato4d：アサインされていないというのは大きな違いかもしれませんね。
Daijiro Wachi：数字ベースで OSS開発するという発言に対して、マーケティング文脈なのか、というご質問だと思うのですが、マーケティングの文脈ではないと思います。ビルドの速度や1つのファンクションの速度、コードの可読性が指標になる点はリアルなビジネスと少し違うところだと思います。数字の設計におけるベストプラクティスを考えてみるとおもしろいと思いますよ。
potato4d：考えた結果がそれぞれ異なるため、単純に取り組むだけでもおもしろいかもしれませんね。また取り組んでいる人が少ない分、有益な情報になりえる気がします。
Daijiro Wachi：npm doctor などはイシューの数が増え続けているのが課題でした。
potato4d：npm doctor で解決されるイシューの数が増えたということは、「doctor を実装することによって、これだけのイシューが捌けますよ」を効果的に伝えられている証拠ですね。
Daijiro Wachi：そういうロジックで提案する感じですね。
potato4d：ある程度コストセンターの考え方と近いかもしれませんが、コストだけを計上するものではないと思うので、かなり面白そうですね。
OSS に貢献しようとすると自分の考えた feature を載せたいと思う人が多いと思いますが、コスト削減も重要であり、取り組みやすいと思います。
Daijiro Wachi：コスト削減はすごくわかりやすいですね。コントリビューター向けの how to guide がレポジトリ内にあるケースは多いと思いますが、それを自分視点でわかったか否かをベースに改善するのは最初の人だからこそできると思います。
すでに長くやっている人はバイアスがかかってしまうので、なかなか取り組めない部分だと思います。そのため、新しくやる方だからこそできるエリアは必ずあると思います。
potato4d：別のイベントで OSS について話したとき、prettier の sosukeさんが「自分くらい prettier を触っていると、prettier のどこがわからないかが逆にわからない」と言っていたので必ず貢献できる余地はあると思います。
Daijiro Wachi：基調講演で説明した UX の部分はまさにそのエリアですね。利用者視点で何に困っているかの部分は言語化が難しいですが、周りにインタビューするなどして何とか言語化するのが大切だと考えています。そもそも、そういったことがないとイシューにすらあがらないので悩み続ける部分ですね。
potato4d：プロダクト開発と同じような悩みですね。
Daijiro Wachi：そうですね（笑）
Developer Relations Engineer(Web) AWSにてAmplifyをはじめとするWeb開発者が利用するサービスの改善をおこなうDeveloper Relations Engineer(Web)。OSS関連では、Node.js Core Collaborator、JSConf JP スタッフ、Amplify Japan User Group 運営などとして活動。PSM2, JSNAD, JSNSDなど保有。
