DXという言葉とともに、日本でもアジャイル開発が定着しつつあります。みなさんの周りでも、ほんとうにそうですか？

「アジャイル」を掲げて活動してきた私ですが、私の周りではまだ半分以下です。今回は、札幌という思い出多い場所で講演するにあたり、アジャイルの「あり方」について考えをお話します。エンジニアの方のみならず、マネジメントや経営者、ビジネス側の方にも聞いていただけるよう、アジャイルを中心テーマに、「ビジネスーチームー自分」という縦の糸と、「都会ー地方ー自分」という横の糸を編みたいと思います。

本講演では、なぜアジャイルが注目されているのか、というビジネス環境変化や、やさしいアジャイル入門や解説、からはじめて、福井で活動している私の経験談、「変わる」ことへの心の持ち方、ほんとうに大切なことに接近します。

アジャイルは「旅」です。どんなに経験を積んでも、みんなアジャイルの「旅の途中」（by 来生たかお）です。

みなさんが旅をはじめる、あるいは旅を続ける力になれるようなお話しをしたいと思います。

私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。

DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？

デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る姿をみます。そこには、まだドメインは明確に認識されていないのであるから、DDDというもの自体が使えない。それを自覚的にしろ無自覚的にしろ何か劣化させて使うことで妙な構造が生まれてしまう。

必要とされているのは、ドメインが認識されていない中でのDDDのやり方、つまり旧式DDDと決別した、もしくはそれを予感させながらも、ドメインが暗中模索ななかでの戦い方であり、DDDを進めることではないのではないでしょうか。

そんな中で身近な所からでもDDDを胸の奥底にしまいながら、挑戦していることについて紹介します。

ScrumBut というのは、「スクラムやってます、でも〇〇」という、スクラムがうまくいっていないときの言い訳から来た名前でです。スクラムだけれど、スクラムを使えていないみたいな状態を指すのに使われます。

スクラムをうまく使うお手伝いすることを仕事にしているのと、当然、うまくいっていないスクラムをたくさん見ることになります。

そこで、最近よく見かける ScrumBut をご紹介してみようと思います。

うまくいかないやり方を学んだところで、うまくいくようになるわけではありませんが、うまくいかない状況を知っていれば、状況を認知して、早く抜け出す手助けになるかもしれません。

なお、ここで出てくる ScrumBut は、すべてフィクションで、現実のプロダクト・プロジェクト・組織などとは一切関係はありません。

「うちの話をネタにしたな！」ではなく、似たようなはまりパターンはたくさんあるのねと思っていただけると幸いです。

アジャイル開発をはじめるときにどのプラクティスからはじめますか？

この問いに、「ふりかえり」と答える実践者の方はとても多いです。
企業活動では一定期間を区切って評価する習慣があるため、プロジェクトのふりかえりや個人のフィードバック面談のようにふりかえりと似た活動を既に経験している方が多いです。そのため、ふりかえりというプラクティスをはじめる理由を説明しやすく、受け入れる方も必要性が理解しやすいため、ふりかえりからはじめることは比較的容易です。最近では、ふりかえりの実践についてさまざまな書籍や情報が手に入るようになったことも後押しをして、既に実践している方も多いでしょう。

一方で同じような現場で同じようにふりかえりをはじめてても、誰がやるのかによって効果が大きく異なるのもふりかえりです。
つまり、ふりかえりは方法や形式ではないところに成果を左右する大きな理由があるように感じています。

はじめてふりかえりをすることになったがどうやって場をつくればよいかわからない
ふりかえりを続けてはいるんだけど、ただ続けているだけになっている気がする
一部の人が中心になって進めているだけで、チームの全体感が生まれていない
リーダー（ファシリテーター）への報告会になってしまっている

こういった悩みにどうやって立ち向かっていけばいいのか。
必要とされているのは、チームの状況に合わせてふりかえりのゴールをどのように設定するのか、そのときに最適な方法はなんなのか、ふりかえりの中で起こる問題をどのように解釈してどうやって解決するのか、などの実践知ではないでしょうか。

