全4061文字
PR

②高品質を求められるシステムでないこと

 ハードウエア製品など利用者が手に取るものや、B2B2C(企業向けにサービスを提供し、顧客企業がそれを一般消費者に提供する形態)のように様々な関係者が登場するサービスシステム、既存システムと連携するようなサービスシステムの場合、高いレベルの品質を担保することが求められます。

 そのため、プロトタイプ開発はアジャイル型でよいとしても、本サービスの開発時には必ず厳密な品質保証テストが必要になります。つまり、途中から必然的にウオーターフォール開発になります。

 ハードウエア製品であれば、リリース前に安全性や耐久性などのテストが必須です。またB2B2Cなどのサービスでは複数の関係者が関わるため、開発やテストが複雑になります。

 例えばホテル予約サービスの場合、サービス提供者、宿泊施設の担当者、予約者という3者分の機能があるはずです。それぞれの機能における仕様の整合性確保や、全体の業務の流れを確認するテストを行う必要があるため、総合テストが必須になります。

 既存システムと連携するサービスシステムであれば、仕様調整のタイミングを合わせる必要がありますし、品質担保のために連携テストをしなければなりません。既存システムとの連携テストは、事前にスケジュール調整、テストケースやテストデータの調整、テスト手順の調整など、多くの取り決めを行った上で実施します。

 連携テストは、一般的には結合テストと総合テストで少なくとも2回、段階的に実施します。必然的に、途中からウオーターフォールのような開発手法にならざるを得ません。

③プロダクトオーナーがいて意思決定できること

 規模や内容がアジャイルに適したプロジェクトだとしても、チーム体制がアジャイルに向いているかどうかを確認する必要があります。

 アジャイル開発の要諦は「素早くモノを作って、要件を満たすこと」と言えます。では、「要件を満たしているか」は誰が判断するのでしょうか。それはプロダクトオーナー(プロダクトマネジャー)です。

 限定的なユーザーにベータ版としてシステムを使ってもらい、ニーズつまり要件を満たしているか判断を仰ぐケースもあります。しかしそれでも意見が割れる場合があり、最終的なリリース可否の判断はプロダクトオーナーが行うことになります。

 プロダクトオーナーがアサインされているものの名ばかりで、実は最終承認者が役員や部長であったりすると、アジャイルはうまくいきません。意思決定に時間がかかる可能性があるからです。役職上位者が多忙で承認のための会議調整に手間取る、事前のレクチャーに時間がかかるなど、多くの作業コストも発生します。