Findy Team+ Lab

NEW

インタビュー
テックブログ

技術負債解消とオンボーディング設計が秘訣?ココナラが目指す開発生産性向上と組織拡大の両立

技術負債解消とオンボーディング設計が秘訣?ココナラが目指す開発生産性向上と組織拡大の両立

日本最大級のスキルマーケット「ココナラ」を、運営する株式会社ココナラ。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、ココナラの執行役員 開発本部担当の村上正敏さんにインタビュー。開発チームにおける課題や取り組み、「Findy Team+」導入のきっかけなどについて伺っていきます。

※Findy Team+のサービス詳細は以下よりご覧いただけます。 https://findy-team.io

目次

開発チームとして、昨年から技術負債の解消に取り組む

ーーまず最初に、村上さんの現在の役割や主なご経歴を教えてください。

村上: 株式会社ココナラで開発担当の執行役員として、アプリケーション側からインフラ基盤まで、開発全般を幅広く見させてもらっています。

経歴としては、もともとSIerからスタートして、Web業界に転向してきました。主にCtoCのビジネスを経験してきて、より多くのユーザーさんに価値提供することに興味を持ってやってきたので、ココナラでもそういったところを実現したいと思っています。

ーー開発チームにおける、現在のミッションについて教えてください。

村上: 開発チームとして、今は技術負債を解消していくフェーズだと思っています。新しい技術を取り入れるなど、先進的なことにも取り組んでいますが、一方でレガシーな部分も残っています。そうした部分を解消していくことにより重きを置いて、しっかり地ならしをしたいと考えています。

1

ーーいつごろから、技術負債の解消に取り組み始めたのでしょうか?

村上: 大きく動いたのは、昨年ですね。それまでは、目先の業務でいっぱいいっぱいだったのですが、昨年からかなり力を入れて、経営サイドにもコミットしてやってきました。1年経ってようやく、少しずつ芽が出始めたところです。

ーー技術負債の解消への取り組みについて、経営サイドの合意を得るのが難しいというお話を、他社さんからよくお聞きします。その点はいかがでしたか?

村上: 他社さんに違わず、そうした難しさは大いにありました。合意を得たといっても、すべてのことが1度ですっと決まったわけではありません。事業施策を推進する上で、問題がいくつも発生しているということは逐次共有し、共通認識を持つようにしていました。そして、その解決策について何度も話し合いを繰り返し、事業スピードを極力落とさずに実現する方向性について議論してきました。

具体的な問題としては、例えば新機能の開発にあたって、従来に比べて開発ペースが落ちていたりとか、関わる人数が増えることで、プロジェクトに混乱が生じていたりとか。あとは、どんどん施策の難易度が上がっていて、これまで通りでは上手くいかなくなってきたりもしていました。

それから、やはりレガシーなものをメンテナンスし続けるのはつらく、エンジニアのモチベーションがなかなか上がらないという声も、強くなってきていました。そういったことを伝えながら、徐々にすり合わせていくことで、経営サイドの合意に繋げていった経緯があります。

技術負債の解消を、それぞれ規模に応じたやり方で進める

ーー技術負債の解消に工数を割きつつ、新規の開発も行われていると思いますが、そのバランスはどのように取られていますか?

村上: 部署によって割合は大きく異なりますが、今までユーザー向けの機能開発が100%だったところを、80%・20%にしたり、50%・50%にしたりと、部署の特性や内容に応じてチューニングしています。

やはりユーザー向けの機能を開発して価値を提供をしていかないと、そもそもの売上が上がっていかないので、そこを守りつつ、一定割合を技術負債の解消に割いていくようにしています。

ーー進め方としては、各チームが独自で進めていくのか、共通で進めるためのタスクフォースなどが組まれているのか、どういった形で行われているでしょうか?

村上: 弊社では、小規模・中規模・大規模の技術施策を、それぞれ別のやり方で進めています。

例えば、小規模な施策というのは、1日から1週間くらいで終わるもの。それらは、大がかりな承認を取って進めるのは非効率なので、業務の中で運用ラインを引いています。例えば、人ごとに週の中での作業日を決めて、その日にちょっとした問い合わせの調査やバグの対応などをする、といった形です。

