Extreme Programming 第一版が改訂され Extreme Programming の第二版になったときに、Kent Beck 氏は、「ぼくは考え方を変えたんだ」と述べています。それまでは、XPを普及させていくために「敵」を倒したり、相手を「説得」して周囲を変えていくという考え方。その後、AI=Appreciative Inquiry (相手の価値を認めることから始める探索）を知って、また、数多くの実践経験の中から、「相手を変えない」やり方を見つけていったとのことです。

このセッションでは、Kent との会話を思い出し、「自分」と「世界」とのよい関係の作り方について、私の経験やこれまでのアジャイル普及の中で考えたことについてお話ししたいと思います。

皆さんは、システムのテストをする際に、次のような問題を経験されたことはないでしょうか？

• テスト環境の準備の工数がバカにならない
• テストデータを複数人・チームで共有していて、気軽にテストできない
• 外部サービスと接続できず、必要なテストができない

これらの問題は、開発者・QAなどのシステム関係者にとって、テストに対する非常に大きな技術的・心理的障壁となります。加えて、十分なテストを行えないことによる本番障害の多発にもつながります。

私たちのチームは、これらの問題を解決すべく、Cloud-native技術を駆使して、2020年に「Testable Infra」という社内インフラを構築し、運用を開始しました。加えて、これを複数のシステム開発プロジェクトに導入し、実際に上述のテストの諸問題の改善という成果が出始めています。

このセッションでは、「Testable Infra」のコンセプト、設計と技術の詳細、およびこれを活用したシステム開発の未来像についてお話しします。

なおこのセッションは、2020年12月に中国で開催された「TOP100 Summit 2020」で発表した『Make testing easier technically and psychologically with Kubernetes - Innovation of testing distributed systems with "Testable Infra" -』を大幅に加筆修正し、日本語で発表します。

※4/16にDevOpsDays Tokyo 2021でお話させていただく予定だった内容になります。

XPの書籍を読んだことはあるし、各種プラクティスをやったことはあるけど。っていう人間がXPを理解しようとつとめてわかったことを発表しようとおもいます。クリストファーアレグザンダー著のNature Of Orderからヒントを得て、XPをアレグザンダー的にひもといてみるという試みです。わたしがXPからどのような影響をうけているのかもわかってきました。

XPという「社会変革ムーブメント」における「生命構造」を「15の幾何学的特性」と共に理解し、XPの価値、原則、パタンの構造やプロセスの美しさを見ていきます。そうして私が感じたXPをより発展させたいがための私としてのアイディアを提案させていただきます。

10年ぐらいアジャイルコーチを経験してきて、営業とマーケ > PO > 開発 > テスト > リリース > CSやCX とプロセスを一通り経験してある程度、改善を進められるようになったのですが、アジャイルテスティングがなかなか倒せません！（現在約5年目に突入）

よって、ちょっと心を落ち着けて、倒せない敵がどういったものなのかを考えるセッションです。

XP祭り初のビブリオバトルで川鯉さんが優勝した『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか？複雑な問題をペア作業によってどのように進めていくのか？に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

２つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

本セッションでは、「ボビンの論文」を機械翻訳をかけながら読むことを通じて、理解とは何か、ペア作業の効果に関する新しい視点を得ることを目標にしたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

事前の準備は不要ですのでさらっと来ていただければと思います。

意思決定。我々は個人でも、チームでも、たくさんの意思決定をしながら働いています。ひとつひとつの意思決定が、アウトカムに通じている。そう言っても過言ではありません。

例えば、スクラムにおいてはどうでしょう。プロダクトオーナーは、プロダクトバックログアイテムの優先順位を決めます。開発者は、アーキテクチャからコーディングルールといった開発に関すること。スクラムチームとしては、レトロスペクティブでどういった改善をしていくかを決めていきます。

この他にも、様々な場面で、様々な意思決定が、個人にもチームにもあります。このひとつ一つの意思決定が、チームのゴールへと結びついていればどれほど良いでしょう。

良いチームは、良い意思決定が作る。そんなお話しをします。

According to Jeff Sutherland, one of the co-founders of SCRUM, backlog refinement forms the backbone of a functioning Scrum Team. However, the Scrum Guide is largely silent on how this important event can be successfully established in the development process. The document only devotes a short and concise paragraph to the event.

 Sutherland's statements on backlog refinement were confirmed during the development of automated scheduling software for ground handling services at a large airport in northern Germany. The event became one of the key success factors in realizing the agile project. And that despite or precisely because the prerequisites for the project were very challenging:
- a brief vision and no formulated requirements for the product
- a large number of the software critical stakeholders
- No possibility to involve business analysts
- a managing director as product owner who was only available to the team part-time
- Expert knowledge that was only available in the respective silos
- a complex product portfolio with many dependencies between the different solutions
- the risk of chain reactions at the airport in the event of delays, endangering the transport of passengers on the same day or losing important slot times for the airspace

In his lecture, Nils Hyoma shows how his team successfully solved complex challenges with good backlog refinement. The team was gradually able to integrate critical stakeholders in a targeted manner. The software developers have taken on the responsibility for determining the requirements, resolved dependencies through collaboration with other teams and coordinated the releases.

 In addition to the actual task of developing software, the planned and structured backlog refinement event gradually became the engine of change management and the agile and digital transformation of the airport.

 The practical talk takes up real project situations and problems. Nils Hyoma summarizes the experience gained in the agile project in a highly complex environment. He explains how and why a well-carried out backlog refinement can become a key success factor in agile projects.

小さいカイゼンを回し始めて、ふりかえりや昼会、チームミーティングや相談会などがまぁまぁうまくできるようになったチームの紹介をします。チームはリモートワークをしているので、チャットツールSlack、バーチャルオフィスoVice、情報共有サービスesa、タスク管理ツールasanaなどのツールを使っている様子の紹介もします。

【追記】

こんな内容を話そうかと思ってます。

https://scrapbox.io/tkskkd-world/日本アジャイル昔ばなし

海外でXP本が出版されてから22年、XPJUGが設立されて20年の月日が経ちました。

当初は日本国内では白い目で見られることも多かったアジャイルソフトウェア開発ですが、今では国として取り組もうとする流れにまでなりました。

登壇者は「アジャイルソフトウェア開発」という言葉が世に出る前の2000年にXPを知り、2001年にXPJUGの立ち上げから参加し、XP祭りをはじめとしたコミュニティ活動を開始しました。その間、自分の現場での実践、海外情報の入手と共有、顧客への導入支援、海外での事例発表などを行い、その後、地方に移住してコミュニティ活動や地方企業への支援を中心に過ごしてきました。

今では「当たり前」のようなアジャイルですが、当初は今では想像できないほど局所的であり、ネガティブな見方も多いものでした。しかし当時、アジャイルに魅せられた人たちは、それぞれの現場で、それぞれのできることを行い、実践したことを持ち寄ってつながりを作りながら、次世代に繋げ続けた結果、この20年を迎えたのです。

この中に貫くテーマは「まったく新しいアイデアが人々の間で少しづつ広がるというのはどのようなことか」です。

歴史に埋もれてしまいつつあるアジャイル黎明期に生き、何か凄いことを成し遂げたわけでもない「いちエンジニア」、「忘れられたXPer」として、XP、スクラムなどのアジャイルがどのように日本で種が蒔かれ、芽生え、育っていったのかを、個人の体験と教訓として物語ります。

そしてそこから何が学べるのか、「次の20年」に何が活かせるのかは、聴衆のあなた次第です。

ソフトウェア開発という文脈で民俗学があるとするならば、その一助になれば幸いです。

技術は何かの課題を解決するために作られ、そして新たな課題を生み出します。この連鎖によって技術は進化してきました。

講演では、アジャイル（2001）からクラウド（2006)、DevOps（2009）を経て、マイクロサービス（2014）に至るまでの歴史を振り返ります。これによってマイクロサービスが解決したかった課題と、そのための技術について理解ができるようになります。また、同時にマイクロサービスが生み出した新たな課題を提示し、これを解決するために、どういった技術が必要なのかを整理します。

最後には、よりよいシステムを設計するための視点や思考について考えていきます。

・誰一人取り残さないSDGsを絵に描いた餅にしないためには、企業・行政・教育機関・NPO等がSDGs事業を「実際に」立上げ推進することが大事です。

・そしてこれからの事業活動は、経済価値と社会価値の向上を両立させる「CSV」と、環境・社会・ガバナンスを重視する「ESG」が重要で、SDGsはビジネスシーンにおいて重要なキーワードです。

・しかし、実際にSDGs事業を立ち上げ・推進しようとすると中々上手く進みません。

・なぜならSDGsのような社会課題解決事業は初めから「答」や要件が初めから明確ではないため長期計画遵守型の事業モデルでは推進が困難です。

・そこで、SDGs事業のスタートアップとアジャイルの有効性についてお話ししたいと思います。

・これまで、企業・行政・市民団体・学校などでSDGs普及促進の講義やワークショップを行い、大学非常勤講師としてもSDGsを行うプロジェクトマネジメントについて講義を行ってきました。

・PMI日本支部が内閣府「地方創生SDGs官民連携プラットフォーム」内に設置したSDGsスタートアップ分科会の代表として企業・行政・NPO・教育機関等にSDGsスタートアップ方法論の普及促進の研修講師や実際の法人のSDGs事業支援を行ってきました。

