はじめに
この度リーン開発の研修を受ける機会があったので、主に自分用の備忘録として
文書化しておこうと思う。
詳細な部分まで突っ込んでは書かないが、これからリーン開発を始める上で大事な心構え的なことを書けたらいいかなと思う。
開発あるある話
ソフトウェア開発の現場で仕事をしていると下記のようなやりとりがよく聞こえてくる。
(例)
Producer(以降P)「この機能いれたいんだよね〜 どれくらい工数かかりそう？」
Engineer(以降E)「テスト含め１人月ですねえ」
P「結構かかるね〜 でもきっとユーザにとっては嬉しい機能だから入れたいな。おねがいできる？」
E「りょーかいです。では実装します。」
~~ 無事リリース。しかしKPIに変化なし ~~
P「なにがだめだったんだろねえ・・・」
E「うーん」
P「よっしゃ、この機能追加したら今度は間違いないよ。この機能はどれくらいかかる？」
E「同じく1人月くらいっすねえ」
P「結構かかるんだなあ。まあ仕方ないな。おねがいできる？」
E「はーい。」
~~ 無事リリース。しかしKPIに変化なし ~~
P「うまくいくと思ったんだけどなあ・・」
E「・・・」
P「じゃこんどは」
~~ 上に戻る ~~
上記の例では開発コストのみ膨れ上がって事業リスクを増大させている。
これを繰り返していけば、最悪の場合にはサービスクローズにもなりかねないし、なによりエンジニアはどんどん疲弊していく。
でもこれはなにもプロデューサーだけの責任ではない。
エンジニアの責任でもあるのだ。
リーン開発 is 何
リーン開発は、トヨタ生産方式をソフトウェアの開発工程に応用させた、
プロセスから無駄を取り除くことを目的とした開発手法である。
特にスクラムのようなプロジェクトマネジメントフレームワークではなく、
実践手段を提供するための手助けの役割を担う。
具体的には、ビジネスアイデア（多くの場合それは思い込み）をまずは仮説と捉えるという事。
そして最小限のコストで実装しスピーディーにリリースしてユーザーの反応を見る（計測する）。
得られたデータを精査し、反響があればさらに一歩進めて実装をしていく。
これを繰り返す事で開発コストを抑えながら仮説を実証していく方法。
リーン開発のサイクル
Build(構築し) -> Measure(計測し) -> Learn(データから学ぶ)
上記のP/Eのやりとりでいうと、まずはPの入れたがっている機能を疑うところから始まる。
MVP（Minimum Viable Product）
では最小限のコストで実装するというのはどういう事か。
MVPという用語がある。これはMinimum Viable Productの略で、「検証するための最低限の機能を持った製品」というもの。
例えば運用中のサービスに購入機能をいれたいとする。
まともに開発すれば決算機能もあったりするので結構な工数がかかるが、まずはサービスに購入ボタンのみ設置してみる。そしてユーザーが「購入」ボタンを押下すると、「絶賛開発中！」のようなモーダルが表示されるといった機能をテスト的に入れてみる。
これをMVPといい、そこから得られたデータからユーザのニーズを知る。
この方法だと、実際に購入機能をフルで開発するよりもずっと低コストで仮説の実証ができる。
なにより大事なのは、MVP導入をエンジニアから提案することだ。
3原則
まとめに入るとリーン開発で大事なことは以下の3点。
1.疑う
入れようとしている機能が本当にユーザーに求められているのかをまずは疑う。
2.測る
MVPをリリースし、ユーザーの反応を計測する。
3.学ぶ
得られたデータから学びを得て修正する
おわりに
つらつらと知ったように書いたが、自分もリーン開発をこれから実践していこうという身なので
実際に携わっているサービスで始めていけたらと思う。
やってみてうまくいった点、反省点などが出てきたら次の機会にまたpostする予定。