私達の愛した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やスクラムフェス札幌にはコーチズクリニックというものがありますが、みなさん活用できてますか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リモートワークでもオフィスワークでも、チームメンバー同士のコミュニケーションがどうも上手く取れていないと感じている方は少なくないのではないでしょうか。

私たちのチームメンバーは東京と沖縄に住んでいます。それぞれ自宅やオフィスから毎日オンライン接続して一日中ずっと会話しながら一緒に働いています。

半年ほど前、チームのふりかえりで「話してる事が伝わってるのかわからない」という問題提起がありました。常にオンライン接続していていつでもお互いの声が聞こえるのに、なんとなく会話しづらい雰囲気が漂っていました。計画ミーティングやレビュー、ふりかえりの際も全員が沈黙する時間がしばしばありました。

COVID-19の影響によってオフィスワークからリモートワークに移行して既に1年が経過し、オンラインでの会話にもう慣れているはずなのに、なぜか会話がしづらい。全員がそのことに気付いていましたが、なかなかその状況を変えることができずにいました。この日、メンバーの１人が勇気を出して問題提起したことで、全員がようやく何とかしなければいけないという気持ちになりました。

そして、その日のふりかえりで出たトライが「朝、みんなでチェックインをする」でした。

翌朝、さっそくチェックインをやってみました。すると、その日のふりかえりでは「チェックインいいね」という声が多くあがりました。

その週、複数チーム合同で行なっているふりかえりの場で「チェックインが功を奏している」という話をしたところ、他のチームでもチェックインを試してみるところが出てきました。

一体、チェックインによってチームにどんな変化が起きたのでしょうか？

みなさんのチームでは、お互いに気軽に相談できる雰囲気をつくるためにどのようなことをされていますか？

スクラム開発でテスターがテストを上手くやるにはどうしたらいいのでしょうか。
スプリント内でテストを実施しますか？スプリント外でテストを実施しますか？

freeeの湯本さんと長田さんにnemorineがインタビューをしながら、実際どのようにやっているのかを根堀り葉ほり聞きたいと思います。
テストコンサルで有名な湯本さんですが、freeeではテスターの一人としてプロダクトと真正面から向き合っています。
スクラムガイドにはそこらへんの話はほとんどないのでノウハウを共有していきましょう。
もちろん正解は1つではないと思いますが、1つの形をお見せできると思います。

・開発の背景説明
・スタートを切るタイミング
・テスト設計の方針
・テスト実行の方法
・システムテストのタイミング
・開発者のテストとQAのテスト
・プログラマとの関係性
・大切にしていること

スクラムチームが自律して活動するためにはどのような要素や条件が必要なのでしょうか？そしてスクラムマスターはチームの自律を促すために、どのような観点でチームの観察・支援を行えば良いのでしょうか？

メンバーのスキルやマインド、関係性といったチームの構成や成熟度に基づく要素もあれば、そのチームが活動している組織の体制や権限の設計といった環境要素もあります。

本セッションではそんな「チームの自律を測る指標」について整理してみたのでその内容と活用状況についてご紹介したいと思います。

「なぜ学ばなければならないのか？」この問を、IPAのインタビューで延々と問われました。そして、その記事がはてブをたくさんいただきました。

スプリントレビューって意外と難しいですよね。

まずどういった趣旨のイベントなのかをイメージするのが難しいです。

• レビューっていうくらいだから作ったもののレビューをするんじゃないの？
• 他の開発手法だと、どのフェーズに対応するものなの？
• リリース前の最終確認でしょ？

みたいな誤解や疑問が生じやすいと思います。

さらに、実践する上でも上手く機能させるのが難しいんじゃないかなと思います。

• ステークホルダってどこまで呼んだらいいんだろう？
• 偉い人への成果報告になってしまうな
• ワーキングセッションって言うけど発表会な感じが抜けない

みたいな戸惑いやモヤモヤが拭いきれないっていう人は結構いるんじゃないでしょうか。

RettyにJoinして間もないころ、私が入ったチームでもスプリントレビューがあまり機能していないように見えました。

ある日、ふりかえりでこんな話が出ました。

「スプリントレビューに何を持って行ったらいいか迷うよね」

LeSSの体制で複数チームが集まってのスプリントレビューでしたが、私たちのチームは他のチームと比較すると扱うプロダクトの性質が少し違っています。
開発内容も全体にはあまり影響のないものだったり、ステークホルダが違っていたりしたため、確かにスプリントレビューにあまり意義を見出せていません。

そんな話をきっかけに、チームはスプリントレビューの目的について考えるようになりました。

開発チームとプロダクトオーナーは、スプリントビューの目的についてたびたび議論しています。
チームやプロダクトが抱える課題の解決のために、スプリントレビューを活かそうという動きがあります。

チームにとってのスプリントレビューの位置付けが以前とは明らかに変わってきました。

このセッションでは自分たちにとって必要なスプリントレビューのあり方を模索したチームの取り組みをお届けします。

チームはまだまだTryの真っ最中です！

開催のころには今よりも少し前に進んだ様子もお届けできると思います！