1.
デジタルトランスフォーメーションに求められる
システム開発手法
アジャイルとスクラムとは
～価値、原則、プラクティス～
安井 力 (アジャイルコーチ、フリーランス)
Copyright© 2017 by 安井力 / やっとむ tsutomu.yasui@gmail.com

2.
デジタルトランスフォーメーションに求められる
システム開発手法
アジャイルとスクラムとは
～価値、原則、プラクティス～
安井 力 (アジャイルコーチ、フリーランス)
Copyright© 2017 by 安井力 / やっとむ tsutomu.yasui@gmail.com
事業開発手法

3.
安井 力 / やっとむ
twitter:@yattom https://www.facebook.com/yattom
プログラマー
Java Python Ruby JavaScript
テスト駆動開発
アジャイルコーチ
ワークショップ 現場導入 技術支援
ファシリテーター
会議 チームワーク 仕事改善

4.
今日の内容
• アジャイルな企業の例
• アジャイルとはなんなのか？
• アジャイルの価値・原則・プラクティスとは？
• アジャイルに向き不向きはあるの？
• アジャイルをやってみるには？
質問歓迎します！

5.
ある
変わった企業
の話

6.
どこが変わってるの？
•顧客が毎週やってきて、開発チームと一緒に
成果について話す
•プログラマーは全員ペアを組んで仕事をする
•毎週納期、でも残業はぜんぜんない
•ハイテク人類学者がユーザーを研究する
•地下の広大なオフィス(駐車場を改装)で、
座席・デスクが移動自由
•赤ん坊や動物がいる
•喜びがある

7.
他の写真？なにか適当なやつ？
https://www.flickr.com/photos/kitlvcollections/5497319028/
ハイテク人類学者
High-Tech Anthropologists

8.
顧客による計画おりがみ

9.
自律的な進捗管理

10.
ペアプログラミング

11.
顧客を巻き込んだデモ
ショウ＆テル

12.
すなわち……
要件定義 プロジェクト
計画 実装
受入テスト
ハイテク
人類学者
顧客と
計画おりがみ
ペア作業
タスクボード
ショウ＆テル
1週間

13.
MAKE MISTEAKS FASTER
失敗をはやくたさくんしよう

14.
https://www.sonicgarden.jp/201407_family_trip
株式会社ソニックガーデン

15.
どこが変わってるの？
•家族旅行をする
•全社員リモートワーク
•オフィスをなくした
•顧客には顧問プログラマが１人で専任する
•企画から設計、コーディング、運用まですべて
•マネージャがいない
•業務ハッカー募集中
•納品しない受託開発
•プログラマを一生の仕事に

16.
http://getnews.jp/archives/1510240
全社員リモートワーク

17.
https://www.flickr.com/photos/124247024@N07/13903385550/
顧問プログラマ

18.
https://www.slideshare.net/rootmoon/ss-48797871

19.
https://www.slideshare.net/rootmoon/ss-48797871

20.
https://kuranuki.sonicgarden.jp/2014/11/innoswdev_fse.html

21.
1人ひとりがセルフマネジメント
チーム全体がみんなで協力

22.
価値観を共有
https://www.sonicgarden.jp/company

23.
「こうした問題を何とかできないか、一体
何が原因なのかを考え尽くしたところ…
ビジネスモデルそのものに問題があると
分かった」
「もともと私たちはリモートチームを…目
的にしてきたわけではありません。…ビ
ジネスモデルを追究した結果として、リ
モートチームで仕事ができるように」
「変化を受け入れる
変化を恐れない
自らの変化を広げる」
変化
試行錯誤
https://www.sonicgarden.jp/company

24.
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/
Joshua Kerievsky
“Modern Agile”

25.
実験？

26.
アジャイルな
ソフトウェア開発
とは

27.
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
http://agilemanifesto.org/iso/ja/
2001年

28.
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
(続く)
http://agilemanifesto.org/iso/ja/principles.html

29.
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
(続く)
http://agilemanifesto.org/iso/ja/principles.html

30.
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
http://agilemanifesto.org/iso/ja/principles.html

31.
http://agilemanifesto.org/iso/ja/
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

32.
アジャイルとは

33.
Alistair Cockburn
“Heart of Agile”
http://alistair.cockburn.us/HeartOfAgile
2014年

