チーム全員が同じ方向を向くための「ワイガヤテスト」とは
「自分の仮説は間違っていなかった」と実感した朱峰氏。立ち上げ期はできていたはずのことが、なぜ、できなくなったのか。その要因の一つとして考えたのが体制である。「例えばPOチームやQAチームというように、チームに付いたラベルが縦割りのマインドセットを醸成したと思う」と振り返る。要件や品質について、「これでいいのか」と思うことがあったとしても、POチームやQAチームの役割なので、開発チームのメンバーは飲み込んでしまう。逆もしかりで、POチームやQAチームが最初の要件と違うと感じても、開発には口を出せないと感じてしまう。
このようなお互いがお互いに思っていることを口に出せず、飲み込んでしまう。このようなモヤモヤを解決するのに欠かせないのが、もう一つの切り口である心理的安全性を担保することだ。心理的安全性はチームの生産性に関わる重要なファクターとして知られている、心理学における概念である。日本の品質保証に多大な貢献を果たしたW.E.デミング氏は組織経営論の中で「不安を取り除け。そうすればきっと皆が組織のために効率的に働くようになる」と提言している。
これらのサーベイから考察できたのは、「プロセスやコンポーネントの分担もよいが、改めてみんなでプロダクトと向き合う機会を作ること」と「その上で感じたこと、気付いたことを共有し、対処すること」である。だがこれを実践するには、仕掛けが必要だ。
そこで、朱峰氏がたどりついたのが「ワイガヤ」というキーワードだった。ワイガヤとは、本田技研工業で昔から行われていたミーティング手法である。「ワイガヤの本質“ひらめき”は必然的に起こせる」という著書の中には、「ワイガヤには上下関係を排した議論の場であるという不文律がある。ワイガヤは人の発意（気付きやひらめき）を促して、今まで存在しなかったモノやコトを創出し、イノベーションを起こすのである」ということが書かれていた。
何についてワイガヤするのか。同じプロジェクトとはいえ、プロセス上の役割も構造上の役割も異なる。だが共通するモノがある。それは目の前にあるプロダクト／システムそのものである。そこで月に1回、チーム横断でプロジェクトメンバー全員が集まって、本番環境もしくは極めて近い環境下で動作するプロダクトに触れ、気付きを共有し合うワイガヤテストを実施することにしたのだ。
実際にやってみると、「非常にうまくいった」と朱峰氏は語る。要件やデモとして伝えられる改善事項について、実際に体感することで、対応の優先度への納得感が高まったことも成果の一つだ。また個々のシステムの特性も共有。議論した上で、全体最適なUI/UXの検討が、以前より手戻りなく実施できるようになったという。さらに「マインドセットが前向きになり、プロダクトの企画や仕様に関する議論が活性化したこともワイガヤテスト実施の効果。ぜひ、チームの規模が大きくなり、動きが鈍っているという課題を持っている方は、ワイガヤテストを試してほしい」と朱峰氏は語る。
