17年間動かざること山の如しのちんも氏と、止まれないことまぐろの如し、転職を繰り返してきた藤村新氏、真逆の生き方をしながらも、それぞれがアジャイルを追い求めてきました。

「17年と13社、それぞれのアジャイル」

俺たちはどう生きたらいいの？感を若干交えつつ、

もがき挑み足掻く者二人の生き方・価値観の核心に迫ります。

モデレーターかいはらがライトな感じでお届けします。

鹿児島の中学生に紙飛行機ワークショップを、

鹿児島の高校生にマシュマロチャレンジを、

それぞれスクラムを知ってもらうワークを実施予定です（5月と6月に）

ワークを通して感じたこと、ホットな情報をお話しできればと思います！

受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました！が、JTCの荒波に揉まれる我々！

• 期待している形で案件が来ない！
• 支援って、ちゃんと評価されるのか？給料下がっちゃうんじゃないの？
• ３年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく！

毎年お送りしている田舎スクラムチームの状況をお伝えします！

G.O.O.D.テストとは何か？そして、なぜそれが誰にとっても大切なのか？

テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか？コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか？もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか？

もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

• G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。（Give）
• O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。（Observe）
• O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く（Open）
• D：エンドユーザーに対する安全性（例えば、プライバシー、セキュリティ、機密性）など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。（Determine）

特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか？

システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

G.O.O.D.のテストをしていますか？それともただのテストですか？

プロダクト開発ではやりたいことは常にやれることより多いとはよく言ったもので、そのような状態下でも「今やること」は常に判断し続ける必要があります。そういった状況下で、私たちのチームはスクラムで進めていますがなぜスクラムでやり続けているのかリアルな状況をお話しします。さらに、今現在向き合っている課題とその課題をどのように乗り越えようとしているのかについてもお話しする予定です。

受託会社で複数チーム（案件）のアカウントマネージャーを務めています。

自分がエンジニアとして関わっている案件はともかく、現場には入っていない案件でもお客様がスクラムチームを組んでされるケースが増えてきました。

スクラムやアジャイルの経験の薄い社員が多く、社内でも積極的に指向する状態でない中、半期に一度の顧客満足度調査では社内でも人前で発言するのがけして得意ではないエンジニアがいるチームに対して「スクラムに積極に関わってくれないメンバーがいる（改善してほしい）」等のお客様からの声を繰り返しいただくことがあります。

また、逆に自社チーム側の進め方としてスクラムを取り入れたいと方法論を相談してくるメンバーもいます。

自身が関わっていない案件から聞こえてくるスクラムやアジャイルに関する疑問や悩み、取り組みなどをお伝えし、皆様からもぜひご意見等をいただきたいです。

私が所属しているスクラム開発チームは、メンバーが3拠点にまたがって所属している、物理的に距離があるチームです。

前職で15年程働き、その間プロジェクトマネージャーやスクラムマスターとして多くのプロジェクトに従事してきた。

その中で、アジャイルやスクラムについて新人研修をはじめ色々な所で説明するような機会もあたえてもらえました。

その経験を生かしSIerから自分たちのプロダクトを作ることに携わってみたいと今までの製造業から金融業へ転職。

しかし、転職した先では内製化も進めたいとのことだったが開発の主導権をベンダーが担当しており自部署のメンバーは開発経験ほぼなし。

また、部署内ではほかの仕事としてイントラ業務/保守・運用業務も担っており開発に十分に集中できるような状況ではなかった。

もちろんアジャイル開発の経験なんてほとんどない状態。

さらに、コロナ真っ只中に転職したことでコミュニケーションも取りにくい。

そんな中、3年経ち少しずつ内製化もできるようになりプロジェクトマネージャーとしてもサービスをいくつかリリースしてある程度価値がだせるようになってきた今、いままでアジャイルを通じて学び・実践してきたエッセンスをどのように新しい環境に適用してきたのかをお伝えします。

いままではうまくいっていたはずなのに、新しい環境やプロジェクトでうまくいっていない人に少しでも良いきっかけになるような何かを伝えられればと思います。

