できるプロダクトオーナーの仕事術【後編】

バックログには、実現すべき機能のほかに非機能要件も含める必要がある。非機能要件とは、性能（レスポンスタイムなど）や脆弱性（セキュリティ）、拡張性などに対する要件である。これらもプロダクトバックログとして作成し、ある程度システムの構築ができた段階で、検証とチューニングを行う。プロダクトオーナーを務める人は必ずしもITの知見が十分にあるとは限らないため、非機能要件の洗い出しは開発チームと共に行うことを推奨したい。

開発されたシステムやソフトウェアの品質は、開発チームのスキルに大きく依存する。経験豊富な開発者であれば、最初から十分に良質なプログラムを組むことができるが、それでも要件追加や変更、コーディングミスなどにより、プログラムが複雑に入り組んでしまうことは考えられる。複雑なプログラムは、機能の追加・改修コストが大きくなり、不具合の発生も増えてしまう。結果的にプログラムの品質は低下し、改修が大変なシステムが残るだけとなる。

前述の通り、小さな開発を繰り返し、機能の追加や変更を行っていくことで、プログラムは複雑さを増してしまうため、リファクタリングを行う。本来、リファクタリングは開発チームが作業の中で実施するものではあるが、機能の実装を優先するあまり、十分なリファクタリングができていないケースは多い。そのため、プロダクトバックログとして定期的なリファクタリングを加えることを推奨したい。その内容とボリュームは開発チームが検討するものではあるが、明示的にタスクとして用意することで、時間を確保し、十分に良質なプログラムを維持できる。継続的に開発をしていくシステムであれば、なおさらこのような取り組みをしていくことをお勧めしたい。

予定していたシステムの構築がある程度実現できたら、リリースを準備する。最初のリリースは必要最低限の機能が実装できたタイミングで行う。アジャイル開発の理想形としては、スプリントが完了した時点でプログラムがリリース可能な状態であることが求められる。そのため、理論上はすぐにでもリリース可能なはずであるが、実際には十分な業務観点のテストができていない、脆弱性や耐障害性が企業内の基準を満たせないなど、確認が不十分なケースが多い。また、日本におけるソフトウェア開発は、リリース後の不具合発生を避ける傾向が強く、業務システムであればなおさら、混乱を起こすようなことは許されない。そのため、リリース前に改めてテストを行う期間を設け、リリースの最終判断を行うほうが安全である。

プロダクトオーナーは、リリース前テストの結果を確認し、プロジェクト内の最終リリース判定を行う。自社の手続きに則り、別途承認を得る場合もプロダクトオーナーが主導する。アジャイル開発におけるリリースは複数回行う場合が多いため、段階的なリリース計画として、関係部署への説明をしっかりと行う必要がある。

リリースが完了したら次のリリースに向けた開発を継続する。この時にリリース計画に変更がある場合は、ステークホルダーや開発チームにも内容を共有し、バックログも再整理する。

プロダクトオーナーは、システムを考え、ビジネスを考え、プロジェクト内外との連携を行うため、高い視点を持ち、しっかりとした考察と判断が求められる。このように書くと非常に高スキルを求められると思われるかもしれないが、プロダクトオーナーに求められるスキルは、必要な情報の整理と関係者に働きかけて協力を得ることにある。ITや業務の有識者から意見をもらい、システムを形作り、作業の段取りを決めていく。アジャイルチームは、コミュニケーションの密度を高くして、それぞれのスキルを合わせることが良い結果を産む原動力となるので、是非プロダクトオーナーはチームの軸となって活躍されることを期待したい。

エンタープライズにおけるプロダクトオーナーとして、具体的にどんなスキルを求められるか、こちらをご覧ください。

▼前回の記事はこちら▼

できるプロダクトオーナーの仕事術【前編】

プロダクトバックログの最終責任者として、どのように適切なプロダクトバックログを作成すればよいのか、また、常に変化している開発状況の中でどのように作業の段取りを決めていけばよいのか、...　続きを読む