スクラムフェス新潟2024 Day2に参加してきた（各セッションの学び記録）
こんにちは、おーのAです。
2024年5月10日に開催されたスクラムフェス新潟2024のDay2に参加してきました。セッションに参加した学びの記録です。
記録のためにザーッと書いているので読みにくいかと思いますが、ご了承ください。
Day1はこちら
kuo Odanaka - OKRと「測りすぎ」〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜
カケハシEMの小田中いくおさんのセッションです。
OKRとスクラムの関係に基づいて話が進んでいく点が非常に分かりやすかったです。そもそも私自身まだKRとして本当に定量的なものをうまく立てられていないという現状もあるので、非常に参考になるセッションでした。
Objectiveに対して弱いKRを立ててしまう可能性がある
Objectiveに効いているか確認せずともKRは進捗させることができる
実際に活動する中で、KRがObjectiveへの因果関係がなかったと気づく場合がある。こういった指標になっているものをバニティメトリクスと言う。また、「尺度が目標になると良い尺度でなくなる」ことをグッドハートの法則という
Objectiveに向かっているか分からない状況で不安を生まないようにKRを経由して目標と向き合っている
OKRの知識を持つことの意味は、「OKRを正しく活用して成果を出すため」である
正しくOKRを運用するためにOKRだけでなくCFRを知り、みんなで対話することが重要
経営層とエンジニア、などの関係においては情報の非対称性が存在しているから、取り組みたいことがあるなら、その意義や見える未来も一緒に共有することが大事
KRは設定するが、高頻度には見ないが、観察はするという点、いまいちピン来てなかったのですが、後日しいばさんがこのことに関してXでポストしていたので理解できた。下にポストも埋め込んでおく。
バックログとの関連を示した以下の図は今後ぜひ活用していきたいです。また、プロダクトバックログを更新するのと同じ感覚でKRも更新していくことが大事なのかなと理解しました。
真面目な話、数字に振り回されないことはなくて、むしろうまく数字をハックできてしまうので、いくおさんが数字の観察はしてくれてるけどチームには見せていないという動きがとてもありがたいです！端的に言うと1個前の↑のコメントになります。
— SHIIBA Mitsuyuki (@bufferings) May 12, 2024
Yoshihiro Yunomae - 開発組織のOKRの作り方
カケハシCTOの湯前さんのセッションです。
現在私も組織全体のことを考える必要があるため、本セッションを聞こうと思いました。弊社の組織でもOKRの運用を開始しているのですが、まだまだ組織全体として良い運用ができているとは思えておらず、苦心しているところです。その観点でも学びの多いセッションでした。
自分はこの仕事が向いてない（組織目標を立てる）と考えた時、「初めてのことをやっているからうまくいかない」と考える。私はなかなか気づけなくてクヨクヨしてしまう。ちゃんと自身をメタ認知して辿り着けるゆのんさんすごい
「CTOの頭の中：技術を財務で表現する」がゆのんさん的に非常にしっくりきたらしい。確かにエンジニアリングは資産を作っていると考えるという考え方は私も納得感がありました。まだちゃんとnote見てないけど、じっくり読んでみたい
ケネディの言葉「今後10年いないに人間を月に着陸させ、安全に地球に帰還させる」がめっちゃワクワクする。期限とやることとゴールが明確
ゆのんさんが目標を考えている時にユーザー体験を表現できるWebサイトの画像を30分ずっと見ていた
カケハシの組織Objectiveめっちゃカッコイイ
コミュニケーションコストに視点を向けてアーキテクチャーや組織レベルから見直ししている。組織の状況に合わせて柔軟にチーム構成を変えていくことは大事だと思いました（ただチームを変えるのは勇気がいる）
ゴールイメージはみんながワクワクするキャッチーな言葉選びが大事
とうま (Masato Ito) - スクラムチームが一体になるために行ったQAプロセス変革の道のり
Cybozeのスクラムマスターとうまさんのセッションです。
とうまさんとはRSGTで少しお話しさせていただきましたので楽しみにしていました。全体を通じてスライドがとても綺麗なのが印象的でした。QAがチームと一体となってプロセスを変えていく様子がよく分かる良いセッションだったと共に、今後チームにQAが参画する時には参考にしたいです。
マネージャやスクラムマスターが不在で組織横断の議論が活発にならない、という点はよく分かると思いました。チーム間の連携の上では透明性が必要だと思うので、横断で議論しても活発に議論できないんだろうと思います
CybozeではQAマニフェストというものを策定して、目指すべき方向性を見失わないようにしているそうです。元ネタはブロッコリーさんのブログ。
「小さな成果を祝福する」ために「やったーエリア」に挙げて共有するとのことです。小さな成果を祝福する、というのは小っ恥ずかしい感じがするので、やったーエリア、というカジュアルな感じ参考にしたい
QAムキムキ化計画とかチムビルといったキャッチーな言葉が出てきて、前のゆのんさんのセッションでもありましたが、こういった、口にしたくなるような言葉を活用するというのは参考にしたい
チームビルディングでみんなが同じ拠点に集まって非日常感を演出するのは良いなと思いました。FearlessChangeでも”場所重要"のパターンがありますし、アジャイル開発とスクラムでも野中郁次郎先生が「合宿をしなさい」と言っているし、空間の演出する魔力ってすごい
上記に関連しますが、理想と現実を語る会、というのをやってみたいと思いました
福々亭ひろにゃんこ かとうひろし - ピンチを抱擁セヨ、逆境に強い組織を目指して。- 環状島モデル、PTMF、認知ワクチン -
福々亭ひろにゃんこさんのセッションです。
組織の中の声のあげ方で何が起こっているかをトラウマという観点で分析している点が面白いなと思いました。
トラウマの環状島モデルというものがある。トラウマの環状島は地震などでトラウマの中心に近ければ近いほど、遠ければ遠いほど声が小さくなるというモデル
炎上しているような案件では中心人物であればあるほど、問題に対して声をあげにくくなる。中心人物を支えるような支援を行なっていくべき
「システムを憎んで人を憎まず」という言葉は覚えておきたい（ここでいうシステムとは情報システムのシステムではなく文化など）。渋滞でイライラして、無理やり割り込みしてきた車に腹が立つってのもシステムパワーに目を向ければ腹立たなくなるかなと思った
トラウマ体験を念頭に置いたものの見方をすることを「トラウマの眼鏡をかける」というらしい
組織としてトラウマになってることを言語化しておくことも大事そうだなーと思いました。 無意識的にトラウマになってることたくさんありそう
事例の組織に対してPTMFやトラウマの眼鏡・認知ワクチンがどのように効果があったのかをもう少し知りたかったなと思いました
Shinya Ogasawara - バーンアウトを知って燃え尽きることを防ごう
KDDIアジャイル開発センターの小笠原さんのセッションです。
バーンアウトに関することは学んだことが無かったので、（情報量が多かったですが）たくさん学びがありました。（情報量が多かったので、後で動画を見返しました）
小笠原さんはRSGT2017のキーノートでRachel Davies「Change take time. BE PATIENT」が記憶に残っているが、耐えるというのはすごく大変だと思っている
バーンアウトの定義は実は曖昧
バーンアウトを測定する尺度があり、「情緒的消耗感」「脱人格化」「個人的達成感」（ますラック・バーンアウト・インベントリー）
「脱人格化」は思いやりのない態度を取ってしまう症状
人の性格を説明するビッグファイブ。「神経症傾向」「外交性」「開放性」「調和性」「誠実性」
仕事要求度−コントロールモデル。要求に対して自分がコントロールできているかを状況を評価する。要求されてるだけでなく、状況によっては勝手に求められていることを想像して自分から突っ込んで行っちゃってるケースもありそう
対処行動には「問題焦点型対処行動」「情緒焦点型対処行動」「評価焦点型対処行動」の３つがある
バーンアウトを防ぐためには、スキルを伸ばして、上手くなること。上手くなると仕事も楽しくなるというのはあるなーと思いました
「感情労働」というものがある。感情を押し殺すことでお金を稼ぐことから生まれた表現
Kiro Harada - 従業員を不正から守れる品質管理システムの作りかた
アトラクタのKiroさんのセッションです。
KIroさんは実は元QA（というか品質保証部門）にいたらしく、このお話をなさったそうです。品質管理システムがどうあるべきなのか考えたことが無かったので、勉強になりました。
品質問題が起こった時のサーベイを見るとだいたい書かれているのは「過度なプレッシャー」
最後に触るのが品質部門なので、QAは悪者にされがち
ラボノートといって、修正の効かないノートがある。同様に品質管理システムもシステムを改変できないように設計しなければならない
品質管理システムをIT化したとき、改変・改竄できないように設計する必要がある
ルールを守りやすく作らないと逸脱するようになる。守れないルールになるとローカルでエクセル管理が始まってしまう。わかりみ
ルールが難しくなるとハックするようになる。ルールをハックすると不正してなくてもやっていることが変わらない
ルールの有効期限を設けるというのは良いなと思った。これはチームの運営ルールとかでも使えそうだなと思いました
ルール・ガイドライン・プラクティスの図が良いなと思った（下に示します）開発チームでも取り組みたいと思いました
プロダクト組織のボスがQAのボスでは大丈夫ではなくなる。だからQA組織が作られる
まとめ
スクフェス新潟はセッションの選び方が他のスクフェスと違ってテストやマインドフルネスなどにフォーカスされているので、新たな学びが多いなと思います（と言いつつ2つは個人的興味でOKRを選択してますが）。
来年も楽しみです！
この記事が気に入ったらサポートをしてみませんか？