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

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

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

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

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

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

組織で初めてScrumに取り組んだ時によく出てくる話題の1つに"スクラムマスター"が出てきます。

理由は様々でしょうが、その1つに"これまでの組織の役割になかった"ということがありそうです。そのため、そもそもどんな目的なのか？なにをすればいいのか？なにはしないのか？などの疑問が湧いてくることあります。

このような疑問をうまく消化できないとスクラムマスターとして活動している人たちもスクラムチームも、そしてよりよいプロダクトを届け事業成長したい組織にとっても損失が生まれることもあります。

このセッションでは、そのような残念な結果にならないために、"スクラムマスターってなにをもたらすの？"というテーマでお話します。

Fun Done Learnが誕生してまもなく5年。

これを機に原点回帰してチームとして本質的にアジャイルであり続けることとはどういう意味なのか、そのためには何が大事なのか、そしてそれがどうFun Done Learnに繋がったのか、ふりかえります。Fun Done Learnで。

アジャイル開発の実践には「プロセス・チーム運営」に関するプラクティスだけでなく、「技術・ツール」に関する技術プラクティスも重要です。真正面から技術プラクティスの取り組みを取り上げ、良い知見を広く探求してきたいという思いからRegional Scrum Gathering Tokyo 2022で登壇機会をいただき、さらに登壇をきっかけに『アジャイルプラクティスガイドブック』という本を書く機会をいただきました。

書籍として形にしていく過程では色々なことを考える必要がありました。「アジャイル開発の技術プラクティスを扱った書籍は無いのか」「技術プラクティスをまとめた情報が少ないと感じる理由はどこにあるのか」「2023年に出版する書籍としてどの技術プラクティスを紹介するべきか」などなど。

本講演は書籍が出版されるまで1年半ほど技術プラクティスの整理に向き合うことでわかったことを紹介し、知見を体系立てて整理するために必要だと学んだことをお伝えします。

本セッションでは、プロダクトマネジメントのコーチをしているMoriyuyaがGPT4を用いて、自然言語を加工する構造を構築し、人には認知負荷の点で困難な多方面の仮説立案と検証を素早く行い、プロダクトに関する幅広い領域を明らかにし、プロダクト開発を高速にする方法を紹介します。

下記は、任意のユーザーに起きる問題の構造を出力するプロンプトの1つ*です。GPT4で動作し、ChatGPT PlusやBing**で試してみることができます。

ある当事者にとって重要な変数1を達成するための行動は、別の重要な変数2を達成するための行動と同時には実行できないとき、葛藤が生じます。この葛藤をジレンマといいます。

下記は人がジレンマ状態に陥った状況を明らかにし、解決するためのフレームワークです。深刻な状況下にあるロールモデルとして質問に対して典型的な回答をひとつずつしてください。

ロールモデル=新人プロダクトマネージャー
ロールモデルが困っている問題状況=プロダクト開発のストレスやコミュニケーションの不和がチームの士気を低下させ、プロダクトの質と開発速度が停滞している

A.困っている状況でロールモデルが仕方がなくしている典型的な行動を3つ推測し、それらの行動が現実に発生している可能性を0-100で評価し、最も評価の高い結果を選択してください
B.上記の、仕方がなくしている行動によって、ロールモデルが満たそうとしている重要な要望を3つあげ、3つからロールモデルにとっての価値を0-100で評価し、最も高い結果を選択してください
C.仕方がなくしている行動の一方で、ロールモデルが本当に取るべきだと考えている行動を3つあげ、効果の観点で0-100で評価し、最も高い結果を選択してください
D.ロールモデルにとって取るべきだと考えている行動によって、どのような重要な要望を満たそうとしているかを3つあげ、3つからロールモデルにとっての価値を0-100で評価し、最も高い結果を選択してください
E.上記のBとDの要望が両立すると、ロールモデルにとってどのような理想の状態が得られると考えているかを3つ推測し、0-100で評価し、もっともロールモデルとして理想に近いものを選び、必要があれば理想の表現としてふさわしいものに修正してください
F.上記のAとCの行動を同時にできずにロールモデルはジレンマの状況に陥っています。仕方が無く取っている行動と、本当は取るべきだと考えている行動が同時に実行できない原因を3つ推測し、0-100で評価し、その中から最も長期にわたって頻繁に生じる原因を選択してください
G.上記のAの行動をとった結果に引き起こされる、Dの要望の実現を最も長期にわたって脅かすことになる結果を3つ推測し、0-100で評価し、最も評価の高い結果を選択してください
H.一方で、本当は取るべきだと考えているCの行動によって引き起こされる、Bの要望の実現を最も長期にわたって脅かすことになる結果を3つ推測し、0-100で評価し、最も評価の高い結果を選択してください

