“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 tress.  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.  If it were possible to condense these years of learning into a book or method or 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. 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」は本では学べません。 もし、こうした長年の学習を本やメソッド、講義に凝縮することが可能なら、この技術に価値はないでしょう。代わりに、武術や楽器の習得と同じように、導入して何年もかけて心と体を鍛えなければならない。そのためには、時には厳しいルールやメソッドに従った上で、直感や感覚、論理を駆使して、自分では思いもよらなかったような方法で挑戦することが求められます。

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

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

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

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

このワークショップでは、TDDの基礎を手を動かして経験し学ぶことを目的としています。

TDDは、コードを書く前にテストを書くことで品質の高いコードを作成するための手法です。スクラムは品質の高いプロダクトを作成することが重要であり、スクラムとTDDを組み合わせることで安心感を持って品質の高いプロダクト開発を進めることができます。このワークショップでは、TDDの基礎を学び、スクラムにおけるTDDの重要性を理解することを目的とします。

ワークショップの流れ:

• TDDの基礎知識
• TDD実際にやってみよう！
• TDDのよくある質問
• スクラムと組み合わせる

このワークショップでは、スクラムにおけるTDDの基礎を学び、実際に手を動かしてTDDを実践することができます。また、スクラムにおいてTDDがどのように役立つかについても学ぶことができます。ワークショップの最後には、参加者にはTDDを実践するための基礎が身につき、スクラムにおいて品質の高いプロダクトを作成するための手段としてTDDが重要であることを理解してもらえるようになっています。

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

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を実施したことでその後のふりかえりの本題にどのような影響があったのかをご紹介します。

昨日まで一緒に頑張っていた仲間がいて
ある日突然、バランスを失ってしまったこと、ありませんか？

組織で誰かを
信用できなくなったり
尊敬できなくなったり
頼れなくなったり

そんな時、あなたはどうしますか？

誰かに相談、したいですか？

本当の声は、第三者や相談窓口には聞こえてきません。
組織内に受け取れる場所がなければ、悲劇は突然訪れるだけです。

組織がこんなギリギリの状態にならない方が良いのは間違いありません。
一方で、瀬谷さんのお話は身近なところでも起きてしまっていると感じてもいます。

このセッションでは、
自分の辛かった体験をベースに
機械的ではない組織の作り方についてお話します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「_ _ 、_ _ 、_ _ 、_ _ 」_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ？

参考 : 【0文字クイズ】クイズ王、文字がなくても正解できる説

みなさんはどれくらいアジャイルテストを知っているのか？すっとその知識を出せるのか？不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにアジャイルテストのクイズを出してその知識や引き出し方を確認してもらえればと思います。

当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

みなさん、毎日ふりかえりやってますか？

去年のふりかえりカンファレンス 2022 で、『実録！ふりかえりを60日間続けると人はどう変わるのか？ふりかえりをふりかえり！』という発表がありました。
その発表を聞いて、自分たちもやってみると何かあるかも！？となったので、毎営業日に集まってふりかえりをすることになりました。

参加メンバーはアジャイル推進室のえーちゃんとふりかえり初心者の人事のねこやなぎさん + Gather で集まったゲストさん。
ふりかえりカタログから引用してやってみたり、自分たちで新しいふりかえりを考えてみたり。
もし今日がうまくいかなかった時も、1日の終りに少しだけいいことが見つかるように、明日を楽しく過ごせるようにといったテーマを持ちつつ
各々が今日1日のふりかえりをやっていました。

最初は1~2ヶ月続けばいいかなと思っていたら、半年・1年といつのまにかふりかえりしないと落ち着かない習慣となってきました。
そして仕事の中でもちょっとずつ変化が起こって、「ポジティブさ」や「前向きに」働くコツがつかめてきたのです。
今回は、1年続いたコツというより、1年間やってみた自分たちの変化や気付きをメインに発表します！

当日は見せられる範囲で実際に私達が使っている Miro なども公開していこうと思います！

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

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

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

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

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

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

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

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスや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 の収益の中からサポートをいただいています。ありがとうございます。

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

チーム作りにおいて、たとえば、小数の意見。ひとりの感想。感情。そういう小さな声には、注目していなかった。

大事なものではある。けれど、プロダクト開発という大きな流れを見たときに、それらは大勢に影響を及ぼすものではないと思っていた。

プロセスやフレームワークが適切であれば、チームはうまくまわる。そう考えていた ──

システムコーチング®のトレーニングを受け、そうした小さな声を聴くことの重要性に気づいた。そんなお話しです。

ソフトウェアに何かエラーが起きたとき、（ちゃんと作られていれば）エラーメッセージが出ます。それによって、どこに異常があるのか、どう対処すればいいのかが分かります。

チームも同じです。小さな声、声にならない声は、チームから出ている何かしらのメッセージです。システムコーチング®とは、そのメッセージの意味を明らかにし、チームの変容、適応、問題解決をうながすアプローチです。

システムコーチングの概要や肝になる考え方を紹介するとともに、今のぼくが見えている、小さな声を聴くことの重要性・可能性について、アジャイルの観点も混ぜながら語ろうと思います。

