ユーザーが“次にやるべき事は何か”を管理しやすくする。それが企画のはじまり。

―まずは通知改善プロジェクトの背景にあった課題について教えてください。

竹下　プロジェクト以前はユーザーに対しての全ての通知が同じように配信され、重要度や緊急性がわかりにくい状況でした。ココナラは様々なサービスの複合体で、多くの機能を擁しています。一言に「取引」と言っても、自分のスキルに値段をつけて買ってもらうケースもあれば、見積もり交渉をするケースもあります。逆に仕事をできる人を募集して、提案してもらって取引が始まるケースもあるなど、購入者と出品者の出会い方ひとつをとっても多種多様です。

加えて取引が始まれば、仕事が完了するまで様々なやりとりが発生し、締切や重要なメッセージなど多くの通知を送ることになります。以前はそれらの通知を全て同じメッセージボックスに届けていたのですが、あまりに通知が多いと本当に重要な通知が埋もれてしまっていました。

結果、抜け漏れが増えたり、リマインド通知が意味をなさなくなるのです。ユーザーが次にやるべきこと、忘れちゃいけないことをシンプルに管理できるようにして、気持ちよくお取引していただきたいという想いのもと、通知改善プロジェクトが始まりました。

―最初は何から取り掛かったのでしょうか。

竹下　まずは理想の状態をディスカッションするところからスタートしました。通知にも「リマインド」や「提案・購入のお知らせ」など様々な種類があります。それらを全てジャンル分けして、それぞれどのようなタイミングでどのように通知されるのが理想的か話し合いました。
通知によっては不要になるタイミングがあり、自然に消えてもらえればユーザーにとっても使いやすいはずです。通知のジャンルごとに最適なあり方を話し合い、コンセプトを作ることからはじめました。

―エンジニアはどのタイミングでプロジェクトに参画したのでしょう。

竹下　私が入社したばかりのタイミングということもあり、開発の要件が決まっていない段階から相談させてもらっていました。エンジニアだけでなく、デザイナーなどにも相談させてもらっていました。

岡田　普段はプロジェクトの要件が決まってから参画することが多いです。どんなことをやりたいのかが決まってから、一緒に設計などを話し合っています。

―エンジニアとして、今回のプロジェクトを聞いた時の印象について教えて下さい。

岡田　通知のデータは大量にあるので、それを改修するとなると大変だと思いました。加えて、サービスを止めず、動き続けている中で理想の状態に近づけていくのは骨が折れそうだなと。。

これまでのキャリアでも、ここまで大規模なリニューアルを経験したことはありませんでした。データベースが4,000万レコードもあれば普通は触りたくないと思うところですが、なんとココナラは1億2,000万レコードもありましたから。。

勘舎　量の多さもさることながら、通知は登録、更新頻度が非常に高いデータであることがプロジェクトをより複雑にしていました。例えば、大量配信や都度既読に更新する処理があるのですが、その処理量をどうやって捌き切るか検討する必要がありました。それらを全てリニューアルすると考えると気が遠くなりましたね。

―エンジニアが参画してからは、どのようにプロジェクトが進行していったのか教えて下さい。

岡田　まずはエンジニアのプロジェクトメンバーを集めて、今のテーブルのレコードをどう分類できるかディスカッションしました。あまり細かく分類すると作業日数がのびるので、大きいテーブルを2つにわけて、パーティショニングという手法で分類していきました。

エンジニアもいくつかの部署に分かれているのですが、部署に関係なく協力してくれるので、いろんな人に意見を求めながら作業しました。

勘舎　ココナラは部署同士の距離が近いので、エンジニアだけでなく、様々な職種の人に相談しやすい雰囲気があります。会社によっては組織が階層構造になっていて、経営層で話した内容がメンバーにまで伝わらないこともありますが、ココナラではそんなことはありません。組織構造がフラットなだけでなく、フラットに経営陣とディスカッションできる機会もあります。