補足
要望とは「健康である」や「スキルが高い」といった人が欲している状態をあらわした表現である。
行動とは、要望を実現するために行われる「ランニングをする」「本を買う」といった人の動きが伴った表現である。

 

これは自然言語で構築されていますが、一つ一つが認知負荷の高い質問となっています。回答を成形させると、次のようなストーリーが生成されます。

これは「新人プロダクトマネージャー」にとって、「プロダクト開発のストレスやコミュニケーションの問題がチームの士気を低下させ、プロダクトの質と開発速度が停滞している」という問題を表現したものである。

私たちのゴールである「チームが高い士気と連携でプロジェクトを円滑に進める」の実現のためには「プロジェクトの完了を確実にする」を満たす必要がある。この要望を満たすためには「チームメンバーにマイクロマネジメントを行う」という行動をする必要がある。
もう一方で、ゴールを実現するためには「チームの士気を向上させる」の要望も合わせて満たす必要がある。その要望を満たすためには「効果的なコミュニケーションスキルを身につける」という行動をする必要がある。

「プロジェクトの完了を確実にする」と「チームの士気を向上させる」の2つの要望を同時に満たすことによって「チームが高い士気と連携でプロジェクトを円滑に進める」を実現できるが、行動である「チームメンバーにマイクロマネジメントを行う」と「効果的なコミュニケーションスキルを身につける」は、「リーダーシップスキルの不足」のために同時には実行ができない。そのため「新人プロダクトマネージャー」にとって「ジレンマの状況」が引き起こされている。具体的には「チームメンバーのモチベーション低下」や「ロールモデルがコントロールを失う感覚」といった問題が引き起こされている。

この回答自体はそれほど目を見張る内容ではありません。重要なことはロールモデルと状況という2つを入力するだけで、様々な情報が引き出され、推論され、加工され、そして疲れることなく生成できるということです。

プロンプトエンジニアリングという生成AIに入力する文字列を工夫するテクニックが脚光を浴びています。これには大きく分けて2種類あります。ひとつは「step by step」のような推論の精度を上げるものです。もう一つはほしい回答そのものをデザインすることです。

前者の「ほしい回答の精度を上げる」ことに関しては時間が解決してくれるでしょう。しかし、後者の欲しい回答そのものをデザインすることは、価値そのもののデザインであるため、しばらくは人の仕事でしょう。生成AIとの対話を通してうまく行ったケースをプロンプトに加工する方法もありますが、冒頭のようなプロンプトをデザインするには時間がかかりすぎます。

冒頭のプロンプトはGPT4向けに加工していますが、元々はプロダクト開発をしていく上でユーザーを取りまく問題構造と因果関係を言語化するために私が人力で用いていた方法がベースとなっています。効果的ではありますが、プロダクト開発のチームにとっては認知負荷が高く、手軽に実践できるものではありませんでした。学習負担の大きなツールを学ぶことが目的ではなく、よりよいアウトカムをユーザーに届けることが目的ですから当然です。それが、GPT4であれば文句も言わずに淡々とこなすのです。

さて、プロダクト開発の状況をしましょう。新製品開発であっても、そのほとんどは既存の要素の組み合わせで、本当に新しい要素は限られています。

また、私たちはそれまでに培った知識や経験を元にプロダクト開発を進めます。ところが、人類の知識の全体は非常に幅広く、私たちは既存の知識のうちごく一部分にしか利用していません。そして学習しようにも、適切な学習対象を探したり、実際に学習するためには時間がかかるといったコストがかかるため、人類の知識の全体に対する情報量は極めて限られた状態がつづきます。

大規模言語モデルはGPT4になって精度が上がりました。大阪駅の美味しい居酒屋だったり、人の名前を聞いても多くが間違いを返しますが、十分な量かつ安定した情報であり、回答が正規分布として収束しているようなことには精度の高い回答を返します。