チームや組織の中でさまざまなふりかえりを実践し続けてきた経験と、アジャイルコーチとしてチームの外からふりかえりを支援してきた経験を合わせて、今の自分に見えているふりかえりという世界についてお話してみます。

いまこそ俺たちの本当のふりかえりをはじめましょう！

スクラムの基本単位は、小さいスクラムチームです。スクラムマスターとしてチームの有効性を高め、価値あるプロダクトを届けるためには、チームワークへの深い理解が欠かせません。

成功するチームと、大して成果をあげられないチームの違いはどこにあるのでしょうか。

J・リチャード・ハックマンの著書Leading Teams（邦題：ハーバードで学ぶ「デキるチーム」5つの条件）では、チームのパフォーマンスを高めるための5つの基本条件が紹介されています。

1. 真のチーム / Real Team
2. 魅力ある方向性 / Compelling Direction
3. チーム力が高まる構造 / Enabling Structure
4. メンバーを支援する環境 / Supportive Context
5. エキスパート・コーチング / Expert Coaching

本セッションでは、これらの5つの基本条件を紹介し、チームについてのよくある失敗や、良いチームを作るためのアプローチ方法を考えてみたいと思います。

RSGTやスクラムフェス札幌にはコーチズクリニックというものがありますが、みなさん活用できてますか？

コーチズクリニックとはなんなのか、どのように活用するといいのか、活用したあとどうなったのか？などコーチズクリニック活用した方の体験を踏まえて紹介していきたいと思います。

ProblemからしかTryを導けない、全部話そうとして別な問題を見落としてしまう、問題にばかりフォーカスしてアドホックな解決策しか出ない、「事実と問題」しか求めない、Tryがずっと放置されたまま、etc...

上手くいかなかったり、辛さの方が強いふりかえり、皆さんは経験ありませんか？

私たちのチームは何年か前、こんなふりかえりを繰り返していました。

毎週同じ曜日・同じ時間に決まりごとだから集まり、効果があるのかわからないまま次のスプリントに向かって行く。 このように、自分たちの行ったことから満足なフィードバックを得られない状態がしばらく続きました。

メンバー全員がこのような状態はまずいと考え、少しずつふりかえり自体を見直して始めました。

これに合わせ、チーム自身の姿勢も変わって行きました。

このセッションでは私たちのチームの取り組みを通じ、自分たちのふりかえりをどう変えて行ったか、その結果得られたものについて話したいと思います。

変えようとしても上手くいかないことの方が多く、試行錯誤を繰り返しながらようやくしっくり来るところにたどり着けました。

キレイにまとまったことだけでなく、上手くいかなかったこと・もっと上手くできただろうことについても話したいです。

スクラムを導入&実践するなど、現場で新しい風を吹かせようとしている人から、「現場を良くしたいという想いで行動しているのに、考え方を否定されるようなふるまいをされたり、批難を浴びて敵のように扱われたりしてしまった」という話を聴くことがあります。
このような抵抗に遭った時には、否定や批難をした相手の話をよく聴いて相手の考え方や立場を理解するといった、相手に寄り添うような対応が望まれると思います。

たしかに否定や批難にあった時、相手に寄り添うことの重要性は理解できますし、現場で自分が実践して効果を感じる場面もあった一方で、実際に否定や批難をされたと感じた時点で心が折れそうになり、相手に寄り添うことが厳しくなる場面も自分は多くありました。

そんな風に心が折れそうになった時、役に立ったのが、進化心理学や生物学を中心とした知識でした。
人がなぜ相手を敵対視することがあるのか、なぜ狭い視野で(自分の立場だけを考えて)行動することがあるのか等々、人の特性や歴史を理解することで、否定や批難をされることを自然と受け止めることができ、現実を見つめて相手に寄り添うきっかけとすることができたのです。

現場を良くするための努力が思わぬ抵抗に遭ってしまった時、ステークホルダーと良い協働関係が築けなかった時...先が見えずに立ち止まってしまった際に、本セッションが前に進むための一助になればいいなあと思っています。

