組織・プロセス・技術 - フロントエンドの生産性向上への複眼的アプローチ

2023年9月、ファインディ株式会社は「フロントエンドの開発生産性」と題したオンラインカンファレンスを開催。第一線で活躍しているエンジニアを招いて、フロントエンド領域における開発生産性を向上するための組織づくりや戦略について語っていただきました。

本稿では、弁護士ドットコム株式会社にてクラウドサイン事業本部Product Engineering部マネージャーを務めている芳賀将至さんのセッション「組織・プロセス・技術 - フロントエンドの生産性向上への複眼的アプローチ」の内容をご紹介します。

クラウド型電子契約サービス「クラウドサイン」を手がける同社は、コロナ禍で事業が急成長。サービスの成長に伴い、フロントエンドエンジニアのメンバーは3年で5倍に増えました。人員増加により、できることが増えた一方で、対応すべき課題も発生。解決に向けて、技術、プロセス、組織といった三つの領域で行われた取り組みとは？

■プロフィール
芳賀将至（はがまさし）/@Hivesbee
弁護士ドットコム株式会社　クラウドサイン事業本部
Product Engineering部マネージャー
クラウド型電子契約サービス「クラウドサイン」のエンジニアリングマネージャー。SIer、Web 会社を経て、一人目のフロントエンドエンジニアとして、2017年弁護士ドットコムに入社。クラウドサインの最初のフロントエンドエンジニアとして設計から実装までを担当。QA チームの立ち上げなども行い、現在は EM として組織成長に従事。

サービス成長に伴う増員で、エンジニアメンバーが5倍に

芳賀：弁護士ドットコムは、リーガルテック領域を中心に「弁護士ドットコム」「税理士ドットコム」「BUSINESS LAWYERS」「クラウドサイン」を運営している会社です。

その中で、私が担当しているのはクラウド型電子契約サービスの「クラウドサービス」です。2015年にリリースしたサービスで、コロナ禍で急成長を遂げており、現在は250万以上の企業や自治体で導入いただいています。

サービスが急激な成長を遂げたことによって、組織にもさまざまな変化がありました。

はじめに、どういった変化があったのかについてお話しします。事業としては、サービスを利用されるユーザー層に変化がありました。リリース当初のユーザー層は、中小企業やフリーランスの皆さまが中心でした。しかし、コロナ禍以降は大企業や官公庁、地方自治体の皆さまにも導入いただいています。プロダクトについては、追加機能の開発が増加し、よりセキュリティを重視するようになりました。

技術トレンドで見ると、jQueryが王様だった時代から黎明期のフレームワーク（backbone、Angular.jsなど）を経て、現在はモダンフレームワーク（React、Vue、Angularなど）に変化しています。技術トレンドと連携する形で、アーキテクチャもSPAやSSRを取り入れるようになり、最近はPESPAなども使用しています。

このように、事業成長に伴いさまざまな面が変化しています。その変化を考慮しつつ、プロダクトの価値を高め続けるためには、新機能を開発して顧客体験を向上する必要があります。また、プロダクトの成長や技術トレンドの変遷によって技術が負債化している部分を解消し、開発者体験を向上する必要もあるでしょう。顧客体験と開発者体験の2軸を両輪で回していくためには、エンジニアの人員を増やさなくてはいけないと考えました。

具体的な数値は控えますが、フロントエンドエンジニアのメンバーはここ3年で5倍の人数に増えています。Web系、SIer、QA、EC系、SaaS系、フリーランスなど、さまざまなバックグラウンドを持つメンバーがジョインしてくださいました。

急激に人数が増え、できることが増えた一方で、課題も発生しました。最初に起こったのは、それまではドキュメントを読めば解決できていた、あるいは暗黙知で情報が共有されていた部分が全く通用しなくなるというもの。加えて、バックグラウンドの違いから、対応が異なるケースも発生しました。具体例を出すと「ある人は変数面をキャメルケースで書くけれど、別の人はスネークケースで書く」といったものですね。設計レベルの話で言うと、コンポーネントの分け方に対する考え方にも差がありました。