これまでをまとめると次のようになります。
・効果があるが、人の認知負荷の観点から実行できない方法がある
・新製品開発は既存製品の知識が大部分を占め、新しい要素は一部分である
・製品開発に利用できる人類の知識のうち、新製品開発の担当者が利用する知識はごく僅かであり、人が学習できる量は限られている
・十分な量かつ安定した情報に対してGPT4は高い精度で回答する

これらの性質を利用する方法が今回のセッションでお話しする内容です。その結果のひとつが冒頭のプロンプトになります。

本セッションでは、これまでよりも高速に仮説検証を行い、学習し、問題を特定し、現実からのフィードバックを得てサービスを展開するために、GPT4を自然言語ファクトリーとして活用する方法を紹介します。

*Bingではプロンプトの複雑さになると回答が拒否されるため、ここではどなたでも試せるようにBingで動作するライト版を掲載しています。
**Bingでは何回か回答させると「複雑すぎるから答えられない」と回答を拒否されるようになります。その時は時間を空けてお使いください。

このセッションは、2023年3月に突然「全ての開発チームにスクラムを導入する」というミッションを与えられた私が、どのようにして3ヶ月で全開発チームの6割強にスクラムの導入を達成したかを振り返りつつ、これからスクラムを始めたいと考えている方の道標となるようなTipsを提供することを目標としています。

スクラムはとてもシンプルなフレームワークです。役割を決め、イベントを設定し、タイムボックスを確定すれば走り出すことができます。しかし、ある程度の規模の開発組織で一斉にスクラムを始めようとすると、多くの場合は手痛く失敗すると言われています。0からスクラムを始めたい場合、私たちはどんなことに気をつけるべきなのでしょうか？

このセッションを通じてお伝えしたいのは、①小さく初めて成功体験をコツコツ積み重ねていくこと、②成功を根気強く周囲に宣伝していくこと、③チームが成長しているという実感を感じてもらうこと、の３つのポイントが、スクラムの立ち上げには不可欠であるということです。

実際に開発チームと協力してスクラムを0から立ち上げた私が、具体的なエピソードと共に、未来のスクラムを担うあなたに必ず役立つTipsをお伝えします！

このセッションで伝えたいこと

本セッションでは、製造業にアジャイルコーチとして入社したSatoshi Haradaが、社内アジャイル勉強会コミュニティの火を燃やすために何を考え・何をしているのか、可能な限り全部お見せしようと思います。

このセッションを見た方には、社内でアジャイル勉強会コミュニティを立ち上げた実例を知っていただきます。そして、社内アジャイルコミュニティを立ち上げよう・盛り上げようと思っている方に、コミュニティ活動はFUNが大事であることを知ってもらい、一歩目を踏み出す勇気を持って帰ってもらいます。

私が社内コミュニティ活動を開始した理由

現在の会社にアジャイルコーチとして入社して4カ月になりました。
勤めている会社は、創業150年・従業員数4500人超の国内製造業です。

この会社では既にDXやアジャイルといった取り組みが進んでおり、スクラムの研修開講やプロジェクトでのアジャイル適用が行われていました。素晴らしいことです。

この素晴らしい取り組みをさらに加速させるためには何が必要だろう？
そう考えた私は、もっと”FUN”が必要で、そのための社内コミュニティ活動の楽しい"場"が必要だと感じ、行動を始めました。

・社内のアジャイルコミュニティをもっと楽しく！さらに盛り上げたい！
・有志による楽しい学びの場を作りたい！

そんな気持ちで、社内のアジャイル勉強会コミュニティを自ら立ち上げて運営を開始したのです。

しかし、順風満帆・全てがうまくいっているわけではありません。
　勉強会に誰も来ない…
　盛り上がらない…
　運営が大変…
　自分だけが運営を頑張っているのかも？
そんなふうに思うときもありました。

そんなとき私は、「コミュニティ運営は焚火に似ている」と思うことにしています。
焚火は火をつけてからだんだんと太い薪に着火させて炎を大きくしていくのですが、その様がコミュニティ運営に似ていると思うのです。

そこで私は、社内アジャイル勉強会のコミュニティでいろいろな企画を投下してきました。焚火でも薪を投入する順番はよく考える必要があります。コミュニティ運営も同じです。
その結果、少しずつではあるのですがコミュニティ参加者が増え始め、勉強会の運営も参加者が主体的に関わってくれるようになってきています。

そして忘れてなはないのは”FUN”です。焚き火も楽しいですよね？コミュニティ活動にも楽しさは不可欠だと思うのです。