34.
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/
Joshua Kerievsky
“Modern Agile”
2016年

35.
https://speakerdeck.com/kawaguti/kanban-and-scrum

36.
1999
1995
2003
2001
参考:
1991 - Linux
1996 - Java 1.0
2001 – Windows XP
2002 - .NET Framework 1.0
1986
1994 (GoF)

37.
アジャイルな開発の特徴
• ルール、プロセス、手法が常に変わり続けている
• 結果を重視している
• 「そこにいる人びと」ならでは、になっている
• 顧客やステークホルダーの信頼を得ている
• 市場競争力を維持している
• 自主性があり、いきいきして、学び続けている

38.
アジャイルは形容詞
agi・le [形] 素早い、敏捷、しなやかな
• Be Agile, not Do Agile
• アジャイル「を」やる ⇒ できない！
• アジャイル「を」使う ⇒ 誤り
• アジャイル「に」開発する
• アジャイル「な」態度
• 「もっと」アジャイル

39.
形容詞「アジャい」
• アジャい開発
• 「うちのチーム、結構アジャいんですよ」
• 我が社でもアジャイルを導入する
→ 我が社もアジャいくなる
• 「アジャイルをやるのに必須のツールです」
→ 「今よりアジャいくなるのに、お勧めツールです」
※誰も言ってません。流行ったらいいな

40.
価値
• メンローイノベーションズ
• 喜び
• ソニックガーデン
• 一生プログラマ
• アジャイル
• 個人と対話、動くソフトウェア、
顧客との協調、変化への対応
• スクラム
• フォーカス、コミット、オープン、勇気、尊重
• XP (エクストリームプログラミング)
• コミュニケーション、シンプル、フィードバック、
勇気、尊重

41.
プロダクトインクリメント
開発チーム
プロダクトオーナー
スクラムマスター
プロダクトバックログ
デイリースクラム
スプリント

42.
お仕事
頑張ってますか？

43.
何のために
お仕事
頑張ってますか？

44.
何のため＝価値
• 価値とは ほしいもの
• ただでは手に入らない

45.
プログラム
機能
フィーチャ
価値
コスト

46.
C
B
どれを選ぶ？
A
D
価値
コスト

47.
B AD
価値が大きく 早くできるものから
C
1 2 3 4

48.
コスト≒時間
B
A
D
C
コスト

49.
価値は時間累積
B
A
D
C
時間
価値
累積価値

50.
価値は時間累積
B
A
D
C
時間
価値
累積価値

51.
B AD
大価値短期間＝高ROI
C
1 2 3 4

52.
A
A
A
A
A

53.
価値とはほしいもの
• 顧客価値
• 情報、リスク対策
• 生産性

54.
早いほうがいい
細かいほうがいい
先のことも考えたほうがいい

55.
簡単
ですね♪

56.
簡単な
わけがない
💀

57.
お仕事
頑張ってますか？

58.
誰のために
お仕事
頑張ってますか？

59.
誰が
誰のために
お仕事
頑張ってますか？

60.
コミュニケーション

61.
情報帯域

62.
コミュニケーションパス
パス＝3本
1人2本
パス＝10本
1人4本
パス＝66本
1人11本

63.
伝言ゲームと
情報劣化

64.
価値を提供するすべてのスキルを一緒に
ビジネスも技術もマネジメントも一緒に
ユーザーも顧客も開発も一緒に
できるだけ少人数で

65.
簡単な
わけがない
💀

66.
手戻り

67.
技術的負債

68.
機能追加とコスト
時間
価値

69.
価値
コスト
時間
圧
縮
技
術
的
負
債
利
子
コスト
時間
圧
縮
技
術
的
負
債
技術的
負債

70.
技術的負債
• 一時的なメリットを与える(レバレッジ)
• 開発したソフトウェアに内在する
• 開発の作業効率を悪化させる
• 除去作業をしないと取り除けない
• 放置すると増殖する

71.
技術的負債
• 不適切なエンジニアリングで発生する
• 能力不足
• 圧力、プレッシャー
• 考慮不足
• 将来は本質的に予測できない
• 「考慮不足」は不可避
• 「キレイ」な状態を
維持するための作業 = リファクタリング
• 負債をためすぎないうちに返済する
• 将来予測 → 変更容易

