FigmaとMeetを使ったリモートワークショップの振り返り

アイキャッチ画像

こんにちは、デザイナーのはるたんです。 最近はハンドドリップを極めたり、個人でReact Nativeを使ってアプリ開発することにハマっています。

今日は3月に開催したリモートワークショップの振り返りと気付きを共有します。

はじめに

僕らのチームは、クラウド税務申告ソフト「申告freee」という税理士さん向けのソフトを開発しています。申告freeeは、freeeの中でも特に業務理解が難しいプロダクトの1つです。古くからいるメンバーの中には、自分で税理士資格のテキストを購入し、申告業務の勉強をしている強者もいますが、後からJoinしたメンバーはキャッチアップが難しい状況でした。そのため、大きい機能開発の時には必ずワークショップを開催し、メンバー間の認識合わせを行うようにしています。

以前のワークショップ

2019年夏に開催したワークショップの様子

上記の写真は2019年夏に開催した時の写真ですが、普段は模造紙と付箋を使ったワークショップをしていました。

急遽リモートでワークショップを開催することに

今回も新機能開発の企画がスタートした後、いつも通りオフラインのワークショップを企画していました。状況が変わったのは2月下旬です。翌週にワークショップを控えていたのですが、新型コロナウイルスの影響で3月2日以降原則在宅で勤務することが決まりました。

急遽オフラインで企画していたワークショップをリモートでできるように設計し直し、試行錯誤しながら取り組んだのが今回のワークショップです。参加メンバーはデザイナー1人(僕)、プロダクトマネージャー1人、エンジニア8人。計10人の予定を長時間抑えて開催するワークショップだったので、オフラインで開催した時と同等のアウトプットを出したいという想いがありました。

リモートワーク直後のアンケート結果を振り返るとオフラインワークショップと同等、もしくはそれ以上のメリットがあったと感じました!今日はその時に実践したノウハウを全て話したいと思います!

リモートワークショップ事前準備

オンライン・オフライン共通で準備しておくこと

  • メンバーの時間を抑える
  • ワークショップの目的をはっきり整理し、メンバーに共有する
  • ワークショップの構成を考える
  • 各ワークの優先度を決める
  • タイムテーブルを設定しておく
    • 仮でも良いから優先度に応じて、タイムテーブルを考える
  • ワークショップのアウトプットイメージを立てておく
    • ワークショップのアウトプットをどうやって活かすかを検討しておく
    • ワークショップ中は時間との闘いになるので、アウトプットイメージがないと時間のコントロールができない
  • ドメインマスターに参加してもらう
    • ドメインマスターとは
      • 担当しているプロダクトに詳しい専門家のこと。freeeではカスタマーサポートのメンバーやPdMがドメインに詳しいことが多い。
    • ワーク中に不明点があったら、すぐに相談できるし、相談してもらうことでメンバー間の認識のズレがなくなる。

オンラインで大事なこと

  • メンバー全員、ツールが使えるかどうかを確認する
    • 参加者にしつこいくらいリマインドして、事前にFigmaが使えるかどうかの確認を行った
  • ツールの利用方法を周知する
    • Figma上にワークショップで使う機能の説明スライドを用意した
  • 数人でプレテストを実施する。できればツールを触ったことがないメンバーに事前に触ってもらう
    • 今回はFigmaを使ったことがない参加予定のメンバーに協力を依頼して、Figmaの操作してもらった
    • 詰まったポイントを重点的に上のスライドに追加するようにした

利用したツール

  • Figma
    • ホワイトボードの代わりとして使った。
    • Miroでも良かったが、今回はファシリテーターが使い慣れているFigmaを利用した
  • Meet
    • ファシリテーターだけ画面共有する
    • 話さないメンバーはミュートにする。タイピング音が気になってアイデア出しに集中できないことがあるため。

