プロジェクトの規模が拡大するとモヤモヤが増えるワケ
ベリサーブは約40年にわたりソフトウェア品質やソフトウェアテストの領域に特化したサービスを提供している企業である。朱峰氏はプロダクトマネージャーとして、「QualityForward」や「GIHOZ」「InsighTest」などベリサーブのテスト支援プロダクト群の全体統制と普及展開に従事している。またプライベートでも、ソフトウェアテスト／品質に関する日本最大級のシンポジウムJaSSTが運営する「JaSST nano」のお世話係を務める、テスト大好き人間だ。
ソフトウェアテストをする目的はさまざまあるが、その中でもメインの目的になり得るのが、プロダクトの価値を明らかにすることである。
だが、その価値の共有について、「プロジェクトの規模が大きくなり、プロジェクトに携わる人の数が増えると、メンバー全員が同じ方向を向かなくなるなど、プロダクト価値の共通認識の醸成が難しくなる」と朱峰氏は指摘する。
朱峰氏自身もプロダクトオーナーとして携わったプロジェクトで、「みんなが同じ方向を向いていないことに、モヤモヤを感じたことがある」と話す。プロダクトの立ち上げ期はビジネスオーナー、プロダクトオーナー、UXリサーチャー、UIデザイナー、iOSエンジニア、バックエンドエンジニアの計6人でプロトタイピングを中心にプロダクトを検討していた。「当時は月に1回の仕様検討会やユーザーテストを実施し、開発は1日1スプリントで、日々優先順位を議論していました。まさに6人でワンチームという形で、スピーディーにフィードバックループを回すことができ、価値探索がうまくできていました」と朱峰氏は振り返る。
このフェーズでは特に何の不満もモヤモヤも発生することはなく、「価値のある活動ができていた」と朱峰氏。だが開発が本格化したことでPOも1人ではまかなえなくなり、「POチームを組成することになった」（朱峰氏）という。またモバイルチームはメンバー増強。バックエンドチームはBFF（Backend For Frontend）チームに改め、体制を増強。その裏では組み込みのチームや基幹チームなどの複数のチームとも連携した。
「このように規模が大きくなったことで、マニュアルテストを自動化しきれず、専任のQAチームを設けました」と朱峰氏は説明する。テストだけではなく、プロセスもしっかりプロジェクトとして定義した。例えばユニットテストはコンポーネントチームに任せ、開発チームが自分たちの裁量でやりやすいような形にした。複数のコンポーネントが絡むインタフェース部分は自動化し、結合テストを実施。また全体のつなぎの部分を、専任のQAチームが担当するという形にテストのプロセスを整理したのだ。
「従来はちょっとしたアップデートにも1年かかっていた重厚長大な開発が、このようなプロセスに改善したことで、2カ月に1回市場にローンチできるようになりました」と、この時点では手応えを感じていたという朱峰氏。アウトプット量も非常に安定していた日々を積み重ねていたが、PO目線でのモヤモヤが積もってきたという。
そのモヤモヤとは「ちょっとした既存機能の改善が、他の新機能開発に対して優先順位を調整しきれずになんとなく先に進んでしまう」「リファインメント・プランニングで開発内容を合意できていたつもりが、出来上がると微妙に違うように感じ、手戻りが微妙に増えてきている」といったものだ。このようなモヤモヤが表層化したのは、チームに分割されることによって、ワンチーム感が薄れたことにより、コミュニケーションやプロセス、マインドセットなど、いろいろな問題が複雑に絡み合う状況があったからだと朱峰氏は当時考えていたという。
