実に16年の時が流れました。私がXP祭りで話をしてから、いや人前でまとまった話をするようになってからです。一見どうしようもないように見える状況でも、自分の踏み出す一歩でほのかにも変わり始める可能性がある。そんな熱に浮かされたような語りから、ソフトウェア開発、プロダクト開発から事業開発、そして組織変革へと、これまで活動を続けてきました。

この数年は、なぜ組織の営みが上手くいかないのか、という問いに向き合ってきています。何が組織の次へと向かう動きを阻んでいるのか。堅牢なはずの開発や最適化された事業、組織運営のどこにその要因があるのか。

問題は何か、その正体を捉えるためには深く深く掘り進めていく必要があります。それは、さながら「探検」のようです。組織という洞窟を降り進んでいった「底」に何があるのか。 “倒すべき問題” とは何だったのか？ もし、そこに倒すべき対象などなかったとき、一体どうするのか？

もし、私が20年前にXPに出会わず、その後アジャイルとともになければ、ここまで続けられなかっただろうと思います。目の前のソフトウェア開発をもうちょっとどうにかしたいと思い、会社がコミュニティのようであればと願い、わけもわからず動き回れたのは僅かに得られた手がかりと、それをともにしようとする同朋たちと出会えたからです。

長く続いた「探検」は大きく一周してここに帰ってきました。どれだけ「底」を掘り下げても、自分たちの「外」にのみ求めたとしても、迷い続けることになりかねない。道は、既に16年も前に見つけていました。1週間イテレーションで言えば832回。この時を経て、自分のジャーニーについてもう一度語ろうと思います。この道はきっとどこかで繋がっているはずだから。

もともとソフトウェア開発から始まったアジャイルという言葉は、今やプロダクト開発にとどまらずビジネス全般のアプローチとして定着しつつあります。にもかかわらず、アジャイルを導入してみたけれども期待していた効果が得られない、経営者の理解が得られない、続けられない、といった声が後を絶ちません。その背景には、アジャイルに対する理解不足や、用語やツールだけが一人歩きしたことから生じた誤解などさまざまな要因があります。でも私は「アジャイルをやってみようと思った人が、そんな理由でアジャイルを諦めてしまうのはもったいない」という思うのです。

私は2008年にアジャイルに出会って以来、15年に渡って最初はアジャイル開発受託者（POやSM）として、後にアジャイルコーチやアジャイルコンサルタントとして約50案件以上の現場経験を経験してきました。その現場から得た「理論」や「理想」だけではない、実際に実践したからこそ見えてきた「現実」に役立ったヒントを144にまとめて書籍「現場で見つけた144のヒント　アジャイルに困った時に読む本（ダイヤモンド社）」としてこの度出版させていただきました。特に、私のバックボーンである「マネジメント視点でのアジャイル」という要素を多く取り入れています。その中から本日は４つのヒントを厳選しお伝えしたいと思います。まったく同じ状況は存在しないかもしれませんが、少しでもこれらのヒントを使ってアジャイルで働く楽しさを感じて欲しいと願っています。

「エクストリームプログラミング」という単語を最初に聞いた時、皆さんはどう感じたでしょうか。

恥ずかしながら私はアジャイル＝スクラムと思い込んでおり、エクストリームプログラミングがアジャイルとどう関わっているのかも知らず、XPの白本を一度サラッと読んだだけで満足し、学びの優先度を下げてしまっていました。

そこから月日が流れスクラムマスターとして何となくチームに貢献できるようになってきたかなと思っていた頃『Clean Agile　基本に立ち戻れ』と『Clean Craftmanship　規律、基準、倫理』を読んだことで、もう一度アジャイルの歴史を学びテクニカルプラクティスの重要性について気付かされました。

• 「TDD」「リファクタリング」「シンプルな設計」「ペアプログラミング」これらがなければアジャイルは本来意図されたものではない、骨抜きにされた役立たずなものになってしまう
• TDDが要となる規律、TDDがなければ他の規律は不可能あるいは無力になる
• 最近のアジャイルコーチは、開発者にテクニカルプラクティスをコーチできるほどの技術スキルを持っていない、開発者たちはアジャイルコーチを新しいマネジメント層だとみなしている

アンクルボブの言葉が深く身に突き刺さりました。

そこから私は

改めて白本を読み直す→ピアソン社のXP関連本を古本で探して読む→『テスト駆動開発』や『Clean Craftmanship　規律、基準、倫理』を写経する→コミュニティから学ぶ→・・・

といったようにXPについての自分なりの学び直しを行い、気づいたら2023年XP祭りのスタッフに立候補していました。

そんな私の学び直しの記録と現在社内で骨抜きのアジャイルにならないように取り組み始めていることについてお話ししたいと思います。

このセッションでは「エンジニア（ソフトウェアエンジニア）がビジネスに越境するとこんな良いことがあるかもしれないよ、ワクワクするね」という投げかけをします。すべてのエンジニアがビジネスに越境するべき！なんて非現実的なことは言いませんが、一人でも多くのエンジニアがビジネスに興味・関心を持つことを目指します。

このところ「エンジニアももっとビジネスを知るべきだ」と耳にすることが増えてきました（よかったらTwitterで「ビジネス　エンジニア」で検索してみてください）。同じようなことを2020年ごろから課題感として考えてきた身としましては、そろそろプロポーザルを出して話題にしてもいいタイミングかなと思える社会的な潮目を感じます。

エンジニアとビジネス。しかも越境。このテーマだけでも、いくつも問いが浮かんできます。

まず、ビジネスとはなんでしょうか。どんな印象があるでしょうか。嫌いだけど最低限付き合い続けなければならない隣人のようだとか、自分たちには理解できない原理で構成されている得体の知れない仕組みだとか、マネジメントとかそういう領分の話でしょうとか、なんか騙されてお金を取られそうだ（！？）とか、なにもわかっていないやつらのことだとか、そもそも自分には関係ないものだから知る必要なんかないとか……。

エンジニアチームに対比する存在として「ビジネス側」という言葉を使う会社もあります。ビジネス側と呼ばれるのはどんなひとでしょうか。エンジニアリングを理解せず、リファクタリングの時間なんかもったいないから時間があったら1行でもコードを書いてプロダクトをリリースせよと圧迫する利害関係者でしょうか。現場を知らないのに人事評価を下すマネージャーでしょうか。それとも、エンジニアがもたらすユーザー価値を理解し、パフォーマンスを最大限発揮するためにあらゆる手段を講じる協力者でしょうか。

