アジャイルでは、なぜ支援者がトレーナーではなくコーチなのか？
どっかに引っかかりを感じながら、でも、なんとなく見ないふりをして、アジャイルコーチのマネごとをしてきました。
アジャイル支援サービスを構築して、販売して、徐々にお客さんからも評価いただくうちに、
自分がやっていることが本当にアジャイルコーチなのかに自信を持てなくなってきました。

ある日、流石に見ないふりが苦しくなって、
コーチを探し始めたら、わざわざ時間をとってたくさんのコミュニティの仲間が相談に乗ってくれて
スーパーコーチのAkiさんにたどり着きました。

現時点では導入となる6回のセッションが終わった段階、
旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

※発表内容は個人の主張・主観であり、所属している組織とは関係ないものになります

スプリントプランニングってどうやってやったらいいか、モヤモヤしていませんか？

スクラムガイドを読んで、又は認定トレーニングを受けていざスクラムやっていこう！となったとき、実際にやってみると具体的にはどうやって進めたらいいかわからない、ということがスクラムには多いのではないかと思います。

「プロダクトバックログってどうやって作るの？」とか「自己組織化って何から始めたら？」とか「Doneの定義って具体的に何？」とかいろいろありますが、中でもワカラナイ代表の一つとしてあげられるのが「スプリントプランニングってどうやるの？」じゃないかなと思っています。

私自身もトレーニングを受けてから見様見真似でスプリントプランニングをやっていましたが、
「今までやってたWBSと何が違うんだ」
「タスクってどの単位で切るの？細かくするにも限界が・・・」
「なんかしっくり来ないな」
という感じでモヤモヤしていました。

それでもなんとか試行錯誤を繰り返していたら、チームの学びとして一つのやり方が確立できてきて、スプリントプランニングの役割もなんとなくしっくりきたな、と思えるようになったので、そのあたりを共有していきます。

これが全てではないけれど、きっと誰かの参考になるだろうと思います！

2010年にフロリダで開催されたAgile conferenceに参加していらい、「よりアジャイルなチームを作るためには？」を考え続けてきたようにおもいます。僕の関心は常に「アジャイル開発」です。

当初は企業内のアジャイルチームとして活動し、のちにアジャイルコーチと名乗るようになり、開発現場に立ったり、チームや組織開発を考えたり、「どうやったらもっとアジャイルになるか」を考え続けてきましたが、今もアジャイルコーチとして新しい現場に立つたびに、10年前と変わらず悩み続けています。

10年の経験を得て、これまでにできてきたこと、まだできていないことをふりかえりながら、次の10年をスーパーアジャイルコーチとして現場を成功させ、その次の10年でウルトラアジャイルコーチとして過ごすために必要なことを考えるセッションです。

完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員（＋希望者は誰でも）向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

こちらのセッションでは、サイボウズ社内で実施している研修（講義）を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

皆様は、組織でスクラムマスターをお願いするときに困ったりしていませんか？
また、スクラムマスターが、成長していると感じますか？

多くのチームの見てきましたが、スクラムマスターの任命時から育成において
うまく仕組みが作れている組織はあまりありません。

スクラムマスターの任命にうまくいかなかったり、育てられないと、
スクラムチームのアウトプット・アウトカムの向上がすごく遠回りになってしまいます。

そこで、これまで私が実施してきた方法を学習科学の観点から解説しながら、
スクラムマスターとしての任命から育成の方法について紹介します。

特にこの数年、日本の受託開発でもアジャイル手法が普及してきている実感はあります。しかし一方、アジャイル受託開発を、日々の当たり前として定着させる難しさも見えてきました。「顧客との関係」「メンバーの育成」「事業の成長」、これらはそれぞれ長い目で取り組む必要があり、かつ相互にトレードオフを含む適応的な課題でもあります。

例えば、次のようなシチュエーションにどのように対応すると良いでしょうか。

• 本来なら受けがたい一括請負によるアジャイル開発を将来有望な顧客から求められたら？
• プロジェクトがピンチ！火消しをすべきなの？チームにまかせるべき？
• ウォーターフォールとのハイブリッドの是非について顧客とメンバーの意見が合わないのをどうすれば？

