私達のチームは今年の4月から新しいマイクロサービスのプロジェクトを始めるため集まりました

• マイクロサービスから独立したプロダクトの開発を行っていたチームのProduct Owner / Designer / Engineer / Offshore Team
  • スクラムではない方法で開発しており、アジャイルは初めて
  • Rettyのマイクロサービスの開発経験はないが技術セットは近い
• マイクロサービス開発の経験があり、スクラムの経験もあるEngineerのスクラムマスター
  • 独立したプロダクトの開発経験は少しあるが、ブランクはあり運用まではしていなかった
• マイクロサービス開発の経験がほとんどないが、スクラムの経験はあるEngineerの私
  • マイクロサービスの技術要素は自習で少し見ていたが業務経験はない
  • 独立したプロダクトの開発に関わったことはない

チームは半年間で既存のマイクロサービスを活用した新規開発を行い、顧客に新機能を提供することを期待されています。
合わせて独立したプロダクトの保守・運用も継続することを期待されており、各メンバーがそれぞれ一部欠けたドメイン知識が持っていて合わせると全体的な領域をカバーできるという状態でした。

このような状態でいかにスクラムに取り組み、アジャイルな思考にシフトしてもらいながら、既存のプロダクトの保守・運用もしつつ、新規プロダクトの開発を行っていったかについてお話できればと思います。

システムの複雑度が増すだけでなく、ビジネスに求められるスピード感もさらに加速している今日このごろ、皆様いかがお過ごしでしょうか？

Rettyでも2〜3年前はテストに関する文化はほぼ無く、一部のメンバーが頑張ってE2EテストやUnitTestに取り組んでいましたが、組織だってテストを入れたり保守したりといったことができていない状態でした。

それから時は経ち、私が所属しているtoB向けのシステム開発チームではテスト文化が少しずつ根付き始めてきています。
ただこの2〜3年の間で順調にテスト文化が育ってきたかというとそんなことはなく、一度は根付き始めたテスト文化が枯れてしまい途絶えかけたこともありました。

本セッションでは具体的なTDDのハンズオンをやることとは別の、そうした活動を始めるためのお膳立てやその後の文化が一度枯れかけてまた復活させるための道のりに関するお話となります。

Rettyでは2年前から大規模スクラムのひとつの手法であるLeSSで開発をはじめました。
私達のチームは約1年半まえから社内の4番目のチームとしてLeSSチームに合流しました。

私達のチームではtoB向け商品開発をすることから開発期限が厳しいものが多かったり、少しでも開発を早くするために（当時としては）できるだけ対象機能について詳しいメンバーにタスクをアサインし、可能な限り着手タスク数を増やすために一人一タスクで開発を進めるといったことを行っていました。

その結果、属人化が進んでしまったり、開発期限から改善系タスクが後回しになりがちになったり（運用やバグ対応はもちろんする）といろいろな課題が発生していました。

このセッションではそうした私達のチームがLeSSに加わってからの1年半の軌跡と、その中であった変化についてのポイントとそれがどういった背景で起きたのかについてをお話していきます。