努力・忍耐。根性なんて大嫌い。
人生の計画なんてとっくに消えた。
周囲に溶け込めず学校や会社、時には家族の中でも孤独を感じてしまう。
エンジニアになれたと思っても、何の役に立っているのかわからない。
キラキラにワクワクして出かけたら、輝けない自分との違いに絶望。
そんな弱虫はこの世にいる価値があるのか？
ずっと辛いままじゃないのか？
この世から消えていなくなりたい。
苦しくてもがいても変化は見えない。
そんな日々をただ過ごすだけ。

でも、気がついたらこんなに生きている。
諦めていた未来がここにある。
なぜだろう。

これを運というのだろうか？
やっぱりただの偶然か？
いや、それとも何か見落としていることがあるのか？
もしそうだとしたらどこかに必然はあるのか？

それがわかれば弱虫は弱虫のままでいいんじゃないか？
弱虫が弱虫らしく生きることで小さな小さなイノベーションを起こせるなら、
弱虫が弱虫らしく生きることで実は小さな成功に繋げられるかもしれない。

なりたいものが見つからない。なりたいものになれないと悩む中、
再考を繰り返し、誰の真似もできずもがき苦しむ過程が、オリジナリティを持った個々の成長や成功への道のりにつながる可能性について共に考える機会になればと考えています。

スクラムやアジャイルの事以外の内容ですが、概念はスクラムやアジャイルな開発はもちろん、組織やチームの中で複雑な人間を捉えるヒントになる部分もあるかと思います。

なお、内容の一部には心理学的な要素および、
eroccowaruicoが過去に経験したネガティブな体験を表現した内容を含みます。

Direct URL:

海外で行われているWomen in Agile(WIA) という活動があります。WIAは、アジャイルコミュニティにおける女性のネットワーク構築やキャリア促進を支援する団体で、アジャイル活動における平等と多様性の包摂を目指しています。

皆さんの周りでは、多様性は活かされていますか？アジャイルの実践者が集まる中で、私たちはジェンダー差異を感じることが実はあまりありません。それは何故でしょうか？

アジャイルやスクラムは人間的な側面に着目し、小さなチームで相手に向き合い、「小さな違和感」を取り除いていく特長があるからです。本セッションでは、多様な現場で働いている私たちが、働く中で感じる「小さな違和感」に目を向けることがアジャイルチームにとってどう役に立つのかを語ります。

「小さな違和感」の端的な例は、女性に対する差別のようなものは職場にほとんどないのに、なぜか職場に女性管理職が少ない、ということです。これは直接変化させることはできないほど大きな問題だと思いますが、その裏にはとても多くの「小さな違和感」が潜んでいるのではないかと思います。偏見とか、自己否定とか、少数派であるのでやりにくいこととか、さまざまです。

さああなたも「小さな違和感」に気づいてみませんか？

Direct URL:

皆様は、スクラムチームが走り始めるときにまずは何から始めますか？

　プロダクトバックログを作る？

　エレベーターピッチを作る？

　インセプションデッキを作る？

　とりあえず開発環境作ってみる？

　えーい！そんな暇はない！開発着手だ！！！

あるあるーと思った皆様。

そんな皆様に私がおすすめしたいのは、スクラムチームのメンバーは今なぜここに集まっているのか？を問うことです。

ゴールデン・サークル理論という言葉を聞いたことはありますか？

TEDの人気プレゼンテーション「優れたリーダーはどうやって行動を促すか」でサイモン・シネックが解説した理論です。

端的に言うと、人が真に突き動かされるのはWhat（何をやるのか）ではなくWhy（なぜやるのか）であるという内容です。

詳細はTEDの動画を見ていただきたいのですが、このWhy（なぜやるのか）こそ、スクラムチームが走り始めるときに最初にやるべきことなのではないかと思うのです。

実は、インセプションデッキの10の設問にも「我々はなぜここにいるのか？」という設問があるので、インセプションデッキを丁寧に作成したチームならWhy（なぜやるのか）を考える機会があるはずです。

しかし実際のところ、インセプションデッキをちゃんと作ったことがあるというチームはそれほど多くないのではないでしょうか？

インセプションデッキを作らない理由は様々ですが、そのようなことにかける時間が無いという理由が大きいのではないかと考えています。

そこで、時間が無い！という皆様にはWhyから始めることを私は提案します。

10の設問があるフルセットのインセプションデッキに比べれば、チームのWhyを決めることは時間はかかりません。

ですが、Whyを設定しないままチームが走り出すよりも、Whyがある方が間違いなくチームが力強く前に進むはずです。

このセッションでは、実際にチームのWhy / How / Whatをゴールデン・サークルに当てはめて設定した私の経験をもとに、Whyから始める際のポイント・Whyを訴求し続けるためにリーダーが取るべき行動・HowやWhatに陥りやすいケースとその対策について私の経験ベースでお話します。

このセッションを見ていただいた方に、「私もチームのWhyを考えてみよう！」と思っていただけるような内容にしたいと思います。

そして、実際にチームのWhyを設定して訴求・改善し続けることで、あなたのチームはなぜやるのかに基づいた力強い推進力を得ることができると、私は考えています。

Direct URL:

変化がますます激しくなりリニアに先が予測できない状況において、強い組織、強いチームとはどういったものなのか、そして、どのように醸成すれば良いか。
多くのマネージャーやリーダーの方が悩まれています。

そのヒントの1つに自己組織化があると考えます。

では、チームの自己組織化を促進するには具体的にどうすればよいのでしょうか？
その解決策として、Management 3.0では多くの手法が紹介されています。

本セッションでは実際に手を動かして手法を体験する事で、勘所をご理解頂き、現場に持ち帰っていただく事を目的としています。

どんな手法を体験するかはルーレットで決定しますので、当日までのお楽しみです。
ただし、どんな手法でもきっとみなさんの組織やチームの円滑な運営、組織変革の推進に役立ちます。

私たちは ”明日から使える” 手法をより多くの方にご体験頂き、現場で活用頂き、少しでも現場が良く成る事を目指しています。
そして現場で実践した結果をフィードバックして頂き、良いチームを一緒に増やしていきましょう！

