名もなき未知

エンジニアリングとか、日常とかそういうのをまとめる場所。アクセス解析のためGAを利用、Googleに情報を送信しています。商品紹介のためAmazonアフィリエイトを利用、Amazonに情報を送信しています。記事に関しては私が書いていない引用文を除いて自由にご利用ください。

スクラムフェス札幌 2022で公開されている資料を読む

スクラム スクラムフェス 勉強会

しっかりと公開されていることが分かっているもののみ。 一旦、スクラムフェス札幌2022関係のものは最後にするつもりです。

順番は時系列などを考慮していません。 なお自分が特に気になったところしか書いてないので、詳細は各種スライドをご確認ください。

テストをスクラムチームに還すためのQAエンジニアの取り組み

  • QAエンジニアとしてプロダクトに入ってからどうするか、という動きがイメージしやすかった
    • （なんとなくいるとありがたいんだけど、どういう仕事をしていただくとお互いに期待感が合うのかなーっていうのは、結構自分自身も悩んでいたところでした）
    • （言語化されていてとても助かります）
  • 開発者にテストしてもらうという発想
    • テスト観点の粒度やポイントを整理してリストをチーム内で共有する
      • （めっちゃよさそうな取り組みだなーと思いました。真似したい）
    • モブレビューでレビュー速度を上げる
      • （ペアプロとかにつながるところがありそう）

開発者のテスト作成スキルを上げるための戦略もあって、そちらも参考になりました。

テストといってもテストケースをただこなすだけから、品質を意識してカイゼンしていくのはとてもよさそうに思います。

対話して、対話して、対話せよ！ 品質を前もって整えるチームへ

  • QAにテストを任せている限り、開発者は「自分の作業はもう終わった」という気持ちが生まれてしまう
    • 思い出すのにも時間がかかる
    • 不具合があって差し戻された際に、なぜか差し込み作業が発生したみたいな意識が発生してしまう
      • (このあたりに関しては完了の定義がチーム内で認識ずれとかすると起きるのかもなーとか思いました)
  • 実装着手する前に、要件の解像度を上げる提案
    • QAの思考パターンを事前に共有する
    • 想定外、考慮漏れを減らす

このあたりは自分もQAエンジニアの方と話していて、多く発見があったので経験と絡めて納得感がありました。 （開発者は非常に偏見含むですが、基本的に性善説っぽいところがあるので、異常系のカバーや仕様策定がうまくな印象がある） （この傾向は自分にもややある）

お互いに対話して相互理解を深めていくことにつながるのかもしれませんが、専門性を組み合わせてより良いプロダクトを作る、という方向性としては非常に良いなと思いました。

コンコーダンス：精神医療から学ぶ行動変化を促すコミュニケーションスキル

  • コンコーダンスは医療用語
    • 医師の指示に患者が従わないケースが出てきた
    • なので患者の価値観やライフスタイルに合わせて調和する（ざっくりな認識）というコンコーダンスが生まれる
  • 傾聴、質問、承認などコーチングとの類似点が多い
  • 対話する中で上司が部下に向き合っていく
    • いくつかポイントはあるが、そのうち面白いと思ったのは事実を起点に話を始めること
      • 5W2H2P（PはPriority, Pre-Conditionらしい、初めて聞いた（発表内での造語？））
      • （事実と意見を混ぜて話すケースは非常に多いので、意識的に話すのは大事だなあと改めて思う）

コンコーダンスでは６つの鍵となる介入と２１のスキルを用いて、患者と向き合っていくのですが、このうちのいくつかについてはコーチングでも大きく力はを発揮しそうです。 （抽出して書くの大変なので、このあたりは元のスライドを見ていただくか、実際に本を手に取ってもらうのがいいのかなと思い、書いていません）。

事実と意見を分けて話す… は何度意識してもいい問題なので、２１のスキルのうち活用できそうなものは探してみようかな、と思います

僕らのふりかえりアカデミア～原体験（オリジン）とこれから（ライジング）?

（これは発表を聞かないとわからない系な雰囲気を感じており、資料を見ても…という感じが）

一応見てて気になったところだけメモ

  • KPTの課題点としてTryまでで止まってしまうことがあげられる

SCRUM MASTER'S LANGUAGE 言葉遣いこそ最強の武器

  • （今日、今から使えそうな例文集みたいな形になっていて、すぐに筋肉になりそうでよい）
  • （特にいいなーと思ったものを1つ）
    • チケットのカテゴリーが未設定ですよ
      • サーバントシップ的にはスクラムマスターが雑務をしていた
      • しかしスクラムマスターの本来の役割はチームが自律的に動くこと
      • （スクラムマスターに雑務を押し付けていると、スクラムマスターに依存しておりチームが自律しない）
      • （よって、実際にチームメンバーにも手を動かしてもらい、チームの自律を助けるってことかな）

ちょっと自分が理解を飛躍させて、チームの自律につなげるためにこういう発言も必要と認識していますが、実際サーバントシップとチームの自律を自分の中で勘違いしていたと思いなおしました。

言葉遣いには今後とも気を付けていきたいとともに、自分に依存しないような継続的に開発が続けられるチーム作りをしないとな… と気持ちを新たにでき、よかったです。

非スクラムチームへの異動で再認識したスクラムの魅力

スクラムっていうフレームのおかげで、カイゼンし続けるという思考が生まれやすいというのがとても良いのかなと思いました。 （実際その恩恵を自分も享受している気がする）

スクラムクイズ王 2022

（難しすぎ…）

Type Cって初めて聞きました。それだけでも学びがあったかも。

スクラムの原典を読み解く(1)：An Agile Way：オルタナティブ・ブログ https://blogs.itmedia.co.jp/hiranabe/2012/06/origin-of-scrum-reopened-1.html

まとめ

どのスライドも多くの学びがあり、当日聞けなかったセッションからも学びがありました。

特にQAに関しての2つのセッションは、これから品質保障やテストプロセスの改善につながりそうなので（スクラムとの関連性はともかく）やっていきたい気持ちです。

ほか、スクラムというフレームに乗っかることで改善できるコミュニケーションや行動様式の変化もあり、カイゼンし続けるというのもいいなと思いました。 なので、とりあえずある程度動ける状態になってきたら、ウォーターフォールからスクラムに切り替えるとか（まあこれは2元的に切り借るものでもないが）、いろいろなチームの動き方も想像できてとてもよかったです。