天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Qiita Conference2023のセッションまとめ〜エンジニアキャリア、特にChatGPTやLLMによって変わっていく開発とその未来〜

increments.connpass.com

こちらのイベントで、基調講演である松本さんの「エンジニアキャリア、特にChatGPTやLLMによって変わっていく開発とその未来」を聞いてきたので、会の様子と感想を書いていこうと思います。

LLMの紹介

自己紹介や松本さんが携わっている事業に関する紹介があった後、簡単に大規模言語モデルの紹介がありました。

大規模言語モデル(=LLM)を非常におおまかに説明すれば、入力に対してもっとも確からしい返答をするモデルだという説明がありました。

LLMのインパク

LLMのインパクトの一つとして、これまで実現したい機能や人の糸をソフトウェアに変換する際のプロセス変化が挙げられていました。

UX/UIデザイン→エンジニアのコーディングといったステップを踏んでいたものが、意図を伝えるだけでいきなりソフトウェアが出てくる*1ような形になるのではないか?ということでした。

LLMで今できること/研究されていること

LLMでは、指示にしたがってコードスニペットを生み出すことが現在すでにできている*2という話がありました。

また、AutoGPTなどに代表されるように、指示にしたがって探索的に複雑なコードやアプリケーションを生成することや、LLMに合わせたフレームワークやインフラ基盤の構築ができないかの研究が進んでいるということです。

LLMの限界と今後

LLMの限界として、以下の点が挙げられていまいた。

  • ハルシネーション
  • 情報管理
  • 入力文字数が制限されている
  • 処理速度が遅い
  • プロンプトリテラシーがないと適切なアウトプットが得られない
  • モデル開発に相当なお金をかける必要がある

しかし、Transformerの改良やそれ以外の手法発見など、今は急速に研究が進んでいるため、今後どうなるかを見通すことは難しいということです。

在り方の変化

今後を予想することは難しいけれども、オンプレからクラウドへの変化やML時代の到来があったように、今後在り方が変化する可能性は非常に高いだろうという話がありました。

松本さんの身近なところだと、コーディング試験の在り方というのがだいぶ変わってきていると感じられているそうです。

note.com

変化に対応し続けるために

一言で言えば、「本当に自分がやりたいこと」を目指すことが重要だというお話がありました。(例えば、機械がコーディングできたとしても自分が趣味としてコーディングしたいと思うならそれは本当に自分がやりたいこと)

この際には、投資家的なキャリア思考が有効だということで、以降は投資家的なキャリア思考の具体例の説明につながっていきました。

投資家的キャリア思考

先程の話の流れで、投資家的キャリア思考の具体例の説明がありました。

リスクとリターン

人が意思決定をする際は、要素をすべてそろえた上で決定することはできないため、リスク(予測と実際のずれを引き起こす不確実性×影響)とリターン(何を得ようとするか積み上がる指標)を整理しておくことが重要だということです。

探索と学習

リスクを小さくするための活動として、仮説を立てて行動して仮説を検証する(=探索)ことをぐるぐると回していくことが重要になってくるという話がありました。

この戦略は不確実性が高い領域で特に有効だということです。

バランスシートとポートフォリオ

自分自身が持っている資産*3を棚卸しし、それをどのように配分してどのようなパターンを結果として期待するのか?を棚卸しするのが重要だということです。

レバレッジ

資産にはレバレッジをかけてより多くのリターンを得て資産を拡張していくことが重要だということです。
例えば、信用を活用してより難易度の高い挑戦をし、そこから資産をさらに増やしていく(例えばお金を増やして移動にかかる時間を削減し時間の資産をより確保する)のはその好例だということでした。

サイクルとポジション

最後に、短期/中期/長期で目標達成に向けた方向づけをして、決めた目標に対しては逃げ道や言い訳を作らずに取り組むことが重要だという話が出ていました。

全体を通した感想

FinTechを主軸としている松本さんらしい素晴らしい発表でした。

投資やプロダクト開発といった普段取り組まれている仕事を自分の人生やキャリアにも適用されているのが非常に印象的でした。

*1:勿論実装が0になるとは考えていない

*2:指示の仕方次第ではある

*3:お金はもちろん、信用や時間や体力といったものも資産になる

大人のソフトウェアテスト雑談会 #159【もでりんぐ!】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

スクフェス新潟

いよいよ今週末に迫ってきたスクフェス新潟の話をしていきました。

