BizOps アドベントカレンダー 2024、15日目の投稿です。
14日目は株式会社マネーフォワードの荒井さんによる「マネーフォワードの BizOps これまでとこれから」でした！15日目は「BizOps が取り組むプロジェクトの評価と優先度」と題して、READYFOR 株式会社で取り組んでいるプロジェクトの評価方法と優先度の付け方、またそれをどのように個人の評価に反映させたのかをまとめます。
はじめに
弊社では BizOps で取り組むプロジェクトを以下の項目に分けて数値化し、計算することで優先度を付けています。各項目は精緻に求めるのではなく5段階前後でランク付けし、それを足し合わせることで評価と優先度にしました。1年半ほど運用していますが、今のところある程度機能しているのかなと思っています。この記事では各項目の具体的な内容と、どのような考えでこれに至ったのかをまとめます。
- 業務改善効果
- 緊急度
- 事故発生可能性
- 事故影響度
- 工数
評価 = 業務改善効果 + 緊急度 + 事故発生可能性 x 事故影響度
優先度 = 評価 / 工数
課題感
営業やカスタマーサクセスと異なり、BizOps のプロジェクトは売上に直接的に繋がることはありません。また売上に繋がったとしても、BizOps の改善の影響で上がったのか、運用メンバーの頑張りで上がったのか、判断するのは難しいところがあります。一方でコスト削減を目的としたプロジェクトも、正確に削減効果を測ろうと思ったら①現状の運用にかかっているコストと②改善後の運用にかかるコストを計測する必要があり、その計測にもかなりのコストがかかります。そのため売上の向上、コストの削減どちらにしてもプロジェクトの評価をするには工夫が必要という課題感がありました。
BizOps を立ち上げたばかりの頃は、課題が明確なことも多く、このような評価をしなくても自分の感覚が実際の優先度とずれることはあまりありません。しかし社内の要望が増えてやりたいプロジェクトが増えてくると、優先度を付けるのも難しい上に後回しになるチームへの説明も難しく、何かしらの基準を作る必要がありました。組織がもう少し大きくなるとまた違った課題が出てくると思いますが、弊社の場合は BizOps 専属のメンバーが1,2名程度なので、精緻に求めるコストの方を優先して解決することにしました。
| 評価項目 | 課題感 |
|---|---|
| 売上の向上 | 直接的に売上の向上に繋がることが少ない。またどこまでが BizOps の成果なのか判断が難しい |
| コストの削減 | 以下の2つを計測して改善前後の差を求める必要があり、計測自体にコストがかかる ① 現状の運用にかかっているコスト ② 改善後の運用にかかるコスト |
評価項目
上記のような課題感があったため、弊社では感覚と精緻な計測の中間的な評価方法として、各項目をランク付けすることで評価することにしました。ここからは評価に使っている各項目について、どのようにランク付けしているのかをまとめます。
- 業務改善効果
- 緊急度
- 事故発生可能性
- 事故影響度
- 工数
業務改善効果
業務改善効果は評価の中で一番大事な指標で、上にまとめた売上の向上とコストの削減の両方を含みます。ただ精緻に測ると課題感に挙げたような問題があるため、ランク付けして評価する仕組みにしました。多少の誤差は気にせずにざっくりと社内の影響範囲と改善効果、かかっている費用を考えて、関係者とすり合わせることでランク付けしています。
| 業務改善効果 | ポイント |
|---|---|
| 年間300万以上 | 300 |
| 年間100万以上 | 100 |
| 年間50万以上 | 50 |
| 年間10万以上 | 10 |
| 年間10万未満 | 0 |
緊急度
緊急度は少しややこしいものの、「業務改善効果以外で」考慮する項目があるときに使います。そのため基本的には「1年以上」など低い数値に設定します。この項目を使うのは例えば以下のような場合があります。評価のために使っている項目の中でも特に「緊急度」は分かりづらいため、今後は項目名も選択肢も調整していくつもりです。
- 時間的制約
- 外部要因による対応期限の存在
- 法規制の改正時期
- システム更改などの確定したマイルストーン
- 放置した場合の悪化速度
- 問題の進行スピード
- 対応遅延による解決難易度の上昇率
- 他業務・プロジェクトとの依存関係
- 後続タスクへのクリティカルパス
- 他部門の施策との連携必要性
| 緊急度 | ポイント |
|---|---|
| 3ヶ月以内に必須 | 100 |
| 半年以内に必要 | 50 |
| 1年以内には欲しい | 20 |
| 1年以上 | 0 |
事故発生可能性・事故影響度
最後にそのプロジェクトを実施しなかったときにどんな問題が起こるのかを評価に追加します。例えば今の運用を続けるとトラブルが頻発してその対応に時間がかかるため改善が必要なもの、セキュリティ上の問題を抱えているものがあります。他の2項目はただの足し算ですが、これについては発生する確率と発生したときの影響度を掛け算しています。
| 事故発生可能性 | ポイント |
|---|---|
| いつ発生してもおかしくない | 20 |
| 1年に1回くらい発生するかも | 10 |
| 2,3年に1回くらい発生するかも | 5 |
| ほとんど発生しない | 1 |
| 事故影響度 | ポイント |
|---|---|
| 企業の存続に影響する | 20 |
| 長期的な事業に影響する | 10 |
| 日々の業務に影響する | 5 |
| ほとんど影響はない | 1 |
個人の評価
ここまでの内容を以下のように足し合わせて「評価」としています。そして弊社では半年に一度評価会議があるため、個人の評価を決める際は半年で400ポイント（≒400万円）分をクリアできるように計画を立てています。そして長期の計画や新たなチャレンジを加えたものを個人の評価としています。またすべてのプロジェクトが評価に合わせて完了するわけではないので、一つ一つのプロジェクトにマイルストーンを設定し、評価のタイミングではそれらのプロジェクトが何%達成したのかに応じて評価の何割をこの半期の評価に反映させるかを決めました。
この取り組みによって評価の観点からも目標を何割超えたか / 超えられなかったかを数値的に判断できるようになりました。また一つのプロジェクトが頓挫したときに、そのポイント分を補うために別のプロジェクトに取り組む判断がやりやすくなりました。
評価 = 業務改善効果 + 緊急度 + 事故発生可能性 x 事故影響度
優先度と工数
ここまではプロジェクトや個人の「評価」をまとめて来ましたが、優先度を付ける際はこれを「工数」で割ることで優先度を決めています。工数についても精緻に決めると時間がかかるため、以下のようにランク付けして数字を変換することにしました。また大きなプロジェクトが先延ばしになって細かいプロジェクトばかりになることを避けるため、完全な線形にはならないように工夫しました。この数字で評価を割り算することで優先度としています。
実際に取り組む際は大きなプロジェクトを何個も回すことは難しいため、大きなプロジェクトが1,2個、小さなプロジェクトが2,3個回るように調整しています。
| 工数 | ポイント |
|---|---|
| 4~6ヶ月 | 8 |
| 3ヶ月前後 | 5 |
| 1, 2ヶ月 | 3 |
| 1ヶ月前後 | 2 |
| 2週間未満 | 1 |
優先度 = 評価 / 工数
おわりに
ここまで、弊社で実際に使っているプロジェクトの評価方法をまとめてきました。最後に実際に運用しているシートのサンプルを公開します。これを読んでくれた皆さんもいろんな評価方法を試行錯誤されていると思うので、その内容を X で教えてくれたら嬉しいです！今回、この記事を書いたことで自分の中でも気づいた改善点が多くありました。残念ながらこの記事には反映できませんでしたが、今後もいろんな意見を取り入れながら評価方法を進化させていこうと思います。
また、明日公開予定の BizOps コミュニティのイベントでは今回書いた内容に近いテーマの発表もあるのでぜひご参加ください！connpassまた次回のイベントも楽しみにしています！
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion