ソフトウェアサービスの開発、運用にかかわっていると「ログ」は開発チームの生産性を左右する重要な要素だと実感します。ところが、「ログ」をどのような観点で書けばよいのか？ということに関してはあまり良いガイダンスを見かけません。本セッションでは具体例や効果を示しながら、インシデントの対応時間を激減させ、インシデント対応の自動化を促進するための「ログ」のベストプラクティスをご紹介いたします。

「安定したチーム」は、機能するチームの前提条件として様々なところで紹介されています。

「真のチーム」の必須条件  
1.課せられた「仕事」が明確なこと  
2.チームの内と外を隔てる「境界」も明確なこと  
3.仕事のやり方を管理する「権限」が具体的に決められていること  
4.メンバーの顔ぶれがあまり変わらない「安定性」があること
『ハーバードで学ぶ「デキるチーム」５つの条件』

安定したチームは、チームのキャパシティを知ることができるため、ビジネスの予測をしやすくなります。
『STABLE TEAMS - Scrum Patterns -』

長続きするチームに仕事が流れ込む
『Team Topologies』

なんとなく安定したチームがよさそうであることは多くの方が同意されることでしょう。

一方で、目の前にある現場のチームを見てみると、

• 受託開発をしていて、案件ごとにチームが組成されるのでチームが長続きしない
• 組織的にはチームになっていても、個人商店化していてチーム感がない
• 組織の都合でメンバーの入れ替えが定期的に起きてしまう
• メンバーはほぼ固定されたチームになっているが、うまく機能していない

など安定したチームとは程遠い現実が拡がっています。

安定したチームが理想であることはわかるものの現実とのギャップがあると、自分には縁遠いものだととらえてそこで思考を止めてしまいたくなります。

でも待ってください！

メンバーを固定できない状態では安定したチームをつくることはできないのでしょうか？
メンバーを固定さえできれば安定したチームをつくることができるのでしょうか？

これに似た構図を私たちは知っています。
そうです、アジャイル開発です。

私たちは変化が多い状況でも思考停止せずに現実を受け止め、変化に対応してチームで協力して価値を生み出し続けることを目指すアジャイル開発に共感をし、コミュニティに勇気づけられて、現場で行動し続けています。

チームづくりにも同じことが言えるのではないでしょうか。

Silver Bullet Clubは、2016年にチームが結成されて現在に至るまで6年以上存続しているチームです。そこだけ切り抜くと安定したチームのように見えるかもしれません。ところが実際には、2回のチーム転職を経て、会社も変わり、一緒に仕事をするメンバーが変わり、仕事のドメインが変わり、常に様々な変化の中にいました。

変化が多い状況でも諦めずに、Silver Bullet Clubであり続けようとしました。その活動の中で、安定したチームとはどのようなチームなのか徐々に理解ができ、機能する安定したチームになるための具体的なアイデアを試行錯誤してきました。

本セッションでは、安定したチームとはどのようなチームなのかを解説し、変化が多い状況の中で機能する安定したチームをどのようにつくっていくのかについて知ることができます。

様々な変化がある難しい状況の中でも諦めずに、機能する安定したチームを目指したい方はぜひご参加ください。

プロダクトゴールについては、昨年のRSGTで長沢さんが素晴らしいセッションを提供してくださいました。では、私が語り得ることは何か?

自分の経験に基づいた話。
ゴールを設定する手前の、そこにいる人がワクワクしていくためのプロセス。
そんな話をしたいと思っています。

目標管理手法のひとつOKR。Scrum Fest Mikawa 2022において「OKRはツリーではない」という発表を行いました。

その発表の中では、OKRにおいて何よりも重要なのは「目指さずにはいられないワクワクする目標を作ること」だと説明しています。

これはスクラムのプロダクトゴールに対しても同じことが言えると、私は考えています。ワクワクする、そのゴールを達成せずにはおられないからこそ、私たちは自分たちの状況を公開し、失敗する勇気をもち、互いに尊敬しあいながらゴールに集中し達成を確約するのです。
私が関わってきた組織、チームでもワクワクするOKRを設定できているかどうかがプロダクトゴールの実現度合いと密接に関わっていることを観測してきました。ワクワクOKRを持ったチームは「ありたい姿」と「プロダクトゴール」の一致度が高くなり、主体的にプロダクトゴールに向かうため達成度が高くなりました。それに対しシナシナOKRが手元にあったチームは「こんな目標、達成できると思ってません」とゴールへ向かうモチベーションさえ湧かず、したがって達成度は低い状態でした。
であれば、ワクワクしたOKRを設定しない手はないですよね。