なお本セッションは、「人に優しい組織マネージメント」勉強会で6月に実施し、大盛況だったセッションの拡大版です。
勉強会の様子はリンク欄からご参照ください。

Direct URL:

Direct URL:

背景

• チームの熟成度: スクラムを組んでアジャイル開発に慣れてきた。
• プロダクト: 製造工場内の装置稼働率を可視化するシステム
• プロダクトのターゲット(エンドユーザー):  社内のフィールドサポート（と顧客）

一度は社内のPOからのインプットをもとにプロダクトを作っていたが、いざリリースしたら現場の求めるものとずれていて、かなり不評だった。

現場にしっかり使ってもらえるプロダクトにしたかったので、アジャイル開発の中心的な要素である、スプリントレビューにお客さんも入ってもらうことにした。

この開発ではレビューを行ってカスタマーからフィードバックをもらい、プロトタイプでの改善を進めつつ、本番プロダクトにも取り込んでいくというサイクルを1週間単位で回していった。

結果と工夫点

結果として、カスタマーが喜ぶと自信を持っていえるプロダクトができつつある。

このサイクルを回す中で、プロダクトを改善するだけでなく、スプリントレビューのやり方なども改善していった。

• 慣れてきても初回と同じくらい丁寧に導入部分を説明する。
• スライドでは、ビフォーアフターをわかりやすくして、価値が何なのかを伝える。
• システム仕様の説明を、カスタマーにとっての価値に言い換える。
• デモをしながら口頭で説明するだけではなく、スライドを併用して理解を促す。
• カスタマーがオンデマンドにデモ環境に触れるようにする。
• 期待値コントロールをして、プロト作成と本開発のバランスをとる。
• 第三者からのレビュー手法についてのフィードバック
• etc.

当日は、製造業のメッカである三河に赴いて、このようなサイクルでのスプリントレビューをうまく回すために行った試行錯誤を中心にお話し、皆さんからのご意見をもらいたいと思っています！！

Direct URL:

「スクラムチームにスクラムマスターは本当に必須ですか？」

スクラムマスターがいるのに、成果が出ていないチームもあります。

スクラムマスターがいなくても、成果が出ているチームもあります。

「その真髄はどこにあるのか？」

異なる立場で向き合う3人のスクラム実践者と紐解くセッションです。

我々3人が見てきた様々なスクラムマスターを紹介します。

• 専任
• PO兼任
• 開発者兼任
• マネージャー兼任
• SM無し
• ペア
• 複数チームのSM
• プロパー
• 社外のメンバー
• 新社会人
• 開発未経験者
• 開発経験者
• サイレントSM

様々なスクラムマスター・チームを見てきた3人が今考えていることはこのような感じです。

• SMの人数とチームの成長は必ずしも相関していない
• SMの役割を他のメンバーに分散しても良いのでは？
• 明示的にSMのラベルを貼らなくても良いのでは？
• SMの役割が多すぎるので1人でやるの難しすぎるのでは？
• SMのスキルが必要なのはスクラムだけじゃないのでは？
• SMの練習はスクラム以外でも出来るのでは？
• SMの勉強だけしていても良いSMになれないのでは？
• SMのゴールや幸せとは？
• SMのキャリアはアジャイルコーチが多いけど他に何があるんだろう？
• SMを長期間継続している人がいないのはなぜだろう？
• あらためて、SMとは？

このセッションでは、上記のようなテーマを3人と一緒に考えてみる時間です。

皆さんも一緒にスクラムマスターの価値を大解剖しましょう！

Direct URL:

3年間開発の現場で、おもに QA として、テスト、パイプラインエンジニア、そして開発チームの PM からの雑用という立ち位置で開発チームのプロセス改善を行い、以下のような発表の機会をいただけました。

• • Scrum Fest 三河 2021
    • 品質をプロセスに組み込む文化つくり
  • Scrum Fest 大阪 2022
    
    • 開発スピードと品質を向上させるための QA の関わり

どこでもテスト、どこでもふりかえりということを念頭に開発プロセスに組み込んでいます。

設計書ができてからテスト、コーディングが終わってからテストとかになると必ず後戻りが発生します。

鉄は熱いうちに打てという諺がありますが、プロセスを実践しているうちに疑問点やモヤモヤ感(違和感) 、これはヤバい臭いがする！ってことを感じた時点で、即テストを行います。

テストと言っても実際に動作させるわけではなく、メンバーのお互いの特性を生かして、仮説を立てて実証してみたり、設計書を見直しを行っていく作業も含まれます。

疑問点やモヤモヤ感  (違和感) に潜んでいるものは必ず何かしらの『バグ(欠陥)』という間違った結果を生み出す人間の行為『エラー』となりうるものです。

疑問点やモヤモヤ感  (違和感)という魔物は、最初は小さくても徐々に暗黒面に飲み込まれ、やがては手に負えない暗黒卿へと育ってしまうことが多いものです。

これらは可能な限り予防し、もしエラーがあったとしても早期発見、早期治療できるようにどこでもテストを実践しています。

さらに、このような小さなヒヤリハット(インシデント) はすぐに忘れやすいので、何かあったときにはプロセスごとにふりかえりをして、そのヒヤリハット(インシデント)を共有・共感して次のプロセス、プロジェクトに活かせることがないかを考えるようにしています。

人間は忘れる生物なので、嫌なこと、都合の悪いことを開かずの引き出しにしまい込んでしまい、「あれ？なんか辛かった気がする～、けど、まっいいか」となるので、その前に小さなことを思い出すためにどこでもふりかえりということを考えています。

このように品質はプロセス (システム) 、そしてそれを作り上げて実践していくメンバー (全員のマインド) という理念を基盤に、開発とテストが一蓮托生、同心協力でプロジェクトにあたるようなチームにしていることをお話しします。

Direct URL:

スクラムフェス初参加のはがくれと申します。よろしくお願いいたします！

SIベンダに所属してスクラムマスターをやったりウォーターフォール開発のPMをやったりぷらぷらしています。

