ぼくらがプロセス改善に取り組む理由
イオンスマートテクノロジー株式会社（以下、ＡＳＴ）では内製開発に取り組んでおり、私が所属している組織ではiAEONというイオンのトータルアプリを内製組織で開発しております。
なぜASTでは内製での開発を選択したのか、その目的はずばり「アジリティを向上させてアウトカムを向上させるため」です。
これまでイオンのプロダクトは外部のベンダーに開発を依頼することが多く、発注からリリースまでのリードタイム、開発途中での要件の変更、案件の優先度変更などを柔軟にコントロールすることが難しい状況でした。
これでは絶えず変化する市場や顧客のニーズに応えることができず、競合他社に対して大きく遅れをとってしまうリスクがあります。
このようなリスクに対する打ち手としてASTでは内製開発組織を作りスクラムによるアジャイル開発に取り組んできました。
2022年に本格的に始まった内製開発組織は2024年現在立ち上げから丸2年経過し、ソースコードに技術的負債が蓄積していくように、開発プロセスにも負債が溜まってきているのでは？と見直しを考えるタイミングになってきました。
そこで、以下のような整理でプロセス改善に取り組んでみることにしました！
後述しますが、今回は改善ポイントの洗い出しまでをスコープとしています。
- 開発組織の現状を確認
- プロセス改善に取り組む目的を明確にする
- プロセス改善の指針を検討
- VSMを書いて改善ポイントを見つける
- 改善方法を考える（実施予定）
- 実際の業務プロセスに落とし込む（実施予定）
開発組織の現状を確認
iAEONでは新規会員獲得数を大きな指標としており、開発組織は会員獲得数をKGIとしKGI達成を下支えするための指標をKPIとして設定しています。
KGI
累計会員数1700万人
KPI
- 量的目標：月1リリース
- 質的目標：大規模障害0、中規模障害4件以内
KPI達成状況
- 量的目標：月1リリース→達成！
- 質的目標：大規模障害0、中規模障害4件以内→達成！
開発組織の現場としては量的目標も質的目標もクリアしています。
では何を目的にプロセス改善を行うべきでしょうか？
改善すべき指標を検討
ここで現在の開発プロセスの特徴を見ていきたいと思います。
ここから改善すべき指標を検討していきます。
月1リリースの内訳は上記のように2週間ごとのスプリント2回分となります。
その期間の中で計画・開発・テストを行います。
量的目標の改善点を考える
開発チームは5〜6名のチームが3つありかつ各メンバーがそれぞれの案件を並行して開発しています。
2スプリントで各チームで並行開発した案件を月1のリリースで「価値」として届けるプロセスはリソース効率に倒したスタイルと言えます。
理想的な開発
開発可能な期間にリソースをフル活用しリリースできる案件を準備できることが理想です。
現実の開発
しかし現実には下記のような理由で開発期間に割いたリソースを価値に変換しきれていない状況があります。
- 2スプリント目の後半にテストがあるため開発可能な期間が少ない
- テストまでに開発が終らないとリリースできない
- テストが開始からリリースまでの期間が短く不具合が解消しきれない場合がある。この場合はリリースを見送る
1月にリリースできる案件量を増やすことが量的目標でのプロセス改善の指標になりそうです。
質的目標の改善点を考える
月1回のリリースに合わせて2スプリント目の後半をテスト期間にあてています。
このタイミングで全案件合流しての機能テストとリグレッションテストが実施されます。
3チーム合わせて15人規模で開発を行っているので毎月リリースされる案件はそこそこな数になります。
理想的なテスト
開発初期からテストを実施しリリースに向けてバグが減っていく状況が理想的です。
現実のテスト
多くの案件を短い期間でテストを実施するのでバグ検知数はこんな感じのグラフになってしまいます。
リリース日は決まっているので短い期間で不具合解消を行うため瞬間的に稼働が高くなってしまう、という事態が発生してしまうことがあります。
また、リリース日までに不具合修正が間に合わない場合致命的な事象でないならそのままリリースするケースもあります。
現在小規模な障害しか発生していない状況で小規模障害を0にするためにこれ以上コストをかけても費用対効果としてうれしいことは無さそうです。
それよりもテストにかかるコストを下げられたほうが浮いた稼働を開発に回せるのでメリットが大きいでしょう。
テスト実施のタイミングを早くしかつテストにかかるコストを下げることが質的目標でのプロセス改善の指標になりそうです。
VSMを書いて改善ポイントを見つける
量的目標・質的目標の改善指標を定めたところで、実際に改善ポイントを見つけていきたいと思います。
プロセスの中のムダを見つけて改善を行うための有名なフレームワークにVSM（バリューストリームマップ）があります。
案件インプットから開発そしてテストを経てリリースされるまで、プロセスを一気通貫に可視化し、その中にどんなムダがあるのか、内製開発組織メンバーでVSMを書いてみようと思います。
みんなでわいわいオフラインで実施してみる
いつもはオンラインでの業務がメインの開発組織ですが、せっかくVSMやるならオフラインでやろうぜということで、チームビルディングも兼ねてみんであつまってワイワイやってみました。
写真は各チームのVSMの発表をしているところです。
VSM書いてみた
我がチームのVSMです。ファシリテートを自分がやっていたので付箋の字がめちゃくちゃ汚い！
一通り書ききったところでメンバーでディスカッションしてみました。
VSMを書いて得た気づき
- そもそもプロセスが多い
- 中規模の案件だとおおよそ同じようなプロセスとリードタイムになる
- 計画で1.5日使っているがこの時間開発ができないかつ複数スプリントをまたぐので計画により開発ができない時間が増える
- 開発だけでなく要件具体化詳細化やテスト計画・設計までDevメンバーが実施しているので複数ロールで並行できるタスクが無く全て直列に進行する
当日はVSMを書いて得た気づきをチーム全体で共有するところまで実施しました。
ムダをどう改善できそうか、改善後のプロセスはどうするか、これから検討していくことになります。
まとめ
VSMというフレームワークを使ってチームビルディングの一環として取り組んだことで、参加者全員が主体者として自分ごと化し業務プロセス改善に取り組めました。
ASTで内製組織が立ち上がって2年、良い意味で型化出来ているプロセスもあれば、形骸化してムダとなってしまったプロセスもありました。それらを見直すよい機会となりました。
年の瀬の大掃除のように業務プロセスの見直しを年末に実施してみるのを恒例行事にしてもいいかもなーと思った次第。
実際にどのようにプロセスを改善したのかはまた別の記事でご紹介したいと考えています！
Discussion