iCAREの開発チーム体制とその課題
この記事は iCARE Dev Advent Calender 2021 1日目です。
今日はiCAREの開発体制作りについてお話してみたいと思います。
なぜ今この話をするか？
2021年11月現在、株式会社iCAREは社員約120名、開発チームは正社員、パートナーあわせて45名の体制です。現在、サービスの急拡大に伴い組織も急拡大をしている過程にあります。当然、急激な変化が起これば、それに伴って様々な課題が次々と現れます。
ただ、それらの課題の多くは業界や会社固有の問題というよりはスタートアップに共通する課題と思われます。なので、これらの課題を共有することは、多くの悩めるスタートアップ企業の開発者にとっても有益と思われます。また、iCAREがこうした課題を抱えていることを知ってもらうことで、そうした課題解決が面白そう、取り組みたい、と考える方が現れて、iCAREに応募くださることも期待しています。
現在の開発体制づくりについてご説明する前に、iCARE開発チームを取り巻く状況についてご説明したいと思います。
iCAREおよびCarelyの歴史
iCAREは2011年に創業し、弊社のプロダクトCarelyは2016年にローンチしております。なので今年(2021年）は、会社設立から10周年、サービスローンチから5周年となります。この間にCarelyは導入社数を伸ばし（2021年10月現在470社）、社員数も約120人にまで急増しています。そして今年2021年、日本の人事部「HRアワード2021」人事労務管理部門 最優秀賞も受賞しました。
そのようにiCAREおよびCarelyは順調に成長をしてきてはいますが、急激な成長の中で様々な課題にも直面しています。
顕在化してきている主だった開発課題を列挙してみます。
顕在化してきている開発課題
顧客の増加や顧客層の変化に伴い、サービスの変化、対応の加速が求められている
サービスの成長とともに、顧客数が増加するのは当然ですが、同時に戦略的な変化もあって顧客企業の規模も変化しています。最近は大手企業の導入が多く、過去に中小規模の顧客からは受けなかった多様で複雑な要望を受ける機会が増えました。主な要望の変化は以下のようなものです。
- 多様な他システムとの連携（SSO、API）
- 多様なユーザー権限体系
- より高いセキュリティ基準
- より安定したサービス提供
- よりスピーディな対応
システムの複雑化
サービスの拡充や要求の多様化に伴い、当然システムは複雑化しています。そのため特定機能の開発をリリースした際に、思わぬところで不具合が出る機会も増えています。可能な限りテストコードを書いたり、リリース前の動作確認を充実させることで、最大限不具合発生を防止する努力をしていますが、それでも事前予測が難しい依存関係により不具合が発生するケースがあります。
また、システムの複雑化に伴い、システム全体を把握することもどんどん難しくなってきています。一人のメンバーが正確に全体を掴むことはほぼ無理な状態に達しており、なんとなく全体像を掴んでいるメンバーも多くはありません。そのため、不具合が発生した時に原因の特定に時間がかかったり、その問題を解決することができるメンバーが限られたりするという不都合も生じています。
高くなる専門性
システムの複雑化に伴い、開発のそれぞれの領域に求められる専門性もより高くなっています。フロントエンド、サーバーサイド、インフラにそれぞれ高い専門性が必要になるため、それぞれの領域の壁を超えて作業する難易度が非常に高くなってきています。そのため、それぞれの領域の間にある問題が、どうしても置き去りになり、そこにおいて非効率が発生したり、作業者のフラストレーションが溜まったりしています。
上記のような要望の多様化、システムの複雑化に伴い、それらの課題を解決する開発体制がまさに今求められています。
求められている開発体制
開発体制として求められている点は、主に以下の点となります。
- 開発要員の増員
- 増員に対応したチーム構成
- チームごとのマネージャー・リーダー
- 領域の間を埋める多様な開発ロール（具体的には、QAE、セールスエンジニア、プロジェクトマネージャなど）
1の「開発要員の増員」、4の「領域の間を埋める多様な開発ロール」は主に採用と関係します。
3の「チームごとのマネージャー・リーダー」は、既存メンバーからマネージャーやリーダーへの昇格や教育、もしくは採用と関係します。
これらの課題も非常に重要なテーマではありますが、今日は2の「チーム構成」に焦点をあててお話したいと思います。
開発チーム構成について
チーム構成の困難さ
よく知られるように昨今エンジニア採用の競争はとても熾烈で、事業の要求にマッチした開発者の採用は非常に難しくなっています。なので当然エンジニア採用は非常に大きなエネルギーを割かねばならないテーマではありますが、同時にそれは、常に潤沢ではない開発リソースの中でなんとか開発をやりくりしなければならない、という現実も意味します。
限られたメンバーで最大限の生産性を発揮するためには、メンバーにとって最適なチーム構成を作り出し、そのチームを有機的に機能させる必要があります。
チーム構成に関するベストプラクティスや知識は世の中にたくさんありますが、メンバーたちはそれぞれ得意領域、苦手領域を持っており、かつ急成長の過程にある私達のような組織では、状況も日々変わっていくので、なかなかそれをそのまま当てはめることは難しいです。また、理想的な体制を作ったとしても、少し時間が経ってしまうと、もうその体制は状況にマッチしないものになってしまいます。
そうした非常に難しい状況の中でも、ベストを探し、それを適用し、メンバーとのコミュニケーションを通して状況をアセスメント（評価）し、チーム構成を最適化していくのは、スタートアップの開発チームの宿命とも言えそうです。
現状の開発チーム構成
現状の開発チーム構成は以下のとおりです。ニコニコマーク一つは一人のメンバーに該当します。
チーム構成の説明
現在アプリケーションエンジニアは3つのチーム（健診、基盤技術、応用技術）に分かれています。これらのチームは、サーバーサイドエンジニア、フロントエンジニアで構成されるフィーチャーチームです。それぞれの役割につきましては後述します。
その他、QAE、SRE、デザインといったファンクションチームがあり、これらのチームはプロジェクト単位で上記フィーチャーチームと関わっていきます。パートナー、技術顧問といった非正社員のメンバーも同様にプロジェクト単位でそれぞれのフィーチャーチームと関わっていきます。
チーム構成の意図
アプリケーションエンジニアが3つのフィーチャーチームに分かれている理由は大きく分けて２つあります。
- Carelyの中で健診関連開発は機能的な独立性を持っており、他機能よりもドメイン知識が必要。そのため、チームとして独立したほうが開発効率が良い
2. 健診関連開発以外の開発は、機能で分割するのは難しい。ただ、一つのチームを構成するにはメンバーが多く、メンバー管理が難しい。
1はフィーチャーチームとして役割も明確であり、人数も適切でまさにフィーチャーチームとしてワークしています。ただし、2については、チーム分割の理由が主に人数的なものであるため、役割の境界が曖昧という問題を持っています。基盤技術チームが認証や権限といったアプリケーションの基盤に関わる開発、応用技術チームが個別の機能に関わる開発、といった具合に、主な守備範囲は定義しているものの、実際の開発は配分的にも、実質的にもきれいに分けることができていません。そのため、責務／境界がやや曖昧という問題を内包しながら、チームを運用しています。
開発チーム体制が抱える課題
現状、上記のようなチーム構成ではありますが、いろいろな問題を内包しています。以下、それらの問題を列挙してみます。
- 事業計画を達成する開発規模には満たない
- 人員に対してリーダー・マネージャが不足している
3. 調査やGUIから操作できないデータ操作オペレーション（SQLやコマンドラインでのデータ操作）などの細々した対応の専門チームが不在
4. メンバー増員による体制変更の連続によるメンバーへの精神的負担
5. サーバーサイド、フロントエンドの人員／業務量のアンバランス
6. SRE、QAE、セールスエンジニアといったニッチなロールの人員不足
7. コア技術、応用技術チームの責務／境界の曖昧さ
7はすでにご説明した、明確な役割を割り当てられないチームの責務／境界の曖昧さの問題です。
オペレーションチームの不在とチームの責務の曖昧さ
3の「オペレーションチームの不在」問題は、7の「チームの責務／境界の曖昧さ」とも関係があります。つまり3のようなオペレーションが発生した時、現状はそれぞれのフィーチャーチームの誰かが開発を止めて対応するのですが、納期厳守のリリースが近いメンバーは、対応が難しいですし、いろいろな事情から誰もそのタスクを拾わないケースがあります。そうしたケースにおいてはマネージャークラスのメンバーが誰か最も適切なメンバーを指名して対応をしてもらうことになります。
ではオペレーションチームを立ち上げればいいかとなると、それも難しいのが現状です。チームを分割するほどメンバーがいない上、開発メンバーとして採用したメンバーにオペレーション作業を専門にしてもらうのは、モチベーション的な難しさもあります。
サーバーサイド、フロントエンドの業務量のアンバランス
弊社チームはサーバーサイドエンジニアとフロントエンドエンジニアが混在するフィーチャーチームで構成されています。ただし、ひとりひとりのメンバーは、基本的にどちらかの役割を担っており、状況に応じてスイッチしたりはしていません。スイッチできないのは、上述したとおり、システムが成熟する中で、それぞれの領域において高い専門性が必要になっているため、簡単に領域を越えて他のロールにスイッチすることができないからです。
ただし、現実の業務量は、現状の人員構成にあわせて発生するわけではありません。現状(2021年11月14日現在）では、サーバーサイドの人員不足／業務過多が顕著となっており、プロダクト開発をすすめる上でのボトルネックになってしまっています。
そのため現在、それぞれのエンジニアが必要に応じて他のロールも担えるようにスキルアップに励み、チームとしても勉強会等でそれを支援しています。ただ、上記の通りそれぞれの領域の壁は高いので、一朝一夕に解決する様子はなく、解決に時間がかかることが予想されます。
体制変更の連続によるメンバーへの精神的負担
またチーム構成とは若干異なる問題ではありますが、体制の「変更」そのものに伴う問題も発生しています。それが4の「メンバー増員による体制変更の連続によるメンバーへの精神的負担」の問題です。
メンバーはコンピューターではないので、チーム構成の変更を精神的負荷なく受け止めることはできません。関係する人の変化、期待される役割の変化に対するストレスは、人によって大きく異なります。対人関係が苦手な人は、チーム構成が変わることによって関わる人が変わり、大きなストレスを受けます。また、事業上の必要性から、本人が希望しない役割を求められたりすることもあります。その場合も、その人はストレスを受けたり、フラストレーションを溜めることになります。
マネージャ不足
チーム規模の拡大においてはある程度そうした問題は起こらざるをえません。その大きな要因は、2の「リーダー・マネージャー不足」にあります。エンジニアの多くは「プログラムコードを書くことでプロダクト開発に貢献したい」というモチベーションでiCAREにジョインしています。なので、リーダー・マネージャーになりたいという意欲を持っているメンバーはそれほど多くはありません。
また、リーダー・マネージャーが不足しているからと言って、簡単に採用できるかというと、そうではありません。そもそもそれを志望するエンジニアが市場に少なかったり、志望者はいてもスキル不足でそれを任せられないケースも多々あります。
そのため、どうしても経験・スキルが十分でなくてもリーダーやマネージャーになってもらったり、リーダーやマネージャーに対する意欲が高くないのにも関わらず、その役割を担ってもらったりする必要が生じます。
私もVPoEとして、可能な限りメンバーのモチベーションや特性、キャリアパスといったものに最大限の配慮をしながら、それぞれの人にそれぞれの役割をお願いしているのですが、組織の都合上、常にメンバーの希望に100%沿うことはできず、日々難しさを感じながら、最善な開発組織になるように頭を悩ませています。
（もしメンバーの方々がこの記事を読んでいましたら、私および開発マネジメント層がメンバーひとりひとりの希望を軽視して、安易にチームを組んでいるわけではないことはご理解いただきたいと切望しております。）
まとめ
iCAREの開発チームが抱えている体制的な課題はこの他にもたくさんあります。ただ、大切なことは、必要な外的／内的要因の変化に対して最善と思われる体制を常に構想・適用し、運用の中で慎重に状況をアセスメント（評価）し、都度必要な調整や変化を加えていくことだと考えています。その際に、メンバーがひとりひとりの個別で固有な特性、ニーズ、希望を持っていることをしっかり踏まえて、都度柔軟に体制の安定化を図ったり、変更を加えたりすることも大切です。
いかがでしたでしょうか？
iCAREの開発チーム体制の今、とその課題ご理解いただけましたでしょうか？
もし、こうした課題にご興味を持ち、一緒に取り組みたいと思われる方がいらっしゃいましたら、ぜひご応募ください。ご応募お待ちしております。
なお、COOもプロダクトオーナー視点でiCAREの開発チームの現状と課題について記事を書いております。そちらもあわせてお読みください。
明日は岩崎さんの「OSSコミュニティ活動のすすめ」です。
お楽しみに！
