ESMの賢者たちと作ったキャリアカーバー誕生物語 ~スクラムde新規事業~

ESM事例カンファレンスで紹介した内容です。

永和システムマネジメント、リクルートキャリアが共同して
ローンチに至ったサービスの事例紹介です。

Transcript

1. 「永和の賢者たちと作った キャリアカーバー誕生物語」 〜スクラムde新規事業〜 （株）リクルートキャリア 二木 祥平 ESM 事例カンファレンス2015
2. 自己紹介 二木祥平（にき しょうへい） 兵庫県出身 リクルートキャリア 認定スクラムマスター リクナビNEXTとキャリアカー バーの開発マネジメントを担 当しています。
3. Our Services（一部）
4. キャリアカーバーとは 一生付き合えるヘッドハンターが見つかる、 ハイキャリア向け転職サービスです。
5. 前置き キャリアカーバーが生まれるまでを ストーリー形式でご紹介します。 ・ぶっちゃけそんな綺麗にスクラムってできんの？ ・いや〜ワンチームって言ってもさぁ ・組織とか決裁とかぶっちゃけ評価とかあるj亜sドフィ アエwファウェファえfdjふぃあうぇおjふぁ っていう人が既存の開発スキームに リーンやスクラムのエッセンスを盛り込んで 進めた
6. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
7. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
8. コトの始まり。 「新規事業やらない？アジャイルで」
9. というわけで発足。 PM Aさん 二木 Cさん Eさん サイト開発チーム 営業チーム PRチーム CS/CLサポート& 業務設計チーム Dさん Bさん ESM 上層部（決裁ボード）
10. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
11. 1.第一のESMからの賢者 パンダこと市谷さん
12. 1.目的とコンセプトを考える インセプションデッキと リーンキャンバスを作ってみる。 インセプションデッキ： 　　プロジェクトの全体像をまとめたドキュメント。 リーンキャンバス： 　　ビジネスモデルを簡潔に書き出すフレームワーク。
13. リーンキャンバス作成のリアル ・リーンキャンバスが２枚になりました。 ※キャリアカーバーの場合はカスタマー向けと クライアント（転職エージェント）向け。 ・完成まで１週間くらいかかりました。 ・執行役員含む、PRJメンバー全員が作成しました。 →のちにマージ。 ・ぶっちゃけこのときの前提はどんどん変わっていきま した。
14. 実際のリーンキャンバス（チラ見せw）
15. リーンキャンバスのメリット ・考えるべき大観点が（ある程度）揃っている 　※提供価値、競合優位、コスト、チャネル…etc. ・一目でわかる。認識が揃う。 （決裁レイヤーがいる場合は 説明と合意形成コストが下がりやすい）
16. コンセプトが決まったところで… ・リーンキャンバスからシステム機能に必要な 　要件を落とし込む。 具体的には… ユーザーストーリーマッピングを作成しました。
17. ユーザーストーリーマッピングのリアル ・ユーザーの転職活動における認知〜転職先決定まで の行動を洗い出し、各行動に必要な機能を洗い出す。 ・だいたい6hくらいかけました。 ・基本作りっぱなしで作成以降メンテしませんでした。 想定するユーザー（有識者） がいた方がいいよ。
18. ユーザーストーリーマッピングの例（チラ見せw） ユーザーの行動 行動達成に必要な機能
19. ユーザーストーリーマッピングのメリット ・システムリリースに必要な最小フローを明確化でき る。（機能単位で精査するとフローで見たときの必須 機能を見落とすことがある！）
20. これだけでシステム開発にはもちろん入れない。 （＝要求定義はまだまだこれから）　
21. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
22. 要件一覧を作成する （プロダクトバックログの作成） ・とりあえずざっくり見積もる。 ・関係者とスコープの調整をする ・各ストーリーを詳細化する やることは… 目的は…
23. たとえば（抜粋）
24. 優先順位とスコープを決める ここはプロダクトオーナーの 超踏ん張りどころ。 よくある例） ・機能の優先順位がコロコロかわる。 ・「あったらいいな」で全て開発することになってしまった。 ・いつのまにかインセプションデッキの優先順位を気にしなくなっていた ・削りすぎて後で開発するボリュームを追加した。 ・上層部と認識があっておらず後でどんでん返し ・頭が良すぎていろんなリスクやパターンを洗い出してしまう。 優先するのはデリバリか品質かスコープか、はたま たコストなのか。 サービスのローンチにあたって本当に必要な機能 （MVP）を絞り込み、合意をとる。
25. 本当に必要な機能（MVP)を絞り込むコツ ・機能一覧から不要な機能を取り除くのではなく、 　必要な機能をピックアップしてみる。 ・サービスローンチ後も開発できることを忘れない リリースしないわけではなく初期リリースしないだけ。 捨てるのではなく遅らせるだけ。 「リリース日が遅れても必要な機能か」 「リリース以降開発したら問題があるのか」 ・脳内逆プロトタイピングしてみる。 「この機能がなくなるとサービスが成り立たないか？」
26. スコープが決まると、、 見積ってスケジュールを決める。
27. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
28. このときの見積精度って？ “60-160%の見積り誤差が生じます。” 　 ※キャリアカーバーの場合は150%に上振れました。 by アジャイルな計画と見積り
29. そもそも企画段階に正確な見積りが出るわけがない スケジュールを変動させるやつら。 ・開発のVelocityが見えていない。 ・デザインも納品されていない。 ・利用するライブラリの変更があるかもしれない。 ・大玉の要求変更だってあるかも。 ・組織の体制（決裁者）が変わってしまった！！！！
30. それでも会社によっては開発に入る前に見積が 必要、スケジュールが必要だったり、、 われわれも見積りとスケジュールが必要でした。 なぜなら… ・開発着手前に決裁（お金）を取らないといけない ・PRチームが鼻息荒くして待っている。 　「CMはどうしますか〜！」 　「イベントやります！会場おさえないと！」
31. ここでプロダクトオーナーが気をつけること。 格好つけようとしない。 “実際より（人が）短く見積ってしまう（報告してしまう） 理由については諸説あるが、「周囲によく見られたいか ら」という説はなかなか興味深い。”　 by エッセンシャル思考 第15章
32. 格好つけたいプロダクトオーナーの場合 アジャイルでやってるからな… 遅いとは言えないしな… とりあえず宣言しちゃおう。 「現段階での見積りがだいたいでたので、 うまくいけばこのくらいのスケジュールで いけそうです。」 →炎上。 「やっぱり足りなかったので追加要員の決裁ください」 「遅れるって言ったってイベントスペース確保してるよ..」
33. 正直者のプロダクトオーナーの場合 「開発の規模感が見えてきましたが、 　スケジュールのFIXは⚪月⚪日以降にジャッジします」 キャリアカーバーの場合… ・スケジュールの候補の提示：２イテレーション後 ・リリース日の確定：開発者試験時 ・決裁は人×期間でとりたかっ..
34. どうしてもスケジュール確定が早めに必要な場合は ・スパイク（事前検証）を実施する ・1.5倍がける（いわゆるリスク比） ・ぶっちゃけそれならウォーターフォール
35. やっと開発です。
36. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
37. ESMからの第２の賢者 ESM→起業 @kenchan
38. リリースまでの開発の進め方 要件定義/開発/UT 要件定義/開発/UT 要件定義/開発/UT 結合試験 ★ リリース 反復開発の進め方
39. 開発が始まりましたが… 8 6 8 18 10 20 18 18 19 17 16 12 0 5 10 15 20 25   1/13
       1/20
       1/27
       2/3
       2/10
       2/17
       2/24
       3/3
       3/10
       3/17
       3/24
        3/31
     Velocity 目標はVelocity１５ まぁ始まったばっかりだしね。 開発スタイルがみんな違うからね。 8
