天の月

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

ふりかえりカンファレンスの懇親会ふりかえり

retrospective.connpass.com

記事にするつもりは元々なかったのですが、今回はブログに残ることを希望する方が多かったので笑、ふりかえりカンファレンスの懇親会のふりかえりをしていこうと思います。

コミュニティ初心者

最初はたかたにさんとtrebyさんと席が一緒だったのですが、たかたにさんはコミュニティに参加してまだ間もないという話からスタートしていきました。
チケットが余っていて参加したRSGT2024が初参加だったそうですが、そこでは同僚がKiroさんにお説教を懇親会でうけていた*1印象が鮮烈に残っているということでしたが、コミュニティにいる方は基本的にみなさん優しいし、気軽に相談することができる人たちばかりだよという話がありました。
trebyさんはコミュニティに誰も知り合いがいない中、アジャイルコーチとスクラムマスターの集いに特攻したけれど、コミュニティの皆さんは受け入れてくれたということです。

おすすめのイベントに関しては、やっぱりRSGTなのかなあという話をしましたが、愛知に普段住んでいるということで、スクフェス三河などは良いんじゃないかな?という話や、少しステップアップするならリトリートが体験としては最高だからおすすめだというお話をしていきました。

もっとわいわいしたチームにするために

スクラムマスター視点だともっとわいわいとしたチームになってほしいと思っているんだけれど、チームにいうと誘導みたいになってしまって悩ましいという話が出ていました。

スクラムマスターがチームを誘導するというと聞こえはたしかによくないのですが、同じチームメンバーなのだから、信頼関係ができているのであれば素直にチームメンバーに想いをぶつけてみるのが良いのではないかな?という意見が出ていました。

スクラムマスターは1on1をやる必要があるのか?やるとしたらどうやって始めればいいのか?

スクラムマスターはチームメンバーに1on1をやるとよいう話があり、実際に実践されているスクラムマスターも多い中で今からどう始めればよいのか?という話がありました。

「こういったカンファレンスに参加して1on1がいいと言うのを聞いたのでやってみたい。次回以降やるかはあなたが決めていいから一度だけやらない?」という風に、やり始める理由付けと一度だけでもいいという条件をつけてやるのがよいのではないか?という意見がありました。

また、そもそも1on1って必ずやる必要があるものでもないし、1on1をスクラムマスターがやると起きてしまう副作用*2もあるので、絶対にやったほうがいいと一概に言えるものではないという話もありました。

QAなにもわからん会をnacoさんが一人で立ち上げた理由

最近話題になっている(?)、QAなんもわからん会はnacoさんが一人で立ち上げたものですが、一人で立ち上げする勇気がすごいという話をしていきました。

ただ、nacoさん的には運営が複数人いると、イベントが炎上したりしたときに責任を感じる必要が複数人のときと比べてないし、何かを決めようとなったときに、みんなで話し合いをして決めるみたいな必要もなくなるので、むしろ楽だという話をされていました。

trebyさんは、むしろ一人よりも複数人で立ち上げをしたほうが楽だということで、例えばこないだのイベントにおおひらさんを呼んだように、協力してスポットでイベントするほうがやりやすいという話をしていました。

コミュニティのシンボルであるおおひらさん

コミュニティのシンボルとなっているおおひらさんの話をしていきました。

パネルのみならずアクスタまでデビューしているうえに会社の経費でアクスタを作っているというのも本当にすごいという話が出ていました。

QAは下に見られがち?

ウォーターフォールのようなシーケンシャルな開発をしていると、QAがどうしても下に見られがちだけどそんなことはないか?という話が出ていました。

個々人の経験的な話でしかわからないところはあるという前提で、開発者はQAのスペシャリティに尊敬している人が多い印象だけれど、QAの人が"テスター"のようにQAをラベリングしたり、一風変わった取り組みをするQAを止めたりする場面のほうが多いので、QAは開発者ではなくてQAの人に下に見られがちな印象があるという意見がありました。

オンラインの体験を追求するふりかえりカンファレンス

びばさんから、ふりかえりカンファレンスではオンラインの体験を徹底的に追求していて、オンラインかオフラインか悩むくらいのイベントにしたいという話を聞きました。