・そして、本業でもSDGs事業をアジャイルに進めるプロジェクトのアジャイルコーチを行っています。

・そうした経験を踏まえて、SDGs事業立上げ・推進に必要なアジャイルを活用したSDGsスタートアップについてお話しするとともに、SDGsに関わることで本人のキャリアを豊かにするIKIGAIについてお話しします。

■イベント終了後スライド公開■

以下にスライド公開しました。

https://www.slideshare.net/RyotaInaba/xp2021sdgsikigai/RyotaInaba/xp2021sdgsikigai

私たちが事業や自分の会社や組織の働き方を主体性を持ったチームに変えていく「ビジョン」を発想する時には「あたりまえを疑うこと」つまり、"特異点を見出すための周囲との比較"を行なっていると言えます。これは、アレグザンダー氏の提唱する「センタリングプロセス」と捉えることができます。

また、「あの「ビジョン」はピンとこない」「ビジョナリーな組織だ！」という言葉を耳にすることもありますが、言い換えると「センタリングプロセス」が身についているか否かとも言えるかもしれません。

この「センタリングプロセス」は「ネイチャー・オブ・オーダー」などに登場する"15の幾何学的特性"とも相互作用しており、その一部と全部を活用することが、「センタリングプロセス」を実践する一助になります。

今回は、「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」を用いて、アレグザンダーとともに数々のプロジェクトで活動した中埜博先生と「センタリングプロセスのを用いたビジョンづくり」をテーマに中埜博先生とワークショップ形式で深掘りしていきます。

【参考：XPとアレグザンダー氏】

XP最初のプロジェクトは当時Chrysler社で行われたC3プロジェクトというレガシーシステムのリプレイスプロジェクトでした。この時の中心人物の一人がケントベック氏です。

彼がXPの着想を得たのはオレゴン大学在学中に出会ったアレグザンダー氏の提唱する「パタン・ランゲージ」だと言われています。この「パタン・ランゲージ」の発表以後もアレグザンダーは「ネイチャー・オブ・オーダー」などに登場する"15の幾何学的特性"、"センター"、"全体性"と言う表現によってその理論をアップデートしています。

2021年5月、希望を胸に新しい職場・現場に飛び込んでいった、2人のスクラムマスターがいました。

新しい環境に飛び込むことは、ただでさえ難しいもの。その上、コロナ禍の状況では、オンサイトで集まって対面で話すことも困難で、実際に2人ともに面接から入社まで一度も出社していません。また、エンジニアでの参画とは異なり、スクラムマスターという立場では目に見える成果やわかりやすいタスクを定義しづらいというのも難しいところです。

