ハイキュー!!北信介に倣う、当たり前品質を当たり前にする『凡事徹底』な仕組みづくり
この記事は、Gaudiy Advent Calendar 2024の7日目の記事です。 Gaudiyの行動指針「Gaudiy UNIFORM」の1つである「超守」と「高速実験」をテーマに、経験やスキルの凸凹なチームにて、継続的に安定した品質（主に機能性）でアウトプットしていくために取り組んでいることを紹介します。
ベストプラクティスをドヤる内容ではなく、愚直に取り組んでいる内容の紹介になりますので、肩の力を抜いて読んでもらえると嬉しいです。
果たして、ラッキーセブンが、吉とでるか、凶とでるか。
自己紹介
こんにちは、Gaudiyで社員代表をしている西岡（@TakeshiNishioka）です。
社員代表とか言うてますが、普段は、主にストアや決済、有償コインで回すガチャなどお金が関わる機能の開発を担っているチームでPMをやっています。
僕らが開発している機能は、お金に関わる機能なので、第一に当たり前品質を担保することを最優先として、さらに事業計画のブロッカーにならないようデリバリーする必要があります。
チームとしては、堅守と速攻を両立しなくてはならないです。
まさに「喝采はいらん、ちゃんとやんねん（by ハイキュー!!北信介）」 です。
とは言いつつ、たまには「どや俺の仲間すごいやろって、もっと言いたかったわ（by ハイキュー!!北信介）」な気持ちにもなってる今日この頃ですw
ざっくり要約
本記事は、Gaudiy Tech Blogで書いたブログの「その後…」な内容になります。
ざっくり要約すると…
こんな課題があるよ！な話
堅守と速攻の両立「スピードと品質を両立せよ！」
戦略的に品質向上「戦略的にテストせよ！」
こんな取り組みをしてるよ！な話
Don’t Think, Feel !!「想像に委ねず、愚直にドメインとプロダクト理解を深めよ！」
解像度を上げる
個人テストの型化と定着！「経験やスキルに依存せず、個人のアウトプット品質を安定させよ！」
期待値を揃える
多様な視点を入れる
（次回）テスト戦略の型化と定着！「チームのアウトプットとアウトカム品質を担保せよ！」
（次回）不確実性とリスクの蓄積する
（次回）不確実性とリスクを適切解消する
今いまは、こんな恩恵があったよ！な話
開発担当者のアウトプット品質が安定した
プロダクトの改善サイクルが生まれた
こらから、ここをやっていくよ！な話
SDLCに、STLCのテスト戦略のプロセスを組み込み実践する
これまでの軌跡
2023年までは、暗号資産WalletやNFTマーケットプレイスなどWeb3系の基盤を開発していましたが、2024年からはGaudiyの事業戦略に沿って、ストアやガチャなどEC基盤に主軸を移して開発を進めています。
堅守と速攻の両立「スピードと品質を両立せよ！」
今のGaudiyは事業目標達成に向けて、全社一丸となって大きな壁に挑戦している状況で、まさに「Gaudiy UNIFORM」の1つ『たのピンチ』です。
次々とやってくる巨大な壁、深い谷、漆黒の闇、難解な謎などの攻略を、たのしんじゃうマインドのこと。
そんな『たのピンチ』な状況の中で、弊チームでは事故るとユーザーやクライアントからの信頼を失うだけでなく、時間とリソースを莫大に消費するピリピリ感のある機能を開発しています。
リスキーな機能と言えど、慎重になり過ぎて牛歩な開発では、事業のブロッカーに成りかねないですし、スピード重視で低品質な機能をデリバリーして、大きな事故でも起きでもしたら…
怖いですねぇ、恐ろしいですねぇー
スピードと品質を両立して、『たのピンチ』を乗りこなそうじゃないか！が、弊チームの目標であり、大きな課題になります。
2024年の序盤は2Weekから4Weekほど規模の機能開発が続いていたのでボチボチ順調にデリバリーできていたが、中盤から複雑性も高く規模が大きい機能を開発するようになります。
戦略的な品質向上「戦略的にテストせよ！」
そんな機能開発のリリースを目前に控えたある日のこと…
対象機能をポチポチとイジっていると「あれ、これ正常に動いてる風だけど動いてなくね？」のような事象を発見しました。
すぐに報告して確認してもらうと、正常系の１つのケースが正常動作していないことが分かりました。
結果、リリース日を延期する判断をしました。
リリース日を延期する、低品質な状態でデリバリーできないので当然の判断だと思うけど、「リリース日を延期する」とは「約束を守れなかった」と同義だと思っているので、個人としては屈辱以外の何ものでもなく、早い段階で気付けなかった自分が情けなかったです。
その後のポストモーテムで、問題が発生した状況を振り返ってみると
思い込みによるテストケース漏れ
ユニットテストのカバレッジ（C1：分岐網羅）漏れ
受け入れ基準のない開発チケットの大量発生
正常か異常か気付けない適当なテストデータ
開発担当者が実施する単体テストの期待値ズレ
など細々と事象が挙がりましたが、その場に同席してもらったアドバイザーの方から「テスト戦略をつくってテストしてますか？」の問いに「…」、まさに芯を食った指摘でした。
開発した機能の品質を担保する上で「どんなテスト観点を、どのタイミングで、どのようにテストするか？」を計画的に実施できているか？ということです。
そこから「テスト戦略」というパワーワードを念頭に置いた、ソフトウェアの当たり前品質との戦いが始まります。
“As Is”と”To Be”を知る「まずは戦う相手を『超守』せよ！」
またまた登場しますが、「Gaudiy UNIFORM」の1つに『超守』があります。
ものごとの検討を始める前に、守破離の守としておこなう、原理・原則や先行事例の超徹底的なリサーチのこと。
「テスト戦略」云々の前に、“As is”と”To be”を設定するための『超守』を行いました。
“As Is”を知るための『超守』
チームのプロダクト品質について状態を『超守』します。
弊チームでは、1日1日の成果物に対して、デイリーQAを実施しています。
デイリーの振り返りでも、QAに関する問題がちょいちょい挙がっていました。
【解決】QAの時間に、そもそも対象箇所が動かない
【解決】QAで発覚した不具合が修正されずにリリースに乗ってしまった
QA前の担当者による動作確認の精度が、個人の経験に依存する
QAの時間が、個人の動作確認を再確認する時間になっている
などなど、既に【解決】している問題もありますが、後者の2つは本ブログの内容で解決を試みています。
デイリーでの振り返りについては、こちらをご覧ください。
また前述のポストモーテムで挙がった細々とした問題も、チームの状態・状況を表していると言えます。
思い込みによるテストケース漏れ
「こうだろう」という思い込みから、テストケースが漏れてしまった
主に開発しているドメインが、ストアや決済、ガチャなど一般的にも馴染みのある機能であるが故に、「こうだろう」と想像に委ねてしまいやすいと考えていますユニットテストのカバレッジ（C1：分岐網羅）漏れ
テストコードの量が多くなり、必要なテースコードを書き忘れてしまった受け入れ基準のないチケットの大量発生
当時は、以下の2つのタイプのチケットがありました。
- ユーザーストーリー：受け入れ基準や完了の定義を記載する
- 開発タスク：対応内容のみ記載する
テンプレ切り替えの手間をなくすため、デフォルト設定を開発タスクにしたら、本来であれば受け入れ基準を記述すべきチケットが少なくなってしまった正常か異常か気付けない適当なテストデータ
同じ名前や画像で見た目で違いの分からないテストデータが多く、結果を見て正しい結果が表示されていると勘違いしてしまった開発担当者が実施する単体テストの期待値ズレ
受け入れ基準のないチケットが多くなり、開発担当者が単体テストでどこまで担保するべきかの判断が本人次第になってしまった
“To Be”を知るための『超守』
ソフトウェアテストに関して『超守』します。
ソフトウェアテストについて改めて学び直します。
教材として、主に以下の３つを『超守』しました。
ISTQBテスト技術者資格制度 Foundation Level シラバス
ISO/IEC/IEEE 29119（ソフトウェアテスト国際標準規格）
ISO/IEC 25000（システム・ソフトウェア品質標準規格）
https://www.ipa.go.jp/archive/files/000065866.pdf
https://cio.go.jp/sites/default/files/uploads/documents/data_hinshitu_guide_beta.pdf
その他、『超守』で登場したキーワードたち
システム・ソフトウェア製品の品質モデル（ISO/IEC 25010）
利用時の品質モデル（ISO/IEC 25010）
データの品質モデル（ISO/IEC 25012）
テストの7原則
シフトレフト
アジャイルテストの４象限
リスクベースドテスト
探索的テスト
などなど
“To Be”と“As Is”のギャップから見えたもの
To Be
ユーザーストーリーマップから、ユーザーストーリーのチケットは起票する
DDDなど開発の設計フェーズ前に、ドメインとプロダクトの解像度を揃える
イベントストーミングで、システムの振る舞いをモデル化する
受け入れ基準を追記する
不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
リファインメントで、ユーザーストーリーを確認して、サブタスクに分解する
受け入れ基準を追記する
不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
リファインメントで、チケットにストーリーポイントで見積もる
チケットを実装する
受け入れ基準を追記する
不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
開発担当者が、チケットの単体テストを実施する
受け入れ基準をチェックする
完了の定義をチェックする
探索テストに向けてテストチャーターを作成する
デイリーQAで、チケットに対して探索的テストを実施する
リスクを記録して、テスト計画に組み込む
テスト計画に従い、各テストを実施する
非機能テスト
Product QA（機能単位のアドホックテスト）
As Is
ユーザーストーリーマップから、ユーザーストーリーのチケットは起票する
DDDなど開発の設計フェーズ前に、ドメインとプロダクトの解像度を揃えるイベントストーミングで、システムの振る舞いをモデル化する
受け入れ基準を追記する不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
リファインメントで、ユーザーストーリーを確認して、サブタスクに分解する
受け入れ基準を追記する実装に関するメモを追記する不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
リファインメントで、チケットにストーリーポイントで見積もる
チケットを実装する
受け入れ基準を追記する
実装で注意すべきチェックリストを追記する不確実性を記録して、Decisionチケットで調査・検討・意思決定する
リスクを記録して、テスト計画に組み込む
開発担当者が、チケットの単体テストを実施する
受け入れ基準をチェックする
実装で注意すべきチェックリストを確認する完了の定義をチェックする探索テストに向けてテストチャーターを作成する
デイリーQAで、チケットに対して探索的テストを実施する
デイリーQAで、チケットの成果物を確認するリスクを記録して、テスト計画に組み込む
テスト計画に従い、各テストを実施する都度判断で、各テストを実施する非機能テスト
Product QA（機能単位のアドホックテスト）
ギャップ
設計フェーズ前に、ドメイン知識やプロダクト理解の解像度を揃えていない
イベントストーミングにて、追加されたシステムの振る舞いを受け入れ基準に追記していない
イベントストーミングにて、発見されたリスクを記録していない
リファインメントにて、追加されたシステムの振る舞いを受け入れ基準に追加していない
リファインメントにて、発見されたリスクを記録していない
チケット実装にて、追加されたシステムの振る舞いを受け入れ基準に追加していない
チケット実装にて、発見されたリスクを記録していない
チケット実装にて、追加されたシステムの振る舞いを受け入れ基準に追加していない
チケット実装にて、発見されたリスクを記録していない
開発担当者の単体テストにて、受け入れ基準をチェックしていない
開発担当者の単体テストにて、完了の定義をチェックしていない
デイリーQAにて、多角的な視点を取り入れてテストできていない
デイリーQAにて、発見されたリスクを記録していない
テスト計画に従い、テストできていない
まとめると…
ドメイン知識やプロダクト理解の解像度を揃える
SDLCの上流から受け入れ基準を追記していき、実装完了後にチェックする
併せて、チケットの完了の定義をチェックする
開発担当者が単体テストを完了したら、多角的な視点と取り入れ、探索テストを実施する
ちゃんとリスクを記録していき、テスト計画を立ててテストを実施する
ちょっと待って、以前に書いたブログで同じようなこと言ってる気がする…
今まで正しく動いていたものを、どこかで変えてしまって、少しづつ機能不全に陥ってたってこと？
『超守』したとしても、「守」がまだ正しく定着していない状態にも関わらず、「離」を試して上手くいかない、ただ戻すこともできず放置してしまっている状態だったと思います。
「守」を続けるのは地味で、一見は非効率に思えることもあるので、何か変えたくなる気持ちになりがちではある。
課題は『守』の定着
改めて、課題を設定すると『超守』して正しく機能している状態を定着させること
そんな最中、組織として各チームで目標設定するタイミングがあり、チームの目標の１つとして”プロダクトの当たり前品質”を掲げて、以下の２つを定着させるために取り組んでいくことにしました。
『単体テストの型化』
単体テストを個人に依存しない形で型化して、品質のボトムラインを向上させ、手戻りコストも削減させる
『テスト戦略の型化』
ISO/IEC/IEEE 29119などにソフトウェアテストの標準規格に準拠したテスト戦略の型を模索・試行して、アウトプット・アウトカム品質の強度を向上させる
当たり前品質を定着させる３つの取り組み
またまた登場しますが、「Gaudiy UNIFORM」、その中の1つに『高速実験』があります。
百聞は一見にしかず。百見は一触にしかず。調べたり考えたりするだけでは気づけない成功因子をイチ早く見つけるために、素早く試して素早く失敗する姿勢のこと。
『超守』はしつつ、「やっていき！」で素早くアクションに移して、問題があれば改善していきましょーのスタンスでお試し導入していきます。
さっそく「やっていき！」の『高速実験』で以下の３つの取り組みを進めています。
Don’t Think, Feel !!「想像に委ねず、愚直にドメインとプロダクト理解を深めよ！」
単体テストの型化と定着！「経験やスキルに依存せず、個人のアウトプット品質を安定させよ！」
テスト戦略の型化と定着！「チームのアウトプットとアウトカム品質を担保せよ！」
Don’t Think, Feel !!「想像に委ねず、愚直にドメインとプロダクト理解を深めよ！」
PRDやプロダクトバックログを非同期で共有して不明点や気になる点などのコメントをもらうスタイルから、イベントストーミング前にも読み合わせを実施するようにしました。
実際に読み合わせを実施してみると、PRDやプロダクトバックログはあまり読まれていないことや、事前に読んでいても解釈のズレがけっこうあることがわかりました。
解釈のズレを解消していき、ドメインやプロダクトの解像度が高めていくことで、手戻り要因となる認識齟齬や勘違い、思い込みが減り、イベントストーミングなど後続タスクの精度も高まっていきます。
「読み合わせ」については、こちらのブログ（タイトルが強烈ですが）が近しい内容だったので貼っておきます。
単体テストの型化と定着「経験やスキルに依存せず、個人のアウトプット品質を安定させよ！」
”To Be”の下部についての取り組みを紹介します。
まずは単体テストとデイリーQAの役割を再定義します。
単体テスト：チェッキング
記述式テスト（スクリプトテスト）として、「受け入れ基準」と「完了の定義」をチェックするデイリーQA（≒探索的テスト）：テスティング
探索的テストとして、テストチャーターに従いテストする
型化して、セレモニーに組み込んで定着させていきます。
単体テストとデイリーQAの型化
単体テスト
「受け入れ基準」は、ユーザーストーリーとDDDなどディスカバリーフェーズを経て、リファインメントや実装中でも追記していきます。
「完了の定義」は定めて、固定項目が設定されているので、必要に応じて追加は可能な状態にしています。
そして実装完了後の動作確認のタイミングで「受け入れ基準」と「完了の定義」をチェックして、実装完了としています。
探索的テスト
探索的テストは、テスターの経験やスキルに依存すると言われていますが、経験やスキルが高いメンバーや多様な視点を取り込めるテスト手法でもあります。
単体テスト完了後に、「受け入れ基準」で拾えない観点や不安な箇所などをテストチャーターに記入して、チームメンバーに探索テストを依頼します。
ちょっとした工夫として、探索テストを依頼しようとすると、単体テストで「受け入れ基準」と「完了の定義」をチェックしたかを確認するダイアログを表示するようにしています。
依頼されたチームメンバーは、テストチャーターに従い探索的テストを実施して、気になりや不具合などを起票します。
単体テストとデイリーQAの役割を再定義して、それぞれを型化することで、単体テストおよび開発担当者のアウトプット品質の個人依存を減らし、品質のボトムラインの向上と安定、さらにセレモニーに組み入れることで定着も試みています。
肌感ではありますが、以下のような恩恵を得られていると実感しています。
開発担当者のアウトプット品質が安定した
探索的テストで認知していない不具合や改善点が見つかるので、プロダクトの改善サイクルが生まれた
ところで『凡事徹底』という言葉をご存知ですか？
特別なことではなく、ごく平凡なことを徹底してやり抜くという意味です。 つまり、物事を成し遂げるには、当たり前のことを当たり前にできるか、徹底してできるかにかかっているということです。
取り組んでいることは難しいことではなく、ごく普通な平凡なことです。
こうした当たり前を愚直に継続していくだけでも、チームのアウトプット品質を安定させることができるよ！というお話です。
テスト戦略の型化と定着「チームのアウトプットとアウトカム品質を担保せよ！」
”To Be”の全体、主に上部と縦の矢印についての取り組みを紹介します。
…と言いたいところですが、まだ仕掛かり始めなので、紹介は次回に持ち越させてください🙇♂️
おわりに
さいごまで読んでいいただき、ありがとうございます。
チームのアウトプット品質の向上と安定を目標に取り組んでいることをシェアさせていただきましたが、いかがでしたでしょうか。
まだまだドヤれるほどではありませんが、けっきょくのところ「喝采はいらん、ちゃんとやんねん（by ハイキュー!!北信介）」という話なので、「ハイキュー!!」を好きになってもらえたら嬉しいですw
🎉次回8日目のGaudiyアドベントカレンダーは、Seya sanです！
AIチームで大活躍なSeya sanです、LLMな話をしてくれるか、せっかくのアドカレなのでまったく違う路線の話をしてくれるのか...わからない、でも楽しみにしていてください！！
初老とは40歳かららしいです、50歳からが中老、初老と中老の間にいるオッサンPdMとゆる〜く雑談したい方は、ぜひお話ししましょう！
いろんなポジションの仲間を絶賛募集中なので、少しでもGaudiyに興味を持っていただけたのであれば、まずはカジュ面からでもお待ちしております！