LegalOn Technologies Engineering Blog

LegalOn Technologies 開発チームによるブログです。

リモートチームとして成長し、生産性を上げるための挑戦の軌跡

こんにちは、LegalOn Technologies 検索・推薦チームの志水勝田です。

我々のチームではこの1年をかけてチームビルディングやアジャイル開発に繋がる様々な手法や施策を試し、その成果が徐々に出てきました。今日はその過程を紹介いたします。時間がかかっても必ず成果は出ると思うので、似た取り組みをしようとされている方はぜひ参考にしてみてください!

はじめに

2024年春、「LegalOn Cloud」がリリースされました。これまでの開発では、各機能に専任メンバーを割り当て、定期的な情報共有や技術的な相談を行う方式を採用していました。この開発スタイルは、開発内容が明確な状況下で高いパフォーマンスを発揮していました。しかし、属人性の解消や、不確実な状況への柔軟な対応のため、より効率的でスケーラブルな開発スタイルを追求する必要性が生じました。

検索・推薦チームは全員がフルリモートで働いています。このような環境下での開発生産性向上が重要な課題でした。業務コミュニケーションは主にSlack、Jira、Notionを使用した非同期のテキストベースで行われ、同期的なやり取りは1日1回のDaily Meetingで実施しています。そのため、非同期・同期両方のコミュニケーションの質を高めることを目指しました。

コミュニケーションの質を向上させるため、開発に必要な知識や語彙をチームで共有することを私達は重要だと考えました。そこで、チームで勉強会を実施し、知識の補完を図りました。また、リモートワークや専任メンバーの割り当てによって、タスクの属人化やコミュニケーションの希薄化という課題が生じていました。これらの課題に対処するため、チームビルディングにも注力しました。さらに、チーム内の開発スタイルを改善するため、ふりかえりを通じて見直しと具体的な取り組みの決定を行い、試行錯誤を重ねました。この記事では、1年間にわたるチームの開発スタイル改善とチームビルディング強化への取り組みを、その試行錯誤の過程とともに紹介します!

タイムライン

2023年春

全社的に新プロダクト「LegalOn Cloud」の開発が発表されました。2024年春までの約1年という短期間で、既存製品の「LegalForce」と「LegalForce キャビネ」 に相当する機能を備えた法務プラットフォームの開発が求められました。これは単なる既存製品の統合ではなく、全く新しいプロダクトとして企画されました。この新プロジェクトに注力するため、会社は開発リソースの大部分を「LegalOn Cloud」に集中させる意思決定をしました。検索・推薦チームでは、チーム一丸となって「LegalOn Cloud」の検索基盤の開発に取り組むこととなりました。大人数でのチーム開発には様々な課題があったので、開発スタイル改善とチームビルディングに尽力しました。

www.legalon-cloud.com

2023年夏

この時期は仕事以外の話をチームとしてできているかに課題感があったので、雑談を導入しました(残念ながら運用に愛を注ぐことができず数ヶ月で自然消滅しました)。そしてチームの活動を活性化するために、2週間に1回のふりかえりを導入しました(こちらは形を変え現在も続いています)。ふりかえりによって定例ミーティングでのチームの会話が活性化し始めた、などポジティブな効果がありました。

miro.com

2023年冬

少しチームの雰囲気に慣れ始めたところで、チームの技術力向上と共通の語彙の獲得のために輪読会を始めました。まずはGoogleのソフトウェアエンジニアリングを題材としました。平均すると4人くらいの参加人数でした。30分の輪読会の直前に30分の黙々会(読書ブロック)を入れることで参加率が上がりました。小規模テスト・大規模テストなどの用語がチームの中で共通見解となり、その後の開発の議論に活きることになりました。

www.oreilly.co.jp

また12月には検索技術勉強会がありました。弊社で開催されたこともありチーム全員が参加し、とてもいいチームビルディングになりました。

now.legalontech.jp

2024年春

2024年の4月に「LegalOn Cloud」のリリースを控えていたため、直前はチームとしてかなり忙しく働いていました。 リリースの後は反動のようにチーム活動は少し目に見えるものは減っていました。

「LegalOn Cloud」 の 0から1の開発では、開発対象となる機能が多岐にわたり、既存製品と重複する機能もありました。結果としては、リリース優先のため、特定の機能に精通した開発者がその関連機能を集中的に開発する体制となりました。これにより再び属人性の課題が生じたため、チーム内の情報共有を促進し、スクラム開発を段階的に導入していくことになりました。

2024年夏

5月からチームリードの浅野主導でテクニカルライティング勉強会が始まりました。こちらは題材として入門 読む技術・書く技術にすることをチームで決めました。輪読会形式で本を読む進めつつ、実際に自分たちのDesignDocがロジカルな構造になっているかを添削し合いました。その後、読み手を意識したドキュメント作成のため、DesignDocのテンプレートに想定読者やピラミッド構造を意識しやすい構成を組み込みました。これにより、チームとして分かりやすく伝える書き方や考え方を自然に意識できるようになりました。