言うは易し。

「『ワクワクする目標を作る』?それができねぇから七転八倒してるんだろうがッ!!」そんな声がきこえてくるようです。少なくとも私の胸の奥からはそのような叫びが聞こえてきました。名著「Measure What Matters」でいうところの「組織全体に目的意識と連帯感をもたらし、多様な活動を結びつける」ような目標は、ゴールはどうやって作ればいいのでしょうか。

OKRオタクを自認する小田中がこれまでに経験したうまくいった（ワクワクした）目標設定、うまくいかなかった（シナシナした）目標設定についてふりかえります。
どうやったらワクワクさせられるのか、シナシナを避けられるのかについても触れていきます。そして、目指さずにはいられないOKR、ワクワクいきいきする目標を作り上げるための再現性のあるプロセスについて解説します。ワクワクの源は千差万別、だからこそ再現させるのは難しい。けれども内発的動機を駆り立て、互いのビジョンを共有しながら深く対話することで、壁に張り出したくなるようなOKRはできるんです。おっと、ここから先は本編で。

アジャイリストなみなさんこんにちは。みなさん、「コーチング」という言葉を耳にする機会が増えたと感じてませんか？これはあくまで個人の観測範囲に過ぎませんが、2022年をふり返ってみると実際にコーチングを学び、探求し、実践する人がこのアジャイル界隈でも増えてきたなと思います。そしてこれはアジャイルコーチのみのことではなく、アジャイルに関わるさまざまな役割の人にも及んでいるとも感じてます。

さて、みなさんは "システムコーチング®（Organization & Relationship Systems Coaching®、以下ORSC®）"というコーチングをご存知でしょうか？

私は2021年中頃からこれを学び始め、2022年はほぼこれを学ぶことに注力しました。いえ、正確に言うといざ始めてみるとこれに注力せざるを得なかったのが実情です。ORSCを学ぶことは少なくとも私にとってはそれほどタフなものでした。正直、もし学び始めの時点まで時が戻るのであれば取り組み方をもう少し考え直すかもしれません。

とまぁしんどいってことを強調してしまいましたが、このプロポーザルを書いた時点(2022/9)ではまだ最後の学びのコースの道半ばではあるものの、決して後悔はしていないってことははっきりと言えます。大変ではあるけれど、自分にとって意味があり、価値がある学びを重ねられていると実感しています。更には既に実際に役に立った体験もしています。そしてこれはRSGT当日の2023/1ではより積み上げられているだろうと確信しています。

というわけで、このセッションでは私自身をサンプルとし、流しのアジャイルコーチとして何を思い、考え、何に価値を感じ、そして何故ORSCを学び、アジャイルコーチングとORSCを重ねることにどのような可能性を見出し、実際にどのように役立ったのかのエピソードにも触れつつ、この先何をしていきたいのかをお話します。

これらがみなさんの普段の中にある関係性への新たな視点や可能性を獲得でき、ORSCの世界へ足を踏み入れてみようと思った時の一歩目の道標となり、そしてアジャイルコーチングとORSCが交わって生まれるパワフルな力を感じられる、そんなセッションにしたいと考えています。

※システムコーチング®、Organization & Relationship Systems Coaching®、ORSC® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

「WF の方が向いてるプロジェクトもありますよね?」そんな議論を時々見かけます。

おそらく スクラムは、学ぶ価値のあるものなのか? それを見極めたいための質問なのでしょう。「自分の周りが WF に向いてるなら、スクラムを学ばなくても…」そんな免罪符を求めているような印象を感じてました。

スクラムは難しそうで、 WF は (みんなやってるから) 簡単というニュアンスを含んでいるようにも感じます。WF が簡単そうに見えるのは幻想で、誤魔化したり、後回しにしたりする振る舞いが習慣化されているのが実態なのですが…。 どんなプロセスを採用するにせよシステム開発は難しい ものなのです。

時は進み、 B.A. (Before Agile) を経験してない人も随分と増えてきました。「もしかして、あの地獄の日々を知らないから、 WF が向いてるかも…なんて疑問を持つのでは???」ふっとそんなことに気付きました。