背景

スクラムマスターという肩書を持って働いていた私。
4~5年経って気がついたのはスクラムマスターとはなにか？
価値を言語化できないまま、なんとなく過ごしていた事実だった。
組織にたいしてどう振る舞うべきなのか？答えられる自信はなかった。

なんとなく時間を過ごしてしまう環境に疑問を持った私は迷った。
全社的にスクラムが導入され、アジャイルなマインドがあるメンバーがいる環境。
ちゃんと専任となるスクラムマスターが認められた環境がある環境。
そんな環境で自分の中のスクラムマスターの価値を、自分の言葉で言えるようになりたい。
打席に立ちたいと思って転職を決意した。

しかし、入社して頑張り始めた時、チームから返ってきたのは入社前には想像もしていなかった反応だった。

メンバーから、
「スクラムマスターって必要ないよね？」 と聞かれているような質問だったり、
「スクラムマスターがいない現場になんて行きたくない！って言う人なんているの？どうなればそう思えるようになるの？」
といった、スクラムマスターの存在意義を問う、気軽で率直な疑問がほどんどだった。

本当に困った。私はこの環境で望まれていないかもしれない。
そう思って苦しみながら足掻いて足掻いていたら、天が強い仲間を送ってくれた。

それから毎日のように、一緒に泣いたり笑ったりしながら作り出した変化を発表してみようと思います。

この発表の目的や理由

実際にチームや組織を良くしたいと思って奮闘した時の、つらみや苦しみ
その中で気をつけたこと、上手く行った時の感動などを共有することで、
これからチャレンジしたり、今ちょうど同じようなチャレンジをする人の参考になったり、勇気が持てる様なことが伝えれたらいいな。
なんでもいいから、役に立てばいいなと思って発表しようと思いました。

また私たちのチームの活動を通して、他のチームの方から、より良い活動など教えて頂いたり議論出来るようになれたら嬉しいと思っています。

登壇者について

• 兼平裕美　しがないまよいぶた
• 笹尾納勇仁 : 本発表のサポート役

サポート役は本当にサポートのみとなる予定です。
視聴者からご要望があれば質問にはどちらの立場からでも回答可能となる予定です。

皆さん日々どんなメトリクスとってますか？メトリクスをとった後何してますか？

メトリクスを使ってチームや自分の行動を変える時、とりあえず計測するだけして、放置されていることってありませんか？
なんならメトリクスを取ること自体が目的化しちゃって本来の目的が横に置かれていることありませんか？
私はあります！

コーチングなんていう、人にあれやこれや気づいてもらう事をしていても、油断をすると手段が目的化してしまうことがあります。
今回はそんな経験から、どうやってそこに気づいていくか？そしてどうやってメトリクスと付き合っていけばいいかについてお話しようと思います。

スクラムの「開発者たち」のなかには、デザイナーも含まれていると理解しています。デザイナーがスクラムチームに入ることになぜ意義があると感じているか、そのうえでどんな悩みがあるか、これまでの数々の悩みと実験の変遷をお話したいと思います。

わたしは技術職からキャリアをスタートし、フロントエンジニアからUIデザイナー、新規事業開発チーム、当時所属していた会社内のアジャイル推進者を経て、現在はプロダクトデザイナーという職能でスクラムチームの一員として働いています。

職能は違えど「デザイン」という活動をしてきたと思っています。

アジャイルの世界を知り、RSGTやスクフェスでセッションをきくたび「これはプロダクトづくりの話をしている、デザイナーにも関係がある」という想いが強くなりました。

一方、スクラムとデザインの相性は悪いのではないかと耳にしたり「なんでスクラムチームにデザイナーが？」と言われることも。

チーム外からのアジャイル支援の経験を経て転職し、プロダクトデザイナーとして新しいチームに入ったことで、何故そういう意見がでるのか、新たな経験や考えが増え、悩みも変わり続けています。

スクラムチームの中の人として「デザイン」にこだわり続け、悩み続けるいちデザイナーの話が、デザインや職能理解のきっかけになると嬉しいです。

