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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私達について

私達は楽天グループでラクマというフリマアプリを開発する部署に所属しているSoftware Engineerでして、主に広告や事業者向けの機能を開発しています。

ラクマは現在楽天グループが運営・開発しておりますが、前身は日本初のフリマアプリ「フリル」でして現在は3500万ダウンロードされております。

私達3人は同じチームに所属しているのですが（マネージャーを含めると4名体制です）、基本的に毎日始業から終業までをほぼモブプログラミング・モブワークをしています。（以下モブワークと総称します）

チームとしてもScrumを取り入れていて、ほぼ全てのバックログをチームで取り組んでおり究極の一個流しをチームで実現させようとしています。

毎朝Daily Scrumでその日に取り組む事を皆で話し合って決め、そこから途中こまめに休憩を挟みつつ基本1日中終業までモブワークを行っています。

これまではリモートで仕事をすることが中心だったので、Zoomを繋げっぱなしにしつつコードシェアをしながら役割を10分タイマーで交代しながらモブワークをしています。

コロナが落ち着いてきて関係で楽天では出社が増えてきておりまして、全員出社してる時は一つの場所に集まって同じ画面を見ながらワイワイモブワークをしています。

モブの皆さんと呼ばれるまで

私達は今組織の中で「モブの皆さん」と呼ばれています。

これは個人としてではなく、チームとしてモブワークを実践してきた事が周りの皆様にも認知してもらっている結果だと思っています。

ですがチームが出来た1年半ほど前はそんな事は全くなくて、発足当初はメンバーの4名中2名が入社したばかりでRails経験が浅い状態かつOJT中だったのもあってか、多くの課題を抱えていました。

• 業務の量に偏りがある
• レビュアーがいない
• さらに育成者もいない

そしてリモートワークが長引いていた関係で、メンバーの一人一人が不安を抱えながら開発をしていたという状況にもなっていました。

そんな状況を見て当時のマネージャーがモブワークを取り入れてみることを勧めてくれました。

そこからおよそ一年半、チームメンバーが減ったり、新しく増えたりなど色んな歴史を経て今に至っています。

途中チーム外の方から「分担作業の方が良くない？」というご意見をいただいてうまくチームとして方針を伝えられなかった事がありましたが、その時はマネージャーが間に入って盾となってくれて色々と関係各所との調整を行ってくれました。

試練の訪れと振り返りのきっかけ

そんな私達に大きな衝撃が走ったのは、私達にモブワークを導入して支援してくれ、チームの文化を築いてくれたマネージャーの退職が決まった時です。

当たり前の事なのですが盾となってくれていたマネージャーがいなくなった事で「これからは自分達で戦っていかないといけない」となり、改めて「私達はなんでモブワークをしているんだっけ、なんで良いと思ってるんだっけ」と考えさせられました。

そこからモブワークについて改めて調べ直し、言語化していく中で他チームから「モブワークについて教えてほしい」と言われる事が増えてきました。

自分達では何かを教えられるほどモブワークについて上達したつもりはなかったのですが、それでも通ってきた悩みや良かったことを共有することで双方で学びや発見がたくさんある事に気付けました。

これからの私達

現在絶賛トライ中なのが「目標設定とモブワーク」の問題です。

私たちも会社員ですので、目標設定とその評価というビッグイベントから逃れることはできません。

チームとしてタスクを成し遂げるのに、目標を立て評価をされるのは個人単位です。

これにどう向き合っていくのが良いのでしょうか。

今季の目標設定では「チームとして共通の目標を作ってそれを個人目標に組み込む」という新しいアプローチを試みています。

これはマネージャーと相談して、チームでのモブ活動に対して理解してもらおうと試みた一例になりますので、皆さんに紹介したいと思っています。

今回のセッションでは以上のような私たちのモブワークの歴史を共有いたします。何かの発見や学びに繋がったら幸いです。

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

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

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

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

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

例えば・・・

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

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

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

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

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

鹿児島の中学生に紙飛行機ワークショップを、

鹿児島の高校生にマシュマロチャレンジを、

それぞれスクラムを知ってもらうワークを実施予定です（5月と6月に）

ワークを通して感じたこと、ホットな情報をお話しできればと思います！

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

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

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

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

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

チームが何かに夢中になると俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいがちです。目の前のタスクに集中すればするほど近視眼的になってしまうのです。そういう経験はありませんか？

僕は以前プレイングマネージャーをしていたことがありますが、成功させたい！と想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまうようなこともありました。

もう同じ過ちは繰り返したくない！専任スクラムマスターをすることになったのを機に「俯瞰して観る」ことを大切にしています。

スクラムはリーン思考に基づいており、スクラムガイド2020には「ムダを省き、本質に集中する」と書かいてあります。それって、マインドフルネスの「雑念を脇に置いておき、イマココに集中する」と同じでは？スクラムはチームでマインドフルネスをすることなのでは！と僕は解釈しこれまでスクラムマスターをしてきました。

日々の様々な活動の中でマインドフルネスを意識することで、雑念に囚われることなく、ムリ／ムダ／ムラをなくし、より良い活動ができるようになったと実感しています。その甲斐あってチームからも「俯瞰して観てくれて助かります」という声が何度かありました。この知見をみなさんと共有したいです。

