僕はこの10年間、色々なチームでスクラムをやってきました。でも、ちゃんとスクラムができたことはありません。それで良いんだろうなと思っています。そして、前に進むための選択をし続けているなら、それはもうスクラムと言ってしまってもいいんじゃないかと思っています。

昨年サポートを依頼してくれたチームは、いくつかの課題を抱えていました。見にいってみると（と言ってもオンラインですけど）、全員が「しっかりがんばらなきゃ！」と全力で改善に取り組んでいたのに、うまく噛み合っていない状態でした。そんなチームも、今はもう「仕組みを改善する仕組み」がチームの中にできている状態です。自分たちで毎日、より良い開発ができるように試行錯誤しています。なにより、ひとりひとりが前を向いて自分に何ができるかを考えているのがとても良いなぁと思いながら見ています。

そのサポートの中で、自分が今回挑戦したのは「誰も嫌な思いをしない変化」です。できていないことを指摘するのではなく、今みんなができることを見て、その頑張りがうまく噛み合う場所を一緒に探すことで、そのような変化を実現することができました。組織やチームに変化をもたらすということについて、今の自分の中にある2つの軸と、自分が実際に何を見て・どう捉えて・次の行動を選択しているのかという観察と選択のループを、以前の自分が陥っていた問題をまじえて、お話します。

これまでの発表では、少しキレイに見える部分をすくってお話してきましたが、今回は自分の内側に触れてみようと思います。あんまり見せるものでもないかなとは思うんですけど、スクラムフェス大阪だから良いかなと思って。色んな人たちとの出会いの中で、少しずつ変化してきた自分の考えや、内側で起こっていることをお伝えします。たぶん今後は、もうこんな話はしないんじゃないかな。

楽しんでもらえると嬉しいです。みなさんにお会いできるのを楽しみにしています！

既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

昨年のスクラムフェス大阪で好評だった「旅する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. 結び

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

達人たちが見ている世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

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

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

「じゃあ山田君は来月からスクラムマスターだから、よろしく！」
上司にこう告げられて、スクラム未経験なチーム、これまでウォーターフォール開発をやってきたユーザー部門と共に、2021年1月から半年間、システム開発を行ってきました。
半年間のシステム開発期間に起きた、チームの試行錯誤と成長をお伝えをしたいと思います。
また、きれいごとだけでなく、ぶち当たった壁、そしてそれにチームはどう対応していったかについても触れたいと思います。

最後に、この半年を振り返って、チームで気づいた、上意下達な文化にスクラムを導入するために大事だと感じたことをお伝えしたいと思います。

上意下達に疲労困憊した文化の中で、スクラムチームを立ち上げる方のお役に立てたら幸いです。

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

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

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

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

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

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

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

プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

でも、もしプロダクト開発がゲームだったら・・・

コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

チームを「アジャイルなチーム」にどう変容させるかという点に苦慮されている方は多いと思います。

「チームの動きがなかなかうまくいかない」「あの人が変えられない」「自分のやり方が間違っている」などと悩んでいる方もいるのではないでしょうか。

そんな時は、一呼吸おいて「チーム」や「他者」ではなく「自分の内面」に目を向けてみましょう。

本セッションでは、チームではなく個人、他者ではなく自分に着目して「自分が変わることで、チームが変わる」という可能性を探ります。

登壇者は、2000年から、XP、スクラムをはじめとする様々なソフトウェア開発、アジャイルの手法・思想・価値体系、パタン・ランゲージやネイチャーオブオーダーなどの周辺の思想も含めて探求してきました。そして現在着目しているのが「個人の変容」です。

Kent Beckは以前、来日した時に「Social change starts with you.」と言う言葉を残しています。本セッションでは「自分が変わる」ということはどういうことなのかをワークを通じて探求していきます。

まず最初に、IKIGAIマップによって自分の今を客観視してみます。IKIGAIマップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

その後、「マルチポ・テンシャライト」という「器用貧乏」を肯定的に捉える考え方をご紹介した後に、自分の内面に目を向けるワークをおこないます。

最後に、「ザ・メンタルモデル」をヒントにして、自身の無意識の振る舞いがどのような現実を作っているのかを見つめます。

自分を内観することで、どのように認知が変わるでしょうか？「そこにあるものを、ある」と認めることで何が変わるでしょうか？

そして、結果として自分の周囲がどう変化するのでしょうか？

様々な手法や考え方を紹介しながら、他者ではなく自分を見つめ、チームが変わるのではなく、自分が変わることで世界が変わるという意味とはどういうことかを一緒に探求しましょう。

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

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

幸運なことに、昨今のITエンジニアには多様なキャリアが存在します。わたしたちは、自分の得意分野を掘り下げ、また新しい分野を開拓し、およそ40年ほどの職業人生を歩んでいくことになります。