また、なぜエンジニアがビジネスのことを知る必要があるのかという問いもありそうですね。逆に捉えて、エンジニアがビジネスのことを知らないことでどんな不都合があるでしょうか。他方で、エンジニアがビジネスを知らないことで得ている利益もあるかもしれませんね。それを言語化できるでしょうか。

そしてなにより、エンジニアがビジネスに越境することで何がうれしいのでしょうか。越境を経てどんな動き方・働き方が可能になり、どんな成果に結びつけられるようになるでしょうか。この問いがおそらくメインディッシュでしょう。

越境は決して簡単ではありません。境目が存在するのは、それなりの理由があってのことで、たやすく越えられるものではないはずです。それでも、どなたかが「ちょっと、越えてみようかな」と思ってもらえるようなお話ができたらと思います。

登壇者は10年以上の経験を持つエンジニアで、主要領域は品質保証（Quality Assurance）であり、アジャイル開発を含むいくつかの領域の知見を活用しています。2022年にMBA（いわゆる、経営学の専門職修士）を修得しました。本業ではスクラムチームのメンバーとして「最高のプロダクトづくりを導く」ための活動を行っているほか、副業で品質保証のエヴァンジェリストや記事の執筆・翻訳などに取り組んでいます。

本トークではMBAで学んだエッセンスや業務経験を織り混ぜながら、ビジネスへの越境というのがどんなものかを描き出してみたいと思います。

今日におけるDevOpsは様々なコンテキストを持っています。
このセッションは、これまで実践してきた事例をいくつか用いながら、DevOpsの構成要素を紐解く手触り感のあるラーニングセッションです。
XPの白本や5つの価値基準を中心に、XPとDevOpsの共通点・相違点を理解し、みなさんの対面にいらっしゃる方からDevOpsという単語が出たときに、ビジネス面・ソリューション面から一歩先に導けるようなお話しをします。
取り扱う主なトピックは下記です。

取り扱う主なトピックは下記です。
・DevOpsとは何か
・XPと何が違うのか
・ソーシャルチェンジ
・CALMS、CALMR
・ソリューション/アーキテクチャの観点
・ポートフォリオ/エンタープライズの観点

システム思考で現場を見ていますか？
開発者、プロダクトオーナー、スクラムマスター、アジャイルコーチ。自身がどういう立場であるにせよ、チームの力を最大限発揮するには、システム思考でものごとを見ることが重要だと考えています。

システム思考とは、人や環境、ものごとがお互いにどう影響し合っているかを理解するための考え方です。個別最適化ではなく、全体最適化を図るためのアプローチとして使います。
システム思考は、複雑な問題を扱うとき、本質的な問題解決をするのに効果があります。なので、スクラムにおいて重要な考え方だと思っています。

1950年代にマサチューセッツ工科大学（MIT）のシステム・ダイナミクスという学問から端を発しています。『学習する組織』で著名なピーター・センゲがその実践を広めていきました。

「木を見て森を見ず」ということわざがあるように、人は近視眼的な思考になりがちです。チーム全体、仕事全体の視点を得るためにシステム思考は役に立ちます。

ただ、現場で実践するとなると、なかなか難しい。

「システム思考に興味はあるものの、現場で使うイメージが持てなくて…」
「そもそも、システム思考のイメージもついていないし…」
「メンバーに説明することも難しい」

こうした声は多いのではないかと思います。

本セッションでは、チーム全員がシステム思考に習熟していなくても、すぐにでも現場で使える3つのやりかたを紹介します。

ひとつは、サクセスファクター。
人と組織のシステムを描くことにより、チームの目標を合わせるツールです。

ふたつめは、現状マッピング。
チームの過去・現在・未来を可視化し、チームのボトルネックを特定するツールです。

みっつめは、みなさんもすでに使ったことがあるであろうツール。
「図を描く」ことについて説明をします。

どれも、実際に僕がアジャイルコーチ・スクラムマスターとして関わっている現場で使っているものです。
本セッションを通じ、システム思考を身近に感じ、現場の改善に役立てていただけると嬉しいです。

XP の創始者である Kent Beck が、建築家 Christopher Alexander の建築や都市の設計に関する「パタン言語」をソフトウェアに応用し、デザインパターンとし、さらに開発手法を XP として表現したと、いう説はよく知られています（XPとパターン：Ralph Johnsonの見解）。アレグザンダーは昨年他界しましたが、彼が博士論文として書いたのが『形の合成に関するノート』 "Notes on the Synthesis of Form" です。その中の付記IIでは、図形（ダイヤグラム）の数学的な扱いについて書いています。

デザインの中で、要求・適合必要条件など「ニーズ」とみなされるものと、それを満たすであろう「形」。両者の「アンサンブル」（両者の組み）にはどのような関係があるのでしょうか？以下の「人口600のインドの農村の構成」では、141の「ニーズ」を満足するデザインを、2階層12パーツの「形」に分割し、それを合成することで全体を設計する様子を示しています。

（出典：『形の合成に関するノート』より人口600のインドの農村の構成）

当然、ニーズの集合は、「こちらのニーズを満たせばあちらが満たせない」といった関係（リンク）を持っています。付記IIでは、ある条件を満足する点の集合を、どのようにサブシステム分割すれば、サブシステム間の情報伝達を最小にすることができるか、という問題を、数学的に定義し、それを考察しています。

この部分は特に数学的素養がないと難解ですが、その後のセミラティス構造（『都市はツリーではない』）にもつながる「機能の分割と合成による形の生成」の基礎になっています。

このセッションでは、パタンの成り立ちとも言える本論文を紹介し、特にその中の付記II 、すなわち数学的な扱いについてやさしく解説します。また、個人的には、将来 Conway's Law の応用である "Team Topology" についても数学的（位相幾何）な記述を試みたいと思っていて（すなわち、組織の構造とソフトウェアの構造は同相である、を数学的に導く）、その助走でもあります。