自分は現地で参加するかオンラインで参加するか悩んでいたのですが、今の所現地で参加しようと思っているので、現地に行った後の流れや新幹線のスケジュール、keynoteの話、現地に参加予定の人たちが誰なのか?など、色々な話をしていきました。

また、現地にはテストの街葛飾からまさかのサブライズゲストがいらっしゃるかもしれない??みたいな話も出ており、色々な方とお会いできるのが楽しみです。

えきねっと

現地参加予定の方とたまたま新幹線がまったく同じだったということもあって、えきねっとで座席変更ができないか見ていたのですが、お互いにお互いの号車が満席に見える(ただしそれぞれが自分の号車を見ると空き席がある状態)という現象が起きており、仕様の推測会をしていきました。

その後は、えきねっとを作っているかもしれない会社の事例発表の話を聞いて、学習速度の速さなどをみんなで話したりしました。

カメラ

カメラに詳しい人はこの界隈だと多いものの、人撮りのうまさとカメラに対する知識の詳しさはあまり変わらないという話をしていきました。

Ryoさんは、「写真を撮るのは上手なんだけれど誰に渡す写真なのかを意識して取れ」というアドバイスを受けてから、かなり写真の撮り方が変わったそうです。

自治会談義

葛飾区の自治体話を聞いていきました。

60代でも相当に若いという話や、「若いから飲めるでしょ」と無理にお酒を飲まされることがあるという話や、仁義が何よりも重要だという話、おっさんとかおじさんではなく僕と呼ばれる話、効率的にミーティングしようとかは誰も考えていないのに不思議とMTGが回る話など、色々な濃い話を聞いていきました。(自治会に3人参加しているのがすごいw)

全体を通した感想

前回に引き続きじゅんぺーさんがいらっしゃったこともあり、スクフェス新潟への期待感が刻一刻と高まっていく葛飾でした。

自分もオンライン葛飾区民として、新潟県葛飾区の盛り上げに尽力したいと思います!

「勉強法の勉強会」に参加してきた

yumemi.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

「勉強マニアだらけのLT大会!」

今回のテーマは、エンジニア向け「勉強法の勉強会」! 「勉強法の勉強会」という名前からは、なんだか難しいイメージを持たれるかもしれませんが、そこは、やさしくたのしくでお馴染のYUMEMI.grow、とってもわかりやすくプレゼンしてくれるメンバーが集結!(募集もしてます!!)

もちろん、エンジニアならではのまじめな情報も盛りだくさん! 沢山のプレゼンテーションから、より効率的な勉強法を持って帰ってください。

自分一人で考えてもなかなか解決できなかった勉強法の悩みも、今夜解決しちゃうかも!? YUMEMI.growに参加するだけで、エンジニアとしてのスキルアップ、語学や資格試験の達成につながるかもしれない!

若手からベテランまで、ぜひこの機会をお見逃しなく! 「勉強法の勉強会」で、新しい自分に出会いましょう!

会の様子

ChatGPT時代の勉強

最初にloveeさんから、ChatGPTが登場したことで、勉強法に対して以下の点でパラダイム革命が起きるのではないか?という話がありました。

  • 対話の中で知らない話を丁寧に説明してもらうことができるため、知らないを知らないことまで勉強できるようになる
  • 個々人のペースや理解度に即した内容の勉強をすることができる

その後に、こうしたことを踏まえて

  • 出てきた用語で知らない内容を詳しく更に説明してもらう
  • 自分の理解が合っているか?をChatGPTに聞いてみる
  • 表形式など、特定のフォーマットで回答をしてもらうようにお願いする
  • 勉強した内容に関してクイズやテストを出してもらう

といった勉強法のTipsが紹介されました。

内需ドリブン勉強法

続いて、奥谷さんから発表がありました。

奥谷さんは勉強の動機については外需と内需に分かれると考えられているそうで、この内需にしたがって勉強することが重要なのではないか?というお話がありました。(外発的動機と内発的動機として整理することもできるが、奥谷さんとしては内発的動機によりわがままな意味が加わるのが内需)

例えば「XXでXXしたい」という動機があれば、XXでの部分にこだわることが重要だそうで、脱線を積極的にして力技と非合理を楽しむことが大切だということです。

こうして自身の欲求にしたがった勉強であれば、苦痛ではないし勉強した内容も自然と頭に入ってくるため、非常におすすめということでした。

勉強を続けざるを得ない人生の仕組化

続いて、安達さんから発表がありました。

様々な勉強法はありますが、実践に勝る修業はないだろうと安達さんは考えているそうで、仕事で勉強できることが理想的であるというお話がありました。