Lean Change ManagementのモジュールのひとつHot Seat（もやもや整理シート）を紹介します。
このHot Seat（もやもや整理シート）を使って、日常の課題を皆で助け合って円滑に仕事を進める方法です。
仕事をすっきりしながら進めるシートはすぐに現場で使えます。
是非、奮ってご参加ください

うまくいけば困った状況の打開に繋がるけれど、まずいともっと困ったことになるのが「相談」です。相談とは「問題解決や結論を出すために話し合ったり他人の意見を聞いたりする活動」です。

相談には次のような性質があります。
・困ったらする
・誰かとする(ひとりではできない)
・1回あたり3分〜1時間
・頻度が多い
・意思決定が多い

この頻繁に行われる「相談」のやり方を多くの人は習ったことがないと思います。一人ひとりが日々の中で工夫しているとおもいます。ところが、結果にはバラツキがあります。うまくいけば事態が進展しますが、失敗すれば仕事が進まなくなってしまいます。ですから相談するタイミングや相手を慎重に選んだりします。事態がこじれてしまいかねない人を避け、うまくいく人に持ちかけようとします。

相談そのものが大きな悩みです。そして、この相談の悩みは組織や社会のいたるところで起きています。

このように考えると相談は私たちが思っていた以上に大きな影響を持った活動であると考えられると思いませんか。

相談がもっとよくなったら…つまり、もし相談したら物事がもっとなめらかに進むという確信をもてたら、何が起こるでしょう。もっと人と働くことが楽しくなり、質も大きく伸びるのではないでしょうか。

このセッションでは個人の工夫のレベルで行っているためにバラツキが発生している「相談」を、機能と構造、発生と分布から観察し、短時間の相談でいかに人を助けるかというテーマを追求します。

「なんとかしたくて相談したのに、もっと困ったことになってしまった!」
こんな事態から「あー相談して良かった!」にしていきましょう!

目次
・相談とはいったいなにか
・相談が組織にどのような影響を与えているのか
・良い相談の成立は難しい
・相談をする技術と相談を受ける技術

Agile 2012 のキーノートで、スタンフォード大学経営学部のボブ・サットン教授が基調講演をしました。当時出版されたばかりの本 “Scaling Up Excellence” を題材に、幅広い調査を元に、よい組織文化をスケールさせるには、どうしたらいいか、なにをやってはいけないか、について話してくれました。

その時に書いたブログがこれです。
Agile2012 Day2 : 基調講演: よい組織文化をスケールさせるには by ロバート・サットン

最近、私は新しい会社 (HoloLab, inc.)にジョインしました。このまだ小さな会社にジョインするにあたって、ふと、ボブの基調講演で学んだことを思い出しました。あわせて当時のインタビューをいくつか見直して、人が増える会社にとって覚えておくべき重要なことを学びました。彼らの研究手法はGTAという質的研究手法を使っているそうで、統計的に有効性が証明されたものではないのですが、うまくいっている企業に共通する要素をとりだしてまとめる、ということにおいて、説得力のある情報が多く含まれていると感じました。一個人の経験や気づきをまとめた自伝やジャーナリストが書いた本とは違い、一定の研究手法にしたがって行わたであろう点も信頼できます。

本セッションでは、そこでボブ・サットン教授がなにを教えてくれたのかを、自分なりにレビューしてみたいと思います。

2019年にマネージャーとして任用されてから、様々なことに戸惑い、失敗してきました。

特にたくさん失敗して悩んできたのは、この二つでした。

• 「自分のグループのあるべき方向がうまく示せない。。。」
•  「グループとしての成果がまとまりがない気がする。。。」

そんな中で色々な情報をキャッチアップしたり、現場で数年もがいたりしているうちに、だんだん自分のやり方がわかってきて、（まだまだ失敗も試行錯誤もしているけれど、）以前よりも上記の悩みは軽減した状態になっています。

この取り組みをする上でベースになっているのはGMOペパボ株式会社の栗林健太郎さんの「やっていき、のっていき」です。振り返ってみると、コンテキストは違いつつ、自分なりにこの考えをどう実現するかを模索してきたように思います。