リモートワークショップの運営中に大事なこと

  • 全員が揃わなくても、開始時間を1分経過したら開始する
  • なるべくカメラに向かって大きめリアクションを。うなづく/拍手/OK/意見がある
  • 喋りがちのメンバーには「議論を支配しないように」。
  • なかなか発言が苦手なメンバーには「積極的に発言をするように」。
  • お互いでカバーする。
  • 休憩/甘いもの/ストレッチ。各自で適宜とるようにする(めちゃくちゃ疲れるので)
    • 今回、休憩時間を考慮していなくてしんどかったというフィードバックがありました(反省)

今回のWorkshop中の流れ

1.事前準備として、Figmaの使い方を周知する

Figmaの操作方法について紹介したスライドの画像

冒頭で紹介したとおり、メンバーに何度もリマインドを行い、ツールによって問題が生じないかどうかを試してもらいました。

2.ワークは時間通りにきっちり始める

ハングアウトで6人参加中のスクリーンショット

これは開始5分前の様子です。10人中、5人がすでに入ってますね!流石!

3. 改めてFigmaの使い方を説明

Figmaを使って複数人で操作している時の画像 事前周知したとはいえ、Figmaの操作で迷う人が出ないかどうかを改めて確認しました。

4. 目的を共有

今日やることの説明が書いてあるスライドをFigma上に表示してある様子

会の目的を10分くらいで共有しました。 タイムテーブルはワークに合わせてよしなにやると良いと思います。

5. Workでやることを説明

10人くらいでFigmaを操作している様子

事前にメンバーの箱を用意したアートボードを用意しておいたので、そこに付箋をひたすらはってくださいという説明をします。上の画像では見えづらいですが、タイムテーブルをFigma上に書いておくことで常に時間を意識してワークを行いました。

6. 発散と収束

合計7セッションやったんですが、各セッションを前半、後半に分けました。

個人のアートボードスペースで発散をしている様子
個人のアートボードスペースで発散をしている様子

前半ではひたすら黙々とアイデアを発散してもらいました。

個人のアートボードで発散したアイデアをマスターのアートボードに移動させている様子

後半はMasterというアートボードを用意しておいたので、そこに自分の中の推しアイデアを2,3個移動してもらいました。 どのアイデアが誰のかわかるように、FigmaのRename機能で付箋に自分の名前を書いてもらいました。

以上でワークショップの流れの紹介は終わりです!

個人の振り返り

良かったこと

  • タイマーを用意して、画面共有しながらやったのでほぼタイムスケジュール通りにワークショップを終えることができた。
  • 事前準備とシミュレーションのおかげでほぼミスなく終えれた
  • 心を鬼にして時間通りに進める

画面共有しているウィンドウにタイマーを表示している様子 こんな感じで画面共有しているウィンドウに常にタイマーを表示していました。

改善点

  • 休憩時間を確保しておく (かなりきついので、休憩時間をタイムスケジュールにいれる)
  • 話していない人のフォローをする。
  • 前提知識が揃っていなかったり、事前に考えておいてもらわないとアイデアがでないこともあるので、事前に目線を揃えておく
  • 話すときは名前をまず名乗ってもらう。10人いるとわからなくなるので話が振りづらい

メンバーからのフィードバック

終了後、アンケートを取ったので良かった点と改善点をそれぞれ共有します。

感想

  • 事前準備がかなり丁寧な印象で、何をすれば良いのかが分かりやすかったです!
  • この形式のワークショップはリモートでもやりやすかったのでよかったと思う。時間がタイトだったので事前準備していないと思ったように考えが出てこないと感じた(主に自分が)
  • 紙じゃないことによって、他の人たちの意見の透明性も増した気がしました。
  • リモートで本格的なワークショップはできないという予想を裏切ってくれました(感謝)

良かった点

  • リモートでもワークショップできるんだという驚きと発見があった。
  • シンプルにワクワクした、このアイデア達を実際に造っていくのが非常に楽しみ
  • どういうことが今できないのか現状ベースでしっかり認識できた

