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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あなたの現場では、こんなことがおきていませんか？

「ペアプロを導入したいけど、上司が…」
「Daily Scrumで何も話題が出てこない…」
「本やブログで書いてあったやり方をやってみたけど…」

同じような問題でも、現場によって有効な解決策やアプローチは違ってきます。
簡単にいうと銀の弾丸はありません。

そこで！

実際に皆さんの現場で起きている問題や悩みを出してもらい、とにかく前向きな6名が通用するかどうか分からない鉛玉を大量に提供したいと思います！

色んな現場で実際に試して
失敗したアイデア、
成功したアイデア、
社内のチェンジエージェントの観点、
社外のアジャイルコーチの観点、
あの現場での話、
この現場での話…
数ある鉛玉から自分の現場に合いそうな輝く弾丸を持ち帰ってください。

セッション中は

みなさんも無責任に「自分だったらこうするかなぁ」「こんなことしたら上手くいったよ！」という鉛玉をじゃんじゃん放流してくださいね！

みんなでわいわいしましょー。

前回から1年、360度変わった6人の姿にご期待ください！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

背景

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

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

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

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

結果と工夫点

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

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

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

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

海外で行われている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と向き合うことができている、といえるくらいにはなりました。

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

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

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

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

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

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

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

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

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

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

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

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

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

をふりかえり、

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

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

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

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

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

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(起きたこと/望んでいること/やってみること)
　・コーゼーションとエフェクチュエーション

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

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

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

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

▼ お話しないこと

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

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

昨年のスクラムフェス三河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エンジニアが一つのチームとして楽しく協調しながら開発を進めていく経験や工夫について、模擬機能開発を例にお話します。

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

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

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

【参考】

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

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

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

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

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

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