そんな中、ここ数年で『ユーザ企業×SIベンダ』という体制でスクラム開発するということをいくつか経験しました。

教科書通りなスクラムを提案するとタイトルに書いたような"例外"がよく起こります

...なぜこのようなご要望が出るのでしょうか？どうすれば良いでしょうか？

答えはたくさんあるはずなので、どういうアプローチがあるかを色々な視点で考えてみたいと思います。

・関係者(ユーザ、PO、開発者、それぞれの上席等)の想いを考える

　→視点を変えたら"例外"ではなくまっとうな意見かも

・作りたいモノの特性から考える

　→モノによって向き不向きが見えてくる

・教科書から形を崩した時に何が起こるかを考える

　→何かを取ると何かが犠牲になる...犠牲に対して対策は？

...等々状況に応じてどのようにスクラムを組み立てたら幸せになるかひも解いてみましょう！

Direct URL:

2021年6月 CTOが退職しました。
想像できる理由はありますが、詳しいことは分かりません。

そして2021年8月 どこの馬の骨かもわからないVPoEが入社しました。
入社した彼は突然言い出します。
『これからはミルクレープ戦法だ』
何を言っているのか、意味がわかりません。
しかも彼は自分の役割を半強制的に変えてしまいます。
『井汲さんとTさんはこれから共同PM(PdM)/POね』
簡単な説明はしてもらいましたが、意味不明な「ミルクレープ戦法」に未経験のロールまで加わって本当に何をしていいかわからない状態でした。

それから自分達なり必死に解釈をして、自分達の力でチームを見直し進む事になります。

今回お話しするのは、
その中で自分や自分達が頑張ったこと。
それによって起こったこと・変化したこと・成功したこと・失敗したこと・手が届かなかった事・嬉しかったこと・悔しかったことなど、苦労も生々しさもひっくるめて発表できたら嬉しいと考えています。

この発表の目的や理由

小さな事業会社で開発をしていると、事業が成功しない限り自己評価も事業に紐づいてしまいます。
小さな成功すら本当に正しいか不安になり、成功を実感することが少なくなるからです。

一方で物事には途中経過があるとも考えています。
事業の状況にかかわらず、今まで自分達が積重ねた失敗が良い失敗なのか？悪い失敗なのか？
自分達から見える素直なふりかえりを皆さんと共有することで、自分達が少しでも自分達を客観的に評価できるようになれたら嬉しいと思います。

また、今回の発表は一部の成功もありつつ、本質的に大きな失敗がたくさん含まれています。
似たような環境で頑張っている人にとっても貴重な情報になれば嬉しいですし、それが難しくても情報交換のきっかけになればと考えています。

(単純にVPoEがやれって言った説もあります)

登壇者について

• 井汲俊介 (PM兼プログラマー) :  本発表のメインスピーカー
• 笹尾納勇仁(VPoE) : 本発表のサポート役
  (アイコン同じ人の分身かもしれません)

内容は実際に現場を回す自分目線での発表となり、VPoEは発表準備等のサポートのみとなる予定です。
(VPoEは検閲しないらしいし発表は自分だけなので不満も出せるかもしれません。)
ただし、視聴者からの質問にはどちらの立場からでも回答可能となる予定です。
(VPoEには言い訳の余地を残そうと思います。)

Direct URL:

「え、それデイリースクラムで言ってよ。」
「いやいや、その話は、デイリースクラムで話さないでよ。」
気づけば、いつのまにかこんな状態に。。。私は開発者の一人として、携わるこのチームの状況をなんとかせねばと思い始めた。

デイリースクラムとは、

スクラムのイベントの中でも一番多く開催されるイベント。
毎日やっているからこそ、慣れ親しんだイベント。
いつもの流れ作業でこなしがちなイベント。

デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
～スクラムガイド２０２０より～

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

現実を見てみると、
・進捗報告だけの場
・ファシリテーターと参加メンバの1対Nのコミュニケーションパス
・課題についてどうするかを議論しだす
・今じゃない話題が出てくる
・今いってほしい話題が出てこない
・15分じゃ収まらない

こんなデイリースクラムは、いるのか？いらないのか？どっちなんだ！？

このセッションでは、形骸化してきたデイリースクラムに対しての、私達チームの課題や悩み、それらを生み出していた根本原因、そして、課題解決と改善に向けた取り組みについて、お話します。
「デイリースクラムが形骸化する」「デイリースクラムいるの？」「デイリースクラムで何すればいいのかわからん」という同じ悩みを抱える方々のご参考になれば幸いです。

Direct URL:

東京海上日動のプロダクトを開発する我々は、『ビジネス部門との協調』『早く市場からフィードバックを得ること』を目的に、2019年からアジャイル開発をスタートしました。
スタート時点での実態としては『野良スクラム』・・・・ 
『野良スクラム』からの脱却を掲げ、『ピュアスクラム』を目指し3年が経過し、徐々にビジネスに価値を届けることができるようになりました。
また、組織の規模も拡張し、3チームしかなかったスクラムチームが、今では約15のチームが存在しています。
一方で、組織の規模が大きくなることによるサイロ化により、類似コードの重複開発や、デリバリーを優先することによる品質の低下が発生・・・
サイロ化を解消し、組織としての学びを蓄積するために、バーチャルチームを立ち上げました。

バーチャルチーム
 スクラムマスタ : 各チームの課題解決
 アーキテクト : アーキテクチャレビュー 共通部品化
 デザイナ : プロダクトデザイン UIレビュー ユーザインタビュー
 SRE : 運用の可視化 運用から開発へのフィードバック
 QA : ポストモーテム プロセス改善 テスト自動化

スクラムチームが自己管理型であることを尊重しつつ、バーチャルチームが組織横断の課題を抽出・検討し、スクラムチームのフローの進化をサポートしています。
みなさんの組織でも、活用できるエッセンスがあると思いますので、ぜひ聞いて欲しいです!

【参考】

以下ニュースの「スクラムチームの体制」にある「バーチャルチーム（ユニット）」にフォーカスしてお話します

