beBitでのスクラム導入歴史

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
beBitでのスクラム導入歴史 により Mind Map: beBitでのスクラム導入歴史

1. 対象者

1.1. 途中から開発の文化を変えようとしている人

1.2. リソースが足りていない状態でスクラムを導入している人

2. タイトル

2.1. スクラム開発へ移行しようとして失敗する原因

3. 3つの失敗ポイント

3.1. 開発だけでスクラムを実施

3.1.1. スクラムは組織全体を巻き込んでいかないといけない

3.1.2. 意思決定者が外にいる

3.1.3. 差し込みタスクが入りがちとなる

3.1.4. 要望をチケット化するときの要望の書き方が伝わらない

3.1.4.1. 要望に対しての再確認が必要になる

3.1.4.2. 最悪のパターンだと、要望を無視し始めて、

3.1.4.3. 開発が対応してくれないと言われる

3.1.5. 透明性があるはずなのに、開発がなにをやっているか分からない。

3.1.5.1. 全然リリースしないと思われる。

3.1.6. リソース不足になる。スクラムの役割には意味がある。

3.2. 既存の仕組みをいきなり変えようとする

3.2.1. 既存の仕組みをいきなり変えようとすると摩擦は大きい

3.2.2. 既存仕組みの上には既存の計画がある

3.2.3. いきなり変えようとするのは、既存の計画を一気に捨てることとなる

3.2.4. 何かを変えるためには、それ相応の説明が必要となる

3.2.4.1. この労力を甘く見積もりがちになってしまう

3.2.5. 開発と企画などがわかれていたりするとき、スクラムでは融合してすすめないといけない

3.2.5.1. いきなりスクラムチームに加わってもらおうとしても

3.2.5.2. 相手の都合を考えない巻き込み方になってしまう

3.2.6. 理想像のために組織変革をしていくことは大事だが、いきなりやるとハレーションを引き起こす

3.3. スクラムを見積もりツールとしてのみ使う

3.3.1. ソフトウェア開発の遅延を解決するためのツールとしてだけ使ってしまう

3.3.2. スクラムは開発工数の見積もりをするためのツールではない!

3.3.3. 開発工数のみつもりはあくまでもスクラムである副産物の一つ

3.3.4. スクラムの本質は、どうなるかわからないものに対して新しい価値を提供することにある

3.3.5. スクラムをやっていればチームで色々考えて進めることができると思ってたのに、何も変わらなかった

4. 兼任について

4.1. 最初のうちは仕方がない

4.2. ROIに責務をもてるProduct Ownerを担える人がいない

4.3. スクラムに関してちゃんとした知識のあるスクラムマスターがいない

4.4. 利害の相反に気をつけないといけない

4.4.1. 役割には意味がある

5. 導入の経緯

5.1. いつまでに何かを作るということだけが決まっている状態

5.2. ロードマップにより正確な見積もりができない状態なのに、期限を決めてしまっている状態

5.2.1. ソフトウェア開発とロードマップの相性の悪さと開発は何を保証すればいいのか

5.3. 2018年トライディアがbeBitにジョインしたタイミングで開発のやり方をスクラム形式に

5.4. 何を開発するかはすでに決まっている状態だったので、開発を兼任するスクラムマスターとあとは開発者という構成

5.5. プロダクトオーナーの定義はなかったが、別に切り離されていた企画設計チームがそれと同じようなことをやっていた

6. 自己紹介

6.1. 2011年ぐらいからスクラム開発にふれる

6.1.1. 当時はバックログという概念

6.1.2. スタンドアップミーティング

6.1.3. タスクの透明化

6.1.4. 2スプリント週間

6.2. 2012年自分の会社

6.2.1. スクラム開発ではなくカンバン方式

6.3. 教育系ベンチャー

6.3.1. スクラムっぽい開発

6.4. 2018年beBitに入ってスクラム開発再開

7. 結論

7.1. 途中で開発の文化を変える時に気をつけるべきこと

7.1.1. 組織全体で変わる必要があるが、実際に始めるのは小さいところからやらざるを得ないことを理解する

7.1.2. なぜスクラム開発が必要なのかを理解してもらうことに時間がかかることを理解する

7.1.3. 役割分担をきちんと意識して、仕組みが破壊されるようなコミュニケーションを避ける

8. どんな課題を解決するのか

8.1. 既存の仕組みをスクラム開発へ変更しようとしてうまくいくために必要なことを知れる

8.2. 本当のスクラム開発は組織変革だ!

8.3. スクラムで役割が分かれている意味が分かる