iCARE初のOSS公開までに立ちはだかった壁
こんにちは、iCAREサーバーサイドエンジニアの寺井(@krpk1900_dev)です。
先月Twitter GJ Carelyをリリースしましたが、期待通りに動作しなかったためリリースから数時間でサービスを停止させることになりました。
https://dev.icare.jpn.com/dev_cat/twitter_gj_carely/
その後多くのメンバーからいただいた指摘をもとにこの一ヶ月で修正を行い、今日改めてTwitter GJ Carelyを再リリースしました。
それだけでなく、以前は十分とは言えなかったコードレビュー、テスト、脆弱性診断まで実施し、iCAREからは初となるOSSのサービスとしてTwitter GJ Carelyのコードを公開しました。
https://github.com/icare-jp/twitter_gj_carely
途中で心が折れそうになることもありましたが、この一ヶ月間本当にたくさんのことを学ぶことができました。
今回は、私たちがこの一ヶ月間で向き合うことになった壁について記録に残したいと思います。
一ヶ月前にリリースしたときの状況
iCAREではこれまでDockerfileやNode.jsのパッケージについてはソースコードを公開する例がありましたが、今から数年前の特定の人による取り組みだったため、OSS化の取り組みに関するルールは存在しませんでした。
一ヶ月前、私はTwitter GJ Carelyがローカル環境で問題なく動作することを一人で確認し、一緒に働いている先輩のエンジニアに「問題なければ発表したいと思います」と言って返信をもらわないままリリースしました。
そのときはソースコードを公開する予定もなく、仮に何か不具合が発生してしまっても、いつもやっている個人開発と同じように逐次修正することで良いものにしていけば良いと考えていました。
しかし、リリースして実際に多くの人に使ってもらった結果、ローカル環境では発生しなかった不具合が発生してしまい、リリース後数時間のうちにサービスを停止させることになりました。
このときはまだ、「世に出さないと分からなかったんだし修正してまた出そう」くらいにしか考えていませんでした。
サービスを停止してから起きた議論
サービス停止の後、この話をここでは終わらせずに私のチームリーダーはiCAREのDevチーム全体に対して指摘を投げかけてくれました。
その内容は簡単にまとめると以下のような指摘でした。
- リリースしたサービスにはCarelyの名が付いておりiCAREとして出したサービスなのだから、すぐに落ちたりしたらiCAREのブランドや信頼の低下に繋がるため、安心して使ってもらえるアプリケーションである必要がある
- コードが非公開でもサービスの脆弱性をつかれて攻撃されてしまったら会社に影響がある
- なので本番サービスであるCarelyの開発と同等レベルの、コードレビュー、テスト、脆弱性診断のフローを通してから慎重にリリースすべき
それに対して、反対の立場の意見も出ました。
- ルールを厳しくすると個人開発やOSS化のハードルが上がってしまって、そもそも挑戦しようという風潮が起きない
- 何も出さないよりもリリースして不具合が起きるほうが何倍も良い
- まずは手を動かして作って、それからみんなで良いものにしていけば良いのではないか
議論は白熱して一日では結論が出ず、テキストからビデオ通話に移して別途ミーティングが設定されました。
その結果、「初期のスタートアップの勢いを忘れないようにしつつも、ブランドや信頼などにも注意を払っていかないといけない時期に入っているので、コードレビュー、テスト、脆弱性診断のフローをしっかりと踏んでからリリースする」ことに決まりました。
私が落ち込んだ理由
正直に話すと、私はこの時期かなりメンタルにきていました。
不具合を生んでしまったことに対して、ではありません。
私は個人開発者でもあるので、不具合をユーザーのみなさんから指摘してもらって修正することには慣れています。
どんなに気をつけても世に出す前に100%完璧にできないことはすでにたくさん学びました。
そうではなく、Twitter GJ Carelyは会社の雰囲気をより良くしたいという思いで作ったサービスだったのに、一時とはいえ逆の結果に繋がってしまいました。
自分が時間をかけて書いたコードは、人を楽しませたり課題を解決して感謝されることに繋がっているとこれまでは疑ったことがありませんでしたが、常にそうであるわけではないと考えるようになりました。
Twitter GJ Carelyを通して得られたこと
つらく感じることもありましたが、Twitter GJ Carelyを通して今まで経験したことのないたくさんのことを学ぶことができました。
先ほど述べたように、自分の書いたコードが人の役に立つまでの過程をより意識するようになりました。
これはおそらくもうすでに、今のプロジェクトの要件定義で一ヶ月前の自分とは明らかに違いが出ていると思います。
多分この壁は、 個人開発でサービスを作っている私にとってはいつか経験することになる壁だったはずです。
ユーザーがみんな知り合いで、お金をいただいているわけでもなく謝ったら許してくれる、規模も数十人だった今、この壁に遭遇できたことは幸運だったと思います。
会社としても前に進めたことがたくさんありました。
リーダー陣だけではなくDevのいろんな人が自分の考えを表明したこと、いずれは必要だった議論を生み出すきっかけになったこと、みんなで話し合った結果最後にはまとまって納得のいく一つの結論を出せたこと、OSS開発に関するルールを新しく作ることができたこと、OSS活動や個人開発を会社として支援する仕組みを作ろうという新しい動きが生まれたこと、きっとまだまだたくさんあります。
実は最初に指摘をしてくれた私のチームリーダーが、「寺井くんが今度の日曜日暇だったら、オフィスに来て手伝うから2人で一緒に直るまでやろうぜ」と声をかけてくれました。
私の知っているチームリーダーはOSSやGJ Carelyに対して特に強い関心があるわけではなく、むしろ休日はゆっくり休むことを好まれるイメージでしたが、この言葉にはいろんな思いが込められているように感じました。
他に誰もいないオフィスで音楽を流しながら心の赴くままに試行錯誤したあの一日は、私にとって本当に嬉しくて楽しくて思い出に残る一日になりました。
終わりに
今度のTwitter GJ CarelyはiCAREとして胸を張って外に出せるサービスです。
よろしければぜひ使ってみてほしいです！
そして、いずれはTwitter GJ CarelyだけではなくGJ Carelyも世界中の人が使えるOSSにしたいと思っています。
2022年6月25日(土)、15:00から15:45と長めですが、GJ CarelyとTwitter GJ CarelyのOSS活動についてOSC2022 Hokkaidoに登壇して発表する予定です。
YouTubeでも無料で視聴可能なので、ご興味がある方はぜひのぞいてみてください！
https://event.ospn.jp/osc2022-online-do/session/585529
追記
個人的な感想ですが、会社を背負ったOSS活動と比べると私がいつもやっている個人開発は気が楽です。
守らないといけない期限もないし、不具合があっても傷つくブランドや信頼の範囲は自分のみに限られています。
何かあったときの責任の大きさが全く違います。
でも、今回は私にとってもiCAREにとっても初めての挑戦だったので結果的に少し痛い目を見ることになってしまいましたが、私はこれからも必ずiCAREの名を背負った個人開発に挑戦し続けます。
そして今回、失敗も含めた私の行動を尊重した上で熱い議論や思いやりのある指摘をしてくれた一緒に働いているDevチームのみなさんには本当に感謝しています。
一緒に働けていることがとても誇らしく思います。