72.
変更容易性
• 設計がシンプル
• 変更箇所と内容が自明
• 依存関係が少ない
• 特に隠れた依存関係
• 実装もシンプル
• 誰でも安心して変更できる
• 自動化したテスト
• リグレッション
• 常にこの状態を維持する
• 厳しい規律
• だんだん難しくなる

73.
品質と規律

74.
簡単な
わけがない
💀

75.
人

76.
こんなに難しいことを実現する
仕組みを作るのは困難
こんなに難しいことを実現する
工夫を作れる人

77.
モチベーション3.0
• 自律
• 熟達
• 目的
好きなことに集中することで
より上手になり、できることも広がり
そうして大きな目標を目指せれば
モチベーションが上がる

78.
トヨタウェイの2つの柱は、「知恵と改善」と
「人間性尊重」である。「知恵と改善」は、
常に現状に満足することなく、より高い付
加価値を求めて知恵を絞り続けること。
そして「人間性尊重」は、あらゆるステーク
ホルダーを尊重し、従業員の成長を会社
の成果に結びつけることを意味している。
(トヨタウェイ2001
https://www.toyota.co.jp/jpn/company/history/75years/data/conditions/p
hilosophy/toyotaway2001.html)

79.
４. 企業としての赤福
赤福の会社は創業が1707年
（宝永4年）、設立は1954年（昭和29
年）である。事業内容としては和菓
子の製造・販売、店舗の企画・運営
があげられている。 (中略)赤福のビ
ジョンとして「続けることが進化す
る業（なりわい）であり、進化するこ
とが続ける業である」という言葉が
あげられている。
「赤福追跡」
http://www.ritsumei.ac.jp/~t-ito/otakara/otakara1/akahuku-conte.htm

80.
チームによる学習

81.
イノベーションを産み出し続ける組織
SECIモデル
http://www.atmarkit.co.jp/aig/04biz/seci.html
http://current.ndl.go.jp/ca1518

82.
学習する組織
• システム思考 – 全体を考える
• メンタルモデルへ意識を向け見直す
• 共有ビジョン ― 「自分たちはなにを創造したいのか？」
• チーム学習とアラインメント(合致)
• 経営者を含むマネジメント全体の意識変革
『学習する組織』ピーター・M・センゲ

83.
•価値
•コミュニケーション
•技術
•人

84.
簡単な
わけがない
💀

85.
価値とは……
• 製品のユーザーが何を
望んでいるか知りたい
• ワクチンの効率的配送
サービスを実現する
• 会社の資金が底をつきそう
• 製品が遅い
• 開発スピードが遅い
• 猫の画像でにっこりさせたい
→ 情報
→ 人命
→ 会社存続
→ 実行速度
→ 開発速度
→ しあわせ

86.
プラクティス
•Practice = 練習 実践
•HOW
•なぜやるのか、なんのためにやるのか
• ノウハウではない
• 必須でもない 必要性から要請される
•実験の対象
• うまくいくかどうか やってみて改善
• 実際のやり方はみな違う

87.
朝会 / デイリースタンドアップ
• チーム全員
• 毎日、同じ場所、同じ時間で
• 状況と問題を共有する
• 立ってやる
• 現状を踏まえて計画を見直す
https://www.slideshare.net/yattom/project-facilitation-from-hiranabe

88.
プランニング、計画ゲーム
• イテレーション(1～4週間)にやることを決める
• 優先順位の高いものを取る
• 作業タスクを洗い出してできる範囲を判断する
• 顧客やプロダクトオーナーと開発チームが一緒

89.
ふりかえり / レトロスペクティブ
• チーム全員
• 仕事のやりかたを見直す
• 改善アクションを出す
• チームが自分自身で実験する

90.
XPのプラクティス

91.
スクラムのプラクティス
• 3つの役割
• プロダクトオーナー、開発チーム、スクラムマスター
• スプリント
• 5つのイベント
• スプリントプランニング、スプリントレビュー、
デイリースクラム、レトロスペクティブ、
リファインメント
• 3つの作成物
• プロダクトバックログ、スプリントバックログ、
プロダクトインクリメント

92.
スクラムの3つの役割

93.
スクラムの原則
• 透明性、検査、適応
• 経験的プロセス制御
http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

