良きモノの提供に向けた協働- 開発とテストが一体となったソフトウェア開発 -2016年9月2日

ヤフー株式会社

山口 鉄平

お持ち帰りいただきたいこと• 協働のイメージ• 組織・プロセスの変化例• 明日から改善する気持ちとそのアクションのヒント

2

写真：アフロ

今日の話
前提とする
状況

協働する
開発

現状に至る過程

明日からのアクションまとめ• 前提とする状況• プログラマとテストエンジニアが同じチームにいる開発• 世の中/ヤフー内での事例• 現状に至る過程 -ステップバイステップ• 組織・プロセス• 過程での失敗• 現状の課題• 明日から取れるアクション
• まとめ
3

• Q&A

自己紹介

山口 鉄平
ヤフー株式会社• ソフトウェア開発技術の技術開発/普及、開発改善の推進• 組込みのソフトウェア開発および開発改善を経て、WEBへ• ソフトウェア開発に関係する様々なイベントの企画、運営や発表など社外活動も実施中
4

セッションの進め方

前提とする
状況

5

協働する
開発

現状に至る過程

明日からのアクションまとめ前提とする状況

背景• サービス開発は不確実性が高くかつ正解が不明• どのようなサービスが現れるか予想しにくい• お客様に響くサービスの正解がない

7

背景• お客様への提供コストが低い

8•

WEBサービスやアプリはインフラとしては無償で提供できる環境すら存在する•提供を楽にするツールが充実している

背景• 不具合の深刻度が低い

9•

不具合により発生する損失が少ない•

不具合の改修コストが低い

開発の改善で目指すもの

1. 不具合の少ないサービス・アプリの開発
2. サービス・アプリの素早い提供
開発の基本方針• 早くリリースしフィードバックを得て改善する

10ヤフーの開発

プロダクト12

開発に関わる人は約2000名
ビジネス：プログラマ：
デザイナ：テストが4：20：2：0.5位

チームA
チームC
カンパニー

カンパニー
支援部門

13

プロセス
•

基本的には短期の開発••プロセスの多くはチームや組織に委ねられる
•
•

•

14

全社的に標準プロセスは規定しているが絶対ではない
セキュリティやブランドなどに関しては規定がありチーム側でチェックする

テスト自動化は普及が進んできている••

アジャイル開発とフェーズ型の開発半々くらい様々なテストレベルにおいて探索的テストは実施できていないセッションの進め方前提とする
状況

15

協働する
開発

現状に至る過程

明日からのアクション

まとめ

プログラマとテストエンジニアが同じチームにいる開発

世の中の場合

参考となる書籍

Janet Gregory, Lisa Crispin. 実践アジャイルテスト. 2009. 翔泳社.

18

Janet Gregory, Lisa Crispin. Agile Testing. 2008.
Addison-Wesley Professional.

実践アジャイルテストの第5部• 反復内でのテストエンジニアの動き
18章

15章/16章
19

17章

19章

20章

計画および開発開始前(15章/16章)• 優先順位に基づきテスト計画をする• リリース計画でテストのスコープや時間、リソースを考慮する• 顧客が達成したいことを明確にするため、具体例などを質問する

20

ここ反復開発開始時(17章)• 様々な見方の質問をして、チームが開発対象の理解を促す• 開発タスクと一緒にテストタスクを作成する• 顧客とともにビジネスレベルのテストケースを作成し、プログラマとレビューなどでコミュニケーションを取る

21

ここ反復開発中(18章)• 開発対象の詳細なテストを作成する• シンプルなテストで開発を推進し、そのテストをパスしたら、さらに複雑なテストを作成して開発を促進する• チームの全員がテストをできるようにする
ここ22

反復開発終了時(19章)• テストに関連した障害を整理し、それらを解決する方法を考える

23

ここリリース・デリバリー時(20章)• ドキュメントなど非ソフトウェア以外のリリース物を計画/作成する• 他のグループとのリリースに向けた調整• リリース受け入れ基準の確認

ここ
24

例えば…
「昨日渡したテストをパスできたら次にこれやってもらえませんか？」「この場合どう動くのですか？」「どうなったらそれ完成ですか？」「このリリース受け入れ基準で提供したいこと満たせますよね？」「次の反復でやり方変えませんか？」アジャイルテスティング• 質はビジネス、開発、テストなどチーム全体の責任• テストエンジニアはプロジェクト初期から関わり続ける• テストエンジニアはテスティングや自動化だ
けではなく、完成の定義や要求の明確化に向けた質問をする

26

ヤフーの場合

書籍とは異なる形での協働

自動テストケース作成・実施
自動テストケース作成・実施
皆で手動テストケース作成・実施

変更点に基づく
テストケース作成・実施
テスト設計/
外注管理
変更点を含むサービス全体のテスト設計、
テストケース作成・実施

テスト設計
手動テストケース
作成・実施

パターン1
28

パターン2

パターン3

パターン1：協働が結構進んでいる場合•
自動テストケース作成・実施
皆で手動テストケース作成・実施

テスト設計
29

効果
• 手戻りの削減• プログラマの開発物へのオーナーシップ増加
ここここパターン2：テストの業務委託を含む場合

