OSS開発に参加する人を継続的に増やしていくプロジェクトOSS Gateをやっている須藤です。2026-02-13（金）にOSS Gateワークショップを東京でオフライン開催しました！会場はオプティムさんが提供してくれました！懇親会ではオプティムさんが作っているスマート米を無料で提供してもらいました。カレーライスにして食べました。おいしかったです！お米がおいしすぎてカレーの方が余ってしまいました。
参加者数：22人！
新型コロナウィルス以降、OSS Gateワークショップは主にオンラインで開催していたのですが、約1年ぶりにオフラインで開催することになりました。せっかくオフラインで開催するならできるだけ多くの人と一緒にやりたいと思って今回はいつもよりも告知をがんばりました。その結果、いつもは多くても10人くらいだったのに今回は22人も参加してくれました。
しかも、参加登録者のうち欠席した人は1人だけでした。これまでになんどもイベントを開催してきましたが、こんなに欠席率が低いことは非常に稀です。数割の人が（連絡なく）欠席することばかりだったので非常に驚いています。もしかしたら、平日の日中に開催したからかもしれません。欠席が多いイベントは平日の夜や休日のイベントでした。
イベント開催前は「平日日中で集まる？大丈夫？」という懸念もあったのですが、会場提供のオプティムさんが社内でたくさん参加者を募ってくれたり、いろいろな人に告知を手伝ってもらったりしたら20人超の参加者になりました。
1/3くらいがオプティムの方でした。会場提供してくれたオプティムさんには優先的に参加してもらいたくて最初の方は告知先を絞っていました。ある程度オプティムさんからの参加者が出揃った段階で、個別に声をかけて告知を手伝ってもらいました。手伝ってくれたみなさんありがとうございます！
また、@yasulabさんにはRailsガイドのコミュニティ支援の一環としてRailsガイド内で告知してもらいました。Railsガイドに協賛すると同じようにRailsガイド内で告知できるので、Railsユーザーにリーチしたい人は検討してみてください。
さらに、ワークショップの様子も撮影してもらいました。実は、OSS GateのYouTubeチャンネルがあって、9年前にクラウドワークスさんに会場提供してもらったときのOSS Gateワークショップの動画もアップロードしてあります。これも@yasulabさんが撮影・編集してくれたものです。が、9年も前のものなので最新バージョンに更新しようということで今回の様子を撮影してくれました。このために新しいコンテンツを追加したのですが、それはもうあとの方で紹介します。
他にはDoorkeeperで1500人弱いるOSS Gateコミュニティのみんなに週に1回くらいのペースで数回連絡したり、Xで週に1回くらいのペースでポストしたり、プレスリリースを出してみたりしました。
私は告知が苦手なのですが、がんばれば20人くらいは集められそうということがわかったのが今回の収穫の1つでした。
今回のチャレンジ
OSS Gateワークショップは「OSS開発のはじめの一歩」用に設計していて、結構うまいこと実現できていると思っていますが、その後の二歩目・三歩目につなげられていないことが課題だと思っています。その課題に対して、OSS Gateワークショップが終わってからもなんらかのつながりを持てていれば二歩目・三歩目もサポートしていけるのではないかという解決案がありました。ということで、それを試すために参加者にOSS Gateのチャットに参加してもらおうとしました。
いつものアイスブレイクの時間をチャットのオンボーディングの時間にしてみたのですが、思った以上にうまくいきませんでした。新しくユーザー登録するところから始めたのですが、ユーザー登録直後の状態が私が思っていた状態とかなり違ってOSS Gateのチャットまで全然たどり着けませんでした。。。
次回はもう少しうまくやりたいですが、自分はすでにユーザー登録していて新規ユーザー作成直後の状態を確認できないんですよねぇ。。。どうしよう。
次回のチャレンジ
OSS Gateワークショップにはふりかえりの時間が組み込まれていて、その中で今回のワークショップで得られた知見を次回のワークショップにどう活かそうかという話もしています。ふりかえりではアンケート結果をもとにみんなで話をしています。
忘れないように、次回のチャレンジ案をここに記録しておきます。
- 今回はタイムキーピングが雑だったので、あと何分で今の作業を終わりにするよーとかを忘れずにアナウンスする
- はじめの一歩向けのワークショップだけではなく、中級レベルのなにかもあるといいかも
- このワークショップの枠組みじゃなくて、それとは別のなにかとしてのチャレンジ
- 他のグループがなにをしていたかを知れる機会を作れないか
- ワークショップ中になにかじゃなくて、後日、チャットで紹介とかできないかしら
- 対象のOSSを決める時間が無駄じゃないと思ってもらえるなにか
- よく、対象のOSSを指定したほうがいいかも？という話があるのですが、対象のOSSを決める時間は、自分が使っているOSSをふりかえる時間にもなっていいと思っているので、無駄な時間じゃないと思える仕掛けを作りたいなぁ
- 作業時間を増やす
- ワークショップの時間は限られていて、説明を短くするとかで早く進めちゃうと置いていかれちゃう人もでがちなので、ワークショップ後にも自然と継続できる仕組みがいいのかも
新規コンテンツ：生成AIとOSS開発
久しぶりのオフライン開催ということもあり、なにか最近のOSS開発に関する話も入れたいなぁと思って生成AIとOSS開発の話を入れました。
こうすれば生成AIを活用してバリバリOSS開発できる！という話ではなく、生成AIは便利だけどOSS開発ではこんな使い方はやめてねという話になっています。
まだまだ生成AIの変化は激しく、今のよいやり方が数ヶ月先でもよいやり方のままなのかはわかりません。なので、一時的な今のよいやり方を伝えてもあまり活用できないはずです。それよりは、だいぶ見えてきているこれはやめてねということを伝えた方が長く活用できそうだと思ってこんな話にしました。
ざっくりとまとめるとこんな感じです。
- 生成AIが生成したバグレポート・機能リクエスト・プルリクエストは、開発元にフィードバックする前に自分でレビューして理解しよう
- 生成AIが生成した成果物は冗長なことが多いから、不要なものは削除して開発元の負荷を上げないようにしよう
- 生成AIが生成した成果物には複数の話題が含まれてしまっていることがあるから、個別の話題に分割して、開発元の負荷を上げないようにしよう
- 開発元からのコメントやレビューを生成AIに丸投げして返事をするんじゃなくて自分が理解してやりとりしよう
- 開発元はコメントやレビューでは知識の共有をして新しい仲間を増やしたいと思っている（ことが多い）
- 丸投げするとあなたとは知識は共有されないのであなたとやりとりする意義がほぼなくなってしまう。開発元が直接生成AIとやりとりしたほうがよいのでは？という状況になりがち。
- 生成AIが生成した成果物がライセンス違反をしていないことを保証することは報告者の責任
- 開発元はライセンス違反しているかもしれないプルリクエストはマージできない
- 報告者は生成AIを使ったことを開示する
- 開発元が適切に対応できる
- なにかあったときに調べやすくするために、どの生成AIを使ったかをGitの
Generated-By:トレーラーで記録するとか
最近、Apache Arrowの開発でも生成AIを使ったコントリビューションに関する議論とかがあったので、そこらへんの話とか、私が開発元として感じていることとかをまとめたものです。他にもいろいろな考え方はあるはずですが、OSS開発への始めの一歩を踏み出す人たちにはこのくらいのことは伝えておいてもいいんじゃないかと思ってまとめました。
次回のオフライン開催の予定
まだ調整中で決まっていないのですが、8月くらいにできるといいなぁという感じで調整はしています。今回参加できなかった人は楽しみに待っていてください！調整ができたらこのブログとかOSS Gateのチャットなどでアナウンスするのでウォッチしていてください。
