ユーザー数190万人に到達し、知識・スキル・経験を売買できる国内最大級のマーケットプレイスへと成長している『ココナラ』。

2012年創業以来、過去のやり方にとらわれず、常に進化を続けるココナラですが、「システム構成面でも組織面でも改革のフェーズに入った」とプロダクト開発部部長を務める村上は語ります。

そこで今回は村上、そしてバックエンド開発チーム部長を務める江口に、エンジニア視点でココナラはどう映っているのか、またココナラならではの開発の特徴や現在の課題など、彼らの仕事の裏側について伺いました。

常に最新技術をキャッチアップし、変化し続ける。その結果、ユーザーに喜んでもらえたときは本当に嬉しい

――　変化し続けるココナラだからこその、開発の難しさや面白さについて教えてください。

村上：ココナラは2012年に創業して以来、開発を続けているのですが、創業当初のコードもいまだに残っていたりするんですね。さらにフレームワークが古いもの、テストが十分書かれていないものなど、いろいろなものが複雑に残っている状態。

それゆえ、まったく関係ないところをいじったつもりなのに、別のところで障害が起きてしまうということも起きてしまいかねません。そういった問題を解決するため、新規機能開発の施策と並行して、サービス実行環境のリプレースも推進しています。

エンジニアとしては既存のコードを読みつつ、古い言語、古いフレームワークを見ながら開発の経緯を読み取っていき、リプレースするという経験はなかなかできることではないので、そういったココナラの成長を掘り起こしていくのはとても面白いなと感じています。

もちろん、ただ新しくするだけでは意味がないため、併行してシステムのマイクロサービス化にも取り組んでいます。その過程でまた新しい技術が出てくるため、常に学び続けながら最新技術をキャッチアップしていくことも楽しさのひとつですね。

江口：ココナラは過去のやり方にとらわれずに、どんどん変化し続ける文化のため、いろいろな技術が使われています。過去に自分自身が触ったことがある技術があったり、聞いたことがあるけど使ったことはないといった技術もたくさんあって。そういった広く様々な技術に触れながら開発ができるというのは面白いです。

また、ココナラならではで言うと、ユーザー数が多いC2Cサービスのためユーザーの声がダイレクトに届くというのも面白さのひとつだなと。やはりエンジニアとしてはユーザーに喜んでもらえるサービスにしていきたいため、ユーザーのポジティブな声が直接届くというのはモチベーションになります。

村上：大きめのリリースをするときは、SNSやプレスリリース等で告知を出すのですが、リアルタイムに「この機能、待ってました！」といった声が届くんですよ。特に既存機能の改修であれば「使いづらかったので、本当に待ってました」といった声も多く、そうやってユーザーに喜んでいただけるのはエンジニアとしても本当に嬉しいですよね。

またココナラでは、ユーザーイベントを毎月開催しており、新機能のリリース報告や懇親会を開催し、ユーザーとの交流の場を設けています。

ユーザーイベントは全メンバーが参加できるため、エンジニアも参加し、フランクに様々なユーザーの意見が聞けるんですね。「こんな機能が欲しいです！」と直接言われたりと、ダイレクトにユーザーさんの声が届くのは学びも多く、楽しいです。

江口：最近も、ある機能をリリースした直後にユーザーから否定的な声が届いたことがありました。それはココナラとしても対処すべきことであったため、すぐに改修したところ、同じユーザーから「オレの声が届いた！」といったコメントがあったり。

必ずしもユーザーの声をすべてを取り入れる事ができるわけではないのですが、事前に自分たちではわからないこともあるので、対処すべきだと判断したものは真摯に対応するようにしています。そうやってユーザーの声も聞きながら、ユーザーと一緒につくっている、という感覚が強いのがココナラの特徴だなと思いますね。

シームレスにスケール可能なシステムを目指して。開発組織は常に変化し続けていく

――　開発組織自体の変化というのは、何かありますか？

村上：実は私がいま所属しているプロダクト開発部というのも、半年前にはありませんでした。さらに今のバックエンド開発、フロントエンド開発、アプリ開発と職能で分かれた構造も少し前まではなく、ざっくりとWeb開発、アプリ開発くらいの分かれ方をしていたんですね。

しかしWeb開発のメンバーが増えていき、現在では全社の1/3が開発メンバーとなり、組織構造を整えていったという背景があります。

またココナラではプロジェクト単位でメンバーがアサインされ、3ヶ月とか半年といった期間で開発する進め方をしているのですが、1〜2年前まではプロジェクトマネージャー的なポジションすら存在しておらず、現社長（当時はCOO）直下でエンジニアが動くといったこともしばしば。開発ドキュメントも整っておらず、結果システム障害が発生して夜中に叩き起こされるといったこともありました（笑）。

しかし現在は、設計工程で第三者の目をいれつつ機能要件・非機能要件などしっかりドキュメントを整理するようにしたり、QA工程でエンドツーエンドテストを綿密に実施するようになったことでクリティカルな障害は減ってきましたし、、スムーズにプロジェクト進行できる体制が整ってきています。