自動テストケース
作成・実施

テスト設計/
外注管理

手動テストケース
作成・実施
30

•

効果
• 実施できるテストの増加• チームの状況に合わせたテスト業務委託の実現
ここここパターン3：小さいリリースと大きなリリースが並行する場合•
変更点に基づく
テストケース
作成・実施

効果• フェーズ開発との大きなギャップなく、素早いリリースごとのテスト実現

ここサービス全体のテスト設計、
テストケース作成・実施

ここ31書籍とは異なる形での協働

自動テストケース作成・実施
自動テストケース作成・実施
皆で手動テストケース作成・実施

変更点に基づくテストケース作成・実施
テスト設計/
外注管理
変更点を含むサービス全体のテスト設計、テストケース作成・実施

テスト設計
手動テストケース
作成・実施

パターン1
32

パターン2

パターン3

セッションの進め方

前提とする
状況

33

協働する
開発

現状に至る過程

明日からのアクションまとめ現状に至る過程- ステップバイステップ -変化前の状態• 組織・プロセス
リリース
依頼

リリース
承認依頼

ビジネス部門ビジネス部門発注

リリース許可
QA部門
開発物

35

開発部門

リリース
開発部門

変化前の課題①• 業務目標の不一致• 情報の速度と精度が低い
リリース
依頼

リリース
承認依頼

ビジネス部門ビジネス部門発注

リリース許可
QA部門
開発物

36

開発部門

リリース
開発部門

変化前の課題②• サービス責任者がリリースしたい時にリリースできない
リリース
依頼

リリース
承認依頼

ビジネス部門ビジネス部門発注

リリース許可
QA部門
開発物37

開発部門

リリース開発部門

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
38

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

変化の過程組織変化の参考となる書籍/資料『生活改良普及員に学ぶファシリテーターのあり方−戦後日本の経験からの教訓−』
http://jica-ri.jica.go.jp/
IFIC̲and̲JBICI-Studies/jica-ri/publication/archives/jica/
kyakuin/200408̲01.html

Everett M.Rogers. イノベーションの普及.
2007. 翔泳社.

40

Mary Lynn Manns, Linda Rising.
Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン.
2014. 丸善出版.

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
41

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

アジャイル開発試行開始

•42

なぜ？
•

課題を解決したいサービスがあった•

アジャイル開発の経験豊富で技術普及に情熱のある人が支援部門にいたアジャイル開発試行開始•アクション•

課題解決をしたいサービスでアジャイル開発の試行をサポートし始めた
•
•
•

43

一緒に開発しながらティーチング・コーチング
偉い人達へのアジャイル開発の良さの説明
支援先でのアジャイル開発の効果測定

技術普及初期は累積戦略で• 累積戦略•“効果を発揮するある決定的な限界点まで、あまり知覚されないような小さな成果を一つずつ積み上げていくもの”• 順次戦略•

J.C. Wylie. 戦略論の原点. 芙蓉書房出版. 2007.

44“起こった結果を元に順を追って、それぞれ目に見えるような段階を踏んでいくもの”

技術普及初期は累積戦略で

45•

小さな成果を積み上げる•

採用効果の大きいところを優先するよりは導入しやすいところから導入•

普及初期は反発に耐えられない•

変化には抵抗がつきものアジャイル開発試行開始

•

46

結果
•

支援先で課題を改善することができた•

関わったビジネス担当者や開発者の考え方が変化した•

アジャイル開発が定着しないこともあった

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
47

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

アジャイル開発の社内標準への追加

•48

なぜ？
•

社内の標準プロセスにアジャイル開発はなく、利用してよいか不安で試してもらえないことがあった•

社内のアジャイル開発の認知度を挙げたいアジャイル開発の社内標準への追加•アクション•

社内調査および説明行脚
•
•
•

49

どこで決めているのか？
決めるプロセスはどのようになっているのか？
決める際の懸念・ポイントは何か？

アジャイル開発の社内標準への追加•結果•

社内定義に合わせたアジャイル開発の説明
追加
•

50

開発方法論自体が社内標準にはなっていないことが判明•

アジャイル開発の利用に関して不安軽減•

社内のアジャイル開発の認知が多少上昇

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
51

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
52

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

組織/承認プロセスの変更

•53

なぜ？
•

「状況把握→意思決定→実行のスピードを爆発的に速める」という経営陣の意思•

サービス責任者の判断でリリースできない課題への課題感の増加

組織/承認プロセスの変更

•54

アクション
•

サービス単位にチームを再編•

プロジェクトを小さく保つ•

承認プロセス削減

サービス単位にチームを再編•

縦割りからサービス単位にチームを再編：

ビジネス部門
チームA

開発部門
55

チームC

承認プロセス削減• 承認プロセス数：

8→2※サービスへのリリース権限委譲
56

組織/承認プロセスの変更

•57

結果
•

リリース速度の向上•

不具合への意識改善•

開発メンバーのモチベーション向上

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
58

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲テストメンバの開発チーム参加開始/品質向上組織の統合

•

59

なぜ？
•

サービス内でのテストの意識向上•