なぜこのセッションをやろうと思ったか

私の社内アジャイル勉強会コミュニティの立ち上げと運営はまだ4か月ですが、まだフレッシュな状態で私が何を考え・何をしてきたかを発表することで、同じように社内のコミュニティを盛り上げたい！と考えている人の背中を押すことができるのではないかと思いました。

社内でアジャイルを進めるにあたって、「仲間がほしい」「共通の話題で相談できる場所が欲しい」「学びを深めることができる場所が欲しい」と思ったことはありませんか？
もしまだそのような場がないという方、ぜひ自らそのような楽しい場を立ち上げましょう！

そのような一歩目を踏み出す方に勇気を持って帰ってもらえる焚火のようなセッションにしようと思います。

達人たちの推しの世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はもしかして、あの偉人？あの概念？からこの答えに辿り着いたのだろうか？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界しに対する思いを覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

今回は「プロダクトマネジメントの光と闇」をテーマにDeep Diveします。

過去のDeep Dive Expertsとトークテーマ

• Deep Dive Experts - 達人が見ている世界を覗いてみよう - @Scrum Fest Osaka 2021
  • スクラムとヨリを戻した時ってどんな時でしたか？
  • 過去や未来問わず。これは一番タフクエスチョンだな... と思った問いはなんですか？
  • スクラムに合ってる人、合ってない人、がいると思っております。スクラムに合っていない人がメンバーにいると思った時、どのような対応をしておりますか？
  • 皆さん様々な発明やアイデア出しをされ、同時に様々な勉強を日々されていると思いますが、日々の勉強をアイデアに繋げるまでの過程を知りたいです
  • いつから○○を拗らせましたか？
  • 当日のMURALはこちら
• Deep Dive Experts - 達人が見ている推しの世界を覗いてみよう - @Scrum Fest Osaka 2022
  • 心の底から本当にアジャイル推してるの？
  • みなさんのオシは何ですか？
  • お互いの推しポイントをDeep Dive目に推し合って欲しい！
  • 当日のMURALはこちら

マネジメント 3.0には、33の魅力的な楽しいツール、ゲーム、実践があります。
今回のミニワークショップでは、ストーリーを語る時にとてもパワフルな２つの「即興カード」を体験していただきます。物語として語ることは、普通に話をするよりも相手の心に響き、印象に残りやすくなります。
ストーリーテリングとは何か、相手に届く伝え方とは？
複雑な問題を解決するためのアプローチや、語る力を鍛えることで、どのように変化するのかをお伝えします。
普段はマネジメント3.0の即興カードを使いますが、今回は語ることの練習として、グループ内で面白いストーリーを作るのに適したカタルタを使います。
語り（ストーリーテリング）は、複雑な話題の説明や相手を説得する時、新しい洞察や過去の出来事とそこからの学び、変化を起こす時など、多くの場面で役立ちます。
優れたストーリーテリングのスキルは、ビジネスや日常生活のコミュニケーションにおいてとても重要です。
チームでの語りに最適なマネジメント 3.0 の即興カードとカタルタのストーリーテリングカード。
どちらもとても楽しく、すぐに実践できるカードなので、次の日からそれぞれの職場に合わせて使えます。ゲーミフィケーションを通して、２つのカードの魅力をお楽しみください。

即興カードの使い方

 ストーリーテリングを語ることは、最も古い情報伝達の方法であり、新しいアイデアを開花させる場でもあります。聴衆と効果的につながるために、語り手は即興で話をすることができなければなりません。生まれつきのストーリーテラーはほとんどおらず、マスターするにはかなりの練習が必要です。即興カードは、ストーリーテリングと即興のスキルを向上させるための素晴らしい練習方法です。また、チームビルディングにも最適です。 

このセッションは、プレゼンは少なめにし、体験をメインで行います。一緒に楽しみながら学びましょう。

スクラム開発うまくいってますか？

うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。

つまり守破離って大事ですよねと。

”スクラム　アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ！」と散々警鐘が鳴らされています。

そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。

例えば・・・

• エンジニアが3人未満のチーム構成
• 全員が他の開発業務を掛け持ち
• スプリントバックログが常に終わらない
• 不完全なインクリメントでスプリントレビュー
• デイリースクラムをやめる  ...etc

なぜ安直なアンチパターンを踏みまくったのか。

起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。

