Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Bill Oneのケーススタディ

SansanTech
October 24, 2024

Bill Oneのケーススタディ

■ イベント
成果が見えづらい… 事業会社のEM必見 "縁の下の力持ち"特有の悩みに迫る
https://sansan.connpass.com/event/332169/

■ 発表者
技術本部 Bill One Engineering Unit 小式澤 篤

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

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

SansanTech

October 24, 2024
Tweet

More Decks by SansanTech

Other Decks in Technology

Transcript

  1. Bill One のケーススタディ Sansan技術本部 Sansan株式会社 Bill One Engineering Unit 小式澤

    篤 成果が見えづらい… 事業会社のEM必見 “縁の下の力持ち”特有の悩みに迫る
  2. 写真が入ります 小式澤 篤 (Atsushi Koshikizawa) Sansan株式会社 技術本部 Bill One Engineering

    Unit 2022年に BtoC 業界から Sansan へ中途入社。入社以来、 Web アプリケーション開発エンジニアとして Bill One の開発に従事。 承認機能やインボイス制度対応などの開発の後、現在はエンジニ アリングマネジャーとしてマネジメント業務、および Bill One 全 体の品質向上に向き合っている。 @lastarrow21 @lasta
  3. システム / ソフトウェア製品品質 (*) - 機能適合性 (機能完全性など) - 性能効率性 -

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

    互換性 - 使用性 - 信頼性 (可用性など) - セキュリティ (機密性など) - 保守性 - 移植性 この場での「品質」の対象 (*) JIS X 25010:2013 (ISO/IEC25010:2011) に基づく いわゆる「バグ」や「インシデント」の 削減に関する話をします
  5. 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 プロジェクトで確認する
  6. 直感的には「品質が不十分」と感じていたが「Elite」判定となった。 Elite 判定となった要因: - デプロイ頻度が極端に高い - 直接的にユーザー影響の無い DB のマイグレーション等もカウントされる -

    一定期間以上前に混入したバグを数値として反映しづらい - 「輻輳」や「運用ミス」など、デプロイに起因しないインシデントを 計上できない より品質の実体を表し、改善に向かいやすい指標が必要になった。 Four Keys の「変更障害率」を計測した結果
  7. より「ユーザーへ価値を提供し続けられているか」を表すべく独自指標である 「ユーザー視点の変更障害率」を導入した。 ユーザー視点の変更障害率 [%] = バグやインシデントの数 [件/月] / ユーザーに有益なリリース数 [件/月]

    導入した結果: - より直感的に品質の現状を把握できるようになった - インシデントの原因を直接的に分析・対策することで改善が数値に現れるよう になった → 現状と成果が見える化された 次に使ったのは独自指標「ユーザー視点の変更障害率」
  8. 「特定レベル (*) 以上のインシデントの発生件数 ◯ 件以下」に変更した。 - より重要度の高いものに対し対策を実施しやすくなった - 組織独自ではなく全社共通の用語を用いることで、組織をまたいで協力 しやすくなった

    - 「ユーザーへの価値提供」を数値に反映できなくなった - スループットは別の指標で計測しているため、スタビリティのみフォーカス しても問題ない → より解決したい課題に対する現状と成果が見やすくなった レベル別インシデント発生件数の削減 (*) 社内にもとから定義されていた、独自の分類基準
  9. 解決したい課題 / 成果によって指標が変わる 指標 見える化できる成果の例 メリット デメリット Four Keys 変更障害率

    デプロイごとの品質保証 を十分にできていること - 統計に基づき「良い」 状態を客観視できる - 結果と原因が直接的に 紐づけられる - システム改修等の変更以外の インシデントは反映されない - デプロイ頻度が十分に高いと 利用できない ユーザー視点の 変更障害率 健全にプロダクト価値を 向上できていること - プロダクト価値の向上も 反映される - 重要度の高い課題にフォーカ スしづらい レベル別インシデ ント発生件数 重要度の高いインシデン トの発生件数を削減でき ていること - より重要度の高い課題に フォーカスできる - プロダクト価値の向上は別途 計測する必要がある - インシデントの全体数の削減 には寄与しづらい 同じ「品質向上」というテーマでも状況は変化するため指標は万能ではない → 状況に応じて指標の変更も検討する必要がある
  10. - 具体的な施策を立案しやすくなった - 解決したい課題に対する現状を表現できるようになったため - 施策の優先度付けができるようになった - 数値から逆算して成果を予測できるため - チームや組織を巻き込みやすくなった

    - 現状を直感的に把握でき、同じ目線で成果に向き合えるようになったため 指標を変えていった結果 組織全体で戦略的に成果の最大化に 向き合えるようになる
  11. - なぜ「メンバーの成長支援」を実施するのか - 組織の成果の最大化のため - 「組織の成果の最大化」のために必要な要素は何か - 技能水準を高めること - より高い水準に押し上げるようモチベーションを高めること

    - どうやって技能水準やモチベーションを高めるか - 定期的な「評価」に基づく振り返りの実施と目標の作成 「メンバーの成長支援」の見える化 メンバーの評価により 成長支援を定量評価することができる 参考文献 : HIGH OUTPUT MANAGEMENT 第4部 選手たち 13章 人事考課――裁判官兼陪審員としてのマネジャー
  12. - 段階ごとの職能定義 - 成長した / 成長支援したことを定量 / 定性的に判断するための共通言語 - 目標に応用することができるもの

    - 評価者 (EM 等) だけではなく被評価者にも公開されているもの - 成長支援や後継者の育成にも言及 - 評価の一般性 - マネジャー個人ではなく複数のマネジャーで評価する等、一般性がある状態 - 評価の妥当性だけではなく、マッチポンプを回避し、成長支援の成果として も妥当性を担保 「成長支援」に必要な材料
  13. - 「メンバーの成長支援」を成果として扱えるようになる - 例 - n 人のメンバーの評価を1段階上げた - 組織的に成長支援の戦略を立てられるようになる -

    例 - 組織全体で成長し平均値を上げる - ジュニアレイヤーの底上げにフォーカスする - ハイレイヤーのメンバーを増やす 「成長支援」に必要な材料が揃うと 組織全体で戦略的に成果の最大化に 向き合えるようになる
  14. - 課題を深堀り、理想を詳細化し、実施理由を明文化する - 解決した際の成果を事前に見据える - 仮説でも良いので、とにかく成果を定量化する - ステークホルダーも含め目線を揃えられるようにする - 振り返りや評価が可能な単位で定量数値を取得できるようにする

    - 定量指標に絶対はないため、定期的に見直しする - 作成した指標そのものに対する振り返りを実施する - 状況の変化に対応できるようにする 「見えづらい成果」に対しとるべきアクションまとめ