ドキュメントは最低限、会議は2つだけ――開発に全集中したプロジェクトの品質はどのようにして保たれたのか：リクルート事例に見るエンジニアとしての価値の高め方（3）

リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を探る本連載。前編に引き続き「本開発フェーズ」にフォーカスし、不確実性が高いプロダクト開発で高い品質を維持しつつ、高速にプロジェクトを進めるポイントを解説する。後編となる今回は「実装に集中するためのプロジェクトモニタリング」と「テストによるプロダクト品質の保証」について。

[今井宏明，リクルートテクノロジーズ]

　変化の激しい市場の中で新規プロダクトをリリースするために、リクルートテクノロジーズが実際の開発事例を基に「どのような開発プロセスや体制を作り上げていったのか」「どのような技術選定や設計をしていったのか」を紹介する本連載。

　前編に引き続き、「本開発フェーズ」にフォーカスし、高い品質を維持しつつ、高速にプロジェクトを進める方法について説明します。後編となる今回は「実装に集中するためのプロジェクトモニタリング」と「テストによるプロダクト品質の保証」です。

機能実装が最優先だからこそプロジェクト全体のモニタリングが重要

　どのようなプロジェクトも「進捗（しんちょく）を正確に管理し、メンバーの状況をリアルタイムで共有する」ことは重要です。今回のプロジェクトでは下記2つの方法で進捗把握と情報共有をしました。

• 週次ミーティングでプロジェクト全体をモニタリングする
• 「Slack」を使って担当者間での情報をリアルタイムに共有する

プロジェクトの状況は週次の会議でチェック

　今回のプロジェクトは開発者の作業効率を上げる（＝実装時間を確保する）ことを優先しました。そのため、ドキュメント作成を最低限の設計に絞り（前編の記事）、会議も極力少なくして進めました。

　会議は「アプリチーム会」と「リーダー会」の2つです。アプリチーム会は開発メンバーの進捗を共有する場です。アプリチーム会で共有した進捗情報をリーダー会に持ち込み「プロジェクト全体で見たときに問題がないか」「後工程でリスクとなる箇所がないか」を確認しました。

最低限の会議で開発者の実装時間を確保する

急ぎの確認はチャットでリアルタイムに共有

　実装を進める上ですぐに確認が必要な情報についてはSlackを使いました。例えば下記のような内容についてはすぐに情報を共有し、全員が情報をキャッチアップできるようにしました。

• プロジェクトの方針に関する情報
• 実装中の機能の仕様変更
• 仕様に関する確認
• コーディング規約やアーキテクチャなどの相談

　他にもささいなことや気になるポイント、困りごとなどもSlackで積極的にやりとりし、メンバー間で情報を可視化しながらプロジェクトを進めました。

テストによるプロダクトの品質保証

　今回開発したプロダクト「リクナビ HRTech 採用管理」は採用業務を管理するという業務の特性上、個人情報が含まれているデータやファイルを扱います。そのため、単体テストや結合テスト、シナリオテストなどの各種テストで「堅牢（けんろう）で安全なシステムである」ことを証明しなければなりません。

各工程のテスト観点

　特に重点的に対応した2つの非機能要件テストです。

1. セキュリティテスト
2. パフォーマンステストとストレステスト

　では各テストの工程について説明します。

1．ユーザー情報をしっかりと守るための「セキュリティテスト」

　リクナビ HRTech 採用管理で扱う個人情報は、氏名や連絡先、履歴書情報、面接状況など、採用に関するセンシティブなものです。これらの情報が漏えいした場合、ユーザーに大きな損害を与えてしまいます。そのため、セキュリティテストは特に力を入れました。

　リクルートテクノロジーズには、リクルート全社のセキュリティレベル強化を目的とした「RECRUIT RED TEAM」があります。セキュリティに関する専門家が集結しており、脆弱（ぜいじゃく）性情報の収集や対策の広報、リクルート内部のプロダクトのセキュリティチェックなどを担当しています。RECRUIT RED TEAMは当初組織として発足しましたが、本記事執筆現在は内製エンジニア組織の活動の一つとなっています。

　このRECRUIT RED TEAMの担当者にもプロジェクトの早い段階から参画してもらい、「セキュリティ観点でのバグ」の抑制に取り組みました。まず、実装と並行してセキュリティ観点での設計、レビューを実施し、機能ごとにバグがないかどうかチェックします。次に「セキュリティテストフェーズ」を設けてプロダクト全体の脆弱性検査を実施するといったフローです。

「RECRUIT RED TEAM - 脆弱性管理のベストプラクティスとスレットモニタリング」から抜粋

　セキュリティテストで見つけた問題はGitHubの課題管理機能「Issue」で管理しました。

　発見した問題をセキュリティ担当者がIssueに残し、アプリチームのリーダーがそれぞれの問題に担当者をアサインします。修正後はセキュリティ担当者がチェックし、Issueをクローズするというフローです。他の実装者が同じバグを作ることがないように、対応したIssueについてはSlackやアプリチーム会で適宜共有しながら進めました。

問題はGitHubのIssueで管理

開発者一人一人がセキュリティの重要性を認識

　RECRUIT RED TEAMのようなセキュリティに詳しい担当者にプロジェクトの早い段階から関わってもらうことで、開発者一人一人がセキュリティの重要性を認識できます。設計や実装時のバグが発生しにくくなり、もしバグを埋め込んでしまったとしても早期に検知、対応ができるメリットがあります。