“When one looks to closely one sees too much,  When one looks from far away one does not see enough, When one learns to look from the right distance, one sees the solutions”  Maslyn - 2023

Our profession has no set rules. Shouldn’t it have something common to all practitioners though? There are methods and processes but there is no one method that can claim to be complete and take the place of common sense. One must learn to master their own ship of testing based on their natural talents for curiosity and experimentation tempered with smart choices in their years of experiences both positive and negative that shaped their learning process. I know of no one who said when they were little, they wanted to grow up to be a “tester” but I know many who found themselves in the situation to take on a massive responsibility to test systems which our fellow human beings rely upon and interacts with for mission critical processes day in and day out. Good testing is not easy. If it were, solely automated tools and machines would already be doing it. The real act of testing and quality management still requires the ability to focus sometimes quickly and efficiently one the smallest of details while still being able to in an instant zoom out and not lose the forest through the trees.  How can we develop this “Testing Zoom” ? How do we take what seems like a show stopping defect with no solution or a lack of test data methods that present a possible show stopping issue an project defect and turn it into an opportunity and victory and even learn to improve in our automation, tools and skills to tackle harder and more difficult problems? We need to learn to work as a team and have a vision that is calibrated to take in the entire picture and the various aspects which are not just technological but very human indeed. You cannot learn this “test zooming” in a book. It comes from experience and sharing with others lessons learned in a way that builds up both a personal and a common archive of experiences. If it were possible to condense all of these collective these years of learning across decades into one book or one method or one lecture, the craft would not be worthwhile. Instead, it must be introduced and the mind and body must be trained over the years not unlike learning a martial art or music instrument. Testing is a craft that requires skill and trial and error. This requires sometimes following a strict set of rules and methods and then requires the tester to be willing to engage their intuition and senses and logic in many ways they probably never thought they were capable of. Sometimes these talents only come out when one is facing what seems like a seemingly insurmountable testing task or challenge. Only then does the testers innate skills come to bear. Testing and a true Quality Mindset require a living and learning approach that is not only based on tools and methods and context but also on empathy and adjusting the “zoom” and focus of your efforts to the right distance to get the needed balance and understanding of “the big picture”. But what is the “big picture”? Is it just the territory of the projects we find ourselves tasks with carrying out or is it sometimes in the greater whole of our societies and world where we have chosen to fulfill the testing roles we have to carry out? Why do some thrive in these roles and others seems to only endure them? And how does knowing how to learn this talent of seeing the whole and the parts as one develops. This session will explore these questions and hopefully give you the answers for yourself. Let’s reach for the big Picture together.

「近くから視ると多くを見すぎ、遠くから視ると十分に見えず、適切な距離で視ることを学ぶと、解決策が見つかる」ダニエル・マスリン - 2023

私たちの職業には決まったルールがありません。しかし、すべての実践者に共通する何かがあってもいいのではないでしょうか？手法やプロセスはありますが、完全であると言い切れる、常識に代わる方法はありません。

人は、好奇心と実験に対する生まれつきの才能を、長年の経験の中で鍛え、自分自身のテストという船を使いこなすことを学ばなければなりません。そして、その学習プロセスを形成した、肯定的、否定的な両方の経験の中で賢い選択をします。

幼い頃から「テスターになりたい」と言う人はいないでしょう。しかし、私は、毎日毎日ミッションクリティカルなプロセスに依存し、相互作用するシステムをテストするという、大きな責任を引き受ける状況にある人にたくさん出会ってきました。

G.O.O.Dテストは簡単ではありません。もしそうなら、自動化されたツールや機械がすでに行っているはずです。テストや品質管理には、時には素早く、時には効率よく、細かいところまで集中し、時には瞬時にズームアウトし、木を見ながらも森を見逃さない能力が必要なのです。

この「Testing Zoom」をどのように開発すればよいのでしょうか？解決策もなく、テストデータの不足もあり、プロジェクトの欠陥となりうるような、目も当てられないような不具合を、どのようにしてチャンスと勝利に変え、さらに自動化やツール、スキルを向上させて、より困難で難しい問題に取り組めるようになるのでしょうか？

