皆様は、スクラムチームが走り始めるときにまずは何から始めますか？

　プロダクトバックログを作る？

　エレベーターピッチを作る？

　インセプションデッキを作る？

　とりあえず開発環境作ってみる？

　えーい！そんな暇はない！開発着手だ！！！

あるあるーと思った皆様。

そんな皆様に私がおすすめしたいのは、スクラムチームのメンバーは今なぜここに集まっているのか？を問うことです。

ゴールデン・サークル理論という言葉を聞いたことはありますか？

TEDの人気プレゼンテーション「優れたリーダーはどうやって行動を促すか」でサイモン・シネックが解説した理論です。

端的に言うと、人が真に突き動かされるのはWhat（何をやるのか）ではなくWhy（なぜやるのか）であるという内容です。

詳細はTEDの動画を見ていただきたいのですが、このWhy（なぜやるのか）こそ、スクラムチームが走り始めるときに最初にやるべきことなのではないかと思うのです。

実は、インセプションデッキの10の設問にも「我々はなぜここにいるのか？」という設問があるので、インセプションデッキを丁寧に作成したチームならWhy（なぜやるのか）を考える機会があるはずです。

しかし実際のところ、インセプションデッキをちゃんと作ったことがあるというチームはそれほど多くないのではないでしょうか？

インセプションデッキを作らない理由は様々ですが、そのようなことにかける時間が無いという理由が大きいのではないかと考えています。

そこで、時間が無い！という皆様にはWhyから始めることを私は提案します。

10の設問があるフルセットのインセプションデッキに比べれば、チームのWhyを決めることは時間はかかりません。

ですが、Whyを設定しないままチームが走り出すよりも、Whyがある方が間違いなくチームが力強く前に進むはずです。

このセッションでは、実際にチームのWhy / How / Whatをゴールデン・サークルに当てはめて設定した私の経験をもとに、Whyから始める際のポイント・Whyを訴求し続けるためにリーダーが取るべき行動・HowやWhatに陥りやすいケースとその対策について私の経験ベースでお話します。

このセッションを見ていただいた方に、「私もチームのWhyを考えてみよう！」と思っていただけるような内容にしたいと思います。

そして、実際にチームのWhyを設定して訴求・改善し続けることで、あなたのチームはなぜやるのかに基づいた力強い推進力を得ることができると、私は考えています。

あなたの現場では、こんなことがおきていませんか？

「ペアプロを導入したいけど、上司が…」
「Daily Scrumで何も話題が出てこない…」
「本やブログで書いてあったやり方をやってみたけど…」

同じような問題でも、現場によって有効な解決策やアプローチは違ってきます。
簡単にいうと銀の弾丸はありません。

そこで！

実際に皆さんの現場で起きている問題や悩みを出してもらい、とにかく前向きな6名が通用するかどうか分からない鉛玉を大量に提供したいと思います！

色んな現場で実際に試して
失敗したアイデア、
成功したアイデア、
社内のチェンジエージェントの観点、
社外のアジャイルコーチの観点、
あの現場での話、
この現場での話…
数ある鉛玉から自分の現場に合いそうな輝く弾丸を持ち帰ってください。

セッション中は

みなさんも無責任に「自分だったらこうするかなぁ」「こんなことしたら上手くいったよ！」という鉛玉をじゃんじゃん放流してくださいね！

みんなでわいわいしましょー。

前回から1年、360度変わった6人の姿にご期待ください！

変化がますます激しくなりリニアに先が予測できない状況において、強い組織、強いチームとはどういったものなのか、そして、どのように醸成すれば良いか。
多くのマネージャーやリーダーの方が悩まれています。

そのヒントの1つに自己組織化があると考えます。

では、チームの自己組織化を促進するには具体的にどうすればよいのでしょうか？
その解決策として、Management 3.0では多くの手法が紹介されています。

本セッションでは実際に手を動かして手法を体験する事で、勘所をご理解頂き、現場に持ち帰っていただく事を目的としています。