品質に関係するチームがいくつもあり、相談先がわからない状態になっていたテストメンバの開発チーム参加開始/品質向上組織の統合

•

アクション
•

品質向上支援のあるべき姿の議論実施••

人の異動と組織の統合••

60「サービスの品質向上のためのあらゆる支援を行う」

サービスへのテストエンジニアの異動
複数ロールを1チームにし、そのようなチームを複数にテストメンバの開発チーム参加開始/品質向上組織の統合

•

結果
•

サービスでのテストスキル向上•

サービス開発組織にとって••••支援組織にとって•••61

ワンストップのわかりやすさ
専門家の知見を活用しやすい邪魔じゃない支援
ニーズ変化への対応力向上
新たな支援方法の開発力向上
モチベーション向上

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
62

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

開発支援組織への品質向上組織の統合

•

なぜ？
•

より良い開発に向けては、テストなどの後工程だけでは良くならない
•

•

63

計画の改善やテスト自動化は分断された組織の中では難しい

サービス内でのテストスキルが自律的には向上しなかった

開発支援組織への品質向上組織の統合

•

64

アクション
•

組織の統合とチームの再構成•作業実施支援からスキル向上/自律的実施支援へ変更

開発支援組織への品質向上組織の統合

•

結果
•

社内での技術普及/スキル向上促進•

65

テスト計画やテスト自動化の技術支援および実施者増加

変化の流れ開発組織

アジャイル開発
試行開始

サービス単位にチームを再編

支援組織

経営陣刷新
2010/10以前

2011/102010/10
プロセス

品質向上組織の統合

アジャイル開発の社内標準への追加

開発支援組織への品質向上組織の統合

2013/4

2012/4

QAのリリース承認必須
66

テストメンバの開発チーム参加開始

2014/10

承認プロセス削減
サービスへのリリース権限委譲

変化の中での失敗

変化の中での失敗

68•

技術普及させた技術が定着しない•「質」の定義が曖昧になってしまった

技術普及させた技術が定着しない

•

起きたこと
•

•

技術を教え、サービス内でちょっと実施されはじめたので、支援から離れたらサービス内では実施されなくなった改善策• 狭く深く支援する•

69

チーム内の誰かの習慣およびその人から別のチームメンバーへ技術の伝搬が起きたら支援から離れるようにした

「質」の定義が曖昧になってしまった

•

起きたこと
••

改善策
•

70

サービス内で不具合やサービス間での不均一さなどが増えてきた領域や観点からなる表を公開し、サービス内などで「質」に対する基本的な概念の醸成をおこなっている

現状の課題現状の課題• テストエンジニアの育成• テストスキルの強化• 支援部門の課題抽出および解決技術
強化72

セッションの進め方

前提とする
状況

73

協働する
開発

現状に至る過程

明日からのアクションまとめ明日から取れるアクション

基本的な考え• 良い開発にむけてチームや組織で努力する

75•

作業だけやってもお客様は満足しない•

お客様に喜ばれないものを作るのはもったいないチーム全体でやっていること•

何を確認すべきかのマインドマップ作成•

個人でマインドマップを作成する•

チームで見せ合い、違いを認識する•チームで何を確認するか合意するプログラマの方へテストエンジニアとのコミュニケーション強化•78

テストエンジニアとコミュニケーションを容易に取れるような状態にする•

定期的に話す場を設ける•

席を近くにする•テストに関する言葉を勉強する利用者の立場で開発物を利用する•79

自分のプロダクト・コンポーネントを利用者の気持ちで使ってみる•

色んな利用シーンで利用できているか？

•

使いやすいか？

テストに関する技術の向上•

80

テストに関する技術を学び、実施する•

テストエンジニアから学ぶ•

書籍から学ぶ•セミナーから学ぶプログラマの方へ：まとめ

1. テストエンジニアとコミュニケーションを容易に取れるような状態にする
2. 自分のプロダクト・コンポーネントを利用者の気持ちで使ってみる
3. テストに関する技術を学び、実施する

81テストエンジニアの方へプログラマとのコミュニケーション強化•

83

プログラマとコミュニケーションを容易に取れるような状態にする•

定期的に話す場を設ける•

席を近くにする•

プログラミングに関する言葉を勉強する作ろうとしているものを知り、質問する•

84

プログラマが作ろうとしているものを知り、それに対する疑問を質問する•

どうやって完成を確認するのか？

•作るものの条件漏れはないか？

プログラミングに関する技術の向上•

85

プログラミングに関する技術を学び、実施する•プログラミングから学ぶ•

書籍から学ぶ•セミナーから学ぶテストエンジニアの方へ：まとめ

1. プログラマとコミュニケーションを容易に取れるような状態にする
2. プログラマが作ろうとしているものを知り、それに対する疑問を質問する
3. ( プログラミングに関する技術を学び、テスト自動化などできる状態にする )86

セッションの進め方

前提とする
状況

87

協働する
開発

現状に至る過程

明日からのアクション

まとめ

まとめ

より良い質のモノをより早く提供するためにプログラマもテストエンジニアも互いの仕事を理解し、協力してより良い開発にしていきましょう！

89