1. B-Testing.fm
  2. #18 思考を「プロセス」で表現..
#18 思考を「プロセス」で表現するメリット:計算問題から学ぶレビューの極意
2026-03-23 12:34

#18 思考を「プロセス」で表現するメリット:計算問題から学ぶレビューの極意

私たちは普段、仕事の成果(結果)にばかり目を向けがちですが、その裏側にある「思考のプロセス」を可視化することには、実は大きなメリットがあります。

今回は、簡単な計算問題を例に、思考をプロセスとして切り出すことの重要性を解説します。なぜプロセスを細かく分けると「レビュー」がしやすくなるのか?そのトレードオフとは?


📌 今回のエピソードのポイント

  • 「プロセス」の定義:手続きに着目し、対象を別のものへ変換する活動
  • プチワーク:8×7-32÷4の解き方から見る、思考の多様性
  • なぜ思考のプロセスを共有すると、ミスやバグの修正が容易になるのか
  • プロセスを細分化することによる「工数」と「品質」のバランス
  • 【質問コーナー】開発側の品質保証知識はどの程度?現場で本当に必要なこと


🕒 チャプター

  • () オープニング
  • () 思考を「プロセス」という形で表現してみよう
  • () プチワーク:計算問題から見る「思考の道筋」
  • () 解答へのアプローチは人によってこれだけ違う
  • () 細かいプロセスを示すとレビューしやすくなる理由
  • () 質問コーナー:開発側の品質保証知識はどれくらい?
  • () エンディング


📢 あなたのご意見をお聞かせください

皆さんは仕事において、結論だけでなく「考えたプロセス」をチームに共有していますか?また、今回の計算問題、あなたならどんなステップで解きましたか?ぜひ感想をお寄せください。

感想

まだ感想はありません。最初の1件を書きましょう!

