JaSST'2024 Tokai にオンライン参加しました。
今回、はじめてのJaSST参加となります。
イベントの概要
今回のJaSST Tokaiでは、「テストの今日から明日、そして未来へ、一緒に考え、探っていこう！」というテーマの下、今日のテストにおける課題、明日のテストに向けた挑戦、そして更にその先の未来のテストについてみなさまと議論したいと考えております。
引用：
イベント参加の背景
・QAとしての知見を身に着けたい。
・JaSSTの魅力を少し前に聞いて参加したいと思っていた。
・t_wadaさんもパネルディスカッションの方々も魅力的。
記憶にとどめたいセッションについて
業務を縫っての参加により集中して聞けたのは２件。
- 組織にテストを書く文化を根付かせる戦略
ITは事業のコアになった。どんな業種であれソフトウェアが競争力の源泉。
ゴールポストが動く時代に。PMBOKが予測型から適応型に。
アジャイルソフトウェア開発の要素が多分に含まれた。
リリースした製品は必ず間違っている。リリース後の改善力が重要。
ソフトウェアの開発力と企業の業績には因果関係がある。
ソフトウェアの開発力の主要メトリクスは4Keysで測れる。
リードタイムとデプロイ頻度：思考プロセスと実証プロセスにより、仮説検証プロセスを迅速に回す。
MTTRが大事。MTBFは早くものを作るという考えと合わない。
開発速度と品質はトレードオフの関係ではない。
継続的デリバリやDevOpsによる組織的な投資により実現できる。
システムのタイプとパフォーマンスには相関がない。
テスト容易性とデプロイ容易性が重要。
テストの大半を統合環境を必要とせずに実施できること。
アプリケーションを独立してデプロイまたはリリースできること。
ローパフォーマーは、ソフトウェアを他社が開発している傾向が強い。
戦略上重要なソフトウェアを外部委託はしない方が良い。
業務ロジックが複雑であり、競合他社との差別化につながるものは内製化する。
ソフトウェアを変化についていかせることが重要。デジタル筋力を鍛える。
労力は外注できるが、能力は外注できない。
生成AIは人間の能力を上げないと使いこなせない。
信頼性の高い自動テスト（擬陽性、偽陰性がない）があると、次の行動に移れる。
信頼不能性は1%未満であるべき。
開発者主体で受け売れテストを作成・管理し、手元の開発環境で簡単に再現・修正できることが重要。
買ってきた自動テストは役に立たない。オーナーシップを持ってメンテナンスできるようにする。
アイスクリームコーンはQAチームが分かれている結果。
開発チームがテストすると、コードがテスト可能になり、管理・修正にオーナーシップが持てる状態となる。
SMURFを意識して、ピラミッド型にメンテナンスする。
ソフトウェアのアジリティには信頼性（Reliability）が重要。結果UTで土台をかためる。
自動テストはなぜ必要か。コスト削減を主目的にしない。
ソフトウェアは変わっていくことが前提であり、常に変化を可能にするため自動テストを行う。
アジリティの本質は、変更を容易にする設計。
素早く躊躇なく変化し続ける力を得るため、自動テストを書く。
自動テストが開発チームに根拠のある自信を与える。
教育と人事評価が重要。
評価がないと行動は持続しない。技術者の評価は同僚も行った方が良い。
継続的デリバリを実践すると、組織文化に好影響を与える。
ハイパフォーマンスな組織を実現するために、技術プラクティスから文化を作る。
自動テスト文化は、テストは皆の仕事であるという明確な期待水準にする。
テストのコストを減らすのは、止めることではなく、うまくなること。 - 品質文化を語ろう ～知識と経験のタペストリー～
組織におけるQAの責務と配置の話。
配置は責務を反映する。品質は組織課題。適切に扱われる配置が良い。
経営と現場の目指すものの乖離。
経営は結果ベース。現場は作業ベース。
経営と現場の違いは視点の置き方。
・ログラス
アプリケーションチームに在籍。QAチームはない。
プラットフォームチームにも所属するようにしたい。
QAも含めエンジニアの評価はプロダクトにどう貢献できたか。
・令和トラベル
QAグループがある。QAグループ内に２つのQAチームがある。
職能横断のミッション別チームがあり、各チームにQAエンジニアが配属。
プロダクトのロードマップ作成からQAエンジニアが関わる。
品質保証は開発メンバーもＱＡメンバーも実施する。
分析結果をもとにロードマップをアップデートする。
・グロービズ
マルチプロダクト体制の各開発チームに対して、プロダクトＱＡユニットが柔軟に伴奏。
テスト分析は内製。設計・実施は協力会社に依頼する。
QAが横串で稼働すると評価が難しい。【いてよかった】を評価する。
・sansan
プロダクトごとに事業部がある。それに合わせて技術本部がある。
技術本部内にエンジニアリングユニット、QAグループがある。
プロダクトごとに年数が違うので、別組織が扱っている。
・GO
開発部門とは別にプロダクト部門があり、QAはプロジェクト部門に所属する。
プロダクト部門には、QAとは別にデータ分析、デザイナー、PjM、PdMが所属。
実際の開発に当たっては別な感じはない。開発部門のメンバーとフラット。
【QA】を他社にどう知ってもらうか。
QAが何やるか・何やらないかの定義から始めた。（令和トラベル／品質富士山）
テスト屋さんというイメージの払拭が大変。
QAの役割を明らかにし協業して価値・シナジーを生んでいく。
開発チームとは別で存在することで状況・課題の明瞭化や、仕様を共有知とするための取り組みなどできる。
まずは、軸足となるテスト分析・設計・実行で価値を出し、信頼を獲得し、領域を広げていく。 - つづき
Xの投稿で気づき、こちらにも参加しました。
どうしたらQAが組織課題に関与できるか。
テストでできることは計測。QAの効果をデータとして定量的に示す。
売上には貢献できないが費用を減らすことはできる。PR数だけでなく質も評価する。
どこに投資すれば効果的か、QAで判断できる。
テスト設計はリリース可否を決めるための判断材料。
経営の意思決定に関与している。 企業理念を実現できているかテストすることを考える。
感想とまとめ
t_wadaさん発表がぐさぐさ刺さりまくりました。
直近の失敗をもとにチームトポロジーとQAtoAQの考え方をもとに、
最近どうしたら開発チームにQA文化根付かせられるか、と考えてたのですが、
改めてその志向を太くできた気がします。
それとともに２つ目のセッションからは、
QAというロールの重要性、テスト自体の価値を改めて捉え直すことができました。
まずは求められているところを実現し、そのうえでやるべきことを実現する、的な文脈が好きでした。
アーキテクチャConferenceで増田亨さんが、
今後エンジニアは設計書を実現するのではなく、事業を実現する目線が重要的なことおっしゃっていたけど、
今日の企業理念を実現できているかテストするというお話は、それのQA側からの目線と感じました。
自分の思考の整理と進展に繋がった貴重な１日でした。
