事業価値とエンジニアリング
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering - Speaker Deck
tkgshnさんがめっちゃ推してたやつ
リクルート
まとめる
SoRも軽視はできぬ
train.iconとはいえSoR側の仕事は俺はしたくないわね
しかしSoE側もキツイんだよな
利他的な行動至上主義
積分の帯を積み上げる
リーンはやっぱり大事
さっさとリリースとしてABテストする
フロー効率を目指す
一つずつつくる。つくれる奴を当てる。
テストコードはもうちょい融通効かせてもいいよ
UI捨てて生データ目視diffするとか
リーン・スタートアップが正しいことを示した一例として良いsta.icon
俺は間違っていないsta.icon*2
「経営者の役割はボトルネックの排除」と言われて言われて、言われまくってるが、ここまで分かりやすく説明してくれる資料はなかったかもしれない。リクルートの公開した”事業価値とエンジニアリング”という資料、今後10年残るレベルです。 https://twitter.com/tkgshn/status/1430295495642017792
/tkgshn/ボトルネック以外にリソースを注ぎ込んでも無駄
hr.icon
https://gyazo.com/4a7ea0b30b480701cea15d44b2deadf5
SoEとSoR
SoEは堅牢。計画型。ウォーターフォールとかプロジェクト管理とか。
SoRは適応。探索型。アジャイル、リーンなどrapidなTAE。
両方必要
SoEマンセーなイメージあったけど、そうか、SoR部分ないと結局耐えられないもんなsta.icon
https://gyazo.com/2d6389694ddfa3432c48a77967270859
リリースするまでは何の価値も生み出さない。使われることで事業価値に変換されていく。
とにもかくにも使ってもらうのが第一
微分ではなく積分を意識する
対象を二つに分けてる
未来に積み上げる資産と過去に積み上げた資産
技術的負債とはリードタイムを悪化させるもの
DevOpsとは変更の適用に要するリードタイムを短縮するための一連の（体系化された）実践
アジャイルとは開発単位を小さくしてTAE回数を増やす思想
https://gyazo.com/6303a46e477aaebd8eea3125ff913477
積分、もっというと帯の累積を最大化できればよい
帯をたくさんつくって積み上げるか？
でっかい帯をつくるか？
事業次第
https://gyazo.com/b008501af73108d95b4ff4072893fd22
ABテスト大事
ほんとそうだよなぁsta.iconsta.icon
リーンでも口酸っぱく言ってるけど、内輪で合意形成してる暇あったらさっさと撃つべきですよねー
https://gyazo.com/2f8c308670e73ebf6a6d13228357199e
既存（再セグメント化しない方）とコピーキャットの話だが、当たり前レベルの価値を担保するまでガチらないといけない
この文脈でガチるだけのコストをかけないのは論外sta.icon
スタートラインに立つまではザ・プロジェクトなので退屈感sta.icon
https://gyazo.com/c20924fecbe79bb278abf748c0e1600c
n要件一気にリリース、よりも1ずつリリースが良いかも、という話
根雪（前回の分が残る）とは、ここで言えば「前リリースした分の肯定的な影響が残る」ってことだろうsta.icon
https://gyazo.com/e89140806628187e06bcdd506645dc9a
機能を一つずつリリースしていくか、同時並行していくかという話
前者はリードタイム短くなるが、要員の稼働率は低くなる
（ある一つの機能だけしているので、あぶれる奴がでてくる）
機能に対して、できる奴を当てはめる
例: ペアプロ、モブプロ、障害発生時
フロー効率という
後者はリードタイム長くなるが、要員の稼働率は高くなる
ウォーターフォール的
人が中心となって、そいつにできることをとにかくやらせる
リソース効率という
現場と管理とで食い違う
https://gyazo.com/01a2e781ef2d396b3005885638da11cc
あるあるsta.icon
Efficiency Matrix
https://gyazo.com/5ad7d6453119ee458d95df1bc3c2bf2e
3から2を目指さないといけない
4を経由した方が良いと言っている
https://gyazo.com/4dc93fb49fcd0c421f3a07198667eac9
もちろん限界はある
https://gyazo.com/8d4a95affd5be46f3b54376f5105dc83
まあVUCAだし、優秀な人材が無尽蔵にあるわけでもないしねsta.icon
https://gyazo.com/3506a6bb37be8985e92c54b5cecca23a
フロー重視が断然良い
実験一つ一つをこなせるし、学べる時間稼げる時間も増える
オーバーヘッド費やす価値はあるってことねsta.icon
データで見ると露骨だなぁsta.icon
リードタイムとはプロセスタイム+無駄
https://gyazo.com/2a2f18b19ee7d100ac9c42ec9bbb5759
回帰テストだるい問題
Q: テストコード書けば？
そのテストコードとリファクタリングもだるい問題
UI部分省いてやればいいと提案している
https://gyazo.com/8795f1a29f7f1ed038c5d43d77199665
step1
https://gyazo.com/79fdda45fc5be6c465892987a8aa3d28
全自動も諦める（jsonの目視を容認している）
https://gyazo.com/3d6691afcc2d7275a7992d24080f17e3
水漏れ量より水が入る量を増やせばいいという話
1: バケツの水漏れを防ぐ
2: バケツに水を流す
3: バケツに流す水を増やす