品質向上・生産性向上のため DevOps の開発プロセス目指して

Scrum Fest 三河 2023

Transcript

1. 品質向上・生産性向上のため DevOps の開発プロセス目指して 2020/09/16 Scrum Fest Mikawa 井関 武史
2. アジェンダ 目次 自己紹介 はじめに めざしたいこと 開発チームでの出来事(やってたこと) 転生 品質管理 (保守) チームでの取り組み (保守改修プロセス設計) DevOps の桃源郷までの長い道のり まとめ
3. 自己紹介 名前： 井関 武史 （いせき たけふみ） 所属： テストの街「葛飾」 職業： 某 ID 管理製品のQA・テストエンジニア 趣味 歴史 チンタラン（マラソン） ゲーム ポケモン（カード・Switch）、Acecombat、その他 Twitter： @katsushika_take 生息地： 葛飾、神田小川町
4. 品質向上・生産性向上のため DevOps の開発プロセス目指して
5. はじめに B２B のパッケージ製品を開発・保守・サポートをしています。 開発・保守は同じ部署ですが、完全にサイロ化しています。 開発は新しいプロダクトを作る部隊 保守は顧客(サポート)から上がってきた質問・課題に対しての調査、既存バグ の修正をする部隊 サポートも異なる部署で、完全にサイロ化しています。 顧客サポート全般ありますが、サポートで対応できない質問や課題は保守の 部隊にエスカレーションします。
6. めざしたいこと バグを修正をしてテストをしてリリースするだけの毎日はゴメンなのです。 顧客から質問に対してソースコード見ないとわからない状況もゴメンなの です。 プロダクト(機能) ができた背景 (Why) がさっぱりわからず、解決したい課 題がぼやけて価値がよくわからなくなるのもゴメンなのです。 ミスを誘発するような (単純で似たような) 手作業が多いのもゴメンなので す。
7. めざしたいこと サイロ化された開発 (Dev) と 運用・保守 (Ops) だけど、相互関係でいい 感じに生産性・品質を向上させた使えるプロダクトを製造して、サポートを やりやすくなる最強のプロダクトをリリースできるプロセス
8. めざしたいこと 価値があるプロダクトを継続的に作りたい (使う人が便利になったり楽になる) 役に立つ製品 (できる限り) 早く価値を提供したい (長期間の) サポート・保守でスムーズな調査とソリューションの提供できう ようにしたい バグ対応・仕様変更は簡単にできるようにしたい
9. 開発チームでやってきたこと 自分たちのプロダクトを価値 (品質) を説明ができるチーム
10. 開発チームでやってきたこと 約３年間をかけて開発チームのプロセスを定義・改善
11. 転生 開発チームでインプロセス QA・テスター としてプロセス定義、プロダクトの テストをやっていました。 理由はよくわかりませんが、あるとき組織変更で転生しました。
12. 転生 気が付いたら運用・保守 (Ops) という世界にいました。 品質管理チームとは言っているようなので、ここからは、この呼び方でいきます。
13. 転生 気が付いたら品質管理チームという世界にいました。
14. 転生 リリースする分の業務プロセス(手順)はある
15. 転生 開発チームの歯車と合わせる (フィードバックする) プロセス・プラクティス がない (現在の) プロダクトの品質を向上させる (リファクタリング) などのプロセス がない バグを修正・テストをして品質を保証するプロセスもない
16. 品質管理チームでの取り組み 品質管理チームのおかれた状況 (主な業務) サポート(顧客) から問い合わせに対しての調査・バグの修正・リリース プロダクトの継続的改善 (リファクタリングなど) 開発チームの生産性・品質向上によい影響・提供していく
17. 品質管理チームでの取り組み 品質管理チームのおかれた状況 (主な業務) サポート(顧客) から問い合わせに対しての調査・バグの修正・リリース プロダクトの継続的改善 (リファクタリングなど) 開発チームの生産性・品質向上によい影響・提供していく
18. 品質管理チームでの取り組み 品質管理チームのおかれた状況 開発 (Dev) 保守 (Ops) サポート・営業
19. 品質管理チームでの取り組み 品質管理チームのおかれた状況 サポート・営業、開発(Dev)、保守(Ops) との縦割り業務(サイロ化) 開発 (Dev) 保守 (Ops) サポート・営業
20. 品質管理チームでの取り組み サイロ化されているメリット 業務が完全に分かれているので担当業務(やること) が明白(はず) 責任範囲が明白である意味、業務内容をこなせば仕事は成り立つ(はず) 保守 開発 営業 サポート
21. 品質管理チームでの取り組み サイロ化されているデメリット (いろいろありますが) 会社としては様々な業務があり100% 各部署の業務(責 任) 範囲が決まっているわけではない 情報伝達のときに暗黒地帯へ吸い込まれて見えなくなる業務 誰がやるんだ戦争、なすりつけあい紛争 保守 開発 営業 サポート 暗黒地帯
22. 品質管理チームでの取り組み とあるサイロ化された組織の毒 開発チームがやり残した(忘れていた) やつでしょ、開発チームでやれよ なんでこんなコード・設計になってんだ、ほんと修正しづらい(よみにくい) 保守チームがリアクティブ (なんもやらん) ドキュメント(設計・仕様・マニュアル) の意味がわからない (わからないのはお前 が悪い) せっかくユニットテスト (テスト環境、データ)など作ってるのに、なんで再利用さ れないのか、作るだけ無駄 この問い合わせ・調査、俺に振られそうだから、だまっとこ サイロ間での避難、侮辱、防御、逃避
23. 品質管理チームでの取り組み この「毒」は放置しているとサイロ内で自分たちをアポトーシスしていく 愚痴に賛同だけして無駄な時間をすごし、サイロ間の溝が大きくするだけ 愚痴に反論してチーム内での不協和音 愚痴を聞く周りへの悪影響 (バカにしている愚痴を聞いて気持ちいいわけない）
24. 品質管理チームでの取り組み 「毒」は適量、処方を考えたら薬になるのも事実 暗黒地帯に吸い込まれたものを明らかにしていき保守業務でプロダクトの 品質保持・維持するプロセスを作っていく 保守 開発 営業 サポート 見えないけど、やら ないと業務
25. 品質管理チームでの取り組み 開発、サポートの両方の歯車に合わせて継続的にプロダクトの保守を行え るようにする必要性があり 各部署が分断されてサイロ化し、それぞれのプロセスに介入するのは困難
26. 品質管理チームでの取り組み 開発、サポートの両方の歯車に合わせて継続的にプロダクトの保守を行え るようにする必要性があり 各部署が分断されてサイロ化し、それぞれのプロセスに介入するのは困難 まずは、品質(価値) を保証する直近の課題を解決
27. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること
28. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること
29. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること (表面上) バグは修正されているように見えるが。。。 設計がつぎはぎ・部分(局所)化 ほかの機能が動作しなくなる (または変な動作をし始める) 業務システムに組み込んだときに期待結果にならない 修正方針・目的の説明ができない (制限事項などを説明できない)
30. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること
31. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること 以前の保守改修では品質を保証するプロセスがない バグ修正のプロセスはあいまい 基本は単純にバグを修正する(だけ) 設計書に修正するコードを張り付けて、その説明をする(背景や理由の記載がない) テストは機能面の見えたところだけ (ＭＥＣＥ 構造になっていない) チェック作業 (ユーザストリー・ユースケースを考えない〇×のテスト)でシステム テストを考慮されていない
32. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること とある問題 修正意図が見えない (説明できない) 関連するバグが修正されない 類似する機能の動作 (仕様) がチグハグになる 前後の処理のデータとあわない (がんばって局所的に修正しても) 顧客の要望に届いていない
33. 品質管理チームでの取り組み バグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質 を保証すること ソースコードを見ないと修正の意図がよくわからない (非開発担当者が読 み解けない) 結局、開発担当者が説明をして担当者が工数を圧迫する 顧客からするとバグが直っていない・要望がかなっていない 修正＆テストしてない・やった戦争という無駄な時間
34. 品質管理チームでの取り組み これでよいなら別にわざわざ品質管理するチームなんて必要ない。 問題があれば開発担当者が修正すればよい 品質保証・管理する必要性がない
35. 品質管理チームでの取り組み なんのために品質管理するチームがあるのか？ せっかく品質管理チームというものがあるので、それを活かせるプロセス・ プラクティスを用意 組織ありきなので、コンウェイの法則的な感じだが。。。
36. 品質管理チームでの取り組み バグの修正は当然だがプロダクトの品質の保証・維持(可能であれば向上) 実運用に困らない機能にすること 機能の意図 (価値)を考慮 周辺機能・ツールなど (への影響、からの影響)を考慮 パッケージ製品としてシステムとして利用できるように 総合的に品質を保証・維持
37. 品質管理チームでの取り組み 保守改修プロセスの構築 品質をある一定状態にしてリリース 修正したプロダクトの仕様をフィードバック 差分の設計書でどこに行ったかわからなくならないようにすること サポートの問い合わせ (顧客対応) で効率よく適応できる情報提供
38. 品質管理チームでの取り組み 保守改修プロセスの構築 まずは保守改修プロセスの骨格を作りました (Scrum Fest 新潟）
39. 品質管理チームでの取り組み 保守改修プロセスの構築 骨格にたいして、少しずつ肉付けをしていく
40. 品質管理チームでの取り組み 保守改修プロセスの構築 見積り、修正・テストにおいてどんぶり勘定、センス (スキル) だけでの対応はや める 機能の修正「だけ」ではなく、どのような品質を保証する(したい) のかというプロ ダクト (システム) 視点で保守改修に臨む リスク軽減・回避するもの (バグ修正)、受容するもの (バグが修正できていない 可能性）、転嫁するもの (制限事項) を可視化 つぎはぎ、部分的な設計書にせず一元管理する設計書の保守
41. 品質管理チームでの取り組み 保守改修プロセスの構築 バグ自体のリスク、そして設計・実装・テストにおいてリスクの可視化
42. 品質管理チームでの取り組み 保守改修プロセスの構築 修正する理由、修正した結果の品質を可視化
43. 品質管理チームでの取り組み もちろん、バグの改修をしてリリースを行うことは重要
44. DevOps の桃源郷までの長い道のり バグの改修をしてリリースを行うことはもちろん重要 それだけでは、バグの修正とリリースだけのプロセスでサポート・営業との 歯車部分で終わる。 (Dev) とのギアの組み合わせを用意して、開発・保守とで新規開発のプロ ダクトの品質・生産性を向上させる
45. DevOps の桃源郷までの長い道のり 開発チームからリリースされるプロダクトは、顕在・潜在バグあり 顕在バグは、修正計画を立てる必要あり 顕在バグは、リスクを把握して周知する必要あり 保守性、移植性などを考慮した内部品質向上のためリファクタリング 派生開発 (機能追加、仕様変更) を行う上での品質維持システム (リグレッ ションテスト)
46. DevOps の桃源郷までの長い道のり 以上、あげたものは開発チームから出力されたものに対してのリアクティブ な活動 電車的にいうと「サ」車両 ※)運転台もモーターも付いておらず、ただ引っ張られるだけの車両 保守 開発
47. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと
48. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと プロダクトの品質を制御 (リスク管理) できるような歯車 電車的にいうと「ク」車両
49. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと プロダクトの品質を組み込んで開発チームにフィードバックする 電車的にいうと「モ」車両
50. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと 以下のようなことをモヤモヤと考えています。
51. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと 以下のようなことをモヤモヤと考えています。 ※) テスト環境構築など既に始めているものもあり
52. DevOps の桃源郷までの長い道のり 目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、 ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと DevOps で役に立つプロダクトを早くリリースできるようにしていきたい
53. まとめ サイロ化された組織でもプロセス・システムを工夫すれば暗黒地帯に吸い 取られた業務をある程度の可視化ができた 品質視点で設計を行うため、サポート(顧客)に説明がしやすく、リスク転嫁 (制限事項) を理由をつけて説明ができるようになった
54. まとめ サイロ化された組織でもプロセス・システムを工夫すれば暗黒地帯に吸い 取られた業務をある程度の可視化ができた 品質視点で設計を行うため、サポート(顧客)に説明がしやすく、リスク転嫁 (制限事項) を理由をつけて説明ができるようになった ただし、開発チームとの歯車は作り始めたところ これからその歯車を開発チームとあわせていく
55. まとめ DevOps 開発やりたいです(なりたいです)、安西先生
56. 詳しくは、テストの街「葛飾」で！
57. テストの街「葛飾」？ グループ：https://ost-zatu.connpass.com/ 通称 ：葛飾テストの会 イベント 毎週火曜日 21:30 ～ 23:00 テスト関係の話を中心に雑談 （なんでもあり） 勉強会やセミナーが渋谷や新宿が多くて東側少ないよね、ないなら自分たちで作っ ちゃえで始まった会 キャベツは「中野甘藍」 （葛飾の野菜生産量 第二位） 第一位は「こまつな」だが、葛飾区の南にある某区によってゆるキャラ出ているから却下 虫はバグ、早急に発見・対処しないと大変なことに。。。
58. おまけ 今日は亀有香取神社例大祭
59. ご清聴ありがとうございました