株式会社ジェーシービーは2020年4月、アジャイル開発を活用して新規ビジネスの構築を高速化する「高速化プロジェクトチーム（高速化PT）」を立ち上げました。その後、高速化PTは20のアジャイルチームを抱えるまでに急拡大し、多数のプロダクトをリリースしてきました。

皆さんのご想像に違わない保守的な金融系組織であるJCB。その組織変革の道のりは平坦ではありませんでした。このセッションでは、文化が深く根付いた巨大な金融系組織にアジャイルマインドを浸透させ、実際に稼働する複数のシステムをアジャイル開発で実現するに至るまでの、3年間の奮闘の軌跡を包み隠さずお伝えします。

アジャイル組織への変革を始めたJCB

デジタル技術の進歩が著しい昨今、JCBはお客様のニーズに合わせた価値を臨機応変に提供する必要性を痛感していました。しかしながら、一般的な金融系の例に漏れず、JCBのシステム開発では莫大な工数と年単位の時間を要するのが当たり前でした。

「このままではいけない！」

この状況を抜本的に変える必要があるという現場と経営層の想いが共鳴し、2020年4月に高速化PTが発足しました。

どのように高速化PTを拡大したか

生まれたての高速化PTには、既存システムの重厚長大な開発スタイルを変革させるだけの影響力はありません。そのため、既存システムと連携する必要のあるサービスの開発に取り組んでしまうと、本来の目的であるお客様へのスピーディな価値提供ができなくなってしまいます。これを避けるために、発足当初の高速化PTでは既存システムから独立したサービスしか扱うことができませんでした。

しかしながら、既存システムと連携しないということは、JCBの主要事業に踏み込むのが困難ということを意味します。JCBが本当の意味での変革を成し遂げるためには、高速化PTで実現されるサービスが既存システムを巻き込み、主要事業でお客様への価値提供を実現することが必要不可欠でした。

高速化PTはどのように既存システムを巻き込んだ変革を引き起こし、発足から1年あまりで20のアジャイルチームを抱える一大プロジェクトにまで急拡大することができたのか。

そこには切り込み隊長として奮闘した初期開発メンバーの苦労と努力がありました。

JCBが直面した課題と変革を主導したメンバーの奮闘

高速化PTが急拡大する裏で、

• 人材不足・スキル不足

• 当初想定したリリース時期を超過して社内外のステークホルダーに迷惑をかける

• アジャイルに対する社内の理解不足からすれ違いが頻発
  「アジャイルだから早いんでしょ？」「要件変更し放題なんでしょ？」

• ウォーターフォールとの違いから誤算が生じる

といった課題が噴出していました。アジャイルチームが増えれば変革成功、というほど世の中は甘くありませんでした。

アジャイルが社内に浸透すればするほど増える課題に、変革を主導したメンバーはどう対処していったのか。

JCBが歩んできたデコボコだらけの変革の軌跡と、その途上で生まれた奮闘記をご紹介します

・同じプロダクトを2つのチームで別々に作成し、ステークホルダーとして指摘しあった事例を基に、チームの成長をもたらしたきっかけを説明します。意図的に複数の視点で考えさせる環境を作ることで、コンフォートゾーンからの抜け出す(越境する経験を増やす)機会を増やし、チーム成長に重要な越境の視点をどのように身につけたかを説明します。

・開発者がどのように越境マインドを身につけるかの参考にいただければと考えています。

１．背景について

・我々の組織は実験的な組織であったため、ローコード開発やアジャイル開発のケイパビリティ取得が重要なテーマでした。その前提の中でどのようなプロダクトを誰向けに作っていったのか？どういう体制・スケジュールで作っていったのか？といった概要を説明します。

２．　２チーム運営について

・２チームで同じプロダクトを作るという特殊な運営を実施した背景や目的について説明します。

３．スプリントでの『越境』エピソード

・スプリントの中で今回のテーマの「越境」をどのように起こしたのか？２チームで同じプロダクトを作るという効果がどういったところにあったのか？を説明します。
　具体的には、ステークホルダーになりきる事、運用/改善についても考える事、デザイナーやプロダクトオーナーに向き合う事について、複数の委託会社での混成チームで進める事に対して、どのような問題がありどう乗り越えていったかを説明します。

４．まとめと考察

・最後に2チーム制で良かった事のまとめやメンバーの感想と今後について報告します。

※実際の講演では、実際に開発者として対応した複数の会社のメンバーの生の意見も聞きながら進めていこうと考えています。

国をメタファーに使い自分自身とお互いの価値観を知るワークショプです。
今回は内発的動機をテーマに行いたいと思います。

このワークショップでは、
・国づくり
・国際交流
の２つのメタファーを通して、自分自身の価値観や、自分とは異なる価値観の理解を深めていくことを狙いに考えました。

国づくりでは、同じ価値観の参加者で即席の国(グループ)を作り、
・国旗を作る
・おもてなしの準備をする
といったアクティビティを通して、自分たち自身の価値観を言葉や絵で表面化していきます。
たとえば国旗デザイン一つをとっても、なぜその色にしたのかという意図を説明することで気づきを得られるはずです。

国際交流では、他の国を観光することで他の価値観への理解を深めていきます。
どんな文化の国なのかを理解しようとする観光客のロールプレイを行うことで、自身のバイアスを取り除き好奇心を持って他の価値観に触れることができることを狙っています。また観光客を受け入れる側は自分たちの国について言葉にして説明するというプロセスを通して、より自分たちの価値観に気づくことができるはずです。

社内向けに考えたワークショップのためまだまだ荒削りですが、みなさんが自分の価値観に向き合うきっかけになると嬉しいです！
また相互理解や関係性に関するワークショップを考えようとしている方も歓迎です。

※スクラムフェス大阪2023の宇都宮会場で開催したものをアップデートしてお届けします！
※このワークショップを考えるにあたり、シリアスプレイやORSCの考え方からヒントを得ています。ありがとうございます。

XPのサークルオブライフ（『Clean Agile』によると12のプラクティス）には、ビジネス・チーム・テクニカルで4つずつのプラクティスがあります。
本ワークショップでは、このうちのテクニカルプラクティス（特にテスト駆動開発とリファクタリング）にフォーカスします。
ハンズオンとぶつかり稽古を通して、テクニカルプラクティスを見つめ直してみませんか？

