Bill One のケーススタディ Sansan技術本部 Sansan株式会社 Bill One Engineering Unit 小式澤 篤 成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る

写真が入ります 小式澤 篤 (Atsushi Koshikizawa) Sansan株式会社 技術本部 Bill One Engineering Unit 2022年に BtoC 業界から Sansan へ中途入社。入社以来、 Web アプリケーション開発エンジニアとして Bill One の開発に従事。 承認機能やインボイス制度対応などの開発の後、現在はエンジニ アリングマネジャーとしてマネジメント業務、および Bill One 全 体の品質向上に向き合っている。 @lastarrow21 @lasta

自分が見ている組織および隣接する組織の成果を最大化させること 前提 - EM の責務

- 品質向上 - 直接的に目に見えるものではない - メンバーの成長支援 - 長期間を通じて現れる傾向がある 紹介するケーススタディ

品質向上

- UI/UX の満足度の向上? - バグやインシデントの削減? - 実装の複雑性の低減? 「品質向上」の成果とは?

システム / ソフトウェア製品品質 (*) - 機能適合性 (機能完全性など) - 性能効率性 - 互換性 - 使用性 - 信頼性 (可用性など) - セキュリティ (機密性など) - 保守性 - 移植性 「品質」と言っても色々ある (*) JIS X 25010:2013 (ISO/IEC25010:2011) に基づく

システム / ソフトウェア製品品質 (*) - 機能適合性 (機能完全性など) - 性能効率性 - 互換性 - 使用性 - 信頼性 (可用性など) - セキュリティ (機密性など) - 保守性 - 移植性 この場での「品質」の対象 (*) JIS X 25010:2013 (ISO/IEC25010:2011) に基づく いわゆる「バグ」や「インシデント」の 削減に関する話をします

品質向上の成果をどうやって 「見える化」するか

品質向上の成果をどうやって 「定量化」するか

DevOps Research and Assessment（DORA）チーム が確立した指標 (Four Keys (*) ) のひとつである「変更障害率」を利用した。 変更障害率 [%] : デプロイが原因で本番環境で障害が発生する割合 本番環境へデプロイした回数のうち、障害が発生した割合を計測した。 最初使ったのは Four Keys Elite High Medium Low 変更障害率 (Change failure rate) 0% 〜 15% 16 〜 30% 16% 〜 30% 16% 〜 30% (*) エリート DevOps チームであることを Four Keys プロジェクトで確認する

直感的には「品質が不十分」と感じていたが「Elite」判定となった。 Elite 判定となった要因: - デプロイ頻度が極端に高い - 直接的にユーザー影響の無い DB のマイグレーション等もカウントされる - 一定期間以上前に混入したバグを数値として反映しづらい - 「輻輳」や「運用ミス」など、デプロイに起因しないインシデントを 計上できない より品質の実体を表し、改善に向かいやすい指標が必要になった。 Four Keys の「変更障害率」を計測した結果

より「ユーザーへ価値を提供し続けられているか」を表すべく独自指標である 「ユーザー視点の変更障害率」を導入した。 ユーザー視点の変更障害率 [%] = バグやインシデントの数 [件/月] / ユーザーに有益なリリース数 [件/月] 導入した結果: - より直感的に品質の現状を把握できるようになった - インシデントの原因を直接的に分析・対策することで改善が数値に現れるよう になった → 現状と成果が見える化された 次に使ったのは独自指標「ユーザー視点の変更障害率」

「ユーザー視点の変更障害率」を1年半ほど利用してきた頃から、施策の効果を 出しづらく、かつ見えづらくなった。 - バグやインシデントに共通する事項を見つけづらくなり、 改善策の立案と実施が難化した - 「軽微なバグ」や「重大なインシデント」のような重み付けが無いため、 重要度が高くかつ件数が少ないものへ対策しても数値に反映されにくかった 単なる件数だけではなく、「バグやインシデント」に対する重み付けが必要に なった。 「ユーザー視点の変更障害率」の弱点