かつて、社会全体が WF を目指して動いていた時代があったのです。完全な要件定義ができれば、完全な設計ができれば、次はきっとうまくゆくはず…と新しいプロセスが導入され、組織が細分化し、仕事はひたすら増えてゆきました。それでも、みんなが幸せになることはく、今に至っています。当時の経験者としては、あの頃に戻りたい気持ちはまるでありません。今、かつての WF を本気で目指しても、実践できる人はいないでしょう。また、財力も持たないでしょう。

そんな昔話を、朧げな記憶を紐解きながら、今時の 受注ゴール を間に挟んで、かつて目指した WF を露わにしつつ、対比としてのスクラムをお見せしたいと思います。

発表を聴いた後でも、(いろいろな事情で) 受注ゴールに関わり続けることになるかもしれません。ですが、迷いなく真剣にスクラムと向き合う気持ちを持ち帰ってもらえるはずです。

このセッションは、
DXやアジャイルを進めていきたいけど、なかなか進められていない、
日本の組織文化の中で悪戦苦闘している人たち向けの
銀行DXのセッションです。
ここでは、銀行DXの4年間の実際の取組を知ることができ、
教科書的な理想論や動きの早い今どきの組織の話とは違い、
ザ・日本企業・組織での取組であるので、自組織に持ち帰って現場で推進するための後押しにしやすいという特徴があります。

銀行組織、どういったイメージでしょうか？

古い、固い、つまらない、そういったイメージを持つ人が多いかと思います。
何を隠そう、私もそうでした。

実際に入社当初感じたのは、ザ・縦割り組織。

初対面でまず確認。役職は？何年入社？
出社したらまずは上席に挨拶。帰りももちろんご挨拶。
Webで入力したのに、なぜか同じ内容を紙に手書きでもう一度。え？！
堅実が一番！一番最初に挑戦？！いやいや、どこかに事例ができてからで…
上げればキリがないくらい昔ながらの日本の組織。

銀行の開発は？というと

外注オンリー。
大事なのは外注管理と、守りのIT。
すごい額とすごい年数の開発がいたって普通。

（ちょっと誇張気味ですが）さて、想像できるでしょうか？

そんな組織に内製アジャイル開発チームを立ち上げる物語。

はじめは4人からの小さな取り組みでした。
開発組織なのにエンジニアゼロ…
衝撃的なスタートではあったものの、幸いにも現在では開発メンバーも増え、内製開発できる状態にはなりました。

ただ、その活動もまだ社内の一部でやっていること。
全社的な取り組みには程遠い。（個人的な見解）
そんなもやもやと、野望を抱えながら地道な活動を続けてきました。

4年が経とうとした頃、組織にも小さな変化の兆しが。

自主的にスクラムマスターやプロダクトオーナーに興味を持ってくれる人がちらほら。
これまで、興味持ってくれそうな人に声をかけて勧誘していたのに、向こうから声をかけてくれる。
あれ、何か変わってきた？ウキウキしていると、

ここから社内にも怒涛の変化が。

これまで守り一辺倒だった既存のIT部門から、アジャイル開発やってみたいという取り組みをかわきりに、組織全体を見据えた小さなDX推進本部が立ち上がり、組織の重要案件での内製開発もスタート。

4年半を迎えた今、全社的な取り組みへと発展させる大きな組織改正がなされました。

大きなうねりが今後も続くことを期待しつつ、これまでを振り返ります。

2020年、2022年のRSGTでは現場のスクラムマスター目線での取組を話してきましたが、
今回は、チームをマネジメントする立場の人間が取り組んできたこと、考えてきたことをお話します。
同じ内容の話でも目線が違うことにより違った気づきが得られると思います。

まだまだ成長段階で、すごい人達がすごいことをやったという話ではありませんが、
レガシーの代表とも言えるような

銀行が挑戦しているのだから、自分たちもできるはず！

そういったことを感じてもらえるようなセッションにできればと思います。

世界経済フォーラム・世界銀行（World Bank）が発表した男女格差のレポートによると、ジェンダーギャップ指数は日本は116位です。女性マネージャーの数はOECD諸国の中で最も少なく、長い間、その状態が続いています。

アジャイルコミュニティで仕事をしている時はそこまで感じることがないこの話題ですが、それでも私がコーチしている非IT企業や、スクラムトレーナーとして女性達に出会うと、女性は孤軍であることが多いです。（特に管理職となるとなおさらマイノリティ！）