中規模な施策は、数週間から1ヶ月くらいかけて、1~2人で行うもの。そういった内容は1年前から、全エンジニアが見れる技術ロードマップとして、技術的な課題を一元化し、優先度をつけて管理しています。その中で、中規模のものは特定の人に割り当てて、新機能と同じくらいの位置付けで、工数を確保して進めてもらっています。

最後に、大規模な施策ですが、これは数ヶ月、場合によっては年単位のものになります。これは、他部署にも絡む場合があることから、開発委員会を設けています。現在、開発委員会は7つあり、パフォーマンスや品質、開発スピードなど、それぞれの内容ごとに委員会が設けられています。

それぞれの委員会では、大きな課題をどう解決していくのか、課題を深掘りして分解し、分解したタスクを何ヶ月単位でどのように進めていくかを決めます。そうすると、1つ1つが中規模のレベルになってくるので、それを技術ロードマップの中に入れて、実際に人に割り当てて進めていくという流れになっています。これが、この1年で整備してやり始めたことですね。

結果として、このような形にたどり着いたのですが、考えながら走っていたので、最初からイメージを描けていたわけではありませんでした。簡単にはできない大きなタスクを、いかに分解しつつ前に進めるか、どういう形であれば実現できるのか、といったことを考えに考え抜いて、今の体制になっています。

開発の状況を定量的に知りたいという、経営層からの声

ーー御社では、今年5月ごろに「Findy Team+」の導入を検討いただきました。導入を検討いただいたきっかけや経緯について教えてください。

村上: まずは、現場からこうしたツールがあるという声がいくつか上がっていて、それが「Findy Team+」を知るきっかけになりました。

それに、経営層から「開発の状況が知りたい」という声が上がっていたタイミングでもあったんですね。これは開発に限った話ではないですが、状況を把握するために、なるべく定性情報だけではなく、定量的な情報を含めて見えるようにしたいと。

今までは「進捗は良さそうです」というような、フワッとした状況しか共有できていなかったのですが、「Findy Team+」であれば定量化できるのではないかということで、1度試してみようという話になりました。

もともと自前でも、ある程度は可視化ツールを構築していたのですが、経営レベルで使える情報にはなっていなかったんです。エンジニアが見る分には問題なくても、粒度が細かすぎてしまって。その点で、「Findy Team+」は粒度がちょうどいいと感じました。

ーー社内で構築されていたという可視化ツールでは、どういった要素を可視化されていたのでしょうか?

村上: 「Findy Team+」と同じように、やはりGitHubが全ての活動の根源だと思っているので、GitHubの様々なメトリクスを取って、クエリさえ書けばそれが見られるような状況になっていました。

なので、正直「Findy Team+」と近いものを出そうと思えば、出せる環境があったんです。ただ、それをそのまま出しても仕方がなく、使い方の面でなかなか結論が出ていなかったという感じですね。

「Findy Team+」のアクティビティ数をKPIとして設定

ーー「Findy Team+」の導入を決定するにあたって、どういったところが決め手になりましたか?

村上: 既にクエリを書けば可視化できる環境があった中で、重要なのは意味あるデータがつくれるかどうかでした。そこで、僕らの中でそもそも観点としてなかったのが、複数の指標を組み合わせて表示することだったんですね。

生産性の可視化をテーマとしたときに、それはコミット数でもなければ、プルリク作成数でもなく、何か一つのプリミティブな指標で示せるものではないだろうなと。でも、だとしたら何なんだろうと、ずっと悩んでいたんです。そうした中で、「たしかに」と思ったのは、「Findy Team+」のアクティビティ数の考え方です。

コミット数やレビュー数、プルリク作成数など、1つ1つの指標は僕らも取ることができますが、それらをトータルでまとめてアクティビティ数として捉えるという考えはありませんでした。もちろんそれも完璧ではないと思いますが、1つ1つを個別で見るよりは、トータルでバランスが良い指標だと感じます。