スクラムという分野に目を向けると、「スクラムマスター」といった役割がまずは目に付きますが、「スクラムマスター」を専任で置いている組織はまだそんなに多くありません。では、スクラム(もしくはアジャイル)をスキルの中心に据えたキャリアの選択は難しいことなのでしょうか？ わたしはそうは思いません。

フロントエンドを得意とするエンジニア、インフラを得意とするエンジニア。この人達は「フロントだけ」「インフラだけ」を頼りにエンジニア人生を全うするでしょうか。おそらくそのようなことができる人は稀だと思います。皆それぞれ自分の得意分野を中心に据え、その周辺のスキルもうまく組み合わせながら多様なキャリアを築いていくのが一般的でしょう。

スクラムについてのスキルも当然同様で、「スクラムマスター」で生涯を終えることを目指すのではなく、スクラムについてのスキルを得意分野として軸にしつつ、多様なキャリアをつくっていくことができるはずです。

顧客に価値を提供できるソフトウェアを「上手につくる」ことに課題を持っている現場はたくさんあります。スクラム(またはアジャイル)を得意とする人は、これからもうしばらくの間は重宝されるのではないかと思います。

このセッションでは、わたし自身のキャリアの経験を交えながら、スクラムについてのスキルを軸にキャリアをつくっていくにはどうすればいいか、について考えてみたいと思います。

ベトナムでは COVID-19 が世界的に流行する以前より、日系企業のオフショア開発の縮小・撤退が散見されるようになってきました。ベトナム経済の継続的なえげつない高度成長により（コロナ禍でもGDPプラス成長）、コスト上昇が著しいのは事実です。コスト、品質、そのバランスなど悩みどころはたくさんあります。

ベトナムの開発では日系企業の場合、基本的には、通訳を通じての日本語もしくは直接英語でやり取りを行いますが、

言葉が通じることと、話しが通じることは違います。

要件を正しく伝える・相手の言いたいことを正しく理解する。ごく基本的で大切なことですが、特に国を超える場合、思考の背景にあるコンテキスト（カルチャー）を理解することが重要です。お互いが。

私は2014年12月からおよそ6年半、

• ハノイ、ホーチミン
• 案件を出す側・受ける側
• 保守運営案件、新規案件、自社開発案件
• ラボ型開発、受託開発
• エンジニアがいるクライアント、いないクライアント

など様々な組み合わせで、PM、エンジニア、人事、経営などの立場でベトナムに関わってきました。

Made in Vietnam のソフトウェア開発を世界品質にすべく活動するなか、試行錯誤してきたこれまでの取り組み、現在の取り組みをシェアしたいと思います。

テスターを含むチーム全体（Whole-Team）で、プロセスやプロダクトに品質を作り込む（Build quality in）にはどうしたらよいでしょうか。
Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

• quality is everyone's responsibility（品質はすべての人の責任）
• improve quality you automatically improve productivity（品質を向上させれば、自動的に生産性も向上する）

また、Janetがオリジナルで提唱する原則が以下の2つです。

• if you focus on quality the speed will come（品質にフォーカスすればスピードが出る）
• if you focus on speed the quality gets lost（スピードにフォーカスすれば品質が失われる）

アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
JanetとLisaは以下のような内容で特にプロセス品質についてトークします。

１．Question Askerであるべき
２．例やテストを使って開発をガイドする
　・magic bubble（魔法の泡）　コード・テスト・自動化
　・Acceptance Testのループ（受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト）
３．エクササイズ（ユーザーストーリーからテストを考える）
４．アジャイルテスティングの4象限を使ってテストを把握する
５．探索的テスト、品質属性のテスト、スライディング・スケール
６．コアプラクティスを使う
　・継続的インテグレーション
　・テスト自動化
　・機能やストーリーの優先順位付け
　・ビジネス価値を頻繁にデリバリー（いつでも出荷可能なリリース候補を用意する）
　・品質をデリバリー（コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築）

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

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

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

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

XP祭りは今年で20周年です。

これまでのふりかえりと、XP祭りが長く続けていける秘訣などをスタッフがお話します。

後半20分は、2016年からスタートしたビブリオバトルについてふりかえります。

チームの能力を高めるといったとき、どんなことをイメージしますか？
能力アップ（熟達）には、レシピ通りに手早く正確に作れるようになる定型的熟達と、材料が揃ってなくても状況に合わせて調理をする適応的熟達があります。
これは、チームの考え方や、マネジメントの接し方によって影響を受けます。

開発現場に置いて、定型的熟達と適応的熟達がどんな行動をするのか、どうしたら適応的熟達に近づけるのか紹介します。

アジャイル界では知らぬ人はいない平鍋健児さんと、Jenkinsを作った川口耕介さんが、ソフトウェア作り、日米のソフトウェア産業の違い、技術者のキャリアなどについて対談します。どんな話が飛び出すのかは、参加してのお楽しみ！

