小さくつくろう！プロダクト開発を顧客起点にバク速で進める考え方
この記事について
最近組織周りの話を多く書いていたので、今回はプロダクト開発について。
開発関連として以前プロダクトビジョンについて書いたが、
今回はHERPで大事にしている小さくつくることについて書きたい。
なぜこのテーマ？
HERPではアジャイルな開発を志向し、小さくつくることを大事にしてから、顧客を起点としたスピード感のある開発をできるようになってきた感覚がある。
改めて言葉に落とすことで、何が良かったのか何が課題なのかを振り返りをしたり、同様の悩みを持つ開発者や課題を既に乗り越えた方と知見を交換したりすることで、次の改善につなげたい。
この記事から学べること
サマリとしては以下内容がわかるような記事にしたい。
1. 小さくつくる意義
顧客のニーズを捉える、社内のモーメンタムをつくるという2つのメリットについて書きたい。
2. 小さくつくるために必要なこと
誰に、何をという2つの観点で絞りをかけていく話、小さいリリースのためのTips(顧客とのコミュニケーション、利用しているツールなど)について書きたい。
デカい開発、いいことない😡
小さくつくるのはサイコー🤗
悲しいことにHERPでも去年の頭頃までかなりデカく開発していた。
小さい開発、デカい開発とはどういうものか？
結論ユーザーストーリーの分解ができているかどうか、が大事だと思っている。
「●●機能をつくろう❗️」はデカい開発になりやすい。
●●機能は多義的だ。
最近HERPでは企業の採用担当者向けの「日程調整機能」をリリースしたが、「日程調整機能」という単語だけでは多くの解釈がしうる。
例えば候補日程の表示方法として、企業側が手動でピックする場合もカレンダーの情報をもとに空き日程を動的に表示する場合があるが、どちらも「日程調整機能」といえる。
では小さい開発とは何か？
ユーザーストーリーを分解する
●●機能をつくる際にまずユーザーストーリーを分解しないといけない。
例えば日程調整でいくと
・採用担当として、担当者の空き日程を候補者に選んでもらうために、担当者のカレンダーの空き時間のみを候補日時として伝えたい
・採用担当者として、平日に面接を調整できるようにするために、候補者が選択できる候補日程から土日を省いてほしい
・採用担当者として、日程調整が完了したことをすぐに知りたい
・採用担当者として、1週間以内の調整可能な枠が少ない際に、枠数を増やして候補者に提示したい
など
このユーザーストーリーを分解せずに、日程調整機能として開発していくとツラい😢ことになる。これまでの機能開発では、この分解をしきれないままつくっていることが多かった。
分解しなくて、辛いこととしては以下がある。
最初になくてもいいもの、あって欲しいものの判断を間違える。結果的に不要なものが最初に生まれる
関係者間で完成のイメージがズレる
反応がもらえるまでの時間が長いため、不安になる。
参考：ユーザーストーリー分割のメリット
逆に、最初からトップダウンで理想型をめちゃくちゃ具体的にイメージできていて、開発期間が長くても不安にならないなら小さくつくる必要はないと思う。なので小さくつくるは凡人を助ける便利な方針だと思っている。
小さくつくるとムダが減る
小さくリリースができると、アウトプットに対して随時フィードバックをもらえる。フィードバックに応じて優先順位（どのユーザーストーリーから解決していくかの順番）を見直すことができる。
結果的に欲しいものから順番につくりあげられる可能性が上がるので、ムダが減って嬉しい。😊
小さくつくるとモーメンタムが生まれる
小さくリリースできるようになると、下記記事にある小さな勝利の頻度が増える。
まずモメンタムは小さな勝利の積み重ねから生まれます。自分たちの進捗を社内や社外に示し続けることがモメンタムの醸成につながる
小さなリリースを社内外に共有をしていき、組織のモーメンタムをつくっていく。
HERPの場合は
・毎週の週次全体会議で、小さなリリースを画面デモをしながら紹介(HERPの全体会議について気になる方はこちら)
・顧客からのフィードバックを#herp-user-voiceというチャンネルに集約(ポジティブな反応、今後の機能への声)
などを行い開発を起点とした組織モーメンタム醸成を狙っている。
「誰に」、「何を」の2つの観点で絞りをかける
誰に提供するか（対象顧客）
何を提供するか
2は上述のユーザーストーリーを分解する話とほぼ同義なので割愛する。
誰に提供するか、は以下のように絞りをかけられる。
・セグメントを絞る
(日程調整ツールを利用していない顧客に絞る、など)
・特定の個社を選ぶ
(A社とB社と自社、など)
・テスト提供に協力してもらえる顧客に絞る
(事前にテスト利用のリスクを説明して許諾してくれた顧客に絞る、など)
一部顧客向けの出し分けや機能別のON/OFFにはLaunch Darklyというサービスを利用している。feature flagの管理やフラグによる機能の出し分けなどを便利にできる。
顧客にも小さくつくる開発方針を伝える
弊社では本記事に書いている小さくつくるという開発方針を顧客に伝えている。
顧客に対して開発の考え方を共有することで、以下のような効果がある。
・開発への期待値が揃う
今後改善をしていくという前提を共有できて、「これで完成！？」と思われにくくなる。
・フィードバックの量と質が向上する
フィードバックを受けて改善していく前提が伝わる、かつ顧客にとってもフィードバックすることのメリットがある。また今後の方針を伝えることで、方針を踏まえたフィードバックをもらえる。
またテスト提供についての顧客への説明やフィードバックをもらう場はビジネス側のメンバー、開発側のメンバー両方が揃う。
開発とビジネスが顧客への価値提供という1つの目的に向かって仕事をできていると感じられる組織に近づく。(関連する取り組みはこちら(ビジネスと開発でのリファインメントについて))
まとめ
大きくつくると、不要なものを先につくってしまったり、関係者間でイメージがずれたりする
小さくつくると、無駄な開発を減らせ、組織のモーメンタムを生むことができる
誰に（顧客の範囲）、何を（どの価値を）という観点で絞りをかけて、小さくつくろう
以上、HERPで大事にしてきた「小さくつくる」について書いた。
同様の悩みを持つ開発者や課題を既に乗り越えた方と知見を交換したりすることで、次の改善につなげたいので、もし興味を持った方はぜひお話ししたいです！