目次
概要
世界中でリーン・アジャイルを実践するチームの立ち上げ支援をしているPivotal Labs. 日本の大企業とのプロジェクトの経験からアジャイル導入の傾向と対策をお話しします。
スピーカー
- 小俣 剛貴[Pivotalジャパン]
- 安西 結[Pivotalジャパン]
スライド
Togetter
内容
- Pivotal Labsとは
- 本社はサンフランシスコにあるコンサル会社
- 一緒に実践しながら手法を教える
- ビジネス価値・ユーザー価値を創出する
- 素早く作り、頻繁にリリースする
- 持続可能なペースで続ける
- バランスチーム
- デザイナー：ユーザーを理解する
- エンジニア：技術を理解する
- プロダクトマネジメント：ビジネスを理解する
- クライアントとペアになって開発
- デザイナ・PM・開発者2名を企業と自社でそれぞれ出して開発をする
- 本社はサンフランシスコにあるコンサル会社
- エンタープライズでアジャイルを導入するにあたっての問題点・対処
- 導入体験談
- 役員：「アジャイルが流行っていてメリットがあるからやってみよう」
- 中間管理職：「若手チームを立ち上げましょう」（予算はつけず）
- リーダー：「はじめてマカされたけど、スクラム本を読んだりインターネットで他社事例を調べよう」
- リーダー：「うまく言葉にできないから、とりあえずなにか作ってみるか…」
- リーダー：「本の通りに進まない！」
- 新しいツールを導入するのに時間がかかっている
- ものを作っている時間がすくない
- 外からは遊んでいるように見えるけどと言われる
- 中間管理職：「成果が出てないじゃないか」
- 役員：「なんだっけ？それ」
- 導入ステップ
- Process・Team Fit
- チーム自身がプロセスの価値を実感する
- 小さな成功事例を生み出す
- 社内の賛同者・支援者を得る
- Team/Company fit
- アジャイル開発の社内導入ロードマップに合意する
- 必要な社内制度の変更に着手する
- チーム規模と適用範囲を広げ始める
- Scale
- ビジネスクリティカルな案件にアジャイル開発を適用する
- チームを大規模化する上で発生するコミュニケーションの問題を解決する
- Process・Team Fit
- 導入のポイント
- 時間がかかるので早く始める
- 価値を証明して社内の信頼を獲得するまでのチームをまもるコミットをする
- 失敗を許容できるようなセットアップで始めて成熟に合わせて負荷を上げていく
- 進め方に絶対的な会はない。自社にあうやり方を模索する
- 社内の制度やチームメンバーが違うから
- なので自分たちで考える
- 今日あつかうのは「Process/Team Fit」・「Team/Company Fit」
- Process/Team Fit
- 目指す状態
- チームがプロセスの価値を実感する
- 小さな成功事例を生み出す
- リスク
- 成果も出ない期間にチームが潰される
- 人材や方法論が存在しない
- ウォータフォールの一部をスクラムにして失敗する
- 組織的トラウマ体験となって導入が遠回りになる
- 対策
- 小さな成功体験を生み出すことに集中させる
- 失敗の影響がすくないスコープで試す
- 新規事業
- 社内の業務改善
- ビジネスクリティカルなものは避ける
- チームを信頼して野放しにしてくれるスポンサーをつける
- アジャイル開発の経験がある人を採用するか、外部人材を頼る
- 目指す状態
- Team Fit・Company Fit
- アジャイル開発の社内導入ロードマップに合意する
- 必要な社内制度の変更に着手する
- チーム規模と適用範囲を広げ始める
- 目指す状態
- アジャイルを適用する範囲の拡大
- チームの拡大と開発のバランスを取る
- 社内の啓蒙
- 教育とチームの生産性のトレードオフ
- 稟議や人事評価などの社内制度の検討
- リスク
- 急拡大のためチームが回らなくなる
- メンバーの成長よりも開発を優先してプロセスが実践できない
- コミュニケーション量が増えて初期のやり方が通じない
- チームメンバーが全然増やせない
- スコープを広げたときに美味く対応できない
- 急拡大のためチームが回らなくなる
- 対策
- チーム内で会話してアジャイルを適用させる範囲を考える
- チームが持てない範囲は避ける
- 社内制度の変更のアジェンダをチームで考えた上で、ステークホルダーたちと合意する時間を十分に取る
- 外部人材に依存してもよいので価値を生み出すまでのリードタイムを短く（同時に社内人材の育成もできるとよい
- 引き続きチームを信頼し野放しにしてくれる人は必要
- 導入体験談
- 1つめの事例「JR東日本アプリ」
- 数百万DLアプリだったが
- 色々盛り込みすぎててよくわからない
- 使い勝手が悪い
- デザイン思考でのアプローチをアプリ担当者が決意
- デザインコンサルファームにリニューアルのコンセプトつくりを依頼
- 内製アジャイルチームの結成
- PM1人（JR社員、アプリ担当者）
- デザイナー1人（協力会社）
- デベロッパー2人（協力会社）
- Pivotal Labsのメンバー4人
- まずは一部機能のみ
- 別アプリとしてリリース
- 内製アジャイルチームの結成
- リリース足りない問題
- PL終了後も内製チームでの開発を続ける
- トップダウンの指示はないが、リニューアルにあたり従来版からの移植が必須の機能をチームで判断
- 開発量に対してリソース不足の認識が会社にないため、人が増えない
- 「外注でいいじゃん」という慣性との戦い
- チームの勝ちを信じ、前向きに妥協
- 内製化の価値アピールするためにリニューアルのマイルストーンを設定
- スコープや実装方法は前向きに妥協し、限られたリソースで間に合わせる
- リニューアル後にチームの存在をより確実なものにするため、とある機能をAndroid/iOS両方で実現にコミット
- やっぱりリソースは足りない
- PVと再度プロジェクトを実施
- 厳しいスコープ定義とリソース増強でリソース
- 問題も起きず社内評価も上々
- 人が増えたことにより、地道な機能改善ができる
- スケール
- 成果と青写真をまとめ、内製化の重要性とリソース不足に関してステークホルダーを説得
- 他部門を巻き込んで事業を推進する立場へ
- 内製チーム拡大のための採用の取り組みが動き出しつつある
- 数百万DLアプリだったが
- 最初はひっそり型
- 社内にエンジニアやデザイナーがいないながらも、外部人材を活用して長期的にアプリにコミットできる内製チームを確立
- 小さく作って徐々に育てる体制を無理なくつくるため、他の事業に影響が少ない形でスタートし、ユーザー価値を検証
- 完璧な理想に固執しない
- 1回目は育成、2回目成果として目的を持ってPivotal Labsを利用
- 当事者の言葉「勢いです。始めるしかない」
- 2つめの事例「経営爆裂コミット型」農業系BtoB新規事業
- 既存領域の延長戦じゃなく新たな領域
- 社長直下に新規事業部をつくり、社長が旗振り
- 学びから成果へ
- 新規事業部門を事業推進本部へ統合
- メンバーの一部入れ替えなどを通じて、学びを徐々に他の事業へ展開
- プロセスのメンテナンス、事業の展開についてPivotal Labsとスポットコンサル
- ポイント
- 時間・予算というリソースを惜しげもなくだしたので本気度を示す
- 治外法権を確率して事業に集中できる環境を整備
- まとめ
- 3つにわけていこう
- チームを守っている人
- QA
- 3段階の「チームの大規模する上で発生するコミュニケーションを解決する」とはなにがあったのか
- 一時期は15人ぐらい人数が増えた
- そのため課題に対しての人をわけた
- 3段階の「チームの大規模する上で発生するコミュニケーションを解決する」とはなにがあったのか
感想
- この前のセッションにあった「チーム・ジャーニー」の話の中にあった「段階」というのをエンタープライズアジャイルに展開した例として聞けた
- エンタープライズアジャイルにおける段階を定義して見せてくれたのは参考になりそう
- そのまま鵜呑みにして自社に展開はできないので、ちゃんと今の組織の状況を整理して課題を言語化するのが大事かなと思った
- 特にアジャイル導入の初段は期待値調整は積極的に働きかけていく必要があるのだなぁ