このセッションでは、受託アジャイル開発を生業とする私たちが、成功や失敗の体験を分析することでたどり着いた「アジャイル開発の組織定着に向けた一つの型」を提示させていただきます。私の立場上、どうしても受注側の視点がメインとなってしまいますが、発注側の方にとっても、ヒントになることは多いかと思います。

アジャイル開発に興味のあるみなさん、どうやって学んでいますか?

XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?

そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。

RSGT2021をきっかけに2冊の本を読みました。

『知識創造企業』と『ワイズカンパニー』。

この中で語られている、
組織がよりいきいきするを、みんなで実現することに
とても魅せられてしまい、野中郁次郎先生のファンとなりました。

20年前に語られていた野中先生のお話を、
スクラムを学んだ目線で読み解いてみると、
非常に面白い要素がたっぷり詰まっていました。

野中先生は、1986年に『The New New Product Development Game』という、
スクラムの原点となった論文を書かれたことでも有名です。

そんな切っても切れないスクラムと野中郁次郎先生について、
にわかファンのJ.Kが熱狂したポイントを語り尽くします。

昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び！

旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます！

★旅するAgile本箱LT2021：発表順(予定)

1. 前説:旅するAgile本箱って?
2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
4. 鳥井 雪さん 　「ダイバシティな絵本」のご紹介(順不同)
   『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる　とびきりおいしいデザート』
5. 吉羽 龍太郎さん「エンジニア的翻訳術」
6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
7. 佐藤 竜也さん『達人プログラマー 第2版』
8. 島田 浩二さん『ユニコーン企業のひみつ』
9. 結び

●ハッカーライフラボスタッフ
・司会：コサカ ジュンキ
・配信：アジャイル札幌のみなさん

ふりかえりをして、改善案を考え、いろいろ手は打っているのに今ひとつ効果が感じられないことってありませんか? システム思考を使うと「ものごとの因果関係を整理し、テコ入れが効果的な箇所(レバレッジポイント)を見つけ、より根本的な問題解決を促す」ことができます。

因果関係とは「開発者が増える→コード量が増える→開発スピードが上がる」というようなものです。他にも「コード量が増える→技術負債が増える→開発スピードが下がる」「開発者が増える→教育のため開発時間が減る→開発スピードが下がる」もあるでしょう。身の回りで起きている問題は事象はこのような複数の因果関係が組み合わさって起きており「開発スピードが上がらない」といった問題として認知されます。このような因果関係は図にまとめることで複数人で共有し、議論することで問題の真因に迫っていくことができます。便利そうですよね?

しかしながらこのシステム思考、自分もきちんと勉強したことがなく、人にやり方・使い方を教えるのにも苦労をしています。Scrum Fest Osakaにプロポーザルを出してしまうことで締め切り効果の発揮を期待し、集中して学習・教育資料を作ってしまおうという企みです。"これから学ぶ"は私の現在の状態、そしてこのセッションでシステム思考を学ぶ皆さんの両方にかかっております。

※システム思考は広義と狭義のものがあるそうですが、本セッションでは狭義のものを扱います。

システム思考 - Wikipedia

このシステムダイナミクスの定性モデルをポピュラーにしたのが、ピーター・センゲの「The Fifth Discipline（ISBN 0385517254、邦訳『最強組織の法則』（徳間書店））で、同書は因果ループによるシステム思考をコアにしながら、ビジネスの組織と人間の行動、学習する組織について論じている。同書を契機にこの因果ループ図を活用したシステムダイナミクスの定性モデリング手法は、「システム思考」として広く利用されるようになった。

スクラムで品質に悩んでいるチームや組織へのアプローチを整理する話をします。

品質を向上するためにテスターやQAエンジニア、SETやSREを増やそうとする組織は多いですが、スキルセットやキャリアパスをどのように決めていけばよいのかについて困っているところも多いと思います。また、当面はテストを外部発注してしのぐとしても、どう内製化するか、どうスケールするか、どう組織全体に根付かせていくか、について悩んでいる組織も多いと思います。

そうした悩みを解決するために、本プレゼンテーションではQMファンネル（3D版）を使って整理するお話を紹介します。

頂点が下向きになっている三角錐を想像してください。まず三角錐の側面はエンジニアのスペシャリティ（得意技）です。スペシャリティをTE（Test Engineer、いわゆるテスター）、QA（Quality Assurance、いわゆる品質保証）、DA（Delivery Accelerator、いわゆるSETやSRE）の3つに分けて整理します。もちろん、それぞれのスペシャリティがサイロ化しないように、側面の境界をスムーズにするような境界的なスペシャリティも考えないといけません。