改善点

  • 1つ目のワークの記載例を書いておくとなおわかりやすかったかも。
  • 休憩時間くらいですかね?
  • ある程度考えてきてもらうとよかったように思う

最後に

リモートのワークショップが決まった時に、このツイートをしたらすぐに反応してくれたクックパッドの倉光さん。 事前に運営のコツをヒアリングできたおかげで、当日はかなりスムーズに運営できました!ありがとうございます!

こちらのスレッドがとても参考になるので、是非ご確認ください。

厳しい状況が続いていますが、みんなで工夫しながらこの状況を乗り越えていきましょう!

フリーをやめてフリーに入社した話

就職 会社員になった男

ご挨拶

こんにちは。はじめまして。
freee株式会社でデザイナーやっています。kazuと申します。
お酒大好きゲーマーです。
Twitterはこちら→ @kazu_u

freeeでは会計の方を担当しています。

知識がほぼないプロダクトのデザインなので勉強が大変ですがメンバーがすごくサポートしてくれるのでなんとかやっています。がんばります。

さて、私は2020年1月20日にfreeeに入社したばかりのど新人です。
さらにそれまでは10年くらいフリーでデザイナーをやっていました。

フリーからフリーに。(これが言いたかった)

minimal designからfreeeに
個人事業主の時は、Minimal Designという屋号で活動してました。

個人事業主(フリーってかくとややこしいのでw)は時間が自由で仕事も選べて出社もないので満員電車にのらなくてすむなどで会社員をやめて個人事業主で活動する人が増えていると思います。
実際、めんどくさい日があったら平日だろうとなんだろうと昼間っからお酒のんでアニメみたりゲームやったりしてたし、ほんとひどい日もあったけど個人事業主で一人でやっているからこそできたと思う。そういう意味ではすごい自由だった。※真似したらダメです

ではなぜ今まで個人事業主で自由にやってきたのに、freeeに入り会社員になったのか。

きっかけはタイミングだった

私の仕事の取り方は、人をみて仕事を取ることが多くて報酬などはあまり気にしないことが多かったです。
freeeから「一度オフィスに遊びに来ませんか?」とオファーをもらって話を聞きに行って、好き勝手話してきたらトントン拍子に採用が決まりました。
数人の方と面接し、色々話していく上で雰囲気がいいなあと感じ、働き方も縛られず、プロダクトの成長をストレートに見れるし、最近自分のなかでプロダクトを長く見ていきたいチームで活動もしたいとどこかで想っていることがありタイミング的に運命なのかな?と思い入社を決めました。

面接画像
師走の忙しい時期にすごいタイトなスケジュールで面接をセッティングしていただきました。あのスピード感すごかった。

ですので、個人事業主のときと会社員の時とのマインドは変わってません。
長期的なとてもでかい案件がとれた!みたいなイメージです!
まー、電車に乗るという最大のタスクは増えましたがw

10年ぶりの人との触れ合いで緊張

とまぁ、こんな感じで個人事業主をやめ、会社員になったんですが約10年ぶりなので初出社はすごい緊張しましたね。
うまく馴染めるだろうか。急に大きな組織でやっていけるのかなど、不安でいっぱいだったけど、マネージャーが頻繁に声をかけてくれたり、メンバーもランチにさそってくれたりしたので手厚いサポート感謝という気持ちでした。

食べなかったです

毎日が新鮮だった

オンボーディング受けたり、ほぼ全社員の前で自己紹介したり(ガチャ爆死芸ありますって話したらスベった)、名刺もらったり、メンバーとランチ行ったり、出社退社も。
全てが新鮮で新しいゲームプレイしてワクワクしている感覚があった!
周りに誰かいるということがほぼほぼなかったのでこれもすごくいい。困ったら聞けばいいこともあるので助かる。ひとりでは難しいことの一つだった。

