大企業でアジャイル開発を推進できる条件とその心構え

Copyright© LIFULL All Rights Reserved.
大企業でアジャイル開発を
推進できる条件とその心構え
株式会社 L I F U L L
L I F U L L H O M E ’ S 事業本部プロダクトエンジニアリング部
プロダクトエンジニアリング 5 U
野澤猛 ( @ t a k e s h i _ n o z a w a )
2 0 2 1 . 6 . 8

■ 2 0 0 9 年
教育系 C G M のベンチャー企業
■ 2 0 1 7 年
L I F U L L 入社。国際事業部に所属
■ 2 0 1 8 年
賃貸事業部
■ 2 0 1 9 年
プロダクトエンジニアリング部 1 U
■ 2 0 2 0 年
プロダクトエンジニアリング部 5 U
( L S M 取得 )
自己紹介
野澤猛
@takeshi_nozawa
Copyright© LIFULL All Rights Reserved. 2

目次
LIFULLでのアジャイル
アジャイル推進の条
件と心構え
今後の課題
3

© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。
https://agilemanifesto.org/iso/ja/manifesto.html
4

LIFULLでのアジャイル
5

LIFULLでのアジャイル: 導入の歴史
6
•開発スピード向上のた
めスクラム導入
•数名がCSM取得。60名
ほどで社内研修の実施
•開発体制、リリースフ
ロー的に難しかったた
め下火になる
2013
•中途入社メンバーが各
部署でスクラムを実施
•その後主要メンバーの
異動先でもスクラムが
採用され普及してくる
2018
•アジャイル勉強会
•スクラムサークル立ち
上げ
2020

LIFULLでのアジャイル: 現状意識調査
7
3年以上アジャイ
ル開発の経験が
ある
16%
1年以上アジャイ
ル開発の経験が
ある
22%
1回以上アジャイ
ル開発手法を採
用したプロジェ
クトに従事した
ことがある
34%
書籍を読んだ
り、ネットで調
べたりしたこと
がある
13%
言葉としては
知っている
12%
全く知らない
3%
LIFULL HOME’Sアジャイルの経験・意識調査
PMI日本支部事務局 2020年度「アジャイルプロジェクトの実態」に関するアンケートより
https://www.pmi-japan.org/topics/PMI_Japan_Chapter_Agile_Survey_2020.pdf
72% vs 46%

LIFULLでのアジャイル: 現状開発手法
8
アジャイル
53%
ウォーター
フォール
42%
組み合わ
せ
5%
LIFULL HOME’Sで採用している開発手法

アジャイル推進の条件
9

PJ名概要特徴開発手法
国際事業部
エンジニア5名
サービス企画2名
デザイナー2名
ストーリーポイント見積もりや
ベロシティの計測は無し
緩めのスクラム
賃貸
システムリプ
レース
エンジニア8名
DevOps3名
デザイナー3名
はじめましての人多め
交代制スクラムマスター
形式的には完全に近いスクラム
賃貸UX施策 -
小さめ(1-2人月位)のPJ多め
全エンジニアのリソース管理表
要件大盛り
ウォーターフォールっぽい
賃貸特命PJ“Z”
エンジニア6名
デザイナー1名
７ヶ月(調査フェーズ抜き)
納期絶対死守
社史でも5本の指に入るくらいの
大規模PJ
ガントチャートとベロシティに
よる計画の併用
ハイブリッド
私がLIFULLで経験した主なプロジェクト
10
まだまだウォーターフォール型の考え方が残っている組織
( プロジェクト志向、アウトプット志向、納期、予算、短期の業績重視 )