この二つが噛み合わさると、情報のギャップが生まれてしまいます。結果として、コードベースも技術方針もバラバラのものが出来上がってしまい、いわゆる“タックマンモデルの混乱期”に突入してしまいました。

本日は、混乱期に突入した私たちが「技術」「プロセス」「組織」という三つの領域で行った取り組みについてお話しします。

トレンド変化に伴う痛みには「地層」をキーとして対応

芳賀：まずは技術レベルで行った取り組みについてお話しします。クラウドサインは、適宜Vueのトレンドを取り入れてきました。最初はjQueryからVue、さらにTypeScriptを導入し、vue-property-decoratorも導入。その後、Composition-APIも導入しました。

トレンド変化に伴う痛みは当然あり、TypeScriptを導入したタイミングでは、VueとTypeScriptがうまくかみ合わず、Reactの方が相性がいいと言われていた時代もありました。vue-property-decoratorに関しては、書き味が異なる点で苦労しましたね。Composition-APIは概念が異なるため、技術のキャッチアップに一定の時間を要した記憶があります。

こういった痛みに対してどのように対応したのかというと、トレンドが変わるごとに方針立てをして、ソースコードのトリアージを行いました。

上図のように、ソースコードは、トレンドが変わるごとに地層のように積み重なっていると思います。私たちの場合で言うと、jQueryで書かれていた地層の上にVueを投入した地層があり、その上にはTypeScriptを導入した地層もあります。

そこで、トレンドが変わるごとに方針立てを行い、各地層に対する対処法を決めていきました。現在は新規機能についてはComposition-APIで開発しますが、vue-property-decoratorに関してはリプレイスを進める、既存のTypeScriptは一旦そのまま置いておくといった形にしています。

SPOF対策として、レビュアーの育成にチャレンジ

芳賀：続いて、プロセスレベルでの取り組みについてご紹介します。

クラウドサインでは、チケット着手→開発→コードレビュー→マージ&デプロイといったシンプルな開発プロセスをとっています。その状態で人が急激に増えた結果、下図のような事態が発生しました。

チケット着手は問題ないのですが、先ほども触れたように情報のギャップがあることで、方針が異なるコードが誕生してしまったのです。それにより、コードレビューに大きな負担がかかる形となってしまいました。どれほどの負荷だったかというと、エンジニア全員が100名だとした際のフロントエンドメンバーの数は50名ほど、着手できるチケットは100ほどありました。マージリクエストの件数も100ほどあったのですが、レビュアーはメンバーの10分の1である5名しかいませんでした。例えではありますが、この数字を見れば、コードレビューが単一障害（SPOF）となっていたことが伝わるのではないかと思います。

これは、ノウハウの伝搬スピードよりも組織成長スピードが大きく上回ったことが原因で発生したものでした。

ノウハウの伝搬には、すぐ対応できるものとできないものがあります。例えば、コーディングに関するものは、コードが仕組み化されていれば特別なことはせずともノウハウを獲得できるはず。しかし、設計にまつわる部分については、レビュアーとして一定の場数を踏む必要があると思います。

レビュアーを増やせばいいのですが、場数を踏めていない方が増えてしまうと、レビュー品質の低下に繋がってしまうでしょう。とはいえ、レビュアーを増やすことが急務でもあるのも事実。

そこで私たちは、サブレビュアーというロールを新しく作り、レビュアーの育成に取り組むことにしました。

レビュアーとサブレビュアーは、師匠と弟子のような関係性です。二人一組で一つのマージリクエストに対してコードレビューを行い、キャッチアップしていただくプロセスを構築しました。

