プロダクト開発を進めていくうちに、開発した機能が実際のユーザに使われないことや開発途中での仕様変更が多くなることがある。ユーザから「使い方が分からない」「活用方法が分からない」「使いにくい」「業務に活かせない」という声が聞こえてきたら、それは仕様と実態の乖離が起きつつある警告信号だ。
\nこの様な状況に陥る原因のひとつに、仕様の意思決定者が適切な人物ではない可能性がある。事業初期はCEOが仕様をすべて決定していても問題はない。このフェーズでは、CEOがユーザに密接に関わっていたり、社内向けプロダクトであれば担当者と共同で作業しているため、どういう課題がユーザや担当者にあったか把握することは容易だ。
\nしかし、事業が進めば組織の規模は大きくなっていく。人が増えると、CEOが行っていたユーザとの対話や担当者との共同作業も別の人に委任していく。こうなってくるとCEOは、ユーザの課題を正確に把握できてていない状態で、意思決定をすることになってくる。この状態で進んでいくと、リリースしたソフトウェアが実態と乖離することが多くなっていく。
\n機能の意思決定者は、実際にその業務や仕事を担当している「担当者」が一番適切だ。担当者は日々業務をこなし、どういう問題があり、どのような機能があれば自分達の仕事が上手くいくかを、一番よく知っている。こうした人物を開発チームに加え、意思決定をしてもらう。
\n「担当者」がtoBであれば客先の従業員だったり、toCであれば一般消費者ということもある。社内に「担当者」が不在な状況だ。こうした場合は、「担当者代理」を社内で専任する。担当者代理は顧客の苦労をよく知っているおり、継続して顧客と直接対話できる人だ。この担当者代理を開発チームに招き入れ、意思決定をしてもらうようにする。
\n担当者は肩書などによらず、開発しているソフトウェアを実際に使い、その業務について誰よりも知識があり、日々その仕事に取り組んでいる人が適任だ。
\n担当者を意思決定者にすることを経営陣と合意する。担当者に適切な権限が無いと、どこか遠慮してしまうことになり決定が正しいものにならない。与える権限には、「どういう機能を作るのか」「どの順番で作るのか」を決める権利、そして「作った機能についてOKかNGか」を判定する権利がある。
\n担当者を開発チーム加え、スプリントレビューの際のデモは担当者に行いフィードバックをもらう。
\nスプリント計画でのスプリントバックログの優先順位も担当者に決定してもらう。 開発チームは担当者が的確な意思決定をできるように協力を惜しまない。