こんにちは、プレックスの種井です。
今回は、PlexJob開発チームにおいて、技術的負債に対して、どのように向き合っているかを紹介したいと思います。
「PlexJob」は物流特化型のダイレクト・リクルーティングサービスです。
- 求職者様が求人を検索するサイト
- 企業の採用担当者様が採用活動を行うための管理システム
を提供しています。
背景
PlexJobはリリースから1年を迎えています。 嬉しいことに1年間ですでに13万ユーザーを突破するなど、急成長のサービスではありますが、まだまだプロダクトとしては、業界特有の課題に対して、仮設検証を繰り返しているフェーズです。
- 開発において、事業間の連携が存在し、複雑なドメイン知識を扱う必要がある
- 複数の外部サービス連携が存在する
- 不確実性の高い、業界特有の課題に対して仮説検証サイクルを回している最中であるため、業務知識やシステムに変化が生まれやすい
ことから、開発を重ねる毎に業務知識と実際のシステムの仕様との乖離や暗黙知が発生することも少なくはありません。
技術的負債が生まれることは仮説検証による学びが得られている、プロダクトが成長している証拠なので、事業としては健全ではありつつも、時間とともに開発効率は低下していきます。
このように検証スピードを維持するため、現状、開発チームとしてどのような取り組みを行っているのかを紹介してきたいと思います。
技術的負債との向き合い方
スプリントのタスクの10~20%を負債の返済に当てる
PlexJobの開発体制は、現在以下のようになっています。
【メンバー構成】
- PO: 1名
- エンジニア: 4名(業務委託・インターン含む)
【開発の進め方】
【リリース】
- タスクが完了した段階で順次リリース(金曜日を除く)
週次のスプリントで、1週間分の開発タスクの10~20%を技術的負債の返済タスクに取り組むことをルール化しています。 また、
- POが技術的負債に対する理解がある
- 後述する棚下ろしを行う段階で、KPIや予定している施策から逆算し、今対応しておくべき課題と優先度を決めている
ことから事業部として重要性を理解した上でルール化ができています。
負債の蓄積と共有を行う
各メンバーが開発タスクを行う中で課題を感じた箇所に関しては、該当タスクの完了前もしくは、直後に
を行い、なるべく鮮度の高い状態で課題に対する情報を蓄積するようにしています。
技術的負債などの開発上の課題に関しては「GitHub Projects」で管理しています。
また、2.の複雑な業務知識などは「ドメインモデル図」を使用してドキュメント化を行っています。
振り返りと棚卸しを定期的に実施する
Qに一度、前Q取り組んだ課題の進捗の振り返りと、バックログや積み残しの課題に対して棚卸しを行っています。
- ロードマップ上、次QのKPIに影響しそうなもの
- 開発者間でボトルネックに感じる度合いの強いもの
のような、観点でGitHub Projectsに起票された課題の優先度づけを行っています。
社内のメンバーで対応できない、技術的専門性の高い課題(弊社の場合、主にフロントエンド)に関しては、専門性のある業務委託のメンバーにフィードバックをもらい、具体的なタスクに落とし込んでいくようにしています。
負債の返済に対しての敷居を下げる
負債の返済には変更の影響範囲が大きくなることもあります。 変更を恐れて、負債の返却を後回しにしないよう、なるべく、不具合を事前に防ぎ、異常を検知する仕組みづくりや、チーム全体としてシステムの変更による影響を認識する場を設けるようにしています。
具体的には、以下のような取り組みを行っています。
- リリースの粒度をなるべく小さく段階的にする
- 各システムで異常検知を行うための監視システムを導入する
- リリース日時と変更点をGoogleカレンダーに自動登録する
- 自動テストやカバレッジの計測、振り返り
- デバッグタイムを設け、スプリントMTG時に開発チーム全員で一斉にデバッグを行う
負債に対して、個々人の目線を合わせる
課題に取り組み、負債を返済する上で個々人の技術的な、習熟度や引き出しの多さが必要となります。 週1回の頻度で実施している勉強会で現在抱えている課題に対する手法や、チームとして不足しているスキルを補うものを中心に選ぶようにし、チームとして目線を合わせる機会を作るようにしています。 今までに実施した勉強会では、DDDやTypeScriptなどを扱いました。
DDD勉強会では、ドメイン知識の共有という課題からはじまり、実際の負債の返済にも活かすことができました。
社内DDD勉強会を通じてトライしたことは、本ブログの記事にもなっているので、ぜひ読んでみてください。
現在抱えている開発上の課題
PlexJobにて抱えている開発上の課題を一部ですが、抜粋して紹介したいと思います。
開発全般
| 課題 | 概要 |
|---|---|
| ライブラリアップデート方針の策定 | Dependabot機能を使用しているものの、アップデートの方針がなく、PRがたまりがちになっているので方針を決めたい |
フロントエンド
| 課題 | 概要 |
|---|---|
| デザインシステムの設計・構築 | 現在、デザインシステムは存在、コンポーネントへのスタイル指定は実装者に任せる形になっているため、統一および再利用性を高めていきたい |
| ユニットテストの導入とカバレッジのモニタリング | プロダクト規模に対して適切なテスト戦略の策定、ユニットテストの導入および、カバレッジ計測を行っていきたい |
バックエンド
| 課題 | 概要 |
|---|---|
| GraphQLのエラーハンドリング方針の策定 | レスポンスコードやGraphQL ErrorのerrorDetailsのデータ構造が実装者によって異なるため、エラー種別毎のレスポンスコードやデータ構造に関しての方針を策定し、コード品質の均一化をおこなっていきたい |
| DBのテーブルスキーマ見直し | リリース当初から検証を重ねる中で不要になったカラム、ドメインモデルと命名やデータ型に乖離のあるカラムの見直しと修正を行っていきたい |
おわりに
今回、PlexJob開発チームにおける技術的負債への向き合い方に関して紹介しましたが、事業の成長により、組織やプロダクトの規模が変わると技術的負債との向き合い方も変化していきます。 また、各論の手法に関しては今回あまり触れませんでした。 今後の取り組みの変化や、手法に関しても継続的に本ブログで取り上げていきたいと考えています。
最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。
上述のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。