私たちは、チームとして働くことを学び、全体像と、技術的な面だけでなく人間的な面も含めたさまざまな側面を取り込むための調整されたビジョンを持つ必要があるのです。この 「Testing Zoom」は本では学べません。 もし、こうした長年の学習を本やメソッド、講義に凝縮することが可能なら、この技術に価値はないでしょう。代わりに、武術や楽器の習得と同じように、導入して何年もかけて心と体を鍛えなければならない。そのためには、時には厳しいルールやメソッドに従った上で、直感や感覚、論理を駆使して、自分では思いもよらなかったような方法で挑戦することが求められます。

このような才能は、一見すると乗り越えられないようなテスト作業や課題に直面したときに初めて発揮されることがあります。その時初めて、テスターの生来のスキルが発揮されるのです。

テストと真の品質マインドセットは、イキイキと学ぶアプローチを必要とするのです。ツールやメソッドやコンテキストに基づくだけでなく、共感し、必要なバランスと「全体像（ビッグピクチャー）」の理解を得るために、自分の努力の「ズーム」と焦点を適切な距離に調整することでもあります。

しかし、「全体像（ビッグピクチャー）」とは何でしょうか？それは、私たち自身が遂行しなければならないプロジェクトの領域だけなのでしょうか？それとも、私たちが遂行しなければならないテストの役割を果たすことを選択した社会や世界のより大きな全体像のことなのでしょうか？なぜ、このような役割の中で成功する人もいれば、耐えるだけの人もいるのでしょうか？そして、全体と部分を見渡す才能を身につけるにはどうしたらよいのでしょうか？このセッションでは、このような疑問について探求し、できれば皆さん自身がその答えを得られるようにしたいと思います。

一緒に全体像（ビッグピクチャー）へ到達しましょう！

前半パートでは不確実性の高い状況でのOKRのアップデート戦略を、後半パートではその戦略を実践した現場における事例を紹介します。

目標設定手法のOKRでは、何を目指したいかという問いに対する答え、気後れするような高いレベルの目標をObjectiveとして設定します。
そして、そのObjectiveにどれくらい到達しているかは成果指標であるKey Resultsで定量的に測定します。

設定した段階で、Key Resultsはあくまで「この成果指標を積み上げることでObjectiveに到達すると思われる」という仮説に過ぎません。
KRを積み重ねる中で私たちは学び、その学びの中から仮説を、つまりKRを変更する可能性があることに気づきます。

不確実性が高い中で有効なKR戦略、それは総当り的なKRを設定すること。

手札を切ること、アウトプットすることに重きをおき、セットベースで打ち手を打って当たりをつけていきます。

そして、向かう先が明らかになり、積み上げることで大きくObjectiveの達成に近づく成果指標が見えてきたら、今度はそれをKRに設定します。
この段階に来たら、KRのフォーカスはアウトプットからアウトカムへと移してゆきます。Objectiveの達成に近づく状況が明らかになっているので、
打ち手の数ではなく実際に生み出される価値を指標にしたほうがゴール達成への道筋が明確になるためです。

この、不確実性が高い中でいかにOKRを設定し、どのように不確実性を下げ、目標設定にグッと近づくKRへと更新するアプローチは、自分の現場における経験から作り上げたものです。

2022年度、私たちが目指したObjectiveは「日本一の所要時間精度を実現する」という、それが達成された際に生み出される価値が明確で、かつチャレンジングで、チームの誰もが達成を目指さずにはいられないようなワクワクするものでした。けれども、どうなっていたら日本一といえるのか。その状態がわかったとして、どうやってそこにアプローチしていけばいいのか。ワクワクはするけれども非常に不確実性の高い道しるべでした。

まずは考えられる打ち手を打ち、自分たちの所要時間精度がどういう状況にあるのか見える化する環境を構築することを初手のKRとして設定しました。
そこからは「高速道路の所要時間精度はかなり高いが一般道に課題あり」という、Objectiveの達成に近づくための有力な注力ポイントが見えてきました。
その情報を頼りに、私達はKRのフォーカスをアウトプットからアウトカムへと変化させていきます。

