今年もJaSST Reviewを開催します! #jasstreview

一昨年から始まりましたJaSST Reviewを今年も開催します。3回目の開催です!

本記事では今回の発表内容をざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします!

www.jasst.jp

目次

JaSST Reviewとは何か

JaSSTとはソフトウェアテストシンポジウム(JaSST)のことで、2003年から全国各地で開催されているテストのイベントです。全国で年間10回以上開催されています。

そしてJaSST ReviewはJaSSTの一つで、ソフトウェアレビューに特化したイベントです。

詳しくは以前書いた下記記事を参照してください。

nihonbuson.hatenadiary.jp

今回のJaSST Reviewのテーマ

今回のテーマは「レビュー対象へのアプローチ方法」です。

以下、JaSST Review'20のページから抜粋。

   「多くの気になることのうち、なぜその内容を指摘しようと考えたのか?」

   「気になることって、そもそもどのようにして出てくるのか?」

   「レビュー対象の中から、作成者に最初に質問した部分はどのように選択されているのか?」

このような質問をレビュアーにしたとしても、「なんとなく」と答えてしまう方が多いかもしれません。

一方で、明確な言語化はしていないものの、自分自身の頭の中では決まった方針があって、それをもとにレビュー対象にアプローチしているレビュアーもいると考えています。

このような、「レビュー対象へのアプローチ方法」「レビュー対象を探る際の狙い」について、今回は議論したいと思っています。

自分たちがとったレビューでの言動がどんな意図を持っているのか、改めて考えられるようなコンテンツになっていると思います。

以降、どのようなコンテンツがあるのか紹介していきます。(主に予稿集の原稿を読んだ感想)

講演1 : 専門書が出版されるまでの編集者の思考と行動 ~編集者はどのように校正・校閲しているか~

1つ目の講演は日科技連出版社の鈴木兄宏さんによる講演です。

鈴木さんは、JaSST Review実行委員の安達さんが書かれた『ソフトウェアプロセス改善手法SaPID入門』などの書籍の編集を担当した方です。

発表当日は、当時の安達さんとのレビューのやり取りも紹介してくれる予定です。

安達さんによる講演の紹介はこちら。

予稿集では「講演当日までお楽しみ」という内容が多くありますが、そのスライドページのタイトルを見ただけでもワクワクするものがいっぱいあります。

また、鈴木さんは「狩野モデル」で有名な狩野紀昭先生の下で論文を書かれています。その当時の狩野先生の言葉なども発表の中で出てくる予定です。

書籍出版という他業種の内容とはいえ、文章に拘りを持つ分野の具体的な例を持ったレビューのやり取りは、参考になるのではないでしょうか?

講演2 : ソフトウェア設計における意思決定とそのレビューの秘訣

2つ目の講演はウルフチーフの川島義隆さんによる講演です。

川島さんは、現在個人事業主として株式会社ウルフチーフを設立し、ソフトウェアアーキテクチャ設計に関する支援を行なっている方です。

また、JJUG等でも多く登壇されています。

有名なスライドでいうと、リクルートさんで行なっていた新卒研修の資料「現代的システム開発概論」やJJUG CCC 2018 Fallでの発表資料「思考停止しないアーキテクチャ設計」などがあります。

speakerdeck.com

www.slideshare.net

今回の発表では、垂直思考、水平思考といった人間の思考の話や、レビュー時によく出てくる事象とその対策について話していただきます。

川島さん本人からもこんな予告が。

以下のページの内容も事前に読んでおくと、より当日が楽しめるかもしれません。

scrapbox.io

事例紹介1 : 刺激語カードを用いたソフトウェアレビューの実践について ~アイデアを刺激し意識外から観点を得る