どんな手法を体験するかはルーレットで決定しますので、当日までのお楽しみです。
ただし、どんな手法でもきっとみなさんの組織やチームの円滑な運営、組織変革の推進に役立ちます。

私たちは ”明日から使える” 手法をより多くの方にご体験頂き、現場で活用頂き、少しでも現場が良く成る事を目指しています。
そして現場で実践した結果をフィードバックして頂き、良いチームを一緒に増やしていきましょう！

なお本セッションは、「人に優しい組織マネージメント」勉強会で6月に実施し、大盛況だったセッションの拡大版です。
勉強会の様子はリンク欄からご参照ください。

背景

• チームの熟成度: スクラムを組んでアジャイル開発に慣れてきた。
• プロダクト: 製造工場内の装置稼働率を可視化するシステム
• プロダクトのターゲット(エンドユーザー):  社内のフィールドサポート（と顧客）

一度は社内のPOからのインプットをもとにプロダクトを作っていたが、いざリリースしたら現場の求めるものとずれていて、かなり不評だった。

現場にしっかり使ってもらえるプロダクトにしたかったので、アジャイル開発の中心的な要素である、スプリントレビューにお客さんも入ってもらうことにした。

この開発ではレビューを行ってカスタマーからフィードバックをもらい、プロトタイプでの改善を進めつつ、本番プロダクトにも取り込んでいくというサイクルを1週間単位で回していった。

結果と工夫点

結果として、カスタマーが喜ぶと自信を持っていえるプロダクトができつつある。

このサイクルを回す中で、プロダクトを改善するだけでなく、スプリントレビューのやり方なども改善していった。

• 慣れてきても初回と同じくらい丁寧に導入部分を説明する。
• スライドでは、ビフォーアフターをわかりやすくして、価値が何なのかを伝える。
• システム仕様の説明を、カスタマーにとっての価値に言い換える。
• デモをしながら口頭で説明するだけではなく、スライドを併用して理解を促す。
• カスタマーがオンデマンドにデモ環境に触れるようにする。
• 期待値コントロールをして、プロト作成と本開発のバランスをとる。
• 第三者からのレビュー手法についてのフィードバック
• etc.

当日は、製造業のメッカである三河に赴いて、このようなサイクルでのスプリントレビューをうまく回すために行った試行錯誤を中心にお話し、皆さんからのご意見をもらいたいと思っています！！

海外で行われているWomen in Agile(WIA) という活動があります。WIAは、アジャイルコミュニティにおける女性のネットワーク構築やキャリア促進を支援する団体で、アジャイル活動における平等と多様性の包摂を目指しています。

皆さんの周りでは、多様性は活かされていますか？アジャイルの実践者が集まる中で、私たちはジェンダー差異を感じることが実はあまりありません。それは何故でしょうか？

アジャイルやスクラムは人間的な側面に着目し、小さなチームで相手に向き合い、「小さな違和感」を取り除いていく特長があるからです。本セッションでは、多様な現場で働いている私たちが、働く中で感じる「小さな違和感」に目を向けることがアジャイルチームにとってどう役に立つのかを語ります。

「小さな違和感」の端的な例は、女性に対する差別のようなものは職場にほとんどないのに、なぜか職場に女性管理職が少ない、ということです。これは直接変化させることはできないほど大きな問題だと思いますが、その裏にはとても多くの「小さな違和感」が潜んでいるのではないかと思います。偏見とか、自己否定とか、少数派であるのでやりにくいこととか、さまざまです。

さああなたも「小さな違和感」に気づいてみませんか？

対話しながらチャレンジングな目標の達成に向けてドリブンしていくOKRと、検査と適応を繰り返していくスクラムチームは相性が良いものだ、と私は考えています。過去には「OKR-based Scrum Team」と題して話したこともあります。ここではOKRのツリー構造を使って組織と個人の意思をいかに伝搬させてゆくか、特に「納得」をいかに醸成していくかという点に重きを置いて話しています。

