ココナラという会社は、会長を務める南も「スタートアップが同じオフィスに1年半いるのは恥ずかしい」と言うくらい、常に成長し続け、変化し続けることを追い求める会社。

そのため、我々開発に関わるメンバーとしても、いかに事業成長に貢献するかという意識が重要です。そこで、いま開発メンバーの評価指標としても掲げている考え方に「速い・固い・広い」というのがあります。

まず「速い」に関してですが、ココナラはまだまだ成長フェーズで、安定フェーズではありません。そのため、開発スピードが事業成長を左右する要因の1つになってきます。当然ながら、新機能を1ヶ月後にリリースするのと1日後にリリースするのでは、事業成長の加速度合いがまったく違ってくるわけです。 そして「速い」を達成するためには、開発スピードを高めるだけでなく、自分たちが開発しやすいように開発環境を改善していくことも重要です。開発環境が使いづらいなど、なにか問題に気づいているのであれば、そこをまず解決しましょうという発想で取り組んでいます。

一方で「速い」を追い求めた結果、システム障害が起きてしまうというのは、ユーザーが200万人いるココナラでは許されない。そこで次に大切なのが「固い」、すなわち最低限の品質を担保することです。

もちろんメンバーによってスキルセットは異なるため、品質の担保というのは容易ではありません。アサインされたメンバーによってアウトプットの品質が異なるというのは良くないため、いまは開発ガイドラインを整備することや開発プロセスの一部自動化を推進するなど、最低限の品質を担保する仕組みをつくっています。

そして最後に「広い」についてですが、個々のメンバーが「自分の仕事じゃないから」と思って取り組んでいると、何か課題を見つけたときに、取りこぼしが発生してしまいかねません。 そこでフロントエンドやバックエンドといった職能を越えてオーバーラップするような働き方を大切にしており、評価指標にも落とし込むことで、そうした動きが加速するよう取り組んでいます。

実は、少し前までは200万人規模のサービスと言えど、開発体制はそこまで仕組みが整っている状態ではありませんでした。しかし現在は村上からもあった「速い・固い・広い」を実現すべく、仕組みを整えていっている段階で、例えば工程管理ひとつ取ってもタスク漏れが少なく、スケジュール管理がしやすい仕組みになっており、綺麗なフローになっているなと思います。

やはり、ユーザーのためにつくった良い機能ですから、ユーザーには早く使ってほしいですし、良いものを使ってほしいという想いがあります。私自身はまだココナラにジョインして間もないのですが、「速い・固い・広い」というのをただ掲げているだけでなく、ちゃんと実行に移しているというのがココナラの開発体制の特徴だなと感じています。

まず開発組織の構造としては、バックエンド開発、フロントエンド開発、アプリ開発と職能で分かれた構造となっています。企業によっては事業部制の形を取り、固定メンバーで仕事をするケースもあるでしょうが、ココナラではそういった縦割り構造ではなく、つくりたい機能ごとにプロジェクトを組成して各職能のメンバーを募り、プロジェクト単位で業務を推進します。プロジェクトは、3ヶ月とか半年のスパンになることが多く、プロジェクトが終了するとそこで解散し、また別のプロジェクトを進めることになります

この進め方の狙いの1つとしては、知識やノウハウの共有です。固定メンバーでの縦割り組織を形成してしまうと、技術的に横串が刺しづらくなってしまいます。例えば、ある機能の開発で用いた技術が別の機能開発では有効活用されなかったり、また一方で、障害が発生したときの学びや気付きなどを整理したポストモーテムの共有が徹底されず、別の機能開発でも同じ失敗を繰り返してしまう、といったことが起こりかねません。 しかしココナラでは職能ごとに組織をつくることで、知識・ノウハウを共有できるようにしています。

また別の狙いとしては、評価の適正化があります。事業部制の形を取ると、非エンジニアの上長がエンジニアの部下を評価することになります。非エンジニアの上長が評価すると、負債解消や性能向上などの作業の重要さを十分に理解しないまま、事業観点でのみ評価されてしまう可能性があり、適正に評価できない恐れがあります。ココナラでは、プロジェクト制で開発を進めつつ、職能ごとの組織で評価することで、エンジニアがエンジニアを適切に評価できるようになっています。

エンジニア視点で面白いなと感じたのは、厚みのある開発ができるということです。2012年に創業して以来、開発をし続けてきているので、ココナラが辿ってきた成長に合わせて様々な技術、フレームワークが用いられています。

それは過去のやり方にとらわれず、新しいものをどんどん取り入れていくココナラだからこそですし、新旧いろいろな技術が用いられたコードから、「こういう経緯で、こうつくったのか！」という気付きがあり、そこを掘り起こして触っていくのが楽しいなと。

実際、過去にいくつかの企業を経験してきましたが、ココナラに入って初めて「開発って楽しいな」と思えたほどです。そういった厚みのある開発ができるのは、エンジニアとしての成長に繋がるため、とても良い環境だと思いますね。

現在の課題感としては、これまでの延長線上での成長に限界がきているフェーズになってきていることです。インスタンスを増やせばいい、人を増やせばいいといった物量勝負のフェーズに終わりを告げるときが近づいており、システム構成面でも組織面でも改革が必要。そして今後直面するであろう様々な課題をスムーズに乗り越えていけるような、スケーラブルなシステムづくり、持続可能な組織づくりを進めていかなくてはなりません。

そういった大きな課題に対して、適切に新しい技術を取り入れていき、イケてると思えるようなシステムをつくっていこうじゃないかと。そのため、これからジョインされる方にも「このシステム、イケてないですね」とどんどん指摘してほしいですし、既存のシステムを塗り替えるパワーを持ったメンバーを求めています。

全社員の1/3が開発メンバーとなったいま、事業運営上必要なプロダクト開発だけでなく、上記のような開発に関する課題など今まで取り組めていなかったことも積極的に推進していきます。 私自身もマネジメントする立場として、メンバーに苦手なことを無理にやらせるのではなく、スキルアップややりたいことを考慮したプロジェクトアサインを大切にしており、その結果として個々人が長所を爆発させて会社全体に勢いをつけられるようにしたいと考えています。

ユーザー数も増え、外からは安定期に入っているように見えるかもしれませんが、まだまだココナラは成長段階。そして “モノを買うならAmazon” と想起するように、”スキルを探すならココナラ” と想起されるような世界的なサービスになるためには、もっと使いやすいサービスにしないといけませんし、技術ドリブンでのサービス改善が求められます。

さらに連続的に学べることが変わっていく、いまの変革時期を味わえるのは、ココナラの中でも今しかないと感じていて。そういった一連の変化を楽しめる方はぜひ、一緒に改革を起こしていきましょう。

村上の言う「連続的に学べることが変わっていく」というのはまさにその通りで、実際に半年かけて進めるような大型施策から、小中規模のちょっとした施策までいろいろ走っていて、様々な開発を経験できるというのはエンジニアとして楽しさを感じる部分です。

プロジェクトごとに自分自身の役割も変わりますし、その都度メンバーがアサインされるため、関わる人というのもどんどん入れ替わっていきます。そういった変化が楽しめる人には最高な環境だと感じます。

そして、現在マイクロサービス化のプロジェクトが進行しており、大きくシステムを分割することで、各システムを独立して動かすことができるようになっていきます。そのため、各システムの中でエンジニアとしては様々なチャレンジがしやすくなるため、いままで学んできたことを発揮できる機会がたくさんありますし、技術的に新しいことを学べる機会が多くあります。 エンジニアとしてさらなる成長を求めている方、ぜひ一緒に世界的なサービスを目指していきましょう！