SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2023 セッションレポート(AD)

プロダクトの品質をテストするために必要な、チームのモヤモヤを解消するための仕組み作り

【9-E-2】プロダクトチーム一丸となって臨むソフトウェアテストの勘所

  • このエントリーをはてなブックマークに追加

 ソフトウェアテストの目的の一つは、プロダクトの価値を明らかにすること。だが、プロジェクトの規模が大きくなると、メンバー全員が同じ方向を向くことが難しくなり、思っていることが口に出せないなど、モヤモヤすることも増えてくる。このようなモヤモヤを解決し、プロジェクトメンバーが同じ方向を向くためにはどうすればよいのか。ベリサーブ 研究企画開発部 サービス開発課 課長/プロダクトマネージャーの朱峰錦司氏が提案するのが「ワイガヤテスト」である。ワイガヤテストとはどんな仕掛けなのか、生まれた背景も含めて朱峰氏が解説した。

  • このエントリーをはてなブックマークに追加

プロジェクトの規模が拡大するとモヤモヤが増えるワケ

 ベリサーブは約40年にわたりソフトウェア品質やソフトウェアテストの領域に特化したサービスを提供している企業である。朱峰氏はプロダクトマネージャーとして、「QualityForward」や「GIHOZ」「InsighTest」などベリサーブのテスト支援プロダクト群の全体統制と普及展開に従事している。またプライベートでも、ソフトウェアテスト/品質に関する日本最大級のシンポジウムJaSSTが運営する「JaSST nano」のお世話係を務める、テスト大好き人間だ。

 ソフトウェアテストをする目的はさまざまあるが、その中でもメインの目的になり得るのが、プロダクトの価値を明らかにすることである。

 だが、その価値の共有について、「プロジェクトの規模が大きくなり、プロジェクトに携わる人の数が増えると、メンバー全員が同じ方向を向かなくなるなど、プロダクト価値の共通認識の醸成が難しくなる」と朱峰氏は指摘する。

株式会社ベリサーブ 研究企画開発部 サービス開発課 課長/プロダクトマネージャー JaSST nano お世話係
株式会社ベリサーブ 研究企画開発 部 サービス開発課 課長/プロダクトマネージャー 朱峰錦司氏   

 朱峰氏自身もプロダクトオーナーとして携わったプロジェクトで、「みんなが同じ方向を向いていないことに、モヤモヤを感じたことがある」と話す。プロダクトの立ち上げ期はビジネスオーナー、プロダクトオーナー、UXリサーチャー、UIデザイナー、iOSエンジニア、バックエンドエンジニアの計6人でプロトタイピングを中心にプロダクトを検討していた。「当時は月に1回の仕様検討会やユーザーテストを実施し、開発は1日1スプリントで、日々優先順位を議論していました。まさに6人でワンチームという形で、スピーディーにフィードバックループを回すことができ、価値探索がうまくできていました」と朱峰氏は振り返る。

 このフェーズでは特に何の不満もモヤモヤも発生することはなく、「価値のある活動ができていた」と朱峰氏。だが開発が本格化したことでPOも1人ではまかなえなくなり、「POチームを組成することになった」(朱峰氏)という。またモバイルチームはメンバー増強。バックエンドチームはBFF(Backend For Frontend)チームに改め、体制を増強。その裏では組み込みのチームや基幹チームなどの複数のチームとも連携した。

 「このように規模が大きくなったことで、マニュアルテストを自動化しきれず、専任のQAチームを設けました」と朱峰氏は説明する。テストだけではなく、プロセスもしっかりプロジェクトとして定義した。例えばユニットテストはコンポーネントチームに任せ、開発チームが自分たちの裁量でやりやすいような形にした。複数のコンポーネントが絡むインタフェース部分は自動化し、結合テストを実施。また全体のつなぎの部分を、専任のQAチームが担当するという形にテストのプロセスを整理したのだ。

 「従来はちょっとしたアップデートにも1年かかっていた重厚長大な開発が、このようなプロセスに改善したことで、2カ月に1回市場にローンチできるようになりました」と、この時点では手応えを感じていたという朱峰氏。アウトプット量も非常に安定していた日々を積み重ねていたが、PO目線でのモヤモヤが積もってきたという。

 そのモヤモヤとは「ちょっとした既存機能の改善が、他の新機能開発に対して優先順位を調整しきれずになんとなく先に進んでしまう」「リファインメント・プランニングで開発内容を合意できていたつもりが、出来上がると微妙に違うように感じ、手戻りが微妙に増えてきている」といったものだ。このようなモヤモヤが表層化したのは、チームに分割されることによって、ワンチーム感が薄れたことにより、コミュニケーションやプロセス、マインドセットなど、いろいろな問題が複雑に絡み合う状況があったからだと朱峰氏は当時考えていたという。

QAに詰まっている、プロダクトの価値と向き合うノウハウ

 このようなモヤモヤを解決するため、朱峰氏はさまざまな角度から事例や文献を調査した。今回はその中から、「ワイガヤテスト」という概念につながった、QA領域と心理的安全性という2つの切り口にフォーカスして調査した事例や文献が紹介された。

 QA領域にフォーカスしたのは、朱峰氏自身、QA領域に強みを持っており、QA活動のガイドラインや事例には、プロダクト価値といい感じに向き合うためのノウハウがあるのではという個人的な仮説があったからだ。そこでアジャイルQAという領域ではどのようなことが言われているのかを調査したという。