キーワードは「小さい」です。
達人のテスト駆動開発やリファクタリングは小さいステップをたくさん実行します。
『Clean Craftsmanship』や『The Art of Agile Development, 2nd Edition』で知って私は「自分のやり方クソデカすぎたじゃん...　今までやっていたものはなんだったんだ...」と愕然とするとともに、真似てみたらそれまでよりもTDDやリファクタリングがやりやすくなりました。
小ささはXPの価値（特にフィードバック）と関わるように私は感じており、この視点をワークショップで共有でき、実践者を増やす機会となったらこんなにも嬉しいことはありません。
小さいは正義、なんだよ！ 小さいTDDや小さいリファクタリングを一緒に体験しましょう〜

教育心理学概論　という本をご存知でしょうか？

2016年のXP祭りビブリオバトルでチャンプ本となった本で、アジャイルやスクラムと直接関係があるわけではないのですが、コミュニティの中で話題に挙がることがしばしばある本です。
参考：出版社への感謝から始まったビブリオバトル

私は、ビブリオバトルで選ばれたのを機に2016年末に始まった読書会でこの本に触れ、それ以降この内容が好きになって、読み直したり、関連する本の読書会に参加するなどを続けています。

先日は Shinagawa Agile Talks に呼んで頂いて、この本に関連する内容についてお話する機会もありました。

教育心理学概論にどんなことが書かれているのか紹介するために、p.3「まえがき」に記載されている内容を引用します。

教育心理学は, 人が賢くなる仕組みを明らかにして, 人をより賢くするにはどうしたらいいのかを探る研究分野である。人は生まれつき身の回りにあるものごとや自分が経験したことの中に規則を見出す仕組みを持っている。自分の経験と他人から聞いたことを結びつけて視野を拡げる仕組みも使える。
〜中略〜
教育心理学の研究成果は, 学校など学びが起きる現場での人の賢さを育てることにつながる。

学びはアジャイルやスクラムにおいて重要な要素の1つだと思いますので、このような「人の学びについて学ぶ」ことに興味を持って頂ける方も多いのではないでしょうか。

一方で、（教育心理学概論はページ数もあまり多くないですし、やさしく書かれている本ではありますが）技術書などとは少し毛色の異なる本を自分で読むことに躊躇いがあったり、自信がない方もいらっしゃるのではないかと思います。

そのため、今回、教育心理学概論に書かれている内容がどんなものなのかを知るためのワークショップを開催したいと考えています。

実施内容は基本的には読書会の形になりますが、教育心理学概論でも紹介されている知識構成型ジグソー法 を使って、複数人が協力しあって、本に記載されている内容を理解していくことを考えています。

どのようなことを行うのか、大まかな流れを紹介します。

• まず、教育心理学概論の内容を大きく3つのテーマに分けます（詳細は検討中ですが、例えば「素朴理論」「建設的相互作用」「熟達」といった内容）
• テーマごとに2〜4人のグループを作り、教育心理学概論に記載されている内容を確認したり、理解するためにグループで話し合ったりします（エキスパート活動）
• 次にそれぞれのテーマを担当していた人たちが1人ずつ集まって、3人のグループを作り、お互いが学んだ内容を共有しながら、教育心理学概論にどのような内容が書かれているかについて話合います（ジグソー活動）
• 最後にジグソー活動で話した内容について、他のグループに対して共有を行います（クロストーク）

このワークショップを通じて、教育心理学概論に書かれている内容のおもしろさを知って頂くのと同時に、複数人で本を読むことで色んな観点から掘り下げることができる楽しさを経験して頂けたら嬉しいです。

※オンサイトのみの開催となります。オンラインには対応していません。

※最小開催人数を6名、最大開催人数を12名としたいです（人が足りない場合には、小笠原も参加します）

※当日の参加希望者が5名に満たなかった場合、実行委員の方などで人数を補って頂けるとありがたいです

※教育心理学概論はこちらで用意しようと考えていますので、参加者で用意して頂く必要はありません

WF歴１０年、アジャイル歴１年と少しの自称アジャイルエンジニアです。

入社してからずっとWF型の案件で、チームリーダーやPjMを行ってきました。

WF案件の中ではアジャイルではアンチパターンとされるような強制で仕事を割り当てたり、マイクロマネジメントに近いようなことも多く行ってきました。

うまくいった案件もあれば、自分自身もボロボロになってしまったような大変な案件もありました。

自分一人がPjMとしてできることに対しての限界も感じていました。。。

そんな私がアジャイルと出会ってそれを学び、今は一つのチームにアジャイル文化を導入し定着させるべく奮闘しています。

そんな中で苦労したこと、頑張ったこと、お話しさせていただきたいと思います。

これからのシステム開発の現場では、同じように仕事の進め方を見つめ直さなければいけない場面がたくさんでてくると思います。その際の一助になれば幸いです。

多くのアジャイルのプラクティスがそうであるように、ペアプロに関しても奥深いものがあると感じています。

私がいる現場では、フルタイムでペアプロ（とTDD）を実践しています。

私自身が現場にJoinして、ペアプロの経験値も2年溜まったところで改めて実感したのは、ペアプロはスキルです

スキルなので伸ばすことが出来ますが、逆に言うと意識をしなければ、なかなか伸びないものだと感じています。

2年経った今でも、こうやってペアプロをすれば良かったなと、何度ものびしろを感じる場面があります。

私自身ペアプロのスキルはまだまだだと思っています。だからこそもっと上手くなりたい。

この機会に自分なりのよりよい「協力的な」ペアプロについて思っていることを、実践していることを自分なりに整理してお伝えしようと思います。

カオナビ社の開発チームに在籍しており、日々多くの開発やチーム課題と向き合っています。

その中で救いを求めて「スクラム」を導入しようとしたのですが、根本的な課題にぶち当たりました。

それはスクラムマスターの行動原理をチームリーダーである私が理解できなかったことです。

より原因を突き詰めていくと「サーバントリーダーシップ」を当時の自分はまるで理解できていませんでした。

そんな中「とある気づき」を得て、スクラムマスターに成るために、ギャルを目指してみることにしました。

そうすると、だんだんとチームの課題が減っていったり、モチベーションが上がっていったり、効果を観測することができるようになってきました。