ですが、実際に自分自身がOKRを運用している現場では、OKRを採用した2年目あたりから厳密なツリー構造というものからは脱却しています。ツリー構造にすることを重視すると、どうしても間に落ちてしまう部分が生まれてしまうというのがツリー構造をみなおすきっかけでした。同時期に「クリストファー・アレグザンダーの思考の軌跡」を読んでいたことも、ツリーを脱却しセミラティス構造に向かう直接の要因だったように思います。（本プロポーザルのタイトルは同氏による「都市はツリーではない」のオマージュになっているので、インスピレーション元がアレグザンダーであることにお気づきの方もいらっしゃることと存じます）

話は変わり、5月に開催された品川アジャイルのイベント「OKRってどういうのが正解なんだろう？」において、名著「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を題材にOKRとはそもそも何なのか、ということを川口さんとたっぷり話す機会がありました。ここで衝撃を受けたのが、あらためてこの本を読み解いてみると「OKRはツリー構造だよ」なんてことは一言も書いていない、ということでした。それどころか、私が自ら切り開いたと思い込んでいた「ツリーではない構造のOKR」は、しっかりとここで提示されていたのです。なんということだ。

気を取り直して。そう、OKRの分野の名著では「ツリーだ」なんていっていないわけです。けれども多くの現場はツリー構造に向かっているように思えます。
そして「ツリー構造に落とし込むのが難しい」といった、本来悩まなくてもよい悩みを抱えてしまうことになったりする…あなたの現場はどうでしょうか。

私自身、最初はツリー構造から出発しました。そこに窮屈さを感じセミラティス構造への転換を試み、メンバーからの意見をOKRに取り入れるよう工夫をし・・・今では、自己評価としてはうまくOKRと向き合うことができている、といえるくらいにはなりました。

このセッションでは私自身がどのようにツリーから脱却していったのかという話と、そもそも人はなぜツリー構造に向かってしまうのかという謎を解明する試みについて話せればなと考えています。

私たちRettyのtoB開発は、飲食店、営業、経理が使うアプリケーションを2チームで開発、保守、運用しており、それぞれのチームが1つのプロダクトバックログから決められた優先順位をもとにアイテムを取ります。

2チームで開発を進めるに当たり以下のような問題が起きました。

• 開発する領域が飲食店、営業、経理と複数あるため、2チーム間で情報共有がうまくできず、認識齟齬による手戻りが発生
• それぞれのチームで得意な技術領域やドメイン知識があるにもかかわらず、2チーム間で情報共有がされないまま開発に着手して無駄に調査の対応工数がかかってしまった

その課題を解決するために私たちは、プロダクトオーナーと開発2チームで集まって担当を決めるプランニングの際に、技術的知見やドメイン知識を持つメンバーが知見の少ないチームに一時的に所属してすすめるのが良いのではないかと考えました。
Rettyでは大規模スクラム Large-Scale Scrum(LeSS) を導入しており、その手法がLeSSにおけるトラベラーという情報共有のプラクティスに似ていたことから、トラベラーについて理解を深め積極的にトラベラーを活用して課題を解決しようとしました。

トラベラーを使って2チームで、うまく情報共有するためにどのように工夫をして課題を解決していったのかお話します。
「チーム間で情報共有がうまくできていない」と感じている方の参考になればと思っております。

安定性がより求められてきた製造業IT部門。一方で近年では世の中の状況も変わり、製造業IT部門も大きな変化を迫られています。これに立ち向かうためには人も技術も同時に変化（モダナイズ）していかなければなりませんが、各現場の努力だけではなかなか実現が難しいのが実状でした。
従来型の文化がまだ根強く開発の主体もオフショアの環境で人と技術のモダナイズをどう実現し広めていくか？Scrumを使って人と技術を同時に成長させられることを実例で示した私たちの小さな取り組みをご紹介します。
なお内容の配分としては組織変革全体に関する内容が３割、具体的な現場やチームの取り組みとその結果が７割位の想定です。

