より品質を上げるためのプロセス改善
はじめに
SkillnoteVPoEの安藤です。
今回はプロダクト開発部門で今まさに進行中のプロセス改善について、どのような背景で、どのような目的を持って取り組んでいるか記載したいと思います。
プロセス改善の背景
前回記事、全社目標から考えるプロダクト開発体制では、メンバー増員に伴うコミュニケーションパスの複雑化を受けて、より小さなチームへ分割する施策を実行したことを記載しました。
これと並行してプロダクト開発部門として主要な課題と感じている2点について、解消へ向けての取り組みを実施しています。
品質課題への取り組み
リリースフロー課題への取り組み
品質課題への取り組み
品質については課題でないことがない、と言い切れることは皆さんご存じの通りと思います。それもあり、例えば常に「テストへの投資は十分に行う」という考えは理解しているものの、なかなか具体的に実施することができていなかった、という点もまた事実です。
開発人員が増え、主にSRE+QAを主担当とするメンバーが増えてきたことから、この取り組みを加速させることとしました。
また、最近数回のリリースにおいてリリース後のインシデント発生が増加傾向になっていることも、この課題への対応の優先度を上げる背景となりました。
リリースフロー課題への取り組み
現在のプロダクト開発部門が描くロードマップは、「ある期間、ある機能を実装する」といったスケジュールをコミットしたWBSのような位置づけとなっており、ロードマップを確定する際に直近の案件についてはある程度「人のアサイン」をした上で確定するような業務になっています。
そのため、ロードマップ案件を実行できる本数を事前に確定させる必要があり、アサインの柔軟性が損なわれ、さらに例えば案件の進行が遅延した場合にはスコープを狭めるかリリースを遅らせるかの2択しか取りうる手段がない（あるいは他の進行中の案件を同じ観点で対応し、ヘルプする）ことにつながっていました。
これが起きることで、「案件を丸ごとロードマップの後ろに回す」ということが起き、結果「後ろに回ったためにアップセルの進行が遅れる」といったARRやチャーンへのインパクトとして現れる課題になっています。
課題に対する改善
上記の課題に対応するため、プロダクト開発部門として以下の施策を実行することとしました。
自動テストサービスの導入
テストプロセスの改善
PdM → 開発へ仕様を落とし込むプロセスの改善
会議体・ギルドの整理
自動テストサービスの導入
今までQAグループでは、主にリグレッションテストの自動化のためにselenideを利用し、自分たちで自動テストをメンテナンスしてきました。
ただし、そのために割ける工数が少なく、リリースにキャッチアップすることも困難で、CI/CDへの組み込みもできておらず品質保証上も課題となっていました。
後述するテストプロセスの改善とセットですが、自動テストサービスを導入することで今後のメンテ工数を削減し、テストケース作りの工数も削減することで、リリースへのキャッチアップを早め、さらには日々の自動テスト実行へつなげることで、品質の向上も狙う施策として現在進行しています。
テストプロセスの改善
結論から言うと「QAグループで実施していたテストの一部を開発者側に押し込む」こととしました。
プロダクト開発部門内で「Excelテスト」と呼ばれているテストが該当しますが、これはテスト観点、テストケース、テストステップを記述し、テストを実施、さらにエビデンスを取得して残す、という作業です。
こちらについては、開発者がローカル環境での結合テストとして実施・保証する必要のあるもので、本来実施すべき開発者に移すことでQAの工数を空け、QAとしてやるべきことにフォーカスできるようにする、ということを狙って実施中です。
合わせて、エビデンス取得やテストステップ記載をやめて開発者の工数を圧迫しすぎない、Excelから脱却してGit管理できるサービスを利用する（テスト工程を見える化する）といったことにも今後取り組む予定です。
PdM → 開発へ仕様を落とし込むプロセスの改善
プロセス改善の背景に記載したように、現在の開発プロセスがSaaSでありながらもウォーターフォールプロセスに寄っている、という点がいくつかの課題につながっています。
案件の初期フェーズでPdMがPRDを記載し、そこから開発者が要件定義を行って分析、仕様へ落とし込んだ上で優先度の高い機能から開発に回すことを実施し、リリースまでの一通りのプロセスを主に2名のエンジニア（フロント担当・バックエンド担当の2名になることが多い）で進行しています。
これはエンジニア視点で言えば一人で全ての作業を完結させられるというメリットはあるものの、一方で今まで記載した課題にもつながっており、「より高速に成長できるプロダクト」であるには足を引っ張る方法になっている、という判断をしました。
この課題を解決するために以下の方法に変更しようとしています。
PRDのアウトプットのゴールをストーリーマップに変更し、ストーリーマップを作成する工程に開発者も参加する（ひいてはCSの参加も検討）
ストーリーマップから優先度の高い順にバックログを整理し、他の案件もクロスした優先度付けを行う
このような変更を実施することで案件を丸ごと後ろにずらさない（本当に優先度の高いストーリーを先にリリースする）、アサインの柔軟性を上げることで優先度の高いストーリーをリリースすることに集中しやすくする、といったことを狙います。
この改善についてはロードマップそのものの見方・見せ方も変える必要があると考えており、関係者の理解を得ながら走る必要も出てくると考えています。
会議体・ギルドの整理
定常的に取り組む必要のある課題ですが、体制変更やプロセス改善を実施すると「走りながらも試行錯誤する」必要が出るため、ある程度の余白時間が必要となります。
この時間を捻出するため、主に定例会議やギルドの棚卸を行い、やめる意思決定をしたり、会議体をまとめたり、小さくする（60分を30分にする、参加人数を絞る）、ということを実施しました。
結果、毎日3人日がミーティングで消化されていたことを、2人日にまで削減することができました（月単位で1人月空いた計算になります）。
まとめ
今回記載した内容はどれも着手したばかりで、まだ何の結果も得られていませんが、少しずつ手応えを感じ始めている点もあります。
また、ある程度時間が捻出できたとはいえ、いくつかの変更が重なったこと、現在改善途中ということによりメンバーが不安を感じ、パフォーマンスが出しづらくなる点も出てくると思います。
このような点にも適宜EMと連携しながらフォローアップを進め、「アウトカムを早く得られる開発組織」にしていきたいと考えています。
Skillnoteは日本発・世界一のソフトウェアを目指しており、事業領域も他に類を見ない場所で戦っています。必然的にユーザー価値を自分たちで定義し、届け、フィードバックを得て改善するサイクルを高速で回す必要があります。
そのような世界をいち早く築けるよう、プロダクト開発部門も常に改善し、変わっていくことで更なるスピードアップを図っていきたい、と考えています。
今後の組織についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、是非気軽にお話にきてください！
この記事が気に入ったらサポートをしてみませんか？