はじめに
介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。2020年1月に入社し、チーム活動やQA組織づくりを通じて品質保証の体制強化や施策推進をしています。
2024年も残すところあと半月ほど・・ということで、今回の記事では今年一年であった変化、その中で取り組んでみた活動の内の一つを振り返ってみたいと思います！ 組織、私個人としても沢山のチャレンジをさせてもらった一年ですが、印象深い活動をピックアップして書いてみています。
どんな変化があった？
カイポケのリニューアルプロジェクトでは今年からLeSS（Large Scale Scrum：大規模スクラム）の導入にチャレンジしています。
このプロジェクトでは以前よりスクラムをベースとした開発プロセスを導入しており、各チームに所属しているメンバーが日々試行錯誤をしながら開発や品質保証を進めてきました。
その中でスクラムマスターの参画もあり、LeSSのフレームワークへと最適化していく過程で、よりチームとして目線を合わせやすい状態、サポートが受けやすい状態となりました。
同時に、そういった変化の中でQAエンジニアが持つ専門性をどう活用し、成長しながら貢献していけるのかということを改めて考える機会が訪れているとも感じました。
この変化や機会の中で実際の動きを通じ、QAエンジニアとしてどう貢献していくべきかを改めて考えてみたい・・・！
私自身はQA組織内の横断的な活動も担当させてもらっているため、入社時と比べるとチーム活動からは少し離れがちにはなっていたのですが、そういった思いのもとで今年はチーム活動にも積極的に参加させていただく一年となりました。
前提
カイポケ開発の各アプリにおけるチームはプロダクトオーナー、開発者、デザイナー、QAと異なる専門性を持った多数のメンバーにて構成されているケースが多くあります。 現在私が主に関わっているチームでも同様で、それぞれが得意な領域の技術を持って開発を進めるスタイルになっています。
関わらせてもらうタイミングでちょうどチームの再編があり、ワーキングアグリーメント（チームの約束事）の作成等、チームビルディングにも参加することができました。
一部抜粋にはなりますが、現状のワーキングアグリーメントには以下のような記載をしています。
スプリントゴール達成に向けて、ロールを越えて得意な武器（領域）で援護してほしい
こちらも一部ですが、QAと呼ばれる活動に専門性を持ったメンバーが期待されていることとして以下記載がされています。
検証するシナリオやパターン知見から、要求に関する不確実性を評価してもらう事に期待している
作るものの「不確実性」（要求の変化や開発における変数等）は一定発生します。
私が所属するチームでは技術と要求の不確実性の切り口でPBI（プロダクトバックログアイテム）の評価、見積もりをしています。 QAと呼ばれるメンバーはこの中で、検証シナリオやパターンの知見を用いた要求の不確実性の具体化、それに対するフィードバックをしていくことを期待されています。
そこに対して貢献ができるポイントはないか考えながら活動していきました。
どんな感じでやっているか
上記にて書かれている「要求に関する不確実性の評価」、そこからスプリントを通じて「要求の不確実性を減らしていくためのアプローチ」として、一例として以下のような活動を通じてトライアルをおこなっています。
- ディスカバリーフェーズから他チーム影響も考慮したテストパターンを考えていく
- PRD作成までの各ステップに参加、早期からテストプランニングやパターン検討を開始
- プロダクトオーナーや開発者とのテストすり合わせ（インクリメントの共通認識化）をスプリント開始後の早い時期に実施する
- リファインメントにて受け入れ基準をチームで確認・最適化し、ストーリーポイントを用いて不確実性に対する会話をする
こういった活動の中で適宜フィードバック、デイリースクラムでの透明性確保を通じ、不確実性を下げていくことをスクラムチームにおけるQAの活動の一部として取り組んでいます。
やってみてどう？
活動の元になっているもの自体はスクラムの基本的な考え方に基づいているため、特に目新しいものではないのかもしれません。 また、これがベストプラクティスではないと思っていますし、アウトプットの精度やフィードバックの数を増やす等、より良くなっていけるように考えていく楽しみがあると感じています。
テストプロセスの更なる最適化、自動テストを駆使したリードタイムの短縮、ワーキングアグリーメントの「ロールを越えて」という部分でできることもまだ多くあり、より一層チームとして、個人として成長していける可能性を感じています。
個人的なこれよかったポイント
長々と経緯や現状を語ってしまいましたが、エス・エム・エスのQA組織では大切にしたいものの一つに「チームで品質保証」という行動指針を掲げています。 その実現に近づいている実感を持てたことが、私個人としてとてもよかったと思っています。
QA組織の行動指針とは？
以前テックブログにQA組織の行動指針を言語化した記事を投稿しました。
この中の一つに「チームで品質保証」というものがあり、「職種の壁を越えて協力することで複雑な問題を解消できる組織を目指したい」という思いのもと、この項目を設計していました。
私の中でこの指針とリンクした活動に携われたという実感があり、今回のテーマで書いてみようと思ったモチベーションにもなっています！
※ちなみにこの記事内の行動指針は昨年初稿として書いたもので、絶賛ブラッシュアップ中です。詳細は追って発信したいと考えています。 （方向性の見直しではなく、組織スケールの中でもより伝わりやすいものにしていきたいと思っています）
1点補足として、本記事の活動や考え方のみが「チームで品質保証」を体現するものではないと考えています。
チームの特色によって構築していきたい開発スタイルは異なると思っており、その自由度が高いのもエス・エム・エス開発組織の良いところだと捉えています。
まとめ
ということで、組織作りにおいて今回のような活動にトライしていきたいという思いが前提としてあり、実際の動きとしてコミットしていくことも微力ながら出来たため、非常に充実した一年になったと感じています。
もちろん全て私が提案・推進・実践したわけでないですし、関係する沢山のメンバーの多大なるサポートがあってこそなので、この場を借りてお礼申し上げます！ いつもありがとうございます！
私自身、スクラム開発やアジャイルテスティングの経験が豊富なわけではなく、ましてLeSSとなってくると日々勉強だなぁと思う毎日です。 今年は会社の支援を受けて外部研修にも参加させてもらい、とても良い刺激になりました。
今回の取り組みに関してもチームプロセスとしてより明確化したり、洗練していくことは必要不可欠だと思っています。 スケールしていくプロダクトに対して取り組みをどのように適用し、どう貢献していくか考え続けたいという思いもあり、ここも継続してチャレンジしていきます。
また、冒頭でも少し触れましたが今回の取り組みはあくまでも一例で、QA組織では他にも多くのTryを進めています。
今回のようにチームで一緒に走っていく活動だけでなく、横断的な関わり方を模索し、品質の維持・向上とともに不確実性を下げていく活動がプロダクトや組織のスケールによって必要になると思っています。 そういった点も組織一丸となって引き続きチャレンジしていきたいと考えています。
来年もがんばるぞ！
様々な活動にチャレンジできるエス・エム・エスのQA組織に少しでも興味を持ってくださった方は是非カジュアル面談よろしくお願いいたします！
