未回答質問の回答一覧 / 開発をリードする品質保証 QAエンジニアと開発者の未来を考える-Findy Online Conference -

未回答質問の回答⼀覧

⾼橋さんセッションの未回答質問はこちら▶▶▶

【ご質問】 AIの助⼒により、英語や中国語などの⾔語の壁がなくなった現代では情報量が多い中で、膨⼤な情報量を活かし何を作るかが課題となっていると考えますが、⾼橋さんはいかがでしょうか？【ご回答】英語が世界の共通語として広く機能し、英語圏に多くの⼈⼝と情報が集中していたことは事実であり、それが知識の流通を加速させた側⾯は確かにあったと思います。ただし、ソフトウェア開発におけるアジャイルやDevOpsの発展を説明する主因としては、それだけでは不⼗分です。私が作成した『ソフトウェア開発現
代史』の年表を⾒ても、主要な技術書やプロセス書はほとんど1年以内に⽇本語へ翻訳されており、情報の量や到達の早さに決定的な差はありませんでした。 (次ページへ)

【ご回答】実際、中国のAI産業の急成⻑は、英語話者が少ないにもかかわらず、⾃国語で知を再⽣産し、社会実装まで結びつける構造があったことに起因しています。英語⼒よりも、知識をどう再構成し、⾃分たちの環境に適応させられるかが競争⼒を分けているのです。アメリカでは、ソフトウェアを「製品の中核」として位置づけ、現場で仮説検証を重ねる⽂化の中からアジャイルが⽣まれました。⼀⽅、⽇本ではソフトウェアが「ハードウェアや事業の補助的存在」として⾒られ、前⼯程中⼼の契約構造が制度的に固定化されていきました。つまり、英語圏の情報量よりも、知を実装に変える構造と⽂化の違いこそが
分岐点だったと考えます。

吉澤さんセッションの未回答質問はこちら▶▶▶

【ご質問】今までのご経験から⽋陥混⼊率/検出率‧レビュー密度‧⼿戻り削減を⽤いた技法⽐較（チェックリスト‧PBR‧アドホック）の費⽤対効果をご共有いただきたいです【ご回答】ご質問ありがとうございます。ご質問の意図はチェックリスト、PBR、アドホックの⽐較をする、ということでよいでしょうか？PBRはパースペクティブベースドレビューと、判断して回答します。PBRはいくつか意味がありますので外していたらすみません。
それぞれの技法の⽋陥検出効果と費⽤対効果についてご説明します。（次ページへ）

【ご回答】 ‧チェックリストスキルの低い⼈でもレビューが可能ですので実施コストは低いです。作業⼿順を固定できるのでレビュー密度も安定します。既知の単純な⽋陥検出に向いていますが、新規の⽋陥、複雑な⽋陥は検出が難しいです。また、チェックリストの良さに影響を受けるので、チェックリストの作成には費⽤をかける必要があります。また、チェックリストは経年でどんどん膨らんでいきますので、確実に運⽤するには定期的な⾒直しも必要です。
（次ページへ）

【ご回答】 ‧PBR 各視点のレビューアを⽤意する必要がある(⼀⼈で何度も帽⼦をかぶりなおすことがありますがその場合は時間を要します)ので、費⽤はやや⾼くなります様々な視点で複合的にレビューをするので⽋陥検出率は⾼くなります。異常系にも強いです。レビュー密度も視点が多いので⾼くなります。（次ページへ）

【ご回答】 ‧アドホックレビューかける費⽤により、効果に⼀番差が出るのがこのレビューです。⽋陥の検出はレビューアの経験値と想像⼒に依存します。⾼スキルの⼈が⼀定時間活動できるのであれば、効果的に⽋陥の検出ができ、特に異常検知に効果が出ますが、⼀般的には費⽤が⾼くなります。費⽤‧時間があまりない場合にスポット的に使うことも多い技法です。レビュー密度は局所的に⾼くなったりします。計測できないこともあります。

【ご質問】キャリブレーションセッション‧判定サンプル‧ベースライン⽋陥セットで、レビュア間のばらつきをどう抑えていますか？【ご回答】ご質問ありがとうございます。いずれも、レビューの場⾯において、ばらつきを防ぐための技法です。ベースライン⽋陥セットを使って、レビュアー間で情報共有を図ります。その際、⽋陥の判定基準やレベル、分類⽅法等を協議し、明⽂化します。次にベースライン⽋陥セットも含んだ判定サンプルを⽤意し、レビュアがそれぞれレビューします。
（次のページへ）