テスト自動化8原則はテスト自動化研究会が提唱するテスト自動化における基本原則です。ただし、開発者向けに書かれている原則も多いため、そもそもどういったことがチームに起こるか想像しにくいのではないでしょうか。そこで、これまでの様々な経験や失敗を踏まえて、スクラムチームを運営する目線で5箇条を考えてみました。

• 初回リリースはあえて手動でテストをしよう
• ツールを考えつつ、何がしたいかも整理しよう
• 価値の下がったテストケースは捨てよう
• チーム全員でテストケースを見てみよう
• 失敗も経験してチームをレベルアップしていこう

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

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

Whole-Team Approachという単語は
誰もが知っていると思いますが、
やさしく説明できるほど理解している
アジャイルエンジニアは
そう多くないはず。
この大事なマインドセットのエッセンスを
赤ちゃんでもわかるようにしたのが本セッションです。

「チーム全員で品質の責任を取る」
などと言われると難しそうな感じがしますが、
本セッションをなんとなく聴くだけで
そのイメージを感覚的につかめます。

Webサービスのフロントエンドなど
身近なものに使われる一方で
ミッションクリティカルシステムのような
ガチガチの開発でも成功の鍵を握るとされる
Whole-Team Approachの基本を、
WhTAコンサルタントでありママさんでもある講演者とSigSQAの仲間たちが
赤ちゃんにでも伝わるように
と願って話す、このセッション。

アジャイルの世界で必要な大事なマインドセットを
チーム全員と学ぶきっかけに、
あるいはプロダクトマネージャーやエグゼクティブへの贈り物に
ぜひ役立ててください。

*○○ for babiesシリーズの絵本をヒントにセッションを構成しました

過去、SIer時代に「アジャイルって品質悪いんでしょ？」って言われてカッとなって作った資料を元にブラッシュアップして発表したいです。
基本的な内容はスライド欄にその当時発表した資料があるのでそちらをご参照下さい。

Web系プロダクトの開発に従事して得た経験が反映されると思います。

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

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

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

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

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

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

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

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

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

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

そんな中

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

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

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

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

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

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

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

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

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

始まりはとある日の居酒屋で…

2月某日、都内の居酒屋にて、前職のスクラムチームの恩師である3名の方との飲み会が開催されました。皆お酒も入り、スクラム談義に花が咲きます。そんな中、私の現在の職場についての話題になり、「今建設業界でシステム開発してるんですよ～」「建築の工程って意外とシステム開発と似ていて面白いんですよね～」「でも現場の方たちは今でもFAX使ってたり、スマホも持っていなかったり、びっくりするくらいIT化のハードル高いみたいなんですよね～、スクラム的に、逆にやりがい感じません？笑」など、建設業界でのシステム開発の話題へとシフトしてきました。これらの話を聞いた、尊敬するアジャイルコーチであるYさんが一言、

「それ、スクフェスで発表してみたら面白いんじゃない？」

他のお二方も「それ、いいじゃん！」「絶対面白いよ～！」と続きます。そこで即座にスクフェスの日程を調べ始める私。

「この間の東京、もっと早く知っておけば良かった～。3月に福岡がありますけど、ちょっとスケジュールタイトすぎますね。あ、5月に新潟ありますよ！これに出ましょう！(即決)」

翌日、会社の上司にスクフェスに出て発表したい旨を相談。すぐに「いいよ！」の返事を貰う私。こうして、私のスクフェスでの挑戦が始まりました。

「これってもしかして、スクラムで建設業界もアップデートできるのでは…？？」

皆さまも薄々気づいているかもしれませんが、建設業界はIT化で大きく出遅れています。その背景には、以下のような問題があると考えられます。

1. 高齢化と人手不足
   建設業界は、3K(きつい・汚い・危険)というイメージが強い業界です。そのため、若手が入ってもすぐに辞めてしまったり、そもそも若手が建設業界を最初から選ばなかったりしてしまい、慢性的に若い働き手が不足しています。また、このために他の業界と比較しても特に高齢化が進んでおり、将来的に熟練した職人の供給が、需要に急速に追い付かなくなると言われています。
2. 各工程間の断絶
   建物を建てる時、以下のような工程を経て建設が進んでいきます。
   　　企画 ⇒ 設計 ⇒ 部材の発注 ⇒ 部材の現場への納入 ⇒ 施工 ⇒ 竣工 ⇒ 維持管理
   この工程の中で、企画を担当するのはゼネコンや工務店、設計は設計会社、施工を管理するのはゼネコンから下請けをした建設会社、実際の施工を担当するのは建設会社から下請けをした専門工事店(大工さん、ペンキ屋さん、ガラス屋さん、左官屋さんなどなど…)といったように、各工程ごとに別の会社が担当することが一般的です。工程の流れはシステム開発によく似ていますが、各工程の担当会社が違うぶん、コミュニケーションの齟齬やリードタイムが非常に多く発生しています。
