PracticeBeginnerScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。(Wikipediaより抜粋)このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。PracticeIntermediate私(@ama_ch)が所属するサイボウズでは、「チームワークあふれる社会を創る」というビジョンを掲げてグループウェアを開発しています。自分たち自身のチームワークを高めるために、2016年にスクラムを導入しました。私の所属するkintone開発チームでは、スクラム導入から1年以上が経過し、新たに下記のような問題に直面していました。「チームが壊れないようスケールさせるにはどうすれば?」これらの問題を解消し、最高のプロダクトを目指すチームを作るために社外のスクラムマスター(@toshiotm)を巻き込んで、より良いスクラムの実践を探求してきました。1年間の実践を通じて、私たちのチームには以下のような特徴が現れました。スクラムマスターが不要になるこの1年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。StudyBeginner2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。どちらもSCRUM!全部SCRUM!規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。PracticeAdvancedhttps://www.youtube.com/watch?v=7xhxIYYMmTcチームがうまくいっていることはスクラムチームの大きな目標です。いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。Hourのタイムボックスを持つチームもあります。それらはたった数日で成されます。良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。PracticeBeginnerみなさんは楽しくふりかえりをできていますか?スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。場を作るためにどんなことをすればよいのか。ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。以下のことを中心にお話いたします。StudyIntermediatePairsを運用する株式会社エウレカでは2018年4月から、それまでの目的別スクラムチーム組織を変更し事業部全体でリアルカンバンを用いたプロダクトバックログの優先順位を忠実に消化できるチーム体制へ変更しました。このセッションでは4月から今までのリアルカンバン運用の軌跡についてお話しながら、つらみやうまく行ったこと、今後の展望などをご紹介したいと思います。StudyBeginnerどのようにするとより良いチーム開発ができるのでしょうか。いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。PracticeBeginnerチームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。このゲームは文字通り、心理的な効果を体験できます。ゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。したやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。どんな改善が見られるか、再度ゲームをやって試してみましょう。StudyIntermediateモバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった・開発業務中に運用業務の差し込みが入り、度々開発が中断していたこれらの根本課題に対処するため、以下を実施しました。本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。StudyBeginnerチームとして、良い『開発プロセス』を設計することは重要です。ROIを高めながら、どうやってプロダクトを『最速』でリリースし、仮説検証を『高速』で繰り返せるかを常に考える必要があります。概念におけるT2Mの部分『プロセスの見える化』と『ムダからの解放』です。SIPOC分析による『プロセスの見える化』の実現から分析プロセス。見える化することでわかる『ムダ』の解放をどのような工夫で行ってきたかをお話できればとおもいます。自分が言いたいことが相手の意見と対立しそうで、伝えなかった...。言ってもわかってもらえないと思ったので言わなかった...。このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった...。そんな体験はないでしょうか?自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。2018/10/19同ワークショップを企業で実施した時の記事が公開されました。StudyBeginner株式会社エス・エム・エスキャリアの辻岡です。弊社は人材紹介事業を主に、医療介護通じて働く人と日本を元気にする会社です。私は社内の人材紹介エージェント(キャリアパートナー)が利用する業務システムの開発を主に担当しています。2年半前に弊社に転職しました。入社当初配属された部署には以下の課題がありました。正社員が誰も実装してない。他の会社から来てくれる人数。リリースしてもトラブルがあっても殆どキャリアパートナーに連絡しないetc...YAMAZUMI(山積み)ある日1つのチームを持つことになりました。彼らにアジャイル手法を伝え続けてチームの輪が出来始めた頃。私は一人で抱えたチームのリーダーシップを一度捨てました。それをチームの輪の中に置きました。リーダーシップを一度捨てることで全員がオーナーシップを持って課題を乗り越えていくチームができた事例を紹介したいと思います。PracticeIntermediateチームがうまくなるために、「学習」と向き合うことはとても大切です。私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。ところが、最近新卒向けの研修に携わった際に衝撃を受けました。timeboxモブプログラミングプロトタイピングユーザーインタビューなどをまわしながら、3週間でプロダクトを作れるようになっていました。その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。彼らはプロダクトを本番リリースしたわけではありません。彼らは運用しながらお金を稼いでいるわけではありません。彼らはプロダクトづくりの経験をもっていませんでした。彼らはプログラミング経験ももっていませんでした。学習し続けていく中で固定観念に囚われてしまうことがあること学習をしていないことが圧倒的成長スピードを生むことがあることという事実に向き合う必要があります。学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。うまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。Patternsを使った問題解決の紹介するだけでなく、実際にそれを体感できるワークショップを開催させてもらおうと思います!多くの現場で有効なパターンを学ぶことで、明日の現場に役立つ方法を持ち帰ることができます。パターンとは既に実証済みの解決策パターンは建築家アレグザンダーの提唱した『パタン・ランゲージ』で挙げられており、パターンの構造は以下のようになっています。❝ある「文脈」で繰り返し起こる「問題」の「解決」する方法。私たちはそのパターンを通して、先人たちの知恵を学ぶことができます。パターンは時に知っていると思い込んでいる事に関しても新しい視点を与えてくれたり、改めて解決方法の目的の真意を思い起こさせたりします。そんなパターンを中心にみんなで問題を議論し、よりよい解決方法を見出したいと思っています。パターンを知らない人や、アジャイル開発初心者でも楽しめる場を提供したいと思います。1組4、5人で4組を想定しており、各チームに1人SPaTメンバーがフォローに入ります。PLoPのサイトがあります(英語)http://www.scrumplop.org※本セッションではSPaTが日本語訳したパターンカード(仮)を使用します。英語が苦手な方でも問題ありませんのでご安心下さい。StudyBeginnerサーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。読んでみましょう(RSGT2019までには日本語版が出ているはず)。「改善をしているはずだけどトラブルが起きてからの事後対処になっている」などの経験をしたことはありませんか。チームメンバを招集して、チームビルディングも儘ならないでプロジェクトを始めてしまって、後手後手にチームの仕事のルールを決めたり、メンバ同士の関係作りに時間を使うくらいなら、最初に『プロばこ』でワークショップをご体験ください!!フルバージョンで登場する「プロばこ」は、チームの作業プロセスのデザインと合意形成のフローを体験できるパワーアップしたワークショップです。2018では、QualityとDeliveryの2つを制約条件にチームの作業プロセスをデザインしました。フルバージョンでは、さらに2つの制約事項がチームの制約として追加されます。PracticeBeginner多くの組織では、うまく進めるためのショートカットやツールを求める傾向にありますが、足元が固まっていない状態でさまざまなプラクティスやツールを導入しても無意味で、混乱したまま成果も出せずに終わってしまうこともあります。そのような状態で大規模な開発を進めるのは自殺行為です。本セッションでは、アジャイル開発をうまく進めるために最低限考えなければいけないポイントをスクラムの文脈で紹介いたします。これらのポイントは多くのアジャイルコーチングの場において強く伝えていることです。StudyBeginner「もっとビジネスのスピードを上げたい」という課題意識があり、それの解決方法として「今までのやり方のままでは難しい。アジャイル開発手法を導入したい」と考える企業は多いです。いえ「さあ始めよう」とするにしても、関わる人のマインドや協力会社との関係性、とりまく環境などなど変えて行かなければならないことがたくさんある場合が多く、実際のところそれがなかなか大変だったりします。人も組織もなかなか急には変われないものですよねぇ。複数POが織りなす複雑なビジョン得られた成果やアジリティが見えないPOとDevチーム、SMのロケーションが別コミュニケーションしづらい座席レイアウトなどなど。このセッションではこのような課題を抱えつつもスクラムの実践に取り組み奮闘している現場のひとつをケーススタディとして、実際にどんな課題があり、スクラムチームやコーチがどのように取り組み解決を試みたのかの成功談や失敗談をみなさんの参考になるべく紹介したいと思います。先日までは開発チームに所属し、アジャイルな開発を目指していた私ですが、この頃はDevOps界隈にも足を突っ込み導入支援などを行っています。DevOpsという言葉は定義が明確でないこともあり、あまり好きな言葉ではありませんでした。結局アジャイルとほぼ同じだし、呼び方を変えたくらいのもんなんじゃないの?という気持ちもありました。この頃の変化DevOpsやアジャイルの導入支援を行うにつれて、この2つに少し差を感じ始めました。「DevOps」と「アジャイル」という言葉自体の差ではなく、相談してくれる方々が持つ「DevOpsのイメージ」と「アジャイル(Scrum)のイメージ」の差です。「DevOpsのイメージ」:価値を顧客に届けるためのワークフロー全体を改善する自動化ツールなど「Scrumのイメージ」:価値を顧客に届けるための「開発フェーズ」を改善する手法これは、Scrumは開発フェーズしか改善できず、DevOpsは全体を改善できる、と言いたいわけではありません。Scrumの実践者の中には企画やデリバリーと言った、俗に言う開発以外の領域もチームで実施している方もおられると思います。逆に開発のみに限定して実践されている方もおられると思います。共通する重要なポイントScrum、DevOps、どちらの呼び方をしたとしても、以下の気持ちは変わらないはずです。「早くフィードバックをもらいたい」この目的を達成するためには、開発フェーズのみに着目するのではなく、もう少し視野を広げる必要があるチームもあると思います。ConfEngine。