ゴールの見えない技術的負債の返済
国内最大級のヘアサロン＆リラク、ビューティーサロンの検索予約サービスである『ホットペッパービューティー』。iOS・AndroidのネイティブアプリとWebで提供され、年間約1億8000万回もの予約実績を誇る。
しかしながら、6年前のリプレースから時間が経過し、技術的負債が蓄積。返済活動がメンバーの主体性に任されており、担当者によって工数が異なるなど計画性がなかったという。浅井氏は「気合でなんとか運用している状態だった」と当時を振り返る。そして、技術的負債を返済しなければという課題感はあったものの、どうなれば返済完了と言えるのか「ゴール定義」ができておらず、進捗状況の把握も困難だったことを明かす。
そこで、浅井氏らは、技術的負債を解消することを決意。施策について次のように手順を設定した。
- 開発組織としてのプロダクトの理想の世界観を定義する
- 理想の仮説を洗い出す
- 課題の仮説と解決策案を洗い出す
- 仮説のマージと改善の分類
- 整理と評価を行い、ファクトチェックを実施する
- KPIツリーとの紐づけを行い優先度を決定する
これらの施策に取り掛かる前に、浅井氏から「ポイント0」として、「一緒に取り組む仲間を見つけること」と「いくつかの工程で集まって作業を行うこと」が紹介された。『ホットペッパービューティー』の場合は、チームリーダーとiOS、Androidのリーダーの計3名で実作業を担い、上司にフィードバックやレビューを依頼した。また、「理想の世界観の定義」「理想と課題の仮説の洗い出し」「仮説のマージと改善の分類」など、対話を必要とする工程ではメンバ−が集まり、集中して作業する日を設けたという。
「デリバリー短縮」と「品質向上」を目標に、返済活動スタート！
1．開発組織としてのプロダクトの理想の世界観を定義する
技術的負債の返済を考える上で、「自分たちはプロダクトをどうしたいのか」、「どんなプロダクトにしていきたいのか」などを定義しておくことが重要だ。方向性が明確でなければ、途中でブレたり、一貫性が失われたりしてしまうからだ。浅井氏は「プロダクトの未来は『我々次第である』という気持ちで言語化をしよう。言語化して形に残すことで、悩んだときに立ち返る場所としても使える。徹底的に話し合い、一緒に活動する仲間の気持ちを理解しよう」と語り、実際に使っていたツールにまとめたものを紹介した。
『ホットペッパービューティー』では2つの世界観を定義。1つ目は「デリバリー短縮」であり、アプリ公開までの納期を短縮することで、多くの案件をリリースし、予約数・売上に貢献できている状態を理想とした。そして、もう1つは「品質向上」とし、障害が起こらず、安定して使い続けられる、技術的負債の継続的な返済ができている、開発中の弊害が少なく開発速度が速いという状態とした。
2．理想の仮説を洗い出す
次のステップでは、第一ステップで定義した理想の世界観を実現するための「理想の仮説」を洗い出す。ここでは、今ある最新の技術などでやりたいこと、やりたい理由について効果の有無に関わらず出し合う。ポイントとして浅井氏は「日頃から最新技術を理解しておくこと」「普段の業務中に理想を常に考えておくこと」をあげ、「『こうだったらいいな』という思いを吐き出しておくことが大切」と語った。
そして、洗い出しとともに、理想の仮説の項目ごとに簡単にグルーピングしておくと後の工程が楽になるという。例えば、『ホットペッパービューティー』の場合、縦軸に「コーディングコスト削減」や「チームの技術ケイパビリティ向上」などにグルーピングし、横軸に「理想の仮説」と「それをやりたい理由」で整理した。
3．課題の仮説と解決策案を洗い出す
ステップ3は「理想の世界観」を実現するにあたり、「弊害となっている課題の仮説」と「解決策案」を洗い出す。また、メンバーからアンケートをとるなどして、実装時の細かい課題も集めておくとよいという。なお「理想の仮説」と異なるのは、解決策案まで検討することだ。「課題の仮説」に対しては「なぜなぜ分析」を実施し“真因”を突き止める。そうすることで課題が解決できるか見当がつけられるというわけだ。
ここでのポイントとして、浅井氏は「リーダーでもコードを触って現場感を知ること」や「なぜなぜ分析で真因を突き止めること」をあげ、「課題の解像度を高くすることで真因を突き止めやすくなる」と語った。
『ホットペッパービューティー』でも、それぞれの課題について「なぜなぜ分析」で解決策を考え、「フロー効率最大化ができていない」「コーディングコスト増」「仕様が難しい部分がある」などの課題ごとにグルーピングし、「課題の仮説」と「検討される解決策」に整理している。
発散した仮説をまとめ、具体的な解決策に落とし込んでいく
4．仮説のマージと改善の分類
ここまでで出した「理想の仮説」と「課題の仮説」をマージする。「課題の仮説」よりも広い範囲をカバーする「理想の仮説」を基準にしてマージしていくのがよい。そのうえで、「理想の仮説」と「やりたい理由」、そして「課題の仮説」「解決策案」を再度グルーピングしていく。このグルーピングが「改善の分類」となっていく。
『ホットペッパービューティー』では、縦軸には「理想の仮説」の「コーディングコスト削減」や「チームの技術ケイパビリティ向上」をそのまま使用し、横軸に「理想の仮説からの解決策」、「課題の仮説からの解決策」、そして「その取り組みをやりたい理由」「課題の仮説」をマージ。一つの表にまとめて評価へとつなげていった。
5．整理と評価を行い、ファクトチェックを実施する
「理想の仮説」と「課題の仮説」をマージして1つの表にしたところで、評価を行なう。ここまでは「出し合う」作業が多かったため付箋ツールが便利だったが、ここからはスプレッドシートやエクセルのような「表計算ソフト」が使いやすい。
再グルーピングした「改善の分類」と「理想の仮説と課題の仮説の解決策案」を表に移し、後者を「施策」と呼ぶこととする。この表に「コストとリターン」の列を追加して、各施策の行を埋めていく。このときコスト・リターンは大中小の額で「3秒見積もり（ざっくり見積もり）」を実施する。実際には、「改善の分類の階層化」や「課題の詳細を書く」、「感覚的な優先度を入れる」なども入れられたが、ここではわかりやすくするために「コストとリターン」にフォーカスして説明された。
『ホットペッパービューティー』では、「コスト大、リターン大」のものをメインのスコープに設定。それ以外の分類や施策は、計画の必要性が薄いものとして、別途、案件の合間で実施する「普段の保守」に組み込まれた。
ここでのポイントについて、浅井氏は「計画が必要な大きさの課題に、スコープを絞ること」と説明する。そして、「ここまでで表がやりたいことがたくさん詰まったものになっているはず。しかし、限られた時間の中で全てに対応するのは難しい。そこで、"計画が必要な大きさ”の課題とそれに見合うリターンを得られるものにスコープを絞ることで、時間を有効活用できる」と説明した。そして、『ホットペッパービューティー』で作成したスプレッドシートを紹介した。
マージ後の表をスプレッドシートに書き写したものに、コストとリターンの列を追加してそれぞれを”大・中・小”で分類。さらにスプレッドシートのフィルタリング機能で、計画するべき改善の分類と施策に絞り込んでいる。
整理と評価を終えたら、続いて「ファクトチェック」を行う。「改善の分類」にある「解決する課題」が、「本当に今の課題なのか」をチェックする。ここまでで表出する課題は「コーディングコスト」「仕様が複雑」など、一般的な課題が多いだろう。しかし、それが「本当に自分たちのプロダクトに必要なのか」を改めて問い直す。
チェックは定量・定性で行うが、「静的解析ツール」や「バグや障害チケット」の数など、測れるものは定量指標を使うのが望ましい。また、比較対象やしきい値に関しては、社内の新しいプロダクトや一般的なものを使用する。そして、定量で測れないものは、定性調査をしてチェックする。例えば、チェックの対象にもよるが、ソースコードを調査して証拠を集めたり、過去の障害履歴を遡ってKPI毀損数を計算したりする。
浅井氏はここでのポイントについて、「課題が本当に課題かを見極め、改善に取り組む意義を、確固たるものにする」と語る。確かに、施策を1年かけて実施したのに、「実は大きな課題ではなかった」となればあまりに残念といえるだろう。
なお「ファクトチェックが遅いのでは？」という指摘について、浅井氏は「定量でできるファクトチェックばかりでなく、定性調査まで行なうのは労力が必要。ある程度現場感を知っているので、大きく外れることはないと判断し、スコープを絞ってからチェックすることとした」と説明。実際、ファクトチェックをした結果、効果が薄いものはいくつかあっても課題に該当しないものはなかったという。
『ホットペッパービューティー』で定性調査を行う必要があったものについては、例えば、過去の障害チケットについて、プルリクエストのレビュー指摘で防げた可能性があるものがどのくらいあったかを調査。そうした定性調査を実際に行ない、ファクトチェックとして活用していった。
6．KPIツリーとの紐づけを行い優先度を決定する
「KPIツリーとの紐づけ」では、KPIツリー内の「改善の分類」の指標となるノードに、実績値を記載していく作業を行なう。『ホットペッパービューティー』では、開発組織向きのKPIツリーを別文脈で作成。KPIツリーがない場合は、下図のように「改善の分類」の指標となるノードとパスだけで作成するとよい。そして、その「改善の分類」の指標となるノードに実績値を書いて該当期間における各ノードの関係性を可視化し、優先度をつけていった。
例えば、予約毀損の推定値は年間1000件、障害発生数は年間20件、バグの混入は年間200件……といった具合だ。実績値を出せない場合は、いったん感覚値で仮置きして進めるとよいだろう。重要なのは「改善の分類」の優先度を決めることだ。
上記の場合、バグが1件混入すると20/200で、0.1件の障害が発生し、5件の予約毀損が発生することが想定される。そうして「改善の分類」の指標となるノードとKPIとの関係性を把握し、最終的にKPIに影響する値を見て、「改善の分類」の優先度を確定する。これをKPI全体で実施し、優先度をつけていった。
『ホットペッパービューティー』では、こうして優先度付けを行ない、高い順に「コーディングコスト削減」「コード認知コスト削減」「バグと障害の流出防止」「障害復旧時間」「MTTRの短縮」「バグと障害の混入防止」とした。しかしながら、必ずしもそれに紐づいた施策を順番に実行できるとは限らない。そこには技術的な依存関係がある可能性があるからだ。そこで「改善の分類」の優先度と「施策」の依存関係をそれぞれ紐解きながら、実際の計画に落とし込む必要がある。そこで、『ホットペッパービューティー』では、この依存関係を付箋ツールで確認し、優先順位をつけて並べて検討した。
改善の分類と施策を見て優先順位が決まったことで、限られた工数の中で効果を最大化できるようになり、適切なメンバーをアサインし、理想に向かう計画を立てられるようになった。浅井氏は「優先度の根拠が明確になり、自信を持って進められる状態になった」と語った。
ビジネスサイドからの理解も得られやすくなる
こうした取り組みの結果、「気合でなんとか」「課題も目的も不明」「技術的な解決が目的化」という状態から脱却し、効果を語れるようになったことで事業や企画組織からも理解を得やすくなり、工数を獲得しやすくなった。特に膨大な工数がかかる案件が適切に効果を語れるようになり、案件化しやすくなったという。具体的にはUIライブラリの導入を案件化できたという。
浅井氏は「UIライブラリの置き換えは開発的なメリットのみで、事業的なKPIに直接紐づかないように見える。しかし、今回の取り組みで開発コストを下げ、開発生産性に寄与し、最終的にはKPIである予約数に影響があることを伝えられた。優先度と効果を適切に語れたことで案件化がかなった」と語った。一連の具体的な取り組みにより、技術的負債の返済活動が叶う。似たような課題感を持つ方は、参考にしてはいかがだろうか。