本セッションは永和システムマネジメントのスポンサーセッションです。

「リファクタリング」「テスト駆動開発(Red Green Refactor)」の本が登場してから約20年近くたち、ソフトウェア開発の現場で「リファクタリング」の言葉がよく使われるようになりました。

一方で、単なるコードをきれいにすること、動作確認をせず平気で壊してしまう作業をリファクタリングと呼ぶ「時間があればまとめてリファクタリングしよう（実施されない。日頃のプログラミング中にリファクタリングは全くしない）」など、リファクタリングが誤解されて広まるようにもなりました。

自信をもってリリースを続けるためにも、日常的に頻繁にリファクタリングをしながら、対話しやすい変更しやすいコードの状態を保ち続けることが大切です。

本日は、初心者向けにリファクタリングが具体的にどういったものなのか、なぜリファクタリングが必要なのかを、ミニ講義＆モブプログラミング見学を通じて、エッセンスがお伝えできればと思います。リファクタリングのステップはモブプロのステップでもあるので、モブプロに興味のある方にもおすすめの内容です。

• 当セッションではCLで開催しているアジャイル道場の背景や目的を紹介します。
• アジャイルCL道場では、門下生同士によるアジャイルな開発体験を通して、会話を中心としたコミュニケーションと信頼関係の向上を目的にしています。
• その具体的な様子をアジャイル道場の道場主と門下生の両方の立場から赤裸々にお話しします。

Tigerspikeはデザインとエンジニアリング能力を組み合わせることで「使いたい、をカタチにする」を実現することをミッションにしています。

エンジニアリングのみではなくデザインに強みをもつこともあり、東京オフィスのメンバーの約半数はUXデザイナー、UIデザイナーです。

同じチームでプロダクト開発をする仲間ではありますが、デザイナーとエンジニアはバックグランドや思考法が異なる存在です。お互いが大事にすること、プロジェクトにおける関心事も異なるため、コラボレーションして成果を出すためには工夫が必要です。

このセッションではプロジェクトや日々のコミュニケーションの中で、デザイナーとエンジニアがお互いのギャップを理解しながら、コラボレーションし成果を出していくための取り組みについてご紹介します。

スクラムの原典ともされる『The New New Product Development Game』では rugby approach や  Like a rugby team のようにrugbyという単語は11回登場します。

2019年、スクラム実践者にもラグビー日本代表の試合に熱狂した方は多いと思いますが、rugby approachとはどういうことなのか、like a rugby teamとは何なのか理解できた方は少ないのではないでしょうか。

そこで本セッションでは、スクラムの思想とラグビーの思想を対比させながら、ふわっとラグビーに詳しくなりつつ、よりアジャイルやスクラムについても理解を深められればと考えています。アジャイルとラグビー半々で話します。

なお2023年フランスワールドカップでは日本は、イングランド/アルゼンチン/オセアニア第1代表/南北米大陸第2代表と同じ予選プールDです。

My Wife Went To U.S.

それは突然のことでした。「ねぇ、4月からアメリカ行っていい？」

そこから始まる父と小学生の息子2人、トイプードルの娘1人との1年間の情熱ワンオペ育児。たくさんの不安がよぎります。しかし、この困難に正面から立ち向かうことにしました。自分の道具箱にはエンジニアリングマネージャーとしての経験があります。これをどうにか活かすことはできないかと取り組みを始めます。

エンジニアリングマネージャーが家事育児にトライしてみると？

実際に取り組みを始めてみると、自分のこれまでのエンジニア、マネージャーとしての経験が多くの場面で活かせることに気がつきます。実際に経験したものの一例は下記のようなものです。

• あ、冷蔵庫行ったり来たりすると面倒だな（TPSのムダの発見と解消）
• 仕事をどう調整つけようか、不安がる実家の親をどう安心させようか（ステークホルダーへの透明性）
• ホットクック（自動化）
• 水回り、お金払ってピカピカになるととってもアガるし効率がいいな（アウトソース）
• 料理代行、ただ作ってもらうだけだとそんなに楽にならないな（リーンソフトウェアの「全体を最適化する」）
• 大根が嫌い？ なら千切りにして味噌汁に入れたらどうなるかな？夕飯で試そう（高速に実験＆学習する）

これらの活動を通して、苦労していたワンオペ育児もだんだんと楽しく、より良くなるように感じています。また、今までの経験・知識をワンオペ育児へ再適用することで、これまでの経験にもより深い理解にたどり着きました。

このセッションについて

