見出し画像

スクラムフェス新潟2024イベントレポート #scrumniigata

Findy ゆーだい

本記事は、スクラムフェス新潟に現地参加レポートです。


スクラムフェス新潟とは

スクラムフェス新潟は、スクラムの中でも「アジャイル x テスト」をテーマとしたイベントの要素が強いイベントとのこと！（海外では、Agile Testing Daysというもあるようです）

公式HPにて、詳細は譲ります👇

参加したセッションなどについて、感想や雑メモを書こうと思います。

Day1

オープニング・菩薩さん

Discordやギャザリングへの参加ハードルが下がる、とてもいいオープニングセッションだった🙌

Daniel Maslyn氏基調講演

Daniel氏の基調講演は、テストの境界を認識し、成長のために越えるべき時と尊重すべき時の判断の重要性を強調する内容でした。
テスターは、品質保証だけでなく、開発者や他の利害関係者と協力する役割も持つことが重要で技術の進歩に伴い、テストの重要性が増しており、継続的な学習と新しいテスト手法の適応が求められます。

テスターだけではなく、開発者、またビジネス全般通して、越境は重要だと感じました。

勇気を持って様々な教会を超えること、重要そうです。

ネットワーキングパーティ

美味しいご飯と美味しいお酒を飲食しながら、色んな方々とお話させて頂きました。

新潟佐渡で醸造したFindyIPAを新潟への感謝の意を込めて運営と参加者の一部にお配りしました（喜んでもらえたようでよかったです）


Day2

セッションのメモを書きます（）

Mori Yuya - 「凄腕エキスパートがいるのに宝の持ち腐れ!」高度なスキルや経験豊富なエキスパートに基本ばかりさせてしまう状況から脱却して、活躍の設計と検証を通して早期にパフォーマンスを発揮してもらうぞ

  • エキスパートをどうやって生かすか

    • 転職してきた専門家

      • 今までの業務を依頼する

    • ドメインエキスパート

      • 聞かれたけど初歩的なことしか話していない

    • 創業者

      • エモい話しかしていない

    • アジャイルコーチ

      • 自信満々だったからどんな話を聞けばよかったのか

  • エキスパートから聞いてるのは参考になるが欲しい結果につながっていない

    • 参考になりますという参考中毒になる

    • 思った結果になっていない

    • 企業に対して提案業務の経験が豊富な方を除いて、顧客の状況に合わせた提案ができる経験者は少ない

  • 多くの時間で感じ取って適用して貰う必要がある

    • 組織で起きていること

    • 組織が望んでいること

    • 外部のエキスパートはそうではない

    • 短時間の関わりでは手探りが続く

    • エキスパートに入門や基本ばかりをやってもらうことに

  • どのようにエキスパートに依頼すればいいのか？

    • エキスパートに依頼するのは難しい

      • 仕事の構造

        • As-is/to be

        • 起きていること→やること→望んでいること

      • 外部エキスパートに依頼

        • 思ったほどうまく行かない

        • なんて伝えればいいんだろう

        • 現在の状況を漠然と捉えている

        • 要求定義（現在の状況から望むこと）や要件定義を類似する能力が必要

  • 依頼の構造をコモディディとマッチングでとらえる

    • コモディティ市場は取引は簡略化されていて、納得すれば買う

      • お金を払えば手に入るもの

    • マッチング市場は相手からも選ばれる必要がある

      • お互いが選ばれる必要がある

    • マーケットデザイン

      • ロードシャープレー、アルビンロスが定義

      • 望んでいることが不明瞭なマッチングは難しい

      • Aさんがさまざまな問題の中から何を解けばいいのか漠然としている

      • Bさんはエキスパートだけど、人にうまく説明できない

      • 不明瞭なマッチングが起きえる

      • 稟議などもそう

    • 不明瞭なマッチング

      • 自分も相手も何を選べばいいのか分からない

      • 不良定義なマッチングは世の中に溢れている

        • 多機能なプロダクトの問題

      • アイデア次第で無限大

        • 多くが持ち腐れ

        • 顧客のアウトカムを実現できない

    • マッチメイキング

      • 自分の問題を明らかにする

        • 起きていること→やること→望んでいることを明らかにする

        • 相手が何をできるかを明らかにする

          • 依頼者の行動サポート

          • そもそもの問題設定の見直し

          • 自分の経験を共有 など

      • マッチングする

      • マッチングを検証する

        • エキスパートとやったこと

        • 起きたこと

        • わかったこと

        • 望んだことにどれくらい近づいたのか

      • 事例

        • プロダクトマネジメント

          • プロジェクトマネジメントビジョンの明確化

          • バランス

          • QCD

          • 市場ニーズ

          • 法規制やコンプライアンス

          • 競合他社

          • ローンチのタイミング

          • フィードバックの還元

          • など沢山あるが、ちゃんと判断していく必要がある

  • プロダクトライフサイクル

    • 売上増加のフェーズ

      • 0→1

        • 遅い、高い、うまい

      • 1→10

        • 早い、安い、うまい

    • 利益増加のフェーズ

      • 10→100

      • 100→1000

    • ネクストのプロダクト

  • 活動サイクル別の組織テーマ

    • 経営

    • マネジメント

    • オペレーション

    • 市場開発

    • 製品開発

    • 組織開発

  • プロダクトマネジメントは1000でも1万でもやることはある

    • どれをやればインパクトがあるのか

    • ギャップを埋める活動を支援・伴奏する

  • 間接サポート

    • 感情サポート

    • 情報サポート

    • 評価サポート

    • 権利サポート

  • 直接サポート

    • 見守りサポート

    • 協動サポート

    • 引受サポート

  • 1年でサポートするかを設計する

    • 1,920時間

      • 毎週１時間年64時間（間接サポートの時間に）

      • 実作業を伴奏する場合は200時間を割く必要がある

  • 期待するアウトカムの狙いを明確に

    • モデルチェンジレベル

    • マイナーチェンジレベル

    • メンテナンスレベル