このセッションでは、その取り組みの中で得られた学びや工夫を含めた一部始終を共有します！

突然あなたの所属するプロジェクトがアジャイルからウォーターフォールになったら、どうしますか？

完全なウォーターフォールにならないまでも、ウォーターフォール的な動きやドキュメントを要求されたら、どうしますか？

そんな巻き込まれ型のプロジェクトでやったことについてお話します。

モブプログラミングはとても強力なプラクティスではありますが、時間や距離の制約やメンバーの意識など、うまくいかない事も少なくないと思います。

私も一度モブプログラミングをチームに根付かせる事に失敗した経験を持っています。

しかしEssential Mob Programmingの上級モブに憧れてしまった私は、どうしてもモブプログラミングでいきいきと開発できるチームをつくりたかった。

そんな私がチーム改変を機に改めてスモールステップで少しづつモブプログラミングを楽しめるチームを作ってきたお話をしたいと思います。

私は元々、ガチガチのウォーターフォールの現場でテスト担当者として働いていました。そこから色々あってアジャイルなプロダクト開発に関わるようになりましたが、テストの進め方や考え方は以前と随分異なるものでした。このセッションでは、テスト担当者としての私がアジャイルなプロダクト開発にどう適応していったかを話します。

XPのプラクティスと言えばTDDやユーザーストーリー、ふりかえりなど様々なものを思い浮かべるかと思います。それぞれのプラクティスは、独自の価値を持ち、チームの生産性やソフトウェアの品質に対して影響を与える役割を果たします。

私がXPについて学習し始めたばかりの頃、これらのプラクティスはそれぞれ孤立したものであると感じていました。しかし、実際にそれらを掘り下げて適用するなかで、一つ気付いたことがありました。それは、各プラクティスが孤立して存在するのではなく、互いに結びつき、相互に影響を与えるということです。

本プレゼンでは、どのように個々のプラクティスが他のプラクティスと関わり、全体としての力強い協調作用を生み出すのか、私自身の経験から学んだ教訓と共にお伝えしたいと考えています。この教訓が皆さんのXPの実践に役立てれば幸いです。

今の私達のチームは去年の8月末からスタートしたチームで、立ち上げからちょうど1年が経ちました。
私は新卒として立ち上げ時から参加し、このチームでスクラムを学んできました。

私達のチームのミッションは会社としてもチャレンジングなことでした。
弊社KDDIアジャイル開発センター株式会社は、KDDI株式会社の一部署が独立して去年事業を開始した新しい会社です。
部署時代はKDDI社内の案件を担当していました。
それが会社化されることで社外の案件も取り組めるようになります。
私達のチームが担当したのは会社として、そして部署時代も含めて初めての社外の案件でした。
いわゆる一番槍であり、社内からの期待は高く、注目されていました。

初めてのことなので、当初はどうなるだろうという不安がチームにはありました。
しかし立ち上げから4ヶ月後に最初のリリースができた段階で、非常にうまくいっていると、発注元のステークホルダーの方々や社内から高い評価をもらうことができました。

本セッションでは、私達のチームが高い評価をもらうことができた理由を、スクラム初心者の視点でお話したいと思います。
具体的には、立ち上げから1年間の私達のチームの良かったところと、改善してきたこと・改善したほうが良いことをお話したいと思います。
また、新入社員としてスクラム未経験から1年経った今までの自身の成長や心境の変化もお話できればと思います。

このセッションでは、「Fearless Change」のパターンランゲージと心理的安全性の概念の組み合わせを探求します。「Fearless Change」の戦略を用いて組織内で新しいアイデアを普及させ、その中で心理的安全性を保つことの重要性と方法について深く理解し、具体的な行動に移すための手法を学びます。また、Michael SahotaのCulture Bubbleモデルを参考に、組織のカルチャーシフトを促進する具体的な戦略についても議論します。

東京都庁でのアジャイル推進の事例を紹介いたします。

現在、東京都はDXに全力で取り組んでいます。

業務改善・業務改革、より良い行政サービスを実現するためにアジャイル開発は不可欠なものと考え実践を重ねているところです。

本セッションでは東京都デジタルサービス局が中心となりアジャイル開発の事例やパターンをまとめた「都庁アジャイルプレイブック」を紹介します。

• 従来と異なる手法であるアジャイル開発の始めかた

• 事業部門と開発チームとのコラボレーションの工夫

• 進める中での課題・改善の事例

などなど、公共分野ではない方々にも参考にしていただける内容です。

本プレゼンは、同名の下記Qiita記事を元にしたものです。

だれかの進捗をうまく把握できないときのフレーズ集

ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。

筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。

しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、

• 進捗はどうですか？ → 進行中です／〜をやっています
• なにか問題はありますか？ → とくにないです
• 〜までに終わりそうですか？ → たぶん大丈夫だと思います

というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。

この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。

当日は、プレゼンを聴いてくれている方々の「わたしのフレーズ」も集めたいと思っています。

みんなの工夫を集結して、最高のフレーズ集を作りましょう！

普段、テスト駆動開発でお仕事をすることが多いのですが、普段の生活にも取り入れられないかと考え、ダイエットに応用してみました。

結果、失敗したのですが、その後、目標体重まで達したのでその経過を共有したいと思います

新たな挑戦が待ち受ける、ソフトウェアサービス会社の一人目QA。そのわたしが託された使命は、奇跡的に弊社に内定を承諾してくださった半年後に入社する二人目のQAを絶対に逃さず、そして彼が入社初日から全力で活躍できるステージを準備すること。そんな一見不可能に近いわたしの任務の行方は？

週一の1on1、二週間に一度の飲み会、そして社内イベントへの誘い…。一筋縄ではいかない作戦の数々。しかし、果たしてそれは本当に彼を確保し、最高のパフォーマンスを発揮させることができるのか？

わたしの挑戦が始まったとき、誰もが疑問を抱いていた。だがわたしの取り組みがもたらした結果は、全員が認めざるを得ない明確な成功だった。それはただ一人の新入社員が圧倒的な存在感を発揮するだけでなく、全社のオンボーディングプロセス改革の可能性をも開くこととなった。