具体的には、今回のふりかえりカンファレンスでは、オンラインのほうが体験が良くなりがちだと考えられるセッション聴講はオンラインでしか聞けないようにして、Miroと組み合わせることで更にオンラインの体験をよくしようとしたという話を聴いていきました。一方でオフラインに関しては、OSTのように現地で話すからこそ得られる体験に全振りしたということです。

結果的に、びばさん含めたスタッフメンバーは、オンラインかオフラインどちらに参加するのかを皆悩むようなカンファレンスになって、これはすごくよかったのではないか?という話をしてくれていました。

その場にいる参加者も、オンラインでセッションを聞くかオフラインでOSTをするかは非常に悩ましいという話をしていて、そういう感想が出てくるのも今回のふりかえりカンファレンスが成功しているといえる一つの指標になりそうだということでした。

Piyoさんの今に至るストーリー

Piyoさんはネガティブな一面とポジティブな一面のギャップが非常にあるということですが、このギャップが原因でとある特徴を持つ方に好かれる傾向があったという話を皮切りに、今のPiyoさんができるまでのストーリーを聴いていきました。

とある特徴を持つ方に好かれる傾向がずっとあったPiyoさんですが、あるときその特徴を持つ人からも関係を絶たれるような出来事があったそうで、そのとき仕事も全然うまくいっていなかったPiyoさんは本当に人生のすべてを失ったように感じたということでした。

ただ、その際にSNSで人生に絶望したら音楽をやるといいという話が流れてきて、そこから元々ちょっとした趣味でやっていた音楽を再度やり始めたそうで、それをきっかけにバンドを組み始めるまでに至ったそうです。
ただ、そのバンドに関してもとある出来事がきっかけでうまくいかなくなったそうで、そこで「バンドを辞めたい」とメンバーに言った際、一人だけ「Piyoさんがそう思うならやめたらいいんじゃない?」とPiyoさんの意見を尊重してくれたメンバーがいて、それが今の奥さんだということでした。

その後KAGに入ってからは、これまでやり続けていた音楽のおかげでこうしたコミュニティでの活動ができるようになったり、今ではたかたにさんをはじめとした方々と一緒に社内で部活を立ち上げられるようにまでなって、音楽は本当に人生のすべてを変えてくれたという話を聴いていきました。

オペラを歌いたがる小笠原さん

今回の焼き肉レトロスペクティブの歌では、小笠原さんが登場していますが、これは小笠原さんがめちゃくちゃ乗り気だったことが原因だという話を聴いていきました。

実際に社内のSlackメッセージを見せてもらったのですが、たとえ次の機会になったとしても、オペラを絶対に歌いたいという意気込みがつまったメッセージが書かれていて、笑いました。

大変な翻訳

最近はアジャイル関連の翻訳本が多数出ていますが、翻訳作業は本当に大変だし、たくさんの人達の貢献があって翻訳本が出ているんだという話をしていきました。

具体的には、翻訳の際に出典として書かれている本や記事をすべて読んだり、元々の著者が理解を間違えたりしている部分には注釈を入れたりといった作業が特に大変だという話がありました。

シアターとふりかえりをコネクトしたRyoさん

今回のふりかえりカンファレンスでは、Ryoさんはシアターとふりかえりをつなげたそうですが、当初はとりあえずシアターの話だけしておけば参加者の人が勝手にふりかえりにつなげてくれるんじゃないの?と思っていたという話を聴いていきました。

結果的にはつなげることができたそうで、録画の公開を皆さん楽しみにしていました。

yamanecoのテスト研修

yamanecoさんが昨年実施していたテスト研修が社内で好評だったという話から、今年もやる予定なのか?という質問が出ていました。

昨年の研修はたしかに好評だった一方で、研修内容の間違いが若干あったという話があり、今年はリバイスしたバージョンをその内やる予定だということでした。

また、研修のコンテンツのなかでワークショップのデザインがすごくよくできていたという話が出ていて、これはJBさんとRyoさんがワークショップの研修をうけてきたことが原因だと思うということでした。
小糸さんも、JKさんあたりを誘って二人でこの研修をうけてみようかな?という話をしていました。