昨年のスクラムフェス三河2021では、「新米QA部門長がアジャイルな組織作りを実践してみかわ」というタイトルで、新米マネージャーのストーリーと意気込みを発表させていただきました。

今年のスクラムフェス三河2022ではその後のマネージャーとしての取り組みについてお話ししたいと思います。

まだまだ先は長いものの、QA部門長として色々見えてきたものや、様々なことにチャレンジして、失敗して、学んだことがあります。そして、もしかしてこれがQAマネジメント？と感じるものを、ここで一旦まとめます。

（この一旦まとめてみるのがスクフェス三河の良さw）

以下のような内容を話したいです。

「ラインマネージャーとQAマネジメントは別物！？」

「突然動かなくなる3rd Party。情報集めと定期的な配信」

「自動テストにできない、定期的な手動リグレッションテストはアウトソースしよう」

「ねぇねぇ。QAにスクラムマスターいる？もちろんいるよ！」

「大変です！テストケース数が多すぎて自動テストが終わりません。。。」

「来週リリースするので出荷承認お願いしますー　え？」

「POも開発エンジニアもテクニカルライターも。みんな集まれ。社内専用Janet研修」

「QAもエンジニア。QMファンネルを使って自身のキャリアをイメージしよう」

「社内チリング会でスクフェス視聴してYYしよう」

「ハイヤリング×ハイヤリング」

努力・忍耐。根性なんて大嫌い。
人生の計画なんてとっくに消えた。
周囲に溶け込めず学校や会社、時には家族の中でも孤独を感じてしまう。
エンジニアになれたと思っても、何の役に立っているのかわからない。
キラキラにワクワクして出かけたら、輝けない自分との違いに絶望。
そんな弱虫はこの世にいる価値があるのか？
ずっと辛いままじゃないのか？
この世から消えていなくなりたい。
苦しくてもがいても変化は見えない。
そんな日々をただ過ごすだけ。

でも、気がついたらこんなに生きている。
諦めていた未来がここにある。
なぜだろう。

これを運というのだろうか？
やっぱりただの偶然か？
いや、それとも何か見落としていることがあるのか？
もしそうだとしたらどこかに必然はあるのか？

それがわかれば弱虫は弱虫のままでいいんじゃないか？
弱虫が弱虫らしく生きることで小さな小さなイノベーションを起こせるなら、
弱虫が弱虫らしく生きることで実は小さな成功に繋げられるかもしれない。

なりたいものが見つからない。なりたいものになれないと悩む中、
再考を繰り返し、誰の真似もできずもがき苦しむ過程が、オリジナリティを持った個々の成長や成功への道のりにつながる可能性について共に考える機会になればと考えています。

スクラムやアジャイルの事以外の内容ですが、概念はスクラムやアジャイルな開発はもちろん、組織やチームの中で複雑な人間を捉えるヒントになる部分もあるかと思います。

なお、内容の一部には心理学的な要素および、
eroccowaruicoが過去に経験したネガティブな体験を表現した内容を含みます。

かつて滝行をしていたころ、私たちにとって "線を引く" ことは息をすることより自然でした。

降ってくるタスクに感謝し "線を引き"
突然の思い付きにも動じず "線を引き直し"
過去の川からの鉄砲水によって "線が崩壊し"……。

そのたびに進捗を管理する立場の方々から、 "線が正しくないんじゃない？" "ちゃんと線引いてよ" と言われ続けてきました。
私たちはそれを真摯に受け止め、"線を引く" ことに時間を使いました。

若干タイトル詐欺なんですが、アジャイル開発をしている現在でも私たちは "線を引いて" います。
ただし、どの人にも "線引いてよ" と言われることはなくなりました。

"線を引いた" あとは、"うん、大体わかった"
"線を引きなおす" 時も、"いいね、変えていこう"
"線が崩壊した" 場合でも、"知ってるよ、進めていって"

ここを見ている方の大半は「タスクの優先順位決めが重要」という話をしても「知っとるわそんなん」となると思うので、
どのようにして "進捗を管理する方々" にアプローチしていったかを伝えていきます。