https://bizzine.jp/article/detail/7032

Direct URL:

※要員交代の荒波に揉まれたチームとその変遷　の続きです。

人が入れ替わるスクラムPJが無事（？）終わり、そこで得た気づきをお話したいと思います。

スクラムマスターから開発者へのジョブチェンジ、体制変更/人の入れ替え、マルチベンダーが故にベンダー間のやり方が違う所からチーム内での衝突が発生したことなどを通してPJを1つ終えた自分の中で見えてきたもの。

このPJを通して（大変でしたが）当たり前だけど忘れてはいけないこと、次につながるものが得られたので、それをぜひお話して皆さんからのご意見や感想を頂いてみたいなあと思ってます。また皆さんも何か気づきがあって持ち帰ってもらえたら嬉しいです。

Direct URL:

ただいま三河。今年も帰ってきました。

昨年のスクラムフェス三河で紹介したチームNOCKnock。あれから1年経過しました。

メイン業務を持つメンバーが、隙間時間を使って活動する遊撃部隊のようなチーム。そして、社内外への発信や組織運営をスクラムでやってみる実験体のようなチーム。

【 「継続してお客様のビジネス成長に貢献する」で有名な強くしなやかな価値実現集団 】をビジョンに掲げ活動してきましが、チームはビジョンに近づけたのでしょうか？

そんなNOCKnockの1年間の活動から

• 活動したこと
• 活動の成果
• 成果への道のり
• 学んだこと

をふりかえり、

• ビジョン・ゴールに近づいたか
• 今後の活動に向けてどんなチャレンジをしていくか

などを踏まえた話をしたいと思います。

このセッションから得られる情報は、すでにスクラムを実践している方はもちろん、これからスクラムを始めてみたい、開発はしないけどスクラムのエッセンスを取り入れたい方にも有益な情報になると思います。

このNOCKnockの活動には実験的な要素も含まれています。

そんな内容を皆さんに伝えて、何かの学びになればとてもハッピーです。

Direct URL:

かつて滝行をしていたころ、私たちにとって "線を引く" ことは息をすることより自然でした。

降ってくるタスクに感謝し "線を引き"
突然の思い付きにも動じず "線を引き直し"
過去の川からの鉄砲水によって "線が崩壊し"……。

そのたびに進捗を管理する立場の方々から、 "線が正しくないんじゃない？" "ちゃんと線引いてよ" と言われ続けてきました。
私たちはそれを真摯に受け止め、"線を引く" ことに時間を使いました。

若干タイトル詐欺なんですが、アジャイル開発をしている現在でも私たちは "線を引いて" います。
ただし、どの人にも "線引いてよ" と言われることはなくなりました。

"線を引いた" あとは、"うん、大体わかった"
"線を引きなおす" 時も、"いいね、変えていこう"
"線が崩壊した" 場合でも、"知ってるよ、進めていって"

ここを見ている方の大半は「タスクの優先順位決めが重要」という話をしても「知っとるわそんなん」となると思うので、
どのようにして "進捗を管理する方々" にアプローチしていったかを伝えていきます。

例えば以下のようなアプローチになります。

• タスク一覧を "進捗を管理する方々" が確認できるよう見える化した
• 見える化することで、飛び込みタスク等、優先順位が変わることを "進捗を管理する方々" に連絡しやすくなった
• 連絡しやすくなったことで、"進捗を管理する方々" がプロダクトの現状を認識しやすくなった
• 上記をチーム内全員で改善しつつ、より良くなるようにスクラムの基本に忠実に実行した

このようなアプローチをした結果、"進捗を管理する方々" の認識に大きな差がみられるようになりました。
そして、"進捗を管理する方々" は現在、"ステークホルダー" としてふるまっていただけるようになっています。

私たちが "線を引く" ことよりも優先すべき事項を見つけられたため、伴って有効に開発ができるようになりました。
製造業における "線を引く" 開発方針に対して、アジャイル開発のメスを入れることができたかと感じております。

もし "進捗を管理する方々" への対応に困っている方がいれば、このトークを聞いていただければと思います。

Direct URL:

私たちRettyのtoB開発は、飲食店、営業、経理が使うアプリケーションを2チームで開発、保守、運用しており、それぞれのチームが1つのプロダクトバックログから決められた優先順位をもとにアイテムを取ります。

2チームで開発を進めるに当たり以下のような問題が起きました。

• 開発する領域が飲食店、営業、経理と複数あるため、2チーム間で情報共有がうまくできず、認識齟齬による手戻りが発生
• それぞれのチームで得意な技術領域やドメイン知識があるにもかかわらず、2チーム間で情報共有がされないまま開発に着手して無駄に調査の対応工数がかかってしまった

その課題を解決するために私たちは、プロダクトオーナーと開発2チームで集まって担当を決めるプランニングの際に、技術的知見やドメイン知識を持つメンバーが知見の少ないチームに一時的に所属してすすめるのが良いのではないかと考えました。
Rettyでは大規模スクラム Large-Scale Scrum(LeSS) を導入しており、その手法がLeSSにおけるトラベラーという情報共有のプラクティスに似ていたことから、トラベラーについて理解を深め積極的にトラベラーを活用して課題を解決しようとしました。

トラベラーを使って2チームで、うまく情報共有するためにどのように工夫をして課題を解決していったのかお話します。
「チーム間で情報共有がうまくできていない」と感じている方の参考になればと思っております。

Direct URL:

2012年にアジャイルと出会い、こんな働き方をしたい！との思いから色々な書籍・研修・コミュニティ活動を通じておよそ10年知識を溜めてきました。

そして、プロジェクトマネージャーをやりながらスクラムの要素を少しずつ入れてみたり、アジャイルやりたくて転職したり。

そんな紆余曲折を経てようやくスクラムをやってる現場に入りましたが、そこで実践されているスクラムに違和感を覚えます。自分の学習してきたものと何か違う。チームや進め方が何かうまくいってない気がする。そもそもスクラムマスターがいない。

そんな現場をいくつか過ごし、どの現場もうまくいってないのはスクラムマスターがいないことが原因に違いないと考えました。