00:07
皆さん こんにちは。B-Testingのブロッコリー です。このB-Testing.fmは、QA
エンジニアである私 ブロッコリー が、テストや品質に対する私なり
の考えを約10分間で語っていく ポッドキャスト番組です。今回の
エピソードが公開されている頃 は、おそらくJust Tokyoが終了している
はずですね。今回、私も一つ登壇 しまして、若手という団体として
登壇をしていまして、以前のエピソード でも話したとおり、Classification
ツリーのワークショップをやったん ですけれども、そこに参加していただ
いた方、もしいたらありがとうございました。 おそらくこのポッドキャスト
をきっかけに、そこの若手のClassificationツリーのワークショップ
に参加したっていう方、ほぼほぼ いないかなとは思ってるんですけど、
もしも一人でもそういう人がいて くれたら嬉しいですし、Classification
ツリーのワークショップ関係なく Just Tokyoっていうものがあるんだ、
じゃあ行ってみようって、少しでも 思ってもらった方がいたら嬉しい
なと思っています。ということで 今回はまた全然別の話なんですけ
れども、思考をプロセスという形で 表現してみようという話について
話していきたいと思います。ということで 今回もbtesting.fmスタートです。
ということで、この思考をプロセス という形で表現してみようという
話なんですけれども、まずこのプロセス っていうものを何かっていうところ
から考えていきたいなと思います。 プロセスとは何かっていうのは
これはWikipediaから引っ張ってきたん ですけれども、プロセスっていう
のは英語で仮定とか肯定を意味する 外来語で、あとはProcessingっていった
場合には処理を意味しますよと、 手続に着目して対象を所定の手続
によって別のものに変換する活動 を表す場合もあるっていう話があります。
ここでは仮定とか肯定とか処理 みたいな、そういう話、もしくは
変換するみたいな、そういうところ を思っておいてもらえばいいかな
と思います。皆さんの開発の中でも プロセス、こういう開発プロセス
でやってくださいとか、みたいな プロセスっていう話があるとは
思うんですけれども、実際に開発 プロセスとか、明言しているもの
以外の思考に対しても実はプロセス って慣れ立つかなと思っています。
ということで、いきたいんです けれども、少し考えてほしいな
と思っていて、プチワークですね。 この計算問題を解いてくださいと。
8かける7マイナス32割る4っていう のを、これ計算問題解いてください
03:03
と。これいくつになりますかね。 8かける7マイナス32割る4。これ計算
すると答えは48なんですよね。この 答えが48であるっていうことが大事
なんじゃなくて、これをどうやって 計算したかっていうことがすごい
大事だなと思っています。これ どうやって計算したかっていう
と、ある人はこう思うかもしれません。 この8かける7マイナス32割る4。これ
見た瞬間に、これどう見ても48でしょ って答えられた人がいるかもしれません
し、もしくはこういう人もいるん じゃないですかね。まずかけ算
やって8かける7で56で割り算やって 32割る4で8で56-8をやると48だっていう
ふうに考えられた人もいるかもし れません。また別の方考えると、
別の人はこういうふうに思った かもしれません。まず計算問題
っていうのは、試測演算があった ときに、まずはかけ算と割り算を
計算してから引き算すればいいな って考えて、じゃあかけ算8かける7
をやってとか、そういうふうに最初 に考える人もいるかもしれません
し。さらに今回これ引き算っていう ところを見ると56-8、じゃあこれ
繰り下がりの引き算だと懐かしい ですね、繰り下がりの引き算。だから
筆算で書いて56-8って書いて、50の 中から1つ10を持ってきて16-8を
して8で5から1つ引いたので4になって 40で40と8を足して48だ。だから答え
48だって出した人もいると思うん ですね。こういうふうにいきなり
見た瞬間に48って分かる人もいれば、 そういうふうに繰り下がりのとか
考える人もいるかもしれません。 それだけではなくて、例えば今回
の問題でいうと、32割り4っていう のを8かける4割り4って考える
と、これ8でくくることができる わけですよね。そうすると8かける
7で-4割り4で7-1で6だから8かける 6で48だみたいな分配法則の逆を
使って解いた人ももしかしたら いるかもしれません。いろいろ
あると思うんですけど、この回答 を導き出すためまでの過程、これ
がいわゆるプロセスかなと思って います。特に思考プロセスですね。
今回ここから言えることとして、 人によってプロセスが違ったり
します。さっきの分配法則の逆 みたいな、そういう考えも持っている
人がいたりしますし。かつ、プロセス 実は細かく分けることができる
っていうふうに考えています。 じゃあ、どうしてこの細かく分ける
っていうところがあるのか。実は これ細かいプロセスをあえて示す
06:00
とレビューがしやすいっていう メリットがあります。例えば今回の
問題、8かける7マイナス32割り4 がこれがイコール64って書いて
×もらったとして、この64これどこで 間違えたんだろうって分かんない
ですよね。それに対してこの8かける 7マイナス32割り4っていうのは、
これは計算すると8かける7を72で マイナス32割り4で32割り4が8だから
72マイナス8で64だってやってた 人がいたとしたら、これはこの8
かける7を72っていうふうに拡散 の部分で間違えているんですね
みたいに。そういうふうにどこで 間違えたのかっていうのが分かり
やすい、レビューがしやすいっていう 特徴があります。一方でデメリット
としては、じゃあわざわざこれを いちいちすごい細かくこういう
ふうに書くかっていうと、それを わざわざ細かく書くこと自体が
コースになるっていうデメリット もあるかなと思っています。
とはいえ、やっぱりある程度思考を プロセスっていう形で表現できる
っていうのを今回のエピソード の中では知ってもらえたらなと思って
いますし、これは次回のエピソード で話そうと思うんですけれども、
じゃあテストっていうもの、ソフトウエア テストっていうものをちゃんと
プロセスを分けて考えるとどういう ふうなことが見えてくるんだろう
っていうのを次回のエピソードで 話していきたいと思います。
続いてはお便りというか、感想ポスト ではないんですけれども、質問ですね。
この質問は何かっていうと、いずれに 私が登壇したときに、そのときに
質問を聴講者からもらっていて、 せっかくこういう質問をもらった
ので、その場でも答えてたような 気はしますけれども、それだけじゃなくて
今回のこのPodcastでも答える質問 コーナーとして答えようかなと思っています。
これは今後もちょくちょくやって いきたいなと思うんですけれども、
まず今日もらっていた質問は、開発 側の品質保証知識がどれぐらい
知りたい、聞きたいですと。ここで 言う開発側っていうのは、自分の
本業であったりとか、何かしら業務 に携わっている人のQAエンジニア
ではなくて、開発者がどれぐらい 品質保証の知識であったりとか、
テストの知識を持っているのか っていうところが質問したい内容
かなと思うんですけれども、品質保証 知識がっていうのは、正直どれ
ぐらいあるかっていうと、ほぼない というか、あんまり意識していない
方がほとんどかなと思いますし、 実は自分の関わっていたところ
09:01
とかっていうところでも、あんまり テストの知識とかを持っている
前提はそんななくてですね、これは 前までの回で話したと思うんですけ
れども、大学とかでテストとか品質 を学んでいる人、エンジニアっていう
のはほぼいないので、あんまりテスト の知識を持っている前提でっていう
のはそんなないですし、そういう 境遇のあるところはほぼほぼない
かなと思っていますと。ただ一方 で、じゃあその知識がないから
どうこうっていうところではなくて、 それ以前に自分がよく関わって
よかったなって思うのは、テスト のことは全然知らないと、やり方
を知らないと、ただテストをどう に化したいという思いがある、それ
がすごい重要だなと思っていて、 テストをどうに化したいんだけど
もうやり方が分からないから困っている みたいな、だからテストができない
っていう話の開発者とかっていう のが比較的多いかなと思っていて、
そうなってくると、じゃあ自分の 知見とか考え方っていうのをおしげ
もなく伝えることによって開発者 自身ももっとテストができるよう
になっていくとか、品質保証っていう のはこういうふうに考えてっていう
のを共有してどんどんどんどん よくなっていくかなと思っています。
なのでこの質問に答えると、品質 保証知識がどれぐらい開発者が持って
いるかっていうと、ほぼほぼそんな 持っていないというか、多分皆さんの
組織とそんなに変わらないとは 思うんですけれども、そこから
じゃあどうしていきたいかっていう ところに対しては波々なる思い
があるのかなと思っています。ということで 今日の質問はこんな感じにしたい
と思います。質問いただいた方 ありがとうございました。
ではエンディングです。 btesting.fm ではリスナーさんからのお便り
を募集しています。エピソードの 感想や私に聞いてみたい質問や
テストのお悩みなど、どんなこと でも構いません。投稿フォームは
この番組概要欄にあります。また エピソードのお感想はハッシュタグ
btesting banscotestingでXのポストを お願いいたします。今日の話でいう
とプロセスっていうところを話して いきましたけれども、自分はあんま
普段そういう細かく分けるっていう 意識してなかったとか、例えば今日
話した計算問題について、自分だったら こういうふうに解くよみたいな
そういう話でもいいので、ぜひポスト をもらえると嬉しいなと思っています。
今日の質問コーナーの内容みたいに、 質問とかお悩みとかいただいたら
それに対してもお答えできるかな と思うので、ぜひ皆さんからの投稿
をお待ちしております。もしも これからも聞きたいという方は
お手持ちのPodcastアプリで番組の フォローもお願いします。最新回
12:02
が上がったときにすぐに気づくことが できます。今日はプロセスの話を
しましたが、次回以降とかでテスト においてのプロセスの話をして
いきたいなと思うので、その最新回 が上がったときとかもすぐ気づける
と思うので、ぜひフォローをお願いします。 ということで、今回はここまでです。
それではまた次回。バイバイ。
12:34

コメント

スクロール