全体を通した感想

ふりかえりの話がそこまでトピックとして出ていなかったのは意外なところではありましたが、ここに書けていない話も含めて、懇親会っぽい話がたくさん聞けて非常に楽しかったです。

特にたかたにさんtrebyさんとは長い時間話すことができて、とても楽しかったです!

*1:説教自体はそのとおりだなあという内容だったそうです

*2:チームメンバーがスクラムマスターに対して不満をぶつけ、スクラムマスターがそれをいい感じにチームに伝えることになるといった具合に伝書鳩的な立ち位置になってしまうことなど

DevOpsDays Tokyo2024で登壇してきた

少しバタバタしていて資料はまだupできていないのですが、DevOpsDays Tokyo2024で登壇してきたので、ふりかえりをしていこうと思います。

プロポーザル提出〜採択まで

プロポーザル提出がぎりぎりになってしまい(1次締め切りに間に合っていなかった)、第一陣のAcceptタイミングでAcceptもされておらず、倍率も非常に高めだったので、採択されることを完全に諦めていました。

ですが、第二陣でAcceptされて、通知をみたときは非常に嬉しかったです。

セッション準備

DevOpsDays Tokyoは他のカンファレンスよりも更に実践知の話が好まれる印象があったので、まずは自分が言語化できる限りの実践知を書き出すことにしました。
この際は一切本を見たりせず、自分の言葉と経験だけでなるべく書き出すようにしました。
ここ最近のプレゼンテーションでは、色々と本や論文を読み直したりして頭の中に散在している知識を繋げて全体感を掴むことをまずやっていたので、今回初めてこのような作り方ができたのはよかったです。
ただ、自分から出てくる言葉で語るというより本の言葉や資料の言葉や流れで話を構成する癖がついてしまっていたのか、自分の経験がうまく自分の言葉で表現できずかなり苦労しました。

次に、自分が言葉にしたセンテンスを見ながら、他の書籍ではどのような表現がされているのか?というのを考えていきました。
RSGTのタイミングでかなり論文や本は読み込んでいて、使えそうなものは多くインデックス化されていたのですが、見てみると想像以上に自分の言葉だと思っていた表現が本のままだったりすることが多く、もう一度自分の経験からどういう言語化をするか?というのを考えていきました。
このあたりでは、ふりかえりカンファレンスの発表準備も雲行きがやや怪しくなっていた上に色々と予定が重なってバタバタしていたため、どっちの発表もうまくいかないのではないか...?という不安が襲ってきて、プライベートの時間を削りながら発表準備を進めていました。そのため、精神衛生上あまりよろしくない時間になってしまっていたのは反省です。

その後、発表1週間半前位になったタイミングでふりかえりカンファレンスの目処がつき出したと同時に、ようやく自分の言葉で話が作り出せ、発表準備が進んでいる実感を持てるようになりました。
自分の言葉を中心に構成して完成したプレゼンテーションを見ると本や論文の表現よりも解像度が低く感じたのですが、あまりにも一般的な話になってしまっている部分以外はそのままにして、自分が考えていたことをできる限り加工せずに喋ることを心がけました。どうしても自分の言葉で話せない部分や一般的な話になる部分に関しては説明をカットして話すように作り変えていきました。

発表当日

前日に急遽現地参加が難しい事情ができてしまい、オンラインから登壇することになりました。
こういうときにオンラインの導線があるのはめちゃくちゃ助かるなあというのを改めて実感しました。

発表自体は特に予想外のこともなく終えることができました。自分の言葉でなるべく構成するようにしていたからか、普段と比べるとそんなに緊張はしませんでした。

全体を通した感想

発表準備のところで書いたように、一時期は無事に登壇を終えることができるのかめちゃくちゃ不安に駆られていたので、まずは一安心しました。

DevOpsはアジャイルスクラムよりも親しんできた期間が実は長いので思い入れもありますし、技術的な話に文化やソフトスキルの話が接合している感覚が本当に好きなので、今後もなにかしらの形で貢献していきたいと思いました。

オンライン登壇のありがたみを実感したことや発表準備のプロセスで色々気がつくこともあり、個人的な学びが多数得られた発表になってよかったです。