例えば以下のようなアプローチになります。

• タスク一覧を "進捗を管理する方々" が確認できるよう見える化した
• 見える化することで、飛び込みタスク等、優先順位が変わることを "進捗を管理する方々" に連絡しやすくなった
• 連絡しやすくなったことで、"進捗を管理する方々" がプロダクトの現状を認識しやすくなった
• 上記をチーム内全員で改善しつつ、より良くなるようにスクラムの基本に忠実に実行した

このようなアプローチをした結果、"進捗を管理する方々" の認識に大きな差がみられるようになりました。
そして、"進捗を管理する方々" は現在、"ステークホルダー" としてふるまっていただけるようになっています。

私たちが "線を引く" ことよりも優先すべき事項を見つけられたため、伴って有効に開発ができるようになりました。
製造業における "線を引く" 開発方針に対して、アジャイル開発のメスを入れることができたかと感じております。

もし "進捗を管理する方々" への対応に困っている方がいれば、このトークを聞いていただければと思います。

AndroidとiOSの組み合わせのような異なるプラットフォーム向けにサービスを提供する場合、どうすれば効率良く開発を進めることができるでしょうか？FlutterやXamarin、KMMといったマルチプラットフォーム向けフレームワークを使うのも１つの手でしょう。しかし、KotlinやSwiftのように全く異なるコードベースであっても、知見を共有し協調できるようなチームを作ることによって、開発速度を維持したまま高品質なソフトウェア開発を行うことができます。この発表では ①開発速度を維持する ②高品質なサービスを提供する の２つの観点から、私達のチームの試みを紹介します。

①開発速度を維持する
全く異なるコードベースで複数プラットフォームに対応する場合、スクラム開発の工程にも工夫が必要です。そこで鍵になるのがDesign Docsです。Desgin Docsは実際に実装を行う前に書くドキュメントの１つで、開発する機能の背景・設計・検討する実装方法を予めまとめ、レビュープロセスを経ることで属人性や実装の出戻りを排除します。私達はAndrod/iOSで共通のDesign Docsを作成し、知見を共有しています。

②高品質なソフトウェアを提供する
より使いやすいアプリをお客様に使ってもらうため、ドッグフーディングと呼ばれるQAとは別に自分達で成果物を触って改善や問題を事前に発見する手法を実践しています。ドッグフーディングでは、プラットフォームの垣根を超えてお互いのアプリを触ることもあります。

プレゼンテーションでは、Android/iOSエンジニアが一つのチームとして楽しく協調しながら開発を進めていく経験や工夫について、模擬機能開発を例にお話します。

東京海上日動のプロダクトを開発する我々は、『ビジネス部門との協調』『早く市場からフィードバックを得ること』を目的に、2019年からアジャイル開発をスタートしました。
スタート時点での実態としては『野良スクラム』・・・・ 
『野良スクラム』からの脱却を掲げ、『ピュアスクラム』を目指し3年が経過し、徐々にビジネスに価値を届けることができるようになりました。
また、組織の規模も拡張し、3チームしかなかったスクラムチームが、今では約15のチームが存在しています。
一方で、組織の規模が大きくなることによるサイロ化により、類似コードの重複開発や、デリバリーを優先することによる品質の低下が発生・・・
サイロ化を解消し、組織としての学びを蓄積するために、バーチャルチームを立ち上げました。

バーチャルチーム
 スクラムマスタ : 各チームの課題解決
 アーキテクト : アーキテクチャレビュー 共通部品化
 デザイナ : プロダクトデザイン UIレビュー ユーザインタビュー
 SRE : 運用の可視化 運用から開発へのフィードバック
 QA : ポストモーテム プロセス改善 テスト自動化

スクラムチームが自己管理型であることを尊重しつつ、バーチャルチームが組織横断の課題を抽出・検討し、スクラムチームのフローの進化をサポートしています。
みなさんの組織でも、活用できるエッセンスがあると思いますので、ぜひ聞いて欲しいです!