これが、ただ一人のQAが描く、未来のオンボーディングへの道のり。その軌跡と共に得られた教訓、それら全てをこの登壇で明らかにします。まだ誰も見たことのないオンボーディングの形、一緒にその先を見てみませんか？

スクラムマスターとしてフリーランスの採用面談をいくつか受けていて気になったことは、スクラムマスターがパフォーマンスを出しづらい環境が非常に多いことである。また、事業会社で働いていたときも、同様の問題で多くの同僚が困っていた。
そこで、スクラムマスターがパフォーマンスを出せるとチームは、どのようになるのか、そのためにはどのようなことを気をつければよいのか紹介する。

皆さんは自分がやりたいこと、続けたいことを簡単に習慣化出来ますか？ちなみに私は全然出来ません。ただ、そんな私でもいくつかは習慣化出来たことがあります。例えば、朝読書した感想をツイッターに放流するとか、Duolingoをなんとなく続けているとかなどなど。

こうやって続けられていること、失敗して続けられなかったことを比較して「自分はこうやると習慣化出来るだ」ということがやっと見え始めました。このセッションは私の素朴理論としての習慣化する技術を紹介しつつ、このセッションを聞いてくれた方が明日にでも使えるようなノウハウを1つでも持ち帰ってもらいたいと思っています。

3日坊主でほとんど失敗続きのなか、どんな観察をして、そこからどんな気付きを得たのかという素朴理論を言語化したいと思います。

アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが必要になります。また、アジャイル開発を実践していく上ではスクラムのみならず、XP（エクストリームプログラミング）や他の手法からもプラクティスをピックアップして「自分たちのやり方」を作っていくことになります。その際にも様々なプラクティスについて、定義だけでなく、実践する意味、できた歴史的背景、トリビアが知りたくなるでしょう。

私たちはアジャイル開発をはじめたい人向けに、重要な語彙を整理したアジャイルプラクティスマップを作成しました。このセッションでは、その一部である「XP中央線」から3つの駅を選んでぶらり途中下車していきます。

以下のプラクティスを取りあげます。

• ペアリング・モブプログラミング
• ユーザーストーリー
• メタファー

ご紹介するプラクティスに関する質問にもお答えしていきたいと思います。