大人のソフトウェアテスト雑談会 #207【しびれ】に参加してきた

ost-zatu.connpass.com

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

アレルギー

子供がアレルギーになってしまったこともあり、皆さんのアレルギー談義を聴いていきました。
ものを食べ過ぎて後天的にアレルギーになってしまうパターンの話や、子供が小さいうちはアレルギーにかかわらず何かしら命に関わるような事態を経験することになるという話を聞いたりしていました。

PCマウント

PCの値段に関するマウントが始まりました。
20万円くらいという話から戦いは始まり、最低でも30万はするという話や、グラボだけで30万という話が横行していました。

炭水化物ダイエット

炭水化物のみ食べるという画期的?なダイエット方法を聴いていきました。野菜の好き嫌いを避けることができたりと便利だそうです笑

nacoさんのイベント

nacoさんのQAなんもわからない会に人が集まりまくっているのですが、なんもわからん枠に分かる人がいるなあという話が出ていました。

これだけわかる人たちがいるならnacoさんが適当に移動させればいいのではないかという話や、QAとして給料をもらっている人はわかる人として登録した方がよいのではないか?という話が出ていました。

科学とエンジニアリングの違い

すごい雑な括りで話をすると、メカニズムが分かり再現性が担保されているのが科学であり、なんかよくわからないけれどこれやると上手くいっているというのがエンジニアリングだという話を聴いていきました。

Shippable

Shippableとはなにか?という話をしていきました。
まず区長から、「バグを発見できるテストをすること」「リスクを予見予知」「十分な品質を確証できること」のテストの三大理念*1に沿って考えれば、十分な品質だと確証できればShippableなのではないか?という話がありました。

ただ、これだと次に「十分な品質とは?」となってしまうという話になり、結局は通らばリーチでのリリースや開発者または経営者が賭けに出ているという状態になるのではないか?という話になりました。

また、品質が高ければ商品は売れる、変数をすべて読みきれば売れるかどうか分かるという話を考えている人がいるよねという文脈から、いくら高性能でも顧客が使ったらのめりこむとしても、倉庫に眠っているだけでは顧客は気付くことができないよね、という話が出ていました。

Testing3.0

バグが出たときに、顧客にそれをバグと呼ばせないようにすればそれはバグではなくなるのではないか?というTesting3.0の話がありました。

QAの倫理性

QAという立場上、「これで本当にいいんですか?」というように感情に訴えるのは倫理性に問題があると考えているという話がありました。

倫理性という意味ではG.O.O.Dテストとも絡むのではないかという話がありましたが、QA自身の倫理性という意味ではめちゃくちゃ興味深いテーマだなあという話をしていました。

全体を通した感想

今日はテストにまつわる話が多く、「テストの街」葛飾感がとてもありました。
残念ながらGWの特別イベントには行けないのですが、葛飾が今後がんがんと発展していく予感がある会でした。

*1:区長の造語??

ふりかえりカンファレンス2024の登壇ふりかえり

ふりかえりカンファレンス2024で登壇してきたので、今日はそのふりかえりをしていこうと思います。

スライド

www.docswell.com

プロポーザル提出〜プロポーザル採択

昨年3人で発表をした際に色々と学ぶことが多かったりしたこともあり、また3人で登壇したいなーという想いからプロポーザルを提出しようという話になりました。

ただ、なかなか3人だからこそ話せるようなテーマが少ないうえに、3人の共通点(?)であるProject Retrospectiveを3年連続で話すのもちょっとなあ...という気持ちがあり、テーマ選びに苦戦しました。

そんな中、翻訳会後に過去3人でしていた感想戦をもとに色々考えられないかなあという話になり、Satirの話は自分たち自身もより深く学びたい気持ちがあるのでよさそうだということで、プロポーザル提出することができました。

プロポーザル採択後〜発表当日

大激戦なのでどうなることかと思いましたが、めでたくプロポーザルが採択されました。