40. 開発が始まりましたが… 8 6 8 18 10 20 18 18 19 17 16 12 0 5 10 15 20 25   1/13
       1/20
       1/27
       2/3
       2/10
       2/17
       2/24
       3/3
       3/10
       3/17
       3/24
        3/31
     Velocity 目標はVelocity１５ 命名規則とか合意とるの時間かかるね このHTMLじゃ取り込めねぇよ 6
41. 開発が始まりましたが… 8 6 8 18 10 20 18 18 19 17 16 12 0 5 10 15 20 25   1/13
       1/20
       1/27
       2/3
       2/10
       2/17
       2/24
       3/3
       3/10
       3/17
       3/24
        3/31
     Velocity 目標はVelocity１５ ここの仕様に抜け漏れがぁああ Wicked使ったことないから難しいなぁ 8
42. ここからがスクラムの見せ所。 そもそもVelocityというのは測るもの で目標にするものではなくてですね。 もとはといえば目標設計自体もあsdfぃ じゃいえおふぁうぇおいfj… 賢者：@kenchan 賢者の教え
43. 開発を改善する。 ・MTGの削減（開発時間の増加） →スクラムで紹介されるMTGは多い。 　コンディションに合わせて絞りまくる。 　キャリアカーバーの場合は50%カット。 ・デモHTMLのgit管理。 →デザインの差分が追えない。取り込み工数の削減 ・口頭伝達を減らす。 →いくらみんな現場にいようと人間の脳ミソは忘れるもの。要求仕 様はなるべくドキュメントへ。 ・レビューやテストコード粒度などルール統一 などなどなどなど…
44. これぞ反復開発のメリット 要件定義/開発/UT 要件定義/開発/UT 要件定義/開発/UT 結合試験 ★リリース 改善 改善 ・要件定義〜UT（デモ）までを反復するので、 各工程を次のイテレーションで改善できる。 そのほかには… ・プロダクトオーナーが都度仕様を確認しながら進められる（品質UP） ・プロダクトオーナーの稼働を平準化できる。
45. そんなこんなでVelocityが急激に安定し始める。 8 6 8 18 10 20 18 18 19 17 16 12 0 5 10 15 20 25   1/13
       1/20
       1/27
       2/3
       2/10
       2/17
       2/24
       3/3
       3/10
       3/17
       3/24
        3/31
     Velocity 試験フェーズに入って行ったので Velocityは緩やかに低下 （たまたま） 該当週の開発ストーリーの単位が 大きく「DONE」しなかった。 その分翌週がVelocity20に。 イテレーション5あたりから安定し始める。 とりあえずVelocityは 当初と比べて 約２倍に。 8 6 8 18 10 20 18 18 19 17 16 12 0 5 10 15 20 25   1/13
       1/20
       1/27
       2/3
       2/10
       2/17
       2/24
       3/3
       3/10
       3/17
       3/24
        3/31
     Velocity
