17年間動かざること山の如しのちんも氏と、止まれないことまぐろの如し、転職を繰り返してきた藤村新氏、真逆の生き方をしながらも、それぞれがアジャイルを追い求めてきました。

「17年と13社、それぞれのアジャイル」

俺たちはどう生きたらいいの？感を若干交えつつ、

もがき挑み足掻く者二人の生き方・価値観の核心に迫ります。

モデレーターかいはらがライトな感じでお届けします。

スクフェスオーガナイザー川口恭伸が全国のスクフェスにズームイン！！

地域トラックの見どころを紹介しちゃいます！！！

朝から盛り上がっていきましょうね！！！

Confengineをながめながら、こう考えた。
智に働けば角が立つ。組織に棹させば流される。意地を通せば懲罰だ。とかくに人の世は住みにくい。
住みにくさが高じると、安い所へ引き越したくなる。どこへ越しても住みにくいと悟った時、体験談が生れて、笑いが出来る。
組織を作ったものは神でもなければ鬼でもない。やはり向う三軒両隣にちらちらするただの仲間である。ただの仲間が作った組織が住みにくいからとて、越す会社はあるまい。あれば人でなしの会社へ行くばかりだ。人でなしの会社は仲間が作った組織よりもなお住みにくかろう。
越す事のならぬ世が住みにくければ、住みにくい所をどれほどか、くつろげて、束の間の命を、束の間でも住みよくせねばならぬ。ここに雑談師という天職が出来て、ここに漫談師という使命が降る。あらゆるアジャイルの士は組織をのどかにし、人の心を豊かにするが故に尊とい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・大規模ウォーターフォールの受託開発のマネジメントを大阪で10数年ずっと実施していたマネージャーがアジャイルでのプロダクト開発組織を作るべく、辞令をもらいました。短期間でアジャイルを学ぶため、どのような事をどのように学んだか？その中で感じた葛藤と解決策をお話しします。

前半パートでは
新たな用語だらけで、ウォーターフォールとの文化の違いが今一つわからない中で、短期間で学習する上でのTipsをお伝えします。

中盤パートでは
「ちょっと何言っているかわかんない」というワードを使いながら、新しいことを学ぶ際にわからない事を前向きに増やしていく重要性とそのマインドセットのコツをお伝えします。

後半パートでは
学習すればするほど、先人のアジャイル先駆者やアジャイルネイティブの若い世代と比べてしまい、恥ずかしさや今までの仕事に対して後悔を感じたこと。逆に学べば学ぶほど自社内では先駆者として孤立してしまうこと
それらに対して、過去の経験をプラスに活かし、仲間と共にどのようにポジティブに乗り越えたかを説明します。

　DXでのリスキリングの必要性が謳われている昨今、リスキリング対象のミドル層が、これから、新規ビジネス創出やアジャイルに取り組む際にヒントになれば幸いです。

＜前半パート(短時間で学習するTips)の事例＞
・本を読み、勉強会資料を作り、勉強会実施を繰り返して机上で学ぶ（「アジャイル/本」の検索ワードでトップとなる）
・アジャイル先駆者との過去時点のDiffを取る
・コミュニティが怖かったところから、３ヵ月で150本コミュニティの参加ブログを書くに至った変化

＜中盤パート(学習のマインドセット)＞
・「ちょっと何言っているかわからない」を重視した学習方法（「完全に理解した」⇒「ちょっと何言っているかわからない」を素早く繰り返す)
・Majorityならではのアジャイルの入り方 (EarlyAdopterと違ってMajorityは効果の確実性を気にする)
・仮説検証型の学習方法

＜後半パート (ミドルとしての乗り越え方)＞
・会社生活、折り返してから始めたアジャイルと20年間の意味
・仲間と乗り越える
・仕事だから(外発的動機)とやりたい(内発的動機)をマッチできるのはミドルの特権
・これから始めるミドル層へのエール

