【勉強会メモ】【Scrum Inc.+KDDI/ESM】Scrum勉強会 in 大阪
- 日時：2018-03-27（火）15:00 - 18:00
- 場所：KDDI大阪ビル 1階 大会議室
業務提携したということで先日ニュースになっていましたが、KDDIと米Scrum主催の勉強会に参加してきました。
特に印象に残った言葉をいくつかピックアップします。
都合のよいところだけ取り入れるな
スクラムの一部のエッセンスを取り入れてみるというのはよくあるやり方ですが、実際のところそれは元々の開発プロセスの一部をカスタマイズしたにすぎないと思います。たとえ上手くいったとしてもそれはスクラムだからではないということだと思います。
また、スクラムのフレームワークはシンプルであるがゆえに定義されていない部分は自分たちでやり方を考えて進める必要があります。しかし最低限定義されたフレームワークの本質を正しく理解していないと、自分たちでやり方を考えるうちに本来守らなければならないシンプルなルールでさえ崩してしまう危険があると感じています。
チームを維持することによってプロダクトの予測は立てやすくなる
スクラムで開発するとリリースまでのスケジュールがわからないという不安は私の経験でもありました。しかしスクラムに慣れたチームは作るものさえ決まればストーリーポイントで見積もることができて過去のベロシティからスケジュールの予測は立てられます。予測を立てやすくするのであればチームを維持したほうが良いというのはスクラムを経験したおかげで理解できました。
彼らが嫌いなのはアジャイルではなく変化
スクラムを広めていこうとした時に様々な障壁があると思いますが、たとえ否定的な反応があったとしてもスクラムを否定しているのではないということは意識したいと思いました。今までのやり方を変えるということは誰しも不安があるものなので、変化に対して安心感が得られるようにすり合わせをしながら広げていくことが大事なのだと思いました。
真のScrumの導入
Scrum Inc. 副社長 Avi Schneier氏
※遅れて出席したため途中からのメモです
強い会社を作る6つの特徴
- 不安定さが組み込まれている
- プロダクトチームの自己組織化
- 開発フェーズのオーバーラップ
- マルチラーニング
- 最小限の管理
- 組織間の学習
ひとつでも欠けていてはだめ
スクラム導入事例
北米トヨタの事例
小規模開発チーム
- Scrumの必要性をA3の資料で経営層に説明
- マネジメントが協力してくれなければ彼らがチームを壊してしまうため
- 次にチームを説得
- コーチを派遣
- コーチは選手の後ろで観察をしてチームがうまくいくのを手助けする
⇒3ヶ月間は準備期間、6ヶ月間にベロシティは2倍
- 一つのチームに浸透させて拡大する
- Scrumの手法を完全に採用する
- 都合のよいところだけ取り入れるな
4年間でプロジェクト完了数が0.6から2.0になった
大規模金融機関
- 〜45,000名のメンバー
- 60%外注
スクラムをやった結果
- 海外に外注はよくない、スピードが上がらない
- 縦割りを壊してクロスファンクショナルなチームにする
- 職能横断チームにすると速い
- 外注を1/3にした
Scrumの導入により、KDDIがどう変わったか？
KDDI 和田 圭介氏
2013年 市場の変化スピードが急激に上昇
グローバルの開発トレンドを調査⇒多くの企業でアジャイル開発が採用されていた
- 企画・開発チームの一体化（Scrumの導入）
- 開発の内製化
- パートナーとは準委任契約&チームとして働く
- パートナー社員＝成果物責任を負わない
- 2人ぐらい社員、3人ぐらいがパートナー
Scrumチームを少しずつ増やす
企画部門の変化
- 企画担当からプロダクトオーナーへ
- 顧客開発モデルを導入し顧客の課題を解決するMVPのリリースを目指す
開発部門の変化
品質保証の変化
- 各チームにテスターを1名配置
- スプリント内で開発と受入試験を完了
- チーム内で自動化する範囲と手動テストの範囲を決める
パートナーとの関係性
- チームの安定性重視
- アジャイルで開発ができるパートナーを選定
- 長期の良好な関係を継続
品質の向上
- スプリントで発見したバグは即修正
- 常に自動テストで動作を確認
迅速なリリースとコスト削減の両立を実現
- 開発期間は当初想定の半分、コスト1/3
アジャイル開発の広がり
- 15チーム以上、200名体制
KDDIのこれからの取組み
スケールするアジャイル開発
- 大規模案件の要望やスピードアップ
- スケールするアジャイル手法の習得・実践
UI/UX
DevOpsの洗練
悩みごと相談会
改善アクションとして見積もり不能なものを取り入れて良いのか
プロセスの改善の場合はチームに求められるものであれば見積もる必要ではない
ただし、スプリントをまわしているなら実施後に評価できるようにしたほうがよい
⇒ふりかえりで評価する
スクラムマスターをどうやって増やしたのか
KDDIの事例
- スクラムの経験のない人がSMになる
- セミナーを実施
- コーチから助走
- 社内のコーチを育成中
他の例
- アメリカでは職場で募集しSMとPOはやりたいと言う人にやってもらう
- 募集要項にSMとPOに必要な要素を書いてそれにapplyしてもらう
- 本当にやりたい人にやってもらう
ドキュメントをどの程度残しているか
- 運用に引き渡す場合はドキュメントを残す
- 古いWF開発に慣れていて運用できるエンジニアがいない運用部隊がある
- ただし要求仕様書のようなドキュメントの量は減った
- AWSエンジニアのような会社に引き渡す場合
- 一緒にチームに入ってもらって引き渡すためあまりドキュメントは作らない
- 設計仕様書
- 会社的にSMやエンジニアが急に異動することもあるためConfluenceに残す
どのタイミングで作るか
- スプリントの中でテストまでやっているので最低の設計情報は残す
- 次のスプリントで仕様が変わるなら変更する
チームによりけり
- 他チームとの連携の境界線がREST API⇒境界線の部分は残す
- 運用への引き渡し⇒重ために残す
プロダクトの見積もりが乖離しないのか
プロジェクトのリスクヘッジの話
- リスクをどの程度見込んでおくか
- POと調整をかけながら帳尻をあわせる
- POと最小セットは何かを考える
- 開発TとPOが対立しないようにする
しょうがないこと
- WFとスクラムの一番大きい部分
初期の見積もりはポイントを付けるが外れることは多い
- バーンダウンチャートを付けて進めながらリリース時期を見極める
- チームを維持することによってプロダクトが変わっても予測が立てやすくなる
- 新しいチームはベロシティの予測がしにくい
WFに慣れた人がスプリントをくりかえす中で何度もテストすることに抵抗感
- 新しくやる人には抵抗感がある
- 後ろ向きな人がいるのも確か
- 前向きな人をみつけてうまくやって広げていく
顧客からはWF方式で多くのドキュメントの納品を求められる
表向きはWFのままで進めて実際はスクラムで開発する方式
- 10年前ぐらいにアメリカでも実際に遭遇したことがある
- 1〜5枚ぐらいのドキュメントで充分
金融機関は規制が厳しい
- POは1日の半分をドキュメント作成に費やしていた
- ドキュメントを統制する人に話をした（POと統制側にミスコミュニケーションがあると考えた）
- ドキュメントによって本当に知りたいことは何かを聞いた
- 何の変更をしたか、なぜ変更をしたかがわかればよかった
- 3行で済んだ
- ノードキュメントが無理でも顧客の横に座って何が本当に必要かを聞いて彼らがそれに答えてくれればドキュメントを減らすことはできる
- 彼らが嫌いなのはアジャイルではなく変化
KDDIでも最初は必要なドキュメントが多かった
- 続けていくうちに必要な文書は減っていく