アンチパターンを踏みまくった結果、このチームやプロダクトはどうなってしまったのか。

スクラムアンチパターンを踏みまくったときの話をしようか。

受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました！が、JTCの荒波に揉まれる我々！

• 期待している形で案件が来ない！
• 支援って、ちゃんと評価されるのか？給料下がっちゃうんじゃないの？
• ３年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく！

毎年お送りしている田舎スクラムチームの状況をお伝えします！

自律的なチームになってほしい！という思いはマネージャーなら常に持っている共通の思いかと思います。が、難易度が高いとか納期が近いとかの仕事のプレッシャーからついつい自分がプレイングとして入ってみたり、過度にチームに指示をしたりで自律的なチームにならない原因を自分からつくっていることもあるのではないでしょうか。

unFIXとはそんな課題にフィットするかもしれない組織やチームのデザインのツールです。自律的な組織に見られるパタンをいくつか抽出したもので、「ベース」と呼ばれる母体に「クルー」と呼ばれる役割を持つチームが垂直水平（あるいはナナメ）に配置していくもので、なおかつ共通のテーブルでディスカッションできるくらいの分かりやすさやとっつきやすさも備えています。

今、私のチームではunFIXをつかって2チームいるセクションの体制を見直し、unFIXが定義するところの各クルーの役割に基づいて動いていく形で活動し始めています。

いわゆるマネージャーの役割は「ガバナンスクルー」であり、チームの役割は「バリューストリームクルー」と呼ばれています。このあたりは提唱者がヨーガン・アペロ氏ということもあり、少数のマネージャーがいわゆるガバナンス的なマネジメントを担い、他についてはチームがセルフマネジメントしていくという思想も入っているように感じられるところがあり、いい意味で「マネージャーとチームの間に線を引く」ことがしやすくなる性質があると感じています。

私のチームではこのあたりをどうやったか、私のチームがどうなったかをお話しできればと思います。

「プロポーザルを出してみたい」

そう思っても実際に提出に至ることができる人は多くありません。それは普通のことです。なぜならプロポーザルを書いて提出するという行為は自らが生み出したモノを人の目に触れる場所に曝け出すことであり、それはとても勇気のいることだからです。それでも私がプロポーザルを提出できたのはコミュニティの皆さんが背中を押してくれたからでした。

はじめてのプロポーザルを書き上げるまで

私が初めてプロポーザルを投稿したのはスクフェス福岡でした。そこで私は初めて参加したRSGT2023に会社の仲間たちと一緒に参加して学んだことについて書き綴りました。書きながら私はいくつもの「内なる悪魔の声」と戦いました。「別にこの話は会社の他の誰かがしても同じじゃない？」や「こんな個人的な話を聞きたい人なんて本当にいるの？」といった声が脳内に響き渡りました。

そういった自己否定の気持ちと戦い抜くことができたのは、RSGT2023で「初めてのプロポーザルで自信がないのでアドバイスをください」と発言したのがきっかけで「スクフェス福岡のプロポーザルを読んでYYする会」の存在を知ったからでした。そこに草稿でもプロポーザルを持ち込めばフィードバックをもらえる。その気持をモチベーションにしてなんとか書き上げました。

フィードバックに背中を押された

プロポーザルを読んでYYする会で書いてきたプロポーザルについての話をする中で私は本文に書かなかった色々な気持ちを自然と口にしていました。RSGTに参加するまではカンファレンスに参加する強い意志がなかったこと、誘われて初めて「みんなで行くなら......」と腰を上げることができたこと、頭取に言われるまでプロポーザルを書いてみようという発想すらなかったこと。そんな何気なく言葉として紡がれた「私のストーリー」を皆さんは拾い上げて「それそれ！」「その話が聞きたい！」と言ってくださいました。

そしてその時に一緒に初めてのプロポーザルを書いた烏帽子さんとおーのAさんにも、今度は私も同じようにプロポーザルを書くに至った経緯を聞く中で「ぜひそれを語って下さい！」と言う側になっていました。この時に私は「結論が一般的でも経験は唯一無二だ」ということ、そして「私が誰かをすごいと思ってもその人にとってはそれが普通で、私が自分を普通だと思ってもそれは誰かにとってはすごいことがある」ということを学びました。そうしてYY会で受け取ったフィードバックを元にプロポーザルのリファインメントをし、ありがたいことに採択していただき登壇することができました。

この経験を届けたい

