品質文化試論と『LEADING QUALITY』
For ScrumFest Sapporo 2022
本講演は2022年5月21日(土)に「スクラムフェス新潟」で初演されたものです。
「品質文化」というQA界隈で話題になっているトピックについて考察したものです。とても抽象的でシンドイ思考が必要であり、皆さんとも議論したいと思い、再演である(新作でない!)との謗りを承知でプロポーザルを提出します。
なぜ「品質文化」というものを考える必要があるのでしょうか? ぼくたちはエンジニアであり技術知識を深め経験を積むことは重要だと簡単にイメージできますが、さて、エンジニアリングと文化とが(それも「品質」文化とが!)どれほど関係があるというのでしょう?
ぼくが考えているのは、むしろエンジニアリングの世界は不可視の文化の土台の上で成り立っているのではないか、ということです。建物を建てるには地中に杭を打ったり礎石を据えたりしますが、そうした杭や礎石は目に見えません。
見えないなら見えないままで良い気もしますが、ビジネス環境の大きな変化が、土台に目を向けないことを許してくれなくなっているように感じます。自分たちがどのような文化の上に立っているのか、今こそ再発見・再定義する必要があるのではないでしょうか。そんな問題意識から「品質文化」の話を広めてみたいと思っています。
ぼくが「品質文化」について一生懸命考えていることが皆さんの目からどう見えているか、またより発展させていくためにはどうしたらいいか、一緒に考えてくださるとうれしいです。
以下、初演時の概要説明を記載します。
▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽
『品質文化試論』というQiitaの記事を2021年12月に公開しました。JaSST東海'21に合わせて公開したわけですが、ありがたいことに、様々なコメントを界隈で貰うことができました。
コメントを眺めていると、一人ひとりの問題意識とか立ち位置(ポジション)によって『品質文化試論』の受け取られ方は異なっているのではないかと思うようになってきました。そこで今回は、改めてMark(ぼく)が何を考えてあの文章を書くに至ったのかをプレゼンしようと思います。
『品質文化試論』で語ったことは、端的に表現すれば「品質文化は組織戦略に逆らったものにはならない」でした。その結論に至るまで、大きく2つの議論をしています。
ひとつめは、縦の階層構造です。「品質文化は組織文化に従う(逆は難しい)」のではないかと提示しています。
もうひとつは、横並びの構造と捉えて「戦略と文化は組織の両輪」と考えました。
「品質文化」というものを真正面から考えるのはシンドイのでこういう手法を取ったわけですが、結果的には「品質戦略」という言葉を引き出すに至りました。魅惑的な言葉が増えてしまって、正直なところ頭を抱えています。ただ、こうした構造を表現したことで、特に「1人目のQAエンジニア」へのメッセージを発することになったかなと思っています。
さてさて、こういうちょっと変わった角度から「品質文化」を考えるに至った源泉はなんでしょうか。これも大きく2つあると思っています。
まずはMBA(経営学修士)で学んだ知識があります。特にヒト系科目と呼ばれる「人材マネジメント」や戦略系科目「経営戦略」あたりで学んだことがベースになっています。エンジニアでMBAに通う人はまだまだごく少なく、特にQAエンジニアでいえば、国内では会ったことがありません。その意味では、少々レアな経験を積んでいると思います。
もうひとつ、5年前から海外カンファレンスや洋書を通じた学びを続けており、現在は『LEADING QUALITY』という本を翻訳しています。この本はCレベルのエグゼクティブ(たとえばCEO)が品質を重要な経営課題と認識して取り組むことの価値と、いかに推進するか、その事例が書かれています。どちらかというと技術書っぽくない、経営陣向けの「ビジネス書」に近い感覚の独特な本ですが、品質エンジニア目線で経営陣をどう説得するかを学びたい方にもおすすめできる著作です(翻訳されたら買ってください、ぜひ)。
ところで、品質関係の書籍というとどんなものを想像するでしょうか。「品質とは何か」「品質をいかに測るか」を説明した書籍や規格類が、やはり多いかなとぼくは思います。その一方で「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説した信頼できる情報源は、ほぼ皆無だとも。「品質文化」という言葉はいかようにも解釈できる危険な言葉で、避ける人もいますが、それが危険なまま放置され続けてきたこともまた、注目に値するのではないでしょうか。人類の進化に火が多大な貢献をもたらしたことを考え合わせてもいいかもしれません(プロジェクトを炎上させたくないぼくたちに火の話題はタブーかもしれませんけど)。
国内では比較的レアな品質 x MBAというコラボレーション、そして『LEADING QUALITY』をはじめ、海外から学んだ知見があって『品質文化試論』につながっているのです。
そして『品質文化試論』は「試論」にすぎません。ぼくはこれを『品質文化論』に進化させたいと考えています。たぶん、数年かけて。
今回の登壇はその長い道のりの第2歩になるかもしれません。
参加者の皆さんとの対話の中で(決して保証はできませんが)広く共有できる「なにか」があればいいなと思っています。楽しいセッションにいたしましょう。長い旅路の第2歩目を、ぜひご一緒しませんか。
Outline/Structure of the Talk
- この講演での「文化」を定義しよう
- 『品質文化試論』の背景にある問題意識
- 「品質文化」への2つのアプローチ
- 「品質文化」をなぜ今考える必要があるのか
- 「品質文化」をどうやって考えるか
- まとめ
Learning Outcome
- 『品質文化試論』に込めたMarkの想い
- なぜ「品質文化」に光を当てる必要があるか
- 自組織で品質文化をどう醸成するかのヒント
- 『LEADING QUALITY』という書籍への興味関心
Target Audience
「品質」をテスト以外の文脈、特にビジネス・組織・リーダーシップの文脈でとらえることに関心がある皆さま
Prerequisites for Attendees
- 抽象的な思考がお好きな方に、特におすすめします。
- 『品質文化試論』や英語書籍『LEADING QUALITY』を事前に読んでくださるとうれしいですが、もちろん、そうでない方にもわかるように説明します。
schedule Submitted 10 months ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yasunobu Kawaguchi / amix edcolor / Iwao Harada / Kei Ogane / Norihide Fujiki / Ryo Tagami / Yuichi Tokutomi - 品川アジャイル presents : カンファレンスの廊下を実況中継
Yasunobu KawaguchiAgile CoachAgilergo Consultingamix edcolorEngineerRelic Inc.Iwao HaradaSoftware Architectogis-riKei OganeEngineering Managerfor Startups, inc.Norihide FujikiManagerYokogawa Electric CorporationRyo TagamiEngineerFUJITSU CLOUD TECHNOLOGIES LIMITEDYuichi TokutomiCEODegino Inc.schedule 10 months ago
45 Mins
Talk
Intermediate
スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。
カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。
哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。
「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」https://twitter.com/bayashimura/status/1542480802658652160?s=21
過去の放送※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。
-
keyboard_arrow_down
Miho Nagase / Kazunori Otani / Tsutomu Yasui / Yosuke Ota / Yudai Moriya - F1 札幌グランプリ'22
Miho NagaseAgile CoachAttractor Inc.Kazunori OtaniSenior Sales Engineer, ObservabilitySplunkTsutomu YasuiConsultantself-employedYosuke Otaソフトウェアエンジニア株式会社ブックウォーカーYudai MoriyaEngineerYahoo Japan Corporationschedule 10 months ago
45 Mins
Talk
Intermediate
Regional Super GT 2022、もとい、Regional Scrum Gathering Tokyo 2022を皮切りにスタート、5月の新潟GP、6月の大阪GP、8月の仙台GP(もっか予選中)に続き、フィードバック1グランプリ'22国内ツアー、好評につき第5弾(?)を札幌で開催します!
初回から3戦連続、王座を守るyattom帝国の牙城は突き崩され、katzchang新時代へ突入!開催年月 開催地 チャンピオン
2022年11月 札幌 ???
2022年 8月 仙台 katzchang
2022年 6月 大阪 yattom
2022年 5月 新潟 yattom
2022年 1月 お茶の水 yattom
F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。
アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1札幌グランプリの勝者となり、1年間、その栄誉が讃えられます。お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか?」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか?」
回答2「ベロシティは顧客価値につながる指標なんでしょうか?」
回答3「デプロイメント頻度は計測できていますか?」お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは?」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか?」
回答3「プロダクトオーナーを説得する役割の人はいないのですか?」出演者の情報です。
実況:ながせ(miholovesq)
解説:もりや(yudmo)
ドライバー(回答者):よた(yota)、やっとむ(yattom)、かっちゃん(katzchang)
今回もローカルレーサーに声かけするつもりです。お題は下記のフォームで募集し、当日はその中から厳正なる抽選で採用されます。
https://forms.gle/9ytXii1RL9wQGrwm6
2022/10/12 追記
てやまぐ(teyamagu)選手は都合により出走取消となりました。
次節の出場をお楽しみに! -
keyboard_arrow_down
Yuki Sakaguchi - 純国産データベースエンジンのアジャイルな開発のお話
20 Mins
Talk
Intermediate
札幌で開発している「Dr.Sum」という純国産データベースエンジンをどのように開発しているかをお話しさせて頂きます。
ところで、データベースエンジンをどのように開発しているかを皆さんご存じでしょうか。
データベースを使った業務システム開発やデータベース設計については、本になっていたり、Webに色々と情報が載っています。
ただ、データベースエンジンそのものの開発についてはほとんど情報がありません。(私が知らないだけかもしれませんが。。。)
そんなベールに包まれたデータベースエンジンの開発をどのように開発しているのかを紹介します。
開発当初は実装だけやって、テストは他の会社にお願いと丸投げする開発を行ってきました。
ただし、これでは品質の良いプロダクトは生み出せないことを様々なイタイ失敗を経験しながら、より良い開発プロセスに少しずつ改善してきました。
アジャイル開発のエッセンスを取り込みつつ、自分たちなりにカスタマイズした開発プロセスを紹介します。
データベースエンジンは複雑な集計やデータ更新のSQLを扱います。
もし間違ってデータを格納したり、誤った集計結果を返したら大惨事!
そうならないようにテスト自動化がとても重要です。
テスト自動化をどのように行っているか、開発中に実行される自動テスト環境をどのように構築しているかも紹介します。
データベースエンジンというニッチな領域の開発プロセスの話ですが、
開発者とQAが協力し合いながら札幌でがんばって開発している会社があるんだというところをお届けできればと思います。
-
keyboard_arrow_down
Tatsuya Sato - 受託開発受注のためのちょっとしたコツ 〜「何でもかんでもやります」じゃなく、まずはデモ〜
20 Mins
Talk
Beginner
私が所属しているチームは、結成されてからこれまでの間に経験してきた開発は、受託開発(部署または会社の外から欲しいソフトウェアの要望が来ることから始まる開発)が少なくありませんでした。その要望を出す人たちは、ソフトウェア開発の経験や知識が無い方々が殆どでした。しかし、その人達が予算を持っており、開発を誰に依頼するのかを決める決定権を持っています。そのため、その人達にとって、もちろん開発したプロダクトのユーザーにとって魅力的でなければいけません。そのために我々は最初のデモを重要視しています。常に受注を続けてこられたわけではありませんが、受注につながったのではないかと思える実感を得られるやり方が見えてきたような気がしています。そこで、このセッションでは、そのやり方を直近で携わっているプロジェクトを例に紹介したいと思います。
-
keyboard_arrow_down
Kazutaka Matsusaki / Ayaka Ikeda - 良い活動を追いかけてたら自然とスクラムになってた
Kazutaka MatsusakiScrum MasterふくおかフィナンシャルグループAyaka Ikedaengineerふくおかフィナンシャルグループschedule 8 months ago
20 Mins
Talk
Beginner
スクラムマスターのトレーニングを完了した直後にスクラムマスターがハマる罠。
その一つに、トレーニングで得た知識をそのままチームに適用する!というものがあるのではないでしょうか?
知識の押し付けですね。私も初めてスクラムマスターに挑戦したとき、思いっきり失敗しましたw
トレーニングでこう教わったからこうなんです!!!
あぁ、恥ずかしい…
月日は経ち1年半後、新チームの立ち上げに関わることに。
初挑戦の失敗と、それまでの経験を活かして取り組むことを心に誓い臨んだチーム作り。どのように取り組んだのでしょう?
知識の押し付けで失敗した初挑戦。
それなら、知識は教えない!教えるにしても最小限。体験を最大限に活かす!
開発者にスクラム経験者が1人いたものの、はたして教えるより体験重視の方針で上手くいくのでしょうか?
チーム開始時点でのスクラムの意識はこれくらい。
- スクラムのイベントは全部やってみよう
- スクラムの作成物は全部作ってみよう
各イベントと各作成物の概要だけ伝えて、いざスタート!当然のことながらスタート時点ではイベントをこなすだけ、プロダクトを作るだけ、とりあえずやってみてます!の活動が続きます。
そんなチームですが、
チームで良い活動をしていこう!
良いプロダクトを作っていこう!
そんな気持ちは持っています。
ふりかえりも真剣にしています。真剣に取り組んでいるので、
ふりかえりで、課題がどんどん出てくる。
出てきたものを少しずつ改善していく。
上辺の改善だけではダメだと気づき、意味を考えるようになる。形だけで始めたスクラムが、いつの間にか、
スクラムの良さに気づき
チームで取り組んでいる状態に。
本セッションでは、2年間毎日書き留めたチームの活動記録とふりかえりを元に、チームがどう変わっていったのか、チームメンバーの視点を中心にお話します。
スクラムマスターとしてどう関与していったのか、ちょっぴり入れられればなとも目論んでいます。 -
keyboard_arrow_down
Tomonari Nakamura ( ikikko ) - スクラムマスターの頭の中:あのときスクラムマスターは何を考えていたのか?
45 Mins
Talk
Intermediate
スクラムマスターとして活動されている皆さん。皆さんの中には、自分が話す内容が、チームメンバーにうまく届いていないなあと感じた経験はありませんか?
スクラムマスターは、他のメンバーと少し違った視点で考えることも多く、前提知識の有無も含めて、なかなか理解・共感を得づらい場面もあります。
その場合、いきなり本題について話すのではなく、1クッション入れるのが効果的です。本題に至った思考の過程や前提知識を共有する場があると、よりメンバーからの理解や共感を得やすくなります。また、副次的な効果として、共有のために言語化する中で自分の考えを整理でき、後のふりかえりにも流用できるようになります。
本発表では、チームメンバーにスクラムマスターの頭の中を共有しながら、チーム・プロセスに関する取り組みを推し進めていった例を紹介します。月1ペースでLT発表する場を通じて、「どういう状況下で」「どういう課題を感じていて」「どのような前提を共有しつつ」「どういった取り組みを進めて」「結果どうなったか」を、いくつかのケースに応じてお伝えします。
-
keyboard_arrow_down
Yasunobu Kawaguchi - Beyond Budgeting 脱予算経営 ~ Agile 2014 キーノートを再訪する
45 Mins
Talk
Intermediate
企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。
毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。
私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。
本セッションでは、Agile 2014 での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか?
-
keyboard_arrow_down
kyon _mm - スクラムクイズ王2022
45 Mins
Talk
Intermediate
"名詞" では 「"名詞"、"名詞"、"名詞"」をまとめてなんと呼んでいるでしょうか?
みなさんはどれくらいスクラムを知っているのか?すっとその知識を出せるのか?不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。
資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにスクラムのクイズを出してその知識や引き出し方を確認してもらえればと思います。
当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。
-
keyboard_arrow_down
Yoya Kobayashi - 対話して、対話して、対話せよ! 〜品質を前もって整えるチームへ〜
20 Mins
Talk
Beginner
「QAさんからバグを指摘されたので、このバックログアイテムはDoneにできませんでした」
これはQAエンジニアである私が度々出会う、最もモヤッとする言葉です。なぜこのような発言が出るのでしょうか?
これはテストによって発生したフィードバックを、開発者が「差し込みで発生した作業」と捉えてしまうからではないかと考えています。自分の手で実装したものなのに、自分ごとにできなくなってしまう瞬間があるのです。
開発者の実装が完了した後、1Sprint遅れでQAエンジニアがテストを行うやり方を採用しているアジャイルチームを時折見かけます。これはあまり推奨できるやり方ではありません。
QAチームがテストを実施している頃、開発チームの心はすでに後続のバックログに向いていて、テスト対象となっているアイテムは「すでに終わったもの」と認識しているからです。しかし、たとえ1Sprintの中で実装からテストまで行ったところで状況は変わらないでしょう。「QAにテストを任せた瞬間に心が離れてしまう」という点は同じだからです。
また、QAエンジニア自身にも甘えや油断が発生しているのではないでしょうか?
あるバックログに対して要件に不明な点があったとき「これはテストをするときに確認すればいいか」と解決を先延ばしにしてしまうことがあります。やがてそれがSprintの終盤にバグとなって吹き出すのです。
考えられる解決手段は2つあります。
- 開発者自身でテストを行うこと
- 実装に着手する前に、要件の解像度を上げること
今回は後者についてお話ししたいと思います。
バグの多くは、要件の認識ずれによって引き起こされます。
そしてその認識ずれは、プロダクトに関わる各ロール (PO、開発者、デザイナー、QA、etc.) が細かく対話を重ねることで解消できるものも多いでしょう。テストだけが品質保証の手段にあらず。
重厚なテストに頼りすぎず、より早い段階で対話を重ねることで品質を担保するチームにシフトしていきませんか。 -
keyboard_arrow_down
Kaoru Yaoi / Yuichi Moriya - 「楽しい!」とチームは強くなる ~専任スクラムマスターの知られざる奮闘〜
45 Mins
Talk
Beginner
はじめまして。
日々、プロダクトやチームの成長を、子供の成長を見守るのと同じように楽しみながら奮闘している母ちゃんスクラムマスターです。私、この2年間、専任でスクラムマスターとして活動しています。
当初、社内SE出身で非エンジニアの私が、現役バリバリのエンジニアのなか、スクラムマスターを担えるのか?
という不安はありました。(私自身はもちろん、チームメンバーも)そんな不安と葛藤のなか、私は、チームメンバーがプロダクト開発を「楽しく!」取り組めることに注力してきました。
それは、「楽しく!」はたらくことでチームが強くなり、どんな困難もチーム一丸となって乗り越えていけると信じているからです。今回は、メンバーがプロダクト開発を楽しむことに全力を注いだ私の事例をメンバーから見た意見を交えながらお話したいと思います。
ただ楽しいだけじゃない、社内一賑やかといわれたスクラムチームの日常をのぞいてみませんか?聞いていただいた皆さんが「楽しい!」をどんどん広げて、強いチームがどんどん増えることを想像するだけで「楽しい!」
-
keyboard_arrow_down
Mori Yuya - 「どれだけ分かったら顧客を理解できたといえる?」プロダクトマネジメント入門! 様々な切り口から顧客の理解を深めよう!
20 Mins
Talk
Beginner
顧客を理解することが大切とはいっても、どのように考えればいいのかそれほどあきらかではありません。
これまで18年間、新規事業や新製品開発、リニューアルといったプロダクトの今後を左右する活動に関わってきました。2010年代からはソフトウェア開発でも、仮説検証やリーンキャンバスといった方法が認知され、プロダクトオーナーやプロダクトマネージャーにとって、顧客を理解するための様々な選択肢があります。
しかし、いったいどのようになったら顧客を十分に理解できたといえるでしょう。
また、顧客理解の新たな課題も登場してきています。チームによる顧客理解です。2010年代中旬頃までは、プロダクト開発においては一人の強力なリーダーシップによって進められることが少なくありませんでした。しかし、チームによってプロダクト開発を進める流れが起こりつつあります。顧客への深い理解はプロダクトオーナーだけの仕事ではなくなり、スクラムマスターや開発者にとっても重要な関心事になりつつあります。
知識や関心にバラツキのあるスクラムチームで、いったいどのようにすれば顧客の理解を深められるでしょうか。
このセッションでは以下の様々な切り口から顧客の理解を深める方法を紹介します。
・顧客の理解を度合いから評価する
・チーム全員で顧客を理解する・顧客との接点はどれくらい持ちやすいだろうか
・顧客をどれくらい理解しているだろうか
・顧客の悩みを考えよう
・顧客の悩みが解決されない理由を考えよう顧客の理解を育み、よりよいプロダクトを提供していきましょう!
-
keyboard_arrow_down
Yusuke Amano / Ami Shiratori / Atusuke Muratra / Masaharu Tashiro / XiaoQi Zhang - 【やってみた】スクラムチームを超生産的にするためのパタン・ランゲージ
Yusuke AmanoScrumMasterCybozuAmi ShiratoriAtusuke MuratraEngineer and Scrum masterCybozuMasaharu TashiroSoftware EngineerCybozu Inc.XiaoQi ZhangDeveloper & Scrum MasterCybozu Inc.schedule 8 months ago
45 Mins
Talk
Beginner
スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ(超生産的)チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。
各パタンの概要はこちらの記事で紹介しました。
スクラムチームを超生産的にするためのパタン・ランゲージ|天野 祐介 (ama_ch)|note筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト(通称フロリア)」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。
プロジェクトの概要やチーム体制は下記の記事で解説しています。
- kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
- 30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ
本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。
-
keyboard_arrow_down
Miyuki Yamada - スクラムから離脱した末端社員のスクラムマスターが社長に「Joy,Inc化しよう」と言ってみた話
20 Mins
Talk
Beginner
スクラムマスターのロールを学び続けることは、スクラムを離れてもこれからの時代に求められるチームビルディングにつながっている
- スクラムとの出会いと学び
- スクラムは人生そのものと思った翌月にスクラム終了した話
- 2年ほどチームと共に育つことを支えたくれた人と言葉
- アジャイルジャパンの安田さん講演からの社長に「Joy,Inc化しよう」と言ってみた話
- 今~スクラムからは離脱しているけどチームビルディングと所属組織の変容に口出しする末端社員になった話
-
keyboard_arrow_down
aki matsuno - カンファレンス/イベントで太い経験を得るために〜1,000回以上のイベント参加で得たノウハウ〜
20 Mins
Talk
Beginner
自分は、2020/11/1〜2022/9/22の間で、1,019回のカンファレンスやイベント(勉強会)に参加してきました。(2020年 : 55回 / 2021年 : 439回 / 2022年 : 525回)
どのカンファレンスやイベントも学びや刺激に溢れる素晴らしいものではありましたが、参加し始めたての頃は、自身や自身の周りに大きな変化が起きるわけでもなく、正直参加するメリットをあまり感じにくい状態でした。
しかし、カンファレンスやイベントに参加している人を観察したり、イベント参加を太い経験にするための工夫を自身で考えて試行錯誤していくうちに、徐々にカンファレンスやイベントの経験が行動変容に繋がるようになり、次第にカンファレンスやイベントに参加する意義を大きく感じられるようになっていきました。(イベントに参加する意義を感じられると共に、イベントに参加する頻度も増えていきました)
本セッションでは、イベント参加を太い経験にするために自身が行ってきた試行錯誤や、カンファレンスやイベントの種別ごとにどのように工夫するポイントを変えているか紹介することで、皆さんがカンファレンスやイベントで得られる経験をより太くし、参加者がカンファレンスやイベントをこれまで以上に楽しめるような話をしていきたいと思います。
-
keyboard_arrow_down
Takahiro Anamizu - 非スクラムチームへの異動で再認識したスクラムの魅力
20 Mins
Talk
Beginner
今年、私は新卒から慣れ親しんだスクラムチームを離れ、新天地でチャレンジし始めました。
フルリモート勤務という働き方や新チームで必要となる業界知識など、どんどん押し寄せる新たなものに立ち向かいつつ、新チームのことを観察していました。
その中には、職種に関わらず顧客価値につながる施策か議論する様子などアジャイルな精神が見えつつ、一方ではどうしてこうなってるのかと疑問に思うようなものもありました。チームの人から相談を受け、一緒にカイゼンしようと活動する中で、前スクラムチームではどうだったか考える機会がたくさんありました。
考え続けるうちに、スクラムじゃなくてもできるけど、スクラムだともっと嬉しいことがあることに気がつきました。
今回は、そんな気づきについてお話ししたいと思います。 -
keyboard_arrow_down
Muneyuki Okamoto - スクラムのエッセンスを実践してみたら、キャリアと人生の可能性が広がった〜鍵は勇気と出逢いと経験主義にあり〜
20 Mins
Talk
Beginner
確約・集中・公開・尊敬・勇気、これら5つのスクラムの価値は何もアジャイル開発の現場に留まるわけではございません。スクラムの考えを実践することは、エンジニアであっても非エンジニアであっても、キャリアの形成や人生に大きく寄与する可能性を秘めております。
非エンジニアであり、人材育成・組織開発に関わる企業の経営者として、自身のキャリアを少しふりかえりながら、スクラムの価値基準がどのように人生に寄与したかをお伝えしたいと思います。
学びのポイントとして、「勇気を出して自身の目で一次情報として経験する(もちろんオンラインもOK)こと」です。どこかで誰かが話していたことを又聞きしたり評論したりするのではなく、現地・現物を大切にすることで、きっと見えてくる世界があると信じております。
そして経験したことは、せっかくなのでふりかえってみましょう。ポイントは一人でふりかえる内省だけでなく、仲間と一緒にふりかえってみることです。経験したことを仲間にオープンにすることで、きっと何かフィードバックを得られ、新たな気づきや学びに繋がるはずです!
本セッションでは、ふりかえって見たらスクラムの価値基準をもとにアレやコレやを個人や組織レベルで実践してきた経験を元に、皆さんのキャリアや人生がほんのちょっとでも豊かになるためのTipsをお伝えしたいと思います。
-
keyboard_arrow_down
ゆうすけ おおひら - 「DIY縦軸」イベントを能動的に楽しむという考え方。または、イベントは誰が作り育てるかという話。
20 Mins
Talk
Advanced
こんにちは、世界。
私は、テストの街「葛飾」を運営者の一人、”ただのテスター”のおおひらです。
みなさん、イベントを楽しんでいますか。
最近、スクラムフェスなど、大規模イベントが増えていますね。
ただ、大規模イベントが増えていることはとても喜ばししいですが、なんとなく物足りなさを感じることはないでしょうか。
特にオンラインだと、発表の視聴はワイワイするし、あとで発表動画を見直して勉強になるけど、ただそれ以外は。。。で、もっと能動的に楽しみたい!と思っている人もいるかもしれません。(オンサイト参加でも、発表を視聴するだけで帰るだけだと、物足りないかもですね)
そんなときこそ、「DIY縦軸」です。
”縦軸”とは、24時間テレビのマラソンのような、バラエティ番組でメインコンテンツに合間に挟まれる続き物のサブ企画のことをいいます(諸説あり)。
参考:https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1151175311「DIY縦軸」では、”縦軸”という仕組みを応用して、イベント中に自分が考えたサブ企画を勝手にやり、能動的にイベントを楽しむ考え方です。
今回は、この「DIY縦軸」を実践した私の事例を紹介したいと思います。
ぜひ、みなさんも「DIY縦軸」実践し、イベントを能動的に楽しみましょう。
-
keyboard_arrow_down
Honami Tatekawa - テストをスクラムチームに還すためのQAエンジニアの取り組み
45 Mins
Talk
Intermediate
「エンジニア自身が品質を担保した状態でリリースできる開発組織」になる。
株式会社マネーフォワード HRソリューション本部プロダクト開発部では、上記の目標を掲げ、組織づくりに取り組んでいます。
マネーフォワード クラウド人事管理の開発チームに関わり出して早1.5年。
開発エンジニアのみなさんにどうやったら品質に関するスキルやマインドを共有できるのか、
また、アジャイル開発を進めていく上でテストがボトルネックにならないためにはどうすればよいのか試行錯誤してきました。まだまだ道半ば。正解には全く辿り着けていませんが、この1.5年の軌跡とこれから見たい景色について、
具体的な事例をまじえつつお話できたらいいなと思っています。 -
keyboard_arrow_down
Satoshi Harada - Back to the basic of Scrum - スクラムの"価値基準"を再考する
45 Mins
Talk
Intermediate
「スクラムとはどういったものですか?」
そう聞かれたら、あなたはどう答えますか?
そのような質問があれば、おおよそ以下のようなスクラムのロールやイベントや成果物をベースに、スクラムの特徴を説明するのではないかと思います。
- 開発者、プロダクトオーナー、スクラムマスターというロールがあるんだよ
- スプリントという短い期間で開発を区切って、繰り返していくんだよ
- プランニング、デイリースクラム、スプリントレビュー、レトロスペクティブといったイベントがあるんだよ
- プロダクトバックログやスプリントバックログといった成果物があるんだよ
しかし、スクラムのフレームワークを長年利用していて親しみがある人でも、スクラムの"価値基準"をベースにスクラムを説明しようという人は少ないように見えます。
スクラムの"価値基準"とは、以下の5つです。
- 確約(Commitment)
- 集中(Focus)
- 公開(Openness)
- 尊敬(Respect)
- 勇気(Courage)
これら5つの価値基準はスクラムガイドでも明示されているのですが、それぞれの内容が何を意味しているのか・なぜスクラムの成功を左右するのかまでは踏み込んで説明されていません。
しかし、スクラムの"価値基準"はスクラムが成功するかどうかの重要なものであること、そしてスクラムの"価値基準"が具現化できていなければスクラムを支える「透明性」「検査」「適応」がハリボテになりかねないということも、スクラムガイドは示唆しています。
このセッションでは、Back to the basic of Scrum(スクラムの基本に立ち戻る)と称して、スクラムの根幹を支えるスクラムの"価値基準"についてふりかえってみようと思います。
スクラムガイドでは踏み込んで紹介されていない5つの価値基準ですが、XP(エクストリーム・プログラミング)と組み合わせて考えることで、これらの価値基準が何を意図しているのか・なぜ大事なのか・なぜスクラムの成功に関わるのかが見えてくると考えています。
-
keyboard_arrow_down
Alex Sloley - The Best Agile Metrics – Everything Else Sucks!!!
45 Mins
Talk
Beginner
Look, you need metrics for your Agile organization, right? In the immortal words of Peter Drucker, “If you can’t measure it, you can’t improve it.” So, you need to measure things, and measure them well. And you need to measure the right things too!
Metrics on employee happiness, theoretical value, and work not done are just plain dumb. I will reveal the metrics that you need. That mean something. And that get results. Join us as we discover THE BEST AGILE METRICS!