背景

現状のチームの構成としては稼動時間や稼動量が社員のメンバーとは異なる時間帯に稼動している業務委託のメンバーがプロダクトチームでは多いです。要件を決めるのがボトルネックになってしまうケースもあり、またメンバーのより主体的なコミットを引きだすために要求分析の段階からオーナーシップをまかせていこうとしていました。

発生した課題

不安定な状態の要求分析のリードタイムが長くなり期を逃しやすくなった

業務委託になって一定の期間が経ったメンバーは、プロダクトの事情やソースの内部などの把握も進んでいるためプロダクトにたいする知識が大きく不足しているという事は無くなってきました。そのため、一定ステークホルダーの中での要求が安定しているような事例についてはミーティングをして要求分析をしてというのはキチンと実施できていました。

一方で、ミーティングの度にステークホルダー側でまだ考えられていないケースが発生して持ち返りの内容が発生したり、ステークホルダーの中でもどうするべきなのかの解像度が低いような事例では要求分析をする側から「たとえばこういう状況設定の時は、ユーザーはこう行動するとおもうんですが、その時XXだとどうなるかな?」等と様々な角度からステークホルダーの中での解像度を高めていくような補助となる議題を積極的につくっていき、ステークホルダーと共に課題が何であるのかをより改造度を高めていくためのディスカッションが必要になります。そういったディスカッションはともすればいわゆる雑談に近くなるような「飲食店点の現場の人というのはどういうモチベーションで作業をしているんだろう」といったようなフワっとした話題についてふかぼりながらペルソナ象を一緒につくっていき、「だとするとこの機能は使いづらいかもしれませんね」といった結論に辿りつくまで、時間をかけて話しあっていく必要があります。

また、現時点でのユーザー体験としてはどちらの実現方法でも提供できるような価値は同じような機能の場合でも、 プロダクトとしての将来象などを考えたときにユーザーとプロダクトの関係性がどうあるべきかなど、中長期のビジョンを見据えた上での機能の設計判断などが必要となる場合もあります。

こういったプロセスには、単純にテキストには落しづらい日々のコミュニケーションでの接触時間が必要であったり、解像度がたかまるまで一緒にさまざまなケースを考えて悩んだりという時間が必要になります。そういった時間を現状の稼動時間帯の差や稼動時間の違うメンバーとお互いに確保するのが難しかったです。

分析した要求に対する質問に日々答えたり、チームに浸透させたりする業務が重要

字面に落してみると、要求分析をして設計判断をして実際にリリースするまでというのは「要求分析をする」などアウトプットベースでのアクションとして羅列されがちですが、実際にプロジェクトを成功裏に終えるためには、

プロダクトチーム内からの仕様に対する疑問について答える
プロダクトチーム外の人と日々期待値を揃える
要求への改善内容について取捨選択したり、それを採用するかどうか判断するための論点を整理してステークホルダーと議論の場をつくる
プロジェクトのユーザー価値についてくりかえしチーム内外に伝える

など、文字に落ちづらい「日々の営み」のような行動が重要である事に、実際にチームメンバーにまかせてみて円滑に進んでいないプロジェクトをあらためて見て気付かされました。

ふりかえり

稼動量が少ないメンバーに任せる分析はタイムスコープが中長期のものに絞って期待値を揃える

要求分析をコミットの時間に差があるメンバーにも依頼する場合、上で述べたような作業を実際に実施してもらいながら進めていただく事になるので、実際の要求分析自体は合計1~2日分くらいの作業量であったとしても、受けた質問についてその週の終末に返信する、翌週にMTGを開催する等コミュニケーションの帯域を考えると時間は非常にかかるようになります。

そのため、そもそもチームとしての期待値としてプロジェクトの遂行にかかる時間が長くても問題がないような案件をより精査してオーナーシップを任せる必要があります。ここの期待値がズレてしまうと、期待したスパンでプロジェクトが進まずお互いに疲れてしまう事になるかとおもいます。