タスクを省略しても、スケジュール短縮につながるとは限らない――「品質を維持しつつ、高速にプロジェクトを進める4つのポイント」：リクルート事例に見るエンジニアとしての価値の高め方（2）（2/2 ページ）
リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を探る本連載。第2回目となる今回は「本開発フェーズ」にフォーカスし、不確実性が高いプロダクト開発において、高い品質を維持しつつ、高速にプロジェクトを進めるポイントを2回に分けて解説する。前編となる今回は「機能開発の目的から考えるアサイン方式」と「進め方の道しるべとなる開発プロセス」について。
進め方の道しるべとなる開発プロセス
アサイン方法を決めたら、次は「開発プロセス」です。
“機能によるアサイン”をしたので、機能実装の方式や進め方は個人に任せました。一方でプロダクトの品質を保証し、スケジュールに遅延なく開発を進めるための「プロセスとルールの整備」は必要だと考えていました。
特に今回は、仮説検証フェーズにてプロダクトに一定の需要があることは分かっていましたが、市場全体の需要は未知数でした。このように不確実性が高いプロダクト開発では、プロダクトのプロトタイプをなるべく早く開発し、実際に触わりながら試行錯誤を繰り返すプロセスが重要です。
ドキュメント作成に割く時間を最小限にして開発に時間を割く
試行錯誤を繰り返すためには、できるだけ開発に時間を割く必要があります。そのため、ドキュメントの作成対象を絞りました。理解がしやすく単純な要件に対しては設計ドキュメントを作成せず、閲覧や操作を制限する「ユーザー権限の制御」やシステムの利用状況をレポーティングする「分析機能」など、複雑な要件に対してのみ設計ドキュメントを作成しました。
一般的な開発プロセスでは、実装フェーズへ入る前に設計ドキュメントを書くことが多いと思います。設計ドキュメントはシステムの振る舞いを定義することはもちろん、ステークホルダーやメンバー間のコミュニケーションを円滑化し、コミュニケーションコストの削減や認識違いのリスク回避を目的としたツールです。設計フェーズにて要件を整理して実装方針を検討し、実装フェーズでの懸念点をなくすためにも重要な工程です。
今回のプロジェクトはプロダクトを最速で形にしてフィードバックと修正のサイクルを回す想定でした。そのため、全ての機能に対して設計ドキュメントを作成すると、要件が変更になった場合のドキュメント更新のコストが増えていき、開発のスピード感を失ってしまいます。
今回のプロジェクトはステークホルダーやメンバーが少ないことから「認識違いはコミュニケーションで防止できる」と判断し、本来やりたかった「プロダクトを形にして仕様を精緻化する」ことを優先しました。
コードレビューで仕様の整合性をチェックする
ただ、実際に進めてみると開発途中やレビューのタイミングで仕様の検討漏れが発覚するケースがありました。その場合は開発担当者と企画担当者が素早く連携し、1つずつ着実に仕様を決め、決定事項として設計ドキュメントに残しました。そして最終的にプロダクト全体の整合性を保証するためのフェーズを用意することにしました。
今回のプロジェクトでは、コードレビューを「開発メンバー内での仕様の整合性を保証するための重要なチェックポイント」として定義し、通常よりも重点的にレビューすることにしました。
コードレビューでは具体的に下記のポイントを確認しました。
- 定義された要件や仕様が実装されているか（要件や仕様の保証）
- 他機能との関連性で認識違いが起きている箇所がないか
- 将来的にメンテナンス性が低くなるコードになっていないか
一般的なコードレビューでは要件よりもコードに注目し「コードとして正しい状態になっているか」にフォーカスしてレビューすることが多いとは思いますが、今回のプロジェクトでは「要件と仕様の保証」についてもフォーカスしました。
レビュワーは対象のブランチからソースコードを取得し、ローカル環境で実際にビルドします。企画担当者が作成した要件メモや実装途中で設計したドキュメントに目を通し、ローカル環境のプロダクトを操作しながら「プロダクトとしてやりたいことが正確に実現できているか」を確認しました。
タスクを省略しても、スケジュール短縮につながるとは限らない
別のケースとして、システムの仕様について再設計が必要になったことがありました。ビジネス要件に関しては問題なかったのですが、「情報の最新化のタイミングをどうするか」「ユーザーが同時に処理した場合の制御方針やエラー表示をどうするか」といった細かいシステムの仕様が詰め切れていなかったのです。
結果的にはそれほど大きな問題とならず、リカバリーできました。振り返ると大きな問題とならなかった理由は次の3点です。
- 問題が発生したタイミングですぐに開発担当者と企画担当者が連携して問題を解消できていた
- 検討が必要となったケース自体が少なかった
- メンバーのスキルが高く、多少のスケジュール遅れがあっても取り戻せた
上記の理由から今回はうまく進めることができましたが、今後を考えるとリスク検討はもう少し改善の余地があると考えています。特に「ドキュメントは最低限の設計に絞る」という点については「最低限の設計としてドキュメントを残す部分はどこなのか」をさらに細分化して言語化する、例えば「成果物定義」をして関係者間で認識を合わせておけばリスクを減らせたと思います。
実際にプロジェクトを進めて得た学びとしては、「タスクを省略しても、スケジュール短縮につながるとは限らない」ということです。
何かを得るために既存のタスクを省略すると、それと対になってトレードオフとなる事象（リスク）が発生します。何かを改善するために仕組みを変更したり省略したりする場合は、「それによってどのようなリスクが発生するか」を把握し、リスク対策が検討できているか、その対策が許容できる範囲なのかを事前に判断していく必要があります。
今後、同じようなプロジェクトが立ち上がった際には、これらの学びを生かしてより良い開発プロセスを検討していきたいと思っています。
今回のまとめ――エンジニアとしての価値を高めるポイント
- アサイン方式を適切に使い分けることでチームのコンディションを維持する
- 「プロダクト全体の整合性を保証するフェーズ」を設けることで品質を保つ
- 仕組みを変える場合は「トレードオフとなる事象は何か」を明確にすることでリスクを減らす
後編は「実装に集中するためのプロジェクトモニタリング」「テストによるプロダクトの品質保証」について解説します。
筆者紹介
今井宏明
株式会社リクルートテクノロジーズ エンジニアリング室 ＨＲ領域プロダクト開発部 ＨＲプロダクト開発１グループ
前職は、SIerでWebアプリケーション開発やクラウドインフラ構築を担当。
2015年にリクルートテクノロジーズに入社し大規模サイトのオフショア開発、フロントエンドチームのリーダーを経て現チームに参画。
プロジェクトリーダーとしてチームをリードしつつエンジニアとしてのスキルアップを目指して奮闘中。
Copyright © ITmedia, Inc. All Rights Reserved.