Harvard Business Reviewにあるように、アジャイルは開発手法ではなく、文化を作ることです。
アジャイル変革を遂行している中でうまくいっている組織、失敗した組織に関するこの調査では、
"プロセスやツールよりも個人との対話 "の重要性を改めて掲示しています。
アジャイルチームが協調的な対話プロセスを行うためには、最終的に心理的安全性（ありのままをさらけ出すことがよしとされる環境）にかかっている、ともあります。

アジャイルな環境で女性をはじめ、より多様な人々が、コラボレーティブに、リーダーシップを発揮するにはどうしたらいいのでしょうか。

私達が働くSlalom(スラロム)は、シアトルに本社を置くデジタル変革専業のコンサルティング企業です。フォーチュン誌の「最も働きがいのある会社」100社に7年連続で選ばれており、13,000人の社員のうち女性の比率が４割を超えている稀有な企業です。

ダイバーシティや、女性活躍などこの手の講演やプログラムはすでにたくさんありますが、
今もなお、見える結果が出ていないということは、まだまだやりようがあるはず。
入社してすぐに、この会社の秘密や知恵を収集して日本で活かせることがないか、
思い切って調査をしようと思い立ちました。

なぜなら私自身も、リーダーの役割を持って働いた経験がなく、なんとなく自分からは遠い存在だと思っていたからです。

このセッションは前後半を通じてアジャイル文化を体現する組織（人間中心・コラボレーティブ、フィードバックと適応、多様性など）やリーダーとは何か？を探求していきます。

◆前半
前半は調査結果とインサイトを共有します。
調査に関しては実施するにあたり２つの観点と仮説を持って調査を行いました。
 ＃統計学的観点での調査はしていません。あくまでインサイトを得るための、定性的なものが多いです
＃ID＆Eは性別だけが対象ではありませんが、今回は女性参画に焦点を当てています

(1)内的環境はどうか？
マネージャーとして活躍しようとする本人の動機があると思うがそれは何か？またはマネージャーとして選ばれる資質はあるのか？（きっとスーパーウーマンが自分で機会を勝ち取りに行っている人が多いだろう）

(2) 外的環境はどうか？
なぜ、マネージャーとして活躍できるのか？マネージャーとして活躍し続けることができる環境は何か？
（より大きな責任ある仕事や管理する仕事を任されることに喜びを見出しているんだろう）

社内のさまざまなチャネルにポストやメールをしまくり、集まった回答は約80。
その答えは私の想像するものとは正反対のものでした。
また、それらの結果にも驚くべき相関がありました！（お楽しみに！）

◆後半
後半では、Slalomで20年実験を繰り返している独自の制度や仕組み、運用方法についても具体的に共有します。
（People Leaderの定義と評価、キャリアフレームワーク、フィードバックの仕組みなど）

アメリカ各地域の女性リーダーたちが、快く、日本の女性リーダーの応援のために、また
インクルーシブな組織が生まれるように、たくさんのエールと事例を教えてくれました。
本セッションでは、日本の大きな組織で実際にリーダーを担ってきたメンバー、人事領域や組織の立ち上げを数多く行なってきたメンバーと、事例を踏まえながら発表します。

アジャイル開発をソフトウェア企業の働き方の最大公約数として捉えるムーブメントがひろまり、アジャイル実践者たちのアイディアは世界に溶け込みつつあります。ただゆっくりとしか進まない領域もあります。そう２０年前にKent Beckが取り組みながらもいまだにそうである、ビジネスや経営と開発の接合点です。

２年前に４７機関がデロイトトーマツコンサルティング合同会社に入ったときには部分しか見えていませんでした。私たちはつねに部分しか見ることができないからです。ですが、この２年で経営というものを理解しつつあるのも事実です。私たちはそこでまた同じ様に変化を始めました。どのように全体性を高めて、チームが、部署が、会社が生き生きとしていくのかにコミットするように。

４７機関はスクラムチームとしての実践からは遠ざかったとも見えますし、最もスクラムを実践しているとも見えます。スクラムの価値基準は考慮していますが、プロダクトオーナーはいませんし、スクラムイベントもありません。私たちの活動の中心はどのように自分とチームと経営が自律的に活躍するかです。