しかも、それを全体で見るのかグループ単位で見るのか、もしくは個人単位で見るのか、といった切り替えもできる。なかなかそこまでやろうとすると大変なので、そういったところまで含めてできるのは大きなポイントでした。

2

ーー現在、どういった形で「Findy Team+」を活用されていますか?

村上: やはり1つはアクティビティ数のところで、これは月次でモニタリングするKPIになっています。毎月の定例会議でCEOと協議するものになっており、日々これを見ながら改善方針を検討しています また、先ほどお話した開発委員会の中に、開発の生産性に関する委員会があります。そこで、より分解した指標から改善が必要そうなものに注目し、ボトルネックを洗い出して施策を考えていこうとしています。

今着目しているのは、例えばレビューからアプルーブまでの時間の長さ。そこに時間がかかっているのは、レビューした後に気づかないからなのか、気づいているけどラリーが増えているからなのか。そういう議論のもとになるものを細かい粒度でウォッチして、原因を深掘りしたりしています。

あとは、施策が実際に進み始めたら、その結果がちゃんと出ているかどうかをモニタリングするためにも使っていますね。

ーー今後、どのように「Findy Team+」を活用していきたいですか?

村上: まだ使い方はいろいろと試行錯誤していて、まさに「Findy Team+」の使い方自体も、1つの技術課題だと思っているところです。

今は、先ほど挙げたアクティビティ数を見ていますが、どうも直近で効いてくる数値ではないということがわかってきました。生産性を上げるためのタスクに取り組んでも、直接は効かない。でも、それをやることに意味はあるし、中長期的には効いてくるだろうと思うのが、まさにアクティビティ数なんですね。

なので、その手前にある中間指標というか、それを少しずつ達成していけば最終的にアクティビティ数につながる、という指標をうまく見つけなければならないと思っています。

というわけで、まだあまり明確に今後の使い方が見えているわけではなく、フェーズごとに応じて見るものを変えていこうと考えているくらいで、手探りでやっていこうとしている状況ですね。

人数を増やしつつも、生産性を落とさない秘訣とは?

ーー実際に、貴社の「Findy Team+」のデータを見ていきたいと思います。アクティブメンバーサマリーを見ると、昨年5月から今年8月にかけて、稼働人数が約1.7倍になっていますが、稼働人数あたりのプルリク作成数はあまり変化がありません。つまり、人数が増えてコミュニケーションコストが大きくなっても、1人当たりのアウトプットが変わっていないことになります。この部分に関して、何か行われている取り組みはありますか?

グラフ1 2021年5月~2022年9月までのアクティブメンバーサマリ(折れ線グラフが稼動人数の数、棒グラフが稼働人数あたりのプルリク作成数を示す)

村上: まったく下がってないかというと、微妙に下がってはいるかなと思います。ただ、大きく下がっていないことについては、新しく入ってきた人が早期に立ち上がれるように、オンボーディングを充実させていることが、ポイントの1つになっていると思います。例えば、ドキュメント化したり、メンターをつけてOJTを行ったりなどですね。

ありがちなのは、実力のある新しい人を採用したのに、立ち上がりに時間がかかってしまって、人数は増えているのにプルリク作成数が減ってしまうような状況ですよね。その点で、弊社は立ち上がりまでの期間が短く、1ヶ月くらいでそれなりに動けるようになっています。

それから、OJTの一環でもありますが、簡単なタスクから振るようにしています。難易度が低いものであれば、新しい人がボトルネックになりづらいですし、それを重ねていけば、難易度が高いものもペースを落とすことなく自然とできるようになっていきます。そのあたりが、人数を増やしていきつつも、それほど影響なくやれている秘訣かなと思いますね。

ーー簡単なタスクというのは、前提となるシステムへの理解やビジネスドメインへの理解が、そこまで必要とされないものというイメージでしょうか?

村上: はい、まさにそういうものです。先ほどお話していた、小規模なタスクがこれに当たります。ちょっとした問い合わせの調査やバグの改修は、コードを見れば1~2行で済むケースも結構あるので。そういったものをやってもらいながら、徐々に理解を深めてもらいます。座学でいろいろと教えるより、その方が早かったりしますからね。

