改善後の開発プロセス
はじめに
SkillnoteVPoEの安藤です。
今回はプロダクト開発部門の改善後の開発プロセスについて、具体的にどのようなフローとなっていて、どのような効果が出ているか記載したいと思います。
プロセス改善の背景
前回記事、「より品質を上げるためのプロセス改善」で記載した通り、品質改善および変化への柔軟な対応を目的として開発プロセスの改善に着手しました。
今までの開発は、現在も本稼働している旧システム（Skillnote社設立前から開発してきたシステム）の機能移行とその強化が主要な案件となっており、お客様の運用が具体的に把握できる中での開発が中心でした。
それもあって以下のようなやり方が適した開発プロセスだったと言えます。
しっかりとした要件定義を行い
細かく決め切ってから開発する
今年これら主要案件がほぼ完了してきており、来年以降はお客様が本当に欲しているか分からないこともあるような、いわゆる未知の領域に踏み込んでいく開発になることが想定されます。
これにあたり、開発プロセスとしてもより変化に強い、アジャイルなプロセスに変える必要があると判断しプロセス改善に踏み切りました。
改善後の開発プロセス
現状の開発プロセスはこのようになっています。
基本的にはスクラム開発を踏襲する形で、タイムボックス型の開発としています。ただし、スプリントの最後はリリースではない、という点が特徴です。（現在は2ヶ月に1回のリリースサイクル）
図には書き切れていませんが、リリース前のスプリントがQAフェーズとなっており、ここでリリースに向けて全体的に品質を向上させる活動を行うこととしています。
一般的なスクラム開発との違いは以下のような点かと思います。
スプリントの区切りがリリースではない（開発ブランチへのマージ）
要件定義タスクをスプリント内で実施する
QAフェーズを1スプリント内で実施する
開発者のアサインをEMが実施する
これらはある程度今までのやり方を踏襲している部分で、変更するとエンジニアが必要以上に混乱してしまい、目的である品質向上や変化に強い、とは逆の方向に一時的に行ってしまうことを避けるための対応です。
会社全体としても、全社員が自律的に動ける組織を目指しているため、EMのアサインが不要で、タスク分解も自分たちで実施するチームになることを理想としています。
今後はリリースサイクルをより短くし、
お客様の運用にインパクトのあるリリースは○ヶ月おき
それ以外の不具合対応やインシデント対応等は1週間おき
など開発プロセスに応じて柔軟な対応ができるようにしていきたいと考えています。
プロセス改善の効果
まだまだ改善の道半ばではありますが、1回リリースサイクルを回した効果として以下のような効果が出てきていると感じています。
誰が嬉しくなる機能か？を深掘りできるようになった
リリーススライスに対するセールスサイドの納得感が出てきた
1つの案件を複数人で取り組んでいる一体感が出てきた
PdMと優先度の話をしやすくなり、何に集中すべきか自然と合意できるようになってきた
主体的にボールを拾うメンバーが出てきた
今までの要件定義のやり方も見直しており、PdMと一緒にユーザーストーリー（マップ）、受入条件を書いてお互いに認識をすり合わせる方式にするなど、「ざっくり決めて動くモノを作ることを優先する」といったことにも取り組んでいます。
もちろん、Skillnoteは製造業向けの業務システムであるため何もかもをざっくり決めて、という訳にはいきませんがウォーターフォールのような堅めのプロセスとの良いとこ取りをしたい、と考えています。
Four Keysがどう変わったか、などでも表現できれば良いのでしょうが、業務生産性の計測も現在進行中のため測定手段が定性評価でしかないのですが・・（それもまた課題ですが）一時的な混乱を抜け出し、少しずつ自律型組織へ向けて良い兆しも見え始めています。
まとめ
プロダクト開発部門は、人数も増え、新プロダクトも機能が充実し、それに応じてプロセス整備や見える化も進んできて組織として一段階上がった印象があります。EMの配置や自分自身の権限委譲も進み、各自プレイングの部分が残るものの組織拡大にも耐えうる構造を築きつつ、急速に変化が進んでいます。
前回からの繰り返しになりますが、Skillnoteは日本発・世界一のソフトウェアを目指しており、事業領域も他に類を見ない場所で戦っています。ユーザー価値を自分たち自身で定義し、届け、フィードバックを得て改善するサイクルを高速で回す世界が目の前まで来ていると実感しています。
今後の組織についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、是非気軽にお話にきてください！
この記事が気に入ったらサポートをしてみませんか？