また、経営陣は新しい技術についても前向きに捉えてくれます。成果が目に見えにくい技術は経営陣から「それって意味あるの？」と言われる会社もあると聞きますが、エンジニアにとって大事なことであれば耳を傾けてくれます。いいプロダクトを作るという目的のためなら、何事も前向きに検討してくれますし、実際に意見を取り入れられることも多いです。

―竹下さんはココナラでの働く環境についてどう思いますか。

竹下　周りにとても相談しやすいです。
私は前職がゲーム会社で、裁量の大きな会社だったので、ココナラに入社する前は「プラットフォームの会社って、窮屈なんだろうな」と少なからず偏見を持っていました。入社前からフラットな組織と聞いていたとはいえ、疑う気持ちもありましたね。

しかし、実際に働いてみるといい意味で裏切られました。仕事で悩んでいると、違う部署の人にも気軽に相談できるので、コードが書けない自分にとってはすごく助かっています。「ちょっと気になる」くらいで相談しても嫌な顔をされませんし、「私だけじゃ難しいからあの人に相談しよう」となります。無理だと思っていたことも、相談していい方法が見つかったことも少なくありません。

―とても働きやすい環境だと思いますが、なぜそのような組織が実現できたのでしょうか。

勘舎　一つはミッションに共感した人だけが集まっているからだと思います。全員がミッションに向いているので、役職関係なく話せますし、意見があれば経営陣も耳を傾けてくれます。

もう一つはコミュニケーションがオープンなところですね。具体的に言うと、社内コミュニケーションはSlackを利用しているのですが、やりとりは常にみんなが入れるチャンネルで行なっています。誰かがディスカッションしていると、より詳しい人が入ってきてアドバイスしてくれるので、相談しやすい雰囲気が自然と醸成されています。

最後まで仕様が決まらない。複雑な通知シナリオ。

―実際にプロジェクトを進めてみて、大変だったことについて教えて下さい。

勘舎　技術負債との戦いです。通知は様々な機能に紐付いていますが、その機能のコードは創業当初に書かれたものもあります。そのため既にコードを知っている人がいないことも多く、一つずつ解読しなければいけませんでした。

―岡田さんはどうですか？

岡田　全体を見ながらプロジェクトを進めなければいけなかったところです。通知は一つの機能で完結するものではないので、全体の機能を俯瞰しながら調整しなければいけません。単体の機能のテストでも大変なのに、いろんなケースを想定しながら進めていくのは大変でした。

竹下　今回は通知を整理するだけでなく、機能の追加もしたので余計大変だったと思います。全部で130種類ほどの通知を制御する上に、一つずつのシナリオが複数あるのでとても複雑なプロジェクトになりました。
それぞれに通知を送る「発生トリガー」と、通知を取り消す「消去トリガー」を複数ずつつけているので、自分でも分からなくなるときがありました。仕様を書いてもエンジニア陣から「整合性がとれてませんよ」と言われることが何度もありましたね。
結局最後まで仕様は完成することなく、毎日のように仕様が変わっていました。

―それはエンジニアの方も大変ですね。

竹下　それがエンジニアの方から提案してくれることも多々ありまして。設計の時は気にならなかった箇所も、いざ開発を始めてみると「ここはユーザビリティが悪いからこうしませんか」と提案してくれました。
正直、「それって、開発が増えるからみんなの首しめるけど大丈夫？」と心配になりましたが、妥協せずにプロジェクトに関わってくれて嬉しかったです。

鳴り止まない問合せ。本当の戦いはリリースしてからだった。

―順調にリリースできたのでしょうか？

竹下　いえ、途中はリリースができなくなると思うくらいの危機もありました。リリース直前になって、運営からの一斉連絡のような大量配信を行うと通知に半日以上かかることが分かったのです。朝配信したものが夕方に届くようでは通知の意味がありません。