ただし、必ずしも仕事で学ぶ機会に恵まれているわけではないため、そういったときにはコミュニティ活動がおすすめだということで、安達さんもマーチャントクラブやアクセプト・インターナショナルや古事記プロジェクトといったコミュニティに入って学習をしているそうです。

なお、活動するコミュニティを選ぶ際には、

  • TakerよりもGiverが多いところ
  • 場数を踏めるところ
  • 代表が情熱的なところ
  • 自分の時間を使っても役に立ちたいと思えるところ
  • だめでもともとな無茶振りがあるところ
  • ベテランエンジニアがいるところ
  • win-winの関係性が結べるところ

といった基準を安達さんは採用しているということでした。(こうした感度を高めるためにも、世の中の問題解決などに対して日頃から興味を持っておくことも重要)

技術書を集中して読むために新たに始めた方法が自分にクリティカルヒットした話

続いて松井さんから発表がありました。

松井さんは40歳を過ぎてから集中力の問題で技術書を一冊通して読むことが難しくなったそうですが、そこでTwitterに感想を投稿しながら本を読むことをおすすめしたいということでした。

この取り組みはTwitterでつながった読書グループがきっかけだそうで、最初は誤字脱字も精度も気にせずに適当に感想をTweetをしていたそうです。
最初はTweetが読書の妨げになるだろうと考えていたそうですが、目で読んで頭で考えてそれを書くというスタイルがこれまで慣れ親しんできた学校教育とも親しいことが原因で、非常に集中できるのでぜひおすすめだということでした。

また、時間設定や読書グループに入ることも重要だということで、松井さんは30分だけ集中するようにしたり、クローズド目な小さな読書グループに所属しながら本を読み続けているということです。

英語学習の取り組み方(例) / Part1

続いて神原さんから発表がありました。

神原さんは様々な英語の勉強方法にチャレンジしてきたものの、勉強方法に魔法はないと考えているそうで、「具体的な目標+達成時期+折れない心」が重要だと考えているそうです。

また、英語学習はWriting/Speaking/Reading/Listeningの要素が語彙/文法/発音という土台の上に備わっているため、最初はどの要素が弱いのか?という弱点や目標とのGap分析をしていくことが重要だということでした。

具体的な勉強法としては、今回は時間の関係でReadingの説明だけあり、以下の内容が挙がっていました。

  • 7-8割程度知っている単語の題材で練習をする(語彙不足対策)
  • 日本語版があっても読みたい!と思えるくらいやる気のある文章を読む(語彙不足対策)
  • 新しい語彙を覚えつつ確実に復習する(語彙不足対策)
  • 英文を和訳すること≠内容を理解すること、だと心得る(Readingの速度が遅い)
  • 語順通り頭で理解する(Readingの速度が遅い)

ノートと一緒に楽しく進めるスタイル

続いてsakaiさんから発表がありました。

sakaiさんは大学時代の体験から、社会人時代になってもノートで話を整理するようにしているそうです。

このようにノートに話をまとめる際には、義務感ではなく楽しく続けることを意識しているそうで、自身のペースでゆっくりと時間をかけて馴染みのある道具でノートを取ることを心がけているということでした。

ノートを用いた学習は自分から能動的に話を聞きに行く必要があるオンライン時代に非常に適していると思っているそうで、実際に技術の勉強やUdemy講座の視聴、勉強会のまとめ、実装前にメモ+図解で整理、登壇資料の下書き...でノートを活用している様子も見せてもらうことができました。

AWSの勉強法、3つの鍵

最後にひろさんから発表がありました。

勉強方法を考える前に、まずなんで勉強するのか?というのを考えることが重要だとひろさんは考えているそうで、その上で情報収集/検証実施/情報交換の3つを組み合わせて勉強していくことが鍵になってくるということです。
以下、それぞれの鍵ごとにポイントを記載していきます。

情報収集...RSSリーダーで公式サイトなど一次情報を確認するようにするのと、市販書籍を利用することが重要だと考えている。(書籍は体系化されており日本語で読める一方で鮮度が落ちるのは注意)

検証実施...環境をささっと用意して実際に動かすようにする。動かし方は公式トレーニングやハンズオンを活用してみる

情報交換...自身が得た知識を発信し、情報交換をする。SNSやブログで発信するハードルが高ければ社内WikiやSlackなどでまず発信してもよい。

会全体を通した感想

勉強対象のドメインに特化した勉強方法の話もあれば、勉強方法で活用するツールに特化した話もあり、LTの旨味が出ている勉強会でした。