次に、三角錐の深さはレンジ（範囲）になります。レンジを、外部発注したり専門組織によるサービスという役割分担から、スクラムチームの内部だけで頑張るインプロセス、チームと一緒に開発しながら高度なスペシャリティを浸透させるコーチ、それぞれのチームの外部からスペシャリティを移転するコンサルタント、組織全体にスペシャリティを浸透させていくプロモーターといった5つのレンジに分けて整理します。

品質を向上するには、TE、QA、DAの3つのスペシャリティが全て必要です。これらをまとめてQM（品質マネジメント）として捉えることで、バランスのよい品質向上が実現できます。同時にオールレンジの活動を意識することで、組織全体でバランスよく品質向上を浸透させることができます。

またQMファンネルは、伝統的なプロジェクトのようにPMとエンジニアを区別する考え方ではないという点にも注意する必要があります。スクラムチームでは、テスト計画・テスト設計・テスト実行を分割してサイロ化させるのは得策ではありませんし、コンサルタントやプロモーターが偉いわけでもありませんので。

私たちのQMファンネル（3D版）について聞いて頂いて、皆さんの組織の品質がスムーズに加速できればとても嬉しく思います。たくさん議論させてくださいね！

社内に多数のScrumチームが立ち上がっているが、Scrum間の連携の必要性がなく、各Scrumが独自に活動。その結果、質の差が大きく出たり、会社としての統制が難しかったり・・・そんな悩みはございませんか？

弊社も同様です。弊社は社員数6000人を超えるNTTグループ会社で、もともと（今でも）WF脳の会社です。そんな会社にもアジャイル開発の波が到来しました。現在、年間数十件のアジャイル開発が立ち上がります。各開発はサービス的にはほぼ横連携はなく個別に活動をしていることが多いのが実態です。

この状況になることは、2016年当時から予想できたため、社内にアジャイル推進組織を作りました。推進組織では、アジャイル開発が増えても最低限の開発の質を担保することや、各チームの困り事の解決のサポートと解決策の横展開を目指した活動をしてきました。

それなりの歴史があり社員数も多い会社であるため、一筋縄ではいかず、今でも悩み多き活動です。また、推進組織のメンバもアジャイル経験の希薄なメンバの集まりという状況で活動をしてきました。推進メンバをどう育てながらどう活動してきたいのかをご紹介いたします。

昨年弊社のメンバーが徐々に増えてきて、自分としてよりリーダーらしい立場と振る舞いをとっていきたいと考え始めましたが、そもそもリーダーとは何か、そこからスタートする必要がありました。

色んな書籍やネット記事を読めば大体のことが理解できますが、相反する考え方もあれば自分としてこういうリーダーになりたいというものがちゃんとフィットするものも見つかりませんでした。

そこで2020年9月にScrum AllianceのCAL（Certified Agile Leadership）プログラムに出逢いました。

よし！CAL1とCAL2を取得してヒント探しに行くぞ、と。

そして2021年4月現在、無事終わりました。確かにヒントは得られました。

しかし、経験したこと、学んだこと、得られたものは想像を遥かに超えていました。

皆さんにもぜひアジャイルリーダーの旅に出て欲しいという気持ちを込めて私のアジャイル・リーダー・ジャーニーを語りたいと思います。

145年の歴史を持つ大日本印刷株式会社。
時代の変化に適応し、印刷という名前からは想像できないほど、ものからシステム、SI案件から自社事業まで幅広いものづくりを行っています。

そんななかで新規事業のシステム開発を担う、たった５人のスクラムチームからはじまり、
現在では会社全体になかまができ、外部コーチの力を借りながらアジャイル推進を行うまでになりました。
新規事業の開発チームしかいなかった状況から、プラットフォーム開発や受託開発での検討の話題にもなっています。
当初は１チームしかなかった開発チーム。チームと人材は徐々に増え、会社としての取り組みが加速しています。

開発チーム内での実践から「アジャイル推進」へ役割を変え、
どのようになかまを作りムーブメントを広げていったのか、大企業内で推進に向き合ってきたなかでの工夫や苦労をお伝えできればと思います。

