オフショアから内製へ─新たな開発のフローとDevOpsの探求
「建設現場を魅力ある職場に。」というミッションを掲げ、建設現場で働く人たちのマッチングサービス「助太刀」と採用サービス「助太刀社員」を展開し、建設業の人手不足の解消、生産性向上に貢献している株式会社助太刀。建設業界では慢性的な人手不足の問題を抱えている。月澤氏によると、建設業界における仕事のやり取りは、職人や工事会社が互いの関係を活用し、仲間内や既知の取引先の中で仕事を回しているのが一般的であるという。既存の関係者内での情報しか持っていないため、人によっては「仕事がない」といった状況に陥る。この状況をITサービスによって解消しようとしているのが助太刀だ。
当初、サービス開発はベトナムで実施していた。しかし、ユーザー数が増加するにつれ、その要望に迅速に対応するための策が求められた。この背景のもと、CTOの月澤氏の指導で開発の内製化とスクラムの方法論の導入が行われた。今回の講演では、過去半年にわたるプロセス改善の取り組みに焦点が当てられた。
助太刀の開発チームは元々、多数のバグや長い開発リードタイムに悩まされていた。リリース日やリリースの頻度が定まらず、最も長い場合では数カ月に1回、早い場合では数週間のペースであった。開発の終了までの期間が長かったため、デプロイも平均して数カ月に1回という状況であった。加えて、当時は特定の機能の要望に応じて即座に開発を行うというスタイルで、綿密なロードマップが存在しなかったのだ。
数カ月に1回の開発サイクルでは良質なサービス提供は望めない。不具合を減少させ、リードタイムを短縮し、デプロイ頻度を増加させるため、ストーリーポイント（ユーザーストーリーを完了するために必要コスト見積）、SLO（サービス稼働率）、4Keys（ソフトウェアデリバリーの速さと安定性の指標）の測定に基づく改善活動を行うこととした。
2週間を1スプリントとするスクラムを実施し、1週目から2週間の期間で各タスクにストーリーポイントを適切に設定し、作業量を測定する体制を築いた。その過程で開発部内にQAチームを設立し、スプリント終了後に必ずQAを実施する流れを確立した。それに加えてユニットテストを各開発チームで徹底する取り組みを推進した結果、品質は徐々に向上し、バグの発生が少ないプロダクトとして進化してきた。以前と比べてリリース頻度やサイクルが安定したが、更なる開発の効率化のための手法を探求。DevOpsの観点から、4keysの計測および改善を試みることとなった。
4keysの測定でわかった、アプリチームのタスク粒度の課題
4keysのデプロイ頻度とリードタイムは、製品の製作開始からユーザーに提供するまでの指標である。障害率や復元率、未復元時間はリリース後の製品の安定性や品質を示す指標だ。短いリードタイムは、デプロイを早く、そして頻繁にできることを意味する。一方で、デプロイ頻度を増やすためには、小さなタスクを速やかに開発する必要がある。これらの指標は相関関係が存在する。
月澤氏は「助太刀の場合、リードタイムが特に長かった」と振り返る。リードタイムを短縮すると、細かいプルリクエストを作成し小規模なリリースが可能となる。結果として、サービスのバグ発生や障害が一定の範囲に収まると考えた。
しかし、改善前に実際の状態を知るため、特定のツールを使用して状況を把握した。3月の1カ月間を対象に分析したところ、コミットからマージまでの時間が非常に長かった。プルリクエストが提出されても、不要であると判断されるものや、放置されているものが多く存在した。本来、不要なタスクは削減し、ユーザーに価値を提供するタスクに時間を割くべきである。無駄なものや、放置されているものを確認し、改善の方向性を模索した。
4keysを計測すると、バックエンドチームにおいては、ユニットテストを書く文化がしっかりと醸成されているため、リードタイムは短縮され、一貫したコードの書き方がなされている一方で、iOS／Androidのアプリチームはテストが不十分であることがわかった。アプリチームにはテストを整備するためのリアーキテクチャやリファクタリングが必要だった。
アプリチームの現場の課題に、タスクの割り当てがあった。プルリクエストやタスクの粒度が大きいため、実装やレビューに時間がかかり、すべてのレビューができないため品質が低下するという状況だった。そのため、タスクの粒度を小さくする方針を採った。最も重要なのはレビューの単位や機能の最小単位の最適化である。その単位をチーム内での議論を通じて決定し、その粒度での取り組みを始めた。
アプリチームのこれまでのアプローチでは、「バックエンドAPIの呼び出し部分」「フロントのロジック」そして「UIの表現」の3要素が1つの機能として扱われていた。改善後は3つのレイヤーごとにプロジェクトを切り分ける方法を採用した。チームはGitHubを利用しているが、プルリクエストにおいて変更箇所が一定のサイズを超えた場合に警告が出る機能や、特定の期間でマージされていないプルリクエストをSlackで通知する機能を導入した。毎週金曜日に振り返りの時間が設定され、未完了タスクの原因やタスク分割の反省などが行われている。
計測によって生じたエンジニアの心理的ハードルを対話で解消
4keysの計測を行った際、エンジニアの心理的ハードルが現れた。これには、自分のプルリクエストの進行速度が他者より遅いことへの過度な意識や、自分たちが監視されていると感じることなどが挙げられる。実際、エンジニアはコミットの粒度やタイミングが異なり、すべてのアウトプットが同じ速度でないため、それが他者に比べて遅いと認識される可能性がある。この問題への対策として、チームのエンジニアメンバーに対して丁寧な説明を行った。
出社する体制のため、対面でしっかりコミュニケーションしたのだ。月澤氏は「4Keysはあくまで指標であり、健康診断的に使うもの。助太刀の最終的な目的は建設業のユーザーに価値を返すことです。背景や目的を明確に説明し、チームメンバーが納得する形で取り組むことが大切」と語る。
ストーリーポイントを小さくする取り組みにおいて、その粒度の違いによる課題が発生した。短時間で終了するタスクと長時間を要するタスクが同じストーリーポイントを持つことで、タスクの粒度にばらつきが生じたのだ。これを解決するために、チームはストーリーポイントの基準を定期的に見直し、振り返りの際に適切なタスクの調整を行っている。
一方、リファクタリングやライブラリのアップデートなど、一括で変更が必要なタスクに関しては、4Keysの指標によって細分化することが困難であることがわかった。このような場合には、そのタスクを除外した。結果として、アプリチームではタスクの処理速度の向上といった成果が得られた。
月澤氏は「このプロセスを通じて、アプリのコードやアーキテクチャについての再評価の必要性を感じるようになりました。特にコードのリファクタリングや設計の見直しを行うことで、現在の依存関係や課題をより明確に把握することができ、やって良かったと思いました」とコメントした。
開発プロセスの効率化によって得られた時間を技術負債の解消に充てる
続いて月澤氏は、開発チームにおける技術負債の返済について説明を始めた。助太刀では建設業で働く人向けのスマホアプリ（ネイティブアプリ）に加え、工事会社が利用するWebサービスを提供している。これらのバックエンドはモノリシックな構造になっているが、コードだけでなく、ビジネス面でも一貫性を保つ必要がある。したがって、アプリとWeb版の統一性や依存関係の管理が必要となる。
スマホアプリの変更については、毎日のアップデートがユーザーにとって必ずしも良いとは限らない。ある程度の機能をまとめてリリースする方が良い。開発のサイクルは2週間のスプリントで行われている。このサイクルは変更しておらず、リードタイムの短縮を主目的としている。その結果、開発の効率が上がり、1スプリントの中で行えるタスクが増加した。空いた時間で次の新機能の開発や、見えてきた技術的な課題の解決ができるようになったのだ。
技術負債の解消には大きな変更が必要で、それには多くの時間がかかる。そこで、まず短期的に課題を整理し、今後の大規模な変更を可能にするための前準備としての短期的なリファクタリングを開始することを決定した。この方針をもとに、チーム全体での取り組みを開始することとなった。
iOS／Androidのアプリチーム、Webフロントチーム、バックエンドチームそれぞれが現在抱えている技術的負債や改善点をスプレッドシートにまとめる作業を進めた。各チームでまとめた情報を基に、全チームが集まって議論を行い、依存関係やタスクの優先順位、開発順序などの認識合わせを行った。これにより、技術的負債返済のロードマップを策定した。返済を進める際のルールとして、スプリント内での作業時間の約30％を技術的負債の返済に充てること、余った時間が出た場合の作業内容はプロジェクトマネージャーと相談することなどを設定した。
技術的負債返済は重要だが緊急性は低い。だからといって放置はできないため、一定の時間は割り当てることとしたのだ。さらに、ロードマップは開発部全体で共有・管理され、それに従って運用されている。一連の取り組みの成果について月澤氏は次のようにコメントした。
「積極的なコミュニケーションを取ることで、お互いの行動や考えを理解することができました。エンジニアとして、直したいと思う箇所を改善できない時は、正直、ストレスを感じることもあります。しかし、今はチーム全員で取り組むことを前提とした良い雰囲気ができたのはすごく良かったと思います」
