Fukabori.fm

9. エンプラ業界でアジャイルになるためのプラクティスとか、社内/社外勉強会とか

Informações:

Sinopse

話したネタ エンプラでアジャイルをやろうとすると何が大変なのか? 内製開発がデファクトじゃない なぜ内製はデファクトではなかったのか? エンプラ業界で内製が増えてきたきっかけは何だろう? 通信事業者のルータやスイッチの調達はどのぐらい時間がかかる? アジャイル開発センターって何? その後のきっかけとなった法人向けのアジャイル案件ってどんな契機で始まった? 小さく成功を作って広げていく 既存の業務プロセスに、アジャイル型開発はどう付き合っていくか? 意思決定をアジャイル開発センターに集めていく アジャイル開発センターの隔離 Cynefin Framework アジャイル開発センターをどう設立していったのか? アジャイル開発センターって名前はかっこよくないけど、実は意味がある ニュースリリースの見出しにのる名前を狙う (新しいもの入れる場合に)社外から社内を攻める (新しいもの入れる場合に)社内の攻め方 - 擁護者を徐々に増やす 彼らのわかる言葉で説明する エンプラはしがらみが多い 特区によって、社内ルールの一部を特例として認めてもらう、代替手段で守る 聞いちゃうとアウトだけど、聞かなければグレーなルールはどうするのか? グレーです、と宣言して進める 謎のチェックリストが生まれる 失敗すると後続が死んでしまう アジャイル開発センターの場のデザインはどうしている? うなぎの寝床みたいなチームスペース Ops専用部署があるにもかかわらず、アジャイルな開発で作ったもののOpsはどうするのか? 運用の要件・要求によってOpsのスタイルを分ける エンプラは標準化しようとする 標準化で決める部分をアジャイル開発センター・チームに権限委譲する、自由度を持たせる 大量のガイドライン・チェックリストとアジャイルの付き合い方 ガイドラインのHowをWhyに戻して考える 会社のルールを変えず、現代のやり方を適用する 障害が起きるとルールが増える ルールを増やしても守れない ルールを増やしてもシャドーが増えるだけで意味がない 半端じゃない数のチェックリスト 誰かが始めないと変わらない 運用へ渡すときに自動化しすぎない 承認フローをあえて挟む 内製をしていなかった企業で、内製エ