大きな組織のなかで試行錯誤している事例のひとつが、みなさんの参考になれば幸いです。

「ユニコーン企業のひみつ」。この本はとても読みやすいんだけど、でもそれって…自分と違う星の話を眺めてる気分だからじゃないのかな（仮説）。

私たちのチームと本で紹介されているチームの様子は、まるで地続きみたいによく似ていてます。本講演では「ユニコーン企業のひみつ」を使って私たちのチームについて説明を試みます。この本を自分のことのように受け止めた人たちの助けになれば良いな、と思います。

昨年の Scrum Fest Osaka 2020 @ Online から、カンファレンスの参加者の交流やさまざまな連絡にDiscordを使うようになりました。それからいくつかのカンファレンスで使ってきたのですが、スタッフ側でちょっと頭の痛い作業が「受付」です。

もちろんリアルのカンファレンスでも結構大変で、長年頭を悩ませてきたのですが、Eventbriteのアプリの出来がいいのが救いでした。しかし、Discordの受付にはそれが使えず、しぶしぶGoogle Spreadsheetを使いながら、スタッフがポチポチ確認作業をするということをしてきました。

それから約一年たちまして、さすがに運用も安定してきましたし、DiscordのボットとEventbriteのAPIを使って、自動化をやってみようかなということで、やってみました。プログラムとしては大したことはないですし、うれしいのもほとんどスタッフだけですし、これといった感動する苦労話もないのですが、こんな話を聞いてもらえるのもスクフェス大阪くらいかなと思い、プロポーザルを書いてみます。

mogiri
https://github.com/kawaguti/mogiri

この小さなアプリを、どのように維持したり、育てて行ったらいいか、皆さんをご意見やご示唆をいただければ幸いです。

トラック・バスといった商用車のメーカーである日野自動車は、コネクティッド技術や車両IoTデータを活用したソリューション開発にチャレンジしています。
より早く・多くの価値をお客様にお届けするための施策として、あるプロダクトの開発を、内製主体でのスクラム開発で進めることにしました。

チームメンバーにアジャイル経験者はゼロ、半数はシステム開発の初心者、おまけに仕事はフルリモート前提・・・
不安が募る船出でしたが、パートナー会社（NEC）によるコーチング・共同開発などの取り組みを通じて、習熟と改善を繰り返してきました。
企画から数えて約1年、8回の開発スプリントを通じて、チームとして工夫してきたこと、乗り越えてきたこと、学んだことを共有します。
スクラムの世界に足を踏み入れたばかりの「よちよちチーム」ですが、私たちなりの創意工夫が皆さんの参考になれば幸いです。

スクラムマスターがチームから離れられない。というのは事実なのだろうか。

勇気が足りないだけなのだろうか？思い上がりなのだろうか？

2年に渡って関わってきたチームからスクラムマスターとしてのロールを卒業することになった私が

自立したチームにおける卒業に向けての取り組みと、その後の現状について共有させていただきます。

2019年夏から新米スクラムマスターとして、コーチングを受けながらビルドアップした開発チーム。

今ではLarge Scale Scrum (LeSS)に踏み入れるくらい成長したチーム。

自立し、改善し、プロダクト価値を高めるための行動を取り続けている攻めるチームから、

私はスクラムマスターというロールを降りることにしました。

新たなるチームの旅立ちを迎え、ScMが離れる為にやったこと、チームの状況についてお話します。

「チームとして成長するにはどうしたらいいんだろう。。。」
こんな疑問を感じたことはありませんか？

新チームが編成されてしばらく経ったころ「今のチームを何とかもっと成長させたい」と漠然と考え様々なことに取り組みました。
ドラッカー風エクササイズ、ワーキングアグリーメント、ふりかえり。。。

取り組む中でただ「ふりかえりを実施する」「ワーキングアグリーメントを決める」だけではチームの成長を加速させることは難しいとわかりました。
また、これらを単なる「イベント」として実施するのではなく、成長へ繋がる「アクション」だというモチベーションでチーム全員が取り組むことも大事だとわかりました。

このセッションでは「チームみんなで成長するチーム文化」を目指して取り組んだことや直面した課題、チームで成長するために効果的だったことを自身の体験を元にお話ししたいと思います！