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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2年前のScrum Fest Mikawaで、初のチーム登壇をしたチームがいました。
そのチームの名前は「オキザリス」。
2年前のこの日、初めて名前が付けられたチームです。

「オキザリス」という花名前に込められた思いは4つ。

• 輝く心
• 喜び
• あなたと過ごしたい
• 決してあなたを捨てません

これらを大切にしながら、チームは成長を続けて、またMikawaに戻って来ました。
2年前は蕾（つぼみ）だったチームが、2年間できれいな花を咲かせることができました。

このセッションでは、「スクラムフェス」に魅せられ、憧れ、手を伸ばし続けてきたチームが、どのような変化の軌跡を辿ってきたのかを語ります。

チームメンバー同士が語りながら、昔から今までをふりかえり、どんな変化が起こったのか、なぜそういうことをしたのかを紐解きます。

今はまだ小さな一輪の花ですが、これからはその花をより増やし、広げていきたいと考えています。
私たちも、フェスによって希望を受け取りました。
45分という時間の中で、みなさんにも希望のバトンをお渡しできればと考えています。

海外ではPixar、Google、Netflixなど、様々な企業がインプロ（即興演劇）を企業研修として取り入れています。
アジャイルとの関係では、Lyssa Adkinsの『Coaching Agile Teams( https://lyssaadkins.com/product/coaching-agile-teams-paperback/ )』の一節で、アジャイルチームにインプロが役立つものであることが記載されています。

私（森）も拝読しましたが、
・インプロがチームメンバーのクリエイティビティを取り戻すものである
・相手のアイデアを受け入れることがクリエイティブな発想のスタートになる
ということが当たり前のように受け入れられているのを感じました。

一方で、日本ではまだまだマイナーなものであり、価値や活用イメージが湧かないという声も多く聞こえてきます。実際にスクフェス大阪2022( https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16538 )での発表後「アジャイルの現場とどう繋がるのかイメージが湧かない」「社内に説明するのが難しそう」というご意見もいただきました。

そこで今回のセッションでは、インプロの価値について実体験をベースに伝えていきたいと思います。インプロバイザー（=インプロを生業とする人）が実際に仕事現場で役立ったエピソードやそこから導き出せる価値を言語化していきます。

例えば私（森）の経験談としては、先日、会社の社長を交代するという一大イベントがありました。弊社はインプロの研修会社のため、社員はすべてインプロバイザーで構成されています。一大イベントと言いつつ、実際の交代にあたっての話し合いは、合計10分程度。当人同士で5分、社内会議で5分程度。しがらみなく交代がされました。
（世間の皆様の反応を受け、社長交代というイベントが一般にはかなり大きなできごとであると改めて実感しています）

このような、インプロバイザーならではの課題解決や状況を打破したエピソードとして、世間的には大きな話から、身近にあるちょっとしたマインドセットまで幅広くご紹介したいと思います。

この発表を通してインプロの価値を少しでも皆様にお伝えでき、活用イメージの一助となれば嬉しいです。

背景

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

一度は社内の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と向き合うことができている、といえるくらいにはなりました。

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

ただいま三河。今年も帰ってきました。

昨年のスクラムフェス三河で紹介したチームNOCKnock。あれから1年経過しました。

メイン業務を持つメンバーが、隙間時間を使って活動する遊撃部隊のようなチーム。そして、社内外への発信や組織運営をスクラムでやってみる実験体のようなチーム。

【 「継続してお客様のビジネス成長に貢献する」で有名な強くしなやかな価値実現集団 】をビジョンに掲げ活動してきましが、チームはビジョンに近づけたのでしょうか？

そんなNOCKnockの1年間の活動から

• 活動したこと
• 活動の成果
• 成果への道のり
• 学んだこと

をふりかえり、

• ビジョン・ゴールに近づいたか
• 今後の活動に向けてどんなチャレンジをしていくか

などを踏まえた話をしたいと思います。

このセッションから得られる情報は、すでにスクラムを実践している方はもちろん、これからスクラムを始めてみたい、開発はしないけどスクラムのエッセンスを取り入れたい方にも有益な情報になると思います。

このNOCKnockの活動には実験的な要素も含まれています。

そんな内容を皆さんに伝えて、何かの学びになればとてもハッピーです。

Scrum Fest Osaka 2021で『シン・仮説検証 70,000枚の付箋で分かった仮説検証のエッセンス』という発表をし、そのなかでYOWというやり方を紹介しました。
https://speakerdeck.com/moriyuya/shin-hypothesis-testing

YOWとは簡単にいえば下記の頭文字です。
　Y:やったこと
　O:起きたこと
　W:分かったこと

行動と、行動によって起きた結果と、行動が結果を引き起こしたメカニズムに焦点を当てることで、自分達の身のまわりに起きている出来事の理解を深めます。その深まった理解を元に、次の行動を効果的なものに変えていくフィードバックループの方法です。

Scrum Fest Osaka 2021では簡単な紹介だったにも関わらず、多くの方に使っていただき、Scrum FestやRSGTで活用事例を紹介していただきました。日常的に使われている方やチームも現れてきています。

　『読書に悩むあなたに贈る50の読書方法カタログ / reading catalog Best50』
　https://speakerdeck.com/aki_moon/du-shu-ninao-muanatanizeng-ru50falsedu-shu-fang-fa-katarogu?slide=26

　『音のような言葉 〜ちゃちゃっとチャットで楽しむちょっとしたコツ〜 / words like sounds』
　https://speakerdeck.com/satoryu/words-like-sounds?slide=65

　『JavaScriptって美味しいの？の私を、プログラミングの深淵をうかがい知るところまで連れて行ってくれた、ふりかえりの力』
　https://www.slideshare.net/ShigeoKonno1/2022pdf-251548859/14

　『Extreme Small Patterns -チームを100倍理解する方法-』
　https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16114/extreme-small-patterns-100-

　『ふりかえりからはじめよ - チームづくりのシンプルな本質 - / start with RETROSPECTIVE』
　https://speakerdeck.com/takaking22/start-with-retrospective?slide=95

　『些細な変化に対する感応度を上げるために / Increase sensitivity to minor changes』
　https://speakerdeck.com/aki_moon/increase-sensitivity-to-minor-changes?slide=12

　『ふりかえりカタログ / Retrospective Catalog』
　https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45dd-911b-f8e5f1308333?slide=57

プロダクトは分かったことしか作れない

私たちはなにかしらのプロダクトを作っています。直接的にプロダクトを作る人もいれば、プロダクトをユーザーが購入できるように流通を確保する人もいますし、困ったユーザーをサポートする人もいます。

これらの仕事は、はじめての人ができるような単純なものではなく、知識や経験といった「分かっていること」を積み重ねて、ユーザーを助けられるだけの能力を持ったプロフェッショナルによってプロダクトは実現されています。

この分かっていることの質と程度はプロダクトに反映され、性能や、価格、ものの使いやすさに繋がります。よりよく分かっていけばプロダクトはより手間無く、簡単に、安全に変化しています。

この分かったことを積み上げるための方法として、YOW(やったこと/起きたこと/分かったこと)を紹介します。

毎月登場するフレームワーク、振り回される私たち

さて、さまざまな専門家が毎月のように新しいフレームワークを発表しています。みなさんも仕事をよりよくするために新しいフレームワークを採用して試してみたり、自分達で作ったり組みあわせたりして、仕事の流れをより良くできないかと工夫されていると思います。

ところがフレームワークを試してみたものの、確かな効果を実感したり、使いつづけているものは少ないのではないでしょうか。

・使ってみたもののピンとこなくてやめてしまった
・効果はあったけど時間がかかりすぎて、またやる時間がとれず放置してしている
・次から次へと出てくるフレームワークに振り回されている気がする

改めて思い返してみれば、私たちはそもそもフレームワークとはなんなのかを教えられていなかったり、どのように仕事を組み立てればいいのかはっきりしないまま、試行錯誤しているのではないでしょうか。

YOWはこのような状況を変え、フレームワークに振り回されるのではなく自分達の手中に収め、仕事そのものの設計を自由自在にできるようにするために作った3分から始められる方法です。

本セッションでは、はじめてでもできるYOWの入門に加えて、私たちの仕事を組み立てる方法を紹介します。

■セッション内容
入門編 やってみるYOW
・はじめてのYOW
・仮説立案のYOW
・仮説検証のYOW

中級編 活用するYOW
・プロダクトはわかったことしか作れない
　・無知/無能/無関心から、知ってる/できる/当事者意識
・説明深度
・経験を開く
・飽きと覇気
　・「なにか面白いことないかな」
　・戻るシグナル
　・進むシグナル
・7つの観点
　・心の言葉、話し言葉、書き言葉
　・ないない言葉
　・予測される異なる結果

上級編 仕事の組み立て
・フレームワークの問題
・アクティビティスペースで評価する
　・イベント型
 ・日常型
・研修とコンサルティングの不都合な真実
・効果的なフレームワークの採用と、仕事の仕組みを育てる
　・駄菓子(やりきる単位)
　・段階的な導入
　・スケーラブルな実施
　・他のワークとの連結
　・自己触媒ネットワーク
・仕事の地図を作る
　・問題空間
　・ONY(起きたこと/望んでいること/やってみること)
　・コーゼーションとエフェクチュエーション

昨年のスクラムフェス三河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エンジニアが一つのチームとして楽しく協調しながら開発を進めていく経験や工夫について、模擬機能開発を例にお話します。

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

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

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

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

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

例えば

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

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

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

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

私は夢と志を持って、新卒で製造メーカー子会社へ入社した。
官公庁向けのシステム開発で、本当に日本で生活する人の暮らしへ貢献したいと思い抱いていた。
しかし、蓋を開けてみると、現場は肉体、精神、どちらの健康に対しても良くない惨状だった。
仲間や自分自身を助けられないのに、世の中への貢献もへったくれもない。
そこで、私はアジャイルを導入しようとした。
結果、アジャイルは導入されることもなく、少しのカイゼンもできず、その会社を去った。

その様な背景を持った私は、現在、また製造メーカーに戻り、R&Dに携わらせてもらっている。
そこでもアジャイルやスクラムは導入していない。
ただ驚くことに、チームは会社が実施するアンケート調査の職場力とやらで、高数値を叩き出した。

チームは、
「研究調査の時は、何もプロセスを導入せず自由にタスクを進め、
　緊急時だけ、カンバンを導入する」
と言う、フレキシブル(?)な形に収まっている。

そこには、スクラムと言う言葉を出さず、学んだエッセンスを入れ込み、こっそり取り組んでいる背景もあるが、
なぜその様な形になったのか？

私は、どの様にチームに向き合い、どの様にチームを見ているのか？
過去の経験とも比較しつつ、紹介したいと思います。

----------
2022/8/14 追記
運営メンバーのみなさまから頂いたコメントに答える形式で説明することで、
よりセッションの詳細が伝わるかと思いますので、その形式で追記します。

> タイトルですが、このセッションの中で一番伝えたいところがそこなのか？と思いました。
> Learning Outcomeで述べているチームとは、去った前職のチームではなく現職のチームを指していると思っています。
> 現職でチームに向き合って前向きに取り組まれている話かと思いますので、
> ちょっとタイトルと本セッションで伝えたいこととのギャップがある気がしました。

今回、焦点を当てたい所は「チーム」ではなく「去った人」で、キツイ表現をすると「挫折した人」がどの様に挫折後を生き抜いているかです。
よって、決して前向きな話ではなく、ドロドロした部分も正直に伝えられたらと思っています。
それらを伝える道具の1つとして、現職チームの仕事の進め方を選びました。

私が挫折をした時、成功体験の情報は手に入れやすかったのですが、挫折した人のその後の情報は入手しづらく、今でもそうですが、不安の中を手探りで生きています。
その様な過程から、私という1例を紹介しようと思っています。

> 製造メーカーでのチームとの向き合い方」とあるが、”製造メーカー”特有の問題なのか、
> そうだとしても”製造メーカー”というところをもう少しブレークダウンした方が良いと思います。

同じ製造業でも、事業分野、社歴、従業員数などで少しずつ特徴が変わるので、その点も少し触れられたらと思いますが、概ね今回挙げる組織は、以下の特徴がある組織です。

・安定思考の人が多く変化を恐れる
・過去のトラブルや契約などでしがらみが多い
・規模が大きすぎて、お金の流れに実感が湧かない

ベンチャー企業も経験したことがあり、ベンチャー企業でもこれらの特徴は全くないとは言えないですが、経験してきた製造メーカーの方が傾向が強いと感じました。

2021年6月 CTOが退職しました。
想像できる理由はありますが、詳しいことは分かりません。

そして2021年8月 どこの馬の骨かもわからないVPoEが入社しました。
入社した彼は突然言い出します。
『これからはミルクレープ戦法だ』
何を言っているのか、意味がわかりません。
しかも彼は自分の役割を半強制的に変えてしまいます。
『井汲さんとTさんはこれから共同PM(PdM)/POね』
簡単な説明はしてもらいましたが、意味不明な「ミルクレープ戦法」に未経験のロールまで加わって本当に何をしていいかわからない状態でした。

それから自分達なり必死に解釈をして、自分達の力でチームを見直し進む事になります。

今回お話しするのは、
その中で自分や自分達が頑張ったこと。
それによって起こったこと・変化したこと・成功したこと・失敗したこと・手が届かなかった事・嬉しかったこと・悔しかったことなど、苦労も生々しさもひっくるめて発表できたら嬉しいと考えています。

この発表の目的や理由

小さな事業会社で開発をしていると、事業が成功しない限り自己評価も事業に紐づいてしまいます。
小さな成功すら本当に正しいか不安になり、成功を実感することが少なくなるからです。

一方で物事には途中経過があるとも考えています。
事業の状況にかかわらず、今まで自分達が積重ねた失敗が良い失敗なのか？悪い失敗なのか？
自分達から見える素直なふりかえりを皆さんと共有することで、自分達が少しでも自分達を客観的に評価できるようになれたら嬉しいと思います。

また、今回の発表は一部の成功もありつつ、本質的に大きな失敗がたくさん含まれています。
似たような環境で頑張っている人にとっても貴重な情報になれば嬉しいですし、それが難しくても情報交換のきっかけになればと考えています。

(単純にVPoEがやれって言った説もあります)

登壇者について

• 井汲俊介 (PM兼プログラマー) :  本発表のメインスピーカー
• 笹尾納勇仁(VPoE) : 本発表のサポート役
  (アイコン同じ人の分身かもしれません)

内容は実際に現場を回す自分目線での発表となり、VPoEは発表準備等のサポートのみとなる予定です。
(VPoEは検閲しないらしいし発表は自分だけなので不満も出せるかもしれません。)
ただし、視聴者からの質問にはどちらの立場からでも回答可能となる予定です。
(VPoEには言い訳の余地を残そうと思います。)

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

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

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

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

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

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

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

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

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

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

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

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

For ScrumFest Mikawa 2022

本講演は2022年5月21日（土）に「スクラムフェス新潟」で初演されたものです。

「品質文化」というQA界隈で話題になっているトピックについて考察したものです。とても抽象的でシンドイ思考が必要であり、皆さんとも議論したいと思い、再演である（新作でない！）との謗りを承知でプロポーザルを提出します。

日本のGDPの20パーセントを占める製造業。その起こりは19世紀イギリスの産業革命ではないでしょうか。「第1次」という枕詞をつける人も、Industry 4.0（第4次産業革命）の文脈ではよく見かけます。その時代から働き方（というか、働かせ方）は大きく変わり、当時の人々の悪戦苦闘はフレデリック・テイラーが『科学的管理法』でまとめたものにいったん落ち着きました。

時は流れ、今ぼくたちが「品質」の話をするときに前提としている感覚・知見は、テイラーがまとめたものを礎石としています。もちろん有用であることは確かですが、その一方で、見直す必要がある部分もありそうだとぼくは考えます。その「見直す」という作業をどこからやるか？　ぼくの提案は「品質文化」を改めて考えてみるのはどうか、です。

ぼくが「品質文化」について一生懸命考えていることが皆さんの目からどう見えているか、またより発展させていくためにはどうしたらいいか、一緒に考えてくださるとうれしいです。

以下、初演時の概要説明を記載します。

▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽

『品質文化試論』というQiitaの記事を2021年12月に公開しました。JaSST東海'21に合わせて公開したわけですが、ありがたいことに、様々なコメントを界隈で貰うことができました。

コメントを眺めていると、一人ひとりの問題意識とか立ち位置（ポジション）によって『品質文化試論』の受け取られ方は異なっているのではないかと思うようになってきました。そこで今回は、改めてMark（ぼく）が何を考えてあの文章を書くに至ったのかをプレゼンしようと思います。

『品質文化試論』で語ったことは、端的に表現すれば「品質文化は組織戦略に逆らったものにはならない」でした。その結論に至るまで、大きく2つの議論をしています。

ひとつめは、縦の階層構造です。「品質文化は組織文化に従う（逆は難しい）」のではないかと提示しています。

もうひとつは、横並びの構造と捉えて「戦略と文化は組織の両輪」と考えました。

「品質文化」というものを真正面から考えるのはシンドイのでこういう手法を取ったわけですが、結果的には「品質戦略」という言葉を引き出すに至りました。魅惑的な言葉が増えてしまって、正直なところ頭を抱えています。ただ、こうした構造を表現したことで、特に「1人目のQAエンジニア」へのメッセージを発することになったかなと思っています。

さてさて、こういうちょっと変わった角度から「品質文化」を考えるに至った源泉はなんでしょうか。これも大きく2つあると思っています。

まずはMBA（経営学修士）で学んだ知識があります。特にヒト系科目と呼ばれる「人材マネジメント」や戦略系科目「経営戦略」あたりで学んだことがベースになっています。エンジニアでMBAに通う人はまだまだごく少なく、特にQAエンジニアでいえば、国内では会ったことがありません。その意味では、少々レアな経験を積んでいると思います。

もうひとつ、5年前から海外カンファレンスや洋書を通じた学びを続けており、現在は『LEADING QUALITY』という本を翻訳しています。この本はCレベルのエグゼクティブ（たとえばCEO）が品質を重要な経営課題と認識して取り組むことの価値と、いかに推進するか、その事例が書かれています。どちらかというと技術書っぽくない、経営陣向けの「ビジネス書」に近い感覚の独特な本ですが、品質エンジニア目線で経営陣をどう説得するかを学びたい方にもおすすめできる著作です（翻訳されたら買ってください、ぜひ）。

ところで、品質関係の書籍というとどんなものを想像するでしょうか。「品質とは何か」「品質をいかに測るか」を説明した書籍や規格類が、やはり多いかなとぼくは思います。その一方で「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説した信頼できる情報源は、ほぼ皆無だとも。「品質文化」という言葉はいかようにも解釈できる危険な言葉で、避ける人もいますが、それが危険なまま放置され続けてきたこともまた、注目に値するのではないでしょうか。人類の進化に火が多大な貢献をもたらしたことを考え合わせてもいいかもしれません（プロジェクトを炎上させたくないぼくたちに火の話題はタブーかもしれませんけど）。

国内では比較的レアな品質 x MBAというコラボレーション、そして『LEADING QUALITY』をはじめ、海外から学んだ知見があって『品質文化試論』につながっているのです。

そして『品質文化試論』は「試論」にすぎません。ぼくはこれを『品質文化論』に進化させたいと考えています。たぶん、数年かけて。

今回の登壇はその長い道のりの第2歩になるかもしれません。

参加者の皆さんとの対話の中で（決して保証はできませんが）広く共有できる「なにか」があればいいなと思っています。楽しいセッションにいたしましょう。長い旅路の第2歩目を、ぜひご一緒しませんか。

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

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

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

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

こんにちは、世界。

私たちは、「テストの街「葛飾」」というコミュニティを運営しています。

テストの街「葛飾」は、毎週火曜日に、”葛飾の公園に人々が自由に集まり自由に話す”をコンセプトのイベントを開催しております。気がつけば、参加人数は小規模ながら、多様な方々に集まっていただき、とうとう開催回数が100を超えました。

さて、この雑なイベントには、実はひとつの原体験が大きく影響しています。

それが、松澤晴夫氏が経営していた、今はなき「More&More」です。

今回は、松澤晴夫氏の「More&More」から、どのようなエッセンスを取り入れたかを紹介したいと思います。

界隈でも群を抜いてゆるい「テストの街「葛飾」」がどのような思想で運営されているのか、
たぶん、他のコミュニティではまったく参考にならないと思いますが、もし気になる方は是非。

近年のパンデミックを経て、リモートワークの浸透が急速に進み、地方に住む人達にも多様なキャリアを選択できる可能性が少しずつ出てきました。

一方で、関東圏に比べるとまだまだ乗り越えられない壁もあるように感じており、地方でITやソフトウェア開発に関わる全ての人達がキャリア発展をさせていくようには今後どのような事をしていくべきか考えていき、発表したいと思います。

■経歴

• 愛知生まれ、愛知育ち、南山大卒。
  • 祖父の代からトヨタ系の家系です。
• 新卒：武蔵精密工業株式会社
  • IT部門所属で、社内の業務効率化ツール開発
• 2~3社目：株式会社Misoca
  • 中途採用担当として、エンジニア・デザイナー採用
  • 技術イベントの運営や広報など
  • 合併して、弥生株式会社に転籍
    • 中途採用担当として、全職種の採用担当
• 4社目：株式会社マネーフォワード
  • toB向けクラウドシリーズのエンジニア採用担当
  • 名古屋開発拠点のエンジニア採用担当

住んでいる地域などの制約に囚われず、ITに関わりたい全ての人がキャリアを築けるようになることを目指して、日々働いています。