本セッションでは、組織間のコラボレーションがDevOps実践において不可欠であること具体的な事例交えながら紹介します。

弊社でも、組織間のコラボレーションによるDevOps実践を開始しました。
まずは定例会議で課題感の距離を詰め、ベイビーステップな施策を複数講じました。
自動テストの推進やスクラムを始めDevOpsのプラクティスを次々に導入していった結果、2つの部署の出会いから約10ヶ月で開発プロセス改善やチームビルディングなど良い成果がみられるようになっています。

このセッションでは、得られた知見や思いを実例を交えながら紹介し、参加者の方々が組織間のコラボレーションを促進し、DevOps実践を進めるためのヒントを得ることを目的としています。

組織内でのコミュニケーションやコラボレーションに課題を抱えている方、またDevOps実践を進めたい方は、是非本セッションにご参加ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新人研修やインターン研修でやっているリモートでのスクラム研修のお話をします。

コロナ以前、弊社では新人さん向けにLEGO®を使ったスクラム研修を実施していました。

2020年、コロナの影響でフルリモート勤務となったことに伴い研修内容もリモート版にアップデートし、現在では新人さんのみならず「スクラムって何？」「聞いたことはあるけどどういうもの？」といったインターン生にも実施する定番コンテンツとなっています。

これまでの過程において、主催者側の自分たちも手探りである中で、我々や参加者側がスクラム研修を通して何を学んだか。どのような改善を次につなげることができたかをお話しします。

研修参加者のアンケートやフィードバックも踏まえながら、今後より良い体験や価値を届けるには何を改善していくかもお話しします。

——

★こちらのセッションは事前収録を行い、当日は動画を放映する形となります。
★ご質問などはセッション中でもDiscordに記載いただければ、その場ですぐに回答させていただきます。

"割り切る"。

どこか投げやりで無責任な印象を持つ方もいらっしゃるかもしれませんが、私は公私においてしばしば出くわす課題や試練を「割り切ること」で乗り切ってきたように思えます。

このセッションではそんな私の以下のような「割り切り話」を展開し、正しく割り切りながら課題と向き合う方法についてお伝えしたいと考えています。

■ソフトウェアテストの割り切り

• はじめての割り切り
• 自動テストだって割り切るところからですねという話

■プロセス改善の割り切り

• 割り切らなきゃ何も始められないぞという話

■私の周りの割り切り話

• 息子の場合、妻の場合、私の場合 etc.

■正しい割り切りについて2,3の考察

• その割り切り、あなたは納得してますか？
• 根拠と主体性が大切

「リリースの度にテストケースが増えていくよ…」
「自動テストを導入したいけどどこから手をつけていけばいいの…」
「やることたくさんあってもう忙しいよ…」

といったお悩み解消の一助となれば幸いです。

ふりかえり実践会による名著「ふりかえり読本」全３冊の中から実際にやってみたふりかえりをご紹介します。

単独で採用したフレームワークから組み合わせて実践したものなど、「楽しくできる」「軽量にできる」ふりかえりのご参考になれば幸いです。

弊社にはソフトウェア開発プロセスの改善を目的としたチーム「SPI（Software Process improvement）チーム」が存在します。
一般的にプロセス改善といった取り組みは「開発関係者の誰か」が各々の業務の合間に行うものかと思いますが、弊社では1つのチームとして切り出されています。

私は7月からこのチームのリーダーを任されており、チームメンバーが「全員上司」といういささかイレギュラーな構成で各プロダクトのプロセス改善に取り組んでいます。

本セッションでは、このチームのミッションや様々な施策、現段階での課題感やそれを解決するために始めた取り組みを紹介します。

プロセス改善活動において、テストの自動化や継続的デリバリーの確立などの技術的なアプローチは代表的な打ち手の一つです。

かたやアジャイル的アプローチでプロセス改善活動を推し進める際、スクラムなどに代表される「組織の構成やそれに付随する約束事的アプローチ」に注目されがちとの思いもあります。

今回私がプロセス改善を目的とする「SPI（Software Process Improvemnet）グループ」と、テストの自動化を推進する「Automationチーム」を兼任した1年半のプロセス改善活動で経験したことを実例を交えて紹介し、組織全体の流れに手を入れながらピンポイントで自動化エンジニアリングが出来ることの有用性や課題、展望について展開することにより、プロセス改善エンジニアの動き方の一つとして皆さまに一考していただくことを目的としたセッションです。

皆さん「文化的負債」という言葉をご存知でしょうか？

当社の主力ソフトウェア・プロダクトは誕生してから20年・25年といった歴史を経て今もなおバージョンアップ繰り返し、進化し続けています。この長い歴史あるプロダクトを開発してきた組織も、市場の要求と時代の変化に対応しながら成長を重ねて来ました。

ところで「技術的負債」とは我々エンジニアにとって常に付きまとう身近なリスクです。これを放っておくとプロダクトの品質や競争力が破綻することは良く知られた事実です。当社のプロダクトも歴史が長い分、この「技術的負債」との戦いの歴史と言っても過言では有りません。しかし、今回これと同等以上に着目したいのは、組織の健全性の指針とも言える「文化的負債」の方です。

書籍「Effective DevOps ―4本柱による持続可能な組織文化の育て方」では次のように表現されています。

【技術的負債とは、システム設計、ソフトウェアアーキテクチャー、ソフトウェア開発、技術の選択などの技術的な決定が最終的に生み出すもののことだ。一方で、文化的負債は、採用や解雇の決定、コミュニティの基準の制定や施行、組織の階層構造、価値観といった文化的な決定が最終的に生み出しているもののことである。 文化的負債にも技術的負債と同じことが当てはまる。つまり、いつか返済しなければいけないし、負債の原因となっている問題を長期に渡って手付かずにしていればいるほど、利息が蓄積して、将来負債から抜け出すことが難しくなる。(p314)】

私たちが今の組織でこの「文化的負債」に着目し、「アジャイルに行こう！」と叫んでからの8年間で実際に経験した、組織文化の変革のコツやメソッド、苦労したことや人相手の難しさ、それらの対処方法などについて発表したい。