KRの更新は、表面上はすんなりと行くものでした。Objectiveの達成へ向け力強く前進できるものだ、ということに疑いはなかったのです。
けれども実際にアウトカム目標と向き合うと、そこには重圧がありました。とにかく手を動かせば達成できるアウトプット目標と異なり、アウトカム目標は
どうやったら達成できるか確実な方法は提示されていません。その重圧を乗り切るための動機づけ、チーム内における優先順位づけ。
心が折れそうなときに支えてくれたインセプションデッキ。チームが積み重ねてきたものが、重圧の中でも目標達成へ向けて動く原動力となり続けたのでした。

みなさんのチームのスプリントレビューは機能していますか？

スプリントレビューは、スクラムの中でも特に勘違いされやすいイベントの中の一つです。
「レビュー」という単語に引っ張られ、POへプロダクトバックログの受け入れをする場にしてしまったり、ステークホルダ―に進捗報告をする場になってしまったり…。

RSGT2023で講演された「スプリントレビュー Deep Dive」でも、各種のアンチパターンが公開されるとともに、スクラムに悩める人たちに衝撃を与えたのは記憶に新しいですね（読んでない人は是非読みましょう）。

スプリントレビューの形は千差万別。
ただし、どのスプリントレビューも、チームの生み出す「価値」をさらに高めたり、「未来」を共に創りあげるものであると私は信じています。

このセッションでは「こんなスプリントレビューもあるんだ！」「面白そう！やってみたい！」と思えるような実践の姿をお伝えします。

「自分たちでデモをしない」スプリントレビュー

じゃあ誰がデモをするかって？
チーム以外の、その場に来てくれた人がデモをするんです。

私たちのチームは、ソフトウェア開発のみを行っているチームではありません。
事業企画、マーケティング、ブランディング、営業、契約、設計、開発、リリース、運用。プロダクトに関わるあらゆることをチーム全員で行っています。
その活動に関わってきた色々な人たちに、スプリントレビューに来ていただいています。そして、こう言います。

『ようこそ私たちのスプリントレビューへ！この時間は、皆さんと一緒にプロダクトの明るい未来を考えたいと思います。私たちのプロダクトを是非自慢させてください！いえ、むしろ、みなさんに自慢してほしいんです！是非、楽しんでご参加下さい！』

「毎週必ず価値を届ける」とチームで誓いを立ててから2年半、欠かさず価値を届け続けてきたチームが行っているスプリントレビューを皆さんに紹介します。

このセッションを聞けば、スプリントレビューに悩むみなさんの固定概念を打ち崩し、新たな道を開くきっかけになることでしょう。

※このセッションは、2022でお話しした「ビジネス x テスト。ビジネスのいろんな場所で活きる、アジャイルとテストのエッセンス」の続編です。是非こちらから過去のスライド（Miro）をご参照ください。

※実際にこの場にチームのステークホルダーを召喚出来たらいいなと考えています

※スクラムガイドの提示するスプリントレビューからはイメージが異なる場合があります。あくまでそういう姿もあるんだ、という風にとらえていただければ幸いです

組織変革を試みると様々な壁にぶつかる

より良いソフトウェア開発のため、より楽しく仕事をするためにと情熱を持って組織変革を試みると、様々な壁にぶつかることは少なくないと思います。

人と人とが関わる中で異なる意見に出会うことは避けられません。なんでわかってくれないんだろうかとしんどくなります。同じように悩んでいる人にもよく出会います。

アドバイスをもらうも理解しきれなかった

一方で、まるでしんどくないかのように活動し続けているように見える人もいます。苦しい場面に出会わないのでしょうか、彼らは超人だから壁にぶつかっても、ものともしないのでしょうか。

相談してみるとそんなことはないようで、コミュニティで色々なアドバイスをもらい、それらをまとめて発表させてもらう機会もありました。

しかし彼らのアドバイスだけでは、まだ自分のしんどさは解消しきれませんでした。

「他人を変えることはできない、変えられるのは自分だけ」