このセッションでは、私が実際に経験した家事・育児での困難さを、自分のエンジニアリングマネージャーとしての経験から見たときにどう見立てられるのかを学び、どう戦っていったのかを話します。その中でのフィードバックループを回す中で、自分が持っているアジャイルやソフトウェアの知識もより深い理解にたどり着いたように感じたので、その学びについてもシェアします。

アジャイルな思想や方法論をどのように適用したら良いのかがわからず困っている人がもしいれば、このセッションを聞いてみませんか？ ソフトウェア開発とは全く異なる対象領域ですが、アジャイルな家事育児を通して、理論と実践、思想と方法論がコネクトできるヒントになると思っています。もちろん日々の家事・育児に悩んでいる人も参考になるTIPsが多いと思いますので、参考にしていただければ幸いです。

老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
（悩みの一例）
・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
など。
せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

登壇するPO、ScMが本プロジェクトで大切にしてるマインド

[ PO ]

対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

[ ScM ]

POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

あなたのチームはなぜスクラムをやっていますか？

少なからず、そこには事業の成功や成長と深く関係していると思います。

今回はスクラムチームにおいて最も事業への貢献を司る「プロダクトオーナー」にフォーカスし、

"開発チームが最初のコードを書く前に必要なお仕事"

についてお話ししたいと思います。

【なぜ、今、私がこの話をするのか】

• 事業会社時代(~2021/3)に複数プロダクトの立ち上げ経験があり、いずれもPOとしての立ち上げを経験していた
• 上記経験をもとに現在"複業PdM"として複数社のプロダクトに参画させていただき、比較し、型が少しずつ見えはじめてきた
• 自身の整理と壁打ちの意味でもこの機会に言語化し、Feed Forward / FeedBackを得たいため

【お話しすること】

• 「アイディア~ビジョン~事業収益~仮説検証~指標(KGI)~施策~チームの組成~Sprint0」の全体像
• 各ステップでのやるべきこと、心構え、フレームワーク、参考資料の紹介

【お話ししないこと】

• それぞれのステップを具体的に掘り下げること(時間が足りないので / それぞれ45分ずつできそうw)
• Sprintがまわり始めてからのPOの立ち居振る舞い(別の機会に)
• PdM、PM、PO、事業責任者の違いなど (今回の内容では重要ではないため)

詳しくは右下の"VIEW DETAILS"より中身を見ていただければと思います。

アジャイルの浸透によってプロダクトがアウトカムに目を向けることの重要性が認識されるようになりました。では、従来型の開発プロセスで10年以上開発を続けてきたプロダクト開発チームは、どのように取り組めばアウトカムに目を向けたアジャイルな開発に転換できるのでしょうか？

今から2年前、10年以上の歴史を持つプロダクトが新たなビジネス領域に参入するためにチームを再結成して新機能を開発していくことになりました。正解がないレッドオーシャンのビジネス領域に飛び込んだ我々はまず開発プロセスをアジャイルに転換する必要性を感じてスクラム開発を取り入れようと試行錯誤していました。そんな中、関西でアジャイルコーチとして活動されている中村洋さんと秋元さんが開催していた相談会をたまたま見つけて相談しました。そこでホワイトボードの中央に書かれた言葉が「アウトカム」でした。

何のためにプロダクト開発をアジャイルにするのか？開発プロセスを変えてアウトプットを増やすだけではなく、ビジネスの成果＝アウトカムにつなげなければ我々の課題は解決しないと気付かされました。「アウトカムは何か？」を問いかけ続けてプロダクトを成長させていくことがアジャイルの本質だと気付きました。

アウトカムを得るためにはプロダクトとその顧客をよく知る人の存在が重要だと考えました。そこで、チームで一番のベテランエンジニアが経験ゼロからプロダクトマネジメントを担当することになりました。そこから1年間、まずは開発チームにスクラムを取り入れて、新体制のアウトプットを安定させる事に取り組みました。その間にプロダクトマネージャーはスクラムのプロダクトオーナーとしての振る舞いを学びました。そして2年目、プロダクトのアウトカム創造をチーム目標に設定して本格的にプロダクトマネジメントに取り組みました。

2年前の再結成からチームのマネジメントを担当しているエンジニアリングマネージャーと、自身も新たなステージへ飛び込んでチャレンジしているプロダクトマネージャーが、アジャイルを取り入れてプロダクトのアウトカム創造に試行錯誤してきたチームの取り組みについてそれぞれの視点でお話しします。

スクラムやアジャイルに初めて取り組むときにありがちなことをネタにして、2人のアジャイルコーチが、紙芝居でRPG風の物語のワンシーンを演じつつ、スクラムやアジャイルでの落とし穴について解説をします。

※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションとして提案するものです。

皆さんは、スクラムの源流が80年代の製造業のプロダクト開発を観察した論文 "The New New Product Development Game" にあることはもちろんご存じですよね。そこにどんなことが書いてあったか、知りたいと思いませんか？現在論文は無料で Harvard Business Review サイトで公開されているので、誰でも読めるのですが、英語なのでちょっとハードル高いですよね。一緒にみんなで機械翻訳かけながら読んでみませんか？