採択後はすぐに発表準備に移りました。まずはSatirの文献を3人で手分けして読み漁るところから始め、その後に文献の中から面白そうな話を選んでいきました。(プロポーザル時点で既に面白い話はあったのですが、それよりも面白い話がないかを探していました)
選んでいった結果、サイコセラピーならではのエピソードや面白そうな話が幾つも出てきたのですが、ここで最初の壁にぶつかりました。
サイコセラピーのエピソードとしては面白いですし、個人の行動変容という観点で非常に有用な話なのですが、チームのふりかえりの文脈だと話として重すぎる(内容が重たいというのもありますし、プロセスが重たいというのもあります)問題が出てきてしまい、これをどうにかしてふりかえりにコネクトするのに非常に苦労しました。

また、発表準備のプロセスが微妙で、個々人の頭の中にある話の中から面白い話を作り込んでいったため、完成したスライドを改めて全体を通して見直しすると、今ひとつ話につながりが感じられず、結果的に大部分のスライドを作り直しすることになりました。

発表1週間前あたりになっても大分バタバタしていましたが、土日返上で追い込んだこともあって笑、3日前になんとか発表が完成しました。

発表当日

Next Actionがうまくいかないときに皆が考える対処法がActionを決めた後の行動に寄っていたり、Norm Kerthとのコネクトを参加者自身が感じてくれたりと、当初良い意味で想定していた通りに発表が進みました。

なお、発表に関しては98lerrさんがメインで話をしてくれたため、自分はDiscordのコメントやMiroに付箋が貼られている様子を見るだけでよく、過去でもっともリラックスして発表に臨むことができました。

全体を通した感想

今回も、3人で準備をしたからこそ学びがある部分も多かったですし、発表準備を通してサイコセラピーの分野に関して多くの知見を手に入れることができたので、発表をしたことによる学習効果という観点では個人的には満足度が非常に高い発表でした。

ただし、発表内容に関しては、やはりプロポーザル提出時に8割がたは決まっているような状態でないと、プロポーザルを見た方が聞きたいと思った内容からは逸れてしまうんだなあというのは実感したので、その点は次回以降改善したいなあと思いました。

スクラムフェス金沢の打ち合わせ第11回目をしてきた

今日もスクフェス金沢の打ち合わせをしていったので、話した内容を書いていきます。

プロポーザルを引き続き募集しているので、ブログをみてくれている皆さんはぜひ投稿してください!

www.scrumfestkanazawa.org

TODO整理

直近はHPの公開やスポンサー募集、プロポーザル募集の開始...優先度高くなる早でやらないといけない作業をひたすらしていてカンバンの状態が正しくなかったので、スクフェス福岡のカンバンを参考にしながらカンバンを直していきました。(今日は優先度の見直しは重要度の高いものしかできなかったので、残りは次回以降やろうという話になりました)

直近必要なものとして追加したのは以下の作業です。

Must

  • チケット販売、Eventbrite準備
  • 会場バナー発注 ・Xバナー ・小さめバナー
  • 現地からオンラインへの切り替え、キャンセルのルールをチケット販売開始前に決める
  • 必要な備品があるか考える
  • 食事スケジュールを決める(Day1夜、Day2昼、軽食)
  • トランシーバーが必要かを考える
  • Miroを使うか決める
  • 現地スタッフの宿泊・交通費の申請
  • Discordのスペース作成
  • スポンサーチケットの払い出し
  • 採択メールの作成
  • rejectメールの作成
  • スケジュールの大枠を仮決めする
  • タイムテーブル作成
  • プロポーザルを採択
  • プロポーザルをReject

Want

  • スタッフTシャツ
  • スピーカー用アンケート作成
  • HPでまだ作り込めてないもの洗い出し
  • ノベルティ検討
  • ノベルティの発注
  • 軽食の内容決める
  • 軽食の発注
  • 必要な備品の発注
  • プロポーザルフィードバック
  • トランシーバーを必要に応じて発注
  • Day2の昼食の内容決める
  • Day2の昼食の発注
  • Day1の夕食の内容決める
  • Day1の夕食の発注
  • Miroスポンサーの依頼
  • 夜に懇親会ができる飲食店をリサーチしておく
  • オンラインの体験を良くするコンテンツを考える
  • 打ち上げ会場を予約
  • カメラマンを誰にお願いするか(運営の誰かがやるのか)考える
  • ネームプレートの発注
  • キャラクター名を考える(募る)

