インプロセスQAのための要因から捉えるプロジェクトリスクマネジメントnano #1 開発リソース効率状態への対処 #jasstnano

JaSST nano vol.52 (https://jasst-nano.connpass.com/event/394328/)での登壇資料です。

Transcript

1. インプロセスQAのための プロジェクトリスクマネジメントnano #1 barus ( @barus_qa_dev ) 開発リソース効率状態への対処 要因から 捉える
2. 自己紹介 田邉 澄春 subaru tanabe / barus X: @barus_qa_dev • JaSST Niigata共同実行委員長 • HeySayアジャCity運営(平成生まれアジャイルコミュニティ) • JSTQB ALTA / ALTM、 • 前の現場 ◦ 某金融系ベンチャーf社でスクラムチームにQAを含めたOneTeamでアジャイルQAを実践(業務委託) • 現在 ◦ WingArc1st株式会社のデジタル帳票基盤プロダクトでPBI単位で複数のバックエンド機能に インプロセスQAでテストリード ◦ UI・UX改善チーム、自動化チーム、組織横断のカイゼンチーム、新卒研修など • インプロセスQA 計5年目くらい 最近の悩みは AI駆動テストプロセスの メンテに時間取られて 積み本消化できないこと
3. 「インプロセスQAのためのプロジェクトリスクマネジメント」シリーズについて JSTQBではリスク識別やリスクベースドテストなどの活動で触れられていますが、 インプロセスQAでは開発チームに入り込み、QA活動に影響の与えるような、チーム内外が 抱える問題(プロジェクトリスク)に対して、しばしば改善活動を行うことがあると思います。 ・インプロセスQA…開発の初期段階からQA担当者が開発チームに入り込み、開発とテストを並行して進める品質保証アプローチ。 ・プロジェクトリスク...プロジェクトのマネジメントや統制に関連するもの。成果物の納期遅れ、スキル不足、社外サービス利用時の社外の遅延など barus 「スクラムマスターを兼任 して見えてきた、シフトレフトの ための立ち回りとやってきたQAの 活動」 https://developers.freee.co.jp/ent ry/qa-adventcalendar-2023-07
4. 「インプロセスQAのためのプロジェクトリスクマネジメント」シリーズについて 起きている問題や解決手法からスタートすると、各組織やチームの状況によって 発生要因が異なるので、そのまま自分のチームに適用するのは難しいと思います。 ここでは、問題の「発生要因」から出発して、なぜその体制や状態だと問題が起こるのか という流れで扱っていきます。 • 例/ ◦ QAEの残業が多い...SWEに対してQAEが少ない？1スプリントのタスクが多い？QAがテスト以外の別 の作業を持っている？他のチームと兼任している？etc… ◦ 1スプリントのタスクを減らす...タスクをどれくらい減らせば良い？何人に対してどれくらい？ 自分たちの抱える問題にその手段が効果的/逆効果？etc… ・SWE…Software Engineer : 開発エンジニア ・QAE...Quality Assurance Engineer : QAエンジニア
5. 注意書き なお、その体制や状態になっていること自体が悪いのではありません。 その体制・状態を取ることによって発生する可能性のある問題を認識することで、 • その体制や状態を解消するための予防・改善を行うよう促す • チームで認識した上でトレードオフとしてリスクを受け入れる どちらを取るかを選択できるようになることが大事だと思います。 このスライドでは、読まれた方が問題の「発生要因」となるような体制や状態を 捉えることができるようになる体験を目指していきます。 ※ 問題の原因切り分けは本スライドの対象外 ※ 解決方法はインプロセスQAでなくても適用できる場合があります
6. 目次 02 01 03 リソース効率/フロー効率 について リソース効率による 問題の解消の仕方 開発フェーズが リソース効率状態だと 起きること
7. 01 リソース効率/ フロー効率について
8. 01 リソース効率について リソース効率...「各作業者のリソースに空きがあればタスクを与え、全員が何かしらの 手持ちタスクのある状態を作り、作業者の稼働率を100%にあげていくこと」 黒田 樹「フロー効率性と リソース効率性について XP祭 り2017で発表してきた #xpjug」 https://i2key.hateblo.jp/entry/ 2017/10/02/081429 この例だと、一人1機能 が割り当てられ、3機能 が並行で開発される状態 縦一列を1日とした場 合、全ての機能が等しく 完成に3週間(15営業日) かかる
9. 01 リソース効率/フロー効率について なぜリソース効率にするのか...従業員のスキルや稼働時間を最適に配分し、無駄を省いて 成果を最大化するという考え方(コストカット的側面) • リソース効率という言葉は出てこないが、経営学・経営管理の分野では人間の稼働を 「経営資源」と見なし、効率化の一側面からこの考え方を含むことがある。※ • PjM、場合によっては執行役員・取締役員などの経営層がこの考え方のもと組織体制を作っている ことも。 ※古典的経営管理論だとテイラーの”The Principles of Scientific Management”(科学的管理法)やガントチャートでお馴染みガントの”Work, Wages, and Profits / Organizing for Work”など、個別資源の稼働率最大化を目指す考え方では、標準(作業にかかる時間平均)のもと、厳格に稼働率を重視する側面がある。 後者のガントの考え方はプロジェクト管理知識体系PMBOK(6版以前)など、ソフトウェア開発においても影響を与えていたと思われる。 1990年代のハマー&チャンピーの”Reengineering the Corporation: A Manifesto for Business Revolution”(BPR：ビジネスプロセスリエンジニアリング)でも共通？ 一方、リソース効率を批判する考え方も存在し、デマルコの”Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”やモーディグ・オールストロー ムの”This is Lean: Resolving the Efficiency Paradox”などのAgileやLean分野での書籍で扱われている。(経営学の分野でメジャーかというとそうでもないかも？) 制約理論(組織全体のパフォーマンスを最も制限している要因（制約・ボトルネック）を特定し、その部分を集中的に改善することで、全体最適と生産性の最大化を 目指す考え方)やクリティカルチェーン(作業の順序だけでなく人員や機材などのリソース（資源）の奪い合いの考慮の必要性があるという考え方)も同様の認識。
10. 01 リソース効率/フロー効率について 一方でフロー効率という考え方もある フロー効率...「ひとつのタスクが投入されてからリリースされるまでの間、止まらず流れ続 けている状態を作り、リードタイムを最短化していくこと」 この例だと、全員で1機能 が割り当てられ、機能が作 り終わり次第、次の機能に 進む。 できたものから逐次で リリースすることができ る。 黒田 樹「フロー効率性と リソース効率性について XP祭 り2017で発表してきた #xpjug」 https://i2key.hateblo.jp/entry/ 2017/10/02/081429
11. 01 リソース効率/フロー効率について よく例えられる比喩...トラックとベルトコンベアの関係 価値はまとめて大きな単位で届ける or 単位時間あたりにどれだけ価値を届けるか 広木 大地「「もったいない」 マインドが逆に効率を悪くす る。フロー効率とリソース効 率から考えるチームで仕事を する理由」 https://qiita.com/hirokidaichi/ items/f59e611772c02f2e74ee
12. 02 開発フェーズが リソース効率状態だと 起きること
13. 02 開発フェーズがリソース効率状態だと起きること よくあるリソース効率状態のチーム
14. 02 開発フェーズがリソース効率状態だと起きること SWE的にリソース効率状態だと困ること①...機能単位での属人化 一人一つの機能を開発するため、その人しか詳細仕様を理解していない状態が起こりがち。 さらに、その作業者が休んだりいなくなると、代替者がいないため、他の人がキャッチアップするために時 間を使ったり、復帰するまで待つなど、スケジュールの遅延が生じる。 →後続のテストプロセスに皺寄せが来ることに...
15. 02 開発フェーズがリソース効率状態だと起きること SWE的にリソース効率状態だと困ること②...レビュー差し込みによるコンテキストスイッチ の切り替え タスク進行中に他の人のレビュータイミングが被ったり、キリの良いところまで終わらせてレビューする まで、リードタイムが発生する。 レビューのために他の機能の詳細仕様のキャッチアップも挟むほか、中断した作業を思い出す時間 (コンテキストスイッチの切り替え)も発生するので、続けて作業している状態よりも効率が落ちやすい。 そもそもキャッチアップが大変なので、やらなくなった結果、仕様ではなく実装技術の抜け漏れがないかの レビューにとどまることも... →実装漏れや要件相違のバグがすり抜け、後続のテストプロセスのバグ起票の負担が増える。 この実装の部分の 仕様なんだっけ？ どこまで実装 終わってたっけ？
16. 02 開発フェーズがリソース効率状態だと起きること QAE的にリソース効率状態だと困ること①...テスト分析・設計対象のクライマックス化 ※ クライマックステスト…すべての機能の開発が終わってから一気にテストすること。ビックバンテストだと単体テストが完了した全モジュールを一斉に結合し、一 気に動作検証を行うシステム統合テスト手法という意味を持つため、アンチパターン的意味合いとして表現を差別化。Ubie株式会社の末村さんが命名。 クライマックス化は上記意味合いを元に筆者が命名した独自用語。 複数機能を並行で開発した結果、QAのレビュー・テスト対象となる開発成果物が降ってくるタイミングが 同時期になってしまい、QAEのテスト分析・設計・レビュー可能な人数<<<開発者である場合に、 一気に降ってきて、一斉に着手する、クライマックスレビュー、クライマックスキャッチアップのような 現象が発生する。 →認知負荷が高まってしまい、 バグのすり抜けに気づきづらくなってしまう。
17. 02 開発フェーズがリソース効率状態だと起きること QAE的にリソース効率状態だと困ること②...並行タスク数が増えることによる認知負荷・ ブラックボックス化 一気に機能が降ってきて、QAEのテスト分析・設計・レビュー可能な人に集中するような状況で、 分析・設計・レビュー待ちがリリーススケジュールのボトルネックになるような場合、 実装コードまで確認する余裕がないために、ブラックボックステストでカバーしがちになってしまう。 →必要のないテストが増えてしまい、よりテスト工数が増加してしまう。 さらに、マルチタスク化によってテスト分析・設計工程の難易度が高まり、ハードルが上がる。 後続のQAエンジニアに気軽に経験させることができない、組織のQAエンジニアの成長鈍化に影響すること も...
18. 03 リソース効率による 問題の解消の仕方
19. 03 リソース効率による問題の解消の仕方 リソース効率は、各SWEが「完全に理解している状態」では理想 とはいえ、現実は人の入れ替わりや新しい領域への挑戦など、不確実性が高いのが現実。 →一足飛びをせず、まずはフロー効率に寄せながら、最終的にリソース効率で回る世界を目指すのが良い。 一つの機能を 一人で担当 1並列でモブプロ 2並列でペアプロ 同一機能の1つのSBIを 一人で担当 フロー効率 リソース効率
20. 03 リソース効率による問題の解消の仕方 フロー効率にもグラデーションがある 1. 1つのファイルに対してペアプロやモブプロを行う 2. 1つのフィーチャー(機能)をメインロジックとサブロジックで分担を分け、 同期コミュニケーションで行う(同一ファイルの編集をライブコーディングで行う) 3. 1つのタスクをメインロジックとサブロジックで分担を完全に分け、 非同期コミュニケーションで行う 4. 1つのフィーチャー(エピック/ドメイン)内で分割し、分割した1つのタスク (メインロジック・サブロジックを含む)を一人が担当する 5. 1つのフィーチャー(エピック/ドメイン)を一人が担当する フロー効率 リソース効率 1に近づくほどフィーチャーの並列数は少なくなり、5に近づくほど多くなる 開発機能の並列数を 下げながら、1機能を 複数人で担当するのが ミソ
21. 03 リソース効率による問題の解消の仕方 チームの状況によってフロー効率の進め方は異なる プロジェクトが立 ち上がり始め＆ アジャイル系のプ ラクティスに理解 があるなら、 1~2スタート すでにリソース効率状 態になっているチーム は5からなるべく小さ い数字に進めて、成熟 した時点で元に戻る U字型のアプローチ 完全に一方向に進む必要 はなく、チームの人の入 れ替わりや担当するプロ ダクトの変更、大規模な リファクタリング、バグ が多発したりして気を引 き締め直す必要があるな ど、 状況に応じて行ったり来 たりを繰り返すもの
22. 03 リソース効率による問題の解消の仕方 フロー効率を実現するための手段のステップ (SWEへの提案手法) • VSCodeのLive ShareやIntellj ideaのCode with meなどのライブコーディング(同時編集可能)なツールを 用いる • 分担箇所についての合意形成手段を確立する...仕様に想定するメインロジック/サブロジックおよび 責務範囲を記載する(2.「1つのフィーチャー(機能)をメインロジックとサブロジックで分担を分け、 同期コミュニケーションで行う」で任意、3 .「1つのタスクをメインロジックとサブロジックで分担を完 全に分け、非同期コミュニケーションで行う」でほぼ必須) 〜ここまではすぐに実施しやすい〜 • 分担しやすいように疎結合化・モジュール化するなどリアーキテクティング、リファクタリングする ※ あくまで一例。他にも手段はあると思います。
23. 03 リソース効率による問題の解消の仕方 どのタイミングで推進するか...地道な対話活動しか勝たん！ • 一番の理想はチームメンバーがプラクティスに理解があり、振り返り/スクラムならレトロスペクティブ など、困ったことを打ち明けられるタイミングで言い、すぐに導入されるパターン (それができるチームならすでにフロー効率でやってそう) • 典型的に効果的なのは、QAEではなくSWEが自分ごと(=開発におけるリソース効率の問題点)が発生した タイミングで相乗りすること • それすら気がつけない、問題ないと言い続けられる場合は、バグや障害・プロジェクトの遅延の証拠を 集め、それベースで会話する • それでもピンとこないなら実際の課金をベースに損失額(エクスポージャーコスト)を計算して、相手に提 示したり、マネージャーや役員層に根回しして社内政治するしかない
24. 宣伝
26. ご清聴ありがとうございました