2016年11月に始まった教育心理学関連　勉強会／読書会では、三宅芳雄先生,三宅なほみ先生の『教育心理学概論』から始めて、教育心理学概論の参考文献や関連する分野の本を用いた読書会をおおよそ月に1回のペースで続けてきました。

4年半ぐらい読書会を続けていますが、これだけの期間続けて実施しているコミュニティはそんなに多くはないのかなと思っています。

私は初回からこの会に参加していて、直近まで参加を続けています。今回、Scrum Fest Osakaでこのコミュニティに関連したセッションを持つことになったと聞き、長く参加している者としての私の観点から、これまでのことをふりかえってみようというのが、この発表の趣旨になります。

※「学んだこと」とタイトルにありますが、具体的な理論の紹介というよりは、自分の気付きを中心としたお話になります。

コミュニティ活動を通じて感じた以下のような内容をお伝えできればと考えています。

• 興味がある内容を話合える楽しさ、協調学習の楽しさ
• 楽しく続けていくことの難しさ
• 楽しい場に居座ることの大切さ

スクラムマスターの役割で動いていると、さまざまなところで言葉を利用したアクションが必要となります。

スクラムマスターのみなさんは、とてもたくさん勉強をして、色々と新しい発見をして、それをチームに伝えたい！そんな思いやりのある方ばかりですよね。

しかしながら、「伝え方が悪くて伝わらない」「うまく伝えられない」という気持ちになったことも一度や二度ではないはずです。

このセッションでは、言葉は伝える（アウトプット）だけではなく、伝わった（アウトカム）を大切にしていくことが大切だという気づきを得た経験から、言葉のアウトカムを最大化するための方法を紹介して、皆さんの言葉の力を引き出せることを目指しています。

チームのスクラムマスターとしての経験だけではなく、Podcastのパーソナリティとしての経験やカンファレンス運営の経験など、様々な角度から言葉のアウトカムについて考えてきた経験を基にお話をさせていただきます。

言葉のアウトカムを高めるために必要なのは、ふりかえりです。

自分の発言した言葉をふりかえることはできていますか？

仮説を立てて、発言をして、ふりかえって、カイゼンするといったサイクルを日々考えることができていますか？

実際に私が行っているふりかえりの方法や、簡単にできる言葉のふりかえり方法の紹介を通して、皆さんがこれから話す言葉の一つ一つを大切にできるようになります。

さらに、言葉のアウトカムを高める意識が高くなっていくと、問いのスキルも向上します。スクラムマスターにとって大切な問いのスキル

効果的な問いをチームに投げかけることで様々なことを引き出すことができると皆さんは感じていると思います。しかり、それを実践することはとても難しいことです。

効果的な問いをするためにはどうすれば良いのか？どのように訓練をすれば効果的な問いを生み出すことができるのかをお話しします。

私達は、楽天グループ内の様々なサービスから利用されるプラットフォーム系サービスを幾つか担当しており高いSLAが期待されています。

そのため万が一システム障害が発生した場合、迅速な原因追求と復旧作業が必要となります。

その反面、トラブルシューティングスキルは属人化しやすく体系立てて引き継ぐのが難しいという課題を感じていました。

そこで、私達はDiRT（Disaster Recovery Training）と呼ばれるプラクティスを参考にし、定期的にStaging環境で擬似的な障害を発生させObservabilityの改善や、レポーティングまで含めたプロセスの見直し、モニタリングツールやシステムそのものの改善を行うため(障害訓練→振り返り→対策実施)を繰り返しています。

今回は我々の活動についてご紹介させていただきます。

開発のマネージャー職として採用されたはずなのに、
気がつけばなぜかユーザー部署でのオペレーター業務をやらされ、
エンドユーザーからの電話を取ることになった弱虫のeroccowaruico。

サポート対象はバグだらけで仕様も不明確で資料もない大規模展開システム。
エンタープライズ環境に理解のないシステム開発部署とエンドユーザーの板挟み。
そして僕に下される開発部署とのコミュニケーション禁止の判断。

嫌なことから逃げることしか出来ない弱虫はチームのメンバー、そしてエンドユーザー、何より自分を守るためにユーザー部署内で小さなプロダクトマネジメントとエンジリアリングマネジメントを行い、ユーザー部署からそのシステムを支えるプロダクトを作り上げ、数万人のユーザーに届ける事にしました。

理不尽にも思える状況の中、ユーザー部署内でひっそりとプロダクトマネジメントとエンジニアリングマネジメントの手法を適用し続ける。
その目的とその中で起こした変化をお話しします。