※毎日瞑想しましょう！というお話ではありません

Scrum Festに参加する多くの方は、複数人でチームを組んで仕事をしていると思います。
また、所属するチームの外側には様々なチームがあり、複数のチームで構成される大きな組織の一員として働いている方が多いと思います。

そういった様々な人々が関わる中で仕事をしていると発生してくるものが「悩み」です。例えばこのようなものです。

お悩み例

• なんでうちの上司はペアプロの良さを理解してくれないんだろ…
• お偉いさんと営業が勝手にお客さんと約束してきちゃったけど…どうすんのこれ？
• 会社の方針が分かりづらいし、みんなバラバラに動いてる気がするんだよなぁ…

このような状況に身を置くのはツラいものです。ツラい環境にいるのは居心地が悪く、ストレスも溜まりやすいため、いくつかの反応を行います。

• 私は関係ない、どうでもいいや、と割り切る
• 自分1人でもできそうなことをやってみる
• 自分の意見をぶつける、愚痴を言う
• どこか違う組織に移る

悩んだ時に、どんなことを考え、どんなアクションを取るかは非常に重要です。うまくいけば悩みが小さくなったり解決することができます。

しかし、落とし穴もあります。悩みを解決できる、もしくは悩みを感じなくなるような良さそうなアクションを取った結果、長期的には悩みが肥大化することがあります。肥大化が進み、悩みがモンスターに育ってしまうと周りの人も自分自身も傷つけてしまいます。

私も過去に色々やっちまった経験があります。今になってはいい経験ですが、その時は「こんちくしょー！」と思ったものです。そういった経験から、悩みとの付き合い方を学び、悩みが育っていかない体になって来ました。今は悩みとか全然なさそうと良く言われますし、Scrum Fest 札幌ではこんなセッションをやったりしています。

本セッションでは、私の元気な話は置いといて、悩んでいた過去の話、そこから学んだこと、今悩みを抱えた時にどう捉えどう考えどう行動しているか、をお話しします。皆さんがお持ちの小さな悩みがモンスター化するのを防ぎ、皆さん自身も、周りの人も少しでもハッピーになることを期待してます！

「観察さえ上手くなれば、もっとチームのことを理解できるはずだ！」

以前の私は、そう考えていました、、、

このセッションでは、人類学のゼミに参加した経験をもとに、人類学的視点がどのようにチーム支援に役立つかをお話します。

支援する立場として感じた効果は、下記のようなものです。

• チームメンバーと向き合い、チームで起きていることに気がつくことがよりできるようになる
• チームで起きていることに向き合い、受け入れることができるようになる
• 自分の持っている思考の偏りやフィルターに自覚的になることができる

また、チームの支援を行う立場にいなくても、自分のいるチームをより良くしたいと思う人が、実際に働きかけを行う時に人類学的視点がどのように効果を発揮するか、私の経験をもとにお話ししたいと思います。

自分のいるチームをより良くしたいと思う立場として感じた効果は、下記のようなものです。

• 始めるべき難しい会話を始める勇気が出る
• 相手と分かり合えない状況になった時に、その場への向き合い方を持ちやすくなる
• 対話を避けるのではなく、小さく対話(会話)から始める動機が持てる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G.O.O.D.テストとは何か？そして、なぜそれが誰にとっても大切なのか？

テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか？コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか？もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか？

もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

• G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。（Give）
• O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。（Observe）
• O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く（Open）
• D：エンドユーザーに対する安全性（例えば、プライバシー、セキュリティ、機密性）など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。（Determine）

特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか？

システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

G.O.O.D.のテストをしていますか？それともただのテストですか？

鳥取県に縁のある人あつまれ！

The biggest challenge for organizations is adapting fast enough before smaller, nimble competitors take their market. Creating an outcome-driven organization is about aligning every aspect of the business toward achieving the outcomes that matter. It requires a shift in mindset, processes, and culture. Gabrielle Benefield, with her vast experience in guiding organizations through Outcome Delivery for the enterprise, will delve into the essential principles and practices necessary to drive successful outcomes. 

スクラムフレームワークに沿ってイベントをこなしながらプロダクトを作る。

一般的なスクラム開発を進める中で、ふと違和感を持ったことありませんか？

「ウォーターフォール開発を短期間で分割して開発してるだけでは・・」

「ラグビーチームのような一体感を持ったイメージと何か違う・・」

私がスクラムマスターを担当した ”とあるチーム”も、上記のようにスクラムを淡々とこなしているチームでした。

プロダクトの価値やチームの成長について熱く語るようなチームになって欲しいと願い、スクラムマスターの立場から色々とチームに働きかけても変化を起こせずにいました。

そんなある日、ちょっとしたことがきっかけでチームが生まれ変わりました。

それはチーム内から起きた内発的動機付けによるものでした。

生まれ変わったチームは、優れたプロダクト体験・機能を素早く届けることにこだわり、メンバー間が相互のタスクに興味を持って助けあい、スプリントゴールを懸命に追いかけるようになりました。

振り返ると劇的な変化が起きたので、他チームでも活用できるようにいつか情報を整理したいと思っていました。

今回の発表はちょうど良い機会なので、チームを変えた内発的動機付けについて考察のうえ言語化したいと思います。