参加人数も多く、勉強方法に対してみなさんが創意工夫されていることが知れて、興味深い会でした。

アジャイルカフェ@オンライン 第32回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

天野さん家永さん木下さんお三方が、アジャイル実践者の方から寄せられたお悩みに答えていくイベントです。

今日のテーマは、「メンバーに頼られがちなスクラムマスターの負荷を下げるためには?」でした。

会の様子

今回のテーマは抽象的で、内容としても非常に大きかったので、要素ごとに分解して考えていく形式が取られました。

頼られがちなシチュエーション

最初に、頼られがちなシチュエーションについて話がありました。

頼られがちになって困ることは?

続いて、スクラムマスターが頼られがちになることでどのようなことが困るのか?という話をしていきました。

  • うまくいかない責任転嫁されるような形になる
  • スクラムマスターがいないと何もできないチームになってしまっている
  • スクラムマスターが意思決定をすべてする(プロダクトが失敗したときに、スクラムマスターがいけないんだなーとメンバーが思ってしまうリスクがある)
  • スクラムマスターの能力に依存するプロダクトになる(もっとよりよいプロダクトが作れる余地がある)
  • スクラムマスターがいないと意見が発散して仕事が進まない

頼られがちになる原因は?

なぜ頼られがちになるのか?という理由について、お三方の経験上から話がありました。

  • 単純に知識不足
  • 開発が好きなのでプロセス改善やプロダクトづくりに対して興味がない
  • WF経験が長く、開発者がスクラムマスターに対して部下と上司のような接し方をしてしまう
  • 経験が浅くタスクを遂行することに自身がない
  • 自己効力感が低い
  • スクラムマスターが高圧的に接するような場面がある
  • スケジュールに逼迫感があり、成長の機会を作る余裕がない

負荷を下げるためには?

最後にこれまでの話を踏まえて、どのようにして課題を解決するのか?という話がありました。

  • スクラムマスターがファシリテーションをせずにローテーション制とする
  • スクラムマスターという役割の理解をチーム全員でする。(まずはスクラムマスター)例えば、よくやるようなタスクをどのロールの人が担うのか?をみんなで考えてみる
  • スクラムマスターの日々の作業を可視化する(スクラムマスターがデイリースクラムで昨日やったこと/困ったことを話してみる)
  • スクラムマスターが一週間くらい仕事を休んでみる
  • 一人に頼りすぎて意図的に(?)失敗を演出する
  • WAを改善していく
  • 他のスクラムマスターやマネージャーからフィードバックをするような仕組みを作っていく

会全体を通した感想

回答自体が参考になったのは言わずもがなですが、回答を考えている際に出てくる経験談や回答をどのように考えていくのかのプロセスも含めてセットで学びになるような会でした。

『この一冊で全部わかる ビジネスモデル 基本・成功パターン・作り方が一気に学べる』読書会に参加してきた

yasashii-agile.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

チェックイン

GW一番印象に残っていることと、自己紹介をしていきました。

議論した内容

以下、読書会の中で話した内容を箇条書きかつ常体で記載していきます。

  • OEMは自動車メーカーがよく使っているビジネスモデルなのだが、自動車業界だと違う意味で用いられるので、それが厄介。
  • ボランタリーチェーンは田舎だとよく見られるビジネスモデルだが、都会だと見慣れないかも知れない。都会で身近なところだと、CGCとかはボランタリーチェーンと言っていいのかもしれない。定義自体もあまり明確ではない。
  • PayPalとかはどういうビジネスモデルにあたるのか、本書だと分類がされていない。オペレーションモデルとしてPayPalは例として適切だと思うのだが...
  • データを売るのは幻想だという話を思い出した。
  • データを使ったり分析をしたりすることで儲けることができると思っているのは非常に怪しい。データをこねくり回す必要があるとしたら売上くらい。Consumer marketの情報を活用するというのはB to Bじゃないと難しい印象もある
  • ビジネスモデルってPMFした後にある程度形が見えてくるものなのかな・・?と感じた。勿論、このビジネスモデルはないだろうというあたりはついているものもあるんだろうけれども。大手企業向けのもの、というのを感じた。
  • 3章の戦略モデルと4章のオペレーションモデルの区分けがいまいちしっくりきていない。3章の戦略モデルを実現するという説明になっているが、4章のどれかが紐づくようにはあまり思えない。理屈上はつながっているのだが、実態としては内容的につながっていない。戦略モデルというよりはやることの定義だと理解するとよいかもしれない
  • 顧客ロックインをビジネスモデルとするのは、なんとなくダークなパターンにも思えた。面白いは面白いんだろうけれど。。

