ファンクション・スコアリング

プロダクトにおける機能開発の優先順位のコンセンサスをとることは非常に難易度は高いです。当然ながら、多数決で決めることは間違っているわけですが、全体の納得感が必要であり、その納得感がその後のパフォーマンスにも影響をしてきます。そのなかで、どういった順番で開発をすることが望ましいのか？今は何に注力すべきなのか？という点の認識を合わせるためのフレームワークを考えてみました。

この手法で得られること

ちょっとしたディスカッションの手法ですが、この手法は以下のような課題で悩んでいる時に使える手法だと思っています。

・細かい機能の荒い部分がおざなりになり続けているのが気になる
・一部の人だけが気づいている問題をもっと知ってもらいたい
・優先順位をつける時に細かい改善をどうしていいかわからない

前提とする環境

この手法が使える環境として、スクラム開発をしていることが前提となります。なぜスクラム開発が前提となるかというと、スクラムにおいて「機能横断的であること」という点が含まれているからです。なぜこの点が重要なのかは後述します。

完成されている状態でリリースはされない

新しく作るプロダクトは、多くの場合において100%の機能を備えていることはありません。これは工数が足りなかったケースもあるでしょうし、リリースした時点では見えていなかった課題もあります。決してこれは悪いことではなく、特にWebアプリケーションのように開発者側のタイミングでリリースができるものではよくやる手法です。

そしてそのフェーズのプロダクトはリリースしてからがとにかくやることだらけです。バグも出続けるでしょうし、まったく使われなかった機能や作り込みが足りなかった部分、ユーザーからのニーズなどからやるべきことはどんどんと増えていきます。ここでスクラムにおいてはPOと呼ばれる人が優先順位をつけて実施をしていくわけですが、POも人間なのでその人の個性は出ますし見えてこない部分が当然あります。

そういった時に使える手法がファンクション・スコアリングです。

それぞれの完成度の得点をつける

やり方はシンプルです。大きな区分でプロダクトを区分けし、それぞれに対して個別に１点〜１０点のスコアをつけます。そのスコアの定義はシステムとしての品質や、機能が足りているか、UI的に微妙など様々な観点が入って問題ありません。

そしてこのスコアはチームに参加をしているメンバー全員が個別につけていきます。当然、全員の視点は異なってくるのでそれなりにスコアの差分はでてきます。ポイントはこのスコアの差があった時にお互いの認識を話し合うことです。

とある機能について、Aさんが８点に対してBさんは２点と出します。この時点でその機能についての完成度に対する認識が大きくずれていることがわかります。このような機能に対する完成度の認識を合わせることは、普段の雑談ではされますが、だいたいこの手の雑談は自分と考え方が近い人とされてしまうため他の人へ情報が伝わらないことが多いのです。

そういったそれぞれの機能に対してスコアをつけることでスクラムチームに参加をしている人たちの認識のズレを把握するわけです。プランニングポーカーに近いですね。

このスコアをつける時の重要なポイントはこのスコアは誰か個人への得点ではないことです。「機能横断的であること」な前提なのはこのためで、それぞれがつけたスコアがチームとしてのアウトプットに向いていることが大事です。

スコアがずれた場合が重要

スコアがズレたときのやり方が重要です。認識がズレていることはわかったので、なぜそういったスコアをつけたのか？という説明をそれぞれしていくようにします。１つの機能で８点の人と２点の人がいたとしたら、それぞれその得点をつけた理由を説明します。

ポイントはこの得点をチームのコンセンサスとして中央値（ないしは平均値）をとったりしないことです。この作業は明確なアウトプットを出すものではなく、お互いの現状の認識を把握するためのものだからです。

やりかたのまとめ

といった非常にシンプルなやり方ですが改めてまとめてみます。

参加者
開発に携わっているメンバー全員
やること
1. スコアリングする対象の機能をリストアップする
2. 参加するメンバーはその機能に対して、1点〜10点のスコアをつけていく
3. 機能ごとに全員がスコアを発表していく
4. 得点がバラついたときはその際にディスカッションする

以上です。機能や参加をする人数次第で時間はそれなりにかかるかもしれませんが、ある程度稼働したプロダクトにおいてはやってみる価値はあるのかなと思っています。