スクフェス福岡に参加した後、その次のスクフェス新潟の情報について調べていく中で「テストやメンタルヘルス」といった私が個人的にとても興味のあるテーマを取り扱っていることを知りました。私は「そこでプロポーザルを書いて得た学びを共有したい！」と思い締め切りが迫る中プロポーザルを書き始めました。「スクフェス新潟のプロポーザルを読んでYYする会」の当日も無我夢中で書き続けて『「あなたすごい人、私ふつうの人」を乗り越える！経験をプロポーザルにしてみよう』の原案を投稿しました。

YYする会に間に合わせるために気合でなんとか最後まで書きましたがこの時も私は「プロポーザル書いたなんて話私じゃなくてもできるし......」「もっとすごい人がプロポーザルを書いてるし......」という気持ちに負けそうでした。でもいざYYする会でプロポーザルの話をしていると「ぜひ聞きたい！」という声や、より伝わるようにするための具体的なアドバイスをいただくことができて取り下げずにがんばろうと思うことができました。そして再び得たフィードバックを元にプロポーザルをリファインメントし、再度登壇の機会をいただくことができました。

何度でも伝えよう

嬉しいことに新潟での発表を見て「プロポーザルを書いてみよう」と勇気を出してくださった方々がスクフェス大阪にプロポーザルを書いてくださりました。そして「スクフェス大阪のプロポーザルを読んでYYする会」で背中を押してもらっている姿を見て「ああ、あの時勇気を出してプロポーザルを書いて良かった」と心の底から思いました。でも同時に「自分じゃなくてもいいんじゃないか」という感情はそう簡単に克服できることではないということを改めて痛感しました。とても素敵なストーリーを持っているのになかなかプロポーザルを書く手が進まない。であれば何度でもこの想いを伝えよう。「あなたの唯一無二の経験にはきっと価値があるはずだ」というメッセージを送り続けようと思いました。

経験をプロポーザルとして言語化している時に私がどういうアプローチを取っているのか。プロポーザルを書き切る為にどういうことを考えているのか。採択されるためにどういう書き方をするのがいいのか。スクフェス大阪に向けて改めてプロポーザルを書きながら気がついたことについても盛り込みつつできる限りの私の想いをぶつけます。

変化の激しいモバイルゲーム市場では、変化に適応してより良い体験をユーザーに届けることが必要です。エンジニアチームも柔軟に変化する状況に適応できるチームであることが求められます。例えば「特定の機能は特定の人しか触れない」属人化状態だと、その機能の改修要望がたくさん来たときに、その人がクリティカルパスになってしまいます。

若手リーダだった頃の私は変化に強いチームでありたいと考えたときに「私がリーダーなのだから、私が全ての変化をリードしないといけない」と考えていました。しかし、リーダーとして色々な取り組みをする過程で「リーダーだけではなくエンジニアチーム全員がリーダーシップを持つことが、変化に強くなるためのポイントである」と考え方が変わりました。

実際に変化を起こしていくのはリーダーではなくメンバーです。私たちのチームでは、個々人がリーダーシップを持ったエンジニアチームを起点として、プロダクトに良い影響を与える取り組みをしています。例えば、モブワークの取り組みを広げたり、非エンジニアの業務効率化ツールを自主的に作成したり、機能開発のやり方を少しずつ変えてみて高品質なアウトカムを模索したりしています。

本セッションでは、変化に適応するエンジニアチームとはどんなチームでなぜ必要なのか、そして、そのようなチームになるためにリーダー、またはエンジニアはどのようなことができるのかについてお話します。

RSGT2023で講演した「Effective Retrospective++～楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ～」の続編シリーズその①です。

RSGT2023で講演とともに公開した「ふりかえりナビ」では、ふりかえりの様々な成長段階に合わせた、段階ごとに次の一歩が踏み出せるようなTIPSを公開しました。
ふりかえりが初めての人にとっては、ふりかえりの目的や7つのステップなど初歩的な部分から学ぶことができますし、ふりかえりが慣れている人にとっては、ふりかえりの成長段階を見ることで、自分たちの次にチャレンジしてみたいアクションがきっとみつかるようなコンテンツになっています。

ふりかえりナビにて「ふりかえりの成長段階」として定義したのは以下の4つ。