【参考】

以下ニュースの「スクラムチームの体制」にある「バーチャルチーム（ユニット）」にフォーカスしてお話します

https://bizzine.jp/article/detail/7032

※要員交代の荒波に揉まれたチームとその変遷　の続きです。

人が入れ替わるスクラムPJが無事（？）終わり、そこで得た気づきをお話したいと思います。

スクラムマスターから開発者へのジョブチェンジ、体制変更/人の入れ替え、マルチベンダーが故にベンダー間のやり方が違う所からチーム内での衝突が発生したことなどを通してPJを1つ終えた自分の中で見えてきたもの。

このPJを通して（大変でしたが）当たり前だけど忘れてはいけないこと、次につながるものが得られたので、それをぜひお話して皆さんからのご意見や感想を頂いてみたいなあと思ってます。また皆さんも何か気づきがあって持ち帰ってもらえたら嬉しいです。

「スクラムチームにスクラムマスターは本当に必須ですか？」

スクラムマスターがいるのに、成果が出ていないチームもあります。

スクラムマスターがいなくても、成果が出ているチームもあります。

「その真髄はどこにあるのか？」

異なる立場で向き合う3人のスクラム実践者と紐解くセッションです。

我々3人が見てきた様々なスクラムマスターを紹介します。

• 専任
• PO兼任
• 開発者兼任
• マネージャー兼任
• SM無し
• ペア
• 複数チームのSM
• プロパー
• 社外のメンバー
• 新社会人
• 開発未経験者
• 開発経験者
• サイレントSM

様々なスクラムマスター・チームを見てきた3人が今考えていることはこのような感じです。

• SMの人数とチームの成長は必ずしも相関していない
• SMの役割を他のメンバーに分散しても良いのでは？
• 明示的にSMのラベルを貼らなくても良いのでは？
• SMの役割が多すぎるので1人でやるの難しすぎるのでは？
• SMのスキルが必要なのはスクラムだけじゃないのでは？
• SMの練習はスクラム以外でも出来るのでは？
• SMの勉強だけしていても良いSMになれないのでは？
• SMのゴールや幸せとは？
• SMのキャリアはアジャイルコーチが多いけど他に何があるんだろう？
• SMを長期間継続している人がいないのはなぜだろう？
• あらためて、SMとは？

このセッションでは、上記のようなテーマを3人と一緒に考えてみる時間です。

皆さんも一緒にスクラムマスターの価値を大解剖しましょう！

コミュニティでの出逢いがきっかけで、2021年4月からコーチングを受け始めました。
最初は、コーチングとは何なのか？コーチングを受けると何が起きるのか？...がなんとなくしかわからないような状態でスタートしましたが、セッションでは毎回様々な学びや気づきがあり、コーチングを経るにつれて確実に自身に変化が起きました。

例えば

• 自身が思いもよらない価値観を持っていたこと
• 自身が何に突き動かされているか
• 自分がサボタージュしていたこと

などについて、コーチングを受けることで気がつきました。

本セッションでは、自身がコーチングを受けてどのような事に気がつき、どのような過程を経てどんな行動変容が起こったのか？を説明することで、自分自身を変えたいのに中々変えられない人が変容を起こすきっかけを掴めることを目指します。

また、セッション前半では自身が受けているコーチングの中身についても説明するため、コーチングに興味があるけど今ひとつ実体が分からない...という人が、コーチングがどういうものなのかを知る手助けになればと思います。

2012年にアジャイルと出会い、こんな働き方をしたい！との思いから色々な書籍・研修・コミュニティ活動を通じておよそ10年知識を溜めてきました。

そして、プロジェクトマネージャーをやりながらスクラムの要素を少しずつ入れてみたり、アジャイルやりたくて転職したり。

そんな紆余曲折を経てようやくスクラムをやってる現場に入りましたが、そこで実践されているスクラムに違和感を覚えます。自分の学習してきたものと何か違う。チームや進め方が何かうまくいってない気がする。そもそもスクラムマスターがいない。