このセッションでは、新しい現場に飛び込んだ2人のスクラムマスターが、悪戦苦闘しながら日々考えていることや取り組んできた実践談をお話します。セッションの後半ではQ&Aタイムを設けようと思っていますので、参加者のみなさんも交えて一緒にディスカッションしてみましょう。

関係者が全員で、リリース時点からプロセスを逆算して洗い出し、手戻りや待ちなど無駄が発生している箇所を誰から見てもわかるようにする方法、VSM。

改善はしたいけれどそのための時間がとれない。どこから手を付けていけばよいかわからない。そういった場面で、VSMは大きな威力を発揮します。チームに共通認識を形成する、プロセスのムダを発見する。カイゼンサイクルを回し始める端緒では、ぜひともVSMを実施しておきたいところ。

しかし、このVSM、それ自体の作成に時間がかかります。そのため、「そんなに時間はかけられないな…」と実施を見送られるケースは少なくありません。また、「ムダを省く」というメリットを伝えても、「うちはもう最適化できてるから、これ以上省けるものはないよ」とかわされたりすることもあります。

自分自身がVSMを通してリードタイムを1/3にまで短縮した経験がある自分は、そういった現場でこそVSMを実践することの効果が大きいと考えています。できればそういった現場を後押ししたい。そういった想いから組織内で啓蒙を続け、実践をサポートし、今ではVSMを実施するチームがずいぶんと増えてきました。

このセッションでは、どのようにしてVSMを組織に広げていくか、というお話をさせていただきます。

2021年6月14日〜18日に開催されたアジャイルアライアンス主催のグローバルイベント XP2021（https://www.agilealliance.org/xp2021/）
英語が苦手で、海外ベンダーとのミーティングに出席するのを躊躇するレベルだった私が、このXP2021に登壇してきました。
このきっかけとなったのは、2021年年始一回目の全社イベント「Weekly朝会」でみんなの前で私個人の今年の目標を宣言したことが始まりでした。
「2021年 安田が実現したいこと：海外のイベントで英語で講演する」

正直なところ、以前は人前で話をするのも苦手で、イベントなどで講演するのも避けてました。そんな私が一念発起し、RSGT2020にプロポーザルが採択され登壇しました。この講演が良い反響を得てたのがきっかけでデブサミ2020に登壇することになり、なんとベストスピーカー賞を受賞しました。これらのチャレンジが多くの方々との出会いを生んでくれました。またこの私の発表内容を聴いて「一緒に働きたい」とクリエーションラインにジョインしてくれる方々が現れたり、「一緒にプロジェクトを進めたい」と新たな仕事のきっかけにもなりました。

・このような多くのきっかけとなるようなチャレンジをしていきたい
・失敗するかもしれないがチャレンジしている姿をメンバーのみんなにも見てもらいメンバーのみんなが「僕も（私も）なんかチャレンジしてみよう！」という思うきっかけになってほしい
などなど、色々な想いが、年始のチャレンジ宣言につながりました。

宣言をしたものの、そこからが色々と苦労しました。
どのイベントにチャレンジするのか？そもそも英語が苦手なのに登壇なんかできるのか？講演するって何を講演するのか？
というレベルのところからのスタートでした。

結果的には、この経験はとても素晴らしいものとなりました。

XP2021で講演した題目は「Joy, Inc. in Japan! How I Built a Joy Dojo in the Land Where Kaizen was Born」でした。
私のロールモデルでもある書籍「Joy,Inc.」の著者Richard Sheridanさん。
彼が創業したMenlo Innovationsでは創業時からXPを実践しています。Richard Sheridanさんの講演や書籍「Joy,Inc.」からインスパイアされた私たちがどのように変化してきたのか、どのような成果が得られたのかという話をしてきました。
（当日、実際の講演動画を一部ご紹介する予定です。）

参加された方からも多くの反響をいただき「Super interesting」などのありがたいコメントもいただきました。
この私のチャレンジした話を通じて、チャレンジすることの素晴らしさを少しでも感じていただき、イベント登壇や新しいプロジェクトへの参入やジョブチェンジなどみなさんの人生の幅を広げるきっかけになればという想いを込めてお話したいと思っています。