図1.アジャイルQAにおける共通の考え方
図1.アジャイルQAにおける共通の考え方

 まず調査したのは、アジャイル品質パターン(QA to AQ)。早稲田大学の鷲崎弘宜教授をはじめ、著名なソフトウェアエンジニアがアジャイル品質の考え方と推奨される活動を、4つのカテゴリと23のパターン集としてまとめたもの。この文献では「開発チームにおいて、品質保証メンバーと残りのメンバー間の障壁をなくし、皆が品質に関わる。これが鉄則」としっかり記述されていたという。

 次に調べたのが日本におけるソフトウェアテスト技術者資格認定の運営組織JSTQBが作成した「アジャイルテスト担当者シラバス」。ここでも「チーム全体のアプローチという項目で、QAだけでなく、チーム全体が品質に対する責任を持つこと」というように、先の文献と同じようなことが書かれていた。またチーム全体のアプローチの本質はロールに関係なく同じ方向を向くため、PO、開発者、QAの三者が一体となって同じ方向を向いて仕事をする「3人の力(Three Amigos)」アプローチを解説していたという。

 さらに「Growing Agile:テスティングマニフェスト」でも同様のことが書かれていたという。Growing AgileはSamantha Laing氏、Karen Greaves氏らが所属するコンサルティング企業。ブロッコリーという通称で活動している風間裕也氏の個人ブログで日本語に翻訳して紹介している。この文献ではアジャイルQAにおける重要な5つの価値観をマニュフェストとして紹介しており、その1つが「テスターの責任よりも品質に対するチームの責任」である。

チーム全員が同じ方向を向くための「ワイガヤテスト」とは

 「自分の仮説は間違っていなかった」と実感した朱峰氏。立ち上げ期はできていたはずのことが、なぜ、できなくなったのか。その要因の一つとして考えたのが体制である。「例えばPOチームやQAチームというように、チームに付いたラベルが縦割りのマインドセットを醸成したと思う」と振り返る。要件や品質について、「これでいいのか」と思うことがあったとしても、POチームやQAチームの役割なので、開発チームのメンバーは飲み込んでしまう。逆もしかりで、POチームやQAチームが最初の要件と違うと感じても、開発には口を出せないと感じてしまう。

 このようなお互いがお互いに思っていることを口に出せず、飲み込んでしまう。このようなモヤモヤを解決するのに欠かせないのが、もう一つの切り口である心理的安全性を担保することだ。心理的安全性はチームの生産性に関わる重要なファクターとして知られている、心理学における概念である。日本の品質保証に多大な貢献を果たしたW.E.デミング氏は組織経営論の中で「不安を取り除け。そうすればきっと皆が組織のために効率的に働くようになる」と提言している。

 これらのサーベイから考察できたのは、「プロセスやコンポーネントの分担もよいが、改めてみんなでプロダクトと向き合う機会を作ること」と「その上で感じたこと、気付いたことを共有し、対処すること」である。だがこれを実践するには、仕掛けが必要だ。

 そこで、朱峰氏がたどりついたのが「ワイガヤ」というキーワードだった。ワイガヤとは、本田技研工業で昔から行われていたミーティング手法である。「ワイガヤの本質“ひらめき”は必然的に起こせる」という著書の中には、「ワイガヤには上下関係を排した議論の場であるという不文律がある。ワイガヤは人の発意(気付きやひらめき)を促して、今まで存在しなかったモノやコトを創出し、イノベーションを起こすのである」ということが書かれていた。

図2.メトリクスの具体例
図2.ワイガヤとは

 何についてワイガヤするのか。同じプロジェクトとはいえ、プロセス上の役割も構造上の役割も異なる。だが共通するモノがある。それは目の前にあるプロダクト/システムそのものである。そこで月に1回、チーム横断でプロジェクトメンバー全員が集まって、本番環境もしくは極めて近い環境下で動作するプロダクトに触れ、気付きを共有し合うワイガヤテストを実施することにしたのだ。

 実際にやってみると、「非常にうまくいった」と朱峰氏は語る。要件やデモとして伝えられる改善事項について、実際に体感することで、対応の優先度への納得感が高まったことも成果の一つだ。また個々のシステムの特性も共有。議論した上で、全体最適なUI/UXの検討が、以前より手戻りなく実施できるようになったという。さらに「マインドセットが前向きになり、プロダクトの企画や仕様に関する議論が活性化したこともワイガヤテスト実施の効果。ぜひ、チームの規模が大きくなり、動きが鈍っているという課題を持っている方は、ワイガヤテストを試してほしい」と朱峰氏は語る。

メトリクスの活用で内部品質やプロセス品質を改善

 セッションの最後にはおまけとして、アジャイル開発におけるソフトウェアメトリクス活用のポイントについても紹介。メトリクスの活用は、内部品質やプロセス品質の改善に役立つからだ。

図3
図3.メトリクスの活用法

 アジャイル開発におけるメトリクス活用のポイントは「自動的に取得・分析可能なモノから始めること」と朱峰氏は言う。活用するメトリクスが決まれば、それを振り返りや要件検討の場で改善検討のインプットにするのである。

図4
図4.メトリクスの具体例

 「体制が大きくなると、おそらくいろいろなモヤモヤが出てくる。そのモヤモヤの要因の大半は、プロジェクトメンバーみんなが同じ方向を向いていないこと。みんなが同じ方向を向くための仕掛けとして、有用なのがワイガヤテストです。ぜひ、試してほしい」

 最後にこう視聴者に呼びかけ、朱峰氏はセッションを締めた。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

提供:株式会社ベリサーブ

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17411 2023/04/07 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング