はじめに
こんにちは。スタメンでエンジニアをしております、mental-space1532と申します！今回は、昨年10月に配属されてからエンジニア3ヶ月でOSSに貢献した経験についてお伝えできればと思います。
早速ですが、私は元々プロダクト職ではありませんでした。現在新卒2年目ですが、当初はビジネス職として入社し、1年半ほどインサイドセールスとして勤務しておりました。要はエンジニアとしてはスタートラインに立ったばかりの人間です（大学も文系です！）。似た境遇の方々や、OSSへの貢献を検討されている方の参考になれば幸いです。
1. 何をやったのか
内容としては、半角@が入力された場合のみ表示されていたメンション候補を、全角＠入力でも表示されるように改善しました。一般に、チャットアプリでは@を入力するとメンションの候補が表示されます。しかし、日本語IME環境では全角＠がデフォルトで入力されることが多く、日本語ユーザーはメンションの度にいちいち入力方式を切り替えることを強いられていました。これを切り替えることなしに実行できるようにするというのが今回のPRの趣旨です。
ちなみに、技術スタックとしてはReact/TypeScriptですので、これを踏まえた上で以降を読んでいただけると幸いです！
2. 動機
ビジネス職時代、こちらのOSSチャットを使っていた際に、毎回入力切り替えを行わなければならず、「めんどくさいなこれ」と思ったことがきっかけです。
ビジネス職の経験がある方なら共感いただけるかと思いますが、セールスやカスタマーサクセスの現場では「お客様への即応性」が何よりも重要です。結果としてメンバー間での情報共有スピードが求められ、伝達漏れを防ぐためにメンションを多用します。個人的な体感ですが、ビジネス職のメンション使用頻度はプロダクト職の5〜10倍ほど多いように感じられます。
特に顕著な例では、毎朝の進捗共有で6〜7名のメンバーにメンションを飛ばす際、毎回「半角切り替え→@入力→日本語切り替え→名前入力」を繰り返す必要がありました。これが地味にストレスだったのです。
当時の私は不便さを「仕様だから」と受け入れていました。エンジニアにチャレンジすることになった10月初週に「どうせやるなら本家のOSSに還元して、世界中のユーザーの体験を改善しよう！」と思い立ち、上司に相談し、社内の業務を行いつつ、AIを活用したコーディングで進めるという条件でOKをもらうことができました。
3. やったこと
初めてOSSにコントリビューションする上で、以下のようなフローで進める想定でした。
- 課題を言語化する（企画）
- GitHub CopilotのCoding Agentで自律的に実装させる（実装）
- 正しく動作するかローカルで検証しつつ変更箇所のコードを解読する（QAその1）
- 社内でレビューをいただく（QAその2）
- OSSのリポジトリでPRを作成し、メンテナーの方にレビューを依頼する（メンテナーレビュー）
- いただいたレビューを受けて対応し、マージ（貢献完了）
- 自社プロダクトへの適用（統合）
企画（やりたいことの言語化）〜初期実装
当初、そもそもPRってどうやって作るんだ・・・？というレベルだったので、手っ取り早くGithub CopilotのCoding Agentで200文字程度のプロンプトを投げて自律的に実装してもらう方法を取りました。そのプロンプトがこちらになります。
現在の仕様において、メンション付きのメッセージを送るためには半角のアットマーク（以下@）を入力し、自分でメンションしたいユーザーの名前を入力するか、表示される候補の中から選択する形になっている。 この状態を、@だけではなく、＠でもできるようにしたい。すなわち、メッセージの編集欄に＠を入力した際にもメンション候補が表示されるような状態に変更をしたい。
今見るとかなりシンプルなプロンプトですね・・・🙃 どのような仕様にするか記述していないので、Copilot先生も困ってしまったのではないかと思います。できたものをローカルで検証したところ早速問題が発生しました。全角＠でメンション候補は出て挿入できるものの、2個目以降のメンション挿入ができない（メンション候補をクリックまではできる）のです。AI（CopilotのAgent Mode）に聞きつつコードをいじっても解決せず、詰まってしまいました。後から考えれば、この時の自分は構文を理解しようとせずに、漫然とAIに「これどうすればいいのですか？」という曖昧な形でプロンプトを投げてしまっていました。流石にこれはまずい、ということになって同僚に助言を求めたところ、半角と全角の文字の幅の違いによって挿入ができなくなっていることが判明し、フロント側の文字列挿入ロジックを修正することで「実装したい機能がとりあえず動く」という状態に持っていくことができました。
社内レビュー
この段階で一度社内レビュー実施していただきました。この時、自分は「ちゃんと動くようになったし、これでOSSにPRを作成できる」と無邪気に考えていました。が、当然そんなうまくいくわけもなく、まだまだ問題が山積みになっていることが明らかになりました。具体的には、私がWebアプリの基本的な構造（責務の分離）を理解できておらず、Copilotが行ったバックエンドAPIの改変（バックエンドAPI側のメンションロジックに全角＠を追加する修正）を見逃してしまっていたのです。結論としては、そもそもフロント側で半角@と全角＠を共に正規表現としていたので、この改変は必要ないものでした。この社内レビューによって、フロントエンドとバックエンドAPIの責務の分離、個々のファイルがどのような仕事を担当しているのかをざっくりと理解することができました。
というわけでバックエンドの修正を元に戻してフロントエンドの修正するべき箇所をある程度理解した上で再度コードを吟味することになりました。ある程度当たりをつけた上で、バックエンドAPIの件のような不必要な改変がないかを確認しました。
社内レビューを経たことでより具体的に各コードについてAIに聞くことができるようになり、結果的によりシンプルに実装する方法を編み出すことができました。これらの工程を踏まえて最初に社内レビューをいただいたときよりもさらにコードの質を高めることができました。ここで再度社内レビューをいただき、OKをもらうことができたので、晴れてOSS本家のリポジトリでのPRを作成にトライしました！
OSS本家でのPR作成〜マージ
PRの説明文の書き方なども何も分かっていなかったのですが、幸いにも規定のフォーマットが存在したので、AIに自分の拙い英文を校正してもらいながら何とかメンテナーの方からレビューをいただける状態にしました。そして、ついにコメントが返ってきました！曰く、「その共通コンポーネントの変更、本当に必要？」とのことで、共通UIはコマンド入力などにも使われるため、そこにメンション特有のロジックを入れるのは設計として美しくないし、影響範囲が広すぎるという指摘でした。
そこでメンテナーの方から「UI側をいじるのではなく、データを供給する側が情報を正しく伝えれば良い」というヒントをいただき、最終的に以下の修正に落ち着きました。
- 正規表現を修正し、
@と＠の両方をキャプチャできるようにする - 関数に実際にマッチした文字列（
matchedPretext）を渡すよう引数を追加する
このことにより、さらにシンプルに同じ機能を実装することができました。
また、海外のプロジェクトであるためPRを英語で書く苦労もありましたが、Geminiに添削してもらうことで乗り切ることができました。一見無理難題に思えることも、分解して各個撃破すれば意外といけるものです。まさに「困難は分割せよ」を実感した瞬間でした！
4. 元ビジネス職という点からプロダクトに貢献できること
弊社のようなSaaS企業ではドッグフーディング（自社製品を自ら使うこと）が推奨されますが、作り手側は「使い慣れている」がゆえに、ユーザーの多様な使い方を見落とすことがあります。
特に、職種によって機能の使用頻度やコンテキストは大きく異なります。元ビジネス職のエンジニアは、
- プロダクト職とは異なる、現場ならではの切実な使い方を知っている
- お客様に近い立場からこぼれる「小さな不満」を拾いやすい
という2点において、UX向上に大きく寄与できるアドバンテージがあると感じています。
5. まとめ
ここまで書いてきましたが、伝えたいことはシンプルです！
- 一見理解不能なエラーも、試行錯誤を繰り返せば必ず糸口が見える。まずはやってみよう！
- 「元ビジネス職」という視点は、エンジニアリングにおいて強力な武器になる
このエントリが、OSSへのコントリビューションを迷っている方の背中を押すきっかけになれば幸いです。
最後に
株式会社スタメンではエンジニアを絶賛募集しております！弊社には、AI活用・新人から様々なことにチャレンジできる文化が整っています。もし興味を持っていただけるなら、ぜひ一度カジュアルにお話しいたしましょう！
最後まで読んでいただきまして、誠にありがとうございました！！！
