フロントエンドの技術刷新と同時に開発体制を再構築
導入事例2万社を超えるサイボウズの主力製品「kintone」は、人事や労務、営業など、開発の知識がない現場の人たちでも業務に合ったシステムを作ることができるクラウドサービス。そのkintoneでは現在、フロントエンドを刷新するプロジェクトが進んでいる。10年以上前からフロントエンド開発で使用してきたClosure Toolsを、Reactを始めとした技術スタックに移行するという内容だ。
このプロジェクトでは技術的な刷新と同時に組織の再構築を進めている。村田氏が目指しているのは「開発者一人ひとりがオーナーシップを持って開発できるチーム作り」だ。
オーナーシップを持つ人とは、どんな人か。同プロジェクトに携わるkintone開発チームのWebエンジニア、村田氏は、「当事者意識を持って物事に取り組んでいる」「責任感を持っている」「自分の能力を客観的に評価できる」「周囲に助けを求めることができる」人のことを指すと定義する。
その村田氏はこれまでオーナーシップを持つことなく開発していたと、「Developers Boost」の講演で振り返る。
「当時は開発チームのエンジニアが3〜5名ほどのチームに分かれて、プロジェクトマネージャーと密にコミュニケーションを取りながら製品を開発していた。顧客理解度の高いプロダクトマネージャーが開発する機能の優先度を決め、エンジニアは優先度の高い順に機能を開発していた。顧客が求めている機能を確実に届けることができていたため、ここ数年間のkintoneは魅力的なアップデートを施すことができている。多くの人たちが知恵を出し合い協力したことで、魅力的な機能を提供できるようになった。一方で、開発チームへの認知負荷は年々増加していた。kintoneは開発が始まってから10年以上経過したアプリケーションで、全体を理解するには多くの時間を要する。しかし、開発チーム全体のミッションに基づき割り振られたタスクを何でもこなさなければならなかったため、常にアプリケーション全体を見る必要があった。そのため、チームの強みを持つことや、発揮することが難しいと感じていた。また、1つの機能を開発するにしても、その意思決定がチーム全体に及ぶため、チームメンバー全員に合意をとる必要があった。人にもよるが、自分はメンバー全員に合意をとる負担が大きく、提案を躊躇ってしまうこともあった」（村田氏）
挑戦することへのハードルが高いと感じる日々が続き、気づけば村田氏は言われたことだけ取り組むようになった。徐々に自分で考えることを放棄するようになったという。
「このままではダメだ」と自身の現状に危機感を覚えた村田氏は、開発体制の改善を提案し、同じような問題意識を抱えているメンバーと議論を重ねた。その結果。フロントエンド刷新プロジェクトから体制を立て直すことが決まった。
既存の開発体制の課題は2つある。1つは、各チームの担当範囲が不明確で、チームごとの強みを発揮しにくくなっていたことだ。チームの担当範囲が不明確な状態で優先度の高い順に流れ作業的にタスクに着手していたため、常にアプリケーションの全体を把握する必要があり、チームの認知負荷が大きくなっていた。もう1つは、１つの意思決定がチーム全体に及んでしまうことだ。物事を進めるにはチームメンバー全員の合意を得る必要があり、能動的に動くことへの心理的な足かせになっていた。
村田氏を含むフロントエンド刷新プロジェクトのメンバーは、これら課題を解決するには、開発チームに自治権や自主性を持たせるような体制に再構築する必要があると考えた。
ポイントは、チームやアプリケーション単位でタスクを分割して影響範囲を明確化し、決定に対するスコープを小さくして、個人が挑戦する際のハードルを下げること。これを実現するために、2つの取り組みが行われた。
1つは、それぞれのチームが自分たちで意思決定できる体制作りだ。
新しい体制では、6名以下推奨、10名以下必須の職能横断チームを複数作り、開発チーム全体のミッションにつながるミッションおよび、ミッション達成に必要なタスクはそれぞれのチームが考える。チームの担当範囲を明確にして、チーム内のコミュニケーションは密に、チーム間のコミュニケーションをある程度制限することで、チームの独立性を高め、チーム内で意思決定して開発を進められる体制にする。
もう1つの取り組みは、チームそれぞれが開発の独立性を保てるよう、アプリケーションに境界を設けることだ。
「具体的には、複数のパッケージを共通のリポジトリで管理するMonorepoを活用している。例えば、team1が管理しているディレクトリの中にkintone-rteというモジュールがある場合、team1がkintone-rteの開発に責任を持つことになる。これをteam2が管理しているディレクトリの中で使用したい場合は、team1がkintone-rteをnpm registryなどにアップロードし、 team2はkintone-rteをnpm registry経由で利用したいバージョンを指定して使う。この方法であれば、team1がkintone-rteに新しい変更を加えたとしても、team2がバージョンを上げなければteam1の変更がteam2に影響することはない。チームが責任を持って開発しているパッケージが他のチームの開発に影響しないようにすることが狙いだ。チームそれぞれが開発において独立性を担保できるので、技術的な挑戦、意思決定がしやすい環境になる」（村田氏）
