最速で失敗し、最速で改善する実行体制の考え方

Pocket


165886018

サービスづくりに終わりは無いですが、
あえて目指すべきゴールとすれば、ビジョンの達成による理想世界の創造。

それを成し遂げるにはどんな方法があるのか?
できれば最短の道でゴールまでいきたいですよね。
ビジョンとアクションの関係ついて考える機会があったので
このタイミングでまとめておこうと思います。  

イメージ_pptx

私が思うサービス運営におけるビジョン達成のイメージは
上図のような形です。
明確なビジョンを決め、そこに対するGAPを知り、
どのような順序で詰めていくかを決め、
最高の体制/環境で改善(PDS)を積み重ね実行していく。

重要だと思う3要素は

  1. ビジョンの決定
  2. GAPの把握
  3. 高速且つ効率的な改善の積み重ね

だと考えています。
基本的にCtoCで成り立つものなので
近道はなく、いかに誰よりも速く正しい道を見つけるか
という考え方が重要です。

1のビジョンについては、前述のブログである通り
初期の全体戦略を決める際にビジョンや
それに紐づく構成要素の方針を決めます。

また、2に関しては
・いまビジョンに対してなにが足りないか
・どのような順序でビジョンに近づくか
ということになります。
Simplogで言えば、最も美しく、シンプルに思い出を残す
というビジョンに対して今なにが足りていないのか
を常に考え、整理しておくことが重要になります。

そして最も重要なのが3です。
グロースハックの根源的な考え方でもありますが、
考えてるより、やってしまえ。が重要。
1、2を経て大中の方針を決めたら、
小についてはどれだけ速くチャレンジし、失敗してリカバリーするかが大事。
このレベルの改善だと仮説が外れることの方が圧倒的に多いので、
それに対して逐一一喜一憂しているのは時間がもったいない。
(現実にSimplogにきて2ヶ月経つが、仮説通りいかないのが半分ぐらい)

要は、いかに速くPDSが回せる開発体制とマインドセットができるか
という部分が非常に重要になります。

では、どんな実行方法をとればいいのか。
私も試行錯誤しながら、チームのリーダー陣と相談をし、
常により良い開発体制を模索して、ちょうど再来週から新しい方法で
チャレンジ予定です。

現状社内ではいわゆるスクラム開発による
sprintサイクルでの開発がメインです。
sprint開発は1weekや2weekに一度のリリースに切ることで
バグや障害発生などのリスクを抑えられますが、
開発スピードが下がってしまう傾向があります。

これをなんとかできないか。

イメージ_pptx-2
そう考えたのが上図です。
簡単に言うと、ストーリーの小さいものと大きいものに分け、
小さいものは極論毎日でもリリース、大きいものは2weekペースで
リスクを最小限に押さえてリリースを行う。というものになります。
これでボタン色の検証、モジュール位置検証、サインアップ時のABテストなど
細かいが重要な改善の頻度を上げることができます。

よって、毎月2回のみだったリリースが最大で20回(営業日ベース)
年間にすると24回→240回にPDSサイクルが増えます。
冒頭の図にもあるように、PDSサイクルの積み重ねによってビジョンに
近づくのであれば、この実行体制にすることで10倍のスピード
理想の状態に近づくことになります。

また、ここにはセットで正しい検証も必要になってくるので
分析する頻度やデータの整理の仕方、仮説の立て方、共有方法なども
チームで決めておくと意思統一がスムーズです。

Simplogチームでは再来週から試験的にこの取り組みを開始予定なので
またやってみて不都合があればどんどんブラッシュアップしていきたいと
考えています。
ポイントはビジョンからブレず、最速のPDSを回せているか
その観点から開発体制や進め方などメンテナンスしていければと思います。

follow us in feedly

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>