ーーもう1つ、チームサマリのグラフを見てみると、プルリク作成からレビューまでの平均時間が低く安定しています。この部分について、何か取り組まれていることはありますか?

グラフ2 2021年5月~2022年9月までチームサマリ(薄い青色の折れ線グラフが、プルリク作成からレビューまでの平均時間を示す)

村上: 定義としては、プルリクを作成してから、“最初の”レビューコメントがつくまでの平均時間ですか?

ーーおっしゃる通りです。

村上: であれば、気づくかどうかがすべてかなと思いますね。特段すごいことをやっているわけではなく、気づくための仕組みを入れているところがポイントだと思います。

プルリクは基本的に、自動テストなどがある程度通った状態でやることになっていて、その後にSlackのチャンネルで、「レビューしてください」とメンション付きで投稿します。人数が多いので見てもらいやすい面もありますが、それに加えて、自動でbotがリマインドしてくれるツールを導入しています。

そのおかげで、忙しくて見落としがあった時にも、気づかずに放置されないようになっているんです。それによって、最初のコメントは確実に1日以内には、早ければ数時間以内につくようにできていますね。

抜本的な見直しも視野に入れ、非連続な成長を目指す

ーー今後目指していきたい、開発チームの姿について教えてください。

村上: 弊社は上場してから少し経ち、今は第二創業期と位置づけています。「ここからまた大きく伸ばしていくぞ」という時で、現在の約314万(2022年8月現在)というユーザー数から、一桁アップの規模を狙っています。

そうなれば、当然ながら開発組織もシステムの規模も大きくしていく必要がありますが、これまでのように単に数を増やせばいいという問題ではなくなってきます。一般的には、組織やシステムが拡大していくと、その管理工数が増えて無視できなくなってくると思います。その管理工数を最小化するためにも、今後一人一人が取り組むべきことを考えて自律的に行動できることが大切で、そういう自己組織化した状態になることが理想的だと考えています。

3

ーーそれでは最後に、そうした開発体制を目指していくにあたって、一緒に働きたいエンジニア像について教えてください。

村上: すべてがそろうスキルマーケットを目指して、私達はプロダクトと技術の両面において大きな進歩を遂げる必要があると考えています。その過程において、今までにない難しい課題に直面することも多いと思います。 そのような状況下において、意欲高く仲間と切磋琢磨しながら成長し、新たな課題が発生しても試行錯誤しながら解決していけるような方と一緒にサービスを盛り上げていきたいと思っています。 ココナラでは、現在さまざまな領域でエンジニアを募集しています。もし興味を持たれましたら、エンジニア採用ページ よりお気軽にご連絡ください。

ーー村上さん、ありがとうございました!

※Findy Team+のサービス詳細は以下よりご覧いただけます。 https://findy-team.io

関連記事

Scrum@Scaleを導入し、チームの横連携を強化。デプロイ頻度を保ちながら組織拡大を目指すグロービスの取り組み

Scrum@Scaleを導入し、チームの横連携を強化。デプロイ頻度を保ちながら組織拡大を目指すグロービスの取り組み

インタビュー
テックブログ
組織拡大を見据えて開発組織の改善意識を醸成。コミュニティオによる定量指標の活用

組織拡大を見据えて開発組織の改善意識を醸成。コミュニティオによる定量指標の活用

インタビュー
テックブログ
Four Keysの自前取得からサービス導入で自動化。高信頼性組織を目指すセンシンロボティクスの取り組み

Four Keysの自前取得からサービス導入で自動化。高信頼性組織を目指すセンシンロボティクスの取り組み

インタビュー
テックブログ
急拡大を支えるカギは成長の可視化と現場ニーズのマッチング、組織力を武器に星野リゾートが目指すグローバル展開

急拡大を支えるカギは成長の可視化と現場ニーズのマッチング、組織力を武器に星野リゾートが目指すグローバル展開

インタビュー
テックブログ

エンジニアリング組織の
パフォーマンスを最大化

Findy Team+はGitHubやJiraなど
エンジニア向けツールを解析することで、
エンジニアリング組織の生産性を可視化するサービスです。