そんな現場をいくつか過ごし、どの現場もうまくいってないのはスクラムマスターがいないことが原因に違いないと考えました。

「これまで10年もいろいろ学習してきた。自分がスクラムマスターをやれば良い感じにスクラムを回せるようになるできるだろう！」

そんな思いから専任スクラムマスターとなりスクラム未経験のメンバーとチームを組みます。

意気揚々とメンバーにスクラムについてレクチャーし、今まで得た知識を活かしてスクラムでプロジェクトをスタートさせました。

しかし、実際にやってみると全くうまくいきません。

進捗共有だけのデイリースクラム、ベロシティ0、進まないカイゼン、チーム解散。などなど。

まさに失敗だらけ。知識だけではうまくいかないことを痛感しました。

本セッションでは、自分が経験した失敗と起きてしまった背景、その中で試行錯誤したことなどを紹介したいと思います。

N＝1の話しではありますが、スクラムマスターをこれから始める方や始めたばかりの方のお役になる話しができれば嬉しいです。

3年間開発の現場で、おもに QA として、テスト、パイプラインエンジニア、そして開発チームの PM からの雑用という立ち位置で開発チームのプロセス改善を行い、以下のような発表の機会をいただけました。

• • Scrum Fest 三河 2021
    • 品質をプロセスに組み込む文化つくり
  • Scrum Fest 大阪 2022
    
    • 開発スピードと品質を向上させるための QA の関わり

どこでもテスト、どこでもふりかえりということを念頭に開発プロセスに組み込んでいます。

設計書ができてからテスト、コーディングが終わってからテストとかになると必ず後戻りが発生します。

鉄は熱いうちに打てという諺がありますが、プロセスを実践しているうちに疑問点やモヤモヤ感(違和感) 、これはヤバい臭いがする！ってことを感じた時点で、即テストを行います。

テストと言っても実際に動作させるわけではなく、メンバーのお互いの特性を生かして、仮説を立てて実証してみたり、設計書を見直しを行っていく作業も含まれます。

疑問点やモヤモヤ感  (違和感) に潜んでいるものは必ず何かしらの『バグ(欠陥)』という間違った結果を生み出す人間の行為『エラー』となりうるものです。

疑問点やモヤモヤ感  (違和感)という魔物は、最初は小さくても徐々に暗黒面に飲み込まれ、やがては手に負えない暗黒卿へと育ってしまうことが多いものです。

これらは可能な限り予防し、もしエラーがあったとしても早期発見、早期治療できるようにどこでもテストを実践しています。

さらに、このような小さなヒヤリハット(インシデント) はすぐに忘れやすいので、何かあったときにはプロセスごとにふりかえりをして、そのヒヤリハット(インシデント)を共有・共感して次のプロセス、プロジェクトに活かせることがないかを考えるようにしています。

人間は忘れる生物なので、嫌なこと、都合の悪いことを開かずの引き出しにしまい込んでしまい、「あれ？なんか辛かった気がする～、けど、まっいいか」となるので、その前に小さなことを思い出すためにどこでもふりかえりということを考えています。

このように品質はプロセス (システム) 、そしてそれを作り上げて実践していくメンバー (全員のマインド) という理念を基盤に、開発とテストが一蓮托生、同心協力でプロジェクトにあたるようなチームにしていることをお話しします。

スクラムフェス新潟でメンタルヘルス悪化当事者がどのように体調を崩し、復活を遂げたのかお話してきました。（スライドはこちら、スクフェス新潟のプロポーサルはこちら）

今回はその続編として、「社会復帰（会社員への復帰）はどうだったのか？」についてお話させていただきます。

結論から言えば大変なことばかりでしたが、それによってメンタルヘルスにどのような影響がでたのかなどもお話させていただきます。

転職をした6月からの約3ヶ月間を1ヶ月毎に区切ってみて、メンタルヘルスの波と体調の波、当時の仕事の状況、同僚や上司とのコミュニケーションなどを振り返っていこうと思います。