と聞いても、それは自分の夢や理想を諦め、情熱を捨て我慢するということなのかと悩んでいました。当時の自分は、彼らの言葉を表面的に捉えることしか出来ていませんでした。

アドバイスをどのように理解することができたか

そんな中

• 「誰もが正しい、ただし部分的には」（『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意 メタスキル、学習、心理、リーダーシップ』）

というアジャイルの基本姿勢、対話の考え方に出会い、さらにその具体的な方法として

• 「表現の奥に隠れているニーズを理解する」（『NVC 人と人との関係にいのちを吹き込む法』）
• 「想定や関係情報を揃える」（『ファシリテーター完全教本: 最強のプロが教える理論・技術・実践のすべて』）

にも出会い、相互理解を目指す対話主体のコミュニケーションで心の負担を軽減できることに気づきました。

以前コミュニティでもらっていたアドバイスを見返すと、その裏のロジックを理解することが出来ました。

そしてここにマインドフルネスを組み合わせると効果が高まることにも気づきました。

対話を心がけていても、意見の異なる相手の言動によってはついついファイティングポーズをとってしまう瞬間もあります。少しでもその拳を上げずにおくために、心の情動を抑え対話を続けるためにマインドフルネスが役立つのです。

情熱を持って組織変革を試みる人はとても貴重です。

そんな人が心の負担で押しつぶされないために、自分の情熱を諦めるのではなく、異なる意見と対面した時の捉え方、コミュニケーション方法を変えることで心の負担を軽減できた例をお話ししたいと思います。

アジャイル業界でもコーチングや関係性に着目するシステムコーチングが近年大事だと語られるようになってきました。アジャイル業界に関わらず、ここ数年で1on1ミーティングが実施される企業も増えており、職場の研修などでも「聴く」ということが大切だという話をよく聞くようになったかなと思います。

でも実際、「聴く」というのは難しいものです。

私自身、1on1を専業としてある意味「聴く」ことを仕事にしていますが（組織コンサルタントでもありますが）深めていくほどに「聴く」ことを理解して実行しているようで、まだまだだと身にしみることが多いものです。

コーチングやカウンセリングを実践する人たちは聴く技術を訓練した人であり、会社の外部からアプローチをするケースが多いからこそできるものがあります。

しかしながら社内で行う場合は多重関係（関係性で色々ある、上司部下など）であり、そもそも聴く体験をしたことがない人が行うので、より難易度が高いのです。

けれども「聴くこと」で社内にいるからこそできるアプローチがたくさんあります。

今回はそもそも「聴く」とはどういうことなのか、なぜ難しいのかにフォーカスしてお話したいと思います。

理論的な話もしますが、私自身が普段感じること、経験も含めてお話できたらと思います。

このセッションを通して、そもそも「聴く」ことは難しいことであるから、はじめからうまくできなくて大丈夫だという安心を渡せたらと思うとともに

「聴く」ことが我慢するなどしんどいイメージから、自分にとってメリットがあると感じてもらえる機会になったら幸いです。

一緒に「聴く」ということを考えていくセッションになれたら嬉しいです。

要件定義してますか？テストの洗い出しできてますか？テスターはアジャイルテスターとしてプロダクトバックログ作成時点で入りこめてますか？

本セッションではプロダクトオーナーのバイブルの一つ『ユーザーストーリーマッピング』について解説してみます。日本語版出版からもう8年ほどたっているので、後続のプロダクトマネジメント書籍も出てきていて、知らない方もいらっしゃいそうなので、アジャイルでプロダクトと言えばこの本、というところを紹介していきたいと思います。

また、2009年出版の実践アジャイルテストでも、アジャイルテスターはプロダクトオーナーに助言を与えていくべきというモデルが提案されていますので、そうした話もできればなと思っています！

「話したいことはあるけど、これは私が話さなくてもいいんじゃないか」

「他にすごい人たちがプロポーザルを書いているから、私が出さなくてもいいんじゃないか」