Yoshihiro Yunomae - 開発組織のOKRの作り方

  • 薬局向けのSaaS

    • 薬局の基幹システム

  • 経営目標、事業目標、チーム目標？何それ？

    • 開発組織OKR

      • 目標と成果を同時に考えられる

      • 目標の60％-70%が理想なのでMoon Shot

      • XXXとしての価値を開発によって高める

        • 架け橋のブランドのコアを形成する

        • 安定運用のための基盤をつくる

      • やらなきゃいけないことになりやすい

    • 方向性

      • 決まってない

    • 方向性決める人

      • 自分

    • ストレッチの度合い調整

      • 自分で調整

  • 開発組織ってどのような存在なのか？

    • どのようなミッションを追っているのか？

      • これらをクリアにしないと良い目標は作れない

    • 参考：CTOの頭の中：技術を財務で表現する

    • 売上を作るための資産（システム）を作る部署

      • 開発生産性をものすごく上げる

        • 開発生産性って何なのか分からないし、

        • いつまでどこまであげれば良いのか分からないし

        • どうなるか想像できない

  • Moon Shot

    • 今後10年以内に人間を月に着陸させ、安全に地球に帰還させる

      • 期限が明確

      • 何をするかが明確

      • ゴールが明確

    • 2029年度に医療体験を日々進化させる世界の実現

      • 5年後にカケハシのあらゆるサービスのリリース頻度が今の2倍になっている

      • 1年後にカケハシのあらゆるサービスのリリース頻度が今の15％改善されている

  • 中長期の目線に立った意思決定をする

    • コミュニケーションコストを抑えるためにアーキテクチャ・組織レベルから見直し

      • LeSSを導入

        • コミュニケーションのやり方が整備されているので、人数をスケールさせやすい

        • チーム間の同期コストがかかっていて、かなり辛い

        • リリースサイクルの低下につながっている

    • チーム間のコミュニケーションをI/F経由に制限して、独立チームで動けるような体制にできないか模索中

    • OKRを立てたことによって・・・

      • 抜本的なやり方そのものを変えていった

      • リリース頻度が上がることは顧客の対応も含めて対応が必要になる

        • 今までとやり方を考えるようになった

  • OKRで大切なこと

    • 会社のミッション・貢献価値などから、クリアなゴールイメージを描くこと

    • いつまでに達成したいかを明確にする

    • ワクワクする・キャッチーな言葉選び

    • 網羅性を気にしすぎないこと

  • OKRでしなかったこと

    • 売上を切った

    • 売上を上げるための施策は短期的な目線になるので、あえて外した

  • OKRで考えたこと

    • 医療体験が日々進化していく中で、そういう方向性があるってことが自分の中でクリアになった