まわりが優秀な人ばかりなので毎日学びになってるのもうれしい。
よい環境なので気になる!って方いたらオンラインお茶しましょう!(オンライン飲酒でも可。むしろこっち)

UXデザイナー募集要項

新しい環境はたのしくもあり葛藤の日々

こんな感じで3ヶ月くらい経ったんですが、freeeってど新人の私の発言でも色々通ったりするんですよね。そこは面白いなあって思いました。
あれやりたいこれやりたい、イベントやりたい。とか色々提案しているけどいまだにできていないのでこれから少しずつ実現していきたいとおもってこんな記事を書いてみました。(これも提案の一つでfreeeのデザイナーで発信していきたいという気持ち)

提案しまくってる様子

会社員で出社するようになるが....

入社して1ヶ月くらいでコロナの影響でリモートになってしまって前と変わらない感じになってしまってますが、こういう状況でもfreeeのデザインチームがよりよいチームになれるような働きを試みたいです。
でも当面はドメイン知識ですけどね。
なんとか食らいついていきます。 そして、freeeにとってデザイナー10連ガチャで星5になれるようにがんばっていきます。

まとめ

freeeにきてよかった。 学びの場があるし、環境もすごしやすい。
意見も通りやすいので発言がしやすい。
みんないい人。
飲み屋もおおい、ランチも充実。

www.instagram.com

kazu on Instagram: “五反田の鉄板焼きのお店チェローナの焼きそば。 天かすがエビ風味でうまい。 とにかく美味しい焼きそばだった。 #焼きそば #鉄板焼き #シャレオツ焼きそば #うまい #五反田ランチ #目玉焼き”

最後に


フォートナイトやマインクラフトやってる方いたら友達になってください!

UXチームの勉強会「スパルタンUX」の紹介

皆さまこんにちは。初めまして。新卒でUXチームに入ったゆっちゃんです。普段は会計freeeのプロダクトデザインをしています。

今日は、UXチーム内で行なっている勉強会の紹介をします。 その名も、スパルタンUX!強そう!(元ネタのアーケードゲーム『スパルタンX』、思い浮かべた方は正解です!)

スパルタンUXとは?

UXチームは2年ほど前からスキル向上のための輪読会を行なっています。事前に課題書籍を読んでdocに感想と質問を書き、週2の会で共有します。

4season目の今回のお題はこの本です!

デザイニングwebアクセシビリティ

デザイナーのスキルにアクセシビリティが据えられたため、著者の一人である弊社デザイナーのmagiさん解説の元進めていくことになりました。 ちなみに前回は「シロクマ本」こと情報アーキテクチャでした。

f:id:yuchan1090:20200421161745j:plain
お昼を食べながら、楽しそうな写真です (リモート勤務になる前の様子で、今はテレビ会議で行なっています)

8章:ビジュアルデザイン

8章は体験版の無料ダウンロードができますので、ぜひ読んでみてください。 www.borndigital.co.jp

この章では主にビジュアル表現に関して、アクセシビリティを意識しないとやってしまいがちなNG例と解決策がまとめられています。

目次

  • 8-1 見た目に頼っている

  • 8-2 コントラストが低い

  • 8-3 どこが押せるかわからない

  • 8-4 テキストブロックが読みづらい

  • 8-5 文字が画像になっている

  • 8-6 フォーカスが見えない

  • 8-7 小さく密集したものが押せない

  • 8-8 スタイルに一貫性がない

  • 8-9 閃光で発作が起きる

  • 8-10 拡大すると問題が起きる

小見出しのタイトルだけでもドキッとしますね。印象に残った章を抜粋します

8-2 コントラストが低い

視力や色の見え方はユーザーによって異なり、発色もモニターによって様々です。背景と文字の色の対比を作らないと、ユーザーによっては読みにくかったり読めなかったりします。下記画像が紹介されている例ですね。

f:id:yuchan1090:20200421162947p:plain
コントラストが低く見にくいデザインのページの例。本書から抜粋