スポンサー募集

前回スポンサーを募集した所、10分で売り切れてしまうという事態が起き、複数の会社さんから追加でスポンサーできないか?という話をいただけたので、追加でスポンサー募集をすることにしました。

枠としてはBronzeを12枠追加することになりました。12枠追加すればさすがに全て売り切れることはないと思っているのですが、今回も前回同様に先着順で、なおかつ事前にスポンサー募集を開始するタイミング(4/17 12:00-開始)をお伝えすることにしました。

全体を通した感想

バックログのメンテナンスをひたすらする会でした。その中でも、なるべく早く決めたいと思っていたスポンサー募集の話を決めることができたのはよかったです。

引き続き持続可能な形を維持しながら準備を進めていこうと思うので、あと3ヶ月の間楽しみにお待ち下さい!

ふりかえりカンファレンスで熊平 さんのkeynote(「リフレクション」って何?)を聞いてきた

ふりかえりカンファレンスに参加してkeynoteを聞いてきたので、その様子を書いていこうと思います。

retrospective.connpass.com

リフレクションの定義

「自身を客観的かつ批判的にふりかえる行為」をリフレクションとして定義するという話がありました。

リフレクションが必要になってきた背景

前例がある時代は、計画偏重でPDCAモデルが重視されてきましたが、前例がないことが求められる時代になったことで、経験が重要なAARモデル(行動→リフレクション→見通し)を高速に回すことが重要になってきて、その文脈でリフレクションが重要視されるように鳴ったという話がありました。

また、これまで結果に対して行ってきた「反省」ではなく、経験や得た学びに注目する「リフレクション」が重要視されるようになってきたということです。

メタ認知とリフレクション

「認知していることを認知する」メタ認知は、意見/経験/感情/価値観の4点セットを活用することで高められるという話がありました。

人々は過去の経験により形成されたものの見方でものごとを捉えるため、同じ情報に触れても同じ意見を持たないということです。

内発的動機を引き出すリフレクション

人の創造力を高めるためには、クリエイティブ・テンション*1を高める必要があるということで、そこにリフレクションが使えるということでした。

ビジョンと現状とのGapを埋める動機の源は、仲間と一緒にプロジェクトを成功させた時などといったやりがいを感じた理由であるということで、小さくてもよいので個々人で動機の源を探求することが重要だということです。(Googleの「情報へのアクセスは民主的であるべき」はまさに動機の源)

主体性のアップデート

これまでは、他人から求められていることに対して積極的に動けることが主体性として定義されていましたが、これからは自分が必要だと思うことに対して積極的に動くことができる主体性が求められているという話がありました。

感情のメタ認知

自身の主体性を見つけるためには、ネガティブな状態でネガティブな感情に対してメタ認知をすることができるとよいという話がありました。

ネガティブな感情は自分自身の「願い」に基づいて起きるものが多く、認知としてもポジティブな感情よりもはっきりとしているため、メタ認知の良い機会になるということです。

感情はおろそかにされがちですが、感情は自身の価値観の認知に先駆けて身体に出るものなので重要だということで、前に紹介された意見/経験/感情/価値観の4点セットが活用できるということです。

ビジョンを語る

ビジョンを語る際、何をどのように実現したくて、メンバーに対してどのような期待を持っているのか?で語られることが多いですが、それはビジョンを語っているとはいえないという話がありました。

ビジョンを語る際には、どうやって実現するのかよりも、なんでそれが必要なのかや、それに関連する経験や感情といったパーソナルストーリーを語ることが大切だということです。

MVVにもあるように、ミッションは共有してそれを行動計画に落とし込み、学びのサイクルを回していくということが重要だということでした。

経験から学ぶリフレクション

経験学習サイクルは非常にシンプルな一方で、質の差が非常に出ていることが気になるという話がありました。

そこで、質を担保するために、想定していた結果と実際の結果を計画(行動計画/仮説), 経験(経験/感情), 学び(経験からの学び/法則の定義/行動計画)の3観点からふりかえることが重要だということでした。