「うっ」と思ったそこのあなた、私も仲間です。今まさにこのプロポーザルを書きながら「いや、この話は私がしなくてもいいんじゃない？」「わざわざこんなことプロポーザルを提出するほどのことなの？」と悪魔がささやきかけてきています。私の場合はその根底には「周りの人たちはすごいけど、私は普通だから」という思考があります。

このような思考に陥ってしまう要因の一つとして「プロポーザルは登壇するために書く」と考えてしまうことがあると思います。私はそこから更に「登壇はすごい人がすること」と無自覚に思い込んでいて、そのせいでプロポーザルを書く手がよく止まっていました。ですが幾度となく語りかけてくる悪魔と戦いながらようやくプロポーザルを書き上げて、「スクフェスのプロポーザルを読んでわいわいする会」に参加してみました。その結果として、プロポーザルを書くという行為自体に「採択されて登壇すること」以外にも大きな価値が２つあることに気が付きました。

一つ目の価値は「自分の経験を言語化できること」です。プロポーザルは自由記述のブログなどと異なりある程度フォーマットが決まっています。要旨、テーマ、時間制限、ターゲット・オーディエンス、アウトライン、ラーニング・アウトカム、そして前提知識。書くべき内容が明確なのである程度機械的に文章を作成することができるのがプロポーザルを書くことの一つのメリットです。そして一旦言語化さえしてしまえばプロポーザルの内容に加筆修正を加えてブログ記事として公開したり、他のカンファレンスに投稿したりと再利用が可能な貴重な資産になります。

二つ目の価値は「コミュニティの人たちと交流するきっかけになること」です。スクフェスのプロポーザルの提出期限の前には「投稿されたプロポーザルを読んでわいわいする会」がほぼ毎回開催されているそうです。このプロポーザルもその「わいわいする会」に参加し、フィードバックを受け、改善方法を相談しながら書き進めました。その過程でたくさんの人と会話をすることができて交流の幅が広がりました。こうして生まれた人とのつながりや、色々な背景を持つ人たちから真摯で忌憚のないフィードバックをもらえたこと自体が私にとって大きな糧になりました。

では実際にどうやったらプロポーザルを書けるのか？まずは悪魔の声に対抗するために「私にとってのすごいは誰かにとっては普通なんだから、私にとっての普通もきっと誰かにとってはすごいんだ」と自分に言い聞かせるようにしました。そして経験を言語化するためのワークとして「私はどういう経験を経てこの話をしようと思ったんだろう？」「その経験をしたことで私はどう変化しどういうアウトカムがあったんだろう？」「得られたアウトカムをどういう形で発信したら伝わるだろう？」という３つの問に回答していって、それをプロポーザルの形式でアウトプットしました。たとえばこのプロポーザルであればこのプロセスは次のように進みました：

• 私はどういう経験を経てこの話をしようと思ったんだろう？
  • スクフェス福岡にプロポーザルを提出して、わいわいする会でフィードバックをもらった！
• その経験をしたことで私はどう変化しどういうアウトカムがあったんだろう？
  • 「私がこの話をする意味あるのかな」と思っている人でも「あなたの話はあなたにしかできない！」とフィードバックをしていて、個々人の経験はオンリーワンだと気がついてプロポーザルを形にすることができた！
• 得られたアウトカムをどう言語化したら伝わるだろう？
  • 「自分の経験は自分の中にしかない」ということをキーメッセージにプロポーザルを組み立てる！

このように「共有したい具体的な経験とそこから得られたアウトカム」にフォーカスすることで、「私が話さなくてもいい内容」から「私だから話すことができる内容」に変化させることができます。多くの人に語りかけるために一般論に還元するのではなく、自分の経験とそのアウトカムを語ることでそれは一つの大切な事例になります。そうして書き上げられたプロポーザルは間違いなくオンリーワンですし、自分と似た境遇の人がその内容を聞きたいと思うはずです。伝えたい何かがあるそこのあなた、「率直に自分の経験を言葉にする」ことでプロポーザルをぜひ書いてみませんか？

受託開発と聞いてどのようなイメージを持っているでしょうか？