淡い色で作るの、やりがちですよね、、パステルカラーなどは女性向けのサービスだとやってしまいそうだと思います。

freeeのデザインシステムは、WCAG2.0(アクセシビリティガイドライン)のコントラスト比を満たすカラーで構成されています。カラースキームを増やせるよう検討していますが、コントラスト比を保つのはなかなか難しいようです。

8-5 文字が画像になっている

テキストはマシンリーダビリティが高いので、様々な加工が可能です。例えばユーザーはテキストを拡大したり色を反転して読むことができます。しかし画像にしてしまうとこういったカスタマイズができないので、読むことができない人が多くなります。特にスクリーンリーダーを使用する人は、何が書かれているのか全く分からなくなってしまいます。

これは知らなかったら悪気なくやってしまうことの一つで、Twitterも140字で足りない時画像で文章書く人が多すぎる、と思いました

解決策は、なるべくテキストに起こし、CSSで加工することです。どうしても画像を使わなければならない場合は、SVGを利用すると良いでしょう。データの中にテキストを持つことができるため、機械で処理することが可能になります。そしてビットマップ形式の画像に比べ、綺麗に拡大することもできる便利なフォーマットです! 関連して、「謝罪文を画像にするのは、検索避け」という話題は面白かったです。「社内でも、SlackやWorkplaceでスクリーンショットを貼って共有を済ませることが多く、それなら元テキストへもリンクすべき」という話題が上がり、今後発信するときは意識しようと思いました。

8-2 コントラストが低い

要素の意味や性質によって要素の見た目を変えるとわかりやすくなりますが、使い方に一貫性がないと、どのスタイルがどの意味に対応するのか分からなくなり、かえって混乱を招いてしまいます。

異なる見た目のものが同じ意味で使われていたり、同じ意味の要素の配置が違っていたり、歴史の積み重ねによって現状のプロダクト内ではいたるところに発生してしまっています。しかし徐々に整ってきたデザインシステムを、プロダクトに反映できるようになってきました!今後はさらにデザインシステムの整備・既存プロダクトの置き換えを進めて、一貫性のあるプロダクトを目指します!

まとめ

8章まで読んできた感想としては、「無知は怖い」です。知れば当たり前だと思うことなのに、知らなければ悪気なく行ってしまうからです。アクセシビリティの具体的な内容を見ると、実はそこまで特別なことをしているわけではありません。ただ知らずにいるだけで、自分の環境以外の人の考慮ができていないと判断されるのはとても怖いことだと感じます。 今後も、無知な人にならないように、勉強していきたいと思いました。 これから定期的に、スパルタンUXの内容を発信していきたいと思っています!

freeeのQAの目指す姿-3/3

前回前々回で、freeeのQAの目指す姿について、QAチームのみんなと話がながら私が考えたことを書いてきました。

developers.freee.co.jp

developers.freee.co.jp

そして、前回の最後でいきなりジャンプはできないと書きました。いきなりジャンプして、品質が低下してしまったら本末転倒だからです。本末転倒とは、以下の図のような状態です。

スピードを速く、コストを適正におさめ、リリース単位を小さくした結果、品質が低くなりすぎてしまったレーダーチャート

これでは、サービスを使ってくれる人たちに価値をあたえられないだけでなく、品質でも選んでもらえるプロダクトを作るというかっこいい世界からは遠のいてしまいます。 品質は意識して引き上げていないと簡単に劣化してしまいますので、品質を適切なレベルに引き上げて、かつ簡単には品質が低下しないようにしていくことがfreeeのプロダクトが品質でも選んでもらえるプロダクトであるために必要だと思います。 理想の状況に持っていくためには、いろいろなアクションが必要だと思っており、これから書く内容こそがいままでの3回の記事の中で、あえ共(あえて共有する、というfreeeの価値基準の1つ)して意見が欲しかったところです。(ここまでが「遠かったー」って思う人もいると思います、すんません。)