「これまで10年もいろいろ学習してきた。自分がスクラムマスターをやれば良い感じにスクラムを回せるようになるできるだろう！」

そんな思いから専任スクラムマスターとなりスクラム未経験のメンバーとチームを組みます。

意気揚々とメンバーにスクラムについてレクチャーし、今まで得た知識を活かしてスクラムでプロジェクトをスタートさせました。

しかし、実際にやってみると全くうまくいきません。

進捗共有だけのデイリースクラム、ベロシティ0、進まないカイゼン、チーム解散。などなど。

まさに失敗だらけ。知識だけではうまくいかないことを痛感しました。

本セッションでは、自分が経験した失敗と起きてしまった背景、その中で試行錯誤したことなどを紹介したいと思います。

N＝1の話しではありますが、スクラムマスターをこれから始める方や始めたばかりの方のお役になる話しができれば嬉しいです。

Direct URL:

アジャイルを採用するきっかけとして、要件が固まらない、価値を明確に定められない、大きな予算が取れないなどがある。
スクラムを始めてみたは良いものの、多くのものが付け足され、シンプルにそのまま始めたつもりであっても時を追うごとに本来のスクラムから遠ざかってしまう場合がある。
例えば、誰かが決めたルール、後から足された厳格なプロセス、プロジェクト共通扱いのコンポーネント、終わらない会議。
陥りがちな改善をしているつもりで改悪してしまっていたケースを元に、
・何をすれば(しなければ)良かったのか
・どのように変更すれば良かったのか
・いつ気付けば良かったのか
・誰が主体になれば良かったのか
スクラムのイベント、ロールや価値基準とプロジェクトマネジメントで使われる取り組みを考査し、本来の守破離の守に戻れるアプローチをご紹介します。
特にビジネスと開発や、POやPMと開発者のように立場やロールの違いから生まれるすれ違いに直面している方や、これからスクラムの経験を増やしたい方にとって1つのケーススタディとしてご自身の場所に応用いただけるようなセッションにしたいと思います。

Direct URL:

昨年のスクラムフェス三河2021では、「新米QA部門長がアジャイルな組織作りを実践してみかわ」というタイトルで、新米マネージャーのストーリーと意気込みを発表させていただきました。

今年のスクラムフェス三河2022ではその後のマネージャーとしての取り組みについてお話ししたいと思います。

まだまだ先は長いものの、QA部門長として色々見えてきたものや、様々なことにチャレンジして、失敗して、学んだことがあります。そして、もしかしてこれがQAマネジメント？と感じるものを、ここで一旦まとめます。

（この一旦まとめてみるのがスクフェス三河の良さw）

以下のような内容を話したいです。

「ラインマネージャーとQAマネジメントは別物！？」

「突然動かなくなる3rd Party。情報集めと定期的な配信」

「自動テストにできない、定期的な手動リグレッションテストはアウトソースしよう」

「ねぇねぇ。QAにスクラムマスターいる？もちろんいるよ！」

「大変です！テストケース数が多すぎて自動テストが終わりません。。。」

「来週リリースするので出荷承認お願いしますー　え？」

「POも開発エンジニアもテクニカルライターも。みんな集まれ。社内専用Janet研修」

「QAもエンジニア。QMファンネルを使って自身のキャリアをイメージしよう」

「社内チリング会でスクフェス視聴してYYしよう」

「ハイヤリング×ハイヤリング」

Direct URL:

コミュニティでの出逢いがきっかけで、2021年4月からコーチングを受け始めました。
最初は、コーチングとは何なのか？コーチングを受けると何が起きるのか？...がなんとなくしかわからないような状態でスタートしましたが、セッションでは毎回様々な学びや気づきがあり、コーチングを経るにつれて確実に自身に変化が起きました。

例えば

• 自身が思いもよらない価値観を持っていたこと
• 自身が何に突き動かされているか
• 自分がサボタージュしていたこと

などについて、コーチングを受けることで気がつきました。

本セッションでは、自身がコーチングを受けてどのような事に気がつき、どのような過程を経てどんな行動変容が起こったのか？を説明することで、自分自身を変えたいのに中々変えられない人が変容を起こすきっかけを掴めることを目指します。

また、セッション前半では自身が受けているコーチングの中身についても説明するため、コーチングに興味があるけど今ひとつ実体が分からない...という人が、コーチングがどういうものなのかを知る手助けになればと思います。

Direct URL:

Direct URL:

私は夢と志を持って、新卒で製造メーカー子会社へ入社した。
官公庁向けのシステム開発で、本当に日本で生活する人の暮らしへ貢献したいと思い抱いていた。
しかし、蓋を開けてみると、現場は肉体、精神、どちらの健康に対しても良くない惨状だった。
仲間や自分自身を助けられないのに、世の中への貢献もへったくれもない。
そこで、私はアジャイルを導入しようとした。
結果、アジャイルは導入されることもなく、少しのカイゼンもできず、その会社を去った。

その様な背景を持った私は、現在、また製造メーカーに戻り、R&Dに携わらせてもらっている。
そこでもアジャイルやスクラムは導入していない。
ただ驚くことに、チームは会社が実施するアンケート調査の職場力とやらで、高数値を叩き出した。

チームは、
「研究調査の時は、何もプロセスを導入せず自由にタスクを進め、
　緊急時だけ、カンバンを導入する」
と言う、フレキシブル(?)な形に収まっている。

そこには、スクラムと言う言葉を出さず、学んだエッセンスを入れ込み、こっそり取り組んでいる背景もあるが、
なぜその様な形になったのか？

私は、どの様にチームに向き合い、どの様にチームを見ているのか？
過去の経験とも比較しつつ、紹介したいと思います。

----------
2022/8/14 追記
運営メンバーのみなさまから頂いたコメントに答える形式で説明することで、
よりセッションの詳細が伝わるかと思いますので、その形式で追記します。