アジャイルを始めるときのつらみ
アジャイル推進の条件つらみ
11
• 思いつくことは全部やろう！ストレッチした目標がなければ会社も個人も成長もで
きない(目標とプロセスの違い)
• 今やらないといつできるか分からない。この人とまた一緒にできるかもわからな
い。
スコープに対する考え方
• 一年に一回、組織の枠組みの変更。稀に半期に一回。
• 仕事の進め方や優先順位、フロー、体制、メンバーが変わる。
• PJごとにチームを招集(開発のやり方、見積もり基準、計画の立て方が変わる)。
• 全員のリソースを余すことなく使えるように、全員の毎日の作業内容を把握し、計
画を立てる(調整する)
• ヤバくなったら人を増やす
組織・チームの考え方

そんな中、どうやってチームを
アジャイルにしていったか？
12

アジャイルを推進できる条件
※ 個人の経験を元にしたものであり M E C E ではありません
13
型に囚われ
ない
考えるきっ
かけを作る
土壌を作る

型に囚われない
アジャイル推進の条件その1
14

アジャイル推進の条件: 型に囚われない
15
完全な
スクラム
変化を受け入
れる側
ハレーション

最初から完全なスクラムが
必要だったのか？
16

アジャイル推進の条件:柔軟なやり方
17
形だけのスクラムになりがち
スクラム導入のバッチサイズは大きい
3つのロール
5つのスクラ
ムイベント
3つの成果物
スクラムも意外と複雑
PMBOKやRUPに比べれば
軽量級かもしれないが…

なので、課題を明らかにした上で、その課題を解決する
仕組みとして個別に導入していくのが良さそう。
→メンバーの学習負荷/心理的な障壁も低い。
→スクラムマスターの負荷も低い。
18
納得感も得られやすいし、
ひとつひとつの効果も実感しやすい。
ってボブも言ってた。

19
問題があるけど言い
にくい
振り返り会
作ったものがステー
クホルダーにイマイ
チ伝わっていない
スプリント
レビュー
チームの開発ノウハ
ウにバラツキがある
ペアプロ
モブプロ

ちなみにスクラムガイドでは
20

21
Ken Schwaber & Jeff Sutherland(2020)
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
スクラムって状況をチェックして変化適応して
いくことが大事なんじゃなかったっけ？
不変なことってありうる？
これだけ世の中変わっているのに？
完全なスクラムでなければスクラムとは言えな
いなら、別にスクラムじゃなくてもいいん
じゃ？
• 適応が大事なのに、適応を拒否している
• 「プロセスやツールよりも個人と対話」というアジャイル開発宣言に反している
スクラムの自己矛盾

なので必ずしもスクラムガイドや
有名な本の通りにやる必要はない
と思います
22
完成の定義をクリアし
たものしかスプリント
レビューしない、なん
てない
バックログはユーザー
ストーリーじゃないと
いけない、なんてない
ストーリーポイントで
見積もり、ベロシティ
を計測しなきゃいけな
い、なんてない

23
https://media.lifull.com/campaign_2021052604/

でもその前に
24

そもそもアジャイルやるのが
ベストなんだっけ？
25
定型業務開発以外の仕事
要件も変わらないし
やり方も分かってるPJ
高度な知識を要し、一人
や少人数でやる仕事
差し込みタスク少ない
または柔軟にタスクを組
み替えられる

考えるきっかけを作る
26

アジャイル推進の条件: 考えるきっかけを作る
27
アジャイル知ってる人
知らない人
知ってる人からすると
解決策は明らかなので
すぐ解決策を提示したくなる
これやれば解決するよ
知らない人からすると、相手
の言葉がよく分からないた
め、無思考で受け入れたり、
ハレーションが起こったりす
る
知らない俺がいけないんだ。
不勉強でした、すみません
いっつも偉そうなこと
ばっかり言ってる
アジャイルに限らず、何か新しいことを導入するときには
知っている人と知らない人の間に、力関係(上下関係)が生まれやすい
力関係が障害になり、アジャイルの理解・定着に問題が生じる→アジャイルになれない

アジャイル推進の条件: コーチング
28
いっつも見積もりがズレ
ちゃうんだよね
じゃあプランニン
グポーカーやって
みようか？
どうすればうまく
見積もれると思
う？
1人で見積もって
ると限界あるよ
ね？

