フロントエンドの技術刷新と同時に開発体制を再構築
導入事例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に影響することはない。チームが責任を持って開発しているパッケージが他のチームの開発に影響しないようにすることが狙いだ。チームそれぞれが開発において独立性を担保できるので、技術的な挑戦、意思決定がしやすい環境になる」（村田氏）
新体制の有効性を自ら検証、オーナーシップを持つことの楽しさを実感する
現在、フロントエンド開発チームはこの新体制へ移行している最中で、新体制になったら自分自身もオーナーシップを持って開発できるだろうと村田氏は期待を明かした。
だが、村田氏はここで内省する。思えば、以前の体制でも「こういう分野に注力した方がいい」「こうした機能を実装したい」と自分の意見を出している人はいた。主体的に取り組めない原因を組織構造のせいにして、そういうものだから仕方がないと自分を納得させて何も行動していなかっただけではないのだろうか。
村田氏と同様に、半ば諦めて業務に従事していたエンジニアもいるだろう。そうした人たちが新体制になったことで、本当にオーナーシップを持って開発に取り組めるようになるのだろうか。そもそも自分自身がオーナーシップを持って開発に取り組める人材なのかを確かめるため、村田氏は検証の場を探した。そして見つけたのが、リッチテキストエディタの開発だった。
業務内容は、フロントエンド刷新後のページ内で使用するリッチテキストエディタを開発するというもの。kintone本体からは切り出して別のリポジトリで開発するようになっており、フロントエンド刷新で最初にリプレースが予定されている画面ではほぼ使われておらず、影響範囲も小さい。また、CIやテストなども別のリポジトリで開発するため、独立性も高い。
早速、開発に着手した村田氏。画面の刷新を進めるメンバーと実装方針や影響範囲の認識を擦り合わせながら、画面にどういったインターフェースが必要かなどを検討。徐々に必要なメンバーを巻き込んで開発を進めた。品質については自動テストの実装を目標に、これまでQAエンジニアが手動で行ってきたリッチテキストエディタのテスト一覧を再検討し、自動テストに向いている項目を列挙。リッチテキストエディタのテストだけでは完結しないものについては、リッチテキストエディタ単体で確認できるレベルまで分解し、このテストでは何を確認できればOKなのか、どのレベルの品質を担保できれば良いのかといった詳細を詰めながら完成を目指した。
「自動テストを実装して、QAエンジニアとWebエンジニアの両方が品質に対して責任を持てるような仕組みを構築したい」（村田氏）
実際に"少人数のチームで、チーム内で意思決定して仕事を進められる""1つの意思決定が他のチームに影響しない"体制で開発を進めたところ、村田氏は「思いついたアイディアを試しやすく、成功も失敗もすべてひっくるめて自分の責任と捉えられるようになった」と感じたという。何よりも、意思決定の機会が以前と比べて増えたことにより、当事者意識を持って製品とこれまで以上に向き合い、取り組めるようになったという。
「オーナーシップを持って開発するのは楽しいですよ。意思決定の機会が増えて、エンジニアとしての成長も実感できるようになりました」と改めて新体制の良さを実感した村田氏。今後も、開発者や開発チームが自主性を持って積極的にコミットできる体制作りに取り組んでいくと述べた。