> タイトルですが、このセッションの中で一番伝えたいところがそこなのか？と思いました。
> Learning Outcomeで述べているチームとは、去った前職のチームではなく現職のチームを指していると思っています。
> 現職でチームに向き合って前向きに取り組まれている話かと思いますので、
> ちょっとタイトルと本セッションで伝えたいこととのギャップがある気がしました。

今回、焦点を当てたい所は「チーム」ではなく「去った人」で、キツイ表現をすると「挫折した人」がどの様に挫折後を生き抜いているかです。
よって、決して前向きな話ではなく、ドロドロした部分も正直に伝えられたらと思っています。
それらを伝える道具の1つとして、現職チームの仕事の進め方を選びました。

私が挫折をした時、成功体験の情報は手に入れやすかったのですが、挫折した人のその後の情報は入手しづらく、今でもそうですが、不安の中を手探りで生きています。
その様な過程から、私という1例を紹介しようと思っています。

> 製造メーカーでのチームとの向き合い方」とあるが、”製造メーカー”特有の問題なのか、
> そうだとしても”製造メーカー”というところをもう少しブレークダウンした方が良いと思います。

同じ製造業でも、事業分野、社歴、従業員数などで少しずつ特徴が変わるので、その点も少し触れられたらと思いますが、概ね今回挙げる組織は、以下の特徴がある組織です。

・安定思考の人が多く変化を恐れる
・過去のトラブルや契約などでしがらみが多い
・規模が大きすぎて、お金の流れに実感が湧かない

ベンチャー企業も経験したことがあり、ベンチャー企業でもこれらの特徴は全くないとは言えないですが、経験してきた製造メーカーの方が傾向が強いと感じました。

Direct URL:

新しい開発チームに配属されたエンジニアの私は、前の現場で利用していたScrumを同じように実施したかったのですが、そのチームではScrumをやっていませんでした。
軽く打診してみたのですが、あまり反応はよくなく、新参者の自分があまり強く提案しても角が立つのではと考えて、導入に関して少し距離を置いていました。

しかし、どうしても新しいチームでScrumを実施することを諦めきれなかったため、まずは、以前のチームで実施していた内容をチームに紹介することから始めてみました。
すると、なんと一部のメンバーが内容に興味を持ってくれて、それをきっかけに今のチームの開発プロセスについて見直す場を作ることができました。

このセッションでは、こうして始まったチームへのScrum導入を1つの事例としてご紹介したいと考えています。

実施した内容としては、
初めに開発プロセスについての見直しで「一度にかかるPRのコストが大きい」「ビジネス側との距離が遠く感じる」「ベロシティが正確に測れていないため、日々の取り組みで改善できているか不安」などの課題を洗い出しました。

その中でも、取り掛かりやすそうな「一度にかかるPRのコストが大きい」をピックアップして解決に向けて取り組むことに。

その解決策としてペア作業を行い、メンバが抱えている「けっこう休憩時間が少なくて疲れる」「(ペア開始してすぐの時)作業ペースに不安があるので1日の作業目標が欲しい」などの不安を解消するためにペア作業のふりかえりの場を設ける、など発生した課題に基づいて少しずつ改善を重ねてきました。

チーム内からの発信だからこそ自分たちの課題解決として取り組むことができ、最初は難色を示されたScrum導入のメリットを少しずつ伝えることができました。
今ではビジネスチームと共にスプリントレビューを行うようになりました。定期的なコミュニケーションの場が設けられたことでビジネスチームとのスムーズな連携が可能になり、開発チームの改善だけでなく、ビジネスチームとの連携改善にも役立っています。

同じ悩みを抱えている人の参考になれば嬉しいです。

Direct URL:

対話しながらチャレンジングな目標の達成に向けてドリブンしていくOKRと、検査と適応を繰り返していくスクラムチームは相性が良いものだ、と私は考えています。過去には「OKR-based Scrum Team」と題して話したこともあります。ここではOKRのツリー構造を使って組織と個人の意思をいかに伝搬させてゆくか、特に「納得」をいかに醸成していくかという点に重きを置いて話しています。

ですが、実際に自分自身がOKRを運用している現場では、OKRを採用した2年目あたりから厳密なツリー構造というものからは脱却しています。ツリー構造にすることを重視すると、どうしても間に落ちてしまう部分が生まれてしまうというのがツリー構造をみなおすきっかけでした。同時期に「クリストファー・アレグザンダーの思考の軌跡」を読んでいたことも、ツリーを脱却しセミラティス構造に向かう直接の要因だったように思います。（本プロポーザルのタイトルは同氏による「都市はツリーではない」のオマージュになっているので、インスピレーション元がアレグザンダーであることにお気づきの方もいらっしゃることと存じます）

話は変わり、5月に開催された品川アジャイルのイベント「OKRってどういうのが正解なんだろう？」において、名著「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を題材にOKRとはそもそも何なのか、ということを川口さんとたっぷり話す機会がありました。ここで衝撃を受けたのが、あらためてこの本を読み解いてみると「OKRはツリー構造だよ」なんてことは一言も書いていない、ということでした。それどころか、私が自ら切り開いたと思い込んでいた「ツリーではない構造のOKR」は、しっかりとここで提示されていたのです。なんということだ。

気を取り直して。そう、OKRの分野の名著では「ツリーだ」なんていっていないわけです。けれども多くの現場はツリー構造に向かっているように思えます。
そして「ツリー構造に落とし込むのが難しい」といった、本来悩まなくてもよい悩みを抱えてしまうことになったりする…あなたの現場はどうでしょうか。

私自身、最初はツリー構造から出発しました。そこに窮屈さを感じセミラティス構造への転換を試み、メンバーからの意見をOKRに取り入れるよう工夫をし・・・今では、自己評価としてはうまくOKRと向き合うことができている、といえるくらいにはなりました。

このセッションでは私自身がどのようにツリーから脱却していったのかという話と、そもそも人はなぜツリー構造に向かってしまうのかという謎を解明する試みについて話せればなと考えています。

Direct URL:

　あなたは、今マーケティングとアジャイルの親和性がこれまでで最も高まっていることをご存知でしょうか？

