00:07
皆さん、こんにちは。B-Testingのブロッコリー です。このB-Testing.fmは、QAエンジニア
である私、ブロッコリーがテスト や品質に対する私なりの考えを
約10分間で語っていくポッドキャスト 番組です。前回からもう一回顔を
出してやってみてますが、いかが でしょうか。前回の場合は発表資料
のところをちゃんと調整ができて なくて、若干顔が右上に配置する
ようになっちゃってたのかもしれない ですね。ちょっと編集でどうして
たか覚えてないですけど、そうな っちゃってたような気がするんで
今回はそうならないように、ちゃんと スライドのほうも工夫したいな
とは思いつつ、それができきれてない 部分もあるかなと思うんですが、
ちょっと顔が被っちゃったりしている かもしれませんが、そこはご容赦
ください。今回は最近ちょっとSNS 上とかでも話題になっているAIに
任せたりすると必ず出てくるボトル ネックとしてレビューのところ
そこについてちょっと深掘りして 考えていきたいと思います。それでは
今回もbtesting.fmスタートです。ソフトウェア レビューでもプロセスを考えよう
という内容で話していきたいな と思うんですけれども、先ほど言った
ようにレビューについて結構今 特にAIでものを作るっていうふう
になっていったときにボトルネック になったりとか、もしくはAIにレビュー
を任せてもうまくいかないなとか そういうふうに思ったりする人も
いるかもしれないですが、そこの 手助けになればなと思っています。
そもそもまずレビューっていう ものを考えると、レビューってJSTQB
の中ではテストの一つだっていう ふうに考えられていますと。よく
テストって言ったりするときの よくあるイメージはこっちだと思って
いて、コンポーネントとかシステム とかものを実行して確認するみたいな
もの。これをテストと呼ぶことが 多いと思うんですけれども、JSTQB
の中ではそれを区分として動的 テストって呼んだりしています。それ
に対してシステムとかコンポーネント を実行しない場合を静的テスト
と呼びます。これはコードとか 仕様書とか設計書とか、実際に
ものを動かすわけじゃないですよ ね。そこに対してもテストをする
ことができるんじゃないか。これを 静的テストと呼んだりします。この
レビューするっていう活動も 静的テストの一つですよとして考え
03:03
られています。他に静的テスト として有名なものといえば静的
解析とかもあったりするんです けれども、今回はレビューの話
なので、レビューについて詳しく 話していきます。そもそもテスト
の一つですよっていう考え方が あるよというのを知ってもらえれば
と思います。そんな中でJSTQBの中 ではレビューのプロセスって
どういうふうに定義してるかっていう と、そこに書いているとおり、計画
をしてレビューの立ち上げをして 個個人でレビューをして、それを
共有と分析をして、修正と報告を するっていうふうにプロセスとして
書かれているんですね。ただこれ ちょっと実際にレビューをやって
いく流れとしてはいいんです けれども、個人的にはこれはちょっと
不満なところでして、個個人のレビュー っていう一番重要な部分、個個人
でレビューしてくださいっていう ところ、これ具体的にどうやって
やるのっていうのはそんなに書かれて ないんですよね。っていうか言語化
ができてないかなと思っています。 少なくともJSTQBの中では言語化
があまりされてないところだし、 他の文献とかではされているかもしれない
ですが、なかなか言語化、体系化 ができていないところだなと思
っています。ここについて自分も 所属している3というレビューの
体系化を考えて研究をしている コミュニティというかがあるんです
けれども、その中でいろいろと 考えをしています。その中の考え
としてこのテストプロセスがうまく 活用できるんじゃないかっていう
のを考えています。これはもう 数回前のところで話したと思うん
ですけれども、テストにはテスト のプロセスっていうのがあって
ただ単純にテストケースを作成 して実行すればいいっていう話
ではなくて、テストケースを作成 する前段階として何をテストする
のかっていうテスト分析とか、どういう パターンをやればいいのかっていう
のを考えるテスト設計とか。そこから 実際に手順書なんかスクリプト
なんかを書くテスト実装があって テスト実行をするよっていうの
がテストプロセスとしてあるっていう ふうにJSTKBの中では書いているんです
が、これを活用できるんじゃないか というふうに考えています。今回
の場合だと先ほど示したレビュー のプロセスっていうのをうまく
テストプロセスのテストって書 かれている部分をレビューって
書き換えることでレビュープロセス として定義できるんじゃないか
っていうふうに我々研究の中では 考えていて、そうするとレビュー
っていうのもただ単にレビュー を実行するのではなくて、その
前にどういうレビューをやろう かっていう計画から始まって何
をレビューすればいいんだろう っていう観点を考えるレビュー
分析があって、そこからどういう ふうにそれを見ていこうかっていう
06:02
レビュー設計実装とかがあって その結果レビューの実行があるん
じゃないかっていうふうに考えて います。我々レビューの研究をして
いるコミュニティの中ではこういう ふうに考えているよっていうの
を一つ紹介します。これは実際に 研究として考えつつも研究会のメンバー
の一人である足立さんが、これは Just Reviewというレビューのシンポジウム
の2022年のときにこういうふうな 図を紹介しています。これ何か
っていうと実際に先ほどのレビュー のプロセスみたいな形で、まずレビュー
の目的っていうのを考えて、それが 青の部分ですね。一番上の部分
レビューの目的、どういう目的で レビューをするのっていうのを
ちゃんと言語化して、そのためには 例えば一番右側のところとかで
言うと、成果物のリスクとして 作成者の状況による結果の作り込み
っていうのがあるんじゃないか そこを見つけようっていう目的
があって、それを見つけるためには っていうので、スライドの中では
黄色の部分ですね。レビュー観点 動出技法って書いてますけど、これ
がレビュー設計とかレビュー実装 に近いと思うんですけれども、作成者
の状況による結果の作り込みっていう ところを考えると、作成者って
どういうコンテキストを持っている のかっていう話からいろいろアプローチ
ができるかなと思います。例えば 作成者がどういう人かっていうこと
を考えると、それを例えば作った 人がフロントエンドがすごい得意
な人であるとかっていうことを 考えると、じゃあバックエンド
よりのロジックの部分っていう のはちょっと弱いんじゃないか。
じゃあその部分を中心にレビュー として見ていこうみたいな話で
あったりとか、それ以外にも例えば 作成者の状況として、もうすごい
残業続きで結構深夜にやっている みたいな話であると、じゃあそもそも
5時とかっていうのが結構あるん じゃないかっていうところから
じゃあ5時とかに注目してレビュー をしてみようかとか、そういうの
があったりすると思うんですね。 っていうふうにレビューの目的
を考えて、その目的に沿う形で、 じゃあどういうレビューの観点
でやっていこうかっていうのを 見つめて、そこから観点群が出てきて
それをもてにレビューの実施を して結果を出すみたいな、そういう
ふうに考えています。本来はその 後にレビューの振り返りとかを
やって、もっとこうすればよかったん じゃないか、レビューとして出せ
たんじゃないかとかっていう振り返り まであるといいかなと思っています。
これをレビューのアプローチの全体像 として、以前に2022年に足立さんが
発表していますと。そんな中、今の レビューの現状としては、こういう
09:03
ふうに考えるところっていうのは すごい少ないと思っていて、よくある
レビューアプローチとしては、その 中のレビューの目的とかレビュー
分析とかレビュー設計、レビュー 実装みたいなところっていうのは、
わざわざこういうふうに考えて みたいなのを出すことが少ない
と思っていて、結構ここ頭の中で 暗黙的にやっているかなと思っています。
さっき言った、この人はフロントエンド が強いからバックエンドのロジック
周り弱そうだなみたいなのは、頭の 中でそう意識しつつ、そこでその
結果レビューしてこういう結果 が出ましたみたいな、最終的なレビュー
での指摘事項しかちゃんと言語化 というか、ちゃんとリストとして
出せてない状況だと思うんですね。 こうなるとどうなるかっていう
と、今みたいなこの人はフロントエンド のことをすごい強い人だからとか
っていうのが、頭の中で考えて きちんとやれてる人はすごいいっぱい
指摘が出るし、そうじゃない人は あんまり指摘が出ないみたいな
すごい俗人的な部分になっちゃう ことが多いかなと思っています。
なので結果的にレビューの成果 っていうのが有識者の参加運ぶ
とか、有識者だからこのいい成果 が出たみたいな、そういうふうに
俗人的に依存している状態にな っちゃうかなと思っています。
じゃあ先ほど示したように そもそもどういうレビューの目的
が必要あるのか、それに対して どういうところを見ていけばいい
のかっていうのをきちんと示す この状態ですね。示す状態になって
いけば、あんまり俗人化はそこまで なることを防げるんじゃないか
っていうふうに思っています。 かつこれをしっかりと言語化を
することによって AIのレビュー の精度っていうのも飛躍的に良くなる
かなと思っています。先ほど言った 対人間がレビュアーとして参加
するっていうのも俗人的じゃなくなって ベテランとかじゃない人でもある
程度はできるようになると思って いるし、そこをさらに言語化して
いくことでAIのレビュー精度が すごい良くなると思っています。
これ何かっていうと、じゃあこの ドキュメントをレビューしてっていう
ふうに丸投げしてもいい精度にならないんですね。 これは対人間に対してもそうですね。
こういう目的でレビューしてっていう ふうに言ったほうが精度は良くなる
と思います。それがAIに対しても この観点でちょっとレビューをして
欲しいですと。例えば先ほどのやつ だとドキュメントの作成者はフロント
エンドが得意でバックエンドの ロジック周りのところがちゃんと
うまくできているかどうかが不安 なので、そこの部分を中心にレビュー
をしてくださいみたいな指示をする とレビューの精度も良くなると思っていますし
さらに言うと先ほどのレビューの アーキテクチャーの全体像として
12:01
示したようにレビューの観点 こういう目的で見たいですと。それを
実現するためこういうふうな視点 で見ましょうっていうレビューの
技法っていうのを紐付けられると もう少しじゃあこのドキュメント
をレビューしてっていうふうに指示 とした丸投げになっちゃうかもしれない
けれどもその前提となるコンテキスト をきちんとインプットとして事前
に与えてあげるとさらに精度が 良くなるかなと思っています。ということで
ここまででソフトウェアレビュー っていうところに対していろいろ
考えていきました。プロセスがやっぱり 必要なんじゃないかっていう一つの
自分が所属しているレビューの 研究会での考え方を共有してきました。
ここからは質問のコーナーです。 一つ質問をいただいています。レビュー
のやり方はQAや開発者PDMなどの ステークフォルダー化で形式化
できていますかという質問をいただき ました。先ほど言ったようにレビュー
のアークテクチャーとして考えて ちゃんと整理しておくことで形式化
というかちゃんとこういうふう にやればいいんだよっていうのは
言えるかなとは思ってるんです けれども現実として自分の業務
の中でそこまでしっかりと形式化 はできてないっていうのが正直
なところです。ただ先ほど言った ようにこういう見方で見ようか
みたいなそういうことはもう少し ずつ言えているかなと思います
しこれをJSTCubeの以前のシラバス には書いてあるんですけれども
他にもリーディング技法として パースペクティブレビューみたいな
そういう言い方で表現されているん ですね。なのでそういうふうに持って
いくことは可能かなと思っています ではエンディングです。btesting.fm
ではリスナーさんからのお便り を募集しています。エピソード
の感想や私に聞いてみたい質問 やテストのお悩みなどどんなこと
でも構いません。投稿フォームは 番組概要欄にあります。またエピソード
の感想はハッシュタグbtestingで Xのポストをお願いいたします。
今日の話でいうと皆さんなかなか 業務ではやっているけれどもちゃんと
言語化したりとかあんまり勉強会 とかでも話すことが少ないと思う
レビューについて語ってきました。 なのでうちではこういうふうに
やってるよみたいな話が聞ける と個人的には大変嬉しいです。もしも
これからも聞きたいという方は お手持ちのPodcastアプリで番組の
フォローもお願いします。最新回 が上がったときにすぐ気づけます。
今日の話とかもSNSとかでレビュー の話とかが盛り上がっていたから
15:00
じゃあちょっと撮ってみようか っていうことで収録をしてすぐ
公開に持っていってるのでそんな 感じで気ままにエピソードが上
がったりするのでそのときにすぐ 気づけると思うのでフォローも
お願いします。ということで今回は ここまでです。それではまた次回
ばいばい