そこで自分がやってきことを振り返りつつ、自分が悩んだこと、失敗、そこから考えてどう変えていったかをお伝えします。

このセッションでは、私自身が感じるオープンソース開発とコミュニティの共通の魅力について紹介したいと思います。

私は、オープンソース開発が好きです。
OSS開発は、複数の開発者がそれぞれの知見を重ね合わせ、少しでも世の中を良くしていこうという活動であると考えています。そして、多くの人に使われているかどうか、有名なOSSであるかどうかに関わらず、そのような活動に真摯に取り組んでいる開発者を尊敬しています。その憧れから、自分もOSS開発したり、誰かのOSSへ貢献するようにしています。

さて、2020年よりコロナ禍によりオフラインでのイベントを行うことが難しくなってしまいました。
不幸中の幸いと言いますか、多くのコミュニティはオンライン開催に切り替えました。その裏で、そういった急な変化に対応できず解散してしまったかもしれません。また、活動が減ってしまったコミュニティもあったと思います。一方で、それでもなお盛り上がりの熱量が冷めず活動しつづけているコミュニティがあります。私が最近好んで参加しているコミュニティの勉強会では、あの廊下の風景が脳裏に浮かびます。

あの廊下とは、Regional Scrum Gathering Tokyoに参加したことがある人なら想像できると思うのですが、あの廊下のように感じます。ちょうどよく陽射しが入り、明るすぎない廊下。窮屈ではなく、かといって離れすぎていない間隔で並んだ椅子。ふと何かを考えたくなったのでそこに座ると、セッションを終えて出てきた人が1人また1人と座り込む。同じ目的で会場に集った人同士なので話しかける口実は十分。それが話しかける後押しになり「どんなセッションでした？」と話しかけてみる。座りこむほどではないけど、もたれかかり立ち話をするのに丁度いい丸テーブル。目の前では参加していたセッションについての話が聞こえてくる。その話に耳を傾けながら、心の中で相槌をうつ。自分の同じ考えが聞けて安心したり、自分が思いもしなかった意見に感心したり、話に引きつけられてしまう。けれど、用事を思い出し、後ろ髪を引かれながらもその場を後にする。それでも椅子でなされていた談笑は続く。そういった談笑だけでなく、久しぶりに会った人同士の集まり、何かの相談ごとがあちこちで見られる。何を話しているのかはわからないが誰かいることはよくわかる。そういう廊下です。

このセッションでは、私自身が感じるOSS開発とコミュニティの共通の魅力について紹介したいと思います。
もしこのセッションから、コミュニティをより楽しくするヒントであったり、組織の中でより楽しく働くことのヒントになれば幸いです。

みなさん、チームで開発してますか？

2人以上で開発を行う時、それはすでに"チーム"です！

そして、"チームをより良くしていきたい"というのはチームで活動しているみなさん共通の願いではないでしょうか。

チームというのは頼もしい存在であり、想像していないような素晴らしい効果を発揮することがあります。

一方で、ほんの少しのことで良くなったり壊れてしまったりするような繊細な面も持ち合わせています。

このセッションでは、そんなチームの気質をうまくとらえながら少しずつ前に進むために私が心がけていることをお話します。

チームを良くしたいと思いつつもなんだかうまくいかない、

良くしたいけど何をやったらいいのかわからないという方のヒントになれば幸いです。

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.

チーム活動による見積もり・計画・改善の勘所を実感し学ぶには、Ball Point Gameに代表される体験型のアジャイルゲームが効果的です。

「アジャイルスクラムは生き方である」

野中郁次郎先生のお言葉である。

とても共感するし、アジャイルやスクラムは実践していることが当たり前な日本になりつつある。

一方で、自分はどうなのだろうか。

最近の関心ごとの一つはSDGsだ。
きっかけはアジャイルとの重なり合いがとても多いと「強烈に」感じたからだ。

ダイバーシティ＆インクルージョンもスクラムマスターだし、
ストレスコーピングもアジャイルの考え方と重なっている。

