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

by takefumi

Slide 1

Slide 1 text

品質向上・生産性向上のため DevOps の開発プロセス目指して 2020/09/16 Scrum Fest Mikawa 井関武史

Slide 2

Slide 2 text

アジェンダ目次自己紹介はじめにめざしたいこと開発チームでの出来事(やってたこと) 転生品質管理 (保守) チームでの取り組み (保守改修プロセス設計) DevOps の桃源郷までの長い道のりまとめ

Slide 3

Slide 3 text

自己紹介名前：井関武史（いせきたけふみ）所属：テストの街「葛飾」職業：某 ID 管理製品のQA・テストエンジニア趣味歴史チンタラン（マラソン）ゲームポケモン（カード・Switch）、Acecombat、その他 Twitter： @katsushika_take 生息地：葛飾、神田小川町

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

はじめに B２B のパッケージ製品を開発・保守・サポートをしています。開発・保守は同じ部署ですが、完全にサイロ化しています。開発は新しいプロダクトを作る部隊保守は顧客(サポート)から上がってきた質問・課題に対しての調査、既存バグの修正をする部隊サポートも異なる部署で、完全にサイロ化しています。顧客サポート全般ありますが、サポートで対応できない質問や課題は保守の部隊にエスカレーションします。

Slide 6

Slide 6 text

めざしたいことバグを修正をしてテストをしてリリースするだけの毎日はゴメンなのです。顧客から質問に対してソースコード見ないとわからない状況もゴメンなのです。プロダクト(機能) ができた背景 (Why) がさっぱりわからず、解決したい課題がぼやけて価値がよくわからなくなるのもゴメンなのです。ミスを誘発するような (単純で似たような) 手作業が多いのもゴメンなのです。

Slide 7

Slide 7 text

めざしたいことサイロ化された開発 (Dev) と運用・保守 (Ops) だけど、相互関係でいい感じに生産性・品質を向上させた使えるプロダクトを製造して、サポートをやりやすくなる最強のプロダクトをリリースできるプロセス

Slide 8

Slide 8 text

めざしたいこと価値があるプロダクトを継続的に作りたい (使う人が便利になったり楽になる) 役に立つ製品 (できる限り) 早く価値を提供したい (長期間の) サポート・保守でスムーズな調査とソリューションの提供できうようにしたいバグ対応・仕様変更は簡単にできるようにしたい

Slide 9

Slide 9 text

開発チームでやってきたこと自分たちのプロダクトを価値 (品質) を説明ができるチーム

Slide 10

Slide 10 text

開発チームでやってきたこと約３年間をかけて開発チームのプロセスを定義・改善

Slide 11

Slide 11 text

転生開発チームでインプロセス QA・テスターとしてプロセス定義、プロダクトのテストをやっていました。理由はよくわかりませんが、あるとき組織変更で転生しました。

Slide 12

Slide 12 text

転生気が付いたら運用・保守 (Ops) という世界にいました。品質管理チームとは言っているようなので、ここからは、この呼び方でいきます。

Slide 13

Slide 13 text

転生気が付いたら品質管理チームという世界にいました。

Slide 14

Slide 14 text

転生リリースする分の業務プロセス(手順)はある

Slide 15

Slide 15 text

転生開発チームの歯車と合わせる (フィードバックする) プロセス・プラクティスがない (現在の) プロダクトの品質を向上させる (リファクタリング) などのプロセスがないバグを修正・テストをして品質を保証するプロセスもない

Slide 16

Slide 16 text

品質管理チームでの取り組み品質管理チームのおかれた状況 (主な業務) サポート(顧客) から問い合わせに対しての調査・バグの修正・リリースプロダクトの継続的改善 (リファクタリングなど) 開発チームの生産性・品質向上によい影響・提供していく

Slide 17

Slide 17 text

Slide 18

Slide 18 text

品質管理チームでの取り組み品質管理チームのおかれた状況開発 (Dev) 保守 (Ops) サポート・営業

Slide 19

Slide 19 text

品質管理チームでの取り組み品質管理チームのおかれた状況サポート・営業、開発(Dev)、保守(Ops) との縦割り業務(サイロ化) 開発 (Dev) 保守 (Ops) サポート・営業

Slide 20

Slide 20 text

品質管理チームでの取り組みサイロ化されているメリット業務が完全に分かれているので担当業務(やること) が明白(はず) 責任範囲が明白である意味、業務内容をこなせば仕事は成り立つ(はず) 保守開発営業サポート

Slide 21

Slide 21 text

品質管理チームでの取り組みサイロ化されているデメリット (いろいろありますが) 会社としては様々な業務があり100% 各部署の業務(責任) 範囲が決まっているわけではない情報伝達のときに暗黒地帯へ吸い込まれて見えなくなる業務誰がやるんだ戦争、なすりつけあい紛争保守開発営業サポート暗黒地帯