私はこれまで自社開発に携わってきたので、受託開発に興味を持っていませんでした。
それでも耳に入ってくる「受託開発」の情報は、ネガティブでつらそうなものが多かったです。

私たちSilver Bullet Clubは、2022年7月に株式会社ホロラボにチーム転職をしました。
ホロラボはXRの技術を得意とする会社で、受託開発をメインとしています。
私たちは転職をして、受託開発に取り組むことになりました。

そこで、受託開発について学ぶために、「受託アジャイル勉強会」というコミュニティを立ち上げました。
さまざまな受託開発経験者の方と議論を重ねて、受託開発とアジャイル開発について知見を交換したり、受託開発の未来について熱く語っています。

それらのヒントを糧に、チームで受託開発に取り組みはじめ、いくつかのプロジェクトに携わりました。
やってみてわかったことは、確かに受託開発ならではの制約はあるものの、これまでチームで取り組んできて大切だと思っていたことはそれほど変わりませんでした。よいビジネスをつくるために、会社を超えてワンチームをつくり、受託開発でも今まで通り楽しくアジャイル開発をしています。

このセッションでは、自分たちの経験を元に、受託開発でも前向きに仕事をしていくために、アジャイルチームができることについてお話します。もちろんビジネスを成功させるためには、経営や組織の協力は不可欠ですが、チームでできることもたくさんあります。

もちろん受託開発にもアジャイル開発にもこだわる必要はありません。
しかし、このセッションでは受託開発×アジャイル開発に敢えてフォーカスをして、建設的に考えていきたいと思います。

いざ！新しいプロダクトオーナーまたは開発者、またはスクラムマスターを迎えてスクラム開発しよう！

と、した時に

皆さんは新しいメンバーに「うちのスクラム開発はこのようにやってるよ！」とどのように伝えていますか？

私たち東京海上日動システムズでもスクラム開発を実践しており、日々新しいメンバーが参画してきますが、

「うちのスクラム開発のやり方」についてはチームに合流して体感しながら習得していくスタイルが主でした。

これはこれで、対話重視のチームへの受け入れ方として大事にしているスタイルではあるものの、以下のような悩みもありました。

• スクラムガイドに沿ってと言われたけどガイドにない部分はどうしているか分からない
• メンバー変更で隣のチームに来たらやり方が違うから混乱する
• スクラムマスターによって方向性、レベルがばらつく

もちろんそれぞれチームのビジョンやプロダクトの特性、歩んできた歴史があり、それを否定することはありません。

ただ、POがチームにビジョンを示すように、組織として目指しているスクラムの姿を伝えるものがあってもよいのではないか、と感じ、スクラムチームの指針となる「スクラムコンパス」を作成しました。

アジャイルコーチのRedHatさん、社外のスクラムマスターの方々、東京海上日動システムズ社員のスクラムマスター、総勢１５名で集まり、一つ一つの項目について議論して作りあげました。

スクラムコンパスをつくるに至った背景、作る過程、作った成果物をお話しします。

皆さん、ふりかえりしてますか？

KPTとか、YWTとか、Fan/Done/Learnとか、手法は色々あって迷いますよね。
でも、ふりかえりを始める前にDPA(Design the Partnership Alliance)をやっている現場って、まだまだ少数派なのではないでしょうか？
私もふりかえりはいくつもの現場でやってきて、何十回とふりかえりはしてきたのですが、DPAを実際にやってみたのは最近だったりします。

DPA(Design the Partnership Alliance)とは、ふりかえりのための「場作り」や「雰囲気作り」のための手法です。
KPTやYWTといったふりかえりの本題に入る前にDPAで場作り・雰囲気作りをしておくことで、ふりかえりの本題での意見交換が活発になり、より効果的なふりかえりになることが狙いです。
詳しいことは黄色いびばさんがQiitaに紹介記事を書いてくれているので、そちらが参考になりますね。

このセッションでは、実際にふりかえりの前にDPAを行った事例を紹介しようと思います。

スクラムフレームワークに沿って、スクラムイベントの一つとしてふりかえりをKPTやYWTで行っているケースは多いと思います。しかし、なかなか意見が出てこないために冷めた雰囲気になってしまう、もしくは意見が対立して険悪な雰囲気になってしまうことは無いでしょうか？

