約10年間成長を続ける「カオナビ」、エンジニア組織の特色は？
企業のプロダクトづくりにおいて、エンジニアチームの果たす役割は大きい。立ち上げ時だけでなく、事業の成長に合わせてプロダクトの規模を拡大していくプロセスにおいても、ビジネス要求に合う適切な技術選定と実装を行うスキルを持ったエンジニアチームの存在は不可欠だ。加えて、プロダクトの成長に伴って、チームの陣容や運営体制も変化していく必要がある。成長の過程で、技術面だけでなく、プロダクトや組織の課題を自律的に見つけ出し、解決に向かって動けるエンジニアチームは、企業とプロダクト双方の成長を加速させる強力なエンジンとなる。
2012年にサービスを開始した「カオナビ」は、社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステムである。サービスを提供しているカオナビは、提供開始から約10年が経過する中で、事業の成長に合わせてサービスの規模や内容を急速に進化させてきた。同社のプロダクトを開発している組織である「プロダクト本部」では、「カオナビ」というプロダクトを構成する、さまざまな技術要素について、現在の課題と、将来的なビジョンをもとに改善を続けている。同時に、個々のエンジニアが自律的に課題を見つけ出し、改善できる組織づくりにも取り組んでいる。
今回、カオナビ社のCTOである松下雅和氏と、プロダクト本部で主にフロントエンド領域を担当する南悠輝氏、バックエンド領域を担当する富所亮氏の3名に、同社におけるエンジニアチームの体制や、実際の取り組みについて話を聞いた。「カオナビ」の例から、プロダクトの成長を阻害せず、加速させるエンジニア組織のあり方について、ヒントを探ってみたい。
「マーケットイン」と「プロダクトアウト」の両面で機能開発
――「カオナビ」というプロダクトの特長と、エンジニア組織のミッションを教えてください。
松下：「カオナビ」は、社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステムです。社員の顔や名前、経験、評価、スキル、才能などの人材情報を一元管理して可視化することで、最適な人材配置や抜擢といった戦略的なタレントマネジメント業務の実現を支援しています。あらゆる人材マネジメントの課題を解決し、企業の働き方改革を実現するHRテクノロジーとして、業種・業態を問わず2200社[※1]以上の経営者や現場のマネジメント層に選ばれています。
エンジニア組織としては「プロダクト本部」を置いており、同本部では、プロダクト開発の生産性とスピードを向上させながら、良いプロダクトを作っていくことをミッションとしています。また、「技術的負債」と呼ばれるような、「カオナビ」のシステム自体が拡張していく過程で出てきてしまう、生産性やスピードを阻害する要素を解消していくことも重要な仕事の一部です。
[※1] 2021年9月末時点。
――エンジニアの働き方について、特長的な社風はありますか。
松下：技術面では、経営層から「こういうことをやってほしい」というトップダウンで指示が出るものよりも、むしろ現場からボトムアップで「こうしたほうがいい」「こうしていきたい」という意見が出て、実際に形になっている部分が多いと感じています。
プロダクトとしての「カオナビ」には、ユーザーニーズや競合を意識して作られる「マーケットイン」的な部分と同時に、提供側が「タレントマネジメントシステムとはこうあるべき」だと提案する「プロダクトアウト」的な部分の両方が含まれています。マーケットインとプロダクトアウトの両方の性質を合わせ持ったプロダクトに関わることで、エンジニアチームの中にも、自発的に「こうしたほうがいいのではないか」と考える習慣が根付いているように思います。
スキルアップ支援制度「スナバ」が生んだ、リファクタリングの取り組み
――南さんは現在、主にフロントエンド関連のリファクタリングや技術選定に関わっておられるそうですね。まず、これまでのキャリアを、簡単にご紹介ください。
南：カオナビには、2018年4月に入社しました。前職は自社開発のMAツールを提供する会社で、フルスタック寄りのWebエンジニアとして働いていました。当社では、当初CI/CDの導入に関わり、その後、それまでjQueryで書いていたフロントエンドをReact＋TypeScriptで開発できるように環境を整備しました。それに対応したデザインシステムの構築なども手がけ、現在は主に「フロントエンド支援チーム」として仕事をしています。
――フロントエンドをReactへ移行された経緯について、少し詳しく教えていただけますか。
南：2018年当時の「カオナビ」は、jQueryでフロントエンドを作っていたのですが、あまり開発者体験がリッチではないと感じていました。具体的には、類似したコードが機能間で共通化されずにファイルが肥大化したり、導入しているテンプレートライブラリの学習コストが高かったりなどがありました。開発者の立場としては、再利用可能なコンポーネントなどを活用しながら生産性を高めていきたいという思いがあり、Reactの導入を検討しました。
言語としてTypeScriptを採用することについては、私の提案を会社に採用してもらいました。当初は、旧Facebookが作って注目されていた「Flow」というJavaScript向け型システムを導入し、1年程利用していたのですが、動向をチェックしていると、開発者の中での人気がなかなか上がってこなかったんです。いろいろと調べるうちに、TypeScriptのほうが将来性があり、今後のフロントエンド開発で必須のスキルになりそうだという感触を得ました。
――通常の業務を行いながら、新たな技術の動向を調べたり、採用を提案したりといったこと行うのは負担が大きかったのではないでしょうか。
南：カオナビのプロダクト本部では業務時間のうち週2時間までを、自己研鑽の時間として使ってよい「スナバ」と呼ばれる制度があります。実は、この制度も自分が上長に相談して実現したものなのですが、それを活用できたのが大きいですね。
当社では隔週で有志の勉強会が開催されているのですが、「スナバ」を、そのためのネタ作りに使っているメンバーも多いようです。「スナバ」で自分の関心がある技術についてインプットを行い、最終的にサービスに反映できなかったとしても、学んだことを発表できる「勉強会」があります。こうした体制が会社にあるのは、良い環境だと思います。勉強会では、新しい技術が好きな他のメンバーとも意見交換ができますし、そこで得た刺激が、さらなる自分のインプットやアウトプットにもつながっているという実感があります。
――実際に、React＋TypeScriptへの移行を上長に提案した際、何らかのフィードバックはありましたか。
南：フロントエンド開発に携わるメンバーに共有し、合意を得ていたので、提案はスムーズに受け入れられたように思います。プロダクト本部には「メンバーのうち2人が合意したものは、とりあえずやってみる」というルールがあり、本件についても、特にトップダウン的に「こうしたほうがいい」という指示はありませんでしたね。
――移行を終えて、現在、「カオナビ」の開発に良い効果は出てきていますか。
南：Reactに合わせて構築したデザインシステムは、サービスで利用する共通のコンポーネントを、プロダクトのリポジトリとは別のリポジトリで管理する仕組みです。使いたい時には、開発者がnpmを使ってインポートする形で利用します。
「カオナビ」は、これまでの開発経緯から、フロントエンドからサーバサイドまでが比較的モノリシックなアーキテクチャとなっており、それがフロントエンドの開発にとっては足かせになるケースもあったのですが、今回、デザインシステムを独立性が高い別のリポジトリとして構築したことで、他の部分に大きな影響を受けたり与えたりせずに、迅速に、フロントエンドの開発、リリースを行うことが可能になりました。稼働して2年以上が経過しましたが、その間にさまざまなコンポーネントが、デザインシステム上で管理されるようになり、開発生産性の向上に寄与しています。
松下：私が入社したのは、2020年2月なのですが、当時は既に、カオナビのエンジニアに、自分たちで全体の状況を考えながら、担当分野に関連して「これがやりたい」「こうしたほうが先々の成長につながる」と考える文化があるように思いました。自分たちで声を上げてやっていこうという姿勢があるのが心強いですね。勉強会や「スナバ」などの制度も活用しつつ、自分たちでチームを盛り上げながら、そこで生まれたものをプロダクトの改善へとつなげていく文化は、今後も継続していきたいと考えています。
余裕を持たせることで「みんなで良いものを作る」意識が浸透
――富所さんには、「カオナビ」のバックエンドの改善について伺います。まず、経歴と現在の業務を教えてください。
富所：カオナビには、2020年11月の入社です。それまでは、Webサービスのバックエンド領域のエンジニアとしてキャリアを積んできました。サービスインから10年近くの歳月を経て規模が大きくなった「カオナビ」というサービスに対し、主にバックエンドの領域で開発生産性を向上できるような取り組みをしています。
松下：富所さんをはじめとするバックエンドのチームに対しては、私から「マイクロサービスをキーワードに、現在のコードベースを整理していってほしい」とお願いをしています。というのも、アーキテクチャのマイクロサービス化からメリットを得るためには、開発チームの組織構造も変えていく必要があります。そのため、この領域についてはトップダウンで進めたほうが良いと判断しました。
――現在、富所さんが取り組んでいる技術的なチャレンジはどのようなものですか。
富所：今、松下さんが「マイクロサービスを“キーワード”に」という表現をしたのですが、この部分が、取り組みを進める上でのポイントです。マイクロサービス化を“前提”にしてしまうと、システムの複雑化を助長するだけになることも多いからです。
現在の「カオナビ」は、PHPのLaravelフレームワーク上に作られており、モノリシックな構造の大規模なコードベースで動いています。また、これまでサービスの拡大に集中してきたこともあり、部分的な仕様に齟齬が出ているケースや、システムが必要以上に複雑化しているところもあります。まずは、現在のサービスがどのような要件で動いているかを、ひとつひとつ調べて、問題がある部分を整理しながら、段階的に解消していこうとしています。もしかしたら、その先には「夢のマイクロサービス」が待っているかもしれませんので、それを視野に入れながら、作業を進めています。
現在のシステムが抱えている複雑性や、それに由来する問題に対処する。同時に、すべてのエンジニアにとって理解しやすく、かつ安定性や生産性を高められる方向に、プラットフォームを改善していく。その両方を、うまくバランスをとりながら進めたいですね。
松下：現在「カオナビ」は、バージョン3系と呼ばれるシステムなのですが、バージョン1系から7年以上の間に多くの人が手を加えており、プログラムの可読性や保守性がかなり悪くなってしまいました。それをより見通しが利くように切り分けられれば、仕様の変更や新しいチャレンジをしながらも、安心してサービスを運用できる環境が作れるのではないかと考えています。逆に、今手をつけなければ、この先行き詰まることは明白です。そうした問題意識を現場にも伝えて、動いてもらっている状況です。
――現在の仕事を進める上で、エンジニア組織に感じる良い文化はありますか。
富所：例えば、PHPのバージョンアップのような作業にも、きちんとメンバーを割り当てて、他の業務と切り分けて行えているのはいいですね。また、カオナビには私以外にも、バックエンドに明るいエンジニアが多くおり、社内の勉強会などでも活発に情報発信をしています。
社内勉強会には、フロントエンド、バックエンド、インフラ、テストなど、さまざまな領域のエンジニアがチームに隔てなく参加しており、「みんなでプロダクトを良いものにしていこう」という雰囲気がエンジニアチーム全体にあるのを感じます。「スナバ」制度などもそうですが、こうしたことができる余裕があることで、エンジニアは余剰のリソースを使って、ちょっとした改善などに取り組みやすくなっているように感じますね。
松下：業務の中に、リリースを前提とした開発の時間しかないと、エンジニアには余裕がなくなり、自発的に改善に取り組めるような風土を作り上げていくのは難しいように思います。「スナバ」は、個人のスキル向上も目的のひとつですが、最大の目的は、エンジニアの仕事に「余白時間」を設けることにあります。一旦頭を切り替えて、プロダクトを見直したり、改善に手をつけたりできるような時間を作ることで、副次的に何らかの成果が生まれてくることを期待しています。もちろん、具体的な成果があれば、評価にも反映されます。
当社のエンジニア組織も、以前は縦割りの傾向があったようなのですが、「スナバ」や「勉強会」といった施策を通じ、結果としてフルスタック的に動ける人が増えているようです。会社としても、特定の領域や部門に閉じるのではなく、専門性を持ちながら組織横断的に動ける人が、今後さらに増えてほしいと思っています。
現場が「正しい」と思うものを快適に開発できる環境を作る
――最後に、エンジニアとして「カオナビ」というプロダクトの未来にどのように貢献していきたいかを、それぞれにお聞かせください。
南：フロントエンドは変化が激しい技術領域です。私としては、新しいものが出てきたら、まず「試してみる」ことを大事にしたいと思っています。試してみて、「カオナビ」にとって良さそうなものであれば、変化を恐れずに取り入れていく。それを、楽しみながらやっていきたいですね。カオナビには、エンジニアがチャレンジしやすい制度がありますので、十分に活用したいと思います。
富所：カオナビは、働く人たちが生き生きと仕事ができる世の中を作っていくことを目指しており、エンジニアチームも、自分たちがリリースする機能で、日本全体に良い影響を与えたいと願っています。プラットフォームに関わる自分としては、「カオナビ」を作る開発者が、快適に、生産性高く仕事ができる環境づくりを通じて、その実現に貢献していきたいです。
松下：カオナビは、仕事の「仕組み化」や、問題解決におけるロジカルな思考が根付いている会社だと感じています。ビジネスの観点からは些末に見える技術的な問題でも、先々に大きな問題となる可能性があれば、早めにリソースを割いて対応する必要がある。そうした考え方は、経営陣にも理解されています。CTOの立場としては、現場のメンバーが、自分たちが「正しい」と思えるものを、気持ちよく作れる技術や環境を、引き続き提供していきたいと考えています。
――本日はありがとうございました。