ソフトウェア開発において、コミュニケーションは非常に重要だとよく言われます。その一方で、ソフトウェア開発の文脈で語られるコミュニケーションは一般的に知られる「コミュニケーション」から連想される意味・行為と比べると幾分限定的なため、そのギャップに戸惑ってしまったり、間違って理解してしまうというのもよく聞く話です。

本講演では、この誤解をなくすため、ソフトウェア開発におけるコミュニケーションとは何なのか、どのように使われるのか、そしてなぜ重要と言われるのかについて整理してお話しします。

自己組織化したチームとマネジメントはどのように力を合わせることができるか？そのような疑問に対する解答の１つとなるのがJurgen Appeloさんが提案するManagement 3.0である。Management 3.0のモデルは6つの視点で構成されているが、本セッションではポスターを用いて3つの視点を中心に説明する。

出張版スクラムとデザインが仲良くする会

「デザインとスクラムがなかよくする会」は、スクラムについて興味のあるデザイナーやスクラムチームに参加しているデザイナー、スクラムチームでデザイナーと一緒に働くエンジニアやプロダクトオーナー、スクラムマスターの方が、日々の活動の中で抱えている課題や疑問、共有したい知見などをゆる〜く集まって雑談や相談ができる場所を目指して運営しているコミュニティです。

今回は、そんなコミュニティで普段、話をしていることを出張版としてパネルディスカッション形式でお送りします。

「デザイナーはスクラムの輪に入れない？」

「いやいや、同じ物作っているじゃん？」

「エンジニアもUIのこと考えてみては？」

「ユーザビリティvsデリバリーの対立ってあるよね？」

そんな話を普段から話をしている我々の様子を垣間見てもらうとともに、一緒にスクラムとデザインについて考えてみませんか？

「でも、カレーは正義」

プロジェクト計画が失敗する要因として「確度の低い見積り」「未凍結の仕様」が、ソフトウェア工学によって示されています。これらに立ち向かうには「確度の高い見積り」「凍結された仕様」を手に入れるのがエクストリームな対策です。ではどのようにすれば、それら対策の入手に近づくことができるでしょうか？ヒントのひとつは反復型開発における見積り技法とその計画づくりの運用にあります。

本講演では、実践から獲得した経験を元に「相対見積り」という見積り技法による "ソフトウェア見積りの公式" を述べます。最終的には、エクストリームプログラミングにて伝えられるトラッカーという役割に改めてスポットを当て、プロジェクトを成功に近づけるための "公式" とその裏にある考え方を知ることを狙います。

チームの一体感を OKR にて演出し、チケット駆動開発にて定量的な評価をすればよいのではないかという考えのもと、四半期を1サイクルとした OKR を5サイクルまわし、6サイクル目に入っています。
4サイクル目までは失敗の連続で、5サイクル目にてようやく「やってよかった」というような、ふりかえりをチームで行うことができました。
OKR の設定に苦しみ、失敗しながらも進めた OKR にて得られた知見についてお話します。

2019年に転職し、配属となったチームでの違和感を
1年ほど掛け「チケット駆動開発」にて、少しずつ解消していきました。

なぜ「チケット駆動開発」を導入しようと思ったのか
https://d.zinrai.info/public/okr-tidd-case/tidd-motivation/

チケット駆動開発を導入するために行った取り組みについては、
Redmine Japan 2020 にて、発表しています。

チケット駆動開発がまわりはじめるまでの取り組み
https://speakerdeck.com/zinrai/okr-tidd-case

チケット駆動開発の導入により、
「誰が」「何を」「いつまでに」は見えるようになりましたが、
人事評価の仕組みにてメンバーに割り当てられた役割が、
日々の業務としてチケットになっているという状態でした。
チームとしてありたい姿を共有し、進んでいくというような一体感は無く、
これを演出するための仕組みが必要ではないかと考え、 OKR を導入しました。

「チケット駆動開発」を導入しての成果と課題
https://d.zinrai.info/public/okr-tidd-case/results-introducing-tidd/