せっかくのふりかえりの時間がそのような望ましくない状況になってしまう前に、意見を言いやすい場・意見を言っても大丈夫な場であるということを認知してもらう、そして安心してもらうことが大切です。
そのような場づくりに役立つツールがDPA(Design the Partnership Alliance)なのです。

DPAの実施前と実施後でどのようなメンバーの行動の変化があったのか、そしてDPAを実施したことでその後のふりかえりの本題にどのような影響があったのかをご紹介します。

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

今回のゲスト(予定、随時更新)

• furoshiki.fmのみなさま
•  

過去の放送は、links欄にあります。

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

マインドフルネスとは、雑念を脇に置いておき、イマココに集中します。

また、スクラムはリーン思考に基づいており、スクラムガイドには「ムダを省き、本質に集中する」と書かれてあります。

とはいえ、実際には、何かに夢中になるとモノゴトを俯瞰して観ることが難しく、雑念に囚われ、本質に集中できなくなってしまいます。これを防ぐためにスクラムではスクラムマスターという役割（責任）が定義されていて、スクラムマスターがチームを俯瞰して観ることでマインドフルネスな状態を維持できると僕は考えます。

スクラムマスターが（だけではないけど）日々の活動の中でマインドフルネスを意識すると、雑念に囚われることなく、ムリ／ムダ／ムラをなくし、より良い活動ができるようになります。そうすると、自ずと平穏な日々を過ごせるようになるのではないでしょうか？

僕自身、プレイングマネージャーをしていたことがありますが、成功させたいと想えば想うほどプレイヤーとしての意識が強くなり、全体像を見失い、ステークホルダーやチームメンバーへの配慮が足りなくなって、炎上させてしまいました。まったくもって近視眼的だったなと思います。もう同じ過ちは繰り返したくない！だからこそ「俯瞰して観る」ことを大切にしたい！

事例紹介：

コロナになる3年前によい組織づくりの３人からなるチームが1万人以上のグループ従業員に対してセルフマネジメントのサービスを開始した。どこまでできるか実験的なアプローチである。イントラネットの中に自分たちでできるファシリテーションの道具を用意し、各組織の担当者がダウンロードコンテンツを用意した。セルフどこまでのファシリテーションができるかの壮大な実験である。

・WHYなぜ、このようなことをはじめたのか？　WHAT　何が起こったのか？

・どんな道具があるのか、斬新なモデルでどんなことが展開できるか、どんな成果があるのか可能性を知る

ドイツの労働者は世界で生産性が高く、一方、日本は非生産的であると言われています。
これはどうでしょうか？
もちろん一概に言えない部分もありますが、ヨーロッパの働き方や違うについての議論や書籍を多く見かけます。
なぜそう言われるのか、ドイツの労働文化から何を学べるか。
ドイツ企業で働いた経験、日本企業で働いた経験、そして10年住んでいる大好きな日本の経験を踏まえて、ドイツ人として両国の働き方の違いについてお話しします。
その後、マネジメント 3.0 のイェイ・クエスチョンを使って、自分の働き方を見直し、改善するミニワークショップを体験していただきます。
(1)どんな実験をすればいいのか？
(2)どんな良い習慣を繰り返すべきか？

この度、クリエーションラインにAgile CoEという組織が誕生しましたー！ぱちぱちぱち
そして、そのAgile CoEの初代リーダーをやることになりましたー！ぱちぱちぱち

このセッションでは、私がAgile CoEのリーダーになるまでの道のりを振り返り、抽出できた「組織を変革していくリーダーに必要なこと」、「リーダーを任せられるために必要なこと」を発表します。

背景

クリエーションラインの中心となっているビジネスは受託でのAgile開発です。
大手製造業などを中心に、お客さん側の開発メンバーと一緒にチームを組み、Agile開発の導入・サービス開発を行っています。