（本発表は守秘義務に反しない内容とするため、脚色や匿名化を行なった内容となります。実際の会社名、案件内容は一切お話できません）

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

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

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

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

システム思考 - Wikipedia

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

みなさんの開発チームでは、スクラムやアジャイルを駆使して色々な課題に向き合っていると思います。
そんなみなさんの隣の非エンジニアだけのチームはどうでしょう？楽しく働けていますか？

私は、会社でアジャイル推進室というチームを立ち上げて、開発チームが楽しくやっている部分を中心に広めていくという活動をやっています。

実際に隣のチームへスクラムイベントのファシリテーションしたり、アジャイルマニフェストを読む会をやってみたり。活動の中でも、特に手応えを感じているのが3年連続でやっている新卒へのふりかえり研修です！

自分はスクラム開発が楽しいと感じており、どうにか他のチームにも広げられないか？
チームイベントのレトロスペクティブで自分たちの活動がどんどん上手く回っていく姿から、どうにかこれを全社的にやれないか？とずっと考えていました。

今回、私の発表では、ちょっとずつアジャイル開発の楽しさ１つとしてふりかえりを会社全体に広げていった3年間の経験を話していきます！

みなさんの今いるチームの隣の人たちにも、自分たちの楽しさを伝染できるようなヒントになる発表をしたいです。

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

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

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

アジャイルコーチをやっていてよく聞く悩みとしてこんなのがあります。

• もっと良いチームを作りたいのになかなかメンバーが変わってくれないんですよ…
• うちのチームはアジャイルなんですが周りのチームが理解してくれなくて…
• 弊社は古くて堅い文化なので新しいことを始めるのは難しいんです…

では支援を提供している自社ではこのような問題はないのか？と問われると、程度こそ違えどチーム・チーム間・組織の単位で色々な問題はあります。もちろん、私が力になれそうな問題であれば良い感じになるように色々な動きをしています。

社外のアジャイルコーチの場合、期限・頻度・役割といった観点で考えると、実際の現場のチームやメンバーと同等の動きは取りません。一緒に問題や解決案を考えたりはしますが、実際に解決のために動くのは現場のメンバーになります。

逆に社内を良い感じにしようと思った場合、自分自身が当事者であり、実際にアクションを行うのは周りの誰かではなく私です。

私は自身の勤務時間の半分を他社向け、もう半分を自社向けに使っています。アジャイルコーチとして現場の支援をすることもあれば、アジャイルコーチの皆さんに相談をして支援を受けることもあります。社外のメンバーの背中を押すときもあれば、社内のメンバーの背中を押すときもあれば、社外のメンバーから背中を押してもらうこともあります。支援や改善活動の単位も個人/チーム/複数チーム/組織全体と様々です。

といった様々な立場や規模で動いている経験から、チームや組織を良い感じにするために実際にやっていること、結果としてどんなことが起きたのか、気をつけているポイントなどを紹介させていただこうと思います。あくまでもコンテキストありきの事例集ですが、事例ごとに参加者の皆さんとそれぞれのコンテキストで活用できることがあるかも議論しながら進めようと思っています。

私の事例を肴にわいわいしましょー！

本ワークショップでは、今年も”Scrum Patterns: The Spirit of the Game”の公開情報を題材に、スクラムのことをより理解することを目的に、みんなで一緒にワイワイと読み進めていきます。

Outlineを見ていただいて、好きなところで参加していただければと思います。

ところで、みなさんはスクラムガイドをご存じでしょうか？
スクラムガイドは、スクラムの基本を簡潔に定義した、わずか13ページのガイドブックです。

みなさんは、スクラムガイドを読んで、実践してみて困った経験はありませんか？
私はあります。
それは、スクラムガイドの理解が足りなかったからでしょうか？

スクラムガイドは、”The Rules of the Game”とあるように、”スクラムのルールブック”と言えます。
ルールを理解することは重要ですし、ルールに従うことは正しい行いです。
しかし、ルールを理解したからといって、優れたプレイヤーにはなれません。

スクラムブックには、”The Sprit of the Game”とあります。
どんなゲームも楽しむには、ルールを守るという心のあり方が大切です。
ゲームに臨むための精神に触れることで、また、ルールをより明確に理解するための助けになります。

序盤は、公開されているスクラムパターンとは何か？なぜ公開しているのか？を自分で調べ、Copeさんにも教えてもらったことを交えてご紹介します。
その後、みなさんと”A Scrum Book: The Spirit of the Game”の公開情報を読み進めながら、よりスクラムのことを知ることができればと思います。

Scrum Patternsを知って
みなさんと
明日からちょっとだけ幸せになれる何か
を見つけられると幸いです

このセッションでは，大学のPBL（Project Based Learning）でリーダーのいない組織を形成し，その活動の中でどのようにチームが成長してきたかをお伝えします．