新しい物事と対峙した時、上記のように感じることが増えてきたのを実感している。
アジャイルやスクラムの眼鏡が自分の中にある。

これは自分の中の大きな変化だ。

これまでアジャイルやスクラムの箱の中だけを覗いていたのに対し、
少し顔を上げると、新しい景色がたくさん見える自分がいた。

アジャイルを体現しているかわからない。

それでも、自分の中の小さな（もしくは大きな）変化に気付いたり、
その経験を誰かと話すことで重なり合いを見つけて世界が広がることは
スクラムから教えてもらったと自負している。

自分がアジャイルやスクラムと出会って
何を感じ、何が起きたのか。

私の中の変化を、私の言葉で誰かに伝えることで、
私とあなたと大好きなスクフェス札幌に新しい重なり合いが生まれることを信じ、
このプロポーザルを提出したいと思います。

47機関をご存知でしょうか。

今回はきょんくん以外のメンバーからみた47機関についてと、47機関の中でどのように働いているのかという話を紹介したいと思います。

熟達したチームでアジャイルやスクラムを経験し、その後他チームへの異動となったり、もしくは新天地（別の会社）に転籍することってありますよね。

そして、新たに入ったチームや組織ではアジャイルやスクラムをやっていない、古き良き開発プロセスで開発を進めているけど、いろいろ上手くいっていないっていうこと、ありますよね。

そんなとき、あなたならどうしますか？
アジャイルやスクラムで感じた良さ・Funを捨てて、古き良き開発プロセスに身を染めますか？
それとも自分がアジャイルやスクラムを説く1人目の推進者となって奮闘しますか？

このセッションでは1人目のアジャイル推進者となった私が、どのようなアプローチから始めて、チームや組織にアジャイルやスクラムの価値を浸透させ、チームの開発プロセスをどのように変えていったのかを成功だけでなく失敗も含めてご紹介します。

集団の中で最初のリスクを踏む人を「ファーストペンギン」と呼ぶそうです。
アジャイルやスクラムを学び、次のステップは自らが推進者としてチームや組織へ広めていきたい！そんな、アジャイルやスクラムのファーストペンギンを志す人の背中を押すセッションにしたいと思います。

研修や授業で「アジャイル開発を学ぶ」という言葉に違和感を感じたことはないですか？

私はこれまでアジャイル開発を体得する授業を売りにしてきながら、もやもやとした違和感を感じてきました。それを学ぶことがゴールなんだろうか、なぜ手段から入るんだろうか、と。

生き生きとしたものづくりの、もっと根幹を体得する授業とはなんだろう、ひょんなことからそんな疑問に対するヒントを見つけたかもしれない、という話をしたいと思います。

きっかけは、休業中でがらんとした学食を舞台に、情報・建築・機械・デザインを専攻する学生や教員と一緒に始めたプロジェクト型授業でした。ここを自分たちの居心地の良い場所に変えようと、毎週学食にあつまり、観察・実践・発見のサイクルを回しているうちに、ささやかな工夫で大きな知見が見つかり、その連鎖で空間が変わっていきました。

・色あせた長いカーテンを外したら、窓の向こうに息を飲むほどの素敵な緑の風景が広がった

・薄暗くて嫌だと思ったけど、案外落ち着くことに気がついた

・学食に関わる様々なステークホルダーの存在、それぞれの事情と思いが見えてきた

・古びたパイプ椅子に少し明るい色のカバーをかけたら、それだけで部屋が彩づいた

・小上がり空間を作ってみたらだだっ広くて落ち着かずパーゴラを作ったら、複数の意味ある領域の構成が緩やかに出来ていた

シンプルな工夫と、見えた景色にハッとする瞬間。その場に過ごしてじんわり気が付く感覚。その蓄積。これってソフトウエア開発でも同じだな。ていうかものづくりに共通だなと。

もしかして、学食プロジェクトで得られるこの経験は、とてもわかりやすい入り口になるんじゃないか。そんなふうに感じ、このプロジェクトを元にしたカリキュラムを考え始めました。

そんな今現在の話と、その先の話をする予定です。