開発生産性における期待付加価値の評価方法を考える(検討編)
はじめに
COSOJIプロダクト開発部PdM 荻野です。
この記事では、私たちが開発生産性における「期待付加価値」の評価方法を検討した経験を紹介します。開発生産性の評価は、多くの企業やプロジェクトで重要な課題となっており、リソースの最適化や迅速な市場投入を実現するために欠かせない要素です。本記事では、「期待付加価値」という観点からの評価方法について、背景から具体的な手法まで詳しく解説します。
COSOJI社が開発生産性評価に至った背景
開発生産性の評価は、リソースの最適化と迅速な市場投入を目的として行われます。
現代はVUCAの時代と言われ、不確実性や複雑性が高まっています。その中で、いかに効率的に開発を進め、顧客に価値を迅速に届けるかが重要です。私たちは、これまでにレベル1である仕事量の生産性評価を開始し、運用に乗せています。
(レベル1の記事:GitHub + GAS + Google SheetsによるFourKeys計測自動化OSSのご紹介)
次のステップとして、一つ上のレベルでの評価、すなわちレベル2である「期待付加価値」の生産性を評価することに焦点を当てました。
そもそも期待付加価値とは?
「期待付加価値」とは、決まった時間内にどれだけの価値が期待される仕事ができたかを評価する概念です。具体的には、優先度が正しく付けられているか、目的達成に寄与するタスクが選択できているかを重視します。これにより、チームはリソースを最適化し、最も価値の高い成果を得ることを目指します。
期待付加価値の評価手法に関する調査
期待付加価値を評価するための手法は、実施の運用事例が少ないですが、主に優先度を決めるに当たってのフレームワークを利用したものが多いとのことで、様々なフレームワーク調査し、評価方法を検討しました。
優先度を決めるフレームワークであるので、期待付加価値評価だけでなく、優先度を決めるに当たっても有用です。以下に非常に簡潔にまとめたので、参考程度にご確認ください。
1. RICEスコア
- 概要: Reach(到達)、Impact(影響)、Confidence(信頼度)、Effort(努力)の4つの要素を基にしてプロジェクトやタスクの優先度を評価します。
- Reach(到達): どれだけ多くのユーザーに影響を与えるか。
- Impact(影響): そのタスクがユーザーやビジネスに与える影響の大きさ。
- Confidence(信頼度): 推定がどれだけ正確であるか。
- Effort(労力): タスクを完了するために必要な労力の量。
- 評価方法: 各要素に数値を割り当て、スコアを計算します。スコアが高いほど優先度が高くなります。
- 長所: 複数の要素を数値化することで、客観的で定量的な評価が可能です。
- 短所: 顧客満足度に即した評価することが難しいです。
2. ICEスコア
- 概要: ICEスコアは、Impact(影響)、Confidence(信頼度)、Ease(容易さ)の3つの要素で構成され、プロジェクトやタスクの優先度を評価します。
- Impact(影響): そのタスクがビジネスに与える影響の大きさ。
- Confidence(信頼度): 推定がどれだけ正確であるか。
- Ease(容易さ): タスクを完了するのにどれだけ簡単か(労力の少なさ)。
- 評価方法: 各要素に数値を割り当ててスコアを計算し、優先度を決定します。
- 長所: シンプルで迅速なスコアリングが可能で、スタートアップや迅速な意思決定が必要な環境に適しています。
- 短所: 主観的な要素が強くなる可能性があります。
3. 狩野モデル
- 概要: 狩野モデルは、製品やサービスの機能に対する顧客の満足度を評価するためのモデル。狩野モデルは、顧客の満足度を以下の5つのカテゴリーに分類する。
- 当たり前品質:欠かせない機能。欠如すると顧客は非常に不満を感じるが、存在しても特に喜びは感じない。
- 一元的品質:あれば嬉しいが、無ければ不満に感じる機能。
- 魅力的品質:あれば顧客が喜ぶが、なくても特に不満は感じない機能。
- 無関心品質:顧客にとって存在の有無が関係ない機能。
- 逆品質:一部の顧客にとっては好ましいが、他の顧客にとっては不満となる機能。
- 評価方法: 顧客からのフィードバックを基に、各品質カテゴリにタスクを分類します。
- 長所: 顧客満足度を重視した評価が可能。
- 短所: 顧客ニーズの把握が難しく、継続的なデータ収集が必要。
4. MosCow法
- 概要: 以下、4つのカテゴリでタスクの優先度を決定します。
- Must have(絶対に必要): プロジェクトに必須の要素。
- Should have(できれば必要): 必須ではないが、重要な要素。
- Could have(あれば嬉しい): 必須ではないが、あると便利な要素。
- Won’t have(今回は不要): 現在のプロジェクトには不要な要素。
- 評価方法: タスクを4つのカテゴリに分類し、優先度を明確にします。
- 長所: タスクの重要性を明確にし、利害関係者との共通理解を促進できる。
- 短所: カテゴリの境界が曖昧で、特に「Should have」と「Could have」の区別が難しい場合がある。
5. Eisenhower(アイゼンハウアー)マトリクス
- 概要: Eisenhower(アイゼンハウアー)マトリクスは、緊急性と重要性の2軸でタスクを評価し、優先度を決定します。
- 重要かつ緊急: 即座に対処すべきタスク。
- 重要だが緊急ではない: 計画的に進めるべきタスク。
- 緊急だが重要ではない: 他の人に任せるか、後回しにするタスク。
- 重要でも緊急でもない: やらないか、削除するタスク。
- 評価方法: タスクを4つの象限に分類し、優先度を決定します。
- 長所: 緊急度と重要度を基にタスクを視覚的に整理し、直感的に理解しやすい。
- 短所: 主観的な判断に依存し、特に重要度の評価が人によって異なる。
6. 加重スコアリング
- 概要: 加重スコアリングは、決めた観点にウェイトを設定し、合計スコアで優先度を決定する方法です。
- 評価方法: 決めた観点に数値とウェイトを設定し、合計スコアを計算します。
長所: カスタマイズが可能で、具体的な要件に合わせやすい。
短所: 複数の基準に対するスコアリングが時間とリソースを消費する。
調査を踏まえたまとめ
上記を踏まえつつ、以下は考慮に入れる必要があると考えました。
- 人の主観的な判断によらない基準を決める必要があること
- あくまでも生産性を評価するためなので、時間とリソースをかけすぎない基準であること
決定した評価方法
結論、私たちは、RICEスコアと狩野モデルを組み合わせて評価を行うことにしました。RICEスコアは、複数の観点で客観的な評価に強みがありますが、顧客満足度を考慮することが難しいという課題がありました。
そこで、RICEスコアの算出後に顧客満足度に即した評価が可能な狩野モデルを用いて、品質に基づいた評価を行うこととしました。この組み合わせにより、どの品質に開発が寄与しているかも確認し、両者を補完し合う評価が可能となる形としました。
具体的な評価基準
RICEスコアと狩野モデルそれぞれの具体的な評価基準を以下に記載します。
あくまでもCOSOJIというプロダクトに合わせた形での評価方法です。それぞれのプロダクト特性に沿った評価が重要と考えているので、ご参考程度にご活用ください!
また、これから本格的に運用をはじめていくので、課題が出てきたら、改善は進めていく予定です。
RICEスコア
上記の評価方法では具体的なスコア算出方法を記載していないですが、以下となります。
Reach × Impact × Confidence / Effort
このようにRICEスコアは4つの観点で簡易的な優先度評価ができます。
但し、期待付加価値を評価するのは、Effortで割った形である費用対効果ではなく、「どのくらいの価値が期待できる仕事ができたか」を算出したいので、以下となります。
Reach × Impact × Confidence
それぞれの評価基準
-
Reach(リーチ): どれだけ多くのユーザーに影響を与えるか。
-COSOJIというプロダクトは、開発によって誰に恩恵をもたらせるものか(Whyの部分)で考えると、以下の3つになります。それぞれで基準を決めるのが適切と考えました。
- COSOJI依頼者向け
- COSOJIクルー向け
- COSOJI事業者向け- それぞれに点数をつけて、重みをつけて、算出します。
- 例:2×2/5 + 3×2/5 + 3×1/5
- 以下例
- COSOJI依頼者向け
- 1:非常に低い:0-20%
- 2:低い:20-40%
- 3:中程度:40-60%
- 4:高い:60-80%
- 5:非常に高い:80-100%
- COSOJIクルー向け
- 1:非常に低い:0-20%
- 2:低い:20-40%
- 3:中程度:40-60%
- 4:高い:60-80%
- 5:非常に高い:80-100%
- COSOJI事業者
社内の運用担当向けにRICEフレームワークのReachを評価する際は、人数だけでなく、運用効率の向上や業務プロセスへの影響度などを考慮する必要があると考えました。以下が例です。- 1:非常に低い
- 業務効率への影響がほとんどない。特定のタスクにしか適用されず、ほとんどの運用プロセスには関係しない。
- 例:1~2名の担当者のみが関与するマイナーなプロセスの改善。
- 2:低い
- 業務効率の一部にしか影響を及ぼさない。特定のチームや部門の一部のプロセスの改善にとどまる。
- 例:3~5名の担当者が関与するプロセスの部分的な改善。
- 3:中程度
- 業務効率に対して中程度の影響がある。特定のチームや部門全体の運用プロセスを改善する。
- 例:6~10名の担当者が関与するプロセス全体の改善。
- 4:高い
- 業務効率に対して大きな影響がある。複数のチームや部門にわたる運用プロセスを改善し、全体の業務効率が向上する。
- 例:10~20名の担当者が関与するプロセスの大幅な改善。
- 5:非常に高い
- 業務効率に対して非常に大きな影響がある。全社的な運用プロセスの改善が見込まれ、広範囲な業務効率の向上が期待される。
- 例:20名以上の担当者が関与するプロセスの全面的な改善。
- 1:非常に低い
- COSOJI依頼者向け
- それぞれに点数をつけて、重みをつけて、算出します。
-
Impact(インパクト): そのタスクがリーチするユーザーやビジネスに与える影響の大きさ。
- どの主語の機能(What)についても、Whyの部分は以下になる。
- COSOJIクルーのユーザー体験がよくなる
- COSOJI依頼者のユーザー体験がよくなる
- COSOJIの事業者の運用コストが下がる
- COSOJIの売上アップにつながる
- それぞれに点数をつけて、重みをつけて(重みの度合いは相談)、算出します
- 例:2×0.25 + 3×0.25 + 3×0.25 + 4×0.25
- 以下例
- クルーのユーザー体験の向上
- 1:非常に低い
- クルーのユーザー体験にほとんど影響がない。
- 例:クルーの作業効率がa%未満向上。
- 2:低い
- クルーのユーザー体験にわずかな影響がある。
- 例:クルーの作業効率がa~b%向上。
- 3:中程度
- クルーのユーザー体験に中程度の影響がある。
- 例:クルーの作業効率がb~c%向上。
- 4:高い
- クルーのユーザー体験に大きな影響がある。
- 例:クルーの作業効率がc~d%向上。
- 5:非常に高い
- クルーのユーザー体験に非常に大きな影響がある。
- 例:クルーの作業効率がd%以上向上。
- 1:非常に低い
- 依頼者のユーザー体験の向上
- 1:非常に低い
- 依頼者のユーザー体験にほとんど影響がない。
- 例:依頼者の満足度がaポイント未満向上。
- 2:低い
- 依頼者のユーザー体験にわずかな影響がある。
- 例:依頼者の満足度がa~bポイント向上。
- 3:中程度
- 依頼者のユーザー体験に中程度の影響がある。
- 例:依頼者の満足度がb~cポイント向上。
- 4:高い
- 依頼者のユーザー体験に大きな影響がある。
- 例:依頼者の満足度がc~dポイント向上。
- 5:非常に高い
- 依頼者のユーザー体験に非常に大きな影響がある。
- 例:依頼者の満足度がdポイント以上向上。
- 1:非常に低い
- COSOJI事務局の運用コストの削減
- 1:非常に低い
- 運用コストにほとんど影響がない。
- 例:運用コストがa%未満削減。
- 2:低い
- 運用コストにわずかな影響がある。
- 例:運用コストがa~b%削減。
- 3:中程度
- 運用コストに中程度の影響がある。
- 例:運用コストがb~c%削減。
- 4:高い
- 運用コストに大きな影響がある。
- 例:運用コストがc~d%削減。
- 5:非常に高い
- 運用コストに非常に大きな影響がある。
- 例:運用コストがd%以上削減。
- 1:非常に低い
- COSOJIの売上アップ
- 1:非常に低い
- 売上にほとんど影響がない。
- 例:売上がa%未満増加。
- 2:低い
- 売上にわずかな影響がある。
- 例:売上がa~b%増加。
- 3:中程度
- 売上に中程度の影響がある。
- 例:売上がb~c%増加。
- 4:高い
- 売上に大きな影響がある。
- 例:売上がc~d%増加。
- 5:非常に高い
- 売上に非常に大きな影響がある。
- 例:売上が20%以上増加。
- 1:非常に低い
- クルーのユーザー体験の向上
- どの主語の機能(What)についても、Whyの部分は以下になる。
-
Confidence(信頼度): 推定がどれだけ正確であるか。
- シンプルに3段階で評価
- 確度を評価するに当たっては、COSOJIにおいては以下が挙げられると考える
- ログに溜まっているデータから読み取る課題
- 顧客ヒアリング(課題に対するアプローチが適切かも含む)
- 外部環境に合わせたもの(法改正、アップデートなど)
- 以下例
- 1:低い
- 成果が出る可能性は低いが、Reach / Impactのスコアは大きいので挑戦価値はあり。
- 成果が出る可能性が低い=データや顧客ヒアリングが不十分で、多くの仮説が必要。
- 成果が出る可能性は低いが、Reach / Impactのスコアは大きいので挑戦価値はあり。
- 2:中程度
- おそらく成果は出るが、推定値に対する自信が中程度。
- おそらく成果が出る=データや顧客ヒアリングどちらかが不十分などで、多少の仮説が必要。
- おそらく成果は出るが、推定値に対する自信が中程度。
- 3:高い
- 成果が出る可能性が高い。もしくは外部環境に合わせた対応必須なもの。
- 成果が出る可能性が高い=データや顧客ヒアリングが十分に足る。
- 成果が出る可能性が高い。もしくは外部環境に合わせた対応必須なもの。
- 1:低い
狩野モデル
前述でも記載していますが、顧客の満足度を以下の5つのカテゴリーに分類します。
- 当たり前品質:欠かせない機能。欠如すると顧客は非常に不満を感じるが、存在しても特に喜びは感じない。
- 一元的品質:あれば嬉しいが、無ければ不満に感じる機能。
- 魅力的品質:あれば顧客が喜ぶが、なくても特に不満は感じない機能。
- 無関心品質:顧客にとって存在の有無が関係ない機能。
- 逆品質:一部の顧客にとっては好ましいが、他の顧客にとっては不満となる機能。
評価基準は以下となります。
管理方法
評価方法を踏まえて、スプレッドシートにて管理します。
すでに存在しているバックログに対して、当てはめてみましたが、今のところの感触としては以下です。
- 評価項目は多いように見えるが、ある程度の基準を決めたので、時間は要しなさそう。
- 基準があるので、主観的な評価は避けられそう。(但し、狩野モデルは、裏付けとして、定性的もしくは定量的データも踏まえて、評価しないとぶれてしまうのでは?とも思っているので、要注意です。)
最後に
開発生産性の評価は、プロジェクトの成功に直結する重要な要素です。
私たちは、期待付加価値を評価するために、様々なフレームワークを調査した上で、上述の方法を選択しました。RICEスコアと狩野モデルの組み合わせは、客観的かつ顧客満足度を重視した評価を可能にし、生産性向上に寄与できるといいなと考えています。この記事が、開発生産性の評価に悩む方々の参考になれば幸いです。
実際に運用進めてみてどうなったか(まずうまくいったのか、運用上での課題、チームにおける変化や反省点など)、今後の記事で書けたらいいなと考えています。
Discussion