「特定レベル (*) 以上のインシデントの発生件数 ◯ 件以下」に変更した。 - より重要度の高いものに対し対策を実施しやすくなった - 組織独自ではなく全社共通の用語を用いることで、組織をまたいで協力 しやすくなった - 「ユーザーへの価値提供」を数値に反映できなくなった - スループットは別の指標で計測しているため、スタビリティのみフォーカス しても問題ない → より解決したい課題に対する現状と成果が見やすくなった レベル別インシデント発生件数の削減 (*) 社内にもとから定義されていた、独自の分類基準

解決したい課題 / 成果によって指標が変わる 指標 見える化できる成果の例 メリット デメリット Four Keys 変更障害率 デプロイごとの品質保証 を十分にできていること - 統計に基づき「良い」 状態を客観視できる - 結果と原因が直接的に 紐づけられる - システム改修等の変更以外の インシデントは反映されない - デプロイ頻度が十分に高いと 利用できない ユーザー視点の 変更障害率 健全にプロダクト価値を 向上できていること - プロダクト価値の向上も 反映される - 重要度の高い課題にフォーカ スしづらい レベル別インシデ ント発生件数 重要度の高いインシデン トの発生件数を削減でき ていること - より重要度の高い課題に フォーカスできる - プロダクト価値の向上は別途 計測する必要がある - インシデントの全体数の削減 には寄与しづらい 同じ「品質向上」というテーマでも状況は変化するため指標は万能ではない → 状況に応じて指標の変更も検討する必要がある

- 具体的な施策を立案しやすくなった - 解決したい課題に対する現状を表現できるようになったため - 施策の優先度付けができるようになった - 数値から逆算して成果を予測できるため - チームや組織を巻き込みやすくなった - 現状を直感的に把握でき、同じ目線で成果に向き合えるようになったため 指標を変えていった結果 組織全体で戦略的に成果の最大化に 向き合えるようになる

メンバーの成長支援

- なぜ「メンバーの成長支援」を実施するのか - 組織の成果の最大化のため - 「組織の成果の最大化」のために必要な要素は何か - 技能水準を高めること - より高い水準に押し上げるようモチベーションを高めること - どうやって技能水準やモチベーションを高めるか - 定期的な「評価」に基づく振り返りの実施と目標の作成 「メンバーの成長支援」の見える化 メンバーの評価により 成長支援を定量評価することができる 参考文献 : HIGH OUTPUT MANAGEMENT 第4部 選手たち 13章 人事考課――裁判官兼陪審員としてのマネジャー

- 段階ごとの職能定義 - 成長した / 成長支援したことを定量 / 定性的に判断するための共通言語 - 目標に応用することができるもの - 評価者 (EM 等) だけではなく被評価者にも公開されているもの - 成長支援や後継者の育成にも言及 - 評価の一般性 - マネジャー個人ではなく複数のマネジャーで評価する等、一般性がある状態 - 評価の妥当性だけではなく、マッチポンプを回避し、成長支援の成果として も妥当性を担保 「成長支援」に必要な材料

- 「メンバーの成長支援」を成果として扱えるようになる - 例 - n 人のメンバーの評価を1段階上げた - 組織的に成長支援の戦略を立てられるようになる - 例 - 組織全体で成長し平均値を上げる - ジュニアレイヤーの底上げにフォーカスする - ハイレイヤーのメンバーを増やす 「成長支援」に必要な材料が揃うと 組織全体で戦略的に成果の最大化に 向き合えるようになる

まとめ

- 課題を深堀り、理想を詳細化し、実施理由を明文化する - 解決した際の成果を事前に見据える - 仮説でも良いので、とにかく成果を定量化する - ステークホルダーも含め目線を揃えられるようにする - 振り返りや評価が可能な単位で定量数値を取得できるようにする - 定量指標に絶対はないため、定期的に見直しする - 作成した指標そのものに対する振り返りを実施する - 状況の変化に対応できるようにする 「見えづらい成果」に対しとるべきアクションまとめ

Bill One 開発エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer

No content