関連リンク
はじめに
こんにちは、マネーフォワード ERP開発本部 福岡第一開発部 Warriorグループの@arai.toshihiroと申します。
昨年の11月にマネーフォワードに入社し、もうすぐ一年が経とうとしております。今回はJaSST’25 Kyushuというイベントに参加したのでレポートを書こうと思います。
JaSST’25 Kyushuとは
開発者が実行委員として在籍する強みを活かし、開発者向けの実践的なソフトウェアテストの手法についての学びを提供しています。また、初学者向けの分かりやすいコンテンツも準備しており、さらに毎年九州の異なる県で開催されるため、様々な地域で新たな発見ができる機会も楽しめるイベントです。
詳細はこちらをご覧ください。
jasst.jp
基調講演: QAチームの士気の源泉 – 地図と価値と学び 湯本 剛（freee, ytte Lab.）
担当：@voller.david
初めて参加したJaSST’25 Kyushuの基調講演は、freeeの湯本剛さんによる「QAチームの士気の源泉――地図と価値と学び」でした。
この講演では、QAチームを率いるマネージャーがどのようにチームの士気を高め、学びを促進し、価値を生み出しているかについて話されました。
マネジメント・コントロール・アドミニストレーションという3つの視点から「マネジメントとは何か？」を掘り下げ、単なる進捗管理ではなく、「チームの方向性を示すこと」が本来のマネージャーの役割であると強調されていました。
特に印象に残ったのは、「チームの成功はメンバーの成功の総和である」という考え方です。
QAマネージャーの仕事は、チーム全体を引っ張ることだけではなく、メンバー一人ひとりが成功できる環境を整えること。
そのためには、ビジョンやロードマップを示して将来の方向性を可視化し、士気と学びを循環させることが大切だと述べられていました。
講演の中心となったキーワードは 価値・地図・学び の3つです。
- 「価値」は、QAが顧客や組織、チームにもたらす信頼や安心感、リスク低減などの効果のことです
- 「地図」は、チームのスキルや位置づけを「見える化」し、成長を感じられるようにする仕組みのことです
- 「学び」は、士気と密接に関わり合い、相互に影響を与えるサイクルのことです
湯本さんは、士気が上がれば学びの速度が上がり、学びが進めばチームの価値が高まると説明し、QAマネージャーはこのサイクルを意識的に回す存在であると述べました。
特に、スキルアップや資格取得などの「学び」を、個人の成長だけで終わらせず、チームや組織の価値につなげる視点が重要であるという点が印象に残りました。
自分自身も日々の業務で、学びをどうチームの成果に還元できるか悩むことが多いため、この話には強く共感しました。
また、品質コスト（予防、評価、内部失敗、外部失敗）についても触れられ、テスト活動を「コスト削減」ではなく「価値創出」につなげる考え方が紹介されました。
QAは数字やデータを通じてステークホルダーと対話し、チームの存在意義を説明できるようになるべきというメッセージも心に残りました。
今回の講演を通じて、QAマネージャーという役割が単にテストを管理する職種ではなく、チームの「士気」「成長」「方向性」を支える存在であることを改めて感じました。
特に印象に残ったのは、「学びと士気の関係」です。
学びがあると人は前向きになり、前向きだからさらに学びが深まる――このサイクルをどう保つかが、チームの雰囲気づくりの大切なポイントだと感じました。
現場では、スケジュールや品質基準などの制約の中で、チームの士気を保つことが難しい瞬間もあります。
しかし、そのような状況だからこそ、マネージャーが「地図」と「価値」を見せ、学びの機会を作ることの意味を強く実感しました。
今回、JaSSTに参加するのは初めてでしたが、全体を通して刺激的で学びの多い経験でした。
チームの一員として、自分がどのようにマネージャーやチームを支えられるかを改めて考えるきっかけにもなりました。
今回の講演をきっかけに、所属しているチームでも「価値・地図・学び」のサイクルを意識して取り組んでみたいと感じました。
招待講演: さまざまな現場でのテスト・QAマネージメントで実践してきたこと〜 千変万化：対象・条件・環境によって異なるアプローチについて考える〜 山本 くにお（SigSQA研究会）
担当：@cho.kori
このセッションではテスト・QAプロジェクトマネージャー、リード、ラインマネージャーの3つの役割について、実務経験を交えて説明されました。講演資料は95ページに及ぶ充実した内容で、以下のリンクから確認できます。
講演の中で印象的だったのは「早くてうまくいったという話は聞くが、遅くてうまくいったのは見たことがない」という言葉で、プロジェクトの成功にはスピードが重要であることを再認識しました。
そして、最も心に響いたのは「テスト・QAは知恵の総合格闘技」という言葉でした。
テスト・QAの仕事では、単一のスキルだけでは太刀打ちできません。技術的な知識、分析力、コミュニケーション能力、創造性、ビジネス理解など、これらすべてを状況に応じて使い分け、組み合わせていく必要があります。
そして「知恵」という言葉も重要で、単なる知識や技術ではなく、それらを実践的に応用する洞察力や判断力が求められます。
限られた時間とリソースの中で、どこにフォーカスすべきか、どうリスクをマネージするか。
経験と思考を重ねて磨かれる「知恵」が必要だと感じました。
また、SQA（Software Quality Assurance）の4つの役割（ミツバチ、ペースメーカー、ブレーキ、コンサルタント）やAQUAフレームワークについても紹介されましたが、講演内では深く言及されていませんでした。これらの考え方はとても興味深く、関連資料を探して、今後のQA活動に活かしていけるよう、学びを続けていきたいと思います。
パネルディスカッション
担当：@arai.toshihiro
最後のセッションは非常に豪華なメンバーによるパネルディスカッションが開催されました。本セッションは参加者からの質問に、QA界のトップランナー2名が回答するという形式で、現場のリアルな課題解決のヒントが満載でした。本パネルディスカッションに登壇されたのは、QA/テスト分野の第一人者であるお二人です。
- 湯本 剛 氏（freee, ytte Lab.）
- 山本 くにお 氏（SigSQA研究会）
なお、以降は私のメモに基づく要約であり、ご本人の意図や意志の強さを正確に表現できていない可能性があります。その点、ご了承ください。また、敬称をすべて「さん」に統一しています。
【質問1】QAマネージャーのメトリクス標準化について。テストの品質が悪い場合にどのようにアラートを出すようにしていましたか？
山本さん：
当初計画の欠陥数より多くの欠陥が見つかった場合や、逆にテストをしてもバグが全く出ない場合など、どちらの状況も「テストの質」を疑うトリガーになります。不具合密度に着目し、特異点（異常な値）が出た場合にそれを掘り下げるといいと思います。
湯本さん：
ベースとなる上流（設計側）の品質が良いのであれば、テストでバグが出ないのは当然あり得ます。これはテストのメトリクスではなく、設計側のメトリクスで測るべきでしょう。IPAの『定量的品質予測のススメ』などを参考に、単なるテスト結果ではない、プロセス全体での品質測定を考えることが重要です。
「テストしました、本番リリースしました、バグが出ました」という状態が続くなら、それは意味のない定型的なテストをしているだけでないかと疑うべきです。探索的テストを組み合わせるなどアプローチを見直すことも有効です。
参考として、湯本さんの会社では、案件数が1.5倍に増えたにもかかわらず、QA中に出るバグが0.5%減、本番でのインシデントが45%減という改善実績があるそうです。
【質問2】組織にQAエンジニアがいるとなぜいいのか。その価値を経営層にどう伝えるか。経営層に刺さるようなQA活動の説明はどうしたらいいか？
湯本さん：
最もシンプルでわかりやすい成果は、「インシデント（本番環境での障害）が減りました」と明言できることです。
山本さん：
開発のリードタイム削減やテストの自動化による効率化など、具体的な貢献を数字で示しましょう。毀損額（障害による損失額）が減った、開発の手戻りが減ったなど、定量的なアピールでなければ納得してもらうのは難しいでしょう。
また、プロダクトの状況によっては、QAを「保険」として考えてもらうことも大切です。「利益の2〜3%をQAに投資することで、事業リスクを軽減できます」といった伝え方をすることも有効です。
【質問3】テストの工数が高いので抑えてほしいということを求められている。テスト設計の標準化って、どんな観点で進めていくのが良い？
山本さん：
工数削減のためには、必要な観点を抽出・集約し、機能として重要なところに注力することが不可欠です。注力ポイントは開発者に確認し、どれくらいパターンを見るかなどを決めていきます。加えて、境界値やデシジョンテーブルなどを利用した設計技法の導入が有効です。
また、探索的テストをQAエンジニアだけでなく、プロダクトオーナー（PO）などにも協力してもらいテストしてもらうことも有効な手段です。
湯本さん：
標準化が難しい場合は、せめて不具合のSeverity（重篤度）が関係者（PO・開発者）の認識が合っていることが大事です。リスク洗い出し会で、クリティカルなものがあるのかを確認し、その前に判断チャートを作成して、クリティカルなものが起こる可能性があるかないかわかる状態にしましょう。「どんな問題が起きたらまずいのか」を話し続けるという、一見地味な認識合わせこそが重要です。
（湯本さんの会社では）設計は属人的になっており、テスト設計標準化はあまりできていないそうです。これについては山本さんから、オンボーディングに時間をかけ教育体制がしっかり整っているからこそ標準化しなくてもうまくできているのでは、というコメントがありました。
【質問4】最近課長になりました。部下を「褒める」コツはありますか？
湯本さん：
1on1などの前に、褒めるべき点を具体的に書き出しておくことを推奨します。書き出さないと、つい忘れがちになってしまいます。伝えるのが恥ずかしい場合は、伝える前に脳内でのトレーニング（シミュレーション）をするだけでも効果があります。
他チームのプロダクトオーナーなどから部下の活動に関してフィードバックを聞くことも有効です。第三者の評価は説得力があります。
山本さん：
周りで聞こえてきた第三者的な良い評判を伝えるのは、説得力を持たせる良い手段です。最も重要なのは、「本人が工夫したこと」を深掘りしてあげることです。成果の裏側にある本人の努力や試行錯誤をしっかりと言葉にして引き出してあげましょう。
【質問5】スキルが未熟なメンバーに対して、独り立ちできるように何ができるか？
湯本さん：
何を学んでほしいのか、どんなスキルを身につけてほしいのかを明確にしておくことが重要です。
「やってみなよ？」と言うだけでは行動に移さないメンバーには、「この本を読みなさい。感想を次の1on1で聞かせてね」といった、行動を促すための具体的なタスクと期限を与える手法が有効です。
山本さん：
日頃から「こんなのどうかな」といった小ネタをメンバーに投げかけることを意識しています。その中で、メンバーに「ヒットした（興味を示した）」ものを見つけ、それについて一緒に深掘りしていくことで、自律的な学習を促すことができます。
感想とまとめ
今回のパネルディスカッションは、QAマネジメントにおける「技術的な深掘り」（メトリクス、工数削減）と「組織的なマネジメント」（経営層への価値伝達、部下育成）という、両輪の課題に真っ向から答えてくれる内容でした。
特に「部下を褒めるコツ」や「独り立ちの支援」といった、日々のマネジメントの悩みに、QAのトップランナーが具体的な行動レベルの回答をしてくれた点が、このセッションの最大の魅力だったと感じています。
私自身としても、QAの価値を「インシデントの減少」という最も刺さる指標で示しつつ、その裏付けとして「正しいメトリクス設計」や「リスクの認識合わせ」が重要であることを再認識しました。この学びを、明日からの業務に活かしていきたいと思います！
さいごに
以上が、JaSST’25 Kyushu 参加レポートでした。ここまで読んでくださって本当にありがとうございます。
今回のイベントを通じて、さまざまな現場での経験や知見を持つ方々と交流し、多くの学びを得ることができました。その学びを自分自身の成長につなげていきたいと思います！
恒例のリンクを貼っておきます。マネーフォワード 福岡開発拠点ではエンジニアを募集しています！よろしくお願いします！
コメント