（本セッションでは組織の変化よりお個人の変化に着目しての説明となります。実際にどんな風に組織が変化したかは興味があれば参考資料を確認ください)

私が開発者としてコードレビューをするのは「コードは自分のもの」という意識があるからです。その意識は自分の所属チームだけにおさまりません。別チームがメインで変更を行うコードにも及びます。

今回のセッションではこのモチベーションとそれに伴う行動に至った私の体験談をお伝えします。

私は Rakuten Rakuma の開発組織に所属しております。 Rakuten Rakuma は開発メンバーだけでも大規模な組織であり、複数のチームがいくつかのアプリケーションを開発、メンテナンスしています。 Rakuten Rakuma に join した当時、まだ組織の開発スタイルがよくわからないので、とりあえず、組織内の主要な repository を watch することにしました。 Rakuten Rakuma に join する前に所属していた組織では、「pull request は open されたら自分の手を止めてでもレビューするのが当たり前」というような環境にいた事もあり、 join したてでわからないなりにもレビューをしてみようと思ったのです。このようなきっかけで組織横断でコードレビューをしてみると、だんだんと以下のような気持ちを持つようになりました。

• ユーザーに影響するような変更がプロダクトに入るのかどうかを知りたい
• 将来、自分が関わるかもしれないからどのような変更が入るのか知っておきたい

こういったことを経てどうやら私には「コードは自分のもの」、別の言い方で言えば、オーナーシップという意識が芽生えてきたように思います。

「コードは自分のもの」という意識でコードレビューを行っていくと、コードの変更を自分ごととして考えるようになるので、より真剣にコードレビューをするのは想像に難くないと思います。そして、他のチームのコードが気になって仕方がなくなってきます。そういった経緯で今日も元気に組織横断コードレビューを行っております。

一人の開発者のプロダクト開発への取り組み方を、楽しんでみてください。

現所属会社に転職後（半年前）、すぐにプロダクトチームの立ち上げを任していただくことになりました。

決まっていたのは「こんな感じのものを作る」ということと、メンバー二人だけ。

持っていたのは「やるんだったら最初から全力でアジャイル開発に取り組んで最速でアプリリリースをしたい」という情熱だけ。

転職前まではウォーターフォール開発しかやったことが無く、「アジャイル開発ってこんな感じなのかなー」と妄想していた妄想癖なPMが、実際にスクラムを通じてプロダクトを社内リリースまでこぎ着けたお話をしたいと思います。

「なかなか人集まらないねー…」

「そうかー、めちゃくちゃウォーターフォール脳だったわー」

「なんだか楽しそうですね？」

3か月が準備、その後3か月のスクラムの話ですが、それでも自分自身にとってはとても濃い半年でした。

このお話は、決して成功体験や高次元な概念やシステム、プロセスの説明ではなく、ただ単にイチ開発者がスクラムに触れて、これから成功したいと思う、失敗だらけのお話です。

だが、情熱はある。

背景

スクラムマスターという肩書を持って働いていた私。
4~5年経って気がついたのはスクラムマスターとはなにか？
価値を言語化できないまま、なんとなく過ごしていた事実だった。
組織にたいしてどう振る舞うべきなのか？答えられる自信はなかった。

なんとなく時間を過ごしてしまう環境に疑問を持った私は迷った。
全社的にスクラムが導入され、アジャイルなマインドがあるメンバーがいる環境。
ちゃんと専任となるスクラムマスターが認められた環境がある環境。
そんな環境で自分の中のスクラムマスターの価値を、自分の言葉で言えるようになりたい。
打席に立ちたいと思って転職を決意した。

しかし、入社して頑張り始めた時、チームから返ってきたのは入社前には想像もしていなかった反応だった。