私たちはこれをLiving Managementと呼ぶ様になりました。「私たちのマネジメントはいきいきとしているか？」が考えることです。マネジメントにはさまざまな要因があるでしょう。触れ合うマネジメントは全てがターゲットです。もちろん世の中全てのマネジメントを実践する機会があるわけではありませんが。

本セッションでは経営のことを理解するチーム、チームのことを理解する経営とはどのように作り上げられていくのか？大企業に入ったチームはどのように相乗効果をだしていけるのか？を知ることができます。

部長、経営者としてどのようにチームに活躍してもらうのかを困っている方、チームとして経営の巻き込み方に困っている方、今後このようなことにチャレンジしていく方はぜひ聞いてみてください。そしてこれからの組織のあり方を共につくりあげていきましょう。

私はアジャイルには20年ほど前から取り組んでおり、アジャイルコーチとして10年ほど活動しています。
10年前から、自分が大切にしていることはそれほど大きく変わっていませんが、もたらすこと、考えていること、やっていることは変わってきています。

そんなアジャイルコーチについて最近特に「アジャイルコーチってどんなことをするの？」と聞かれることが何度かありました。

理由の1つにアジャイルコーチと名乗る人が10年前と比較して増えたこともあるでしょう。また必要に応じて、いろいろな組織が外部の力を適切に借りる選択をすることが増えたかもしれません。その一方、1つのチームや組織が複数のアジャイルコーチの振る舞いを見たり、比べたりする機会を持つことはそこまで多くないかと思います。

私は、アジャイルコーチとしての経験が長い人ほど、その経験に応じて引き出しがあり、それぞれのアジャイルコーチとしての考えや特徴が強く出てくるように思います。

アジャイルコーチの力を借りる時には、そのアジャイルコーチがどのような価値をもたらすのか、どんな考えをしているのか、なにを得意としているのかを知ることが、より良い結果を引き出すポイントの1つです。

このセッションでは、私がアジャイルコーチとしてもたらそうとしているのか？何を考えて、どんなことをしているのか？という"アジャイルコーチの1つの類型、中村洋の場合"をお話します。

「え、まだウォーターフォール開発やってるのw」という声をよく聞きます。

ウォーターフォールはもう時代遅れで過去の遺物なんでしょうか？

確かに「ウォーターフォール開発」と呼ばれたソフト開発には、辛い・不条理・非効率・etc、、といったネガティブな思い出がたくさんあります。
そしてそれらは近年の「アジャイル開発」によって劇的に改善され、私もその大きな恩恵を日々実感しています。

しかし、ウォーターフォールは本当に時代遅れで過去の遺物なんでしょうか？（二回目）

私自身はソフト開発に関わって25年ほどが経ち、その半分をウォーターフォールで、残りの半分をアジャイルで過ごしてきました。

そんな中で最近ふとした瞬間に
「あ、このやり方って若い時に習ったな」とか
「この仕組みはこういう意図があったのか、なるほど」と感じることがあります。

そして「これは武器になるな」と思うものが、実は結構な割合でウォーターフォール時代に覚えたことなのです。
・・・もしかしてここには何かお宝が埋まっているのでは？
・・・これは放っておくと永遠に失われてしまうのでは？

このセッションでは、（自分も含めて）勢いよく捨て去ろうとしているウォーターフォール時代のソフト開発を見つめ直し
そこで育ったエンジニアがアジャイル開発全盛の今日でも活躍できる方法について、みなさんと一緒に考えてみたいと思います。

昔は良かった系の話ではないので、若い人も是非！

ろう者・難聴者の参加者と聴者の参加者がRSGT2023でワイワイGatheringできる方法を
一緒に考えて実践するワークショップです。
----------------------------
私は筑波技術大学産業技術学部という、ろう者・難聴者の学生が通う大学で
デフエンジニアを育てています。

2022年の夏休み、琉球大学で開催されているアジャイルミニキャンプに初参加したところ、アジャイル開発とても楽しい！もっと他のところでもやりたい！と盛り上がっていたので、RSGT2023でいろんな人とワイワイして、授業に限らずアジャイル開発ができる機会をゲットしようよ！と誘いました。
学生たちもプロポーザルを出しています。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17568

RSGTはアジャイルを実践している人、初心者、興味のある人、様子を見にきた人、全ての人が参加しやすく、みんな気さく・オープンで、廊下での会話でネットワーキングが活発なのが私の好きなところで、私がアジャイル開発に興味を持った学生たちをつれていきたい理由がそこにあります。