いま，日本の大学ではPBLという学習方法が広く実施されています．PBLとは，実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって，チーム開発やチームマネジメントの手法について学ぶことができる学習手法です．私が所属する大学でもPBLのカリキュラムがあり，スクラムを用いてプロダクトを作るという経験を得ました．しかし，私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました．そして，その結果として，とても良いチームを形成できたと感じています．

リーダーもいなく，開発初心者が集まるプロジェクトで，どのようなことに苦労したか紹介・分析し，そのうえでチームをより良くするためにはどうすればいいかお話ししていきます．

私たちはバックオフィス向けのSaaSを開発しているスクラムチームです。私たちは複数チームでスクラムを実践していくためにLeSS（Large-Scale Scrum）を採用しています。

最初から全てのプラクティスを導入することは難しいため、まずは顕在化していたプロダクトオーナーのボトルネックを解消することから始めることにしました。

この課題を解決するためにエンジニアがプロダクトオーナーの領域に越境するエピック大臣制を導入しています。（エピックとは複数のユーザーストーリーを束ねたユーザー価値の最大の単位を意図しています）

エピック大臣がどのようにして誕生し、プロダクトオーナーのボトルネックを解消していったかを紹介させて頂きます。

スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskの開発拠点はベトナムにあり、約1500名の開発体制では常に110を超えるプロジェクトが同時に動いています。

私達は最近までプロダクトを高速でデリバリーすること強みとしてきましたが、最近では”品質”を次のテーマとして取り組んでいます。

今回はそんな私達の取り組みについてご紹介させていただきます。

#Agile mindset #AgileTesting #Scrum #GIST Planning

システム開発において、テストは切っても切り離せない存在です。
しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか？
実は、テストコードを書き始める前に既に勝負は決まっています。

本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

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

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

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

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

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

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

組織の変革や新しいカルチャーを醸成するにあたって、何から始めるべきか？どのように進めるべきか？悩んでいるすべての方々にお届けしたいセッションです。

本セッションでは「次世代版 地域総合会社」を目指し、お客様のニーズに対応するために様々なデジタルトランスフォーメーション戦略、システム戦略に注力している株式会社北國銀行の取り組みをご紹介します。

北國銀行は多様性が低く、年功序列や縦割りの保守的なカルチャーで、声が大きい人の意見が採用されたり、従来の仕事のやり方が踏襲されたり、お客様不在で仕様を決めたり、新しい発想が出てこないなどの状況に陥ってました。

そのため、ステークホルダー全員が同じ目線でプロジェクトを推進するにあたり、今までとは異なる新たなマインドセットを持つ必要性を感じていました。

そこで、部署横断でチームを作り、業務をシンプル化しつつ統合して全体最適を図るために、ITプレナーズの「フェニックスプロジェクト DevOpsシミュレーション研修」を、6部署（銀行業務部門・マーケティング部門・IT部門など）から合計36名が受講しました。

その結果、チームがどう変わったか、業務の進め方がどう変わったか、どのような成果が現れたかをお話しします。

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

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

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

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

リモートワークの課題をモブワークで解決する試み

開発チームの改善

開発者からTechLeadになると、チームもシステムの一部だと気づきます。

ソフトウェアシステムを改善するように、私達はチームというシステムを改善することでユーザへより良い価値提供ができるようになります。

Tech Leadになったばかりの頃は、まだチームの問題を認識できておらず、ソフトウェアシステムの改善を行うことでチーム改善をしていました。

この改善は容易で、わかりやすいですが、問題の核にアプローチできず、部分的な問題を解決するにすぎません。

そのため一度立ち止まり、チームで話し合い、チームの問題を明らかにし、取り組むことにしました。

スケジュールと実績の乖離

私達のチームでは、開発スケジュールに対して実績が大幅に超えることが多々ありました。

正確なスケジュールを引くことは不可能ですが、一方でこの状態は望ましくありません。

実績が超える原因の多くの理由は、想定外の修正や要件です。

この問題に対処するために、チームでスケジュール作成に取り組むことにしました。

教育サービスを提供する会社の中で辺境とも言えるソフトウェア開発部門から実験的に始まったスクラム開発。

最初はWF型組織の中で密教のように立ち上がったスクラムチームですが、ときにオレンジな空気に抗わず、ときにWFポリスの目をごまかし、現場では挫折や失敗を繰り返す日々を重ねてまいりました。

そんなアジャイルジャーニーもなんとか６年目。

気がつけば小さな成功を積み重ね、チームは成長し顧客やプロダクトのためであればドメイン外の仕事も自発的に取り組む頼もしいチームへと成長してくれました。

今回は、このようなチームと活動を共にしながら、私自身が人事異動によって非ソフトウェア開発部門にも関わるようになり。さらに社外へとカルチャーバブルを少しずつ広げていった話をします。

