Battle Conference Under30 2018の発表資料

1. 売り上げ約600億のプロダクトで
スピードとクオリティの両立を求められた話
リクルートライフスタイル ビューティ事業ユニット
前島 恵

2. 自己紹介
‣ 2015年リクルートホールディングス(現：株式会社リクルート)新卒入社
‣ ショプリエでエンジニア、保険チャンネルで開発統括を経て、2016年4月∼2018年
3月までホットペッパービューティー開発統括
‣ 2018年4月より、開発サイドからビジネス/企画サイドのプランニンググループに異
動
‣ 最近はAI系のベンチャーを副業でやっています

3. 開発統括とは
要するに開発チームのリーダー
開発案件を進める上での、ヒト・モノ・カネの最適化に責任を持つ人
アプリT
インフラ
T
クライア
ントT
カスタマ
T
カスタマ
T
デザインT QAT
マネージャー
開発責任者
PMO
TechLead
わたくし/開発統括

4. 今日の話の目的
‣ 大規模プロダクトにおいて、開発リーダーとしてスピードと品質の両立を目指す中で
重要だと思った考え方についてお伝えしたい

5. ホットペッパービューティーとは？
2007年開始のサロン予約サービス
年間約8000万予約(美容キレイ含む)、単独で売り上げ約600億
予約管理サービスのSALON BOARDは業界のデファクトスタンダード
2015年10月、2016年3月に合わせて4.5日のサービス全体停止を伴う障害

6. 美容事業の組織概要
開発 Dir 集客 プロマネ
事業
(2000人弱の営業含む)
プロダクト側責任者 営業側責任者
事業責任者
基本的には開発含む事業的な決定は営業側も含めて、合意して進めていく組織

7. アサイン当時の自分に求められていたもの
スピード 品質
売り上げ急増構想
盛り沢山のエンハンス案件
開発チームの信頼回復
障害ダメ、絶対
C言語、EOSL対応
プロセス全般の点検/整備

8. 当時考えたこと、やったこと
品質とスピードの構成要素を考え、優先順位を付けて手当てしていく
ということを愚直にやった

9. スピード

10. プロダクト開発におけるスピードとは？
起案 開発 テスト リリース 検証
端的に言うとこのサイクルがより早くまわっていること

11. 開発におけるスピードとは？
起案 開発 テスト リリース 検証
組織理解
エンジニア力
既存システム・環境
各プロセスに効いてくる要素としてこの3つを考えた

12. スピードに寄与する3大要素
構成要素 スピードへの寄与
エンジニア力
‣ 開発力
‣ スタンス/地頭
‣ 実装スピード
‣ 学習バッファの少なさ
システム・環境
‣負債の少なさ
‣保守のしやすさ
‣リリースのしやすさ
‣ 保守コストの低さ、容易さ
‣ リリースコストの低さ、容易さ
組織理解
‣計画調整のしやすさ
‣投資の得やすさ
‣ 説明コストの低さ
‣ お金で解決できるものの早期解消

13. 気づき①
構成要素 スピードへの寄与
エンジニア力
‣ 開発力
‣ コミュニケーション力
システム・環境
‣負債の少なさ
‣保守のしやすさ
‣リリースのしやすさ
組織理解
‣計画調整のしやすさ
‣投資の得やすさ
起案できなければ改修もできない、お金がなければ人がとれない
よって手当てできていないならば最初に手をつけるべき

14. やったこと
‣ 現状を言語化/数値化/可視化し丁寧にコミュニケーションする
‣ 「負債」という言葉を言い訳にしない：「負債になるから(あるから)」という言葉
が意思決定の材料になってしまう組織は不健全
‣ エンジニア間でも負債の定義には差があるし、対象とする期間や機能スコープによっ
て負債の定義は変わってくる
‣ 言語化、数値化されていない理由による意思決定は後々検証も振り返りもできない
＝組織として成長できない

15. やったこと一例
コード品質、エンハンス頻度、過去の障害頻度
などからサブシステムごとのリスクを定量定期に評価
とにかく手をつける、ではなく事業的なコストパフォー
マンスを勘案して手をつけるべき範囲を考察・提案

16. 品質

17. プロダクト開発におけるシステム障害への打ち手
予防
検知
対応
‣ 機能・非機能含めて十分にテストが実施され、プロダクトが予期せ
ぬ挙動が無いように供えられている
‣機能不具合が発生した場合に速やかに検知し、周知するべき人への
情報共有が行なわれる
‣障害発生時に速やかに障害の原因究明と復帰が行なわれること
‣再発防止に向けて原因調査と対策定義が行なわれること

18. 気づき②
予防
検知
対応
‣ 機能・非機能含めて十分にテストが実施され、プロダクトが予期せ
ぬ挙動が無いように供えられている
‣機能不具合が発生した場合に速やかに検知し、周知するべき人への
情報共有が行なわれる
‣障害発生時に速やかに障害の原因究明と復帰が行なわれること
‣再発防止に向けて原因調査と対策定義が行なわれること
‣ 予防はもちろん重要だが、深追いは泥沼にはまりこむので絶対にしない(人間が
システムを作る限り障害を防ぐことは絶対にできない)

19. 予防のコストパフォーマンス
20
40
60
80 障害の予防効果
組織からの信頼
時間・エネルギー
ある一定のラインからは障害予防はコスパが悪化する
また、「これだけ時間をかけたのにまた障害？」と逆に組織からの信用が劣化す
る場合もあるため、適切な分岐点の見極めが重要
許容CPライン

20. やったこと
予防
検知
対応
‣ 当たり前品質の実現
‣ C言語のリプレイス、リソース増強
‣ 非機能要件定義/テストのルール化
‣定期的な自動動作確認と通知
‣(結局Twitterが一番早かったりするので)SNSのクローリング、
Slack通知
‣障害対応の型化
‣自動強化テストの推進
あたり前品質＋検知の迅速化、対応の確実さによって信頼残高が蓄積

21. Before After
2年前
現在
開発への信頼が低いことに加えて、開発側もなかなか説明する努力
をしなかったことにより、事業全体の合意がとれず改修案件やプロ
セス変更を実施できないという負のスパイラル
開発起案案件が機能拡張と同じ土壌で、未来のプロダクトを見据
えた事業優先度議論の対象になっている

22. できるようになったこと一例
‣ 予約数が伸び続けているアプリをSwift,Kotlinでフルリプレイス
‣ C言語をほぼ撲滅
‣ Hot Pepper Beauty一部画面のRails,SpringによるFE,BE分離
エンジニアが事業視点を持ち、事業としての
実施価値を説明してきたからこそ実施できた施策

23. 最後に
‣ 信頼はスピードと品質の基盤
‣ 相手が非エンジニアでも諦めない
‣ 論理とプロダクトへの情熱という共通言語を以って丁寧にコミュニケーションすべき
‣ 品質とスピードの両担保は頑張れば可能
‣ 物事の因果関係を解きほぐして、安易な言葉に逃げず本物の言葉を使い、本質を見極
め、自分がやるべき領域にエネルギーを注ぐ