今回から新たな取り組みとして事例募集をしました。(本ブログでも、事例募集に関する記事を書きました

結果、多数の応募の中から2名の方に発表していただくことになりました。

1人目の発表は、エムスリーの中塚裕美子さんによる講演です。

今回の発表では「刺激語カード」を用いて、観点を得ていくやり方での事例を紹介していただきます。

刺激語カード自体は、レビューやソフトウェアテスト以外の分野から持ってきたアイデアのようですので、どのようにレビューに応用して使っているのかなども発表されるのかなと期待しています。

また、この発表については既に紹介記事がありますので、そちらも参考にしてください。

www.m3tech.blog

事例紹介2 : レビューイの力を引き出すフィードバックのチューニング~チーム外からの支援で見えてきた、成熟度に応じた「問いかけ」の調整方法と各種レビューへの適用可能性

2人目の発表は、グロース・アーキテクチャ&チームスの常盤香央里さんによる講演です。

今回の発表では、チームの成熟度によって問いかけの方法を変えていくという事例を紹介していただきます。

レビューの時はもちろん、普段のチーム内の会話でも活かすことができる、問いかけ方法の考え方かなと思いました。

常盤さん本人による講演の紹介はこちら。

事例紹介のお二方は事例投稿募集なので、講演内容の依頼まではしていませんでしたが、今回のJaSST Reviewでのテーマである「レビュー対象へのアプローチ方法」に沿った内容になっているようで大変嬉しいです!

おわりに

今回のJaSST Reviewでは以上の4名の方の発表をお届けします。

またイベントの最後では、鈴木さん、川島さん、私の3人がパネリストになってパネルディスカッションをすることで、さらにレビューについて深掘りしていきたいと思います。

まだまだ参加登録募集中です。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

#RSGT2021 では開発にテスト活動を浸透させる話を発表したい!

現在の会社に転職してから、QAと開発の在り方について今まで以上に考えるようになりました。

また、今年に入ってからは、その考えを社外でも発表するようになりました。

2月にあったDevelopers Summit 2020では、「テストコードを書き始める前に考えるべきテストの話」と題して発表しました。この発表では、開発者自身がどのようにテストを考えていくべきかの基礎的な部分をお伝えしました。

結果、たくさんの反響をいただき、また何社の方から講演のお声がけもいただきました。

6月にあったScrum Fest Osaka 2020では「Agile Testingのエッセンス」と題して発表しました。この発表では、開発者とQAがどのようにコラボしていくのか、事例を含めてお伝えしました。

発表後には、複数の現場から「実例マッピングを使ってるよ!」という声をいただくようになりました。

今月あったD3QAでは「テスト活動の納得感を持ってテストケースを激減させた話」と題して発表しました。この発表では、QAがテスト技術を用いつつ、どのようにして開発チームに近づいていったかという話をしました。

結果、配信していたYoutube liveでは数百人の方に視聴していただき、たくさんのポジティブなフィードバックもいただきました。

そして、ここまでの発表を踏まえて、私は来年1月にあるRSGT2021のプロポーザルを提出することにしました。

発表タイトルは「Scrumチームに「テストは活動だ」という意識を浸透させるまでの物語」です。

ここまでの発表では、開発者自身のテストの話、開発者とQAのコラボの話、QAチームの話をしてきましたが、そのどれとも違う視点での話になります。

「テスト=TDD」というような認識を伝えたいのでも、テストを作業としてこなすやり方を伝えたいのでもありません。

創造的な活動としてテストを考えることで、開発実装前から、設計よりも前からテストの活動を行うことができます。それにより、以前よりも品質の良い&コストのかからない製品を作り出すことができます。

今回はそのようなやり方を紹介するだけでなく、どのようにその考え方を開発者に染み込ませていったか話す予定です。(ちなみに、「伝えた」のではなく「染み込ませた」のがポイントです)

この発表が気になる方は、下記プロポーザルのページへ行き、タイトルの下にあるハートボタンを押していただけると嬉しいです!

confengine.com

9月末までの投票となっておりますが、よろしくお願いします!

レビュー時のアプローチを考えてみませんか? #jasstreview

今年もJaSST Reviewを開催します!

jasst.jp

今年のテーマは「レビュー対象へのアプローチ方法」です。

この「アプローチ」についてもう少し考えてみましょう。

アプローチとは何か?

weblio国語辞典には以下のように書かれています。

①ある目的のために人に近づくこと。親しくなろうとすること。

②学問・研究などの、対象に接近すること。また、接近のしかた。研究法。 「歴史的な観点から-する」

レビューについて言えば、「どのように問題点に近づいていくか」を考えることかなと思っています。「問題点に対してすぐに指摘できる」ではありません。

歯医者を例に考える

歯医者さんとのやり取りは、問題へのアプローチそのものだと思っています。

歯が痛くて歯科医院に行った時、歯科医院に着いてすぐに歯を抜くことはありません。

以下のようなプロセスを踏むと思います。

  1. 患者に現在どこが痛むのか聞く
  2. 全体的に歯を見て、どこに虫歯があるのか見つける
  3. 今後の方針を患者と相談して、治療する順番を決める(複数の虫歯があった場合)
  4. 歯のレントゲンを取り、虫歯が神経まで届いているのか確認する
  5. 患者の反応を見ながら虫歯の治療を行う

f:id:nihonbuson:20200722190236p:plain

これにより、32本の歯から徐々に対象の歯を絞っていき、虫歯の状態をだんだん明確にしています。

その際には患者とのコミュニケーションを取ることで、治療の優先順位も決定しています。

これはまさに問題(虫歯)に対して近づいていく(アプローチする)行動そのものです。

このアプローチでは、現在の歯のレントゲンというデータだけでなく、どの部分で患者が痛みを感じているのかなどの反応を見つつ、麻酔が必要かなどを判断していることが分かります。

レビューの場合に当てはめて考える

レビューの場合でも、たくさんのレビュー対象から問題がありそうな部分を絞っていき、問題点をだんだん明確にします。

もちろん、レビュー対象物だけでなく、レビュー対象物の作成者とコミュニケーションを取ることで、解決すべき問題点を見つけたり、優先的に伝えるべき内容を探っていきます。

ただし、歯科医院の場合と違い、どのようなアプローチで問題点を見つけるのか、レビュー対象物の作成者とどのような会話をするのかなどは定かではありません。

このJaSST Reviewというシンポジウムを通じて、レビュー対象へのアプローチ方法について考えていきたいと思っています。

JaSST Reviewでは事例募集をしています!

この「レビュー対象へのアプローチ方法」という話は、まだまだ未開拓の地だと感じています。その一方で、多くの現場ではレビューを行なっていると思います。

そこで、皆さんの現場で行なっている、レビュー対象へのアプローチ方法について事例募集をすることにしました!

締め切りは今月末となります。

参加者の方々と共有して、レビューについて改めて考えてみませんか?

「そんなに新しいことやってないし…」と思っている人へ

大丈夫です。この部分は未開拓の地なので、事例発表をする人なりの言葉で語ってもらえれば、それは他の人にも発見が多いと考えています。

つまり、すでに色々な考え方や技法があるテストや開発の分野に比べて、すぐに新規性のある発表になります!

「事例発表をしたいけど、まだ発表内容が固まってない…」という人へ

まずは「事例発表したいと思っている」と言ってもらえる(ツイート、DM、直接口頭でこっそり教える)と助かります!*1

また、何回も応募して内容をどんどんブラッシュアップして頂いても構いません。

皆様からのご応募をお待ちしております!

*1:運営は「何人応募してくれるのかな…?」と不安でいっぱいです

「テスト駆動開発の『駆動』は誤訳なんじゃないか」と言われて改めて考えた話

先日、社内のSlackでこんなことを言われました。

f:id:nihonbuson:20200628162510p:plain

TDDとかのdrivenを駆動って訳すの誤訳じゃないのかと思うんですけど、どう思いますか?

意味合いは駆動より操縦とか運転なんだと思うんですが

そこで「駆動」の意味を改めて考えてみました。

辞書で調べてみる

goo辞書では以下のように書かれています。

[名](スル)動力を伝えて動かすこと。「四輪駆動」「駆動輪」

書籍から考える

書籍『エクストリームプログラミング』の第2章には以下のように書かれています。

「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」

これがXPのパラダイムだ。注意して、適応して、変更する。

なぜ「駆動」が誤訳だと感じてしまったのか

テスト駆動開発(TDD)は「test-driven development」の略であるように、直訳すると「運転」が当てはまる気がします。

書籍『エクストリームプログラミング』の話にあるように、ここでの「driven」は微調整を繰り返すことこそが重要に感じられます。*1

一方で「駆動」だと、「動かす」というニュアンスが強くなり、「微調整を繰り返す」という意味合いが薄くなっているように思えます。

もしかしてリファクタリングが蔑ろにされる理由の1つ?

さらに最近では「テスト駆動開発=テストをきっかけとして開発を行う」という認識の人も出てきているように感じます。*2

昨年のSelenium Confでのt_wadaさんの講演では、リファクタリングが行われなくなってくる理由について、次のように語っていました。(t-wadaのブログより引用)

黄金の回転を構成するひとつひとつの矢印が、単一の目的を持ち、十分な長さを持ち、 きちんとした軌跡を描いて回転している限りは、テスト駆動開発は大きなパワーを発揮し続けます。

しかしテスト駆動開発の回転がもたらすパワーは、矢印のどれかが傷つき短くなっていくことによって、だんだん減っていきます。

では、3つの矢印のうちで、最も打たれ弱く傷つきやすい矢印はどれでしょうか。みなさんは、どう思いますか?

一番弱く傷つきやすいのは、リファクタリングの矢印です。

(中略)

外発的であれ内発的であれ「きれいにしている時間はない」「リファクタリングしている時間はない」などと焦燥感に駆り立てられると、 リファクタリングの時間が短くなったり、リファクタリングが先送りにされ始めます。 リファクタリングの矢印は弱く、折れたり短くなったりしやすいのです。

f:id:nihonbuson:20200706183413p:plain

もちろん、焦燥感によってリファクタリングが行われなくなることは十分ありえます。

ただそれだけなく、「テスト駆動開発」という言葉自体が、リファクタリングという微調整を繰り返す意味を無くしてしまっていることも原因のように思えます。*3

都合の良いように解釈しているだけ?

いや、ちょっと待ってください。

もしかしたら「微調整を繰り返す」という意味を「駆動」という言葉から無くしているのは、都合の良いように解釈しているからかもしれません。

「駆動」の元々の意味は、最初に書いたように「動力を伝えて動かすこと」です。これは「微調整」や「きっかけ」などの場面に限定した意味ではないはずです。

とするならば、いつからか「テスト駆動開発=テストをきっかけとして開発すること」と認識してしまい、そこから逆算的に「駆動=きっかけ」という本来の意味とは少し異なる考えに至ってしまったのかもしれないです。

改めて「テスト駆動開発」の意味を考えてみよう(+宣伝)

私はこの一件で、改めて「テスト駆動開発」というものを意味から考え直すことができました。

皆さんも「テスト駆動開発」とは何か、改めて考えてみませんか?

そもそも「テスト駆動開発」を知らない、やったことないという人は、8/1にTDD Boot Campが久々に開催されるので、そちらに参加して体験してみてはいかがでしょうか?*4

peatix.com

追記

記事を公開したら早くもフィードバックが!ありがたやー。

確かに「driven」と受動態になっている以上、「テストに駆動される開発」と考えた方が良さそうですね。

ただその解釈であっても、「駆動される」タイミングが新しいテストを書き始めた時だけの認識になり、リファクタリングのような微調整を伴う時の認識が薄れているなーという思いは変わりません。*5

確かにそうですね。「誤認の可能性がある」という方が納得感があります。

ただ、発端となった社内の人の発言は「誤訳」なので、記事のタイトルはこのままでいきます。

*1:書籍の例はXPの話であり、TDDに限定した話を示したわけではないですが、TDDにも通じる話のように思ってます

*2:「テストをきっかけとして開発を行う」はテストファーストな開発ではありますが、テスト駆動開発ではないのでは?というのが私の考えです。

*3:「誤訳」ではないが「誤認をしてしまう恐れがある」といったところでしょうか

*4:自分が参加した時のレポートこちら

nihonbuson.hatenadiary.jp

*5:認識が薄れている理由が「駆動」という単語のチョイスではなく、都合の良いように解釈した結果であることは、元の文章でも書いた通りです。

銀の弾丸には時間軸も存在する

最近、周りで銀の弾丸を提供しようとしている人が散見されたので、思ったことをつらつらと。

銀の弾丸を求めるな」というのは、「どんな場合でも活用できる万能なプラクティスなんて無いんだよ」という話だけではないと思ってます。

普段から同じプラクティスを使っている場合に、「本当にそのプラクティスが適切か常に見つめ直す必要があるんだよ」ということを伝えてるような気もしてます。つまり、「昔も今も未来も同じプラクティスを当てはめている=銀の弾丸」となっていないかと見つめ直すことも大事なのでは?という主張です。

『人月の神話』より

書籍『人月の神話』の第16章「銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項」の一節

現代のソフトウェアシステムでこれ以上還元することができない基本的要素に含まれる固有の性質

の1つとして、可変性が挙げられています。

ソフトウェア実体は、つねに変更という圧力にさらされている。

(中略)

大当たりしたソフトウェアはまずたいてい、すべて変更される。行われる作業は2つの工程である。あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を超えるような新しい使い方を試してみようとする。主として、拡張機能のために変更してほしいという圧力は、基本機能が気に入っていて新しい使い方を考え出す利用者から出される

次に、大当たりしたソフトウェアは最初に書かれた対象である機械機器(媒体)の通常の寿命よりも長く使用され続ける。新しいコンピュータが出てこないとしても、新しいディスクや新しいディスプレイ、新しいプリンタが出てくれば、ソフトウェアは成功する見込みのある新しい機器(媒体)に順応しなければならない。

要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器(媒体)といった文化的マトリックスにすっかりはめ込まれているのだ。そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。

ソフトウェア以外のプラクティスでも同様のことが言える

『人月の神話』ではソフトウェアについて話していますが、それだけでなく常日頃行なっている様々なプラクティスに対しても同様のことが言えると思ってます。

例えば、Daily Scrum。

「前回のデイリースクラムから行ったこと・次回のデイリースクラムまでに行うこと・問題点を15分以内で話し合う」という風に言われてるけど、それって本当に適切なのかな?と疑問を持って良いはずです。*1

例えば、レトロスペクティブ。

「今までKPTでやってました。KPTを導入してみたら我々のチームではうまく行きそうだったのでKPTでやり続けてます。」と言ってたりするけど、それって本当に今でも適切なのかな?と疑問を持って良いはずです。

やっているScrumイベントや、構成しているチームメンバーが変わっていないとしても、適切なラクティスは日々刻々と変わるはずです。

それを無視して「それだったらこのプラクティスを使えば良いよ」と案にプラクティスを薦めるようなAgileコーチがいるとしたら、それはどうなのかなと思ってます。

病院での検診の例

例えば、病院での検診で考えてみましょう。

「どんな人が来ても、腹痛を訴えてきたら痛み止めを処方して終了」という医者は信用できないですよね?

ただそれだけでなく、「Aさんが来たら、腹痛を訴えた時には痛み止めを処方して終了」という医者も信用できないはずです。

同じ人が訴えているいつも通りの腹痛とは思ってたけど、ちゃんと調べたら実はガンだった、かもしれません。

「いつも通り」という思考停止

変化を見極めず、いつも通りというプラクティス*2を提供するような人は、医者でもアドバイザーでも信用できないと思ってます。 ただし、プラクティスではなく本質的な考え方はあまり変化せずに当てはまることが多いので、その部分は引き続き大切に持ち続けたいものです。(自戒を込めて)

*1:現に、2013年度版のスクラムガイドでは質問内容が改められ、2017年版のスクラムガイドではDaily Scrum実施時のオプションであり、別の方法でやっても良いとなっているようです。参考:スクラムで削除された5つのトピック

*2:思考停止の分類の中の「無意識の思考停止」に当てはまるのかも

Scrum Fest Osaka @Online 開催終了?しました #scrumosaka

6/26,27にScrum Fest Osaka@Onlineが開催されました。

www.scrumosaka.org

イベントは本番前から始まっていた…!

本イベントは開催前からdiscordを用いて運営の話し合いをオープンに公開していました。

そんなdiscordの場で私は、実行委員ではないにも関わらず無邪気に色々と絡ませてもらいました。

具体的には、新潟トラックのトラックオーナーとしてコンテンツ作成に携わった他、「フェスフェス」や「仕事してる」といったリアクションの絵文字を作成したりしてました。

f:id:nihonbuson:20200628154631p:plain
フェスフェス誕生の瞬間

少しでもイベントの盛り上がりに貢献できたのならば嬉しいです。

イベント開催、そして発表

イベント当日には、パネルディスカッションの登壇の他、発表も行いました。

発表資料は既にアップロードしてます。

speakerdeck.com

書籍『Agile Testing Condensed』の中で、特に伝えた方が良いなと感じた部分を中心に紹介しました。

また、以前にこのブログでも書いた「実例マッピング*1を実際に使った事例を、当時の会話込みでお伝えしました。

発表の聴講者からは「良かった」という感想を多くいただき嬉しい限りです!

イベントは終了した…のか?

イベント自体は6/26,27で、この記事を書いている時点ではすべての発表が終了しました。ですが、discordはまだ残っており、引き続き会話が行われてます。そして、講演の内容は動画に収められており、参加登録した方々はイベント終了後もその動画を見ることができます。*2

すべての発表が終わったにも関わらず、イベントが終了した感じになっていないのは独特な感じがします。

この余韻も含めて、Scrum Fest Osaka@Onlineはこれからのオンラインイベントの見本になるような気がしました。

とまあ色々と感じたことを書きましたが、このイベントの感想を一言で言うと「いやー、楽しかったーー!!」でした。

*1:実例マッピングの記事はこちらnihonbuson.hatenadiary.jp

*2:もちろん私の講演動画もあります!

Scrum Fest Osaka @Online の盛り上がりがスゴい! #scrumosaka

先日、Scrum Fest Osakaがオンラインで行われることが発表されました。

www.scrumosaka.org

今回のイベントの特徴として約20個のマルチトラックが用意されています!

オンラインイベントで発表場所の制限が無いからこそ実現したのだと思ってます。

各トラックのkeynoteも豪華!まだ公開されてないけど、楽しみで仕方ないです!

さらに今回は各トラックで色々と実験的なことをやると思うので、色々とフェスな感じで盛り上がるのでは?と期待しています。

私も「新潟トラック」で運営と発表をする予定です。*1

新潟トラックのkeynoteは既に川口さんのツイートで公開されているので、ここでも紹介!

keynoteはなんと、書籍『実践アジャイルテスト』『More Agile Testing』そして『Agile Testing Condensed』を書いたJanet&Lisa!

2人がAgileTD2011で発表した内容を放映したいと考えています。*2

その他、新潟トラックでは主にAgile Testingを中心とした構成になっています。

興味がある方は、ぜひScrum Fest Osakaに参加登録して新潟トラックに来てくださいー!参加登録は公式ページからお願いします!

*1:私自身は新潟に行ったこともないけど、縁あって新潟トラックの運営になりました!

*2:もちろん、既に2人には許可を貰ってます