メンバーから、
「スクラムマスターって必要ないよね？」 と聞かれているような質問だったり、
「スクラムマスターがいない現場になんて行きたくない！って言う人なんているの？どうなればそう思えるようになるの？」
といった、スクラムマスターの存在意義を問う、気軽で率直な疑問がほどんどだった。

本当に困った。私はこの環境で望まれていないかもしれない。
そう思って苦しみながら足掻いて足掻いていたら、天が強い仲間を送ってくれた。

それから毎日のように、一緒に泣いたり笑ったりしながら作り出した変化を発表してみようと思います。

この発表の目的や理由

実際にチームや組織を良くしたいと思って奮闘した時の、つらみや苦しみ
その中で気をつけたこと、上手く行った時の感動などを共有することで、
これからチャレンジしたり、今ちょうど同じようなチャレンジをする人の参考になったり、勇気が持てる様なことが伝えれたらいいな。
なんでもいいから、役に立てばいいなと思って発表しようと思いました。

また私たちのチームの活動を通して、他のチームの方から、より良い活動など教えて頂いたり議論出来るようになれたら嬉しいと思っています。

登壇者について

• 兼平裕美　しがないまよいぶた
• 笹尾納勇仁 : 本発表のサポート役

サポート役は本当にサポートのみとなる予定です。
視聴者からご要望があれば質問にはどちらの立場からでも回答可能となる予定です。

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

また「話題になっているからChatGPTを使ってみたけど、うまく使えなくて、使わなくなってしまった」という状況の理解を通して、新しい道具との関わり方を示します。

----

下記は、任意のユーザーに起きる問題の構造を出力するプロンプトの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」のような推論の精度を上げるものです。もう一つはほしい回答そのものをデザインすることです。

前者の「回答の精度向上」は時間が解決してくれるでしょう。しかし、後者の欲しい回答そのものをデザインすることは、価値のデザインです。使う人が的確に設計する必要があります。

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

さて、プロダクト開発の状況の話をしましょう。

新製品開発であっても、そのほとんどはよく知られた要素を追加したり、知られた要素の組み合わせで、本当に新しい要素は限られています。

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

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

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

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

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

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

Bingでも動作した例

Bingで動作しなかった例

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

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

事例紹介：

コロナになる3年前によい組織づくりの３人からなるチームが1万人以上のグループ従業員に対してセルフマネジメントのサービスを開始した。どこまでできるか実験的なアプローチである。イントラネットの中に自分たちでできるファシリテーションの道具を用意し、各組織の担当者がダウンロードコンテンツを用意した。セルフどこまでのファシリテーションができるかの壮大な実験である。

・WHYなぜ、このようなことをはじめたのか？　
　なぜ組織開発チームが求められたのか　
　それは大企業病に蝕まれていたから　外資系企業には機能として存在するのに私たちには何故ないのか
　天の声

・WHAT　何が起こったのか？　素人同然のメンバー3人で始めよと無茶振り

・どんな道具があるのか、斬新なモデルでどんなことが展開できるか、どんな成果があるのか可能性を知る

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

このセッションでは、説明下手なのにファーストペンギンをしている自分が、３種類の「やってみせる」をうまく活用してフットワークが重い人を巻き込んできた経験を共有することで、説明下手で人をうまく巻き込めない人たちの伝え方が変わる一歩を踏み出せる時間にしたいと考えています。

内容

全世界のみなさま、こんにちはこんばんは、やたです。普段はクリエーションラインという会社で開発者をしています。

これまでの背景

もともと自分はとある大企業の新卒としてはじまり、新卒研修としてRSGTやスクラムフェスで登壇するような人たちから学ぶ実践形式の研修を通じてかっこいいチームへの憧れやアジャイル開発に興味を持つようになりました。それから数年の間、スクラムフェスやRSGTなど現地のイベントなどに参加していたのですが、もっとお客さんやさまざまなロールの開発者と近い距離感で仕事をしたいと思い、今の会社で働いています。

社内の開発者の仲間を増やす活動に取り組んでいます