ただそれに際して思い悩んでいることがあります。
それは、活発＝大変賑やかなRSGTの環境によって、ろう者・難聴者の参加者たちが話の内容を理解できる機会が大幅に減ってしまう、という問題です。同じ場所で同時多発的に多くの会話が発生する環境では、補聴器や人工内耳等で普段比較的音をとれる人でも話を聞き取るのが難しくなり、音声認識も役に立たなくなります。

セッションで発表をしたり聞いたりすることは、情報保障を工夫すればできます。
でもRSGTの最大の魅力はGathering、ワイワイすることなのでその魅力を享受できなのは勿体無い。
さてどうしたものか。。。

一人で考えていても仕方ない。参加する予定の学生たちはまだRSGTのワイワイした状況を知らない。ならば他の参加者にも協力してもらって、興味を持ってくださったみんなとワイワイする方法をワイワイと一緒に考えれば良いのでは。。。？

と言うわけで、どうやってワイワイするかをワイワイ考えてやってみる会を提案します！
基本的に、対面の環境を優先的に考えたいと思います。
（もちろん工夫の一つとしてオンラインとのハイブリッドも考えられそうですが。。。）

まずは考える材料として

• 聞こえ方の多様性
• コミュニケーションの手段（筆談、音声認識、手話通訳、手話、ジェスチャーなど）
• ワイワイガヤガヤした状況で難しくなること

をお伝えした後、みなさんと「そもそもワイワイってどんなこと話してる？話したいの？」ってことなどをお聞きしたりして、やりたいことの対象を少し絞り込んでから、じゃあどうしたらいいんだろう？っていうのを実験的にいくつかやってみようと思います〜！

私はIT業界で30年、ずっとウォーターフォールでの開発をしてきました。

20004年のある日。私は「初めてのアジャイル開発」という本に出会いました。デスマーチに巻き込まれていた私は、衝撃を受けました！！
ソフトウェア開発は、もっと楽しく想像的なものであるべきではないのか。
今私がやってるやり方は、間違っているのではないか？

それ以来、ずっとアジャイル開発がしたいと思っていましたが、なかなか機会は訪れませんでした。そして昨年末のこと。「もうアジャイルしかやらぬ！」と決め、とうとう今年4月にスクラムマスターに転生いたしました！

これは、私の勇気と希望の物語です。

★このセッションでは、以下のような話をします。

• 私が経験した、初めてのスクラム
• スクラムとウォーターフォールとの違い
• 経験なしで新しい環境に飛び込む方法
• アジャイルなキャリア開発

★こんな方向けです。

• ウォーターフォールからアジャイルの世界に行ってみたい人
• 50歳Overで、今後のキャリアを少し見直してみようという人
• 私の勇気の記録を見て、勇気づけられたい人

30年前にウォーターフォールで開発していた人たちは、開発プロセスがこんなに変わるなんて全く思っていませんでした。もしかしてあなたも、20年後に異世界に転生することになるかもしれません…！！

auでんきの「でんきアプリ」は、Large-Scale Scrum（LeSS）フレームワークで7年目に突入しました。
4チームでスクラムオブスクラムズを構成しています。

おかげさまで月間100万人以上のお客様に利用いただけるアプリへ成長しましたが、
以下のような多くの要望があります。

• より多くの魅力的な機能を短いスパンでリリースしたい
• プロダクト運営にかかわる対応をスピーディに行いたい
• 日々アップデートされるセキュリティ対策を施したい
• エンジニアは新しい技術をプロダクトで試したい

 etc….

これにより、POが全ての内容を理解して優先順位を決めることが難しくなり、
並行作業が多くリリーススピードの停滞が見えるようになりました。

また、プロダクトの期間が長いため人も入れ替わり、今の変化したやり方が当たり前になり、変えようとする気持ちも薄れつつあります。

スクラムを採用する意味を改めて考え直し、
より素早く市場へ投入できるようにカイゼン活動を行なっております。

スクラム導入の基本である
「スクラムを組織に導入する時は小さくても完璧なスクラムチームをまずは綺麗に回すべき」を既存のLeSSチームの中で実施しています。

既存プロダクトを運営しながらの大胆なカイゼン内容と結果を皆様に共有いたします。