水平思考クイズとは、「出題者が読み上げる謎の物語に対して、回答者が「はい」「いいえ」「関係ありません」のいずれかで答えられる質問を繰り返すことで状況を整理し、真相を推理する形式のクイズ」のことです(古川洋平著. ひらめき脳を鍛えるナゾトキ水平思考クイズ(幻冬舎)紹介ページより, https://www.gentosha.co.jp/book/detail/9784344979840/ )。

この水平思考クイズでは、1つの出題から複数の回答が想像できることが多いですが、正解は出題者が決めた1つだけです。
この「1つの出題から複数の回答が考えられる」という点、テスト中に遭遇した不具合の原因を考えることに似ていませんか？
見た目は同じ不具合に見えても原因が異なることが多いため、不具合から原因を見つけるというスキルはテストに必要だなぁと思っています。

なのでこのセッションでは、この水平思考クイズのテスト版をやってみようと思います。 私が実際に経験した不具合を出題するので、参加者の方は回答者になって私に質問して不具合の原因を当ててください。 参加者の方と一緒に不具合の原因を想像して、そこで出た質問(気になる点)や答え(不具合の事例)を持ち帰ってもらえたらと思います。

※ お題は以下のようなものを予定しています(当日変わる可能性があります)。
・スマートフォンのアプリを起動してしばらく放置するとアプリがクラッシュした
・パスワード変更ページでパスワードを変更したら他のブラウザでログインできなくなった
・注文してないのに注文したメールが送信された

2016年1月10日Ryuzeeさんにより日本語訳された「スクラムマスターを雇うときに聞いてみるとよい38個の質問」が公開されて以降、熟練スクラムマスターが回答したBlog記事がたくさん公開されました。
（原文：「Hiring: 38 Scrum Master Interview Questions To Avoid Imposters」）

しかし、スクラムマスターを目指している人が回答した記事や内容は、あまり見かけないのではないのでしょうか。

本セッションでは、スクラムマスターを目指す私による回答を題材として使用し、参加者の皆さんが熟練スクラムマスターの関と一緒になってフィードバックをしていきます。

フィードバックを通じて、皆さん自身がスクラムマスターとして正しく振舞えているか、質問する側の期待に沿った回答ができているかを確認し、日々の振舞いを改善するきっかけとしていただければ嬉しいです。

■ 参加型セッションの進め方

・チャット（Discord）に「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に対する私の回答を流します。

・気になった回答内容に、本セッション参加者からフィードバックを返信コメントでコメントいただきます。

・本セッション参加者からいただいたフィードバックを元に、熟練スクラムマスターによる良いフィードバックのポイントを概説します。

こんにちは！私たちはパタン・ランゲージに興味を持ったソフトウェアエンジニアの3人です。このセッションでは、「パタン・ランゲージをまちづくりに取り入れた街『川越』」に私たちが実際に行って体験したこと、またそれを通した気づきについて語ります。

私たちは、良い雰囲気のチームに再現性を持たせるためには「チームのパタン・ランゲージ」を作ればよいのではないかと考えました。それこそ、アレグザンダーが町並みに現れる「名付け得ぬ質」に再現性を持たせるためにパタン・ランゲージを提唱したように！

川越には『まちづくり規範』というパタン・ランゲージを文書化したものがあります。私たちはそれを手に川越の街を散策しました。最初は何となく風情や雰囲気が良いと感じるだけでしたが、パタン・ランゲージのレンズを通して街を見るとその魅力的な要素がより明確に浮かび上がってきました。

本セッションは以下のような構成を予定しています。

• そもそも、パタン・ランゲージって何？
• なんで川越なの？
• 川越に行ってどうだった？
• 3人が得たものとは。そこから導いたチーム開発における仮説
• 仮説をもとに試してみた！結果はいかに...

また、本セッションを聴いてくださった方には以下のようなアウトカムが得られることを期待しています。

• 「パタン・ランゲージって何それ美味しいの？」って人には...
  • パタン・ランゲージについてもっと知りたいと思う気持ちを。
• 「パタン・ランゲージは聞いたことがあるけど、そんな言うほど活用したことないなぁ」って人には...
  • 良いチームに再現性をもたらすための思考・取り組みを。
• 「もうパタン・ランゲージを活用しているよ！結構いろんなことを知ってるんだ！」って人には...
  • パタン・ランゲージを「体験」した3人の話から得られる新しい視点を。

アジャイルを実践する人々にとって変化とは愛し抱擁するものであり、そのマインドセットは生き方そのものでもあります。コミュニティで出会う方々はアジャイルを啓蒙するために燃え盛る情熱の炎をその身に宿してスクラムやOKRといったプラクティスを学び、持ち帰り、そして仕事に取り入れています。ところが現場には抵抗感が漂い動機なきスクラムはゾンビとなりOKRはKPIの延長になってゆくという悩みを持っている方がたくさんいました。私もアジャイルに触れて熱狂し、無理のない範囲でプライベートの時間もコミュニティ活動に身を投じる一方でそこで学んだことを組織にうまく響かせることができずに苦悩しました。そして「どうしたら同僚に、組織に、変化を起こせるのだろうかと」自問する中である信条を思い出しました。「いつでも変えることができるのは自分だけ」つまり裏を返せば他人を変える、ましてや組織という多数の人の集合体に直接働きかけて変えることなどできるはずがないと思い至りました。

さて、今あなたはどう感じたでしょうか。「では変化を諦めろというのか」と激昂したでしょうか。「自分に変化なんて起こせないのか」と落胆したでしょうか。「これまでの努力は無駄だったのか」と悲嘆したでしょうか。あるいはもっと別の感情かもしれません。私は「自分以外は変えられない」という考えに触れて抱いた感情、自分に対する怒り・悔しさ・悲しみに気づいた時にその根本にあった一つの事実と向き合うことができました。「『変えよう』と他者に働きかける自分を変えられていない」ということに。

私はアジャイルを学んだことで自分に変化が起きたと思い込んでいましたが本当に起きていたことは「ずっと心のなかにあった価値観が顕在化した」に過ぎないと考えるようになりました。これまでの人生を経て培ってきた信条にアジャイルという名前が与えられ、それを周囲に浸透させるためのプラクティスという武器と戦いに赴く勇気をくれるコミュニティという仲間を得ました。結果的に私に起きた変化といえば大義をふりかざし主張するようになったくらいのもので、到底アジャイルのマインドセットを体現しているとは言い難い状態でした。

このことに気づいた時、私は武器を起き対話を始めました。色々な人と1on1を通じて一人ひとりを知っていく活動を始めました。そして偶然にもそのタイミングで新しいチームが発足しそこでもいきなりスクラムを組み込むのではなく、メンバーがチームに求めているものは何か、組織からの課題にチームとしてどう向き合いたいかといった事柄について共通の理解を構築してその状態に向かうための方法を一緒に考えました。チームとして理想の状態を作るために一定期間ごとにどんなタスクに取り組むのかをプランニングし、日々の取り組みの中でできたことや公私を問わず助けてほしいことを共有し、プランニング期間の最後に達成できたことやできなかったことやプロセス自体について振り返る。このサイクルを続けていく中で少しずつチームの開発はスクラムの形に発展していきました。完璧なスクラムでなくても継続したことで計画したタスクはバックログとなり、３ヶ月が過ぎた頃にはチームとしてどの程度のタスクが捌けるかが見える状態になっていました。

思い返せば変えたものはたった一つ、私のアプローチだけでした。自分の状態に気づき（マインドフルネス）、周囲の人間の声に耳を傾け（傾聴）、チームメンバーのために奉仕し（サーバント・リーダーシップ）、淡々と改善のためにできることを一つずつ進めていたら小さくても確実な変化が起き始めていました。RSGT2023に参加してからの約半年間の経験で私は無理に変えずに変わるという変化の戦略的アプローチがあることを学びました。各地スクフェスなどで学んだ「マインドフルネス」「傾聴（Ozawaさん「なぜ『聴く』ということは難しいのか」、えわさん「相互理解を目指す対話主体のコミュニケーションで心の負担を軽減し持続可能な組織変革を」）」「サーバント・リーダーシップ（piyoさん「チームにノリをもたらした時にいた「二人目に踊る人」の共通点」）」など、自分で実践できることに取り組みました。そしてコミュニティからはLyssaからアジャイルを実践する勇気、烏帽子さんから一人でも踏ん張る勇気、おーのさんから無理をしない勇気、Danielから挑戦し続ける勇気と本当にたくさんの勇気をもらいました。

とあるシステムの開発プロジェクトにて、一人のリーダーが発した言葉。
「なんだか会議の雰囲気暗いね。もっと明るく楽しくしようよ！」
この言葉に衝撃を受け、「明るく楽しい会議」を目標に何かしたいと行動することになりました。

社内のコミュニティやプロジェクトの各チームのリーダー・PMの協力を得ながら試行錯誤を繰り返した結果、少しずつ効果がでてきました。
この取り組みによって、会議はどうなったのか、何が変わったのか、実際にやってみた具体的な施策を交えてお伝えしたいと思います。

文章を書くという行為は、すなわち世界を変える第一歩です。このセッションでは、自分の想いを引き出し文章を書きたくなる方法をワークショップ形式で実践します。

本橋さん、高柳さん（ガオリューさん）とのコラボレーションワークショップです。

みなさん、Fearless Journeyというゲームをご存知ですか？
このゲームは、パターンを活用してチームの目標を達成する戦略ゲームです。
パターンは、書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」に記載のパターンを用います。

このゲームは、実際のチームが、実際の課題を解決するために使えるゲームです。
本ワークショップは、参加者同士でFearless Journeyを遊びつつ、ファシリテーションのノウハウを自社に持って帰ってもらうことを目的としたワークショップです。

ワークショップの流れとしては、Fearless Journeyをしてから、Fun! Done! Learn! でふりかえりをします。

セッション概要

本セッションでは、学生時代に3回世界一を経験した自分が、メンタルヘルスを意識して積んでいたトレーニングをお話することで、エクストリームなストレスとの付き合い方をメンタルヘルスに不調を抱えていない人ができるようにすることを目指します。

なお、自分はメンタルヘルスの専門家でなく、過去の話で記憶が美化されている可能性も高いため、すべてを真似をしようとするのではなくAdvancedセッションとして楽しんで聞いてもらえると幸いです。

セッション詳細

自分が世界一を獲得した3回のうち、どのときも共通してメンタルヘルスのトレーニングを重ねていました。
本セッションでは、このメンタルヘルスについて以下の観点で話をしてみようと思います。

• ストレスとの付き合い方
• いわゆるフロー状態を呼び覚ますためにやっていたこと
• 自分が独自に実施していたメンタルヘルストレーニング

ただし、これらの観点で提示されるものはいずれもエクストリームなものであり、万人が行えるトレーニングではないため、特にメンタルヘルスに不調を抱えている方は真似をしないことを強く推奨します。

あまり知らない相手に話しかける、これ自体とても勇気がいることです。
ましてや違う会社・違う部署の人に話しかけ、協力を求めることって大変ですよね。
相手は相手で仕事を抱えている、なんか忙しそう、そーいや過去、自分と相手、自分の部署と相手の部署ってぎくしゃくしたこともあったよな、そんな中時間をさいて新たな仕事の協力をお願いしていかないといけない。。
想像するだけでも、不安となり、難しく感じるのではないでしょうか。

小さい頃から緊張しがちで気の小さい自分は特にそうでした。
とはいえ、何か新しいことをやっていくためには、他者への協力を求めること、必ず通る道です。

ここでは、ぎくしゃくしそうな、見知らぬ、忙しそうな相手の協力を求める、その求めかたについて、一緒に学んでいきたいと思います。

特に事前準備などはいらないとは思いますが、過去とても辛い経験をされたことがある方はご無理せずにした方がよいかも。

改善が停滞しているチームというのは、現状のままでも特に問題ないと思い込んでいるが周りから見れば課題がある、言い換えると『負の成功体験』が課題発見を阻害している、という特徴を持っています。

本セッションでは、改善が停滞しているチームに対して、『負の成功体験』を脱却させるための強いエネルギーをどうやって外から作用させ、改善を再開させるかについて、概説します。

自分たちだけでの改善が行き詰っているチームに、何らかの良いヒントとなれたら嬉しいです。

日本初のスクラム本が発売されてから今年でちょうど20年。その節目に、翻訳者のひとりである今野睦さんにBeyond The Timeということで、当時のことをエピソードなどを交えて、いろいろと質問しちゃおうという企画です。セッションはいくつか用意した質問をインタビュー形式で話をお伺いする予定です。当日の流れ次第では話が脱線してあらぬ方向へ行くかもしれませんがそれも含めてゆるくお楽しみいただければと思います（笑）

＜本の情報＞

名称：アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

作者：ケンシュエイバー,マイクビードル,テクノロジックアート,Ken Schwaber,Mike Beedle,

長瀬嘉秀,今野睦,スクラムエバンジェリストグループ 

出版社/メーカー：ピアソンエデュケーション

発売日：2003/09

https://books.rakuten.co.jp/rb/1593751/

2001年にアジャイルソフトウェア開発宣言（アジャイルマニフェスト）が公開されてから20年以上経ちました。当時は先進的だったマニフェストも、現在では当たり前のことのようにも思えますし、むしろちょっと古臭さも感じます。

これまで、各所でアジャイルマニフェストを刷新したほうが良いのでは？という意見が上がってきています。

アジャイルマニフェストを刷新しないまでも、新たに、Alistair Cockburn氏のHeart of Agile、Joshua Kerievsky氏のModern Agileのように、独自の原理原則を作って使っていく流れもでてきています。

2023年時点でアジャイルマニフェストは改訂されていませんが、この数年で世界は大きく変わっています。
アジャイルマニフェストも、時代の変化とともに、必要であれば変化していく必要があるのではないでしょうか。

本セッションでは、アジャイルマニフェストを時代の変化に合わせて改訂するなら、どのような変容になるかを探求していきます。単にアジャイルマニフェストをカスタマイズするのではなく、アジャイルマニフェストの本質を読み解きつつ、良いところは残し、変えるべきところは変える、アジャイルマニフェストの進化を、そして、世界を「生き生き」とさせるために何が必要かを考えてみましょう。

最後に、私の提案する「生き生きマニフェスト（仮）」をご紹介します。

世の中にイノベーションを起こす原動力の１つであるスタートアップ。スタートアップで効果的に機能するアジャイル、リーンスタートアップ、デザインシンキングなどのプラクティスに関する研究も盛んに行われ近年では数十の論文が出揃いました。

自分はスタートアップに身を置いてこなかったのもあり、論文からも勉強してみました。今回はこれらの論文をまとめて紹介します。

人やチームの関係性について学び始めると待ち受けている罠 (https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18305/2023-saga-of-the-psychology-the-evil)の各テーマの最後のスライドで表示していた引用について語ります。本編では9割以上触れることはありませんでした。今回は逆に本編には触れず引用への想いだけを語ります。なぜこの引用なのか気になった方や引用元について想いがある方は覗きに来て下さい。

ソフトウェア開発のアジャイルプロジェクト自体は急速に増えてきました。そんな中、企業組織の中でアジャイルな活動がうまく根付かせ継続できていない、複数のアジャイルプロジェクトがうまく連携できていない、企業活動とアジャイルチームが噛み合っていない、アジャイルチームだけでなくそれを包含する組織自体も変わっていかなければいけない、そんな課題をお持ちではありませんか？

本セッションでは、企業組織やコミュニティ組織がどんな状態になってほしくてアジャイルをやっているんだろうか、という問いに対し、IPA独立行政法人情報処理推進機構アジャイルワーキンググループの活動の一環として、組織的にアジャイル導入を検討するリーダーのために、組織が幸せであるとはどういう状態かを言語化し、ゴールやそこに至るまでのギャップやアクションを整理・洗練させた「組織を幸せにする組織アジャイル5つの原則（略称：ソシアジャ五良核）」について概説します。

１．同じ方向性を向いて働けている
２．お互いに協働できている
３．お互いに敬意を持っている
４．組織も個人も成長できている
５．ビジネスが持続的に回せている

組織的なアジャイル導入にこれから取り組みたい、複数のアジャイルチームを連携させたい、開発 以外の組織にアジャイル的なマインドを広げていきたい、等々で今まさに苦労している方々のお役に立てれば幸いです。