94.
事例はあとから
• 人の事例は役に立たない
• 状況が違う
• 人も違う
• 事例は「いい話」

95.
事例はあとから
• 自分でやってみる
• 実験する
• まずやってみる
• 結果を分析する
• 「うちはこうだったけど、おたくはどう？」
• 次の実験へのヒントに
• 人を説得する材料にはなる
• 実際には、あまりならない

96.
アジャイルと○○
• アジャイル vs. ウォーターフォール
• 適応型 vs. 計画主導
• 個人依存 vs. 平準化・標準化
• アジャイル vs. DevOps
• アジャイル vs. UX
• など……

97.
アジャイルを
“やってみる”

98.
Unlearn
脱学習

99.
アジャイルの向き不向き
• 効果が期待できるプロジェクト、プロダクト
• 能力を発揮する個人の性向
• チームや組織の文化

100.
カオス
複雑
込み入った
シンプル

101.
https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
Stacey Matrix
要求、スコープ、市場
技術、テクノロジー 不明確明確
不明確
明確

102.
Stacey Matrix
https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
要求、スコープ、市場
技術、テクノロジー 不明確明確
不明確
明確

103.
Stacey Matrix
https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
要求、スコープ、市場
技術、テクノロジー 不明確明確
不明確
明確

104.
On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley
http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html

105.
マインドセット
• Fixed
• 固定的、変化を嫌う、失敗を避ける
• Agile / Growth / Effort
• 成長的、変化する、挑戦する

106.
Fixed vs. Agile
能力 – 不変、背の高さなど
ゴール – 良く見られる
挑戦 – 避ける
失敗 - 個人的な問題
努力 - 能力がない人がやる
困難に直面すると – 無力
能力 – 成長、筋肉など
ゴール – 学ぶ
挑戦 – 受け入れる
失敗 – 情報を得られる
努力 – 熟達への道
困難に直面すると –
回復力(レジリエント)

107.
Fixed vs. Agile
能力 – 不変、背の高さなど
ゴール – 良く見られる
挑戦 – 避ける
失敗 - 個人的な問題
努力 - 能力がない人がやる
困難に直面すると – 無力
能力 – 成長、筋肉など
ゴール – 学ぶ
挑戦 – 受け入れる
失敗 – 情報を得られる
努力 – 熟達への道
困難に直面すると –
回復力(レジリエント)

108.
https://www.youtube.com/watch?v=SMvVJwwMn5A
https://is.gd/Ra15Rq
Linda Rising

109.
イノベーションの普及
https://ja.wikipedia.org/wiki/%E6%99%AE%E5%8F%8A%E5%AD%A6

110.
サーバントリーダーシップ
ト
ッ
プ
ダ
ウ
ン
市
場
・
顧
客
エスカレーション
依存関係の逆転
市場・顧客
意志
決定
意志
決定

111.
自分ごと
• 「対象＋実験(手法)＋観察者」を系とした科学
• 自身の経験を通じて学ぶ
• Participating Consciousness
― 自分自身を世界の一部と認識する
• Tacit Knowledge
― 身体を通じた経験から体得する知

112.
プロダクトインクリメント
開発チーム
プロダクトオーナー
スクラムマスター
プロダクトバックログ
デイリースクラム
スプリント

113.
品質の作り込み

114.
品質の作り込み

115.
品質の作り込み
• ペアプログラミング
• コード共同所有
• テストエンジニアが一緒に開発する
• テスト駆動開発(TDD)
• テスト自動化
• 継続的インテグレーション(CI)
• 継続的デリバリー(CD)
• モニタリング

116.
• TDD
• Test Driven Development
• テスト駆動開発

117.
• 動作するきれいなコード

118.
• 動作する

119.
• きれい

120.
動作する、きれいなコード
きれい
汚い
(すぐには)動かない 動作する

121.
テスト駆動開発

122.
• 1. テストを書く
• 2. 実行して失敗させる
• 3. テストが通る実装を書く
• 4. テストを成功させる
• 5. テストが通る状態のままリファクタリングする

123.
動作する、きれいなコードへ
きれい
汚い
(すぐには)動かない 動作する
二つの道がある

124.
TDDでサイクルにする
きれい
汚い
(すぐには)動かない 動作する

