More Related Content
Similar to DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏 (20)
More from Yusuke Suzuki (17)
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
- 1. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
DX時代に目指すべき
品質向上とテスト
2019/6/25
グロース・アーキテクチャ&チームス株式会社
代表取締役 鈴木 雄介
@IT ソフトウェア品質向上セミナー 2019夏
- 2. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
自己紹介
• 鈴木雄介
–Graat(グラーツ)
» グロース・アーキテクチャ&チーム
ス株式会社
▸ 代表取締役 社長
» http://www.graat.co.jp/
–SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
1
- 6. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
• システム開発の流れを「早く」したい
• スピードは「リードタイム」で理解する
–工程にかかった時間+調整/待ち時間
DX時代のシステム開発
5
企画
立案
概算
見積
予算
稟議
詳細
見積
要員
計画
実装
&テスト
システム
テスト
品質
検査
リリース
作業
受入
テスト
全工程の20%~35%
- 9. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
アジャイル開発
• 特徴とメリット
–先にリソースを確保しておく
» 調達期間を作らない
» チームを成長し、習熟していく
–定期的に計画し、リリースする
» その時点の優先順位で判断する
» 次のリリースがあることを前提に曖昧な要件を排除する
–動くソフトウェアを重視する
» 仕様書での品質確認を重視しない
» 関係者全員で合意形成する
8
- 11. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
アジャイル開発
• 電車
–スケジュールに従わなければ乗れない
–車両の大きさは決まっているので、効率的に乗客を
詰めることが大事
–専用線なので、かなりの精度で到着する
• タクシー
–呼びたいときに呼べるが捕まるとは限らない
–必要な台数を選べるが、確保できるとは限らない
–道路が混むこともある
10
- 12. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
リリーストレイン
• アジャイル開発は電車で考える
–まずは運行計画が大事
» どの頻度で、どの大きさの車両にするかを予測する
–乗せる客は、その時点でホームにいる人から選ぶ
» 時間厳守!遅れたらタクシーか、次の電車
• もちろん、タクシーも重要
–全ての開発が電車である必要は無い
11
- 13. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
アジャイル開発
• 企画~実装までのリードタイム
–調整/待ちが不要になる
12
企画
立案
概算
見積
予算
稟議
詳細
見積
要員
計画
実装
&テスト
年間
予算
企画
立案
詳細
検討
実施
判断
実装
&テスト
- 15. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
DevOps
• DevOpsとは
–運用作業の自動化を通じて、開発者がセルフサービ
スでシステムを運用できるようにすること
» NoOps:マニュアル化できるような運用作業は自動化へ
–代表的なのはリリースに関する作業の自動化
» CI/CD
» その他にも…
▸ 障害検知、インシデント起票、障害連絡、復旧作業
▸ OSやミドルウェアのパッチ適用
14
- 16. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
CI/CD
• リリースに関する作業の自動化
15
運用ツール
開発部門
運用/品質
部門
アプリ
ケーション サービス
開発部門 サービス
DevOps
チーム
アプリ
ケーション
- 17. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
CI/CD
• リリースに関する作業の自動化
–テストで品質を確認しながらフェーズを進める
16
ビルド環境
開発/テスト
環境
ステージング
環境
本番
環境
ユニット
テスト
単体/結合
テスト
システム/受入
テスト
本番動作確認ソース
コード
※性能試験
※セキュリティ試験
- 18. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
• 自動化する
–環境構築+デプロイ+テストがセット
–トリガーは開発者のコードマージ作業
継続的インテグレーション
CI/CD
17
ビルド環境
開発/テスト
環境
ステージング
環境
本番
環境
ユニット
テスト
単体/結合
テスト
システム/受入
テスト
本番動作確認ソース
コード
継続的デリバリ
継続的デプロイメント
自動パッケージング
- 19. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
CI/CD詳細
18
ビルド環境
開発/テスト
環境
コード
取得
ソース
コード
ビルド
ユニット
テスト
パッケー
ジング
アプリケー
ション
レポジトリ
環境
構築
デプロイ
自動
テスト
ステージング
環境
環境
構築
デプロイ
自動
テスト
本番
環境
環境
構築
デプロイ
自動
テスト
本番
切替え
コード
マージ
CI/CD
ツール
Web
hook
- 20. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
CI/CD
• 自動化すべきテスト
–静的コード解析
–ユニットテスト/インテグレーションテスト
–E2Eテスト/ファンクショナルテスト
» 受入テスト
–セキュリティテスト
–障害テスト/FIT
19
- 21. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
CI/CD
• テスト自動化の導入判断
–手動で実施するよりも品質↑工数↓になるか?
» 何を自動にして、何を手動にするのかの判断
» リグレッションテスト
» 網羅性が求められるテスト
▸ ブラウザ互換など
• 開発チームの中にテストコーダーをいれる
–新機能では機能とテストの実装をセットで実施
20
- 22. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
DevOpsチーム
• 必要なスキル
–アプリケーション構成とシステム構成の理解
–各工程に必要なテストの概要
–自動化スクリプトの作成
» インフラのコード化(Infrastructure as Code)
» デプロイ手順のコード化
» テスト実施のコード化
▸ テストの中味は開発チーム
• 誰が?
–開発部門+運用部門+QA部門
21
- 23. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
• 実装~リリースまでのリードタイム
–調整/待ちが不要になる
DevOps
22
実装
&テスト
システム
テスト
品質
検査
リリース
作業
受入
テスト
実装
&テスト
CI/CD リリース
- 24. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
アジャイル+DevOps
• 企画~実装~リリースまでのリードタイム
–従来の品質を維持したまま調整/待ちを排除
23
企画
立案
概算
見積
予算
稟議
詳細
見積
要員
計画
実装
&テスト
システム
テスト
品質
検査
リリース
作業
受入
テスト
実装
&テスト
CI/CD リリース
企画
立案
詳細
検討
実施
判断
- 27. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
アジャイル開発の適用
• 阻害要因:既存のプロセス、組織、規則、文化
–稟議
» 「何をやるか決めないと稟議が通らない」
» 「稟議で決まったことだから」
–部門の縦割りと丸投げ
» 「企画がー」「開発がー」「QAがー」「運用がー」
» 「情シスがー」「経営がー」
–全ての調整ごと
» 「現場が忙しい」「基幹システムが遅い」「ベンダーが遅
い」
26
- 28. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
DevOpsの適用
• 阻害要因:既存プロセス、組織、規則、文化
–既存のガバナンス
» 「○○というツール/手順がルールです」
» 「ルール通りなのに問題があったらしかたない」
–部門の縦割りと丸投げ
» 他部門の効率化には口を出さない/出せない
–自部門の仕事を無くす仕事ができない
» クラウド化したのに既存のツールを手放さない
» 運用部門やQA部門には自動化が想像できない
27
- 29. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
適用に向けた第一歩
• 部門を横断して話し合う
–トップダウンは機能しない
» トップの指示は実行性は伴わない
• 話し合いのステップ
–まずは、お互いのやっていることを理解する
–部門関係なく課題を見つける
–協力して解決する
• そもそも、目指すべき所は一緒のはず
–既存を全否定することはない
28
- 31. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
さらに、その先へ
• 組織のプロセスを見直す
–本質的には意思決定プロセスの設計
» 全部門を巻き込んで策定を行う
» 誰が、いつ、何を判断するのがよいのか?
–部門を跨がる判断は、その上が意思決定するべき
» 部門内の判断は部門長でよい
–基本的に事業部門が判断するようにする
» 企画部門にプロダクトオーナーをやらせない
–複数システムに跨がる開発は四半期定期を推奨
30
- 33. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
まとめ
• DX時代はリードタイムを早くしたい
• 遅い理由は調整や待ち時間
32
企画
立案
概算
見積
予算
稟議
詳細
見積
要員
計画
実装
&テスト
システム
テスト
品質
検査
リリース
作業
受入
テスト
全工程の20%~35%
- 34. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
まとめ
• 調整や待ち時間をなくしていく
–アジャイル:企画~実装
–DevOps:実装~リリース
33
実装
&テスト
CI/CD リリース
企画
立案
詳細
検討
実施
判断
- 36. Copyright© Growth Architectures & Teams, Inc. All rights reserved.
まとめ
• 変えていきましょう!
–ボトムアップでDXをリードすることは可能
» トップダウンはかけ声のみ
–みんな目指すべき所は一緒のはず
» 楽して、良いものを作りたい
–デジタル化
» システム開発を事業活動に織り込むこと
» だから、会社の意思決定とシステム開発を近くする
35