スピードを速く、コストを適正におさめ、リリース単位を小さくしたが、品質は向上しているレーダーチャート

どんなアクションが必要だと思ってるか

ここから、前回前々回で書いたようなことを実現していくためには、どんなことをしていかなければいけないと思っているかを書いていきます。思いつくままに書いてるので、全部が本当に必要かも検討不十分ですし、優先順位もまだ考えていません。「ええっ!こんなにたくさんやるの?」って思わないでください。まだ、アイデアレベルであり、この中から現実的にできることから実践していきます。

チーム自身QA(自分たちでQAする)

チームでQAをするためのテストができるようになっていくことが必要だと思います。これらができると、そのテストのために大量に人が必要ではなくなると思っています。

  • 開発者全員がチーム自身でQAをやると言うマインドの醸成
    • 最初の取り組みとして、QAのメンバーが開発の一員として開発の初期から参加し、スクラムのイベントに参加したり、一緒に活動をする。開発初期からQAについて考えることを常態にする。
  • E2Eテストの効率化(手動でやるユーザー目線のテスト)
    • テストの道具を整備し、使いたいときにすぐ使えるように道具の在庫管理する。(道具とは、計算仕様のコンペアツール、ちょっとした自動化スクリプト、繰り返し使えるテストデータなど。)
    • 探索的テストのできる人材を増やすためにトレーニングなどをする。
    • プロダクト横断のQAのルール決める。統合点を簡潔にしていき(これは設計マターですが)、テストも少なくて済むようにする。
  • ユニットテストやサービステストを改善し、E2Eテストの前でバグ撲滅する。
    • ユニットテストにてテスト技法を普通に使う人が増えるようにトレーニングなどをする。同値分割や境界値分析のような基本的なテスト技法もあるが、原因結果グラフや状態遷移テスト、All-Pairといったテスト技法も普通に使う。
    • 意味のないユニットテスト(ユニットテストアンチパターン)を集めて共有し、同じ過ちをくりかえさないようにする。
  • テスト結果のデータベース(テスト管理ツール)への蓄積とテスト結果分析
    • 手動と自動テスト結果の蓄積をして品質リスク軽減のトラッキングし、どこまで品質リスクが軽減しているかが瞬時にわかるようにする。
  • チームによる品質判断のための基準(exit criteria / definition of done)
    • テストプランで合意した品質リスクが軽減されているかがまさに判断のための基準となる。
    • 合意した品質リスクに対するテスト実行カバレッジのリアルタイムモニタリングのためにテストや欠陥の管理ツールで瞬時に判断可能にする。
    • 内部品質(コードカバレッジなど)と外部品質(流出した欠陥)とカスタマーサポートの問い合わせを継続的に計測して相関関係をとる。
    • 開発チームとカスタマーサポートの間で欠陥についての情報交換をする。

ビジネスしていく上で会計freeeのようなツールが重要なのと同じように、開発には欠陥やテストケース(テスト結果)の蓄積が重要だと思っています。手動テスト用のテストケースだけでなく、自動テスト用のテストケースも該当します。特にテスト自動化のスクリプトが増えるほどテストケース数も膨大に増えていくので、テスト結果や欠陥データの蓄積とそれらのデータ分析をするのが必要になると思います。そのデータから自分たちで品質に対する判断をできるようにしていくのがよいと思います。

予防QA

QAとしてのテストを開始する前に品質を確保し、QAとしてのテストを短縮する活動を指します。前々回では予防テストと言ってたのに、ここであえて予防QAと呼ぶのは、テスト以外の活動も含めるからです。

  • QAがテストする必要がある箇所をちゃんと検討して合意
    • 単体テストをどこまでやるかをテストプランで合意する。テストプランは、チーム自身QAの一環でもあるが、最初のタイミングでテストしなきゃヤバイところをちゃんと考えて、QAとしてのテストに入るまでにエンジニアがどれだけテストするのかを明確にできるのが予防QAにつながる。
  • 再発防止
    • 欠陥分析とフィードバックで同じ問題を繰り返さないようにする。類似の問題が潜んでないかをテストしたり、リグレッションテストのテストケースに反映したりする。
  • 早期に品質確保
    • リスク洗い出し会を開発初期に行い、テスト観点でのレビューとフィードバックすると、開発前に仕様の曖昧なところが見つかる。
    • どのような方式で実装するか、設計をどうするかを確認することで、品質的な課題の有無を関係者が理解できる。