3. 超アナログ
   上記の工程で、企画・設計のような上流工程はCADやBIMの活用等で他工程よりも少しだけIT化が進んでいますが、中流・下流の工程では未だにびっくりするくらい超アナログなやり取りが行われています。例えば、弊社へ各工事店さんが部材を発注するとき、一番多い発注手法は「電話」です。そして、その次に多いのは「FAX」です。職場の高齢化によりIT化のハードルが上がってしまっていたり、末端の専門工事店は極小規模な会社であることが多いために導入コストがネックになっていたりと、この問題は他の問題も絡んでいるかもしれません。
4. 設計不備のしわ寄せが下流工程に…
   現場の職人さんたちは、設計書を元に家を建てていくわけですが、実は設計書に不備があり、その場で何とかしなければならない場面が多々あるようです。(例えば、天井裏の配管のことを考えずに梁を設計したため、配管が梁に干渉してしまっていたり…)こういった事が起こった際、解決しなければならないのは現場の職人さんの仕事になります。こういったことが頻繁に起これば起こるほど、現場の職人さんが解決策を考え、その場で部材を加工し、施工し直すという手間と技術が必要になってしまいます。あれ、これってシステム開発でも見た事あるようn……

こういった問題を知り、私は思いました。

「建設の工程ってWFに似てるとこあるよなぁ。上流の不備のしわ寄せが現場の職人に現れるのも似てるし。…あれ？って事は、もしかしてスクラムの価値観ががシステム開発の現場を変えたように、スクラムを使って建設業界もアップデートできるのでは？？」

そこで私は野原ホールディングスに入社し、スクラムを通して業界の課題解決に取り組んでいこうと決意したのです。

スクラムの価値観で建設業界のアップデートへ…

私は野原ホールディングスへは昨年10月に入社したばかりで、入社から現在まで、WFしか経験したことのない他のメンバー達に向けての勉強会の開催したり、社内向けシステム開発のプロジェクトでスクラムの手法を試したりして、社内の理解を促進する取り組みを実施しています。そして今年の5月頃から、本格的にスクラムでの社外向けシステムの新規開発プロジェクトをスタートさせる予定です。今回の発表では、建設業界の抱える問題点と、それらをスクラムの価値観をどう用いて解決しようと考えているか、これから具体的にどのような取り組みをしていこうと考えているか、などを中心にお話できればと考えています。

まだまだ道半ばではありますが、組織に初めてスクラムを導入しようと取り組むアジャイルリーダーの方々や、建設業界をはじめとする業界全体のIT化、ひいてはDXに興味のある方のご参考になればと思います。

【Tips】そもそも、「野原ホールディングス株式会社」って何の会社？

現在私の所属する「野原ホールディングス株式会社」は、慶長三年創業の建材商社です。主力商材は内装建材で、特に壁材(石膏ボードなど、建物の壁の中に使われている部材)をメインに取り扱っています。自社での生産ラインは保持しておらず、全ての商材をメーカーより仕入れ、それを工事店へ販売しています。そんな商社がなぜエンジニアを雇っているのか？きっかけは、社長の交代でした。

現在の社長である野原弘輔氏が、父の後を継いで社長に就任したのは2018年。IT化が大きく出遅れている建設業界にもIT化の波が徐々に起こってきている現状を分析し、「このまま建材の卸しだけをしていたら、時代に取り残されて会社が無くなってしまう」と感じていた弘輔氏は、社長就任をきっかけに会社を「建設業界のIT化・変革を促進する」会社に造り変え始めます。そして、「建設業界を根本からアップデート」するという方針のもと構想されたのが、3D図面に時間(工程管理)や価格といった付加情報を付与した「BIM」というデータを情報基盤として、プロジェクトの全行程でBIMを活用することで効率化を図るという「BuildApp」です。こうして現在、開発者人材を大幅に増員し、システムの一部機能の開発を終え、ゼネコン各社との実証実験を経てカイゼンを重ねると共に、開発未着手部分についても随時要件の洗い出しや開発を行っているという状況です。

「観察さえ上手くなれば、もっとチームのことを理解できるはずだ！」

6ヶ月前の私は、そう考えていました、、、

このセッションでは、6ヶ月間人類学のゼミに参加した経験をもとに、人類学的視点がどのようにチーム支援に立つかをお話します。

支援する立場として感じた効果は、下記のようなものです。

• チームメンバーと向き合い、チームで起きていることに気がつくことがよりできるようになる
• チームで起きていることに向き合い、受け入れることができるようになる
• 自分の持っている思考の偏りやフィルターに自覚的になることができる

また、チームの支援を行う立場にいなくても、自分のいるチームをより良くしたいと思う人が、実際に働きかけを行う時に人類学的視点がどのように効果を発揮するか、私の経験を交えてお話します。

自分のいるチームをより良くしたいと思うする立場として感じた効果は、下記のようなものです。

• 始めるべき難しい会話を始める勇気が出る

近年、1人目QAとして活躍される方が増えてきました。1人目として行ったことの事例もweb上で見かけることも増えました。次なる関心はその先の話です。

今回は、2年目に行った取り組みのうち、開発チームの外側からの支援とチームの中に入っての支援両方を行った経験についてお話します。

（支援とは主に、テストスコープの決定、結合テストの設計・実行の支援を指します）