自律的なチームになってほしい！という思いはマネージャーなら常に持っている共通の思いかと思います。が、難易度が高いとか納期が近いとかの仕事のプレッシャーからついつい自分がプレイングとして入ってみたり、過度にチームに指示をしたりで自律的なチームにならない原因を自分からつくっていることもあるのではないでしょうか。

unFIXとはそんな課題にフィットするかもしれない組織やチームのデザインのツールです。自律的な組織に見られるパタンをいくつか抽出したもので、「ベース」と呼ばれる母体に「クルー」と呼ばれる役割を持つチームが垂直水平（あるいはナナメ）に配置していくもので、なおかつ共通のテーブルでディスカッションできるくらいの分かりやすさやとっつきやすさも備えています。

今、私のチームではunFIXをつかって2チームいるセクションの体制を見直し、unFIXが定義するところの各クルーの役割に基づいて動いていく形で活動し始めています。

いわゆるマネージャーの役割は「ガバナンスクルー」であり、チームの役割は「バリューストリームクルー」と呼ばれています。このあたりは提唱者がヨーガン・アペロ氏ということもあり、少数のマネージャーがいわゆるガバナンス的なマネジメントを担い、他についてはチームがセルフマネジメントしていくという思想も入っているように感じられるところがあり、いい意味で「マネージャーとチームの間に線を引く」ことがしやすくなる性質があると感じています。

私のチームではこのあたりをどうやったか、私のチームがどうなったかをお話しできればと思います。

1年前に転職という形でスクラムチームから今のチームへ異動しました。

新たなチームは、プロダクトへの情熱を持っているメンバーは多い一方でエンジニアが個人商店状態になっていました。そのため、Joinしてしばらくは雑談会でコミュニケーション量を増やすなど、チームになることを目指して草の根活動をしていました。

そこから月日が経って iOS エンジニアチームのリーダーになり、自分が直接手を動かすことよりチームとしての成果を意識するようになりました。コーディングルールの再検討や今ある技術的負債について議論し、個人が感じていたことチームとして認識できるような取り組みをやってきました。取り組みの中には、チームの理解を得られず挫折する・取り組みを継続させることができず霧散するなど失敗もたくさんありました。

そうした取り組みをしているうちに、今度はモバイルエンジニアチーム(iOS / Android)として技術的負債への戦略的な取り組みをリードすることになりました。技術的負債と向き合う中でも「どうしたらみんなが楽しく開発できるだろう？」「持続的に改善を重ねられるチームにしたい」などエンジニアチームのために考える時間はどんどん増えています。

そんな自分の取り組みをふりかえってみると、ただのエンジニアからリーダーへ、リーダーからエンジニアチームをリードする立場になり、少しずつ良いチームを考えるときの視点が変わってきていることに気づきました。それだけではなく、自分の行動もリーダーになった当初は自分がやるんだと抱え込みがちだったのが、Whyは自分が考えてそれ以外はみんなで考えようなど周囲をうまく巻き込むことがいつの間にかできるようになっていました。

このセッションでは、新米リーダーが取り組みに失敗したときの思考やそこから変化するために挑戦してきたことをお話しします。

本セッションでは、パッケージ製品開発に数十年携わってきたQAの視点から、パッケージ製品開発の品質を高めるために自身が取り組んできたことをお話する予定です。

最初に、パッケージ製品と一口にいっても多種多様な製品があるため、自己紹介を兼ねて自身がどのようなパッケージ製品に携わってきたのかを説明します。

その後、パッケージ製品の特徴をSaaSと比較しながら簡単に説明していきます。
パッケージ製品で品質保証をしていく難しさとしてレガシー化しやすい環境やパッケージ製品固有のテスト戦略の問題についてお話し、自身が考えるパッケージ製品における品質評価を最後にお話します。

最後に、 パッケージ製品開発の品質を高めるために自身が取り組んできたことを説明することで、パッケージ製品開発の品質保証が上達するために明日から具体的にできることをお伝えします。

※) プロポーザルを作るにあたり、 aki.m さんにお手伝いただいております。