アジャイルなリリース
Page content
リリースを早くとか、要望の変化への柔軟性も高くとかするなら単一機能ごとにこまめにリリースするのが良い気がする（図の下側）んだけど、承認行為みたいなプロセスも一緒に軽量化しないと回らん感じで悶々としている。
これは「フロー効率とリソース効率」というものだったらしい。
フロー効率とリソース効率
フロー効率を高めるほうが学びまでの期間、価値を生むまでの期間が短く、基本的には好ましいと感じる。で、コレに対して自分が課題に感じるのがリリース判断の軽量化だ。以下の記事にヒントが有る:
フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog
リソース効率が求められるケースについて、以下のような記述がある：
- どうしても一括でまとめて処理しないとならない場合
- 手動でしかテスト出来ない部分、データセット上、まとめて確認したほうが早いような場合
- 承認印が必要でなおかつ承認者が特定のタイミングでしか捕まらない。承認者のリソースに空きがうまれたタイミングで一括で処理してもらう必要がある場合。
- 【余談】大抵ここがボトルネックになってくるため、制約理論を活用することになる。
- 【余談】最終的には改善していくとこの承認行為自体が不要になる場合もある（権限委譲等により）
- 権限委譲については、いろいろなやり方がある。エンジニアリングにより、安全に失敗できるインフラを構築できればその枠内では権限委譲できる等。
- 例えば、自由にアイデアをリリースしたい場合、Feature Toggleを用いて、 社内のメンバのみに公開 する設定で実装。ドックフーディングをして、 問題なければユーザの10%に公開 。そこで 問題なければ全体公開 等。これはエンジニアリング＆インフラにより権限委譲を可能にするパターン。
- もしくは、マイクロサービスアーキテクチャにて売上をあげている単位でマイクロサービス化（アーキテクチャレイヤ分割というよりは、ドメイン分割）。これにより 売上責任を持ったクロスファンクショナルチームは、売上をあげる責任を持つと同時にプロセス権限が委譲される。
何をすればリリース判断が軽くなるか？
コレは完全に個人のアイデア出し状態です。
- 権限移譲をする
- それをするには何を条件付ければ良い？
ただ委譲しろ！ -> ムリダロ
前後の意思決定
- 幹部会議・サービス開発会議付議有無？
- 運用判定会議有無？
更新の種類で絞る
- 費用に変わりない or not
- 顧客への影響が限定される or not
- 後戻りできる or not
関わる部署の範囲で絞る
- 自分の担当に閉じる or not
- 委譲されたやり方で他部署も協力してくれる or not
これか？: テストが通っていてデプロイ内容をポチッと承認できて、記録にも残る
- それをするには何を条件付ければ良い？