その問題が発覚した時は、勘舎さんが助けてくれました。結局、直接的に解決することはできなかったものの、通知を行う際にはサーバーのユーザーステータスを参照しないなど、別の方法によって通知のスピードを上げることで相殺してくれたのです。むしろ、以前よりも早く通知できるようになりました。

―無事にリリースできたのですね。

竹下　はい。ただ、リリースしてからの方が大変でした。ココナラの方針として、どんなに詳細に仕様を検討しても結局は机上の空論なので、可能な限り早くリリースして爆速で改善するようにしているのですが、今回もリリースしてから多くの意見をもらい、急いで修正をかけました。

ユーザーからの問い合わせがSlackに流れる仕組みにしているので、リリースした瞬間からSlackが鳴り止みませんでしたね。10件に1件は肯定的な意見でしたが、残りは全て不満でした。

リリース後、CSと協力してそれらの意見を集約し、翌日には修正のリリースを出せました。翌週には大きな部分は全て改修し、その点に関してはユーザーからも高く評価してもらいました。「問い合わせてからこんなにすぐ動いてくれるのはすごい」という意見を、問い合わせやSNSなどで多くいただきました。

―なぜそんなにすぐに修正できたのでしょうか。

竹下　勘舎さんはじめ、エンジニアの方たちのおかげです。Slackにユーザーからの問い合わせが届くと、エンジニアがすぐに反応してディスカッションが始まるんです。必要に応じて詳しい人をメンションで呼んで、問題を一つずつ潰していきました。特に勘舎さんは問い合わせがきてすぐに事態の深刻さに気づいて対応してくれましたね。

―なぜ勘舎さんは事態の深刻さに気づけたのですか。

勘舎　私の役割はサイトの安全稼働なので、普段からユーザーからの問い合わせに触れる機会が多いです。その経験から、なんとなく事態が深刻な問い合わせについては直感で分かるんですね。軽微な問題であれば気にしませんが、今回は危険な気配を感じたのですぐに対応しました。

竹下　本当にあの時は感謝しかないです。

―せっかくなので最後にココナラで働くよさについて教えて下さい。

勘舎　私は自分のスキルを上げたい人におすすめの環境だと思っています。
理由は二つあって、一つは多様性です。エンジニア職以外も含め、各分野のスペシャリストがいるので、話しているだけで自然と様々な気づきを得ることができます。

もう一つはコミュニケーションがオープンなことです。コミュニケーションがオープンでなければ多様な人がいても意味がありません。先程も触れたようにSlackでいろんな人と関われるので、視野も広がりますし視座も上がります。

岡田　私も勘舎さんに似ていますが、スキルの幅を広げたい人にもおすすめの環境ですね。一つの言語にとらわれず、いろんな言語に触れられます。バックエンドだけでも3言語を扱っていますし、これからももっと増えていく予定です。

竹下　私は、多様性はあるのに、ミッションで一つにまとまっているところだと思います。まとまっているだけの会社はある種の息苦しさもあるのですが、ココナラにはそのような息苦しさがありません。様々な人が様々な強みを発揮しながらていて、それでもミッションに向けて一緒に働けるのは居心地がいいですね。

あとは意見を否定されないのもとても助かります。どんな基本的な質問しても「そんなことも知らないの？」と言われることがありません。ココナラでは入社直後から成果を上げる方が多いのですが、その理由がそこにあると思います。Slackで@hereで「困ってます」と投げれば、みんな返信してくれるのでキャッチアップが早いんです。Slackの例はほんの一例でしかありませんが、全体として心理的安全性が高いあるので、現在のようなコロナ禍におけるリモート環境でもすぐに活躍してくれるのだと思います。

―皆さんありがとうございました！

ココナラは常にユーザーベネフィットを最大化を図るべく、複数のプロジェクトが進行してます。少しでもご興味をお持ちいただけた方はぜひ「募集職種」で現在採用中の職種をチェックしてみてください。

※この記事は2022年に公開された記事です（所属や役職の一部当時のものです）