125.
きれい
汚い
(すぐには)動かない 動作する
Green
Refactoring
TDDと黄金の回転

126.
• 自信と安心

127.
テストファースト

128.
テスト駆動開発の効果
IBM
ドライバ
Microsoft
Windows
Microsoft
MSN
Microsoft
VisualStudio
チーム人数 9 6 5-7 7
コード量
(KLOC)
41.0 6.0 26.0 155.2
開発規模(人月) 119 24 46 20
欠陥数
(TDD未使用に
対する)
61% 38% 24% 9%
開発時間の増加
(管理者の見積)
15～
20％
25～35％ 15％ 20～25％
Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through
test driven development: results and experiences of four industrial teams” 2008
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

129.
保守性への影響
生産性
(行数/工数)
保守性 ※1
(工数/変更件数)
プロジェクトA
(非TDD)
2.3 84
プロジェクトB
(非TDD)
2.5 80
プロジェクトC
(TDD)
1.8 59
※1 保守期間(260日間)中、変更要求の対応にかかった工数の平均
"The effectiveness of test-driven development: an industrial case study"
(Tomazˇ Dogsˇa • David Baticˇ , Software Qual J (2011))

130.
TDDの効果の研究をまとめた研究
"Effects of Test-Driven Development: A
Comparative Analysis of Empirical Studies" Simo
Makinen and Jurgen Munch, 2013
• 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究
の結論を整理した
• TDDは欠陥の作り込み(introduced defects)を減らし、メンテナン
スしやすいコードを産む
• TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低
い場合がある
• メンテナンスがしやすくなるものの、初期開発では時間がかかる

131.
TDDの効果の研究をまとめた研究
やっとむ TDD 検索

132.
• TDDのテストはテストではない！！ …のか？

133.
http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html

134.
• テスティング Testing
• チェッキング Checking

135.
アジャイルテスト 高品質を追求するアジャイルチームにおけるテストの視点 増田聡 Developer Summit 2010
http://www.slideshare.net/satoshimasuda/ss-3241717

136.
• 品質のためのテスト-ユニットテスト-TDDのテスト

137.
JaSST’11 Tokyo 新しいTDDアプローチ http://togetter.com/li/93719

138.
テスト自動化のメリット
• 回帰テスト
• 追加/変更が容易、安心
• 品質管理しやすい、品質向上
• 機能横断と多能工
• 依存性排除
• 他にもたくさん！

139.
• システムテスト自動化標準ガイド

140.
• ソフトウェアテスト技法ドリル

141.
テスト書きたい？

142.
• TDD×テスト自動化

143.
品質とは
誰かにとっての価値
― G. M. Weinberg

144.
～さいごに～
なぜアジャイル？

145.
なぜアジャイル？
• アジャイルプラクティスが便利だから？
• アジャイルだと生産性が良さそうだから？
• アジャイルだとお客さんやユーザーの
満足度が高まるから？
• 競合に勝てるアジリティを身に付けたいから？
• アジャイルの価値を追求したいから？
• 自分たちの価値を追求するのに、
アジャイルな態度が必要だから？
• 自分たちの価値とアジャイルの価値が
親和性が高く、同じことを目指すから？

146.
おすすめ書籍など
• 『アジャイル開発とスクラム』平鍋健児 野中郁次郎 https://is.gd/3VXy43
• アジャイル開発やスクラムの概要や全体像、
企業から見てどういうメリットがあるのか
• 『アジャイルサムライ』Jonathan Rasmusson https://is.gd/K9zZf4
• アジャイル開発を実際に始める方法
• 『スクラムブートキャンプTHE BOOK』西村、永瀬、吉羽 https://is.gd/VVfMw7
• スクラムの実際のやりかたについてお気楽に学べる
• 『アジャイルな見積りと計画づくり』Mike Cohn https://is.gd/lBZ6aN
• 価値を生み出す計画をアジャイルに作り、進める方法
• 『塹壕より ＳｃｒｕｍとＸＰ』 Henrik Kniberg https://is.gd/jaPSty
• 無料ＰＤＦ。アジャイルの実例と工夫
• 『テスト駆動開発による組み込みプログラミング』 James W. Grenning
https://is.gd/qW1yMX
• C言語による組み込み開発向けのTDD手法を基本から