リグレッションテスト自動化(インパクトリスクを軽減)

QAのテストで時間がかかるテスト実行を機械に任せます。特に単純でつまらないけど、だれかが大量にやらなきゃいけないこと、例えば、会計freeeで言えば試算表や月次推移表の金額が勘定科目ごとに期首、借方、貸方、期末の金額が正しく集計されていることを1つ1つ確認するようなことは、人間の手動テストではすごく時間がかかります。金額が間違っていたら大問題なのでテストは必要ですが、時間もかかりコスト増になる上に、確認量が膨大すぎてテスト担当者が確認を間違える可能性があります。それに、確認量が膨大すぎて「いや、これ無理だろ!」って話になり、やらなくなってしまってはまずいです。なぜなら、ここで見つかる欠陥はインパクト(ユーザーへの影響)が高いからです。例えば数万を超える集計パターンをテストして欠陥が1件見つかるようなものでも、ユーザーが使ってて金額が間違ってしまったら大問題だからです。こういうものをインパクトリスクが高いと呼びます。

  • リグレッション自動化対象選定(インパクトリスクの高いもの)
    • ごく普通の使い方ではあるが、万が一問題あったらシャレにならないテストを洗い出す。(普通の操作はリグレッションテストに向いてる。)
  • チーム自身が自動化を進めていく
    • フレームワーク化とデータドリブン/キーワードドリブンを推進し、QAやSETを介在せすに運用する。(例えばプロダクトマネージャーがテストケース追加して、エンジニアが実行支援とスクリプトメンテを行う。)
  • 継続的に開発と非同期に自動テストができる環境/テストデータ準備
  • リグレッションテストでバグが見つかった時の速攻修正と本番適用
  • 自動テストの結果をテスト管理ツールへ蓄積し、どのテストがいつ最後に実行されたか、過去にバグが出たことがあるかといったことがわかるようにする。

QAの大政奉還

まずは、アウトプット→思考(これもfreeeの価値基準の1つ)を体現して、いろいろ書き出しました。

freeeのQAの役割は、品質面でも他より抜き出てfreeeを使いたいと思ってもらえるようになるってことだと考えていますが、実は、それだけではないと思うようになりました。QAがやるべきことは、freeeの開発チーム全体の品質に関する能力を最強にするなのではないかと思います。自分たちが作るプロダクトは自分たちが一番よくわかっているので、わかっている自分たち、つまり開発者自身でお客様への価値を考えるのは自然なことだと思います。QAをチーム自身に大政奉還するのは自然の流れです。

「freeeのエンジニアはテストが本当に上手だ!」って言われるようになれば最高です。それに向かって進めていけると思いますし、できることから実現に向けて進めていければと思います。(前回も書きましたが、QAに相当するテストをする専任メンバーが開発チームにいるケースはプロダクトによってあっても問題ありません。)

この3回で書いたことのどれかは今後のQAチームのOKRに反映して活動をすすめています。今はQAとして、リリース前にテストを行うことも精一杯頑張っていますが、理想のQAとして書いたことは組織でチャレンジしていくことになります。このような世界を作るのがQAという組織の仕事です。ただし、ここに書いたアクションはだけでは足りないこともあるかもしれません。適時見直して、本当に目指す世界を実現していくためにQAはこれからも精進していきます!

おしまい。(ここまでの全3回を読んでくれたみなさん、ありがとう!)