今日リーン開発を知ったエンジニアが考える最強のプロダクト開発環境のつくりかた
まえがき
以前こんな記事を書いたが結局転職した。
そして転職して一週間たったので、 中途受入講義を受けたり、社内のいろんな方とお話させていただいて得た知識を自分の中で体系的にまとめてみる。
何を書くのか
特に今日リーン開発とは何か？といったレクチャーを事例を交えながら受けて、 じゃあエンジニアとしてどんな視点で何していかなきゃいけないんだっけ？ ということを考えてみた。 より具体的には、 ユーザにとってより良いものであり、利益を継続的にあげていける素晴らしいプロダクトを作る環境を エンジニアの視点でどうやって作っていけばいいのか、という内容で記事を書いてみる。 結局DevOpsとかって目的じゃないよ！手段にすぎないよ！ちゃんと組織の方針みて改善してこうね！ っていうお話。
良いプロダクトってそもそもなに？？
ユーザに継続的に使ってもらえる => つまりユーザの課題を継続的に解決できている。(ユーザ目線)
収益構造が成立していて、継続的に利益をあげていける（企業目線）
などなど...
そのためにどんなチームになれればいいのか
企画者、開発者一体で仮設検証を高速にまわしていける組織になること！
それって具体的にどういうこと？
以下の考え方に準じる。
- すべてのビジネス企画は思い込みであり仮設である。
- はじめから企画をフルで開発するのではなくその企画が本当に開発する価値のあるものなのかを実証したうえで開発する。これにより無駄を排除する。
例
- DAU増加を期待して、ある機能A（開発工数は1人月とする）を考える。 => (仮設)
- 最初から機能Aをフルで開発するのではなく、機能Aを呼び出すダミーボタンを用意し、10％のユーザに表示。(ボタンを押すと鋭意開発中！と表示する) => (検証)
- 一定期間様子をみて、10%のユーザがそのボタンをどれだけ押したのかを計測。実際に機能開発をするかを判断する。
これにより、検証の結果全然使われないような機能だとわかった場合、1人月分の工数を無駄にせずに済む。 こうして、仮説をたてて、検証をして、学びを得て次に活かすというサイクルを高速に回していける組織を目指す。
詳しくは、このスライドを参照すると良い。 リーンスタートアップ概論
どんな環境を作っていけばいいのか
じゃあどうやってそんな組織作っていくんだ？
というところだが、これには２つの観点からアプローチしていく必要が有り、
下記図のように組織的な観点と開発環境的観点があると思っている。
以下で具体的に説明していく。
組織環境
チームとしてどういう状態にしていくかを考える。
目指すべき姿の理解。これは企画サイド、開発者サイド両方でともに、仮説検証サイクルを回して事業を運営していく組織にしていくことの合意がとれている状態。
仮設の実証プロセスの定着。 そもそも顧客は？その顧客設定でOKなの？顧客ってどんな課題抱えてんの？その課題ってなにやったら解決すんの？ その施策の効果が出てるってどうやって判定すんの？競合優位性ってどこだっけ？どうやって儲けるの？
といったような各項目について、しっかり検討し、実証していく。（一度実証して終わりではなく、状況はかわっていくものなので都度更新していく必要がある） これについては便利なツールとしてリーンキャンバスという考え方があるらしい。 具体的にどうやって実証してくんだよ（マジギレ）って方は、上のスライドを見てみてほしい。 正直実務でやった経験が乏しいので私もわからない。
開発環境
開発環境としてどういう状態を目指していくかを考える。 これについては以下２種類に大別できると考えられる。
仮説検証を回していくために必要
- ログ収集基盤
- 各データの可視化。CVRやPVなど。
- データを見るための指標。各施策に対してデータをどう見ていくかの指標定義。
- A/Bテストやライブテスト、フューチャートグルを実行できるような環境
- ユーザをクラスタリングするための仕組み。 => ある特徴を持つユーザをグループ化してそのグループに対してだけ特定の施策を出してみるとかを行うため。
とかとか。
高速に品質を担保して開発していくために必要
- CI/CD
- 自動化テスト
- 自動デプロイ
- 静的解析
品質指標
インフラのコード化 + インフラCI
- 仮想化
- バグや課題管理の仕組み
- ChatOps
などなど。。。
サービスの成長曲線と開発に必要なことの優先順位
まず前提として、サービスには成長のフェーズというものがある。 立ち上げ期、成長期、安定期といったような。 そして当然ながらそれぞれのフェーズにおいて、必要なものは変わってくる。 優先順としては次のように考えている。
- 組織環境
- 仮説検証のための開発基盤
- 高速で品質を担保していきながら開発する基盤
サービス立ち上げ期においては、まず組織としての目指すべき姿とマインドを共有していくことが大事。 これさえ共有できてれば、検証などは極端な話人力で計測してしまっても良い。 DropBoxのように、先にこんなもの作るよーとユーザに訴求して、プロダクトがないのに先に登録だけさせ、 登録ユーザ数をみてから開発し始めるといったアプローチも有効であるため、必ずしも開発環境として便利な仮説検証基盤が整っている必要もない。
成長期に入ってくると、仮説検証をより高速に、頻繁に回す必要がでてくるため、 開発側で便利な環境を整えてやるのがよい。 そして、随時高速に品質を担保しながら開発していくための仕組みを整えていく。
当然だが、必ずこの順番で順々にすすめていく、という話ではない。 CI/CD、テストコードなどは簡単なものでも早い段階で可能なら入れておくべきだと思う。 その辺は各サービスによるんだと思う。
結論
立ち上げにがちがちにCI環境など開発環境を整えても要求スピードを担保できない。 逆に成熟しきったサービスにマインドから導入するのはかなりの苦労が必要。 DevOps的な整備とかも普段の開発も組織ゴールに根ざしている必要があり、なんとなくイケてないから、という理由で改善していくものではない。 よってサービスのフェーズに合わせて必要なもの、優先するものを選択、改善していくことが重要。 DevOps、普段の開発も目的ではなく手段。 CI推進とか単体だけでみるのではなく組織の目指す姿という大局的な視点で見て、 本当に今必要なのかどうか見極めながら改善していくことが重要。
感想
今まではエンジニアとして開発環境を整備しようとか開発プロセス改善しようにも何からすべきか、 どう説得すればいいのかというのがまったくイメージできず、 常にエンジニアだけの視点で自己満足なことしかいえなかったが、 こうして体系的にまとめてみることでひとつの判断指標を得ることができた。 経験が全然伴っていないのでこれが正しいとはまったく思わないが、 ある程度この考えに根ざして組織貢献できたらいいなと思う。