Subaru Tanabe / Ren Karita / Ryosuke Osada - QA出身スリーアミーゴスでDeep Dive！ スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの

  • Freee：アジャイルQA

    • FreeeカードUnlimitedからアジャイルQAを開始

    • 仮説検証型アジャイル開発を取り入れている。

  • Biz/Opsへの連携

    • Biz/Opsにリスク洗い出し会の開催

  • Biz/Opsからの連携

    • 統合プロダクトの戦略の共有

  • 品質とスピードを両立したOneTeamを構成するために意識していること

    • 品質価値

    • 提供スピード

  • 品質価値とは何か？

    • 利便性・可用性・正確性・安全性といった品質特性が高水準で提供できる

    • プロダクト体験（PX）に付随する価値

      • 品質価値

        • 利便性・可用性・正確性・安全性

        • 品質価値KPI

          • 重篤度別欠陥件数

          • 欠陥密度

          • 欠陥除去率

      • 機能価値

        • 経済性・顧客ニーズの適用性

        • KPI

          • 継続利用率（CRR）

          • チャーンレート

          • ARR

          • LTV

          • NRR

          • CSAT

    • 品質価値と提供スピードのバランス関係を探る

  • MVPはスピード先行

    • 重篤な障害を発生させる蓋然性の高い欠陥がある品質は避ける

  • アンチパターン

    • 人を増やす・テストを増やす

      • 学習コストが上がり、理想の状態にはならない

      • 一時的に価値提供のスピードを落として、エミュレーター実装やテスト自動化を優先的に載せるスプリントを意図的に設け、中期的にスピード向上になるような準備と組織体制への移行を試みている

  • スクラムマスターから見た品質とスピードの捉え方

    • プロダクトとは、価値を提供する手段を爆速で提供すること

  • 品質とスピードの両立に立ちはだかる問題

    • ミスコミュニケーションによるニーズからそれた機能や欠陥の作り込み

  • スクラムチームは、各スプリントで価値を生み出すために必要なすべてのスキルを備えていく。

    • 自己完結を目指す

    • T字型プロフェッショナルを目指す

    • 機能横断力を組織へインストール

    • メリットは役割の専門性を超えたコラボレーションのしやすさ

      • 集中・・・認識を合わせやすくする

      • 後からキャッチアップすることを避ける。ともにインプットする

      • Leaning Session

      • なぜそう書かれているかなどを議論する

  • 機能横断型OneTeamがもたらすインパクト

    • 複合的な領域をカバーできる状態を作っていく。それに近づけていく

    • それによっていろんな視点を知ることで、課題・不具合・考慮漏れの発見やプロセスを発見できる確率を増やす

  • QA活動

    • AQUAフレームワーク

      • とにかく早く何度もリリースする

    • 主要な価値

      • コア機能は何かを理解する。重篤度で認識を合わせる

    • UX

      • 動かしてみた感想をいち早くチームに共有する。そのために、実装成果物を最速でテストすることを目指す

      • プロダクトをどう理解しているかのメンタルモデルは、擦り合わせていく

        • ユーザーのバーニングニーズは何であるか

        • メンタルモデルは議論の前提であり、メンタルモデルが揃わないとそもそも議論を行えない

    • PdM

      • 価値の提供スピードと品質のバランス・相関性を開発チームの全員で意識する

    • SM

      • チーム全員で機能横断力を高め、品質・スピード両方の向上につながる取り組み・改善の創出の確率を上げること

      • Whyを理解し、重要な使用検討をチーム全体で行うこと

おまけ

美味しいご飯たち

帰りの電車


いいなと思ったら応援しよう！