また、質を測る指標として、レベル1は出来事や結果、レベル2は他者や環境、レベル3は自己の行動、レベル4は自己の内面になると捉えることができるということでした。

ダブルルーム・ラーニングとアンラーニング

ダブルルーム・ラーニングは、個々人が持っているメンタルモデルを前提から疑って軌道修正することであるという話がありました。

また、アンラーニングは、アインシュタインの「問題を起こしたときと同じ思考では、その問題を解決することはできない」という言葉にある通り、過去の体験をもとにして形成されたものの見方を変えることだという話がありました。(過去の体験を否定したり消したりする必要はない)
アンラーニングしているときは、新しい物の見方に自分を変えるかどうかという選択をする際が一番大きなストレスとなるため、行動を変えないなら変えないではっきりと選択しておくことがおすすめだということでした。

対話にリフレクションが欠かせない理由

対話は自己内省して評価判断を保留して他者に共感する聞き方と話し方をすることであるため、意見/経験/感情/価値観の4点セットでリフレクションをすることで自己の内面をメタ認知し、内省と共感を起こしていくのが重要だということでした。

また、

  • 個々 × 創造&変化 = 対話
  • 個々 × 現状維持 = ディベート
  • 一体 × 現状維持 = ダウンロード
  • 一体 × 創造&変化 = 共創

だという整理がありました。*2

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

自分たちの会社で掲げられているChange to Changeはアンラーニングと同じなのか?

Change to Changeがよくわからないのでなんともいえないのだが、似ているような気がする

チームメンバの主体性を高めるためにできることはなにか?

まさにチームメンバーのリフレクションを促すことが重要だと思う

アンラーンでは価値観のアップデートがあると思うがこれは無闇にやっていいものではないと思えるのだが、やったほうがいいかどうかという基準はあるのか?

何か誰かに言われているからアンラーンする、みたいなのは奨励できない。
この状態に自分は合わないな、と思った時、「なにをなぜ今手放したいのか?(なぜ違うものを横におくのか?)」というのを考えることが重要だと思う

全体を通した感想

ふりかえりは勿論ですが、想像以上にアジャイルスクラムとのコネクト要素も多かったのには驚きました。
自分もそいうですが、Discordをみていても皆さん自身のいろいろな体験や経験に繋がってくる話が多かったので、そこでもコネクト要素があったのも非常によかったのかな、と思いました。

一方で、個々のトピックがどのようにコネクトしているのかや、個々のトピックが有益な背景や理由付けが今ひとつ腑に落ちない部分もあったので、リフレクションをしてもう一度見直そうと思いました。

*1:ビジョンと現状とのGapを埋めること

*2:ただ、一方的に話すkeynoteはダウンロードで

最後の門番はもう古い!? QA2.0をQA立ち上げ期の2社が語るに参加してきた

timeedev.connpass.com

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

会の概要

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

株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。

今回は株式会社カカクコムとの共催イベントです! 現在、カカクコムでQAの立ち上げを担う伊藤由貴さんをお招きして、タイミーでQAを担う矢尻さんでそれぞれのセッション後にパネルトークを行う予定です。 二人が考える良いQAの在り方やこれからのQAのあるべき姿など見所たっぷりでお届けします! ハイブリッド開催でオンライン視聴も可能ですのでお気軽にお申し込みください!

会の様子

QAがQAしないでQAするために by伊藤さん

QA組織の目指す姿

開発者主体で品質保証に関する活動およびその継続的改善をする姿を伊藤さんは目指しているということでした。
理由としては、

  • 伊藤さんが働いているカカクコムでは、100名程度の開発組織に対してQAは一人であり、QA採用も難しいので、最後の門番となるような体制を作ることができない
  • 伊藤さんは一人目のQAとしてjoinしているので、元々は開発者自身でテストを行っていたのでそこを大切にしたいと思った(QAがテスト業務を「はがして」もどうせQAが見てくれるマインドになるような開発者に悩む可能性もある)

を考えているということです。

目指す姿を実現するための取り組み