当社は、日本ラグビーフットボール協会のオフィシャルパートナーです！！※本当です！！

NTTコムウェアでのアジャイル開発、それは求められるNTT品質という北極星を目指す長い旅路です。そして、その道程はこの先も続いています。

本セッションでは、我々が「どのようにしてアジャイル開発における品質に取り組んでいるのか」をご紹介します。

NTTコムウェアはNTTグループの一員として、長年インフラを支えるキャリアグレード品質を提供してきました。
そのほとんどをウォーターフォール開発で取り組んできた我々ですが、近年はアジャイル開発にも果敢に挑戦しています。

その中で私の所属する組織は、事業組織での「アジャイル開発の普及および支援」を目的に設立され、
これまで社内組織を巻き込んでアジャイルを取り巻く課題の解決に取り組んできました。その課題の１つが『品質』です。

我々がどのようにして品質とアジリティの両方を求められる事業組織の開発において、目指すNTT品質の姿を共有し、
相互改善と仲間づくりをしてきたのかをご紹介します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

freee株式会社でエンジニアをやっています。宗田（そうだ）です。
エンジニアでありスクラムマスターでありエンジニアリングマネージャーでもあります（兼任したからこそ学べたことも多くあり兼任してよかったなと感じていますがその話は今回はやりません）。

新卒で入社したSIer（前職）でスクラムをやっていたためエンジニア歴イコールスクラム歴です。
前職でのアジャイルエバンジェリストや社外コミュニティ活動で先人の行動や考えを確と学ぶ機会も多くあったため実践で大きな失敗もあまりなかったように感じていました。
が、それも自分に力があったわけではなく周囲のサポートがあったからこそだったのだと痛感する失敗を経て、現在に至ります。

ただし、単に失敗しただけでは終わりません。
そこからどうやって巻き返したのか。失敗から何を得たのかをこのセッションでお話しします！

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

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

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

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

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

Team as Project and Member

　私はチームの要素は２つあると考えています。プロジェクトとメンバーです。

チームは、与えられたプロジェクトをきちんと回さなければならないですが、

プロジェクトを支えるものが人の集まりということを考えると、まずメンバーについて考えなければなりません。

TO DO?

　チームのためにリーダーがやるべきことについては、すでに様々な場面で話されてきました。

共感、情熱、パフォーマンスそして革新など全て間違いではないし、どれも欠かせない必須条件として考えられるでしょう。

ではいいチーム作りの前提となる、メンバーのモチベーションを向上させるためにリーダーが考えるべきこと、考慮すべきことはどういったものがあるのでしょうか。

TO CONSIDER　

　私には今までリーダーを務める機会が多くありました。それはスクラムマスターであったり、軍隊の士官であったりしました。

特に士官時代は数百人の隊員がいて、どうすれば全員の方向性を一つにまとめられるかを工夫する日々でした。

こういった経験から私はどのようなことを感じたでしょうか。

STAY TUNED

　プロジェクトを回すにあたってメンバーは最も重要な存在であり、特にメンバーのモチベーションはその成果を最大化するエンジンとなります。

このセッションを通じて、いいチーム作りのためにリーダーが考えるべきこととは何なのか、という質問について

皆さんと一緒に答えを探してみたいと思います。

スクラムの活動にはチーム内で話す場面がたくさん設計されていると思います。
話すという行為は言われてみると当たり前なのかもしれないのですが
・ちゃんとチームのメンバーと話せているのか
・聴く耳を持てているのか
・チームメンバーの気持ちを尊重できているのか
・個々のキャリアに向き合えているのか
といった観点を振り返ってみるとどうでしょうか。
話すということはちゃんと考えると結構難しいことだと思います。

私は1on1ミーティングを外部の立場から行うなど、職場のコミュニケーションに特化して組織を支援しています。
一見、1対1のコミュニケーションだから、チームの話とは違う印象をもつかもしれません。
でも仕事を行う以上、人と関わるのは必然。複数人行ううちに共通の課題も見えてきます。
いろんな現場にいくと、対話をしているようでできていない現場をよく見ます。
もちろんこんな風に書いている私もうまく話せなかったなぁという体験はあります。

このセッションでは、「外部メンターとして現場に関わる私がメンバーとの会話で大切にしていること」として職場のコミュニケーションを行う上でどんな考え、理論をもとに普段行なっているのか、そこを考えるに至った背景や時に失敗したことなどをお話ししたいと思います。話すこととはどういうことかをセッション参加者と一緒に考えられたら嬉しいなと思っています。

※参考スライドとして先日発表した資料を添付します。
この内容をそのまま話すわけではないですが、雰囲気や大枠の流れが似たものになるかと思います。
可能な限り新作を加えた形でお話ししたいと考えています。