ココナラエンジニア組織の未来像について
この記事はこれからココナラがつくっていきたいエンジニア組織の未来像について、技術戦略、開発プロセス、評価制度という3つの切り口から紐解いたものです。
ココナラでは事業を前に進めてくれるエンジニアの方を広く求めています。そういった方に少しでも組織の全体感を知っていただればと思い、重要な軸に絞ってまとめました。
技術戦略について
未来像とそれを支える思想
メインプロダクトであるココナラにおいては、今後2〜3年後ぐらいのスパンで、ユーザー数やサービスの規模が2倍、3倍になっていくだろうという計画ならびに見通しがあります。そのレベルになってくると現状のシステムをそのままの構造でスケールさせていくということは難しいため、アーキテクチャのリニューアルを含めた対応を進めていきたいと考えています。
現状
具体でいうと、DB周りについては単純にサーバーの性能を上げる、または台数を増やすなどのスケールアップ/スケールアウトでは限界があり、インフラやアプリケーションの作り方から考え直していかなければならないと考えています。
また、ちょうどいいタイミングですので、その際に合わせて現在の技術トレンドの取り込みも検討する必要があると思っています。具体的には、マイクロサービス化を中心としたアーキテクチャの整備やそれに親和性の高い開発環境の整備などを考えています。
ギャップとそれをどう埋めていくか
アーキテクチャリニューアルのような大きな技術課題は、細分化して技術ロードマップ上で管理するようにしています。技術ロードマップでは、タスクの優先順位順に並べて優先度の高いものからスケジュールを記載しています。
最初は現状調査や方針検討を行ない、その後スコープ毎に具体的な計画に落としていき、最終的に移行プランを整備した上で本リリースするという流れを考えています。その中で、関係部署と相談したり、またAWSの内部の方と相談をするなどして安心・安全で時流に合わせたバランスの取れた方針を検討していきたいと考えています。
また、特に大掛かりな対応になるため、事業影響も無視できません。アーキテクチャリニューアルのために事業KPIに効く施策を中断することは難しいため、移行プランとして何をどの順番でリリースするかの計画が非常に重要になっていきます。
アーキテクチャリニューアルは、開発工数や変更影響が大きいことから難易度も非常に高く、他社事例でもそれほど明確に成功している例は多くないと思っています。
ココナラでは難易度の高い課題についてもどんどんチャレンジしてノウハウを貯めていきたいと考えています。
開発プロセスのアップデートについて
未来像とそれを支える思想
エンジニアは、自分で（開発する上での）解決すべき課題を見つけて主体的に改善していくことに喜びを感じる人が多いと思っていて、将来的には自然にそれを実施できている組織にしていきたいと考えています。
現状
課題を見つけていくためには、前述の通りエンジニア間であるべき姿についての共通認識をもっていることが大事だと考えています。共通認識があることで、現状何がたりないのか、何を実施すべきかをそれぞれが判断できるようになり、結果として上記のような改善につながっていくと思っています。
しかし、現状はまだそれが十分にはできておらず、各人がそれぞれの理想像を描いている状況です。
ギャップとそれをどう埋めていくか
まずはシステム構成や開発プロセスの両面からあるべき姿を整理し、それを皆で議論しながら精緻化していくことで、徐々に共通認識を持てるようにしていきたいと考えています。
これは、言葉でいうと簡単ですが、実際には結構骨の折れる作業で、エンジニア全体の共通認識として定着させるまでには時間も手間もかかると思っています。エンジニアの価値観は人それぞれで、どこを重視するのかも人によって変わるため、意見を取りまとめるのは簡単ではありません。ただ方針としては、「一般的なベストプラクティス」は議論・検討の上で参考にしつつも、最終的には「ココナラにおいての最適解」を作っていくという方向性で進めていきたいと思っています。
「ココナラにおいての最適解」が描ければ、あとは現状との差分が明確になるので、それを技術ロードマップに記載し、計画に落として実施していくだけとなります。
評価について
未来像とそれを支える思想
これからますますのユーザー数増加やシステムの大規模化が想定されています。これらに対応していくためには、今までのように単に機能要件を実現していくだけでなく、より高度な技術力を駆使してパフォーマンスや品質などの非機能要件なども柔軟に対応していくことが求められるようになっていきます。そのため、今のうちからエンジニア全体の技術力の向上を図っていきたいと考えています。
エンジニア専用の評価制度というのは、その課題に対する１つの布石だと考えていて、高い技術力を有することを奨励・評価していくことで、自主的に技術力向上に取り組みやすい環境を作っていきたいと考えています。
現状
これまではエンジニアもビジネス職の方も同一の基準で評価し、同一のグレードを用いた全社共通の人事評価制度を運用していました。
具体的には、3ヶ月毎の短期的な結果をベースに計画通りに実現できたかどうかで評価をしていました。
そこでの課題として、開発案件によっては3ヶ月で終わらないことも多く、結果が出てない状況の中で中途半端な評価になってしまってしまうこともありました。加えて、案件の内容や難易度によって評価が影響を受けてしまうこともあり、フェアな評価をしにくい状況にありました。
また、これまでは上にいくとなるとマネージャーになるしか道が有りませんでしたが、エンジニアの中にはマネージャーになることを望まない人も一定数いるため、そういった方にとっては、道が閉ざされている状況になっていました。
ギャップとそれをどう埋めていくか
上記のような課題を踏まえて、2021年9月よりエンジニア専用の評価制度を整備し運用し始めました。
この評価制度は、短期的な結果だけでなく、その結果を生み出す根源となる技術力にも着目し、その技術力が一定レベルに達したかどうかで評価するというものです。
これにより、案件によって短期的な結果がでなかったとしても、技術力がしっかりと身につき、次の案件からはその実力を発揮できるような状況になっていたらそれを評価できるようにしました。
評価をする上で、グレードごとに期待する技術力を定義し、次のグレードにいくためにはどのようなことが求められるかが明確になりました。
また、上記グレード定義は採用の側面でも活用していく予定です。会社として高い技術力を醸成していくためには、内部での評価・育成の他、外部から高い技術力を持ったエンジニアを採用する必要があります。グレード定義は、まさにその候補者の技術力を図る物差しとなるものだと考えています。採用時にこれを活用することで、候補者の想定グレードを適切に判断できるようになっていくと思っています。
今後のキャリアパスという点では、マネジメントトラックとエキスパートトラックという2種類のトラックを設けました。
マネジメントトラックの方は今までも運用していたもので、チームやグループ、部という組織をマネージして成果創出をはかるトラックとなります。逆にエキスパートトラックの方は、いち個人の技術力を生かして、難易度が高い課題を解決し、成果創出をはかるトラックです。この２つのトラックにより、柔軟なキャリアパスを検討できるようになったと考えています。
ただ、エンジニア評価制度は、まだ運用を開始し始めたばかりであり、完璧な状態ではないと思っています。また、時代の変化に応じて制度自体も柔軟に変化が求められるものだと思っています。そのため、適用して終わりではなく、運用をしていく中で常に制度のブラッシュアップを図っていきたいと考えています。
最後に告知
この記事の冒頭で記載したとおり、ココナラでは事業を前に進めてくれるエンジニアの方を広く求めています。もし、少しでも面白そうと思っていただけましたら、下記ページからエントリーいただければと思います。
まずはフラットに話を聞きたい、とかでも大歓迎です！
※この記事は2021年に公開された記事です（所属や役職の一部当時のものです）