Search

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

9. エンプラ業界でアジャイルになるためのプラクティスとか、社内/社外勉強会とか
Category: Technology
Duration: 00:59:20
Publish Date: 2018-11-01 15:00:00
Description:

話したネタ

  • エンプラでアジャイルをやろうとすると何が大変なのか？
  • 内製開発がデファクトじゃない
  • なぜ内製はデファクトではなかったのか？
  • エンプラ業界で内製が増えてきたきっかけは何だろう？
  • 通信事業者のルータやスイッチの調達はどのぐらい時間がかかる？
  • アジャイル開発センターって何？
  • その後のきっかけとなった法人向けのアジャイル案件ってどんな契機で始まった？
  • 小さく成功を作って広げていく
  • 既存の業務プロセスに、アジャイル型開発はどう付き合っていくか？
  • 意思決定をアジャイル開発センターに集めていく
  • アジャイル開発センターの隔離
  • Cynefin Framework
  • アジャイル開発センターをどう設立していったのか？
  • アジャイル開発センターって名前はかっこよくないけど、実は意味がある
  • ニュースリリースの見出しにのる名前を狙う
  • (新しいもの入れる場合に)社外から社内を攻める
  • (新しいもの入れる場合に)社内の攻め方 - 擁護者を徐々に増やす
  • 彼らのわかる言葉で説明する
  • エンプラはしがらみが多い
  • 特区によって、社内ルールの一部を特例として認めてもらう、代替手段で守る
  • 聞いちゃうとアウトだけど、聞かなければグレーなルールはどうするのか？
  • グレーです、と宣言して進める
  • 謎のチェックリストが生まれる
  • 失敗すると後続が死んでしまう
  • アジャイル開発センターの場のデザインはどうしている？
  • うなぎの寝床みたいなチームスペース
  • Ops専用部署があるにもかかわらず、アジャイルな開発で作ったもののOpsはどうするのか？
  • 運用の要件・要求によってOpsのスタイルを分ける
  • エンプラは標準化しようとする
  • 標準化で決める部分をアジャイル開発センター・チームに権限委譲する、自由度を持たせる
  • 大量のガイドライン・チェックリストとアジャイルの付き合い方
  • ガイドラインのHowをWhyに戻して考える
  • 会社のルールを変えず、現代のやり方を適用する
  • 障害が起きるとルールが増える
  • ルールを増やしても守れない
  • ルールを増やしてもシャドーが増えるだけで意味がない
  • 半端じゃない数のチェックリスト
  • 誰かが始めないと変わらない
  • 運用へ渡すときに自動化しすぎない
  • 承認フローをあえて挟む
  • 内製をしていなかった企業で、内製エンジニアをどう集めるのか？
  • デベロッパーを集めたいなら、デベロッパーコミュニティに行く
  • Tech-Onという社外勉強会と、Tech-Inという社内勉強会の目的は？
  • 前例があると突破できる
  • 前例を知るために社内勉強会ネットワーキング
  • 社内勉強会を実際に始めるとすごいパワーがある
  • 会社に熱を持っている人は見えてない範囲にいる、隠れている
  • どうやって社内勉強会に巻き込んでいったのか？
  • 会社の命令で参加させるのはダメ
  • 影響力ある人から集める
  • ちゃんとした人は、ちゃんとした人を呼んでくる
  • ルール化しましょう、というアンチパターン
  • せっかく燃えていた火を消化させない
  • 70回以上、続けているTechLunchという社内勉強会
  • 運営側が燃え尽きない
  • 社内勉強会をオープンな場所でやる
  • 自分が発信すると、情報が外から入ってくるという体験をさせる勉強会デザイン
  • デベロッパーリレーションズを、なぜエンプラでやるのか？
  • 社外勉強会で外のモノサシを知る
  • 社外で話す、コミュニティ活動をどう社内で評価するのか？
  • エンプラだけど、使ってるツールや言語は普通にエッジなもの
  • メンバーシップ型社員とスペシャリスト型社員の評価制度は同じで良いのか？
  • お客様に価値を届けられる人間が対価を得るべき
  • 2018/11/12 Tech-on Meet Up #03
Total Play: 0