ただ、今の会社ではアジャイルコーチやスクラムマスターは多数在籍しているものの、開発者としてアジリティ高く仕事ができる人はまだまだ多いわけではなく、チームによっては1週間に1回しか全員で顔を合わせず、お隣さんのエンジニアが何をやっているかまったくわからないなんてチームも存在します。

そのような状況下でいくつかチームを渡りながら開発者の仲間を増やす活動を現在進行形で続けています。具体的には、t_wadaさんを会社に招いて講演（質とスピード）をしてもらったり、自分が新しいプロジェクトに入るたびにユニットテストの導入やモブプロに巻き込んだりして地道に変化を起こす取り組みを続けています。

結果として、必ずしも自分が変えたとは言い切れませんが、自分がチームから過ぎ去った後もユニットテストが増え続けてテストがレガシーコードが減っていたり、デイリースクラムが続いていたりしています。

３種類の「やってみせる」を活用しています

開発者に対しての普及活動を続けていく中で、ちょっと一緒にやってみません？ということでも拒否反応を示す人もいます。自分の経験上、そういう人の特徴は大体以下の２パターンに分類されてきます。

• アジャイル開発や関連するプラクティスに関して全く知らない
• どこかでアジャイル開発とかに苦い経験がある

そういう人たちに対してできることは、良さをちゃんと実感してもらえるように説明したり、苦い経験からくる誤解を解いてあげることだと思います。しかし、自分自身は社外にも名が知られているようなプロフェッショナルでもないので説得力に欠けますし、そもそも自分は言語化や説明が得意ではないので難しいものがありました。

だからこそ、自分の場合は３種類の「やってみせる」をうまく活用しています。

• 自分でやったものをそのままみせる
• デモしながら説明する
• ペアしながら答えをみせる

やってみせる上での大事なポイント

やってみせるの大事なポイントは巻き込む人の原体験を塗り替える・作るつもりで「やってみせる」という点です。

その点を意識するだけでも以下の効果があります。

• 興味を持ってもらう確率は高まって、そこから一緒にやる方向に繋げやすい
• 巻き込んだ人たちは自分がいなくなった後でもちゃんと続く確率が高まる
• たとえその時はうまく巻き込めなくても、その後の違ったファーストペンギンを助ける要因になる

もしあなたが、「スクラムマスターって何？」と聞かれたらどう答えますか？

• サーバントリーダー
• スクラムを確立する人
• チームの障害を（チームとして）取り除く人

他にもいろいろな回答があるかもしれません。

この問いは、スクラムマスターにとって、とても重要だと考えています。自分の中にあるスクラムマスター像は、スクラムマスター自身のパフォーマンスに影響します。なぜなら、スクラムマスターの明確なタスクはどこにも定義されておらず、自分の知識・経験・考え・イメージで定めていくしかないからです。

僕は、認定スクラムマスターのトレーニングで聞いた「プロダクトオーナーと開発者が責務をまっとうできる確率を最大化する人」がとてもしっくりきています。

この概念をより深めていくと、「情報を巡らせる人」になるのではないかと考えています。

これは、書籍『リーダシップとニューサイエンス』を読んでいて感じたことです。同書によると、組織のシステムを改善する上で重視すべきなのは、「アイデンティティの共有」、「新しい情報の共有」、「システム内のどこの人とも関係を築けること」の3つだそうです。

この「情報の共有」が、スクラムマスターの中核ではないでしょうか。

他にもたくさんあると思いますが、僕のイメージする「情報」の例は下記です。

• プロダクトの情報
  • 予算
  • 成功の指標
  • ユーザの課題
  • 課題を解決するソリューション
• チームの情報
  • 進捗
  • 生産性
  • Four Keys
  • プロダクトバックログ
• 個人の情報
  • 役割
  • 期待
  • 願い
  • スキル