マーケティングの神様であるフィリップ・コトラー氏は最新書籍「マーケティング5.0」において「テクノロジーと持続可能性の融合」を行なっていく中で重要なアプローチとして"アジャイル"という言葉をうたっています。

アジャイルのプロである私達がキャッチアップし、マーケターの背中を押し、足並みを揃えることで、プロダクトの成果(売上や事業貢献)はより上がっていくと考えます。

今回は、エンジニア出身PMの私が大学で3ヶ月間、スターバックス、ファミリーマート、ニューバランスのＣＭＯやマーケティング責任者から学んだマーケティング業界の潮流を交えてお話したいと思います。

▼ お話しないこと

・ごめんなさい！私自身が会社で行っているマーケティングや顧客への提案の内容は戦略そのものなのでお話できません。

・この分野、調べれば調べるほど深いです・・・。問題提起と一歩目のアプローチは提示できますが、根本解決までには僕もまだまだ学ぶ事が多すぎました。今後色んな所で続報を発表していこうと思ってます。

Direct URL:

AndroidとiOSの組み合わせのような異なるプラットフォーム向けにサービスを提供する場合、どうすれば効率良く開発を進めることができるでしょうか？FlutterやXamarin、KMMといったマルチプラットフォーム向けフレームワークを使うのも１つの手でしょう。しかし、KotlinやSwiftのように全く異なるコードベースであっても、知見を共有し協調できるようなチームを作ることによって、開発速度を維持したまま高品質なソフトウェア開発を行うことができます。この発表では ①開発速度を維持する ②高品質なサービスを提供する の２つの観点から、私達のチームの試みを紹介します。

①開発速度を維持する
全く異なるコードベースで複数プラットフォームに対応する場合、スクラム開発の工程にも工夫が必要です。そこで鍵になるのがDesign Docsです。Desgin Docsは実際に実装を行う前に書くドキュメントの１つで、開発する機能の背景・設計・検討する実装方法を予めまとめ、レビュープロセスを経ることで属人性や実装の出戻りを排除します。私達はAndrod/iOSで共通のDesign Docsを作成し、知見を共有しています。

②高品質なソフトウェアを提供する
より使いやすいアプリをお客様に使ってもらうため、ドッグフーディングと呼ばれるQAとは別に自分達で成果物を触って改善や問題を事前に発見する手法を実践しています。ドッグフーディングでは、プラットフォームの垣根を超えてお互いのアプリを触ることもあります。

プレゼンテーションでは、Android/iOSエンジニアが一つのチームとして楽しく協調しながら開発を進めていく経験や工夫について、模擬機能開発を例にお話します。

Direct URL:

