これはなに
読むやつです。よむのはこれら
https://qiita.com/hirokidaichi/items/f59e611772c02f2e74ee
https://i2key.hateblo.jp/entry/2017/05/15/082655
ひとつめの記事よむ
- 効率性はふたつある
- フロー効率とリソース効率
- フロー効率
- 単位時間あたりのリリース数
- 疑問
- リソース効率
- 所有リソースに対するリソース消費量
- いかにリソースをダブらせてないか、投資した額に対する稼働量
- 適切な弁の開け閉め
- リソース効率はトラック、フロー効率はベルトコンベアという比喩
- リソース効率の考え方だと価値はまとめて届けるほうが効率が良い
- ？？？
- フロー効率はベルトコンベア
- 単位時間あたりの提供量
- 細かく提供できる
- 価値の単位で分割してリリースすると、リターンも早くでるし、方向性の修正もできる
- 開発コストに対する市場への影響が高い
- 効率性
- 熱効率的に、入力からどれだけ出力をえられるかのイメージだった
- なのでリソース効率は、いやなんかリソース効率こそちがうな
- 出力じゃないもんな。まあでも細かなはなしよ、、なんか有効に使えてますよという指標なのは分かる
- 対してのフロー効率は投下した労働力に対してのリリース数
- これは分かる、けどたぶん本来言いたいのは労働力ではなく工期。工数じゃなくて工期なので、そうなると少し分からなくなる。
- 工期に対するリリース数のなにが分からんのかというと、
- まとめ
- リソース効率とフロー効率てのがある
- 効率という言葉が「投下した資源に対する結果」という意味を持つので、フロー効率ってそもそもなんやねんと思いがちだが、そういう概念を学んでくれという記事
- フロー効率というのは、工期に対するリリース数
- かつ、事業機会に対する挑戦や検証の数といえる
- アジャイルな開発組織ではそっちのが大切になりがち
- しかしコストはふつうに高いよ、リソースダブらせることになるし、労働力あたりのリリース数を担保しないので
- LTSFに当てはめると、、
- たとえばユニットの人数3人あたりのベロシティを上げるための策ではない？
- プロジェクトひとつに対してどれだけ短期間で取り組めるのか？ の効率性。リリースまでの速度が指標になる
- そのためにはペアプロ実施とかレビューは最優先とかそういうのが必要？
- これは安直な考えですが、3人のうちひとりは運用に固定して、レビューとかテストとかペアプロをその人に固めて効率性を高めるとかはありか？
- レビュー溜まるとかありそうなのであらかじめ前提知識を入れてもらって、、とか？
ふたつめの記事よむ
- 共通の価値観としての「リードタイム」
- 仮説検証の速度を高めるためにサイクル効率性が必要
- えー、、この効率性というのは、はい、工期にたいするサイクルの効率性ね、、おーけーおーけー
- フロー効率性とリソース効率性の話
- リソース効率性パラダイム
- 複数のことやるのでリードタイムはかかる
- みんなに仕事が分配される
- フロー効率性パラダイム
- リードタイムは短い
- リソースの稼働率はさがる
- しかしこれ別にトレードオフじゃないはずだよね？
- 一本目の記事にはそう書いてあったし、読んでてもそう思う
- あ、そういっとるわ
- フロー効率性を高めていくとリソース効率性の問題も解決する
- これなんでフロー効率性から高めていくと良いのか分からないな？
- QCDのトレードオフなんて本当はなかったんだ
- QCDはぜんぶだいじ
- Q（下げる選択肢はないので固定）
- C（人件費はだいたい固定）
- D（リードタイムなので短くしたい）
- S（ここがかわる。スコープ）
- QCDは選択肢ではなく、スコープの大小が決めている
- チームが一度に扱うタスクが大きい場合
- フロー効率おちるよ、ってPOと握ろうね
- どうしてもそうなるケース
- データセットがうんぬん
- 承認フロー的にそうなる
- チームが一度に扱うタスクが小さい場合
- ええぞ
- フロー効率性を向上させるプラクティスや事例
- カンバン方式
- ペアプロ、モブプロ
- なんかgitflowのやつ
- ようわからん
- CICD
- せやな、、
- マルチタスクやめい
- バリューストリームマップ
- プロセスタイムとリードタイムを可視化して改善
- クロスファンクショナルチーム
- 自分のチームだけで機能をリリースできるようにする
- 待ち時間、引き継ぎ時間を減らす
- フルスタックエンジニア
- そらな
- まとめ
感想
- MPははよLTSFから分離させて単体のプロダクトとして仮説検証できるようにした方がええんとちがうか、、？？？ これいっつも思うな
- までもそのうちまっつんさんがやるんやっけな
- やるやら
- リソース効率性（ベロシティ）があがらんな〜〜というのの改善が進んでないので、まあひとつとして取り組むことはできるのかも。
- どう継続してやっていくか、どこでやめるかの判断とかが難しいかも。
- あとベロシティを直接的に改善する方策ではなくて、例えばプロジェクトのリリース単位を小さくしてフェーズ分けて進めるようにするとか、開発サイクルを効率的にするものである、と言う認識を持った方がいいかも
- 開発サイクルが高速化して何が嬉しいのかって言うと、謎なんだよな〜〜〜我らPDCA回してないからなプロダクトとして
- 営業さんを顧客と見た時に、提供している機能が豊富すぎるのと、分割されてなさすぎるんだろな
- そう、根本的には施策が多すぎるのとか、それを受けるために人員を増やすには領域が広すぎてコミュニケーションコストが増えるだけなのとか、そういった構造的な問題がありそうで...ｳｯ
- 少なくともMPとLINEは独立させたいね、LINEはプロジェクトとして機能化ともうちょいこう切り離しやすくしてと言うのをしたいね、、ほんまに、、そこ違うだけで結構楽になるのではないか
- しかし、開発者体験としては、めちゃくちゃいいだろうからやりて〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