このような情報のひとつひとつが、スクラムチームのひとりひとりが責務をまっとうすることにつながります。なぜなら、日々の活動において個々人で意思決定して進んでいくためには、情報が必要だからです。

本プロポーザルでは、「情報の共有」という視点からスクラムを考えます。そして、「情報を巡らせる人」をスクラムマスター像のひとつとして提案します。

我々は社内のアジャイル推進活動をアジャイルな働き方で進めています。
活動当初は組織で決められた目標・計画が正で、それを遵守する働き方をしていました。
しかし、状況は常に変化して達成できないことも多々発生、、、
「それってそもそもアジャイルなんだろうか？変化に柔軟に対応するのがアジャイルなのに」
そんなメンバーのモヤモヤの原因は、
     組織の運営が「従来型」、現場の仕事の進め方が「アジャイル」
このすれ違いにありました。

そこで、組織の運営自体もアジャイルにすることにトライしました。

・チームのスプリント（１週間）に加え、組織運営のスプリント（四半期）を導入する
・組織は、組織目標を提示するが、何をどう達成するかはチームの判断を尊重する
・年間および四半期の計画は、チームメンバー全員で作り、年間ゴール・四半期ゴールを決めて合意する
・組織もチームも、状況の変化を受け入れる。ゴール達成よりも、提供できる最大限の価値を重視する

今も改善を繰り返しながら、変化に柔軟で自律的なチームに向かっている最中です。
我々の試行錯誤の取り組みをお伝えすることで、皆さんの組織運営をよりよくするヒントになればうれしいです。

私の経験した、２つの新しいスクラムチームの立ち上げにエンジニアリングマネージャがチームと伴走する上で、良かったこと、悪かったことを紹介し、
エンジニアリングマネージャ、あるいは組織をリードする立場の方が気をつけるべきサポートの方法について知るセッションです。

---

私は株式会社Specteeでエンジニアリングマネージャー（以下EM）をしています。
弊社は2022年に社員数100人を超え、100人の壁を越えるために組織一同努力しています。

スクフェス福岡2023の「ゼロからスクラムを推進したスクラムマスターがラスボスゾンビEMになるまでの失敗と心の中」続編になります。

スクラムチームを去ることを決めた私はチームと伴走することを決めました。
特に重要視したのが1on1。メンバー数は9名、週1回 30分。
チームに直接関与する時間を減らす一方で、1on1での間接的な関与の時間を増やすことで、スクラムチームを支援しました。

しかし、一方のチームが軌道に乗るサポートは順調に、もう一方のチームでは難航。

その後、一方のチームへはスプリントイベントへの参加することで、直接的に関与する時間を増やし、結果的にチームが軌道に乗ることができました。

チームの支援として「何が良い取り組みだったのか」、「何が悪い取り組み」だったのか、この活動で得られたことについてお話しいたします。

スクラムチームの成長の向き先はどこなのか。スクラムガイドに載っていることを愚直に追い続ければよいのか。スクラムを実践することは大切で困難なことだ。一方で、もっとプロダクトチームとしての成長に目を向けてもいいのかも。でもどうやって…

スクラムチームをどう支援していくか悩んでいた中、私は書籍『EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ』からそのヒントを得ました。

この書籍ではプロダクトマネージャーを評価するための分類として、「人・プロセス・プロダクト」の3つの柱が取り上げられています。そして、この柱を軸にすればプロダクトデザイナーやテックリード向けにもアレンジが可能とされています。

「この柱はプロダクトチームにも応用できる！」

このセッションでは、「人・プロセス・プロダクト」の三本柱をスクラムチームの支援にどう適用していくのかを発表します。そして、実際にどんな支援を行うことで”いい感じ”のスクラムチームに成長してきたのかを共有していきたいと思っています。

きっといろいろな軸でチームの支援をしている方がいると思うので、このセッションを踏み台にして、いろいろな軸を教えてもらえたら嬉しいです。