海外ではPixar、Google、Netflixなど、様々な企業がインプロ（即興演劇）を企業研修として取り入れています。
アジャイルとの関係では、Lyssa Adkinsの『Coaching Agile Teams( https://lyssaadkins.com/product/coaching-agile-teams-paperback/ )』の一節で、アジャイルチームにインプロが役立つものであることが記載されています。

私（森）も拝読しましたが、
・インプロがチームメンバーのクリエイティビティを取り戻すものである
・相手のアイデアを受け入れることがクリエイティブな発想のスタートになる
ということが当たり前のように受け入れられているのを感じました。

一方で、日本ではまだまだマイナーなものであり、価値や活用イメージが湧かないという声も多く聞こえてきます。実際にスクフェス大阪2022( https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16538 )での発表後「アジャイルの現場とどう繋がるのかイメージが湧かない」「社内に説明するのが難しそう」というご意見もいただきました。

そこで今回のセッションでは、インプロの価値について実体験をベースに伝えていきたいと思います。インプロバイザー（=インプロを生業とする人）が実際に仕事現場で役立ったエピソードやそこから導き出せる価値を言語化していきます。

例えば私（森）の経験談としては、先日、会社の社長を交代するという一大イベントがありました。弊社はインプロの研修会社のため、社員はすべてインプロバイザーで構成されています。一大イベントと言いつつ、実際の交代にあたっての話し合いは、合計10分程度。当人同士で5分、社内会議で5分程度。しがらみなく交代がされました。
（世間の皆様の反応を受け、社長交代というイベントが一般にはかなり大きなできごとであると改めて実感しています）

このような、インプロバイザーならではの課題解決や状況を打破したエピソードとして、世間的には大きな話から、身近にあるちょっとしたマインドセットまで幅広くご紹介したいと思います。

この発表を通してインプロの価値を少しでも皆様にお伝えでき、活用イメージの一助となれば嬉しいです。

Direct URL:

安定性がより求められてきた製造業IT部門。一方で近年では世の中の状況も変わり、製造業IT部門も大きな変化を迫られています。これに立ち向かうためには人も技術も同時に変化（モダナイズ）していかなければなりませんが、各現場の努力だけではなかなか実現が難しいのが実状でした。
従来型の文化がまだ根強く開発の主体もオフショアの環境で人と技術のモダナイズをどう実現し広めていくか？Scrumを使って人と技術を同時に成長させられることを実例で示した私たちの小さな取り組みをご紹介します。
なお内容の配分としては組織変革全体に関する内容が３割、具体的な現場やチームの取り組みとその結果が７割位の想定です。

Direct URL:

Scrum Fest Osaka 2021で『シン・仮説検証 70,000枚の付箋で分かった仮説検証のエッセンス』という発表をし、そのなかでYOWというやり方を紹介しました。
https://speakerdeck.com/moriyuya/shin-hypothesis-testing

YOWとは簡単にいえば下記の頭文字です。
　Y:やったこと
　O:起きたこと
　W:分かったこと

行動と、行動によって起きた結果と、行動が結果を引き起こしたメカニズムに焦点を当てることで、自分達の身のまわりに起きている出来事の理解を深めます。その深まった理解を元に、次の行動を効果的なものに変えていくフィードバックループの方法です。

Scrum Fest Osaka 2021では簡単な紹介だったにも関わらず、多くの方に使っていただき、Scrum FestやRSGTで活用事例を紹介していただきました。日常的に使われている方やチームも現れてきています。

　『読書に悩むあなたに贈る50の読書方法カタログ / reading catalog Best50』
　https://speakerdeck.com/aki_moon/du-shu-ninao-muanatanizeng-ru50falsedu-shu-fang-fa-katarogu?slide=26

　『音のような言葉 〜ちゃちゃっとチャットで楽しむちょっとしたコツ〜 / words like sounds』
　https://speakerdeck.com/satoryu/words-like-sounds?slide=65

　『JavaScriptって美味しいの？の私を、プログラミングの深淵をうかがい知るところまで連れて行ってくれた、ふりかえりの力』
　https://www.slideshare.net/ShigeoKonno1/2022pdf-251548859/14

　『Extreme Small Patterns -チームを100倍理解する方法-』
　https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16114/extreme-small-patterns-100-

　『ふりかえりからはじめよ - チームづくりのシンプルな本質 - / start with RETROSPECTIVE』
　https://speakerdeck.com/takaking22/start-with-retrospective?slide=95

　『些細な変化に対する感応度を上げるために / Increase sensitivity to minor changes』
　https://speakerdeck.com/aki_moon/increase-sensitivity-to-minor-changes?slide=12

　『ふりかえりカタログ / Retrospective Catalog』
　https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45dd-911b-f8e5f1308333?slide=57

プロダクトは分かったことしか作れない

私たちはなにかしらのプロダクトを作っています。直接的にプロダクトを作る人もいれば、プロダクトをユーザーが購入できるように流通を確保する人もいますし、困ったユーザーをサポートする人もいます。

これらの仕事は、はじめての人ができるような単純なものではなく、知識や経験といった「分かっていること」を積み重ねて、ユーザーを助けられるだけの能力を持ったプロフェッショナルによってプロダクトは実現されています。

この分かっていることの質と程度はプロダクトに反映され、性能や、価格、ものの使いやすさに繋がります。よりよく分かっていけばプロダクトはより手間無く、簡単に、安全に変化しています。

この分かったことを積み上げるための方法として、YOW(やったこと/起きたこと/分かったこと)を紹介します。

毎月登場するフレームワーク、振り回される私たち

さて、さまざまな専門家が毎月のように新しいフレームワークを発表しています。みなさんも仕事をよりよくするために新しいフレームワークを採用して試してみたり、自分達で作ったり組みあわせたりして、仕事の流れをより良くできないかと工夫されていると思います。

ところがフレームワークを試してみたものの、確かな効果を実感したり、使いつづけているものは少ないのではないでしょうか。

・使ってみたもののピンとこなくてやめてしまった
・効果はあったけど時間がかかりすぎて、またやる時間がとれず放置してしている
・次から次へと出てくるフレームワークに振り回されている気がする

改めて思い返してみれば、私たちはそもそもフレームワークとはなんなのかを教えられていなかったり、どのように仕事を組み立てればいいのかはっきりしないまま、試行錯誤しているのではないでしょうか。

YOWはこのような状況を変え、フレームワークに振り回されるのではなく自分達の手中に収め、仕事そのものの設計を自由自在にできるようにするために作った3分から始められる方法です。

本セッションでは、はじめてでもできるYOWの入門に加えて、私たちの仕事を組み立てる方法を紹介します。

■セッション内容
入門編 やってみるYOW
・はじめてのYOW
・仮説立案のYOW
・仮説検証のYOW

中級編 活用するYOW
・プロダクトはわかったことしか作れない
　・無知/無能/無関心から、知ってる/できる/当事者意識
・説明深度
・経験を開く
・飽きと覇気
　・「なにか面白いことないかな」
　・戻るシグナル
　・進むシグナル
・7つの観点
　・心の言葉、話し言葉、書き言葉
　・ないない言葉
　・予測される異なる結果

上級編 仕事の組み立て
・フレームワークの問題
・アクティビティスペースで評価する
　・イベント型
 ・日常型
・研修とコンサルティングの不都合な真実
・効果的なフレームワークの採用と、仕事の仕組みを育てる
　・駄菓子(やりきる単位)
　・段階的な導入
　・スケーラブルな実施
　・他のワークとの連結
　・自己触媒ネットワーク
・仕事の地図を作る
　・問題空間
　・ONY(起きたこと/望んでいること/やってみること)
　・コーゼーションとエフェクチュエーション

Direct URL:

星野リゾートに入社してから約４年。たった一人の状態から内製化を始めた私は、４年間のうちのたくさんのチームを作り上げてきました。しかしながら、チームを作る中でよいチームになる場合もあれば、いまいちうまくいかないチームになることもあります。チームを作り上げていけば、何かしらの知見が得られるはずなので、チームが変わると必ずしもそのノウハウが役に立つわけではありません。皆さんも同じような課題を感じることはないでしょうか？
本セッションでは、私が作ってきたたくさんのチームの中から、どのような学びを得て、チームを作り上げていっているのかをお話したいと思います。

チームがどのように動いていくのかには、必ず理由があります。過去をふりかえりながら、どのような行動が良い結果を生み出していくのかお話したいと思います。

Direct URL:

2年前のScrum Fest Mikawaで、初のチーム登壇をしたチームがいました。
そのチームの名前は「オキザリス」。
2年前のこの日、初めて名前が付けられたチームです。

「オキザリス」という花名前に込められた思いは4つ。

• 輝く心
• 喜び
• あなたと過ごしたい
• 決してあなたを捨てません

これらを大切にしながら、チームは成長を続けて、またMikawaに戻って来ました。
2年前は蕾（つぼみ）だったチームが、2年間できれいな花を咲かせることができました。

このセッションでは、「スクラムフェス」に魅せられ、憧れ、手を伸ばし続けてきたチームが、どのような変化の軌跡を辿ってきたのかを語ります。

チームメンバー同士が語りながら、昔から今までをふりかえり、どんな変化が起こったのか、なぜそういうことをしたのかを紐解きます。

今はまだ小さな一輪の花ですが、これからはその花をより増やし、広げていきたいと考えています。
私たちも、フェスによって希望を受け取りました。
45分という時間の中で、みなさんにも希望のバトンをお渡しできればと考えています。

Direct URL:

Direct URL: