開発施策を意思決定することについて
こんにちは、SCOUTERの鍬です。人材紹介会社向けのSaaS事業SARDINEを開発しています。
昨年7月のプレスリリースから急成長しており、最近は社内のステークホルダーが増え、取り扱う課題の文脈が深くなり、開発チームの規模が大きくなってきています。
今回は、そのような事業状況の中で、開発施策を選定するまでの取り組みで大事にしていることを書いてみたいと思います。
1.期限付きのタスクをスケジュールに埋める
ビジネスチームからの依頼の内、「○月末までに機能が必要」などと会社運営上期限が決まっているタスクがあります(特に法務・経理などバックオフィス関連に多い)。最終的には、全ての施策を洗い出した上で優先順位を付けてリソース配分を検討しますが、施策選定の一歩目として、期限付きのタスクを埋めるところから考えています。
2.解く課題を見極める
このステップが一番重要です。そしていきなりですが、課題には2種類しかありません。明確に言語化されていない課題と、明確に言語化されている課題です。
前者の場合は課題の深掘りが必要です。数値分析やヒアリング、プロトタイピングなどで課題を明確にする必要があります。課題が不明確な場合のほとんどの理由は「情報不足」です。そのため、社内外のステークホルダー達とのコミュニケーションが非常に重要です。情報収集を徹底して行います。
そして、課題を深掘った結果「開発してみないと分からない」となった場合に初めて、開発を行いますが、このときに2つ、気をつけます。仮説に謎の自信を持たないことと、解決策ありきで考えないことです。仮説である以上、作り込み過ぎないことが大事です。検証は必要十分な開発に留めます。また、課題を深ぼっていたはずが、いつの間にか課題を置き去りにしてしまうことが良くありますので注意が必要です。
後者の場合は、周辺に関連する課題が漏れていないか、優先度がどれくらいの課題かを検討します。実は期限付きのタスクというのは、後者のパターンであることが多いです。課題が明確で完全に解決しきりたいときに解決策を作り込みます。
3.工数を見積もる
優先度が高く、開発で解決すると決めた課題について、解決策のWFを作ります。ここにおけるWFの目的は、ストーリーポイントで何ポイントくらいかを見積もることです。この見積もりは、実際の工数の±20%くらいのの精度で良いと思います。そのため、WFのレベル感としては、関連するDBスキーマの変更やデザイン量などをイメージできればOKです。一番知りたいのは、今のチームだと何週間で開発できるのかです。
また、WFを書くと同時に、課題と解決策が綺麗に繋がっているかを確認します。工数が膨らんでいる時は怪しいです。課題の理解不足や、課題分割の必要性を認知できた場合は、1つ前の「課題を見極める」に戻ってやり直します。
4.優先順位を決める
これは最後のステップです。課題の優先順位が付いていることはもちろんですが、それがそのまま解決の優先順位になるとは限りません。
仮説検証の調査期間を設ける場合、技術投資を盛り込む場合、不具合(バグ)の対応、メンバーの入社予定などを加味して、各週の取り組み内容に関する意思決定を総合的に行います。
他にも、チームの成長や、作業効率を上げる視点でも、各週の開発内容を色々と工夫できると思います。
まとめ-大事な気持ち
WFやバックログをどんなに綺麗に書けても、解くべき課題を見誤ってしまえば、それは全て暖簾に腕押し、いくらコストをかけてもリターン0になってしまいます。
本当にやるべき今一番の課題に取り組めているか、を考え続けることは、プロダクトオーナーが1人で背負わなければならない責任と役割だと思います。改めて、スクラムチームのROIを最大化することがプロダクトオーナーのミッションですね。
今回書かなかったこと
この記事では、書かなかったこと（字数の都合上、書けなかったこと）がいくつかあります。
・プロダクトバックログアイテムを書き起こすことについて
・プロダクトバックログアイテムをチームに複数回共有することについて
・デザイン/プロダクトに対するFBをいつどのようにするかについて
・毎週リリースする、スクラムスプリントの勘所について
これらの内容はまた別の機会に書ければと思います。
最後に
弊社では一緒に働く開発チームメンバーを募集しています。もし興味を持っていただけたら、応募/DMなど頂けると幸いです。
この記事が気に入ったらサポートをしてみませんか？