良きモノの提供に向けた協働 - JaSST · 2016年9月2日ヤフー株式会社山口鉄平良きモノの提供に向けた協働-開発とテストが一体となったソフトウェア開発-

2016年9月2日

ヤフー株式会社山口鉄平

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

お持ち帰りいただきたいこと

• 協働のイメージ

• 組織・プロセスの変化例

• 明日から改善する気持ちとそのアクションのヒント

2 写真：アフロ

今日の話

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

• 世の中/ヤフー内での事例

• 現状に至る過程 -ステップバイステップ-• 組織・プロセス• 過程での失敗• 現状の課題

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

• Q&A3

前提とする状況

協働する開発

現状に至る過程

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

自己紹介

• ソフトウェア開発技術の技術開発/普及、開発改善の推進

• 組込みのソフトウェア開発および開発改善を経て、WEBへ

• ソフトウェア開発に関係する様々なイベントの企画、運営や発表など社外活動も実施中

4

山口鉄平ヤフー株式会社

セッションの進め方

5


協働する開発




背景

• サービス開発は不確実性が高くかつ正解が不明

• どのようなサービスが現れるか予想しにくい

• お客様に響くサービスの正解がない

7

背景

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

• WEBサービスやアプリはインフラとしては無償で提供できる環境すら存在する

• 提供を楽にするツールが充実している

8

背景

• 不具合の深刻度が低い

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

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

9

開発の改善で目指すもの

開発の基本方針

• 早くリリースしフィードバックを得て改善する

10

1. 不具合の少ないサービス・アプリの開発2. サービス・アプリの素早い提供

ヤフーの開発

プロダクト

12

開発に関わる人は約2000名

13

チームA

カンパニー

チームC

カンパニー

ビジネス：プログラマ：デザイナ：テストが4：20：2：0.5位

支援部門

プロセス

• 基本的には短期の開発• アジャイル開発とフェーズ型の開発半々くらい

• プロセスの多くはチームや組織に委ねられる• 全社的に標準プロセスは規定しているが絶対ではない• セキュリティやブランドなどに関しては規定がありチーム側で

チェックする

• テスト自動化は普及が進んできている• 様々なテストレベルにおいて

• 探索的テストは実施できていない

14


15


協働する開発



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

世の中の場合

参考となる書籍

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

Addison-Wesley Professional.

実践アジャイルテストの第5部

• 反復内でのテストエンジニアの動き

19

15章/16章

17章 19章

18章

20章

計画および開発開始前(15章/16章)

• 優先順位に基づきテスト計画をする

• リリース計画でテストのスコープや時間、リソースを考慮する

• 顧客が達成したいことを明確にするため、具体例などを質問する

20 ここ

反復開発開始時(17章)

• 様々な見方の質問をして、チームが開発対象の理解を促す

• 開発タスクと一緒にテストタスクを作成する

• 顧客とともにビジネスレベルのテストケースを作成し、プログラマとレビューなどでコミュニケーションを取る

21 ここ

反復開発中(18章)

• 開発対象の詳細なテストを作成する

• シンプルなテストで開発を推進し、そのテストをパスしたら、さらに複雑なテストを作成して開発を促進する

• チームの全員がテストをできるようにする

22

ここ

反復開発終了時(19章)

• テストに関連した障害を整理し、それらを解決する方法を考える

23 ここ

リリース・デリバリー時(20章)

• ドキュメントなど非ソフトウェア以外のリリース物を計画/作成する

• 他のグループとのリリースに向けた調整

• リリース受け入れ基準の確認

24

ここ

例えば…

「どうなったらそれ完成ですか？」

「昨日渡したテストをパスできたら次にこれやってもらえませんか？」

「この場合どう動くのですか？」

「次の反復でやり方変えませんか？」

「このリリース受け入れ基準で提供したいこと満たせますよね？」

アジャイルテスティング

• 質はビジネス、開発、テストなどチーム全体の責任

• テストエンジニアはプロジェクト初期から関わり続ける

• テストエンジニアはテスティングや自動化だけではなく、完成の定義や要求の明確化に向けた質問をする

26

ヤフーの場合

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

28

パターン1 パターン2 パターン3

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

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

テスト設計


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

テスト設計/外注管理

変更点に基づくテストケース作成・実施

変更点を含むサービス全体のテスト設計、テストケース作成・実施

パターン1：協働が結構進んでいる場合

• 効果• 手戻りの削減• プログラマの開発物へのオーナーシップ増加

29



テスト設計

ここここ

パターン2：テストの業務委託を含む場合

• 効果• 実施できるテストの増加• チームの状況に合わせたテスト業務委託の実現

30

ここここ




パターン3：小さいリリースと大きなリリースが並行する場合

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

31

ここ


サービス全体のテスト設計、

テストケース作成・実施

ここ

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

32

パターン1 パターン2 パターン3



テスト設計





変更点を含むサービス全体のテスト設計、テストケース作成・実施


33


協働する開発



現状に至る過程- ステップバイステップ -

変化前の状態

• 組織・プロセス

35

ビジネス部門

開発部門

QA部門

発注

リリース承認依頼

開発物

リリース許可ビジネス部門

開発部門

リリース依頼

リリース

変化前の課題①

• 業務目標の不一致• 情報の速度と精度が低い