Slide 22

Slide 22 text

品質管理チームでの取り組みとあるサイロ化された組織の毒開発チームがやり残した(忘れていた) やつでしょ、開発チームでやれよなんでこんなコード・設計になってんだ、ほんと修正しづらい(よみにくい) 保守チームがリアクティブ (なんもやらん) ドキュメント(設計・仕様・マニュアル) の意味がわからない (わからないのはお前が悪い) せっかくユニットテスト (テスト環境、データ)など作ってるのに、なんで再利用されないのか、作るだけ無駄この問い合わせ・調査、俺に振られそうだから、だまっとこサイロ間での避難、侮辱、防御、逃避

Slide 23

Slide 23 text

品質管理チームでの取り組みこの「毒」は放置しているとサイロ内で自分たちをアポトーシスしていく愚痴に賛同だけして無駄な時間をすごし、サイロ間の溝が大きくするだけ愚痴に反論してチーム内での不協和音愚痴を聞く周りへの悪影響 (バカにしている愚痴を聞いて気持ちいいわけない）

Slide 24

Slide 24 text

品質管理チームでの取り組み「毒」は適量、処方を考えたら薬になるのも事実暗黒地帯に吸い込まれたものを明らかにしていき保守業務でプロダクトの品質保持・維持するプロセスを作っていく保守開発営業サポート見えないけど、やらないと業務

Slide 25

Slide 25 text

品質管理チームでの取り組み開発、サポートの両方の歯車に合わせて継続的にプロダクトの保守を行えるようにする必要性があり各部署が分断されてサイロ化し、それぞれのプロセスに介入するのは困難

Slide 26

Slide 26 text

品質管理チームでの取り組み開発、サポートの両方の歯車に合わせて継続的にプロダクトの保守を行えるようにする必要性があり各部署が分断されてサイロ化し、それぞれのプロセスに介入するのは困難まずは、品質(価値) を保証する直近の課題を解決

Slide 27

Slide 27 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証すること

Slide 28

Slide 28 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証すること

Slide 29

Slide 29 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証すること (表面上) バグは修正されているように見えるが。。。設計がつぎはぎ・部分(局所)化ほかの機能が動作しなくなる (または変な動作をし始める) 業務システムに組み込んだときに期待結果にならない修正方針・目的の説明ができない (制限事項などを説明できない)

Slide 30

Slide 30 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証すること

Slide 31

Slide 31 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証すること以前の保守改修では品質を保証するプロセスがないバグ修正のプロセスはあいまい基本は単純にバグを修正する(だけ) 設計書に修正するコードを張り付けて、その説明をする(背景や理由の記載がない) テストは機能面の見えたところだけ (ＭＥＣＥ構造になっていない) チェック作業 (ユーザストリー・ユースケースを考えない〇×のテスト)でシステムテストを考慮されていない

Slide 32

Slide 32 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証することとある問題修正意図が見えない (説明できない) 関連するバグが修正されない類似する機能の動作 (仕様) がチグハグになる前後の処理のデータとあわない (がんばって局所的に修正しても) 顧客の要望に届いていない

Slide 33

Slide 33 text

品質管理チームでの取り組みバグを修正・テストをして、 (プロダクトを組み込まれた)システムとして品質を保証することソースコードを見ないと修正の意図がよくわからない (非開発担当者が読み解けない) 結局、開発担当者が説明をして担当者が工数を圧迫する顧客からするとバグが直っていない・要望がかなっていない修正＆テストしてない・やった戦争という無駄な時間

Slide 34

Slide 34 text

品質管理チームでの取り組みこれでよいなら別にわざわざ品質管理するチームなんて必要ない。問題があれば開発担当者が修正すればよい品質保証・管理する必要性がない

Slide 35

Slide 35 text

品質管理チームでの取り組みなんのために品質管理するチームがあるのか？せっかく品質管理チームというものがあるので、それを活かせるプロセス・プラクティスを用意組織ありきなので、コンウェイの法則的な感じだが。。。

Slide 36

Slide 36 text

品質管理チームでの取り組みバグの修正は当然だがプロダクトの品質の保証・維持(可能であれば向上) 実運用に困らない機能にすること機能の意図 (価値)を考慮周辺機能・ツールなど (への影響、からの影響)を考慮パッケージ製品としてシステムとして利用できるように総合的に品質を保証・維持

Slide 37

Slide 37 text

品質管理チームでの取り組み保守改修プロセスの構築品質をある一定状態にしてリリース修正したプロダクトの仕様をフィードバック差分の設計書でどこに行ったかわからなくならないようにすることサポートの問い合わせ (顧客対応) で効率よく適応できる情報提供

Slide 38

Slide 38 text

品質管理チームでの取り組み保守改修プロセスの構築まずは保守改修プロセスの骨格を作りました (Scrum Fest 新潟）

Slide 39

Slide 39 text

品質管理チームでの取り組み保守改修プロセスの構築骨格にたいして、少しずつ肉付けをしていく

Slide 40

Slide 40 text

品質管理チームでの取り組み保守改修プロセスの構築見積り、修正・テストにおいてどんぶり勘定、センス (スキル) だけでの対応はやめる機能の修正「だけ」ではなく、どのような品質を保証する(したい) のかというプロダクト (システム) 視点で保守改修に臨むリスク軽減・回避するもの (バグ修正)、受容するもの (バグが修正できていない可能性）、転嫁するもの (制限事項) を可視化つぎはぎ、部分的な設計書にせず一元管理する設計書の保守

Slide 41

Slide 41 text

品質管理チームでの取り組み保守改修プロセスの構築バグ自体のリスク、そして設計・実装・テストにおいてリスクの可視化

Slide 42

Slide 42 text

品質管理チームでの取り組み保守改修プロセスの構築修正する理由、修正した結果の品質を可視化

Slide 43

Slide 43 text

品質管理チームでの取り組みもちろん、バグの改修をしてリリースを行うことは重要

Slide 44

Slide 44 text

DevOps の桃源郷までの長い道のりバグの改修をしてリリースを行うことはもちろん重要それだけでは、バグの修正とリリースだけのプロセスでサポート・営業との歯車部分で終わる。 (Dev) とのギアの組み合わせを用意して、開発・保守とで新規開発のプロダクトの品質・生産性を向上させる

Slide 45

Slide 45 text

DevOps の桃源郷までの長い道のり開発チームからリリースされるプロダクトは、顕在・潜在バグあり顕在バグは、修正計画を立てる必要あり顕在バグは、リスクを把握して周知する必要あり保守性、移植性などを考慮した内部品質向上のためリファクタリング派生開発 (機能追加、仕様変更) を行う上での品質維持システム (リグレッションテスト)

Slide 46

Slide 46 text

DevOps の桃源郷までの長い道のり以上、あげたものは開発チームから出力されたものに対してのリアクティブな活動電車的にいうと「サ」車両 ※)運転台もモーターも付いておらず、ただ引っ張られるだけの車両保守開発

Slide 47

Slide 47 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと

Slide 48

Slide 48 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくことプロダクトの品質を制御 (リスク管理) できるような歯車電車的にいうと「ク」車両

Slide 49

Slide 49 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくことプロダクトの品質を組み込んで開発チームにフィードバックする電車的にいうと「モ」車両

Slide 50

Slide 50 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと以下のようなことをモヤモヤと考えています。

Slide 51

Slide 51 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと以下のようなことをモヤモヤと考えています。 ※) テスト環境構築など既に始めているものもあり

Slide 52

Slide 52 text

DevOps の桃源郷までの長い道のり目指すは、プロダクト設計・製造・テストなどに必要になるシステム、ツール、ライブラリ、環境などをつくりプロダクト開発をアクセラレートしていくこと DevOps で役に立つプロダクトを早くリリースできるようにしていきたい

Slide 53

Slide 53 text

まとめサイロ化された組織でもプロセス・システムを工夫すれば暗黒地帯に吸い取られた業務をある程度の可視化ができた品質視点で設計を行うため、サポート(顧客)に説明がしやすく、リスク転嫁 (制限事項) を理由をつけて説明ができるようになった

Slide 54

Slide 54 text

まとめサイロ化された組織でもプロセス・システムを工夫すれば暗黒地帯に吸い取られた業務をある程度の可視化ができた品質視点で設計を行うため、サポート(顧客)に説明がしやすく、リスク転嫁 (制限事項) を理由をつけて説明ができるようになったただし、開発チームとの歯車は作り始めたところこれからその歯車を開発チームとあわせていく

Slide 55

Slide 55 text

まとめ DevOps 開発やりたいです(なりたいです)、安西先生

Slide 56

Slide 56 text

詳しくは、テストの街「葛飾」で！

Slide 57

Slide 57 text

テストの街「葛飾」？グループ：https://ost-zatu.connpass.com/ 通称：葛飾テストの会イベント毎週火曜日 21:30 ～ 23:00 テスト関係の話を中心に雑談（なんでもあり）勉強会やセミナーが渋谷や新宿が多くて東側少ないよね、ないなら自分たちで作っちゃえで始まった会キャベツは「中野甘藍」（葛飾の野菜生産量第二位）第一位は「こまつな」だが、葛飾区の南にある某区によってゆるキャラ出ているから却下虫はバグ、早急に発見・対処しないと大変なことに。。。