• そこに問題があるということに、まず気づいてもらうところから始める
• 課題を発見し、解決策も分かっている場合でも、ぐっとこらえる
• チームで解決策を話し合い、考えてもらう必要がある
• 少しずつアイデアを出したりする
つまりこれってコーチング
• もしかしたら、あなたは問題を取り違えていたかもしれない
• もしかしたら、今の解決策よりも良いアイデアが出るかもしれない
• 何より、ティーチングよりも深い理解がチームに残る
• ハレーションも起きなければ、みんなも納得して進められる
アジャイル推進の条件: 考えるきっかけを作る
29

土壌を作る
30

アジャイル推進の条件: 土壌を作る
31
変化拒否反応
MVPって必要？
なんでそんなこと考えるの？
ユーザーストーリーって面倒く
さい。ワイヤーフレームだけで
いいじゃん。
スプリントに分割？ガント
チャート引けば良くない？
大企業で培われた
「正しいやり方・考え方」
変更するためのコスト
分からないものに対する怖さ
面倒臭さ・胡散臭さ

32
変化を要求
する側
変化を受け
入れる側
なぜ変えるのかを説明する責任

説明するのは大変
33

34
変化を要求
する側
変化を受け
入れる側
変わらない方が良いことを説明する責任
変化
変化
変化
変化
変化
変化
変化
変化を認知している
から変化を要求して
いる
変化が必要なことを
説明するのではな
く、変化の認識を揃
える
変化を積極的に検知
する責任
“DX Criteria” https://dxcriteria.cto-a.org/e5a00d8543af4d87944211603e3ff066#a51bcebb0e8d49b4bf1542f341289575
説明責任の向きを反転させる
なぜ変えるのかを説明する責任

変化を要求
する側
変化を受け
入れる側
変化
変化
変化
変化
変化
変化
変化
衝突
ここの衝突ではなく
この変化に対する認識を
一緒に豊かにしていく

勉強会を開催してみた
36
座学
ワークショップ
合計4日間
(各2時間)
参加者平均40名
(のべ150名)

全社で「アジャイル」の存在が
ちょっとだけ近くなった
37
チームに導入してみたいと思った
チームで仕事を始める前にみんなで考えたいと思った
読書会をやってみようと思った

38
社内ブログ
• 見積もり方法
• アジャイルとウォーター
フォールどっちがいいの？
書評書籍リスト
認定資格の情報
おすすめの勉強会やカ
ンファレンスの情報
うまくいったプロジェ
クトの紹介(Award)
サークルの立ち上げ

39
うまくいかないなぁ
私もあまりうまくいってないけ
ど、Aさんのチームはうまく
いったみたいですよ
そうそう。
こういう事例を使って説明した
ら分かってもらえたよ。
なるほど。そういうやり方があ
るのか。そんなに僕も間違って
はいなかったな。諦めずにやり
方考えてみよう。
ひとりでいろいろ頑張るのはツライ

まとめ
40

アジャイルを推進できる条件
まとめ
41
型に囚われ
ない
考えるきっ
かけを作る
土壌を作る

今後の課題
42

今後の課題
43
• 仮説検証型
• アウトカム志向
• アジャイルな動き方が求められる
プロダクトづくり
• 年間ロードマップ、予算編成、組織のあり方
• 人材育成、ノウハウの蓄積
• 人事制度、評価制度、キャリアパス(PO、SM)
• 大規模アジャイル
全社に広げていくのか？
• 疎結合アーキテクチャ
• 技術的負債
• TDD / ペアプロ・モブプロ
• CI/CD
技術力/アーキテクチャ/エンジニアリングカルチャー

最後までお聞きくださり
ありがとうございました
44

大企業でアジャイル開発を推進できる条件とその心構え

More Related Content

What's hot

Similar to 大企業でアジャイル開発を推進できる条件とその心構え

More from LIFULL Co., Ltd.

Recently uploaded

大企業でアジャイル開発を推進できる条件とその心構え

Editor's Notes