46. アジェンダ 0.ことの始まり 1.目的とコンセプトを考える 2.MVPを決める 　 3.見積もる（＋決裁をとる） 4.反復開発する 5.試験とリリース 結合試 験 反復開発 反復開発 反復開発 企画 見積り と計画
47. そして最後の結合試験フェーズへ ・各イテレーションで確認した単体機能ではなく、 機能の流れ（シナリオ）を試験する。 そしてプロダクトオーナーにとっての試験とは、 品質を確認するだけではなく、リリースに向けての 準備を行う必要がある。 ・サポートセンターや業務運用担当者に機能を確 認してもらう。 ・営業活動のために営業に機能を確認してもらう。 ・PRイベント用にサイトのキャプチャを展開する。　 などなど
48. 晴れてリリース！ ※リリースの瞬間
49. リリース後のお話。
50. ESMからの第３の賢者 ESM→転職 @koic どうやら転職サイトに携わると離職リスクが高まる。
51. キャリアカーバーの今 ・ちなみにツールや環境はこんな感じ Github/PivotalTracker/ Idobata/ Vagrant/Solr/jenkins/zabbix…. DRYDRYDRYDRYDRYDRYDRY 賢者koicも爆走中！ ・リリース後も爆速成長中。 ・１スプリント2WEEK
52. 最後に なんだかんだ一番大事なのは スクラム活動（変化）を許容するための文化作り。 People Process Structure Strategy Leader Ship Culture Culture Culture Culture People Process Structure Strategy Leader Ship Culture Culture 無理な変化 the rubber band of culture（ゴムの文化） 組織文化をアジャイルに変容させるには ピラミッド全体の変容が必要。
53. SpecialThanks スクラムやるならESM/リクルートキャリアへ。 転職するならキャリアカーバーで。 kbaba(BUTAKIMUCHI) hibariya(IDOBATAMASTER) muryoi(ANNIN) sawada(NIHIOJISAN) seto(IZAKAYATERO) tonyu(IROIROTERO) katsuyoshi(LOLI) flada_auxv(GYAMBLE) kunou(KODOMOKAWAII) suginoy(TANTANSUGOI) haneda(BUCCHAKESALES) kinoshita(BUCHO)