「そういう価値観もあるよね」という生暖かい気持ちで読んで欲しい
すでにリリースされているコードの価値
リリースされたコードの価値はそのコードが達成すべき目標に対する指標で測る。例えば、売上やユーザー数、PVです。本来の目的にそった指標で測ることによって目的に最短で達成できると考えるからです。
リリースされていないコードの価値
新しい機能は指標をどれだけ上昇されると予測されているかで評価されるべきです。この記事ではこの指標を予想評価値と呼ぶことにします。各機能は予想評価値と作成時間を考慮して、優先順位を決めます。
あとはリリースするだけのコード
完全に出来上がっていてデプロイボタンを押せばリリースされるコードの価値は、リリースされていないので無価値とも言えるし、ほとんど予想評価値とも言えます。間をとって、予想評価値の半分の価値だとします。リリース日が決まっているとかあると思うが、デプロイすれば予想評価値が二倍になるので、リリース日にデプロイボタンを押す必要のない作り方をした方が素早く価値を高めれます。
まだアイディア
予想評価値が付けれる程度の状態。まだ、作成時間も予想していない状態。
コードとしては価値がある物は一切ないのでほとんど無価値だと言えます。
アイディアがなければ良いプロダクトもないのでアイディアにはには別の価値を与えた方が良いです。
アイディアからリリースまで価値
1つの機能を作るためには、複数のサブ機能を作り組み合わせることで作っていくと思います。サブ機能ごとに仕様を考えて作っていきます。仕様に沿ったものを作ってはマージしていきます。仕様からマージするまでの段階を経るごとに2倍以上の価値を持つと考えています。例えば、レビューされているコードはレビューされていないコードの2倍以上の価値があし、マージされいるコードはレビューされているコードの二倍以上の価値があります。
この思想の意味
アイディアからリリースするまでに大切なこととしては、早く作りリリースすることです。段階を分割することによって各段階の時間を計測して最適化することができます。各段階の価値は後半になっていくにつれ増大します。新しく機能を作り始めるよりも、作りかけのものをリリースする方が価値が高いということです。後半の作業は価値が高いため自動化の価値が高いです。例えば自動デプロイや自動テストをすることで、自動的にコードの価値の増加させることができます。
サブ機能についても同じです。新しいコードを書くよりもレビューすることの方が価値が高く、レビューを簡単にするための努力は価値があるということになります。早くレビューを通すために分割や説明文を書くことは価値があります。フォーマッタやlinter、自動テストによる動作の保証はすることはレビューの妨げの排除は価値があります。
まとめ
- リリースするまでの時間を短くすることは価値
- リリースするための段階は後半になるにつれ価値が高くなる
- レビューやレビューしやすくすることは価値が高い。
