QAチームの参画しているプロジェクトで、最近スクラムを導入しました。
ですが、あまりうまく進んでいる実感がない・・・。
どういうところが難しいのか、どこを改善すればうまくいくのかを模索していたところ
スクラム経験者で、社内の別プロジェクトでもスクラムを実践している亀田さんが声をかけてくださり、急遽、勉強会が開催されました！
興味ある方の任意参加という形での開催だったのですが、急だったにも関わらず12人程の参加！
みなさん真剣に聞き入っています。
・タスクの長さは一定にしておいたほうがよい
・スプリントはタイムボックスにしないと効果がない
・小さいフィードバックを得ることが大切
・プロセスよりどういう成果を出せるのかを重視する
などの、基本的なスクラムの回し方のお話や
アジャイル開発のトレーニングやコーチングを行っている日本でのアジャイル開発のスペシャリスト、吉羽 龍太郎さんのWebサイトよりプレゼン資料：スクラムチームは改善する問題を正しく選んでいますか？を参考にしながらの説明で、今のプロジェクトにどう取り入れていくかがクリアになってきたように思いました。
こちらの資料によると、キーワードは
問題設定力 × 開発力 × チーム力とのこと。
難しそうな感じも受けますが、この力がつくと組織としてレベルアップできそうです。
画面はプレゼン資料：スクラムチームは改善する問題を正しく選んでいますか？を見ながらZoomミーティング
亀田さんはいくつかの案件でスクラム開発を経験しているそうなのですが
その中には、ひとりスクラムをやってる案件もあるのだとか！
新しい技術やフレームワークを試行錯誤しながら積極的に取り入れたり
型にはまらずに自由にカスタマイズして自分のものにしたりというのを簡単にできるところが
mmjのよい文化なのかなと思っています。
誰かの声かけから勉強会をサクッと開催できちゃう、スピード感のある社風もmmjの特長ですね！
そんなmmjでは、一緒に学んでいきたいエンジニアさんを募集しています。
まずは話を聞いてみたいでもOK！お気軽にお問い合わせください。
エンジニア採用の詳細はこちら
フルリモートのQAエンジニア。前職は客先常駐で様々な開発を担当していたJavaエンジニア。子供との時間を多くしつつ業務の専門性も上げるため、フルリモートのQAエンジニアにジョブチェンジ。