• 黎明期 ：導入と探索。ふりかえりをまだ始めておらず、これから始める人や、ふりかえりをしたものの定着していないチームの段階。
• 過渡期 ：探索と繰り返し。ふりかえりを何度かやっていたが、効果がよくわからなかったり、見えていない時期。手探りの状態。
• 発展期 ：固定化と脱マンネリ。ふりかえりを何度も繰り返して、同じような意見ばかり見かけるようになってきたり、マンネリしていると感じる段階。その状態を抜け出そうとしている段階。
• 成熟期 :自由な発想と進化。マンネリを脱して、自分たちで新しいやり方を生み出そうとしている状態。より自由に、より独自性のあるふりかえり文化がチームから生まれていきます。

RSGTの中では、これらの成長段階を少しずつチェリーピックしてお話しましたが、今回は成長段階における最初期の「黎明期」にフォーカスして、その際によくある疑問や、それに対してどのようなアプローチをとるとよいか、を詳しくお話しします。

例えば、ふりかえりの黎明期に起こりがちな疑問は以下のようなものがあります。

• どの手法から始めればよいのでしょうか？
• チームメンバーが後ろ向きなのですが…
• POが忙しくてなかなか参加してくれません
• 忙しくてよくふりかえりがスキップされます
• 毎週ふりかえりをしたら話すことがなくなりませんか？

このセッションでは、これらの疑問を丁寧に解きほぐし、解説していきます。また、次の「過渡期」へと進むためのステップも提唱していきます。

このセッションは、ふりかえりをこれから始めたいと思っている人に向けて伝える、具体的なHOWが満載です。まただし、ふりかえりに慣れている人だとしても、基本に立ち戻るきっかけになったり、これからふりかえりを別のチームや組織に広げていくための力強い味方になってくれると信じています。

このセッションでは、リモート環境下での受託開発において、クライアントと一緒に[email protected]を活用し、ベトナムオフショアでスクラム開発を実践するチームとともに、私たちが直面した課題や学んだことをシェアします。以下のトピックを中心に、私たちの取り組みを紹介します。

- 受託開発で[email protected]に挑んだ私たちの物語
- リモートチームとして、ベトナムオフショアと一緒にスクラム開発を展開する経験
- チームトポロジーを活用して、より良いチーム分割を目指す私たちの試み
- 開発者の幸せを追求！DX(Developer eXperience)チームを立ち上げた取り組み
- DORA 4keysで見える化された開発生産性を向上させるための私たちのアプローチ

みなさん、組織を変えたいですか？
組織を変えるために熱い想いを抱いていますか？
あなたの情熱の炎は組織を変えられていますか？
情熱を燃やし続けることは苦しくないですか？

おそらく、ここに来て、このタイトルに惹かれたあなたは、これらの問いに「はい」と答えるでしょう。そんなあなたに私の経験談をお話ししたいと思います。

私の心が大きく燃え上がるまで

私は2022年からスクラム開発を組織に適用する活動を開始し、2022年中に3チームの立ち上げを行いました。
その頃、2022年末にエンジニア組織の大きな変更をトップダウンで実施され、メンバーと共に作り上げてきたチームを解体することが決定されました。

自律的な組織を目指すべくマネージャとして努力してきた私は深い悲しみを覚えました。

そして、年末年始を過ごし、私は思ったのです。
「もう辞めたい。こんな会社にいても自律的な組織は作れない」

そんな折、私はRSGTに参加しました。
「一体なんなんだ、この熱量は！？」

たくさんの人たちが同じような悩みを抱え、組織を変えるために努力している。では私は？
組織を変えるために十分にやってきたのだろうか。いや、私は足りない。情熱が足りないのだ。そう、

「心を燃やせ」

私の心は大きな炎となって燃え上がりました。
そして、組織を変えるべく、再び歩み始めたのです。

心を大きく燃やし続けろ、心の火を絶やさぬように

私の熱量は今はコミュニティからしか得られないのだ。

プロポーザルを出し、登壇し、たくさんのオンラインカンファレンス、コミュニティ、オフラインイベントなど。

RSGT後、私は心の炎を絶やさぬよう、さまざまなコミュニティに積極的に参加し続けました。

そして、たくさんの熱量を貰ってきました。

壁に当たるたび弱くなる炎

しかし、どうだろうか。もらってきた大きな熱量は大して長続きしない。

スクラムチームの開発が軌道に乗らなかったり、ステークホルダーとの調整がうまくいかなかったり。
冷静になって考えれば、そんなに大きな壁じゃないかもしれない。でも、私の心の炎は弱くなってしまう。

