良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
- 1. 2016年9月2日 ヤフー株式会社 山口 鉄平 良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
- 2. お持ち帰りいただきたいこと • 協働のイメージ • 組織・プロセスの変化例 • 明日から改善する気持ちと そのアクションのヒント 2 写真：アフロ
- 3. 今日の話 • 前提とする状況 • プログラマとテストエンジニアが同じチームにいる開発 • 世の中/ヤフー内での事例 • 現状に至る過程 -ステップバイステップ- • 組織・プロセス • 過程での失敗 • 現状の課題 • 明日から取れるアクション • まとめ • Q&A3 前提とする 状況 協働する 開発 現状に 至る過程 明日からの アクション まとめ
- 4. 自己紹介 • ソフトウェア開発技術の技術開発/普及、開発改善の推進 • 組込みのソフトウェア開発および開発改善を経て、WEBへ • ソフトウェア開発に関係する様々なイベントの企画、運営や 発表など社外活動も実施中 4 山口 鉄平 • ヤフー株式会社 • 一般社団法人 アジャイルチームを支える会
- 6. 前提とする状況
- 7. 背景 • サービス開発は不確実性が高くかつ 正解が不明 • どのようなサービスが現れるか予想しにくい • お客様に響くサービスの正解がない 7
- 8. 背景 • お客様への提供コストが低い • WEBサービスやアプリはインフラとしては無償 で提供できる環境すら存在する • 提供を楽にするツールが充実している 8
- 9. 背景 • 不具合の深刻度が低い • 不具合により発生する損失が少ない • 不具合の改修コストが低い 9
- 10. 開発の改善で目指すもの 開発の基本方針 • 早くリリースしフィードバックを得て改善する 10 1. 不具合の少ないサービス・アプリの開発 2. サービス・アプリの素早い提供
- 11. ヤフーの開発
- 12. プロダクト 12
- 14. プロセス • 基本的には短期の開発 • アジャイル開発とフェーズ型の開発半々くらい • プロセスの多くはチームや組織に委ねられる • 全社的に標準プロセスは規定しているが絶対ではない • セキュリティやブランドなどに関しては規定がありチームで 確認している • テスト自動化は普及が進んできている • 様々なテストレベルにおいて • 探索的テストは実施できていない 14
- 17. 世の中の場合
- 18. 参考となる書籍 18 Janet Gregory, Lisa Crispin. 実践アジャイルテスト. 2009. 翔泳社. Janet Gregory, Lisa Crispin. Agile Testing. 2008. Addison-Wesley Professional.
- 20. 計画および開発開始前(15章/16章) • 優先順位に基づきテスト計画をする • リリース計画でテストのスコープや時間、 リソースを考慮する • 顧客が達成したいことを明確にするため、 具体例などを質問する 20 ここ
- 21. 反復開発開始時(17章) • 様々な見方の質問をして、チームが開発対象の 理解を促す • 開発タスクと一緒にテストタスクを作成する • 顧客とともにビジネスレベルのテストケースを 作成し、プログラマとレビューなどでコミュニ ケーションを取る 21 ここ
- 22. 反復開発中(18章) • 開発対象の詳細なテストを作成する • シンプルなテストで開発を推進し、そのテス トをパスしたら、さらに複雑なテストを作成 して開発を促進する • チームの全員がテストをできるようにする 22 ここ
- 24. リリース・デリバリー時(20章) • ドキュメントなど非ソフトウェア以外の リリース物を計画/作成する • 他のグループとのリリースに向けた調整 • リリース受け入れ基準の確認 24 ここ
- 26. アジャイルテスティング • 質はビジネス、開発、テストなどチーム全体 の責任 • テストエンジニアはプロジェクト初期から関 わり続ける • テストエンジニアはテスティングや自動化だ けではなく、完成の定義や要求の明確化に向 けた質問をする 26
- 27. ヤフーの場合
- 29. パターン1：協働が結構進んでいる場合 • 効果 • 手戻りの削減 • プログラマの開発物への オーナーシップ増加 29 自動テストケース 作成・実施 皆で手動テスト ケース作成・実施 テスト設計 ここ ここ
- 30. パターン2：テストの業務委託を含む場合 • 効果 • 実施できるテストの増加 • チームの状況に合わせた テスト業務委託の実現 30 ここ ここ 自動テストケース 作成・実施 手動テストケース 作成・実施 テスト設計/ 外注管理
- 39. 変化の過程
- 40. 組織変化の参考となる書籍/資料 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. 丸善出版.
- 42. アジャイル開発試行開始 • なぜ？ • 課題を解決したいサービスがあった • アジャイル開発の経験豊富で技術普及に 情熱のある人が支援部門にいた 42
- 43. アジャイル開発試行開始 • アクション • 課題解決をしたいサービスでアジャイル 開発の試行をサポートし始めた • 一緒に開発しながらティーチング・コーチング • 偉い人達へのアジャイル開発の良さの説明 • 支援先でのアジャイル開発の効果測定 43
- 44. 技術普及初期は累積戦略で • 累積戦略 • 効果を発揮するある決定的な 限界点まで、あまり知覚され ないような小さな成果を一つ ずつ積み上げていくもの • 順次戦略 • 起こった結果を元に順を追っ て、それぞれ目に見えるよう な段階を踏んでいくもの 44 J.C. Wylie. 戦略論の原点. 芙蓉書房出版. 2007.
- 45. 技術普及初期は累積戦略で • 小さな成果を積み上げる • 採用効果の大きいところを優先するよりは 導入しやすいところから導入 • 普及初期は反発に耐えられない • 変化には抵抗がつきもの 45
- 46. アジャイル開発試行開始 • 結果 • 支援先で課題を改善することができた • 関わったビジネス担当者や開発者の考え方 が変化した • アジャイル開発が定着しないこともあった 46
- 48. アジャイル開発の社内標準への追加 • なぜ？ • 社内の標準プロセスにアジャイル開発は なく、利用してよいか不安で試してもら えないことがあった • 社内のアジャイル開発の認知度を挙げたい 48
- 49. アジャイル開発の社内標準への追加 • アクション • 社内調査および説明行脚 • どこで決めているのか？ • 決めるプロセスはどのようになっているのか？ • 決める際の懸念・ポイントは何か？ 49
- 50. アジャイル開発の社内標準への追加 • 結果 • 社内定義に合わせたアジャイル開発の説明 追加 • 開発方法論自体が社内標準にはなっていないこと が判明 • アジャイル開発の利用に関して不安軽減 • 社内のアジャイル開発の認知が多少上昇 50
- 53. 組織/承認プロセスの変更 • なぜ？ • 「状況把握→意思決定→実行のスピードを 爆発的に速める」という経営陣の意思 • サービス責任者の判断でリリースできない 課題への課題感の増加 53
- 54. 組織/承認プロセスの変更 • アクション • サービス単位にチームを再編 • プロジェクトを小さく保つ • 承認プロセス削減 54
- 57. 組織/承認プロセスの変更 • 結果 • リリース速度の向上 • 不具合への意識改善 • 開発メンバーのモチベーション向上 57
- 59. テストメンバの開発チーム参加開始/品質向上組織の統合 • なぜ？ • サービス内でのテストの意識向上 • 品質に関係するチームがいくつもあり、 相談先がわからない状態になっていた 59
- 60. テストメンバの開発チーム参加開始/品質向上組織の統合 • アクション • 品質向上支援のあるべき姿の議論実施 • 「サービスの品質向上のためのあらゆる支援を行う」 • 人の異動と組織の統合 • サービスへのテストエンジニアの異動 • 複数ロールを1チームにし、そのようなチームを複数に 60
- 61. テストメンバの開発チーム参加開始/品質向上組織の統合 • 結果 • サービスでのテストスキル向上 • サービス開発組織にとって • ワンストップのわかりやすさ • 専門家の知見を活用しやすい • 邪魔じゃない支援 • 支援組織にとって • ニーズ変化への対応力向上 • 新たな支援方法の開発力向上 • モチベーション向上 61
- 63. 開発支援組織への品質向上組織の統合 • なぜ？ • より良い開発に向けては、テストなどの 後工程だけでは良くならない • 計画の改善やテスト自動化は分断された組織 の中では難しい • サービス内でのテストスキルが自律的に は向上しなかった 63
- 64. 開発支援組織への品質向上組織の統合 • アクション • 組織の統合とチームの再構成 • 作業実施支援からスキル向上/自律的実施 支援へ変更 64
- 65. 開発支援組織への品質向上組織の統合 • 結果 • 社内での技術普及/スキル向上促進 • テスト計画やテスト自動化の技術支援および 実施者増加 65
- 67. 変化の中での失敗
- 69. 技術普及させた技術が定着しない • 起きたこと • 技術を教え、サービス内でちょっと実施されはじ めたので、支援から離れたらサービス内では実施 されなくなった • 改善策 • 狭く深く支援する • チーム内の誰かの習慣およびその人から別の チームメンバーへ技術の伝搬が起きたら支援 から離れるようにした 69
- 70. 「質」の定義が曖昧になってしまった • 起きたこと • サービス内で不具合やサービス間での不均一さ などが増えてきた • 改善策 • 領域や観点からなる表を公開し、サービス内など で「質」に対する基本的な概念の醸成をおこなっ ている 70
- 71. 現状の課題
- 72. 現状の課題 • テストエンジニアの育成 • テストスキルの強化 • 支援部門の課題抽出および解決技術 強化 72
- 74. 明日から取れるアクション
- 75. 基本的な考え • 良い開発にむけてチームや組織で 努力する • 作業だけやってもお客様は満足しない • お客様に喜ばれないものを作るのは もったいない 75
- 76. チーム全体でやっていること • 何を確認すべきかのマインドマップ作成 • 個人でマインドマップを作成する • チームで見せ合い、違いを認識する • チームで何を確認するか合意する
- 77. プログラマの方へ
- 78. テストエンジニアとのコミュニケーション強化 • テストエンジニアとコミュニケーショ ンを容易に取れるような状態にする • 定期的に話す場を設ける • 席を近くにする • テストに関する言葉を勉強する 78
- 80. テストに関する技術の向上 • テストに関する技術を学び、実施する • テストエンジニアから学ぶ • 書籍から学ぶ • セミナーから学ぶ 80
- 81. プログラマの方へ：まとめ 1. テストエンジニアとコミュニケーショ ンを容易に取れるような状態にする 2. 自分のプロダクト・コンポーネントを 利用者の気持ちで使ってみる 3. テストに関する技術を学び、実施する 81
- 82. テストエンジニアの方へ
- 83. プログラマとのコミュニケーション強化 • プログラマとコミュニケーションを 容易に取れるような状態にする • 定期的に話す場を設ける • 席を近くにする • プログラミングに関する言葉を勉強する 83
- 84. 作ろうとしているものを知り、質問する • プログラマが作ろうとしているものを 知り、それに対する疑問を質問する • どうやって完成を確認するのか？ • 作るものの条件漏れはないか？ 84
- 85. プログラミングに関する技術の向上 • (必ず学ぶべきとは言わないが…) プログラミングに関する技術を学び、 実施する • プログラミングから学ぶ • 書籍から学ぶ • セミナーから学ぶ 85
- 86. テストエンジニアの方へ：まとめ 1. プログラマとコミュニケーションを 容易に取れるような状態にする 2. プログラマが作ろうとしているものを 知り、それに対する疑問を質問する 3. プログラミングに関する技術を学び、 テスト自動化などできる状態にする 86
- 88. まとめ
- 89. Q&A 89