www.diamond.co.jp

6月からは、スクラム開発を本格的に始めていくことになりました。

今での開発スタイルを大きく変えるとチームの負担になると考え、まずは週に1回1時間のスプリントプランニングから始めました。

今までは互いにタスクの概要しか把握していませんでした。そこから比べると他の人に伝わるよう自分のタスクを簡潔に説明する必要があります。これ自体がチーム内での情報共有における良いトレーニングになった感触があります。

これを2週間続け、3週目からはプランニングポーカーを始めました。一旦半日分くらいの作業を1ポイントとして、投票しました。互いにタスクの難易度を説明する難しさにチームとして始めて触れました。スプリントの型っぽくなり、ちゃんとスクラムをやる土台ができました。

Scrum Poker Online を用いたプランニングポーカーの使用例

www.scrumpoker-online.org

4週目からは毎日スタンドアップをやるようにしました。これまでは意図的にミーティングを1つも入れない日を設定していましたが、その日もスタンドアップだけはやるようにしました。毎日14時、が体感として刻まれました。

また6月の末からは、GitLabに学ぶ 世界最先端のリモート組織のつくりかたの輪読会が始まりました。本で紹介されていた様々な方法論(例えば、コミュニケーションの取り方や会社のValuesを設定・実践する仕組み)は、リモートワーク中心のチームとして参考になるものでした。

www.shoeisha.co.jp

7月からはスプリントレビューを始めました。最初はチーム内のみで流れを掴み、途中からステークホルダーを呼びフィードバックを得る機会にしました。

8月からはスプリント中のタスクを人にアサインせず未アサインで残し、スプリント中に手が空いた人がとっていく運用を始めました。このあたりから急にスクラムぽくなった気がします。

この運用の変更により、開発内容を熟知している開発者が単独で作業を進める状態から、チームメンバー全体に開発内容を共有し、協力して遂行する形へと移っていきました。短期的には生産性が低下する可能性がありました。しかし、これは属人化を解消し、機能開発の人的なスケーラビリティを向上させるための投資だと考え、この運用方法を採用しました。

内容が複雑なタスクをすぐに取り組むのは難しいため、リファクタリングや小規模なコード変更から始め、徐々に慣れていくようにしました。また、機能の背景や目的については、プランニング、ペアプログラミング、コードレビューを通じて共有することが効果的でした。

またリリース頻度が不定期になっていたので、スプリントレビュー後に必ずリリースするようにするリリースブロックの運用を始めました。そして8月末からはSCRUM BOOT CAMP THE BOOKの輪読会を始めました。参加者が平均で7人になり、輪読会での議論において意見の多様性が広がりました。また、チームメンバーのスクラム開発に対する理解が深まったことで、日々の業務における改善の提案が出やすくなりました。

www.shoeisha.co.jp

チームが変化を感じたこと

スクラムの導入やその他の施策によって、どんな変化があったかを感じたかをチームメンバーにヒアリングしました。

今までは1人が1つのプロジェクトを持っている体制だったため、そこから比べるとチームで開発することで属人化が減り、触るプロダクトが増え、開発の速度が上がったと感じるメンバーが多いようでした。その反面、コミュニケーションの量が増え、特にスクラムイベントが集中する日の負担が大きいこと、また議論の時間が長いと感じるメンバーもいました。

またこのタイミングでスクラムマスターを世代交代したのですが、引き続きチームの中で改善の提案やよりインパクトを出せる働き方の模索が行われていて、チームとしてアジャイルになっている実感があります。

まとめ

本記事では、検索・推薦チームが取り組んだチームの生産性向上とチームビルディングの施策について、その導入過程を紹介しました。

ふりかえりの実施により、チームの開発スタイルにPDCAサイクルを導入し、様々な施策を段階的に試すことができました。輪読会を通じてソフトウェア開発に必要な考え方を継続的に学び、議論することで、チームメンバー間の共通認識が深まったと思います。

また、属人性を排除し、チームとしての成果を最大化するため、スクラム開発を採用しました。プランニング、プランニングポーカー、スプリントレビューなどの手法を取り入れたことで、他のメンバーの課題を積極的に考えるようになり、課題に対する理解が深まったと思います。似たような取り組みを検討されている方は、ぜひ参考にしていただければ幸いです。

Acknowledgement

スクラムをやりたいという志水の声を聞いて全面的に任せてくれたチームリードの浅野、また各種施策に協力しドライブしてくれた検索・推薦チームの皆さんに非常に感謝しております!

仲間募集

今日は我々のチームが1年かけてアジャイル開発に繋がる手法を試し、その成果が出てきた過程を紹介しました。検索・推薦チームやLegalOn Technologies全体では一緒に働く仲間を探しておりますので、ぜひご応募いただけると幸いです。

herp.careers