「やっぱり私には無理なんだろうか」

私は心も体もすぐに疲れてしまいました。組織を変える素質なんて無かった。私にはできない・・・

私に足りなかった心の燃やし方を知る

そんな頃、FEARLESS CHANGEの読書会に参加した私は自分の心の炎の燃やし方の間違いを知りました。

「燃え尽きないように細く長く燃える」

これが私に足りなかったことだ。

このセッションでは、私の体験を通じて知った、「心の燃やし方の間違い」と「組織を変える安心安全な心の燃やし方」、
そして、最後に燃え尽きないための心の燃やし方についてお話ししたいと思います。

※以下のnoteに関連するお話をします。

note:心を燃やせ ~その炎、本当に安全ですか？~「組織を変える安心安全な心の燃やし方」

スクラムへの愛を広めることに燃えていませんか？
社内のスクラムチームをさらに活性化させて一緒に学び、成長したいと思いませんか？

KDDIの社内スクラムコミュニティは、まさにそのような情熱と好奇心に満ちたメンバーたちが集まり、共に「もっと社内のスクラムを盛り上げていこう！」という目的で活動しています。本セッションでは、200人を超える社員が参加したスクラムフェス開催の裏側に隠された熱い想いと実践方法について語ります。

オンラインと現地会場のハイブリッド形式で開催したこのスクラムフェスでは、Talkセッションや、スクラムクイズ、Fun Done Learnのうたなど、学びと楽しみを同時に提供しました。ただ知識が得られる勉強会のような場ではなく、同じ組織の中で苦労したり工夫してる人たちから勇気をもらえたり、共感して仲間を作れたり、楽しさを感じてプロダクトや組織を変えていくモチベーションを得られる大きな営みとなりました。

スクラムを学び、深め、そして楽しむためのスクラムフェスを成功させるための秘訣を共有します。私たちの経験から得た知識とアイデアを参加者の皆さんと共有し、あなた自身の組織でも同様のイベントを開催するための具体的なヒントを提供します。

〜選手は体を鍛え技を磨くように、リーダーは言葉の力を磨く〜

各地で大変ご関心をいただいているペップトーク
今回は概要はきちんと押さえつつ、
簡単なワークショップを交えた形式で体験いただきます。

今まで気になっていた方も
初めて目にして気になった方も
ペップトークに触れてみませんか？

このセッションでは、
声がけからチームの本領発揮を引き出したり
自分や周りへの言葉の選び方だったりに役立つペップトークについて、
簡単な体験を通じてその日から使えるTipsをお持ち帰りいただきます。

＜ペップトークとは＞
アメリカで生まれた、スポーツの試合前で行われる
選手に向けた激励のショートスピーチから生まれて、
現在、教育やビジネスの現場でも活用されるようになってきた
自分や周りへの声がけのことを言います。

令和４年９月に発売された一冊の書籍「ゾンビスクラムサバイバルガイド〜健全なスクラムへの道〜」皆さんはもう読みましたか？

私はこの本を読んで多くのことに気付かされました。これは、今自分が置かれている環境じゃないか。気付かぬうちに、「ゾンビスクラム」になっていたとは。。。読み進めるにつれて、グサグサと突き刺さる内容。

• 縦割りのサイロ思考。ビジネスとITの分断。チーム内も役割で分断
  • ステークホルダーのニーズを知らない
• 「私たちにふりかえりなんていらないです」
  • 継続的に改善しない
• 与えられたタスクだけをこなす姿勢。当事者意識が欠如
  • 自己組織化をしない

読み終えた頃には、できていないことの後悔を通り越して、ガイドを参考に一刻でも早く何とかしたいと焦りました。もっと早くこの一冊に出会っていれば。

このセッションでは、私がスクラムマスターとして、開発メンバとして、経験/目の当たりにしてきた「ゾンビスクラム」に陥るパターンや予兆とそれらを生み出していた根本原因について、アンチパターンとともに紹介いたします。特に以下ポイントにフォーカスしていきます。

• 私たちが陥っていた症状と原因
• スクラムの本来の「目的」と私たちの誤解
• 私たちの「健全なスクラム」への道
• 銀の弾丸などない！？直ぐには治せないゾンビスクラムとの付き合い方

同じ悩みを抱える方々のご参考になれば幸いです。