この記事は Akerunのカレンダー | Advent Calendar 2023 - Qiita の 14 日目です。
こんにちは、オフィス開発チームの ps-shimizu - Qiita です。普段はRuby on Railsや Golang での開発をメインにしています。 最近はプロジェクトマネージャーとしても活動を始めて、技術と管理の両面からプロジェクト成功の秘訣を模索しています。
今回は初期段階での検証がなぜ重要か、どうやって実施するかをお話しします。
はじめに
プロジェクトの初期段階での検証は、将来的な問題を未然に防ぐために重要です。 この段階での検証は、設計や実装フェーズでの手戻りを減らし、結果として開発プロジェクトの Quality / Cost / Delivery のバランスを保つことに繋がります。
なぜ事前検証が重要か
プロジェクト初期での事前検証が重要なことは読者の皆さんもご存知だと思います。 この検証が重要な理由は、開発初期に検証を行うことで、リスクや性能のボトルネックを早期に発見できる点です。これにより、リスクや性能改善のための対策を素早く実施することが可能となります。
事前検証を効果的に行うためには適切なリソース（スケジュールや予算）や予算の確保が重要です。検証プロセスに必要なスケジュールや予算をあらかじめ、計画に組み込むことで実施に必要な精度と焦点を保つことができます。事前検証は単なる前準備というよりは、プロジェクトの品質と成功を保証するための投資と考えることが重要です。適切なリソースを確保することで、検証が十分に行われ、その結果をもとにした効果的な対策を講じることができます。
早期にリスクや性能改善の対策を講じておくことで、設計・実装フェーズでの予期せぬ問題によってプロジェクトの遅延や開発コストの増加を未然に防ぐことが可能になります。
少々地味な作業かもしれませんが、プロジェクトのQCDを一定水準満たすために欠かせないプロセスです。
失敗談
読者の皆さんも開発途中にリスクやパフォーマンスに問題があることが発覚し、それによって開発が遅延した経験があるのではないでしょうか？
私自身もプロジェクトの初期段階での事前検証の重要性を理解しておらず、事前検証を実施しなかった経験があります。その結果、設計・実装フェーズでリスクやパフォーマンスに問題があることが発覚し、発覚したリスクの対応やパフォーマンスチューニングを追加で実施することになり、結果開発が大幅に遅延し当初予定していたリリース日に成果物をデプロイできなかった経験があります。
失敗してから変えたこと
開発初期段階に十分なリソースを確保した上で事前検証を実施するようになりました。事前検証は開発内容やプロダクトによって検証内容が異なりますので、ここでは私が直近実施した事前検証の例を紹介します。
事前検証の実施例
事前検証の要なのは「本番相当の環境」で検証を実施することです。 本番相当の環境で検証を実施することで、本番環境で発生するリスクやパフォーマンスの問題を事前に発見することができます。
例1 | クエリのパフォーマンス検証
よくある例です。 クエリを新たに追加するもしくは既存のクエリを改修するのであれば、本番相当のデータ量のあるDBに接続し、追加するクエリの実行計画を取得するかつ実行時間を計測します。 本番でクエリを実行するとリスクがあるようであれば検証環境で本番と同等のレコード量を用意し、クエリの実行計画を取得し、実行時間を計測します。
事前にクエリの性能を確認しておくことで、開発初期にクエリの改修や別のロジックを検討することが可能となります。
例2 | メール送信処理のパフォーマンス検証
新たに機能を追加するのであれば、追加する機能のパフォーマンスを検証するために、本番相当の環境でパフォーマンステストを実施します。 私が直近検証したのは、メール送信処理が所定の時間内に完了するかを開発初期段階で検証しました。仮に、メール送信対象のユーザ数が5000ユーザいたとして「所定の時間以内に5000ユーザに対してメール送信が可能か？」という検証です。
検証の結果、メール送信処理が時間内に完了することは確認できましたが、仮に「メール送信が所定の時間内に終わらない」ということが発覚した場合、開発初期にメール送信処理のロジックをかえるもしくは別の仕組みでメール送信を検討することが可能となります。
例3 | 初導入の技術の検証
初導入の技術の検証でも同じことが言えます。 直近、新たにRedisを既存のAPIに導入するプロジェクトに携わりましたが、APIとRedisのパフォーマンス検証を開発初期に実施しました。 検証内容は、Redisを利用するAPIに対して本番同等に分間15000回リクエストし
を検証しました。 結果はRedis / APIともに十分にパフォーマンスが発揮できることを確認できましたが、 仮にRedis / APIどちらか一方でもパフォーマンスが出ない場合は別の仕組みやロジックを検討する必要があります。
開発初期に事前検証を取り入れた結果
開発スケジュールが遅延した経験を経てからいくつかの開発プロジェクトに携わっていますが、プロジェクト初期に十分にリソースを確保した上で検証を実施するようになってから、未然にリスクやパフォーマンス問題を検知できるので「実装フェーズでリスクやパフォーマンス問題が発覚し追加の対応を実施する」ケースが減り、結果開発スケジュールが前倒しもしくはオンスケジュールで開発を進行できるようになっています。
開発が前倒しやオンスケジュールで進行している要因は、開発初期に不確実性を解消することで、 設計や実装フェーズでの手戻りも少なくなり結果、予測しにくい追加開発が発生しくくなっているためです。
まとめ
今回は事前検証がなぜ重要か、どうやって実行するかを私の失敗談や事例を交えてお伝えしました。事前検証は地味な作業ではありますが、プロジェクトの初期段階で不確実性を減らす強力なツールになります。
適切な検証プロセスを設計し実行することで、プロジェクト進行における不確実性を減らし、問題が発生するリスクを軽減することができます。プロジェクトの成功に向けて、ぜひ事前検証を活用してください。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp
Akerunにご興味のある方はこちらから akerun.com
