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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

海外では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分程度。しがらみなく交代がされました。
（世間の皆様の反応を受け、社長交代というイベントが一般にはかなり大きなできごとであると改めて実感しています）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

をふりかえり、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば

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

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

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

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

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

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

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

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

この発表の目的や理由

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

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

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

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

登壇者について

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

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

QAエンジニアもどんどん転職する時代ですが、
転職されるQAエンジニアの皆さん、どんなオンボードを受けましたか？

そして、転職QAエンジニアを受け入れる皆さん　どんなオンボードをしていますか？

実は、私、今年の5月にSaas企業に転職したQAエンジニアです。

そんな私が受けたオンボードのことをお話しし、参加者の皆さんからも、オンボードのお話を聞きたいと思っています。

• 会社の概要
• オンボードの概要
  • どの程度の期間実施したの？
  • 全社オンボードと部門オンボードがあったよ
• 全社オンボードでは何をしたの？
  • 会社のこととか
  • 制度のこととか
• 部門のオンボードの詳細を話す前に、私の部門を紹介
• 部門のオンボード
  • どんな風にすすめたの？
  • オンボードミーティングではどんなことをしたの？
  • ミーティング以外では何をしたの？
• 実は、フルリモートです
• コミュニケーションはどうやってとってるの？
  • 話す場が、とにかくたくさん用意されている
    • 仕事のことも
    • 雑談も
    • スキルアップにつながることも
  • こんなMTGがあるよ
    • 完全に仕事のMTGいろいろ
    • 仕事よりのMTGいろいろ
    • 勉強会
    • コミュニケーションメインのMTGいろいろ
• さまざまなMTGのおかげで、オンボードできていく
  • どんな情報を得てるの
    • 現行の仕様の経緯、背景
    • 自社サービスを使うときのTips
    • その人の人となり
    • 同僚の人となり（この情報、大事！）
    • QAのTips
    • 会社に対する愛
• リモートが基本だと、人は会いたがる
  • 隙あらばオフサイト
  • 我が社のオフサイトとは「リアルで会うこと」
• オンボードのここが有難かった
  • 受け入れてくれる人達のスタンス
  • いろんなMTGや1on1があったこと
• 質疑応答
  • 参加者にも質問したいと思います

近年のパンデミックを経て、リモートワークの浸透が急速に進み、地方に住む人達にも多様なキャリアを選択できる可能性が少しずつ出てきました。

一方で、関東圏に比べるとまだまだ乗り越えられない壁もあるように感じており、地方でITやソフトウェア開発に関わる全ての人達がキャリア発展をさせていくようには今後どのような事をしていくべきか考えていき、発表したいと思います。

■経歴

• 愛知生まれ、愛知育ち、南山大卒。
  • 祖父の代からトヨタ系の家系です。
• 新卒：武蔵精密工業株式会社
  • IT部門所属で、社内の業務効率化ツール開発
• 2~3社目：株式会社Misoca
  • 中途採用担当として、エンジニア・デザイナー採用
  • 技術イベントの運営や広報など
  • 合併して、弥生株式会社に転籍
    • 中途採用担当として、全職種の採用担当
• 4社目：株式会社マネーフォワード
  • toB向けクラウドシリーズのエンジニア採用担当
  • 名古屋開発拠点のエンジニア採用担当

住んでいる地域などの制約に囚われず、ITに関わりたい全ての人がキャリアを築けるようになることを目指して、日々働いています。

あじゃてく（Agile Tech Expo)のみなさんと発行した「ぼくのアジャイル100本ノック」
めでたく8月に発行に至りましたが、結果的に100章、450ページの本になりました。

本書の内容は、
「アジャイルの具体例を知りたい」「成功例も、失敗例も、困ったことも」「実体験を！聞きたい！」
「スクラムやってみた」「JTCでスクラムって無理じゃね？」etc…
参加者の経験、体験、知見のぎっしり詰まった、パワーのある本になりました。

アジャイルに関する色々をまとめるという本企画を通じて、
・参加者が得た体験
・コミュニティが得たこと
・本がもたらした成果、届いた先　という観点でお話しします。

普段とは違う「アウトプット」をして、参加者（寄稿者）が得た体験、
自分の知識の棚卸や整理ができたといった大きなメリットがありました。

コミュニティで本を作るということの意義の点では、
活動記録としての本という媒体、そしてコミュニティで発行することにより、
パワーのある本を作り、広く届けることができました。
また、コミュニティがそのスキームを獲得・経験することで、次回企画にも活用できます。
約60人の参加者がゆるく、でも一つのテーマについて考える機会にもなりました。

「本の執筆」という形のアウトプットの意義と、それがもたらす効果、ブログや登壇との違いをご紹介します。
インプットも重要ですが、知識・経験をアウトプットしてみましょう。
それが、聞いてくれた人の背中を押すことになれば最高です。

本を作り上げるという行為は、様々な技術要素を含む「プロダクト開発」そのものです。
本に取り上げる（文字になる）技術的内容以外にも、
ネタ出し（≒伝えたいネタを探す、想定した読者に届けるためのマーケ）、執筆≒開発、
それ以外にも、デザインやプロモーション（SNS告知など）を小規模に実体験できます。
通常のプロダクト開発では「全体のごく一部」にしか関われないことも少なくありませんが、
一気通貫にすべてを体験できるレアなチャンスです。

さらに、「合同誌」であれば、複数の著者、あるいはデザイナーや校閲など様々な立場でチームができます。
今回は企画・編集（+本文執筆も）という立場でしたが、
スケジュールの設定や、著者へのフィードバックなど、
約60人の執筆者みんなが原稿を気持ちよく出すための工夫もあります。

また、本書をはじめいくつかの技術同人誌を持ち込んで、
現地で頒布もする予定ですので、ぜひ見てみてください。

https://oyakata.booth.pm/
これまでに作った合同誌はこちら。様々なコミュニティのメンバーがいます。
合同誌ならではの内容面での広さや、いろいろなトピックスで本が書けるということを見ていただければと思います。

https://note.com/ayanaru/n/n07a5bf761d42
https://note.com/oyakata2438/n/nf62de9a7f0ff
ぼくのアジャイル100本ノックの概要・理念