全体を通した感想

今日は、実際に使っているビジネスモデルの話をしたり、ethic的な議論を行うことができたりして、面白かったです。

また、参加者の方にデータにまつわるスペシャリストがいらっしゃったこともあり、データ分析に関して突っ込んだ議論ができたのもよかったです。

Tech系Podcastを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

川口 恭伸×樽本 徹也 サービスの全体像を付箋で地図に~企画・デザイナー・開発者がみんなでアジャイルに議論できるストーリーマップの秘訣~を見る

www.youtube.com

こちらの動画を同時視聴していきました。

2015年ということで今とは違う雰囲気も感じながらの同時視聴だったのですが、樽本さんや川口さんが話しているような内容が前回分散アジャイルチームで話していた内容ともつながっていて面白かったです。

また、質疑応答でマーケティング分野の方が質問されていた内容が面白くて、これに対してどう答えるのか気になるなーと思っていたら、きょんさんから「デザインのためのデザイン」を紹介してもらいました。

ピアソン・ショックに巻き込まれていて全然知らない&絶版の本だったので、このタイミングで知れてよかったのと、内容的にめちゃくちゃ自分が興味がありそうな話だったので、届くのが待ち遠しいです。

雑談

動画を見終わった後にきょんさんと参加者で雑談が始まり、あれよあれよと色々な話題が繰り広げられていきました。以下、話の流れを箇条書きかつ常体で書いていきます。

  • フレームワークは凡人のためにあるもので、フレームワークからイノベーションが生まれることはない
  • 凡人は抽象化の方向性がありきたり。天才はスペックや特徴として言い表されていないものを見つけてしまう。構成要素は天才が見つけた時点では整理されていないので、天才が言ったことは少なくともその当時他の人は何を言っているのか分からない
  • ゲーミフィケーションでいうシグナリングコミュニケーションは仕事における手札と似ている
  • 仕事では短い時間でひたすらチャレンジするのが大切だと思っている。もやもやしているときにベストプラクティスをいくつ打てるかが大切。
  • ラクティスをばんばん実践しない人は、自分が体験してきたことや学んできたことを適切なタイミングで実践できると思っている節がある
  • 手札が足りないときはひたすらインプットするのと原理プラクティスに整理するのをやる。書籍 < 20の時はインプットしまくる & 人に聞く位のバランスでやっているが、この20はカード化が下手な人や構造を見出す人が下手な人はもっと少なくないといけない
  • 公正世界仮説に陥ってしまい、プラクティスをうったりするのが遅れる人が多い。自分が手間をかけることに納得するために考える時間がほしいと言ってみたり

太田さん

スクフェス大阪のkeynoteを務められる太田さんについて、自分がどんな方なのか分かっていなかったので、人となりを知っている方々に太田さんがどんな経歴なのかを教えてもらいました。

とにかくぶっ飛んでいて、太田さんと比較をしてしまうときょんさんがめちゃくちゃまともな人だなーと錯覚してしまうような人でしたw

ATN#17 「アジャイルテストの4象限とテストピラミッドを意識して効果的なテストを見つけていく夜」に参加してきた

wingarc1st-spqi.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

アジャイル開発が主流となる中、テスト活動にもアジャイルの波が押し寄せています。 しかし「アジャイルなテスト」とはなんたるかを理解し、それを実践するのは容易ではありません。

今回のAgile Testing Nightは前回大盛況だった「ATN#15 探索的テスト&ペアテストでアジャイルテストを味わってみる夜」を経て、さらに一歩踏み込んだアジャイルテストのプラクティスに迫っていきます。 ゲストは前回からに引き続きグレゴリさんとJBさんが登場! 2人の豊富な経験と実績に裏打ちされたアジャイルテストの世界を案内していただきます。 前回同様ミニマムなワークもご用意いただいていますのでお楽しみに(見学も大歓迎)。

本イベントでの体験は、進化し続ける開発の現場に立ち向かう勇気を私達に与えてくれることでしょう。 今宵、進化の夜が幕を開けます。アジャイルテストの世界へ一緒に飛び込みましょう!

www.yamaneco.co.jp

会の様子

マインドセット

最初にアジャイルテストに取り組むにあたって必要なマインドセットの転換について話がありました。

グレゴリーさんは、QAメンバーにまつわる採用面接をしたそうですが、その際にアジャイルテストに馴染んでいないようなQAは「我慢強さ」「システマティックに考える能力」を挙げたそうです。
しかし、このようなマインドセットは自動化されたテストに取って代わられるリスクもあるため、転換の必要があるんじゃないか?という話をされていました。

転換の具体的な例としては、

  • 考え方(唯一の正解がある→状況に応じて多くの選択肢を持つ)
  • 責任(テスターがバグの発見に関して責任を担う→チーム全体がバグの発見に関して責任を担う)
  • スキル(ミスを許さずシステマティックに細部に拘る→コミュニケーションを取りながらドメイン知識や技術的な理解をスキルとする)

が挙げられていました。

アジャイルテストとは

アジャイルテストとは、一言で言えばアジャイル開発の支援を可能にするテストだ、という話がありました。

その上で、Testing manifestoの説明がありました。

  • 最後にテストするよりもずっとテストし続ける(テストはドキュメント作成などと並行して実施)
  • バグの発見よりもバグの防止(当然だが、バグを発見する前よりもバグが作られるのを防止する。BDDや実例による仕様など、バグ発見に使えるプラクティスもある)
  • 機能性をチェックするよりもチームが理解している価値をテストする(コンピューターは単純なテストに飽きないので、チェックは機械にやらせる)
  • システムを破壊するよりも最高のシステムを構築する(WFで最後にもぐら叩きをやらないようにする)
  • テスターの責任よりも品質に対するチームの責任(QAが品質の全責任を担わない)

テスト自動化

早く高品質なプロダクトを取り組むためには、すべきテストは非常に多いため、アジャイル開発においてテストをすべて手動でやるのは現実的ではないという話がありました。
そこでテスト自動化が必要になってくるわけですが、テスト自動化をする際にはテストの目的をもっと知ることが重要だということで、まずは自分たちのプロダクトに対して興味を持つのが重要だということです。

また、テスト自動化をするためにはインフラ基盤や新しいプロセスに慣れる時間、完成の定義などが必要になってくるため、場合によっては組織全体に変化を起こしていくような必要があるというお話も出ていました。

テストピラミッドのレベルが上下することでテストの特性はどう変わるか?

テストピラミッドの上の部分に行くにつれて、テストの特性はどう変わるのか?という質問があり、じゅんぺーさんや荒川さんや参加者がワークをしてくれました。以下のような意見が出ていました。

  • 「そのシステムを誰が使うか?」みたいなユーザーの解像度が上がっていく
  • バグ検出時の修正コストが上がっていく
  • 実装のしやすさが上がっていく
  • メンテナンスコストが上がっていく
  • フレイキーなテスト数が上がっていく
  • 実行時間が上がっていく
  • 手戻りのコストが上がっていく
  • 実装のしやすさが上がっていく
  • (バグが見つかった時の)プロジェクト担当者の罪悪感

アジャイルテストの4象限

「ビジネス - 技術」と「チームを支援 - プロダクトを批評」の軸(Q1, Q2, Q3, Q4)にしたがって、様々なテストがマッピングされていきました。

Q1(基本的に自動化するもの)...単体テストコンポーネントテスト

Q2(自動化するものも手動で実施するものもある)...実例テスト、シミュレーションテスト、パフォーマンステスト

Q3(手動で実施)...アルファベータテスト、パフォーマンステスト、ストーリーテスト、ユーザビリティテスト、UAT、プロトタイプ、探索的テスト

Q4(ツール)...コンポーネントテスト、負荷テスト、機能テスト、セキュリティテスト

テストプランニング

テストプランニングを架空のシステムで実践してみるワークがありました。Gukki-さんと工藤さんが参加してくれました。

ワークの詳細(どういうワークだったのか?どんな回答が出たのか?)は省略しますが、ワークが終わった後に以下のような話が出ていました。

  • 「〜という意味で良いですか?」「〜という言葉を今後使っていきましょう」といったコミュニケーションが取れていた
  • 会話のキャッチボールが上手にできて認識のすり合わせがうまくいった
  • 受け入れ条件とテストプランニングのシートをいったりきたりしながら会話したので、これを繰り返していければ一定レベルの品質が担保できるようなテストになると思った

告知

www.yamaneco.co.jp

www.scrumfestniigata.org

会全体を通した感想

どのようにアジャイルテストを説明するのか聞けて面白かったですし、他の方のワークショップの様子を見ることができたのも非常によかったです。

特に、QAエンジニアではない工藤さんとGukkiさんがコミュニケーションを有効に取りながらテストプランニングをしている様子が印象的でした。