上述した体制を整えるために、

  • QA活動の指針としてのQAガイド作成(QA活動について共通してやるべきことやった方がいいことを定義し、品質向上のためにできることを把握するとともに品質向上の土台を作りたいと考えている)
  • 現状把握のためのQAクライテリア作成(QAガイドに即した活動ができているかのセルフチェックリストを用意して開発者に定期的にやってもらうことで、状態を把握している。アンケートは状態把握と共に、じわじわとやるべき活動のメッセージが浸透することを期待している)
  • テストのスキルや考え方のトランスファー(取り入れやすく小さな効果が得られそうな部分を伊藤さんから伝えるとともに、能動的に情報取得できる媒体を用意している)

の2点の活動を行っているということでした。

組織の変化

まずポジティブな点として、QAクライテリアの結果が徐々に改善するとともに、QAへの支援依頼*1や相談が増えたということです。

一方でネガティブな点として、状況を可視化して次の改善活動に向けたパワーが足りていないところと、障害数やリリース速度などの定性成果がまだ足りていないということでした。

駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話 by矢尻さん

開発チームへ飛び込み

矢尻さんはイネイブリングチームにQAとしてjoinしたそうで、ここでは高速に石橋を叩いて渡れるようにQAコーチとして振る舞いをしていこうと最初は考えていたそうです。

モヤモヤの始まり

チームに入ったところ、QAってテストのことだよね?という話や、QAが品質に責任を持ってくれるんだよね?という話、テストは何のためにやるのか?といった話が出ていたことにモヤモヤした矢尻さんは、

  • QAはプロダクトではなくプロセスの品質も見ること
  • QAはテストではなくアジャイルのライトウィングであること
  • QAのケイパビリティは全員にある
  • アジャイルテストの4象限

といった話をしたそうです。

イネイブリングの流れ

上記のような状態だったことを踏まえ、

  • 現在地点を評価してビジョンを共有する
  • アジャイルテストの4象限をもとに戦略を練る

を実施したそうです。イネイブリング活動を行っていくなかでは、「知識は経験から生まれ、意思決定は観察に基づく」というスクラムガイドの一節を大切にしているということでした。

また、教えるための手法としてはアクティブラーニング手法であるThe4Csを使うことを大切にしているということです。

パネルトーク

講演の後はパネルトークがありました。以下、テーマと議論内容を箇条書きかつ常体で記載していきます。

一人目QAは何を学び初手に何をするのか?
  • 既存の文化を大切にしながら、今までの知識や認知を捨てるアンラーニングすることが多い
  • 飲み会をやってとにかく仲良くなった
  • 全チームの代表者とMTGをして、顔合わせ兼ヒアリングをした
  • QAに対して悪い印象を抱いている開発者もいるので、そう思われないように振る舞えたのがよかった
現場のやる気、どう引き出す?
  • 割と上手くいっている状態でjoinしたので、「もっとこういう部分はよくやれますよ」という話をしたり知的好奇心をくすぐるような知識を渡すようにした
  • 心配事を引き出して、その心配事がわくわくに変わるようにするためにはどんなことをすればいい?という話をした
  • マインドマップを使ったテスト設計手法など、細かい道具を渡すとやる気が引き出せることに気がついた
QAとしての成果の計測はどうすれば良い?
  • 4 keysの変更失敗率やインシデント分析を実施している
  • それなりの期間計測できてきた実績がないと意味が薄いと思っている
  • 売上とかにどうつなげて話をするのか?というのは難しいと思っている
QAだと減点主義になりがちだと思うがその弊害はあるか?
  • テストをやる限りにおいては減点のコミュニケーションになりがちなので、バグをハッピーと言い換えるとかは他社事例ではあるがある
  • バグとか障害を見つけたときに躊躇う場面が出てきてしまう
  • 偉い人からの今どうなっているんだ!?みたいなものがプレッシャーになる

会全体を通した感想

きれいにまとめすぎることなく、課題感も含めてやっていることを話してくれていたのが非常によかったです。

1人目のQAとして入ると、どうしても短期的な成果を求めたくなるフォースはあるのかなあと思っていましたが、そこで長期的に活動が必要な部分から入れているのが、すごくいいなあと思って聞いていました。

*1:これやってとかではなく、これを自分たちでやりたいのだけどどうやるといいんだろう?