【ご回答】キャリブレーションセッションでその結果を持ち寄ってレビュア間の差分を検討し、⽋陥の判定基準などを確認していきます。実際にレビュー結果なども⽤いて定期的にキャリブレーションセッションを⾏うことで、レビュア間のばらつきを防ぎ、さらにレビュアのスキル向上も図ることができます。

【コメント】テストがつまらない、というのは、「想定した1が1であることを確認する作業」のイメージが強いからかなと思っているんですが「想定した1」の部分が⾮常にクリエイティブで奥が深くて⾯⽩部分なんですよね。【コメントへのご回答】ご感想ありがとうございます。「想定した1が1であることを確認する」と、すべて与えられてしまっている状況ではクリエイティブな⾯は発揮しにくいですよね。その中にもどのように確認するか、いかに早く確実に確認するかといったところに⼯夫⾯はいろいろあるのですが。さらに、説明はささっとしてしまいましたが、テストの際にどこまで何を考慮するかとい
う想定すること、それを確認するためにどの技法を⽤いてどのように確認するかを考えること、想定したものをどうやってテスト‧レビューしていくかといった全体を組み⽴てること、など、作業を決める前の部分はクリエイティブな⾯が多いと感じています。

林さんセッションの未回答質問はこちら▶▶▶

【ご質問】 QAEがテストコードを修正‧実装を代⾏するメリットはどんなところにあるでしょうか？【ご回答】 ‧SWEの仕事を部分的に巻き取る、QAEができることが増える、ことで組織全体の⽣産性が向上する ‧QAEのケイパビリティが向上することで気付ける課題も増えて組織成⻑に中⻑期的に寄与できる（かも） ‧ケイパビリティ向上によってQAE個⼈の市場価値が向上するあたりかなと思います！

⼤沼さんセッションの未回答質問はこちら▶▶▶

【ご質問】（⼤沼さんのご登壇内容のニュアンスは）テストすることを前提にしないということでしょうか？【ご回答】ニュアンス的には「あとでテストするから実装のこと考えておけばいいや」ではなく、テストのことを設計段階で考えておくと捗るよねという感覚です！

【ご質問】 QAをチーム内/横断/CoEのどこに置き、DoD/DoRとリリース判定兼をどのように再設計されましたか？最も効果的だった組織トポロジがございましたらご教⽰下さい【ご回答】僕がQAチームを前提としたリリース判定権を再設計したわけではないですが、基本的にストリームアラインドチームに決定権があるのが望ましいと思っており、弊社ではそのようにしています！

【ご質問】レイテンシ/可⽤性/学習継続率などをプロダクトKPIとどう連結し、速度vs安定の意思決定を⽇次/週次で回す運⽤をどのように対応されていますか？【ご回答】精緻に毎回意思決定できているわけではないですが、プロダクト開発チームとは別にDevExチームというのを⽴ち上げており、ﬂaky tests対応やパフォーマンスチューニングを⼀部担っています（もちろんプロダクト開発チームもパフォーマンスチューニングしています）
それとは別にちょっとしたSLOは設定されているので、SLOが毀損された場合はSLOをリカバリーするという意思決定はやっています（まだ発展途上です）

平⽥さんセッションの未回答質問はこちら▶▶▶

【ご質問】継続的リリースにおいて、「品質保証⽔準を⾼くすると、システムのTAT性能が低下する」ようなケースならQAチームとAREチームどちらがオーナーシップを持ち、決定していけばよいのでしょうか？【ご回答】 QAチームもSREチームも会社によって、⽬的とするものが多少なりとも変わってきます。また、組織体制がどうなっているかも会社によって異なっています。したがって、どちらがオーナーシップを持つかは、その組織の作りに依存するかと思います。

【ご質問】影響範囲を確認した上でグループ化した⾃動テストを実⾏するというのは、検討出来ないでしょうか？（機能ごとに単体テスト等をグループ実⾏出来るようにするなど）【ご回答】影響範囲が分かりやすいものであれば、おっしゃるようなこと含め、⾊々なアプローチができます。しかし複数チームが扱うリポジトリのコードというのは、得てして影響範囲がわかりづらくなります。だからこそ、なにかをするのに⼼理的抵抗が出てきやすくなります。
なので、「影響範囲が⾒えるように進める」というのと「影響範囲が関係ないところを進める」という２つのアプローチを進めているということになります。

未回答質問の回答一覧 / 開発をリードする品質保証 QAエンジニアと開発者の未来を考える-Fi...

未回答質問の回答一覧 / 開発をリードする品質保証 QAエンジニアと開発者の未来を考える-Findy Online Conference -

ファインディ株式会社（イベント資料アップ用）

More Decks by ファインディ株式会社（イベント資料アップ用）

Other Decks in Technology

Featured

Transcript