そんなクリエーションラインですが、ここ数年で人数規模が急拡大しています。
私が入社した4年前から比較すると約4倍です。
この急拡大に伴い、Agile開発をあまり知らないメンバーが増えているという事実もあります。
それは開発・運用組織だけでなく、人事・マーケ・セールス組織でも同じことが言えます。
現場で手を動かしているメンバーだけでなく、マネージャーや経営に関わるメンバーでも同じです。

このままではコアなビジネスであるAgile開発を継続していくことが困難なのでは？
本気でAgile開発をしたい人がツラい思いをしてしまうのでは？
胸を張ってAgile開発をしている企業だと言えないでは？

そんな課題感の中から、Agile CoEが爆誕しました。
Agile CoEの立ち上げにあたり、私が最初のリーダーになることになりました。
社内にはアジャイルコミュニティでも知られているようなメンバーが何人もいます。
そんなメンバーと一緒にAgile CoEの活動を行っていくので心強い限りです！

もちろん、組織を変更したり新設したから問題が解決するのではありません。
社内にどう訴えかけていくのか、他の組織とどんな関係を築いていくのか、どんな目標を立てるのか、目標を達成するためにどんな活動をするのか、活動の優先順位をどう付けるのか、まず最初にやることは何か、そういった話が重要だったりします。
「Agile開発への理解を高め、よりいきいきした組織になっていきたい」という願いを叶えるためにAgile CoEは誕生しましたが、まだ僕たちの旅は始まったばかりだ！

話すこと

背景にも書いた通り、Agile CoEの立ち上げにあたり、私が最初のリーダーになることになりました。
社内にはAgileコミュニティに出入りしているメンバーが沢山います。
経験の長いメンバー、勢いのあるメンバー、コミュニティやイベントの運営を行っているメンバー…
開発者、スクラムマスター、アジャイルコーチ、組織開発を行っているメンバー…

「そんな多様ですごいメンバーがいる中でなぜ私がリーダーとして選ばれたのか？」

今回は自分がこの問いに向かい合って見えてきた「組織の中で変革を行っていくリーダーに必要なもの」または「リーダーとして任されるために必要なこと」について話していきたいと思います。

（同じような役割の人と話をしたいので採択の有無に限らず、Twitter/Facebookあたりで連絡いただければと）

心の健康と体の健康は別のものでしょうか？それとも相互に関連しているものでしょうか？

「体力がない人はメンタルヘルスが悪化しやすい」という研究結果もあり、適度な運動によって体力を維持することが心の健康にとっても重要だと私は考えています。

そこで、書籍「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」を参考にして計測とふりかえりを繰り返しながら健康のリファクタリング（身体的負債の解消）を行なっています。

基本的には1週間スプリントで以下を繰り返します。

• 計画づくり
• エクササイズとストレッチを実行
• 自分の身体のさまざまな数値を計測
• ふりかえり

とはいえ、理解は容易ですが実践は難しいのはスクラムと同じです。

継続するためには、楽しみを見つけること。
実行した結果が数値として見えてくる、身体や心の調子が良くなってくる。
自分自身の変化を感じとれるようになると、健康のリファクタリングが楽しくなってくるでしょう。

本セッションでは、計測項目として使えるフィットネスのユニットテストを解説し、肩こりや腰痛解消に効くヨガのエクササイズやストレッチを紹介します。

参考図書「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」より

健康の定義

• 健康な人物とは、ライフスタイルから病気を生じさせてしまうリスクが低い人物のこと

アジャイルダイエット宣言

• お仕着せのメニューよりも個人の好みを
• 得意なダイエットよりも栄養素のバランスを
• トレンドへの追従よりもカロリーの計測を
• ダイエットのプランへのこだわりよりも、自分自身の環境への対応を

３つの質問

• 昨日、健康促進のために何をしましたか？
• 今日、健康促進のために何をしますか？
• 健康であることを阻害する要因が何かありますか？

フィットネスのユニットテスト

• 1.5マイルウォーク/ラン
• プッシュアップ
• ハーフシットアップ
• シットアンドリーチ
• 体組成

お酒やソフトドリンクを飲みながら、みんなでわいわいしましょう！