発散した仮説をまとめ、具体的な解決策に落とし込んでいく
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である予約数に影響があることを伝えられた。優先度と効果を適切に語れたことで案件化がかなった」と語った。一連の具体的な取り組みにより、技術的負債の返済活動が叶う。似たような課題感を持つ方は、参考にしてはいかがだろうか。