今後も開発プロセスを可能な限りテンプレ化していくことで、開発の品質が属人化しないようにしていくことが重要だと考えています。また、エンジニアブログを書いたり、技術負債を解消したり、新しい技術を試したりとプロジェクト以外のことにも時間をさけるようにしていきたいと考えています。

そして2020年9月よりCTOが加わったことで、今後ココナラは中長期的な視点でシステムおよびシステム開発のあるべき姿を考え、それを実践していく体制にシフトしていきます。これまでは、ユーザーの増加に伴って、その場しのぎのシステム拡張または継ぎ接ぎ開発が中心でしたが、現在のやり方でサービスが成長していくのには限界があります。

そうしたときに、いま抱えているプロジェクトの片手間で対策をうつというのは限界があります。事業計画に沿うように中長期の技術ロードマップを策定し、持続的なサービス成長を阻害しないよう、システムおよび開発体制を改善していくつもりです。

――　ココナラならではのカルチャーや風土は何かありますか？

江口：私自身は2020年5月入社なので、まだ入社間もないのですが、ココナラはビジョンやバリューを大切にしている会社で、実際にバリューを体現しているメンバーが多いなと感じています。過去に私がいたスタートアップでも、そういったミッションなどは言葉として掲げられていたのですが、浸透していなかったり、体現しているメンバーが少なかったりしていたので、文化として根付いているココナラに驚きました。

またバックエンドエンジニアとしては、フロントエンドエンジニアと仕事をするのが楽しいなとも感じています。というのもココナラのフロントエンドエンジニアは、ココナラの価値観としても掲げている「プロダクト愛」が本当にすごいんです。

何か相談しても、自分がユーザーだったらああだこうだと、自分ごとのように相談に乗ってくれるんですね。また会話にもよく「ユーザー体験的にこっちのほうがいい」といった話が出るのですが、みんな自分自身がユーザーであったりもするため、そういった細かい使い勝手の表現が会話に出てくるんです。

本当に細かい部分まで熱心に意見を言ってくれるため、入社したてのころは「これがココナラの文化か」と驚きました（笑）。

十人十色のエンジニアたちが挑戦し、それが有機的に繋がり、ユーザーに満足してもらえるサービスを目指して。

――　あらためてエンジニアとして、今後ココナラの開発をどのようににしていきたいですか？

村上：エンジニアも十人十色。それぞれ価値観が違うので、画一的に同じ開発手法・ツールで開発してくださいというのは無理があると思っています。そのため、ある程度自由度を持って開発できるようにしていきたいと考えています。

現在、マイクロサービス化を推進しており、多少の自由度を持たせながら開発を進められるようになってきています。今後もそれを継続して推進し、十人十色のエンジニアが生み出したものが有機的に繋がっていき、最終的にユーザーに満足してもらえるサービスを作れる体制が整備できたらいいなと思っています。

江口：私も現在マイクロサービス化のプロジェクトを担当しているのですが、村上からもあったとおり、マイクロサービス化によって各システムの依存関係が薄くなり、システム障害の起こりにくい開発環境が整っていきます。

それにより、エンジニアとしては新しい言語や技術を使ってチャレンジがしやすくなるため、エンジニアがコードを書いていて楽しいと思える、気持ちよく開発できる環境をつくっていきたいですし、私自身も開発を楽しみたいなと考えています。

――　最後に、おふたりの今後の目標をお聞かせください。

村上：部長の立場としても、いま私自身が感じている課題としてあるのが、エンジニアの評価制度です。というのも、これまでの延長線上でのやり方を続けるのではなく、システム構成面でも組織面でも改革のフェーズにココナラは入っています。

さらに今後も様々なエンジニアがジョインし、組織としてのあり方が変わってくる中で、現状の評価制度では限界があるなと。

たとえばエンジニアであれば、ステップアップの方向としてマネジメント職に就くというのだけでなく、スペシャリストになりたい人もいます。そういった現在の評価制度の枠に収まらないメンバーがでてくることを踏まえ、適正にエンジニアを評価できるよう制度を整えていきたいと考えています。

そして、目指しているのはエンジニアの幸福度を上げていく仕組みづくり。勤務時間内でプロジェクト以外の「遊び」の時間を設け、エンジニアが様々なことにチャレンジできるようにしていきたいですし、事業成長をさせるという前提のもと、エンジニアが働きやすい環境をつくっていきたい、そう思っています。

江口：私は現在リーダー職に就き、プロジェクト管理を行う機会も増えてきました。そこで感じているのは、毎回プロジェクトごとにメンバーがアサインされるわけですが、メンバーのスキルセットが必ずしも同じレベル感ではないということ。そういったときでも、最終的なアウトプットの品質に差が出ないような進行管理ができるようにしていきたいと考えています。

たとえば、ちょっとしたタスク漏れでリリースが遅延してしまったり、リリース後にユーザーから不具合報告が大量に届いてしまったりといったトラブルは、会社にとってもユーザーにとっても不幸でしかありません。

そうしたことが起こらないよう、ユーザーに満足いただけるサービスであり続けるためにも、見えないところでトラブルを防ぐ仕組みづくりをしていきたいですね。