狙いは三つあり、一つ目はレビュアーと一緒にコードレビューを行うことによるスキルトランスファーの促進です。二つ目は伝搬スピードの促進、三つ目はボトルネック化の早期解消です。ちなみに、サブレビュアーの習熟度が上がったら、レビュアーになってもらいます。最初はレビュアーが1名しかいなかったのですが、現在はレビュアーが2名になり、計2名のサブレビュアーを育成中です。この取り組みを通してレビュアーがどんどん増えていけば、効果を実感できるようになっていくのではないかと考えています。

長期的な展望としては、全員がレビュアーになった暁には、サブレビュアーの仕組みを撤廃するつもりです。再発防止策としては、新入社員のオンボーディングにてレビュアーの育成に関する項目を組み込むのもいいかもしれないなと考えています。

プラクティスを補助線として活用し、乳化に成功

芳賀：最後に組織レベルの取り組みについてご紹介します。メンバーが増える前のクラウドサインは、スクラム開発チーム体制でした。エンジニア、デザイナー、PdM、QA、SREからなる、スクラム開発チームを組成し、スクラムの習熟度を上げるために、メンバーは大方固定していました。新機能開発をメインに行い、その傍でプロダクト改善に従事してもらうというスタイルですね。

メンバーが増えた後は、複数のスクラム開発チームが発生したため、相互連携を促すためのPMOという組織を作りました。これは、各スクラム開発チームが各種情報連携をとり、スムーズに開発できるようにフォーカスする仕組みです。

PMOをつくったことで、開発をスムーズに進められるようになりました。しかし、価値提供にフォーカスできていない、といった新たな問題も発覚してしまって……。

開発組織に求められているのは「価値」をつくることです。とはいえ、開発中に小石につまづくこともありますよね。例えば、新機能を開発している際に、画面のレイアウトが崩れてしまったため、以前に開発したものも含めて修正する必要が出てきたとします。これは小石レベルのものだと思いますが、共通コンポーネントの振る舞いが変わってしまい、基盤部分にも手を入れないといけなくなった場合はどうでしょうか。それだと改修コストも影響範囲も大きくなってしまいますし、小石のように見せかけた岩レベルのつまづきですよね。そういったつまづきが重なると、価値提供の阻害要因になってしまいます。PMOをつくった時点では、「価値提供にフォーカスできているか？」という問いに、「YES」とは答えられない状態でした。

そこで「価値提供にフォーカスするためには、どうすればいいのか？」と考え、ひとまず開発体制に補助線を当ててみることにしました。補助線として活用したのは、組織設計についてまとめられている書籍『チームトポロジー』です。

書籍の中では四つのチームタイプが紹介されていて、ストリームアラインドチームは基本的に価値提供にフォーカスするチームです。他の三つに関しては、ストリームアラインドチームをサポートする関係性だと捉えていただければいいのかなと。

これら四つのチームタイプをクラウドサインの開発組織に例えると、開発しているのがストリームアラインドチームで、それらを支援するPMOがイネイブリングチームに当たります。

上図を見ていただくと、ストリームアラインドがつまづかず、価値提供にフォーカスするためにはプラットフォームチームが欠けているのがわかります。そこで、フロントエンドプラットフォームチームをつくることにしました。

フロントエンドプラットフォームチームの目的は、先ほどお話ししたような価値提供の阻害要因を排除し、ストリームアラインドチームが価値提供にフォーカスできる状態をつくることです。

フロントエンドプラットフォームチームの実際の取り組みとしては、バグfixや標準化といった足回りの改善やトリアージしていたコードの改修を実施。結果として、ストリームアラインドチームでは解決が難しい大規模な課題に対して戦略的に対処できるようになりましたし、ストリームアラインドチームが価値提供にフォーカスできるようになりました。

ここでポイントとなるのは、課題を解決するプロセスの中で自然とプラクティスに適応した、という点です。『チームトポロジー』をはじめに、組織に関する有名な書籍はいくつもあります。ただ、それらをそのまま自分たちの組織に当てはめると、歪みのようなものが発生してしまいがちです。プラクティスをそのまま当てはめるのではなく、課題を解決するための補助線として扱うことで、うまく乳化できるのではないかと思いました。