36

ビジネス部門

開発部門

QA部門

発注


開発物


開発部門

リリース依頼

リリース

変化前の課題②

• サービス責任者がリリースしたい時にリリースできない

37

ビジネス部門

開発部門

QA部門

発注


開発物


開発部門

リリース依頼

リリース

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

変化の流れ

38

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10

QAのリリース承認必須サービスへのリリース権限委譲

開発組織

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

アジャイル開発試行開始

経営陣刷新

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

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

品質向上組織の統合

プロセス

支援組織

承認プロセス削減

変化の過程

組織変化の参考となる書籍/資料

40

『生活改良普及員に学ぶファシリテーターのあり方－戦後日本の経験からの教訓－』

http://jica-ri.jica.go.jp/IFIC_and_JBICI-Studies/jica-ri/publication/archives/jica/

kyakuin/200408_01.html

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

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


変化の流れ

41

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織



• なぜ？

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

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

42


• アクション

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

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

43

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

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

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

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

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

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

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

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

• 変化には抵抗がつきもの

45


• 結果

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

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

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

46


変化の流れ

47

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織



• なぜ？

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

• 社内のアジャイル開発の認知度を挙げたい

48


• アクション

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

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

49


• 結果

• 社内定義に合わせたアジャイル開発の説明追加• 開発方法論自体が社内標準にはなっていないことが判明

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

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

50


変化の流れ

51

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織



変化の流れ

52

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織


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

• なぜ？

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

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

53


• アクション

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

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

• 承認プロセス削減

54


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

55

チームA

チームC

ビジネス部門

開発部門


• 承認プロセス数：

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

56


• 結果

• リリース速度の向上

• 不具合への意識改善

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

57


変化の流れ

58

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織


テストメンバの開発チーム参加開始/品質向上組織の統合

• なぜ？

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

• 品質に関係するチームがいくつもあり、相談先がわからない状態になっていた

59


• アクション

• 品質向上支援のあるべき姿の議論実施• 「サービスの品質向上のためのあらゆる支援を行う」

• 人の異動と組織の統合• サービスへのテストエンジニアの異動• 複数ロールを1チームにし、そのようなチームを複数に

60


• 結果

• サービスでのテストスキル向上• サービス開発組織にとって• ワンストップのわかりやすさ• 専門家の知見を活用しやすい• 邪魔じゃない支援

• 支援組織にとって• ニーズ変化への対応力向上• 新たな支援方法の開発力向上• モチベーション向上

61


変化の流れ

62

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織



• なぜ？

• より良い開発に向けては、テストなどの後工程だけでは良くならない• 計画の改善やテスト自動化は分断された組織の中では難しい

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

63


• アクション

• 組織の統合とチームの再構成

• 作業実施支援からスキル向上/自律的実施支援へ変更

64


• 結果

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

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

65


変化の流れ

66

2010/10以前

2010/10

2011/10

2012/4

2013/4

2014/10


開発組織



経営陣刷新




プロセス

支援組織


変化の中での失敗

変化の中での失敗

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

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

68

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

• 起きたこと• 技術を教え、サービス内でちょっと実施されはじめたので、支援から離れたらサービス内では実施されなくなった

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

69

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

• 起きたこと• サービス内で不具合やサービス間での不均一さなどが増えてきた

• 改善策• 領域や観点からなる表を公開し、サービス内などで「質」に対する基本的な概念の醸成をおこなっている

70

現状の課題

現状の課題

• テストエンジニアの育成

• テストスキルの強化

• 支援部門の課題抽出および解決技術強化

72


73


協働する開発



明日から取れるアクション

基本的な考え

• 良い開発にむけてチームや組織で努力する

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

• お客様に喜ばれないものを作るのはもったいない

75

チーム全体でやっていること

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

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

• チームで見せ合い、違いを認識する

• チームで何を確認するか合意する

プログラマの方へ

テストエンジニアとのコミュニケーション強化

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

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

• 席を近くにする

• テストに関する言葉を勉強する

78

利用者の立場で開発物を利用する

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

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

• 使いやすいか？

79

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

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

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

• 書籍から学ぶ

• セミナーから学ぶ

80

プログラマの方へ：まとめ

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

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

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

81

テストエンジニアの方へ

プログラマとのコミュニケーション強化

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

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

• 席を近くにする

• プログラミングに関する言葉を勉強する

83

作ろうとしているものを知り、質問する

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

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

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

84

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

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

• プログラミングから学ぶ

• 書籍から学ぶ

• セミナーから学ぶ

85

テストエンジニアの方へ：まとめ

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

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

3. ( プログラミングに関する技術を学び、テスト自動化などできる状態にする )

86


87


協働する開発



まとめ

より良い質のモノをより早く提供するために

プログラマもテストエンジニアも

互いの仕事を理解し、協力して

より良い開発にしていきましょう！

89

Documents

良きモノの提供に向けた協働 - JaSST · 2016年9月2日 ヤフー株式会社 山口鉄平 良きモノの提供に向けた協働-開発とテストが一体となったソフトウェア開発-

良きモノの提供に向けた協働 - JaSST · 2016年9月2日ヤフー株式会社山口鉄平良きモノの提供に向けた協働-開発とテストが一体となったソフトウェア開発-