こんにちは。現在プロダクトマネージャー兼ソフトウェアエンジニアとしてfreee人事労務の開発を行っている金山（@tkanayama_）です。私は現在、労務担当者の勤怠締めにまつわるペインを解消するための「勤怠モニター」という機能を開発しており、この開発を通して特にプロダクトマネージャーとして様々な学びを得ています。今回はその中から、「スコープの絞り方」について考えたことを整理します。
時間・予算・品質・スコープのトレードオフ
プロジェクトにおいて、時間・予算・品質・スコープはトレードオフの関係にある場合が多く、私も日々このバランスに頭を悩ませています。
これについて、書籍「アジャイルサムライ」では以下のように主張されています。
時間と予算、それから品質は固定されたものとみなし、スコープを柔軟に扱うのだ。
たしかに実体験としても、苦渋の決断としてスコープを切り詰めざるをえない場面が多いように思います。
「機能を削る」というスコープの絞り方の問題点
「スコープを絞る」というと、ほとんどの場合、機能を削ることにより実現すると思います。
しかしながら、安易に機能を削ることは、誰にも刺さらないものを作ってしまうことに繋がります。 たとえば開発予定の機能A, B, C, Dからスコープを狭めるとして、
- ユーザーセグメント1にとっては、 機能 A, B, D が揃って初めて実用できる。
- ユーザーセグメント2にとっては、 機能 B, C, D が揃って初めて実用できる。
- ユーザーセグメント3にとっては、 機能 A, C, D が揃って初めて実用できる。
という状況において、機能A, B, Cだけをスコープとした場合、誰も使ってもらえないことになります。
ここでは、たとえば「今回のメインターゲットはユーザーセグメント1だから機能A, B, Dを作ろう」のように適切なスコープの取捨選択ができるのがベストですが、これには精緻なユーザー理解が求められます。まさに、PdMの腕の見せ所と言えると思います。
「公開範囲を絞る」というもう1つのスコープの絞り方
前述のように、「機能を削る」というスコープの絞り方はPdMとして避けて通れないですが、非常に難易度が高いこともまた事実です。
そこで、この記事ではスコープの絞り方の別のアイデアとして「公開範囲を絞る」という方法を深掘りします。「公開範囲を絞る」とは、機能を一部のユーザーだけが使える状態にする（というより、むしろ「一部のユーザーが使えない状態にする」と表現した方が正確です）という意味です。常に適用できるわけではありませんが、いくつかの条件を満たしたとき、選択肢に入れる価値があると思っています。
この方法が上手くいくための条件を説明するために、私が取り組んでいるfreee人事労務の例を挙げます。freee人事労務は「事業所」という単位で契約され、1つの事業所が複数の従業員を持ちます。従業員数が多い事業所を大規模事業所と呼びます。
freee人事労務は、大部分が小〜中規模事業所から構成されます。これは、「スモールビジネスを、世界の主役に。」という私たちのミッションにも現れています。
一方、割合としては少ないですが、大規模事業所も存在します。大規模事業所特有の問題として、パフォーマンス問題があります。パフォーマンスが悪いことにより、「動作が遅すぎて使い物にならない」という体験をユーザーにもたらします。
以上の前提を1枚の図として表現すると、以下のようになります。
パフォーマンス悪化を防ぐための手法として、例えば
- 余計なクエリが発行されないようにする
- 実行結果をデータベースに永続化しておく
- インフラを増強する
- などなど
が挙げられます。
しかし、これらはいずれも対応に工数や費用がかかる場合が多いです。
そこで、前述の「公開範囲を絞る」という戦略が活きてきます。開発した機能を小〜中規模の事業所に限定して公開することにより、
- 大部分のユーザーに価値が届く*1
- パフォーマンスが問題にならないユーザーにのみ機能が公開される
- 開発者は、パフォーマンス改善の問題を一時的に回避*2できるため、そのぶん早くユーザーに価値を届けることができる
という効果が得られます。
私が現在取り組んでいる勤怠モニター機能でもこの方法を用いて、まずはパフォーマンス問題を回避して大部分のユーザーにリリースしました。その後、処理の非同期化などを実施してパフォーマンス問題によるユーザー体験悪化を緩和し、全ユーザーに機能を展開しました。最初のリリースから全面展開までの間に、実際に機能を使ったユーザーからフィードバックをいただき機能を改善することができたため、この手法を用いた価値があったと感じています。
おまけ： 公開範囲を絞るロジックの具体的な仕様
一口に「公開範囲を絞る」と言っても、具体的な方法がいくつか考えられます。以下、「従業員数がN人以下の事業所にのみ公開する」という場合の仕様を考えます。
オンデマンド方式
機能を利用する時（加えて、機能の導線を表示する時）に、従業員数を取得して利用可否を制御する方法です。
- メリット
- 厳密に利用を制御できる。
- デメリット
- 従業員数は増減しうるので、「昨日まで使えたのに今日から急に使えなくなった」という状況が発生する。
allow list方式
事前に「この機能を利用可能な事業所のリスト」を作成しておき、リストに入っている事業所だけが機能を利用可能にする方法です。
- メリット:
- 「昨日まで使えたのに今日から急に使えなくなった」という状況が発生しない。
- デメリット:
- 新規にサインアップした事業所は機能を使えない。
- あとから従業員数が増加した場合、N人をオーバーする可能性がある。
deny list方式
事前に「この機能を利用不可能な事業所のリスト」を作成しておき、リストに入っている事業所だけが機能を利用不可能にする方法です。
- メリット:
- 「昨日まで使えたのに今日から急に使えなくなった」という状況が発生しない。
- 新規にサインアップした事業所でも機能を使える。
- デメリット:
- あとから従業員数が増加した場合、N人をオーバーする可能性がある。
- 新規にサインアップした事業所が大規模事業所だった場合、機能を使えてしまう。
おわりに
今後も、プロダクトマネジメントとソフトウェアエンジニアリングの中間みたいな記事を書いていけたらと思っています。
